how to improve physics realism at minor cost of speed

[big air]

Trading speed for realism is easy if you know exactly what to do, but it's not intuitive:

replace (in ./src/physics/physics.cpp)
m_dynamics_world->stepSimulation(dt, 3);
with:
m_dynamics_world->stepSimulation(dt, 3000000,0.002);

Explanation: The old one will simulate dt with a maximum of 3 sub-steps. It is natural to think that decreasing dt and calling this function many times in a for loop will make a more accurate simulation, but this DOES NOT WORK! Adding the third argument seems to force it to simulate a step every 0.002 seconds over a total time of dt and a maximum of 3000000 steps (the 300000 doesn't matter, any big number will work). Slightly larger numbers than 0.002 also work, which are less likely to slow down fps but are less "safe".

Exactly what does this fix? The tunneling problem. The normal fix of this problem, in cart.cpp described an implemented at line 1275, clamps the y-velocity. This is not elegant at all and makes long falls unrealistic.

This has been tested successfully on canyon with turning off linear damping for a free fall at high speed.

[Auria]

Hi,

I'll let Joerg answer more than me since he's our physics specialist here.

But, does this bring any advantage beyond fixing long falls? Long falls happen quite rarely in game, so I'm not sure slowing down the game is worth it if long falls are the only thing that really improve out of this? STK is already running slow on lower end computers (mostly because of the graphics and not the physics, but still, we need to watch ourselves before adding stuff that slow it down)

[hiker]

Hi,

I don't see any benefit of this. We actually don't have any long falls anymore (it only happened in the original tux tollway, which has been replaced with a completely new version). Basically long jumps are kind of boring, so we would want to avoid them anyway (I am not talking of the 'simulated' canon-like shots in Mario Kart). The disadvantage of lowering performance especially on low end computers for no real benefit is just too big (though I'd guess that stk is still graphics bound).

Note that the first number does potentially matter: on slow computers doing too many physics step will make the game way too slow (which is atm usually caused by slow graphics). Otherwise you can get a spiral: slow computer --> more physics steps necessary to catch up with real time --> more delay if physics are too slow --> even more simulation steps necessary to catch up with real time etc (and STK has code to handle this situation at least a bit better).

Cheers,
Joerg