Is suspect its an issue with the relationship between OpenGL
attributes and modes, and naming. For instance
viewer.setLightingMode(NO_LIGHT); actually means that the view does
assign any setting for glLight, wheras this method could be thought of
as NO_LIGHTING which it isn't - lighting is still enabled, so there is
still light. Even the english language here can be a bit misleading
too.
Advance apologies for my rambling:
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/
