Hi,
 
I think that going for the alternative of querying the scene is a great
way to go. This way, we would be able to construct various shaders
dynamically based on the requirements of scene nodes. Some shaders would
to shadow and some wouldn't. This would also help to have full scene
shaders which go down to the geometry level for specific effects. The
big problem is the management of such a shader interface since we can
only have one "main" method, and determining the requirements of the
scene can be complex/slow is not done well. (just my 2 cents!)
 
Regards,
 
Martin

________________________________

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Monday, February 19, 2007 12:43 PM
To: osg users
Subject: Re: [osg-users] osgShadow::ShadowMap implementation


Hi Mihai,


On 2/19/07, Mihai Radu <[EMAIL PROTECTED]> wrote: 

        Saw it  
        
        Had to wait for a couple of fixes while I was building, but now
[ rev. 6238 ] it works very nicely.



So does the latest SVN version compile fine?  If not point me at the
errors. 



        I have done this before, by using a bool Uniform to control the
texturing. On the first implementation, I had a flag when adding to the
scenegraph. 
        As an improvement, I was thinking of testing the models for
texturing ( at addition or update ) , I'm not sure if the steps below
are sufficient :
            Visit the model, test each Drawable for
StateSet->textureAttribute and set the Uniform accordingly
        Any suggestions for some code that does something similar wold
be very welcome.



I was thinking about having a uniform too, or simply a default texture
to inherit.  The other alternative is to go an query how the scene graph
is set up and apply different shaders.  This starts to get rather
intrusive. 
 

        This should be interesting, and very close to PSSM for 1 light.


It should be relatively straight forward - just multiple cameras, and
multiple textures, and different shaders to cope with the different
needs.
 

        When using spotlights this is much easier, as the spot's
parameters can be used.


I have a few thoughts on creating convex hulls around the shadow casting
model, then clipping this by a frustum created by enclosing the light
position with the view frustum.  One could add in spot light cone into
this clipping as well.  Then once you have your tightest bound convex
hull you can estimate the best fit projection required to capture it. 
 

        I think there are a couple of names for different
implementations of this [ from GpuGems 1 & ShaderX4 ]: 
            "Perspective Shadow Maps" [Stamminger02]
            "Light Space Perspective Shadow Maps" [Wimmer04]



Sounds about right.  Perspective Shadow Maps title is a bit misleading
as a title as the tex gen is perspective based when you have a position
light anyway, not even sure Light Space Perspective Shadow Maps is very
appropriate either... 
 

        Bias for the PolygonOffset and bias for SM look-up come to mind.



Feel free to add this methods to osgShadow.

 Robert.

        

Attachment: smiley-3.png
Description: smiley-3.png

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

Reply via email to