Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convex hull not covering whole mesh when using small number of vertices per ch #143

Open
olivierp99 opened this issue Jan 16, 2023 · 7 comments

Comments

@olivierp99
Copy link

Hello,

As stated in the in title, using a small number of vertices per convex hull does not cover the whole mesh. Is there any way to mitigate that issue?

As you can see in the picture. We still see the red part from the original part. Tried change pretty much all parameters without success. Increasing the number of vertices fixes it but I would like to keep the number below 16 maybe.

Is there something I don't get?

Thanks in advance,

Olivier

Screenshot from 2023-01-15 22-24-46

@jratcliff63367
Copy link
Collaborator

I can research it, but the best I can do is probably mitigate it to some extent by using statistical methods. Please provide the sample asset and parameters you are using for the screenshot above.

I definitely think I can make it somewhat better by using kmeans plus plus.

@olivierp99
Copy link
Author

https://easyupload.io/gb345x
this would be the part.
something like: resolution = 400000, max ch = 5, max verts per ch = 8, max depth = 10 would do it, volume error = 1.0

thanks!

@jratcliff63367
Copy link
Collaborator

Thanks. I will try to work on this tomorrow or Wednesday. I'm fairly confident that kmeans plus-plus will give much better results. It will be a new command line option though. Kmeans is a statistical method which finds the mean most significant set of points from a point cloud. This should guarantee better coverage with fewer verts. I will say, though, that setting max vertices per convex hull toi 8 is extremely aggressive and will be difficult to get perfect results even with kmeans statistical averaging. It should be slightly better though.

Why so aggressively low? For performance reasons solely? If you used 16 verts it would probably look a lot better and shouldn't be a massive change in perf.

@olivierp99
Copy link
Author

I wanted something like a oriented bounding box decomposition. With 16 vertices it is fine but wanted something more like a box.

Thank you for you time!

@jratcliff63367
Copy link
Collaborator

I'm curious, why do you want an OBB? Are you writing your own physics engine? A low vertex count convex hull is processed extremely efficiently by most physics engines, I certainly know it is by the PhysX SDK. An OBB is always going to be a bit of a crappy fit compared to a convex hull. What you could do is just generate an OBB from the convex hull vertices. I have code of my own laying around that does this. I could even add a command line option to V-HACD to output the results as a set of OBBs, though I really don't see why that would be useful.

An OBB might be slightly faster than a low-vertex count convex hull, but probably not by very much.

@olivierp99
Copy link
Author

olivierp99 commented Jan 16, 2023

It more to process the part into simple primitives to apply different processing afterwards. It's not really for collision detection! Yeah I have thought the same (generate OBB from the hulls) but I'm not sure if it's enough from the 8 vertices result to cover all the part or not.
edit: typo

@jratcliff63367
Copy link
Collaborator

When you convert a hull to OBB just allow it to use more input points. I will add an OBB export option to the V-HACD tool for your reference when I fix the other issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants