CarSim: Automatic 3D Scene Generation of a Car Accident Description

Arjan Egges, Anton Nijholt

Department of Computer ScienceUniversity of Twente

PO Box 217, 7500 AE Enschedethe Netherlands

Phone: (31) 53 4893686Fax: (31) 53 4893503

Email: {egges,anijholt}@cs.utwente.nl

Pierre Nugues

GREYC laboratoryISMRA

6, bd du Marechal JuinF-14050 Caen, France

Phone: (33) 231 452 705Fax: (33) 231 452 760

Email: pnugues@greyc.ismra.fr

ABSTRACT

The problem of generating a 3D simulation of a car

accident from a written description can be divided

into two subtasks: the linguistic analysis and the

virtual scene generation. As a means of communica-

tion between these two system parts, we designed a

template formalism to represent a written accident

report. The CarSim system processes formal de-

scriptions of accidents and creates corresponding 3D

simulations. A planning component models the tra-

jectories and temporal values of every vehicle that

is involved in the accident. Two algorithms plan

the simulation of the accident. The CarSim sys-

tem contains algorithms for planning collisions with

static objects, as well as algorithms for modeling

accidents consisting of more than one collision and

collisions with vehicles which have stopped.

1. INTRODUCTION

This paper presents the results of a prototypesystem to visualize and animate a 3D scene froma written description. It considers the narrowclass of texts describing car accident reports.Such a system could be applied within insur-ance companies to generate an animated scenefrom a police report. The research is part of theTACIT1 project [11, 12] at the GREYC2 labo-ratory of the University of Caen, in cooperationwith the ISMRA3.

There are few projects that consider auto-matic scene generation from a written text, al-though many projects exist that incorporate nat-

1Traitements Automatiques pour la Comprehension

d’Informations Textuelles2Groupe de Recherches En Informatique, Image,

Instrumentation3Institut des Sciences de la Matiere et du

Rayonnement

ural language interaction in virtual worlds, likeTRAINS [3], Ulysse [2, 4] and AnimNL [1].

Visualizing a written story requires a differ-ent approach. The language analysis has to dealwith texts where syntax and semantics are morecomplex than with spoken orders. TACIT basesits language processing techniques on a templatefilling paradigm, see [7] and [8] for more informa-tion about the conversion from text to template.This technique is successfully implemented inthe FASTUS system [5], in which it is possi-ble to obtain tabular information from a static(written) text very efficiently.

Section 2 describes the approach where wediscuss the different issues that play a role invisualizing an accident description. Section 3presents a formalism for describing an accident.Sections 4—7 cover planning techniques and ac-cident modeling algorithms that we use. Finally,temporal planning is discussed in Section 8.

2. PROBLEM APPROACH

“Vehicule B venant de ma gauche,je me trouve dans le carrefour, a faiblevitesse environ 40 km/h, quand le vehiculeB, percute mon vehicule, et me refusela priorite a droite. Le premier chocatteint mon aile arriere gauche, sous lechoc, et a cause de la chaussee glissante,mon vehicule derape, et percute la pro-tection metallique d’un arbre, d’ou unsecond choc frontal.” Text A4, MAIF

corpus.

“I was driving on a crossroad witha slow speed, approximately 40 km/h.Vehicle B arrived from my left, ignoredthe priority from the right and collidedwith my vehicle. On the first impact,my rear fender on the left side was hitand because of the slippery road, I lost

control of my vehicle and hit the metal-lic protection of a tree, hence a secondfrontal collision.” Text A4, MAIF cor-

pus, our translation.

The text above describes an example of anaccident from the MAIF4 corpus. This corpuscontains 87 accident descriptions that are writ-ten in French. The given text is a very goodexample of the possible contents of an accidentdescription: a rather complex accident betweena set of different objects (cars and trees).

If a simulation of this particular accident isto be constructed, a possible strategy is a di-rect one: try to find objects in the text and cre-ate them in a 3D environment. In [6], this ap-proach has been used to create objects directlyfrom a text. Although such a method may solvesome specific cases, it’s not sure that it wouldscale up gracefully to simulate a large numberof complex accidents. We investigated anotherapproach consisting in formalizing the textualcontents of an accident description. There aretwo reasons why a formalism is probably supe-rior:

1. Generality: if a formalism is developed, itdoes not only deliver a formal description,but it also makes the solution more gen-eral. A formal description forces an ab-straction from a set of specific situations(the accident descriptions) and hence re-sults in a more general solution.

