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

[Curt <cu...@in...>]

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