Script flightgear

As-tu un message d'erreur
Je suis mumble

Grrr, je ne peux pas changer de salon dans Mumble

Je n'ai pas de message d'erreur apparent (je le prendrai où éventuellement?).

Je fais Import => Flightger (xml), je sélectionne le dr400-jsbsim-set.xml par exemple, Blender mouline un peu, et la fenêtre de modélisation apparaît, mais vide.

Blender a pourtant l'air d'être satisfait de lui.

Si je lance Blender dans une console, c'est ma 2.49 qui se lance, même si je lance l'exécutable dans le dossier de la 2.63a.

ok va sur mumble , j'observe ta venu

Il n'est pas d'ac, ma bouche est barrée en vert.

j'essai de t'nvoyer des messages


Chat du forum ????

Code:

/home/titimint/fgdata/Aircraft/Aerostar-700/aerostar700-set.xml
Name : /home/titimint/fgdata/Aircraft/Aerostar-700/aerostar700-set.xml
current_path : /home/titimint/blender-2.63a
BaseName : aerostar700-set.xml
DirName  : /home/titimint/fgdata/Aircraft/Aerostar-700
Aircraft/Aerostar-700/
/home/titimint/fgdata/Aircraft/Aerostar-700/aerostar700-set.xml
xml_import:parse_file()  /home/titimint/fgdata/Aircraft/Aerostar-700/aerostar700-set.xml
         Pas d'offset
         Pas de rotation
xml_import:parse_file()  Aircraft/Aerostar-700/Models/aerostar.xml
   ac_manager:clone_ac() Aerostar-700/Models/aerostar700.ac
   Clone aerostar700.ac in 0.01 sec
xml_import:parse_file()  Aircraft/Aerostar-700/Models/cabin.xml
   ac_manager:clone_ac() Aerostar-700/Models/cabin.ac
   Clone cabin.ac in 0.01 sec
Traceback (most recent call last):
  File "/home/titimint/blender-2.63a/2.63/scripts/addons/ io_fg2blender/__init__.py", line 165, in execute
    import_xml(   filename, ac_option, xml_option )
  File "/home/titimint/blender-2.63a/2.63/scripts/addons/ io_fg2blender/xml_import.py", line 888, in import_xml
    read_file_xml( conversion(filename) )
  File "/home/titimint/blender-2.63a/2.63/scripts/addons/ io_fg2blender/xml_import.py", line 839, in read_file_xml
    parse_file( conversion(file_name), -1 )         
  File "/home/titimint/blender-2.63a/2.63/scripts/addons/ io_fg2blender/xml_import.py", line 797, in parse_file
    parse_file( conversion(file_include), no )
  File "/home/titimint/blender-2.63a/2.63/scripts/addons/ io_fg2blender/xml_import.py", line 797, in parse_file
    parse_file( conversion(file_include), no )
  File "/home/titimint/blender-2.63a/2.63/scripts/addons/ io_fg2blender/xml_import.py", line 787, in parse_file
    file_includes = parse_node( node, filename )
  File "/home/titimint/blender-2.63a/2.63/scripts/addons/ io_fg2blender/xml_import.py", line 726, in parse_node
    ret_list += parse_node( n, file_name )
  File "/home/titimint/blender-2.63a/2.63/scripts/addons/ io_fg2blender/xml_import.py", line 726, in parse_node
    ret_list += parse_node( n, file_name )
  File "/home/titimint/blender-2.63a/2.63/scripts/addons/ io_fg2blender/xml_import.py", line 663, in parse_node
    read_offset_path( node.parentNode, xml_file )
  File "/home/titimint/blender-2.63a/2.63/scripts/addons/ io_fg2blender/xml_import.py", line 588, in read_offset_path
    xml_file.offset = Vector( (0.0,0.0,0.0) )  + read_vector_center(child)
  File "/home/titimint/blender-2.63a/2.63/scripts/addons/ io_fg2blender/xml_import.py", line 134, in read_vector_center
    v.y = ret_float_value(childs[0])
  File "/home/titimint/blender-2.63a/2.63/scripts/addons/ io_fg2blender/xml_import.py", line 341, in ret_float_value
    s = float( sup_space( child.nodeValue ) )
