Script flightgear

Ok à partir de 14 heures si tu veux...

cet après midi ok, mais plus vers 14H30 si ça ne te dérange pas.

Je te me montre une capture de l'essai fait après une mise à jour hier soir :


Bon la partie supérieur du message montre un problème d'export en AC3D, mais je m'intéresse plutôt à la deuxième partie du rapport, comme tu le vois, les "\" sont à la bonne place, mais pour certains chemins, il y a une répétition de Aircraft\DR400-jsbsim

J'ai mis une nouvelle version du script sur gitotious.
La gestion de la transparence à été revue. Gros travail sur les textures. mais pas que ....
Encore à faire:
Les transformations multiples suites aux inclusions de fichier.
Visible sur le DR400 et le dc-3
Mais cela se rapproche du but ..... avant la prochaine étape.
Quelques recopie d'ecran ..

Salut René,

C'est franchement génial le script que tu conçois !
Pour la partie animation, je ne sais pas comment tu veux t'y prendre, je donne l'idée que j'ai en tête :

Le XML nous indique quel objet est relié à quelle propriété. Ce qui peut être possible de faire c'est :
- Lorsque l'on sélectionne un objet qui possède une animation, un menu s'affiche (dans le même genre que le tout premier menu que tu avais fais) ce petit menu nous montre la propriété concerné, et permet de modifier la valeur de celle-ci afin de voir l'animation dans Blender.

L'inconvénient de cette technique c'est qu'on ne peut faire bouger que l'objet actuellement sélectionné, aussi, que se passe-t-il si 2 objets animé sont sélectionné en même temps ?
Une autre possibilité, mais peut-être un peu plus "bordélique" serait de créer un panneau "Animations" dans lequel on a la liste de tous les objets animé avec les propriétés et les valeurs de chacun d'eux. Si on ouvre un tableau de bord entier on devrait alors se retrouver avec un panneau bien garnit. Est-ce que tu vois ce que je veux dire où je fais un petit montage Gimp pour illustrer ça, ou bien tu as déjà une idée bien précise de ce que tu va faire et donc pas besoin de mes idées ?

En tout cas un grand bravo ! N'hésite surtout pas à demander de l'aide, je regarde régulièrement ton code mais je t'avoue que je ne me sens absolument pas compétent. Je ne connais même pas les bases du python, en ce moment en plus je n'ai plus beaucoup de temps, donc pas le temps d'apprendre le python et l'API Blender.

Tiens nous au courant de ce que tu fais, ce que tu vas faire, ce qu'il reste à faire... ça m'intéresse !

PS: Ah je viens de voir un truc, je pense que c'est un soucis de récursivité. Si je charge le "panel.xml" du DR400-jsbsim (comme tu as fais dans tes screenshot précédent) tout se passe très bien, c'est superbe, tout est à sa place bien comme il faut.
Par contre si je charge le dr400-jsbsim-set.xml (c'est à dire l'avion entier) les instruments sont décalé de quelque centimètres du tableau de bord. La première idée qui me vient à l'esprit c'est ces histoire d'offset : Dans le DR400-jsbsim plusieurs fichiers XML sont appelé avec des offsets, Les instruments sont en "bout de chaine", c'est à dire que lorsque les instruments sont affichés il doivent subir l'offsets de TOUT les xml précédent. N'y aurait-il pas une limite concernant la récursivité de ces offsets ? du genre : un xml ne prend en compte que l'offset du xml parent ? si un fichier xml est appelé par un autre xml avec offset, lui-même appelé avec un autre xml avec offset, lui-même appelé......etc etc est-ce que TOUT les offsets sont bien pris en compte ?

