Hi Ben, I don't think this will work, as the cull traversal just stores the data in the rendering back (RenderLeaf/RenderBin/StateGraph) that is later traversed in the draw traversal. This will mean that you change will in effect restore the ambient light to what is appropriate for the rest of the scene, but break the ShadowMap, as it'll then have an overbright contribution from the ambient light, something that results in z fighting artefacts in the shadow map being far more obvious.
I think the only solution will be to have two separate lights, or perhaps just use shaders with custom handling of the light model. Robert. On Thu, May 22, 2008 at 10:28 AM, Ben Discoe <[EMAIL PROTECTED]> wrote: > Robert, > > I have found a partial workaround; save the light's Ambient value at the top > of cull(), and restore it before the bottom of the function. > > That seems to retain the desired behavior: > ".. so that the ambient bias uniform can take it's affect" > > The ambient bias still takes effect. I can smoothly transition ambient bias > from (0,1) very light shadows to (1,0) very dark shadows. And, with the > workaround, most objects in the scene still get their correct ambient. > > My scene graph layout is simple: > > 1. root > 1a. ShadowedScene > 1a1. Terrain (lit by ambient light) > 1a2. A vehicle (casting a shadow on the terrain) > 1b. the rest of the scene > > I hope a separate light is not needed, because that could be really complex. > I have attached my changed file, with the workaround which is at least some > improvement. > > -Ben > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:osg-users- >> [EMAIL PROTECTED] On Behalf Of Robert Osfield >> Sent: Wednesday, May 21, 2008 10:15 PM >> To: OpenSceneGraph Users >> Subject: Re: [osg-users] ShadowMap is wiping out ambient light; how to fix? >> >> Hi Ben, >> >> Thanks for investigating, with my fix I obviously made the assumption >> that the ShadowedScene contained the whole scene graph. As for using >> a separate light, this might well be the best route, one would >> probably need to keep overwriting it's values each frame from the main >> one. There will probably be issues about having two light sources on >> the same light number for a single RenderStage... ouch this one could >> get a bit sticky, this suggests we'd need to make the ShadowedScene >> its own RenderStage. >> >> Could you explain a bit more about your scene graph layout so I can >> better understand the mechanics of what is going wrong. Adding an >> extra example scene graph into the osgshadow example that illustrates >> this problem would be best >> as this would give us something we can all test and reproduce the >> problem and make sure fixes work well. >> >> Robert. >> >> On Thu, May 22, 2008 at 8:39 AM, Ben Discoe <[EMAIL PROTECTED]> wrote: >> >> ----- >> >> From: Alejandro Segovia >> >> Sent: Wednesday, May 21, 2008 5:50 AM >> >> >> >> Hey Ben, >> >> >> >> On Tue, May 20, 2008 at 6:20 AM, Ben Discoe <[EMAIL PROTECTED]> wrote: >> >>> I noticed that using osgShadow::ShadowMap in my scene makes everything >> >>> very dark, even nodes not part of the shadowed scene. Studying the >> OSG >> >>> code, i found this in ShadowMap.cpp, in ShadowMap::cull: >> >> >> >>> const_cast<osg::Light*>(selectLight)-> >> setAmbient(osg::Vec4(0.0f,0.0f,0.0f,1.0f); >> >> >> >> I can't seem to find this in OSG 2.2. It must have been added recently. >> >> Maybe the old code can be "forward ported"? :P >> > >> > I dug into SVN, and found the change, revision 7690, December 15, 2007. >> Comment is "Tweaked the ambient lighting contribution so that the OpenGL >> vertex lighting has the ambient light source switched off, and use the >> fragment shader to add this contribution back in." >> > >> > That added the code: >> > >> > // set to ambient on light to black so that the ambient bias uniform >> can take it's affect >> > const_cast<osg::Light*>(selectLight)- >> >setAmbient(osg::Vec4(0.0f,0.0f,0.0f,1.0f)); >> > >> > Unfortunately that breaks ambient light for the entire rest of the scene, >> because that light is the same light used to illuminate everything, even >> outside the shadowed sub-graph. Setting ambient to black has no effect if >> your materials already have no ambient. But if they have ambient, then >> osgshadow is wiping it out, resulting in very dark objects. >> > >> > So yes, the code can be 'forward ported' - we can remove that black >> ambient, or some other solution such as using a separate light. Robert, >> should i submit the fix to osg-submissions? >> > >> > -Ben >> > >> > >> > _______________________________________________ >> > osg-users mailing list >> > osg-users@lists.openscenegraph.org >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users- >> openscenegraph.org >> > >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
