Fr/FlightGear Newsletter July 2012: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
No edit summary
 
(13 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{newsletter}}
{{newsletter}}
{{TOC_right|limit=2}}
{{TOC_right|limit=2}}
''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 ==
== À 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 [http://www.flightgear.org/download/ de cette page]. Les testeurs sont encouragés à signaler les bogues sur [http://code.google.com/p/flightgear-bugs/ notre outil de suivi d'anomalies].


Le 17 Juillet, la branche pour la nouvelle version a été créée dans le dépôt Git du code source et des données du simulateur. C'était la dernière étape majeure dans la feuille de route, avant la sortie de la nouvelle version de FlightGear, la version 2.8.0. Pendant les deux prochaines semaines, les développeurs travailleront sur la correction des derniers bogues connus pour ensuite compiler le logiciel pour les plateformes majeures. Vous pouvez aidé les développeurs a trouvé des bogues, en testant la release candidates qui est téléchargeable ici: http://www.flightgear.org/download/
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]].
les testeurs sont encouragés a signalé les bogues ici: http://code.google.com/p/flightgear-bugs/
 
Pour savoir ce qui a changé depuis la dernière version (2.8.0), un journal des modifications est en cours d'écriture.


== FlightGear fête ses 15 ans avec un concours de captures d'écrans ==
== 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.


Pour célébrer les 15 ans du projet FlightGear, un concours de capture d'écran a été organisé. À partir du 1er août, la période de vote a commencé.
Nous tenons à remercier les 37 participants qui ont soumis un total de 165 captures d'écrans. Votez pour vos favoris sur [http://flightgear.org/contest le site du concours] !
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 au grand public. Nous aimerions remercié les 37 participants qui on soumit un total de 165 captures d'écrans.  


Votez pour vos favoris sur le site du concours: http://flightgear.org/contest
Vous souhaitez en savoir plus sur l'histoire de FlightGear ? Lisez [[FlightGear History]].


== Nouvelles du développement ==
== Nouvelles du développement ==
=== Le nouveau système de rendu 2D Canvas ===
=== Adoption du nouveau système de rendu 2D Canvas ===


En juillet 2012, les développeurs de FlightGear ont accepté d'inclure le nouveau système de rendu 2D développé par Tom qui est géré par des propriétés et gère tout l'affichage 2D avec l'arbre des propriétés de FlightGear. Initialement, l'idée était de remplacé la bibliothèque graphique PLIB et d'utilisé uniquement Canvas, qui sera majoritairement implanté dans l'espace de script Nasal et simplement utilisé le système Canvas comme interface de rendu. Les détails de l'implantation sont couverts en détail sur le wiki: http://wiki.flightgear.org/Canvas_Widgets . Cette étape va permettre à l'utilisateur final de personnaliser facilement l'apparence et l'interface graphique de FlightGear en créant des thèmes graphiques personnalisés ou créer une nouvelle fenêtre en utilisant un éditeur de fichier SVG tel que Inkscape.
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, il seulement possible de modifier l'affichage dans une fenêtre de dialogue existante, mais l'idée est d'implanter progressivement la fonctionnalité actuelle dans Nasal pour se débarrassé des fenêtres de dialogue codées en dur. Seulement quelques lignes de codes seront nécessaires pour l'interaction souris/clavier avec Nasal.
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 de fenêtre de dialogue codées en dur, cette approche donnera beaucoup plus de flexibilité et permettera de modifier et créer des fenêtres, sans toucher au code de FlightGear.
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, n'importe quel type de fenêtre sera possible, même des sous-menus seront réalisables. Un autre avantage est que le système Canvas repose largement sur l'arbre des propriétés de FlightGear, qu'il est entièrement accessible depuis l'espace de script Nasal et il est configurable avec le format XML actuel.
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 la fenêtre de démo de Canvas est de démontré à quel point le système Canvas est puissant et flexible. Il ne peut pas uniquement être utilisé pour les instruments d'appareils, mais aussi pour l'interface graphique, ce qui veut dire que le système peut unifier l'interface de rendu 2D en réduisant le code C++ requis pour faire ce genre de chose, ce qui permet à l'interface d'être gérée entièrement dans l'espace de script sans connaitre le C++, seulement des rudiments de Nasal.
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.


En adoptant le système Canvas, des tonnes de code C++ périmé pourra être envoyé à la poubelle et être remplacé par une seule implantation en C++ qui utilise du code C++/OSG moderne, ce qui veut dire qu'OSG peut faire plus d'hypothèse sur ce qui doit être rendu pour qu'il y ait plus d'optimisation, donc plus d'images par seconde en utilisant les protocoles d'OSG au lieu de vieille bibliothèque qui n'est plus à jour.
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.


Ce qui est intéressant à propos de ce système, c'est qu'il est intégré d'une telle façon, qu'il va fonctionner avec l'ancien code d'interface graphique en place. En plus, toutes les fonctionnalités de l'interface actuelle sont supportées grâce à la façon dont il est intégré. Habituellement, c'est un vrai problème, car lors de l'intégration d'une nouvelle bibliothèque graphique avec les fenêtres de dialogue, tout doit être porté. Cependant, le système Canvas va nous donner cela sans effort, ce qui veut dire moins de code C++ donc plus facile à maintenir.
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.


De plus, quand la version d'autonome sera disponible, il sera possible de faire fonctionner l'interface en mode multi fenêtre et chaque fenêtre de façon indépendante. En utilisant le système Canvas pour les fenêtres de dialogue, il sera possible de rendre les instruments d'un avion, comme le HUD ou le MFD dans une fenêtre de dialogue.
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.


