My last post comparing Ogre3D to OpenSceneGraph seems to have directed a fair amount of traffic towards this blog, so I wanted to write a follow-up comparison, now that I’ve actually used both for quite a while. Ogre3D and OpenSceneGraph have similar features – animation, shaders, particles, terrain, shadows, etc – but are very different in their overall design, respective capabilities but also the communities that grew up around these engines. I am not going to compare each individual feature (that would be way too long of a post!) but instead will compare from a high level perspective. We are going to look at the latest stable versions, that is Ogre3D 1.9 (released on November 24, 2013) vs. OpenSceneGraph 3.4.0 (released July 20, 2015).
Let’s take a look at the compelling aspects:
Reasons to prefer Ogre3D
1. Ogre3D is well documented
Quality of documentation can be subjective as it really depends on the type of documentation you prefer – some people prefer written tutorials, some people rely on a Wiki with code snippets, and others just learn by doing, looking up API references when necessary. That said, generally speaking I would consider Ogre3D to be better documented than OpenSceneGraph. The API reference is more extensive and verbose, plus we have the excellent manual written by Ogre3D’s founder, Steve Streeting, that covers the entire engine in-depth.
The main source of documentation for OpenSceneGraph is their mailing list / forum, and a (very outdated) wiki. I wouldn’t strictly consider a mailing list “documentation”, but the quality of information you get from there is very good. Often times I search for a particular subject and the first result is a mailing list post from OSG author Robert Osfield, explaining a particular subject or feature in all detail just like a book would.
Speaking of books, there are some books are available covering Ogre3D and OpenSceneGraph, but I haven’t read any of them so can’t attest to how good they are.
2. Ogre3D is easy to use
When I first started with 3D graphics, Ogre3D was one of the first engines I’ve used. It was very easy to find your way around and get a basic scene going, and from there I just worked my way up to where I am today.
In OpenSceneGraph, you’ll often find more than one way of achieving the same result – which is a testament to its great flexibility, but can be a downside for the learning curve. Want to move or rotate a scene element? Here’s 3 different transform nodes you can choose from. Want to change the appearance of a model? Here’s 20 different StateAttributes, good luck finding the one you need. Want to hide a model? Go ahead and change its “node mask”. Want to move the camera manually? You’ll need to somehow calculate your “view matrix”. For a beginner in 3D graphics, all this could be overwhelming. In Ogre3D, these kind of tasks are more streamlined which eases the learning curve.
3. Ogre3D supports many rendering systems
In Ogre3D, calls to the graphics hardware are hidden away behind a “Rendering system”. There are multiple implementations for this rendering system, and before running an Ogre3D application the user can typically choose which rendering system to use. The currently available rendering systems are:
– OpenGL 3.x (still in “beta” as of Ogre3D 1.9)
– OpenGL ES
– Direct3D 9
– Direct3D 11 (still in “beta” as of Ogre3D 1.9)
The idea is to give the user more choice while requiring no additional effort from the application writer. This choice can be useful because some graphics drivers on Windows are said to perform better with the Direct3D API, while on other OS’s OpenGL is your only option.
Unfortunately, this extra choice doesn’t come for free – Ogre3D is pretty good at abstracting away the differences between these rendering APIs, but there are some things that can’t be abstracted away. For example, in Direct3D you have to write shaders in the HLSL language, but OpenGL uses the GLSL language. These languages are pretty much the same aside from syntactic differences, but it’s still frustrating to try and support both – you’ll either have to write all your shaders twice, or use your own abstractions to generate API-specific shader code.
So generally speaking, an Ogre3D application will still be written with one (or more) of these rendering systems in mind, and the more of these you want to support, the more of a maintenance burden you will have.
OpenSceneGraph on the other hand supports only OpenGL, OpenGL 3.x and OpenGL ES. Also, the choice is made at compile time rather than runtime, making the decision up to whoever is compiling the package rather than the end user.
4. Ogre3D is fun to play around with
This is a bit hard to explain, but when I have a look around the Ogre wiki and forums, I see tons of posts with code snippets, material scripts, compositors and shaders that people have created “just for fun” and decided to share with the community.
I think one reason we’re seeing this tendency is because Ogre3D is a simpler engine, and the process for creating materials and compositors is all streamlined. You can write a material script or compositor script as a simple textfile, any other Ogre3D user can then use it simply by dropping the file into their asset folder.
OpenSceneGraph does feature material scripting as well, but the format is different. It’s part of their general purpose scene serialization library, so the material script files look a bit more abstract than the data-driven format that Ogre3D uses. OpenSceneGraph does not feature compositing scripts, although there is a community addon for that purpose.
Maybe another reason that we’re seeing more “snippets” for Ogre3D is that it’s more commonly used by hobbyist game developers that are just tinkering around – and thus more willing to share their creations – vs. OpenSceneGraph having a large community in the professional 3D space, people that are creating actual products and have busy lives.
Reasons to prefer OpenSceneGraph
1. OpenSceneGraph is flexible
As I hinted in the last article, OpenSceneGraph has a lot more functionality built into its scene graph than Ogre does – callbacks, node masks, node visitors, the ability to create custom nodes and custom StateAttributes, and the ability to attach a node to multiple parents, to mention a few. So what is all that good for? I certainly don’t expect a beginner to get use out of all these features, but they’re part of what makes OSG so extensible and customizable for your own needs. In addition, a flexible core library serves as the foundation for adding more features as “modules” that the core does not depend on, which we will look at in the next bullet point:
2. OpenSceneGraph is modular
Modularity is an important aspect when looking at the usability of a software library. A non-modular piece of software will become useless if one feature in it is not up to your requirements. With a modular design on the other hand, the user can simply decide to not use that particular module and swap it out for a different module, or create his own module.
OpenSceneGraph is incredibly well designed from a modularity standpoint. The core libraries are: “osg” handling the scene graph structure, “osgUtil” implementing rendering tasks and algorithms, and “osgViewer” handling the platform-specific render window creation. In osgViewer, you can easily plug in your own implementation of an osgViewer::GraphicsWindow, which allows for painless integration of OSG with third-party windowing code like SDL2. In Ogre3D this kind of integration is more difficult to pull off (I won’t go into details here, but have a look around for Ogre-SDL-QT-whatever integration guides – the short version of it is that it’s platform and rendering system dependent, and there are some bugs).
So called OSG “node kits” handle more specific features – shadow mapping (osgShadow), particles (osgParticle), animations (osgAnimation), etc. The core library doesn’t depend on any node kits, so the user can pick and choose whatever kits they want or write their own replacement kits. The “osgDB” module handles the reading and writing of files and management of a file “library”, but its use is optional – you can just as well plug in your own resource system by passing std::ifstream*’s to the OSG codecs. Speaking of codecs, various “plugins” that are loaded at runtime handle the reading and writing of various image, video and model formats.
Compare that to Ogre3D, which is modular to a certain degree (e.g. the rendering systems, terrain system, and codec plugins) but falling far short of what OpenSceneGraph has to offer in that respect. The biggest problem for me was that the resource system and the animation system are hardwired into the OgreMain core so not replaceable. This was one of the reasons we eventually decided for OpenMW to ditch Ogre3D and port to OpenSceneGraph.
3. OpenSceneGraph is fast
OpenSceneGraph is probably the fastest free and open source 3D engine in existence. While you’re not going to find extreme optimizations like SIMD instruction sets or “AZDO” OpenGL hacks that would add a lot of complexity – OpenSceneGraph is simply fast by design because it can run its drawing commands in parallel with scene culling, animation and whatever else the user is running in the main thread. The drawing commands themselves are also quite fast. OpenSceneGraph uses a state graph to manage OpenGL state, minimizing the amount of redundant state changes done. OpenSceneGraph also includes some auxiliary tools to help you get the most performance out of it: a scene graph optimizer tool, and a profiling overlay.
When OpenMW was ported from Ogre 1.9 to OpenSceneGraph, I noted 300-400% the framerate when it comes to “raw” drawing performance, and in the end a 250% framerate when all the other subsystems were back in place. This was a particularly complex port though so it’s not a fair comparison by any means. Please do your own benchmarks and draw your own conclusions!
The upcoming Ogre 2.x versions are supposed to resolve performance problems in 1.x, but since we are looking only at the latest stable versions we can’t look at it in this article (and I don’t have any experience with Ogre 2.x, either).
4. OpenSceneGraph is stable
“Stability” of a software library refers to the ability to upgrade your applications to a newer version of the library with minimal hassle. OpenSceneGraph has many users in the professional 3D space that have a vested interest in keeping their products updated, thus stability is important – and this is something OSG author Robert Osfield takes very seriously. Every change is carefully reviewed from a compatibility standpoint before it gets merged.
As for stability in Ogre 1.x versions, my experience has been okay-ish… there were a couple incidents that I felt unnecessary. Pointless renamings that broke old user applications (“StringUtil::BLANK” to “BLANKSTRING”, particle API renaming), and a massive breakage of the resource API (that was thankfully fixed before the 1.9 release). Also note that the future of Ogre with the upcoming 2.0 and 2.1 versions is anything but “stable” – the changes are so massive that porting over a large application that used 1.x can be a scary undertaking. These drastic changes were made to resolve all the various performance bottlenecks in Ogre in one fell swoop.
We can’t say that one or the other engine is “better” – your mileage will vary depending on the things you use it for. Both are excellent engines and – with enough effort – can be made to do whatever you want, really. If you’ve already started a project in either engine, there is most likely no compelling reason to switch. If you are new to 3D rendering, I’d recommend starting with Ogre and see where it takes you. If you already have a bit of 3D experience, you should be able to make up your own mind based on the arguments above. I hope this post helped you decide either way. Happy coding!