Quote:Original post by jdavis
Upon reading the fetchresults description, it's suppose to tell PhysX when your scene is finished rendering (I'm guessing) but when I put it at the end of my render function it wont even let me move or do anything.

fetchResults basically gathers the simulation results from your simulate() call and puts them in your NxActor data structures so that you can read them and apply them back to your visual scene. It does other stuff too...collision callbacks, etc., but the net effect is that it makes sure NxActor data is up-to-date and readable.

The way your doing it now is valid, though there are other arrangements that would do better thread or multicore load balancing (e.g., enable PhysX to work on the next time step within another thread or on another CPU while you are using results from the prior time step in your main rendering thread).

PhysX is built to enable physis to run asynchronously with rendering. But, by calling fetchResults in blocking mode immediately after you call simulate(), you are basically forcing it into a synchronous mode....wait for physics to finish before doing anything else. There's not necessarily anything wrong with that. BUT, if PhysX ends up taking a VERY long time for something (resolving many collisions, constraint force solving, etc.), then you can get into a situation where the frame time grows larger and larger for each frame...I won't go into how this happens exactly, but it can happen if things are done naively.

What I would do is call checkResults(), and only if checkResults() returns true then call fetchResults. I also would use NX_ALL_FINISHED instead of NX_RIGID_BODY_FINISHED, for both checkResults() and fetchResults(). Further, you should not call simulate() more than once without calling fetchResults(), so you'd have to have a flag and even if you render several frames before physics finishes, don't call simulate() again until you are able to fetchResults(). Make sense? More stuff. The fDeltaTime should reflect the time between calls to simulate(), not just your frame time...important in the case that a single physics simulation is spread across multiple frames. Now, all this should keep your app responsive even if physics is not completing fast. It doesn't mean your physics will be what you want it to be, but it should at least keep things going. The kind of game loop I'm talking about is:

bool m_bCompletedLastFrame; // in class definition
float m_fTimeSinceLastCallToSimulate; // in class def

if (bCompletedLastFrame)
{
m_pScene->simulate(m_fTimeSinceLastCallToSimulate);
m_bCompletedLastFrame = false;
m_fTimeSinceLastCallToSimulate = 0.0;
}

m_fTimeSinceLastCallToSimulate += fDeltaTime;

if (m_pScene->checkResults(NX_ALL_FINISHED, false))
{
m_pScene->fetchResults(NX_ALL_FINISHED, true);
m_bCompletedLastFrame = true;
}

(My management of m_fTimeSinceLastCallToSimulate is probably not quite right, but this shows the idea.)