Re: [osg-users] recent changes to osg::Geometry
Hi Trajce, I spent good time to go through the archive looking for the announcement from Robert from time ago about the changes in osg::Geometry with no luck. And I don't mean the last one that now it is a regular osg::Node, but was something else, and I don't remember what was it. I believe those earlier changes were made around OSG 3.2 release. See http://www.openscenegraph.org/index.php/community/press-releases/143-openscenegraph-3-2-release . ... - Clean up of osg::Geometry class removing all deprecated slow path API's resulting in a smaller and faster Geometry class ... And were mainly related to VecArrays refactoring. Look for changes in array binding setup. Cheers, Wojtek Lewandowski ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] recent changes to osg::Geometry
Thanks Wojtek, yes, that is it. In very brief. Any clue what is making now osg::Geometry faster, what is the story behind? Thanks again! Nick On Fri, Sep 19, 2014 at 11:43 AM, Wojciech Lewandowski w.p.lewandow...@gmail.com wrote: Hi Trajce, I spent good time to go through the archive looking for the announcement from Robert from time ago about the changes in osg::Geometry with no luck. And I don't mean the last one that now it is a regular osg::Node, but was something else, and I don't remember what was it. I believe those earlier changes were made around OSG 3.2 release. See http://www.openscenegraph.org/index.php/community/press-releases/143-openscenegraph-3-2-release . ... - Clean up of osg::Geometry class removing all deprecated slow path API's resulting in a smaller and faster Geometry class ... And were mainly related to VecArrays refactoring. Look for changes in array binding setup. Cheers, Wojtek Lewandowski ___ 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
Re: [osg-users] recent changes to osg::Geometry
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
Re: [osg-users] recent changes to osg::Geometry
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
Re: [osg-users] recent changes to osg::Geometry
Hi Nick, On 19 September 2014 11:29, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: 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 The plugins have remained pretty well the same, just a few tweaks to the serializers for the refactor. If you are upgrading to a svn/trunk or dev release then you should be able to update the whole OSG and not worry about plugins - just pull them all in as well. Most of the plugins don't yet take advantage of the new changes of the Drawable subclassing from osg::Node, so they mostly all still create osg::Geode and attach the Drawables to it. These plugins could be optimized a little by removing the Geode where it isn't required but I haven't tackled this work. Others are welcome to pitch in. There are various other small tweaks to the OSG to help reduce the CPU overhead, so in general the the latest should just be all-round a better bet. Don't expect big performance changes though, it's just little improvements here and there. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] recent changes to osg::Geometry
Ok. I think I will definitely give it a try and see. Thanks again !!! Cheers, Nick On Fri, Sep 19, 2014 at 12:40 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Nick, On 19 September 2014 11:29, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: 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 The plugins have remained pretty well the same, just a few tweaks to the serializers for the refactor. If you are upgrading to a svn/trunk or dev release then you should be able to update the whole OSG and not worry about plugins - just pull them all in as well. Most of the plugins don't yet take advantage of the new changes of the Drawable subclassing from osg::Node, so they mostly all still create osg::Geode and attach the Drawables to it. These plugins could be optimized a little by removing the Geode where it isn't required but I haven't tackled this work. Others are welcome to pitch in. There are various other small tweaks to the OSG to help reduce the CPU overhead, so in general the the latest should just be all-round a better bet. Don't expect big performance changes though, it's just little improvements here and there. 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
