# GLUtesselator : Issues with zero-area triangles and T-intersections

This topic is 2370 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

[font=inherit][color=#373737][font=inherit]

## [font=inherit]I will try to demonstrate the problem with tessellation of character ‘H’. Input vertices to the GLUtesselator are:[/font] [font=inherit][font=inherit]This is how it was triangulated using GLUtesselator. I set the winding to GLU_TESS_WINDING_ODD and GLU_TESS_TOLERANCE was set to default 0.[/font][/font] [font=inherit][/font] [font=inherit][/font] [font=inherit]After preliminary inspection of the triangulation, it seemed as if there were T-intersections at vertex 5 and 10 which raised a red flag as the geometry was further processed by half-edge data structure and T-intersections were not allowed.[/font] [font=inherit][/font] [font=inherit]However, generating the list of triangles showed that tessellation actually generated zero-area triangles and not T-intersections. Here is the list of generated triangles:[/font] [font=inherit][/font][font=inherit]Legend : T = True , F = False[/font] [font=inherit]The problem is that I can’t use zero-area triangles either as I can’t calculate normal or equation of plane correctly for zero-area triangles. Normals and equation of planes can be very critical for implementing smoothing and shadow generation algorithms so they need to have a valid value.[/font] [font=inherit]So, I am stuck here with a very bad situation: If I have zero-area triangles then I can’t calculate normal and equation of plane correctly which is a must. It is trivial to remove zero-area triangles but if I remove them then I am stuck with T-intersections and I can’t live with them either.[/font] [font=inherit]So I would like to make sure that in cases where GLUtesselator generates zero-area triangles, my application will re-triangulate a sub-portion of the polygon such that there are no zero-area triangles or T-intersections. For our example case, triangulation should look some thing like this:[/font] [font=inherit][/font] [font=inherit]I think its a very fundamental problem and a solution to it will benefit lot of developers working in a similar area. I am sure I am not the first one to stumble upon it. Any suggestions how it can be done? Any alternate approach is very welcome as well.[/font]

##### Share on other sites
As a robust workaround, why do you need to recalculate the normal for each triangle? You already know it per face - why can't you use that?

##### Share on other sites

As a robust workaround, why do you need to recalculate the normal for each triangle? You already know it per face - why can't you use that?

How did I miss that! That should work...

I guess it wasn't very obvious to me as per vertex normals were re-calculated for each triangle based on the geometry and connectivity information for smooth shading in a separate dll. I guess I just need to figure out a way to pass normal information to the dll and to block re-calculation of normal for zero-area triangles. Thanks a lot!

##### Share on other sites

How did I miss that! That should work...

I guess i spoke too early. Even with correct normals because of zero-area triangles there is flickering of edges and there are artifacts with stencil shadows. I suppose it is because of limited precision of depth buffer.

1. 1
Rutin
46
2. 2
3. 3
4. 4
5. 5
JoeJ
19

• 13
• 10
• 12
• 10
• 13
• ### Forum Statistics

• Total Topics
632998
• Total Posts
3009808
• ### Who's Online (See full list)

There are no registered users currently online

×