Starting Out

My name is Richard Jobling and I am a Senior Software Engineer here at iRacing. For a long time now my primary focus at iRacing has been to develop our new damage model. It’s been a long journey, and I’d like to share some details from along the way.

When we first discussed improving damage in iRacing, we focused on the goal of adding parts to the cars that would break off during impact. Immediately I started adding more to our to-do list such as improving the particles and sounds to complement breakable parts.

As a recent hire at the time, I optimistically thought this might not be too much work. Surely I could integrate some existing physics middleware to simulate the car parts and some other middleware for particle effects.

However, as we spent more time discussing priorities, it became clear that at iRacing more so than other games, we value the authenticity of our simulation. That means that everything has to work together to be physically accurate. When we discuss new features, we have to consider all the physical processes that take place.

For car damage, it isn’t enough to just throw off parts and effects during a crash. For iRacing we want to model as much as possible of everything happening during an impact: flexing, crunching, breaking, separating, etc.

Also, because the physics is so important to iRacing we wanted to keep control of our code rather than depend on middleware. That being said, the existing systems had a lot of shortcomings that we wanted to improve on for the future.

And so the project grew to the point where we have written entirely new systems for collision and damage and reworked much of the physics.

Headed out on track at Lime Rock park to gain some real world experience in the Skippy.

 

I have have first-hand knowledge of what happens to a race car when it comes into contact with a wall – no wonder Dave assigned me to this project!

Cones

Rather than tackle damage straight away we first worked on making the track cones dynamic. This would help us learn more about what to improve.

Building on the existing tech we successfully implemented dynamic cones which on the surface seemed like a great step forward. However, as much as the cones were now moving it was clear that our current systems needed improving.

The collision for cars and cones are represented as a series of spheres. This is great in that it is simple and we can efficiently test many spheres against our track geometry. However using spheres makes it hard to represent long, flat or thin shapes or even cones. Also, there would always be holes between spheres, and the final aggregate shape ends up being lumpy, so we need a separate set of planes for the other car/cone.

Testing one set of object spheres against another objects planes works well enough. Unfortunately, it can lead to inconsistencies when the order of the objects is flipped. So, for example, the cone works well when tested against the car planes but not the other way around.

So our problems were that we couldn’t represent our shapes well without using many more spheres and that we needed two different collision representations in use, which led to some problems of asymmetry.

Furthermore, if we can reduce our collision to one representation, then impacts between cars would be more consistent from client to client. This would go some way toward improving what everyone loves to call the netcode.

Also, we have always struggled with the spheres sticking through walls at high speeds, and now cones could get trapped in cars. We wanted to improve in those areas as well.

You can see the two different collision representations below.

What Already Works?

Having tried out cones, we knew we needed to make some big changes, so it made sense to take stock of what was currently working well for us.

Simulating physics for iRacing is unique in some ways that differ from typical middleware and aren’t immediately obvious, but they make a significant difference in our pursuit of realism. Anything new would need to maintain these custom features.

Collisions in iRacing are not like the usual billiard ball physics in video games. Typically an impact in a video game is simplified, so it’s considered instantaneous. When one object bounces off another, the response is immediate, and the objects that were moving toward each other will be traveling away from each other with some energy loss.

This works for most games, but it isn’t very realistic in cases we care about. For example, when cars bounce off each other, we want drivers to be able to maintain control realistically. If the impacts affect the cars instantly, it’s hard for players to predict and react in time. Real cars are not infinitely stiff; impacts involve flex which takes a little time.

This is an important phenomenon that iRacing captures by running the physics at a high frequency of 360hz and by implementing what is known as the penalty method for impact forces. Penalty forces by their nature can spread the impact over multiple frames and allow us to model more variety in how materials collide.

Also important to iRacing is the road surface, this needs to be smooth to drive on but also detailed enough that it includes all the real world bumps and dips our laser scans capture.

Most games use a low-resolution triangle mesh for track collision. At iRacing our surfaces are defined parametrically as smooth sweeping road sections on which we overlay a separate bump map. The bump map is what captures all the track details in high fidelity.

This high resolution is critical, so our tire model has enough detail to work with when reproducing an accurate representation of the track features and the road feel.

GJK Collision Shapes

