Hi Sebastian, Unfortuantely I do not have enough time to get as deep as neccessary into this complex problem you are considering. There could be many approaches to integration of deffered shading with OSG. And I guess algorithms and data structures used in such implementations would most probably impact the ways of Shadow integration. So its hard to speak how to best adopt the Shadow techniques without deeper knowledge of your DefferedShader classes and their call graphs.
I have seen few projects recently where fixed lighting was replaced by programmable lighting and in almost all cases certain ShadowTechique was a natural class to derive a LightManager which would be a main class controlling which lights are processed and which lights generate shadows. If I was to implement my deffered shader I would do the same. I would create LightManager class that would override my favourite shadow Technique. That class would be a center point for light handling and like all shadow techniques it would capture the cull method of main scene traversal to do following steps: 1: run the main scene cull to fill RenderStage to fill opaque geometry to G-Buffers. 2: read all traversed lights from PossitionalStateAttributes or run light traversal to select (cull) light sources lighting the view. Such Light cull traversal could take light volumes into consideration and could reject lights landing outside view frustum. 3: Then from list of processed lights I would probably select few (N) closest or brightest or largest volume (policy may vary) lightsources as those which cast the shadows and would run N cull traversals for the scene to generate RenderStages for their shadow maps. Remaining lights would not need own RenderStages because would be rendered without shadows. 4: Then in next step would add light geometries used to lit the pixels in lighting passes each light geometry would also take proper shadow map and would set the positioning and scaling matrices on some uniform. Shader applied for geometry would add light contribution to color buffers. 5....: Next steps would be transparency pass and postprocessors. (I must say I have not thought much about how to integrate them yet, but I am sure something tehre must be a way to do it;-) Certainly the steps 1..4 (if not all) can be invoked from such overriden cull method of LightManager. So refering to your questions I would rather make my customized ShadowTechnique a center class for the algorithm. So I would not import external shadow textures and cameras but would create container of shadow maps (actually single Shadow2DArray is perfect here) and vector of cameras for shadow maps as technique variables. The first one is to specify the texture the shadow-pass renders in by > myself so I can bind the appropriate texture object and set the render > order individually. > I believe ShadowTechnique extended to process N lights is a perfect place to do this. I would not render it individually just would make sure the Cameras have proper rendering order... > The second step is to tell the shadow pass not to apply the shadow texture > to the scene, but instead just guarantee that is finished after the > render-pass and must be able to pass me the matrices used for shadow > calculation so I can transform my scene's depth into light-view space on my > own. > Well... applying the shadow is actually done be global shader. As far as I understand you would need a special shader to generate MRT gbuffers. So will not render the shadows anyway then. Shadows maps would be most probaly multiplying light cotribution in later light passes. > I've taken a look into the DebugShadowMap which curiously seems to be the > place where the shadow-camera for the ViewDependentTechniques is declared. Yes DebugShadowMap defines ShadowMap and ShadowCamera because DebugShadowMap defines a lowest layer of Debug functionality of all ViewDependentShadowTechniques. This Debug functionality needs acces to shadow map so it declares it. StandardShadowMap is derived from DebugShadowMap and rest of stems from StandardShadowMap. > So my general idea was to provide a public function to set the > camera/render texture from the outside and tell the init function only to > create it if the cam wasn't setup from the outside. Honestly I found the split up code for the different shadow implementations > hard to understand, as they are scattered a bit too much to get the idea. > I admit its terribly complex but other option would be to create a 8 or 9 techinques that would have all the code separated and lots of this code would identical and redundant. Maintaining such thing would be a greater problem I guess. > Has anyone a better idea to render the shadow map to a predefined > FBO-attached texture and let my own shader do the reprojection in order to > do shadow mapping in a deferred setup? > As I said shadow map techniques do this for you. So I guess this means you have rather different class structure than I would propose. Cheers, Wojtek > Hello, >> >> I have used the osg shadow implementations with great success in state of >> the art forward rendering. >> Right now I'm trying to implement shadowmapping into my deferred >> rendering approach. >> Can anyone point me into the right direction, regarding the correct usage >> of the view dependent shadow mapping algorithms in a RTT environment? >> What I need to perform is to render the shadowmap in to depth texture and >> apply it later in separate pass. But how do I setup the shadowmapping graph >> to only render the shadow texture so I can use it later on in my >> lighting/combine pass? >> >> any hints are welcome >> cheers >> Sebastian >> ______________________________**_________________ >> osg-users mailing list >> osg-users@lists.**openscenegraph.org <[email protected]> >> http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** >> openscenegraph.org<http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org> >> > > ______________________________**_________________ > osg-users mailing list > osg-users@lists.**openscenegraph.org <[email protected]> > http://lists.openscenegraph.**org/listinfo.cgi/osg-users-** > openscenegraph.org<http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org> >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
