unknown polygon winding trouble...

Hi,

I am having trouble rendering an isosurface extracted from a volume with the Marchine Cube algorithm. The problem is that my vertex array does not have consistent winding. All the models I have dealt with in the past has known winding and I would render with a state such as:

glEnable(GL_DEPTH_TEST); // hidden surface removal
glFrontFace(GL_CW); // counter clock-wise polygons face out
glEnable(GL_CULL_FACE); // Do not calculate inside
glCullFace(GL_BACK);

However, rendering my vertex array will not look correct since not all polygons are wound CW.

I tried to comment out these calls (except the depth test) and instead make a call to:

glLightModelf(GL_LIGHT_MODEL_TWO_SIDE, 1.0f);

However, this still doesn’t do the trick.

Does anyone have any advice on how to set the gl state so that I do not have to worry about polygon winding at all?

Thanks,
jdaniel

glDisable(GL_CULL_FACE);
glDisable(GL_LIGHTING_TWO_SIDE);

Note that if your normals are not unified, and you use lighting, you’ll get crap no matter what you do with the geometry, in accordance with the GIGO principle.

Originally posted by jwatte:
[b]

glDisable(GL_CULL_FACE);
glDisable(GL_LIGHTING_TWO_SIDE);

Note that if your normals are not unified, and you use lighting, you’ll get crap no matter what you do with the geometry, in accordance with the GIGO principle.[/b]
That’s not how you disable 2 sided lighting.

2 sided lighting screws up lighing. The dark faces now will be lit.

What the OP needs is a algo for reorienting normals. If the object is 2 manifold, then shoot a ray from far away to the polygon (maybe the center).
If # of intersections is even, then this ray suggests proper normal orientation.

It’s best to use this kind of algo to reorient the polys, the compute normals, then enable culling.

The algorithm that we are using does not provide consistent polygon winding, but does always produce normals that point outward. Shouldn’t I be able to render this mesh with correct lighting without having to reorient all the polygons?

Originally posted by jdaniel:
The algorithm that we are using does not provide consistent polygon winding, but does always produce normals that point outward. Shouldn’t I be able to render this mesh with correct lighting without having to reorient all the polygons?
That seems a little odd to me.

Using the indices for the polygons (or rather TRIANGLES), build an edge list that lets you compare the order the indices are in from one triangle to the other. To align the normals (when they are created using the actual vertices) you want Triangle a to use Point A then Point B and Triangle b to use Point B then point A.

Eg.

0 ----- 1
|\      |
| \     |
|  \    |
|   \   |
|    \  |
|     \ |
3 ----- 2

Triangle a = 0, 1, 2 (or 2, 0, 3)
Triangle b = 0, 2, 3

They have the same winding because in a the common edge goes 2 -> 0 while in b it goes 0 -> 2.

I haven’t thought about this for non-triangle meshes though (it should be fine with quads but beyond that I’d have to say “triangulate”).

Hope I explained that correctly - and I think it works - at least it did on paper. :smiley:

Originally posted by jdaniel:
The algorithm that we are using does not provide consistent polygon winding, but does always produce normals that point outward. Shouldn’t I be able to render this mesh with correct lighting without having to reorient all the polygons?
The answer seems obvious to me. Just disabled culling, and use regular old 1 sided lighting.

It’s so obvious that this question belongs in the beginners forum.

There is no relation between polygon winding and lighting.

>>There is no relation between polygon winding and lighting. <<

Sorry, this is completely wrong.
The normal needs to always point away from the front face of a polygon for OpenGL’s fixed pipe lighting to work.
The front face is defined by the projected vertex coordinates’ winding and the normal is inverted for two sided lighting in the backface cases only.
To get correct OpenGL lighting the winding and the normals must be in sync. Your marching cubes algorithm needs fixing.

Just disabled culling, and use regular old 1 sided lighting.
That’s what I suggested, but in my haste I used glDisable() instead of glLightModel() to suggest turning off two-sided lighting – hope that wasn’t too confusing :wink:

The normal needs to always point away from the front face of a polygon for OpenGL’s fixed pipe lighting to work.
That’s not correct. The normal is just a vector, and the GL vertex lighting doesn’t know anything about the winding order. If you have correct normals, and turn off back-face culling, then it should work fine.

OpenGL spec 2.0 says this:

“Lighting may operate in two-sided mode (tbs = TRUE), in which a front color
is computed with one set of material parameters (the front material) and a back
color is computed with a second set of material parameters (the back material).
This second computation replaces n with -n. If tbs = FALSE, then the back color
and front color are both assigned the color computed using the front material with
n.

The selection between back and front colors depends on the primitive of which
the vertex being lit is a part. If the primitive is a point or a line segment, the front
color is always selected. If it is a polygon, then the selection is based on the sign of
the (clipped or unclipped) polygon’s signed area computed in window coordinates.”

Ok, I agree, single sided lighting should work.
Two sided needs the normals correctly placed on the front face.

OK, but this is what you said

>>>Sorry, this is completely wrong.
The normal needs to always point away from the front face of a polygon for OpenGL’s fixed pipe lighting to work.
The front face is defined by the projected vertex coordinates’ winding and the normal is inverted for two sided lighting in the backface cases only.
To get correct OpenGL lighting the winding and the normals must be in sync. Your marching cubes algorithm needs fixing.<<<

but the normals orientation is not related to the polygon winding in one sided lighting.

I suggested the OP use 1 sided lighted.

If the OP absolutely needs a different back face color material, then loop back to the beginning of the thread.

Yes, I was wrong because I forgot that single sided lighting will assign the color to both front and back color.
And I was biased because I programmed a marching cubes algorithm before which has the triangle winding correct and use two sided lighting to get the inside blue and the outside red which perfectly validated winding at that time (and looks cool if you fly through the model).