To improve the collision shapes we decided to replace the aging, but efficient spheres and planes approach with a new system which would use sets of convex shapes.

Convex shapes are a good choice because we can still process them efficiently, and by combining a set of them we are able to match the shape of the car very closely.

To support convex shapes, we implemented the GJK algorithm which also makes it trivial to add shapes such as those needed for our tires. The details of the GJK algorithm we can skip and just look at what the new shapes look like.

Below is our car with the newly defined GJK shapes.

With the new approach, we can now collide one set of shapes with those of another. So both cars use the same shapes for collision, solving our asymmetry problems and giving us more consistent outcomes.

Another property of the old spheres was that we could move them to represent the effects of damage. Each sphere would move inward to approximate how the car was bending or crushing at that location.

For our convex shapes, we can improve on this as well. We can morph our convex shapes based on damage. In fact, we can control the morphing, so each shape is only affected in the damaged areas, giving us finer control than the spheres.

Modeling these convex shapes has been a huge job for the art team. For each car, they need to reexamine exactly how they are constructed so we can build appropriate shapes. Shapes for the underlying chassis, body panels, wings and everything else need to be modeled, so they fit the car correctly and detach at the right locations. In many cases, we need to go back to reference materials just to figure out exactly how that car was constructed in the real world to match it as closely as possible.

Contact Manifolds

Unfortunately, the physics for contacting convex shapes is not as simple as that of a sphere and a plane.

With our old system, we could reduce each pair of sphere/plane contacts down to a single point for which we would then compute the collision and friction forces.

This was simple, but it did mean that to rest a cone on the ground we needed at least four spheres at the base, one for each corner if it was going to rest realistically rather than roll away. For most objects, this led to us adding yet more spheres.

With convex shapes, on the other hand, we can represent the shape of the cone using only two convex shapes: a box for the base and a pyramid for the top.

But to rest the cone on the ground, we still need to determine the supporting forces concerning how it sits in contact with the road.

Rather than splitting the cone shapes up as we did with our spheres we’d prefer to determine how the base rests on the ground.

This is solved with what is sometimes called a contact manifold. The manifold maintains a set of contacts collected over the last few frames. Contacts are retained so we can eventually construct a stable set of corner points which will support the cone.

Below is an image showing some cones and their contact manifolds when at rest. The same approach is used for all the important parts of the car as they contact the ground and the surrounding walls, as well as other cars and objects.

Track Collisions

Unfortunately, when it comes to testing against our custom track surface, the new convex shapes are not as straightforward as the spheres.

It was relatively easy to construct planes for each sphere based on the surrounding track data. This was not efficient, but it was workable with the number of spheres we were using for cars. It was also convenient to apply the fine detail from the bump map to the planes.

However, when considering convex shapes, it’s not practical to reduce the track surface to a set of flat planes. Long shapes can potentially stretch across parts of the track that should dip down or rise, and this wouldn’t be captured by flat planes.

As mentioned most games use a low-resolution triangle mesh to represent the environment. This is a more practical representation for GJK shapes, but has its own problems that need to be addressed.

In our case, we need a high level of detail. To reach our required fidelity we need the mesh tessellation to be at least within a half meter. For a track like the Nürburgring that can end up requiring approximately 5 million triangles. Storing that many triangles alone will use almost 100meg.

Fortunately, there are data structures we can use to accelerate mesh collision queries, but those take up even more valuable memory. Our initial attempts ended up with huge data and performance overheads compared to the previous system.

After much head scratching, we were able to design our own custom data structure that was both compact and efficient enough for our high level of detail.

For creating our mesh data, we created a preprocessing tool that reads the parametric track definitions and after much work produces an optimal triangle mesh in our custom format. The tool tries hard to tessellate with consistent precision across the entire road surface while keeping all the featured grooves and transitions our guys work so hard on.

The consistency helps us maintain stable performance no matter what part of the track cars are racing on. With our existing system tight corners or other detailed areas would perform worse due to the extra detail, now we can have the same level of detail in all areas and with the same performance.

Here is a screenshot of one such track mesh.

It’s impossible to see the subtle detail in the mesh required by the tire model. However, without it, each track would lose its character and feel very smooth and artificial.

One advantage of the mesh approach is that it is adaptable to particle collisions. And so when we introduced the new particle effects some time ago, we were able to use meshes early rather than wait for the entire new collision and damage system. So the meshes are already out there and in use.

