Hi Paul, On Wed, Oct 28, 2009 at 8:57 PM, Paul Martz <[email protected]> wrote: >> 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...?
No error, but the macro refers to glVertexPointer/glNormalPointer/glColorPointer. OpenGLES 2.0 has none of these, and I presume OpenGL 3.x is the same. I don't include the VertexAttrib arrays under the remite of the OSG_GL_VERTEX_ARRAY_FUNCS_AVAILABLE. I understand that this name could be confused to include VertexAttrib arrays, but I couldn't come up with a name that differentiated this. Suggestions welcome. >> 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. I have found that OpenGL ES 1.1 and 2.0 for the most part require disabling/avoiding old style gl calls, and have very few new functions, so I haven't need to come up with an new extension testing/setup. I would have though GL3 would be similar - should be for the most part just a case of including the GL3 header and then disabling/avoiding the functions that are no longer provided. > 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. Could you do another svn update as I've now checked in my changes to the node kits, these all now compile cleanly under OpenGL ES 1.1 and 2.0, and shouldn't hit upon the above issue if you disable the macros appropriately >> 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? Err... no.... that's what my next paragraph said... this is my task for tomorrow. > 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). I don't yet whether we'll need a seperate subclass of just hint in the GraphicsContext::Traits and/or #ifndef blocks. For EGL it's likely we'll need a completely different GraphicsWindow/PixelBuffer subclass, but for GL3 we might be able to get away with just a optional compile paths. >> 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. Right now for OpenGL ES 1.1 and 2.0 I've just disabled clip planes, initially for GL3 I'd suggest we do the same. Further down the line I expect we'll need to map the StateAttribute's like osg::ClipPlane to "OSG build-in" uniforms and have the positional state aspects for the uniform values managed correctly. To do this I'm expecting that we'll need to refine the way that osg::State and osg::StateAttribute's interact when they provide the uniforms for the GL3 and GLES2 targets. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
