Script flightgear

Bonjour tout le monde,

Suite au message de Charles, je pense qu'il serai bien de développer un script pour Blender d'import-export de fichier ac. Mais aussi un script permettant l'export d'animation. En ce moment je développe un script pour incorporer les avions de x-plane dans mon programme. Mais il serai vraiment intéressant, de faire le même genre de script pour flightgear.

Sur la copie d'écran, on peut voir que ce script ajoute des nouveaux "panels" dans l'interface de blender, pour finalement créer les fichiers nécessaire à mon programme. On pourrait faire de même avec les fichiers xml et ac de fg.

En plus il serait bien de faire évoluer ses scripts avec l'api de blender , car cette api change souvent.
Bien-sur le git de la paf serai un endroit tout désigner pour héberger ces scripts ....




Amicalement René

Salut René,

C'est énorme ce que tu fais ! (je suis sérieux !)

Évidemment si on pouvait faire la même chose pour FG ça révolutionnerai totalement la façon de créer un avions (dans le bon sens).
Je crois savoir que Alexis s'est mis au python dans le but de créer des scripts pour Blender, je ne sais pas où il en est de son apprentissage.

À priori le script d'import/export de fichier AC a déjà été mis à jour pour Blender 2.6x : http://www.flightgear.org/forums/viewtopic.php?f=18&t=13442

Sur quel base pourrions nous partir pour créer ce script ? Ton travail peut être une bonne base ? ou est-il trop dédié à ton programme et il serait plus rapide d'en créer un nouveau plutôt que de l'adapter ?

Peux-tu fournir tes fichiers ? C'est du python ? Aurais-tu une vidéo de démonstration de ce que peux faire ton script avec Blender ?

(Je n'ai pas changé... je pose toujours autant de question désolé^^ )

Amicalement,
Clément

F-JJTH a écrit:Sur quel base pourrions nous partir pour créer ce script ? Ton travail peut être une bonne base ? ou est-il trop dédié à ton programme et il serait plus rapide d'en créer un nouveau plutôt que de l'adapter ?

1er question : c'est à vous de définir ce qu'il doit faire ... ( par exemple il faut une arborescence de fichier commune aux avions, quel type d'animatiions, etc... )
2eme question : Je pense que oui .... car, dans blender, on peut definir de nouvelle propriété pour les objets. On peut définir des propriété spécifiques à flightgear.
3eme question : Je pense qu'il vaut mieux repartir de zéro. Mais je peux réécrire facilement un squelette de script.

En fait j'aimerai l'abandon du format .ac, pour le format obj. Le format ac3d, tel qu'il est utilisé aujourd'hui, ne sauvegarde pas les normales, et cela me gêne. En plus faudrait regarder de plus prêt le "normal-map" pour pouvoir y faire de belle chose.

P.S. Bizarre je ne vois plus ma recopie d'écran sur le post initial.

Salut,
Un tel script serait une super avancée. J'avais effectivement essayé de travaillé sur un script en partant de zéro. J'ai beaucoup lu, pour apprendre à programmer en python. Mais il n'y a pas que ça, il faut aussi étudier l'api de blender, et là c'est une autre histoire.

J'avais écrit quelques scripts, notamment pour générer du xml, j'arrivais à reproduire quelques animations simples dans blender avec python, j'ai essayer de parser du xml sans succès. Il faut avoir un peu de bouteille pour pondre un tel script, mais l'aide qu'il peut apporter est énorme !

Re,


Juste une petite question ... peut-on avoir des animations imbriqués dans flightgear ?
par exemple un truc comme cela

Code:


<animation>
  <type>rotate</type>
    <object-name>AnimeTete</object-name>
    <property>controls/flight/rudder</property>
    <factor>-25</factor>
    <center>
      <x-m> 0.366 </x-m>
      <y-m> 0.005 </y-m>
      <z-m> 0.411 </z-m>
    </center>
    <axis>
      <x> 0.000 </x>
      <y> 0.000 </y>
      <z> 1.000 </z>
    </axis>

    <!-- puis une deuxieme animation subissant la premiere -->

    <animation>
      <type>rotate</type>
        <object-name>AnimeTete</object-name>
        <property>controls/flight/rudder</property>
        <factor>-25</factor>
        <center>
          <x-m> 0.366 </x-m>
          <y-m> 0.005 </y-m>
          <z-m> 0.411 </z-m>
        </center>
        <axis>
          <x> 0.000 </x>
          <y> 0.000 </y>
          <z> 1.000 </z>
      </axis>
    </animation>
  </animation>



Cela aiderai bien pour avoir des cinématiques complexe de train d'atterrissage, tout en utilisant les parentés d' armatures de blender.
Et une autre question : est-on obligé de fournir le nom d'un objet(ou d'une liste) pour une animation ??? Peut-on avoir juste une transformation affectant les transformations "enfants". (Je ne sais pas si je suis clair )

A+

1) À ma connaissance il n'est pas possible de faire des animations imbriqué.
Pour créer des mouvements les uns après les autres on utilises une propriété qui varie entre 0 et 1 et on dit par exemple :
entre 0 et 0.25 : l'objet blabla doit faire une rotation de 25°
entre 0.26 et 0.50 : l'objet ririri doit faire une translation de 12cm
entre 0.51 et 0.75 : .... etc etc etc

Bien entendu on peut faire varié la vitesse de variation de la propriété utilisé comme "repère temporel"

2) Tu veux parler des groupes d'objets qu'il est possible de faire dans Blender ? (et dont j'ai aucune idée de comment on fait)
Si c'est ça : tu peux faire des groupes d'objet et animer ce groupe entier. Mais oui on est obligé de renseigner le nom d'un objet, sinon FG ne sait pas quel objet il doit animer.

Sauf erreur, je dirais non. En revanche l'ordre des animations est important. Lorsque deux animations concernent un même objet, la deuxième animation est incluse dans la première.

Et une autre question : est-on obligé de fournir le nom d'un objet(ou d'une liste) pour une animation ??? Peut-on avoir juste une transformation affectant les transformations "enfants". (Je ne sais pas si je suis clair )

Je suis pas certain de comprendre


Souhaite-tu utiliser les armatures de blender ? Lorsque j'avais essayé d'intégrer les animations dans blender, j'avais pensé que l'utilisation des courbes IPO serait vraiment très simple, surtout lorsqu'il y a des interpolations qui entrent en jeux.

Comme un dessin vaut mieux qu'un long discours..
Je t'ai fais une recopie d'écran de l'animation du train d'atterrissage d'un fw190.
On vois, par exemple, que certaine certaine bielle en plus de subir une rotation propre, subissent en plus la rotation de la jambe du train.
Et ma question est la suivante. Comment dire à flightgear de faire subir une rotation à une bielle mais en plus de lui faire faire la rotation du train ?

Si j'ai bien compris il faut un truc du genre

Code:


<animation>
<propriété associé>
<objectname>bielle
<vecteur>
<point>
</animation>

puis....

<animation>
<propriété associé>
<objectname>jambe
<objectname>bielle
<vecteur>
<point>
</animation>


