Need help with making a MeshCollider

Hi all,
I’m trying to figure out how to make a mesh collider with the entityManager. The following code is what I have right now, which seems to either cause a memory leak or is just generally terrible, as when I deep profile it destroys my computer.

NativeArray<float3> float3Vertices = new NativeArray<float3>(meshData.float3Vertices, Allocator.Temp);
                NativeArray<int3> int3Triangles = new NativeArray<int3>(meshData.int3Triangles, Allocator.Temp);

                BlobAssetReference<Unity.Physics.Collider> meshCollider = Unity.Physics.MeshCollider.Create(float3Vertices, int3Triangles);
                entityManager.SetComponentData(meshEntity, new PhysicsCollider {
                    Value = meshCollider
                });
                float3Vertices.Dispose();
                int3Triangles.Dispose();

meshData.float3Vertices is an array of type float3 and meshData.int3Triangles is an array of type int3.

I’m generally unfamiliar with the new meshcollider system or what BlobAssetReference even is, could someone help me out here? Thanks!

That looks right. Note the BlobAssetReference will need to be Disposed when you don’t use it anymore since it’s a native object, so that might be the source of your leak?

I’m doing it in a job, but it looks basically identical to that: https://gitlab.com/burningmime/burning-rpg-framework/-/blob/master/Packages/building/src/jobs/BuildColliderJob.cs

1 Like

Hmmm disposing of the BlobAssetReference did not seem to work, I know it’s just these few lines of code because when I comment it out the leak is fixed, I think I’ll try putting it in a job and see if that works but I think that just might make it harder to debug, I’d like to get it working on the main thread first.

Okay, so I’ve narrowed it down to the following line:

BlobAssetReference<Unity.Physics.Collider> meshCollider = Unity.Physics.MeshCollider.Create(float3Vertices, int3Triangles);

This line on it’s own is EXTREMELY slow and I can’t seem to figure out why. I don’t know if there’s a better way to do it or if it’s only optimized for burst, but this seems very strange to me.

How big/awkward/complex is the mesh?

It’s quite large, at most ~9000 vertices. I think generating these colliders are just much slower than I anticipated, I’m looking to ways to make them faster. The old mesh colliders had options for fast midphase and things which helped them generate faster. It’s a little faster in a burst job, but still quite slow.

It is incredibly slow. Everything in dots that requires performance in this regards hopes that you have precalculated it, serialized it and only load it. Generating new meshes and colliders during runtime is a pain.

To clarify, I am not saying those operations are implemented inefficiently, I am just saying if you do so consider that this might be a very costly operation.

Mesh collider generation is pretty slow. Some of it is things you could optimize out like just skip vert welding, but some of it is just core to the design. They choose to do more work at collider creation which saves work when building the BVH. It’s an intentional trade off that favors BVH build time.

So some use cases you might have to do a bit more work with collider creation. Like create multiple mesh colliders instead of a single one so you can spread the work out, then create a single compound from those.

9000 does not feel like too much; I routinely do 30k+ verts in maybe 15ms or less (in a Burst job). The meshes tend to be made of flat planes (a building) which might simplify some things. I guess it depends on what you define as “slow”; if you’re building a mesh every frame that would be a huge problem while if you’re building a mesh once every second or so, that’s not too awful. What’s the use case here?

@snacktime - The mesh collider generation is the BVH creation, right? The resulting structure is a BVH that can do raycasting and collision. Or am I missing a step?

1 Like

The bvh is the tree of all active colliders and it has to be rebuilt every time a collider is added/removed. But… You can pre bake the data to some extent so there is less work to do at build time, which is what they are doing.

But given the huge boost of burst the OP really needs to post a bursted time and the vertice/triangle counts. Extremely slow gives us nothing to go on really.

1 Like

@burningmime sorry to come back to this thread after such a long time, but recently I’ve been getting ‘BlobAssetReference is null’ errors on this code and I haven’t changed anything. I’m not sure if this is a bug in an update of Unity Physics or what… Have you experienced this at all?

Are you using Burst to get them? If so, you need to pass it back in a 1-element array. It should allocate them with Allocator.Persistent, so they’ll stick around until you call Dispose() or leave/enter play mode.

My Unity Physics version is "com.unity.physics": "0.6.0-preview.3". I haven’t bothered to update it because it seems to clash with unity collections, and I’m only using it for raycasts and stuff, not actually simulating anything.

Yes, I have them in a NativeArray. It doesn’t seem to be affecting performance so I’m gonna chalk it up to just another safety check that I won’t worry about haha