I've got an issue when I tried to create a lot of scenes.

[sunduk]

Hi.
First of all, thanks for sharing such a good source code on Github.

When I tried to create 2000 scenes, I've got an error on TlsAlloc function.
The return value is 0xffffffff.(It means that it couldn't allocate thread local storage index anymore)

I'd like to run PhysX on online multiplayer game server.
There are a lot of rooms to play, each room has own physics objects and players.
I would tried to create a scene for each room and run each simulation.
Then the server would synchronize it to each clients.

like this :

for (int i=0; i<2000; ++i)
{
    CreateScene();  // gPhysics->createScene(sceneDesc);
}

By the time it made 1080 scenes, I'v got an error.

uint32_t TlsAlloc()
{
	DWORD rv = ::TlsAlloc();

        //error: rv is 0xffffffff
	PX_ASSERT(rv != TLS_OUT_OF_INDEXES);
	return (uint32_t)rv;
}

I've found the code which executed TlsAlloc function in NpScene constructor.

NpScene::NpScene(const PxSceneDesc& desc)
{
    ...
    mThreadReadWriteDepth = Ps::TlsAlloc();
}

https://docs.microsoft.com/en-us/windows/win32/procthread/thread-local-storage
In the above article, a process has an 1088 thread local storage indexes.

I'll very appreciate to give me some hints how I can fix it.

By the way, Is it wrong direction to create a lot of scenes on server side?
I want to know if there are some good examples about server side PhysX simulation like this.

[msauter-nvidia]

Hi there,
As you already pointed out, this is a limit of the OS. However, in theory you could try to remove the related code if you do not care about the detection of parallel read/write, write/write. Giving no guarantees here, so do it on your own risk ;-) but it could work.
At the same time, I do wonder about having all these scenes for the rooms. It does sound like the rooms are independent, thus you might rather consider running multiple processes with a small number of scenes each (which would also be more safe with respect to crashes, else a crash might affect all players at once). One other alternative is to have multiple rooms be part of the same scene with the downside of certain performance hits (and having to add room specific position offsets when adding stuff).

[sunduk]

Hi there, As you already pointed out, this is a limit of the OS. However, in theory you could try to remove the related code if you do not care about the detection of parallel read/write, write/write. Giving no guarantees here, so do it on your own risk ;-) but it could work. At the same time, I do wonder about having all these scenes for the rooms. It does sound like the rooms are independent, thus you might rather consider running multiple processes with a small number of scenes each (which would also be more safe with respect to crashes, else a crash might affect all players at once). One other alternative is to have multiple rooms be part of the same scene with the downside of certain performance hits (and having to add room specific position offsets when adding stuff).

Thank you very much for your advice.
I've look into the related code. Maybe I am able to modify it.(As you mentioned, without that code it runs well)

It does sound like the rooms are independent, thus you might rather consider running multiple processes with a small number of scenes each (which would also be more safe with respect to crashes, else a crash might affect all players at once).

Yes, those rooms are independent. Something like an instance dungeon. As you mentioned, I think that running multiple processes is a good idea to be more safe with respect to crashes.

One other alternative is to have multiple rooms be part of the same scene with the downside of certain performance hits (and having to add room specific position offsets when adding stuff).

I had thought too like your final suggestion, but it seems a little bit too complicated to calculate actors' positions. :)