Hi Robert, thanks a lot for the detailed info. I was following the user list but was somehow moving the upgrade to the latest from the trunk to some better days, and these days are now :-).
I understand now the changes, just reading the code now and comparing it to some older version. I have another question. Are these changes reflected into the plugins like OpenFlight, ive, osgb? The real problem I am facing is the performance of a system already installed on a site and if there is a way to improve them just by upgrading OSG. or I have to touch the mentioned plugins as well. Probably the most important is the OpenFlight plugin Thanks again ! Nick On Fri, Sep 19, 2014 at 12:03 PM, Robert Osfield <robert.osfi...@gmail.com> wrote: > HI Nick, > > On 19 September 2014 10:47, Trajce Nikolov NICK < > trajce.nikolov.n...@gmail.com> wrote: > >> yes, that is it. In very brief. Any clue what is making now osg::Geometry >> faster, what is the story behind? >> > > The changes to osg::Geometry in 3.2 relate to removal of the code paths > that handle the cases where index arrays where used, even when not used > this added an small overhead to each osg::Geometry call when display lists > weren't used. These changes distil osg::Geometry down to just supporting > OpenGL fast paths. For most end users there won't need to be any changes > as they shouldn't have been using index arrays as they have been deprecated > slow paths for many years. To support this change the osg::Array has > already been re-factored a little to now contain things like binding > information directly with the osg::Array rather than as part of > osg::Geometry. > > In svn/trunk and the OSG-3.3.x dev releases there are further changes to > osg::Drawable that relate to change it to subclass from osg::Node rather > than osg::Object. This change also brought about unification and > generalization of the Callback. Now that Drawable is a Node you no longer > need an osg::Geode to attach a Drawable to the scene graph, this makes a > little simpler to create scene graphs, and reduces the number of nodes in > the scene graph which which can help cut down CPU overhead of cull > traversal. > > All of these changes have been done in a way that retains backwards > compatibility as far as possible, so most applications won't notice a > difference when compiling their OSG apps. The small improvements to > performance are unlikely to be noticeable without accurate time stats. > Together these changes are all about slowly cleaning up the OSG API and > making more efficient and flexible. > > Robert. > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > -- trajce nikolov nick
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
