EXC_BAD_ACCESS at Triangle::OppositePoint
GoogleCodeExporter opened this issue · 4 comments
GoogleCodeExporter commented
I prepare a lot my polygons (procedurals) : check if self-intersecting, remove
doubles, adjust too close vertices, but I sometimes have an EXC_BAD_ACCESS in
Point* Triangle::OppositePoint(Triangle& t, Point& p)
{
Point *cw = t.PointCW(p);
double x = cw->x;
double y = cw->y;
x = p.x;
y = p.y;
return PointCW(*cw);
}
Could it be that adjacent edges are parallels ? I do allow my polygons to have
parallel edges. Do I need to move a little one of the vertices ?
I'm using the last svn version on MacOSX 10.8.
Thank you.
Original issue reported on code.google.com by lahoz....@gmail.com
on 9 Apr 2013 at 5:54
GoogleCodeExporter commented
Sorry for disturbing : I checked my crashing polygons (in a few hundreds set)
and I realized that my method to build my polygons from polylines wasn't
managing colinearity and was sometimes producing what you can see in the
attached file... Thanks for your quick answer.
Actually, I deal with coordinates that can go from -20.0 to 20.0. It doesn't
seem to be a problem though, but if you have an advice...
By the way, I saw the polygon.dae in the source files. Is there a tutorial or a
test file to show how to build a mesh from poly2tri ?
Thanks again.
Original comment by lahoz....@gmail.com
on 10 Apr 2013 at 5:06
Attachments:
GoogleCodeExporter commented
Need you to dump one or more of your polygons that fail so I can debug and see
what the problem might be.
If you could dump a bad polygon in the same format as these files:
http://code.google.com/p/poly2tri/source/browse/testbed%2Fdata
The default epsilon value is chosen for points in the range 0.0 - 1.0. A wild
guess is that you might have point values far outside that range and have some
floating point issues.
Original comment by thahlen@gmail.com
on 9 Apr 2013 at 10:24
GoogleCodeExporter commented
Original comment by thahlen@gmail.com
on 19 Apr 2013 at 7:46
- Changed state: Invalid
GoogleCodeExporter commented
Ah. -20 to 20 is no problem. You could multiply the epsilon by 20 and change it
to get the preferred epsilon precision.
There was someone using a range with very big numbers then he got some issues
due to loss of precision in orientation test using the default epsilon value.
Do you mean making an index list and coordinate list for use with opengl?
Original comment by thahlen@gmail.com
on 11 Apr 2013 at 2:25