I am currently playing with the tesselator and I appear to be getting results I do not expect.

If I place the following contours into the tesselator:

{ (1,1), (1,-1), (-1,-1), (-1,1) } // CW square
{ (2,2), (-2,2), (-2,-2), (2,-2) } // CCW square
{ (3,3), (-3,3), (-3,-3), (3,-3) } // CCW square
{ (4,4), (4,-4), (-4,-4), (-4,4) } // CW square

With a winding rule of GLU_TESS_WINDING_POSITIVE and the tesselator set for boundary only, I get back:

{ (-4,-4), (-4,4), (4,4), (4,-4) } // CW square
{ (-3,3), (-3,-3), (3,-3), (3,3) } // CCW square

Which is puzzling, as my understanding of the documentation leads me to believe I should get something similar to:

{ (1,1), (1,-1), (-1,-1), (-1,1) } // CW square
{ (2,2), (-2,2), (-2,-2), (2,-2) } // CCW square

I am unsure if this a problem with my reading of the documentation (most likely) or an issue with the tesselator.

Essentially, I am trying to get “negative” polygons to just disappear (except where the overlap a positive polygon) leaving the positive polygons (minus any bits of negative polygon).

Does anyone have any ideas what may be the issue?

Your understanding is right. The 4 nested contours make 4 regions, and the winding numbers from the centre area to outward are 0, 1, 0, and -1. Therefore, the area you can see with GLU_TESS_WINDING_POSITIVE is the second region only.

But, I suspect 2 things in your implementation. First, you may looking at the contours from back. Because the winding direction becomes opposite if you look the contours in opposite side. (I guess this because the 4th contour is visible with all opposite windings.)

Second, you can use gluTessNormal() to specify the normal vector of contour explicitly, for example, (0,0,1). Because GLU tessellator will compute the normal from the given vertices and winding if you don’t define it.


I think I am, conceptually at least, looking from the front, in so much as I tend to consider counter-clockwise a sold, and clockwise to be nothing or a negative solid (depending on circumstance).

I do believe you have hit the nail squarely on the head however: the computed normal was indeed the problem, overriding this produced the predicted result.

I can now get on with having a good old play with the tesselator, thank you. :slight_smile: