Script flightgear

voila voila voila... bon ben on s'rappelle dans 1 semaine quand j'aurai compris hein

Plus sérieusement : c'est cool d'avoir décortiqué et compris ce qui se passait ! Car je me souviens avoir été obligé de faire une animation bizarre pour la poignée situé au dessus du pilote. Dès que j'ai le temps je regarde les xml pour y comprendre un peu mieux.

Bravo Alexis !

Amicalement,
Clément

Salut Alexis,


Heureux de te lire, je n'ai pas voulu relancer le post, même en sachant ton retour
Je n'est pas creusé le problème, car j'ai préféré continuer le script, car il me semble bien lancé. Je n'ai pas trop de mal, a m'y retrouver, finalement, c'est bon signe
Cela me fait pensé à un post, que je trouve très juste, où tu écris : il vaut mieux écrire une interpolation avec 2 x 2 = 4 plutôt que (-2) x (-2) = 4. C'est typiquement le genre de chose qui amène beaucoup de soucis à la longue. A la fin cela rend les choses difficilement "maintenable".

Les problèmes d'offset m'ont posés beaucoup de soucis, mais j'ai réussi à les résoudre (j'espère...). Pour les offsets, tu as raison, ce n'est qu'une translation (des fois des rotations aussi) au chargement. Si je devais faire une programme qui utiliserais cela, alors je ferais ses changements de repère, au moment de la création de la vbo (vertex buffer object=transmission du maillage à la carte graphique) pour éviter un calcul supplémentaire à chaque image (optimisation). Je n'ai jamais regardé le code de flightgear, mais on peut être sûr à 99%.

Actuellement le script arrive à lire les animations suivantes :
rotate
translate
pick
shader
spin
light

Je pense que l'animation "light" est plus complexe que ce que je fait.(Je laisse cela de côté pour l'instant ...)

J'ai posté sur flightgear.org, http://www.flightgear.org/forums/viewtopic.php?f=18&t=16848
et un utilisateur "mr_no" m'a dit que pour les propriétés YAsim les repères ne sont pas les mêmes .... gr ... Mais cela me semble curieux, je préfère avoir ton avis.
Il me manque encore l'ensemble des propriétés et avec leur valeur de variations. Tu verras dans le fichier props_armature.py, les propriétés que tu m'as fourni. J'ai rajouté ton nom sur le fichier, complètes-le.
Pour les propriétés que l'on oubliera, on pourra faire un appel sur le forum officiel, je pense.

Forcement, en faisant plein de test je suis tombé sur des choses qui m'ont plues. L'animation du train de l'A-10 est superbe, j'adore le mouvement des bielles. Si tu veux voir cela , il y a un bug lors du chargement de pilot.xml, sur le siège du pilote. Mais on peut le contourner de cette manière:
-Tu fais un import de A10-set.xml ou plus court Models/A-10-model.xml
Avant de faire la création des animations il faut faire la manipe suivante
Sélectionnes l'ensemble des objets empty
Dans la fenêtre 3D menu select
-select>SelectAll by Type>Empty
Puis tu fais une fausse translation
-Touche G puis Echap (pour ne pas modifer la position)
Normalement les objets empty vont réapparaitre à leur position correcte.
Cette fois tu peux créer les animations
-Touche F >création animations
Lance l'animation (Alt-A) et regarde les bielles du train. C'est un superbe travail, réalisé avec un logiciel c'est pratiquement certains. Cela sera accessible grâce au script.

Demain, je serai disponible sur mumble .....

A+

Bien vu Alexis ..

F-JJTH a écrit: Car je me souviens avoir été obligé de faire une animation bizarre pour la poignée situé au dessus du pilote. Dès que j'ai le temps je regarde les xml pour y comprendre un peu mieux.

Marrant, la poignée à un comportement bizarre avec le script. La rotation est au bon endroit, mais il y a une drôle de translation ...

A+

Alors ce même fichier interior.xml est plein de truc intéressants

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 :
Regardez :

Code:


<entry><ind>  0.00 </ind><dep>  0.00 </dep></entry>
<entry><ind>  0.12 </ind><dep> 45.00 </dep></entry>


(C'est l’interpolation de la rotation de la manette).
Visiblement, ça à l'air bon et pourtant, question : que ce passe-t-il quand la prop varie de 0.12 à 1 ?
Vous le savez, la manette reste tournée à 45°, or ce n'est pas indiqué, la formule plus correcte est la suivante :

Code:


<entry><ind>  0.00 </ind><dep>  0.00 </dep></entry>
<entry><ind>  0.12 </ind><dep> 45.00 </dep></entry>
<entry><ind>  1.00 </ind><dep> 45.00 </dep></entry>


Traduction en Français svp a écrit:
De 0 à 0,12 tourne à 45°
Ensuite de 0,12 à 1 reste à 45°

Flightgear comprenait la première formulation, mais si vous avez bidouiller des animations à s'en tirer une balle, il faut mieux en dire plus que le nécessaire, on est pas à l'abri d'un cas particulier auquel on aurait pas pensé. Donc si une prop varie de 0 à 1, elle doit varier de 0 à 1 dans l’interpolation.

Deuxième chose, et là je cherchais car je ne comprenais plus rien, rappelez vous ma loi fondamentale de l'animation :

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

Si je place la rotation après la translation, ça ne fonctionne plus du tout ! l'interpolation fait que de 0 à 0,12, ça fonctionne (pas encore de translation), mais dès que la translation commence à fonctionner, ça déconne.

Et c'est là que j'ai la révélation, ouf, ma loi fondamentale fonctionne encore :
La translation emporte le centre ! oui, elle translate le centre de rotation à 45 ° ! Youhou ! La rotation est incluse dans la translation et la dévie. Imaginez un archer debout sur une plateforme tournante, on la fait tourner à 45° et on lui dit de tirer ! pas glop !

Pour bien fonctionner il faut que la translation soit incluse dans la rotation. Ou plutôt, si je reformule : il faut que la rotation n'ai pas d'influence sur la translation. Imaginez le même archer, fait tourner la plateforme à 45° sauf que son arc ne dépend pas de la rotation (il corrige), du coup quand il tir, il met dans le mille !

J'espère que vous avez compris avec cette image

C'est dingue de voir tout ce qu'on peut apprendre de nos erreurs ! Merci à tous ceux qui en font, vous êtes des contributeurs du script !

---

Autre chose , Les courbes IPO de blender sont des courbes , je suis persuadé que flightear 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é ?

---

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