[Plib-devel] Another stumper ...

[Curtis L. O. <cu...@in...>]

Here's another weird one I'm running into.  

I realize that with opengl, that opening statement always has meant
I've done something stupid.  But in this case I'm wondering if I've
hit an untested path of ssg and have managed to confuse it's lazy
state management.  Or it could be I've hit a subtlety of ssg and have
failed to do something I should be doing.  At any rate, here's the
description of my problem.

Note, with the exception of the "work around" I list at the end, I'm
not making any opengl calls in my code ... everything is handled
through ssg mechanisms.  (Well, no opengl calls that should matter.
The opengl calls I am doing are stuck in call backs and dis/enable
depth testing and change the blend mode.  These cannot be done with
ssg's provided state management.)

I'm building two objects in ssg.  One uses:

    state->enable( GL_COLOR_MATERIAL );
    state->setColourMaterial( GL_AMBIENT_AND_DIFFUSE );

The vertex colors are then provided via the ssgVertexColourArray.

The next object uses:

    state->enable( GL_COLOR_MATERIAL );
    state->setColourMaterial( GL_DIFFUSE );
    state->setMaterial( GL_AMBIENT, 0.0, 0.0, 0.0, 1.0 );

Note that the second object, the color_material function only applies
to the diffuse component, and I explicitely set the ambient component
to be black.

Now, when I draw my scene, it *appears* as if ssg's lazy state
management gets confused and on subsequent rendering passes, doesn't
properly set the AMBIENT back to all black for the second object.  If
I register a call back for the leaf node and have it explicitely call:

    color = all black;
    glMaterialfv ( GL_FRONT_AND_BACK, GL_AMBIENT, color ) ;

In this case the object is properly rendered.

Now to add to my confusion, I added some printf()'s to ssg to see when
and where it calls:

    glMaterialfv ( GL_FRONT_AND_BACK, GL_AMBIENT, ambient_color ) ;

As best I can tell, ssg resets the ambient color to 1, 1, 1, 1 at the
start of each rendering pass.  But, I do see it apparently trying to
do the right thing and setting the ambient color back to 0, 0, 0, 1
before rendering my second object, but for some reason this call
doesn't appear to have an effect.  Like I said before, if I also
"help" and make my own glMaterialfv() call in the object's predraw
callback, everything starts to work.

I guess I'm not expecting any quick solution from anyone, especially
with Steve on vacation.  But I'm hoping that writing out my problem
will help me stumble on the solution ... but so far that hasn't
worked.  So the only thing left to do is actually fire off the letter.
Usually if I get this far, I discover right after posting what my
problem is.

Regards,

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org