Hi! I was wondering if anyone here has any insights or useful information on creating a custom collider. Important remark here is that by custom collider I don’t mean just using any pre-existing collider (cube, sphere, capsule, and especially not mesh!) in order to create a bigger collider.
I’m currently generating meshes, and it works, however the mesh generation takes too much time, and the collider must be dynamically generated and re-generated.
Any information will be appreciated. Thanks for reading!
If you are already generating a mesh for the visuals, you’ve spent the time. Now just assign it to the MeshCollider Component and you’re done.
If you are NOT generating a mesh for visuals already, then perhaps make a compound collider out of other primitives or much-simpler meshes to save compute time.
PhysX only supports Sphere, Box, Capsule, or Mesh colliders. If you want to use any other kind of custom collider, there is no way to get it to work with PhysX, which is the Physics engine Unity uses by default.
Anyway, if you’re generating a “custom” collider shape, isn’t that a mesh?
1 Like
I actually explained myself bad, sorry.
The mesh generation is okay. I generate vertices/triangles/etc in a 2nd thread, pass that to main, create mesh in main and pass it to renderer/collider. That’s how it is currently. By itself it’s not lagging, and it’s the best I could do, I think. Need it for visuals anyway.
The problem I’ve been having is some lag (very small by itself) when passing that generated mesh data to the collider. It would be no big deal if there was just one mesh, however I’m doing a voxel-ish kind of world, so each of those meshes is a piece of the world, and there are 100s of those pieces being generated (think Minecraft). I was looking at reducing the performance weight and that’s why I’ve been looking around for alternatives.
The first that came to mind is a custom collider, which is why I’m here today. But it seems to be impossible. My idea was to base collisions in a simpler algorithm, something about the lines of having a 3d matrix and checking numbers there, like in old NES games where you collided with tiles through simple maths. That doesn’t necessarily solve the issue, but hey, it was an idea.
The other alternative is constructing that collider with subcolliders, like you all mentioned. I think that’s the route I’ll go then. I’ll just try to reduce the amount of total colliders any way I can, because one chunk is 240x240x240 cubes, which means up to 13824000 colliders per chunk (piece of world). Which is of course not a good idea at all.
I’ll push “post”, been rewriting this for like half an hour. Sorry in advance if I explain myself poorly again.
I take it as read you’re already NOT updating it when it doesn’t change, correct?
Now what about just NOT doing the work at all except for blocks that meet specific requirements, such as “player or agent or projectile is close enough to care about collisions.”
I mean depending on your game it might only be a few meshes you truly care about.
The time-honored way of saving CPU and GPU is just… don’t do the work!
1 Like
Correct, currently the system only updates either when there is no mesh and it asks for one, or there is a change. It also checks for distance from the player, generates only meshes within that range and all that.
There has been some considerations around that idea of reducing the amount of colliders, especially for chunks that are too far away. It’s probably a good route to take, having a list of physics-enabled objects, check at what chunk they are located, and only care about chunks near them (with a small range should be good enough).
Thanks a lot for the suggestions!
1 Like
Um It’s nearly impossible Until a Unity Worker Guides You On How To do it coz Unity is written in c++ and all the c# classes Import Those Dlls and Call The Appropriate Methods So Until You Don’t Write A Custom Collider In C++ Using Nvidia’s Physx Documentation By Yourself And Then Create C# File For It, It’s just Impossible.
The collider cannot use the mesh as-is and needs to do some processing on it, this is likely the lag you’re seeing. The Mesh Collider manual page goes a bit into it under “Cooking Options”. They do recommend to turn some of these options off for dynamically generated meshes but there will always be some work that needs to be done.
Also note that if you have “Convex” enabled, Unity will convert your mesh to a convex hull, which also takes some time.
Besides tweaking the options above, you can try simplifying the collision mesh so Unity needs to do less processing or splitting it into smaller colliders, so that more work can be split across multiple frames.