Damage Mounts

Colliding with other cars and the environment is only one aspect we need to model. Another important area we need to consider is how we simulate the resulting damage.

As mentioned, for the spheres our old system worked by moving the sphere positions to approximate crushing. The forces for a sphere contact were divided into what we call elastic and plastic forces to model both the collision and damage effects.

Now that we have convex shapes which morph to accurately model crushing we need a complementary method for tracking our damage state.

Additionally, we want to be able to detach some car parts when there is sufficient damage. And in many cases we want those pieces to remain tethered to the car, for example when a hood breaks open but remains hinged and should flap up and down.

This led to the addition of what we call mounts. Each car in addition to having multiple collision shapes now also has a set of mounts associated with each part of the car. Each mount models damage in a local area for that part and can also model a connecting spring to simulate hinges and other attachments.

We position and specify all the mounts needed for damage and attachments across the car. Each mount can be tuned to represent the underlying construction at that location.

As the shapes detect collision, they generate forces which are propagated through each mount causing appropriate damage. Each contact taken in turn gradually damages the mounts which then cause the collision shape to crush and eventually when possible detach.

Below you can see an image showing our car with boxes at the mount locations.

Removing Parts

We also need to accurately model the consequences of removing parts. For each part, we need to determine the mass and inertia and how that affects the car as a whole when attached in position or when removed.

At iRacing we have a pretty sophisticated multi-body solver used to calculate how all the connected parts of the car interact given all the external and internal forces acting on the system each simulation step.

The multi-body system is critical to how we model our cars and allows us to build an accurate representation of all the connecting geometry for among other things the suspension, drivetrain, and chassis.

Because the multi-body solver has to do lots of work in real-time our system is designed to precompile optimal code to perform the computations at 360hz. Unfortunately, because we precompile the code, this means the arrangement of bodies needs to be fixed. In other words, we can’t easily disconnect or reconnect bodies from the car.

To remove parts as they break off, we needed to rework this system without sacrificing performance. We were able to do this by augmenting the multi-body system so chassis bodies could maintain removable mass and inertia totals which we dynamically update whenever some part needs to break away or snap on.

After a part detaches we replace it with a new separate part that performs its own collision and physics so it can bounce and tumble down the road independently.

Wheels also need to be removed. Since wheels are already part of the multi-body, we need a similar approach so we can remove their mass.

With all these individual masses now dynamically accounted for we can accurately shed mass and therefore energy during big crashes.

Below is our example car with all parts and a couple of wheels damaged and removed.

Sticky Walls

An unfortunate problem with our old system was that for big impacts the car could end up stuck inside a wall. Despite some clever fixes we were never quite able to solve this completely, and it was another area we wanted to improve.

For the new system, we had the same problems, which stem from the penalty method approach. The penalty method requires that collision shapes are allowed to overlap. The depth of the overlap is then used to determine an appropriate collision force. Unfortunately for soft objects or objects moving very rapidly, this approach starts to break down. If some shapes pass through walls and get over to the wrong side, then the car as a whole will get stuck.

We would see this problem frequently for our new shapes, especially for parts such as body panels and hoods which were thinner than the typical old spheres.

This problem is partly why it is more common for middleware to model collisions as instantaneous. By doing so, they can sidestep the problems caused when shapes overlap for longer times.

We experimented with different methods for solving this tricky problem. Mostly we tried to predict the problem and then revert to instantaneous collision impulses. However, the results were never perfect, and the motion was just not convincing.

This was a challenging problem and one that at times felt like it might never be solved. But in the end, we were able to devise our own unique approach which allows us to maintain the properties we liked from the penalty method while ensuring the collision shapes don’t pass through walls.

Our approach maintains a separate core sphere for each collision shape. A core sphere is small enough to be encapsulated by the corresponding collision shape. Most of the time, these two shapes move in lockstep. However, the core sphere is never allowed to pass through the collision environment.

In the case of a deep collision, the core sphere and the collision shape will separate. The core sphere will remain on or near the surface while the collision shape continues deeper. We are therefore able to maintain an understanding of the surface for that collision shape until it has time to spring back out. This approach allows us to use the penalty method while avoiding the common pitfalls.

Tweaking Properties

