Replies: 8 comments 5 replies
-
|
The OSG is legacy scene graph being maintained in a backwards compatible fashion for existing applications. Breaking backwards compatibility looses this fundamental asset of the OSG for existing users. If you want a modern take on the OSG then you need to move the VulkanSceneGraph, it's C++17, it uses Vulkan, it addresses all the major CPU performance bottlenecks of the OSG, it's far better designed for modern hardware and modern graphics/compute applications. Back in 2018 I decided doing an upgrade like you have in mind was pointless, as it couldn't come close to delivering the full performance and feature capabilities that modern hardware can offer, it's why I chose to develop the VSG. Now, 5 years on my view has only solidified behind creating the VSG as being the right choice for the scene graph users. Now, the OSG is open source, you are free to build something that isn't backwards compatible, still uses the legacy graphics API that now gets no updates, because Khronos is focused on Vulkan, not OpenGL, because like the OSG, OpenGL is now just being maintained for legacy applications. Or if you have time you want to invest in learning modern scene graphs and graphics/compute APIs then you could look towards seeing what value you can add to a the VSG project or the collection of projects that build upon it. If you do decide the create a new "OSG" like project then may I ask you call it something other than the OSG to avoid creating lots of confusion amongst the community. |
Beta Was this translation helpful? Give feedback.
-
|
millennial |
Beta Was this translation helpful? Give feedback.
-
|
In case folks are wondering about items on @jurgus list. The VulkanSceneGraph already has PBR support, with glTF loader that fully supports it and much more robust cascaded shadow maps support out of the box that goes well beyond what osgShadow is capable of. This month we have also been working on providing users a richer experience with annotation the scene graph when using with RenderDoc, and also working on provide hooks for Tracy instrumentation. Details on this VulkanSceneGraph discussion thread: There are still gaps in functionality between the VSG and OSG, but bit by bit these are being filled in, and when they are they leap-frog what the OSG is capable of. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Robert, thank you for your reply. P.S. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, it is cool to see someone else who want to work on a modern version of OSG. Have a look at osgverse (https://github.com/xarray/osgverse). It already includes some features that you may be interested in, like an initial version of PBR shading and deferred pipeline, non-intrusive cascaded shadow maps and deferred lighting, GLTF & FBX importing (with full skeleton / blendshape supports), as well as WASM support for running OSG scene on web browsers. You may feel free to use my code to build your "new" version of OSG, or contribute to osgverse to fix its tons of bugs and finish the longer and longer TODO list. :) |
Beta Was this translation helpful? Give feedback.
-
|
Hi Rui, |
Beta Was this translation helpful? Give feedback.
-
|
If you care about performance on CPU and GPU you wouldn't be considering using the OSG and OpenGL as your starting place, both are outdated and have high CPU overhead. I'm the lead author of the OSG,I used OpenGL every working day between 1992 to 2018, I am not so random developer talking shit about stuff I don't have any knowledge and experience of. In the vsgTuorial online book I've been working on I touch upon the motivations for moving to a completely new scene graph and the go into the performance benefits of doing so: https://vsg-dev.github.io/vsgTutorial/ You will never be able to achieve the performance and functionality that can be achieved with the VSGulkan/V, and if you are breaking backwards compatibility what is the point of accepting compromised performance from day one? |
Beta Was this translation helpful? Give feedback.
-
|
Hi Robert, OpenGL and OSG will have little chance of surpassing VSG when it is ready. But what I want to achieve, at least give it a fighting chance :). I ask myself this question how much more potential there is in OSG and OpenGL, and this hobby project of mine is also to check it out. |
Beta Was this translation helpful? Give feedback.
-
|
The VSG has already solved the major challenges of working with Vulkan, many tasks are now actually easier with the VSG than they are with OSG/OpenGL. A key goal of the VSG was to make Vulkan easy. The main reason why graphics software fails to achieve the potential performance improvements promised by Vulkan is that they are poorly architected for them and have a CPU overhead that is so high that this dominants performance, not the graphics API. Fix those problems are you start to see the benefit of Vulkan. The VSG is designed specifically around Vulkan and the capabilities of modern hardware. Performance improvement you see between OSG/OpenGL to VSG/Vulkan is typically 3-4x faster, not a couple %. You can lower the CPU overhead that the OSG has by adopting the techniques I've implemented in the VSG to try and close this gap, but you can't fix how OpenGL works, but this would fundamentally break backwards compatibility for existing OSG codebase and users. Please read the vsgTutorial, spend some time learning the VSG, this time will be a invaluable in understanding the context that the OSG/OpenGL & VSG/Vulkan have in history through to technical side to different design decisions made. Even if folks don't actually use the VSG in the end this should still help them understand the topics of graphics and scene graphs better. OpenGL is zombie at this point. OpenGL 4.6 was released in July 2017, over 6 years ago. It's only future is keeping existing OpenGL based applications working. Khronos know this, and by now I would have hoped that the rest of the industry would have come to terms with this. Contrast this to Vulkan, it's very much alive and active development by Khronos with lots of hardware companies support latest releases quickly, and the VulkanSDK keeps getting regular updates even between point releases of Vulkan itself. It's a healthy and vibrant ecosystem. Vulkan already beats OpenGL on features - compute shaders, cross vendor mesh shaders and ray tracing, multi-thread design, explicit memory management, and as new hardware features are being developed they are being exposed in Vulkan, initially via extensions then pulled in to the core Vulkan. All while the OpenGL horse which not technically dead is laying in Coma, unchanged for over 6 years. This beast isn't suddenly going to get up and start running. Of all the middle-ware graphics APIs available, the VSG is closest in design and philosophy to the OSG, it's born from the same DNA so for existing OSG while requiring a major port is probably the route with least pain. My job is get the VSG as quickly to a place to where OSG users can port to it and know they have a solid foundation for the next 20 years. If developers have time on their hands and energy to invest in something new then please consider contributing to the VSG project, there are plenty of areas that one could make their own - the VSG project is composed of a family of projects, rather than monolithic one like the OSG. Trying to build something on top the existing OSG/OpenGL is flogging what is close to a dead horse, it bifurcates development communities and does nothing with pushing the start of art along. |
Beta Was this translation helpful? Give feedback.
-
|
I am keeping my fingers crossed for the successful development of the VSG project. I believe that having a next-generation VSG and some improvements around OSG sounds like a win-win situation for everyone. |
Beta Was this translation helpful? Give feedback.
-
|
If developer resources were an infinite commodity then trying to pull in two different directions at once might be fine. In the real world we are finite resource it's better if we all pull in the same direction. For existing OSG users what will they decided to do? Try porting to your non backwards compatible OSG version in the hope that it isn't too painful and not too much useful functionality is lost, or just bite the bullet and port to the VSG or other properly modern API. Right now, my advice to existing OSG users is maintain your current software with OSG-3.6.5 and start learning VSG/Vulkan so when you get the opportunity you can write new applications based on this, or port your existing code base. The % of OSG users that can port across to the VSG increases with each step forward with the VSG, but the more effort that happens to fill in the functional gaps missing from the VSG the quicker we can increase that % of OSG users that can find a safe haven in the VSG. Having developers waste time on the deluded idea that OSG can somehow be tweaked to make it modern while they could be doing something productive within a project that has a long term and vibrant future is galling to me, rather than an dead-end that Khronos sealed 6 years ago when they stopped developing OpenGL. However, if I can't help you see sense then you are free to waste your time on fools errand then I have to hope my skill at developing scene graph is better than my skills are persuasion. |
Beta Was this translation helpful? Give feedback.
-
|
If I see it right the OpenSceneGraph is not anymore in development. |
Beta Was this translation helpful? Give feedback.
-
|
Please just read what I've been writing over the past 5 years. Posts to this forum and to the website have all made it clear that the successor to the OpenSceneGraph, VulkanSceneGraph has been development and the OSG is in maintenance mode since 2018. My 2023 review and 2024 plans post goes into some further details: #1291. We also have a new website in development: #1292 which makes clear that the OSG is maintenance mode and VSG should be used for new projects. |
Beta Was this translation helpful? Give feedback.
-
Hi everyone, I wanted to introduce to you a mine personal hobby project to "improve" OSG. My "improvements" that I am working on can be summarized in the following points.
Does this "new" version maintain backward compatibility with the latest OSG version available on Github? Unfortunately, NO. I know this is probably not good news. But changes to API (OSG 3.6.5) I try to keep to the "bare minimum". And they, at the moment, around the Math and Image/Texture classes and enforced by removed obsolete code.
What are the effects of the changes I made?
I'll show a more subtle change first, and that is full support for Linear-Space Lighting (needed for PBR rendering)
-Linear-Space Lighting
-Gamma-Space Lighting
Next I want to show performance improvements.
Test was made by running slightly modified osgdeffered example (just added more 4000 torus).
Lets compare it with stack version of OSG ( 3.6.5).
As we can see “optimization” do their work. We gain on every step except Draw. And this is mostly because by default OSG is using DisplayList for rendering. On PC they are still supported but on mobiles they not.
Lets test OSG with disabled usage of DisplayLists and turn off it in Cmake.
and IMHO something rotten in this rendering path.
What's next.
To summarize this post. This is my beginning journey in optimizing and upgrading OSG. As I mentioned, this is my hobby project, but I look forward to your feedback, in particular, for now I have only done a synthetic test of this "new" version of OSG. I expect that someone can share with me a more representative scene or a scene where I can conduct appropriate performance and comparability tests.
Beta Was this translation helpful? Give feedback.
All reactions