HI Oliver, Your ramblings are pretty well spot on. Language ambiguities, OpenGL naming, OSG naming and behavior all conspiring to confuse :-)
W.r.t having a high level LightingSystem class to enable/disable lighting etc, this would break the OSG's light weight mapping of OpenGL modes i.e. if one did a local stateset->setMode(GL_LIGHITNG, osg::StateAttribute::OFF); then the LightingSystem would be thrown out of sync. Trying to keep things is sync would lead to tangled mess of coding. Perhaps a small step on the OSG side would be to have more explict naming so NO_LIGHT could become NO_LIGHT_OBJECT, or perhaps... we should do away with NO_LIGHT completely. Another change might be to change VIew::setLightingMode() to View::setLightMode(), or perhaps change it completely so does View::setHeadlight(), View::setSkyLight(), and have a View::setLightingEnabled(bool) method that does a Viewer::getCamera()->getOrCreateStateSet()->setMode(GL_LIGHTING, osg::StateAttribute::ON); Robert. Robert. On 6/29/07, Oliver Schoenborn <[EMAIL PROTECTED]> wrote:
My own experience with lighting was exactly as discussed: very confusing. If I think back, and reading this thread, I think it's because in english there is no real distinction between "no light" and "no lighting" (though there is between "light" and "lighting"), whereas the OpenGL (and therefore OSG) API's do make a distinction. I gather that OpenGL models the concept of light in the environment as (one) light switch plus one or more lights, and that "lighting" refers to the light switch (common to all lights). The OpenGL naming (and therefore OSG's) is confusing in terms of "adding light" perhaps because they assume developers will just "know" that to have things lit in the world you need to have lights *and* "turn on the switch". With respect to turning lights off, perhaps there it's the defaults that are the source of confusion: you should just have to turn "lighting" off. Oh look the OSG api has a "no light" option for viewer -- hey that must be it! oops light doesn't go away, why not? Because it refers to the presence of a light, not to lighting itself. If the OSG API had an osg::LightingSystem (.e.g), with methods like enableLighting() and manageLight(osg::Light), and for the osg::Viewer a method setLightingSystem(), then those are the first things the developer would find and perhaps they wouldn't go astray. As a developer it's probably reasonable for me to assume that osg::Viewer's "no light" should imply that I'm not going to see anything lit, rather than "oh but the low-level behind-the-scenes OpenGL stuff has different defaults so lighting could still be on. " :) So it's a compound problem: OpenGL naming, OpenGL defaults, OSG wrapping of openGL vs defaults. A good example of how an API affects what developers try first (the first thing they find in the API). JM2CW of course (wihtout even having checked what the new API does) :> Oliver _______________________________________________ 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/
