How to compensate for smaller fixed time steps

rraallvv
Posts: 30
Joined: Thu Feb 09, 2012 2:39 am

How to compensate for smaller fixed time steps

Post by rraallvv »

I wonder how to compensate when calling DynamicsWorld->stepSimulation(), say twice as fast, for instance running at 60 fps compared to 30 fps, while mantaining the physics simulation behaviour in the faster simulation as close to the slower as posible.

I've just called DynamicsWorld->stepSimulation(1/30,0) for 30 fps and DynamicsWorld->stepSimulation(1/60,0) for 60 fps of course

One problem, for instance, is when clamping the velocity for some objects, I only can set their velocity after the bodies have accelerated for 1/30th of second for 30 fps or 1/60th for 60 fps, which gives some inconsistence, allowing the bodies at 30 fps to move faster than at 60 fps.
STTrife
Posts: 109
Joined: Tue May 01, 2012 10:42 am

Re: How to compensate for smaller fixed time steps

Post by STTrife »

First, I think you should always base the first parameter on the time actually elapsed after the last call. Then if you want to move the simulation twice as fast, you should multiply that parameter by two.

Internally bullet uses it's own ticks, which are by default 1/60th of a second (you can change that in the third parameter of the setpSimulation, but that's only when you need to increase or decrease the resolution of the simulation, it doesn't change the simulation 'speed'.

If you use the snippet from here: http://bulletphysics.org/mediawiki-1.5. ... e_Snippets, you should be able to set the speed after each tick, before the bodies are actually moved. So it should be independent of the speed.

So basically, just tell the stepSimulation that twice as much time has elapsed since last call then is actually the case, and it will move twice as fast, since bullet will do more internal steps (or interpolate further), but it will still use internal steps of 1/60th second, and if you use the code snippet to limit the speed after each tick, using the callback, it should behave exactly the same as with the slower speed.
rraallvv
Posts: 30
Joined: Thu Feb 09, 2012 2:39 am

Re: How to compensate for smaller fixed time steps

Post by rraallvv »

Thanks for the info,

Let me clarify a bit further, using StepSimulation that way causes it to ignore the third parameter which by default is 1/60th, i.e. passing zero in the second parameter, and to set the first parameter as the internal clock disabling interpolation, I did it that way becouse I am not planning to use the interpolation feature. The simulation works pretty well because the game loop calls StepSimulation at a fixed rate.

The simulation is originaly intented to run at 30 fps, passing 1/30th of a second in the first parameter and zero in the second as explained above, but now I changed the game loop to run at 60 fps, so I pass 1/60th as the fixed time interval, but it causes all sort of inconsistent behaviors in the simulation compared to the game loop running at 30 fps.

I am using the snippet on that page already, It needs the simulation to step before, and then it clamps the speed to a maximum, but if the snippet runs twice as faster, I would have a chance to clamp the velocity earlier than when running at a slower speed, causing the bodies to move slower as a consequence.

I am thinking on remove the snippet at all and modulate all forces and impulses multiplying by a factor in proportion to the body velocity, which gives a result almost as the snippet to clamp the velocity
STTrife
Posts: 109
Joined: Tue May 01, 2012 10:42 am

Re: How to compensate for smaller fixed time steps

Post by STTrife »

I would guess that if you do it that way (disable the internal ticks, and do a fixed step always), and you want the exact same behaviour as before, just call the stepSimulation every other tick, with the same 1/30 seconds, so basically skip every other frame. You should get the same results as with the 30 fps, cause it's still 30 fps.
Or is there some other reason why this is not good?

Maybe you could explain more why you are not using interpolation. and also what kind of inconsitent behaviour do you get at 60 fps? it should be more reliable with smaller steps if anything...

Another option is to call stepSimulation(1/60, 1, 1/30). If i'm correct, this should make it use the same size steps as in the 30 fps version, but interpolate between the steps.
rraallvv
Posts: 30
Joined: Thu Feb 09, 2012 2:39 am

Re: How to compensate for smaller fixed time steps

Post by rraallvv »

The reason to run the game loop at 60 fps is that the game originaly was intented to run in at 30 fps on a screen half the size that it uses now, on the smaller size the bodies move somewhat choppy, jumping from position to position, but that is on porpose, the choppy movement is not noticeable for most people. but this choppy movement was programed that way because of the limitation of the plataform.

On the other hand, running the game at 30 fps on a bigger screen, does the coppy movement very perseptible, and unconfortable.

Updating the simulation evrey other frame, causes the same coppy movement, and for some reason, running at a fixed inverval of 1/30th and interpolating for 1/60th, gets the same result, with the same choppy movement.

I guess the solution could be somewhere in between, for instance updating the simulation at 1/60th, but applying forces and impulses, and the speed limit snippet, every other frame, at 1/30th.

Most incosistencies are due to the speed limit snippet, if a body is accelerated for 1/30th of a second, it already has moved a bigger distance, that if it has accelerated for 1/60th of a second.The speed limmit is applied every frame so the bodies at 30 fps would move always a bigger distance that at 60 fps.

Another problem is applying forces and impulces, at 60 fps it would be expected that the overall effect is that the same magnitud of force applyed twice as fast would cause the bodies to have a bigger acceleration.
STTrife
Posts: 109
Joined: Tue May 01, 2012 10:42 am

Re: How to compensate for smaller fixed time steps

Post by STTrife »

I don't understand why you get the same choppy movement if you use interpolation at 30 fps with 60 fps steps. Sure the collisions would behave the same 'choppy' way but the interpolation would make it move twice as smooth when there is no collision. You sure you didnt make an error in the call stepsmulation, you set the second parameter to 1 instead of 0? Cause it would be the best solution i guess if it works as expected... With the limting of velocities etc.

Also for applying forces they should be constant. Like gravity. If you only apply a force 1 time then there is a difference between 30 and 60 fps, because the duration of the force differs. But if you apply forces for a constant amount of tome then it shouldnt matter if its 30 or 60 fps. Somif you make sure the forces are applied for the same amount of time, it should work the same. For 60 fps it mean apply it twice as many frames as in the 30 fps..
rraallvv
Posts: 30
Joined: Thu Feb 09, 2012 2:39 am

Re: How to compensate for smaller fixed time steps

Post by rraallvv »

I did call StepSimulation(1/60, 1, 1/30); at 60 FPS, but the bodies are in a vectorial field where the user can turn on and off the field at will, the effect is like turning on and off gravity but changing its direction too, I guess the interpolation doesn't work because the bodies are moving in a chaotic way most of the time.

I finally get the desired consistence between the two simulations, at 30 fpt and 60 fps like this, I call StepSimulation(1/60, 0) at 60 fps, while forces, impulses, and the speed limit are applied every other frame, at 1/30. Interestingly enough the forces and impulses have to be scaled by 2x.

Thanks for your thoughts, I really apreciate that, I was stuck with this for a week, all I needed was a fresh look at the problem.
STTrife
Posts: 109
Joined: Tue May 01, 2012 10:42 am

Re: How to compensate for smaller fixed time steps

Post by STTrife »

The forces are only applied during the length of the frame you set them, they do not work as impulses. So if you skip every other frame it would be expected that you need to make them twices as large to make it work the same.. Good to hear it works now!