OpenSceneGraph to VulkanSceneGraph Migration

Moving a mature OpenSceneGraph application to VulkanSceneGraph is not a recompile, and it is not a find-and-replace. It is a move from OpenGL to Vulkan: from an implicit driver that hid a great deal of state to an explicit API that hands you both the control and the responsibility. We do this migration for a living, and we help you decide whether you should do it at all.

Why VulkanSceneGraph exists

OpenSceneGraph is built on OpenGL, an API that is decades old, effectively frozen, and being retired on some platforms. Apple has deprecated it, and it was never native on modern consoles. Robert Osfield, who co-created OpenSceneGraph, designed VulkanSceneGraph as its successor on Vulkan: a lean, modern C++17 scene graph that gives the GPU explicit instructions instead of routing everything through a heavy legacy driver. The result is lower CPU overhead and, on the right workload, frame rates several times faster than the equivalent OpenSceneGraph scene. We have collaborated with Robert Osfield directly, including work that made OpenSceneGraph itself significantly faster, so we know both engines from the inside.

What actually changes

The scene-graph concepts carry over, but the machinery underneath is different, and that is where a migration lives:

• OpenGL to Vulkan. Vulkan is explicit. There is no fixed-function pipeline, no immediate mode, and no forgiving driver to clean up after you. Command buffers, descriptor sets, pipelines, and synchronization become yours to manage. VulkanSceneGraph handles most of that for you, but code that reached down into OpenGL directly does not survive the move.
• Shaders. GLSL is still GLSL, but it is compiled to SPIR-V, and fixed-function and legacy shader assumptions have to be rewritten as explicit modern shaders.
• Data and assets. Models, textures, and scenes come across with the conversion tooling (osg2vsg and vsgXchange), but paged terrain, custom file loaders, and NodeKit-specific data need real porting work.
• The NodeKit ecosystem. OpenSceneGraph has two decades of NodeKits behind it. The VulkanSceneGraph ecosystem is younger, so a dependency you took for granted may need a replacement or a fresh implementation. For terrain, the path is osgEarth to Rocky, Pelican Mapping's Vulkan-era successor. For GPU text, our Slughorn library already spans both worlds.
• Ownership and lifetime. VulkanSceneGraph uses its own intrusive reference counting, familiar in spirit to osg::ref_ptr but not identical, and its traversal and record model is rebuilt around Vulkan command recording rather than OpenGL state.

Migrate, rewrite, or stay

Not every application should move today, and we will tell you so. If your app is stable, leans on OpenSceneGraph NodeKits that have no VulkanSceneGraph equivalent yet, and does not need the performance, staying on a well-maintained modern OpenSceneGraph build is often the right call, and we can modernize that instead. Migrate when you need Vulkan's performance and lower overhead, when you are targeting platforms where OpenGL is being retired, or when you are starting a long-lived project that should be born on the successor rather than the predecessor. Sometimes the honest answer is a selective rewrite of the core with a bridge to the parts that are not ready to move. We help you make that call with the tradeoffs on the table, not a pitch for the bigger job.

How we do it

We start by assessing what your OpenSceneGraph application actually uses: the NodeKits, the custom rendering, the file formats, and the places it touched OpenGL directly. Then we port the core scene and rendering to VulkanSceneGraph, convert or rebuild the assets and shaders, replace or re-implement the NodeKits that have no successor yet, and validate the result against the original so the picture and the behavior match. We can migrate your existing codebase incrementally, or write the replacement from scratch, whichever the situation actually calls for. Because we work in both OpenSceneGraph and VulkanSceneGraph every day, and alongside the people who build them, we are not learning on your budget.

Who works on it

AlphaPixel is a US-owned small business, founded in 2004, and among the oldest and most experienced OpenSceneGraph and VulkanSceneGraph developers active today. DLA DD2345 / ITAR registered. We take closed-source defense work and open source alike, and we do not sell an engine, so our advice is not a sales pitch for one.