Having built our new collision shapes and positioned and connected our damage mounts, we still need to tune all of the associated properties.

Collision shapes have properties defining: mass, material, stiffness, damping, friction, etc. Damage mounts have properties defining: material, yield limits, break limits. And then even more properties for the mount spring behaviors.

All of these properties need to be carefully researched and dialed in for every car. This job fell on our dedicated vehicle dynamics engineers, and it was going to be a huge undertaking.

To improve the workflow and accelerate the long process we have developed a live editing interface we call the Tweaker. Using the Tweaker tool, we can adjust all these properties on the car during the simulation as well as inspect things like the collision shapes and mount positions.

The Tweaker is built using the popular Dear ImGui library which allows us to quickly adjust the interface to our needs as the engineers discover new and faster ways to work.

Below is an example showing the Tweaker in use.

Collision/Damage Events

So far we’ve covered what the new collision and damage system is capable of. But we also need to communicate the results to other systems in iRacing.

Rather than add these features as needed, we have a new system for collision and damage events. This system packages all the necessary information for each impact or damage change so it can be parceled off to other areas for processing. We are then able to hook any of our other systems up so they can react appropriately.

We are currently using collision and damage events to improve our particle and sound effects, so they more closely resemble the kind of destruction happening to the car.

Next Steps

When all this new work is finalized, we will be able to start building on our new foundation to add even more improvements.

For example, we’re better placed to improve our simulation step rate to give us even more accurate physics. We should be able to improve how we represent specific curbs and track features when necessary. And ultimately we would like to be able to break cars in half for spectacular Indy 500 crashes.

For now, we need to concentrate on the work still to do. We’ll be busy updating all our cars and all our track objects. We need to update everything in the iRacing service before we can release since there are too many changes for the old and new systems to co-exist.

We’re also still finalizing the new effects and sounds. From there we will need to optimize and debug all these new systems.

That said it’s exciting to reach this point and I’m happy I can share these details.

Thanks

Richard

P.S. – We are working on a video that will show much of what I discussed above – hope to have that out in a couple of weeks or so.

Share Button


About Kevin Bobbitt

Kevin Bobbitt is the Director of Marketing at iRacing.com. He has been with iRacing since 2007 and is a long time marketing professional bringing more than 16 years of experience in both online and offline consumer marketing to the job. Kevin's commitment to iRacing starts with his passion for motorsports. He is a fan of anything powered by an engine. When not racing on iRacing or watching a race on TV he can likely be found at the track or an autocross site in his Porsche 944S2. Kevin is also the commissioner, punisher and all around rule maker for the Rennsport Racing League run on iRacing. Kevin resides in New Hampshire with his wife and two boys.


39 Comments

Poor Skippy takes all the heat 🙁

lol. Good read Richard. Looking forward to seeing the video!

Brendan Hobbart
June 19th, 2018 at 4:23 pm

Great stuff Richard, very interesting and thank you for all the hard work by you and the rest of the team.

Allan Paterson
June 19th, 2018 at 4:39 pm

Will These Be For The Nascar Cup Cars?

Jimmy
June 19th, 2018 at 4:46 pm

Crashing my car would look better than ever!

Alex Crawford
June 19th, 2018 at 5:20 pm

Looks awesome! Can’t wait for this to be implemented guys, keep it up!

George

George Simmons
June 19th, 2018 at 5:46 pm

Thank you and very much looking forward to this #soon

Michael A. Jones
June 19th, 2018 at 6:36 pm

This sound like its a year or more out?

Adam
June 19th, 2018 at 6:37 pm

Good read. Very interesting and easy to understand. Keep up the good work!

Tristan Boddice
June 19th, 2018 at 6:58 pm

So Rich, did you really trash that car….or was that just some Rando? If yes, how pissed was Tony about it?

Jason Gerard
June 19th, 2018 at 7:55 pm

As a retired geek, I love this stuff, which is why I enjoy iRacing.

Thanks Richard.

Vinny Moriarty
June 19th, 2018 at 10:34 pm

Will this improve the IR scoring when you get wreck or hit from behind ? Thanks great work! Keith.

Keith
June 19th, 2018 at 11:24 pm

When pieces fly off, will a debri caution be throw on an oval track and a debri flag be shown on a road course? Great work!! Just thought this might need to be thought of.

