Re: [boost] GGL Review

Subject: Re: [boost] GGL Review
From: Brandon Kohn (blkohn_at_[hidden])
Date: 2009-11-17 12:20:47

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