Il y a aussi un truc bizarre concernant des normals. Ceci n'a rien à voir avec ton script mais c'est gràce à ton script que je viens de comprendre ce qu'il se passe :
Dans la version Rembrandt de FG (version avec les ombres et AO calculé par FG) les instruments du tableau de bord sont transparent. Ainsi la lumière du soleil passe à travers les instruments et selon la position/orientation du dr400-jsbsim et bien on voit l'absence d'ombres des instruments aux pieds du pilote. Pourquoi je te parle de ça ? parce que je viens de charger le tableau de bord du dr400-jsbsim, tout est parfait commen dans tes screenshots. J'ai sélectionné TOUT les objets (touche "a") puis j'ai tout fusionné (ctrl+j) pour n'avoir qu'un seul bloc (ne me demande pas pourquoi j'ai fais ça... c'était pour le fun) Et là figure-toi que lorsque tout les objets étaient fusionné, l'intégralité des fond d'instruments se sont retrouvé avec les normals inversé !!! Je pense que c'est ce qui se passe dans FG et c'est pour ça que les fond d'instruments ne projettent pas d'ombre. la question est : pourquoi ? comment résoudre ça ?

Amicalement,
Clément

F-JJTH a écrit:Le XML nous indique quel objet est relié à quelle propriété. Ce qui peut être possible de faire c'est :
- Lorsque l'on sélectionne un objet qui possède une animation, un menu s'affiche (dans le même genre que le tout premier menu que tu avais fais) ce petit menu nous montre la propriété concerné, et permet de modifier la valeur de celle-ci afin de voir l'animation dans Blender.

L'inconvénient de cette technique c'est qu'on ne peut faire bouger que l'objet actuellement sélectionné, aussi, que se passe-t-il si 2 objets animé sont sélectionné en même temps ?
Une autre possibilité, mais peut-être un peu plus "bordélique" serait de créer un panneau "Animations" dans lequel on a la liste de tous les objets animé avec les propriétés et les valeurs de chacun d'eux. Si on ouvre un tableau de bord entier on devrait alors se retrouver avec un panneau bien garnit. Est-ce que tu vois ce que je veux dire où je fais un petit montage Gimp pour illustrer ça, ou bien tu as déjà une idée bien précise de ce que tu va faire et donc pas besoin de mes idées ?