Bien-sur pour les animations je compte utiliser les armatures de blender qui sont finalement assez intuitive. (une fois qu'on les configurent correctement). En les spécialisant sur des rotations par exemple. On limitent, leur rotations en local. Et en travaillant en "Euler XYZ", le paramètre Y donne l'angle de rotation autour de l'axe. Et l'interpolation peut se faire en insérant des "keyframe". A chaque "keyframe" on connaît la valeur de l'angle par exemple.

Salut rené,
Je comprends bien ce que tu souhaite faire. Dans ce cas l'animation de la bielle et du train ne sont pas vraiment dépendantes enfin tout dépend où tu place tes centres de rotation. Je m'explique :

Sur tes captures, en regardant comment les armatures sont disposées, je crois comprendre qu'il n'y en a pas entre le train et la bielle. Dans FG ça donnerait tout d'abord une rotation de la jambe du train

Code:


<animation>
<propriété associé>
<objectname>jambe
<centre de rotation>
<axe de rotation>
</animation>


Et il y a ensuite l'animation de la bielle en deux parties et dans cet ordre

Code:


<animation>
<propriété associé>
<objectname> Bielle 1 et Bielle 2
<centre de rotation> bielle axe 1
<axe de rotation>
</animation>

<animation>
<propriété associé>
<objectname> Bielle 2
<centre de rotation>  bielle axe 2
<axe de rotation>
</animation>


En schéma, ça donne :


Si on avait inversé les animations entre les deux pièces de la bielle, le centre de rotation 2 n'aurait pas bougé causant de gros soucis car l'objet 2 lui aura bougé. En fait la première animation fait bouger les deux pièces ainsi que l'axe de rotation 2.

Mais cette solution présente un problème, étant donné que les deux éléments du train ne sont pas dépendant, ça devient compliqué de trouver les angles exactes de rotation et la jonction entre ces deux éléments peut être chaotique.

L'autre manière consisterait à lier les deux éléments par un axe de rotation, voilà ce que ça donnerait :


Ici tout est lié et ça donnerait quelque chose comme ça :

Code:


<animation>
<propriété associé>
<objectname> Jambe Bielle 1 et Bielle 2
<centre de rotation> axe 1
<axe de rotation>
</animation>

<animation>
<propriété associé>
<objectname> Bielle 1 et Bielle 2
<centre de rotation>  axe 2
<axe de rotation>
</animation>

<animation>
<propriété associé>
<objectname> Bielle 1
<centre de rotation>  axe 3
<axe de rotation>
</animation>


(la bielle 1 est la partie haute et la bielle 2 est la partie basse)

En temps normal, il faut trouver les bon angles pour tomber juste. Notons ici que c'est la jonction bielle/aile qui est problématique, le reste sera toujours lié. Mais en utilisant blender, je pense qu'on pourrait trouver bien plus facilement ces angles.

Une troisième solution consisterait à déplacer l'axe de rotation 3 au niveau de la jonction aile/bielle.

J'avais rédigé ceci d'ailleurs sur les rotations : https://equipe-flightgear.forumactif.com/t595-cours-les-rotations-dans-flightgear

Dans les animations de FlightGear, il y a toujours une partie "libre", on ne peut pas lier les éléments entre eux. Dans blender, on peut dire qu'un élément est relié à un autre et le logiciel va "comprendre" que lorsqu'on fait bouger une partie, l'autre va suivre, ça n'est pas le cas dans FG et ça peut vraiment compliquer les choses. En fait, c'est pour ça que je te parlais de courbes IPO. FlightGear fonctionne comme les animations par courbes IPO et les keyframe de blender en utilisant les objets. Les armatures sont bien sûr très intéressantes, mais il faut traduire ça en ce que comprend FG.

Pour ce qui est des interpolations, elles sont toujours linéaires dans FG. Passer d'un point A à un point B se fait à vitesse constante. La courbe de l'animation dans blender sera uniquement constituée de droites. Gérer la vitesse de l'animation se passe par l'ajout de nouvelles valeurs dans l'interpolation.

Je me demandais comment tu pensais traduire tout ce qui se passe dans blender en xml. J'avais eu l'idée de me rapprocher de ce qui se fait dans les logiciels en pythons servant à créer des pages html. Je pensais à une liste de listes, c'est pas très intuitif mais ça fonctionne. Une liste d'animations contenant une liste de paramètres contenant elle même une liste de paramètres...

Voilà, en tout cas c'est une idée super ce script et je suis prêt à répondre à toute tes questions et te donner toute l'aide dont tu aura besoin.

Alexis a écrit:Je me demandais comment tu pensais traduire tout ce qui se passe dans blender en xml. J'avais eu l'idée de me rapprocher de ce qui se fait dans les logiciels en pythons servant à créer des pages html. Je pensais à une liste de listes, c'est pas très intuitif mais ça fonctionne. Une liste d'animations contenant une liste de paramètres contenant elle même une liste de paramètres...

Ci qui n'est pas simple, au début, c'est de comprendre comment sont organisé les données dans blender, et la confusion que cela peut entraîner
Par exemple tout commence avec la liste suivant:
bpy.data.objects

Elle contient tous les objets de blender, camera, mesh lamp armature etc.., avec des propriétés individuelles.
bpy.data.objects['Cube'] : fait référence à un objet Cube qui contient un mesh
bpy.data.objects['Lamp'] : fait référence à un objet Lanp qui contient une lampe

Par exemple , tous les objets de blender ont une position dans l'espace
bpy.data.objects['Cube'].location
bpy.data.objects['Lamp'].location

Lorsque l'on veut accéder au données des objets les choses se compliquent. en effet les meshs les lampes, les armatures, etc.. ont leur propre liste.
bpy.data.lamps : liste des lampes
bpy.data.meshes : liste des meshs
bpy.data.armatures : liste des armatures
etc...

Pour connaître les données des objets on utilise la propriéte data de l'objet, ainsi:
bpy.data.objects['Cube'].data == bpy.data.meshes['Cube']
bpy.data.objects['Lamp'].data == bpy.data.lamps['Lamp']

Ce qui prête à confusion c'est le nom des objets et le nom de leur données. En effet ces noms ne sont pas forcement identique. On peut avoir la chose suivante
bpy.data.objects['aileron'].data == bpy.data.meshes['Cube']
bpy.data.objects['soleil'].data == bpy.data.lamps['Lamp']

En français on peut traduire " bpy.data.objects['aileron'].data == bpy.data.meshes['Cube'] " comme cela:
'aileron' est un objet de type mesh dont les données ont pour nom 'Cube'
bpy.data.objects['aileron'].type == 'MESH'
bpy.data.objects['aileron'].data == bpy.data.meshes['Cube']

On peut retrouver les noms avec les propriétés associé :
bpy.data.objects['aileron'].name == 'aileron'
bpy.data.objects['aileron'].data.name == 'Cube'
bpy.data.meshes['Cube'].name == 'Cube'

Voilà pour clarifier les noms des objets et le lien entre eux.




Pour en revenir aux bielles


Il y a deux armatures bielle-1 et bielle-2 qui sont liés par une parenté
bpy.data.objects['bielle-2'].parent == bpy.data.objects['bielle-1']
bpy.data.objects[bielle-1].parent == None

On peut traduire dans un pseudo-langage par:

Code:


Pour toutes les armatures
    Pour toutes les armature enfants
        Ecrire le nom des objets(mesh) liés à l'enfant
        enfant suivant
    Ecrire le nom des objets (mesh) liéé à cette armature
    Ecrire les paramètre de cette armature
    armature suivante


Il faudra certainement écrire une fonction récursive pour parcourir l'arbre de parenté. Et les fonctions récursives ne sont vraiment pas simple à écrire au début. Je ne sais pas si tu trouveras des chose simples décrivant ces foncions sur le net. Mais c'est l'étape suivante dans la programmation. Indispensable (quoique..) pour ce cas.
Mais ne t'inquiètes pas , je m'en charge.

Par contre ... ce qui serai bien c'est de me donner une liste des propriétés de flighgear du genre <property>surface-positions/flap-pos-norm</property>
pour associer une armature de blender avec une propriété de flightgear

_run_ a écrit:
Ci qui n'est pas simple, au début, c'est de comprendre comment sont organisé les données dans blender, et la confusion que cela peut entraîner

Exactement, il y a une quantité phénoménale de fonctions et ça évolue tout le temps, perso je m'y perds vraiment. Il y a aussi tout un tas de choses à soir, je ne pensais pas jusqu'à maintenant que les noms d'objets pouvait entrainer ces difficultés.
Je comprends ce que tu souhaite faire avec la récursion, j'ai eu l'occasion de voir des exemples de fonctions récursives, et effectivement, il ne vaut mieux pas que je me penche sur ces casse tête

Pour ce qui est des propriétés, c'est effectivement une autre problématique. Comment pensais tu aborder les choses ?. Il y en a un certain nombre, elles ne réagissent pas forcément de la même manière. Peut-être commencer par intégrer quelques éléments principaux (ailerons, volets ect...). Pourquoi pas associer ça à un manche et pouvoir agir sur toutes les commandes... D'ailleurs je pense que je serais capable d'en ajouter après avoir visionné quelques exemples
Pour ce qui est d'une liste des prop : http://wiki.flightgear.org/Property_Tree/Reference
Ou bien dans data/Docs/README.properties

Pour le moment, on passe de Blender à FlightGear, mais ça serait réalisable de faire le contraire ? blender lit le fichier xml et va créer les armatures nécessaires.

Autre chose qui peut devenir casse bonbon, les coordonnées. Vois-tu lorsqu'on sépare des éléments en plusieurs fichiers placés par du xml, l'ensemble des animations vont s'effectuer suivant un nouveau centre, gros soucis donc car les coordonnées sont différentes. Bon pour le moment, il vaut mieux se concentrer sur 1 seul fichier à la fois, mais gérer toute une arborescence de fichier 3D et xml serait vraiment énorme

Désolé, je divague un peu
@++, Alexis

lol, mais non alexis tu ne divagues pas du tout.


Pour le passage de flightgear à blender .... effectivement cela sera plus compliqué. Car les fichiers d' avion de flightgear sont souvent ecrit (ou modifé) à la main. Il est souvent tres, voir tres tres compliqué d'ecrire un programme qui tente de comprendre la logique humaine ( ). C'est comme ecrire un programme de reconaissance d'écriture, chacun a sa propre écriture. Mais dans 90% des cas il n'y a rien d'insurmontable.

Pour l'instant, je pense qu'il vaut mieux parler de création d'un avion avec blender où le script pourra écrire toutes les animations et certains paramètres de l'avion vers flightgear. Le chemin inverse sera obligatoirement faisable, si les fichiers ne sont pas modifiés par un humain.

En lisant quelques fichiers xml du dc-3, j'avais remarqué que lors d'inclusion d'un autre fichier xml, un paramètre d'offset était utilisé. ce qui indiquait un changement de centre.
Ce n'est pas un problème, ces problèmes de référence sont encore pire dans les données de blender, avec la parenté.
Les fichiers des instruments (par exemple) décrivent des animations d'aiguille dont le centre (de l'aiguille) est la réference de l'objet. D'ou l'offset .... (precises, si je me trompe)
A moins d'utilisation de matrice 3x3, et d'un calcul vectoriel, les animations d'instrument pourront travaillé avec un centre quelconque. Donc revenir à un offset à 0 pour tout le monde. Le même centre pour tout les fichiers je trouve cela beaucoup plus sains


