Developers wishing to add graphics capabilities to their applications have to either deal directly with the low-level APIs to drive the graphics and compute hardware, or choose from a collection of higher level APIs that are more focused on the needs of application developers than the underlying low-level APIs. A good high-level API will not only enable developers to be more productive but also provide better out of the box performance and visual quality, with the high-level API packaging up the expertise and time put in by specialists in high performance graphics and compute.

Scene Graphs

A common concept utilized by high-level graphics APIs is a Scene Graph. Scene Graphs are an example of a Directed Acyclic Graph (DAG), where a tree like hierarchy is used to represent the scene. Nodes in the graph may be internal group nodes, support culling, such as view frustum or level of detail culling, through to behavior like switches or sequences, or represent state or geometries that are passed to the GPU for rendering.

Features vs Generality

High-level APIs may choose to remain quite minimal in feature set and leave more functionality for the application developer to implement, while others build in many different areas of functionality. Broadly speaking the wider the range of features provided by an API the more domain specific it becomes as each additional feature will choose a particular approach or 3rd party dependency that is likely to work better for some domains than others. The more features are bundled together, the more choices are made for you, and the more likely it is they’ll be inappropriate for your needs and just bloat the codebase and binaries. The advantage of the greater feature integration is potentially providing a cohesive system of features that work well together.

Examples of high-level APIs with a relatively modest feature set and tight focus would be scene graphs like Open Inventor or Performer, while ones that encompass an extensive feature set would be game engines like Unreal or Unity. These two approaches aren’t incompatible - a game engine could contain its own scene graph or a 3rd party scene graph, the latter approach was taken by the Delta3D project that built upon the OpenSceneGraph.

Abstraction vs Encapsulation

Some high-level APIs choose to build in low-level API abstraction layers so they can support multiple APIs such as Vulkan, OpenGL, multiple versions of Direct3D, Metal etc. - this brings us to the perverse realm of the hardware abstraction layer abstraction layer. Such extra abstraction layers add complexity and move the application developer further away from what they are attempting to run on the hardware. This approach also adds more code for the high-level API maintainer to write, test, debug and support, and a far greater range of permutations of hardware and APIs to test and support. This poor engineering approach has been born from the real or perceived issues with how well the cross platform low-level APIs are supported across platforms, it’s a workaround to the attempts of Microsoft/Apple/etc. to exert vendor lock-in.

An alternative approach used by some high-level APIs is to simply encapsulate the low-level APIs rather than abstract from them, this keeps the application developer closer to a 1:1 relationship with the data and processing they are managing on the hardware. Taking this path could limit portability to particular OSs, or hardware, but thankfully with OpenGL and Vulkan they are designed to be both OS agnostic and able to handle a wide range of hardware so the choice to encapsulate OpenGL or Vulkan need not limit portability over the low-level API abstraction approach.

A Brief History of High-level APIs

One of the first widely used high-level APIs for real-time 3D graphics was IRIS Inventor that was started at SGI in the late 1980’s and followed a scene graph approach to represent a 3D scene. It was created to make development of 3D graphics applications easier as the low-level nature of IRIS GL was a barrier to entry. Then it was succeeded by Open Inventor which used OpenGL as its base and became widely adopted in the scientific and engineering sectors where ease of use was more critical than maximizing performance. Inventor’s strength lay in its embodiment of the scene graph concept in such a flexible and extensible way. Its weakness was in the way its design limited performance and scalability.

Performer, created in 1991 by developers from the Inventor development group, focused on performance rather than usability. Performer was designed to work multithreaded, scaling to multiple CPUs and multiple GPUs in order to utilize SGI’s high-end hardware such as the Onyx line of graphics “super” computers. These have far less performance and capabilities than modern phones, but during the mid-90’s they were the world’s most powerful graphics systems.

Cosmo3D - mid 1990’s there was yet another SGI scene graph! Created to provide a unified scene graph that was scalable and fast like Performer, and with better usability like Inventor. SGI worked with other vendors to create a standardised OpenGL++ scene graph, using Cosmo3D as the base.

Fahrenheit - late 1990’s. SGI and Microsoft collaborated to create a low-level API successor to OpenGL, and high-level successor to Inventor/Performer. At the high-level they used Cosmo3D as a starting place. Microsoft strung SGI along for a year before the project collapsed, with Microsoft using the IP agreement to enable more advanced features to make it into Direct3D. Microsoft’s plan all along?

The collapse of the Fahrenheit project left a vacuum in the world of standardized high-level APIs, the proprietary scene graph world had failed to deliver a standardized solution as had been done for low-level APIs. In the late 1990’s Open Source/Free Software was growing in significance and offered an entirely different approach to creating software, a number of hobby level projects sprung up like Plib through to CrystalSpace but none had anything close to the capabilities of the professional APIs like Inventor, Performer and other proprietary APIs like Vega.

In 1999 the Fraunhofer Institute created a consortium to develop the OpenSG project, from the outset it had high aspirations for delivering an Open Source cross platform, scalable, high performance scene graph - embracing all the facets that the industry had been wanting from Fahrenheit.

