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

Announcement: VulkanSceneGraph and SceneGraphTestBed!

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


Joined: 18 Mar 2009
Posts: 12131

PostPosted: Fri Jun 08, 2018 9:03 am    Post subject:
Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

Hi Chris,
On Thu, 7 Jun 2018 at 22:19, Chris Hanson <> wrote:
Quote:
I was mostly suggesting POCO in terms of all of the support code that it provides for the parts outside the core scenegraph. But I understand that that's not what you're focusing on right now.

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.


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


Joined: 30 Apr 2009
Posts: 186

PostPosted: Sat Jun 09, 2018 1:59 am    Post subject:
Reply with quote

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 sooooo many plugins it's a blessing and a curse. A system which when I generated my project let me select the plugins I wanted would be awesome. A full build of osg on mobile platforms can take well over an hour but it's mainly the plugins users will probably never use that take all the time.

I know that's really just an issue when you build osg but it really puts me off doing tests for releases.

Regarding macOS not currently supporting Vulkan. The same will be true of UWP apps, but hopefully a similar solution to Angle will be available. Most of the changes in the UWP port aren't related to using Angle, that's pretty much just using different headers and libs. The changes were mostly for UWP itself, file access etc.
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12131

PostPosted: Sat Jun 09, 2018 7:25 am    Post subject:
Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

Hi Thomas,

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

Quote:
Regarding the actual VulkanSceneGraph. I like the idea of keeping it as just a pure scenegraph and renderer then having node kits. It's not just about dependencies for me but speedy building and testing.

An issue for me with osg at the moment isn't the dependancies for the plugins. You can do a lot with zero third party libs. The issue is that there are just sooooo many plugins it's a blessing and a curse. A system which when I generated my project let me select the plugins I wanted would be awesome. A full build of osg on mobile platforms can take well over an hour but it's mainly the plugins users will probably never use that take all the time.

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.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Scott (Scott Bailey)
Newbie


Joined: 14 Dec 2010
Posts: 2

PostPosted: Fri Jun 15, 2018 6:04 pm    Post subject:
Reply with quote

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]
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12131

PostPosted: Wed Jun 20, 2018 8:14 am    Post subject:
Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

Hi Scott,

On Wed, 20 Jun 2018 at 08:09, Scott Bailey <> wrote:
Quote:
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.


Quote:

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








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





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

On Wed, Jun 20, 2018 at 8:14 AM, Robert Osfield < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
Hi Scott,

On Wed, 20 Jun 2018 at 08:09, Scott Bailey < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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
Quote:
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 Smile

Robert.


Quote:

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




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


Joined: 18 Mar 2009
Posts: 12131

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

Hi Tim,

On Thu, 21 Jun 2018 at 08:25, Tim Moore < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:

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

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





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

Hi Robert,

On Thu, Jun 21, 2018 at 9:35 AM, Robert Osfield < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
Hi Tim,

On Thu, 21 Jun 2018 at 08:25, Tim Moore < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:

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

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



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

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


Joined: 18 Mar 2009
Posts: 12131

PostPosted: Thu Jun 21, 2018 12:16 pm    Post subject:
Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

On Thu, 21 Jun 2018 at 12:11, Tim Moore < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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.



 
Quote:
Quote:

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. 



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

------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Scott (Scott Bailey)
Newbie


Joined: 14 Dec 2010
Posts: 2

PostPosted: Thu Jun 21, 2018 4:25 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12131

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

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

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


Joined: 18 Mar 2009
Posts: 12131

PostPosted: Fri Jun 22, 2018 3:18 am    Post subject:
Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

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.


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





PostPosted: Sat Aug 04, 2018 10:34 am    Post subject:
Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

On 02/06/18 01:22, Robert Osfield wrote:
Quote:
Hi All,

I am delighted to say that today I began work on VulkanSceneGraph,

[snip]

Quote:

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 Smile

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.


------------------
Post generated by Mail2Forum
Back to top
kornerr
Appreciator


Joined: 01 Oct 2013
Posts: 280

PostPosted: Mon Aug 06, 2018 10:22 am    Post subject:
Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

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

On 4 August 2018 at 13:33, Andrew Lowe <> wrote:
Quote:
On 02/06/18 01:22, Robert Osfield wrote:
Quote:
Hi All,

I am delighted to say that today I began work on VulkanSceneGraph,

[snip]

Quote:

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.



------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
pawel_xx (Paweł Księżopolski)
User


Joined: 29 Nov 2011
Posts: 21

PostPosted: Thu Aug 09, 2018 3:43 pm    Post subject:
Re: Announcement: VulkanSceneGraph and SceneGraphTestBed!
Reply with quote

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

https://github.com/pumexx/pumex

Cheers,
Paweł Księżopolski
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Goto page Previous  1, 2, 3, 4  Next
Page 3 of 4

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

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


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