[GIT] Moon effect.. (slow physics)

I am currently experiencing the so called Moon effect where the physics does not seem to be running at full speed. I have had a look at the NxOgre source code and this is why i think it is happening....

In NxOgreFixedSceneTimer.cpp the following are set;
Max time step = (1/60)/8
Max iterations = 8;

This will cause the physics to slow down more and more as soon as your frame rate dips below 60fps

Why....
If you have a frame rate of 30fps then the physX is asked to simulate 0.033s each frame, however its maxTimeSteps is (1/60)/8 = 0.002s and the maximum num of iterations (subSteps) its allowed to do per frame is 8. So 8*0.002 =0.0166s which means that for each frame the physics is only calculating half the time the graphics is rendering.

how to fix
Well..... you could change the MaxTimeStep in NxOgreFixedSceneTimer.cpp from 1/60 to 1/30, this will work but be aware that if you increase the maxTimeStep to much the physics will become unstable
OR
You could up the max Num of Iterations per frame. I have not tried this yet but in theory it should work! However it will put an extra load on the CPU... (I think!)

N.B. Please do not take what i have said here to be correct! Its just based on my current experience and knowledge, which is near to nothing!!

I knew. Although it has always did seem "off" before, but that was measuring by eye thus; subjective. I proved it a few days ago, and your right it does slow down when the frame rate drops the inverse of the max timestep.

The thing is; I'm not sure why it should be slowing down in the first place, in many aspects the simulation should get less stable (because of fewer and larger timesteps) but slowing down time doesn't make any sense. In the code in "Fix Your timestep article" prevents this sort of thing happening, I'm puzzled why PhysX doesn't use a similar integration algorithm. However if you want to try out code with your with mine to get some proper results, go for it.

Hmmm........

Well i understand why it does slow down, alteast it makes sense to my slightly messed up brain!

What i dont understand in your code is why you take the maxTimeStep of 1/60 and then divide it by 8 which is effectivly a maxTimeStep of 1/480???? Yes this will create an extremely stable simulation but you will begin to see 'Slow Down' as soon as you go below 60FPS.

If you used a maxTimeStep of 1/100 or even 1/60 you could run at frame rates of 12.5 or 7.5FPS respectivley without any 'slow down' (assuming maxIteration = 8 )


**EDIT Tried increasing the maxIterations, and as expected it sort of fixed the problem but ate alot more CPU which meant my frame rate was even lower which caused more 'slow down'.... This brings me back to the way NxOgre works ie (Simulate->fetchResults->Render) instead of (Simualte->render->fetchResults) which removes pretty much all of the physics calcs from the render thread

I read it in the PhysX Documentation, I believe I was in error or mis-understood it when I decided to change it.

In Bloody Mess the timestepping is 1/60/8, but in Detritus is 1/60 which can be overridden via the SceneDescription.

[Edit]

When I did those tests, I was using Detritus and the max timestep was 1/60, using the deltaTime as the timestep from a timer.

ah ok, in that case.......... What the hell is PhysX doing!!!!

*EDIT* Just looked at your results and that actually makes sense, because you had a hard coded delay of 500 milliseconds which means your effective frame rate would be at the most 2FPS. With a MaxTimeStep of 1/60 and a maxIterations of 8 that will allow you 7.5FPS before you get any 'slow downs' and since you were running at less that 2FPS that means the physics could only run at 26% of realTime

*EDIT* Fixed my bad maths!

Yeah, I know.

[Edit]

I'll try and confirm the results using an NxOgre-free application.

ah ok, in that case.......... What the hell is PhysX doing!!!!

*EDIT* Just looked at your results and that actually makes sense, because you had a hard coded delay of 500 milliseconds which means your effective frame rate would be at the most 2FPS. With a MaxTimeStep of 1/60 and a maxIterations of 8 that will allow you 7.5FPS before you get any 'slow downs' and since you were running at less that 2FPS that means the physics could only run at 26% of realTime

That makes some sense, but I still don't like it.

Well i guess PhysX developers made the assumption that;

A) 1/60 was good enough for stable phyics
B) you are unlikely to design a game thats going to drop below 7.5FPS, for any lengthy period of time!

Seems after 150 milliseconds delay (what is that in FPS?) is where the simulation really starts to fall down.

N:\projects\nxogre.org\PhysXApp\PhysXApp\Release>PhysXApp.exe
Max delay (in seconds) > 0.15

Max. Timestep: 0.0166667s
Max. Delay: 0.15s
----------------
1.09951 Actual:1.06667 Should be:1.09951 0.970129%
2.16644 Actual:2.13333 Should be:2.16644 0.984718%
3.23286 Actual:3.2 Should be:3.23286 0.989836%
4.29952 Actual:4.26667 Should be:4.29952 0.992359%
5.3662 Actual:5.33335 Should be:5.3662 0.993879%
6.43285 Actual:6.40003 Should be:6.43285 0.994898%
7.49962 Actual:7.46671 Should be:7.49962 0.995612%
8.56626 Actual:8.53337 Should be:8.56626 0.996161%
9.63293 Actual:9.60003 Should be:9.63293 0.996584%
----------------

N:\projects\nxogre.org\PhysXApp\PhysXApp\Release>PhysXApp.exe
Max delay (in seconds) > 0.2

Max. Timestep: 0.0166667s
Max. Delay: 0.2s
----------------
1.10078 Actual:0.8 Should be:1.10078 0.726756%
2.20064 Actual:1.6 Should be:2.20064 0.727062%
3.30067 Actual:2.4 Should be:3.30067 0.727124%
4.40068 Actual:3.2 Should be:4.40068 0.72716%
5.50069 Actual:4 Should be:5.50069 0.727181%
6.60069 Actual:4.80001 Should be:6.60069 0.727198%
7.70084 Actual:5.60002 Should be:7.70084 0.727195%
8.80086 Actual:6.40003 Should be:8.80086 0.727205%
9.90085 Actual:7.20004 Should be:9.90085 0.727214%
----------------

Checkout the attached executable if you like.

Sounds about right...

150 milliseconds delay roughly equates to 6.67FPS

Infact more interstingly you can see how physX deals with lost or extra time in each frame (ie the accumulator in action!). 1/60 timeStep = 16.66667 milliseconds. So....

if you take 150 milliseconds - the maxTimeStep = 133.33333; 133.33333 milliseconds delay = 7.50000FPS!!!

*EDIT* Not sure what i have said is sctricly correct, but the maths is right!!