PDA

View Full Version : Distinct front and back face material properties



Phaedrus
04-16-2002, 07:57 AM
Are all material properties separable for front and back polygon faces or are there unavoidable interactions?
For example, the diffuse alpha component of the back faces trumps the alpha specified for the front faces. Also, the shininess specified for back faces seems to be ignored in deference to front face shininess.
Is there some basic lighting concept at work here that I am unable to grasp?
Are there any special tricks to completely separable specification of front and back material properties?

Relic
04-17-2002, 04:36 AM
OpenGL specs chapter 2.13.1 and 2.13.2 have no notion about differences between front and back handling. There are two independent sets of material parameters for front and back.
You need to have two sided lighting set in the glLightModel otherwise the front material is used for both sides.


[This message has been edited by Relic (edited 04-17-2002).]

Phaedrus
04-17-2002, 06:33 PM
I must confess to having neglected to check out the specs, but take your suggestion as valuble advice. I primarily rely on the man pages as well as the red and blue books.
I have two-sided lighting enabled and set up properly enough that ambient, diffuse, and specular properties for each side display as specified. Both sides, however, seem to use the shininess specified for the front side and the alpha specified for the back side (while back face shininess and front face alpha are ignored).
Perhaps, the GL specs will indicate whether this behavior is intended or if my results occur if some state exists even when two-sided lighting is otherwise set up properly.
I am new to this list and would greatly appreciate feedback if I am going about this question improperly here.
-Thanks

Relic
04-19-2002, 07:45 AM
My answer was not meant as an RTFM http://www.opengl.org/discussion_boards/ubb/wink.gif I just wanted to give a hint where I look normally.
(I just ignore all these "What happened to this board messages?". I have better things to do. http://www.opengl.org/discussion_boards/ubb/smile.gif)

Try if your code renders fine with another implementation (MS OpenGL generic or MESA).
If not, it's your program, if yes it's the driver.

mrbill
04-19-2002, 09:35 AM
There is a full set of FRONT material state and a full set of BACK material state.

So, to answer your question, no, the calculations for back colors should not use the front shininess and the alpha calulated for the front primary color should not use the back diffuse alpha.

Front colors are calculated using the current normal and front material state. Back colors are calculated using the negated current normal and back material state.

Possible sources of confusion or programmer error:

You can use Material calls with face set to FRONT_AND_BACK. This will set front material state and back material state simultaneously.

The other is ColorMaterial with face set to FRONT_AND_BACK. Again, this is setting front material state and back material state simultaneously continuously with glColor calls.

Another real gotcha involves the specular exponent (shininess). Lighting calculations are undefined if you have set the exponent less than 0.0 or greater than 128.0!

Finally, the colors (front OR back) are selected based on the winding of the polygon in window coordinates. Also remember that FrontFace sets the winding of front facing polygons to either CW or CCW, and this is determined in window coordinates.

-mr. bill

HFAFiend
04-24-2002, 08:17 AM
You can do some things different (like lighting, I believe) but I believe you'll have to use two polygons to pull off a double sided effect like you mentioned.

Phaedrus
04-25-2002, 09:57 AM
The GL code prompting my original question is within VTK. I have replicated much of the GL state-related stuff from vtkProperty, vtkLight, and vtkRenderer within a class of my own. I no longer have the obvious interaction between some front and back face material properties, but, as you suggest, the appearance of the faces does not seem completely distinct.
Though it sounds a little ugly ... just for kicks ... what do you think of these implementation ideas:
1.) glLightModel(LIGHT_MODEL_TWO_SIDE,TRUE)
glCullFace(GL_FRONT)
... set GL_FRONT alpha to 0 ...
... render geometry ...
glCullFace(GL_BACK)
... restore GL_FRONT alpha ...
... set GL_BACK alpha to 0 ...
... render geometry again ...
(this also has the advantage of being a
very cheap and dirty "depth sort")
-OR-
2.)
glLightModel(LIGHT_MODEL_TWO_SIDE,FALSE)
glCullFace(GL_BACK)
glFrontFace(GL_CCW)
... set "front" GL_FRONT material props ...
... render geometry ...
glFrontFace(GL_CW)
... set "back" GL_FRONT material props ...
... render geometry again ...
(here you don't have to consider the
influence of the opposite face at all, but
I fear my normals will be reversed and
screw up lighting)

Relic
04-29-2002, 04:12 AM
I have no idea what VTK is doing, if you're using this to work around its bugs. From pure OpenGL point of view:
#1) It doesn't make sense to set the alphas to 0, because it's not used in either case anyway because you've enabled culling for the repective side.
This cheap per object sorting will only work for non-occluding convex objects.
#2) Yes, your normals need to be inverted when switching winding and the order of drawing is not the same as under #1.

Phaedrus
04-30-2002, 10:05 AM
I should not have mentioned VTK ... I know what it's doing (mostly), but it wanders off topic ...
Thanks for the input. I know that the "depth-sorting" is craptastic at best, but I am dealing with multiple surfaces of ca. 100K - 2M triangles each, so any means which approximates depth sorting is useful when attemping to maintain interactive frame rates.