> Curious little titbit. When you say you could access GL_LIGHTING state, > do you mean the GL_LIGHTING mode, or the glLight associated uniforms?
The mode itself. The glLight information is passed nicely to the shaders (including nuance like light positions being pre-transformed). The only reason I mentioned it is that if you're emulating FFP, some of the detail "stuff that just works" can be a speedbump. If you have an object under a DOF and toss a sibling decorator such as a wireframe bounding box and the box has GL_LIGHTING set OFF, then the object is shaded, the box glows, and all is well. If you emulate the shader and assume someone attaches it to the object at the DOF level instead of the geometry itself (or the shader state is inherited from higher up the graph), then you need the shader to examine the GL_LIGHTING mode so that it can keep the decorator lit and shade the object geometry normally as the FFP would. > Given this context I was expecting to have to do some high level shader > composition > (i.e. in our C++ code) using modes as a guide to know which shaders to > include in the > vertex/fragment main shaders. It may be possible to use #define's and > #ifdef's to > replicate some of this mode support, but have to admit I haven't explored > this part of GLSL yet. This seems to me to be a perfectly acceptable way to tackle it. If OSG "caught" every GL_LIGHTING mode change a user could make and set a uniform at that StateSet level, then the emulation shader would function like FFP (in this regard) and have access to a valid bool that tracked the GL_LIGHTING mode. The usual warnings come into play, such as a user poking through to OpenGL behind OSG's back and making a change to a mode that isn't caught by the uniform handler, etc. Bill _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
