[Geometry] 3D Oriented Bounding Box
Hi All, Boost.Geometry looks promising for my personal projects. Reading the doc, I couldn't figure if it is possible to create a 3D oriented bounding box (OBB). I read that axis aligned bounding box (AABB) is supported but nothing on OBB. I need to use it in usual algorithms like intersetion, distance, ... Can anybody tell me if it is possible with the current Boost version and how I can achieve that ? Thanks. Jérémy
Hi Jérémy, Thanks for your interest. On 14-12-2011 19:23, Jérémy Coulon wrote:
Hi All, Boost.Geometry looks promising for my personal projects. Reading the doc, I couldn't figure if it is possible to create a 3D oriented bounding box (OBB). I read that axis aligned bounding box (AABB) is supported but nothing on OBB. I need to use it in usual algorithms like intersetion, distance, ...
Can anybody tell me if it is possible with the current Boost version and how I can achieve that ?
Yes, I can tell you that alas this is not possible with the current version. OBB's are not yet supported. Besides that, 3D intersections (besides trivial ones) are far from implemented... Regards, Barend
Le 14/12/2011 19:37, Barend Gehrels a écrit :
Yes, I can tell you that alas this is not possible with the current version. OBB's are not yet supported. Besides that, 3D intersections (besides trivial ones) are far from implemented...
OK. Thank you for your quick answer. Is there any project roadmap I can browse ? Another little question. When you say 3D intersections are not implemented, does it mean that a) it would not even compile b) it compiles but gives wrong results c) it gives correct results but is not optimized for 3D ? Regards, Jeremy
Jeremy Coulon wrote: Le 14/12/2011 19:37, Barend Gehrels a écrit :
Yes, I can tell you that alas this is not possible with the current version. OBB's are not yet supported. Besides that, 3D intersections (besides trivial ones) are far from implemented...
Another little question. When you say 3D intersections are not implemented, does it mean that a) it would not even compile b) it compiles but gives wrong results c) it gives correct results but is not optimized for 3D ?
The answer is (a) for the non-trivial intersections, but there seems to be a misunderstanding about the nature of 3D intersections. 3D solid modeling/meshing/graphics algorithms are not achieved by putting a template parameter for dimensionality on the 2D algorithm, passing 3 and getting the 3D algorithm. The algorithms for 3D intersections on 3D solids represented by a surface mesh, for example, are completely different than the algorithms for 2D intersections of polygons. They are less efficient (quadratic versus near-linear wrt. vertex count) and much harder to make numerically robust because of the higher order arithmetic involved. A 3D solid modeling library is an order of magnitude larger in scope than a 2D geometry library. What is meant by "non-trival" in this context is multiple man years of work, up to a decade or more to be competitive with the closed source offerings in terms of features, reliability and performance. Regards, Luke
On 15-12-2011 22:07, Simonson, Lucanus J wrote:
Jeremy Coulon wrote: Le 14/12/2011 19:37, Barend Gehrels a écrit :
Yes, I can tell you that alas this is not possible with the current version. OBB's are not yet supported. Besides that, 3D intersections (besides trivial ones) are far from implemented... Another little question. When you say 3D intersections are not implemented, does it mean that a) it would not even compile b) it compiles but gives wrong results c) it gives correct results but is not optimized for 3D ? The answer is (a) for the non-trivial intersections, but there seems to be a misunderstanding about the nature of 3D intersections. 3D solid modeling/meshing/graphics algorithms are not achieved by putting a template parameter for dimensionality on the 2D algorithm, passing 3 and getting the 3D algorithm. The algorithms for 3D intersections on 3D solids represented by a surface mesh, for example, are completely different than the algorithms for 2D intersections of polygons. They are less efficient (quadratic versus near-linear wrt. vertex count) and much harder to make numerically robust because of the higher order arithmetic involved. A 3D solid modeling library is an order of magnitude larger in scope than a 2D geometry library. What is meant by "non-trival" in this context is multiple man years of work, up to a decade or more to be competitive with the closed source offerings in terms of features, reliability and performance.
Thanks for this detailed explanation Luke, I agree with this. Regards, Barend
participants (3)
-
Barend Gehrels -
Jérémy Coulon -
Simonson, Lucanus J