SimGear
| Note When compiling FlightGear from source it is very important to have the matching version of SimGear and FlightGear. |
SimGear is a set of open source software libraries used by FlightGear. The 1.0 release was released along with FlightGear 1.0 in December 2007. The project is still developing but the goal is to be a "Simulation Kernel", and to be used by other non-FlightGear projects. The project was started in the year 2000.
SimGear, like FlightGear and TerraGear, requires PLIB for building.
SimGear is a library of supporting code and a downstream dependancy if you plan on compiling FlightGear — it is not needed to run precompiled binaries. For the source code, see the #Source code section below. For getting the up-to-date API documentation you currently have to build the Doxygen documentation yourself.
FlightGear 1.9.0 requires SimGear 1.9 if compiling from source.
Design & Dependencies
(This section is largely copied together from the devel list, see [1])
Simgear and the property system are used in a variety of other projects, so whatever we do, we shouldn't make these low level libraries depend on OSG (which isn't available for instance on a little embedded UAV controller.)
OSG data structures
Sure we already rely on osg at many places. But if I build an aplication on simgear, I hope to have simgear classes there. SGProperties are simgear classes, and if you use the property system you may not want to rely on osg.
... also from past experience switching to an other scenegraph, I would prefer to see no osg::.. references at all in flightgear - except some few viewer related stuff. But the simulation part of FlightGear should not need to know that the viewer runs on osg/OpenGL. So looking at SimGear as a utility library for simulation applications, this make sense from my point of view ...
So, even if you will need some more glue code, It would be better to avoid osg classes in simgears parts that are not scenegraph related. The property system is such an area.
This is not a hard requirement. But we definitely have parts in a simulation that just do not need to know that they run on osg/OpenGL.
Imagine you want to change the viewer library. All the physics is still the same. By mixing osg classes into everything without any type abstraction in between, you need to rewrite the whole pile of code. Even for parts that do not depend on any viewing crap at all.
That was done during the switch to osg and plenty of that work was almost only for that reason we have all the sg types directly spread around. So please avoid having osg::whatever spread around in the whole application.
Appart from that, having more separate code paths in general for the simulation parts and the viewer/scene parts would help for plenty of our scalability problems a lot. So just thinking about general software design ... So nothing is set in stone here, but it makes sense IMO to head into that separation where possible/sensible.
More in detail for the reference counting. I do not like the referenced implementation of osg. That is already very heavyweight. Has some members we do not need in any way in something simulation dependent. The observed_ptr stuff is not thread safe, also that observer implementation does not scale well if you have many observers. Referenced already has a vtable. Just to name a few ...
What we have is a very weak thing that could be used in the same basic way but is way more flexible even for smaller objects. I would prefer to keep that own implementation. The same goes for the osg vectors. They are neat, but inconsistent over the member types. Also the collision system is missing there.
The rule of thumb when to use what is simple:
- If you are in the scene graph most probably osg::... might be a good thing to use.
- If you are in the simulation, network, input system, property system, wherever
not scene graph dependent, use simgears own classes.
So scenegraph means osg::ref_ptr and fg/sg means SGSharedPtr. And from an abstraction point of view osg* usage should not be visible too much. Those places where this rule is broken is something I do not like either. As already told, I believe that it is not a good idea to tie a simulation to a viewer framework. And a scenegraph is nothing more than that ...
So I would not tell that a hard design goal. But If we can make that I believe that we will get a benefit in doing so in the mid/long term.
SGReferenced vs. Boost
When using std::tr1:shared_ptr you will need two allocations for a new object that is used with the std::shared_ptr implementation - one for the object and one for the reference count. I like to use that SGReferenced stuff for many small lightweight objects that should not take to much time to create and should not take too much space. That kind of the solution is the most lightweight one I can think of.
Also you can no longer work with raw pointers passed around and use the reference count included in the object since the shared_ptr implementation has a separate count object. If you do so you will end up with two reference counts for the same object. The current implementation avoids that and make raw pointer based apis if required.
So alltogether we have with the SG* version something that works equally well than the shared_ptr/weak_ptr pair and provides some extra features I would like to have.
The SGAtomic counter could make use of the std::atomic at some point - if we add an additional case int the current implementation selection when we have that available. This could be done without loosing any of the features we have available in our current SharedPtr/WeakPtr implementation. The only thing in tr1 is the shared_ptr/weak_ptr. I am Not sure what tr2 includes.
What I am missing in the intrusive pointer is a thread safe implementation of the weak_ptr. Note that we already have that in simgear ... Not yet thought about that, but is there any chance to implement the weak_ptr semantics together with the intrusive_ptr?
Compiling from source
Note If you do not require GUI functionality, the flag -DSIMGEAR_HEADLESS can be set to avoid having to pull OpenSceneGraph in as a dependency
|
Compilation of SimGear follows the fairly stupid standard procedure for building CMake projects.
git clone git://git.code.sf.net/p/flightgear/simgear/ flightgear-simgear cd flightgear-simgear cmake . -DSIMGEAR_HEADLESS=YES # Optional, decreases build size and dependencies make make install
Related content
Wiki articles
Source code
External links
- Curtis L. Olson. SimGear - Simulator Construction Tools. Archived from the original on April 27, 2010. The old simgear home page.