[osg-users] Porting application from OSG 3.0 to OSG 3.6

Robert Osfield robert.osfield at gmail.com
Fri Oct 26 04:24:38 PDT 2018

Hi Daniel,

On Fri, 26 Oct 2018 at 11:30, Daniel Trstenjak <daniel.trstenjak at gmail.com>

> Looking at the 'NEWS.txt' I could only find one obvious one:
> - removing slow path API from osg::Geometry (OSG 3.2)
> Are there any other major breaking changes I should be aware of?

There is 7 years of work between 3.0 and 3.6, too much work to recall
everything in detail  - the NEWS will the enumerate the major changes, and
CHANGELOG will enumerate every single commit.

What is important totally depends upon what parts of the OSG you use.  I
might be that none of the API you rely upon has changed so just a recompile
will be needed, conversely you could be using deprecated features that have
now been removed.  In general public interfaces are less likely to change
that internal implementation details.  Also changes to public interfaces
generally happen only when the old interface is causing problems/limiting

There only way you can work out where you stand with your application is
try a build and see what happens.  If there are errors just post what
issues you are having and we can try and point your in the right
direction.  If the number of issues you are seeing is too many to deal with
at once try porting to 3.2, then 3.4 then to 3.6.

In the case when you remove deprecated functionality, often the new code
will still work with older versions as well as the newer ones.  In cases
where there is divergence in how one can support different OSG versions you
can use the macros in include/osg/Version to help select the approach code
path for the version of OSG you are presently compiling against.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20181026/b3ad870d/attachment.html>

More information about the osg-users mailing list