modsim.org OSGEdit Product Review by

Ruben Lopez

3D engines are the essential bricks for building today's graphics applications, but as feature lists grow to support the latest techniques, they become more and more complicated. If you have to build a scene by hand either by editing an ASCII format or by writing a little program to merge models, you spend a lot of time. Any engine provide exporters for digital content creation (DCC) tools and loaders for common file formats, but artists end depending on programmers when they need to use any engine feature not present in the DCC tools. Another common problem in the content creation pipeline is the difference between the aspect of the scene in the content creation tool and in the realtime renderer.

OpenSceneGraph is an open source high performance scenegraph library that is evolving very fast. As most engines, it already has lots of features that can't be mapped to every content creation tool. As an OSG user, I found myself lots of times editing the ASCII file format by hand, finding unmatched brackets, writing scripts for scene compositing, and little programs to generate a complex scene. I knew that this wasn't the right way of doing things.

Project history

OSGEdit started by 2002 powered by the Source Forge hosting and the support of the OSG community (specially Robert Osfield who spent a lot of time answering OSG questions), with the initial idea of being an OSG swiss army knife. It should allow to mount the scenes, make small adjustments, and run typical processes on the scenegraph. Although the idea evolved somehow, the development keeps focused on making a scene composer, not a complete content creation tool with modeling, animation, etc. There are enough DCC tools in the world, and making another one would be useless.

The design of OSGEdit evolved a lot since its birth, from a rigid user interface made completely by hand to the current one, generated mostly dynamically.


OSGEdit allows WYSIWYG editing of particle effects


Every step in the design was made with the invaluable help of Ricardo Rodriguez, who contributed with his experience in design patterns and software engineering. The project implied learning a lot about user interfaces, and we keep learning with each release. Providing an editor for such a big project as OSG is a very hard task, and you can't use the same strategy as with any other application. You have to to automatize the GUI generation, because it is the only way for supporting every OSG feature in a reasonable amount of time. But automatic generation, if not well done, conflicts with usability. We had severe usability problems in the early versions of the editor, and we still have some, but each version enhances this aspect a bit.

Current status

The current strategy for automatic GUI generation relies in a reflection framework built within the editor core. This reflection framework is built almost automatically from a XML description providing meta-data about the OSG classes. The meta-data isolates the OSG details from the user interface, providing a generic mechanism for knowing which attributes are on each class, and which characteristics have these attributes. The user interface is generated from this meta-data, and also the actions that update the scenegraph providing the undo/redo feature.

Since the 0.6.0 version, even the menubar and toolbars are generated automatically from a XML description. This reduces the development cost of adding new tools to the GUI, as you don't need to write, compile and debug source code. But this major release involved also another big change in OSGEdit: the drop of GNOME code. OSGEdit started supporting only GNOME, but one day Clement Bourdarias sent some some patches that implemented a GTK+ branch, with GtkGLExt (instead of GtkGLArea) and ported the code to Win32. This great unexpected contribution changed radically the amount of work for each release, as we had to synchronize the GNOME and GTK+ interfaces. The reason for having the GNOME version was that it had more powerful widgets, but the consequence was the overhead of keeping synced both branches. As we have a lot of Win32 users (maybe more than Unix ones), and most of the original GNOME widgets that we were using are now in GTK+ also, we decided to drop GNOME code and maintain a single branch, avoiding the need of synchronization. Although the project started as a Linux-only application, thanks to the help of people like Clement with his Win32 port, and James E. Hopper with his OSX port, now OSGEdit supports a wider range of operating systems.


WYSIWYG editing of back and front materials

Future Plan

Now we are planning a new design that will make use of the osgIntrospection reflection API. The current reflection framework of OSGEdit is far from complete, and the XML descriptions used for source code generation are written by hand. Moreover, when the API of some supported OSG class changes (ie, grows), it must be updated by hand writing more source code. These limitations, and others more subtle, will disappear by using osgIntrospection, which already supports every OSG bit, and is always synced with each OSG release.

Although the use of osgIntrospection solves some problems, it also creates new ones. For example, the OSGEdit reflection API incorporates documentation for each object property, that is shown as tooltips in the GUI. The OSG reflection API doesn't provide this documentation at the moment. Moreover, the OSGEdit reflection API provides information about visual representation of properties, like distinguishing between homogeneous coordinates and colors (which are represented by the same class in OSG), and of course OSG doesn't provide this information either.




The new design that we are working on will allow integrating osgIntrospection without losing any of the current features, and we are even pushing it a bit further by allowing new features like widget layouts and custom class editors. The basic idea is to decorate the osgIntrospection meta-data with hand-written rich descriptions that enhance the user experience, like the documentation of properties or the appropriate widgets for editing them. This returns us partially to the hand work for supporting OSG, but take into account that this information only enriches what OSG is already providing. OSGEdit will support every OSG bit at every moment, and those for which there is a rich description, will be simply more user-friendly. And there will be less work involved in supporting new OSG features, because we will only need to fill in a form made by an automatic tool instead of writing a complete representation of the OSG API from scratch.



Just in time shader programming with OSG and OpenGL Shader Language


Other enhancement that will provide the new design is the ability to design visual layouts of properties in the editing form of each class, enriching a bit more the osgIntrospection meta-data. And there will be even the possibility of building a custom class editor from scratch, for those classes that are so complicated that an automatic form is quite uncomfortable.

The other big feature that we are planning for the near future is the plug-in system. This involves exposing some of the OSGEdit internals, which are already ready for being exposed. But the real challenge is to provide not only a C++ SDK but also some scripting mechanism. The most probable candidate is python for which there are already OSG bindings. We are also thinking in Javascript, but this would involve a bit more of work because of the OSG wrapper. osgTcl is a good example of how to build a new wrapper very fast by also using osgIntrospection.

Conclusions

The OSGEdit development evolves providing with each release a cleaner and more powerful design, that allows for new features and support for more bits of the OpenSceneGraph. The downside is the low development speed, mostly because it is developed in our free time, but we keep on working keenly with the encouragement provided by our users.

For more information on OSGEdit, please visit its homepage at http://osgedit.sourceforge.net

You can download the latest version of this software at http://osgedit.sourceforge.net/download.html