Hello Wojciech,
first of all, thank you for taking a reasonable amount of time to dig in
to my problems.
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;-)
Currently I indeed have a Lightmanager, but i kept it a bit simpler by
doing this:
1. In a preprocess all lights are traversed from the scene, put in to a
structure inside the lighting manager and detached from the scene.
2. In a second preprocess all lights are analysed and and appropriate
lightvolume with a transform is created
2.1 render fullscreen quad with directional light (there is currently
only one directional light)
3. The main render-pass (realized via putting a RTT-camera with
preorder and attached scene at the viewer) renders Gbuffer
(depth+stencil, albedo + spec-mask, normals)
4. A lighting pass is performed with a graph containing the transformed
lightvolumes(in view-space)
This is simply done by using the standard culling and some
stencil-swapping to ensure only a few fragments are shaded despite of
being not lit.
5. Render all transparent objects applying a simple shader that performs
only directional lighting
6. Do a combine pass that takes the light-buffer and the albedo and
return the result to the final-postprocess cam
Now my design, while being not terribly sophisticated only uses some
cameras with a specific render-order, only relies on some subgraphs
being created(or ruled out via cullmask).
I'll give your LightManager that does some more logic on light source
culling/prioritizing a thought, but for now i really want to keep it as
small and simple as possible (as this spare time work)
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.
Okay, so deriving a own ShadowTechnique where I have full access and
control of the Camera and ShadowTex nodes in order to read them back in
the shadow-applying pass
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.
agreed, In my design this would have been done in the pass 6 or
somewhere after lighting buffer was created and filled
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.
Maybe I didn't state my question clear enough. Right now the FBO-camera
and textures are created in a hidden manner inside the DebugShadowMap.
So there is no simple way for me to rebind them or control when they are
executed, or do I miss something?
My current graph looks like this:
MainCAM
|
Relative Pre-render RTT
| |
| Opaque-Scene
Lighting-Pass Pre-Render-RTT
|
....
Now somewhere in between I would like to place a shadow-cam pass and
apply the shadow-textures in the lighting pass.
As I cannot set the render-order of the nested shadow-cams I cannot
guarantee it is executed before my lighting-pass, neither can I simply
get the camera-information in order to reproject the shadow-map into
light space.
Thanks for good explanations anyways, maybe my initial design wasn't the
best choice for shadow support. However lessons learned are invaluable ;-)
cheers
Sebastian
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
[email protected]
<mailto:[email protected]>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
<mailto:[email protected]>
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
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
