Search Unity

MeshCollider creation is too slow, help me explore alternatives.

Discussion in 'Editor & General Support' started by Slight0, Nov 13, 2014.

  1. Slight0

    Slight0

    Joined:
    Dec 6, 2013
    Posts:
    28
    Surprise I'm building a multithreaded voxel engine. I want this thing to go fast and so far it does. It can do voxel data generation, mesh generation, and light calculation quickly (within hundreds of ms for the entire map) without holding up the main thread thanks to threading and careful design.

    Performance

    The one issue is collisions. For the MeshCollider alone (aka meshCollider.sharedMesh = mesh), a 16x16x16 chunk with a moderately complex mesh shape takes 6ms on my machine. Compare this to the time it takes to generate the mesh triangle/vertice data which is around 4ms and to actually instantiate the Mesh object which is under 1ms. Voxel data generation for a chunk is about 2ms. That's about 6ms for voxel gen, mesh data gen, and mesh creation and 6ms for MeshCollider creation; 12ms total.

    Currently I am testing with a 5x5x5 chunk voxel map, but the final map size will be around 10x10x10 - 16x16x16 chunks.

    Without mesh colliders, the entire 5x5x5 chunk map at worst takes (4ms + 1ms + 2ms) * 5^3 = 875ms (less than one second). I say at worst because I'm using complex arrangements of voxel data for every chunk in order to do benchmarking. In reality, chunks that are all air or all solid can take less than a millisecond in total since mesh generation time will be 0ms and simple meshes take less time. For example, normal world data typically takes 200ms to generate a 5x5x5 chunk map.

    All the while, because of threading, the main thread is not tied up and the game runs at 60fps.

    The Problem With MeshColliders

    They're slow, yes. As I said, creating the mesh collider, which shares its mesh with the rendered mesh for the chunk, takes 6ms effectively doubling chunk generation time. The biggest problem is I can't thread it because of Unity's arbitrary restriction on multithreading. So it blocks the main thread for 6ms for each chunk. Even if it was just 1 chunk per frame, that's 6ms gone of our tight 16ms budget for 60fps.

    I've googled around and checked up on people with similar problems. Here are some threads I've read:

    http://forum.unity3d.com/threads/need-help-improving-performance-of-mesh-collider-creation.247866/

    http://answers.unity3d.com/questions/321428/adding-mesh-collider-in-run-time-slow.html

    http://forum.unity3d.com/threads/faster-meshcollider-generation.18189/

    The conclusion is that MeshCollider generation is slow and there's not much you can do about it other than simply not use it.

    Box Colliders?

    One user suggested using box colliders. Instead of creating a box collider for every voxel we just create one for each surface voxel. That is, any voxel with one or more empty voxels around it. We're still talking about thousands and thousands of box colliders.

    That user also suggested simplifying further by only creating 20 or so box colliders and moving them to represent voxels nearby the player. What about NPCs? Other players that must be client-side predicted? Item collisions? All physically simulated objects must have these colliders constructed around them. Further, this will add to overhead as moving objects will need to search within a 10x10x10 or so cube and adjust box colliders to represent surface voxels every time the physics object moves to a new voxel coordinate. For moving objects this could be every 1-4 frames depending on speed.

    If I had no other solutions, this would be the best solution, but there are other possibilities.

    Other Solutions

    If I could create mesh colliders within a thread that would be my favorite solution. I thought that maybe someone had created an alternative physics subsystem for Unity and that's when I found uPhysics. It looked promising at first because it uses a threaded implementation of physics. However, it does not support mesh colliders and so is of no use.

    Maybe the best thing to do is to use a 3rd party physics library and try integrating it into unity? Something like bullet physics, ODE (open source), or another library from this list. The obvious downfall being this it'll likely be difficult and time consuming to integrate a 3rd part library. I will also not be able to use any of Unity's physics functionality whatsoever.

    Looking for feedback and thoughts on the subject.
     
    Last edited: Nov 13, 2014
  2. Rezan7CC

    Rezan7CC

    Joined:
    Apr 19, 2014
    Posts:
    14
    Hey, I have the same problem. Did you find a solution? Maybe Unity 5 can solve the problem because of Physix 3.3? I read that Physix 3.3 is multithreaded.
     
  3. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Hello there,

    uPhysics TriMesh colliders will be available within the next update like announced in the asset thread. Its scheduled to appear this month.