Feedback Multiple worlds seems very very slow?

I did a small comparison between World, Filter and offsets for small isolated simulations. And it seems multiple world is a heavy punch on performance.

My test was 32 simulations (see image) with 8 dynamics and ~70 statics (Sadly couldn't get the static to become one collider with instantiating from prefab), and the statics were not shared between worlds.

World - 50 ms
Filters - 9.85 ms
Offsets - 9.61 ms



I don't like working with the limitation of 32 filters, so I guess I'll resort to offsets if nothing gets improved here.

 

Apologies that I don't have anything to add to your query, but I'm trying to figure out how to do something similar -- instantiate multiple isolated physics worlds -- and you've gotten much further than I have. Do you have any example code or resources you could point me to? I've read through the docs I know of but have only found a bare outline of how to really do it.

 

https://github.com/Jawsarn/LocalSimulationTests

 

I had a similar issue just creating a lot of worlds with almost no data and I was not even updating them. This is probably not related to your case, since you need a lot of worlds to have this "problem", but just in case.

I took a brief look at the profiler and it seems there is a post frame update that takes a lot of time in my case, it is executing a lot of memory profiler jobs on the main thread.

Code (CSharp):

1. Profiler.FrameMetadata
2. UnityEngine.CoreModule.dll!::ExecuteJobFunction.Invoke() [Invoke]
3. MemoryProfiler:MemoryProfilerJob
4. UnityEngine.CoreModule.dll!::UpdateFunction.Invoke() [Invoke]
5. UpdatePostFrame
6.  

 

I have also seen multiple worlds (100+ of them) to be extremely slow, talking seconds per frame, even if they are empty.

My approach before PhysicsWorldIndex and still now is patching CollisionFilter's IsCollisionEnabled to treat IndexGroup like it's a WorldIndex instead.

Works pretty well, for sparse worlds like my space game that has many physics bubbles / worlds. Additional Performance can be gained by patching BVH to make certain assumptions about IndexGroups, or by making CollisionFilter Unions treat IndexGroups like bit fields, too.

(Wow, I just realized that's a simple optimization I can make, currently I use hashes to generate groupindices, these occupy a lot of bits, but I only need maybe 2 or 3 bits (out of 16) tops, which gives me a big amount of room if I shuffle these appropriately into a Union-able IndexGroup.)