Fr/Nouvelles du projet FlightGear - mars 2012

From FlightGear wiki
Jump to navigation Jump to search
Magagazine.png
Welcome to the FlightGear Newsletter!
Please help us write the next edition!
Enjoy reading the latest edition!


Nous voudrions rappeler que la lettre d'informatins mensuelle ne peut pas vivre sans les contributions des utilisateurs et développeurs de FlightGear. Toute personne disposant d'un compte wiki (inscription gratuite) peut éditer la lettre d'informations et toute contribution est la bienvenue. Donc si vous êtes informé d'une nouvelle ou de projets liés à FlightGear comme par exemple la mise à jour d'une scène ou d'un aéronef, s'il vous plait sentez-vous comme invité à ajouter ces nouvelles à la lettre d'information.

Nouvelles du développement

FlightGear et l' architecture de haut niveau (High Level Architecture, HLA)

Quand on parcourt les forums FlightGear ou les listes de diffusion des développeurs, vous avez peut-être remarqué le terme «HLA» est utilisé de plus en plus fréquemment.

Dans les faits, les développeurs de FlightGear et les autres contributeurs semble utiliser ce terme dès que quelqu'un demande une meilleure modularité de FlightGear, des accès concurrents plus performants (par exemple utilisant toute la puissance de votre CPU au repos), mais également un meilleur taux d'images par seconde, une expérience multijoueurs et météo plus cohérente.

Il semblerait que le «HLA» soit le couteau suisse pour traiter plusieurs défis de longue date de FlightGear.

Donc, qu'est-ce que le «HLA» ?

En résumé, l'architecture de haut niveau est un standard de l'industrie (IEEE 1516) pour uniformiser les interactions entre les architectures de simulation à base de composants dans une configuration distribuée.

Voici une explication simplifiée: La plupart des logiciels (comme FlightGear) ont une grande base de code unique où tous les sous-systèmes obtiennent leur temps de traitement par la "boucle principale" qui parcourt le système de façon séquentielle et appelle tous les systèmes à se mettre à jour, de manière à donner à chaque système le temps nécessaire pour réaliser son travail (mettre à jour la météo, l'interface graphique, le FDM, le son, etc.).

Malheureusement, ceci veut aussi dire que chaque sous-système qui fonctionne comme une partie de la boucle principale a un effet direct sur le nombre d'images par seconde. Le temps de fonctionnement de chaque cycle de mise à jour est déterminé par le temps utilisé par chaque routine. À cause de ceci, le temps de mise à jour ajoute à la perte d'image par seconde : tous les travaux du FDM, du son, de l'intelligence artificielle (AI), de l'interface graphique ajoutent à la perte d'image par seconde.

De manière simple, tout le travail que FlightGear doit réaliser sont des sous-routines séparées et plus qu'il y en a, avec l'information associées, plus le taux d'images par seconde est affecté de façon négative.

Si vous ajoutez un nouveau système, vous devez l'ajouter à la boucle principale et ajouter des nouveaux fichiers sources à la base de code du programme. Ceci implique de reconstruire FlightGear à partir des sources.

Dans l'architecture de haut niveau HLA, l'idée générale est de séparer une simulation conséquente en un ensemble de petites simulations qui sont interconnectées et échangent des informations (objets et évèneemnts) pour créer un environnement de simulation cohérent en utilisant un interfaçage bien défini. Cette séparation permet d'exécuter ces simulations dans différents fils d'exécutions, processus ou même sur d'autres ordinateurs.

Seule l'information qui doit réellement être échangée est échangée, donc l'échange est le seul évènement qui laisse son empreinte dans le temps d'exécution, chaque simulation effectue ses calculs et se met à jour selon son propre état.

Les communications entre chaque noeud de simulation a lieu sur un réseau d'ordinateurs et un API (similaire à COBRA). Toutes les simulations participantes sont contrôlées par un composant central nommé "Run-Time Infrastructure". Le RTI surveille la simulation globale et gère la distribution des données entre tous les noeuds individuels, qui sont appelés "fédérés". La simulation dans son ensemble est appelée une "fédération" en HLA.

Nous avons créé un nouvel article et y avons copié des annonces antérieures et des messages; allez lire FlightGear HLA support (High Level Architecture) pour plus d'informations

FlightGear en orbite, Deuxième épisode

Codé en moins de 8 heures, le moteur de rendu orbital de terrain de la vue de la terre est un module pour FlightGear, qui permet l'utilisation de textures photoréalistes orbitales au-dessus des textures par défaut du terrain de FlightGear. Combiné avec l'effet skydome, ceci améliore grandement le réalisme du visuel dans les vols orbitaux dans FlightGear

Earthview07.jpgEarthview06.jpgEarthview05.jpg

Avec quelques corrections supplémentaires, Vostok-1 est libre de la restriction de 150 km d'altitude et peut entrer dans des orbites très hautes de plusieurs centaines de kilomètres au-dessus de la planète bleue.

Earthview09.jpgEarthview10.jpgEarthview11.jpg

Nous espérons que ceci déclenchera de l'activité du côté des développeurs pour ajouter quelques nouveaux engins spatiaux à l'expérience FlightGear !

Discussion du développement et téléchargement : sujet du forum.

FlightGear entre ombre et lumière

Le projet Rembrandt, qui a débuté comme une démonstration de faisabilité et qui était hébergé dans un dépôt séparé, est est en cours d'intégration dans le dépôt principal. Une nouvelle option (--enable-rembrandt ou --prop:/sim/rendering/rembrandt=true pour FGRun) est disponible pour démarrer FlightGear avec ce nouveau rendu. Sans cette option, les scènes doivent être rendues comme à leur habitude. Avec cette option, vous pouvez obtenir ceci :

Rembrandt-vinson-iar80.jpg Rembrandt-ksfo-iar80.jpg

ou encore :

Rembrandt-ksfo-night-iar80.jpg Rembrandt-ksfo-night-hurricane.jpg

Le moteur de rendu fait encore l'objet de plusieurs dysfonctionnements connus (les ombres disparaissent suivant les angles, en agrandissant les vues, on obtient parfois des artéfacts de couleurs, ...) et peu de modèles et shaders sont prêts pour ce nouveau rendu. Une page wiki collecte les détails techniques du projet et devrait aider les développeurs pour convertir leurs modèles. N'hésitez pas à contribuer à cette page pour la clarifier si nécessaire.

Entretien avec un contributeur

Dans chaque édition, nous essayons d'interviewer un contributeur. Malheureusement, il n'y a pas eu d'entretien pour cette édition, donc nous vous invitons à écrire un entretien (avec vous-même ou d'autres) pour la lettre d'information du mois prochain ! Les suggestions pour des questions possibles sont disponibles ici.

Le coin des scènes

Aéroport International de Miami

KMIA Prévisualisation dans Sketchup

Andryramone a terminé son année sabbatique loin de FlightGear et a recommencé à travailler sur la modélisation de l'aéroport international de Miami (KMIA). Il y a un modèle de base pour le terminal principal, qui devrait être disponible via TerraSync à la mi-mars.

Le plan est, par la suite, d'améliorer le modèle en ajoutant des textures plus fidèles, des textures de nuit, des rampes mobiles d'accès aux avions et d'améliorer la position des voies de circulation et possiblement les porter vers le format 850. Les hangars avoisinants, bâtiments et hangar cargo dans le sud seront aussi ajoutés à fur et à mesure qu'il sont développés.

Tous les modèles respecteront la licence GPL et seront disponibles via TerraSync.

Mises à jour de TerraGear GUI

Le mois dernier, TerraGear GUI, une interface graphique qui permet de générer des scènes FlightGear, a été mis à jour à la version 0.9.0. Cette dernière version apporte le support pour le format de X-Plane (et le futur format de FlightGear) apt.dat 850. Ce format autorise les créateurs d'aéroports à modéliser des voies de circulation avec des courbes, des lignes et un éclairage précis, ainsi qu’un périmètre personnalisé et beaucoup plus.

Bien que le support du 850 soit toujours en développement, il est assez mature pour être testé par les collaborateurs habituels de FlightGear. Pour plus d'informations et le téléchargement, voir TerraGear GUI.

Avion du mois

La famille A320 améliorée (Airbus A320 Family et Airbus A320neo) a été nommée dans la catégorie "Avion du mois".

EmbedVideo was given an illegal value for the alignment parameter "Avion du mois - Famille Airbus A320/NEO". Valid values are "left", "center", "right", or "inline".

Aéroport du mois

EPWA night.png EPWA service.png

L'aéroport de Varsovie/Chopin Warsaw Chopin Airport (EPWA) est l'aéroport le plus actif de la Pologne. Cet aéroport est inclus dans les scènes de la Pologne (Poland) qui est disponible à l'adresse this link. Cette scène contient :

  • Custom airport layout (v.810)
  • Taxiway signs
  • Terminals, hagars, tower models
  • Day/night photorealistic textures
  • Details like custom lamps
  • Airport service vehicles (ot-666 models)

Capture d'écran du mois

Piper Comanche 250 au large de San Diego.

Comanche1.jpg

Suggested flights

Searching Wizard Island

  • USA, Oregon, Klamath County

With one VORTAC behind our back we do an IFR/VFR search of Wizard Island, a mysterious place, a sacred place for native Americans. You might even find the Old Man of the Lake.

Don't pull up the map, that would spoil the surprise but I promise unique views. We will land on a short lawn runway. Terrain altitude will range from 4,000 to a max of 8,930 feet and down again. Total length of the trip will be about 50 NM. Select your aircraft with care. It must have one working navigational radio (VOR-DME), a strong engine, a strong undercarriage, must be capable of a good climb and a steep descend. I suggest to use Fair weather (Environment=>Global Weather). If needed remove some clouds (View=>Rendering Options=>Slider 3d Clouds to the left).

Mount Scott (8929 feet) just after depart from 2S7 (Two Sierra Seven). Wizard Island is just to the North-West of it.
  • Park your aircraft on 2S7 (Two Sierra Seven), Chiloguin-State.
  • Set NAV1 on 115.9 (Klamath Falls VORTAC) and on radial 323o (Magnetic). We are at an elevation of 4,217 feet. Set QNH. Set heading bug at 275o (Magn).
  • Take off an fly the course set with the heading bug.
  • Intercept the radial.
  • Monitor distance and you will find Wizard Island at 50 NM from Klamath Falls. The island has an elevation of 6,673 feet. I suggest a full 360o turn, take pictures.
  • Set radial 318o, keep the same frequency. Do a new radial intercept.
  • Try and find the airstrip (3S6, Three Sierra Six, Toketee-State) at 71 NM from Klamath Falls with an elevation of 3,361 feet, runway heading 275o (Magn). There are bumps around you should avoid.
  • If you are capable of finding the island, finding the airstrip and landing without a crash, in one go..., you are a wizard.

Click this link after you have landed so you know what amazing landscape you have seen.

Wiki updates

Uploading files

As of this month, it is possible to license files on the wiki under licenses other than the GPL (which isn't a good license for images anyway). In the upload form, a dropdown menu allow you to pick a license of your choice (or, when uploading an image from another source, the license compatible with that source). This will automatically add the corresponding template to your file and place it in the license's category.

Besides licensing your files, it is also important to describe them. Therefore a file information template was introduced, which holds a description of the file, the author's name, the source and the creation date. Please add this template to your file right during the upload process.

More information on licenses and the information template can be found at Help:Upload.

Community news

FlightGear on YouTube

Forum news

As of March, the forum team welcomed a new moderator: Hal (hvengel). He will help the team to combat spam, move topics to the right subfora and mediate when issues a rise. We wish Hal all the best in his new job!

And finally ...

Contributing

One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.

For ideas on starting to contribute to FlightGear, you may want to check out: Volunteer.

Call for volunteers

  • The OpenRadar project is looking for a new maintainer.
  • The FGFSPM (FlightGear Package Manager) is looking for a new maintainer.

Did you know

Torsten recently introduced a new internal command in Git: property-interpolate.

This exposes the SGInterpolator subsystem to bindings in xml animation files. The SGInterpolator allows the interpolation of property values over time and has so far been used via Nasal in aircraft.door.

For an example, start the Hansajet from git (fgfs --aircraft=Hansajet) and zoom to the gyrosyn heading indicator left of the HSI. Locate the black/white knob with "VOR" and "ADF" written on it. Click it (it swaps the assignment of the needle-driving sources) and notice that it does rotate smoothly to its new position (it's a 2-position toggle knob).

Now, look at the overhead panel, either by paning the view up and right or by pressing Shift-V on the keyboard. Locate the six rotary buttons GEN.1, GEN.2, ALT.1, ALT.2 and the two between the AC and DC instruments. Move them by clicking their left/right edges. Notice they move smoothly instead of jumping to the new position.

Thats done completely without Nasal but from just a few lines in the animation files. Basically, you have to add two bindings to the <pick> animation:

  1. property-assing the target value describing the state of the button
    (that's what you are used to do)
  2. property-interpolate the position of the model to it's new state's value
    (that's the new binding to add)
  3. Animate the model's rotation from the position property, not the state property
    (that's what you have to change)
  4. done.

See the animations for the object SyncKnob and SyncKnobPick.[LR] in Aircraft/Hansajet/Models/Sperry-C-6d.xml as an example.

The use of the property-interpolate may be:

Change the value of /some/target/property to the constant value of 100.0 over 3 seconds.

<binding>
   <command>property-interpolate</command>
   <property>/some/target/property</property>
   <value>100.0</value>
   <time>3</time>
</binding>

Change the value of /some/target/property to the value of /some/source/property over 0.5 seconds.

<binding>
   <command>property-interpolate</command>
   <property>/some/target/property</property>
   <property>/some/source/property</property>
   <time>0.5</time>
</binding>