Hi Paul,
Hi J-S -- Good discussion. Thanks for responding to my OSG BOF pleas to
start discussing GL3 in osg-users. :-)
Heh, I think this kind of discussion is long overdue... OpenGL 3.0 has
been out for a year after all. :-)
I have the start of a NodeVisitor that will change all Geometry classes
to use generic vertex attributes, as well as switch DLs to buffer
objects. See below. I can also set uniform matrix values for the view
and projection matrices in the app main loop.
While this is certainly an incomplete solution, it does allow me to use
GLSL 1.30 shaders without any deprecated functionality. I currently have
a GL3-safe cow running, doing all the transforms, lighting, and texture
coord generation in GLSL 1.30 shaders. (One major piece of missing
functionality is support for any model transforms buried in the scene
graph. But it's a start.)
That's a good start, though it assumes vertices and normals will always
be present and will always go in positions 0 and 1 (that's why you're
discussing attribute array names with Robert in another thread, I realize).
You could also place vertex colors in attribute position 2. You could
probably also check if a texture is currently bound to unit 0+i and then
set texcoords from unit 0+i to attrib position 3+i, etc.
I bet it wouldn't be too hard to add apply(osg::Camera& camera) that
would set view and projection matrix uniforms, as well as
apply(osg::Transform& transform) for the current local-to-world matrix
(and perhaps uniforms for model*view, model*view*projection for
convenience).
Then later we could even extend the visitor so that at each node, it
accumulates and checks all state and sets uniforms for the
StateAttributes we're interested in.
Ideally, OSG apps should not need to change at all to be compatible with
GL3. However, at this point, it's too early to tell whether this will be
the case or not. With that in mind, I feel that exploring ways for
applications to use OSG in a GL3-safe way is a worthwhile endeavor,
especially for new app development. If there are ways for apps to take
responsibility for using vertex attribs and setting their own uniforms,
we need to research this and make the methods known, so that new
development can use these techniques and avoid any porting headaches
that might otherwise arise in the future.
Well I think for the basic functionality (vertex positions, normals,
vertex colors, texcoords and the normal matrices) an app should not have
to change other than modifying its shaders to use new names. OSG is
after all a rendering library, so I think we can assume most apps will
use this functionality as a bare minimum.
After that we can decide whether we want to keep the current wrapping of
fixed-pipeline state (for example osg::Fog) and have it set uniforms
when needed (say int osg_Fog_Type --> FOG_LINEAR, FOG_EXP, FOG_EXP2
which could be defines; float osg_Fog_start, float osg_Fog_end, float
osg_Fog_density, vec4 osg_Fog_color for example), or if we want to do it
some other way. I don't know in what way, but perhaps someone will think
of some more elegant way.
Since GLSL allows you to define your own structs, perhaps we could do
something similar to what GLSL 1.2 did, instead of the above. Something
like:
struct osg_FogParameters { // From glsl_quickref.pdf, s/gl_/osg_/
vec4 color;
float density;
float start;
float end;
float scale;
};
uniform osg_FogParameters osg_Fog;
...
...
vec4 fogColor = osg_Fog.color;
...
...
But as I said above, perhaps someone will have a better idea, as this
would just basically re-do all the features that GL3 removed...
So I think we have to answer a basic question before we do any actual
work: Do we want OSG to be like it was before, and basically become a
GL2 layer over GL3? That would make it easier to use than straight GL3
for beginners, I think, but it would make OpenGL programming less
hands-on than straight GL3. Of course, if we do it right we can still
expose all the GL3 code paths through a thin layer like was done for
GL2, so people who wanted to use all the freedom and generality of GL3
could still do so. But OSG would become a good solution for people who
wanted an easier way of doing graphics programming than the "programming
without a safety net" model that GL3 offers. I personally think this is
a great opportunity for OSG to position itself as a great solution that
offers all the power of OpenGL 3 but with a gentler learning curve.
What do you think?
J-S
--
______________________________________________________
Jean-Sebastien Guay [email protected]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