ValueError: could not convert string to float: '-0.0xxx'

location:<unknown location>:-1

location:<unknown location>:-1


Bonjour à tous,

Demi victoire, pour pouvoir enfin avoir la bonne vue, et importer via les xml, il faut qu'à l'ouverture de Blender je fasse un "split aréa" et là, ho magie!, les fenêtres des calques apparaissent, ainsi que les objets concernés.

La différence entre les 2 fenêtres, en haut à gauche "Front ortho (local)", et "User ortho" pour la fenêtre qui va bien.

on avance...

Salut Patten,

Je me suis penché sur ton problème, dimanche, et je pense qu'il faut reconfigurer blender.
Je n'ai pas réussi à recréer l'absence des layers dans la fenêtre 3D. Et pourtant, cela m'était déjà arrivé.
Par contre, tu devrais essayer la "manip" suivante :
Redémarre avec un blender configuré par défaut.

Dans le menu "File"
Tu recharges la config par défaut : "Load Factory Settings"
Tous les addons sont retirés, ansi que la configuration 'GLSL', et vbos
Ensuite tu réactives le script
Ctrl-Alt-U ... etc ...
Et tu testes le script.


Si cela fonctionne, tu réactives l'accélaration "GLSL, et vbo". Et l'affichage des textures sera meilleur.
N'oublie pas de changer le mode d'affichage. Dans la fenêtre 3d en bas ,à côté, de "Object Mode" il y a un bouton où tu choisi le mode d'affichage :
"Texture", ou "Solid" ou "Wireframe" ou "Boundinbox".
Mets ce bouton en texture :
Cette fois la transparence est mieux géré.

Pour avoir les animations il faut les chargés après le chargement de l'avion
Touche "F"
Un menu flightgear apparait:
Et tu choisi "Creation animations"

Pour lancer les animations chargés, le raccourci :
"Alt-A" lance/stop les animations
Les flèches droite et gauche déplace la "frame" courrante.

Tiens-moi au courant


A+

Etat actuel du script :

Disfonctionnement (découvert):

1.
Lors de l'import de certains avions, blender me renvoi une erreur sur des doublons de vertex sur des faces, cela arrive.

Code:

BLI_assert failed: source/blender/blenlib/intern/edgehash.c:98, BLI_edgehash_insert(), at 'v0 != v1'

Cette erreur est issu du chargement de : A-10-set.xml
Cela entraîne un cafouillage au niveau des objets "empty" qui donneront des animations farfelues. Ont peut y remédier avec une manip 'douteuse' que je ne vous détaille pas car c'est plus une "bidouille" qu'autres choses. Dans certains avions le chargement est interrompu.

2.
Lors de l'import de "fkdr1/fkdr1-set.xml"
Les coordonnées de texture ne sont pas correct. Mais il n'y a aucun message d'erreurs. Il faut que je regarde cela de plus près.

3.
Lors du chargement de "fw190/fw190a8-set.xml"
Tout ce passe bien, mais au moment de la visualisation des animations deux roues ont été créé. Pareil à regarder de plus près. (paramètre compression ???)

