[osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

Hi Chris,
On Thu, 7 Jun 2018 at 17:24, Chris Hanson <xenon at alphapixel.com> wrote:
> I would like to throw out the concept of using something like Conan.io ( https://conan.io/ ) to assist with 3rdparty package management.

For the current phase of work I don't plan to look at package
management, my current focus is on Vulkan, C++ and scene graph design.
Once we actually have a prototype scene graph to play with we can
start to think about ancillary issues.

For the initial work my aim is to only have C++11 and Vulkan as dependencies.

> I would like to do whatever is feasible to make this new scene graph more easily approachable by new developers, as I think it speeds adoption and spread. I applaud the idea of using things like language-core thread features and possibly existing platform libraries like BOOST or POCO to supply technologies that are already-invented. I think this will greatly simplify the codebase and reduce the potential for novel error.

I haven't seen any compelling reason to make Boost a dependency.
With C++11 there even less reason to think about Boost as all the most
valuable parts are parts are in C++.

I'm not familiar with with POCO, but a quick search online makes me
wonder why you suggested it.  It doesn't seem related to the core
issues scene graph design/implementation.

For something to be made of dependencies of the core VulkanSceneGraph
it will offer very significantly level of value to the core scene
graph.

> For example, Paul Martz, when he wrote a non-FFP scenegraph (called JAG https://github.com/pmartz/jag-3d/ ) a number of years ago, utilized BOOST, POCO and a math library named GMTL ( http://ggt.sourceforge.net/html/main.html ). JAG also had linkage to OSG, allowing it to use OSG to load a file, then a visitor to traverse the loaded graph and rewrite it into a JAG graph. OSG's support for Performer in the early days allowed this same sort of bootstrapping trick, I believe, until OSG had its own diversity of native loaders.
>
> Jeremy Moles' Heirograph scenegraph (GL3+, GLES2+ and prototype Vulkan support) used GLM ( https://glm.g-truc.net/0.9.9/index.html ) instead, because the syntax of the math library is exactly the same as GLSL's. Not sure if that's good or bad, but both those libraries are pretty bulletproof.

I did look at GMTL a long while back, and recently looked at GLM.
While I can see some value in GLM for some users it's a huge set of
code for what it is, or at least what we'd need from it for doing a
scene graph.

I strongly want to keep the scene graph small, coherent and focused,
not splurge all over the place with monster dependencies, each with
their own set of style/

> If you think looking at the Heirograph design would be helpful, I might be able to make that happen. The concept there was to have a modular API backend to potentially support GL3/4, GLES2/3 and Vulkan all on the same library platform. I don't know if that's relevant anymore, but I think the idea of decoupling the graph architecture from the graphics API backend driver is compelling in that it would help adapt to any future API evolutions as well, and could leave the door open to things like Apple's Metal, DirectX (Microsoft's Hololens / UWP currently only supports the DX platform for 3D), etc. And I think it's good abstractional architecture decoupling too.

Previously I've considered design and implementation issues of
supporting multiple API's in a scene graph and feel that it comprises
the design and complicates the implementation.

Vulkan is very different from OpenGL, it needs a different way of
managing things, it deserves a dedicated scene graph to make the most
of its capabilities without compromise.

Cheers,
Robert.