Super le lien ....
Il me faut savoir comment evolue les propriétés .... entre 0et 1 .... entre -1 et 1 ...
J'ai trouvé aussi dans le fichier de dc-3 des choses comme "indicated-altitude-ft" est-ce générale ou particulier ??


Merci a+

Salut rené,

C'est amusant, tout ce que j'avais fait n'a pas été très concluant d'un point de vue production, mais j'ai eu l'occasion de réfléchir à pas mal des problématiques d'un tel script, il y a d'ailleurs d'autres petites choses qui me viennent à l'esprit au fil des messages. Je me dis que créer un tel script passe par un grande phase de compréhension de ce qu'on veut mettre en place et de comment le mettre en place.

Pour ce qui est de la lecture d'un fichier écrit par un humain, Il existe des parseur assez perfectionnés qui peuvent être réutilisés et optimisés pour FG. J'ai fait quelques essais, je manipulais avec pas mal de difficultés les données xml, mais j'ai bien vu que s'était réalisable. Je m'étais dit qu'il faudrait mettre en place des "règles" de mise en page. Dans python, la mise en forme à une grande importance (tabulation ect) et facile au passage la lecture. Mettre en page automatiquement des fichier xml écrit par des humains serait pas si complexe. Il faut arriver à analyser l'arborescence des balises ect... enfin bref, ça n'est pas à l'ordre du jour. Mais quand il sera question de lecture de xml, il faudra le passer à la moulinette avec une petite fonction de mise en page et de suppression des petites conneries...

Les fichiers des instruments (par exemple) décrivent des animations d'aiguille dont le centre (de l'aiguille) est la réference de l'objet. D'ou l'offset .... (precises, si je me trompe)

Exactement, c'est un des avantage de cette solution. Il y a aussi la possibilité de travailler à plusieurs sur un avion sans se gêner, c'est le deuxième gros atout.

Alors pour les propriétés, plusieurs choses,
Tout d'abord, pour répondre à ta question, à savoir comment évoluent les propriétés, c'est assez particulier, elles n'évoluent pas toujours de la même manière. Ce que je peux déjà dire, c'est que pour toutes les surfaces mobiles comme les ailerons, volets, profondeur, toutes varient de -1 à 1 :

/controls/flight/aileron
/controls/flight/aileron-trim
/controls/flight/elevator
/controls/flight/elevator-trim
/controls/flight/rudder
/controls/flight/rudder-trim

"indicated-altitude-ft" est-ce générale ou particulier ??

Cette prop est présente sur tout les avions, pour animer l'aiguille de l'alti notamment

J'avais essayé de trouver une manière de gérer les propriétés. Peut-être un genre de fonctionnement par hérédité des prop. Je sais pas si tu vois de quoi je parle, mais les prop fonctionnants d'une même manière vont présenter les mêmes caractéristiques dans blender. Enfin, je ne sèche un peu là dessus, j'ai pas trop d'idées.
Mais il y a autre chose, je m'étais dit, lorsqu'un objet s'appelle "aileron", il ne va pas y avoir trente six milles possibilités de choix pour la propriété, alors pourquoi pas avoir des propositions de propriétés lorsqu'on veut animer un objet J'avais écrit un petit script :
D'un côté on a un fichier texte, une base de donnée des propriétés, et ensuite, après un ":" se trouve des mots clés

