Release 2.0.7 now available 05/16/2018

Source code updates are also available since this release on our GitHub OpenIG site.!

an open-source cross-platform OpenSceneGraph based
Image Generator


Intended for use on commercial and military simulators.

OpenGL Shaders

OpenGl shader adds the realism in a scene.  OpenIG has the ability to  support many methods depending on your needs.

Lighting Systems

Version 2.0 now uses a

"Forward +"  render engine.

This method allows for millions of lights  inside database.


OpenIG provides via XML file the ability to select a simple or advanced system depending on needs

The MUSE OpenIG Project

OpenIG (Open Image Generator) is cross-platform open-source lightweight image generator implementation built on top of OpenSceneGraph. It is designed to be simple, easy to use and extensible through its plug-in based architecture and was proved on few commercial ComPro projects.


The target is flight simulation, which has it’s own specifics that differ from other Image Genarator features and reflects OpenIG’s design concepts and implementation. The core is very simple and easy to use, and only manages IG structures and the plug-ins.


The real features of the IG come from plug-ins which are available free unless they rely on commercial libraries and toolkits (example can be the atmospheric  and 3D ocean plug-ins which are built on top of Sundog’s SilverLining and Triton - please visit Sundog's web for more info on this toolkit , or the sensor plugin which rely on JRM commercial library).


The OpenIG history starts four years ago when a visual system implementation was required for a military fighter simulator program. The in-house image generator was written and delivered successfully to this program, but as more projects were coming an independent solution was required and recently with a decision from our company to write such a solution and make it publicly available made the birth of this project.  Former experience with flight simulation image generators and the last two years of testing features and code in the lab helped to write OpenIG with main design focus on simplicity and extensibility.



The core of OpenIG is the Core-Base (OpenIG-Base) library where the OpenIG::Base::ImageGenerator Interface class is defined and further implemented by the OpenIG::Engine class in the Core-OpenIG (OpenIG-Engine) library.


The plugging based approach is realized with the Core-PluginBase (OpenIG-PluginBase) library where the abstracts of plug-ins and their host is declared. And thatís it. All the features then come from different plug-ins.


Building OpenIG

OpenIG is cross-platform, relies on OpenSceneGraph and, boost STL so in theory it can be built by any desktop compiler supporting the these applications,


Just a little history: We choose g++ for all platforms, and the development of the first release was done in the QtCreator IDE, so there are project files available and set for QtCreator  – QtCreator is available for all desktop platforms as well.


For Windows the initial release was developed using the mingw toolchain, but this was problematic due to instability and issues of the  mingw toolchain for Windows.


Starting in version of 1.0.1, we added CMake support – as you might know with CMake you will be able to use any of CMake supported IDEs and compilers, as well as the Microsoft’s Visual Studio for Windows. Addition, we still we support the QtCreator project files since we found it is easier for debugging on Linux and MacOSX.


Building on Linux and OS X it is straight forward once you have installed all the dependencies. CMake searches on default installation locations. For Windows you should tell CMake where are these dependencies are installed and it will generate the project files accordingly for your chosen target.


More details and instructions can be found on the support forums located



The scene is built by entities !

Inside of MUSE OpenIG, you refer to entities and all other structures (like lights, etc …)  through an id.   However, in this  version 1.0.0, cameras and views are not yet managed by an id, but soon they will be as well)


On entity scene introduction, the entity ID is provided and used across the whole scene management by invoking OpenIG methods.


For example:

virtual void addEntity(unsigned int id, const std::string& fileName, const osg::Matrixd& mx, const osgDB::Options* options = 0);  // this method adds an entity in the scene, an here the entity ID is introduced to be used for any call referring to "THIS" entity


virtual void updateEntity(unsigned int id, const osg::Matrixd& mx); // the method to update THE entity with the ID introduced above

This is same for lights and expect in the next versions for Cameras and Views. Entities can be attached to another entities and become sub-entities, in a tree like fashion. And their management is exactly the same, through an ID.


Few words about sub-entities:  From a code perspective it is very easy, you simply attach one entity to another by the following call:

virtual void bindToEntity(unsigned int id, unsigned int toEntityId);


However, it is a bit tricky to do this from a modeler perspective. In our OpenIG the modeler can cut the model to be loaded into the scene as individual controllable pieces, and utilize the plug-in ( ModelComposition plug-in ) to put it back into a entity tree like structure, using the mentioned method. The hierarchy of the entity and it’s sub-entities are defined in a corresponding  model XML file. With the OpenIG installation a sample of a working model and it’s XML is provided to you as a reference.





Simple articulation of entities/sub-entities animations based on XML definition and independent of the modeler were implemented first in version 1.0.0.


Starting in version 1.1.0, we support FBX animations as well, through a transparent interface.


FSX Animations are invoked by an animation name on an entity.


The reason for implementing the simple articulation of entities/sub-entities and their animation is to make it very simple to use.


In practice the updating of entities/sub-entities position/orientation over time  is defined in an associated XML file, and to fulfill the requirement to control the players mathematically by utilizing a run-time value.


For example:  You might need an animation illustrating the closing of airplane landing gear with a failure on some specific angle of the landing gear retracting – in this case the OpenIG application needs to listen to the current position/orientation of the landing gear and stop the animation using the run-time value, the position and/or orientation.


A sample of a model with it’s animations ( the model animation and model composition XML) is provided with MUSE OpenIG for your reference.



OpenIG is taking osgViewer::CompositeViewer as an input during setup and it is up to the user how this viewer instance is setup. The user can add camera manipulators as he wants. Still, there are some camera manipulation methods like attaching the camera to an entity, or if you are not keen to use any of Camera-manipulator, a keypad Camera manipulator is provided ( press F8 to show the command line terminal and type keypad – this will bind the numeric keypad to the camera – please refer to the on screen help about the specific key bindings -, or if you provide an entity id to the keypad command it will bind the keypad to that entity/sub-entity).



The Commands interface is defined in the IgCore.  In the default OpenIG core, a few commands are implemented that simply wrap some of the OpenIG functionalities. The OpenIG commands can be extended from the custom plug-ins, so one can write plug-ins and introduce new commands without touching the OpenIG core code.



OpenIG is configured using few XML files. The ‘few’ might sound odd, since the user might prefer configuring it all from one single place, but it has a schema, and the main reason to have it distributed was the extensibility.


The common configuration file is opening.xml.  It is located at /usr/local/lib/igdata on Linux and .\igdata on Windows. This file configures which plug-ins you want to use in run-time and some other common IG features.


Each plug-in can have it’s own specific configuration file located in the same directory as the plug-in itself ( usually on Linux and Mac is /usr/local/lib/igplugins, on Windows .\igplugins ). The naming convention is the name of the plug-in shared library + .xml ( example: ).

Currently Available OPENIG PLUG-INS

Here is a short list of some we have integrated into OpenIG.  Note: Not all are Open Source but this is the flexibility of OpenIG.  If there is not an existing Open Source plug-in that meets your needs, please contact us to create a customized one for you.


  • SilverLining – this plug-in wraps the SunDog’s SilverLining ( atmospherics and 3D clouds library for atmospheric effects in OpenIG.
  • Model Composition – compose a model into entity/sub-entities from a decomposed controllable models from an XML file
  • Animation – adds support for simple experimental animations in OpenIG
  • VDBOffset – helps large database management to avoid rendering artifacts by offsetting a visual database by a given offset
  • GPUVegetation – implements simple vegetation generated on the GPU. Works together with the veggen tool also available in the OpenIG distribution
  • ForwardPlusLighting - provides Forward+ lighting system
  • SimpleLighting - very simple lighting implementation as an alternative to Forward+
  • LightsControl - plugin that converts database lightpoints into Forward+ lights, manage switches on lights
  • UI - provides OpenGL user interface for editing XML files and launching OpenIG commands visually
  • MUSE - sample of using the Compro's multi-platform shared memory library
  • LightsControl - plugin that converts database lightpoints into Forward+ lights, manage switches on lights
  • SkyDome – adds support for custom simple textured sky model
  • FBXAnimation – support for FBX animations
  • OSGParticleEffects – support for particle effects available in OSG
  • OSGEarthSimpleLightng – integration of our lighting with the osgEarth shader composition
  • Bullet – sample integration with bullet physics
  • Networking - OpenIg Simple networking over UDP and TCP
  • Triton - 3D Ocean plug-in integration Triton from Sundog Soft (
  • Mersive - Provides warping and blending of multiple channels (
  • Physics Based Sensors plugin - commercial, based on the JRM SDK (