Script flightgear

je pense effectivement que ce genre de chose peut être ajouté à la main. Après, vu comment rené me donne plein d'idée de programmation et que c'est finalement pas si compliqué d'ajouter des fonctions au script, je serais peut-être capable d'ajouter ça un de ces jours

A propos des conditions, je ne sais ce que l'on peut faire pour l'instant. Et puis il y a déjà assez de boulot
Par contre je sais que blender , a une nouvelle approche pour le gestion des matériaux, en utilisant le "Node Editor" de blender. Cette nouvelle approche est utilisé avec le nouveau moteur de rendu "cycle"
On obtient quelque chose dans ce genre



On peut voir que c'était déjà présent dans blender 2.49.
Je ne sais pas pourquoi, mais je trouve que cette représentation graphique à quelque chose d'intéressant. Je ne sais pas du tout comment utiliser cela dans un script ( pour l'instant ) et si l'on peut créer ses propres nodes. Je verrai bien un node <greater-than-equals> un autre <less-than> un autre avec la propriété, etc... et on les brancheraient, cela donnera l'utilisation logique des conditions. Je ne sais pas ....

En tout cas pour l'instant, je ne les gèrent pas !

Une petite video sur l'utilisation du script

https://vimeo.com/45724874

La HD n'a pas fonctionné , je vais voir demain si je peux l'uploader sur youtube en HD

Il a réponse à tout lol

je connais un peu ces nodes ça joue sur les matériaux, mais ça permet aussi d'obtenir des rendu sympa comme des flou d'arrière plan, différents effets de vitesse, ça facilite les insertions dans des vidéos/images d'éléments 3D ... Tous les autres logiciels proprio utilisés par les grands studios d'animations utilisent ces systèmes, preuve que blender reste à la pointe de la pointe ! Mais c'est très orienté rendu image j'ai l'impression (je connais très peu) ça serai cool de pouvoir le détourner pour des utilisations différentes, mais est-ce possible, je ne sais pas.

_run_ a écrit:Une petite video sur l'utilisation du script

https://vimeo.com/45724874

J'arrête pas de le dire, mais c'est trop génial

_run_ a écrit:Une petite video sur l'utilisation du script

Super demo!
Je m'aperçois que je ne connais que 2% des possibilités de blender

Amicalement.

Bonjour tout le monde,


L'export avance doucement mais sûrement. J'ai une question à propos sur FG_ROOT. Est-ce une variable système déclarer sur tout les OS. Puis-je m'en servir pour fabriquer les chemins de fichiers inclus, issu d'un autre avion. Par exemple certains avions font référence à certains fichier contenu dans Aircraft/generic. Ce FG_ROOT est défini dans fg_run, mais cela le rend local au context d'execution de fg_run.. ?

A+

P.S. La correction d'Alexis plus la prise en compte du "<offset-deg>", rend l'import du DR400, à priori sans erreur. Si c'est le cas , c'est plutôt bon signe...

Salut René,
Je te fais une réponse simple et rapide depuis mon smartphone, dès que possible et si besoin je completerai ma réponse.

Sous linux, tu peux trouver la valeur du fg-root de fgrun dans le dossier: ~/.fltk.org/fgrun/prefs.conf (de tête ... ca doit etre presque juste)

Amicamement,
Clément

Oui mais c'est un paramètre de fgrun qu'on peut ne pas avoir configuré. $FG_ROOT n'est en général pas déclaré non plus. Pourquoi ne pas le demander dans l'interface du script?

On ne va pas avoir le choix

Salut,
J’essaie de faire fonctionner la partie export, et paf :

J'ai seulement importé le DR-400, j'ai sélectionné le manche, puis F > ecrit xml

Sinon, si tu te souviens bien, j'avais eu l'idée de créer une nouvelle un nouveau mode de sélection dans l'outliner. Pour ceux qui ne connaissent pas, l'outliner s'ouvre de la manière suivante :


et c'est cette fenêtre :


Vous pouvez grâce à cette arborescence, sélectionner ou non certains éléments, les afficher/masquer ect...
Prenons un exemple, passer en mode groups :

Sélectionnez 1 seul élément puis ctrl+I pour inverser la sélection, puis h pour tout masquer. Maintenant, vous pouvez afficher ou non les objets en cliquant sur l’œil :


Voilà, tout ça pour vous dire que j'aimerais ajouter un mode propriété, celui-ci contiendrait une liste de l'ensemble des propriétés utilisées et on pourrait alors afficher seulement les objets concernés par la propriété et ainsi travailler efficacement sur une animation. Bon j'ai creuser un peu le truc, et ... je vais encore creuser

Je pense aussi à un bouton dans le panneau FlightGear, qui afficherait tout les objets de l'animation, pour éviter de fait F -> Select property puis ctrl+I puis h. Là je pense en être capable