4.
Lors du chargement du DR400 rembrandt.
Les lumières ont besoin d'un objet pour délimiter leur influence(si je ne me trompes pas). Ces objets cacheront entièrement l'avion. En cachant ces objets, on peu afficher quand même l'avion.
Sélectionnez l'objet puis le raccourci clavier 'H', permet de cacher l'objet (il n'est pas effacé). Recommencez l'action pour tout les objet de la lumière rembrandt.
J'envisage de modifer l'affichage de ces objets, une fois intercepté dans le xml, en utilisant l'affichage "wire", des objets. Wire = affichage en fil de fer. De cette manière l'objet est toujours présent, mais ne masque plus l'avion.
@ Clément : Peux-tu me donner la structure de ces lumières dans le fichier xml.
Tu pensais peut-être à cela en créant l'option light ?
Il faut modifier la propriété blender de l'objet
bpy.data.objects['Cube'].draw_type='WIRE'
Cela devrait suffire sinon: il y a aussi :
bpy.data.objects['Cube'].show_wire=True (par défaut False)

5.
Lors du chargement du DR400 (standard 2.6)
Si l'on charge panel.xml, les boutons de la radios sont au bon endroit.
Par contre, si l'on charge l'avion complet, certains boutons de la radios ne sont pas à leur place. On le voit bien en lançant l'animation. Certainement la gestion des offset des roll-deg posent ici un problème. La première correction a déjà corriger certains problèmes, il faut que je regarde cela.

6.
Le dc-3 m'a donné des soucis avec l'animation du volant. En décortiquant le xml, je me suis apperçu que les 'blocs' d'animations n'étaient pas dans le bon l'ordre. En modifiant le xml. Cela a remis les animations dans le bon ordre. Par contre j'ignore encore l'influence que cela peut avoir dans flightgear ???? (A regarder)

Avancement
En ce moment j'incorpore, les données de flightgear dans blender.
Certaines propriétés ont été ajoutés dans blender.
Par exemples:
Dans le cas des armatures
bpy.dat.objects['Cube'].data.fg.familly
bpy.dat.objects['Cube'].data.fg.familly_value (juste pour la gestion interne)
bpy.dat.objects['Cube'].data.fg.property_value
bpy.dat.objects['Cube'].data.fg.factor
bpy.dat.objects['Cube'].data.fg.xml_file
bpy.dat.objects['Cube'].data.fg.xml_present (gestion interne)
bpy.dat.objects['Cube'].data.type_anim (1:rotation 2:translation 4:pick)

Dans le cas des meshs
bpy.data.objects['Cube'].data.fg.ac_file


pour tester si l'objet est une armature ou un mesh
bpy.data.objects['Cube'].type renseigne son type :
bpy.data.objects['Cube'].type='ARMATURE' ou bpy.data.objects['Cube'].type='MESH'


A faire (urgent)
Aujourd'hui , lors de l'import de fichier .ac , à différents endroit, le script gère cela en clonant les objets. Il en résulte, quand modifiant un objet cela se retrouve sur tous le objets identiques. (Tete de pilote par exemple : pour le dc-3 Models/Cockpit/cockpit.xml)
Il faudra que je fasse la même chose pour les animations. Lorsque un fichier xml est incorporé plusieurs fois. Il faudra créer des 'clones' de l'animation, pour qu'une modification d'animation se répercute sur ces "clones".


Bientôt

Je vais faire des test d'écriture de fichier .ac et fichier xml.

@Patten

Je n'arrive pas à bien voir sur ta recopie d'écran .....
Mais cela me fait penser à une chose.
Dans blender on peut configurer l'affichage de deux manières. Ortho ou Perspective
La touche '5' du clavier numérique permet de passer le l'un à l'autre


Dans perspective certains paramètre sont ajustable.
Partie droite de la fenêtre 3d (touche N)

Panel View:
Lens = 35 par default, c'est l'equivalent d'un objectif photo de 35mm.
Clip Start et End
Permet de régler les plans de cliping . Toutes parties d'un objet distant par rapport à l'oeil virtuel, d'une distance inférieur à Start et supperieur à End .ne seront pas affichées.
Dans le mode ortho cela n'a pas d'effet

Bonjour tout le monde,


Pour commencer une recopie d'écran

Le script arrive à charger le reflet des verrières, en lisant l'animation "shader". (Le test a été sur le fgdata 2.6)

J'ai une question, a propos de la variable d'environnement FG_ROOT

Cette variable est-elle créé sur tout les systèmes (windows, linux mac) ?? Car pour charger les textures des reflets, il faut charger une texture du fgdata, /Aircraft/generic/...
Pour l'instant le chemin est en dur dans le script, et forcement incompatible avec tout le monde. C'est un chemin spécifique a mon "ordi".

Bonjour tout le monde,


Je me pose beaucoup de questions, sur l'animation dans flightgear, et je trouve des incohérences, dans la déclaration de la translation de la verrière. Ces animations se trouvent dans le fichier interior.xml du DR400-jsbSim. Elles indiquent à flightgear de faire des translations avec comme propriété "instrumentation/doors/crew/position-norm". Or le vecteur de translation n'est n'est pas toujours identiques, les valeurs d'interpolation ne sont pas toujours identiques. Or flightgear affiche correctement la translation. C'est pour moi un mystère.

Je fait le test suivant dans flightgear. Je modifie interior.xml pour avoir la même interpolation et le même vecteur, pour la plaque et le reste de la verrière :

Code:

<entry><ind> 1.00 </ind><dep> 0.40 </dep></entry>
en
<entry><ind> 1.00 </ind><dep> 0.80 </dep></entry>

Et la plaque fait une translation double ! pourquoi ????
Qu'est-ce qui permet de faire des transformations différentes avec des valeurs identiques. ????




Interior.xml

Code:

  <animation>
    <type>translate</type>
    <object-name>intverriere</object-name>
    <object-name>longeronint</object-name>
    <object-name>toitverriereint</object-name>
    <property>instrumentation/doors/crew/position-norm</property>
    <interpolation>
      <entry><ind> 0.12 </ind><dep> 0.00 </dep></entry>
      <entry><ind> 1.00 </ind><dep> 0.80 </dep></entry>
    </interpolation>
    <axis>
      <x> -1 </x>
      <y>  0 </y>
      <z>  0 </z>
    </axis>
  </animation>

  <animation>
    <type>translate</type>
    <object-name>plaque_canopy</object-name>
    <property>instrumentation/doors/crew/position-norm</property>
    <interpolation>
      <entry><ind> 0.12 </ind><dep> 0.00 </dep></entry>
      <entry><ind> 1.00 </ind><dep> 0.40 </dep></entry>
    </interpolation>
    <axis>
      <x> -1 </x>
      <y>  0 </y>
      <z>  0 </z>
    </axis>
  </animation>

  <animation>
    <type>translate</type>
    <object-name>poignee_canopy</object-name>
    <property>instrumentation/doors/crew/position-norm</property>
    <interpolation>
      <entry><ind> 0.12 </ind><dep> 0.00 </dep></entry>
      <entry><ind> 1.00 </ind><dep> 0.80 </dep></entry>
    </interpolation>
    <axis>
      <x> -0.0625 </x>
      <y>  0.0625 </y>
      <z>  0.000 </z>
    </axis>
  </animation>


J'ai regardé du côté du nasal, (mais je ne connais pas grand chose) et je ne trouve rien relié à la propriété ou aux objets. Peut-être doors.nas, mais il me semble, que ce fichier n'est utilisé que pour donnée le temps de variation de la propriété ??
Je sèche .....
A+

Salut rené,
Je suis de retour ! je vais essayer de m'attaquer aux soucis de xml que tu rencontre.

Je commence par le problème de la plaque du DR-400 :
Alors aucune liaison avec le nasal, ça vient pas de là, la prop indique effectivement une durée d'animation, mais il n'y a aucune interpolation dans le nasal. Je regarde le xml, et la je crois que ça déconne.

Code:


  <model>
    <name>Pilote</name>
    <path>Aircraft/DR400-jsbSim/Models/Interior/Panel/Instruments/pedals/pedals.xml</path>
    <offsets>
      <x-m> -2.047 </x-m>
      <y-m> -0.234 </y-m>
      <z-m> -0.225 </z-m>
    </offsets>
  </model>

  <model>
    <name>Pilote</name>
    <path>Aircraft/DR400-jsbSim/Models/Interior/Panel/Instruments/pedals/pedals.xml</path>
    <offsets>
      <x-m> -2.047 </x-m>
      <y-m>  0.234 </y-m>
      <z-m> -0.225 </z-m>
    </offsets>
  </model>

  <!-- Manche -->
  <model>
    <name>Pilote</name>
    <path>Aircraft/DR400-jsbSim/Models/Interior/Handle/handle.xml</path>
    <offsets>
      <x-m> -1.497 </x-m>
      <y-m>  0    </y-m>
      <z-m> -0.21 </z-m>
    </offsets>
  </model>


Pourquoi à chaque fois, il y a une balise <name>Pilote</name>, bien étrange, ça doit être une erreur humaine. Un mauvais copier coller de la balise (ligne 55-63):

Code:


  <model>
    <name>Pilote</name>
    <path>Aircraft/DR400-jsbSim/Models/Pilot/pilot.xml</path>
    <offsets>
      <x-m> -1.474 </x-m>
      <y-m> -0.251 </y-m>
      <z-m> -0.029 </z-m>
    </offsets>
  </model>


Et d'ailleurs, pourquoi avoir mis une balise <name>Pilote</name> ? je me rends compte qu'on peut donner un nom à l'ensemble d'un fichier 3d (externe) et s'en servir pour l'animation. Je ne connaissait pas ça, si dans ce fichier une animation appelait l'objet Pilote (qui est donc un groupe d'objets), ça causerait de gros problèmes.