Code:


/controls/flight/aileron:AILERON
/controls/flight/aileron-trim:AILERON-TRIM
/controls/flight/elevator:ELEVATOR
/controls/flight/elevator-trim:ELEVATOR-TRIM
/controls/flight/rudder:RUDDER
/controls/flight/rudder-trim:RUDDER-TRIM
/controls/flight/flaps:FLAPS:volet
/controls/flight/slats:SLATS
/controls/flight/BLC:BLC
/controls/flight/spoilers:SPOILERS
/controls/flight/speedbrake:SPEEDBRAKE
/controls/flight/wing-sweep:WING-SWEEP
/controls/flight/wing-fold:WING-FOLD
/controls/flight/drag-chute:DRAG-CHUTE
/controls/engines/throttle_idle:THROTTLE_IDLE
/controls/engines/engine[%d]/throttle:THROTTLE
/controls/engines/engine[%d]/starter:STARTER
/controls/engines/engine[%d]/fuel-pump:FUEL-PUMP
/controls/engines/engine[%d]/fire-switch:FIRE-SWITCH
/controls/engines/engine[%d]/fire-bottle-discharge:FIRE-BOTTLE-DISCHARGE
/controls/engines/engine[%d]/cutoff:CUTOFF
/controls/engines/engine[%d]/mixture:MIXTURE
/controls/engines/engine[%d]/propeller-pitch:PROPELLER-PITCH
/controls/engines/engine[%d]/magnetos:MAGNETOS
/controls/engines/engine[%d]/boost:BOOST
/controls/engines/engine[%d]/WEP:WEP
/controls/engines/engine[%d]/cowl-flaps-norm:COWL-FLAPS-NORM
/controls/engines/engine[%d]/feather:FEATHER
/controls/engines/engine[%d]/ignition:IGNITION
/controls/engines/engine[%d]/augmentation:AUGMENTATION
/controls/engines/engine[%d]/afterburner:AFTERBURNER
/controls/engines/engine[%d]/reverser:REVERSER
/controls/engines/engine[%d]/water-injection:WATER-INJECTION
/controls/engines/engine[%d]/condition:CONDITION
/controls/fuel/dump-valve:DUMP-VALVE
/controls/fuel/tank[%d]/fuel_selector:FUEL_SELECTOR
/controls/fuel/tank[%d]/to_engine:TO_ENGINE
/controls/fuel/tank[%d]/to_tank:TO_TANK
/controls/fuel/tank[%d]/boost-pump[%d]:BOOST-PUMP[%D]
/consumables/fuel/tank[%d]/level-lbs:LEVEL-LBS
/consumables/fuel/tank[%d]/level-gal_us:LEVEL-GAL_US
/consumables/fuel/tank[%d]/capacity-gal_us:CAPACITY-GAL_US
/consumables/fuel/tank[%d]/density-ppg:DENSITY-PPG
/consumables/fuel/total-fuel-lbs:TOTAL-FUEL-LBS
/consumables/fuel/total-gal_us:TOTAL-GAL_US


(d'ailleurs je m'étais amusé à faire un script pour générer le mot clé en majuscule en fonction de la prop)

on a ensuite un script python:

Code:


# -*- coding: cp1252 -*-
import os
from fonctions import *
from string import capwords
choix = 'XX'

with open('property.txt','r') as f:
    print ('data charge')
    prop_objet = []
    listeprop_objet = []
    for ligne in f:
        prop_objet.append(ligne.strip(' \n').split(':'))
       
suite = 'y'
while suite != 'n':
    objet = input('nom de l\'objet')
    i = 0
    while i != len (prop_objet):
        liste = prop_objet[i]
        i=i+1
        if objet.upper() in liste:
            print(liste[0])
            i = len(prop_objet)


#choix = propertybrowser(objet,property)

print('Il est probable que la propriété que vous cherchez est')


On entre un nom d’élément et python cherche dans la liste ce qui peut correspondre. J'aurais même pu ajouter des choses, comme l'ajout de mots clés automatiquement au fil du temps par le logiciel et son utilisateur ect...

Je dis ça juste pour te montrer ce à quoi j'avais pensé, j'avoue ne pas trop savoir quoi faire pour gérer simplement les propriétés. Mais en même temps il n'y en a pas énormément à intégrer au script. Toutes les surfaces mobiles et surtout le train (qui peut devenir horrible à animer)


En tout cas je suis super content de voir l'idée du script revenir sur le tapis !
@++, Alexis

Tiens Alexis .... essaye ça

C'est juste pour te montrer comment flightgear peut s'intégrer dans blender. Les animations deviendraient bien plus simple en n'utilisant que blender.

Pour voir cela tu créer les trois fichiers avec un copier-coller, dans un repertoire(respectes les noms). Ce répertoire tu le recopies dans le répertoire add-on de blender.
Puis tu actives le script dans blender "Ctrl-Alt U"

Ensuite dans blender tu ajoutes une nouvelle armature. Tu verras dans le volet tool shelf de la fenêtre 3D un nouvel onglet du doux nom de flightgear. (touche T)

J'espere que les tabulations passeront , python est sensible .....

Regardes les messages d'erreur sur la console, car je ne suis pas chez moi , et je ne dispose pas de la derniere version de blender. Je suis avec la version 2.57 de mon portable.


fichier : anim_props.py

Code:

import bpy








class fgAnimSettings(bpy.types.PropertyGroup):


   familly = bpy.props.EnumProperty(      attr='familly',
                                 name='familly',
                                 description="familly animation",
                                 default='none',
                                 items=[   ('none','none','none'),
                                       ('controls','controls','controls'),
                                       ('instrumentation','instrumentation','instrumentation'),
                                       ('flight_control','flight_control','flight_control'),
                                       ('engines','engines','engines'),
                                       ('fuel','fuel','fuel'),
                                       ('gear','gear','gear'),
                                       ('anti-ice','anti-ice','anti-ice'),
                                       ('electric','electric','electric'),
                                       ('pneumatic','pneumatic','pneumatic'),
                                       ('pressurization','pressurization','pressurization'),
                                       ('lights','lights','lights'),
                                       ('armament','armament','armament'),
                                       ('seat','seat','seat'),
                                       ('apu','apu','apu'),
                                       ('autoflight','autoflight','autoflight'),
                                       ('position','position','position'),
                                       ('orientation','orientation','orientation'),
                                       ('velocities','velocities','velocities'),
                                       ('acceleration','acceleration','acceleration')
                                       ]   )

   controls = bpy.props.EnumProperty(      attr='controls',
                                 name='controls',
                                 description="property control",
                                 default='aileron',
                                 items=[   
                                       ('aileron','aileron','aileron' ),
                                       ('aileron-trim','aileron-trim','aileron-trim' ),
                                       ('elevator','elevator','elevator' ),
                                       ('elevator-trim','elevator-trim','elevator-trim' )
                                    ]   )


   instrumentation = bpy.props.EnumProperty(      attr='instrumentation',
                                       name='instrumentation',
                                       description="property instrumentation",
                                       default='adf',
                                       items=[   
                                       ('adf','adf','adf' ),
                                       ('airspeed-indicator','airspeed-indicator','airspeed-indicator' ),
                                       ('altimeter','altimeter','altimeter' )
                                    ]   )