Cette problématique, n'est pas spécifique à flightgear. Mais elle est la même pour tout les programmes qui font de la 3D animées. La discussion, sur ce post, avec alexis (voir bielle1 et bielle2) montre que flightgear à chosi une autre voie pour les objets subissant plusieurs transformations. D'un manière générale on décrit la parenté des animations (blender fait cela, x-plane aussi, mon programme aussi, mais plein d'autres aussi). Or flightgear décrit la parenté des objets. Ainsi dans flightgear, un objet peut être inscrit dans plusieurs blocs <animation>. Mais heureusement je pense que ces manières sont équivalentes. J'ai déja réfléchi à un algorithme qui permet de passer de l'un à l'autre.
Avec de la pratique tu verras que ce n'est pas compliqué (vraiment pas).
Voila comment je vois les choses:
Pas de menu ou boîte de dialogue mais un panneau dans l'interface de blender. Ce panneau sera différent suivant la sélection d'une armature ou d'un objet. Dans le panneau armature ont peut écrire tous les objets liés, et dans le panneau objet, les armatures liées. Ont peut même mettre des boutons donnant des ordres de modifications. Bien sur des ordres spécifiques aux armatures dans le panneau armature, et des ordres spécifiques aux objets dans le panneau objet. La liaison objet-armature est déja pris en compte par blender ( parenté de 'bone' )

F-JJTH a écrit:PS: Ah je viens de voir un truc, je pense que c'est un soucis de récursivité. Si je charge le "panel.xml" du DR400-jsbsim (comme tu as fais dans tes screenshot précédent) tout se passe très bien, c'est superbe, tout est à sa place bien comme il faut.
Par contre si je charge le dr400-jsbsim-set.xml (c'est à dire l'avion entier) les instruments sont décalé de quelque centimètres du tableau de bord. La première idée qui me vient à l'esprit c'est ces histoire d'offset : Dans le DR400-jsbsim plusieurs fichiers XML sont appelé avec des offsets, Les instruments sont en "bout de chaine", c'est à dire que lorsque les instruments sont affichés il doivent subir l'offsets de TOUT les xml précédent. N'y aurait-il pas une limite concernant la récursivité de ces offsets ? du genre : un xml ne prend en compte que l'offset du xml parent ? si un fichier xml est appelé par un autre xml avec offset, lui-même appelé avec un autre xml avec offset, lui-même appelé......etc etc est-ce que TOUT les offsets sont bien pris en compte ?

Tu as bien senti où ce trouve le probleme. A l'heure actuelle, il n'y a pas de problème si il n'y a que offsets. Le problème vient des rotations. Dans le DR400, il y a des inclusions multiples, avec des offset différents, mais aussi avec des rotations différentes. (pitch-deg etc..). En réfléchissant, avec un papier et un crayon (un dessin), tu peux voir où ce trouve l'erreur. Heureusement, l'api de blender fournit des fonctions qui permettront de corriger cela. (Il va falloir faire du calcul matriciel)

F-JJTH a écrit:
Il y a aussi un truc bizarre concernant des normals. Ceci n'a rien à voir avec ton script mais c'est gràce à ton script que je viens de comprendre ce qu'il se passe :
Dans la version Rembrandt de FG (version avec les ombres et AO calculé par FG) les instruments du tableau de bord sont transparent. Ainsi la lumière du soleil passe à travers les instruments et selon la position/orientation du dr400-jsbsim et bien on voit l'absence d'ombres des instruments aux pieds du pilote. Pourquoi je te parle de ça ? parce que je viens de charger le tableau de bord du dr400-jsbsim, tout est parfait commen dans tes screenshots. J'ai sélectionné TOUT les objets (touche "a") puis j'ai tout fusionné (ctrl+j) pour n'avoir qu'un seul bloc (ne me demande pas pourquoi j'ai fais ça... c'était pour le fun) Et là figure-toi que lorsque tout les objets étaient fusionné, l'intégralité des fond d'instruments se sont retrouvé avec les normals inversé !!! Je pense que c'est ce qui se passe dans FG et c'est pour ça que les fond d'instruments ne projettent pas d'ombre. la question est : pourquoi ? comment résoudre ça ?

Il va falloir que je t' explique comment est programmé l'affichage des ombres. Mais il faudra du temps pour faire un post clair, avec quelques petits dessins qui "vont bien". Ce n'est pas sur ( si j'ai bien compris ) que ce soit un problème de normales. Pour les ombres on utilise le z-buffer. Or les objets transparent modifie le z-buffer, et le tableau de bord, contient des objets transparents. Les vitres des instruments.
Or j'ai modifié l'import des fichiers .ac , pour avoir une meilleure gestion de la transparence. (on ne les voit pas ....mais elles y sont) Si tu as fait un (ctrl+j) tu as dont fusionné les vitres aussi. Regarde de ce côté ...

A++

P.S. Actuellement j'écris l'intégration des animations et je vais réorganiser le code pour que vous puissiez rajouté facilement des fonctions au menu "flightgear". Tu verras ce n'est pas compliqué. C'est à votre portée ... ne t'inquiètes pas.

P.P.S. Bientôt je vais avoir besoin de vous, mais pour l'instant il est normal que je fasse tout.

Ça y est !!! J'ai écrit mes premières lignes de Python !!!
https://gitorious.org/paf/fg2blender/commit/cd980db714417c1e36f8b7e038b19622454f1fe1

J'ai essayé de garder la même approche que toi, mais impossible de créer la variable "option_light" pourtant je l'ai bien déclaré à False en haut du fichier et déclaré en tant que Global dans print_animation() mais rien y fait... c'est pourquoi le if option_light est commenté et j'ai donc supprimé les déclarations... Tu peux m'expliquer ?

