Robert Osfield wrote:
In the case of GL3 you'll want to set the following CMake vars:
OSG_GLU_AVAILABLE to OFF
OSG_GL1_AVAILABLE to OFF
OSG_GL2_AVAILABLE to OFF
OSG_GL3_AVAILABLE to ON
OSG_GLES1_AVAILABLE to OFF (default)
OSG_GLES2_AVAILABLE to OFF (default)
OSG_GL_DISPLAYLISTS_AVAILABLE to OFF
OSG_GL_MATRICES_AVAILABLE to OFF
OSG_GL_VERTEX_FUNCS_AVAILABLE to OFF
OSG_GL_VERTEX_ARRAY_FUNCS_AVAILABLE to OFF
?? I hope that's a cut and paste error. Vertex arrays are a part of GL3.
Or maybe this CPP macro controls use of the deprecated part of vertex
arrays: glVertexPointer, glNormalPointer, glPushClientAttrib,
glPopClientAttrib, etc...?
OSG_GL_FIXED_FUNCTION_AVAILABLE to OFF
You may well need to modify include/osg/GL to pick up on the GL3
header if it's different than gl.h.
I'll need to figure out what this means for OSG on Windows. (My OS X
system is GL 2.1, so I'm doing this dev on Windows.) I've done all my
GL3 development to date using GLEW to get the definitions. OSG has its
own GLEW-like solution. I'm not sure what this will mean for OSG on GL3
yet. But without GLEW, this is not just a simple drop-in-a-header change.
Also have a look at the osgvertexattributes example, as it enables the
aliasing of vertex attributes and projection/modelview projection
matrix uniforms. The aliasing also renames the shader variables
gl_Vertex/gl_Color/etc and gl_ProjectionMatrix/gl_ModelViewMatrix/etc.
to osg_ equivilant and adds in uniform/attribute declarations for
them, as well as populates the required for them.
osgViewer will also need mods to support the GL3 context.
I'm about to check in a series of mods to enable compilation of the
all the OSG NodeKit, utility libs (osgUtil, osgDB, osgGA) and the
plugins against OpenGLES 1.1 and OpenGLES 2.0. I haven't yet ported
osgViewer to work with EGL yet, osgViewer save for the
GraphicsWindow/PixelBuffer files all compile though.
OK. Currently I'm seeing build failures (with the GL3 setting) in osgFX
and osgParticle because they are using "glLoadMatrix" (sic: no 'd' or
'f' suffix), which is defined in the "GL" header but not for the GL3
case. Perhaps your latest mods will fix this. Not really a big deal, as
I'm not interested in the nodekits at the moment. Maximizing GL3
performance of OSG core is my primary concern.
Given how close OpenGL 3.x and OpenGLES 2.0 are in feature set I would
expect that it shouldn't require too many more changes to get things
compiling against OpenGL 3.x. What changes will be required should be
able to follow the approach I've taken for ES support. Thankfully the
OpenGL code hasn't become spaghetti code, at least so far... :-)
Do you have EGL context creation going yet? For GL3, I'm assuming I need
to derive a new class from GraphicsContext to use the GL3 context
creation syntax (or #defines in the existing GraphicsContext
specializations).
Once I get the EGL support added to osgViewer I'll be able to test
runtime against OpenGL ES 2.0, which will mark the testing, debugging
and learning process. I say learning process as doing without any the
fixed function pipeline and coding everything with shaders will be
interesting.
It's a great experience in plain GL3, but then I wasn't trying to adapt
a fixed-function-like layer over the top of OpenGL. I see what you mean
by "learning experience".
> The osgUtil::ShaderGen class will help a little (as the
osgvertexattributes example illustrates) but there is still a lot of
functionality that will be missing thanks to the lack of fixed
function pipeline.
Along these lines, I'm interested in looking at clip planes, which are
handled differently in GL3/GLSL1.30 than they were in GL2/GLSL1.20.
-Paul
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
