Hi Paul,
Mathias, J-S -- Thanks for taking me down this thread, it has caused me
to do some serious thinking about some upcoming work I have to do for a
client, and re-think what my real objections are to something like
ShaderGen.
Ah, so that's why you were so vehemently objecting shader composition. I
wasn't talking about ShaderGen. I was talking about something closer to
VirtualProgram - see the osgshadercomposition example.
VirtualProgram gives you total freedom over what you want to do. You
just define prototypes, and then attach shader "fragments" that realize
these prototypes. Then lower down in the graph, you can attach a
different shader "fragment" that realizes the same prototype, and it
will override the one that was set higher up in the graph.
So that is to say, instead of whole shaders being inherited down the
graph, shader fragments are. This is very flexible. And there's no
restriction of what the shader fragments are, you don't have to
replicate the fixed pipeline at all if you don't want to.
OpenGL 3 gives developers a blank canvas with no restrictions, but
ShaderGen reimposes the restrictions of the FFP that OpenGL 3 removes,
by providing a way for developers to stay locked in an FFP-centric
mentality. By even having something like ShaderGen in OSG, it implies,
to me at least: "OSG is not forward-looking".
I kind of disagree with that, but that's a wider subject, and largely
down to appearances. OpenGL 3 is much easier to implement for driver
developers, but dumps a lot more work on the app developers. IMHO that's
a wrong philosophy, but it won't go back to how it was now... So IMHO,
this is a great opportunity for OSG to fill a niche by helping app
developers, at least when they start developing an app, but still giving
full access to OpenGL 3 if they want to.
I think a pipeline that starts with a shader that replicates the fixed
pipeline is a good thing, because not every OSG developer wants to deal
with the nitty gritty of shaders.
IMHO, StateAttributes that can be inherited or overridden down a graph
is a great abstraction to rendering, and it would be a shame to lose all
that and *force* users to use only shaders and uniforms for everything.
You don't want OSG to prevent you from having full control, but others
will want OSG to allow them to not *have* to take full control.
I'm envisioning an infrastructure that supports modules of shader code
scattered throughout the scene graph, tagged to identity the
functionality they implement. It would have "slots" for all FFP
features, but also the capability to add custom features not present in
the FFP. There would be some reasonable FFP defaults like ShaderGen has,
but the app could supply its own lighting shader code module, for
example, if desired. There would be a default main() that would
implement FFP, but the app could specify its own main() to go beyond
what is possible with the FFP, such as accessing custom features.
Does this sound like it would be a good system? I'd be interested in
hearing your thoughts on this concept.
Check out VirtualProgram, I think you'll find that most of this is done.
The difference is that which "slots" (it calls them prototypes) are
defined is completely up to the app, and no defaults exist, but I agree
that OSG could define some defaults and thus replicate the fixed
pipeline by default.
But just to reiterate, I was never talking about ShaderGen. I agree with
you, I think it's not a good strategy, just for the fact that it will
*always* replicate the fixed pipeline and gives no easy way to override
parts of that down in the graph, but VirtualProgram does.
J-S
--
______________________________________________________
Jean-Sebastien Guay [email protected]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
