HI Daniel,

I think the "correct" solution is to refactor osg::Material so that
the colour material is implementated seperately in its own
osg::ColorMaterial class.

The _colorMode is really a bit of hack to keep all the meterail
related operations in one place.  Its been this way since the very
early days of the OSG, and not something I've looked at much since as
it general works just fine.

In hindsight a seperate ColorMaterial state attribute would be more
flexible, and more of the "OSG" way that we've adopted with later
state attributes, i.e. to keep things orthogonal/decoupled.

However, there is this issue of backwards compatibility to be warry of.

Robert.

On 6/22/06, Daniel Trstenjak <[EMAIL PROTECTED]> wrote:

Hi all,

When a osg::StateAttribute uses a OpenGL mode than this mode
should be returned by osg::StateAttribute::getModeUsage(ModeUsage&).

osg::Material does this, but also calls glEnable/glDisable
in osg::Material::apply(State&):

(current cvs version)

void Material::apply(State&) const
{
    if (_colorMode==OFF)
    {
>>>     glDisable(GL_COLOR_MATERIAL);
        glColor4fv(_diffuseFront.ptr());
    }
    else
    {
>>>     glEnable(GL_COLOR_MATERIAL);
        glColorMaterial(GL_FRONT_AND_BACK,(GLenum)_colorMode);
        switch(_colorMode)
        {
            case(AMBIENT): glColor4fv(_ambientFront.ptr()); break;
            case(DIFFUSE): glColor4fv(_diffuseFront.ptr()); break;
            case(SPECULAR): glColor4fv(_specularFront.ptr()); break;
            case(EMISSION): glColor4fv(_emissionFront.ptr()); break;
            case(AMBIENT_AND_DIFFUSE): glColor4fv(_diffuseFront.ptr()); break;
            case(OFF): break;
        }
    }

    ....
}

The calls of glEnable/glDisable will cause an invalid osg::ModeStack.
These two calls shouldn't be there and osg::Material::getModeUsage(ModeUsage&)
should look like this.

bool MaterialgetModeUsage(ModeUsage& usage) const
{
   if (_colorMode == OFF) {
      return false;
   }
   else {
      usage.usesMode(GL_COLOR_MATERIAL);
      return true;
   }
}


Daniel
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to