J'ai testé et ajouté une animation incluant le groupe d'objet Pilote :

Code:


  <animation>
    <type>rotate</type>
    <object-name>Pilote</object-name>
    <property>instrumentation/doors/crew/position-norm</property>
    <interpolation>
      <entry><ind>  0.00 </ind><dep>  0.00 </dep></entry>
      <entry><ind>  0.12 </ind><dep> 45.00 </dep></entry>
    </interpolation>
    <axis>
      <x>  0 </x>
      <y>  0 </y>
      <z>  1 </z>
    </axis>
    <center>
      <x-m> -1.064 </x-m>
      <y-m>  0.000 </y-m>
      <z-m>  0.000 </z-m>
    </center>
  </animation>


Tout ce qui à été inclu dans ce <name>Pilote</name> est animé !

Figure toi que la plaque aussi est externe au fichier interior.ac :

Code:


<!-- Plaque interieur canopy -->
  <model>
    <name>plaque_canopy</name>
    <path>Aircraft/DR400-jsbSim/Models/Interior/Panel/Instruments/plaques/plaque_canopy.xml</path>
    <offsets>
      <x-m> -0.991 </x-m>
      <y-m> 0.000 </y-m>
      <z-m> 0.701 </z-m>
    </offsets>
  </model>


L'ensemble de ce qui a dans le fichier plaque_canopy.ac sera nomé plaque_canopy et regarde bien, il y a un offsets. Comment ceci est géré dans FlightGear ?

