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

Started by
2 comments, last by pjdixit 11 years, 11 months ago
GLUtesselator : Issues with zero-area triangles and T-intersections

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

I came across this issue when I was trying to triangulate Text entities using GLUtesselator. However, it can occur during triangulation of any polygon using GLUtesselator. The problem is that sometimes GLUtesselator generates zero-area triangles. Most of the times you can ignore them but there are cases where they can’t be ignored. I am trying to find a solution so that final triangulation of a given polygon do not have any zero-area triangles or T-intersections. As far as I know, GLUtesselator is one of the most robust and stable tesselator available so I would like to stick to it and won’t mind doing some post-processing to fix the triangulation rather than writing a new tesselator myself.[/font][/font]
[color=#373737]


[font=inherit]I will try to demonstrate the problem with tessellation of character ‘H’. Input vertices to the GLUtesselator are:[/font]

H_input.jpg



[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]H_Tesselation4.jpg[/font]



[font=inherit]vertexlist-table3.jpg[/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]H_T-Intersection2.jpg[/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]table_trilist2.jpg[/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]H_Wanted_Tesselation1.jpg[/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]

Advertisement
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?

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!

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.

This topic is closed to new replies.

Advertisement