2. Flexibility: the development of a formal-ism creates a distinction (and a means ofcommunication) between two totally dif-ferent tasks: one concerning the extrac-tion of valuable information from a writtentext and a planning/imaging task. Thisdistinction makes the final solution moreadaptable to different situations.

The task of simulating an accident is dividedin two main tasks: extract the necessary andrelevant information from the text, and createa 3D simulation from this (formalized) informa-tion. Figure 1 shows this division. The Car-

Sim5 system encapsulates the second task. Afinal question is: why should we bother to makea 3D simulation of the accident? Probably a2D environment will provide enough functional-ity to simulate almost every accident. We choseto use a 3D model, because of the extensibility.Perhaps, in the future, we might want an op-tion in the system to see the accident from the

4Mutuelle Assurance Automobile des Instituteurs de

France. MAIF is a French insurance company.5Car Accident Simulator

FD

Linguisticanalysis

Virtual scenegenerator

Figure 1: The two subsystems and the FD (For-mal Description) as a means of communication.

driver’s point of view. Furthermore, a 3D envi-ronment provides a way to view the accident inevery possible angle.

3. FORMAL REPRESENTATION IN

CarSim

3.1. The general accident model

The general model of the accident will from nowon be called M . This model contains variousmathematical structures, representing differentparts of the accident model. The CarSim sys-tem knows the following kinds of objects: mov-ing objects (dynamic objects) and motionlessobjects (static objects). Furthermore it knowscollision objects. We define M as follows:

Definition 1 Model M consists of three parts:a list MS of k static objects S1, . . . , Sk, a listMD of l dynamic objects D1, . . . , Dl, and a listMC of n collisions C1, . . . , Cn.

With the lists MS and MD, the general en-vironment in which the accident takes place canbe defined. Now only the accident itself hasto be defined. Based on the descriptions fromthe MAIF corpus, we conclude that most acci-dents can be defined as an ordered list of col-lisions, with a collision being represented by arelation between two objects from MD and/orMS

6. This ordered list MC then is defined asfollows:

Definition 2 MC is a list of n collisions C1, . . . , Cn

and ∀ Ci, Cj ∈ MC : i < j ⇒ Ci occurs beforeCj in time.

3.2. Static objects

In general, a static object can be defined withtwo parameters: one parameter defining the na-ture of the object and another parameter thatdefines the location of the object. Examples ofstatic objects are: trees, crossroads, pedestriancrossings, etc.

6Later on, we will give a more detailed explanation.

length

width

Figure 2: Simplified model of a dynamic object.The object is represented by a rectangle and itsposition is defined by the coordinates of the in-tersection point of the two diagonals..

Definition 3 A static object Si consists in atuple (K, C) with K ∈ {tree, traffic light, pedes-trian crossing, crossroad, straightroad, turn left,turn right} and C a tuple (x, y) representing theCartesian coordinates of the object.

3.3. Dynamic objects

Every dynamic object has a certain shape. Thisshape can be rather complex. The CarSim sys-tem maintains a simplified model of a dynamicobject, using the length and width shown in Fig-ure 2.

Dynamic objects can’t be defined by givingonly their nature and position. Instead of aposition, the movement of the object must bedefined. In the CarSim formal representation,the movement of an object is defined by twoparameters. The first parameter, the initial di-rection, defines the direction to which the objectis headed before it starts driving. This directioncan be to the North, South, East, or West. Thesecond parameter is an ordered list of atomicmovements. This list is called the event chain.A dynamic object can then be defined as follows:

Definition 4 A dynamic object Di consists ofa triple (K, I, EC) where K ∈ {car, truck}, I ∈{North, South, East, West}, and EC an eventchain.

The event chain is defined as an ordered listof atomic movements. Examples of atomic move-ments can be: driving forward, stopping, turn-ing left, etc. Changing lanes or overtaking couldalso be considered as atomic movements. Atpresent, CarSim recognizes only a small set ofatomic movements and we set them aside in ourprototype. The event chain can then be definedas follows:

Definition 5 An event chain EC is a list of m

events E1, . . . , Em, where E ∈ {driving-forward,

event 1event 2

event 3

Figure 3: A crossroad with a vehicle driving for-ward, turning left and driving forward with aninitial direction to the East.

stop, turn-left, turn-right, overtake, change-lane-left, change-lane-right} with ∀Ei, Ej ∈ EC : i <

j ⇒ Ei occurs before Ej in time.

With these definitions, we could for exam-ple define a dynamic object Di with K = car,I = East and EC =<driving forward, turn left,driving forward>. Figure 3 shows how this ve-hicle is placed.

3.4. Collisions

A collision is defined by giving the two objectsthat participate in the collision and some addi-tional attributes. In CarSim , these attributesare the collision coordinates and the parts of thevehicles that are involved in the collision. Thereis a slight distinction between the vehicle thatcollides (in other words: the actor) and the ve-hicle that is hit (the victim). For planning rea-sons (and also for linguistic grounds) it is usefulto maintain this distinction in the formalism. Tosummarize, a collision occurs between an actorand a victim. The victim can be either a staticor a dynamic object, the actor clearly has to bea dynamic object.

Next to the location (coordinates) of the col-lision, something has to be said about the con-figuration of the objects while colliding. Thisinformation is sometimes given in the text, seefor example text A4 from Section 2. The Car-

Sim system uses a simplified model of these ve-hicle parts. They are divided in four categories:frontal, rear, left side and right side, plus one‘unknown’ category. A collision can then be de-fined as follows:

Definition 6 A collision Ci is given by a quin-tuple (Oactor, Ovictim, Pactor, Pvictim, Ccollision)where Oactor ∈ MD, Ovictim ∈ MS ∪ MD, ob-ject parts Pactor, Pvictim ∈ {front, rear, leftside,rightside, unknown} and Ccollision a tuple (x, y)representing the collision coordinates.

With this definition, we can define an ex-ample collision. Let’s again consider text A4that describes an accident consisting of two col-lisions. We define MC = C1, C2. C1 is a colli-sion between two vehicles: vehicle B (the actor,VB) and the other vehicle (the victim, say VA).Furthermore, there is a static object mentionedin the text, a tree (T ). Say that the first colli-sion occurs at coordinates (1, 1). This collisioncan then be defined as C1 = (VB , VA,unknown,leftside, (1, 1)). The second collision occurs be-tween a static and a dynamic object. The actoris vehicle A. This vehicle collides frontally withthe tree (the victim). Because a tree doesn’thave a ‘part’ that collides, we define it as ‘un-known’. There is no need to give collision co-ordinates, because they depend on the positionof the tree and the trajectory of vehicle A. Toconclude, we give the formal description of textA4 that is given to CarSim:

// Static objects

STATIC [

ROAD [

KIND = crossroad;

]

TREE [

ID = tree1; COORD = ( 5.0, -5.0 );

]

]

// Dynamic objects

DYNAMIC [

VEHICLE [

ID = vehicleB; KIND = car;

INITDIRECTION = east;

CHAIN [

EVENT [

KIND = driving_forward;

]

]

]

VEHICLE [

ID = vehicleA; KIND = car;

INITDIRECTION = north;

CHAIN [

EVENT [

KIND = driving_forward;

]

]

]

]

// Collision objects

ACCIDENT [

COLLISION [

ACTOR = vehicleB, front;

VICTIM = vehicleA, leftside;

Trajectory planning

Accident planning

Temporal planning

Preplanning

Position planning

Figure 4: The planning architecture. The ar-rows indicate the planning order.

COORD = ( 1.0, 1.0);

]

COLLISION [

ACTOR = vehicleA, front;

VICTIM = tree1, unknown;

]

]

4. PLANNING

Planning complex events like collisions requiresa well-defined and flexible planning architecture.General planning algorithms which apply meth-ods incorporating artificial intelligence, are dis-cussed in [9] and [13]. The CarSim planneris much more straighforward, because the plan-ning process is not as complex as a lot of tradi-tional AI planning problems, see also [10].

The total planning process is performed byusing a number of different subplanners, whichperform a small part of the total planning task.The layout of the general planning architectureis shown in Figure 4. The first three plannersuse the event chain and they do not address thedata that is given by the collision(s). The lattertwo planners do consider the collision data.

4.1. The preplanner

The preplanner is a planner that ensures theconsistency of the formal description. If somevalues are not given (e.g. coordinates of a staticobject or initial directions of dynamic objects)

or some values imply a contradiction (a vehi-cle turning left on a straight road), this plannertries to find (default) values and to solve the con-tradictions, if possible. This planner is a simpleknowledge base, as discussed in [10].

4.2. The position planner