def addProjectRNA():
   # basic classes
   bpy.utils.register_class(fgAnimSettings)   

   bpy.types.Object.property = bpy.props.PointerProperty(   attr="familly",
                                             type=fgAnimSettings,
                                             name="familly",
                                             description="Property familly")
                                             
   bpy.types.Object.controls = bpy.props.PointerProperty(   attr="controls",
                                             type=fgAnimSettings,
                                             name="controls",
                                             description="Property controls")
                                             
   bpy.types.Object.instrumentation = bpy.props.PointerProperty(   attr="instrumentation",
                                             type=fgAnimSettings,
                                             name="instrumentation",
                                             description="Property instrumentation")
                                             



def removeProjectRNA():
    # complex classes, depending on basic classes
    bpy.utils.unregister_class(fgAnimSettings)


fichier : anim_ui.py

Code:


import bpy


#from bpy_extras.io_utils import ExportHelper, ImportHelper
from io_utils import ExportHelper, ImportHelper



#--------------------------------------------------------------------------------------------------------------------------------

class ANIM_PT_armature(bpy.types.Panel):
   '''Flight Object Panel'''
   bl_label = "FLightgear"
   #bl_space_type = "PROPERTIES"
   #bl_region_type = "WINDOW"
   bl_space_type = 'VIEW_3D'
   bl_region_type = 'TOOLS'
   #bl_context = "object"

   @classmethod
   def poll(self,context):
      obj = context.object

      if obj:      
         if obj.type in ("ARMATURE"):
            return True
      return False

   def draw(self, context):
      obj = context.active_object
      if obj:
         if obj.type == "ARMATURE":
            layout_armature(self, obj, context);
#--------------------------------------------------------------------------------------------------------------------------------

def layout_armature(self, obj, context):
   layout = self.layout
   boxAnimProperty = layout.box()
   
   rowProperty = boxAnimProperty.row()
   rowProperty.label( text='Familly :' )
   rowProperty.prop(obj.property, "familly", text="")
   #print( obj.property.familly )
   if obj.property.familly == 'controls':
      rowProperty = boxAnimProperty.row()
      rowProperty.label( text='PROPERTY :' )
      rowProperty.prop(obj.controls, "controls", text="")
   
   elif obj.property.familly == 'instrumentation':
      rowProperty = boxAnimProperty.row()
      rowProperty.label( text='PROPERTY :' )
      rowProperty.prop(obj.instrumentation, "instrumentation", text="")
   
#--------------------------------------------------------------------------------------------------------------------------------

def register_ui():
   bpy.utils.register_class(ANIM_PT_armature)
#--------------------------------------------------------------------------------------------------------------------------------

def unregister_ui():
   bpy.utils.unregister_class(ANIM_PT_armature)



fichier : __init__.py

Code:


bl_info = {
    "name": "Flightgear",
    "description": "Flightgear props",
    "author": "Clement ader",
    "version": (0,1),
    "blender": (2, 5, 7),
    "api": 31236,
    "location": "File > Import-Export",
    "warning": '', # used for warning icon and text in addons panel
    "wiki_url": "http://wiki.blender.org/index.php/Extensions:2.5/Py/"\
        "Scripts/My_Script",
    "tracker_url": "http://projects.blender.org/tracker/index.php?"\
        "func=detail&aid=<number>",
    "category": "Import-Export"}


import bpy

from . import anim_props
from . import anim_ui


from io_utils import ExportHelper, ImportHelper
#from bpy_extras.io_utils import ExportHelper, ImportHelper





#====================================================================================================================
#
#
#
#            REGISTER
#
#
#====================================================================================================================


def menu_func_export(self, context):
    self.layout.operator(ExportBone.bl_idname, text="Export bones")      # text=Title in the menu


def register():
   anim_props.addProjectRNA()
   anim_ui.register_ui()


def unregister():
   anim_props.removeProjectRNA()
   anim_ui.unregister_ui()


if __name__ == "__main__":
   try:
      unregister()
   except:
      pass
   register()
   


Alors, problèmes.
Le premier était lié à un nom de fichier, c'est anim_props.py et non anim-props.py, il y avait une petite erreur dans ton message, rien de bien méchant.

Par contre en essayant de nouveau après avoir renommé cette erreur :


J'ai blender 2.6.1 et python 3.2

Je vais chercher de mon côté, peut-être le module io_utils n'est plus présent dans les nouvelles versions de blender

dans le fichier __init__.py

change la ligne d'import avec celle commentée

actuelement :

from io_utils import ExportHelper, ImportHelper
#from bpy_extras.io_utils import ExportHelper, ImportHelper


deviens
#from io_utils import ExportHelper, ImportHelper
from bpy_extras.io_utils import ExportHelper, ImportHelper



Ca devrait marché ... je me rappelle plus ... mais je crois que ca viens de la version 2.7 de python de mon portable ... En espérant que les autres import marcheront aussi....

+++

Tu vas pas me croire, j'ai réussit !

Alors dans tout les fichiers concernés, il faut remplacer io_utils par bpy_extras.io_utils

Ok maintenant que ça fonctionne, je vais voir ce comment tout ça fonctionne !


[édit] Ah ! tu as trouvé en même temps que moi

C'est juste pour te montrer, un début d'integration. Toutes les propriétés non pas été copiés. Mais ca permet de montrer comment le travail peut s'integrer sur blender.
Le script de l'import créera l'armature puis renseignera la nouvelle propriété en fonction du fichier xml
bpy.data.objects['Armature'].familly='controls'
bpy.data.objects['Armature'].controls='elevator'
Et la partie inverse, le script écrit le fichier xml, en fonction du choix fait dans blender.

C'est un bout de script de faisabilité. Il est meme souhaitable d'avoir une propriété qui soit associée à l'armature ( bpy.data.armatures ) et non pas à l'objet (bpy.data.objects).

Par exemple , dans la patie scene de blender, on pourra créer un onglet, pour gérer l'arborescnece des fichiers. Exemple un champs pour renseigner l'emplacement des instruments, un autre pour les sons etc ....

Alors j'ai bien regardé le script, je comprends grossièrement son fonctionnement (je regarderais encore plus dans le détail chaque élément). Et jusque là, c'est plutôt cool

Je me suis mis à revoir le fonctionnement des armatures car ma dernière utilisation date un peu, ça n'a pas été long de tout remémorer. Alors j'ai importé le c172p et je me suis dit comment animer l'aileron. Il tourne suivant un axe "non orthogonale" mais ça à été vraiment très simple : J'ai placé la tête et la queue d'une armature sur les charnières de l'aileron (en me servant du "selection to cusor" ctrl+S pour être précis), je l'ai bloqué sur son axe de rotation y et hop terminé. Tout ça pour te poser une question :

Alors voilà, comment pense-tu gérer ce genre d'action, je m'explique et je part du principe que nous sommes dans le cadre d'une création d'animation, pas de la lecture d'un xml existant pour générer les armatures :

• Soit l'utilisateur installe lui même ses armatures, comme ce que j'ai fait

• Soit dans l'interface, on aurait un espace ou on rentre l'axe de rotation. On place le curseur sur la première "charnière", puis on valide avec un bouton, puis on place le curseur sur la deuxième charnière avant de valider de nouveau, et le logiciel crée l'armature.

