<div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 7, 2018 at 11:55 AM Robert Osfield <<a href="mailto:robert.osfield@gmail.com">robert.osfield@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Chris,<br>
On Thu, 7 Jun 2018 at 17:24, Chris Hanson <<a href="mailto:xenon@alphapixel.com" target="_blank">xenon@alphapixel.com</a>> wrote:<br>
> I would like to throw out the concept of using something like Conan.io ( <a href="https://conan.io/" rel="noreferrer" target="_blank">https://conan.io/</a> ) to assist with 3rdparty package management.<br>
<br>
For the current phase of work I don't plan to look at package<br>
management, my current focus is on Vulkan, C++ and scene graph design.<br>
Once we actually have a prototype scene graph to play with we can<br>
start to think about ancillary issues.<br>
<br>
For the initial work my aim is to only have C++11 and Vulkan as dependencies.<br>
<br>
> 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.<br>
<br>
I haven't seen any compelling reason to make Boost a dependency.<br>
With C++11 there even less reason to think about Boost as all the most<br>
valuable parts are parts are in C++.<br>
<br>
I'm not familiar with with POCO, but a quick search online makes me<br>
wonder why you suggested it.  It doesn't seem related to the core<br>
issues scene graph design/implementation.<br>
<br>
For something to be made of dependencies of the core VulkanSceneGraph<br>
it will offer very significantly level of value to the core scene<br>
graph.<br>
<br>
> For example, Paul Martz, when he wrote a non-FFP scenegraph (called JAG <a href="https://github.com/pmartz/jag-3d/" rel="noreferrer" target="_blank">https://github.com/pmartz/jag-3d/</a> ) a number of years ago, utilized BOOST, POCO and a math library named GMTL ( <a href="http://ggt.sourceforge.net/html/main.html" rel="noreferrer" target="_blank">http://ggt.sourceforge.net/html/main.html</a> ). 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.<br>
><br>
> Jeremy Moles' Heirograph scenegraph (GL3+, GLES2+ and prototype Vulkan support) used GLM ( <a href="https://glm.g-truc.net/0.9.9/index.html" rel="noreferrer" target="_blank">https://glm.g-truc.net/0.9.9/index.html</a> ) 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.<br>
<br>
I did look at GMTL a long while back, and recently looked at GLM.<br>
While I can see some value in GLM for some users it's a huge set of<br>
code for what it is, or at least what we'd need from it for doing a<br>
scene graph.<br>
<br>
I strongly want to keep the scene graph small, coherent and focused,<br>
not splurge all over the place with monster dependencies, each with<br>
their own set of style/<br>
<br>
> 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.<br>
<br>
Previously I've considered design and implementation issues of<br>
supporting multiple API's in a scene graph and feel that it comprises<br>
the design and complicates the implementation.<br>
<br>
Vulkan is very different from OpenGL, it needs a different way of<br>
managing things, it deserves a dedicated scene graph to make the most<br>
of its capabilities without compromise.<br>
<br>
Cheers,<br>
Robert.<br>
_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div style="text-align:center">Chris 'Xenon' Hanson, omo sanza lettere. Xenon@AlphaPixel.com <a href="http://www.alphapixel.com/" target="_blank">http://www.alphapixel.com/</a></div><div style="text-align:center">Training • Consulting • Contracting</div><div style="text-align:center">3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL</div><div style="text-align:center"><span style="font-size:12.8000001907349px">Legal/IP •</span><span style="font-size:12.8000001907349px"> </span><span style="font-size:12.8000001907349px">Forensics •</span><span style="font-size:12.8000001907349px"> </span>Imaging <span style="font-size:12.8px">•</span><span style="font-size:12.8px"> </span><span style="font-size:12.8px">UAVs </span><span style="font-size:12.8px">• GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile • iPhone/iPad/iOS • Android</span></div><div style="text-align:center"><a href="https://twitter.com/alphapixel" target="_blank">@alphapixel</a> <a href="http://facebook.com/alphapixel" target="_blank">facebook.com/alphapixel</a> (775) 623-PIXL [7495]<br></div></div></div></div></div></div>