The position planner estimates the start and endpositions of the vehicles in the simulation. Bydefault a vehicle is placed 20 metres away fromthe center of the (cross)road. If two or morevehicles are moving in the same direction, theycan’t all be placed at this distance because theywould overlap. Therefore, if there is more thanone vehicle facing a particular direction, the sec-ond vehicle is placed at a distance of 26 metresfrom the center and if there is a third vehicle,it is placed at 32 metres from the center7. Re-garding the end points of the vehicles, the vehi-cle that is placed closest to the center, will haveits end point placed farther away from the cen-ter. The vehicle initially having a start pointfar away from the center, will have an end pointclose to the center, so that every vehicle tra-verses approximately the same distance.

Regarding a crossroad, there are four ‘sub-roads’ to place the vehicles on. The road onwhich a vehicle is placed, depends on the initialdirection of this vehicle. If the initial directionof a vehicle is East, it will have its start pointplaced on the West road of the crossroad. Ifthe initial direction is North, the vehicle will beplaced on the South road, and so on.

4.3. The trajectory planner

For two reasons, an event chain can’t be directlylinked to a dynamic object. First, the eventchain is a very restricted form for defining themovement of an object. To maintain general-ity in the system, a more abstract form that isapplicable to a larger number of different situa-tions is required. A second reason is that mod-eling an accident as a part of the event chain(for instance, as a collision event) is not prac-tical, because collisions often don’t occur beforeof after an event, but during it.

Instead of linking an event chain to a dy-namic object, the system links a trajectory toevery dynamic object, which is created from thecorresponding event chain. The difference be-tween a trajectory and an event chain is thatthe trajectory is a more abstract representationof the movement of a dynamic object.

7In the CarSim system, the maximum number of ve-

hicles that can have the same initial direction is three.

Figure 5: A possible trajectory belonging to theevent chain of Figure 3.

A trajectory is basically a polyline (a col-lection of connected line segments). The trajec-tory is defined by a list of points, represented byCartesian coordinates. The trajectory consistsof the straight lines (or trajectory segments) con-necting these points.

Every event in the event chain is convertedto a list of trajectory points. A turn is approx-imated by a number of points lying on a circlearc. Overtaking is modeled by using a gonio-metrical function. Creating the trajectory corre-sponding to the event chain from Figure 3 couldhave as a result the trajectory shown in Figure 5.

4.4. The accident planner

After the application of the trajectory planner,a trajectory has been created for every vehicle.These trajectories do not incorporate any col-lision. In fact, they are created without evenlooking at the collision data. The CarSim sys-tem uses two algorithms for modeling the acci-dent. One for altering the trajectory and an-other one for incorporating the collisions in thetrajectory. This mimics the description of caraccidents in texts. Drivers describe a trajectoryin which collisions are anomalous deviations ofthese trajectories.

4.5. The temporal planner

The final planner called by the planning man-ager is the temporal planner. While all the otherplanners concerned the location of objects, thisplanner addresses the temporal issues of the ac-cident model. The most important part of this

planner is the part that synchronizes the col-lisions (actor and victim arrive at the collisionpoint at the same time). A more detailed ex-planation of the temporal planner will follow inSection 8.

5. ACCIDENT MODELING

This section describes the accident planner. Itpresents two algorithms that are used by theCarSim system to model simple accident con-figurations, consisting only of one collision. Amore complex accident model will be introducedin Section 6.

5.1. General approach

The accident planner uses the trajectory that iscreated by the previous planners. This trajec-tory is planned as if there was no collision at all.The task of the accident planner is to change thistrajectory in such a way that it incorporates thecollision. Some part of it has to be thrown awayand an alternative part (which ultimately leadsto the point of collision) has to be added to thetrajectory. For every vehicle, actor or victim,the trajectory is changed in two steps:

1. Remove a part of the trajectory.

2. Add a part to the trajectory so that thefinal result will be a trajectory that leadsthe vehicle to the point of collision.

These two steps are the basis of the accidentplanner. The first step is performed by a circleintersection algorithm that will be explained inthe next subsection. Section 5.3 presents the al-gorithm for adding a trajectory part so that thecorresponding vehicle will come at the collisionpoint.

5.2. The circle intersection algorithm

The section of the trajectory that is removed de-pends on the location of the collision point andthe precision of the algorithm that is applied.The circle intersection algorithm removes thetrajectory segments that lie (partially) withinthe region of a circle with center (x, y) (the col-lision point) and radius r. This radius is thusa parameter that defines the precision of the al-gorithm. If a large radius is chosen, a lot oftrajectory segments will be removed. An ap-plication of the algorithm using a small region,removes only the trajectory segments closest tothe collision point.

