Preface: Why would anyone care about such a thing, and what do these values mean?

There are two advantages to calculating more physics positions, rotations and forces more often. Consider an extreme case of updating physics at 30Hz and have a car that can drive at 200mph. You're moving 3m between each physics update, so objects (eg kerbs, dips, potholes) that are smaller than that are likely to be missed entirely, thus the car won't react.
Firstly, a faster update rate gives more fidelity for the texture of the terrain beneath the tyres. Secondly, stiff springs become numerically unstable at large time steps (slow update rates), which can limit the settings used or start to give poor handling.

So why not always run at a very high update rate? Performance. Double the update rate and you've doubled CPU time dedicated to physics, and this quickly becomes expensive. Also, given cars only drive so fast and only have springs so stiff, there becomes a point where the is no benefit to running faster. As such, the rate is a compromise.


Anyway, on to the list:

'98 Sports Car GT - 50 Hz [from Blackhole Motorsports article]
'98 Viper Racing - 60 Hz (general) / 300 Hz (some aspects) [email with Dave Broske]
'98 Grand Prix Legends - 144 Hz
'00 F1 2000 - 50 Hz [from Blackhole Motorsports article]
'00-'08 Racer - 300 Hz (general) / 3000-30,000 Hz (tyre rotation) [posted by Ruud in a thread archive on racer.nl, dated '01]
'01 F1 2001 - 200 Hz [from Blackhole Motorsports article]
'02 Total Immersion Racing - 100 Hz / 400 Hz effective internal due to Runge-Kutta RK4 integration [from press release]
'02-'08 Live for Speed - 100 Hz (collision detection) / 2000 Hz (vehicle dynamics) [posted by Scawen on lfsforum]
'03 NASCAR Racing 2003 Season - 288 Hz (possibly)
'04 VirtualRC Racing v1.0 - 300 Hz (general) / 600 Hz (tyre model) [posted by Todd on lfsforum]
'05 VirtualRC Racing v3.0 - 250 Hz (general) / 500 or 1000 Hz (tyre model) [posted by Todd on lfsforum]
'05 rFactor - 400 Hz
'05 Forza Motorsport - 180 Hz
'06 Test Drive Unlimited - 100 Hz (collision detection) / 1000 Hz (vehicle dynamics)
'06 netKar Pro - 333 Hz [posted by Kunos on RSC]
'07 Forza Motorsport 2 - 360 Hz [from wikipedia article]
'07 Rigs of Rods - 2000 Hz [from ROR forums]
'08 Ferrari Challenge: Trofeo Pirelli - 60 Hz
'08 rFactor Pro - 800 Hz [from official website]
'08 iRacing - 360 Hz [from AutoSimSport]
'09 Supercar Challenge - 60 Hz
'09 Need for Speed: Shift - 180 Hz / might be 360 Hz (effective due to 2 physics passes per timestep?)
'09 Forza Motorsport 3 - 360 Hz [from gamespot article]
Motorsport - 333 Hz (but still being tuned) [posted by Stenyak on RSC]
'11 NASCAR 2011: The Game - 60 Hz / either 240 or 360 Hz (I forget which value I settled on) for sub-stepping the tyre force calculation but only at slow speeds. Also the thermodynamics were updated at just 3 Hz as that's quite expensive so but also very numerically stable.
'12 rFactor 2 - 400 Hz [posted on forum.studio-397.com]
'13 Stock Car Extreme - 360 Hz [from game-automobilista.com]
'14 Assetto Corsa - 333 Hz [posted by Kunos on assettocorsa.net]
'15 Automobilista - 720 Hz [from game-automobilista.com]
'15 BeamNG - 2000 Hz [from beamng.gmbh]
'17 Project CARS 2 - 600 Hz [posted by Ian Bell on forum.projectcarsgame.com]
'18 iRacing - 360 Hz / 720 Hz for force calculation [from article on iRacing.com]
'18 Assetto Corsa Competizione (up to v1.7) - 333 Hz [posted by Kunos on assettocorsa.net]
'20 Automobilista 2 - 1000 Hz
'21 Assetto Corsa Competizione (v1.8 onwards) - 400 Hz [ACC v1.8 release notes]

We can see that rates have generally increased with CPU power in the early years but seem to have largely plateaued in more recent times. Rigs of Rods and BeamNG beings exceptions due to the soft body modelling (ie much stiffer springs) having higher demands.

Anything sim can add to the list, or additional details you could provide, I would be very interested in reading! Cheers.

netKar PRO - 333 Hz
Source: http://forum.racesimcentral.co ... php?p=3767150#post3767150

iRacing - 360 Hz
Source: AutoSimSport vol. 4, issue 4, page 28

Surprisingly, these figures are not present in the Wikipedia comparison. Might be a good idea to add it.

wsinda, that was the first place I checked. I agree it would be handy to see that info in there, although I'm not sure which table would make the best home for this extra column.

Excellent additions, thanks w126, I'll add them to my first post to save people having to read all this thread in the months/years to come.

Quote from Bob Smith :

VirtualRC Racing - 600 Hz, has tested up to 30,000 Hz in the past [posted by Todd on lfsforum, have also read something similar in a usenet posting]

Not sure where the 600Hz came from. It was 300Hz originally and somewhere in the middle I changed it to 250Hz in one of the updates around V2 or V3. The 30,000Hz was only very briefly many years ago (well before Virtual RC Racing was ever released; possibly before I even started work on it) and that was only for the tire model.

Anyway, it's 250Hz now with the tire model running at 1000Hz. Nobody ever noticed the change from 300 to 250, btw.. Up until now I was the only person on the planet that knew

Quote :

Total Immersion Racing - 100 Hz (effectively 400 Hz due to Runge-Kutta 4th order integration rather than Euler?) [from press release]

Don't get too excited about Runge-Kutta solvers. That doesn't make something work like it's 400Hz instead of 100Hz. Just a bunch of marketing BS really...

360Hz is an odd one along with a couple of the others. You could use any frequency you want of course, but if you follow the practice of using milliseconds for timing things then you'll wind up using a multiple of 1/milliseconds. I.e., 1ms = 1000Hz, 2ms = 500Hz, 3ms = 333Hz, 4ms = 250Hz, 5 ms = 200Hz, etc.. That's not a requirement at all, but that's why you'll frequently see these familiar numbers popping up in different sims whether they're racing, flying, boating, first person shooters, and so on.

I thought I'd read way back on rec.autos.simulators that GPL ran at 333Hz. I could be wrong though of course.

Are these the rates that the physics engine updates? and what difference to the end user, just out of interest. thanks.

What I mean is what the heck are these?

Quote from jtw62074 :

Not sure where the 600Hz came from.

http://www.lfsforum.net/showthread.php?p=125152#post125152

Quote from jtw62074 :

Don't get too excited about Runge-Kutta solvers. That doesn't make something work like it's 400Hz instead of 100Hz. Just a bunch of marketing BS really...

I got it from here: http://www.simracingworld.com/content/157/ - the sentence is a little ambiguous to say the least.

Quote from jtw62074 :

I thought I'd read way back on rec.autos.simulators that GPL ran at 333Hz. I could be wrong though of course.

It's possible. I just had 240 Hz in my head for some reason, although I tried researching it again today and couldn't find where I originally came across the figure.

Thanks for the info though Todd.

Quote from AlienT. :

Are these the rates that the physics engine updates? and what difference to the end user, just out of interest. thanks.

What I mean is what the heck are these?

Smoother physics, essentially. Less catastrophic collisions with red barrier like objects. Less oscillation problems at low speeds. Less headaches for the programmer(s). More CPU usage.
I've read that simulations used in films often run around 500 Hz, as that's the sweet point to look and act natural.

Quote from Bob Smith :

http://www.lfsforum.net/showthread.php?p=125152#post125152

Oh, right... That 600 was for the tires only when the main engine was at 300 back then. I just checked and currently (I was wrong) the main engine runs at 250Hz with the tires running 500Hz most of the time. At low speed the tires switch to 1000Hz. The RC car tires have almost 0 inertia so you need to run them at a pretty high frequency as you can imagine. The 30,000Hz was overkill. At one point I think I had them running at 60,000Hz. A bit unnecessary

Quote from AlienT. :

Are these the rates that the physics engine updates? and what difference to the end user, just out of interest. thanks.

What I mean is what the heck are these?

Just like Bob said, it's smoother.

Literally what you're doing in a simulator is calculating the new position, speed, etc., (let's call it the "state") of the car over and over. You can say "the car's speed is now 100 km/h, so where will it be x seconds from now at that speed?"

The "x seconds" is where the frequency comes in. If you calculate the new position/velocity (state) for 1 second from now, the engine is running at 1Hz (cycles per second). That's not very good because nothing you do over the course of an entire second will effect the car at all. The suspension and other forces won't do anything either during that time, so you're better off calculating everything much more often.

In my case on Virtual RC Racing, I say "the car is here now, so let's calculate where it will be 1/250th of a second from now." That's 250Hz. The tire rotational speeds are calculated 2 times during each step, so the frequency there is double: 500Hz.

At some point you don't notice any difference. I can't tell a difference between 250 and 1000 or 10000 Hz in my stuff (I've tried them all), although some people might. Running 1000 versus 250 takes 4 times the processing power though, which means you have that much less available for graphics, sound, AI, etc., so the name of the game is to run as low a frequency as you can get away with while still maintaining good accuracy and response.

Thanks for the reply....oh and I am going to have a try with VRC it looks very interesting.....you should get together with Bob and give the talented chap a job

Viper Racing 60hz with some aspects running at 300hz

Source: an e-mail with Dave Broske, on of the programmers on Viper Racing

AlienT. - Since I currently have a job developing driving games (specifically the vehicle dynamics) and am working on two interesting titles atm, I'm in no need of another job.

I brought this thread up since the PC racing sim I'm working on is having low speed issues and I needed to convince my boss that fighting a 60Hz timestep was always going to be a losing battle. I've got it working pretty reasonably, but since we don't need to support the PlayStation 2 anymore, we can afford to use up some more CPU cycles. We're planning to up the core engine to 120Hz and de-couple the drivetrain physics to run even faster, which should make my life much easier, and make for a more credible car simulation.

Quote from jtw62074 :

360Hz is an odd one along with a couple of the others.

It has good reason at least in case of Forza Motorsport 2. Their graphics is always at 60 fps (when playing), so with 360 Hz physics rate the graphics is smooth and they don't need to interpolate between 2 physics steps to get the state used for a single graphics frame. LFS also does not have such interpolation but some people notice it's not smooth, for example with 75 Hz monitor refresh rate and full screen vertical sync switched on. (http://www.lfsforum.net/showthread.php?p=604281#post604281)

Quote from Bob Smith :

AlienT. - Since I currently have a job developing driving games (specifically the vehicle dynamics) and am working on two interesting titles atm, I'm in no need of another job.

Good on you, It must be nice to do work that you have a genuine interest in.

OK, good progress so far. Anyone have any ideas for: NASCAR series, later ISI engined games (F1 '99-'02, GTR, GT Legends, GTR2, rFactor, RACE), Richard Burns Rally, Grand Prix series, or X Motor Racing?

Quote from AlienT. :

Good on you, It must be nice to do work that you have a genuine interest in.

Yep, indeed it is. Only downside is that I don't have as much time as I'd like to work on VHPA / my LFS stuff.

Quote from w126 :

It has good reason at least in case of Forza Motorsport 2. Their graphics is always at 60 fps (when playing), so with 360 Hz physics rate the graphics is smooth and they don't need to interpolate between 2 physics steps to get the state used for a single graphics frame. LFS also does not have such interpolation but some people notice it's not smooth, for example with 75 Hz monitor refresh rate and full screen vertical sync switched on. (http://www.lfsforum.net/showthread.php?p=604281#post604281)

Interesting. Didn't know that. Thanks for the info.

Although the only sim I ever worked on did not get finished and released, I developed a flexible technique for the physics by using a delta. When the car needed extra physics cycles it got them provided the current framerate allowed it.

This allowed me to run physics as low as 1:1 for screen refresh when the car was settled on a straight, and to pile on the calculations in the corners and exits when the car and suspension was working.

Mind you this goes back about 7 or 8 years now and was a much cruder simulation than the games lsited, and the game never got past a few multiplayer alpha demo's with a handful of testers, but conceptually it seemed to work and allowed for much lower CPU loading.

I've never understood the concept of doing things on fixed timings, I do things when they need to be done. It's the same with my multiplayer data packets too. It's a more event driven approach.

GPL for sure , and possibly N2003 run at 288hz (hence the 144fps framerate limit in n2003 (/2) and the 36fps (/8) limit in GPL which might have something to do with it.

I'm quite sure about GPL, and guessing for N4/n2003.

Edit, and F1 2001 had a 'super high rate' option in an INI file somewhere, doubling the frequency from 200 to 400. And, to my knowledge, this is the default for rFactor. (400)

Quote from Becky Rose :

Although the only sim I ever worked on did not get finished and released, I developed a flexible technique for the physics by using a delta. When the car needed extra physics cycles it got them provided the current framerate allowed it.

This allowed me to run physics as low as 1:1 for screen refresh when the car was settled on a straight, and to pile on the calculations in the corners and exits when the car and suspension was working.

Mind you this goes back about 7 or 8 years now and was a much cruder simulation than the games lsited, and the game never got past a few multiplayer alpha demo's with a handful of testers, but conceptually it seemed to work and allowed for much lower CPU loading.

I've never understood the concept of doing things on fixed timings, I do things when they need to be done. It's the same with my multiplayer data packets too. It's a more event driven approach.

afaik the problem with this (apart from whatever nyquist will have to say about bumps) is that online everyone will play with different varying physics

Deciding what integration frequency is enough is difficult too, as it not only varies with speed, but with the parameters of the car. Low power tanks will likely be fine at 50Hz, RC cars like in Todd's sim need a lot more.

Shotglass - with Becky's exact implementation that is true, but I don't see why varying frequency would cause a problem multiplayer if done carefully. I mean technically speaking Todd is already doing that in VirtualRC.

Quote from Bob Smith :

I mean technically speaking Todd is already doing that in VirtualRC.

is he from how i understand it (tbh im not sure he does himself after correcting the numbers 5 times so far ) all he does is multiply the base rate by some (by what weve read so far most likely random) number to get a higer rate for some subsection of the physics loop

although i do know that all id games up until doom3 used variable physics rates but that was a complete mess

Quote :

afaik the problem with this (apart from whatever nyquist will have to say about bumps) is that online everyone will play with different varying physics

Not a problem, my project was written in multiplayer from the start. The trick is careful consideration of the event triggers that scale the physics delta. My game didnt have bumps on the track (we are going back a few years here - we had to keep poly counts down!) but if the track had any noteable bumps i'd set a locational/path trigger in addition to the fall-back of the physics themselves saying "hang on, I need more because thats a big movement". For instance, my physics processed more when near a kerb.

It's often assumed that multiplayer needs to be perfectly synced, in reality it's impossible to perfectly sync anyway because of lag, so you position, rotate and give mommentum according to the remote vehicles data in the packets, but movements of suspension and other fine details are mostly "cosmetic" and also in part to carry on processing movements between updates of the data packet, so really absolute precision of remote vehicles is not necessary. It just has to be "close enough" that corrections in the packet data dont cause visual jitter. I didnt even send data like that in the multiplayer packets (though remember my physics where simpler), if I recall the only "physics" thing sent was once a lap a simple map of tyre wear and fuel load and that was it, other than that it was just position, rotation, and velocity and the physics coped with the rest locally.

the thing with synchonous fixed rate physics is more about having everyone playing the same game
with quake3 for example you can find long articles about why 125fps will let you jump the highest which at the time gave players on high end pcs an advantage and is why doom3 used fixed rate physics
with a sim its obviously even more important

Quote from Shotglass :

the thing with synchonous fixed rate physics is more about having everyone playing the same game
with quake3 for example you can find long articles about why 125fps will let you jump the highest which at the time gave players on high end pcs an advantage and is why doom3 used fixed rate physics
with a sim its obviously even more important

Yes, but this can be avoided if you integrate everything carefuly. Using varying time steps can work...but it introduces many tricky potential bugs, and make things that should be easier like integration between fames become much harder.
It is like using a rotating referential to calculate everything. It works if you think about it all the time.

aye sounds like shoddy coding to me Shotglass. Or just using a different approach to problems than I do, I do understand what you meen - but I dont see how a sensible approach to the physics cannot treat the physics themselves as a suspension model.

If done right everyone IS playing the same game, you're assuming the physics run at a different rate in the same circumstances whereas this isnt really the case. You set the physics rate based upon the need (and anticipated need) of the calculations it has to do. It's not the same as full 1:1 ratio delta timing, it's using an individual delta for each physics objects and modifying its delta based upon how many calculations it needs to do.

Sure in practice I capped the exponential increase in calculations on framerate on my project, a sensible precaution against slowdown on slow machines, but i'd argue this is prefferable to playing at 15fps.

Think about it logically, does a car travelling down a straight with it's suspension settled need 300 calculations per second? If you can get away with 50 or 10, then why not do that until you get near the corner. Now in a race game most of the time the car is on a straight, so you've just freed up enough CPU cycles to increase the size of the field by 3...

Quote from Juls :

It is like using a rotating referential to calculate everything. It works if you think about it all the time.

i guess it can work if done correctly but id rather not think about what it all means in the framework of discrete time maths

Quote from Becky Rose :

Think about it logically, does a car travelling down a straight with it's suspension settled need 300 calculations per second? If you can get away with 50 or 10, then why not do that until you get near the corner. Now in a race game most of the time the car is on a straight, so you've just freed up enough CPU cycles to increase the size of the field by 3...

it probably doesnt however i dont really see how it might help with framerates when the pc still has to cope with a much higher rate and 3 more cars during the corners where a high framerate is most important