Peyton Johnson
June 20th, 2018 at 12:09 am

iRacing 3.0!

Rob
June 20th, 2018 at 2:14 am

This is a fascinating read, thank you! And it really helps in understanding why some of the issues (e.g. cars getting stuck in barriers) not only occur but are more difficult to fix than might at first be thought.

iRacing is without doubt a favourite pastime of mine. Thank you to everyone at iRacing that puts in so much hard work to make it as realistic as possible.

Chris Keeble
June 20th, 2018 at 2:30 am

You are the best! we wait a little video to appreciate work

Avanzini Thomas
June 20th, 2018 at 3:24 am

Awesome news, nice work guys can’t wait!! :O

Kevin Mills
June 20th, 2018 at 4:27 am

This is amazing … this is why iRacing will always be the greatest sim ever made. Thanks to your efforts.

Marcio
June 20th, 2018 at 7:33 am

Thanks for a well written explanation. You really captured how complex damage modeling can be. I have always wondered if it would be possible for the program to let the driver know what was damaged on the car after an incident.

Donal Fitterer
June 20th, 2018 at 8:18 am

Will these new crash models involve debris on track til the driver leaves the track, hanging hoses,clamps, Shee metal , fire etc and will their be Actual oil spills on track and I only see Open wheel Vehicle models will their be Oval vehicle models too? I have and idea for a garage mode open the infield including Victory Lane just as a bonus but if you wreck into the Turn 3 turn 4 or whatever a wall or get hit if your car is repairable but it needs more than five minutes of repairs take it behind the wall into your garage door where it will reduce the time of repairs by 2X so if repairs take 30 minutes so reduced down to 15 minutes! All you have to do after that is back out of your stall and go back out on track!

Mike
June 20th, 2018 at 8:34 am

These studies are very promising and indicate that iRacing is well on the way to trying to simulate reality as much as the current hardware allows. Thank you for keeping us updated and good luck for the difficult work still to be done.

Mario Pires
June 20th, 2018 at 9:27 am

Wow we as iracing pilots would never imagine the hard work behind the scenes if you dont share….thanks for sharing……our respect grow when we understand the sacrifice you making to turn on iracing code….thanks a lot….what more can i say…..speechless….cant express well whats going on my mind. But…..in one sentence….you make a nightmare become a sweet dream.

Reis
June 20th, 2018 at 9:53 am

This all sounds good for sure while a bit over my head to understand it all the important part is that Iracing continues to produce the best SIM racing in the world. It is amazing the effort put in but something as a 10 year member I have come to expect from Iracing.com Keep up the great work and THANK YOU!

Gary
June 20th, 2018 at 10:53 am

Good read Richard. Tell me, how close will the eventual damage model be to the soft body model used by BeamNG?

Fahim Antoniades
June 20th, 2018 at 3:15 pm

