Crash with Dynamic Meshes when not using CookForFasterSimulation

We are creating dynamically updated physics meshes and attaching to a MeshCollider. These are per-vertex-coloured meshes, so they contain many duplicate vertex positions (in fact, every triangle consists of 3 unique vertices, and the index stream of the mesh consists simply of 0, 1, 2, 3, ... n*3 where n is the number of triangles in the mesh.

As raycasts are performed only occasionally against these meshes, but updates are frequent, we are passing the following mesh collider options:

meshColider.cookingOptions = MeshColliderCookingOptions.EnableMeshCleaning | MeshColliderCookingOptions.WeldColocatedVertices; // Don't optimize for speed of raycasts.

That is, we are explicitly NOT passing MeshColliderCookingOptions.CookForFasterSimulation.

When we then assign the shared mesh in unity, we get an internal crash as below. We believe this is a bug, but don't yet have a minimal repro.

Repro'd using Unity 2017.4.3 and Unity 2018.1.1.

The issuetracker lists this issue (potentially related, I can't tell anything from the issuetracker except that the crash location in the call stack is the same) as fixed, but note above that I repro'd this in 2018.1.1.

https://issuetracker.unity3d.com/issues/physx-subsortquick-sort4-crashes-on-project-load

For now, we've re-enabled MeshColliderCookingOptions.CookForFasterSimulation. This works for now for prototyping on high end devices, but won't work for target ship.

EDIT: This seems to happen only with one mesh. The mesh where the crash occurs is interesting in that it is 3 consists disparate triangles about 5cm in size and about 50cm apart (assuming 1 unit = 1m in world space.) For now, we've disabled cookforfastersimulation only on that mesh...

0x0000000142991A89 (Unity) physx::SubSortQuick::sort4
0x00000001429921F2 (Unity) physx::buildFromBounds
0x0000000142992924 (Unity) physx::RTreeCooker::buildFromTriangles
0x000000014298601B (Unity) physx::InternalTriangleMeshBuilder::createRTree
0x000000014297BA8D (Unity) physx::TriangleMeshBuilder::loadFromDesc
0x000000014297A56E (Unity) physx::Cooking::loadTriangleMeshDesc
0x000000014297AD82 (Unity) physx::Cooking::createTriangleMesh
0x0000000140971116 (Unity) CreatePxTriangleMeshFromUnityMesh
0x00000001409714D1 (Unity) CreatePxMeshFromUnityMesh
0x0000000140973685 (Unity) PhysicsModule::CreateNxMeshFromUnityMesh
0x0000000140965899 (Unity) MeshCollider::ExtractMeshGeometry
0x000000014096597D (Unity) MeshCollider::Create
0x0000000140960F7E (Unity) MeshCollider::SetSharedMesh
0x0000000039904195 (Mono JIT Code) (wrapper managed-to-native) UnityEngine.MeshCollider:set_sharedMesh (UnityEngine.Mesh)
0x00000000398F590B (Mono JIT Code) [C:\Users\snip\QuadMeshDebug.cs:408] QuadMeshDebug:CreateVertexColouredMeshes (UnityEngine.MeshRenderer)

 

I spent half an hour making a minimal repro project for this (7 files total, a script and a single model with mesh, textures and materials, crashes as soon as you hit Play in the editor.)

I clicked "report bug" and wrote a detailed bug report.

The Bug Reporter has been hung on "Uploading the report" for half an hour.

This is really very frustrating.

 

Hmm, ok, so Unity Bug reporter was "uploading", it just wasn't obvious as the progress bar didn't seem to move (and starts at 50%). This is because if you strip your project to a minimal repro, then submit the bug from that project, Unity Bug Reporter happily tries to zip and upload the contents of your library folder, which will still contain representations of everything in your project from previous imports. Bug reports really do have to be migrated to a "new" Project (typically by stripping the project then doing Export Package into a clean project), which makes keeping a branch for them in version control potentially tedious (if your git/hg repo was the project root.)