Script flightgear

Il a raison, je me rappelais plus de ça d'ailleurs :


Mais ça n'a rien de grâve, le FDM est externe aux animations, et c'est de la gestion des animations qu'il est question dans ce script. Gérer un FDM impliquerait un ajout en plus ce qui est déjà là, quelque chose d'indépendant, mais pas à l'ordre du jour.

Lien intéressant, la quasi seule doc sur YASIM : http://wiki.flightgear.org/Fr/YASim (super traduction de jano)

Il y a encore un 3ème type d'axe, celui des vues, le x y z ne servent pas à la même chose, mais là aussi ce genre de chose est externe et constituera un ajout simple à faire

En tout cas, je suis sur le cul de voir ce que fait ce script ! je le dis jamais assez !

PS : quelqu'un peut parler de JSB ?

Alexis a écrit:Les interpolations ont l'air d'être problématiques pour le script. J'ai fait quelques essais, je suis pas certain de ce que j'ai fait, car ça à été accompagné d'autres modifs, enfin je me suis un peu mélangé les pinceaux ! Disons que c'est plus pour la forme pour le premier point

Ne t'intièque pas, je ne crois pas que le script cafouille; il fait juste ce que je lui de faire et je lui est dit de cafouilller

En faites, comme je n'avais pas les valeurs mini et maxi des propriétés, j'ai calculé un mini et un maxi entre les valeurs de l'interpolation. Puis il fait une règle de trois suivant le mini et le max de <ind></ind>

en python c'est là

Code:


      if len(self.interpolation) != 0:
         _min = 0.0
         _max = 0.0
         for ind, dep in self.interpolation:
            if ind > _max:
               _max = ind
            if ind < _min:
               _min = ind
         #if self.interpolation[0][1] > self.interpolation[-1][1]:
         self.interpolation.reverse()
         for ind, dep in self.interpolation:
            coef = _max - _min
            frame = (( (ind-_min) / coef ) * 59.0) + 1.0
            value = dep * self.factor
            self.insert_keyframe_rotation(  frame, value )



Je calcul le min et le max Cela permet de respecter les intervales de temps.
Le choix du temps est totalement arbitraire, toutes les animations se font sur 60 frames. Il faudra trouver un truc, pour lui indiquer le temps.

Cela m'a permis de vérifier que tous bougent avec la bonne "parenté" surtout. Et sur certaines propriétés comme celle du tachymètre, d'avoir une valeur d'angle plus visuelle. J'ai tout ramené entre 0 et 1 en proportion puis multiplié par factor.
Donc les valeurs ne sont pas tout à fait exact. Elle le sont dans le principe, car le script fait déja la règles de trois, mais il lui manque les bornes que je ne peux pas inventer.

Alexis a écrit:Plusieurs animations sur un même objet : Toute animation est incluse dans la précédente.

Avec les bonnes valeurs cela rentrera dans l'ordre.

Alexis a écrit:

---

Autre chose , Les courbes IPO de blender sont des courbes , je suis persuadé que flightgear utilise des interpolation linéaires, ces courbes doivent donc être des droites, non ? Du coup il y a des différences de vitesses

Ce sont des courbes de bézier, il faudrait juste trouver la prop pour les passer en linéaire, heu... rené ?

Normalement avec la dernière version du script les interpolations sont linéaires. Je ne sais plus quand j'ai fait la modif, mais maintenant elles sont linéaires.

Alexis a écrit:

---

Concernant ce qui est dit sur le fofo anglais, je suis pas encore certain de comprendre, va falloir qu'il développe plus, ou que je relise mieux (l'anglais et moi...).
Déjà non, ça change rien pour ce qui est des anim, certain ! il faut pas confondre le visible et la machinerie qu'il y a derrière. Bon c'est pas à un programmeur que je vais apprendre ça lol, ça serait plutôt le contraire ! Ce qui est interne à l'avion, le FDM à peut-être des différences.

Enfin je veux pas parler trop vite, je vais creuser et comprendre ce qu'il dit.

Il y a déjà une curiosité dans flightgear, le système de coordonné utilisé dans les animations xml n'est pas le même que celui utilisé dans les fichiers .ac. Lorsque j'ai commencé à écrire le script je m'attendais à voir un truc bizarre, car dans les fichiers ac , je ramène les coordonnées en ( X,-Z,Y). Je n'ai pas eu besoin de faire cela avec les animations. (tant mieux, c'est une source d'erreur en moins )

Alors pour les prop, je vais y travailler, mais en gros, soit elle varie de 0 à 1 soit elle varie de -1 à 1. Soit l'objet tourne dans un seul sens soit il tourne dans les doit.

Mais je me pose à l'instant la question des instruments, ils varient suivant des prop différentes. La vitesse par exemple, de 0 à +infini (enfin 299 792 458 m/s, désolé Enstein). Comment ça peut se traduire dans blender ? pour lire l'existant, mais surtout pour créer l'animation. Il va presque falloir un fonctionnement propre aux instru ?

Et désolé, nos messages ont tendances à se croiser, bizarre, mais j'ai besoin d'écrire pour réfléchir, du coup plus j'écris et plus j'ai des idées et je pense à de nouvelles choses, du coup j'ai du mal à m'arrêter à un message lol

Depuis le début je suis cette discussion avec beaucoup d'intérêt.
Mais j'ai quelques (beaucoup de) questions.

Si j'ai bien compris (ce qui n'est pas forcément vrai ), le but final c'est de pouvoir développer un avion complètement dans blender, y compris toutes les animations, que l'on pourra mettre au point et visualiser avant d'exporter le tout en .ac et .xml

Mais pour le moment (encore si je pige bien) le travail de René est axé sur l'importation (ac et xml).
Dans le but d'améliorer les modèles existants ?

Mais,ne serait-ce pas le moment d'essayer de s'affranchir du format Ac3d?
Qui semble quand-même provoquer quelques soucis ?

Je lis sur la page d'accueil de FG :

Tous les fichiers utilisés sont écrits au format texte, et donc leur contenu est lisible par tous et modifiable sans passer par un éditeur spécialisé (excepté les images, ça va de soi, même les objets 3D sont au format texte!1)).

Les objets 3d au format texte, est-ce vraiment un si grand avantage ? On y met le nez surtout pour corriger des problèmes de conversion blender>ac.

1) .ac, format de AC3D, mais en version CVS il est possible d'utiliser plein d'autres formats

"plein d'autres formats" : c'est très vague, le format .blend en fait partie ? Ou serait possible ?

L'idéal ne serait il pas de concevoir en blender et que Fg utilise directement le fichier
.blend qui pourrait (encore une fois si je comprends tout) contenir :
le modèle 3d, les animations, les éclairages etc.etc.
à la limite plus de, ou beaucoup moins de xml.

Peut-être que je suis complètement à côté ?
Et que le format blender n'est pas du tout directement compatible avec Fg?
Je suis bien conscient que des adaptations assez profondes seraient nécessaires dans les
sources de Fg. Quoique des librairies de conversion n'existe t-elles pas déjà quelque-part?

Est on vraiment obligés de passer par un format de logiciel non libre (ac3d) pour faire le pont entre deux systèmes libres ?

Amicalement.

Bonjour F-sig,

Tes remarques sont pertinentes. En plus je me suis poser les mêmes questions dès le début.

