[osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

Tim Moore timoore33 at gmail.com
Thu Jun 21 00:24:54 PDT 2018


On Wed, Jun 20, 2018 at 8:14 AM, Robert Osfield <robert.osfield at gmail.com>
wrote:

> Hi Scott,
>
> On Wed, 20 Jun 2018 at 08:09, Scott Bailey <Bailey at insanegenius.org>
> wrote:
> > Wow is this ever good news!  I'm glad to see OSG will move into the
> future, albeit as VSG.  I'm especially excited to see modern c++ targeted.
> Personally, my preference is for c++14 if only for std::make_unique<>(),
> but I'll take c++11 any day!
>
> I guess there is chance I'll use std::unique_ptr<> and associated
> std::make_unique<>() at some point.  The scene graph itself will be
> managed using intrusive reference counting just like the OSG does for
> performance reasons, so I've prototyped equivalents of osg::ref_ptr<>
> and osg::Referenced for this purpose.  I guess one could also write a
> vsg::make_ref<> equivalent to std::make_unique<> if one so desired.
>
> Before you move on, the big advantage of std::shared_ptr over intrusive
reference counting is that support for weak pointers is rock solid. In the
intrusive model, you can't implement thread-safe weak pointers without an
auxiliary data structure, which complicates the implementation a lot. I
know that one historic OSG performance win for  osg::ref_ptr  was the
ability to not do the reference counting if it isn't needed, but with
atomic increment / decrement implemented everywhere, do you think there is
really much performance advantage for intrusive counting? Also,
std::make_shared<>() allocates the shared_ptr control block in the same
memory allocation as the shared object, so there need not be a memory
fragmentation hit for using shared_ptr.

Tim

> For now I'm wider design issues, doing experiments with more modern
> C++ along the way to see what is possible.  My general guide is that
> modern C++ features deployed needs to make the code easier to read and
> maintain than not using it, or provide significant flexibility/power
> that justifies any possible complexities in following the code.  So
> far so good on this count - I've been able to make the VSG equivalents
> of OSG much simpler thanks to modern C++ features.
>
> I won't make any decision on C++11 vs 14 vs 17 until the end of
> Exploration Phase.  If we can do everything we'll need with just C++11
> and there are few features of 14 and 17 that offer significant
> benefits then I'll likely just stick with C++11 for better backwards
> compatibility to older compilers.  The backwards compatibility with
> older compilers isn't a priority though, just something worth
> maintaining if it comes at no cost to the integrity/quality of the
> scene graph.
>
> I have to admit, I *really* like working with modern C++, looking back
> to some OSG code is bit painful now.  This isn't just C++ features
> though, my skills as programmer have slowly advanced over the years so
> now can spot better ways of solving problems.  Once VSG is established
> there may be a few areas of the OSG that could be updated to do
> similar things to what the VSG will do, though backwards compatibility
> for the OSG is crucial - it'll be a case of asking the question what
> can make OSG users lives better without risking breaking things.
>
> These possibilities are all a way off yet.  Through to the end of
> August I'll be just learning, thinking, experimenting with C++, Vulkan
> and ideas for improving scene graphs, and also getting OSG-3.6.2 out
> the door :-)
>
> Robert.
>
>
> >
> > If you haven't already seen it, check out the Magnum Graphics Engine.
> It's the only example I've found of anything close to a scene graph with a
> modern c++ interface.
> >
> > Best luck and Thanks!
> > SB
> > [/url]
> >
> > ------------------
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=74083#74083
> >
> >
> >
> >
> >
> > _______________________________________________
> > osg-users mailing list
> > osg-users at lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20180621/fa3a8ad0/attachment.html>


More information about the osg-users mailing list