Plans for OpenSceneGraph master, 3.6.x, 3.8 and beyond

[openscenegraph]

Hi All,

Over the past 4 and half years I have been close to 100% focused on development of the VulkanSceneGraph, the successor to the OpenSceneGraph, actually it's probably nearer to 150% given all the over-time mastering the Vulkan beast and re-inventing what a scene graph should be in the 2020's. It's been one of those all consuming tasks that you can only do it justice if you concentrate all your efforts on. Hugely proud of how it's turned out, so please check it out, it surpasses the OpenSceneGraph in many ways.

Now that VulkanSceneGraph-1.0.0 is out I can finally let other tasks start creeping back into consciences, and start looking at catching up with outstanding OpenSceneGraph support work and planning future releases. I will be easing slowly back into the OpenSceneGraph side, so please don't expect me to be suddenly available 60hrs a week provide support, but I plan to put aside some of my free time over the next few months to try and bring things a bit more up to date.

Follows are my thoughts about the way forward for the OpenSceneGraph project.

OpenSceneGraph and OpenGL are legacy APIs, that are widely used and need maintaining

While we can get all excited about the potential of the VulkanSceneGraph/Vulkan to get every ms of performance and fancy new features out of modern hardware the reality is the OpenSceneGraph/OpenGL has lots of existing applications that use them and rely upon their availability and usability going forward.

Providing a solid and reliable base for the community of OpenSceneGraph users has to be the priority. If you want best performance and support for latest hardware features then the OpenSceneGraph/OpenGL is not the tool for you, that's what the VulkanSceneGraph is for.

Prioritizing build and runtime stability over features and performance will be metric used for all PR's, be them build changes, code changes. If new code and build submissions isn't focused on stability improvements then it will need to be risk assessed and well tested in order to justify the risk of merging it. I'd rather reject a new feature or performance enhancement rather than risk breaking the build or runtime.

When it comes to reviewing PRs expect me to be risk adverse and feature skeptic. This will be a sliding scale:

• For any work on the existing stable release series like OpenScenGraph-3.6 you'll see peak risk aversion and close to blanked rejection of new features.
• For work on master or future stable releases I will be more open to features additions, but still looking to spot any possible areas that might break because of the new addition, if it looks risky I will push back and expect real justification for the addition, something being "cool", or "might" possibly be useful isn't going to cut it. If you application really needs it and there isn't any easy other way to tackle it then this will be appreciated over things that have alternatives.
• Any change to the CMake build system and any code change will be looked upon as potentially breaking stability.
• Priority will always be stability of the code base over features.

My current near term (next 3 months) OpenScenGraph plans:

