Re: [Plib-devel] Another stumper ...

[Steve B. <sjb...@ai...>]

"Curtis L. Olson" wrote:

> 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 am totally brain-fried over this.  I've seen the same problem in
my own code - and the effect seems to vary from one OpenGL implementation
to another.

The problem seems to relate to the order of operations when enabling
glColorMaterial - or something like that.

I asked the Guru's on OpenGL-Gamedev to explain how this is *supposed*
to work - and it rapidly became apparrent that even amongst the people
who wrote the OpenGL spec, they don't 100% agree on what should happen
in some of the darker corners of the API.  Given that, it's not
entirely suprising that some OpenGL drivers get it wrong.

I've tried a variety of work-arounds - but whatever I do seems to
flake on some other driver.

IIRC, the coe of the misunderstanding is this:

  When you use glColorMaterial to tell opengl to use glColor to
set the current material colour, does it tell the renderer to use
the glColor colour for that component or does it tell the material
to change it's colour to whatever glColor says.

You may need to think about that distinction carefully.

This means that if you do something like:

   glMaterial ( ...AMBIENT...BLUE ) ;
   glColorMaterial ( ...AMBIENT... ) ;
   glEnable ( GL_COLOR_MATERIAL ) ;
   glColor ( RED ) ;  /* Set current ambient colour to RED. */
   glDisable ( GL_COLOR_MATERIAL ) ;
   draw something ;

...the resident guru's couldn't decide whether the current ambient
colour is:

* BLUE - because disabling the ColorMaterial means that
  the renderer switches to using the glMaterial colour - which
  was set to BLUE

* RED - because the glColor command changed the current material's
  ambient colour to RED and even though we've now disabled the
  ability to change the glMaterial colour future glColor commands.

Well, this is just one example of the mess we are in here.  IIRC,
it got deeper than that.

This stuff doesn't matter for most programs - but when you are
trying to use lazy evaluation of state change, it's a pain.

I think what's needed is to write some simple OpenGL test
programs and to try them on a variety of machines.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)