(Ou alors, les deux en même temps)

---

Par contre lorsqu'on génère les armatures à partir d'un fichier xml, c'est assez simple, pour une rotation, il y en a de deux sortes :

Code:


   <animation>
      <type>rotate</type>
      <object-name>arrow_vor</object-name>
      <property>instrumentation/nav/heading-deg</property>
      <center>
         <x-m>0</x-m>
         <y-m>0</y-m>
         <z-m>0</z-m>
      </center>
      <axis>
         <x>-1</x>
         <y>0</y>
         <z>0</z>
      </axis>
   </animation>


(notons que le <center> si il est à 0 n'est pas utile)
Là une rotation simple, 1 centre 1 axe, on place la tête de l'armature sur le centre et bloque la rotation sur le bon axe

Ou alors le deuxième grand type :

Code:


<animation>
   <type>rotate</type>
   <object-name>AileronG</object-name>
   <property>/controls/flight/aileron</property>
      <factor>13</factor>
   <axis>
      <x1-m>3.419</x1-m>
      <y1-m>-4.483</y1-m>
      <z1-m>0.690</z1-m>
      <x2-m>2.901</x2-m>
      <y2-m>-3.253</y2-m>
      <z2-m>0.860</z2-m>
   </axis>
</animation>


Et bien là on place la tête et la queue de l'armature aux deux points indiqués et on bloque la rotation sur l'axe y

---

Je comprends aussi très bien l'intérêt d'utiliser les armatures pour lier les prop entre elles. Je m'explique en reprenant l'exemple du fw190 que tu m'avais montré, sur celui ci l'animation du manche est liée à celle des ailerons, en déplaçant des poignées on peut voir comme tout s'anime et c'est très intéressant. ça donne une idée des possibilités de le cadre de la gestion de toute une arborescence de fichier, c'est juste énorme ! (bon je me projette assez l'avenir lol)

---

En tout cas, je suis très heureux de voir ce début de script, je vais suivre avec attention toutes ses avancées et chercher à bien comprendre comme il fonctionne pour pouvoir donner un coup de main une fois le squelette de script terminé (pour ajouter de nouvelles fonctionnalités ect...)

On peut aussi créer un espace dédié au script sur le GIT de la PAF (en dehors du FG data)

merci,
Alexis

_run_ a écrit:Re,

Juste une petite question ... peut-on avoir des animations imbriqués dans flightgear ?
par exemple un truc comme cela

Oui bien sur, quand tu appliques une animation sur un objet ce sont tous les objets accrochés a cet objet qui subissent l'animation. Donc tu peux mettre une animation sur le pere, et une sur le fils ; le fils subira les deux animations. Les objets accrochés sont les fils tels que definis dans l'objet sous blender/ac etc, ou des groupes que tu fabriques a la main avec des animations vides.

<animation>
<name>NouveauPere</name>
<object-name>A</object-name>
<object-name>B</object-name>
<object-name>C</object-name>
</animation>

Bon la c'est a vos riques et perils.

HJ.

Bonsoir tout le monde,

Voila comment, je vois les choses avec blender.
Blender est un logiciel servant à créer des images de synthèses, des animations 3D et toutes formes artistique d'infographie 3D. Même, si aujourd'hui un virage est pris pour la création d"effets visuels 3D, blender reste un logiciel de création 3D. C'est un outil extrêmement puissant pour la 3D. Surtout, il affranchi le créateur de toute forme de manipulation des coordonnées x, y, z grâce à ses outils puissant.
Ce préambule, pour dire que blender permet de faire des animations d'une très grande complexité. A tel point, qu'il peut reproduire toutes les cinématiques de flightgear, sans aucune difficulté. Faire subir une succession de rotations et translation, à un objet est le minimum des posiibilités de blender. Or ce sont les animations utilisé par les simulateurs de vols, en général, et flightgear en particulier.
En développant mon script d'import des avions de x-plane, il m'est venu à l'idée d'importer les animations, puis de les exporter dans un autre format pour mon programme. Je me suis aperçu ( sans grand étonnement ) que blender est fait pour cela. J'entends par là : la création des animations.

Voilà les étapes pour créer une animation par exemple d'aileron.
Ouvrir un fichier 3D avec un aileron séparé du reste du maillage.
Le but est de placer un armature dans l'axe de rotation de l'aileron. Puis de faire l'animation.

