Script flightgear

L'utilisation de blender est extrêmement simple, expliquer comment marche blender l'est beaucoup moins ! En tout cas, tu le fais très bien run

Je trouve d'ailleurs au passage que les vidéos sont une bonne manière d'apprendre à faire tourner blender, avec 15 min de visionnage par jour Clément, tu vas devenir une bête !

Alexis a écrit:Quand à lire des fichiers modifiés par les utilisateurs, ça n'est pas impossible, ils se présentent toujours de la même manière, tout ce qui change d'un auteur à l'autre c'est le nombre de tabulations ou d'espaces avant les balises, la mise en forme des interpolations. J'avais commencé un script pour mettre en forme les fichiers xml, si on pouvais passer tout les fichiers dans cette petite moulinette de mise en forme, ils seraient tous lisibles. Il faudrait donc définir des règles de mise en forme.

Pour lire les fichiers xml, cela fait quelques heures que je me penche sur la bibliothèque python xml.dom.minidom
Elle est parfaite, elle peut lire tout le xml. On retrouve toutes les données sous une forme d'arbre. On retrouve toutes les informations dans des listes.
Je ne l'ai pas testé encore en écriture, mais j'ai l'impression que je vais avoir de bonne surprise.

J'ai remarqué que les fichiers xml était enchainé les uns aux autres, mais j'ai du mal à retrouver le premier.
dc-3-base.xml
dc-3A-set.xml
dc-3-set.xml
dc-3-copilot-set.xml
dc-3-jsbsim.xml
dc-3A-yasim.xml

Quel est la règle ???
Y a-t-il plusieurs avions de défini ???
A++

Ici, oui, il y a "plusieurs avions en un", avec et sans flotteurs.

En fait, FG va tout d'abord lire le fichier -set.xml, ensuite on peut appeler tous les autres fichiers de différentes manière :

par un attribut dans la première balise :
<PropertyList include="dc-3-base.xml">

En fait, tout ce qui est ajouté dans cette balise pourrait être contenu dans le -set, il est séparé pour des raisons de visibilité (même si je trouve perso que tout ça est un peu trop séparé )


Ensuite chaque grande catégorie est appelé :
Toute la partie visible :

<model>
<path>Aircraft/Douglas-Dc3/Models/dc-3.xml</path>
<livery>
<file type="string">default</file>
</livery>
</model>


Tout ce qui est entendu :

<sound>
<path>Aircraft/Douglas-Dc3/Sounds/dc-3A-sound.xml</path>
</sound>

Le FDM :

<flight-model>yasim</flight-model>
<aero>dc-3A-yasim</aero>

La page de chargement (image) :

<startup>
<splash-texture>Aircraft/Douglas-Dc3/dc-3-splash.png</splash-texture>
</startup>

Merci Alexis

J'ai fait un petit programme python illisible, même moi j'ai du mal à lire mes lignes. Mais j'ai a peu prêt réussi à parcourir l'ensemble des fichiers xml du dc-3. Comme je vous l'avais annoncer j'essaye d'utiliser une bibliothèque python pour lire les fichiers xml.

Ce programme se lance dans le répertoire fgdata_paf. Il ouvre le fichier "dc-3-set.xml" et va lire toutes les "noeuds" du fichier xml. On peut traduire noeud (node en anglais) par le terme balise du xml.
Il recherche les balises "path" et les attributs "include". Il affiche toutes les balises avec leur valeur. N'affiche pas les commentaires. Puis ouvre les fichiers inclus. Même si je n'ai pas tout vérifier en détails (il n'arrive pas à lire quelques fichiers du tuto, car ils n'ont pas de chemin) il arrive à lire la grande majorité. (18000 lignes)

Il a été écrit pour python 3.2.
Ce mettre dans le répertoire fgdata_paf
Faire un copier-coler du code dans un fichier : truc.py
puis lancer le script par la commande : python truc.py

Code:

#!/usr/bin/env python3.2
import sys
import os



import xml.dom
from xml.dom import minidom
from xml.dom.minidom import Document


niv = 0

def tabs():
   global niv
   ret = ''
   for c in range(niv):
      ret += '\t'
   return ret






def ret_text( node ):
   s = ""
   if node.nodeType == 3:
      if node.nodeValue[0] != '\n':
         s = node.nodeValue
   return s





