How to get global pose of actors in different threads and an issue on api checkResults

[SHiziw]

Hello dev teams,

I want get the global pose of actors in different threads and I care about the performance cost so I think adding the Lock is not the most suitable approach. So I tried the api of scene checkResults().
But it always returns false. No matter where I called it.
I do the check as below (PhysX 5.3.1):

void stepPhysics(bool /*interactive*/)
{
	bool result0 = gScene->checkResults(false);
	gScene->simulate(1.0f/60.0f);
	bool result1 = gScene->checkResults(false);
	gScene->fetchResults(true);
	bool result2 = gScene->checkResults(false);
...

I think result0 should be true, and result1 should be false while result2 should be true.
But when I print them, they are all false.

My question is 1. is there any better way to get global pose of a actor in different threads?
and 2. is the api checkResults() under some defect?

Thanks and best regards.

[msauter-nvidia]

Hi SHiziw,
Not quite sure I understand. Quite often, PhysX is used like this:

PxScene->simulate();
PxScene->fetchResults();

now you read from your PhysX actors etc. and this can happen in parallel on multiple threads. Once you've read all you needed to read, you start another simulate/fetchResults cycle.

The checkResults() call you've mentioned, is meaningful between simulate() and fetchResults() but not really between fetchResults() and simulate()

[SHiziw]

Hi there,
I understand that I should read PhysX actors after the simulate/fetchResults cycle is finished. But in another thread (we can call it the reading thread), I can't guarantee what state this cycle is. So I want checkResults() to tell me whether the cycle is finished.
According to my observation, in the reading thread, checkResults() always return false. I think this phenomenon is abnormal.

[msauter-nvidia]

Often you would rather build some task system for this. Once the simulation has finished, it will spawn a task that reads results (which then can happen on another thread).
With the system you are describing, there seems no guarantee that the next simulation step will not start just after your sim-is-running check might have returned false.
How does your update loop look like? I mean where are the sync points between starting/stopping the sim and your other logic?
Just for checking whether the sim has stopped, you can introduce your own variable that you set to true once fetchResults(true) was called and set to false before you call simulate(). But be aware of the problem I've outlined above.

It's not surprising that checkResults() is false most of the time. If I do understand your scenario correctly, then the problem is that you call fetchResults() independently of checkResults(). One intended usage was something like:

if (checkResults(false))
{
fetchResults(true)
process sim results
}
else
{
do something else since the sim has not finished yet and try checkResults() later again
}

[SHiziw]

Thanks for your constructive answer which helps a lot.
The update loop I want to build is simple: one simulation thread and one reading thread. They are totally independent.
So now I know that it is not legal to call fetchResults() in reading thread to tell whether simulation step in simulation thread is end.
Maybe that is the reason why I call fetchResults(true) it will block up forever.

[msauter-nvidia]

If you really want to keep them totally independent, then it seems to me that you can't avoid some sort of mutex or at least lock-free data structure to communicate the actor poses safely.
It would seem simpler if the reading thread called simulate() and fetchResults(). Note that the simulation will run on a separate thread that way, if you implement the PxCpuDispatcher interface with one worker thread (see PxSceneDesc::cpuDispatcher and the PxDefaultCpuDispatcher example). And by using checkResults(), the reader thread will only call fetchResults() once the simulation has finished, it will not get blocked otherwise. But I'm sure there is a good reason why you do not want to work with such an update scheme.

[SHiziw]

Thanks again, I think building a better data structure is a good choice for me.