Maintenant j'ai des questions :
Quelle différence entre def read_axis_vecteur( node ) et def readVector_axis_vecteur( node ) ? Les deux permettent de récupérer un x,y,z
Je vois les déclarations suivante : x = y = z = 'no' ou encore x0 = y0 = z0 = 'no' ne serait-ce pas mieux de remplacer no par 0 ?

J'ai vu que tu as ajouté des "datas" aux "objets" (corrige moi si je n'utilise pas les bons termes). Je vois par exemple self.property qui doit contenir la propriété à laquelle l'objet (ou l'armature??) est associé. Je n'arrive pas à y accéder
J'ai essayé ça bpy.data.objects['light'].property mais ça marche pas.. comment faire ?

Amicalement,
Clément

Salut Clément,

Continu comme ça, c'est très bien ....

F-JJTH a écrit:J'ai essayé de garder la même approche que toi, mais impossible de créer la variable "option_light" pourtant je l'ai bien déclaré à False en haut du fichier et déclaré en tant que Global dans print_animation() mais rien y fait... c'est pourquoi le if option_light est commenté et j'ai donc supprimé les déclarations... Tu peux m'expliquer ?

J'ai fait une version sur le dépôt, où la variable option_light est pris en compte. Il faut bien se rendre compte que la déclaration des variables, n'est pas seulement une syntaxe du langage. Mais c'est aussi une manière de réserver de la mémoire sur ton ordinateur au moment de l'exécution.Tu as vu la portée des variables, en utilisant le mot "global", mais il faut quand même déclarer la variable. Je le fais en générale en début de script. Je rassemble toutes les variables globales ensemble. Puis à chaque fois qu'une fonction utilise ces variables tu déclares que cette variable n'est pas une variable locale à la fonction, mais globale au fichier : global option_light
Si tu veux utiliser cette variable (cette "case mémoire") dans un autre fichier il faudra cette fois écrire, au début de la fonction : from .xml_import import option_light

F-JJTH a écrit:Maintenant j'ai des questions :
Quelle différence entre def read_axis_vecteur( node ) et def readVector_axis_vecteur( node ) ? Les deux permettent de récupérer un x,y,z
Je vois les déclarations suivante : x = y = z = 'no' ou encore x0 = y0 = z0 = 'no' ne serait-ce pas mieux de remplacer no par 0 ?

Beaucoup de fonctions read_blabla, et print_blabla, sont issues du premier script de test de la bibliothèque xml.dom.minidom. A ce moment je ne faisait qu'afficher des données. Ces fonctions retournaient des "string" (des chaines de caractères) pour l'affichage. Mais maintenant il faut retourner les valeurs exactes contenu dans le fichier xml. Il faut donc convertir les strings en float, int et vector. Pour l'api python de blender, Vector est un objet contenant un tuple de 3 rééls. vec = mathutils.Vector( (0.0,0.0,0.0) ). Vector contient 3 float qui correspondent aux coordonnées, x y et z. Une fois déclaré, tu peut changer la coordonnée x de cette manière. vec.x = 3 * 6.23 + une_variable_float.
J'ai donc commencé à réécrire les fonctions read_blabla pour retourner les vraies valeurs. Je l'ai appelé readVector_blabla. Lorsque j'ai besoin de la vraie valeur j'utilise readVector_blabla, mais aussi read_float_blabla. Lorsque je récupère une chaîne de caractère on peut utiliser ces fonctions read_blabla. Exemple le nom d'un propriété.
Le 'no' pour vérifier que la personne à bien rempli entièrement le xml. J'ai trouvé des cas, où le 'y' d'une coordonnées n'est pas renseigné. C'était juste pour le voir plus rapidement. Si le script affichait "x=20.5216, y=no, z=no", c'est que <y-m></y-m> n'avait pas de valeur. Mettre une vraie valeur par défaut ne me permettait pas de visualiser cela rapidement.

F-JJTH a écrit:J'ai vu que tu as ajouté des "datas" aux "objets" (corrige moi si je n'utilise pas les bons termes). Je vois par exemple self.property qui doit contenir la propriété à laquelle l'objet (ou l'armature??) est associé. Je n'arrive pas à y accéder
J'ai essayé ça bpy.data.objects['light'].property mais ça marche pas.. comment faire ?

Pour l'instant il n'y a aucune données du script reliées aux données de blender. Il faut pour cela créer cette liaison grâce à l'api de blender. (voir script anim_ui.py, et surtout anim_prop.py sur ce post).
C'est très bien ce que tu as fait, cela permettra au script de gérer les animations "light", si j'ai bien compris.
Je préfère attendre pour relier les données du script avec les données de blender. Car blender sauvegarde ces nouvelles données d'objets, dans le fichier .blend. C'est carrément génial, on retrouvera toutes les données du scripts dans le fichier .blend, et pas besoin de relire tout le xml.
Mais entre les nouvelles données qui apparaîtront et celles qui seront modifiées, il risque d'y avoir des incohérences. Je préfère attendre un peu.
En plus blender est un gros logiciel, qui a obligatoirement des bugs. J'en ai trouvé un par exemple, qui empêche la création correcte de l'animation sur deux instruments du DR400. On peut le contourner je te rassure.
Blender se mélange les pinceaux avec deux objets , un du nom de face.001 et l'autre Face.001. Ces deux objets distincts sont bien visible distinctement dans blender, mais au moment de la création de la "parenté" pour l'animation blender fait une erreur. En choisissant deux noms moins proche tout rentre dans l'ordre. Ce bug n'apparait que dans l'api de blender, en faisant la parenté manuellement cela fonction correctement.

Pour l'instant je continue sur la création des armatures, car cela ne me plaît pas du tout. Il va falloir que je réécrive certaine chose car un fichier xml, contenant une animation peut être inclus plusieurs fois. Et le script, pour l'instant ne fait bien la chose.


A+

Ok, super les explications ! J'ai tout compris et tout me semble parfaitement logique
Ta façon de coder est très agréable car très lisible et clair, en plus c'est documenté. Bref c'est vraiment le top !

Oui j'ai fait en sorte que les animations de type "light" soit prise en compte. Ces animations sont spécifiques à la version Rembrandt de FG, c'est grâce à ces animations que l'ont fait de vrai lumière dans FG. À termes j'aimerai insérer une source lumineuse pour chaque animation de type "light" afin de pouvoir créer des lights Rembrandt via Blender. Ce qui serait largement plus simple que faire ça via un XML et lancer FG pour voir le rendu.
Ça devrait être un bon exercice

Amicalement,
Clément

C''est vraiment bien de penser à "rembrandt" avec le script. J'espère que l'on aura quelque chose de fonctionnelle lorsque ça sortira en release.

Je viens de faire le test du script sur la console du dc-3, et cela me fait marrer ("un vrai gamin"). Téléchargé la dernière version

Faire un import>Flightgear .xml dans blender

Une fois terminé dans la fenêtre 3d appuyez sur la touche F
Et cette fois choisissez "Creation animations"

Une fois terminé ... lancez l'animation avec ALT-A

Les armatures se trouve sur le layer 2.
Et vous pouvez déja remarqué que les "keyframe" sont inséré
Pas comme il faut (dans l'absolu) , mais en tenant compte du paramètre factor.

Excellent ! effectivement ça fait marrer

Bonjour tout le monde ,

J'ai un petite question sur les propriétés associées aux animations de flightgear. J'ai souvent un train d'atterrissage dont les deux jambes tournent dans le même sens. Y a t-il une particularité pour dire que l'animation est sur la jambe de train à droite et l'autre à gauche. Cela influe-t-il sur la variation de la propriété ? au lieu de varié de 0 à 1, dans certains cas cela varie de 0 à -1 ??
Je n'ai pas éplucher les xml. Je reste concentré sur le script.

Je pense que d'ici la fin de la semaine , j'aurai résolu le problème des "inclusions multiples". A ce moment je pense qu'il serait bon de discuter en vocal sur mumble. Je pense à ce week-end, si vous êtes dispo ??

La prochaine partie du travail, sera directement liée à l'utilisation de blender, dans le cadre de flightgear. Pour cette discussion tout le monde peut et devrait donner son avis. Cela ne concerne pas seulement les "codeurs". Une idée qui peut paraître farfelue est des fois quelque choses de simple à mettre en place, et au final très utile. Tandis qu'une prouesse de programmation n'est utilisé par personne (car elle ne sert à rien )


Amicalement René

ça avance à grande vitesse ! impressionnant

Bon par contre, ça ne fonctionne pas encore chez moi, (problème spécifique à windows ?), ce que dis la console :


Je vais chercher de mon côté, ça va me permettre de mieux comprendre le script

Ah flûte .... excuse moi .....

Mais je suis tellement concentré sur le script, que je fait pas attention.

Pour corriger, trouve la fonction conversion, dans xml_import.py, elle permet de remplacé les / par des \.

A mon avis en modifiant les deux lignes 650 et 690 :
xml_file.name = absolute_path( ret_text(node.childNodes[0]) )
en
xml_file.name = absolute_path( conversion(ret_text(node.childNodes[0])) )

cela devrait être mieux !

_run_ a écrit:

J'ai un petite question sur les propriétés associées aux animations de flightgear. J'ai souvent un train d'atterrissage dont les deux jambes tournent dans le même sens. Y a t-il une particularité pour dire que l'animation est sur la jambe de train à droite et l'autre à gauche. Cela influe-t-il sur la variation de la propriété ? au lieu de varié de 0 à 1, dans certains cas cela varie de 0 à -1 ??

Pour ce qui est des trains,sous YASIM, dans le FDM on va indiquer autant de jambes que l'on veut, ça donne quelque chose comme ça :

Code:


<gear x="4.014" y="-0.178" z="-1.67" compression="0.35" sfric="1.1" dfric="1.1">
<control-input axis="/controls/flight/rudder" control="STEER" square="false"/>
<control-input axis="/controls/gear/gear-down" control="EXTEND"/>
<control-speed control="EXTEND" transition-time="7"/>
<control-output control="EXTEND" prop="/gear/gear/position-norm"/>
</gear>


La prop ici est /gear/gear/position-norm, une deuxième jambe prendra la prop : /gear/gear[1]/position-norm.
Les noms de props sont les mêmes pour JSB (à confirmer)
Mais pour ce qui est de l'animation, absolument toutes les prop vont varier de 0 à 1. Il arrive même que pour certains avion, l'auteur utilise la même prop pour toutes les jambes du train.

[quote="_run_"]
Je pense que d'ici la fin de la semaine , j'aurai résolu le problème des "inclusions multiples". A ce moment je pense qu'il serait bon de discuter en vocal sur mumble. Je pense à ce week-end, si vous êtes dispo ??
[/code]

Alors je serait absent à partir de ce Samedi et ce jusqu'à la fin de la semaine prochaine, je reste à disposition jusqu'à vendredi soir.

_run_ a écrit:Ah flûte .... excuse moi .....

Mais je suis tellement concentré sur le script, que je fait pas attention.

Pour corriger, trouve la fonction conversion, dans xml_import.py, elle permet de remplacé les / par des \.

A mon avis en modifiant les deux lignes 650 et 690 :
xml_file.name = absolute_path( ret_text(node.childNodes[0]) )
en
xml_file.name = absolute_path( conversion(ret_text(node.childNodes[0])) )

cela devrait être mieux !

Je pensais à ce genre de soucis, ok je fais la modif tout de suite !

[EDIT] OK ça fonctionne

Je reinsère l'invitation

Je pense que d'ici la fin de la semaine , j'aurai résolu le problème des "inclusions multiples". A ce moment je pense qu'il serait bon de discuter en vocal sur mumble. Je pense à ce week-end, si vous êtes dispo ??

La prochaine partie du travail, sera directement liée à l'utilisation de blender, dans le cadre de flightgear. Pour cette discussion tout le monde peut et devrait donner son avis. Cela ne concerne pas seulement les "codeurs". Une idée qui peut paraître farfelue est des fois quelque choses de simple à mettre en place, et au final très utile. Tandis qu'une prouesse de programmation n'est utilisé par personne (car elle ne sert à rien )

On peut se "voir" (en vocal ) vendredi soir .... (pour Alexis")

Je ne suis pas certains à 100% de pouvoir être là mais si je peux je n'y manquerai pas !
Je vous tiens au courant en tout cas

Bonjour tout le monde ,

Voila, maintenant vous allez pouvoir rajouter des chose a ce script. Bien sur, il reste des "bugs", et je ne les ai pas tous vus. Mais ils n'empêchent pas le scrtipt de fonctionner.
Par contre, je pense à un gros "bug" qui empêche le script d'importer des fichiers ".ac". Dans des doublons de vertex sur une même face. Blender renvoi une erreur "v0!=v1" et je n'ose la corriger. En effet, comparer chaque vertex avec les autres aurai un coût en temps phénoménale. Le script d'import deviendrai extrêmement lent.
De toute façon blender ne vous laissera pas faire cette "horreur". Mais certain fichier .ac contient cela. Je pense à des avions modélisé avec AC3D ou bien des erreurs de script d'import/export.

Maintenant quelques explications sur la structure de fichier: 3 nouveaux type de fichier font leur apparitions.
ui_blabla
ops_blabla
props_blabla

Les fichiers ui_*.py, font référence à l'interface utilisateur (ui=User Interface)
Ce trouve dedans le menu (flightgear) "ui_menu.py", les nouveaux "panel" blender "ui_panel_armature.py", et les raccourci clavier "ui_shortcut.py"
Les fichiers ops_*.py, font référence aux nouveaux opérateur blender, que l'on définira
Les fichiers props_*.py font la liaison des données du script avec blender. Les données liés à blender seront sauvegardé dans le fichier blender .blend.

Toutes ces nouvelles fonctions sont reconnues par blender, car elles sont enregistré (fonction register() et unregister() appelé par __init__.py)


Quelques explications sur les opérateurs blender.
Pour faire des nouvelles fonctionnalités à blender, on utilise les opérateur (operator)
bpy.ops.object.select_pattern( pattern='Cube' ) est un operator interne. Il permet la séléction d'un objet par son nom (ici Cube')
Comment créer un nouvel "operator": il faut définir et enregistrer une nouvelle classe/

Code:

class FG_OT_exemple(bpy.types.Operator):
   bl_idname = "fg.exemple"
   bl_label = "fg.exemple"

   def execute(self, context ):
   #Code à éxécuter
      return {'FINISHED'}


bl_idname = "fg.exemple" sera le nom reconnu par blender. Le nouvel operator pourra être appelé par bpy.ops.fg.exemple(). Ce nom est obligatoirement en 2 parties. Avec un . au milieu.
et la fonction execute( self,context ) sera éxécuté.
Le context est une variable contenant le context blender c'est à dire l'endroit ou l'on se trouve ex: mode objet , mode edit mode pose-mode. C'est des fois rebutant je vous préviens.
Et enfin enregistrer cette classe : rajouter une ligne dans la fonction register()
bpy.utils.register_class(FG_OT_exemple)

Petit bug lorsque je souhaite charger le fichier -set



il y a un chemin ligne 129 du fichier __init__.py qu'il faut changer, en quoi ?

C'est une bidouille que j'ai fait pour aller plus vite lors des tests. J'ai créé un raccourci pour charger le dernier fichier chargé. Je te mets une version sans cela sur le git.



[Edit]
C'est fait

es-tu certain que le commit est passé ? rien à changé

je regarde

En fait le chemin est devenu : /home/rene/tmp/script-fg2bl

Ca devrait etre bon, es-tu sur mumble ??

J'arrive,

ça ne peut pas être le bon : /home/rene/tmp/script-fg2bl