Sorry your browser is not supported!

Just hoping Matty or someone else could give me a heads up on how the timing system works.

I want to experiment with non fixed time, so my understanding is that I use this command dynSetTiming( 0, 0, 1). This will tell the system to not work to any specific time interval, and expect an irregular update pattern. I believe I then call these commands in this order in my loop:


dynFetchResults();
dynUpdate();
// Force related commands here
dynSimulate();
// Objects are moved now, so update camera here


With fixed timing, I believe the system performs multiple iterations of the physics calculations to get smoother/better results (as defined by the second parameter), and that with irregular timing I'm responsible for this. So would I do something like this?



If I'm applying forces every iteration, that seems pointless. But if I don't apply forces every iteration, then that seems weird! I'm assuming with fixed timing, the engine applies your forces gradually over each iteration? So if it runs 4 updates per dynSimulate(), it will apply 1/4 of the forces you applied per game loop? Or does it apply them straight away?

Also, I'm assuming I don't need to tell the physics system how much time has passed? It calculates that itself?

Basically, I just want to understand what's going on behind the covers so I can correctly implement an irregular timing system which gives the physics system the best chance at accurate, smooth physics.

Ok, think I've sussed it myself. The documentation says to call simulate and fetchresults as often as you see fit, but including the dynUpdate() seems to make it work as expected.

For my irregular timing I've done this:


This gives me three simulation updates, and my character controller is still moving at the correct speed, so I assume this is working correctly.

However, it canes the frame rate. 100 FPS drops to about 45 FPS with 3 updates. 65 FPS with 2 updates. This is 1 character controller on some fairly basic geometry, so hogging the CPU a bit.

Having played a bit, I can drop it down to 2 updates and it seems to still run fairly smoothly. 1 update was causing my character controller to jerk about as he ran along.

Edit: Actually found I was able to remove the dynUpdate(); and smoothness was still ok, although frame rate didn't increase.

All dynUpdate() does is sync all your objects with the physics simulation therefore you should only need to call this once no matter how many simulation iterations you run, as I think you have discovered.

Another thing to note is that doing it the way you are doing it will be slower as you are not getting the benefit of multi-threading. Calling dynSimulate() - dynFetchResults() like that means you are slowing your game down waiting even though it is simulating on another thread.

This is why I advise against this method. The default setup allows multiple simulations all running on another thread while your game is busy drawing to screen and doing other stuff, so it is best to explore that option as much as possible.

Have you tried doing this:



What happens here is that it does as many simulations as it can in the given time step and adds or takes away the remaining time and put it on the next loop.

I can get more info from the physx sdk notes if you wish, I'm not an expert on timing but I think I have explained it correctly. Hopefully the code above will work for you. Even using this code you can still play with dynSetTiming() to see if you can improve things.

You may not need 4 sub simulations for just character controllers running around a level but you may need that many when you add ragdolls etc.

Thanks for that Matty. Your explanations are slowly clicking it into place in my little brain. So ...

dynSimulate() kicks off a new thread and does the physics simulation.
dynFetchResults() waits for simulate to finish.
So since that is on a CPU thread, ideally you want the GPU rendering the display during that time. Correct? Makes perfect sense!

So the perfect loop explained:


Based on your snippet, you seem to be suggesting you can add a time step to the dynSimulate() command, even with fixed timing? Actually, I think that's making sense too now. I'll go and experiment and see what happens.

Cheers Matty.

It seems I have left that vital piece of information out in the documentation , I will have to remember to put it in.

The PhysX docs say you will get better results by passing in a value which is a multiple of the sub-time-step value. This way it never has any time left over that it needs to pass on to the next loop, although I don't see how this is always possible for variable timing, perhaps with some very clever programming.

I would just try putting in the raw time-step value for that loop no matter what it is and see if it still works smoothly.

Ahh. That's interesting. I'll have a play with that too.

Interestingly, when I pass a time value in Simulate(), I get a judder once per second. As my character controller moves, it jolts once per second, as if the simulation isn't updating that game loop. I think it's probably something to do with physX using too much time and then decided it doesn't have time to update at all on one loop. Total guess. Possibly an issue that could be fixed by passing in one of the fixed timestep multiples you're talking about.

I'll report back if I figure anything out.

I'm having trouble with timing as well. I'll have to take a look at what you posted and figure out how to get timing working correctly.

DigitalFury