At the same time, completely independently and initially unaware of the OpenSG project, Don Burns, an SGI engineer, working in his spare time on a home-built Hang Gliding Simulator, created a small scene graph library, on top of OpenGL, simply because Performer hadn’t yet been ported to the Linux PC. Don sought assistance from Robert Osfield, a fellow software engineer and Hang Glider pilot with knowledge of aerodynamics to help with the development of the flight model. Robert ported the nascent scene graph library to Windows and the decision was made to publish the library as Open Source under the LGPL license. Originally named SG, for Scene Graph, Open was added to the name and the OpenSceneGraph project came into existence with a tar.gz file published on a single web page. Two engineers in their spare time were hacking away on a hang glider sim with no lofty goal beyond just getting a hang glider, a flying site with a hill and a few trees rendered.

In 2000 the vis-sim and GIS sectors desperately needed a modern, professional grade graphics scene graph alternative to the proprietary scene graph projects which were poorly supported, slow moving or failing. OpenSG and OpenSceneGraph both were contenders but paradoxically the grand plans of the OpenSG project meant its release cycle was too slow for an industry desperate for a new scene graph, while the OpenSceneGraph was developed in spare time, with no formal plans or funding but a rapid release cycle and responsive lead developers and gained acceptance in the vis-sim and GIS sector.

By 2001 the OpenSceneGraph had gained a commercial following sufficient for Robert and then Don to leave their full-time jobs and go fulltime and pay the bills through consulting, bespoke development work and training services. Through the first decade of the new millennium the project gained a following in both commercial and open-source applications with thousands of developers worldwide using it, and over 500 developers having contributed directly to the software code base. The strength of the OpenSceneGraph lay in the expertise and responsiveness of lead developers and the choice to encapsulate OpenGL in a clean way, without attempting to abstract away from the API layer.

In 2005 Unity was released, a game engine and tools with a licensing model that was free for hobby/small scale use. Unity evolved over the years from a niche of the market to wide market acceptance.

Around the middle of the second decade OpenGL’s evolution was under serious strain with CPU and GPUs capabilities so far removed from the capabilities of hardware in the early 90’s. Driver quality across vendors and performance remained a serious issue for application developers. Small incremental changes were no longer sufficient to keep up, and the attempt at introducing the OpenGL Core Profile only fractured and complicated the task of supporting OpenGL. For high-level APIs like the OpenSceneGraph that focused entirely on OpenGL and OpenGL ES the troubles with OpenGL and its own age began to make it more cumbersome to support and use.

In 2014 the Unreal Engine 4 was released with a new licensing model, with the full source code released and royalties charged on game revenue. Having a professional grade game engine and tools widely available changed the competitive landscape for high-level APIs.

In 2016 Khronos released Vulkan as the successor to OpenGL, which then presented the question for high-level APIs - do they add yet another low-level hardware abstraction layer to the ones they already support or create new high-level APIs specifically for Vulkan building upon its strengths. Game engines that adopted Vulkan showed modest performance gains over OpenGL and have increasingly become the preferred choice for cross platform games.

The advent of Vulkan and the clear need for it given OpenGL’s failings presented the OpenSceneGraph with a dilemma. The OpenSceneGraph is written to be an OpenGL scene graph - it embodies the OpenGL++ dream held by engineers in the 90’s, the whole design is built around the OpenGL state machine and the OpenGL FIFO and threading constraints. Vulkan has a completely different API and architecture to OpenGL and a significantly lower CPU overhead. For the OpenSceneGraph to adopt Vulkan and still support OpenGL would require a major rewrite of the API and internal architecture and implementation, handling two very different low-level APIs would require significant compromises in the way features are exposed in order to support both OpenGL and Vulkan. Such considerations would make the final high-level software incompatible with older versions of the OpenSceneGraph and deliver performance that is less than either OpenGL or Vulkan is capable of due to the extra abstraction layer that would need to be introduced.

It was clear to OpenSceneGraph project lead Robert Osfield that a new scene graph built for Vulkan using modern C++ would be the best choice for exposing all the new capabilities that Vulkan brings and to keep the CPU overheads as low as possible so that performance could fully take advantage of Vulkan’s low CPU overhead. For instance, if your existing scene graph has a CPU overhead of 10ms, and OpenGL adds another 5ms then the best-case improvement from going to Vulkan with a 1ms CPU overhead would be a 10.5ms frame-time - a 43% improvement, even though Vulkan might be 10 X faster. To get a 5 X improvement overall you also have to make the scene graph 10 X faster as well.

In Spring 2018 Robert Osfield was approached by a company that used OpenSceneGraph for vis-sim that wanted to fund the initial development of a new Vulkan based scene graph. Work began on the VulkanSceneGraph in the 3rd week of May 2018. Four and a half very intense years later VulkanSceneGraph-1.0 was released on the 13th November 2022.

Prev: Vulkan Next: Development Principles