def parcour_child( node ):
   global niv

   ret_list = []
   value = ""
   # Element
   if node.nodeType == 1:
      extra = ""
      if node.hasChildNodes():
         extra += ret_text(node.childNodes[0])
      if node.hasAttributes():
         for i in range(node.attributes.length):
            extra += " attr:"+node.attributes.item(i).name + "=" + node.attributes.item(i).value +"  "
            if node.attributes.item(i).name == 'include':
               print( "*** Bingo ****  Fichier include" )
               ret_list +=  [ str(node.attributes.item(i).value) ]
      if extra!= "":
         print( "%s<%s>%s" % (tabs(),node.nodeName,extra) )
      else:
         print( "%s<%s>" % (tabs(),node.nodeName) )
      if node.nodeName == 'path':
         if ret_text(node.childNodes[0]).find('.xml')!=-1:
            ret_list +=  [ ret_text(node.childNodes[0]) ]
            print( "*** Bingo ****  Fichier xml" )
         if node.hasChildNodes():
            if ret_text(node.childNodes[0]).find('.ac')!=-1:
               print( "*** Bingo ****  Fichier AC3D" )

   #Attribut
   elif node.nodeType == 2:
      print( "%sATTR:%s = %s" % (tabs(),node.nodeName, node.nodeValue) )
   # text
   #elif node.nodeType == 3:
   #Commentaire
   elif node.nodeType == 8:
      print( "%sCommentaire" % tabs() )
   #Undef
   elif node.nodeType != 3:
      print( "%sIndéfini %d" % (tabs(), node.nodeType) )
      
      
   niv += 1
   for n in node.childNodes:
      ret_list += parcour_child( n )
   niv -= 1
   return ret_list


path = 'Aircraft/Douglas-Dc3/'


def lit_fichier( filename ):
   global niv
   
   print( "######################################################################" )
   print( filename )
   file_includes = []
   niv = 0
   if os.path.isfile(filename):
      fsock = open(filename)
      xmldoc = minidom.parse(fsock)
      fsock.close()               
      node = xmldoc.documentElement
      file_includes = parcour_child( node )
   else:
      print( "Fichier introuvable : %s" % filename  )
         
   print( "----------------------------------------------------------------------" )
   for file_include in file_includes:
      print( file_include )
   
   for file_include in file_includes:
      if file_include.find( path ) == -1:
         file_include = path + file_include
      lit_fichier( file_include )


lit_fichier( path+'dc-3-set.xml' )
     


Mon avis est le suivant :

Seul les fichiers qui contiennent une balise <path>fichier.ac</path> doivent être lu par le script de blender, car c'est uniquement grâce à cette balise <path> que l'on fait référence à un fichier AC.
Les fichiers qui ne font pas référence à un fichier AC n'ont pas d'intérêt à être lu et interprété par Blender (views.xml, keyboard.xml, tutorial.xml, dc-3-base.xml, dc-3-set.xml .......)

Au final, seul les fichiers situé dans le dossier "Models" et ses sous-dossier doivent être interprété.
Le script ne doit reconnaître que les balises <path> et <animation> (et ce qui se trouve dedans biensur), bien sûr si on arrive à faire plus c'est chouette mais je ne suis pas certain qu'on en est besoin.

Amicalement,
Clément

Re Clément,

Ne t'inquiètes pas , Il ne s'agit pas de lire l'ensemble du xml, autant réecrire flightgear. lol
Mais pour retrouver les animations on est obligé de tout parcourir. Pour le dc-3 par exemple, pour remonter aux animations qui nous intérresse on parcours au moins 3 attribut include qui renvois sur du xml.
Dans ce script aucune données n'est sauvegardées entre deux fichiers. Il faudra s'arrêter sur les noeuds contenant "animation" et "path" puis transférer les données à blender. A ce moment le programme va grossir. Pour l'instant ce script ne fait qu'un "print" bête et méchant.
Cette bibliothèque à l'avantage de pouvoir lire n'importe quel fichier xml valide. Sans ce soucier des tabulations, des espaces des retours chariots( en plus différent entre window et linux/mac \n\r ou bien \n) Un parseur n'est jamais simple à écrire. On peut déja s'appuyer sur cette bibliothèque.
Le but n'est pas de faire plus, mais plutôt de ne rien oublié.


A+

Bonjour la PAF,

J'ai terminé un script de lecture (petite lecture) de fichier xml de flightgear.
Ce programme python affiche les transformations contenues dans les fichiers xml, Il ne fait qu'afficher. Il recherche les balises <animations> <path> et l'attribut include ex: <PropertyList include="blabla"> pour pouvoir lire aussi les autres fichiers xml d'un avion. Il peut si on le souhaite, parcourir tout l'arbre xml, d'un avion.
Cette lecture "récursive" est faisable à la demande de l'utilisateur. On peut lire uniquement un seul fichier xml.
Il a été écrit pour pouvoir être utiliser dans blender mais aussi en ligne de commande.
J'ai essayé, aussi, de le rendre compatible windows, (les chemins sont différents) pour les fichiers. Sans doutes, pour les fichiers xml inclus, il ne fonctionne pas.
Il extrait aussi les offsets, mais aussi les pitch-roll .... des fichiers inclus.
Enfin, avec un petit script shell, j'ai pu parcourir l'ensemble du répertoire fgdata de flightgear (401 répertoire pour 500 et quelques avions). Le script plante pour les fichiers xml invalide pour le codage des caractères:
<?xml version="1.0" encoding="UTF-8"?>
Il me semble que Alexis avait fait un post là dessus

Voilà un exemple de ce qu'il peut extraire :

Code:

