Hi David,
Good to know you've got some progress.
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.
Yes, of course, someday only OpenGL 3 will be supported in the graphic
card drivers, in which case the fixed pipeline will be deprecated. So
OSG will have to provide some high-level mechanism for managing shaders.
Whether that is a fully fleshed out shader system or something close to
what we already have (with a little more functionality) remains to be seen.
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.
Well, that is the crux of the problem really. There are a few ways to
manage shaders in a scene:
* One uber-shader at the root, with uniforms at nodes to control their
appearance, a bit like what ViewDependentShadow does now and what I do
in our framework here. (easy to maintain but on older cards you pay a
penalty for conditionals and loops).
* N different shaders for N different combinations of effects, and you
choose the right shader on the node depending on its appearance
(difficult to manage but you have more control and it can scale to
older/newer cards)
* Shader fragments on nodes which are linked together to make a complete
shader (reduces the number of shaders to write manually, but need to
make sure all combinations are linked at program load time or else
dynamically linking a program at runtime will introduce a frame rate hit)
There are possibly other strategies out there, but these are the main
points.
I've been researching this topic a lot, and there is still no clear
winner out of these three options. It's a tradeoff and depends on your
application and target market (for example: do you need to support old
cards or do you have control over your hardware?). I haven't yet done
any experimentation though, this is just from reading the literature.
(also see Deferred Shading which might render all this obsolete - if the
issue with transparency can be solved in an elegant way)
So unless OSG intends on supporting all three and allowing the user to
select which strategy to use, I think it's really up to the library user
to select a strategy and adapt it to his own use, and then implement it.
OSG should only supply the tools to make implementing these strategies
possible (and it already does).
As I said, that's just the way I feel about it, and you may disagree.
We'll see what the future holds. I'm sure that if someone submits a
system that implements one (or all) of these strategies, it will not be
rejected, but it won't be a silver bullet solution so it will only be
used by part of the applications using OSG.
1) I admit I haven't looked properly at the 2.7 osgShadow, but does it
handle LOD nodes within objects?
Yes. Specifically, the LOD used in shadow computation will be the same
as seen from the camera's viewpoint, so the shadow will look like the
geometry.
On our side, we're looking into forcing the lowest-resolution (furthest)
LOD for shadows, to lower the shadow RTT time in the cull traversal on
large models. But this is not supported in the basic shadow technique(s).
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).
Yes, of course you would need that in that case, and it's something that
can be supported by subclassing the shadow technique once again.
J-S
--
______________________________________________________
Jean-Sebastien Guay [EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
