Re: [osg-users] ShadowMap is wiping out ambient light; how to fix?
- 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_castosg::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_castosg::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
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_castosg::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_castosg::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
Re: [osg-users] ShadowMap is wiping out ambient light; how to fix?
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_castosg::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_castosg::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 /* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield * * This library is open source and may be redistributed and/or modified under * the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or * (at your option) any later version. The full license is in LICENSE file * included with this distribution, and on the openscenegraph.org website. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * OpenSceneGraph Public License for more details. */ #include osgShadow/ShadowMap #include osgShadow/ShadowedScene #include osg/Notify #include osg/ComputeBoundsVisitor #include osg/PolygonOffset #include osg/CullFace #include osg/io_utils using namespace osgShadow; #include iostream //for debug #include osg/LightSource #include osg/PolygonMode #include osg/Geometry
Re: [osg-users] ShadowMap is wiping out ambient light; how to fix?
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_castosg::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_castosg::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
Re: [osg-users] ShadowMap is wiping out ambient light; how to fix?
Ben and Robert, I tried to avoid this discussion beacuse I am just leaving and will be back on monday, but this topic is also on my agenda, so I decided to join. I will be responding on monday. Ben, the change you did in practice equals to simply removing the line setting mbient to 0. Ambient light is not used throughtout rest of the cull method. Its used later at Rendering phase. So if you restore it at the end of the cull to the original value its like not reseting it. I agree with Ben that ambient light should not be touched inside ShadowTechnique. But leaving it as is would also require changing shadow shaders I guess. If you look at the shader using ambient bias formula. With some simplification it looks like this: color = gl_Color * Texture; color = color * ( AmbientBias.x + Ambient.y * Shadow ); This formula clearly cannot compute proper lighting without some simplification in lighting model. If you subsitute gl_Color with lighting term with most common solution used with Fixed pipeline we have gl_Color = ambientMaterial * ambientLighting + diffuseMaterial * diffuseLighting * ( N dot L ) [ + emissive ]. Emissive is usually not used so we may skip it. You will see that above shader using AmbientBias will always incorrectly scale ambient term somehow. Thats why (I guess) someone has turned off ambient completely. ( As you see specular is also omitteed. But with specular on gl_SecondaryColor its easy to add it.) I will go back to my email about AmbientBias earlier. Solution recommended by many papers is color = ( ambient + shadow * diffuse ) * texture; or bit more advanced color = ( ambient + ( dimming + ( 1 - dimming ) * shadow ) * diffuse ) * texture; where dimming is interpreted as some scattering factor which limits darkenning by shadow. Now when you reset ambient to zero, you end up with formula where uou can use AmbientBias.x and AmbientBias.y as dimming and ( 1-dimming ) factors. And I guess this was the idea behind zeroing Ambient contibution. But unfortunately its not good solution for wider audience. On the other hand using proper formula recommended by shadowing papers would require passing ambient term to fragment shader. Its almost impossible without using vertex shaders. And generic vertex shader emulating fixed pipeline could be huge and complex... So its probably the reason its done like its done. Cheers, Wojtek PS. I attach code excerpt from my code that defines such shaders for one light (code is based on fantastic Open GL Shadoing Language book Emulating fixed pipeline chapter ). You may try it you ShadowMaping app. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ben Discoe Sent: Thursday, May 22, 2008 11:28 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] ShadowMap is wiping out ambient light; how to fix? 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
Re: [osg-users] ShadowMap is wiping out ambient light; how to fix?
HI Wojteck, The fix the ambient light contribution one has to tweak the vertex program rather than the the fragment program, unless one moves the light computation to be per pixel rather than per vertex. Robert. On Thu, May 22, 2008 at 12:05 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Ben and Robert, I tried to avoid this discussion beacuse I am just leaving and will be back on monday, but this topic is also on my agenda, so I decided to join. I will be responding on monday. Ben, the change you did in practice equals to simply removing the line setting mbient to 0. Ambient light is not used throughtout rest of the cull method. Its used later at Rendering phase. So if you restore it at the end of the cull to the original value its like not reseting it. I agree with Ben that ambient light should not be touched inside ShadowTechnique. But leaving it as is would also require changing shadow shaders I guess. If you look at the shader using ambient bias formula. With some simplification it looks like this: color = gl_Color * Texture; color = color * ( AmbientBias.x + Ambient.y * Shadow ); This formula clearly cannot compute proper lighting without some simplification in lighting model. If you subsitute gl_Color with lighting term with most common solution used with Fixed pipeline we have gl_Color = ambientMaterial * ambientLighting + diffuseMaterial * diffuseLighting * ( N dot L ) [ + emissive ]. Emissive is usually not used so we may skip it. You will see that above shader using AmbientBias will always incorrectly scale ambient term somehow. Thats why (I guess) someone has turned off ambient completely. ( As you see specular is also omitteed. But with specular on gl_SecondaryColor its easy to add it.) I will go back to my email about AmbientBias earlier. Solution recommended by many papers is color = ( ambient + shadow * diffuse ) * texture; or bit more advanced color = ( ambient + ( dimming + ( 1 - dimming ) * shadow ) * diffuse ) * texture; where dimming is interpreted as some scattering factor which limits darkenning by shadow. Now when you reset ambient to zero, you end up with formula where uou can use AmbientBias.x and AmbientBias.y as dimming and ( 1-dimming ) factors. And I guess this was the idea behind zeroing Ambient contibution. But unfortunately its not good solution for wider audience. On the other hand using proper formula recommended by shadowing papers would require passing ambient term to fragment shader. Its almost impossible without using vertex shaders. And generic vertex shader emulating fixed pipeline could be huge and complex... So its probably the reason its done like its done. Cheers, Wojtek PS. I attach code excerpt from my code that defines such shaders for one light (code is based on fantastic Open GL Shadoing Language book Emulating fixed pipeline chapter ). You may try it you ShadowMaping app. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ben Discoe Sent: Thursday, May 22, 2008 11:28 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] ShadowMap is wiping out ambient light; how to fix? 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
Re: [osg-users] ShadowMap is wiping out ambient light; how to fix?
Hi Robert, The fix the ambient light contribution one has to tweak the vertex program rather than the the fragment program, unless one moves the light computation to be per pixel rather than per vertex. Agree, my shaders include Vertex shader. Thats what also said in the end of my post. I guess my posts are so lenghty you may have not read it till the end ;-). I certainly understand that you are terribly busy ;-). Cheers, Wojtek On Thu, May 22, 2008 at 12:05 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Ben and Robert, I tried to avoid this discussion beacuse I am just leaving and will be back on monday, but this topic is also on my agenda, so I decided to join. I will be responding on monday. Ben, the change you did in practice equals to simply removing the line setting mbient to 0. Ambient light is not used throughtout rest of the cull method. Its used later at Rendering phase. So if you restore it at the end of the cull to the original value its like not reseting it. I agree with Ben that ambient light should not be touched inside ShadowTechnique. But leaving it as is would also require changing shadow shaders I guess. If you look at the shader using ambient bias formula. With some simplification it looks like this: color = gl_Color * Texture; color = color * ( AmbientBias.x + Ambient.y * Shadow ); This formula clearly cannot compute proper lighting without some simplification in lighting model. If you subsitute gl_Color with lighting term with most common solution used with Fixed pipeline we have gl_Color = ambientMaterial * ambientLighting + diffuseMaterial * diffuseLighting * ( N dot L ) [ + emissive ]. Emissive is usually not used so we may skip it. You will see that above shader using AmbientBias will always incorrectly scale ambient term somehow. Thats why (I guess) someone has turned off ambient completely. ( As you see specular is also omitteed. But with specular on gl_SecondaryColor its easy to add it.) I will go back to my email about AmbientBias earlier. Solution recommended by many papers is color = ( ambient + shadow * diffuse ) * texture; or bit more advanced color = ( ambient + ( dimming + ( 1 - dimming ) * shadow ) * diffuse ) * texture; where dimming is interpreted as some scattering factor which limits darkenning by shadow. Now when you reset ambient to zero, you end up with formula where uou can use AmbientBias.x and AmbientBias.y as dimming and ( 1-dimming ) factors. And I guess this was the idea behind zeroing Ambient contibution. But unfortunately its not good solution for wider audience. On the other hand using proper formula recommended by shadowing papers would require passing ambient term to fragment shader. Its almost impossible without using vertex shaders. And generic vertex shader emulating fixed pipeline could be huge and complex... So its probably the reason its done like its done. Cheers, Wojtek PS. I attach code excerpt from my code that defines such shaders for one light (code is based on fantastic Open GL Shadoing Language book Emulating fixed pipeline chapter ). You may try it you ShadowMaping app. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ben Discoe Sent: Thursday, May 22, 2008 11:28 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] ShadowMap is wiping out ambient light; how to fix? 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
Re: [osg-users] ShadowMap is wiping out ambient light; how to fix?
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_castosg::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 -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ShadowMap is wiping out ambient light; how to fix?
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_castosg::Light*(selectLight)-setAmbient(osg::Vec4(0.0f,0.0f,0.0f,1.0f); The light's ambient is set to black, and never restored! That certainly explains why my whole scene is darker than normal. I thought i might fix it by saving the ambient value, and restoring it later at the bottom of ShadowMap::cull(). And in fact, this does restore the scene's lighting - but, it prevents ShadowMap from drawing a shadow correctly. Apparently, ShadowMap needs this black ambient set later after cull(), probably during render(). But if the light is black during the scene's render(), that's not good. Does anyone see a solution to this? I can only imagine a couple of possibilities: 1. Move the black-ambient from cull() to render pass somehow. I don't see any explicit render() code in ShadowMap so i have no idea how this would work. It seems like it must be possible. 2. Workaround: Make a second light, and set it with ShadowMap::setLight. Then ShadowMap can use that light with black ambient, and leave the real light alone. But, this is messy; we don't actually want 2 lights turned on in the OpenGL pipeline, and we'd have to constantly copy values (like direction) from the real light to the dummy light. -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