(x,y)start point

end point

rinit

Figure 6: A trajectory and a collision point. Thecircle intersection algorithm draws a circle withradius rinit and searches within this circle forintersecting trajectory segments.

The algorithm has to be applied to the tra-jectories of both vehicles involved in the colli-sion. It will be presented here for one trajectory,because applying the algorithm to multiple tra-jectories does not differ.

Suppose we have a trajectory T consistingof the trajectory points t1, . . . , tn. The collisioncoordinates are defined by (cx, cy). The algo-rithm starts searching for intersecting trajectorysegments within a circle with radius rinit. Ifit does not find any intersecting trajectory seg-ments, the algorithm increments the radius witha step size s and searches again, until the radiushas reached an amount of rmax. The final algo-rithm consists of four steps:

1. Set i = 1 and j = 2 (thus the first segmentof the trajectory) and set r = rinit.

2. If the trajectory segment ti − tj lies (par-tially) within the circle C with center (cx, cy)and radius r, remove the trajectory seg-ment ti − tj and ∀k ∈ {j, . . . , n − 1}: re-move the trajectory segment tk−tk+1; endof algorithm.

3. Set i = i + 1 and j = j + 1. If i = n go to4. else go to 2.

4. If i = n and no trajectory segment wasremoved, set r = r + s. If r < rmax, go to1. else no collision could be modeled; endof algorithm.

Consider the trajectory and the collision pointin Figure 6. This shows the initial situation ofthe circle intersection algorithm.

For every trajectory segment, starting withthe first one, the algorithm determines if the seg-ment lies within the circle region. If this is thecase, the segment is removed. Figure 7 showsthis situation.

All the succeeding segments are also removed.This situation is shown in Figure 8. Figure 9shows the final situation after calling the circleintersection algorithm.

(x,y)start point

end point

rinit

Figure 7: The circle intersection algorithm hasremoved the segment defined by the fifth andthe sixth point, which lies partially in the circle.

(x,y)start point

end point

rinit

Figure 8: The circle intersection algorithm hasremoved all the segments that come after thefirst removed segment.

(x,y)start point

end point

Figure 9: Final situation after calling the circleintersection algorithm.

frontal rear

left side right side

Figure 10: The four possible collisions for a ve-hicle, given its last trajectory point and the col-lision coordinates (the large dot).

5.3. Collision modeling

When first considering Figure 9, one would thinkthe collision modeling is easy: it consists only inadding the segment between the last point ofthe trajectory and the collision point. However,this does not result in a realistic model of thecollision.

The position of an object is defined as coor-dinates of the intersection of the two diagonalsof the rectangle representing a simplified modelof the object (see Figure 2). If two vehicles thatparticipate in a collision collided with the samecoordinates, they would be crossing each otherin the collision point, which would result in anunrealistic situation. Furthermore, when apply-ing this kind of collision model, we are overlook-ing something, namely the fact that a collision isnot only defined by its coordinates and its par-ticipants, but also by the parts of the involvedvehicles.

The collision point is defined as the pointwhere the two participants in the accident touch,or better: where the two participating parts ofthe vehicles touch. There are four possible partsof a vehicle that can participate in an accident:the frontal part, the rear part, the left side andthe right side. The CarSim system uses thesefour parts to create a simplified model of thecollision: a vehicle always collides in the middleof the part that is involved in the collision. Forevery vehicle this implies four different collisionconfigurations (see Figure 10). In this figure, thevehicle is drawn at its last trajectory point andthe trajectory segment that should be added tothe trajectory is marked with a dotted line.

The final coordinates of the vehicle do notonly depend on the collision coordinates, butalso on the coordinates of the last trajectorypoint and the part of the vehicle that is involved.Furthermore, the length and width of the vehi-cle play an important role, for they define thedistance of the vehicle from the collision point

(Cx,Cy)

width

Figure 11: A detailed collision model of a carcolliding with its left side.

(Cx,Cy)

length

Figure 12: A model of a car colliding with thefront.

when it collides.

If a vehicle collides with its left side, for ex-ample, the final coordinates will lie on the circlewith center (cx, cy) (the collision point) and ra-dius width

2(see Figure 11).

In fact, the final coordinates of the vehicleare the coordinates of the intersection point ofthe circle and a tangent to this circle, passingthrough the last trajectory point of the vehi-cle. For this tangent there are two possibilities:an intersection above the collision point and anintersection beneath the collision point. The in-tersection point below the collision point definesa collision with the left side (as in Figure 11)and the intersection point above the collisionpoint determines a right side collision. Find-ing these intersection points is an application ofbasic mathematical algorithms.

For frontal and rear collisions, the methodis slightly different. For the radius of the cir-cle should now be chosen length

2. The situation

that corresponds to a frontal collision is shownin Figure 12.

In this figure, the final coordinates are notdefined by the tangent, but by the intersectionof the circle and the line passing through the tra-jectory end point and the collision point. Thereare again two intersection points. The intersec-tion point that lies between the collision pointand the trajectory end point corresponds to afrontal collision. The intersection point that liesafter the collision point (extrapolate the dottedline drawn in Figure 12) corresponds to a rearcollision.

trajectory

collisions

1

2

3

4 5

Figure 13: An example of a trajectory of a ve-hicle with 5 collisions C1, . . . , C5.

trajectory

collisions

1

2

3

4 5

Figure 14: An example of a trajectory of a vehi-cle participating in 5 collisions C1, . . . , C5. Thisfigure represents a simplified form of the colli-sions (the dotted lines are actually not the realtrajectory segments that are added (see Sec-tion 5.3)).

6. MULTIPLE COLLISIONS

A number of accidents in the MAIF corpus con-sist of multiple collisions. A clear example ofthis is text A4, that defines two collisions: acollision between two vehicles and after that, acollision between a vehicle and a tree. Here wedo not consider collisions with static objects, sowe will assume that the collision modeling con-sists in modeling a number of collisions betweentwo dynamic objects. The mathematical repre-sentation of an accident consists of an orderedlist of collisions C1, . . . , Cn. Figure 13 shows anexample situation for 5 collisions.

For most of the cases, the distance betweenthe collision points is not very large. A simplestraight line between them already renders anacceptable simulation. This action is shown inFigure 14. Furthermore, remember that the col-lision modeling algorithm has to be called to geta realistic result. Hence, a simple algorithm formodeling multiple collisions is as follows:

1. Set i = 1.

2. Let (cx, cy) be the coordinates of collisionCi and let ACi

be the actor and VCibe the

victim of Ci.

3. Apply the collision modeling algorithm to

ACiand add the calculated trajectory point.

4. Apply the collision modeling algorithm toVCi

and add the calculated trajectory point.

5. Set i = i + 1. If i > n end of algorithm,else go to 2.

7. OTHER ACCIDENT

CONFIGURATIONS

In the MAIF corpus, a number of accidents in-volve static objects (for instance a collision witha tree, text A4). Collision modeling with staticobjects or stopped vehicles consists in finding aplausible collision point. The static object doesnot move of course, so only a trajectory for theother (dynamic) object (the actor) involved inthe collision has to be defined. We will first dis-cuss how we can find a proper collision pointand after that we will show that the trajectoryof the actor can easily be calculated.

In CarSim, static objects are represented bya tuple (K, C) that defines nature and locationof the object. Such an object can have a verycomplex exterior geometry (e.g. a house or apiece of a guard rail). In the CarSim system,a static object Sj is approximated by a cylin-der with a centre (xSj

, ySj) and a boundary ra-

dius rboundary (the height is not important forthe simulation). In this way, a rather easy wayto calculate the collision coordinates comes for-ward. In a simplified model, the collision pointlies on the circle that is defined by the approx-imation and it can be found by drawing a linebetween the last trajectory point and the circlecentre.

Modeling a collision with a stopped vehicleis almost similar to modeling a collision witha static object. However, a (stopped) vehicleis represented by a rectangle and this requiresanother approach. The CarSim system definesfour possible collision points relative to the po-sition of the stopped vehicle. Figure 15 showsthese points.

The position of the stopped vehicle that isinvolved in the collision and a given vehicle part(for example front or rear side) thus define thecollision point.

Given a collision point, the circle intersectionalgorithm as discussed in Subsection 5.2, canthen be used to determine the final trajectoryof the other car that is involved in the collisionin both cases.

Figure 15: The four collision points relative toa stopped vehicle.

8. TEMPORAL PLANNING

Temporal planning has been a subject of re-search within the Artificial Intelligence domainfor some time. A lot of temporal planning meth-ods have been developed within the blocks world.In [9] and [13], this world is described and sim-ple temporal planning algorithms such as theSTRIPS planner are discussed. The CarSim sys-tem performs temporal planning in another way.The temporal planner of the CarSim systemplans the temporal values of the trajectory intwo steps. First the segment that is not partof any collision is planned. After that, the sys-tem plans the remaining segment (representinga number of collisions).

8.1. Temporal structure

To maintain the temporal values, coordinates donot suffice to define a trajectory point. For ev-ery point, some temporal information must bemaintained. In the CarSim system, every tra-jectory point has a time value. This is a valuebetween 0 and 1, with 0 representing the be-ginning of the simulation and 1 being the endof it. For the vehicles that participate in oneor more collisions, there has to be a synchro-nisation between the collisions. To be able tomodel this synchronisation, the temporal plan-ner has to know which trajectory segment be-longs to which collision. This means that forevery trajectory point a value containing the in-dex i of the corresponding collision has to bemaintained. If a trajectory point has a colli-sion index that equals −1, the trajectory pointdoesn’t correspond to a collision.

Definition 7 A trajectory point ti consists in atriple (C, p, i) with C representing the Cartesiancoordinates (x, y) of ti, p a value between 0.0 and1.0 representing the moment in time and i theindex of the corresponding collision. If i = −1,

ti does not correspond to a collision, but is anormal trajectory point.

Generally, a trajectory consists of a num-ber of ‘normal’ trajectory points, followed bya number of trajectory points that represent acollision. Suppose that there are n trajectorypoints and k + 1 points represent a collision.The trajectory can then be represented as fol-lows: t1, . . . , tn−k . . . , tn, the last k + 1 pointsrepresenting collisions. The trajectory can besplit in two parts, one part representing a nor-mal trajectory t1, . . . , tn−k and a second partrepresenting a number of collisions tn−k, . . . , tn.A parameter of the temporal planner is the timevalue of the point that splits the two trajectoryparts, the time value of tn−k, which representsthe first collision of the trajectory. This timevalue is called Tsplit from now on.

8.2. The first trajectory part

The first trajectory part does not require anysynchronisation, because it only contains tra-jectory points that do not represent a collision(except for the last point). The planner has tocalculate for all of the n − k points the corre-sponding time value, which lies in the interval[0.0, Tsplit]. If we want the vehicle to have thesame speed all of the time, the calculated timevalues have to depend on the length of every tra-jectory segment. This length can be calculatedusing basic mathematics. The CarSim systemcalculates the percentage of the total length ofthe first trajectory segment and can then cal-culate the percentage of time that has to be as-signed to every trajectory point in the first part.

8.3. The second trajectory part

The second trajectory part consists of a num-ber of collisions, represented by the trajectorypoints tn−k, . . . , tn. The vehicle correspondingto this trajectory should finally participate inall the collisions that are represented by thesetrajectory points. Of course, every vehicle doesnot participate in every collision. That meansthat this vehicle may participate in k + 1 colli-sions, but that the total simulation may consistof more than k + 1 collisions. Say that for thetotal simulation n collisions C1, . . . , Cn are de-fined (n ≥ k +1). These collisions begin at timevalue Tsplit and end at 1.0. A very simple wayto plan the temporal values of these collisionsis to divide their time values equally over theinterval [Tsplit, 1.0]. This situation is shown inFigure 16.

Tsplit

C1 C2 C3

1.0

Cn-1 Cn

Figure 16: The division of the time values forcollisions C1, . . . , Cn.

The time value for collision Ci, representedby TCi

can be calculated as follows:

TCi= Tsplit +

1.0 − Tsplit

n − 1· (i − 1) (1)

As stated before, not every car participatesin every collision. Let us again consider the ve-hicle with trajectory t1, . . . , tn−k . . . , tn. For ex-ample, the time value responding to tn−k couldbe TC1

, the time value to tn−k+1 could be TC8

and so on. The corresponding time values de-pend thus on the collision index i that is definedin the structure of the trajectory point. There-fore, assigning the right time values for everycollision results in the following three steps forevery tj ∈ {tn−k, . . . , tn}:

1. Read the collision index i from tj .

2. Calculate the time value TCiwith (1).

3. Assign TCito ptj

.

8.4. Finalizing temporal attributes

When the trajectory time values have been cal-culated as described in the previous subsections,not every vehicle has a correct time value array.We know that the first trajectory point musthave a time value 0.0. This is taken care of whileplanning the first trajectory part. The last tra-jectory point must be 1.0. This is not alwaystrue after calculating the time values, becausea vehicle does not participate in every collision.If a vehicle does not participate in the last col-lision Cn (which has time value 1.0), then thelast collision point of this vehicle (which is alsoits last trajectory point) will have a time valuethat is less than 1.0.