-Sélectionner l'objet aileron (click gauche )
-passer en mode edit (touche tab)
-se mettre en sélection de point (bouton vertex)
-sélectionner le point le plus proche du début l'axe. (click gauche)-
-Mettre le curseur 3D à cet endroit ( ctrl-S cursor to selected)
-sortir du mode edit ( touche tab )
-Ajouter un armature ( shift-a armature>bone)
-selectionner de nouveau l'aileron (click gauche)
-passer en mode edit (touche tab)
-sélectionner le point le plus proche de la fin de l'axe. (click gauche)-
-Mettre le curseur 3D à cet endroit ( ctrl-S cursor to selected)
-sortir du mode edit ( touche tab )
-sélectionner l'armature (click gauche)
-passer en mode edit (touche tab)
-selectionner la fin de l'armature ( click gauche )
-Mettre cette partie d'armature sur le curseur 3D ( ctrl-s selected to cursor )
Vous voila avec l'axe de rotation de l'aileron défini dans blender , sans utiliser une seule fois les coordonnées x, y, z.
A partir de là on sélectionne l'aileron puis l'armature (dans l'ordre objet puis armature click gauche en maintenant la touche shift )
et on fait une parente spéciale ( ctrl-p ) une parenté de bone.
A partir de là tous les mouvement de la bone seront transmis à l'objet.
En insérant des "keyframe" à la bone (touche i) en mode pose ( ctrl-tab) on définit l'animation dans le temps. C'est magique


Je ne fait que détailler ce que tu as certainement fait Alexis. Tu as compris où je voulais en venir. Ces manipulations qui peuvent paraître compliqué sont en faites très simple, une fois que l'on en a fait plusieurs
Maintenant pour flighgear, les scripts python de blender permettent de récupérer, la postion de la bone très facilement
bpy.data.armatures['Armature'].bones[0].tail (coodonnée (x,y,z) de tete de la bone)
bpy.data.armatures['Armature'].bones[0].head (coodonnée (x,y,z) de queue de la bone)

pour les points et le vecteur (v = tail-head)

bpy.data.actions[0].fcurves[0].keyframe_points[0].co

pour les valeurs de l'animation (keyframe)

A partir de ces données on peut reconstituer les valeurs à fournir à flightgear y compris pour les interpolations. On peut donc fabriquer les fichiers xml lié à l'animation. sans ce soucier des valeurs. On travail uniquement avec blender. On voit directement l'animation. Plus de x, y, z, plus de calcul ... on ne travail qu'avec blender, c'est visuel et précis ...

X-plane décrit les animations d'une autre manière par exemple

Code:

   ANIM_begin
      ANIM_trans     -0.0251  -0.9562  -0.1282     -0.0251  -0.9562  -0.1282   0 0   no_ref
      ANIM_rotate     1.0000    0.0005    0.0004     0.55  0.00   0 1   sim/flightmodel/parts/tire_vrt_def_veh[0]
      ANIM_rotate     -1.0000  -0.0000    0.0000     0.00  29.21   0 1   sim/flightmodel/parts/tire_vrt_def_veh[0]
      TRIS   1122 120
      # leg_main_right.004
      ANIM_begin
         ANIM_trans     -0.0185  -0.2666    0.0784     -0.0185  -0.2666    0.0784   0 0   no_ref
         ANIM_rotate_begin   0 0 1   sim/flightmodel/parts/tire_vrt_def_veh[0]
         ANIM_rotate_key   0     0.00
         ANIM_rotate_key   1    -0.00
         ANIM_rotate_key   1    -0.00
         ANIM_rotate_end
         ANIM_rotate_begin   0 1 0   sim/flightmodel/parts/tire_vrt_def_veh[0]
         ANIM_rotate_key   0     0.00
         ANIM_rotate_key   1    -0.00
         ANIM_rotate_key   1    -0.00
         ANIM_rotate_end
         ANIM_rotate_begin   1 0 0   sim/flightmodel/parts/tire_vrt_def_veh[0]
         ANIM_rotate_key   0    -1.32
         ANIM_rotate_key   1    67.93
         ANIM_rotate_key   1    67.94
         ANIM_rotate_end
         TRIS   1242 60
         # leg_main_right.005
         ANIM_begin
            ANIM_trans     0.0185  -0.1250  -0.2566     0.0185  -0.1250  -0.2566   0 0   no_ref
            ANIM_rotate_begin     -1.0000  -0.0000    0.0001   sim/flightmodel/parts/tire_vrt_def_veh[0]
            ANIM_rotate_key   0     0.00
            ANIM_rotate_key   1    44.31
            ANIM_rotate_key   1    44.38
            ANIM_rotate_end
            TRIS   1302 36
         ANIM_end
      ANIM_end
   ANIM_end


Les animations sont définies encore d'une autre manière, dans mon programme, mais la finalité est toujours toujours la même. On multiplie une matrice de transformation par les coordonnées du point pour obtenir la nouvelle position du point. Blender fait cela aussi.

Maintenant à mon tour :
Comment change-t-on la durée dans le temps d'une propriété ????
par exemple un train d'attérrissage peut mettre 2s ou 10s pour rentrer. Il doit y avoir un paramètre pour dire à flightgear qu'il faut 5s pour faire varier cette propriété de 0 à 1 ....

Juste une remarque
Les deux sortes de descriptions sont equivalentes, center, axis et les deux points
Derriere le mot axes se cache le mot vecteur
deux points définissent un vecteur v(x,y,z) = B(x,y,z) - A(x,y,z) v est le vecteur AB
d'ailleurs "center" peut prendre comme valeur A ou B ou tout point appartenant à la droite.

Il faut faire attention à une chose le vecteur AB=-BA

Je vous ferais un dessin car on se sert de la main pour définir les sens positif de rotations, et l'orientation générale de l'espace ...

Salut,

Je ne fait que détailler ce que tu as certainement fait Alexis

Exactement, moi qui n'avais pas mis le nez dans les armatures depuis des siècles, j'ai seulement regardé une petit tuto vidéo (Anglais en plus), en même pas 2 minutes, j'étais opérationnel et j'ai eu l'idée d'animer l'aileron de la sorte. Après, j'ai me demande si n'importe qui ayant très peu de connaissances puisse arriver au même résultat. Accompagné d'une petite notice, n'importe qui peut y arriver, ça j'en suis certain.

---

Pour ce qui est du temps. Alors ça se gère soit par du xml soit par du nasal. Je vais avoir besoin d'aide sur ce coup là (Clément ?), mais je vais déjà te dire ce que je sais. Quand le FDM de l'avion est sous YASIM, il y a un paramètre de temps à entrer. Ceci pour l'ensemble des parties mobiles de l'avion. Voici un exemple avec un extrait d'un FDM YASIM, c'est une partie du train d'atterrissage :

Code:


<gear x="-0.956" y="-1.620" z="-1.652" compression="0.2">
<control-input axis="/controls/gear/brake-left" control="BRAKE"/>
<control-input axis="/controls/gear/brake-parking" control="BRAKE"/>
<control-input axis="/controls/gear/gear-down" control="EXTEND"/>
<control-speed control="EXTEND" transition-time="7"/>
<control-output control="EXTEND" prop="/gear/gear[1]/position-norm"/>
</gear>


Regarde la ligne :
<control-speed control="EXTEND" transition-time="7"/>
Elle indique que la rentrée/sortie du train dure 7 secondes.

Voilà comment ça se présente sous yasim, je ne sais pas comment ça se passe avec jsb (que je connais moins), je n'ai pas trouvé de paramètre de temps semblable, ça doit se passer ailleurs ? (besoin d'aide les amis !). Je pense aussi que si aucun timing n'est donné, il doit y en avoir une valeur par défaut d'attribué.

Lorsqu'il est question d'une création d'une propriété, le timing est indiqué par du nasal, tout comme son comportement.

Si on regarde bien les choses, la durée d'une animation est indiquée ailleurs qu'entre des balises <animation></animation> qui la concerne. Étant donné que c'est quelque chose qui est externe à l'animation, on peut lui attribuer une valeur par défaut dans blender et donner la possibilité à l'utilisateur de la faire varier. On peut ainsi lui donner la possibilité d'observer plus lentement une animation et voir d'éventuels cafouillages. Au moins dans un premier temps, après si toute une arborescence de fichier est prise en compte, on pourrait faire varier cette valeur dans les fichiers de FG, mais ça m'a l'air chaud.

---

En insérant des "keyframe" à la bone (touche i) en mode pose ( ctrl-tab) on définit l'animation dans le temps. C'est magique

Exactement, et on peut le faire même si l'animation ne dure pas le même temps dans blender et dans FG. Très simple, la majorité des prop passe de 0 à 1 en un certain temps, lorsqu'il y a une interpolation, on a quelque chose comme ça :

Code:


<interpolation>
   <entry><ind>    0  </ind><dep>    0</dep></entry>
   <entry><ind>    0.3</ind><dep>    10</dep></entry>
   <entry><ind>    1  </ind><dep>    90</dep></entry>
</interpolation>


ce qui veux dire en traduisant : " entre 0% et 30% de l'animation, tu fais un angle de 10°. Puis entre 30% et 100% de l'animation, tu continue jusqu'à 90°"

Peu importe le temps que ça dure dans FG et blender, on aura le même déroulement de l'animation. Et pour l'instant à l'utilisateur de se débrouiller pour la durée de l'animation dans FG (il peut voir ce qui marche dans blender et le remettre dans FG).

---

bpy.data.armatures['Armature'].bones[0].tail (coodonnée (x,y,z) de tete de la bone)
bpy.data.armatures['Armature'].bones[0].head (coodonnée (x,y,z) de queue de la bone)

pour les points et le vecteur (v = tail-head)

C'est simple effectivement ! punaise, tu arrive bien à te repérer dans toutes les fonctions de blender, moi je m'y perdais
C'est vrai que blender est totalement compatible avec ce qu'on veut faire, tout est récupérable, modifiable ect...

on ne travail qu'avec blender, c'est visuel et précis

Exactement, c'est une interface graphique pour créer les animations. Plus besoin de modifier les fichier xml puis de lancer FG pour vérifier. Pour un aileron, ça va, on fait pas trop d'erreur (quoi que lol), mais lorsqu'il est question d'un train très compliqué, ça prend énormément de temps !

