Hi terry, about the PSSM demo...
The osg::View class, where does that come from? Old? New? Never seen it
before.
Something from your own stew?
/Anders
________________________________________________________________
Anders Backman Email: [EMAIL PROTECTED]
HPC2N/VRlab Phone: +46 (0)90-786 9936
Umea university Cellular: +46 (0)70-392 64 67
S-901 87 UMEA SWEDEN Fax: +46 90-786 6126
http://www.cs.umu.se/~andersb
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Terry Welsh
> Sent: den 21 september 2006 04:33
> To: [email protected]
> Subject: Re: [osg-users] Parallel-Split Shadow Map with osg [PSSM]
>
>
> Hi all,
> Sounds like a lot of people want PSSM, so here's another
> contribution to the effort.
> http://www.reallyslick.com/~terry/stuff/PSSMdemo.tar.gz To
> run this demo, you'll need a model of a big scene; I didn't
> supply one. I suggest a nice outdoor scene about 10,000
> units in diameter. You also need GLSL support.
>
> This implementation is fairly complete, but I would like any
> opinions that you all have (or code to extend it). I don't
> know if this would make a better example program or nodekit.
> The big problem I see with making a nodekit is that there are
> just too many different ways to implement PSSM; I don't know
> how you could make one nodekit that would satisfy everyone.
>
> The angle I took in writing the DirectionalParallelSplitShadowMaps
> class was to just produce high quality shadow maps, but not
> to force people to render their scene any particular way.
> The demo renders your scene in one stage with a shader, but
> it would be interesting to see what happens if you split the
> scene into slices and render each slice with a single shadow map.
>
> I also did not implement a split scheme like Adrian did. It
> seemed like everyone uses a different split scheme, and the
> split scheme might need to be particular to the scene, so I
> leave that up to the user of the
> DirectionalParallelSplitShadowMaps class.
>
> The class lets you add your scene in pieces: an opaque
> piece, and a piece with transparency. Then it applies a
> different shader to each one for rendering the shadow maps.
> It might be nice to apply a different shader to the opaque
> and transparent rendering bins, so that the user doesn't need
> to make this separation themselves. I don't know if this is
> possible yet, though. On the other hand, no sorting is
> necessary for rendering objects with alpha into a shadow map
> because pieces of those objects either become completely
> opaque or completely transparent in the shadow map. So maybe
> the rendering big idea isn't the best solution.
>
> The biggest thing missing in this demo is good LOD support.
> I have been trading emails with Robert about implementing
> good LOD support for shadows, but this effort isn't complete
> yet. So you might not see shadows cast by LODed nodes.
>
> Anyway, let me know what you all think.....
> --
> Terry Welsh - mogumbo 'at' gmail.com
> www.reallyslick.com | www.mogumbo.com
>
> > Message: 12
> > Date: Wed, 20 Sep 2006 18:53:04 +0100
> > From: "Robert Osfield" <[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="iso-8859-1"
> >
> > On 9/20/06, Radu Mihai <[EMAIL PROTECTED]> wrote:
> > >
> > > Here's how I think this could be handled:
> > > - SSM NodeKit - standard shadow map, using FBO and
> GL_DEPTH textures
> > > there's an point of interest being discussed in the list about
> > > doing a depth-only FBO render after the FBO version is
> running well,
> > > there can be some fall-back methods added
> > > - derive a PSSM NodeKit based on the previous one
> > > I think the approach here would be to have MultiTexturing
> used in the SSM
> > > kit and use that capability in the PSSM kit to do the
> texture management
> > > additionally there will be code to manage the creation of
> the splits
> > >
> > > This kind of approach would allow me to combine job-related work
> > > with OSG contributions :)
> > >
> > > If you're interested, and if you think this is a good way to
> > > proceed, I'll post the code I have and we can go forward
> from there.
> > >
> >
> > FYI, I should start work on an osgShadow library for the OSG quite
> > soon. The contract is for stencil volume shadows, so this will
> > probably be the intitial back end implementation, however,
> I'd like to
> > make the interface classes as generic as possible, and
> support other
> > shadowing algorithms.
> >
> > How easy this might be is very difficult for me to say until one
> > starts lining up various implementation side by side and
> working out
> > the commonality and the differences, and finding ways to
> encapsulate
> > the differences neatly.
> >
> > More info on this once I get underway on it.
> >
> > Robert.
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://openscenegraph.net/mailman/listinfo/osg> -users
>
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
