Hi, The SVN version compiles & works very nice (Fedora 6).
About the clipping for SM creation; if we could get the shadowers
clipped by the main view frustum, and then use the bounding box of this
for adjusting the SM camera, it would make a big improvement for SM
anti-aliasing. With the current method, adding in a shadow-casting
terrain makes the part of SM used close to the main camera very small,
therefore very jaggy.
On the subject of texturing control, for the simulation at work I wrote
a little "ShadingHelper", that applies shaders ( with sources taken from
lua config files), and applies them according to an [enum] criteria to
selected parts of our scene. Right now we are distinguishing between
regular 3D objects, particle systems and text (this one has a NULL
Program on it).
I think this is the beginning for more control for shading in osg, it
could be used to delegate the creation and storage of shading programs
and uniforms for the rest of the application. Then if below a certain
node there's a need for a specific program something like this could be
called:
ShadingHelper::setShadingProgram((osg::Node*)
i_node,ShadingHelper::ShadingProgramType::SHADOWED_TEXTURED);
for uniforms I can call something like this:
ShadingHelper::setShadingValue((osg::Node*) i_node,
(std::string)i_uniformName, <class T> value);
Some ideas on the things a general design should accomplish would be
very welcome.
Cheers
Mihai
On Mon, 2007-02-19 at 13:04 -0500, Martin Tapp wrote:
> 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.
>
>
>
>
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
--
Mihai Radu <[EMAIL PROTECTED]>
Critical Mass Labs
smiley-3.png
Description: smiley-3.png
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
