Robert Osfield wrote:
Hi Guys,
I've been on holiday during this thread, so now just catching up...
some brief thoughts on some of the points raised.
Thanks for adding to the thread, Robert. I hope your holiday was enjoyable.
First up, modelview and projection matrices are something that the OSG
can pass to GL3/OpenGLES2 by assigning a standard uniform to each of
these matrices and then having
osg::State::applyModelViewMatrix(RefMatrix*) and
osg::State::applyProjectionMatrix(RefMatrix*) set these uniforms
automatically. This will isolate the required changes to just
osg::State. I'd suggest that these uniforms target the standard
gl_ProjectionMatrix and gl_ModelViewMatrix uniform names for
consistency with GL2.
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.
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.
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. 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.
-Paul
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
