EXC_BAD_ACCESS at Triangle::OppositePoint

[Google Code Exporter]

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 [e-mail] on 9 Apr 2013 at 5:54

[Google Code Exporter]

Original comment by [e-mail] on 19 Apr 2013 at 7:46

• Changed state: Invalid

[Google Code Exporter]

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 [e-mail] on 9 Apr 2013 at 10:24

[Google Code Exporter]

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 [e-mail] on 10 Apr 2013 at 5:06

Attachments:

• crashingpoly.dat

[Google Code Exporter]

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 [e-mail] on 11 Apr 2013 at 2:25