Sign in to follow this  
Dunge

Game logic/renderer timing with PhysX

Recommended Posts

Dunge    405
I trying to create a simple game engine. I currently use a single thread for everything and a main loop who simply calculate the delta time between each frame using QueryPerformanceCounter and use it and the inputs to update the game logic, then do a rendering pass. This way, the game have the same results even if it's running at 10fps or 200fps. I'm currently trying to add PhysX support, from what it seems, I should use a fixed timestep of like 60fps to run the simulation. So instead of simply passing my delta time I calculate between each frame, I need to block my rendering and game logic to 60fps so the simulation get in synch. That don't seems right because usually every application I see can get under or above a fixed framerate without problem. I've searched around a bit and didn't find a clear answer. What is usually used? 1. Variable timestep using my first idea (which bring inconsistencies) 2. Passing a fixed constant in simulate() even if the function is called at a different speed which would probably result in different speedy strangeness. 3. Use another thread which run at fixed time for physx and the main one who run at full speed as usual and find a way to pass all objects and collisions info between threads (I would need a guide for this). 4. I've ended up on the word "accumulator" 2 times, what is it and can it help me? A small pseudo code would be nice. Thx

Share this post


Link to post
Share on other sites
nife87    520
I think you might have forgotten one solution.
Using a single thread running updating a constant 60 times a second (possible updating several times for each rendering-frame, since updating will take place before rendering) and rendering as fast as possible while interpolation between the two latest update frames/samples to get average/plausible physics data for the rendering.
This way, updating will always take place (assuming 60 fps) at "virtual" time (the time you pass PhysX) 0 ms, 16.67 ms, 33.33 ms, etc. with the rendering taking place after the necessary updating has been performed.
You should be aware of timestamping input data and other time-sensitive data, so that input and the rest of the time-sensitive will be triggered/"discovered" in the right update (because multiple updates might happen before rendering).

This article also explains it, although it might not be exactly the same method (long time since I read it): Fix Your Timestep.

Share this post


Link to post
Share on other sites
Dunge    405
Thx for the help. I actually ended up on this page before writing the post, but tough it was another crappy one and I got confused with the "integrate" function, which actually seems to be the "update". Reading it trough actually helped and it takes in account every situations. This adds up something new, I need to save old physics states for each object between updates to interpolate. This include position and rotation, anything else?

Share this post


Link to post
Share on other sites
SiS-Shadowman    359
There's no nead to make it complicated. I've integrated physx a year ago now and I can run it with a variable timstep:


NxReal CPhysX::UpdateTime()
{
NxReal deltaTime;
static __int64 gTime, gLastTime;
__int64 freq;

QueryPerformanceCounter( ( LARGE_INTEGER * )&gTime ); // Get current count
QueryPerformanceFrequency( ( LARGE_INTEGER * )&freq ); // Get processor freq
deltaTime = ( NxReal )( gTime - gLastTime ) / ( NxReal )freq;
gLastTime = gTime;

return deltaTime;
}

m_pScene->setTiming( 1.0f / 60, 8, NX_TIMESTEP_VARIABLE);
m_pScene->simulate( UpdateTime() );
m_pScene->flushStream();
m_pScene->fetchResults( NX_RIGID_BODY_FINISHED, true );



The devs told me this will work and it does work like a charm. I've never had problems with it. Physx already runs at a seperate thread and the scene does all the wrapping for you, there's no need to reinvent it twice, it will just cause more trouble.

Share this post


Link to post
Share on other sites
Dunge    405
It cause more trouble, but it stay fixed. From the documentation and some forum posts, using your method (what I was thinking of using) will bring different results on some computers..

Share this post


Link to post
Share on other sites
Sly    128
Firstly, there should be no need to run faster than 60fps, since that is about the highest framerate you can realistically display. Any higher and you're just wasting time.

If you are running below 60fps, you can run multiple 1/60 sec physics updates each frame and interpolate the remainder from the last update.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this