Hi Roger,
Thanks for the suggestions. They may well be my only option, but I am a
bit limited in what I can do as I am adding shadowing into an existing
application, which also limits me to the OSG 2.6 branch for production code.
I can relate, as I am also working on an existing framework which is
used in multiple existing applications, and up until lately we were
actually at OSG 2.2. I recently upped that to 2.6, with Wojtek's
ViewDependentShadow added locally.
I realise that taking nodes out of the tree could do what I want, but
that would be a bit messy as most of them are under LOD nodes, and the
user needs to be able to switch shadows on and off on various objects.
Sure, I agree it complicates things.
I have managed to avoid fragment shaders so far. Experiments using
ShadowMap gave me between a 30 and 50 percent raw framerate (non
vsynced) hit, and I am up against it performance wise in many cases
already. I already have a version which runs my own shader but as far as
I can see the ShadowMap does not allow me to specify my own uniforms via
a public interface, and more importantly unilaterally turns off ambient
lighting in the main scene.
Adding shadows can be expected to drop the total frame rate (vsync off,
as you say) by roughly half, since you're essentially rendering twice.
Other than disabling some unneeded effects when rendering to the shadow
map, which will lower the hit somewhat, you can't do anything about
that. The straight truth is that you're rendering twice, so expect a hit
related to that.
As to not using shaders, well, you're using shadows so you're using
shaders already... osgShadow::ShadowMap uses a fragment shader under the
ShadowedScene (no vertex shader, so the fixed vertex processing is kept,
but that's pretty easy to replicate in a vertex shader). So using those
shaders or using your own won't make much difference in performance (as
long as your shaders are well written, which of course requires some
learning if you haven't done it before), but the difference is that
everything is under your control.
For example, the problem with ambient lighting can be solved by changing
the shader - it's a result of how the osgShadow::ShadowMap default
shader is written. Replace that shader by one that calculates the
ambient lighting correctly, and the problem is solved.
Writing your own shaders also gives you control over lots of other
things, and you can use your own uniforms for all of it.
For me, it all comes down to the later points by Wojtek.
osgShadow::ShadowMap gives you the tools, and does the basic things, but
for anything else, it's up to the user of the library to do them in the
way they see fit. For me, replacing the osgShadow::ShadowMap shaders was
the way to go, as in the long run it also opens the doors to lots of
other things. For you it may be something else.
I won't go into your comments on node masks, as I don't think there's
much to be said about that. Node masks are the way they are, and they're
useful for some things, but in this case there are other solutions that
work as well or better...
Hope this helps,
J-S
--
______________________________________________________
Jean-Sebastien Guay [EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
