Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

Hi Pawel,

On Thu, 9 Aug 2018 at 17:59, Paweł Księżopolski
 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.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Paweł Księżopolski]

Hi Robert,

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[michael kapelko]

Hi. I think you should post this question in a new thread.

On 4 August 2018 at 13:33, Andrew Lowe  wrote:
> On 02/06/18 01:22, Robert Osfield wrote:
>> 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.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Andrew Lowe]

On 02/06/18 01:22, Robert Osfield wrote:
> 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.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

A short note on "The importance of working in a isolation."

This thread has been ended straying away from what I intended.  It was
announcement, and never intended to a discussion or technical issues
or wish-lists, personal preferences, from the community.  It's
devolved a bit into this as I guess I was too subtle when I wrote in
the project introduction:

"We aren't looking to involve the wider community at a day to day
level in this process, or looking to collate a wish list of features:
the plan is to keep focused on scoping out the technology and
techniques."

Why is this important?  When working on big ideas you need to take a
step back, to be creative you need to be able to dart from topic to
topic at your own pace, to look at minute detail then back up to high
level as inspiration strikes.   This creative process is greatly
hampered by getting bogged down with wading through stiff that is
irrelevant or already decided, or too soon in the cycle to be able to
discuss.

I know this is hugely important as all the biggest advances that I've
made over the years in with the OpenSceneGraph have been done working
alone, just banging my head against the wall till something compelling
pops out,The State system, multi-pass, multi-stage rendering,
database paging, osgViewer, the plugin system, #pragma(tic) shader
composition have all been instigated by myself reflection on big
issues and coming up with solutions.  Those solutions later get
refined with help from the community.

For each of these steps forward the community has a great deal of
input to helping me understand what the problems that users had and
needed to be solved, sometimes there was a specific issue or issues
realised by the community that had no good solution and I went away
and came back with a solution.  Sometimes, it was years of the
community and myself struggling with an issue with no clear resolution
that was found, then suddenly a solution came to me - #pragma(tic)
shader composition is one example of the later.

For the VulkanSceneGraph project, the input I have needed to
understand what is required has been accumulated over 20 years of
working the OpenSceneGraph.  I've been witness to all of the issues
that the user community have had trying to solve their graphics
application tasks, I've been involved in tens of thousands of support
discussion, made many thousand bug fixes, many thousand reviews of
code submissions.   I really know what it's like for the community, I
know what it's like to maintain a piece of software over many years.
I need no more input at his point, I've listed to you all for nearly
two decades, all this input data is sat inside my head and has been
gestating for years.

Right now attempts at technical discussions or putting in your ideas
is not at all helpful, in fact it's a real hindrance to creativity,
it's a distraction from necessary quiet time required to come up with
coherent designs.

So the please be patient, there will be a time for technical
discussions, testing, refining, it's just not now.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

On Thu, 21 Jun 2018 at 17:25, Scott Bailey  wrote:

> Regarding smart pointers, Boost Libs has a mature implementation that
> includes intrusive_ptr<>.  Adding another dependency is, of course, a mixed
> bag; however, if you go header only with boost libs it's reasonable.
>
> For my projects, I have found one advantage of Boost is how often it's
> libraries migrate themselves into the standard.  There are quite a few
> other libraries in Boost I use regularly, including threading and
> filesystem.  Just something to think about.
>

Just to be clear.  I have *no* intention of making Boost a dependency, ever.

I am perfectly fine with users adding whatever dependencies they want for
their own projects but the VulkanSceneGraph will be focused on keeping the
dependencies to a minimum, Vulkan and C++11 (possibly later) and perhaps
native windowing.

If the standard committee do decide something is worth adopting from Boost
then at that time that I'll consider using that feature, but even then it
has to justify itself.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Scott Bailey]

Regarding smart pointers, Boost Libs has a mature implementation that includes 
intrusive_ptr<>.  Adding another dependency is, of course, a mixed bag; 
however, if you go header only with boost libs it's reasonable.  

For my projects, I have found one advantage of Boost is how often it's 
libraries migrate themselves into the standard.  There are quite a few other 
libraries in Boost I use regularly, including threading and filesystem.  Just 
something to think about.

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

On Thu, 21 Jun 2018 at 12:11, Tim Moore  wrote:

> This is not the way shared_ptr is implemented, at least in gcc. The shared
> pointer contains a pointer to the object as well as to the control block.
> You could argue that this makes a shared_ptr twice the size of an
> osg::ref_ptr, but I really can't speculate on the overall effect on memory
> usage.
>

16 bytes instead of 8 for every single pointer... plus the extra shared
pointer object... is it just a pointer + atomic?