Bon tout ça est assez accessoire à côté du boulot qu'il y a à faire, mais tout un tas d'outils facilitant la vie de l'utilisateur serait plutôt cool

Bonjour,


Cela ne va pas être simple, car je suis certain que certains avions font des références "arrières", par exemple : une fichier xml faisant référence à un autre xml mais dans un répertoire plus prêt du $FG_ROOT.
Normalement, par exemple, le cockpit se trouve soit dans le même répertoire que l'avion ou bien dans un sous répertoire. En général on ne fait que descendre dans l'arborescence. Mais je suis certain qu'il y aura des exceptions.

Indiqué ce chemin au script, cela va être une obligation. Mais le renseigner systématiquement au démarrage, cela sera énervant à la longue. (moi le premier).
Un ajout sur une ligne de commande : export FG_ROOT="repertoire";blender ne me plaît pas. Même si je trouve cette solution la plus simple et celle que je choisirais pour moi, je sais, que cette solution n'est pas du goût générale. La ligne de commande rebute vraiment certaines personnes, et je pense qu'il ne faut pas l'imposer.
Je ne voit plus qu'un fichier de configuration créé et lu par le script. On renseigne ce chemin une fois puis il le sauvegarde dans un fichier.
Ou alors le mettre dans les options de l'import. Les options de l'import sont "mémorisables" par blender par l'intermédiaire des "PRESET"

---------------------------------------------

Une nouvelle version du script, permet de récupérer, les valeurs <axis> <center> <property> etc.... On peut commencer à faire des tests avec flightgear. Pour vérifier les valeurs du script.
Pour l'instant , il y a une obligation, c'est de travailler sans offset et sans rotations dans les fichiers xml.

A+

Excellente idée Alexis !
Effectivement c'est plein de petit outils, qui, mis bout à bout, feront de ce script un réel outils efficace pour FG.

Par contre une documentation claire et précise est à prévoir ! Avec des exemples. Des tuto vidéos seront les bienvenues je pense. Mais pour le moment c'est en développement donc il faut attendre pour ça.

Amicalement,
Clément

Alexis a écrit:Bon tout ça est assez accessoire à côté du boulot qu'il y a à faire, mais tout un tas d'outils facilitant la vie de l'utilisateur serait plutôt cool

Pas du tout Alexis. Ce n'est pas accessoire. C'est typiquement le genre de chose qui font la différence entre un script utile, et un script pour le plaisir. Rendre ce script utile, passe par l'ajout de telle fonctionnalité. C'est pour cela que je vous ai contacté des le début.

Alexis a écrit:Salut,
J’essaie de faire fonctionner la partie export, et paf :

Lol, Je ne me rappelai plus que j'avais laissé ce menu. Il ne faut pas l'utiliser..lol

Dans le panneau flightgear de l'armature. Il y a maintenant un bouton "write file' sous le fichier xml. Ce bouton permet l'export du fichier. L'export se trouve dans l'editeur de texte de blender. Le fichier change de nom : par exemple vsi.xml devient vsi.xml.script. Ce bouton exporte toutes les animations du fichier. Puis il faudra faire un copier-coller vers le vrai fichier xml. Il y aura obligatoirement des erreurs, et je ne veux pas endommager le fichier original.

Je vais uploader une vidéo, pour vous montrer comment utiliser le script pour l'instant.

A+


mdr ... décidément on est des spécialistes de posts croisés

Salut,
Ok, merci pour les indications, je ferais des essais dans la soirée !

Mais j'ai quelques questions rené, j'aimerais savoir comment pense-tu gérer les arborescences de fichier à l'avenir pour ce qui est de l'export ? On sait que le fait de pouvoir gérer une grande partie des fichiers xml avec blender permet de moins diviser les choses et ainsi d'avoir des xml plus conséquents. Mais il faut garder tout de même une arborescence minimale pour ne pas compromettre les travaux collaboratifs. Comment dira-t-on que tel élément doit faire parti du fichier interior.ac, qu'un autre fait parti du panel ect...

À ce propos l'idée des nodes est plutôt cool, imagine reproduire et manipuler l'arborescence des fichiers avec les nodes et les boites. Je part peut être encore dans un délire, mais imagine que dans les boites on rassemble les objets que contiendra les fichier ac.

Si tu veux ce soir je pourrais être sur mumble.

