Robert Osfield and Don Burns
Windows, Linux, Mac OS X, Solaris, SunOS, FreeBSD, Irix, Playstation
Languages Written In:
None (be one!)
OpenSceneGraph is an portable, high level graphics toolkit for the development of high peformance graphics applications such as flight simulators, games, virtual reality or scientific visualization. Providing an object orientated framework on top of OpenGL, it frees the developer from implementing and optimizing low level graphics calls, and provide many additional utilities for rapid development of graphics applications.
osgedit: allows editing some of the features in scenegraph
|License Name||Price in $US||Source Code Included?|
Showing 1-7 of 7
First I thought I would start by saying that alot of features have been added that are not listed so check their website for more details.
I have been using OpenSceneGraph for about 2 years now. It is a very stable and mature engine with a full set of features. The OpenSceneGraph Engine uses OpenGL as its rendering engine. I have found it to work very well on both Windows and Linux(It works on Macs too, but I don't have a Mac).
Probably its most powerful/unique feature is the terrain rendering system. You can render a terrain the size of North America or Europe. It makes use of a Paged LOD System that can load geometry on the fly from your disk drive. Another strong feature is the NodeKit system that allows you write modules for custom features or to load custom 3d formats unlike some of the other engines that only support a special format. The osg file format is the richest 3D format I have every used.
OSG has a very clean code architecture and uses CMake to compile files which is much easier to use then make or project files.
The biggest weakness of OSG is poor documentation, and a steep learning curve. The source comes with lots of coding examples but almost no documentation explaining the basic classes and features. There are now several books you can buy that can help with this but they are not free.
There are large number of applications written using OSG which shows it a full featured engine.
If you are looking to write a large scale application give OSG a look.
Okay, I'm definately venting my frustration with the OSG community which has utterly let me down with their lack of support. But, I feel like my problems with this engine are indeed legitimate and will be shared by many others.
OpenSceneGraph has terrible, terrible documentation. The API is mearly function signatures and there really is no all inclusive programmer reference with, say, a table of contents, index, and a beginning and an end. What they have is a collection of random tutorials (some pretty good, some useless), a huge library of examples, and a mailing list. The mailing list is full of a bunch of people that are very active, very smart and entirely uninterested in questions that don't "challenge and intrigue" them. My project included drawing approximately a thousand quads on the screen, that would shuffle around independent of one another. In order to do this I had to touch every vertex of every quad every frame. Straight OpenGL can handle this at nearly 100 fps. With OSG I could barely clear 30 fps. This is the question I posted to the mailing list - I would have enjoyed figuring this out for myself - but how the heck can I do any research on the subject without any sort of documentation?!? The responses I received ranged from "You didn't ask the question correctly" to "I don't have time to help you figure out your performance problem" to "Try [x], [y] and [z]". All responses were (I'm sure) completely honest, but, in the end, not helpful. So about three weeks ago I started reading through the code (good ol' open source) and today I'm as frustrated with this engine as ever.
OSG has many many features and what features I have managed to figure out (again, on my own) have worked flawlessly. Before I had to start manipulating individual vertices I had no problems with the frame rate. From what I see, it's a great engine - just good luck trying to figure it out! There is, as I said earlier, a huge library of example projects that come with the source. These have been a saving grace for me, but, in the instance when I have a specific issue that I need to resolve, they have still fallen short.
My final thoughts:
If you are a veteran OpenGL programmer and can figure a problem like mine out by looking at the code for a graphics engine ("scene graph", whatever) then OSG may be a good fit. But if you are like me and don't necessarily enjoy "hacking" an open source project in order to divine its secrets to make it work for you, then you may not be interested in this one. Pretty easy to install on Windows, do NOT attempt to install it on Linux without APT or some other installation and dependancy checking utility (these are words born of experience, my fine fellows).
Edit: I don't know what the following reviewer is talking about when he mentions the so called "API Documentation". I'm trying to figure out the ImageStream object right now and the only information the so called "API Documentation" provides is function signatures. I can't believe someone would speak so highly of such pitifully useless information.
Another edit: I hate OpenSceneGraph so very much. So very very much. What a terrible engine. Irrlicht is so much better, easier and more friendly to the casual user. This is just junk.
This library impresses with the cleanliness of its hierarchy, completeness of its features, and abstractions/class designs that Just Make Sense. I don't know too much about Design Patterns, but I imagine a lot of what I vaguely perceive as "elegant" falls out of the main authors' avowed full embrace of such mature software engineering methods. The scene graph traversers and behavior specifiers are particularly elegant.
I also like that OSG provides various levels of integration with the windowing system. If you just want a quickie visualizer, with full low-level control of the renders (like with raw opengl), you can have a non-interactive window up in minutes. If you want the rendering in a separate thread, there's a slightly more complicated class for that. If you want full interactivity, there's a class for that too. In other words, OSG really is a general graphics engine that is also well-suited to game development, as opposed to many of the other libraries on this list, which were designed with an exclusive focus on game dev. For example, OGRE has added lots of cruft that might be useful in large-scale game projects, but as a result you need scads of boilerplate code just to get started with an object in a window. On the other end of the spectrum, Irrlicht has a few functions and classes that streamline getting started, but underneath those prepackaged functions was alot of hackishness. The moment you go slightly under the hood, you start spending alot of time fighting or correcting this messiness. OSG has a simple interface, but doesn't hide anything to those who want to get under it. And the machinery underneath is well-coded.
Initially, there was some awkwardness since I had to "learn" (it takes 3 minutes) about smart pointers to get started, but after that, the examples and the API documentation pretty much give you what you need to take off and keep running. This is a good thing, since there's there aren't any friendly Irrlicht-style tutorials!
From following the OSG mailing list, I hear they've recently added introspection features to enable easier binding to scripting languages. I hope they regain Python support soon.
OSG is an absolute dream. But it's a nightmare to set up, and the documentation is vague and could possibly be good if only one of the developers would write out a good page or two explaining a couple of basic things.
As far as what OSG can do visually, you can't dispute it. Being focused on OpenGL is a huge plus. You can't dispute that OpenGL will run 10 - 20 frames faster than Direct-X on an nVidia graphics card.
Not trying to be God helps OSG out too. Ogre does anything and everything, but it does none of it well without editing. Edit the source though, and it's tough to get it to compile. Irrlicht has the same problem except twice as often. And Nebula 2, well, I can't use the words to describe Nebula here, but I'm sure random spattle will get my point across: Nebula 2 is straight lsjdfoaksjdf lksjadfkasjdflk lkasjdfklajsdf lkajsdfklaj.
Take a look at Open Scene Graph, and give it time to grow on you. You'll find that it will love you more than you will love it.
This is how should looks every scene graph. Optimized scene graph cost of OpenGL port only. There are two things could be added: (1) dx port, (2) indoor scene graph management.
This is by far the best graphics engine I have seen. I love Ogre, its performance and quality are very promising. However, OpenSceneGraph is having better quality on class hierarchy because of the SceneGraph design is very advance. OpenSceneGraph is a very high performance game/rendering engine because of the culling. Besides, the state of art SceneGraph architecture is giving users breath-taking benefits such as minimum state changing, optimized for rendering performance and flexibility on scene modifications.
Comparing to Ogre, OpenSceneGraph is easier to use for developers. I have a glance in the Ogre source code and found that their class design are a bit too complicated to make its engine compatible to many different platforms including GL and DX, Windows and Linux. While OpenSceneGraph is using OpenGL as the rendering engine, it is optimized for specific API and it does have less compatibility code overhead.
I love it...good job OpenSceneGraph!!!
It does what it says it does... Good product.