Over the last few days I've been checking in significant implementation changes to osg::State and osg::Geometry to facilitate the OpenGL ES 2.0 port, these have all gone smoothly, and the nightly builds haven't yet complained. The changes I've been making don't change the public API or functionality of osg::Geometry, so client apps "should" all just compile and run exactly as before.
I say "should" as despite all the functional and performance testing I've been doing I can only cover a small portion of the type of app usage then OSG users can push it through, I also just have linux to compile against, and with so many internal changes to how data is dispatched to OpenGL there is a chance of regressions. Only testing out in the community will really stress test my changes, so could users please try out svn/trunk against their own apps. If you spot anything odd in behaviour or a performance regression please just shout and I'll get on to it as soon as possible. Other changes that are related to the changes in osg::State and osg::Geometry are the introduction of two helper classes osg::ArrayDispatchers and osg::GLBeginEndAdapter. ArrayDispatchers is primarily used in osg::Geometry to encapsulate the task of dispatching osg::Array data as OpenGL attributes, and includes support for automatically remapping glVertex,glColor, glNormal etc calls to glVertexAttrib equivalents - something that is required for both OpenGL ES 2.0 and OpenGL 3.0. osg::GLBeginEndAdapter is also used in osg::Geometry to dynamically replace all glBegin/glEnd usage with vertex arrays/vertex attirb arrays, this is required for OpenGL ES 2.0, OpenGL 3.0 and OpenGL ES 1.x as these don't support the old OpenGL slow paths. The OSG also had glBegin/glEnd usage in osgText, osgSim and osgParticle NodeKits, so these now have all their glBegin/glEnd code replaced by the usage of the GLBeginEndAdapter. Functionally and API wise these NodeKits are essentially unchanged save for some minor changes to osg::Particle that are just related to the implementation. These changes are really about making a smooth transition between different OpenGL targets, both for the OSG code base and client apps. The changes also minimize the amount of separate code paths we'll need for the different OpenGL targets, so we'll all be sharing the majority of the OSG code base no matter what platform you target, which in turn means we'll all be sharing the task of testing, debugging and optimizing - improvements for one target will benefit the others. The public interface for the OSG will also be pretty consistent across the different targets so less of your application code will need to be OpenGL target specific. So what to take away from all this? The internal implementation of how geometry data is dispatched to OpenGL is now done with almost completely new code, but the public interfaces have not changed in any way that should break the build of client apps. Functionally the new code is the same - it achieves the same result just with different, and more flexible and future proofed, code paths. If I've done my job well we'll see few regressions due to these changes. Fingers crossed we won't see any ;-) Robert. ps. Hopefully you'll find the new code in osg::Geometry::drawImplementation() more readable and efficient too :-) _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
