Have a job that makes physics queries across multiple frames

From looking at the error output I can tell that at the end of each Simulation frame BuildPhysicsSystem attempts to deallocate PhysicsWorld and in turn CollisionWorld, which the job is trying to read from. Is there a way to get a "snapshot" of the PhysicsWorld at a point in time from the main thread and use the unchanging snapshot inside of a job that spans multiple frames?

 

There appears to be PhysicsWorld.Clone(), but the implementation has a worrying comment

Code (CSharp):

1. // Clone the world (except the colliders)
2.         public object Clone()
3.         {
4.             var clone = new CollisionWorld
5.             {
6.                 m_Bodies = new NativeArray<RigidBody>(m_Bodies.Length, Allocator.Persistent, NativeArrayOptions.UninitializedMemory),
7.                 m_NumBodies = m_NumBodies,
8.                 Broadphase = (Broadphase)Broadphase.Clone()
9.             };
10.             clone.m_Bodies.CopyFrom(m_Bodies);
11.             return clone;
12.         }

Is it still relevant? Is Clone() expensive both in memory taken up and time to clone? Will queries work on the clone as if it were a snapshot of the world when it was cloned? It seems like if all of the answers are satisfactory then it's safe to use the cloned CollisionWorld in a job that runs across multiple frames

 

I really have to ask if this is something you really want to do? It seems like a really poor idea.

You'd be colliding with things that no longer exist, or walking through things that now block you.

Anyway the best bet to know if this works is simply to test it yourself. I doubt there are many people who have attempted this.

 

This sounds like a side effect of your other thread where your pathfinding job lasts for multiple frames in a single job? It seems that is actually now causing several issues. While i realize NavMeshQuery is currently a pain, I think it's probably best to just bite the bullet and fix the root of your problem. Use UpdateFindPath over multiple frames but in different jobs, which puts you back into how the whole job flow is supposed to work well.

 

Cloning the collision world is cheap - it is just a clone of the NativeArrays of rigid bodies and broadphase nodes, Memory use scales with the number of bodies of course. Some approaches to rollback depend on keeping multiple physics world's in memory so easy cloning is part of the design. The key thing to note is that the collider and joint blobs are shared with the original world so be sure to not modify those (hence the code comment).

Whether cloning is the right answer for your use case is a different question, I'll leave that to others.

 

I'm okay with that. A small margin of error is acceptable. The job will run for 10 frames max.

Hmm, I'll be running physics queries against the cloned world. In the job it'll be read-only. Would physics queries just to detected obstacles still work when the cloned world contains no colliders?

 

@Abbrew the cloned world shares the colliders (see Collider* in Unity.Physics.RigidBody) so it does "contain" the colliders in the same way that the original world does. Those point to blobs that are created by the conversion system and are persistent in memory so unless you are manually managing the blobs or mutating them after creation everything will just work.