Hi Paul, On Fri, Aug 14, 2009 at 5:19 PM, Paul Martz<[email protected]> wrote: > I'd caution against reusing the "gl_" names. The GLSL spec, section 3.7, > says: "Identifiers starting with “gl_” are reserved for use by OpenGL, and > may not be declared in a shader as either a variable or a function." I'd > propose a mechanism that allows the application to specify the uniform > variable names these matrices should map to. Then, if the app wants to reuse > the reserved "gl_" names, they are free to do so, but apps that want to > write cleaner code are free to use other names.
If GL3 isn't providing any gl_ uniforms surely they can't be reserved, you can only reserve something if it might exists. I can see why gl_ will be reserved for GL2, but I can't see the issue for non backwards compatible GL3. > But I like the idea of setting these uniforms directly in State. Very > efficient solution. >> >> Need for the inverse versions and combinations >> could also be supported via osg::State. >> >> One in theory could name the projection and modelview matrices >> anything you want but personally I think it would be good to stick >> with a standard naming to avoid confusion and the need for extra API >> to set them consistently. >> > > :-) Looks like we disagree. > > While I don't think adding an entry point to let the app specify the matrix > uniform names would be too cumbersome, I'm open to other options for > providing this same flexibility. Could there be a simple API solution such > as a callback that could be executed when one of these matrices change > during draw? This would allow apps to register a callback that would set > matrices for any uniform variable name they desire. This would avoid the > reserved prefix issue without adding too much API entry point bulk. IMHO, a callback would be really cumbersome. If we have to modify the name of the modelview and projection matrix then we should just expose the Uniforms used directly in osg::State, and one would have to have some scene graph API for setting these. It's the later which is where things would get more complicated as we'd have to make sure that the API and assocaited scene graph data is serialized. None of this is really complicated, but it's more complicated for end users than just being able to assume gl_ values are provided by default. > In fact, I think I prefer this latter solution, as it's more in the GL3 > flavor. GL3 does not have a modelview or projection matrix, and apps send to > shaders only whatever matrices they need, or none at all. GL3 might not have a modelview and projection matrix but the vast majority of scene graph applications will still need them, they exist for a good reason - they are darn useful. The OSG itself has special treatment of management of projection and modelview matrices as well, and I fully expect us to be using them in 20 years time except for very specific graphics solutions. > A callback > mechanism that notifies the app when an OSG matrix changes would allow the > app to perform different operations on the matrix and send down only the > data desired. Or apps could emulate the old GL1/2 modelview/projection > paradigm, if they choose to do so. I really don't think a callback would be at all useful in this context, it's really out of keeping with how matrices are currently managed, and would require specialist treatment by far more OSG users than should be required. Standard modelview and projection matrices should be part of the bedrock of what services the OSG provides end users, and should be done in consistent and standard way across GL versions. Performance wise we also want to avoid as many code indirections (such as if's and virtual functions) for very standard features. Now if users want to deviate from standard implementations and do there own funky matrix management then they could define their own uniforms for this. In the case with shaders the only the uniforms that are used by the shaders are bound, the rest are ignored, so if you didn't use the standard uniforms they wouldn't be bound and should safely be ignored. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