Aircraft/Douglas-Dc3/Models/main.xml
        Fichier AC3D <path>: dc-3.ac
        Animation sans type
        Animation type : material
        Animation type : shader
        Animation type : noshadow
        include : Aircraft/Douglas-Dc3/Models/Immat/immat.xml
                Pas d'offset
        include : Aircraft/Douglas-Dc3/Models/Cabine/cabine.xml
                Offset :  0 , 0 , 0
        include : Aircraft/Douglas-Dc3/Models/Cockpit/cockpit.xml
                Offset :  -8.346 ,  0.000 ,  0.185
        include : Aircraft/Douglas-Dc3/Models/Engines/engineG.xml
                Offset :  -6.542 , -2.814 , -1.189
        include : Aircraft/Douglas-Dc3/Models/Engines/engineD.xml
                Offset :  -6.542 ,  2.814 , -1.189
        Animation type : material
        include : Aircraft/Douglas-Dc3/Models/ailettesL.xml
                Offset :  -6.040 , -2.814 , -1.195
        include : Aircraft/Douglas-Dc3/Models/ailettesR.xml
                Offset :  -6.040 ,  2.814 , -1.195
        include : Aircraft/Douglas-Dc3/Models/Effects/cranking/crankingL.xml
                Offset :  -4.873 , -3.393 , -1.559
                roll-deg :      0
                pitch-deg :    35
                heading-deg :  -10
        include : Aircraft/Douglas-Dc3/Models/Effects/cranking/crankingR.xml
                Offset :  -4.873 ,  3.393 , -1.559
                roll-deg :      0
                pitch-deg :    35
                heading-deg :  10
        include : Aircraft/Douglas-Dc3/Models/Light/dc-3-lights.xml
                Offset :  0 , 0 , 0
        Animation rotate : rotate
                Property : surface-positions/rudder-pos-norm
                Object : direction
                Axe :  0 , 0 , 1
                Center :  8.076 , 0.000 , 2.368
                Factor :  -25
        Animation rotate : rotate
                Property : surface-positions/elevator-pos-norm
                Object : profondeur
                Axe :  0 , 1 , 0
                Center :  8.724 , 0.000 , 0.107
                Factor :  30
        Animation rotate : rotate
                Property : surface-positions/left-aileron-pos-norm
                Object : aileronG
                Axe : pt1  -0.894 , -13.695 ,  0.125    pt2  -1.221 ,  -6.313 ,  -0.955
                Factor :  15
        Animation rotate : rotate
                Property : surface-positions/right-aileron-pos-norm
                Object : aileronD
                Axe : pt1  -1.221 ,  6.313 , -0.955    pt2  -0.894 , 13.695 ,  0.125
                Factor :  15
        Animation rotate : rotate
                Property : surface-positions/flap-pos-norm
                Object : voletG2
                Axe : pt1  -1.214 , -6.313 , -1.046    pt2  -1.214 , -3.484 , -1.476
                Factor :  40


------------------------------------------------------------------------------------
**** J'aimerai avoir votre avis sur plusieurs choses ?? ****
-----------------------------------------------------------------------------------
-Pensez-vous qu'il est utile de continuer dans ce sens?
J'utilise une bibliothèque python xml.dom.minidom Cette bibliothèque me semble parfaite pour cela (à mon sens).

-Souhaitez-vous l'utilisation d'une autre bibliothèque, ou bien écrire un parseur "from scratch" ??

-Voulez-vous tester ce début de parseur ? Pensez-vous utile de l'uploader sur gitorious ?
Cette fois il fait presque 500 lignes, et le forum ne me semble pas approprié.

-J'ai l'impression de "noyer le poisson" (amicalement) ! Ce sentiment est-il légitime ??
Sur ce forum, j'ai tenté de dégrossir l'api python de blender, pour pouvoir créer une interface "flightgear" à blender. Mais aussi sur l'utilisation de blender et de ses armatures. Maintenant il y a cette bibliothèque python. Je comprends, tout à fait, que cela fait une grosse quantité d'informations à digérer, en peu de temps.
Certains on peut être l'impression que "je passe du coq à l'âne". Alors que pour moi tout est lié.


Voilà ...
Amicalement René

Salut René,

