G'day,
I've got a problem with creating convex hulls. I create one with a total of 8 points, and it is fed 8 valid points, but I get a convex hull with only 3 points. Each of these points is a Vector3.NAN.
The purpose for this, is to create a bounding frustrum for box select in 3D space, it is not added to the space, just used in Toolbox.AreObjectsColliding(). The box is correct, and with a try catch or similar, I can ignore this bug most of the time and the box select works great using bepu.
I would use at static triangle group instead, but I can't really see any way to easily check collision, like the toolbox does without having an entire space for the selectionBox object.
These are some I can feed it, that give me a busted convex hull:
[0] {X:38.19882 Y:12.97655 Z:-25.88181}
[1] {X:38.09936 Y:12.97655 Z:-26.00113}
[2] {X:38.22325 Y:12.89633 Z:-25.90218}
[3] {X:38.12379 Y:12.89633 Z:-26.02149}
[4] {X:-324.2889 Y:-71.91434 Z:322.5069}
[5] {X:-344.1812 Y:-71.91434 Z:298.6451}
[6] {X:-319.4037 Y:-87.95857 Z:318.4344}
[7] {X:-339.296 Y:-87.95857 Z:294.5725}
Any help would be appreciated!
Convex Hull with 3 NAN Points?
Re: Convex Hull with 3 NAN Points?
As a workaround, you could try using a DetectorVolume. It wraps arbitrary closed TriangleMeshes and allows you to query them with entities for containment/intersection.
Technically the DetectorVolume is an Updateable, but you don't need to add it to the space to make use of its direct queries (isEntityIntersectingVolume, isEntityWithinVolume). Making use of the events would require being put in a Space, though.
I'll go run the points through the ConvexHull method to see if I can fix that problem too.
Technically the DetectorVolume is an Updateable, but you don't need to add it to the space to make use of its direct queries (isEntityIntersectingVolume, isEntityWithinVolume). Making use of the events would require being put in a Space, though.
I'll go run the points through the ConvexHull method to see if I can fix that problem too.
-
MuletTheGreat
- Posts: 8
- Joined: Thu May 06, 2010 7:30 am
Re: Convex Hull with 3 NAN Points?
[quote="Norbo"]As a workaround, you could try using a DetectorVolume. quote]
Works great, no flickering due the problem from earlier. Although the detector volumes I am creating seem to be a bit larger than I say, as objects highlight a bit before the selection box touches them. I tried lowering the error margin, but that had little effect.
Either way, it works much better now. Thanks for you fast response
Works great, no flickering due the problem from earlier. Although the detector volumes I am creating seem to be a bit larger than I say, as objects highlight a bit before the selection box touches them. I tried lowering the error margin, but that had little effect.
Either way, it works much better now. Thanks for you fast response
Re: Convex Hull with 3 NAN Points?
I wasn't able to reproduce the NaN problem with that pointset, unfortunately (using v0.13.0, but I believe the convex hull system did not change from v0.12.1). I do think there is an error somewhere as in the past I have observed occasional strange behavior in the getConvexHull method, but I haven't had the time to reproduce it.
As for the extra size, if you pass in a margin of 0 and it still seems to hit things slightly outside of it, it could be numerical precision problems rearing its head again. That selection frustrum's geometry is very long and tiny errors could start creeping in. At only a few hundred units long, it shouldn't produce massive errors, but there could be occasional issues. Using shallower frustums or splitting the geometry more would address this issue.
There's also the option of using the broadphase's getEntities method that takes a frustum, if selection worked based on bounding boxes instead of core shape. That might be a little awkward/inconsistent with the rest of the selection systems, though.
As for the extra size, if you pass in a margin of 0 and it still seems to hit things slightly outside of it, it could be numerical precision problems rearing its head again. That selection frustrum's geometry is very long and tiny errors could start creeping in. At only a few hundred units long, it shouldn't produce massive errors, but there could be occasional issues. Using shallower frustums or splitting the geometry more would address this issue.
There's also the option of using the broadphase's getEntities method that takes a frustum, if selection worked based on bounding boxes instead of core shape. That might be a little awkward/inconsistent with the rest of the selection systems, though.