En ce qui concerne, l'arborescence. Le script est parti pour laisser le choix. On fait ce que l'on veut. C'est sur, faire un seul fichier .ac, et un seul xml, c'est une solution de facilité. Mais de toute façon cela n'ira pas loin. Les personnes faisant cela, ne fairont pas d'avion fantastique. Ce n'est parce que blender existe, que tous les avions sont des modèles de modélisation. Le seul moyen de progressé est de faire les choses de manière structurée.
Travailler avec méthode, est le seul moyen de faire des avions ressemblant à quelque chose. Rien qu'aujourd'hui, il faut faire un mesh 3D, des textures, des animations, un modèle de vol, des programmes pour rajouter des fonctionnalités et des propriétés. On s'apperçoit que les quelques modèles qui valent le coup ont été créer modifier par plusieurs personnes. C'est toujours le travail d'une équipe. Et pour faire travailler une équipe, l'anarchie ne fonctionne pas.

Pour le script, il faudra rentrer le repertoire racine de l'avion , puis les concepteurs définiront leur besoin, en donnant des arborescences relatives pour les fichiers.
Voila comment je vois les choses.

A+

_run_ a écrit:

oh ça donne envie d'essayer !

Je vais essayer de créer une animation

Alors pour tester, j'ai créer une animation. Un simple vérin qui tourne et s'étire. Je n'ai eu aucun gros soucis pour créer l'animation, c'est super simple.

Par contre, au moment d'écrire le fichier xml, problème !


Sinon, le fait de devoir réécrire à chaque fois la la propriété et le nom du fichier xml pour chaque armature est un petit peu répétitif

je suis sur mumble

oh désolé, je ne pouvais pas hier soir, ce soir par contre c'est possible pour toi ?

pas de bonne heure ...

Mais ce qui est bizarre, c'est que je n'arrive pas à reproduire l'erreur !!!

je vais sur le chat du forum !!

Salut rené,
Alors j'ai un petit soucis. Ce que je souhaite faire pour le moment, c'est ajouter un petit bouton pour afficher tous les objets d'une même animation. Ce que je souhaite faire sans succès c'est appelé la class FG_OT_select_property (fichier ops_flightgear.py)

Comme je n'arrive pas à l'appeler, j'ai simplement copier le code qu'elle contient dans ma class pour qu'il soit tout de même exécuté.

C'est probablement tout bête pourtant

Salut Alexis,

Pas de problème.
Je pense que pour utiliser FG_OT_select_property tu utilises dans ton code, bpy.ops.view3d.select_property().
C'est comme cela que cette fonction s'appelle dans l'api blender

Elle ne sera éxecuté uniquement si :

Code:

   @classmethod
   def poll(cls, context):
      if not context.active_object:
         return False
      return context.active_object.type in( 'MESH','ARMATURE')


Cette fonction return True.
Ce sont les mécanismes d'appel des operateurs de l'API blender.

Cette fonction retourne True si il y a un objet sélectionné et actif, et si l'objet actif et une armature où un mesh. ( Un petit rappel, l'objet actif est le dernier élément sélectionné, il peut y avoir plusieurs objets sélectionnés, mais il n'y a qu'un seul objet actif)

Ensuite il est possible que l'appel ne se fasse pas sur la fonction execute() mais la fonction invoke(), et comme elle n'est pas définit dans la classe, il ne se passe rien. Cela m'est arrivé, mais je regarderai cela.

En attendant et plutôt que de te bloquer la dessus tu as bien fait de recopier la fonction.


En ce moment je corrige les dernières erreurs de l'import, qui ne sont vraiment pas simple à trouvé. Je jongle avec les fichiers xml mais aussi avec les fichiers .ac du f14, et c'est long. Je viens de trouver une erreur que je ne vois pas comment corrigé. J'ai trouvé deux faces d'un objet avec des doublons de points. Blender se mélange les pinceaux avec une seule face, pas avec l'autre. En corrigeant à la main le fichier .ac, le script arrive à lire l'ensemble de l'avion. Alors là, il y a près de 1000 animations, le script est forcement lent, je n'ai pas chronométré, mais c'est plusieurs longues minutes. Et l'affichage est relativement lent. Par contre il reste encore quelques erreurs de parenté que je vais corrigé.

Continue Alexis, c'est très bien, j'ai hâte de récupérer ton code, je tiens absolument à ce que vous soyez aussi les artisans de ce script.

A+

Super ça fonctionne ! merci beaucoup, Je devais faire une erreur dans l'appel de la fonction.

Pour le moment, j'ai créer deux fonctions, une pour afficher les éléments d'une animation, et l'autre pour ré-afficher tout, ça peut être utile pour les utilisateurs ne connaissant pas bien les raccourcis.

Alors pour simplifier dans un premier temps, j'ai placé ces deux fonctions dans le menu flightgear (qui s'ouvre avec la touche f), mais je vais essayer de déplacer ça dans le panneau latéral. Nous aurions un bouton pour appeler le la première, puis celui-ci sera remplacé par un autre bouton "Show all"

Au passage, peut-on utiliser des icônes, le l’icône de l’œil se prêterait bien au jeu pour afficher ou masque l'animation

C'est un petit pas pour le script, mais un grand pour Alexis