Jonathan Franklin wrote:
My own view is that something that only works part of the time really doesn't work.
I'm sure that's great for whatever you do. It is valid in many use cases.
The visualization software that I work on, on the other hand, prefers speed over making sure that point p1 is provably inside or outside the box. If it's *that* close, then it doesn't matter.
Or more aptly, when computing the union of many polygons to simply display an area of coverage, it is much more important to be fast than to use the provably correct point p1 or p2, which happen to be so close together, that uncertainty/error in measurement is more significant than the FP precision. And it turns out that for my use case, the points are so close together, either one will do fine.
Hi Jonathan, I figured I should point out here that all failures will not be in the form of marching points, merged points, or point in polygon tests failing. The effects can manifest in the form of failed predicate checks which lead to large changes in the outputs. For example, if an algorithm at some point performs an orientation test and determines a state based on that orientation, another part of the algorithm may derive values and make decisions which are in conflict with that state. For boolean operations this can mean you have vertices which are skipped on output, incorrect point ordering when recovering faces/rings, or any other number of odd artifacts. These are of course algorithm dependent, and I don't claim to know how GGL would fail. Regards, Brandon