shared_ptr<> is a "solution" to how do I share types like an int, but it's
not at a good solution for situations where intrusive reference counting is
trivial to provide as part of class design.

Intrusive reference counting is a far better solution for a scene graph,
there isn't a comparison.  Frankly I can't believe I'm even having to
explain this, shared_ptr<> is a niche solution that gets way more airtime
than is deserves.



> So... as my aim where possible is to make the VulkanSceneGraph more
>> efficient than the OpenSceneGraph I can't just put chains around my ankles
>> by adopting shared_ptr<>, instead I will acknowledge where the
>> OpenSceneGraph already does something well and following this approach,
>> albeit in a modern C++ way.
>>
>> For the thread safe observer_ptr<> you do need a separate auxiliary
>> object, just like the OSG, so in my prototyping this is already what I have
>> done.  I already have an vsg::Auxiliary object that is created when
>> required, this Auxiliary object is for more than just supporting
>> observer_ptr<> though, it also stores optional extra user data.  Doing this
>> shrinks the base vsg::Object/Node classes and improves memory utilization,
>> providing a measurable gain in construction, destruction and traversal of
>> the scene graph over what can be done with the OSG.
>>
> What's the measured gain?
>

Measurable gain as in timing stats, the approach I'm exploring for the
VulkanSceneGraph is faster for creating objects, destructing objects and
traversal.  Good for all users, especially any time we are paging data.



> Of course I trust your judgement, but I struggled mightily with weak
> pointer thread safety back in the day and am happy to be able to make it
> someone else's problem now. I am very happy that VulkanSceneGraph is coming
> on the scene!
>

I remember all the pain getting is to work robustly.  My experiments build
upon what the OSG does currently, but using std::atomic, as well as
discarding a lot of baggage that the OSG has due to it's long history, it's
far, far cleaner. Yes we'll hammering with mutti-threaded stress cases to
make sure what we end up with is solid implementation, but with the
implementation being so much cleaner I expect the process to be a lot less
painful.

Things like ref_ptr<>/observer_ptr<> are just a tiny bit of what I'm
looking at in the Exploration Phase, these are really just a footnote
compared to the wider design and implementation issues.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Tim Moore]

Hi Robert,

On Thu, Jun 21, 2018 at 9:35 AM, Robert Osfield 
wrote:

> Hi Tim,
>
> On Thu, 21 Jun 2018 at 08:25, Tim Moore  wrote:
>
>> Before you move on, the big advantage of std::shared_ptr over intrusive
>> reference counting is that support for weak pointers is rock solid. In the
>> intrusive model, you can't implement thread-safe weak pointers without an
>> auxiliary data structure, which complicates the implementation a lot. I
>> know that one historic OSG performance win for  osg::ref_ptr  was the
>> ability to not do the reference counting if it isn't needed, but with
>> atomic increment / decrement implemented everywhere, do you think there is
>> really much performance advantage for intrusive counting? Also,
>> std::make_shared<>() allocates the shared_ptr control block in the same
>> memory allocation as the shared object, so there need not be a memory
>> fragmentation hit for using shared_ptr.
>>
>>>
> The big advantage of intrusive reference counting is that the ref_ptr<>
> holds a pointer to the actual object that you want to access, it's a single
> jump. shared_ptr<> is literary a pointer to a shared pointer (which is a
> reference counted object) to a the actual object that you want to access,
> it's two pointers, two objects vs one pointer and one object.  Scene graphs
> are predominately memory bandwidth limited so this extra level of
> indirection is not even close to as efficient as intrusive reference
> counting.  The only advantage that shared_ptr<> has is that it works with
> any type, but with a scene graph the types are mostly all under our control
> there is no cost in complexity of having intrusive reference counting, just
> stick it into the base class that most classes use anyway and your job is
> done.
>
> This is not the way shared_ptr is implemented, at least in gcc. The shared
pointer contains a pointer to the object as well as to the control block.
You could argue that this makes a shared_ptr twice the size of an
osg::ref_ptr, but I really can't speculate on the overall effect on memory
usage.

> So... as my aim where possible is to make the VulkanSceneGraph more
> efficient than the OpenSceneGraph I can't just put chains around my ankles
> by adopting shared_ptr<>, instead I will acknowledge where the
> OpenSceneGraph already does something well and following this approach,
> albeit in a modern C++ way.
>
> For the thread safe observer_ptr<> you do need a separate auxiliary
> object, just like the OSG, so in my prototyping this is already what I have
> done.  I already have an vsg::Auxiliary object that is created when
> required, this Auxiliary object is for more than just supporting
> observer_ptr<> though, it also stores optional extra user data.  Doing this
> shrinks the base vsg::Object/Node classes and improves memory utilization,
> providing a measurable gain in construction, destruction and traversal of
> the scene graph over what can be done with the OSG.
>
What's the measured gain?