Music to my ears!
A new fully revamped iRacing system, that can hopefully take advantage of modern hardware.
I doubt that you guys will offer DX12 (too many users still on Win 7 and you need to wait for that number to dwindle to a point where it’s ‘acceptable’ to lose customers who refuse to accept their PC’s are literally too old and holding back the SIM development. Of course, DX11 is capable of parallel multi-threading, just not many developers have bothered to invest the time to use it, instead harping on about the same old ‘single threaded’ excuse that isn’t the entire story!
Even better – offer the use of BOTH DX11 and DX12 so that the service can be tailored to meet the needs of different PC setups.
Also, I was wondering about day/night transitions and how they current system could possibly cope with the added resource of moving shadows in relation to the location of the sun moving across the sky and direction of the car on the track in relation to those shadows! A new system surely must be needed!?
Thanks for the update!
Exciting times – hopefully not still year(s) out!

Globe
June 20th, 2018 at 5:03 pm

Damage modeling and how it affects the cars on the track I think is very key to racing in general. I only drive dirt at the moment and some impacts should be race ending but they are not. Others should or could have the possibility of bending components but yet the car is still driveable which we do see currently. Not sure how others feel but in open wheel racing tire to tire contact can be devastating. Not sure if they have this modeled yet in the sim but it could help make drivers think twice about how they drive. Catching rear tires of two cars in the right way can make someone go for a wild ride. Banging the wall with the right rear can have an affect on the jacobs ladder straps where they get bent and start to bind up. Most of the time it’s a bad thing but it can help too. Overall good to hear they are doing damage modeling because seeing sprint cars flipping and the top wing stays fully intact is a bit weird.

Howard West
June 20th, 2018 at 6:18 pm

Hi everyone,

Yes, that really is the RT2000 I personally wrecked. Tony and Dave were not pleased. Steve was ecstatic and has never let me live it down.

The new system will be applied to all cars. Newer cars will potentially have more parts to lose than old cars because we’ve been anticipating this for a while and building all the hidden parts like the undersides of hoods.

We still need to figure our exactly how the debris will interact with race control. Currently the new system cleans things up pretty eagerly so they can cause the least amount of trouble. But it’s all up for discussion.

BeamNG is awesome! But I think we have different priorities. Still I think people will be impressed. And longer term the new system gives us a lot to build on with further improvements.

Richard Jobling
June 20th, 2018 at 10:12 pm

Richard, thank you for taking the time to give us the “coles notes” version of game physics. That was a very interesting read and it will take another read through (or three) to get a bit more of an understanding. Thanks for the awesome sim and all your hard work.
-Corey

Corey Kish
June 21st, 2018 at 12:15 am

Very interesting . Keep up the good work!

julle
June 21st, 2018 at 7:06 am

What an awesome article. I wish there were more like these! Love seeing the inner workings with problems faced and the solutions for them. SIM-PRON

Robert Tinsey
June 21st, 2018 at 8:38 am

I enjoyed the read. It’s all so, so cool. Love what you guys do, thank you for your passion. You’ve really brought us the fun and memorable experiences that are iRacing.

Colin Taber
June 22nd, 2018 at 11:45 pm

Wonderful article and work. Thanks so much Richard my friend. I am very much looking forward to the video sneak peek.

-Jamie

Name
June 23rd, 2018 at 7:42 pm

Honestly, it appears that there is way too much thought going into this operation. The damage that it most prevalent and observed is during the endurance races, the damage is forever present on the GT3 and GTE cars after repairs. it’s completely unrealistic and looks very poor to the viewer watching a racer’s stream which can be seen world wide. Although the C7DP damage model may not be the end game in this matter it would been fantastic to use that model until this project is completed. I don’t think it matters all that much the way the car comes apart during a collision it’s what it looks like when it exits the pits after being repaired. The current wing configurations after being damage resembles nothing I’ve ever seen, it’s not being repaired which doesn’t make since a car would never drive on the track with disfigured rear wings. I hope this matter will be addressed in your project.

Mark
June 26th, 2018 at 4:37 am

@Mark – very good points.
These cars (at least GT cars) can have any body panel replaced in minutes, and the cars are designed to have parts that can very quickly be changed or adjusted.
The Wing angle amonf other things should also be an available option during pit – just like it is IRL.

I am really grateful for the update, iRacing is very sparse on these so they are appreciated.
However, it seems that there is often little focus on the here and now, always new projects that usually take much longer to implement than expected.
If this new damage model is still a year out (likely conservative), then can’t anything be done with the current one?
To Marks point, how much work could it possibly take to replace a bent wing? Real pit crew guys would have this replaced in 20-30 seconds, there’s no way a car would leave the pits with a bent wing.

Globe
June 26th, 2018 at 1:47 pm

This update is long overdue. The current collision/damage model certainly does not fit the price tag.

Dave
June 27th, 2018 at 9:06 am

thank you for the hard work

ph. boulet
July 8th, 2018 at 9:30 am

Could you concider make some kind of feed to the driver of what is broke when cars get repaired in pit. It would be cool if game wrote which parts needs to be replaced/repaired.

jesper
July 9th, 2018 at 8:39 am

Will you model collisions between parts of the same car? Like tires scrubbing the fenders from too low ride height.

mertol
July 9th, 2018 at 10:02 am

Can’t wait to see this open to the public

Name
August 7th, 2018 at 6:59 pm

Can we have exploding petrol tanks included in the older cars for some spectacular fireballs? I respect that the modern cars dont tend to do that now but it would add a different twist to the experience of driving the older cars.

TIm
August 16th, 2018 at 11:17 am

Interested in special offers, free giveaways, and news?

Stay In Touch

Ad