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 <pawel.ksiezopo...@gmail.com> 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