( - A lot of substeps: physics can be the bottleneck )
- is this common thing in Physics Engines?
- can someone please explain what "moon gravity effects" means and what exactly are they talking about there?
- i must assume it is about some - loss of precision - otherwise there would be no observable effect at all, and they would not call it "trade off", right?
- but the most confusing is why would subSteps be responsible for anything like that?
thank you
Last edited by unter on Fri Sep 05, 2008 6:09 am, edited 4 times in total.
Assume you have to step the world 160 ms forward in time. You use a fixed timestep of 16ms which means you need t take several stubsteps to simulate the full intervall. If you clamp the maximum number of substeps to maybe five than you loose the rest of the timestep which will slow down the physics. Maybe they call this moon gravity effect.
i thought i was chasing completely another issue there, but it all makes sense now. its all because of the subSteps.. unbelievable, i knew about it without even realizing it because i thought it was something else.. uh, never mind that
anyway, here's what i think... you must be right,
after all, that is the only case where we use subSteps - when deltaTime > fixedTimeStep
more precisely, the only time we actually really need it is when one stepSimulation() takes more time than it was supposed to simulate...
the worst thing with it is that in all-other-cases we want to set maxSubSteps as high as possible, but again, only hoping that computer is fast enough to execute one simulationStep in less time than fixedTimeStep, otherwise it will be cut off sooner or later...
its even worse than that because the time it takes to render the scene is of course in play too.. quite often assumed to be the dictating factor in "computer speed" which is wrongly referred to as FPS ..and this, very much and very directly is connected to the fact that someone invented maxSubSteps in the first place
and if all this is true, "moon gravity effect" SHOULD NOT be related to gravity or any other forces, it would affect everything as it practically just causes less number of simulation steps per real-time second and with fixed time step that simply means general "slow-down" - as you said, but the byproduct might also be a drop in FPS all too sudden as time to execute stepSimulation() approaches fixedTimeStep
so i think "maxSubStep" is wrong way to go about it,
as it does not really "solve" anything and it causes troubles on the way..
i propose 2 solutions,
but lets see if i got this whole thing wrong?