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, -Paul
_____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christophe Medard 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 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.0 .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:[EMAIL PROTECTED]> Martz To: 'OpenSceneGraph Users' <mailto:[email protected]> 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 feature 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 program. Hope that helps, Paul Martz
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
