Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark Physics & Dark A.I. & Dark Dynamix / [Dark Dynamix] Irregular timing setup

Author
Message
Fallout
17
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 16th May 2012 12:39 Edited at: 16th May 2012 12:41
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.

Fallout
17
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 16th May 2012 12:59 Edited at: 16th May 2012 13:15
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.

Matty H
11
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 16th May 2012 16:45
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.

Fallout
17
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 16th May 2012 17:39 Edited at: 16th May 2012 17:40
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.

Matty H
11
Years of Service
User Offline
Joined: 7th Oct 2008
Location: England
Posted: 16th May 2012 20:05
Quote: "Based on your snippet, you seem to be suggesting you can add a time step to the dynSimulate() command, even with fixed timing?"


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.

Fallout
17
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 17th May 2012 00:12 Edited at: 17th May 2012 00:14
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.

DigitalFury
9
Years of Service
User Offline
Joined: 30th Jul 2010
Location: United States
Posted: 19th Jun 2012 01:42 Edited at: 20th Jun 2012 22:24
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

Get Out Alive (Zombie WIP): My latest zombie game I am working on.

Login to post a reply

Server time is: 2019-11-21 05:26:44
Your offset time is: 2019-11-21 05:26:44