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.
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".
However, it is undeniable that functionality present in the old FFP is
useful, after all, it was around for more than a decade. So maybe if we
could find a way to enhance ShaderGen so that it exposes the freedom
available in GL3 but also provides shader-based FFP equivalents, then
that might be a very good tool.
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.
-Paul
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
