Wasn't implemented (nor modified!) by the authors of this project
Seems that "normally" the algorithm's getEdges returns with ... (start, a, b) where start has numbers.
In degenerate cases, the start of the VEdge will have Nan.
I guess our polygon-construction (using winged-edges and everything) assumes this isn't the case?
In the main.cpp of the code using this implementation, the points generated are all doubles, up-to-10000 in x, y coordinate. Our values are integers, and much smaller range.
With that kindof input, the implementation frequently runs into cases with NaN values in its startVPoint.
I don't know if it's a matter of:
just render these edges anyway (will still look 'nice'); and buggy polygon-construction(?)
the algorithm suffers too badly in edge cases.
In any case; probably better to just get rid of it for now; maybe investigate using some implementation of Fortune's if it turns out the Delaunay one is just too slow.
getEdgesreturns with ...(start, a, b)wherestarthas numbers.startof theVEdgewill haveNan.main.cppof the code using this implementation, the points generated are all doubles, up-to-10000 in x, y coordinate. Our values are integers, and much smaller range.NaNvalues in itsstartVPoint.I don't know if it's a matter of:
In any case; probably better to just get rid of it for now; maybe investigate using some implementation of Fortune's if it turns out the Delaunay one is just too slow.