OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

Announcement: VulkanSceneGraph and SceneGraphTestBed!

Goto page Previous  1, 2, 3, 4  Next
 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12131

PostPosted: Tue Jun 05, 2018 8:23 pm    Post subject:
Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

On 5 June 2018 at 19:51, Andrew Cunningham <> wrote:
Quote:
Great news and very timely given Apple’s just announced decision to deprecate OpenGL....

Apple are behaving like complete ***** that don't give a shit about developers.

It's time users stopped putting up with this crap and just dumped
Apple products.

I really couldn't have less respect for Apple's conduct over the
years, it's even worse than Microsoft. There was promise in Apple
many years ago. They got too big and too greedy. Us developers are
just bugs on the wind-shield. For those who want to stay on the Apple
"freeway" expect to get squished.

For me, my focus in open platforms, if users can add support for Apple
and avoid us having to jump through many hoops to do so then feel
free, but please don't expect me to go a long way out of my way to
support a platform that is so abusive towards developers.

Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
ravidavi
User


Joined: 06 Nov 2015
Posts: 48

PostPosted: Tue Jun 05, 2018 8:43 pm    Post subject:
Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

I've been using Macs and developing on MacOS for over 25 years now, but still I gotta say I completely understand your frustration Robert. My past two computers have been Windows laptops, which is also the first time I've bought non-Mac hardware, mainly because Apple doesn't seem to care about VR (which has been important to me recently).

Nevertheless, supporting MacOS alongside Windows & Linux is a necessity in my field (aerospace). It looks like Vulkan will be available on OSX, even if it's without Apple's official support. Once VulkanSceneGraph gets going, I'll do my bit to help with Mac support.


Ravi

On Tue, Jun 5, 2018 at 4:23 PM, Robert Osfield < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
On 5 June 2018 at 19:51, Andrew Cunningham < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
Great news and very timely given Apple’s just announced decision to deprecate OpenGL....

Apple are behaving like complete ***** that don't give a shit about developers.

It's time users stopped putting up with this crap and just dumped
Apple products.

I really couldn't have less respect for Apple's conduct over the
years, it's even worse than Microsoft.  There was promise in Apple
many years ago.  They got too big and too greedy.  Us developers are
just bugs on the wind-shield.  For those who want to stay on the Apple
"freeway" expect to get squished.

For me, my focus in open platforms, if users can add support for Apple
and avoid us having to jump through many hoops to do so then feel
free, but please don't expect me to go a long way out of my way to
support a platform that is so abusive towards developers.

Robert.
_______________________________________________
osg-users mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12131

PostPosted: Wed Jun 06, 2018 9:29 am    Post subject:
Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

On 5 June 2018 at 21:42, Ravi Mathur <> wrote:
Quote:
Nevertheless, supporting MacOS alongside Windows & Linux is a necessity in
my field (aerospace). It looks like Vulkan will be available on OSX, even if
it's without Apple's official support. Once VulkanSceneGraph gets going,
I'll do my bit to help with Mac support.

Thanks for the offer. I'm hoping that Mac support won't be a huge effort.

VulkanSceneGraph on Mac will offer a path long term for existing
OpenSceneGraph users, but migrating to a new scene graph is now small
matter, even one that's has the same lead's paw prints all over it.
For existing OpenSceneGraph users under Mac having a 3rd party
OpenGL/OpenGLES -> Metal library might be the way forward.

For the rest of the platforms life should be a bit easier, OpenGL will
remain supported, so use of OpenSceneGraph will remain problem free.
Users can then port to VulkanSceneGraph if and when they choose.

Quote:
From my perspective I'm just going to keep focused on making the
VulkanSceneGraph a compelling scene graph, and maintaining the
OpenSceneGraph so it's a solid base for existing users. My focus on
cross platform portability will not be explicit focus, instead it'll
just fall out from just not doing things in a platform specific way,
i.e. just stick to C++11 (or later), Vulkan and cross platform build
tools and well, basically, you are 90% the way there on the
portability front.

Cheers,
Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
bbjorn
Appreciator


Joined: 12 Oct 2010
Posts: 219
Location: Linköping, Sweden

PostPosted: Thu Jun 07, 2018 7:49 am    Post subject:
Reply with quote

Hi Robert,

Very exciting news!

I do not have any strong opinions on the Vulcan parts. But I do have some wishes since this project is starting from scratch:

1. Use modern CMake - this will make the project much easier to use.

2. Minimize external dependencies - Preferably the project should be able to be used without any external dependencies included at all.

3. Try to follow the ISO-cpp guidelines as close as possible - This will ensure a consistent style when used together with other modern c++ programs. This will also help when using static code analysis tools.
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md


And maybe this time we will get header files with the .h extension. Wink

Best regards,
Björn
Back to top
View user's profile Send private message Visit poster's website
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12131

PostPosted: Thu Jun 07, 2018 9:21 am    Post subject:
Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

On Thu, 7 Jun 2018 at 08:49, Björn Blissing <> wrote:
Quote:
1. Use modern CMake - this will make the project much easier to use.

Modern CMake and xmake are on the short list.

Quote:
2. Minimize external dependencies - Preferably the project should be able to be used without any external dependencies included at all.

C++11 and Vulkan are the only current planned non optional
dependencies (apart form the build tools :-)

I don't know yet whether we should have loaders within the core
VulkanSceneGraph project or outside in additional
libraries/frameworks, it's the loaders that cause the 3rd party
dependency issues.

Quote:
3. Try to follow the ISO-cpp guidelines as close as possible - This will ensure a consistent style when used together with other modern c++ programs. This will also help when using static code analysis tools.
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md

Heh... I just so happened that to the list of 3rd party resources
that I'm referencing this morning.

Quote:
And maybe this time we will get header files with the .h extension. Wink

Maybe, no decisions made yet, but I'm also not polling for opinions,
the VulkanSceneGraph isn't a design by committee.

My initial code experiments have .hpp but frankly it's ugly as hell as
well as stupid - there's no header plus plus language so I'm rapidly
tiring of .hpp. Code should to be a thing of beauty not some ugly
kludge. .h makes sense as it's a header, .cpp makes sense for source
files as it's C++. However, public headers are placed into include
directories and that's their role, we know they are headers because
that's why we put them there, so the .h should be superfluous for
public headers and the standard C++ headers illustrate this. If 3rd
party tools/editors can't even handle the extension less C++ standard
library headers then they aren't really up to the job.

Cheers,
Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
bbjorn
Appreciator


Joined: 12 Oct 2010
Posts: 219
Location: Linköping, Sweden

PostPosted: Thu Jun 07, 2018 9:31 am    Post subject:
Re: Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

robertosfield wrote:

Quote:
And maybe this time we will get header files with the .h extension. Wink

Maybe, no decisions made yet, but I'm also not polling for opinions,
the VulkanSceneGraph isn't a design by committee.

My initial code experiments have .hpp but frankly it's ugly as hell as
well as stupid - there's no header plus plus language so I'm rapidly
tiring of .hpp. Code should to be a thing of beauty not some ugly
kludge. .h makes sense as it's a header, .cpp makes sense for source
files as it's C++.


The ISO cpp guidelines recommend using .h for headers and .cpp for source:
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rs-file-suffix

robertosfield wrote:
However, public headers are placed into include
directories and that's their role, we know they are headers because
that's why we put them there, so the .h should be superfluous for
public headers and the standard C++ headers illustrate this. If 3rd
party tools/editors can't even handle the extension less C++ standard
library headers then they aren't really up to the job.


As a Visual Studio user I do disagree (since Visual Studio really seems to dislike extensionless headers). But I also recognize that the decision is your prerogative to make as creator.

Regards,
Björn
Back to top
View user's profile Send private message Visit poster's website
kornerr
Appreciator


Joined: 01 Oct 2013
Posts: 280

PostPosted: Thu Jun 07, 2018 10:28 am    Post subject:
Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

Since we're talking about standard proposals now, here are some I would want:

1. Provide an option of single header and source file per each module:
vsg.h/cpp, vsgViewer.h/cpp, vsgUtil.h/cpp, etc.

This would greatly simplify referencing VSG across platforms because
CMake has issues under Android (it's part of Android Studio project,
so CMake does not drive building) and iOS (one can build a library
with CMake to be referenced by Xcode project).
So, simple header/source inclusion still wins distribution battle when
you target desktop, mobile, and web at the same time.

2. Conform to `Best Practices Criteria for Free/Libre and Open Source
Software (FLOSS)`
The rules: https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md
Here's how a conforming project looks like:
https://bestpractices.coreinfrastructure.org/ru/projects/289


On 7 June 2018 at 12:32, Björn Blissing <> wrote:
Quote:

robertosfield wrote:
Quote:


Quote:
And maybe this time we will get header files with the .h extension. ;)


Maybe, no decisions made yet, but I'm also not polling for opinions,
the VulkanSceneGraph isn't a design by committee.

My initial code experiments have .hpp but frankly it's ugly as hell as
well as stupid - there's no header plus plus language so I'm rapidly
tiring of .hpp. Code should to be a thing of beauty not some ugly
kludge. .h makes sense as it's a header, .cpp makes sense for source
files as it's C++.


The ISO cpp guidelines recommend using .h for headers and .cpp for source:
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rs-file-suffix


robertosfield wrote:
Quote:
However, public headers are placed into include
directories and that's their role, we know they are headers because
that's why we put them there, so the .h should be superfluous for
public headers and the standard C++ headers illustrate this. If 3rd
party tools/editors can't even handle the extension less C++ standard
library headers then they aren't really up to the job.



As a Visual Studio user I do disagree (since Visual Studio really seems to dislike extensionless headers). But I also recognize that the decision is your prerogative to make as creator.

Regards,
Björn

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73993#73993








------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12131

PostPosted: Thu Jun 07, 2018 10:29 am    Post subject:
Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

On Thu, 7 Jun 2018 at 10:32, Björn Blissing <> wrote:
Quote:
The ISO cpp guidelines recommend using .h for headers and .cpp for source:
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rs-file-suffix

So use .h unless you want to maintain consistency with existing
projects... I don't know such as the Standard C++ headers or
OpenSceneGraph headers....

For the OpenSceneGraph, the VulkanSceneGraph I aspire to be a Stardard
C++ library for real-time graphics.

Quote:
As a Visual Studio user I do disagree (since Visual Studio really seems to dislike extensionless headers). But I also recognize that the decision is your prerogative to make as creator.

Really the answer is pretty simple, Visual Studio clearly isn't up to
the job... the fact that MS haven't yet fixed this in over two decades
doesn't validate that it's not broken. MS over the years has tried
hard to make C++ a pain in the butt to use under Windows. I can't fix
what MS choose to do, but also have no desire for bugs in 3rd party
tools to dictate decisions on code I personally write, I want code
that aspires to something more than lowest common denominators.

Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12131

PostPosted: Thu Jun 07, 2018 10:46 am    Post subject:
Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

On Thu, 7 Jun 2018 at 11:28, michael kapelko <> wrote:
Quote:
Since we're talking about standard proposals now, here are some I would want:

No we aren't, I didn't start this thread to debate with the community
the pros and cons of every decisions. I made the original an
announcement that project is under-way and that the initial phase will
be mostly done privately.

If there are questions people have and I can provide some clarity at
this stage then I'm happy to do so. However, VulkanSceneGraph isn't a
design by committee. I'm not looking to debate stuff.

Once the project comes out of the Exploration Phase and into the
Implementation Phase I'll have a clearer direction, will publish a
design document and likely have some code to share.

The community will need to trust me on this stuff during this less
public phase of project work. I'm an experienced open source project
lead, I have witnessed all the trials and tribulations that the
OpenSceneGraph users have in developing graphics application for
nearly two decades. All this experience informs my decisions. My
goal is to VulkanSceneGraph a thing of beauty and practicality.

Cheers,
Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
bbjorn
Appreciator


Joined: 12 Oct 2010
Posts: 219
Location: Linköping, Sweden

PostPosted: Thu Jun 07, 2018 11:05 am    Post subject:
Re: Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

robertosfield wrote:

For the OpenSceneGraph, the VulkanSceneGraph I aspire to be a Stardard
C++ library for real-time graphics.


In my mind (and I also think the general convention is that) the extensionless headers are reserved for libraries accepted into the std by the ISO committee. Before that they should stick to .h or .hpp. This is also the process that the libraries which originated in boost use, i.e. they used .hpp while being part of boost and then removed the extension once they were accepted by the ISO committee.

The boost FAQ answers the question like this:
Why do Boost headers have a .hpp suffix rather than .h or none at all?
File extensions communicate the "type" of the file, both to humans and to computer programs. The '.h' extension is used for C header files, and therefore communicates the wrong thing about C++ header files. Using no extension communicates nothing and forces inspection of file contents to determine type. Using '.hpp' unambiguously identifies it as C++ header file, and works well in actual practice.

robertosfield wrote:
Really the answer is pretty simple, Visual Studio clearly isn't up to the job... the fact that MS haven't yet fixed this in over two decades doesn't validate that it's not broken. MS over the years has tried hard to make C++ a pain in the butt to use under Windows. I can't fix
what MS choose to do, but also have no desire for bugs in 3rd party tools to dictate decisions on code I personally write, I want code that aspires to something more than lowest common denominators.


Well, Visual Studio is not the only IDE with these types of problems with extensionless headers. Other IDEs and other tools suffer the same problem. So the assumption that extensionless headers are reserved for ISO standardized libraries seems to be persistent outside MS as well.

Also simple file pattern matching in the console is much simpler when the header do have a file suffix.

So in my mind these are reasons enough to stick to headers with some form of standard file extension, at least if beauty and future aspirations are the only counter arguments.

But once again, the decision is up to you. And we Visual studio developers will adapt and overcome, as we always have done. Smile

Best regards,
Björn
Back to top
View user's profile Send private message Visit poster's website
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12131

PostPosted: Thu Jun 07, 2018 1:52 pm    Post subject:
Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

Hi Björn,

I've heard all these points before, didn't find them convincing in the
early days of the OSG and still don't. Given the same set of facts I
simply have a different opinion on how we should weight them.
Repeating points 100 times won't magically tip the balance, it's just
makes me fed up with tedious and pointless discussion that I never
invited.

I don't wish to dictate to others what they should do with their own code.

When it come to writing my own code it's my own judgement that I use.

It really is that simple.

Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Chris Hanson
Guest





PostPosted: Thu Jun 07, 2018 4:24 pm    Post subject:
Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

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.

------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12131

PostPosted: Thu Jun 07, 2018 5:55 pm    Post subject:
Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

Hi Chris,
On Thu, 7 Jun 2018 at 17:24, Chris Hanson <> wrote:
Quote:
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.

Quote:
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.

Quote:
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/

Quote:
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.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12131

PostPosted: Thu Jun 07, 2018 7:02 pm    Post subject:
Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

Hi Chris,
On Thu, 7 Jun 2018 at 18:54, Robert Osfield <> wrote:
Quote:
Quote:
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 creating a list of resources that I can use as references. Do you
have a link to Jeremy's project?

Thanks,
Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Chris Hanson
Guest





PostPosted: Thu Jun 07, 2018 9:20 pm    Post subject:
Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

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 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:

Quote:
Hi Chris,
On Thu, 7 Jun 2018 at 17:24, Chris Hanson < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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.

Quote:
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.

Quote:
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/

Quote:
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
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



--
Chris 'Xenon' Hanson, omo sanza lettere. 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 facebook.com/alphapixel (775) 623-PIXL [7495]

------------------
Post generated by Mail2Forum
Back to top
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Goto page Previous  1, 2, 3, 4  Next
Page 2 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts The naming of VulkanSceneGraph Chris Hanson General 21 Thu Jun 21, 2018 2:58 pm View latest post
No new posts EXTERNAL: Announcement: VulkanSceneGr... Rowley, Marlin R General 0 Mon Jun 04, 2018 3:00 pm View latest post
No new posts Announcement: OpenGL ES 2.0 port unde... robertosfield General 1 Mon Oct 05, 2009 4:04 pm View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP