Fr/SimGear: Difference between revisions

Jump to navigation Jump to search
470 bytes added ,  23 December 2022
Traduction partielle
(Traduction partielle)
(Traduction partielle)
Line 8: Line 8:
Tout comme FlightGear et [[Fr/TerraGear|TerraGear]], jusqu'à la version 1.0, Simgear nécessitait [[PLIB]] pour sa construction. Dans les versions ultérieures, PLIB a été remplacé par [[OpenSceneGraph|OSG]].
Tout comme FlightGear et [[Fr/TerraGear|TerraGear]], jusqu'à la version 1.0, Simgear nécessitait [[PLIB]] pour sa construction. Dans les versions ultérieures, PLIB a été remplacé par [[OpenSceneGraph|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/.


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 api docs see http://api-docs.freeflightsim.org/simgear/ and legacy information see http://www.simgear.org/.
N'oubliez pas d'aligner les versions de SimGear et de FlightGear sir vous recompilez à partir des codes sources.


[[FlightGear 1.9.0]] requires SimGear 1.9 if compiling from source.
==Conception et dépendances==
(Cette section est en grande partie copiée de la liste de développement, consultez [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg22720.html])


==Design & Dependencies==
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é.)
(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.)
===Structures de données OSG===
Bien entendu, nous faisons référence à OSG à de nombreuses rep^rises. Mais si je construis une application sur SimGear, j'espère y trouver des classes SimGear. SGProperties sont des classes SimGear, et si vous utilisez le système de propriétés, vous ne voudrez peut-être pas dépendre d'OSG.


===OSG data structures===
... Egalement, 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 ...
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
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.
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.
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.
The property system is such an area.
 
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.  


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.  
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.  
729

edits

Navigation menu