FlightGear wiki - User contributions [en]

Talk:SimGear

2023-09-03T01:26:24Z

Meliache:

=== Simgear.org is dead/taken? ===
I have just checked this page within the scope of translating FAQ page to Russian - and it seems that current content of simgear.org has nothing to do with the project. Has someone else acquired this domain? Is there an up-to-date website somewhere still?
[[User:Dot sent|Dot sent]] ([[User talk:Dot sent|talk]]) 18:02, 3 February 2018 (EST)

: As of today there is nothing under simgear.org. I just created an edit where I link to the git repo directly plus an archived version of simgear.org. Bless the Internet Archive (and donate if you can). [[User:Meliache|Meliache]] ([[User talk:Meliache|talk]]) 01:26, 3 September 2023 (UTC)

SimGear

2023-09-03T01:19:58Z

Meliache: Fixup to previous edit, fixing links and typos

[[File:Flightgear uml associations class diagram.png|thumb|A [[UML Diagrams|UML]] class diagram disclosing the associations between some classes of the FlightGear source code.]]

{{note|When [[Building FlightGear|compiling FlightGear from source]] it is very important to have the matching version of SimGear and FlightGear.|width=70%}}

'''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. You can find [https://sourceforge.net/p/flightgear/simgear its source code on the Flight Gear Sourcehut Project Page]. The [https://web.archive.org/web/20100427070428/http://www.simgear.org:80/ legacy SimGear homepage] and [https://web.archive.org/web/20160921061005/http://api-docs.freeflightsim.org/simgear/API API docs] are not maintained anymore but still available via the ''Internet Archive''. 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 [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg22720.html])

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 <code>-DSIMGEAR_HEADLESS</code> 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

== External Links ==
* Latest Docs - http://simgear.sourceforge.net/doxygen/
* http://simgear.sourceforge.net/

== See also ==
* [[Building FlightGear]]
* [[FlightGear related projects]]
* [[TerraGear]]

[[Category:Software]]
[[Category:GPL software]]

[[fr:SimGear]]

SimGear

2023-09-03T01:16:51Z

Meliache: Simgear homepage and API page links are down, therefore link to the archived versions and sourceforge repo, asking users to compile the docs themselves.

[[File:Flightgear uml associations class diagram.png|thumb|A [[UML Diagrams|UML]] class diagram disclosing the associations between some classes of the FlightGear source code.]]

{{note|When [[Building FlightGear|compiling FlightGear from source]] it is very important to have the matching version of SimGear and FlightGear.|width=70%}}

'''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. You can find the source code on the [https://sourceforge.net/p/flightgear/simgear its source code on Flight Gear Sourcehut Project Page]. The [legacy homepage] and [https://web.archive.org/web/20160921061005/http://api-docs.freeflightsim.org/simgear/API docs] are not maintained anymore but still available via the Internet Archive. 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 [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg22720.html])

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 <code>-DSIMGEAR_HEADLESS</code> 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

== External Links ==
* Latest Docs - http://simgear.sourceforge.net/doxygen/
* http://simgear.sourceforge.net/

== See also ==
* [[Building FlightGear]]
* [[FlightGear related projects]]
* [[TerraGear]]

[[Category:Software]]
[[Category:GPL software]]

[[fr:SimGear]]