>
> When adopting new features of C++ you have to understand what is happening
> under the hood, for software that is performance critical like a scene
> graph you have to take the time to make sure
>
Agreed :)

> there aren't hidden performance costs are, if there is a cost then you
> have to be really sure that this cost is worth the value it provides.
> shared_ptr<>/weak_ptr<> don't cut it for the core scene graph.  There are
> plenty of other modern C++ features that are really neat and just make life
> easier without a cost, you'll see this sprinkled everywhere in the
> VulkanSceneGraph.
>
>
> Of course I trust your judgement, but I struggled mightily with weak
pointer thread safety back in the day and am happy to be able to make it
someone else's problem now. I am very happy that VulkanSceneGraph is coming
on the scene!

Tim
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

Hi Tim,

On Thu, 21 Jun 2018 at 08:25, Tim Moore  wrote:

> Before you move on, the big advantage of std::shared_ptr over intrusive
> reference counting is that support for weak pointers is rock solid. In the
> intrusive model, you can't implement thread-safe weak pointers without an
> auxiliary data structure, which complicates the implementation a lot. I
> know that one historic OSG performance win for  osg::ref_ptr  was the
> ability to not do the reference counting if it isn't needed, but with
> atomic increment / decrement implemented everywhere, do you think there is
> really much performance advantage for intrusive counting? Also,
> std::make_shared<>() allocates the shared_ptr control block in the same
> memory allocation as the shared object, so there need not be a memory
> fragmentation hit for using shared_ptr.
>
>>
The big advantage of intrusive reference counting is that the ref_ptr<>
holds a pointer to the actual object that you want to access, it's a single
jump. shared_ptr<> is literary a pointer to a shared pointer (which is a
reference counted object) to a the actual object that you want to access,
it's two pointers, two objects vs one pointer and one object.  Scene graphs
are predominately memory bandwidth limited so this extra level of
indirection is not even close to as efficient as intrusive reference
counting.  The only advantage that shared_ptr<> has is that it works with
any type, but with a scene graph the types are mostly all under our control
there is no cost in complexity of having intrusive reference counting, just
stick it into the base class that most classes use anyway and your job is
done.

So... as my aim where possible is to make the VulkanSceneGraph more
efficient than the OpenSceneGraph I can't just put chains around my ankles
by adopting shared_ptr<>, instead I will acknowledge where the
OpenSceneGraph already does something well and following this approach,
albeit in a modern C++ way.

For the thread safe observer_ptr<> you do need a separate auxiliary object,
just like the OSG, so in my prototyping this is already what I have done.
I already have an vsg::Auxiliary object that is created when required, this
Auxiliary object is for more than just supporting observer_ptr<> though, it
also stores optional extra user data.  Doing this shrinks the base
vsg::Object/Node classes and improves memory utilization, providing a
measurable gain in construction, destruction and traversal of the scene
graph over what can be done with the OSG.

When adopting new features of C++ you have to understand what is happening
under the hood, for software that is performance critical like a scene
graph you have to take the time to make sure there aren't hidden
performance costs are, if there is a cost then you have to be really sure
that this cost is worth the value it provides.  shared_ptr<>/weak_ptr<>
don't cut it for the core scene graph.  There are plenty of other modern
C++ features that are really neat and just make life easier without a cost,
you'll see this sprinkled everywhere in the VulkanSceneGraph.

Cheers,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Tim Moore]

On Wed, Jun 20, 2018 at 8:14 AM, Robert Osfield 
wrote:

> Hi Scott,
>
> On Wed, 20 Jun 2018 at 08:09, Scott Bailey 
> wrote:
> > Wow is this ever good news!  I'm glad to see OSG will move into the
> future, albeit as VSG.  I'm especially excited to see modern c++ targeted.
> Personally, my preference is for c++14 if only for std::make_unique<>(),
> but I'll take c++11 any day!
>
> I guess there is chance I'll use std::unique_ptr<> and associated
> std::make_unique<>() at some point.  The scene graph itself will be
> managed using intrusive reference counting just like the OSG does for
> performance reasons, so I've prototyped equivalents of osg::ref_ptr<>
> and osg::Referenced for this purpose.  I guess one could also write a
> vsg::make_ref<> equivalent to std::make_unique<> if one so desired.
>
> Before you move on, the big advantage of std::shared_ptr over intrusive
reference counting is that support for weak pointers is rock solid. In the
intrusive model, you can't implement thread-safe weak pointers without an
auxiliary data structure, which complicates the implementation a lot. I
know that one historic OSG performance win for  osg::ref_ptr  was the
ability to not do the reference counting if it isn't needed, but with
atomic increment / decrement implemented everywhere, do you think there is
really much performance advantage for intrusive counting? Also,
std::make_shared<>() allocates the shared_ptr control block in the same
memory allocation as the shared object, so there need not be a memory
fragmentation hit for using shared_ptr.

Tim

> For now I'm wider design issues, doing experiments with more modern
> C++ along the way to see what is possible.  My general guide is that
> modern C++ features deployed needs to make the code easier to read and
> maintain than not using it, or provide significant flexibility/power
> that justifies any possible complexities in following the code.  So
> far so good on this count - I've been able to make the VSG equivalents
> of OSG much simpler thanks to modern C++ features.
>
> I won't make any decision on C++11 vs 14 vs 17 until the end of
> Exploration Phase.  If we can do everything we'll need with just C++11
> and there are few features of 14 and 17 that offer significant
> benefits then I'll likely just stick with C++11 for better backwards
> compatibility to older compilers.  The backwards compatibility with
> older compilers isn't a priority though, just something worth
> maintaining if it comes at no cost to the integrity/quality of the
> scene graph.
>
> I have to admit, I *really* like working with modern C++, looking back
> to some OSG code is bit painful now.  This isn't just C++ features
> though, my skills as programmer have slowly advanced over the years so
> now can spot better ways of solving problems.  Once VSG is established
> there may be a few areas of the OSG that could be updated to do
> similar things to what the VSG will do, though backwards compatibility
> for the OSG is crucial - it'll be a case of asking the question what
> can make OSG users lives better without risking breaking things.
>
> These possibilities are all a way off yet.  Through to the end of
> August I'll be just learning, thinking, experimenting with C++, Vulkan
> and ideas for improving scene graphs, and also getting OSG-3.6.2 out
> the door :-)
>
> Robert.
>
>
> >
> > If you haven't already seen it, check out the Magnum Graphics Engine.
> It's the only example I've found of anything close to a scene graph with a
> modern c++ interface.
> >
> > Best luck and Thanks!
> > SB
> > [/url]
> >
> > --
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=74083#74083
> >
> >
> >
> >
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

Hi Scott,

On Wed, 20 Jun 2018 at 08:09, Scott Bailey  wrote:
> Wow is this ever good news!  I'm glad to see OSG will move into the future, 
> albeit as VSG.  I'm especially excited to see modern c++ targeted.  
> Personally, my preference is for c++14 if only for std::make_unique<>(), but 
> I'll take c++11 any day!

I guess there is chance I'll use std::unique_ptr<> and associated
std::make_unique<>() at some point.  The scene graph itself will be
managed using intrusive reference counting just like the OSG does for
performance reasons, so I've prototyped equivalents of osg::ref_ptr<>
and osg::Referenced for this purpose.  I guess one could also write a
vsg::make_ref<> equivalent to std::make_unique<> if one so desired.

For now I'm wider design issues, doing experiments with more modern
C++ along the way to see what is possible.  My general guide is that
modern C++ features deployed needs to make the code easier to read and
maintain than not using it, or provide significant flexibility/power
that justifies any possible complexities in following the code.  So
far so good on this count - I've been able to make the VSG equivalents
of OSG much simpler thanks to modern C++ features.

I won't make any decision on C++11 vs 14 vs 17 until the end of
Exploration Phase.  If we can do everything we'll need with just C++11
and there are few features of 14 and 17 that offer significant
benefits then I'll likely just stick with C++11 for better backwards
compatibility to older compilers.  The backwards compatibility with
older compilers isn't a priority though, just something worth
maintaining if it comes at no cost to the integrity/quality of the
scene graph.

I have to admit, I *really* like working with modern C++, looking back
to some OSG code is bit painful now.  This isn't just C++ features
though, my skills as programmer have slowly advanced over the years so
now can spot better ways of solving problems.  Once VSG is established
there may be a few areas of the OSG that could be updated to do
similar things to what the VSG will do, though backwards compatibility
for the OSG is crucial - it'll be a case of asking the question what
can make OSG users lives better without risking breaking things.

These possibilities are all a way off yet.  Through to the end of
August I'll be just learning, thinking, experimenting with C++, Vulkan
and ideas for improving scene graphs, and also getting OSG-3.6.2 out
the door :-)

Robert.


>
> If you haven't already seen it, check out the Magnum Graphics Engine.  It's 
> the only example I've found of anything close to a scene graph with a modern 
> c++ interface.
>
> Best luck and Thanks!
> SB
> [/url]
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=74083#74083
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Scott Bailey]

Robert,

Wow is this ever good news!  I'm glad to see OSG will move into the future, 
albeit as VSG.  I'm especially excited to see modern c++ targeted.  Personally, 
my preference is for c++14 if only for std::make_unique<>(), but I'll take 
c++11 any day!

If you haven't already seen it, check out the Magnum Graphics Engine.  It's the 
only example I've found of anything close to a scene graph with a modern c++ 
interface.  

Best luck and Thanks!
SB
[/url]

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

Hi Thomas,

On Sat, 9 Jun 2018 at 03:09, Thomas Hogarth  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.

Excellent, this is the type of thing I'm hoping the SceneGraphTestBed
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 so 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.

Perhaps additions to CMake might help.   Essentially you'd want to be
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.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Thomas Hogarth]

Add my two cents

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 
so 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:
http://forum.openscenegraph.org/viewtopic.php?p=74015#74015





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

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

One thing I feel is worth doing is keeping the core VulkanSceneGraph
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.

Cheers,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [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 
wrote:

> Hi Chris,
> On Thu, 7 Jun 2018 at 17:24, Chris Hanson  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@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>


-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@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  facebook.com/alphapixel (775)
623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

Hi Chris,
On Thu, 7 Jun 2018 at 18:54, Robert Osfield  wrote:
> > 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.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

Hi Chris,
On Thu, 7 Jun 2018 at 17:24, Chris Hanson  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@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [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.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

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

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

On Thu, 7 Jun 2018 at 11:28, michael kapelko  wrote:
> 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.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

On Thu, 7 Jun 2018 at 10:32, Björn Blissing  wrote:
> 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.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[michael kapelko]

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

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

On Thu, 7 Jun 2018 at 08:49, Björn Blissing  wrote:
> 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.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Björn Blissing]

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. ;)

Best regards,
Björn

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

On 5 June 2018 at 21:42, Ravi Mathur  wrote:
> 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.

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

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Ravi Mathur]

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 
wrote:

> On 5 June 2018 at 19:51, Andrew Cunningham  wrote:
> > 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
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

On 5 June 2018 at 19:51, Andrew Cunningham  wrote:
> 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
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

Hi Sam,

On 5 June 2018 at 17:30, sam  wrote:
> Regarding SceneGraphTestBed are we looking to have a library to help
> facilitate testing? What is the current vision for the test repository.

I am open to suggestions and support.   My motivation is that both the
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.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Andrew Cunningham]

Great news and very timely given Apple’s just announced decision to deprecate 
OpenGL

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Julien Valentin]

Hi all

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,
> On 4 June 2018 at 18:03, Julien Valentin <> 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.
> > 
> 
> 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: 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
> 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
>  --
> Post generated by Mail2Forum



Twirling twirling twirling toward freedom

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[sam]

Hi Robert,

Regarding SceneGraphTestBed are we looking to have a library to help
facilitate testing? What is the current vision for the test repository.

Thanks, Sam

On Tue, Jun 5, 2018 at 1:35 AM Robert Osfield 
wrote:

> Hi Julien,
>
> On 4 June 2018 at 18:03, Julien Valentin 
> 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.
>
> 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: 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
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

Hi Julien,

On 4 June 2018 at 18:03, Julien Valentin  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.

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: 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
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Julien Valentin]

Hi all
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


pawel_xx wrote:
> > Thanks for the link to your pumex library. 
> > 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



Twirling twirling twirling toward freedom

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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

Hi Pawel,

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.

On 4 June 2018 at 18:48, Paweł Księżopolski  wrote:
>> Thanks for the link to your pumex library.
>> 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
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Paweł Księżopolski]

> Thanks for the link to your pumex library. 
> 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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Julien Valentin]

Hi all
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: 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:
http://forum.openscenegraph.org/viewtopic.php?p=73959#73959





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Remo Eichenberger]

Hi Robert

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:
http://forum.openscenegraph.org/viewtopic.php?p=73957#73957





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

HI Michael,

On 4 June 2018 at 13:55, michael kapelko  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.

Thanks for the offer.  Once we move onto the second phase and we have
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.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[michael kapelko]

Hi. Great news!

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.

On 4 June 2018 at 13:07, Paweł Księżopolski  wrote:
> Hi Robert
>
> 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.ksiezopo...@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
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Paweł Księżopolski]

Hi Robert

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.ksiezopo...@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





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Announcement: VulkanSceneGraph and SceneGraphTestBed!

[Robert Osfield]

Hi All,

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-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org