Lorsque j'ai découvert flightgear, un simulateur open-source, je me suis dit que l'on pouvait créer des avions plus facilement, qu'avec les autres simu. Effectivement c'est le cas. Même si la doc n'est pas toujours facile à trouver, on fini par y arriver.
Mais j'ai eu une grosse surprise, lorsque je me suis aperçu que le format utilisé était le format AC3D. Un format propriétaire. J'ai trouvé cela surprenant. Finalement, je me suis dit, c'est au moins un format texte ! Pourquoi est-ce un plus ?? Tout simplement, pour les personnes sachant programmer (et il en faut sinon pas de fg ) un format texte fait gagner beaucoup, beaucoup de temps. Pas besoin "d'ingénierie inverse" pour décortiquer un format binaire. Pour l'avoir déjà fait , c'est vraiment très très pénible. Les erreurs sont fréquentes, et cela fonctionne toujours sur 3 pattes. Imaginez la suite d'octets 03 21 5d 85 96 d6, qu'est-ce donc : les coordonnées d'un point, d'un vecteur, d'une chaîne de caractères, d'une matrice de transformation, ou d'une données utilisé par une fonction du programme, ou je ne sais quoi ??? l'avantage d'un format texte est que l'on devine très vite ce que font les données.
Un inconvénient, les formats textes sont lourd (en taille) par rapport au format binaire. Mais on peut y remédier en compressant les données, et en les décompressant à la volée. (Je crois que la librairie boost fait cela). Flightgear n'utilise pas ce procédé. C'est un choix.
Personnellement, j'aurai tendance à faire la même chose, à laisser les données en brutes.

Pour revenir au format texte, il existe d'autre format, je pense au format obj, que j'utilise, mais aussi au format collada. C'est un standart ouvert, comme opengl, et je pense qu'il s'adapterait très bien à flightgear. Le jeu 0ad utilisait ce format jusqu'a la version (alpha8). C'est un format utilisant le standart xml. Ce n'est pas seulement, le maillage que peut transporter ce format, mais aussi les animations. Attention les animations peuvent être très très complexe avec ce format. Bien au delà des besoins de flightgear.
Le gros reproche, personnel, du format .ac, c'est la non sauvegarde des normales. Le rendu peut devenir très laid, a cause de cela. Avoir un bel avion dans blender ne garanti pas un beau rendu dans flightgear, et vis-versa. Juste à cause de ce manque. Mais cela va bien au-delà. Aujourd'hui la modélisation fait appel, a des techniques de plus en plus répandues, tel que le bump-mapping (modification locale des normales), spécular-mapping.( l'effet de la tache spéculaire ne se trouve plus dans un paramètre global à l'objet, mais contenu dans une texture). On utilise aussi le multi-texturing, pour les normales et d'autres effets, mais avec une carte uv, spécifique à chaque texture. Blender gère tout cela par exemple, et son moteur temps-réel (blender-engine) fait des choses impressionnantes. Voilà encore une autre limite du format .ac on ne dispose que d'une seule carte uv.
Flightgear évolue avec son temps, et utilise de plus en plus souvent ces techniques moderne.(cf rembrandt). Mais flightgear se heurte aux limitations du format .ac, et tente de le préserver. Je ne crois pas que ce soit une bonne solution. En informatique, il y a toujours un moment, ou il faut changer ces habitudes. Attention ne jamais oublier d'où l'on vient. C'est toujours un plus. Mais tout les programmes ont un jour, recommencé de zéro pour avancer de nouveau. (En faites on ne recommence jamais de zéro, car l'expérience est présente et c'est un "bien" d'une valeur inestimable)
Le format interne des données de blender, ne sont pas adapté à flightgear. En effet les .blend, sont des formats binaires, qui évolue je pense très souvent, mais qui contiennent beaucoup de chose inutiles pour flightgear. Et les fichiers sont plutôt volumineux , aussi.

Enfin pour terminer. un jour où l'autre, il y aura aussi une révolution dans la gestion de l'aérodynamique. Les cartes graphiques sont devenues des monstres( et le terme est faible) de calcul parallèle.Des nouvelles API ont fait leur apparition, openCL et CUDA, permettant d'utiliser cette possibilité de calcul pour autre chose que du graphisme. Appliquer à la simu avion, on devrait pouvoir s'affranchir, des modèles de vols de YAsim ou JSBsim par exemple, et faire calculer les paramètres aérodynamique directement par la carte graphique, sur le maillage 3D. Ou par exemple, rendre le mouvement des masses d'air de l'atmosphère. Ou je ne sais quoi.
Tu vois Alexis , il n'y a pas que toi qui rêve .....


