I’m genuinely curious why this was disabled for rigidbodies, since it worked fine and is basically necessary for levels build as a single mesh, etc.
2 Likes
Wait, what? You can’t add mesh collider to a,3D object? Since when? V5.1?
No, you can. You just need to mark it as “convex”. Which works for things like barrels, but not when you have statue that has some holes in it that you can shoot through AND is affected by physics (rigidbody), well, good luck.
It is a PhysX 3 limitation.
You can always make a compound collider. Break the mesh up into pieces which are each convex, or use a number of primitive shapes. You can do the same thing, you just do it a different way that (ideally) ends up being more efficient.
If your level is built as a single mesh why does it need a Rigidbody?
This asset: Unity Asset Store - The Best Assets for Game Making
can make a concave collider by generating several convex colliders automatically, I’m using it in my project and saves me a lot of time (it works better with low poly meshes though).
2 Likes
Never had that problem… I just add a mesh collider and boom, et Voilà. It’s just eating more ressources. Or maybe I’m missing something. Mesh collider is concave by default. Clicking convex will just optimize the collider by creating a rough bouding box
1 Like
Not specifically a physics specialist, but IIRC, most algorithms for physics are much faster if only dealing with convex shapes. So, it is often still cheaper to subdivide a concave mesh into multiple convex meshes. Basically, it’s the trade for convenience vs. performance.
3 Likes
Yes, but why force it? IMO it should be that way:
- Convex in collider is selected - use faster algorithm
- Convex isn’t selected - use slower.
And if someone would have issues regarding physics performance, stock answer should be “please limit amount of concave rigidbodies”.
1 Like
Again, not the physics expert, but my suspicion is that there is no “slower” algorithm offered. It probably did some sort of auto-subdivision in the background which is better left to the user to do is my guess. Though, I’m probably not the best to explain this…
1 Like
This is why I sometimes look down on the use of 3rd party libraries and technologies. I asked a potential interview some questions about how their stuff works and their best answer was a flow of interactions of 3rd party technologies doing behind the scenes woo woo and they have no idea what’s going on.
I understand that you shouldn’t reinvent the wheel nor should you need to understand it 100% to make use of it… but come on ._. A feature people were making use of suddenly vanished and the best answer offered here (by @Ryiah ) is PhysX updated aaaaand it’s gone. The way it works now is better in every way… except for where concave colliders were needed. I don’t personally use them or have any idea what’s happening in this thread, but I’m drawn in by the inconvenience to other community members 
The only good to come of this is that it inspires people to make work arounds and actually code things. The nice thing about reinventing the wheel is that your car doesn’t break when the 3rd party distributer releases wheel 2.0.
1 Like
Considering the level of expertise of the average person using these systems the general response would be “physics is slow” and “why are my mobile builds bigger” because they have no clue that what they’re doing is causing a problem.
It’s simple enough to just make a compound collider. It’ll be okay.
2 Likes
It is a PhysX 3 limitation, there may be more info on NVidia’s forums, but ultimately Convex = Slow, if it’s static, they can pre-optimize, but for moving ones its far more complex, simple answer, break it down to sub meshes, it’s easy and will give far better performance than a single Convex mesh.
This goes off-topic slightly, but I figured I would still respond to this comment. This is something we struggle with regularly. We can hide the magic behind the curtain, but then there are places where the best person to make the decision as what to do is not us, but the game developer. So, we need to balance where pulling back the curtain is the appropriate approach. A lot of engineering is about trade-offs, and letting Unity make all the calls is not necessarily the best approach, even at the cost of inconvenience (sometimes).
and…to try and set things straight I’ve tapped on a physics dev to try and respond.
3 Likes
concave collider support was removed in PhysX3 by Nvidia. Support for concave trigger was also removed. The subject was discussed here U5 - Rigidbody, mesh collider & trigger problems. - Unity Engine - Unity Discussions
In my opinion, where Unity needs to address this is on the tools side. There should be a tool built into Unity for generating various types of optimized colliders. I agree with the idea behind forcing game developers to use optimized colliders, but Unity should have included the tools in Unity 5.0 to do that.
As it is right now, I have to use 3rd party tools to make optimized collision meshes. In my case, I use MeshLab and Blender to create the optimized collision meshes. It is not the end of the world, but the workflow would have been smoother if Unity 5 included a tool for generating various optimized meshes. For example, UnrealEngine includes a built in tool that makes it easy to generate collision meshes without 3rd party tools. It would be easy for Unity to include a similar feature.
This is not an issue about engineering trade-offs. The issue is simply a lack of built in tools for generating the optimized colliders. If Unity included such a tool, nobody would be complaining about restrictions on concave mesh colliders in Unity 5. If the tool was built in, then everybody would be happily generating optimized convex mesh colliders using the tool.
2 Likes
Just curious, how would you handle a situation where you are inside a pipe/tube shape? It would take a ton of colliders to recreate the shape in a convex shape.
Something like a Fzero tunnel.
My approach would be to create a spline that follows the path of the tube and is centered within it. From there you would have two basic ways to check if the player is colliding.
One is to simply check the distance of the player from the spline. Alternatively you could have a few colliders, in the shape of a tube, following the spline at all times and adjusting their positioning to match it.
1 Like
Thank you for saying that 
And especially that :3
It’d be interesting to use a procedural generation sort of technique to build the colliders near the edges of the vehicle as it turned around walls. Great idea for infinite runners & racing games.