Couldn’t create a Convex Mesh from source mesh, within the maximum polygons limit (256). The partial hull will be used. Consider simplifying your mesh. Source mesh name:
How to fix this?
Easy, split your mesh and use more than 1 collider.
That is extra steps and waste of time need devs to fix engine limitations
Pretty much everything in gamedev are extra steps ;). Making games is optional!
Maybe a waste of your time, could be saving time for your game - which also saves you time in the long run. If I had to choose between a game made quickly that runs like crap and a game that took a bit longer to make but runs smoothly, I’d definitely take the latter.
These limitations often exist for a good reason, they’re a tradeoff for something else: better performance, lower memory consumption, etc. It’s not like someone decided to put an arbitrary limit on something just for the sake of it as you seem to think.
In this particular case, 256 being a power of 2 and representable with only 8 bits makes me think the engine takes advantage of this to use a compact/fast representation of the convex hull.
Furthermore Unity’s physics engine is PhysX, I don’t think it is within Unity’s power to change this even if it made sense. Quoting PhysX’s documentation:
https://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/Geometry.html
Anyway, a mesh whose convex hull can’t be represented with 255 polygons is a seriously complex one. Even if you could make a convex hull out of it, it would still be wise to simplify or split it for collision detection purposes.
This is totally wrong as unity could change the code as it is not set in stone they start with psyx and can tweak it from there
PhysX is developed by Nvidia, not Unity.
Changing this would involve meddling with a codebase they’re unfamiliar with and making it worse in some other way because as I explained: these kind of restrictions are in place for a good reason.
Back to the original issue: convex colliders are mostly used only for dynamic rigidbodies (since you can use a concave mesh as-is if it’s going to be static geometry). A convex hull is already a crude approximation of the shape of a concave object, so it doesn’t matter at all if the mesh you generate it from is a decimated, simplified version of the mesh used for rendering.
It just doesn’t make any practical sense to have more than 255 polygons for a convex hull: you seldom use dynamic concave meshes, when you do +95% of the time the convex hull will have a lot less than 255 faces and when it doesn’t, simplifying the mesh is a quick and easy fix.
If you find yourself consistently running into this problem, you’re definitely doing something wrong and it would help to know: what is your use case?
agreed but if you want to move on to building your game instead of wasting time bitching, you can make a prefab variant off your asset and slap in one of the 2 convex decomposition repos from github.
this is the unity way
It’s a limitation of the physics engine which is Nvidia’s responsibility, and that limit is still in the latest release so it’s not like they can just upgrade the version and suddenly this goes away. Unity would have to start adding their own code and it would never be as good as or as fast as Nvidia’s code, and that assumes it wouldn’t be a buggy mess.
https://nvidia-omniverse.github.io/PhysX/physx/5.4.0/docs/Geometry.html
I’ve linked the appropriate header from the source repository for additional details. While these are hard limits of the algorithms they’re not actually the tightest limits. Unity’s PhysX is CPU only. GPU compatible convex meshes have even tighter limitations.
https://github.com/NVIDIA-Omniverse/PhysX/blob/main/physx/include/cooking/PxConvexMeshDesc.h
I saw the other day that v5 even has SDF colliders, which would take care of that. Well, if Unity integrated their SDF baker in the importer like in Unreal and like they should because of VFX graph.
And that’s what “The unity way” comment was about, not about Physx limitations.
Unity lacks very basic game dev tools that make the engine look completely broken for newcomers so all devs have to get crafty and either make, siphon from github or buy them.
In this case, the V-HACD convex hull decompo was already made by Unity engineers and can be found on github and would make OP’s life easy with zero need for roundtripping in the 3D modeling tool.
So to summarize and avoid further misunderstanding: my suggestion is to download the repo, or Rorygame’s fork or my CoACD fork and be done with it.
You’re assuming that most newcomers have a good reason for wanting to use a mesh collider, but in my experience most of them are just choosing it because it’s the least effort, and then when it kills their performance somehow it’s Unity’s fault.