[osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Chris Hanson]

I'm going to avoid discussing header extensions, because it's a dead dog. I
will say, that more tools and processes than just VS rely on file
extensions.

I would like to throw out the concept of using something like Conan.io (
https://conan.io/ ) to assist with 3rdparty package management.

As we all know, OSG's breadth of appetite for third-party dependencies has
made it daunting for people to build throughout history, and I'm sure that
while VSG will be narrower in scope, it will still have the same issue.

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.

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 am excited to look at the potential of bringing other OSG nodekits and
tools to VSG.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20180607/b5680ecc/attachment.html>