[osg-users] Lighting behavior and osgViewer::osgViewer

Paul Martz pmartz at skew-matrix.com
Thu Sep 13 07:41:25 PDT 2007

Hi Christophe --
If I'm reading your email right, you have two concerns:
 1. You don't understand how SceneView uses its _light member variable.
Without digging into the code, I'm not sure either. But I suspect it
circumvents the typical update/cull traversals and slaps the light state
directly into the positional state of the draw traversal. As _light just
controls GL_LIGHT_0, you don't need to access _light or even its StateSet --
you just need to specify your own alternate values for GL_LIGHT_0.
 2. You seem to be unsure that you can fully control lighting and
simultaneously use osgViewer. This is not the case, and again I direct you
to the osglight example program, which uses osgViewer and overrides lighting
effects directly in the scene graph.
Hope that helps,


From: osg-users-bounces at lists.openscenegraph.org
[mailto:osg-users-bounces at lists.openscenegraph.org] On Behalf Of Christophe
Sent: Thursday, September 13, 2007 2:57 AM
To: OpenSceneGraph Users
Subject: [osg-users] Lighting behavior and osgViewer::osgViewer

OK thanks, the code I was looking for to understand the whole thing lies
inside osgUtil::SceneView.cpp.
The chain is :
osgViewer::Viewer::setUpRenderingSupport()  -->
osgUtil::SceneView::setDefaults() , on each SceneView the Viewer has...
The _light member inside osgViewer::Viewer in the code as is, as far as I
can see, isn't associated to any StateSet nor any LightSource so is useless
for now (but maybe is to add itself to the SceneView::_globalStateSet one in
the future versions of OSG). OK...
Having multiple levels where things can be (osg::Light in this case) is a
bit tricky indeed.
Thanks for the help, I understand the mecanics...
The ony thing that remains is that :
-> SceneView::_globalStateSet  isn't set in any scenegraph the user can
modify after osgViewer creation : it is used along display list (if I
understand correctly, being still a little rookie), established through
cullVisitor and alike
-> due to protection levels one cannot access easily to sceneViews and their
_globalStateSet having a pointer to the mere Viewer.
Therefore, in other words, using osgViewer as is, and remaining at the scene
graph level isn't possible to solve the problem.
The other alternative would be to override some function of
osgViewer::Viewer or osgUtil::SceneViews but there again it's hard since the
non-virtual status of concerned methods prevent their overriding...
To sum up, it's quite hard to obtain a neutral lighting (but maybe also of
other properties) with current version of osgView and osgViewer.
Is there examples of OpenSceneGraph mainloops that don't use osgViewer as
the core ?? 
(It would prevent to have to do those resettings...)
I don't have seen any in
.0/examples/ .
Christophe Médard
Société OKTAL (http://www.oktal.fr)
2 impasse Boudeville
31100 Toulouse (France)
Tél. : (+33) 5 62 11 50 10
Fax : (+33) 5 62 11 50 29


----- Original Message ----- 
From: Paul  <mailto:pmartz at skew-matrix.com> Martz 
To: 'OpenSceneGraph Users' <mailto:osg-users at lists.openscenegraph.org>  

The fact that osgViewer/SceneView set up default lighting does seem to
confuse many users, as your posting demonstrates. However, lighting state is
really no different from any other state. You can control it in your own
scene graph using standard OSG setMode, setAttribute, and
setAttributeAndModes calls.
StateSet::setMode( GL_LIGHTING, OFF ); // Disable the OpenGL lighting
StateSet::setMode( GL_LIGHT_0, OFF ); // Disable OpenGL light 0
The above two calls disable the two features enabled in osgViewer/SceneView
by default.
If you want to leave lighting and light 0 enabled and simply control the
light's attribute (position, color, etc) then you should use osg::Light and
the osg::LightSource node as demonstrated in the osglighting example
Hope that helps,

Paul Martz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20070913/d20ea4d6/attachment-0003.htm>

More information about the osg-users mailing list