Dis-moi si je me trompe, un offset n'est rien d'autre qu'une animation permanente de type translation. Ne serait-ce pas encore un soucis d'ordre d'animation ?
Je prends la partie X du vecteur déplacement, soit -0.991 (dans le offset,le négatif va vers l'avant). Elle doit rentrer en conflit avec la translation en X de la verrière. J'ai du mal à comprendre, Je perds le fil en essayant de visualiser le problème, j’essaie de calculer la chose dans tout les sens, j'y arrive pas. Je pense que la personne qui à réalisé ça à fonctionné en essayant plusieurs fois et en cherchant la bonne valeur

Je sais que tu as une bonne expérience en géométrie dans l'espace, tu vas peut-être trouver après ce que je viens d'écrire, en tout cas ça montre tout l'intérêt d'utiliser un logiciel pour gérer le xml, plus d'erreurs humaines.

@++, Alexis

Je sais !

0.8 = 2 x 0.4

La translation de 0.4 se produit 2 fois, une fois pour l'objet et une fois pour son centre. Or le déplacement du centre de l'objet implique un déplacement de cet objet, soit un déplacement final de 0.8 !

C'est ça ou je dis une connerie de plus ?

[édit] euh c'est pas très logique ce que je dis, mais il y a quelque chose comme ça qui se passe

J'ai raison ! ah ah ! (oui, je cherche depuis longtemps, alors je suis bien content d'avoir compris lol)

