Fr/SimGear
Version traduite le 23 décembre 2022
| Note Lorsque FlightGear est compilé depuis son code source, il est très important d'avoir les versions de SimGear et de FlightGear en correspondance. |
SimGear est un ensemble de bibliothèques logicielles open source exploitées par FlightGear. La version 1.0 de FlightGear est sortie en décembre 2007. Le projet est toujours en cours de développement mais l'objectif est d'être un noyau de simulation et d'être utilisé par d'autres projets hors FlightGear. Le projet a été lancé en l'an 2000.
Tout comme FlightGear et TerraGear, jusqu'à la version 1.0, Simgear nécessitait Portable Game Library (PLIB) pour sa construction. Dans les versions ultérieures, PLIB a été remplacé par Open Scene Graph (OSG).
SimGear est une bibliothèque de programmes avec possibilité d'édition de lien si vous envisagez de compiler FlightGear - il n'est pas nécessaire d'exécuter des binaires précompilés. Pour les fonctions des API, voir http://api-docs.freeflightsim.org/simgear/ et les informations héritées, voir http://www.simgear.org/.
N'oubliez pas d'aligner les versions de SimGear et de FlightGear sir vous recompilez à partir des codes sources.
Conception et dépendances
(Cette section est en grande partie copiée de la liste de développement, consultez [1])
Simgear et le système de propriétés sont utilisés dans une variété d'autres projets, donc quoi que nous fassions, nous ne devrions pas faire dépendre ces bibliothèques de bas niveau vers OSG (qui n'est pas disponible par exemple sur un petit contrôleur UAV intégré.)
Structures de données OSG
Bien entendu, nous faisons référence à OSG à de nombreuses reprises. Mais si je construis une application sur SimGear, j'espère y trouver des classes SimGear. SGProperties sont des classes SimGear, mais si vous utilisez le système de propriétés, vous ne voudrez peut-être pas dépendre d'OSG.
... Également, d'expérience, en passant à un autre concepteur de scène, je préférerais ne voir aucune référence OSG:: .. Du tout dans l'équipement de vol - à l'exception de quelques trucs liés au spectateur. Mais la partie simulation de FlightGear ne devrait pas avoir besoin de savoir que la visionneuse fonctionne sur OSG/OpenGL. Donc, regarder SimGear comme une bibliothèque d'utilitaires pour les applications de simulation, cela a du sens de mon point de vue ...
Donc, même si vous avez besoin de plus de code de colle, il serait préférable d'éviter les classes OSG dans les constituants de SimGears qui ne sont pas liées à la scénographie. Le système de propriété est un vaste domaine.
Ce n'est pas une exigence stricte. Mais nous avons certainement des parties dans une simulation qui n'ont tout simplement pas besoin de savoir qu'elles ont une adhérence à OSG/OpenGL.
Imaginez que vous vouliez changer la bibliothèque de la visionneuse. C'est toujours le même problème. En intégrant les classes OSG un peu partout dans le code sans aucune forme d'abstraction, vous devez réécrire toute la pile de code interfaçant SimGear et OSG.
Cela a été fait lors du passage à OSG et une grande partie de ce travail était presque uniquement pour cette raison que nous avons tous les types de concepteurs de scène directement répartis. Donc, s'il vous plaît, évitez d'avoir OSG:: quoi que ce soit qui se répande dans l'ensemble de l'application.En dehors de cela, avoir plus de chemins de code séparés en général pour les parties de simulation et les parties visionneuse/scène aiderait grandement pour beaucoup de nos problèmes d'évolutivité. Donc, juste en pensant à la conception générale du logiciel ... Donc, rien n'est gravé dans le marbre ici, mais il est logique, à l'OMI, de se diriger vers cette séparation lorsque cela est possible / raisonnable.
Plus en détail pour le comptage des références. Je n'aime pas l'implémentation référencée d'OSG. C'est déjà très lourd. A certains membres dont nous n'avons en aucun cas besoin dans quelque chose qui dépend de la simulation. Le truc observe_ptr n'est pas thread-safe, et l'implémentation de l'observateur ne s'adapte pas bien si vous avez de nombreux observateurs. La référence a déjà une vtable.
Ce que nous avons est une chose très faible qui pourrait être utilisée de manière basique mais qui est beaucoup plus flexible même pour des objets plus petits. Je préférerais garder cette propre implémentation. Il en va de même pour les vecteurs OSG. Ils sont soignés, mais incohérents sur les types de membres. Là aussi, le système de collision manque.
La règle d'or pour utiliser ce qui est simple :
- Si vous êtes dans le concepteur de scène, OSG::... peut être une bonne chose à utiliser.
- Si vous êtes dans la simulation, le réseau, le système d'entrée, le système de propriété, où que vous soyez
ne dépend pas du concepteur de scène, utilisez les propres classes de SimgGar.
Scenegraph signifie donc OSG::ref_ptr et fg/sg signifie SGSharedPtr. Et d'un point de vue abstrait, l'utilisation d'OSG* ne devrait pas être trop visible. Ces endroits où cette règle est enfreinte sont quelque chose que je n'aime pas non plus. Comme déjà dit, je pense que ce n'est pas une bonne idée de lier une simulation à un cadre de visualisation. Et un scénographie n'est rien de plus que ça...
Je ne dirais donc pas qu'il s'agit d'un objectif de conception difficile. Mais si nous pouvons faire cela, je crois que nous en retirerons un avantage à moyen/long terme.
SGReferenced vs. Boost
Lors de l'utilisation de std::tr1:shared_ptr, vous aurez besoin de deux allocations pour un nouvel objet utilisé avec l'implémentation std::shared_ptr - une pour l'objet et une pour le nombre de références. J'aime utiliser ce matériel SGReferenced pour de nombreux petits objets légers qui ne devraient pas prendre trop de temps à créer et ne devraient pas prendre trop de place. Ce type de solution est la plus légère à laquelle je puisse penser.
De plus, vous ne pouvez plus travailler avec des pointeurs bruts transmis et utiliser le décompte de références inclus dans l'objet puisque l'implémentation de shared_ptr a un objet de décompte séparé. Si vous le faites, vous vous retrouverez avec deux décomptes de références pour le même objet. L'implémentation actuelle évite cela et crée des API basées sur des pointeurs bruts si nécessaire.
Donc, dans l'ensemble, nous avons avec la version SG* quelque chose qui fonctionne aussi bien que la paire shared_ptr/weak_ptr et fournit quelques fonctionnalités supplémentaires que j'aimerais avoir.
Le compteur SGAtomic pourrait utiliser le std :: atomic à un moment donné - si nous ajoutons un cas supplémentaire dans la sélection d'implémentation actuelle lorsque nous l'avons disponible. Cela pourrait être fait sans perdre aucune des fonctionnalités dont nous disposons dans notre implémentation SharedPtr/WeakPtr actuelle. La seule chose dans tr1 est le shared_ptr/weak_ptr. Je ne suis pas sûr de ce que comprend TR2.
Ce qui me manque dans le pointeur intrusif, c'est une implémentation thread-safe de la faiblesse_ptr. Notez que nous avons déjà cela dans SimGear ... Pas encore pensé à cela, mais y a-t-il une chance d'implémenter la sémantique de low_ptr avec le intrusive_ptr ?
Compiling from source
Note Si aucune fonctionnalité du GUI n'est requise, l'indicateur -DSIMGEAR_HEADLESS peur être positionné afin d'éviter de créer une adhérence à OpenSceneGraph
|
La compilation de SimGear suit la procédure standard et simpliste pour la construction de projets CMake.
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