Script flightgear

Bonjour tout le monde,

Après un mois de Septembre chargé, je n'ai plus rien fait sur le script ...

J'aimerai que l'on commence la conversion du mc 202 et par la même occasion finaliser le script. Je viens de voir sur blender.org, que blender viens de passer en 2.64. Je vais faire le test du script , et je vous tiens au courant.

A+

Bonjour,

Je viens de faire un simple test d'import du Cap10, et le script a l'air de fonctionner avec la version 2.64 de blender.

Voici le lien pour télécharger la nouvelle version
http://www.blender.org/download/get-blender/


A+

Cool !
J'ai entendu dire que le script import/export de mr_no ne fonctionnait plus avec Blender 2.64
J'aurai plus de temps la semaine prochaine concernant la conversion du mc202, mais rien n'empêche de commencer au moins à faire une todolist.

Amicalement,
Clément

Bonjour tout le monde,

J'aimerai savoir si quelqu'un utilise le script,si cela vaut le coup de continuer. Je me rappelle que clement et alexis , avaient commencé un tutoriel. Après une pose, je suis partant , pour finir les choses, et publier une version bêta ...

Je n'ai rien fait depuis quelques mois, mais je suis motivé pour finir le script.
Je me rappelle qu'une animation de moteur, avait montré que ce script était sur la bonne voie, qu'il rendait la création d'animation plus "intuitive".

Cet arrêt du développement, semble à priori préjudiciable, (il l'est forcement) mais il me permettra de remettre de l'ordre dans le code. Il y a forcement beaucoup de chose écrite trop vite. (refactorisation du code)

Tenez moi au courant...

Amicalement et bons vols .. René

Bonjour René,

Évidement que cela vaut le coup de continuer , l'import par xml c'est royal.

Par contre, l'export fait cruellement défaut .

Merci patten, de ta réponse ...

Pour l'export, il y a déjà beaucoup de parties écrites. Par contre tout ce passe dans l'onglet "flightgear", et si mes souvenirs sont bons et pas du tout intuitif. La dernière chose que j'avais fait, c'était de tenir compte du centre de gravité, pour appliquer les transformations (rotations) de l'avion. Mais encore une fois, ce n'est pas évident de trouver la façon de s'en servir.

Un état des lieux serait un bon préambule, à la poursuite des travaux .....

A+

Bonjour à tous,

J'ai installé Blender 2.66 depuis le dépôt svn (comme ça je pourrais être à jour tous les jours)
J'ai appliqué ça : https://equipe-flightgear.forumactif.com/t997-parametrage-de-blender
J'ai cloné le dépôt fg2blender de la PAF et ajouté l'addon à Blender sans soucis

Seul petit bémol, dans Blender User Preference > onglet "System" > partie "Compute Device" (en bas à gauche) j'ai "None" et pour seul choix "CPU" alors qu'avant j'avais "None" "CUDA" "OpenCL" et ma carte graphique était reconnu... j'espère que ça n'aura pas trop d'impact sur les performances. (J'ai sans doute oublié un argument dans le make à la compilation...)

Tout ça pour dire que je suis prêt à remettre les mains dedans.

Bon j'ai déjà fais l'inventaire des docs existante :
- https://equipe-flightgear.forumactif.com/t1019-script-d-animation-blender (COMPLETEMENT OBSOLETE)
- http://wiki.flightgear.org/Fr/fg2blender ( c'est plus une description qu'un tuto, hors on a besoin d'un tuto pour apprendre à se servir de quelque chose )

Dommage que mon tuto soit obsolète, en le relisant je le trouvais pas trop mal, le fait de faire plusieurs chapitres permettait de voir les choses une à une. Aussi en rédigeant un tuto je pense que l'on se rendra compte des choses difficiles à faire (accessibilité/logique) tout ce qui est difficile à expliquer/montrer à l'écrit est donc quelques choses de trop compliqué/illogique aux yeux d'un utilisateur.

On sait que le script fait déjà beaucoup de chose, on pourrait en faire une liste, avec cette liste on prend chaque point de la liste et on en fait un chapitre dans un tuto. Au fur et à mesure de la rédaction du tuto, si on se rend compte de bug/problème d'accessibilité/simplicité/logique on les corrige, afin de continuer l'élaboration du tuto.

une fois cette tache accomplie (ça va déjà être beaucoup) on pourra voir pour ajouter d'autre fonctionnalité (certaines ont déjà été ajouté à titre d'exemple (textOSG, lumière Rembrandt...)) mais c'est dans un deuxième temps je pense.


Je commence la liste, René, libre à toi de compléter :

Features a écrit:
1) Import simple .XML / .AC
2) Import récursif XML / .AC
3) Interprétation / rendu d'animation
4) Création d'animation
5) Export d'animation .XML
6) Export AC3D .AC
7) Lire les textOSG