J'ai viré l'animation de la plaque dans fichier interrior.xml et j'ai aussi viré le <name>plaque_canopy<name> du offset

J'ai ensuite placé une animation de 80 cm dans le fichier plaque_canopy.xml

J'ai donc les deux fichiers suivant :

interior.xml

Code:


<?xml version="1.0" encoding="UTF-8"?>

<!-- ########################################

 # DR400-jsbSim by PAF team
 # April 2012 : Modified by PAF team
 # http://equipe-flightgear.forumactif.com

##########################################-->

<PropertyList>

  <path>interior.ac</path>

  <animation>
    <!-- Objets opaques -->
    <object-name>interieur</object-name>
    <object-name>tour</object-name>
    <object-name>sieges</object-name>
    <object-name>ceintures</object-name>
    <object-name>sono</object-name>
    <object-name>longeronint</object-name>
    <object-name>toitverriereint</object-name>
    <object-name>poignee_canopy</object-name>

    <!-- Objets transparents -->
    <object-name>intverriere</object-name>
    <object-name>intverriere2</object-name>
  </animation>

 <animation>
    <type>shader</type>
    <shader>chrome</shader>
    <texture>Aircraft/Generic/Effects/glass_shader.png</texture>
    <object-name>intverriere</object-name>
    <object-name>intverriere2</object-name>
  </animation>

  <animation>
    <type>noshadow</type>
    <object-name>intverriere</object-name>
    <object-name>intverriere2</object-name>
  </animation>

  <animation>
    <type>select</type>
    <object-name>intverriere</object-name>
    <object-name>intverriere2</object-name>
    <condition>
      <property>sim/model/config/glass-reflection</property>
    </condition>
  </animation>

  <!-- Pilote -->
  <model>
    <path>Aircraft/DR400-jsbSim/Models/Pilot/pilot.xml</path>
    <offsets>
      <x-m> -1.474 </x-m>
      <y-m> -0.251 </y-m>
      <z-m> -0.029 </z-m>
    </offsets>
  </model>