Concernant l'encodage des caractères c'est assez simple :
<?xml version="1.0" encoding="UTF-8"?> N'ACCEPTE PAS les caractères "Speciaux" : àâéèçêîôöï en clair, dès qu'on met un accent ou un truc un peu bizarre : ça marche pas
Si on veux écrire des caractères spéciaux il faut utiliser <?xml version="1.0" encoding="iso-8859-1"?> (Et même si c'est dans un commentaire xml ! )

FlightGear étant un simulateur internationale, il est rédigé en Anglais. À ma connaissance, la langue Anglaise ne contient pas d'accent (cela dit, je suis pas un grand lecteur de bouquin Anglais, donc je peux me tromper)
Pour ma part, je suis POUR le fait de garder cette "convention" que FG est international, que la langue international est l'anglais, qu'en anglais il n'y a pas d'accent, donc on n'écrit pas d'accent dans un xml donc on utilise <?xml version="1.0" encoding="UTF-8"?>
(Ceci n'est que mon avis...) Voir réponse de Guillaume

Pensez-vous qu'il est utile de continuer dans ce sens?

Je pense que c'est exactement ce qu'il faut ! C'est parfait ! On a donc la possibilité de récupérer tout ce qu'il nous faut pour appliquer ça à un modèle 3D dans Blender !
Prenons un exemple; l'objet "direction" :
- On sait que cet objet doit pouvoir faire une rotation
- On sait qu'il est relié à une propriété FG qui varie de -1 à 1
- On sait que son centre de rotation est situé à x, y, z du centre de dc-3.ac (c'est là que sera placé la bone si j'ai bien suivi)
- On a l'axe de rotation (C'est là que le Euler XYZ entre en jeu c'est bien ça ? )
- On sait que les limites de rotation sont : -1 x -25 et 1 x 25 soit -25° à 25° (On a plus qu'à appliquer la contrainte "limit_rotation" sur la bone)

C'est vraiment le top !
Juste une chose : pourquoi prendre en compte les <include> ? Moi je vois la chose comme ça :
Je veux travailler sur le fichier dc-3.ac, donc j'importe ce fichier dc-3.ac dans Blender, maintenant j'ouvre la fenêtre "FlightGear" et je renseigne le chemin du fichier XML qui correspond à ce fichier dc-3.ac. Donc l'utilisateur a la charge de :
- Renseigner le fichier 3D à ouvrir
- Renseigner le fichier XML à ouvrir

Le fichier XML contient tout ce qui concerne le fichier dc-3.ac, je n'ai pas besoin d'aller voir ce qui se passe dans les fichiers <include>, si je veux travailler sur le cockpit, et bien je recommence la manœuvre depuis le début : je dis à Blender quel fichier AC et quel fichier XML je veux charger. Qu'en dis-tu ?

Seul petite chose : si on fait du récursif ça permet de n'indiquer que le 1er XML (dc-3.xml) et après le script peut charger l'intégralité des <include> et <path> ainsi en chargeant un fichier XML, le script reconstitue l'appareil dans son intégralité... ça peut être une idée, mais j'ai souvenir que travailler sur un appareil complet n'est pas très facile, à moins d'utiliser les layers/groupes et mettre chaque fichier AC dans un groupe/layer pour pouvoir les afficher à souhait.

Souhaitez-vous l'utilisation d'une autre bibliothèque, ou bien écrire un parseur "from scratch" ??

Non, pourquoi réinventer la roue ? La bibliothèque existante semble parfaitement convenir.

Voulez-vous tester ce début de parseur ? Pensez-vous utile de l'uploader sur gitorious ?

Oui je veux tester
Pour faire simple : mets tout ce que tu peux sur gitorious ! La moindre modification, même si ton travail n'est pas fini, mets le sur gitorious. Ça permet de savoir qui a fait quoi, où on en est etc etc....

J'ai l'impression de "noyer le poisson" (amicalement) ! Ce sentiment est-il légitime ??

Moi ça va j'arrive à suivre, enfin je crois Garde ton rythme !
Moi j'ai l'impression que tu viens de faire une grosse partie du boulot en créant ce parser XML. Il ne reste plus qu'à créer une bone pour chaque animation rencontré, de faire un lien de parenté entre cette bone et l'objet qui doit subir l'animation, indiquer à la bone les contraintes la concernant (centre de rotation, axe de rotation, limite de rotation...) sachant que tu as déjà créer le script qui récupère les informations de contrainte situé dans les XML FlightGear.

Un truc qui serait super c'est de créer l'interface GUI "FlightGear" comme tu as commencé à le faire pour pouvoir faire varier les propriétés à l'aide de curseurs (pour les propriétés qui varie de -1 à 1 ou 0 à 1) et case à cocher (pour les propriétés booléan : 0 ou 1). Du coup quand on fait bouger les curseurs, et bien les objets bouge dans la vue 3D en direct live ! Et comme ça on peut voir si l'animation est bonne (l'objet entre-t-il en collision avec un autre pendant l'animation ?)
Tiens je viens de faire un montage Gimp pour montrer ce à quoi je pense :


Comme tu vois le curseur "ELEVATOR" est situé au milieu de la barre et sa valeur est 0 car la propriété "ELEVATOR" (surface-positions/elevator-pos-norm) varie de -1 à 1 donc quand on est au milieu on est à 0. Le curseur "LND GEARS" est lui aussi situé au milieu mais sa valeur n'est pas 0 mais 0.5 ! car la propriété "LND GEARS" varie de 0 à 1, on est donc bien à la moitié.

C'est réalisable ça ?

Pour en revenir au problème des propriétés différente entre Yasim et jsbSim : on sait que les propriétés situé dans /controls/flight/... sont communes à Yasim et jsbSim, cela dit, ces propriétés sont les propriétés "d'entrée". Tandis que les propriétés situé dans /surface-positions/..." sont les propriétés de "sortie". La différence est simple : Imaginons que mon rudder est abimé, il ne doit donc plus bouger, si j'enfonce mon palonnier à droite, la valeur /controls/flight/rudder va passer à 1, mais Yasim sait que mon rudder est abimé et qu'il ne peut plus fonctionner, la propriété /surface-positions/... va donc rester à 0, elle ne bougera pas.
Conclusion : je n'ai pas encore d'idée de "comment faire pour que Yasim et jsbSim soit compatible avec le script"... à moins d'avoir un dictionnaire jsbSim et un dictionnaire Yasim, l'utilisateur devra alors indiquer si son appareil est un Yasim ou un jsbSim ... qu'en dites vous ?

Amicalement,
Clément

F-JJTH a écrit:<?xml version="1.0" encoding="UTF-8"?> N'ACCEPTE PAS les caractères "Speciaux" : àâéèçêîôöï en clair, dès qu'on met un accent ou un truc un peu bizarre : ça marche pas
Si on veux écrire des caractères spéciaux il faut utiliser <?xml version="1.0" encoding="iso-8859-1"?> (Et même si c'est dans un commentaire xml ! )

C'est sans doute parce que ton fichier est réellement encodé en ISO-8859-1. Le codage UTF-8 supporte très bien les accents, il doit gérer beaucoup plus de caractères que l'autre d'ailleurs (tu peux aussi écrire plein d'alphabets non latins avec, je crois). Les caractères présents en ASCII (caractères latins non accentués) doivent être gérés partout à peu près de manière compatible (en UTF-8 au moins, ils sont codés exactement de la même manière qu'en ASCII), donc tant qu'il n'y a pas de caractères accentués, ça marche quelque soit le codage que tu mets en en-tête.

Bref, il faut que l'en-tête soit cohérent avec l'encodage réel du fichier.

Oui, il me semble ..

C'est certainement des modifications faites pas quelqu'un utilisant windows sur un fichier utf-8. C'est problèmatique car le parseur s'arrête pour ces fichiers.

Le parseur se trouve dans la branche master de fg2blender dans le répertoire tools

A ce propos, j'invite tout le monde à télécharger la dernière version de blender 2.63a.

Ah oui tu as raison Guillaume, j'avais oublié que l'entête du fichier ne faisait pas tout il y a aussi l'encodage du fichier en lui-même lors de l'enregistrement.
J'ai donc barré cette partie dans mon post précédent.

@René: effectivement, les fichiers qui étaient impacté par ce problème étaient les fichiers de tutorial du dc-3, ces fichiers ont été écrit par Alexis qui est sous Windows.
Alors les Windowsien : faites attention quand vous enregistrez un fichier XML

Oui, ce coup-ci c'est de ma faute, je vais résoudre ce problème d'enregistrement merdouillant dès demain.

Bonne nouvelle, je suis en vacances dès aujourd'hui, je vais avoir bien plus de temps à accorder à FG ! Je suis vraiment impressionné par le travail que tu as fait rené, c'est vraiment super !

Concernant ta petite interface Clément, blender est même capable de faire mieux, tu peux très facilement créer des petites "manettes", comme un marionnettiste, tu fait bouger tout ton modèle. Tu peux créer un manche virtuel.

En fait, on peut classer les animations en deux types, soit ce sont des mouvements simples (ailerons ect..) soit ce sont des cinématiques (rentrée de train, ouverture de verrière)

F-JJTH a écrit:- On sait que les limites de rotation sont : -1 x -25 et 1 x 25 soit -25° à 25° (On a plus qu'à appliquer la contrainte "limit_rotation" sur la bone)

Même plus et très facilement, insérer des keyframes, pour rendre l'animation visuelle.

F-JJTH a écrit:Juste une chose : pourquoi prendre en compte les <include> ? Moi je vois la chose comme ça :

Ça donne l'impression que j'insiste la dessus
Effectivement j'insiste , pour la raison suivante : je ne connais pas bien flightgear. (Vrai, mais fausse raison )
J'ai une petite idée derrière la tête, rendre l'ouverture de dc-3-set.xml avec l'affichage complet de l'avion. J'y ai réussi avec x-plane, il n'y a pas de raison que cela ne soit pas réalisable avec flightgear. Au moment de l'écriture il faut juste faire attention à utiliser des variables locales, pour rendre les scripts récursifs.
La bonne raison la voilà :
Cette façon de faire a aussi un avantage. Si on veux gérer les offsets, pitch-deg, roll-deg et heading-deg, le script doit remonter au fichier xml parent. Et cette fois la lecture récursive, sera un atout. Cette partie "offset" se fera plus tard, certes, mais il sera pénible de réécrire le parseur.

F-JJTH a écrit:Seul petite chose : si on fait du récursif ça permet de n'indiquer que le 1er XML (dc-3.xml) et après le script peut charger l'intégralité des <include> et <path> ainsi en chargeant un fichier XML, le script reconstitue l'appareil dans son intégralité... ça peut être une idée, mais j'ai souvenir que travailler sur un appareil complet n'est pas très facile, à moins d'utiliser les layers/groupes et mettre chaque fichier AC dans un groupe/layer pour pouvoir les afficher à souhait.

En fait c'est en regardant, les fichiers des tableaux de bord. On a souvent à faire à un répertoire par instrument. Avec un xml, un .ac et une texture. Je suis d'accords pour garder cette organisation. Pire lorsque les choses sont organisées je n'y touche pas. Mais blender permet d'afficher le tableau de bord complet sans risque de confusion. Chaque instrument a une place unique. Les armatures ne risquent pas de se chevaucher.
Mais pour lire ce type d'organisation, une lecture récursive de fichier xml est indispensable. Sans oublié la gestion des offsets etc.
Ce type de lecture sera un atout , j'en suis sur.

F-JJTH a écrit:
Un truc qui serait super c'est de créer l'interface GUI "FlightGear" comme tu as commencé à le faire pour pouvoir faire varier les propriétés à l'aide de curseurs (pour les propriétés qui varie de -1 à 1 ou 0 à 1) et case à cocher (pour les propriétés booléan : 0 ou 1). Du coup quand on fait bouger les curseurs, et bien les objets bouge dans la vue 3D en direct live ! Et comme ça on peut voir si l'animation est bonne (l'objet entre-t-il en collision avec un autre pendant l'animation ?)
Tiens je viens de faire un montage Gimp pour montrer ce à quoi je pense :


Comme tu vois le curseur "ELEVATOR" est situé au milieu de la barre et sa valeur est 0 car la propriété "ELEVATOR" (surface-positions/elevator-pos-norm) varie de -1 à 1 donc quand on est au milieu on est à 0. Le curseur "LND GEARS" est lui aussi situé au milieu mais sa valeur n'est pas 0 mais 0.5 ! car la propriété "LND GEARS" varie de 0 à 1, on est donc bien à la moitié.

C'est réalisable ça ?

Blender a une superbe interface, et oui, c'est possible. En faites les ascenseur sont abandonné depuis blender 2.5x. Maintenant on clic sur la valeur et on maintient. Puis le déplacement fait varier la valeur. Et pour la précision, à tout moment, on appui sur SHIFT. On peut rajouter des boutons aussi. Qui dit bouton, dit script, on peut faire ce que l'on veut.

F-JJTH a écrit:Pour en revenir au problème des propriétés différente entre Yasim et jsbSim : on sait que les propriétés situé dans /controls/flight/... sont communes à Yasim et jsbSim, cela dit, ces propriétés sont les propriétés "d'entrée". Tandis que les propriétés situé dans /surface-positions/..." sont les propriétés de "sortie". La différence est simple : Imaginons que mon rudder est abimé, il ne doit donc plus bouger, si j'enfonce mon palonnier à droite, la valeur /controls/flight/rudder va passer à 1, mais Yasim sait que mon rudder est abimé et qu'il ne peut plus fonctionner, la propriété /surface-positions/... va donc rester à 0, elle ne bougera pas.
Conclusion : je n'ai pas encore d'idée de "comment faire pour que Yasim et jsbSim soit compatible avec le script"... à moins d'avoir un dictionnaire jsbSim et un dictionnaire Yasim, l'utilisateur devra alors indiquer si son appareil est un Yasim ou un jsbSim ... qu'en dites vous ?

Cela a été une grosse surprise, lorsque j'ai affiché le fw190 de x-plane sur flightgear. Les propriétés (je ne me rappelle plus)
/controls/gear/brake-left
/controls/gear/brake-right
/controls/gear/brake-parking
/controls/gear/steering
/controls/gear/gear-down
/controls/gear/antiskid
/controls/gear/tailhook
/controls/gear/tailwheel-lock
/controls/gear/wheel[%d]/alternate-extension
ne fontionnaient pas. En décortiquant le fichier xml, j'ai finalement trouvé gear/gear[0]/position-norm. Qui était (si je ne me trompe pas) une propriété yasim.
Pour afficher cette avion j'avais modifier le fichier d'un avion simple. Et mon choix c'était porté sur "ogel" l'avion lego.

Alexis a écrit:Oui, ce coup-ci c'est de ma faute, je vais résoudre ce problème d'enregistrement merdouillant dès demain.

Pas spécialement, le script a parcouru l'ensemble du fgdata, et il n'y a malheureusement pas que les avions de la paf ...

L'import de fichier AC pour la version 2.63a semble ne pas fonctionner



@René: j'approuve à 200% ton idée que tu as derrière la tête Au final on ouvrira pas un fichier AC mais plutôt un fichier XML qui lui chargera le fichier AC et les autres fichiers AC et XML inclut. Ça serait génial !

Ah bah avec ce que tu viens de pushé ça le fait ! C'est magique ! Je clique sur "File > Import > FlightGear (.xml)" je choisi le fichier *-set.xml de l'avion, (c'est ce que fait FG d'ailleurs ! FG cherche en premier lieu ce fichier -set.xml) Et mon avion se charge. Pour l'instant j'ai pas mal d'erreurs, et tout n'est pas chargé, j'ai l'impression que le côté "récursif" n'est pas présent pour le moment, c'est bien ça ? Je viens de tester avec le P92 et tout fonctionne super bien ! Le récursif fonctionne au poil ! c'est fantastique ! Il ne reste plus qu'à implémenter les offsets car tout est placé au centre,c'est ça ? (je pose la question pour voir si je suis pas trop largué )



PS: si tu veux je suis sur Mumble

Désolé pour Mumble, j'ai juste le temps d'écrire ce post ....

En premier, le script d'import est à modifier. Le bug des uvs a été corrigé il y a une semaine, mais je crois que j'ai fait une bêtise sur le commit. En fait je crois que j'ai une "connerie" avec gitotrious. La commande suivante me renvoie ça:

Code:

rene@Poste-002:~/programmes/opengl/blender/paf/fg2blender$ git remote show origin
* remote origin
  Fetch URL: git://gitorious.org/paf/fg2blender
  Push  URL: git@gitorious.org:paf/fg2blender.git
  HEAD branch: master
  Remote branches:
    2.62  tracked
    2.63  tracked
    master tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local refs configured for 'git push':
    2.62  pushes to 2.62  (up to date)
    2.63  pushes to 2.63  (up to date)
    master pushes to master (up to date)
rene@Poste-002:~/programmes/opengl/blender/paf/fg2blender$


Lors de la création des branches 2.62 et 2.63 j'ai fait une git push 2.62 au lieu de git push origin 2.62. On peut voir que le HEAD est perdu.
Je suis désolé.

Le script d'import des fichiers .ac, pose aussi un problème au niveau des répertoires. Ce sera la prochaine modification avant la suite.
J'ai réfléchi cet après-midi à l'organisation des fichiers.
Je vais certainement revoir leurs nom :
ac_import.py
ac_export.py
xlm_import.py
xlm_export.py
mais aussi :
ac_manager.py
xml_manager.py

La création des objets de blender se fera dans les fichiers ac_manager et xml_manager.

Pourquoi ce manager ??
Parce que certains fichiers xml subissent plusieurs inclusions à différents offset. Pour l'instant l'import est "brutos", il y a des doublons.
Mais blender permet du dupliquer des objets identiques, le "manager" s'occupera de cela.
C'est à peine le début. Et je n'arrête pas penser, aussi, au langage. Je m'explique : le rendre multi-langues. Comme je te l'ai dit revenir en arrière est souvent compliqué. Il vaut mieux réfléchir à la façon d'implémenter cela.

Je pense à un truc du genre:

Code:


FileError = { 'fr' : 'Erreur sur fichier', 'en' : 'File error' }


lang = 'fr'

print( FileError[lang] )


On doit même pouvoir extraire la locale du système pour renseigner une variable global (Il faudra regarder la doc python, pour voir les différences mac, windows, linux )
A+

_run_ a écrit:
Le script d'import des fichiers .ac, pose aussi un problème au niveau des répertoires. Ce sera la prochaine modification avant la suite.
J'ai réfléchi cet après-midi à l'organisation des fichiers.
Je vais certainement revoir leurs nom :
ac_import.py
ac_export.py
xlm_import.py
xlm_export.py
mais aussi :
ac_manager.py
xml_manager.py

Ça me parait une très bonne modification, avec ces noms de fichier c'est bien plus clair

J'ai voulu voir comment il était possible de prendre en compte les offsets lors de l'importation des différents fichiers AC. Je n'ai pas réussi à écrire la moindre ligne de python mais j'y ai réfléchi, c'est déjà ça. Alors dis moi si mon raisonnement est bon :
On importe le fichier AC que l'on met immédiatement dans un "groupe" (le nom du groupe pourrait être le nom du fichier AC) puis on déplace le groupe tout entier aux coordonnées x,y,z renseigné par l'offset.

Si le raisonnement est bon... c'est déjà une victoire pour moi C'est que je commence à cerné comment il faut "réfléchir" avec Blender. Après il faut traduire ça en langage python. Ça pourrait donner ça :

Code:


ac_read(filename)  # On importe le fichier ac
bpy.ops.object.select_??? # ici il faut sélectionner tout les objets qu'on vient d'importer avec la fonction ac_read(), mais comment faire ? Il faut faire attention à ne pas sélectionné les objets déjà importé et placé. Il faut vraiment sélectionner uniquement les objets du fichier AC qu'on vient juste d'importer.
bpy.ops.group.create(name="nom_du_fichier_ac") # On créer le groupe avec comme nom, le nom du fichier ac, tout ce qui est actuellement sélectionné est automatiquement ajouté à ce groupe
bpy.ops.object.select_all(action="DESELECT") # On désélectionne tout et on passe au fichier ac suivant


Alors verdict ?

Verdict !!
C'est un bon début

Pour la doc blender, il y a deux endroits pour les données de blender. Pour les groups par exemples:

Description de :bpy.data.groups
http://www.blender.org/documentation/blender_python_api_2_63_11/bpy.types.BlendData.html#bpy.types.BlendData
Là tu y trouves

Code:

groups
    Group datablocks
    Type :   BlendDataGroups bpy_prop_collection of Group, (readonly)

Première découverte , c'est une liste (au sens python)
et ici il y a deux liens BlendDataGroups et Group
BlendDataGroups : Ce sont les fonctions associés à bpy.data.groups
Group : Ce sont les propriétés de bpy.data.group['group]

Dans BlendDataGroups tu trouves la fonction new.

Donc on écrit :
bpy.data.groups.new( name="dc-3.ac")
et maintenant tu peux modifier ses propriétés par exemple
bpy.data.groups['dc-3.ac'].objects.append( bpy.data.objects['Cube']) (*** j'ai jamais essayé pas sur que ça fonctionne ** de toue façon il y a toujours une solution)
Explication:
Dans la doc, bpy.data.groups['dc-3.ac'].objects, est une liste au sens python d'objet blender. Donc la fonction append des listes python.
Les objets blender sont disponibles par bpy.data.objects. Donc bpy.data.objects['Cude'] est l'objet blender 'Cube'



En ce moment, avant de reprendre le codage, je réfléchi. Car il faudra créer des objets intermédiaires (au sens programmation orienté objet). Le script d'import fait déjà cela avec deux objet intermédiaire, MESH() et MATERIAL()
Ici il en faudra d'autre. Mais surtout, ce que je ne veux pas , c'est des bpy.data.blabla, partout dans tous les fichiers. Dans ce cas le script deviendra ingérable. D'ou l'idée de ac_manager.py et xml_manager.py, C'est deux fichiers feront l'interface entre blender et le parseur xml, et l'import .ac. Mais aussi l'export. Déjà il faudra réécrire import_ac.py. Il communiqueront avec des objets intermédiaire MESH(), MATERIAL() et des nouveaux.
Et seul les fichiers xml_manager.py ac_manager.py contiendront des fonctions spécifiques à blender.

Attention la liason avec l'interface de blender se sera encore d'autre fichier.
Genre anim_ui.py , anim_props.py fournies sur le forum.


Tu as pressenti que l'objet intermédiaire contiendra une liste de mesh contenu dans le fichier .ac. Mais aussi un autre objet qui contiendra l'offset, le pitchdeg, roll-deg, converti en matrice issue du .xml. Etc ...
Maintenant le script a besoin d'un bonne dose de réflexion.

A+



[Edit]

Je viens de faire le test suivant
bpy.data.groups.new( 'dc-3.ac' )
obj = bpy.data.objects[ 'Cube' ]
obj.select = True
bpy.context.scene.objects.active = obj
bpy.ops.object.group_link( group='dc-3.ac')

Cela rajoute le l'objet 'Cube' créé précédemment au nouveau groupe 'dc-3.ac'



Je le fait de cette manière car j'ai l'impression que les fonctions de sélection de blender font un "memory leak" une fuite mémoire.
Les fonctions bpy.ops.object.select_pattern( pattern='Cube' ) et autre .. font un message d'erreur en quittant blender un bug à remonter d'ailleur.
dans la console j'ai

Code:

Saved session recovery to /tmp/quit.blend
Error: Not freed memory blocks: 1
wmOperatorReportList len: 40 0x7f87091160b8


Salut,
Alors tout d'abord, pour les soucis d'encodage, j'ai installé la dernière version de notepad (6.1.3), et je vous montre ce qui est présent par défaut dans le menu encodage :



Et pour ce qui est du script python, s'était à prévoir, marche pas avec windows. Les fichiers sont introuvables à cause des chemins ( avec des "/" et les "\" un peu partout)
Voilà ce que j'ai en console :

Merci Alexis de me remonter l'info .....
Je m'endoutais ...
J'avais la conversion pour la lecture de base mais pas pour les fichiers inclus. Aussi bien pour les fichier .ac que les les fichiers inclus .xml

Je suis dessus , et bientôt je vais pusher une version qui gera mieux les inclusions. Et aussi les conversions des chemins
Tu peux noter que la conversion à déjà commencer: Aircraft\Douglas-Dc3\Aircraf/Douglas-Dc3

A+ ... je vous tiens au courant ..

@Alexis

Je travaille sous la dernière version de blender 2.63a
Télécharge là !!

Pourrais-t-on se donner rendez-vous sur mumble ?? ...... ce soir par exemple ???
Je crois qu'il serai bien de faire le point !!!

Je suis sur Mumble, il est 20h45, je reste pas longtemps... au plus tard 21h30

Je ne vois le message que maintenant :/
Je serais dispo demain une bonne partie de la journée

J'ai pusher une nouvelle version, qui lit les offsets. Le script me déplait énormément sur la gestion des offsets. Je n'avais pas penser qu'un fichier inclu avec offset pouvait être inclu par un autre fichier possédant aussi un offset. C'est à revoir.
Pour les chemins windows , comme je n'ai plus de windows chez moi, je ne peux pas faire de tests malheureusement. J'ai déjà modifié des choses. Donc a tester et à remonter.