TaylorCodes / poly2tri

Automatically exported from code.google.com/p/poly2tri
Other
0 stars 0 forks source link

EXC_BAD_ACCESS at Triangle::OppositePoint #71

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
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 8 years ago
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 8 years ago
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 8 years ago
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

GoogleCodeExporter commented 8 years ago

Original comment by thahlen@gmail.com on 19 Apr 2013 at 7:46