<!-- Plaque interieur canopy -->
  <model>
    <path>Aircraft/DR400-jsbSim/Models/Interior/Panel/Instruments/plaques/plaque_canopy.xml</path>
    <offsets>
      <x-m> -0.991 </x-m>
      <y-m> 0.000 </y-m>
      <z-m> 0.701 </z-m>
    </offsets>
  </model>

  <!-- Tableau de bord -->
  <model>
    <path>Aircraft/DR400-jsbSim/Models/Interior/Panel/panel.xml</path>
    <offsets>
      <x-m> -1.859 </x-m>
      <y-m>  0.000 </y-m>
      <z-m>  0.099 </z-m>
      <roll-deg>    0.000 </roll-deg>
      <pitch-deg>  -5.000 </pitch-deg>
      <heading-deg> 0.000 </heading-deg>
    </offsets>
  </model>

  <!-- Les palonniers -->
  <model>
    <path>Aircraft/DR400-jsbSim/Models/Interior/Panel/Instruments/pedals/pedals.xml</path>
    <offsets>
      <x-m> -2.047 </x-m>
      <y-m> -0.234 </y-m>
      <z-m> -0.225 </z-m>
    </offsets>
  </model>

  <model>
    <path>Aircraft/DR400-jsbSim/Models/Interior/Panel/Instruments/pedals/pedals.xml</path>
    <offsets>
      <x-m> -2.047 </x-m>
      <y-m>  0.234 </y-m>
      <z-m> -0.225 </z-m>
    </offsets>
  </model>

  <!-- Manche -->
  <model>
    <path>Aircraft/DR400-jsbSim/Models/Interior/Handle/handle.xml</path>
    <offsets>
      <x-m> -1.497 </x-m>
      <y-m>  0    </y-m>
      <z-m> -0.21 </z-m>
    </offsets>
  </model>
 

  <!-- Canopy -->
  <animation>
    <type>rotate</type>
    <object-name>poignee_canopy</object-name>
    <property>instrumentation/doors/crew/position-norm</property>
    <interpolation>
      <entry><ind>  0.00 </ind><dep>  0.00 </dep></entry>
      <entry><ind>  0.12 </ind><dep> 45.00 </dep></entry>
    </interpolation>
    <axis>
      <x>  0 </x>
      <y>  0 </y>
      <z>  1 </z>
    </axis>
    <center>
      <x-m> -1.064 </x-m>
      <y-m>  0.000 </y-m>
      <z-m>  0.000 </z-m>
    </center>
  </animation>
 
  <animation>
    <type>translate</type>
    <object-name>intverriere</object-name>
    <object-name>longeronint</object-name>
    <object-name>toitverriereint</object-name>
    <property>instrumentation/doors/crew/position-norm</property>
    <interpolation>
      <entry><ind> 0.12 </ind><dep> 0.00 </dep></entry>
      <entry><ind> 1.00 </ind><dep> 0.80 </dep></entry>
    </interpolation>
    <axis>
      <x> -1 </x>
      <y>  0 </y>
      <z>  0 </z>
    </axis>
  </animation>



  <animation>
    <type>translate</type>
    <object-name>poignee_canopy</object-name>
    <property>instrumentation/doors/crew/position-norm</property>
    <interpolation>
      <entry><ind> 0.12 </ind><dep> 0.00 </dep></entry>
      <entry><ind> 1.00 </ind><dep> 0.80 </dep></entry>
    </interpolation>
    <axis>
      <x> -0.0625 </x>
      <y>  0.0625 </y>
      <z>  0.000 </z>
    </axis>
  </animation>

  <animation>
    <type>pick</type>
    <object-name>poignee_canopy</object-name>
    <action>
      <button>0</button>
      <binding>
        <command>nasal</command>
        <script>globals.dr400.doorsystem.crewexport();</script>
      </binding>
    </action>
  </animation>

</PropertyList>


et plaque_canopy.xml

Code:


<?xml version="1.0" encoding="UTF-8"?>

<!-- ########################################

 # DR400-jsbSim by PAF team
 # April 2012 : Modified by PAF team
 # http://equipe-flightgear.forumactif.com

##########################################-->

<PropertyList>

  <path>plaque_canopy.ac</path>
 
  <animation>
    <type>translate</type>
    <object-name>plaque_canopy</object-name>
    <property>instrumentation/doors/crew/position-norm</property>
    <interpolation>
      <entry><ind> 0.12 </ind><dep> 0.00 </dep></entry>
      <entry><ind> 1.00 </ind><dep> 0.80 </dep></entry>
    </interpolation>
    <axis>
      <x> -1 </x>
      <y>  0 </y>
      <z>  0 </z>
    </axis>
  </animation>
</PropertyList>


Et ça fonctionne !

Donc autrefois, l'animation de 40cm déplaçait l'objet (ou plutôt) le groupe d'objet, ainsi que le offset, soit un déplacement total de 80cm

Moralité : Ne jamais faire ça

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