David,
All classes belonging to ViewDependentShadow group derive shaders from
StandardShadowMap. If you look at these shaders you will notice that they are
split into main vertex and fragment shader and shadow vertex and fragment
shader. Main shaders do nothing extraordinary they simply emulate fixed
pipeline. Specific shadow tasks are performed in DynamicShadow functions
defined in shadow.vert and shadow.frag shaders. So the code is prepared for
such scenario where you simply substitute main shaders with yours and link your
main shaders with default shadow technique shadow shaders.
As to more general problem of shaders in OSG classes conflicting with user
shaders I think we should start another thread devoted only to discussing this
problem. I agree Its important topic but I really think its not only related
to shadows.
LODs should be properly handled by ViewDependentshadows. Shadow camera uses the
same viewpoint as main camera. Shadow Camera ref frame is set to
ABSOLUTE_RF_INHERIT_VIEWPOINT.
The depth map rendering optimizations were the topic we discussed recently with
J-S. For now we have decided we don't change this code. If neccessary - one
should be able to everride proper shadow class and their internal ViewData
class and adjust this fuctionality where needed.
Cheers,
Wojtek
----- Original Message -----
From: David Spilling
To: OpenSceneGraph Users
Sent: Thursday, October 23, 2008 2:04 PM
Subject: Re: [osg-users] Advice on interacting with osgShadow
Hi J-S, Wojciech,
Thanks for the help. I've got shadow maps working (I'm on 2.6.1) and when I
get round to it, I'll migrate up to the 2.7 ViewDependant stuff and see if I
can get the other techniques working as well.
Now, an add-on library could be written that would help unify the art
pipeline. Things like models, textures, mapping of textures to texture units,
shader management, shader generation from chunks of shader code, effect
management, etc. could be made much simpler and more user-friendly. But as I
said, I don't think it's OSG's job to do this. OSG provides a framework, and
this is a bit too domain-specific IMHO.
Regarding shader management, I think that it would be appropriate for OSG to
provide something here. ( Obviously I realise that this is a large amount of
code - I'm arguing about the appropriateness, not actually demanding that
someone provide it ! )
The reason is basically that as fixed function falls away, shaders become
more important, and the relationship between the scenegraph and the shader
becomes much more like the relationship between the scenegraph and the state.
For example, the 2.7 shadow library does a fantastic out-of-the-box job of
providing a sort of uber-shader that tries to handle a variety of effects
(various sorts of lights, multiple lights, diffuse texture etc.). However,
throw that at a model that already has shaders on it, and you end up having to
copy-and-paste the shadow shader into the models' shader. This gets more
complicated if the various shadowed objects have different shaders, and this is
the situation I have. I fear that bugfixes and so on to the complex shaders in
osgShadow will end up with my object shaders being out-of-step, and therefore
producing hard to pin-down errors in the result. (shader debugging is awful).
Thinking aloud, I wonder if some sort of text-based accumulation of functions
that are passed down the scenegraph, with assembly and binding at the level
they are actually required, would be appropriate. For example, the shadow
shader could just be a stub e.g. a "float CalculateShadow()" function that
objects that are shadowed need to call if they want.
A couple of specific things:
1) I admit I haven't looked properly at the 2.7 osgShadow, but does it handle
LOD nodes within objects?
2) Although not relevant to me right now, in case the depth-only vertex
shader gets implemented (at the moment it appears from the comments that fixed
function has been found to be faster) it might be useful to be able to override
osgShadow's depth-only vertex shader, - the object might in some cases be being
dynamically transformed during shadowing (e.g. character animation).
Anyway, just my 2p. Thanks (all involved) for all the work on the shadow
libraries.
David
------------------------------------------------------------------------------
_______________________________________________
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