I am struggeling with this issue for a whole week now. I have 4 big terrain meshes made in 3ds max. I use T4M to make it work in Unity, since I cannot use the Unity built-in terrain editor for my project.
Now I don’t know if my problem is actually related to T4M or Unity itself. One terrain is made of 9 pieces with less than 65000 vertices due to the limitation of Unity. If every part 4x9 = 36 has a mesh collider attached, every start of the scene takes up to 5 minutes in the editor and build as well. As soon as I delete them, the scene is ready in max. 30 seconds.
I don’t understand this. It seems like Unity is generating the collider on every start, this would be my only idea. Is it possible?
The player is not supposed to drive on the terrain, only on streets. My only idea would be to seperate the terrain in straight parts using box collider and hilly parts using mesh collider. But that is a little botchy I guess.
Since Unity uses the physX library to handle collisions, I’d guess that Unity is building some sort of meshbuffer in a format that physX likes and then passes it to PhysX. PhysX will then probably attempt to build some sort of spatial partitioning to optimize this structure. I don’t know if T4M adds some overhead to the equation. But I’m quite certain that if you cut it into smaller pieces it would be faster. But it will probably never be instant.
However it sounds like there is only one player and if that is the case you could just have colliders for the meshes near him. If the player is completely unable to leave the roads then you could of course remove the collider for the terrain all together. You could also consider using a polygon reduced collision mesh, especially if your terrain have lots of small details that doesn’t really matter for collision.
Perhaps a few pictures to clarify what you got and what you need would help.
Rattlehead: Mesh colliders are slow but if you absolutely need to use them you should break the meshes down further. On top of the mesh collision physx does it also uses bounding boxes to detect when mesh collision calculation should be done. So when oyu have massive meshes a single raytrace that goes through the aabb bounds of the big mesh collider basically can slow things down very much as it potentially is iterating through all triangles.
As far as the load time, this issue could be related as well. If you have rigidbodies placed throughout your scene the first loading of the scene can be heavy on physics if rigidbodies are not set to sleep on creation.
Generally though i can’t see a down side to breaking the big meshes down to even smaller meshes (besides the potential extra work), and i think it’ll benefit you.
Also it can help to take the triangle count down on the collider mesh, you do not need to use the same mesh used for rendering and any extra verts placed for things like uv coordinate looping or vertex lighting can be done away with.
