Resolved Unity Physics runtime mesh collider creation and modification

Unity Entities Graphics has some great convenience features to enable runtime mesh creation / modification:

1. RenderMeshUtility.AddComponents for runtime mesh creation
2. MaterialMeshInfo (and RegisterMesh / RegisterMaterial calls) for efficiently changing meshes at runtime

Are there any plans to add similar helpers and concepts for DOTS Physics?

Procedural terrain is a good use case. There is the need to create meshes at runtime and, if the terrain is modifiable at runtime, then there is a need to efficiently update mesh colliders at runtime.

I've rolled my own "PhysicsUtility.AddComponents"-style helpers for creating a mesh collider at runtime by looking at the physics internals, but this is obviously quite fragile. Specifically, taking a Mesh (or MeshDataArray), ColliderFilter and (physics) Material and building a BlobAssetReference<Collider>. It sure would be nice to have a supported helper API to rely on for this. I have no idea if it's possible to change a collider efficiently at runtime without building a whole new collider, but I'd love if there was a way to build the collider asynchronously and do a MaterialMeshInfo-style ID swap efficiently.

 

Yes, that's correct.

My own implementation uses Physics.MeshCollider.Create() under the hood, and it pretty much does what you describe... it gets the MeshData and builds the vertices and triangles NativeArrays in a job and passes it to Physics.MeshCollider.Create() in another job.

It's not that any of that is particularly difficult, but there are some fiddly bits dealing with the correct index format of the MeshData to build the triangles, handle all the sub-meshes, wrap it in jobs, etc. I definitely had to go dig into the physics codebase to figure out exactly what to do. It just seems like there should be something in the general public API that takes a Mesh, MeshData or MeshDataArray (along with the CollisionFilter and Material) and spits out a BlobAssetReference<Collider> and just abstracts away the internal complexity of these fairly common operations.

My wishlist would be to add:

Code (CSharp):

1.  
2. public static BlobAssetReference<Collider> Create( Mesh mesh, CollisionFilter filter, Material material );
3. public static BlobAssetReference<Collider> Create( MeshData meshData, CollisionFilter filter, Material material );
4. public static BlobAssetReference<Collider> Create( MeshDataArray meshDataArray, CollisionFilter filter, Material material );
5.  

... maybe along with some simple jobs to wrap the three burst-able calls (NativeArrays, MeshData and MeshDataArray). Again, something that is trivial to write, but is just another thing that many people will have to do.

Finally, in my PhysicsUtility class, I have it all wrapped in a call that has RenderMeshUtility.AddComponents() vibes, taking an Entity and EntityManager and adding the correct components. But, that's just gravy.

 

Hi @daniel-holz

No, I'm creating an entirely new collider given a procedurally generated Mesh (or MeshData / MeshDataArray). Think colliders for procedurally generated terrain chunks.

In my case, the terrain is not only procedurally generated at runtime, but can also be modified at runtime (something like No Man's Sky or Astroneer). So, I not only need to create the mesh colliders for each terrain chunk at runtime but also modify them at runtime given a new mesh. I understand modification is it's own can of worms so just replacing works too.

Again, Physics.MeshCollider.Create() is fine—it's just lower level than what is typically needed, and requires unpacking the mesh data into arrays, building the triangle list, etc. Most developers are just thinking: I have a mesh and I want a collider, where's the mesh-to-collider function.

Also, the more that can be done asynchronously in a job, the better.

 

@daniel-holz

Yes, those are the types I'm referring to.

If it's helpful, here's a gist of my current utility code related to this. It doesn't handle every case, there's some default behavior specific to my current prototyping and it isn't optimized but should give you an idea of what I'm doing.

https://gist.github.com/pbhogan/d9170ff611eff23229274bec9207a633

CreateColliderForMesh() is most applicable to the discussion here, but AddComponentsForMesh() is also worth noting as a similarity to Unity's RenderMeshUtility.AddComponents()

 

Hey, I just wanted to chime in here as I'm working on a similar project and would really love a solution for this as well. Being able to create a mesh collider at runtime using the job system would be super cool.

It would be ideal to be able to create multiple mesh blob/object in a burst compiled job, since multiple chunks are sometimes created simultaneously (world initial creation or lod change).

Please let me know if this gets put on the roadmap as I'd be happy to vote on it.

 

it will be even greater if the samples project can also be updated

 

sounds great, i already managed use this in my tilemap system just now, it's so simple and works like a charm:

Code (CSharp):

1.  
2.             // create any mesh/entity you like (use RenderMeshUtility.AddComponents)
3.             state.EntityManager.AddComponentData(entity, new PhysicsCollider()
4.             {
5.                 Value = MeshCollider.Create(mesh, extraInfo.PhysicsInfo.CollisionFilter,
6.                     extraInfo.PhysicsInfo.Material)
7.             });
8.             state.EntityManager.AddSharedComponent(entity, new PhysicsWorldIndex());

for physics material, you can use PhysicsMaterialTemplate and create like this:

Code (CSharp):

1. new TilePhysicsInfo()
2.             {
3.                 Material = new Unity.Physics.Material
4.                 {
5.                     Friction = PhsicsMaterialTemplate.Friction.Value,
6.                     FrictionCombinePolicy = PhsicsMaterialTemplate.Friction.CombineMode,
7.                     Restitution = PhsicsMaterialTemplate.Restitution.Value,
8.                     RestitutionCombinePolicy = PhsicsMaterialTemplate.Restitution.CombineMode,
9.                     CollisionResponse = PhsicsMaterialTemplate.CollisionResponse,
10.                     CustomTags = PhsicsMaterialTemplate.CustomTags.Value
11.                 },
12.                 CollisionFilter = new CollisionFilter()
13.                 {
14.                     BelongsTo = PhsicsMaterialTemplate.BelongsTo.Value,
15.                     CollidesWith = PhsicsMaterialTemplate.CollidesWith.Value
16.                 }
17.             }

i do have a question, how to dispose/free this generated mesh/collider memory? since it can be generate quite frequently, can i just call blob.Dispose() ?

 

Thanks for this @daniel-holz
I'm excited to try this out when I get a chance1

 

Thanks for this, it's very interesting work.

I'm attempting to transition my code from using normal GameObjects to store procedural meshes to the ECS paradigm. I'm having some large performance regressions compared to the PhysX bake pathway. For me, the Physics.Create method is somewhere between 5-10x slower than the PhysX bake job. Do you guys have any benchmarking data to confirm if this is expected or if it's something I'm doing wrong? I really like the convenience of this new API as I am wanting to move to only one physics system rather than using both the traditional one and the new Entities Physics.

I moved away from using Create(MeshData, CollisionFilter, Material) towards the direct Create(NativeArray<float3>, NativeArray<int3>) as the Create that uses MeshData has some extra checks in there (the call to
MeshUtilities.AppendMeshPropertiesToNativeBuffers). This has made it somewhat faster, but still its 5x+ worse than the PhysX version.

Other ideas I have is somehow calling without the SafetyChecks.CheckTriangleIndicesInRangeAndThrow check, or allow me to directly pass in the tempIndices. Any other tips would be appreciated. Thanks again.