Fr/FlightGear Newsletter July 2012
|
Nous voudrions insister sur le fait que cette lettre d'information ne peut pas vivre sans les contributions des utilisateurs et développeurs de FlightGear. Il suffit d'ouvrir un compte sur ce wiki pour l'éditer et toutes les contribution sont les bienvenues. Si vous avez connaissance de nouveautés dans FlightGear ou dans un projet parent, comme les avions ou les terrains, vous êtes invité à les partager en éditant cette newsletter.
À propos de la prochaine version
Le 17 Juillet, la branche pour la nouvelle version a été créée dans le dépôt Git hébergeant le code source et des données du simulateur. C'était la dernière étape majeure dans la feuille de route (Release Plan) avant la sortie de la nouvelle version 2.8.0 de FlightGear. Durant les deux prochaines semaines, nous allons travailler intensément à la correction des derniers bogues connus dans le code pour ensuite créer les paquetages pour les principales plate-formes. Vous pouvez nous aider à trouver des bogues, en testant les versions de test (release candidate) qui sont téléchargeables en bas de cette page. Les testeurs sont encouragés à signaler les bogues sur notre outil de suivi d'anomalies.
Pour savoir ce qui a changé depuis la dernière version (2.6.0), un journal des modifications est en cours d'écriture dans cet article : Changelog 2.8.0.
FlightGear fête ses 15 ans avec un concours de captures d'écrans
Pour célébrer les 15 ans de FlightGear (le 17 juillet), un concours de capture d'écran a été organisé. À partir du 1er août, une période de deux semaines vote a commencé. Les gagnants seront annoncés le 18 août, en même temps que la sortie de FlightGear 2.8.0. Les captures d'écrans gagnantes seront utilisées pour promouvoir FlightGear auprès du grand public.
Nous tenons à remercier les 37 participants qui ont soumis un total de 165 captures d'écrans. Votez pour vos favoris sur le site du concours !
Vous souhaitez en savoir plus sur l'histoire de FlightGear ? Lisez FlightGear History.
Nouvelles du développement
Adoption du nouveau système de rendu 2D Canvas
A compter de juillet 2012, les développeurs de FlightGear ont accepté d'adopter le nouveau système de rendu 2D Canvas développé par Tom qui est entièrement piloté par des propriétés et prend en charge tout l'affichage 2D par le biais l'arbre des propriétés de FlightGear (voir l'article Original Canvas Proposal). Initialement, l'idée était de remplacer le kit d'outils de l'interface graphique actuelle (PUI/PLIB, qui a montré de nombreuses limitations au fil du temps) pour utiliser une implémentation basée uniquement sur Canvas, qui sera essentiellement implémentée dans l'espace de script Nasal et qui utilisera simplement le système Canvas comme interface de rendu. Les détails de l'implantation sont couverts en détail dans l'article Canvas_Widgets. Cette étape pourrait permettre à l'utilisateur final de personnaliser facilement l'interface graphique de FlightGear et son apparrence en créant des thèmes graphiques personnalisés (thèmes/skins) mais également en créant des widgets totalement nouveaux en utilisant un éditeur SVG comme Inkscape.
Actuellement (juillet 2012), seul le dessin à l'intérieur d'un dialogue existant (PUI) est possible, mais l'idée est d'implanter progressivement la fonctionnalité actuelle en Nasal et de se débarrasser des fenêtres de dialogue PUI codées en dur. Seules quelques lignes de codes pour l'interaction souris/clavier avec Nasal resteront nécessaires.
Contrairement à l'utilisation d'une interface graphique codée en dur (PUI, osgWidget, etc.), cette approche donnerait beaucoup plus de flexibilité et également les moyens de modifier et créer de nouvelles fenêtres, sans nécessiter de toucher au code de FlightGear.
Avec le système Canvas, tout type de fenêtre serait possible, de telle sorte que des choses comme des sous-menus peuvent être conçues. Un autre avantage de l'approche Canvas est qu'elle s'appuie fortement sur l'arbre des propriétés de FlightGear et il est ainsi entièrement accessible depuis le code Nasal et également configurable avec les formats XML existants.
Le but de démonstration des fenêtres Canvas est de montrer à quel point le nouveau système Canvas est puissant et flexible. c'est-à-dire que non seulement il peut être utilisé pour les scripts des aéronefs (instruments, MFD), mais aussi pour les scripts de l'interface graphique, ce qui veut dire que l'utilisation de ce système unifierait l'interface de rendu 2D (tout peut être géré par canvas), tout en réduisant la quantité de code C++ requise pour faire ce genre de chose, ce qui signifie que l'interface graphique pourrait être entièrement maintenue dans un espace de script, c'est-à-dire comme faisant partie du paquetage de base, par des personnes qui n'ont pas besoin de connaître le C++ - seuls des rudiments de Nasal seront nécessaires.
Simplement, l'adoption du système Canvas pour de telles fins ou d'autres fins similaires signifierait que des tonnes de code C++ ancien/périmé pourront être supprimées et remplacées par une seule implantation homogène en C++, qui utiliserait du code C++/OSG moderne - ce qui veut dire également qu'OSG en lui-même peut faire plus d'hypothèse sur ce qui est rendu, de telle sore que plus d'optimisation (donc un meilleur taux de rafraîchissement d'images) soit obtenue facilement en utilisant des patrons et protocoles de code OSG, au lieu de bibliothèques anciennes/personnalisées/tierces qui devraient être insérées manuellement dans l'écosystème FG/SG/OSG.
De plus, ce qui est intéressant à propos du système canvas, c'est qu'il est intégré de telle façon qu'il va continuer à fonctionner avec l'ancien code d'interface graphique toujours en place. En plus, toutes les fonctionnalités de l'interface actuelle (disposition, traitement XML), sont prises en charge implicitement grâce à la façon dont le système canvas est implémenté. Ceci est une étape essentielle pour l'implémentation d'une nouvelle librairie d'interface graphique en parallèle à PUI car, autrement, tout l'existant devrait être porté explicitement (soit dans l'espace C++ ou par la conversion de tonnes de fichiers XML). Globalement, le système canvas nous permettra d'obtenir tout cela sans effort, et cela signifiera aussi moins de code C++ dans l'arborescence des sources aussi, et donc une maintenance plus aisée.
Enfin, quand la version autonome FGCanvas sera disponible, il sera possible de faire fonctionner l'interface en mode multi-fenêtré ou même dans des processus séparés.
Egalement, en utilisant le système Canvas pour les fenêtres de dialogue, il sera possible de rendre les instruments d'un aéronef, comme les HUDs ou MFDs dans une fenêtre de dialogue.
Les plans futurs prévoient de réimplanter le HUD et le système de panneaux 2D actuels en utilisant le système Canvas . En plus, Le système canvas permettra la possibilité d'unifier incrémentalement le système de rendu 2D dans FlightGear dans les mois à venir. Voir Unifying the 2D rendering backend via canvas. En plus, le système canvas offre un nouveau niveau d'abstraction pour la création d'écrans de cartes mobiles dynamiques et totalement interactives, ainsi que les fenêtres pour générer des graphiques en utilisant les Canvas Maps.
Textures procédurales
Habituellement, les textures des modèles ou des scènes sont préparées à l'avance puis chargées et rendues par FlightGear. L'utilisation de textures procédurales permet de calculer les textures pour un rendu à l'intérieur du fragment shader plutôt que d'utiliser une texture prédéfinie. Le principal désavantage de ce procédé est qu'il a un coût plus important sur le nombre d'image par seconde. Cependant, contrairement aux textures prédéfinies qui montrent un certain degré de répétition (tuilage) sur des distances beaucoup plus larges que la taille de la texture, un calcul au sein du fragement shaderpermet d'évaluer une fonction qui ne montre pas de tuilage et l'utilise comme base pour la texture finale. Dans le même temps, des détails comme la carte de hauteur du terrain (terrain heightmap) ou les variations de couleur à n'importe quelle échelle peuvent être générées.
Comme les textures sont générées dynamiquement, il est aussi possible de laisser l'élévation et les courbes du terrain influencer le résultat (comme démontré actuellement avec les shaders d'effet de transition et de neige). L'utilisation des textures procédurales dans le shader du terrain afin de mélanger différentes textures et d'ajouter des effets environnementaux permet de rendre le terrain de FlightGear avec un niveau de détail jamais atteint. La génération dynamique de la texture permet de cacher les coutures entre deux types de terrains différents et de générer la rugosité du terrain à un haut niveau de détail. Elle permet aussi d'ajouter facilement l'effet la réflexion de la lumière induit par des mares d'eau peut être utilisée pour texturer en très haute résolution les types de sols présents dans les aéroports.
(toutes les captures d'écrans ont été prises dans les scènes par défaut)
Dans le Hangar
En mai 2011, nous avons adopté un nouveau système de notation pour les aéronefs. A l'heure actuelle, seuls quelques appareils ont été notés, comme on peut le voir dans la liste 'hockenberry' mise en place sur Google Docs. Si vous êtes un développeur d'aéronef et que celui-ci ne figure pas sur cette liste, pensez à noter leurs statuts. Tout ce que vous devez savoir est écrit dans l'article Formalizing Aircraft Status. Si vous souhaitez simplement contribuer à FlightGear, ce serait également une excellente façon de commencer.
Un nouveau hangar, celui de Lukas
Un nouveau hangar pour FlightGear a ouvert, celui de Lukas. Vous pourrez y trouver quelques livrées d'appareils ainsi que quelques projets scènes notamment des aéroports des Îles Baléares et Canaries. Le mieux est de jeter un coup d'oeil par vous-même dans son hangar.
Le coin des scènes
Données du terrain de Manhattan
Gijs a modifié à la main les contours du terrain de l'île de Manhattan à New York. Ces données sont maintenant disponibles sur le serveur de cartes. Comparées aux données actuelles (VMAP0), ces données sont beaucoup plus fidèles à la réalité et montrent un niveau de détail plus élevé. Les améliorations les plus flagrantes sont l'ajout de parcs et des îles, dont Liberty Island.
Ceux parmi vous qui savent utiliser TerraGear peuvent s'en servir pour construire Manhattan, pour les autres il faudra attendre la prochaine construction des scènes de FlightGear.
Outils
FlightGear l'a (encore) fait ! Pour la première fois dans l'histoire des simulateurs, il n'a jamais été aussi facile de contribuer a l'amélioration des scènes. Si vous avez déjà copié/collé une fois dans votre vie, alors vous serez capables de contribuer aux scènes de FG. Un copier/coller direct des nouvelles lignes d'objet au format STG dans un formulaire en ligne vous permet dorénavant de mettre à jour les objets des scènes du monde entier pour l'ensemble des utilisateurs de FlightGear qui utilisent Terrasync. L'ajout de votre adresse email au formulaire vous permet d'être tenu informé de la progression de la mise à jour. L'importation est généralement rapide (disons entre 24 et 72h), mais cela dépend de la charge de travail des (du) responsable(s) des scènes.
Vous voulez essayer ? Cliquez ici, puis choisissez Mass import, ou alors via le menu du site scenemodels (Contribute => Mass shared object position insertion).
Veuillez noter que :
- vous devez importer uniquement des nouveaux objets et non le fichier STG au complet sur lequel vous travaillez !
- N'ajoutez pas de modèles qui ne seraient pas présents dans la base de données scenemodels de FlightGear (ni d'OBJECT_SIGN ou d'OBJECT_STATIC) ;
- n'ajoutez pas de forêt ou d'autre élément lié aux données du terrain, car ces éléments doivent être générés en fonction des données du terrain. Les seuls arbres qui seront tolérés sont ceux qui sont ajoutés, par exemple, dans une scène d'aéroport ;
- les données dont vous demandez l'import doivent être basées sur l'élévation du terrain fourni par FlightGear/Terrasync et non sur des données de terrain que vous pourriez avoir compilé ou téléchargé vous-même, car sinon vos objets pourraient se retrouver flotter ou enterrés dans le terrain ;
- les importations sont limitées à 100 lignes par soumission (une petite pensée pour les pauvres responsables des scènes) ;
- l'importation est assez sensible sur la qualité des données en entrée, qui passent par pas mal de vérifications y compris humaines, avant d'être insérées ;
La prochaine étape est l'outil d'import des modèles 3D. Il est terminé à 90%. Soyez patient, c'est un outil assez compliqué à finaliser.
Serveur de cartographie
Quelques nouvelles du Mapserver, car nous n'avons pas parlé de cet outil très utile depuis un certain temps. Mapserver a été mis à jour ce mois-çi, la mise à jour la plus intéressante étant la possibilité de visionner les détails d'un objet et de le modifier/le supprimer directement à partir de la carte. Il n'a jamais été aussi simple de mettre à jour/supprimer un objet partagé directement à partir de la carte (voir la capture d'écran). Notez que vous devez avoir un facteur de zoom suffisant (>=16) pour apercevoir les flèches rouges, puis cliquer dessus. Remerciements à Martin, Julien et Gijs pour les mises à jour et les tests effectués sur cet outil. Pour l'utiliser, regardez ici.
Mise à jour de la licence d'OpenStreetMap
Comme vous le savez probablement, le service cartographique en ligne OpenStreetMap change sa licence. Lorsque le changement de licence sera terminé, nous serons en mesure d'utiliser les données OSM dans les scènes officielles de FlightGear. Comme tous les contributeurs d'OSM n'ont pas accepté la nouvelle licence, les données issues de ces sources doivent être supprimées. Ce processus de rédaction devrait être terminé d'ici la fin juillet. Même si c'est un grand pas en avant, la licence n'a pas encore changé. Voir le blog OSM pour les mises à jours et les dernières informations sur le sujet: http://blog.osmfoundation.org/
Nouvelles de la communauté
FlightGear sur Youtube
Fallen a revisité ses enregistrements vidéos à la vieille mode lors d'un vol entre l'aéroport international de San Francisco et le porte-avion USS Nimitz, mais l'a réalisé la nuit, avec le nouveau F-14 Tomcat mis à jour pour Rembrandt permettant de voir FlightGear sous de nouvelles lumières.
FlightGear 2.8 de nuit avec Rembrandt
Multijoueurs
Deux nouveaux serveurs multijoueurs ont été paramétrés :
- mpserver15.flightgear.org (North Point, Hong Kong)
- grace à Hazuki Amamiya
- mpserver16.flightgear.org (Dallas, TX, USA)
- grace à Rob Dosogne (truthsolo)
- Héberge également une nouvelle page Statut des serveurs.
Ce texte fait exception à la licence générale de ce site, ce texte est disponible sous la licence GNU GPL v2.
Et enfin...
Contribuer
Une des nombreuses remarques exprimée dans les forums de FlightGear est "Je souhaiterais contribuer, mais je ne sais pas programmer et je n'ai pas le temps". Malheureusement, il y a souvent une incompréhension qui fait que beaucoup d'utilisateurs imaginent qu'il est nécessaire de savoir programmer et de disposer de beaucoup de temps libre pour participer. En fait, il y a de très nombreuses façons de contribuer au projet sans avoir besoin d'écrire du code ou de passer des journées sur certaines tâches.
Si vous avez besoin d'idées pour contribuer à FlightGear, vous pourriez jeter un oeil à cet article : Volunteer.
Merci à Alexandre pour sa traduction http://aviactu.info/ wikification réalisé par [lolalilo]