Voronoi Fracture Demo Error

[StabInTheDark]

RBD, you are correct that shapeHull.buildHull does not show the actual collision geometry
in the Bullet demos. Let me explain my confusion, when I constructed visual geometry in my
game engine demo fromshapeHull.buildHull and "convexHC". I was getting more or less the same result
and it was matching the collision shape showing missing shards.

Flix, I have tested your suggestion in double precision and it makes a big difference. It fixes
the errors even at a larger scale. It has also made a difference with rotation which was causing
strange results in my game engine but not in the bullet demo.
Would either of you have a suggestion on a method to determine which faces are exterior to the
original shape so they could be textured differently from interior faces.

[Flix]

Flix, I have tested your suggestion in double precision and it makes a big difference

Are you referring to the change of the "threshold value" ? (as I wrote, I didn't test the double precision mode yet, but this solved the "missing shards issue" for me (that actually was a "bad shard creation when the aabb is large" issue)). And if so, have you found a way to associate the "threshold value" I changed to the aabb size of the input convex volume?

Another thing. Do you think that the double precision enhancement is something really necessary , or just something that fixes "second order" cracks (relative to the solution I proposed) ? I write this, because I'm very lazy at recompiling the whole bullet library (maybe I can try to use doubles instead of btScalar locally in the voronoi fracture related methods).

Would either of you have a suggestion on a method to determine which faces are exterior to the
original shape so they could be textured differently from interior faces.

Not me, although it would be useful. Anyway that's not strictly a Bullet-related question. And if you ask it, it means that all of your issues about Voronoi Shatter in Bullet are solved !

[StabInTheDark]

Are you referring to the change of the "threshold value" ?

Yes the threshold value made the difference.

And if so, have you found a way to associate the "threshold value" I changed to the aabb size of the input convex volume?

No, I am still trying to create a good solution.

Another thing. Do you think that the double precision enhancement is something really necessary , or just something that fixes "second order" cracks (relative to the solution I proposed) ? I write this, because I'm very lazy at recompiling the whole bullet library (maybe I can try to use doubles instead of btScalar locally in the voronoi fracture related methods).

Since I am wrapping Bullet to be used in a game engine double precision is necessary.
I should have realized I was not working in double precision before I posted.
I had been using Newton Game Dynamics before switching to Bullet, which was using double precision.
I guess it would depend on how you are using Bullet.
Its very easy to rebuild as double precision.

The "voronoiConvexHullShatter" is also working nicely now.
I would like to be able to voronoi shatter the actual mesh.
This has inspired me to look into the "Voro++" library
and possibly incorporate it in Bullet. If I have any success I will create a new post.
Yes, my problems with voronoi shatter are solved.

[Flix]

I'm glad SITD soved his problems

I was wondering why this solution seems to be working... here is my personal answer:

In a previous post, RBD wrote that to limit math precision problems one can scale / translate objects to and from around unit scale / origin, before and after fracture.
I think this is the point: maybe (but I'm not sure about it) scaling both threshold values in getVerticesInsidePlanes(...) can be roughly equivalent to scale/scale back the input aabb.
It's not the optimal approach and we should still center the aabb for best results, but,
as I said, it seems to be the easiest modification possible to make the Voronoi Fracture Demo work with bigger objects.

The bigger the shards are (this happens when the input aabb is big and/or when VORONOIPOINTS is small), the bigger such errors seem to be, the bigger the values should be scaled.

This is what (at the moment) I'm thinking about this solution.

In addition:
-> double precision mode can of course help a lot.
-> as usual btShapeHull's visual cracks may appear (but I can detect them).