Robert Osfield wrote:
it will at least mean that you can load the full range of scene graphs and then search and replace elements that you know aren't supported on your target of interest. In effect I've pushed the issue of support for non op elements on to application developer to handle, but as the same time given them a basic tool for going about fixing it.
That's a reasonable approach.
Further down the line I am thinking about whether we can do some runtime work to map elements like TexGen to uniforms or runtime modification of texture coordinates (for GLES1.x), this possibility extends to the rest of the osg::StateAttribute that are non ops as well. All these StateAttribute are useful ways to control elements of the rendering so not having them available in some way in GL3 and GLES2 would be a handicap to OSG users. However, solving these problems is something I'm more than happy to leave until after the basic GLES and GL3 ports.
Supporting OSG's fixed function interface in precooked shaders will be complex. This is one reason why OpenGL designers deprecated the fixed function interface: too complex to support in drivers on programmable hardware.
Even more complex would be making it easy for developers to integrate their own shaders with the fixed-function-over-shaders later, so that their own shaders could simply call a function to compute per vertex lighting values, for example.
-Paul _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
