Moving a mature OpenSceneGraph application to VulkanSceneGraph is not just a recompile or a search-and-replace. Moving 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, and when.
Why VulkanSceneGraph exists
OpenSceneGraph is built on OpenGL, a respected 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 in specific situations, so we know both engines from the inside.
The difference between OSG and VSG
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 much of that for you, but you can still hurt yourself.
- 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 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 right 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 clearly on the table.
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 touches 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.
Frequently asked questions
Should I migrate my OpenSceneGraph application to VulkanSceneGraph?
Not always, and we will tell you so. Migrate when you need Vulkan's performance and lower overhead, when you target platforms where OpenGL is being retired, or when you are starting a long-lived project that should be born on the successor. If your app is stable, leans on OpenSceneGraph NodeKits with no VulkanSceneGraph equivalent yet, and does not need the performance, staying on a well-maintained modern OpenSceneGraph build is often the right call.
What is the difference between OpenSceneGraph and VulkanSceneGraph?
The scene-graph concepts carry over, but the machinery underneath changes. OpenSceneGraph is built on OpenGL, which is decades old, effectively frozen, and being retired on some platforms. VulkanSceneGraph, from OpenSceneGraph co-creator Robert Osfield, is a lean modern C++17 scene graph on Vulkan that gives the GPU explicit instructions instead of routing through a heavy legacy driver.
How much faster is VulkanSceneGraph?
It lowers CPU overhead and, on the right workload, runs several times faster than the equivalent OpenSceneGraph scene. The gain depends on the workload, so part of the assessment is deciding whether your app is one that benefits.
Is a migration just a recompile or a search-and-replace?
No. Vulkan is explicit: 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 much of that, but shaders move to SPIR-V, and paged terrain, custom loaders, and NodeKit data need porting work.
What happens to my NodeKits, terrain, and file loaders?
Models, textures, and scenes come across with conversion tooling (osg2vsg and vsgXchange), but paged terrain, custom file loaders, and NodeKit-specific data need porting. OpenSceneGraph has two decades of NodeKits, and the younger VulkanSceneGraph ecosystem may need a replacement or a fresh implementation for a dependency you took for granted.
What do I use for terrain and text after moving to VulkanSceneGraph?
For terrain, the path is osgEarth to Rocky, Pelican Mapping's Vulkan-era successor. For GPU text, our Slughorn library already spans both OpenSceneGraph and VulkanSceneGraph.
Can you migrate incrementally, or do you rewrite from scratch?
Either, whichever the situation calls for. We can migrate an existing codebase incrementally, write the replacement from scratch, or do a selective rewrite of the core with a bridge to the parts that are not ready to move.
Why AlphaPixel for this migration?
We are among the oldest and most experienced OpenSceneGraph and VulkanSceneGraph developers active today, and we have collaborated directly with Robert Osfield, including work that made OpenSceneGraph itself faster. Because we work in both engines every day, we are not learning on your budget.
Talk to us
Tell us what you’re building and where it’s stuck. We’ll tell you straight whether it’s something we can help with, and how we’d approach it.
Or see how we run consulting and software development engagements.