1) et 2) : Ces features sont à ma connaissance 100% fonctionnelle
3) : Je me souviens qu'il y avait des soucis "d'origine du centre" de l'animation, est-ce résolu ? à ma connaissance il n'y a pas de bug. Mais je pense qu'il faut faire encore des test
4) : L'exemple du(des) piston(s) était concluant. Est-ce que l'export faire FG fonctionnait ? Je me souviens qu'on avait des soucis de timeline linéaire... on en était où ?
5) : Hormis le fait que l'on écrit pas encore de fichier .XML sur le disque dur de l'utilisateur, je crois que tout est fonctionnel sur ce point
6) : On avait fait un gros pas en avant en prenant en compte le nom des objets du .AC, celà dit on avait du mal à réimporter un modèle je crois
7) : La lecture était fonctionnel, mais il manque la prise en compte de la couleur du texte si j'ai bon souvenir

Je pense qu'il faut se pencher sur les points 4) 5) et 6), sachant que le point 5) devrait être une simple vérification de bon fonctionnement (espérons que ça fonctionne correctement sans modification )

À vous les studios !

Amicalement,
Clément
Je dirai qu'il faut donc se concentrer sur l'export XML

Bonjour, tout le monde ....

Désolé de n'avoir rien fait ce week-end , contrairement à ce que je t'avais dit. Mais je n'était pas chez moi.

C'est une très bonne idée que ton état des lieux.
pour les points 1,2,3,4,7 tu as raisons.

Pour l'export, je n'avait rien dit mais c'est déjà opérationnel. Par contre son utilisation n'est pas intuitif, en faites comme je l'ai souvent dit , je n'aime pas la façon dont j'ai écrit ça. L'export n'est pas dans le menu ("flightgear") mais utilise l'onglet flightgear. J'ai fait cela pour pouvoir faire des sauvegardes que sur un fichier sélectionné, et non pas sur l'ensemble de l'avion.

Mauvaise nouvelle .....
Blender 266 et le script pose problème. Un paramètre de texture a changé dans l'api blender. Il faut que je regarde, je ne pense pas que cela soit très grave, mais je vais modifier cela.


Il va falloir que je remettes à jour pas mal de truc aussi.

Je vous tiens au courant
A++
P.S. est-ce que le script de clement download_and_compile est toujours opérationnel pour remettre à jour mon flightgear ???

_run_ a écrit:P.S. est-ce que le script de clement download_and_compile est toujours opérationnel pour remettre à jour mon flightgear ???

Oui oui : http://clemaez.fr/flightgear/download_and_compile.sh

J'espère que tu n'auras pas trop de soucis à adapter le code pour la 2.66

