[osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!
Robert Osfield
I am delighted to say that today I began work on VulkanSceneGraph, an
all new scene graph that builds upon Vulkan and modern C++. This new
project can be thought of a new family member, the child of
OpenSceneGraph project. As it's a family member I've created the
project repository alongside the OpenSceneGraph within the github
openscenegraph account:
https://github.com/openscenegraph/VulkanSceneGraph
Please have a read through the README.md on the above repo as this
will explain a little about the project and where my focus will be for
the next three months work wise conducting an Exploration Phase to
scope out the technology and techniques that will go into project once
we start coding the scene graph itself.
This new project will co-exist with the OpenSceneGraph for years to
come. I will remain as project lead of the OpenSceneGraph, I will fix
bugs, push out releases, generally chase everybody to test things and
also help out with general support here - continue to do what I've
done for nearly two decades. Like OpenGL the OpenSceneGraph is still
relevant to many application developers and I expect it to remain a
corner stone of many application for years to come. Both OpenGL and
OpenSceneGraph are very mature bits of software now so there isn't a
need to keep pushing hard on new features, so I planning for a stable
period when maintenance is increasingly the focus rather new new bells
and whistles.
You no doubt will have lots of questions, but at this point I can't
provide too many answers on the technical front as we are so early in
the project the technical details are yet to solidified - this is what
my next three months work will be all about. I'll be learning
everything I can about Vulkan, working out how best to encapsulate
it's features them in a scene graph.
I also will be looking into what features of modern C++ can bring to
the table to make our lives as graphics developers easier and more
productive, C++11, 14 and 17 are all under consideration.
There also all the scene graph design elements that have been bubbling
around in my head for the last five years that I'd like to try out to
see what might be possible.
Once this Exploration Phase is complete I will have a more concrete
idea of what needs to be done next and will write a design document to
share with the community to give everyone a clearer idea of where we
are going next. During this phase I will spend most of my time
working quietly away learning, testing, thinking, learning, testing,
thinking. It's not a period that I am looking for lots of external
input on, the best software designs don't come from committees but
from a coherent and calm contemplation. I guess I need to go find
myself a mediation rock on Skellig Michael :-)
If you are keen to help out VulkanSceneGraph then this is something
you can help out with right away, without needing me to complete any
design docs or to publish any code. What all good software needs
during development and through into maintenance phase are unit tests
that test features and performance. To this end I can created a new
SceneGraphTestBed repository to collect together in one place a set of
data and test programs that we can run to test out features and
performance of both the OpenSceneGraph and the VulkanSceneGraph once
it starts becoming usable.
https://github.com/openscenegraph/SceneGraphTestBed
I don't have any data or test programs written at this point, so this
repo is an empty room waiting to be filled. My thought is that we
would initially just create OpenSceneGraph based test data and
programs that test various features and performance of the
OpenSceneGraph. If you have a particular tests that illustrate the
problems areas that you have in performance, or things that are
awkward to implement but shouldn't be then you could submit this as
unit tests that stress the OpenSceneGraph.
As the VulkanSceneGraph project evolves we tackle recreating these
OpenSceneGraph test programs using the new scene graph and the have an
ability to compare OpenGL/OpenSceneGraph with Vulkan/VulkanSceneGraph,
as well as have a set of unit tests that we can run prior to each
release of the OpenScenGraph or VulkanSceneGraph.
I don't have any specific plans of how to layout or manage the
SceneGraphTestBed, if you feel like it's something you'd like to pick
up the lead on then let us know - I'm already have plenty to juggle
myself so being able to let others manage sub projects is great way of
helping us all be as productive as we can be.
Thanks for your support and patience - cause I know we all want it yesterday!
Robert Osfield
Newly minted VulkanSceneGraph Project Lead :-)
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Paweł Księżopolski
I am pleased to hear that you decided to move into the Vulkan development.
Creating VirtualSceneGraph may shape graphics development for
many years to come.
It may have great impact on open source projects, because in my opinion
the current state of Vulkan open source development is rather weak.
Few game engines implemented its Vulkan backend ( and I suppose
that none of them uses Vulkan to its full potential ),
there are few small game engines made by hobbyists/students with
very narrow objectives in mind, lots of better or worse demos
showing how some Vulkan features work, plentitude of tutorials showing
how to draw a single triangle and that's all. But there is certainly lack of
universal, feature full industry quality graphics library similar to
OpenSceneGraph for OpenGL.
Eleven years ago I started working as a graphics developer using
OpenSceneGraph everyday in my professional career. I took part
in a few significant industry scale projects and made
few submissions to OpenSceneGraph, with the most important
one beeing the osggpucull example.
With that example I wanted to start a discussion about how to implement
new features from OpenGL, that didn't fit well into OpenSceneGraph
architecture, but it looked like there was no demand for it at the time.
When Vulkan came out I decided to start my own project in which
I try to use many good ideas from software I used for years
and combine it with Vulkan architecture :
https://github.com/pumexx/pumex
My project goals are :
- use multithreading as a first class citizen, so that applications
scale well with growing number of CPU and GPU cores
- create architecture that is as close to the metal as possible, but not closer
- enable rendering to multiple windows, like OpenSceneGraph does
- work on multiple platforms ( currently rendering on Linux and
Windows is implemented )
- use modern C++ features that make programming more robust
and efficient, skip features that are irrevelant
- explore possibilities of creating scene graph that is stored and processed
on GPU side ( this feature is in its early infancy, but when properly
implemented, it may speed up applications a lot )
I spent much time learning, thinking and exploring many dead ends while
implementing my library and I am willing to offer my knowledge to help you
create VulkanSceneGraph. I am convinced that synergy coming
from common work may speed up creation of VirtualSceneGraph a lot.
If you are interested, I may start with describing my library design in
greater detail as a food for thought, because documentation
for pumex library is outdated or missing at the moment.
Also you can reach me through my email address : pawel.ks...@gmail.com
Looking forward to hearing from you
Paweł Księżopolski
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73944#73944
michael kapelko
1. Target C++20: by the end of 2030, when (supposedly) all new
graphics software uses Vulkan, C++20 will be old enough
2. My personal concern is the ability to run VSG on linux, windows,
mac, ios, android, and web browsers, so I volunteer to help in testing
closs-platformness of VSG.
Robert Osfield
Thanks for the link to your pumex library. I've downloaded it and run
the examples. This is great resources to have a look at and having
your around to ask question/exchange areas is really useful.
At this point in the game I'm in sponge mode, soaking up info and
resources that can help me understand Vulkan better. If there are any
resources that you've found really helpful let me know.
Cheers,
Robert.
Robert Osfield
On 4 June 2018 at 13:55, michael kapelko <kor...@gmail.com> wrote:
> 1. Target C++20: by the end of 2030, when (supposedly) all new
> graphics software uses Vulkan, C++20 will be old enough
At this point in time I want both the OSG and VSG to be forwards
compatible with C++17, so if users use it in their applications they
don't hit upon build issues. I really don't know yet whether to set
C++14 or C++17 is a minimum for VSG, but for sure C++11 will be the
minimum as the threading and other features simplify life.
> 2. My personal concern is the ability to run VSG on linux, windows,
> mac, ios, android, and web browsers, so I volunteer to help in testing
> closs-platformness of VSG.
alpha code that others can build and test the fledgling scene graph it
would be good to be able to get it ported and working across
platforms. It'll be late autumn/early winter before we have much to
play with.
Cheers,
Robert.
Rowley, Marlin R
----------------------------------------
Marlin Rowley
Software Engineer, Staff
Missiles and Fire Control
972-603-1931 (office)
214-926-0622 (mobile)
marlin....@lmco.com
Remo Eichenberger
MacOSX has no official support of Vulkan :(
But Khronos has a Vulkan to Metal runtime:
https://github.com/KhronosGroup/MoltenVK
Cheers,
Remo
------------------
Read this topic online here:
Julien Valentin
Glad to hear vsg is on the grill. As Remo wrote, MoltenVk should be taken into consideration in the design of VSG for the Mac/IOS compatibility.
@Robert classic Vulkan resources I read (if you don't already have them):
-Vulkan Programming Guide (Graham Sellers)
-per feature examples: https://github.com/SaschaWillems/Vulkan
-fill the gap between gl&vk: https://www.youtube.com/watch?v=PPWysKFHq9c
I have nothing to share yet about my thoughts on vsg but believe most of the osg Node abstraction can be kept...
Good trip
Cheers
remoe wrote:
> Hi Robert
>
> MacOSX has no official support of Vulkan :(
> But Khronos has a Vulkan to Metal runtime:
>
> https://github.com/KhronosGroup/MoltenVK
>
> Cheers,
> Remo
Twirling twirling twirling toward freedom
------------------
Read this topic online here:
Paweł Księżopolski
> I've downloaded it and run the examples.
I encourage you to take a look at the sourcecode
of the examples - I made it similar to OSG code.
> If there are any resources that you've found
> really helpful let me know.
Vulkan specification is the most comprehensive source of knowledge about
the API - it's long but it is a must for any developer taking it seriously :
https://www.khronos.org/registry/vulkan/specs/1.1/html/vkspec.html
As for the books I recommend "Vulkan Programming Guide" written
by Graham Sellers. Sometime ago it was even available for free in
certain countries on Google Play bookstore :
http://www.vulkanprogrammingguide.com/
Active forums discussing Vulkan include Khronos forums :
https://forums.khronos.org/forumdisplay.php/114-Vulkan-High-Efficiency-GPU-Graphics-and-Compute
and Vulkan subreddit :
https://www.reddit.com/r/vulkan/
Sascha Willems wrote a good set of Vulkan demos, that show how to
implement certain features :
https://github.com/SaschaWillems/Vulkan
https://www.saschawillems.de/
There's also a curated list of useful links to everything
associated with Vulkan :
https://github.com/vinjn/awesome-vulkan
Meanwhile I will try to write some article or two about my design,
but I see that I don't have to be in a hurry ( which will be good
for article quality ) while you learn Vulkan. I will post a link
to it when I'll finish.
As for the Mac/iOS platform - it was Apple's choice to skip
Vulkan and go only with their Metal API. Maybe things will change
on that platform before VSG becomes mature enough.
Cheers,
Paweł Księżopolski
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73962#73962
Robert Osfield
Thanks for the links. I have the book already and already download
some of the resources, some new ones too so very helpful.
Earlier today I downloaded and played a bit with your pumex examples.
Design wise I can probably work out most of it from the implementation
so no need to write any tutorials for my benefit, over the years I've
got quite good at reviewing code and trying to make sense of it. If
I can't easily work out what is going on and why I will ping you for
an explanation :-)
Cheers,
Robert.
Julien Valentin
Thanks pawel_xx for the resources, some are very interesting
I forgot to mention Anvil the AMD vulkan c++ wrapping
https://github.com/GPUOpen-LibrariesAndSDKs/Anvil
Don't know what it worse...
Cheers
------------------------
Twirling twirling twirling toward freedom
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73968#73968
Robert Osfield
On 4 June 2018 at 18:03, Julien Valentin <julienva...@gmail.com> wrote:
> Glad to hear vsg is on the grill. As Remo wrote, MoltenVk should be taken into consideration in the design of VSG for the Mac/IOS compatibility.
supporting it?
> @Robert classic Vulkan resources I read (if you don't already have them):
> -Vulkan Programming Guide (Graham Sellers)
> -per feature examples: https://github.com/SaschaWillems/Vulkan
Excellent, I've added it to my list of resources.
> I have nothing to share yet about my thoughts on vsg but believe most of the osg Node abstraction can be kept...
point I'm doing it clean room both conceptually and implementation
wise. It's likely you'll see things in VulkanSceneGraph that will be
like old friends, but many other places I'll changes things
drastically, either that's what Vulkan requires or to improve
performance or flexibility a new approach is required.
Cheers,
Robert.
sam
Julien Valentin
MoltenVk is a Vulkan implementation, so not a great constraint, only some cmake code and macros to prevent incompatibilities are to be forseen:
https://www.moltengl.com/docs/readme/moltenvk-0.13.0-readme-user-guide.html#install
Concerning Android Vulkan support begins with API 22 (lolipop),
on these platefroms std libraries are likely (or not) to support C++11 std::thread (don't know i have an old kitkat..) but some users exp feedback on std feature would lever this doubt
PS: I repost Anvil just in case you missed it
https://github.com/GPUOpen-LibrariesAndSDKs/Anvil/
I'd like other people ptofview about it as it provide the base we require
(but more..pumex is definitly easier to read:/).
If anyone have experience with it it would be great to share it...
Cheers
robertosfield wrote:
> Hi Julien,
>
> > Glad to hear vsg is on the grill. As Remo wrote, MoltenVk should be taken into consideration in the design of VSG for the Mac/IOS compatibility.
> >
>
> I haven't investigated MoltenVk yet, are there gotcha's involved in
> supporting it?
>
>
> > @Robert classic Vulkan resources I read (if you don't already have them):
> > -Vulkan Programming Guide (Graham Sellers)
> > -per feature examples: https://github.com/SaschaWillems/Vulkan
> >
>
> Thanks, have the book and have done a bit of diving into Sascha's resources.
>
>
> > -fill the gap between gl&vk: https://www.youtube.com/watch?v=PPWysKFHq9c
> >
>
> Excellent, I've added it to my list of resources.
>
>
> > I have nothing to share yet about my thoughts on vsg but believe most of the osg Node abstraction can be kept...
> >
>
> While many of the osg Node abstractions could be replicated, at this
> point I'm doing it clean room both conceptually and implementation
> wise. It's likely you'll see things in VulkanSceneGraph that will be
> like old friends, but many other places I'll changes things
> drastically, either that's what Vulkan requires or to improve
> performance or flexibility a new approach is required.
>
> Cheers,
> Robert.
> _______________________________________________
> osg-users mailing list
>
>
> ------------------
> Post generated by Mail2Forum
------------------------
Twirling twirling twirling toward freedom
------------------
Read this topic online here:
Andrew Cunningham
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73979#73979
Robert Osfield
On 5 June 2018 at 17:30, sam <brk...@gmail.com> wrote:
> Regarding SceneGraphTestBed are we looking to have a library to help
> facilitate testing? What is the current vision for the test repository.
OpenSceneGraph and VulkanSceneGraph need testing and doing it in one
coordinated way could help both projects.
OpenSceneGraph is feature rich and has lots of loaders but still needs
testing. VulkanSceneGraph right now has no code, no features, no
loaders, but over time these will be expanded and progress towards
OpenSceneGraph feature wise. However, I don't plan for
VulkanSceneGraph to have all the NodeKits and niche features that
OpenScenGraph, these instead will be something for high level
frameworks or add on libraries.
As VulkanSceneGraph is developed it will be rarely useful to have a
set of existing tests for it to use as concrete goals that we can work
towards. I can envisaged creating an OpenSceneGraph test program that
tests an OpenSceneGraph/GL feature set, then this test becomes a
target for replicating as the VulkanSceneGraph is developed. For
instance we might have a quad tree scene graph and we want to test
culling performance of the scene graphs traversal and culling.
Another test might be a specific render to texture technique like
distortion correction or shadows. One could create dozens of
different tests, or simply have one test program that loads many
different types of data.
One possibility I have been thinking of is to create a scene graph
builder interface that has a lua front end that we can use lua scripts
to build scene graphs and run tests. This scene graph builder
interface would then have a scene graph builder backend, one for
OpenSceneGraph, one for VulkanSceneGraph then at runtime one can
select either or both and then test the resulting scene graphs.
Another extension to this could be doing loading data and imagery
using the OSG, but then pass this in as input into the scene graph
builder than abstracts away from the OSG specifics.
These are just ideas right now, nothing more than a git repo making
intent as this stage.
--
As a bit of background, in the early days of the OSG I was lucky to be
using Performer for my day job so I got to test models like
Performance town and just for fun set myself a goal of implementing
all the features used in Performer town - so LOD's switches, sequences
and a range of GL state that originally the OSG had none of. Once I
could load and render the town so it looked the same of performer the
issue of performance become apparent - the OSG was getting ~1fps while
Performer got 60fps+, which then spured me to on to implement culling,
state sharing, state sorting, lazy state updating until eventually the
OSG performed just as well.
This process of having a full featured scene graph to compare to was a
really helpful yardstick to measure against. The OSG wasn't
attempting to be Performer, it was headed in it's own design direction
wise, but it still needed basic features to serve the needs of the
vis-sim market, so knowing what these were was a big step up. As the
OSG developed new challenges were brought forward by the community and
clients that forced it to evolve in more scalable and flexible ways
too.
For the VulkanSceneGraph I'd like to use the same practical
feature/performance benchmarks to aim for, measurable goals are so
much more effective for software design than marketing bullet points.
For the future VulkanSceneGraph user community being able to define in
practical terms what features you'd like to see would be a good way to
measure up progress against it. As we have a really powerful scene
graph to work with already we should be in a good position to leverage
it to provide such benchmarks.
I hope this makes sense,
Robert Osfield
> 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.
Ravi Mathur
Robert Osfield
> 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.
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.
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,
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Björn Blissing
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. ;)
Best regards,
Björn
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73990#73990
Robert Osfield
> 1. Use modern CMake - this will make the project much easier to use.
Modern CMake and xmake are on the short list.
> 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.
> 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.
> 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++. 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.
Björn Blissing
robertosfield wrote:
>
>
> > 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:
> 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
michael kapelko
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
Robert Osfield
> 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.
> 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.
Robert Osfield
> Since we're talking about standard proposals now, here are some I would want:
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.
Björn Blissing
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 STL 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. :)
Best regards,
Björn
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=73998#73998
Robert Osfield
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.
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.
Robert Osfield
> I would like to throw out the concept of using something like Conan.io ( https://conan.io/ ) to assist with 3rdparty package management.
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.
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.
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.
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 Osfield
> > 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.
have a link to Jeremy's project?
Thanks,
Chris Hanson
Robert Osfield
> 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.
project more focused on just the scene graph and rendering it, rather
than adding many ancillary features like the OpenSceneGraph has.
These additional features are still essential to many users so I
envisage more 3rd party NodeKits that build upon the core
VulkanSceneGraph that users can use, some of these might be siblings
to the VulkanScenGraph project like osgQt is now to OpenSceneGraph
sitting alonside it in the openscenegraph github account, or
completely independent like osgEarth.
I also think that many users don't want to just compose their
applications from VulkanSceneGraph and various addon NodeKits I expect
many will want higher level functionality tailored to specific
application sectors. So for instance a VulkanImageGenerator
framework that pulls all the bits required for the simulator market,
another for first person games, etc. etc.
It might be that some developers want to take on the likes of
Unity/Unreal and need a scene graph to build this upon, the
VulkanSceneGraph and addons could all be nestled within doing the
heavy lifting.
Somewhere in all of this might a project the uses POCO, but as I never
used it myself I won't attempt to say what type of NodeKit or
framework that it would be best be deployed - this is something I'm
more than happy to let the community go wild with. For me, having
made the decision that VulkanSeneGraph won't attempt to encompass a
massive range of functionality but keep focussed, I have the
luxury/opportunity of donning a set of blinkers for all ancillary
topics to the core issue of Vulkan, C++ and scene graphs. If I get
mixing of these core technologies right then it'll be a fertile ground
for the community to build great frameworks and applications.
Thomas Hogarth
I'd by up for making a small unit test application framework. This is also a problem for osg examples at the mo. They only run in console/desktop environments.
I could develop a simple DemoBase class or whatever, examples and Unit tests inherit from that and then for each platform (desktop, iOS, Android etc) make a simple launcher frame work.
Regarding the actual VulkanSceneGraph. I like the idea of keeping it as just a pure scenegraph and renderer then having node kits. It's not just about dependencies for me but speedy building and testing.
An issue for me with osg at the moment isn't the dependancies for the plugins. You can do a lot with zero third party libs. The issue is that there are just sooooo many plugins it's a blessing and a curse. A system which when I generated my project let me select the plugins I wanted would be awesome. A full build of osg on mobile platforms can take well over an hour but it's mainly the plugins users will probably never use that take all the time.
I know that's really just an issue when you build osg but it really puts me off doing tests for releases.
Regarding macOS not currently supporting Vulkan. The same will be true of UWP apps, but hopefully a similar solution to Angle will be available. Most of the changes in the UWP port aren't related to using Angle, that's pretty much just using different headers and libs. The changes were mostly for UWP itself, file access etc.
------------------
Read this topic online here:
Robert Osfield
On Sat, 9 Jun 2018 at 03:09, Thomas Hogarth <thomas....@gmail.com> wrote:
> I'd by up for making a small unit test application framework. This is also a problem for osg examples at the mo. They only run in console/desktop environments.
>
> I could develop a simple DemoBase class or whatever, examples and Unit tests inherit from that and then for each platform (desktop, iOS, Android etc) make a simple launcher frame work.
will be able to host, it's why I created the repo on github. I've
thinking of a small test framework, tests and supporting data. If you
can create something to illustrate what it could look like this would
be really useful. This work can happen independently from the
VulkanSceneGraph work, once the later is usable/testable we can then
start adding VulkanSceneGrpah specific support. Until the
VulkanSceneGraph is ready the test framework could build upon the
OpenSceneGraph.
Setting a C++11 as base for SceneGraphTestBed would be fine. This is a
big topic for discussion so probably best to create a separate thread
for it.
> Regarding the actual VulkanSceneGraph. I like the idea of keeping it as just a pure scenegraph and renderer then having node kits. It's not just about dependencies for me but speedy building and testing.
>
> An issue for me with osg at the moment isn't the dependancies for the plugins. You can do a lot with zero third party libs. The issue is that there are just sooooo many plugins it's a blessing and a curse. A system which when I generated my project let me select the plugins I wanted would be awesome. A full build of osg on mobile platforms can take well over an hour but it's mainly the plugins users will probably never use that take all the time.
able to define white list of what you are happy building, not sure how
easy this would be to implement. I'm open to suggestions, but for
changes to the OSG we need a separate thread.
Cheers,
Robert.
Andrew Lowe
> Hi All,
>
> I am delighted to say that today I began work on VulkanSceneGraph,
[snip]
>
> I also will be looking into what features of modern C++ can bring to
> the table to make our lives as graphics developers easier and more
> productive, C++11, 14 and 17 are all under consideration.
>
[snip]
Dear all,
The above announcement has prompted me to up my skills with C++. I
started using it back in the days of the release of the HP & SGI STL
implementations, the mid to late '90s but always managed to use it as a
"super" C. I now want to learn all the new stuff and become buzz word
compliant.
To this end, what books would people suggest I invest in to get the
latest info and the most out of the latest bits & pieces? What I aim to
be able to do is understand what Robert is doing with the new Vulcan
scenegraph, understand Boost etc and in turn make use of them. On the
other hand I don't want/need to be someone who can criticise the latest
decisions be the various standards committees :)
Any thoughts, pointers would be greatly appreciated,
Andrew
p.s. A viewing of the various online stuff from MIT/Stanford/Berkley etc
is also on the to do list.
michael kapelko
Paweł Księżopolski
If you are still in sponge mode - I just released new version of my Vulkan renderer, where you can find few articles linked from README.md.
These articles describe some of the important aspects of my renderer architecture, that you may find inspiring, interesting or just simply wrong ;) :
https://github.com/pumexx/pumex
Cheers,
Paweł Księżopolski
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74482#74482
Robert Osfield
On Thu, 9 Aug 2018 at 17:59, Paweł Księżopolski
<pawel.ks...@gmail.com> wrote:
> If you are still in sponge mode - I just released new version of my Vulkan renderer, where you can find few articles linked from README.md.
>
> These articles describe some of the important aspects of my renderer architecture, that you may find inspiring, interesting or just simply wrong ;) :
>
> https://github.com/pumexx/pumex
Thanks for the update.
I already have check out of pumex, it is indeed a good reference, one
of the best libs on top of Vulkan I've come across ;-)
Just did an update and build, latest pumex master builds and runs
cleanly on my linux system.
I'm still learning Vulkan, thinking lots, experimenting. So still in
sponge mode. What I have on screen is very primitive, it'll be a
while before I can do anything as impressive as pumex can.
Cheers,
Robert.