Nick Arvin: In the company where I worked, we had an engineering group and an animation group. In the engineering group, we created what we called motion data, which was a description of how the vehicle moved. We fed the motion data to the animators, and they created the imagery. The motion data was extremely detailed, describing a vehicle’s movement tenth of a second by a tenth of a second. At each of those points in time we had roll, pitch, yaw, and locations of vehicles. To generate such detailed data, we sometimes used a specialized software program⎯the one we used is called PC-Crash⎯or sometimes we just used some equations in Excel.

When you’re using PC-Crash, you start by entering a bunch of numbers to tell the program what a vehicle looks like: how long it is, where the wheels are relative to the length, how wide it is, where the center of gravity is, how high it is, and a bunch of other data I’m forgetting right now.

Once you’ve put in the parameters that define the vehicle, it’s almost like a video game: you can put the car on the roadway and start it going, and you put a little yaw motion in to start it spinning. You can put two vehicles in and run them into each other, and PC-Crash will simulate the collision, including the motion afterward, as they come apart and roll off to wherever they roll off to.

Often you have a Point A and a Point B, and you need the animation to show how the vehicle got from one to the other. Point A might be where two vehicles have crashed into each other, called the “point of impact.” The point of impact was often fairly easy to figure out. When vehicles hit each other—especially in a head-on collision—the noses will go down and gouge into the road, and the radiator will break and release some fluid there, marking it. Then, usually, you know exactly where the vehicle ended up, which is Point B, or the “point of rest.” But connecting Points A and B was the tricky part.

Twilley: In real life, are you primarily using these kind of animations to test what you think happened, or is it more useful to generate a range of possibilities that you can then look for evidence of on the ground? In the book, your reconstructionists seem to do both, for example, going back and forth between the animation and the actual ground, generating and testing hypotheses.

Arvin: That’s right. That’s how it works in real life, too. Sometimes we would come up with a theory of what happened and how the vehicles had moved, and then we’d recreate it in an animation, as a kind of test. Generating a realistic-looking animation is very expensive, but you can create a crude version pretty easily. We’d watch the animation and say, “That just doesn’t look right.” You have a feel for how physics works; you can see when an animation just doesn’t look right. So, very often, we’d look at an animation and say to ourselves: We haven’t got this right yet.

One of the challenges of the business is that when you’re creating an animation for court, every single thing in it has to have a basis that’s defensible. An animation can cost tens of thousands of dollars to generate, and if there is one detail that’s erroneous, the other side can say, “Hey, this doesn’t make sense!” Then the entire animation will be thrown out of court, and you’ve just flushed a lot of money down the toilet. So you have to be very meticulous and careful about the basis for everything in the animation.