F-JJTH a écrit:Seul petit bémol, dans Blender User Preference > onglet "System" > partie "Compute Device" (en bas à gauche) j'ai "None" et pour seul choix "CPU" alors qu'avant j'avais "None" "CUDA" "OpenCL" et ma carte graphique était reconnu... j'espère que ça n'aura pas trop d'impact sur les performances. (J'ai sans doute oublié un argument dans le make à la compilation...)

Télécharge la version binaire du site blender.org, je n'utilise que cette version, en pensant qu'un utilisateur aura tendance à choisir cette dernière.
http://www.blender.org/download/get-blender/

Pour cette version CUDA est actif chez moi ....

Avec la version 2.66
En commentant deux lignes du script , j'arrive à charger un avion complet. Pour l'instant je n'ai que des vieilles versions d'avions. Je télécharge le nouveau fgdata(c'est long 20% depuis 16h), et je ferai un test sur IAR80.
Si tu veux faire le test, il faut commenter les lignes qui modifie la propriétés use_alpha.
xml_manager.py:872 tex.use_map_alpha = True
ac_manager.py:507 tex.use.alpha = True


Il y a beaucoup de message d'erreur, mais cela n'empêche pas le script de fonctionner. Je vais regarder de plus près ces messages.

_run_ a écrit:Je télécharge le nouveau fgdata(c'est long 20% depuis 16h), et je ferai un test sur IAR80.

Malheureusement l'IAR80 ne fait plus parti du FGDATA... i4dnf (l'auteur) s'est retiré du projet après un désaccord et a souhaité récupérer son travail. Cela dit il est toujours dispo ici : http://gitorious.org/iar80

Je vais commenter les lignes qui posent problème et commencer à ré-étudier

Bonjour,

J'ai mis sur le git la nouvelle version du script, qui corrige les petits soucis dû a la mise à jour de blender.
Je vais préparer une doc sur les objets/données du script pour pouvoir s'y retrouver.

Je me suis aperçu qu'il y avait beaucoup de chose dans le script. Qu'il contient beaucoup de fonctions. Par exemple le placement d'une camera, dans blender reviens à créer un point de vue sur l'avion dans le fichier xml (jsbsim) , intéressant. Les coordonnées des points peuvent être modifier en plaçant un objet "empty" dans blender avec comme nom "CG". Ce dernier point deviendra le point zéro des coordonnées, et donc l'avion pourra tourné autour de son centre de gravité, ce qui est quand même le minimum pour un simulateur. Il en résulte que tous les points des fichiers .ac seront modifiés dans le nouveau système de coordonnées ...


A+

Je viens de jeter un œil à ton commit, et je vois que toi non plus tu n'as pas trouvé mieux que de conditionner le "use_alpha". Le soucis c'est que dans Blender on ne peut plus voir les objets transparents dans ce cas, tout est opaque désormais.
Il nous faut donc modifier le "material" de l'objet pour lui mettre une valeur alpha=xxx ?

Si tu es dispo ce soir pour un petit cours sur le bpy en direct sur Mumble je suis preneur

Re,

L'affichage des textures est correct, regarde plus du côté du paramétrage de blender.
https://equipe-flightgear.forumactif.com/t997-parametrage-de-blender
Regarde le mode d'affichage, et le "Shading" glsl.
C'est plutôt de ce côté le problème.


Ok, pour ce soir, tiens moi au courant pour l'heure.

A+
P.S, le cap10 est un modèle entouré par un halo. J'ai cru au début que le script se mélangeait les pinceaux. En fait en désactivant les objets "lights", l'affichage à l'air correct (par exemple)

Et bien je suis dispo maintenant, (je suis sur mumble) sinon pour 21h ça te va ?

Desole pour tout de suite je suis pas chez moi. Ce soir21h c est bon......
A+

Je suis sur le serveur jeuxlinux.org

Bon j'ai passé plusieurs heures sur le script sans écrire quoique ce soit de définitf... que des print("test") et autre truc inutile sauf à la compréhension. Cependant j'ai pu cerner le problème avec exactitude.
Tu avais raison c'est bien un soucis de chemin. Il faut donc harmoniser la gestion des chemins. Soit on fait tout en relatif, soit on fait tout en absolu. Actuellement les chemins "ac_file" sont en absolu alors que les chemins "xml_file" sont en relatif, du coup lors de l'écriture du XML on a effectivement des soucis de ../../../Aircraft....

Malheureusement je n'ai pas été foutu de trouver la solution :/

J'ai repérer où était "calculé" le chemin de <path> mais je pense qu'il faut résoudre le soucis à la base, c'est à dire harmoniser la gestion des chemins. Mon opinion se tourne vers le "tout relatif" qui me semble être le plus "portable" (plusieurs utilisateurs pourront travailler sur le même projet sans se soucier de "oh mais c'est claude qui a ouvert le fichier du coup il faut que je change tout les chemins pour que ça fasse référence à moi, Vincent"

Salut Clément,

J'ai commencé à écrire la doc sur les données internes du script, mais je n'ai pas cherché à résoudre le problème d'hier.
Par contre j'ai commencé à réfléchir, sur les différentes situations, et cela va être complexe.

Par exemple :
Je commence de zéro un avion, j'ouvre blender, et je commence ma modélisation. Tout ce passe bien (hypothèse). J'exporte.
Un autre jour je montre mon travail à quelqu'un , je lui envoi le fichier. Rien ne fonctionne les chemins sont différents (le cas hier).
Déjà ici il y deux cas, je travaille sois avec le fichier blend, ou avec les fichiers de flightgear xml et .ac
Mais il y a plein d'autre cas.
Je transfère l'avion sur le fgdata, et je m'aperçois qu'il y a une légère retouche à faire. Je veux faire la retouche uniquement dans l'avion du fgdata. je pense que là aussi le script se mélange les pinceaux. Il y aurait le même cas dans une réorganisation de répertoire (Ca m'arrive de temps en temps lorsque l'arborescence ne me plaît pas, blender supporte ce genre de manip mais pas le script )
Et après il y a tout les cas d'échange de fichiers et de système d'exploitation, le script devra passer toutes ces épreuves (remplacement de "/" par "\" , etc...).
Et après les références à des fichiers externes à l'avion.

Il faudra bien mettre à plat, les différents cas, et la solution viendra d'elle même.
Python et blender ont des puissants utilitaires pour résoudre ce problème.

Ca me plaît , je crois que l'on tient le bon bout.

A+

René,

Je suis sur Mumble si t'es dispo

EDIT: suis-je bête... Mumble ne fonctionne pas pour toi, GTalk

J'arrive si ça fonctionne

Bonjour,

Je viens de réfléchir encore à des possibilité que le script devra gérer. Mais qui ne sont pas encore implémenté.
Je veux travailler sur une partie de l'avion et son chargement complet est long. Je charge uniquement deux ou trois fichier xml, par exemple dans le mc202, je charge empennage.xml et trains.xml. La création des animations peut dupliqué certaines animations, si je fais import xml et creation animations pour le premier fichier. Puis je recommence la même manipulation avec le deuxième fichier.

J'ai écrit un outil pour si retrouver.
Je l'ai associé a un raccourci clavier de blender Ctrl-X
Ces fonctions écrivent sur le disque, toutes les données internes du script. A partir de la liste xml_files.
Puis toutes les données de blender créer par le script .
Ce n'est pas encore éxaustif, loin de là.
La définition du raccourci clavier est dans le fichier ui_shotcut.py.
La fonction éxécuté est dans ui_menu.py. Il s'agit de la classe class FG_OT_exec2
Encore une fois se sont des informations de débugage.


Les fichiers de debuggage ne sont plus dans le home mais dans /tmp juste après la racine. Nous n'avons pas de soucis d'utilisateur comme cela.

Re,

J'ai trouvé une variable blender qui contient le nom du fichier .blend, lorsque celui-si est sauvé.
bpy.data.filepath
Si il n'y a pas eu de sauvegarde blender, alors cette variable est un string vide ""

Comme je te l'ai dit sur mumble, je propose la création d'une classe qui fera les manipulations de chemin, pour l'écriture des fichiers.

Je vois quelque chose comme cela.
par exemple La propriété bpy.objects[0].data.fg.xml_file sera ecrite de deux manieres.

Lorsque l'on importe un fichier xml en partant de zero. Cete propriété contient le nom absolu du fichier ex: /home/tartenpion/fg_data/aricraft.je_ne_sais_quoi.xml
Lorsque que l'on exporte. Il faut écrire des fonctions qui convertissent les chemins absolu en chemin relatif.
Dans ce cas il ne devrais pas y avoir de probleme

Maintenant on fait une sauvegarde du fichier .blend
j'ai trouve une fonction callback bpy.app.handlers.save_pre (voir la doc)
On doit pouvoir faire quelque chose juste avant la sauvegarde
On modifie toutes les propriété fg.xml_file de tous les objets pour avoir cette fois des noms relatif par rapport au fichier .blend
A l'export suivant
Les fonctions de conversions détectent un changement dans la variable bpy.data.filepath, et elle peuvent savoir que les chemins ne sont pas en absolu mais en relatif par rapport au fichier blender, et mener à bien leur conversion.

Il faudra modifier toutes les fonctions d'import écrivant les propriété fg.xml_file pour utiliser les fonctions de la nouvelle classe. Et toutes les fonctions de l'export écrivant les noms de fichier.
Actuellement ce sont les fonctions d'import et d'export qui font les conversions et souvent de manière différente. De cette manière aussi, les conversions seront partout les mêmes et regroupé dans une classe. C'est plus portable et plus maintenable.

Je ne sais pas si je suis clair .... tient moi au courant si tu ne comprends pas certaines choses.

Je vois un avantage à cela, c'est de pouvoirr s'échanger des fichier blender aussi

J'ai bien compris l'enjeu mais je suis incapable de coder une telle classe :/ Je te laisse donc faire, j'espère que tu ne m'en voudra pas.

Par contre je viens de voir que les animations sont encore un problème à l'import et à l'export. Par exemple :

- Lance FG avec le MC202 d'origine (celui que tu m'as envoyé)
- Met toi en l'air (Ctrl+u) et regarde le train d'atterrissage de plus près, tu constatera que le vérin qui pousse/tire le train pour le rentrer/sortir est littéralement en train de pendre le long du train d'atterrissage
- Maintenant rentre le train (g) et tu verra que le vérin est purement et simplement non animé
- Ouvre Blender, importe le mc202-set.xml, crée les animations, positionne toi de façon à voir le train et lance l'animation, le train s'ouvre et surprise ! le vérin est animé !! Bon déjà première surprise, le script permet de lire des animation FG que même FG n'arrive pas à lire ^^
- Mais c'est pas fini ! Maintenant tu stop les animations, tu sélectionne une armature du train, tu vas dans "FlightGear animation" tu as donc "Write file" qui est rempli, tu coche "To disc" puis clic sur "Write file" (là tu vas me dire "Mais quel interêt d'écrire le fichier XML vu que j'ai rien modifier !" c'est vrai... mais fais le quand même)
- Retourne dans FG, si tu l'avais arrêté relance le, sinon réouvre le train (Shift+g) puis Debug > Reload aircraft model
- Et là seconde surprise : le vérin ne pend plus le long du train et les triangles au niveau du fourreau d'amortisseur sont malade
- Rentre le train (g) et là le vérin est animé alors que je n'ai fait aucune modif dans Blender je n'ai fais que "Write file" il est donc censé écrire la même chose que ce qui était écrit.
- Continuons dans les surprises retourne dans Blender, quitte Blender puis réouvre le, réimporte le mc202-set.xml, créer les animations, lance les animations : c'est du grand n'importe quoi ! l'animation ne correspond même pas à l'animation qu'il y a dans FG.

Tout ceci alors que je n'ai rien modifier !

Bon ben... y'a du boulot !!!

Amicalement,
Clément

Ne t'inquiete pas , j'ai modifier pas mal chose et cela devrait rentrer dans l'ordre.
Je n'ai pas fait par exemple de test lors de la modification des centres c'est peut-etre cela ... le probleme
Il y adeux trois ligne a modifier

je regarde