I am looking to reuse the convex collision code for purposes other than physics simulation. Is it feasible to reuse the convex collision hull generator for generating new changing hulls every frame without performance issues?
Thanks.
I am looking to reuse the convex collision code for purposes other than physics simulation. Is it feasible to reuse the convex collision hull generator for generating new changing hulls every frame without performance issues?
Thanks.
Additional notes: I am trying to create a hull from a set of points that move. There will be many hulls so the hull creation should be efficient as it is done every frame.
Hi, it depends a bit on what you’re doing. Just building a convex hull is not terribly expensive, the biggest part of the cost comes from simplifying and shrinking them. Those steps make collision queries faster and help the simulation generate better contact points. But if you’re not simulating then you don’t care about contact points, and if you only query the hull a small number of times then simplifying might cost more than it saves. All costs are of course also proportional to the number of vertices you pass in.
It looks like ConvexHullBuilder doesn’t currently have an API that allows you to disable simplification or shrinking, but if you have a look at the constructor that takes HullGenerationParameters you can probably work out how to do it. You can then make a ConvexCollider from the ConvexHullBuilder if you want to do collision queries. I’m not sure whether it will be fast enough for your purposes but you can give it a try and time it, just make sure to use Burst ![]()
Hope that helps.
Thanks a lot for your response. Are you saying that removing the shrinking/simplification is not worth removing since it will make collision detection substantially less performant? In my case I’m actually just going to use it for generic collision detection. Thank you for your advice.
How shall I use burst in this process?
I think that removing shrinking and simplification is a good idea if you’re building hulls at runtime, unless you will do very many queries against the hull and can amortize the cost of simplification. These routines are O(N^4) in the worst case and intended for authoring time.
One limitation I should mention, ConvexCollider has some limits on the number of vertices, number of faces, and number of vertices per face. If the hulls you build might exceed those limits, and you don’t use simplification, then you will need to find another way to remove vertices from the hull builder input.
I’m also interested in this. I’d basically like a way to tell the constructor “it’s fine, this mesh is convex already”. ConvexHullGenerationParameters are only related to the actual simplification process.
A small detail for my personal use case: In my use case, I only have only vertices (no mesh).
Out of curiosity… What are you using a convex hull for then?
Yes but my convexhull is generated from points input instead of mesh.
Edit:
Sorry, somehow I misread your question. I’m using the hulls for collision detection.
Knowing that the mesh is convex would speed up ConvexHullBuilder, but probably not by much. Figuring out which vertices to discard from a concave set is only a small part of the process.
ConvexHullBuilder doesn’t use triangle data from the mesh, it only looks at the vertices.
That is unfortunate, because in my use case I have a pre-generated convex hull which I’d like to use.
If you already have all of the data required by ConvexCollider, then you can create one yourself and don’t have to use ConvexHullBuilder. However, without the shrinking done by ConvexHullBuilder, collision performance can be considerably worse. It’s a decision between whether you want to save time building the hull or during simulation. For typical physics usage it makes sense to spend some time building an optimized collider offline in order to save time while the game is running, but if you’re building hulls while the game is running then the decision may change.
Hi.
Your advice intrigues me. I am looking at the constructor that takes HullGenerationParameters for ConvexHullBuilder, and I am struggling to understand what bits of code are for shrinking and what is for the actual hull generation. Can you help me out? You seem to understand this better than I do. Thanks, I’m working through on making my own fast-version of this convex hull generator.
If you just wanted to build a hull without simplifying or shrinking, you would do everything up to and including the first BuildFaceIndices(), then call UpdateHullMassProperties(), then you’re done.