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

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

Sounds like the best solution is to try to stick to a consistant
scheme ... either use glColorMaterial every where, or don't use it at
all.  However, I've had very poor luck using anything but
glColorMaterial in ssg.  I get what I expect when I use
glColorMaterial.  I rarely get what I expect when I don't.  This could
be a problem with my understanding and expectations, or perhaps it
could be that something somewhere isn't quite right in the state
handling?

Regards,

Curt.

Steve Baker writes:
> 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)
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel

-- 
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