To solve this problem, one has to think aboutwhat the vehicle has to do after reaching its lasttrajectory point. The best solution is to let thecar stay at the same position for the rest of thetime. Thus, a stop has to be added to the tra-jectory. This results in adding a trajectory pointthat has the same coordinates as the last trajec-tory point of the vehicle, with a time value of1.0. In this way, the vehicle waits until all colli-sions between other vehicles have been finished.

Figure 17: The first collision in text A4.

Figure 18: The second collision in text A4.

9. SIMULATING TEXT A4

Given the accident description in Section 2, theCarSim system can generate an animated sceneof the accident. Figure 17 shows the first colli-sion and Figure 18 the second one.

10. CONCLUSION

Creating a system that simulates accidents iscomplex. Right now, the CarSim system isable to generate an acceptable simulation of atleast 50 texts of the accident descriptions in theMAIF corpus. This boils down to a little lessthan 60% of the texts in the corpus. The acci-dents that can’t be simulated, are accidents withmotorcycles, accidents with an unusual cause orcomplex interactive models (such as accidentsincorporating traffic lights that change color).

Although the CarSim system can simulatenearly 60% of the accident template descrip-tions, the final result will depend on what thelinguistic analyzer delivers. The performance of

a final system that incorporates automatic lin-guistic analysis will certainly be lower. How-ever, we believe that information contained intemplates can be obtained with a good accuracyusing information extraction techniques. Link-ing CarSim with such the linguistic part corre-sponds to the next stage of our project.

11. REFERENCES

[1] N. Badler, W. Becket, B. Di Eugenio,C. Geib, L. Levison, M. Moore, B. Web-ber, M. White, and X. Zhao. Intentionsand expectations in animating instructions:the AnimNL project. In Intentions in An-imation and Action. Institute for Researchin Cognitive Science, University of Pennsyl-vania, March 1993.

[2] O. Bersot, P.O. El-Guedj, C. Godereaux,and P. Nugues. A conversational agent tohelp navigation and collaboration in virtualworlds. Virtual Reality, 3(1):71–82, 1998.

[3] George Ferguson, James F. Allen, and BradMiller. TRAINS-95: Towards a mixed-initiative planning assistant. In Proceed-ings of the Third International Conferenceon AI Planning Systems (AIPS-96), May1996.

[4] C. Godereaux, P.O. El-Guedj, F. Revolta,and P. Nugues. Ulysse: An interactive, spo-ken dialogue interface to navigate in virtualworlds, lexical, syntactic, and semantic is-sues. In John Vince and Ray Earnshaw, ed-itors, Virtual Worlds on the Internet, chap-ter 4, pages 53–70. IEEE Computer SocietyPress, 1999.

[5] Jerry R. Hobbs, Douglas Appelt, JohnBear, David Israel, Megumi Kameyama,Mark Stickel, and Mabry Tyson. FASTUS:A cascaded finite-state transducer for ex-tracting information from natural-languagetext. In Roche and Schabes, editors, FiniteState Devices for Natural Language Pro-cessing. MIT Press, 1996.

[6] Yann Mathet. Un formalisme pour ledeplacement. In actes de TALN, 1998.

[7] Proceedings of the fifth Message Under-standing Conference. Morgan KaufmannPublishers, Inc., August 1993.

[8] Proceedings of the sixth Message Under-standing Conference. Morgan KaufmannPublishers, Inc., November 1995.

[9] Nils J. Nilsson. Artificial Intelligence, aNew Synthesis. Morgan Kaufmann Pub-lishers, Inc., 1998.

[10] P. Norvig and S. J. Russell. Artificial intel-ligence: a modern approach. Prentice Hall,1995.

[11] F. Pied, C. Poirier, P. Enjalbert, andB. Victorri. From language to model.In Workshop Corpus-Oriented SemanticAnalysis in European Conference on Arti-ficial Intelligence (ECAI), August 1996.

[12] C. Poirier and F. Pied. Analyse de constatsamiables d’accident automobile. In 1er Col-loque etudiant en Linguistique Informatiquede Montreal, June 1996.

[13] Yoav Shoham. Artificial Intelligence Tech-niques in Prolog. Morgan Kaufmann Pub-lishers, Inc., 1994.