Hi Brandon,
I'm referring to OpenGL's CSG boolean ops and PolyBoolean, both of which routinely fail in an application with which I work. (It requires partitioning space by iteratively subtracting isovists from a triangle partition of a polygon with holes.) I have read the CGAL also has issues for similar reasons.
Thanks, I didn't tested them nor the use case you describe, but would be happy to test it (I mean: the use case)
Numerical floating point issues can be addressed using arbitrary arithmetic types, and besides that other measures can be taken using the default floating point types. As for GGL's working with arbitrary arithmetic types, I would have to take your word for it. I have found a few bits in the code that seem to be converting to double.. and so I'm not so sure about your claim.
Sure, you are right here. I think I mentioned this in another mail but will summarize it here with references. I was talking about how the design is setup. We've designed it with strategies and (optional) calculation types. That design is used in e.g. area calculation. Because the numeric_adaptor (this was another posting on the boost list) was not 100% completed and because it seems to have much overlap with Boost.Math bindings, we chose here for showing the design in some algorithms and we didn't yet apply it everywhere. So it is not yet applied to intersection indeed, and as the focus of the whole library is currently on intersections, I admit that I regret that and we should have chosen to apply it there. Anyway, I hope you'll believe me thus and please look in area, http://tinyurl.com/ggl-area1 and http://tinyurl.com/ggl-area2 where it is applied (it is also applied in centroid and distance). It will be in (a.o.) intersections too. Regards, Barend