1. Enable Discussions directly on github (done because you're here reading this :-), to replace the existing osg-users google group which will be become an archive for old discussions rather than a continued forum for discussions.
2. Create Deprecated_master_20th_November_2022 branch (done) from OpenSceneGraph master, and officially deprecate this thread of work as it contains highly experimental work on shader composition that is incomplete and will never be completed. This shader composition work that I started prior to the VulkanSceneGraph project and was an attempt to unify shaders and fixed function pipeline usage, but now that we're 5 years on interoprability of fixed function pipeline with shaders is now pointless - the world is going 100% shaders. Experimental features with now future and which risk stability just don't cut it, even it's many months of my own work that I'm ditching.
3. Make the MeshShaders branch the new OpenSceneGraph master. This branch is close to the OpenSceneGraph-3.6 branch, but adds OpenGL MeshShader and MultiView extension support. This will be the key features for what will be a future OpenScenGraph-3.8 release.
4. Review outstanding PR's for ones that are suitable for inclusion with the new master, or 3.6 branch.
5. Possibly create an Experimental branch to put PR's that I don't feel are suitable for immediate inclusions, or an interesting enough to warrant wider community testing/comment.
6. Once PRs are tackled discuss with community testing of OpenSceneGraph-3.6 branch with a view to making a 3.6.6, possibly in the new year.

Possible longer term OpenScenGraph plans:

8. After 3.6.6 is out turn attention to making a 3.8 release in Spring/Summer. Focus for 3.8 to be stability rather than new features.
9. Community discussion about opportunities for pulling in ideas/features from the VulkanSceneGraph into the OpenSceneGraph and improving interoperability between the two. There is already a osg2vsg project for this but it's needs a significant rewrite as the VulkanScenGraph has moved on significantly since osg2vsg was written in the early days of the VulkanSceneGraph project.

Funding would be really helpful

Over the past year I took a long sabbatical from paid client work so I could concentrate fully of completing the VulkanScenGraph and getting 1.0.0 out. I used funds from previous client work to make it possible to do 9 months work without income but now 1.0.0 I'm having to concentrate primarily on client work - I need to refill the tank. This means I won't have much time available for general open source work and support. The time I have available will need to be split between the OpenScenGraph and VulkanSceneGraph projects.

As new client work comes in then I'll need to continue to prioritize it over unpaid work, but if organizations using the OpenSceneGrah want to me to concentrate on the OpenSceneGraph then funding a block of time will really help me schedule OpenSceneGraph support/dev work. While I don't have any active OpenSceneGraph support contracts in place perhaps this would be a way funding the open source work, perhaps combined OpenSceneGraph/VulkanSceneGraph contracts would be something companies would like.

I'm open to suggestions on how to balance the books and time between the various project demands.

--

Many thanks for the your patience over the past few years. I do appreciate that it can't have been easy having a project lead largely absent from the helm for four and half years.

Cheers,
Robert Osfield.
OpenSceneGraph/VulkanScenegraph Project Lead.

[robertosfield]

As part of clean up of the OpenSceneGraph I have removed all developer release tags leaving just major release tags, cutting the number of tags from 137 down to 26.

I have also pruned the branches down to just the active and the stable release branches.

These changes are meant to "thin out the woods" so developers can more easily see the relevant parts of the repository.

[Modenbach]

Hi Robert,
congratulations for your vsg 1.0 launch. Great work!
As you may know, I still use OSG for in textile simulations.
I'm sure you know, my main interest is in the MeshShader, as they really offer excellent performance on complex geometries that I couldn't achieve before. Also, I can now even create effects like fluffiness and surface elements entirely on the GPU.
I would be really happy if we had a dedicated primitive class instead of a ProxyPrimitive.
Fundamental to MeshShader are BufferTextures that allow indexed access to all elements. At the moment they are a bit cumbersome to create (see code below). I'm also not sure if this handling is optimal. Further more it generates error messages on execution.
If you could take a look at this and possibly write a class that provides a simple interface, that would also be a win for handling and code transparency.
Here is my (example) approach for the ProxyPrimitive and a vertex array:

    osg::ref_ptr<osg::ProxyPrimitive> proxyPrimitive = new osg::ProxyPrimitive;
    proxyPrimitive->drawMeshTasks = new osg::DrawMeshTasks(0, numberOfMeshlets * taskInvocationsPerMeshlet);
    geometry->setUseDisplayList(false);
    geometry->addPrimitiveSet(proxyPrimitive.get());

    _osg::ref_ptr<osg::Vec4Array> osgVertices = new osg::Vec4Array();
    // fill vertices here ...
    // create buffer and texture
    osg::ref_ptr<osg::VertexBufferObject> verticesBufferObject = new osg::VertexBufferObject();
    verticesBufferObject->setUsage(GL_DYNAMIC_READ_ARB);
    osgVertices->setBufferObject(verticesBufferObject.get());
    osg::ref_ptr<osg::TextureBuffer> vertexTexture = new osg::TextureBuffer(osgVertices.get());
    vertexTexture->setInternalFormat(GL_RGBA32F_ARB);
    vertexTexture->setInternalFormatMode(Texture::USE_USER_DEFINED_FORMAT);
    stateSet->setTextureAttributeAndModes(MESH_VERTEX_ARRAY_TEXTURE_UNIT, vertexTexture.get());_

Please contact me if you need more info.

Translated with www.DeepL.com/Translator (free version)

[robertosfield]

Refining TextureBuffer/MeshShaders might be doable for 3.8. I've never been happy with the ProxyPrimitive. To refine this type of functionality an extended mesh shader example that illustrates the types of usage would be useful start. The fact that this example is a bit cludge right now would be fine as it'll illustrate what doesn't work cleanly and then as improvement are made it should be possible to steadily clean it up.

However, this type of functionality is what the VSG/Vulkan is good at so there may be a point where it's just so much cleaner and efficient to do with the VSG, that trying to chase this functionality with OSG/OpenGL might be a lot more effort for modest gain isn't worth the extra effort.

At this point in time I'm swamped with several years of support backlog on the OSG, so just getting to up to date is a big challenge. As almost all my income comes from VSG related projects this is essentially the day job, the OSG support side is spare time/volunteer effort. This means focusing on just clearing the OSG backlog and not taking on any new development work.

[MauFranco]

Hi Robert,
First of all, thanks so much to you and all the developers working on OSG and VSG. We use OSG to deliver simulations and equipment emulations to container terminals and ports worldwide, including the largest automated facility in the planet.

We selected OSG because it was a cleaner and clever design compared to all other alternatives. Now we would like to know if OSG/VSG are future proof. For this we appreciate your thoughts about other developments in the industry, for instance:

1. Pixar's USD becoming a standard for 3D scene representation (NVIDIA has been pushing very hard on this). Will it be enough writing a USD importer/exporter plugin for OSG/VSG?
2. Also, NVIDIA has been proposing MDL as the industry standard for PBR material definitions and exchange format. Is this something that is currently supported or can be supported by OSG/VSG, not only for importing but also for rendering accurately?
3. Real-time ray tracing and path tracing. Can this be achieved currently? by means of shaders?
4. What things can be achieved with other platforms such as Unreal, O3D or Unity that cannot be achieved with OSG already?

Thanks in advance,
Kind regards,

Mauricio.

FlexTerm Development Lead
https://www.linkedin.com/in/maufranco/

[robertosfield]

We selected OSG because it was a cleaner and clever design compared to all other alternatives. Now we would like to know if
OSG/VSG are future proof.

The OSG is primarily in maintenance mode and I consider it a legacy scene graph, based on a legacy graphics API, that is maintained in a stable state as possible for the large number of applications that depend upon. As long as OpenGL/ES is still supported on platforms it will should possible to keep the OSG building for them.

The VSG is next gen scene graph, based on a modern graphics API , that is designed from the ground up for modern hardware and application needs. It's still in it's infancy having just got to 1.0, but it's already very functional and will provide a great base for the future evolution of Vulkan, the scene graph and utility libraries on-top of it. As much as you can future proof a scene graph the VSG probably qualifies as state of the art.

Fast forward 10 years and I wouldn't be surprised if their are applications still happily using the OSG, they won't be ground breaking in any way, but that's not what most graphics applications need. In 10 years the VSG will be very mature and should still be able to help users developing cutting edge applications.

If application developers want to use the latest features of hardware and get the best performance they'll need to migrate from the OSG to the VSG or one of the competing modern APIs.

I don't see much value in trying to chase features with the OSG as it'll always be held back by OpenGL and maintaining backwards compatibility to older applications. For applications that don't want/need to modernize then they'll need this stable OSG to keep maintaining their applications in a usage state.

Personally, I'd like to see folks migrating from the OSG to the VSG. It's just a better scene graph in many ways, I learned lots of lessons about scene graphs in developing and maintaining the OSG, and working with application developers over two decades, the VSG is distillation of what I think a modern scene graph needs to be.

There is lots of scope discussion about how we evolve the OSG to enable folks to migrate from OSG/OpenGL to VSG/Vulkan, part of this will be gathering experience and sharing it on places like this forum, as well as work on the OSG itself or the osg2vsg migration library,

As more folks migrate to the VSG they'll also get used some of neat features that it has and want to see those back-ported to the OSG - for instance adoption of the C++17, modern C++ threading, the vsg::Allocator for more efficient memory allocation, more GLSL style maths classes like the VSG has, or even the file path handling, There are lots of little things in the VSG that just make life for programmer easier.

However, as much as pulling some elements of the VSG into the OSG might round off some of the OSG's rough edges better, the OSG won't be able to magically be modernize and perform anything close that you can get with the VSG/Vulkan, the focus will have remain maintaining backwards compatibility.

For this we appreciate your thoughts about other developments in the industry, for instance:
Pixar's USD becoming a standard for 3D scene representation (NVIDIA has been pushing very hard on this). Will it be enough writing a USD importer/exporter plugin for OSG/VSG?

I haven't follow Pixar's USD effort, but if it does become a standard then it'll join the rest of the "yet another" industry standard like Collada and GLTF.

The VulkanSceneGraph's vsgXchange library uses Assimp for loading 3rd party models so if USD support gets added to Assimp then we'll automatically get it.

Otherwise it would be case of a member of the OSG or VSG community developing a loader for USD, or commissioning a dev like myself to develop it.

Also, NVIDIA has been proposing MDL as the industry standard for PBR material definitions and exchange format.
Is this something that is currently supported or can be supported by OSG/VSG, not only for importing but also for rendering
accurately?

Same situation as with USD, it's just another "standard" that we can choose to support based on whether it offers value to end users and their is someone who wants to contribute it or some organization to help fund it's development.

Basically all these new standards just add to all the other standards that are out there, there won't be one that comes along and makes all the rest irrelevant.

Real-time ray tracing and path tracing. Can this be achieved currently? by means of shaders?

The VullkanSceneGraph supports the Vulkan ray tracing extensions.

What things can be achieved with other platforms such as Unreal, O3D or Unity that cannot be achieved with OSG already?

I don't have experience with these projects so can't personally comment on detailed comparisons. In general Unreal and Unity are more modern and provide much more functionality out of the box, and asset tools that the OSG doesn't have, but there are essentially game engines design for games, that can be for more general graphics applications but they'll have lots of SDK overhead associated with all those game related functionality that have no relevance for general purpose graphics applications.

However, what the OSG has is backwards compatibility with existing OSG based applications. It's doesn't attempt to be a full game engine and gives users quite a bit of freedom in how they put their applications together.

The VSG doesn't have the backwards compatibility that the OSG has, but it's made from the same DNA, with a focus on graphics applications in general rather than a specific market segment. Another advantage the VSG has is cross pollination of the OSG and VSG communities.

[MauFranco]

Thanks a lot for your detailed answers. Looks like VSG is the way moving forward.
All the best,
Mauricio.

[loopless]

My only comment would be that Vulkan is not supported (or the drivers are of poor quality) on older hardware encountered out there in the real world ( particularly on laptops). Industrial users tend to hold onto old equipment until it dies.

[openscenegraph]

On Mon, 5 Dec 2022 at 17:13, Andrew Cunningham ***@***.***> wrote: My only comment would be that Vulkan is not supported (or the drivers are of poor quality) on older hardware encountered out there in the real world ( particularly on laptops). Industrial users in particular tend to hold onto old equipment until it dies.

That's a big reason for maintaining OpenSceneGraph for those users who are stuck supporting users on really old hardware. An alternative might be to just software rendering of Vulkan on such systems. Performance would not be great but might be good enough for providing backwards compatibility to ancient hardware. Each user of the OpenSceneGraph will have to determine what is appropriate for their applications and their users. Early adopters have already moved over to the VulkanSceneGraph, some even had commercial applications in the hands of customers 2 years ago. Over time the number of users that the VulkanScenGraph will be suitable for will increase, but I don't see there being a drop dead date for OpenSceneGraph users, it's open source you have plenty of options for maintaining applications.

…

Message ID: <openscenegraph/OpenSceneGraph/repo-discussions/1176/comments/4315401@ github.com>

[xarray]

I'm developing a long-term project named osgverse (https://github.com/xarray/osgverse), which is a non-intrusive PBR-based rendering framework and scene editor based on OpenSceneGraph. It will support most old hardwares and integrated ones, as well as different platforms in a much convenient way. I've rewritten the postprocessing pipeline, realtime shadow, and will aim to implement a Unity like engine for developers and artists.

I will release a 1.0 version based on OpenSceneGraph 3.6.5 first. And then try to make the underlying module compatible with VSG if possible. I've leaved the community for a long while (to work as a UAV/AGV developer) and now I can finally back to work as a 3D software engineer. ^_^