Hi Radu,
I tried to keep my shadow mapping code out of the scene setup business
as much as possible and have it concentrate on just rendering shadow
maps.  The only scene setup it does is add CameraNodes between a
user-specified root and scene.  The CameraNodes override scene shaders
with their own depth shaders to render shadow maps quickly.  The user
is still free to specify their scene as a subgraph of their whole
scene for the cases like you mention.  And the user is free to render
the final scene any way they want using the resulting shadow maps any
way they want.

There are so many ways to set up a scene that are application-specific
that I think it would be dangerous to let a shadow library do very
much of it.  It might make the library unusable for a lot of
applications.
- Terry


Message: 7
Date: Fri, 22 Sep 2006 17:38:57 -0400
From: Radu Mihai <[EMAIL PROTECTED]>
Subject: Re: [osg-users] Parallel-Split Shadow Map with osg [PSSM]
To: osg users <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="utf-8"

I haven't had time to move the files around the systems so it took me
some time to get back to posting the refactored osgdepthshadow:



Robert has mentioned that he's working on a shadow library, and I
think that, for me, now it's the time to have an interface to go
towards.
If there is something that can be used I would be ecstatic

I have to integrate this new depthShadows code in the company's app,
we already have this implemented, but it's based on pbuffer cameras
form OSG 0.99, and some of the code in there is plain ugly ...
The kind of issues I have to deal with now relate more to the
interface of this with the rest of the viewer:
        - are there objects excluded from casting shadows ? like terrain,
that receives, but doesn't cast
                this could be implemented straight-forward with a NodeMask on 
the
occluders Group
        - objects that cast, but don't receive shadows ?
                here changing shaders is needed
        - is the shadow library going to be managing the various render-
stages of the app ?
                or (link in the code above) it keeps track of the essential 
pieces,
and makes changes to subgraphs that are passed to it
The last point will be more important to PSSM, as the shadowLib has
to manage the splitting of the view fulstrum ( have to look @ Terry's
demo to see if some of these have been already dealt with)

--------------------------
Radu Mihai
[EMAIL PROTECTED]
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to