---

Juste une remarque
Les deux sortes de descriptions sont équivalentes, center, axis et les deux points
Derriere le mot axes se cache le mot vecteur
deux points définissent un vecteur v(x,y,z) = B(x,y,z) - A(x,y,z) v est le vecteur AB
d'ailleurs "center" peut prendre comme valeur A ou B ou tout point appartenant à la droite.

Il faut faire attention à une chose le vecteur AB=-BA

Encore une fois, Exactement ! c'est pour ça que les choses se simplifient encore. Pour ce qui est traduire une rotation (par exemple) en fichier xml, ça peut se faire en une seule fonction.

Mais pour ce qui est du AB=-BA, ça peut devenir un problème. Si on place un vecteur BA, au lieu d'un vecteur AB, l'animation sera inversée (j'espère me faire comprendre), comment éviter celà ? c'est un problème lié à l'utilisateur, celui-ci ne sait pas exactement dans quel sens définir son vecteur. On retrouvait déjà ce problème dans les animations, on se rend compte que les ailerons sont inversés, alors la mauvaise idée est de mettre un "angle négatif" (exemple <factor>-20</factor>) alors qu'il faudrait plutôt inverser le vecteur :

Il vaut mieux faire 2 x 2 = 4 que (-2) x (-2) = 4. c'est plus clair

Voilà, encore un message un peu long, mais il y a tellement à dire !
@++, Alexis

C'est un super projet que de créer ce script ! Je ne suis pas créateur d'avion mais je suis certains que beaucoup seront content d'avoir un tel script.
Je viens donner quelques précision concernant l'interpolation et la gestion du train sous jsbSim.

1) La gestion du train sous jsbSim
Et bien là c'est très simple, vous savez pourquoi ? parce que jsbSim possède une documentation !
Donc je suis allez voir la documentation de jsbSim et j'ai trouvé la réponse en moins de 5 secondes : http://jsbsim.sourceforge.net/JSBSim/classJSBSim_1_1FGKinemat.html#_details
Et voici un exemple (Migs21)

Code:


<?xml version="1.0"?>

<system name="gear">

  <channel name="Landing Gear">
  <kinematic name="Gear Control">
    <input>gear/gear-cmd-norm</input>
    <traverse>
      <setting>
          <position> 0 </position>
          <time>    0 </time>
      </setting>
      <setting>
          <position> 1 </position>
          <time>    5 </time>
      </setting>
    </traverse>
    <output>gear/gear-pos-norm</output>
  </kinematic>

  </channel>

</system>


Je pense que vous l'aurez compris, ce bout d'XML permet d'indiquer à jsbSim que le train s'ouvre en 5 secondes. (euh par contre il se referme en 0 seconde ??? bizarre ce Migs21)

2) Gestion des temps d'interpolations sous FlightGear
Alors là y'en a pour tous les goûts On peut le faire soit en XML soit en Nasal ou dans le FDM (uniquement pour le train d'atterrissage)

Alors je vais prendre un exemple simple, je veux ouvrir la porte de mon avion en 3 secondes.
a) En nasal ça donne ça :[code]interpolate("sim/model/doors/position", 1, 3[code] voilà je viens de dire à la propriété "sim/model/doors/position" de passer de 0 à 1 en 3 secondes. Maintenant pour refermer la porte :[code]interpolate("sim/model/doors/position", 0, 3[code] on passe donc de 1 à 0 en 3 secondes. Ensuite il reste à créer l'animation XML de rotation bien entendu. Ici on ne fais que faire varier une propriété en un temps voulu.
b) En XML ça donne ça :
[code] <animation>
<object-name>doors</object-name>
<type>pick</type>
<visible>true</visible>
<action>
<button>0</button>
<repeatable>false</repeatable>
<binding>
<command>property-interpolate</command>
<property>sim/model/doors/position</property>
<value>1</value
<time>3</time>
</binding>
</action>
</animation>
[/code]
Ce bout de XML permet de dire que : lorsque je clique sur la porte, la propriété sim/model/doors/position doit passer à 1 en 3 secondes.
Cette animation est assez récente (elle a été introduite en Mars 2012) pour plus d'info : http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35900.html


Voilà j'espère avoir pu éclaircir certaines choses

Amicalement,
Clément

Quelques explications, pour se repérer dans blender, il faut bien connaître les termes et faire une recherche dans la documentation
http://www.blender.org/documentation/blender_python_api_2_63_11/
Par exemple, pour les armatures on s'aperçoit qu'il y deux termes: armatures et bones. On peut traduire ces termes par squelette et os.
une armature peut avoir plusieurs bones.
On regarde toujours du coté bpy_types_BlendData
C'est une l'endroit ou se trouve toutes les données de blender.
On voit qu'il existe : bpy.data.armatures. C'est une liste qui contient toutes les armatures. Mais on ne trouve pas sont équivalent pour les bones. (bpy.data.bones)
Avec le (quick search) de la documentation, tu entres "bone", et une grande liste de réponse apparait. Et c'est la que ma petite expérience va t'aider. Regardes du côté de bpy.types. Et là tu vois
bpy.types.Bone (Python class, in Bone(bpy_struct))
bpy.types.Bone.basename (Python data, in Bone(bpy_struct))
bpy.types.Bone.bbone_in (Python attribute, in Bone(bpy_struct))
bpy.types.Bone.bbone_out (Python attribute, in Bone(bpy_struct))
etc.
Tu clic sur bpy.types.Bone. Tu vois a ce moment qu' il existe une données contenant les paramètres de la bone.
bone.head = les coordonnees de la tête.
bone.tail = les ccordonnées de la queue.
bone.layers = le layer où ce trouve la bone
bone.name = le nom de la bone
etc....
Mais comment accéder à cette donnée, il n'existe pas de bpy.data.bones
Il m'a fallu beaucoup de temps pour comprendre qu'il faut travailler à l'envers.
Tu vas tout en bas de la page et tu regardes la partie "Références"

Là tu vois
Armature.bones
ArmatureBones.active
Bone.children
Bone.parent
PoseBone.bone
Tu clic sur Armature.bones et là "bingo" armature commence par armature(ID), c'est une donnée référencé dans bpy.data.
donc
bpy.data.armatures['aileron'].bones contient la liste des bones

bpy.data.armatures['aileron'].bones[0].head (coordonnées de tete de la premiere bone)
bpy.data.armatures['aileron'].bones[1].head (coordonnées de tete de la deuxieme bone)
bpy.data.armatures['aileron'].bones[2].head (coordonnées de tete de la troisieme bone)
etc..

Pour les paramètres de keyframe tu fais pareil et tu fini par trouver
bpy.data.actions[0].fcurves[0].keyframe_points[0].co
mais aussi
bpy.data.armatures[0].animation_data.action.fcurves[0].keyframe_points[0].co

Apres il faut faire des tests avec la console python de blender si tu arrives bien à accéder à la données. Voilà

Je vous rassure, j'ai aussi galéré pour m'en sortir avec cette documentation. J'ai mis du temps à comprendre que l'on travail à l'envers. On cherche d'abord l'élément bone texture materials, object, keyframe etc... puis on remonte jusqu'au bpy.data pour pouvoir y accéder.