[osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Chris Hanson]

I was mostly suggesting POCO in terms of all of the support code that it
provides for the parts outside the core scenegraph. But I understand that
that's not what you're focusing on right now.

On Thu, Jun 7, 2018 at 11:55 AM Robert Osfield <robert.osfield at gmail.com>
wrote:

> 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.
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>


-- 
Chris 'Xenon' Hanson, omo sanza lettere. Xenon at AlphaPixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Forensics • Imaging • UAVs • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
iPhone/iPad/iOS • Android
@alphapixel <https://twitter.com/alphapixel> facebook.com/alphapixel (775)
623-PIXL [7495]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20180607/e9d2fe91/attachment.html>