Re: [Plib-devel] ssgSimpleState Question (bug?)

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

Steve,

Let me rephrase my question a bit more simply.

Can you tell me the proper way inside of ssgSimpleState to
enable/disable GL_COLOR_MATERIAL along with which variable should get
it's bits twiddled on/off?  That should be all I need to know to go
off and experiment with reordering state change calls to see if I can
eliminate my unwanted material property artifacts.

Thanks,

Curt.

Curt writes:
> > "Curtis L. Olson" wrote:
> > > For my flight gear application I had been noticing some strange
> > > lighting effects where the entire scene would jump to a noticably (and
> > > erroneously) brighter state depending on view direction, pitching the
> > > nose of the plane up, pitching down, etc.  Strange.
> 
> Steve Baker writes:
> > Seems like this is another variation of the dreaded glColorMaterial
> > problem.
> 
> Steve,
> 
> I've been poking around tonight in ssgSimpleState.cxx:
> ssgSimpleState::apply() and force().
> 
> Note: it is my "perception" that calling glMaterial() while
> GL_COLOR_MATERIAL is enabled seems to be generally problematic at
> least for me.  The only clue I can find in the Red book (version 1.1)
> is on page 201 at the bottom:
> 
>     You should use glColorMaterial() whenever you need to change a
>     single material parameter for most vertices in your scene.  If you
>     need to change more than one material parameter ... use
>     glMaterial().  When you don't need the capabilities of
>     glColorMaterial() anymore, be sure to disable it so that you don't
>     get undesired material properties ...
> 
> Well, I'm certainly getting "undesired material properties" when I mix
> glMaterial() with glColorMaterial() in the same ssgSimpleState ... !
> 
> The above statement seems to imply that if glColorMaterial is enabled
> and you aren't simply calling glColor() to set the specified material
> property, you are likely to get undesired material properties.
> 
> The program flow is a little obfuscated by the optimizations, but by
> my reading here is what is happening in ssgSimpleState::apply().
> 
> 1. glColorMaterial() is called first (if needed) irregardless of
> whether or not GL_COLOR_MATERIAL is enabled or not.
> [shouldn't be a problem]
> 
> 2. several glMaterial() calls may be made if needed (while
> GL_COLOR_MATERIAL is enabled.)
> [PROBLEM?]
> 
> 3. finally GL_COLOR_MATERIAL is enabled (if needed).
> [shouldn't be a problem]
> 
> So now the trick is to flip things around with out breaking a lot of
> stuff so that if we need to make any calls to glMaterial() we first
> *disable* GL_COLOR_MATERIAL, then make the glMaterial() calls.  Then
> re-enable GL_COLOR_MATERIAL, then call glColorMaterial() if needed.
> 
> Damn the OpenGL standard ... I think this will fix the problem!
> 
> Now, I tried my hand at rearranging things myself and am getting
> confused.
> 
> QUESTIONS:
> 
> What is the difference between:
> 
>      _ssgCurrentContext->getState()->enables
> 
> and:
> 
>     enables
> 
> ... in an ssgSimpleState:: method?
> 
> isEnabled(), enable(), and disable() seem to use the variable
> "enables" while force() and apply() seem to mix
> "_ssgCurrentContext->getState()->enables" and "enables" in ways I
> don't quite understand.
> 
> And ... the state of SSG_GL_COLOR_MATERIAL_EN almost seems to be
> switching magically on me for reasons also beyond my understanding.
> I've added quite a few fprintf(stderr, "...") and
> SSG_GL_COLOR_MATERIAL_EN seems to change state without anything
> telling it to ... but perhaps I'm getting
> _ssgCurrentContext->getState()->enables and "enables" confused and am
> not updating the bits in the proper variable when I force a disable
> before calling glMaterial()?
> 
> Any thoughts Steve?  It may be my sleep deprived stupor, but I've
> convinced myself that this is the problem ... making calls to
> glMaterial() while GL_COLOR_MATERIAL is enabled.  Any tips to point me
> in the right direction for correctly disabling GL_COLOR_MATERIAL
> before any glMaterial() calls are made?  If you take a look at it,
> this needs to be done both in apply() and in force() ... I'm guessing
> this won't be too hard to fix for someone who understands how it is
> all wired together.
> 
> Thanks,
> 
> Curt.
> --
> Curtis Olson   Human Factors Research Lab       Flight Gear Project
> Twin Cities    cu...@hf...                cu...@fl...
> Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel

-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org