>I'm a bit confused where the problem lies for you.
The problem is when i use introspection, i can't determine the string representation of a GLenum (or osg::StateAttribut::Mode)
>The StateAttribute::Type existings to differentiate between
>StateAttributes in a way that is efficient for StateSet to manage in a
>map. StateAttributes can be associated with multiple OpenGL modes, so
>its not possible to just replace the type by the modes associated with
>them.
Oups, my english is not very good, i'm sorry.
I don't want to replace the type by the modes associated with them.
I just when do an enum with osg::StateAttribute::GLMode, for all GLenum can be past to glEnable/glDisable function.
>Implementing an enum for all the OpenGL modes simply isn't practical,
>maintainable or extensibile - this is why its left up to use OpenGL
>modes directly, as new modes are added to OpenGL then they all can
>work natively without needing core OSG headers to be modified.
ok,
but with the osg::StateAttribute::Type you force the user to use specific attribute (all from OpenGL 2.0 and some from NVidia)
When a new attribute is added to OpenGL, you must add it to the osg::StateAttribute::Type, and implenting a new class for this attribut
So why not do the same process for the enum osg::StateAttribute::GLMode.
Generally a new GLmode is add to OpenGL at the same time that a new Attribute, so core OSG headers must be modified for Attribute and for GLmode.
Moreover the class TextureGLModeSet is use to check if the mode is a TextureMode, this class must be maintain with the OpenGL evolution, this is exactly what you qualified of "isn't practical, maintainable or extensibile". With a enum osg::StateAttribute::GLMode and another enum osg::StateAttribute::GLTextureMode you solve this checking with a type check at compile time.
Thanks
David
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