Amicalement René
P.S. Très intéressante ta remarque, mais, attention aux conséquences ... il faut absolument réfléchir à tout cela ...

Salut

F-Sig a écrit:Depuis le début je suis cette discussion avec beaucoup d'intérêt.

Merci beaucoup ! et merci d'y participer !

F-Sig a écrit:
Si j'ai bien compris (ce qui n'est pas forcément vrai ), le but final c'est de pouvoir développer un avion complètement dans blender, y compris toutes les animations, que l'on pourra mettre au point et visualiser avant d'exporter le tout en .ac et .xml

Mais pour le moment (encore si je pige bien) le travail de René est axé sur l'importation (ac et xml).
Dans le but d'améliorer les modèles existants ?

Le but est d'améliorer l'existant, et d'en créer de nouveaux. L'idéal est de ne plus avoir à gérer l'ensemble des fichiers xml. Tu vas avoir une interface graphique pour tout gérer, et surtout pour tout visualiser instantanément.

F-Sig a écrit:
Mais,ne serait-ce pas le moment d'essayer de s'affranchir du format Ac3d?

Qui semble quand-même provoquer quelques soucis ?

Le format AC3D risque fort de ne plus être utilisé. Un autre point qui est défavorable à Flightgear, ce sont les textures. René compte mettre au point un script capable de faciliter considérablement les dépliages UVmap, il y a eu des discussions très intéressantes là dessus avec Mumble. Mais FG est capable de mettre en place de meilleurs rendu (sans prendre plus de ressources), sans parler de Rembrandt, tout cela implique un format 3D performant. AC3D n'est peut-être pas génial d'un point de vue gestion des normales, Chaque facette présente une normale, et il y a tout un calcul de rendu de fait avec. Il existe un format plus performant qui améliorera la qualité des rendu, c'est le format .obj.

Le format blend n'est pas intégré à FG (sauf erreur), il me semble bien différent des autres formats, intégrant plus d'éléments qui ne servent qu'à lui-même. Si il devait être intégré, je suis pas certain qu'il y aurait une révolution dans les rendu.

Je pense qu'il va falloir faire un de ces jour une série d'essais de rendu dans FG, pour mettre à l'épreuve les formats 3D et ainsi tirer des conclusions en béton armé. Trop souvent, les discussions se font sans éléments concrets, beaucoup de paroles et répétitions de ce qui à été dit, les FDM en était un bon exemple. Comprendre comment tout fonctionne, ce qui va ou ne va pas n'est surement pas une perte de temps !

héhé, rené est plus calé pour parler dans le domaine, mon message est bien maigre à côté.

Le format obj est déjà intégré à FG, mais si j'ai bien compris, il doit en exister plusieurs sorte ? (ceux de X-plane sont différents)

Raison de plus pour faire des essais ! s'orienter vers les bonnes solutions, performantes et peu gourmandes. Il faut suivre l'évolution des techniques et préserver nos machines. C'est un vrai jeu d'équilibriste !

René,
Quelque chose comme ça pour les tuples ?

controls = ( ('/controls/flight/aileron',-1,1)
('/controls/flight/aileron-trim',-1,1)
('/controls/flight/elevator',-1,1)
('/controls/flight/elevator-trim',-1,1)
('/controls/flight/rudder',-1,1)
('/controls/flight/rudder-trim',-1,1)
('/controls/flight/flaps',0,1)
('/controls/flight/slats',0,1)
('/controls/flight/BLC',0,1)
('/controls/flight/spoilers',0,1)
('/controls/flight/speedbrake',0,1)
('/controls/flight/wing-sweep',0,1)
('/controls/flight/wing-fold',0,1)
('/controls/flight/drag-chute',0,1 )

Je serais sur Mumble ce soir

Parfait
tu vois c'est pas dure la programmation
:-(

Et que penser du format OSG ?
FlightGear utilise la librairie OSG (ombres, lumières, shaders...) qui possède son propre format de fichier. C'est aussi un format texte, mais qui peut embarquer des animations. Je ne sais pas grand chose sur ce format de fichier, sauf qu'il est parfaitement reconnu par FG.

Pour en revenir au script en lui-même, je continue de suivre avec attention le développement. Le mois de Juillet est un gros mois de travail pour moi c'est pourquoi je ne mets pas encore pleinement les mains dans le projet.

Amicalement,
Clément

Pour le script, je vais m'orienter en premier vers l'écriture du fichier xml, dans l'éditeur de text de blender. Le fichier sera écrit en entier. Et à la demande il affichera le fichier xml, choisi. On pourra pour l'instant afficher autant de fichier xml que l'on veut. Aucune modification n'est prise en compte, actuellement, mais cela ne va pas tarder.

J'opte pour cette solution, car écrire directement dans le fichier, pourrait entrainer des conséquences facheuses, en cas de fausse manip, ou plus certainement d'erreurs du script. Il va s'en dire que tout ne fonctionnera pas du premier coup. Donc faire des "modifs" dans l'éditeur de texte de blender évitera ses désagréments.
Pour utiliser les modifications et les tester, il suffira de faire un copier coller, vers le fichier et un éditeur de texte.

Je reprends ce que je disais sur les propriétés, certaines sont simples. Elles sont à intervalle fermé (de 0 à 1, de -1 à 1), mais d'autres sont à intervalle ouvert, comme les prop responsables de la rotation des aiguille (vitesse ect...), comment faire.

Pourquoi pas indiquer cela dans le tuple : ('prop',0,'x'), ou ('prop','x','x'), le x indique que la valeur est variable et doit être rentrée

Dans ce cas lors de l'animation, il y aurait quelque chose du genre : Position (on place l'armature dans une position), value (on indique pour quelle valeur de la prop l'armature prend sa position). Il il n'y a qu'un position de rentrée, on fait un factor, sinon une interpolation.

Pour le tuple , cela devrait être bon car python utilise un "typage" dynamique, et cela devrait fonctionné.
Mais je viens de me rendre compte que certaines propriétés, sont liée au temps, par exemple le train d'atterrissage, et d'autre pas, l'heure ou la vitesse. Il faudra faire un tuple de 4 valeurs
('prop', 0, 'x', True ) la variable booléenne pour dire si la propriété est liée au temps ou pas.
Cela modifiera le comportement du script, au moment du calcul de l'interpolation.

Sur cette recopie d'écran du nouveau panel blender, les valeurs sont modifiables. Mais elle seront affichées dynamiquement, c.a.d., en fonction de la sélection. Si l'armature, sélectionnée, est liée à une propriété qui n'a pas besoin du temps, le bouton time disparait. De la même manière si le tuple qui contient la propriété a ses bornes de définis. Le boutons min et max disparaiteront. Ainsi de suite ....

La seule limite sera l'imagination , et certaines contraintes techniques (dû au programmeur je ne connais pas tout )



[Edit] l'heure qui n'est pas lié au temps .... elle est jolie celle-là

Oui, en gros deux types de propriétés : une cinématique (train rentré/sorti) ou un mouvement "contrôlé" (aileron)

Je suis sur mumble pour toute la soirée

Bonjour tout le monde,

Je vais bientôt mettre sur le git , une nouvelle version qui commence à exporter du xml. Il faudra faire beaucoup de test, pour vérifier que cela fonctionne avec flightgear, je compte sur vous.

Le fichier .xml se trouvera dans l'éditeur de texte de blender, il faudra faire un copier-coller pour mettre des morceaux dans les fichiers des avions ...
A gauche le fichier créer par le script, à droite le fichier original.
Les interpolations sont calculées , etc ..., il va avoir, beaucoup de cas, à regarder, avant que l'on réécrive les fichiers .xml.
Et aussi comment rendre le script le plus pratique possible.

A+

Bonjour tout le monde,

En testant le script, je suis tombé sur une partie qui m'a semblée curieuse. Puis je me suis aperçu que les animations peuvent être déclenché sur une condition.
Pourrai-je avoir des précisions sur ces "conditions" ???

Bonjour,

Merci, René et Alexis pour les réponses à mes interrogations.

J'aimerais bien essayer d'essayer vos travaux.
Quel sont les fichiers à mettre dans mon /blender.2.63/2.63/scripts/addons/tartempion/... ?

Ceux de /io_fg2blender/ ou ceux de /io_scene_ac , de quelle branche master ou 2.63 ?

Pour les conditions, tout est expliqué là :
http://wiki.flightgear.org/Howto:Animate_models#Conditions

Amicalement.

Salut F-sig,

Tu télécharges la dernière version sur le git. Depuis le début, il y a eu des modifications tous les jours.
Pour installer le script , il faut ajouter le répertoire complet io_fg2blender avec les fichiers dedans pour te retrouver avec :
mon /blender.2.63/2.63/scripts/addons/io_fg2blender

Tu lances blender
Puis tu actives le script dans user preferences de blender
CTRL-ALT-U
Dans l'onglet Addons
Tu sélectionnes import/export
et tu cherches import/export: flightgear (c'est classé par ordre alphabétique)
tu active le script (case à coché)


Une fois activé, tu le lances dans le menu blender :
file>import>flightgear (.xml)
tu sélectionnes ton fichier xml dans le fgdata/Aircraft/avion_que_tu_veux-set.xml

Une chargé ton avion.
Puis il faut créer les animations
Mettre la souris dans la fenetre 3D
Appuyez sur la touche F
Dans le menu Flightgear tools menu tu fait Creation animations

Un fois chargé pour lancer les animations ALT-A lance/stop les animations

A+

Merci René, ça bouge

Je commence à assimiler le but de l'opération
Tu as réalisé un gros truc là!

J'ai visualisé quelques anims:
DR400
Console du Dc3
Le train du A10, dont tu parles(écris) quelques posts plus haut; intéressant!
Et je suis tombé sur un os
Sur le PC9M les anim. des trains sont décalées de 90°
A l'examen du xml je vois un offset de -91°(<offset-deg>-91</offset-deg>) je pense que c'est la cause?
Je n'ai pas(encore) compris pourquoi il a mis cet offset?, mais apparemment le script ne le prends pas en compte?

Code:


<animation>
<type>rotate</type>
<object-name>rwheel</object-name>
<object-name>rtyre</object-name>
<object-name>rstrut</object-name>
<object-name>ruring</object-name>
<object-name>rdring</object-name>
<object-name>ruscissor</object-name>
<object-name>rdscissor</object-name>
<object-name>rhydro</object-name>
<property>gear/gear[2]/position-norm</property>
<factor>91</factor>
<offset-deg>-91</offset-deg>
<axis>
<x1-m> 0.00</x1-m>
<y1-m> 1.19</y1-m>
<z1-m> 0.21</z1-m> 
<x2-m> 0.05</x2-m>
<y2-m> 1.19</y2-m>
<z2-m> 0.21</z2-m>
</axis>
</animation>

Amicalement.

Re ..

Effectivement, sur certains avions les animations sont décalées de 90°. En fait il s'agit d'un problème de signe. Et je n'ai pas encore identifié où se trouvait exactement le problème. Il est possible que cette erreur provienne de l'initialisation de blender. En effet, si j'insère les "keyframes" en premier la frame 1->angle=0 et ensuite la frame 60->angle=60, l'animattion est inversé dans l'ordre inverse (frame 60->angle=60 en premier et ensuite frame 1->angle=0) C'est vraiment étrange. Les angles sont pourtant identique dans les deux cas ainsi que la courbe, et cela ne devrait pas avoir de conséquence.
C'est plus compliqué que ce simple exemple, et je n'ai pas encore trouvé de règle.
Mais tu fait bien de le noter ....

Merci

A+
P.S. heureux que tu ai réussi à le faire fonctionner ....

Oups ...

En relisant ton message, je crois tu m'as donné la solution .... pour l'instant le script ne gère pas la balise <offset-deg> à l'intérieure d'une animation. A tous les coups, cela viens de là. Il fait une rotation préalable pour fermer le train d'atterrissage. Pour la valeur 0, puis il ouvre le train de 91°. Sans doute, il a modélisé l'avion de train ouvert ...


Merci
A+

Merci , c'est ça .....


Il reste un gros, gros bug à corriger lors de la lecture des fichiers .ac. Et je pense que le f14 passera l'import dans le script. En effet le f14 faisait aussi l'erreur que tu décrit. Et maintenant, le train arrive à s'ouvrir correctement. Mais Il y a toujours l'autre bug, sur le fichier .ac

A+

J'en avait parlé brièvement dans un message et depuis ça m'est complètement sorti de la tête.

Alexis a écrit:

Sinon, je suis d'accord sur le fait que des animations comme scale n'ont pas (pour l'instant) besoin d'être présente dans le script, c'est presque jamais utilisé. Par contre, il y a aussi conditions en xml qui pourraient être intégrées. Un exemple :

Code:


   <animation>
      <type>spin</type>
      <object-name>Train2Roue</object-name>
      <property>gear/gear[0]/rollspeed-ms</property>
      <factor>8.2</factor>
      <condition>
         <equals>
            <property>gear/gear[0]/position-norm</property>
            <value>1</value>
         </equals>
      </condition>
      <center>
         <x-m>0.956</x-m>
         <y-m>-1.289</y-m>
         <z-m>-1.277</z-m>
      </center>
      <axis>
         <x>0.0</x>
         <y>-1.0</y>
         <z>0.0</z>
      </axis>
   </animation>


Pour que la roue tourne que quand le train est sorti. Il y a aussi des exemples dans les animations d'hélices.

Alors niveau condition, il y a pas mal de choses possible (bien que les conditions sont très peu exploitées en xml au profit du nasal)

Voilà la liste des balises utilisables :
<condition>...</condition>
<and>...</and>
<or>...</or>
<not>...</not>
<equals>...</equals>
<not-equals>...</not-equals>
<greater-than>...</greater-than>
<greater-than-equals>...</greater-than-equals>
<less-than>...</less-than>
<not-equals>...</not-equals>
<less-than-equals>...</less-than-equals>
<value>...</value>

On les utilises toujours en lien avec une propriété. Dans la balise animation, il y a un bloc condition qui s'insère. Le but est de dire la chose suivante : quand la prop est égale/supérieur/inférieur/à ceci et/ou ceci est ... alors déclenche l'animation.
On obtient ce genre de syntaxe :

Code:


<animation>
 [........]
  <condition>
  <less-than>
    <property>/engines/engine[0]/rpm</property>
    <value>1500</value>
  </less-than>
  </condition>
[.......]
</animation>


Si tu as le dossier data de Flightgear dans un coin de ton bureau, je te propose de jeter un coup d’œil dans le dossier Docs, il y a un fichier READM.conditons où tout est bien décrit.

Comment intégrer ça au script ? ça me semble chaud

Alexis a écrit:Comment intégrer ça au script ? ça me semble chaud

C'est l'impression que j'ai aussi... D'ailleurs j'ai tendance à penser que les conditions c'est plutôt orienté "programmation" alors que Blender est ici utilisé dans le but de créer des animations...
D'autre part je ne vois pas comment faire varier les propriété dans Blender pour se dire <<tient je vais tester l'animation qui contient une condition quand la condition retourne FALSE puis quand elle retourne TRUE>>

Le plus simple, et je pense que personne ne nous en voudra : c'est d'ignorer les conditions. Le script est là pour afficher/créer des animations. Ce que fait le script est déjà énorme ! Les quelques conditions nécessaire par-ci par là qui demande une réflexion de programmeur pourront être ajouté à la main.

C'était mon avis

Amicalement,
Clément