Quote:Original post by Dave Eberly I would be surprised if a tessellator for a simple polygon produces zero-area triangles. Not claiming they do not, but you have to work very hard to get them to do this...
The GLU tesselator implementation on my Linux box does this on Samsters' data set. I don't know which implementation it is exactly, but it's probably one that came with Mesa. It's not the SGI reference one I mentioned earlier, as that one produces normal (ie. non-zero area) results.
I should have only 8 triangles, but I get two more (degenerate ones).
And I just noticed that my Combine callback function is called exactly once in the very beginning: CombineCB: -128.000000, -23.000000, 0.000000
Am I getting these errors because I included a duplicate vertex point at the end of the list? I thought I needed to duplicate it to close the poly loop.
And yes, I have a cleanup function that removes degenerate triangles, so I end up with T-junctions.
Quote:Original post by samster581 bad blocking edge
It's not a 'bad edge'. The triangulation you got might be a corner case, but it is perfectly valid and doesn't contain t-junctions.
Quote:Original post by samster581 I should have only 8 triangles, but I get two more (degenerate ones).
8 triangles would be incorrect. The 10 you are getting are one valid permutation out of many others for a tesselation of that polygon.
Quote:Original post by samster581 And I just noticed that my Combine callback function is called exactly once in the very beginning: CombineCB: -128.000000, -23.000000, 0.000000
As I mentioned above, the combine function is called for new vertices and for merged vertices. The tesselator is merging your first and last vertices.
Quote:Original post by samster581 And yes, I have a cleanup function that removes degenerate triangles, so I end up with T-junctions.
So as I suspected, you are creating the t-junctions, and not the tesselator. Keep in mind that the two degenerated triangles are only degenerated in your original vertex configuration. As soon as you apply any transformation to your vertices (rotations, etc), these two triangles may suddenly get a non-zero area and will become visible (due to numerical inaccuracies in the transformation). They are needed for correct rendering, you cannot simply remove them.
Basically, your 'cleanup' function destroys valid geometry.
I removed the duplicate vertex point, but I still get the same list with degenerate triangles. The only difference was the Combine callback function is not called anymore.
Well, GLU tesselator may create degenerate triangles, but that is still bad for my purposes if I can't remove them.
Quote:Original post by samster581 Well, GLU tesselator may create degenerate triangles, but that is still bad for my purposes if I can't remove them.
Why ? They don't do any harm.
They're only semi-degenerated anyway. They're just zero area, but they have three individual indices. As such, they're actual valid triangles. A real degenerated triangle has two or three identical vertices, and becomes a line or a point (eg. something like 9,0,0 or 9,9,9). These triangles can be safely removed (usually).
They're only semi-degenerated anyway. They're just zero area, but they have three individual indices. As such, they're actual valid triangles. A real degenerated triangle has two or three identical vertices, and becomes a line or a point (eg. something like 9,0,0 or 9,9,9). These triangles can be safely removed (usually).
Because they are 'visually' bad. An artist working on a model won't know that it's valid geometry by just looking at it. And I remove all degenerate triangles, whether they are good or bad.
Quote:Original post by samster581 And I remove all degenerate triangles, whether they are good or bad.
And that is incorrect. You are destroying valid geometry by doing this. And whatever other tesselator you are using right now, don't bet on it never returning zero area faces, unless you specifically added code to prevent that. And even then, given the right input set, it will generate such faces. Simple numerical errors or two lines in epsilon range can be enough.
In conclusion, if your code cannot handle zero area faces, then it is broken.
Note that 99% of all code out there can handle these 'semi-degenerated' faces just fine, even if it wasn't built with this in mind. That's why most people using the GLU tesselator (and other tesselators) never even notice this "problem".
Quote: Samster, I can't reproduce your problem. Using your input data set (removed the last duplicate entry, but the triangulation is correct even if it is left in) I get the following triangles:
I have tested this on the old standard SGI implementation. So either your implementation of the GLU tesselator is broken, or you are using it incorrectly.
There are no degenerate triangles in your list. Why would you get a different listing, if you used the same data as mine? I set GLU_TESS_EDGE_FLAG too, so I only get triangle list back.
My tesselator is using default values. Tolerance property is set to zero, winding property is set to GLU_TESS_WINDING_ODD, boundary property is set to GL_FALSE. I don't see what else can be different.
[Edited by - samster581 on October 20, 2010 11:00:33 PM]
Using jyk's posted test code (sans windows.h and associated bits, for compiling under Linux) I get samster's results (with degenerate tri's) using both the original SGI SI (ogl-sample.20000807) and the latest Mesa (7.9).