{{#ev:youtube|CIS8UyuJLgM}}
{{#ev:youtube|CIS8UyuJLgM}}


Les plans prévoient de réimplanter le HUD et le système de panneaux 2D en utilisant le système Canvas . Le système permet d'unifier le système de rendu 2D. Plus d'information: http://wiki.flightgear.org/Unifying_the_2D_rendering_backend_via_canvas
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]].
 
Le système Canvas permettra de créer un nouveau système de carte interactive. Plus d'information: http://wiki.flightgear.org/Canvas_Maps
 
=== Texture procédurale ===


Habituellement les textures des modèles ou bien les textures des scènes sont préparer a l'avance et puis rendu et charger par FlightGear. Texture procédurale est la notion de calculer les textures pour les rendre la l'intérieur du «fragment shader» plutôt que d'utiliser une texture prédéfinie. Le plus grand désavantage de ce procéder est qu'il fait baisser de beaucoup le nombre d'image par seconde. Cependant contrairement aux textures prédéfinies, qui expose beaucoup de carénage sur de grandes distances que la taille de la texture. Un rendu fait directement par le procéder de texture procédurale ne montre aucun carrelage de plus des détails comme une heightmap terrain ou des variations de couleur à n'importe quelle échelle la taille peut être généré.
=== 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 shader''permet 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és dynamiquement, il est possible de laisser l'élévation et les courbes du terrain influencé le résultat, comme démontré avec la neige actuellement et l'effet de transition. L'utilisation de la texture procédurale sur le terrain pour mélanger plusieurs textures différentes et ajouter un effet environnemental permet de rendre le terrain de FlightGear d'une façon très détaillé. La génération dynamique de la texture permet de cacher la différence flagrante entre deux types de terrain différents et générés la rugosité du terrain a un haut niveau de détail et ajouter facilement l'effet la réflexion de la lumière sur un terrain humide et peut être utilisé pour texturé en haute résolution les aéroports.
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.


[[File:Proc01.jpg|400px|Terrain detail heightmap texturing]]
[[File:Proc01.jpg|400px|Texturage de la carte d'altitude détaillée du terrain]]
[[File:Proc02.jpg|400px|Reduced contrast between different landclasses]]
[[File:Proc02.jpg|400px|Réduction des contrastes entre différents types de sols]]
[[File:Proc03.jpg|400px|Ajout dynamique de mares pour le terrain humide]]
[[File:Proc04.jpg|400px|Offre une texture d'aéroport avec une résolution de 5 mm par pixel]]


[[File:Proc03.jpg|400px|Dynamical addition of puddles for wet terrain]]
(toutes les captures d'écrans ont été prises dans les scènes par défaut)
[[File:Proc04.jpg|400px|Hires texturing of airport features with 5 mm resolution per pixel]]


== Dans le Hangar ==
== 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 [https://docs.google.com/spreadsheet/ccc?key=0ApzphjA4w05ndF94Y2F0bzJTbHQ5QTJXZXJRcUVRbWc&hl=en_US 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.
Tout le progrès effectuer au mois de mai dernier sur un nouveau système de notation d'appareil a finalement été adopté. Jusqu'a présent seulement quelque appareil ont été annoté avec le nouveau système d'annotation. Si vous êtes un développeur et que votre appareil n'est pas classé selon le nouveau système d'annotation veuillez S.V.P. annotez leurs statut. Tout ce que vous devez savoir est écrit ici: http://wiki.flightgear.org/Formalizing_Aircraft_Status . Si vous voulez commencer à contribuer à FlightGear c'est une excellente façon pour commencer à contribuer au simulateur.


=== Un nouveau hangar, celui de Lukas ===
=== 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 [http://lukashangar.jimdo.com/ son hangar].
Un nouveau hangar a ouvert celui de Lukas. Vous pourrez y trouver quelque livrée d'appareil ainsi que quelques scènes notamment un aéroport des Îles Baléares ainsi qu'une scène des Iles Canarie. Le mieux est de jetez un coup d'oeil par vous même ! http://lukashangar.jimdo.com/


== Le coin des scènes ==
== Le coin des scènes ==
=== Données du terrain de Manhattan ===
[[File:Manhattan v0 vs cs-osm.png|thumb|270px|Scènes personnalisées avec données linéaires OSM (gauche) par rapport à l'occupation des sols VMAP0.]]
Gijs a modifié à la main les contours du terrain de l'île de Manhattan à New York. Ces données sont maintenant disponibles sur [http://mapserver.flightgear.org/ 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.


=== Donnée du terrain de Manhattan ===
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.
[[File:Manhattan v0 vs cs-osm.png|thumb|270px|Custom scenery with OSM line data (left) versus v0 landclassing.]]
Gijs à modifier à la main, les contours du terrain de l'ile de Manhattan et ses environ. Les données sont maintenant accessible a l'adresse suivante : http://mapserver.flightgear.org/. Comparativement, les données mises à jour son plus fidèle à la réalité que les données précédemment fournit dans FlightGear. Les différences les plus marquantes sont l'ajout de parc et d'iles particulièrement Liberty Island.
 
ceux qui savent utiliser [[TerraGear]] peuvent s'en servir pour construire la nopuvelle scène de manathan, pour les autres il faudra attendre la prochaine version de FlightGear.


=== Outils ===
=== 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.


Il sera maintenant plus facile que jamais de contribuer a l'amélioration des scènes dans FlightGear, si vous avez déjà copier/coller une fois dans votre vie vous serez maintenant capable de contribuer au simulateur. Vous pourrez maintenant copier/coller des lignes d'objet au format STG dans un formulaire en ligne ce qui permettrait de mètre a jours les bases de données de toutes les donner des objets dans les scènes pour tous les utilisateurs de FlightGear qui utilise Terrasync. De plus vous pouvez ajouter votre adresse email au formulaire pour pouvoir être mit au courent des progrès de la mise a jour le temps moyen d'importation varie entre 48 et 72h tout dépendent du responsable en service et de sa charge de travail.
Vous voulez essayer ? Cliquez [http://scenemodels.flightgear.org/submission/ ici], puis choisissez ''Mass import'', ou alors via le menu du site ''scenemodels'' (Contribute => Mass shared object position insertion).
 
 
 
Veulliez notez que:
 
-Vous devez importer seulement l'objet sur lequel vous travaillez et non le fichier STG au complet
 
-N'ajouter pas des objets qui ne sont pas présents dans la base de données de FlightGear et des modèles ne scènent FOG, OBJECT_SIGN ni OBJECT_STATIC.
 
-N'ajouter pas de forêt ou tout autre objet lié aux données du terrain, car c'est données sont autogénéré. Les seuls arbres qui seront tolérés sont ceux qui sont ajoutés dans une scène d'aéroport
 
-Les donnés que vous importez doivent être basé sur l'élévation du terrain fournit par FlightGear/Terrasync et non sur des données de terrain que vous avez compilées ou télécharger vous-même, car sinon votre objet pourais flotter dans le ciel au lieu d'être au sol.
 
-Les importations sont limitées à 100 lignes par soumission.


-L'importation est très sensible sur les données en entrée, qui passe par beaucoup de vérifications, avant d'être insérée dans le simulateur
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 un outil pour l'importation de modèles 3d. Il est en route, terminé à 90%. Soyez patient c'est un outil compliquer a finalisé.
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 ===
=== Serveur de cartographie ===
[[File:Mapserver - Update and Delete links.png|thumb|270px|Mapserver showing update and deletion links.]]
[[File:Mapserver - Update and Delete links.png|thumb|270px|Affichage des liens de mise à jour et de suppression d'objets sur Mapserver.]]
Nous n’avions pas parlé de cet outil très utile depuis un certain temps. Il a été mis à jour le mois dernier et quelques fonctions très intéressantes y ont été ajouté comme la possibilité de visionner de modifier et supprimer certains objets directement à partir de la carte. Il n'a jamais été aussi facile de mettre à jour/modifier et partager des objets directement à partir de la carte. Notez que vous devez avoir un facteur de zoom suffisant pour pouvoir l'apercevoir et cliquer sur les petits cercles rouge sur la carte. Remerciement à Martin, Julien et Gijs pour les mises à jour et les tests effectuer sur cet outil. Pour l'utiliser, regardez ici: http://mapserver.flightgear.org/popmap/?lat=52.47492&lon=13.38199&zoom=1...
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 [http://mapserver.flightgear.org/popmap/?lat=52.47492&lon=13.38199&zoom=16&layers=B00FFTTTTT ici].


=== Mise à jour de la licence d'OpenStreetMap ===
=== 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/


Comme vous le savez probablement, OpenStreetMap un service de carte en ligne, est maintenant en processus pour changer sa licence d'utilisation. Lorsque le changement de licence sera complété l'équipe de FlightGear sera en mesure de pouvoir utiliser les donner fournit par OpenStreetMap et de les intégrer dans la scène officielle de FlightGear. L'équipe d'openstreetmap travaille actuellement à retirer les données des contributeurs qui ne sont pas d'accord avec la nouvelle licence, le tout devrait être disponible sous peu. À suivre...
== Nouvelles de la communauté ==
 
=== FlightGear sur Youtube ===
Pour plus d'information: http://blog.osmfoundation.org/
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.
 
== Nouvelle de la communauté ==
 
=== Flight Gear sur Youtube ===
 
Fallen nous reviens avec une nouvelle vidéo qui nous démontre les capacités du nouveau système de rendu de la lumière Rembrandt. La vidéo ce déroule a San Francisco entre l'Aeroport international de San Francisco et le porte-avion U.S.S Nimitz le tout ce déroulent la nuit


FlightGear 2.8 de nuit avec Rembrandt
FlightGear 2.8 de nuit avec Rembrandt
{{#ev:youtube|q951rsP0DBk}}
{{#ev:youtube|q951rsP0DBk}}


=== Multijoueur ===
=== 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 ([http://forum.flightgear.org/ucp.php?i=pm&mode=compose&u=9926 truthsolo])
: Héberge également une nouvelle page [http://mpserver16.flightgear.org/ Statut des serveurs].


Deux nouveaux serveurs multijoueur ont été ajoutés
Ce texte fait exception à la licence générale de ce site, ce texte est disponible sous la licence GNU GPL v2.


mpserver15.flightgear.org (North Point, Hong Kong)
== Et enfin... ==
Courtoisie de Hazuki Amamiya
=== 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.


mpserver16.flightgear.org (Dallas, TX, USA)
Si vous avez besoin d'idées pour contribuer à FlightGear, vous pourriez jeter un oeil à cet article : [[Volunteer]].
Courtoisie de Rob Dosogne


Ce texte fait exception à la license générale de ce site, ce texte est disponible sous la license GNU GPL v.2.
''Merci à Alexandre pour sa traduction  http://aviactu.info/ ''
''wikification réalisé par [lolalilo]
[[Category:FlightGear Newsletter]]

Latest revision as of 12:39, 12 October 2019

Magagazine.png
Welcome to the FlightGear Newsletter!
Please help us write the next edition!
Enjoy reading the latest edition!


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.

Texturage de la carte d'altitude détaillée du terrain Réduction des contrastes entre différents types de sols Ajout dynamique de mares pour le terrain humide Offre une texture d'aéroport avec une résolution de 5 mm par pixel

(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

Scènes personnalisées avec données linéaires OSM (gauche) par rapport à l'occupation des sols VMAP0.

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

Affichage des liens de mise à jour et de suppression d'objets sur Mapserver.

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]