mercredi 7 décembre 2016

Python et 3ds Max... Et si c'etait pas si mauvais.




















 







Avec des logos aussi similaires on aurait pu croire à une rencontre fusionelle! Ah non, et en plus 3ds max à change de logo...


Hello à tous!


    Cela fait trop longtemps que je vais à reculons pour mettre mon nez dans le python de 3ds max... et bien voila! c'est fait ! et je vais vous en dire deux mots.
Le MaxPlus est apparu dans la version 2014, il est complete de version en version. 
MaxPlus c'est le module python de 3ds max, et c'est qu'un seul et unique gros fichier python! (déjà ça part mal vous aller me dire).
Je n'ai jamais voulu m'y plonge déjà parce que MaxPlus est trop eloigne du max script (on verra pourquoi et pourquoi c'est une bonne chose) et que de faire des choses simples me paraissait trop compliquer, surement par manque d'expérience dans la programmation. De plus je ne m'intéressais pas d'aussi pret à la programmation oriente objet. Et la pire des raisons pour que les gens ne se lancent pas dans le MaxPlus c'est le manque d'informations, la doc est aussi vide que Myspace et il y a très peu de tuto sur la toile, heureusement il y a quelques exemples, bref la communication et la documentation sont les gros points noirs du MaxPlus.

Donc voilà, ici, je pose ma brique à édifice pour y remédier.

    Le premier point que j'aimerais éclairer c'est qu'il ne faut pas chercher à se rapprocher du max script comme le fait le python et le mel, par exemple pour Maya. Vous retrouverez quelques noms de fonctions similaire, evidement, mais la logique n'est pas la même. LA raison : c'est que MaxPlus est base sur l'API C++ de 3ds Max. Et quand j'ai compris ça, les portes de mon petit cerveau se sont ouvertes.    En fait, MaxPlus est ce que l'on appelle un wrapper, il essaie tant bien que mal à "traduire" le C++ en Python. Pour faire ça les Monsieurs d'Autodesk ont choisi d'utiliser le programme swig. C'est surement pour cette raison que des choses maladroites sont faites comme l'utilisation d'un seul fichier, des classes servant de namespace, des méthodes converties en fonctions où tout un tas d'autres choses... mais qui au fond nous empeche pas d'utiliser MaxPlus.

    Ayant compris ça il est donc possible de lire la doc C++ et de s'y retrouver en MaxPlus. Nous retrouverons les "interfaces" C++, plus simplement dit les "objets, comme les INodes, Animatable, FPInterface... À la différence avec le max script où nous ne retrouvons pas de manière transparente ces objets. L'exemple flagrant est la création d'une teapot, en maxscript le mot "teapot" suffit à faire apparaitre une teapot dans le viewport, en MaxPlus il va falloir deux lignes de code mais derrière ces deux lignes il y a un concept simple de la 3d : les notions de node et d'objet referent. Alors que le maxscript jou la boîte noire sur ce genre de chose (ce que veut faire le nouveau pymx 2017) 
 
Un autre element fort intéressent est l'intégration de PySide, ce qui change pas mal la donne par rapport au Maxscript (sans .net). Avec PySide, le wrapper python de Qt, nous allons pouvoir faire des interfaces vraiment pousse. Par contre... il semble qu'avec des interceptions (de click, touches, move...) un peu pousse 3ds Max perd le contrôle et la navigation dans le viewport devient impossible.

    Malheureusement il manque pas mal de choses essentiels dans Max plus. Comme par exemple l'interface skinOps qui permet d'utiliser efficacement le modifier skin. Un petit éditeur integre à Max pour pouvoir taper quelques lignes a le vole. L'implementation des types python, les INodeTab, les tableaux de INode, sont partiellement implémentés en liste python; maliste[-1] nous retournerons un Index Error Index out of range... ce qui oblige à faire une petite liste compréhension pour convertir l'INodeTab en une liste python de INode. Ne possède pas de moyen simple de lister tous les objets de la scène. Ou encore l'utilisation de getter / setter en plus des properties classique, par exemple:



INode.name #retourne name

INode.name = mon_nouveau_name #set un nouveau nom

INode.GetName() #retourne name

INode.SetName(mon_nouveau_name) #set un nouveau nom

   De mon point de vue MaxPlus semble assez prometteur malgré tous ses défauts et j'ose espérer que cest sur la bonne voie. Ce qui me fait le plus peur c'est Autodesk... et que les dernières maj de python max de la version 2017 sont loin d'etre ce que j'attendais ....















lundi 14 novembre 2016

Le retour du node graph ! ... en PySide.

Vous vous souvenez que j'avais attaqué y a quelques années la conception d'un node graph view en pyqt parce que impossible de trouver une librairie pyqt/pyside pour faire "facilement"  ce genre de choses...
http://unblogdecolin.blogspot.fr/2013/07/pyqt-qgraphicsview-la-base-pour-un-node.html
  bref j'ai laissé tombé et le projet a était avorté.  
Jusqu'au jour où j'ai discuté avec mon ami Frangipane qui a rencontré le même genre de problématique,  sauf que lui a réussi à se lancer sur la conception d'une lib pyside pour faire des graph views qui claques.  Il a déjà fait une petite base bien rodé mais loin d'être implementable pour le moment et la Frangipane commençait à s'essouffler.  
Du coup je me suis incrusté sur son projet et nous avons décidé de relancer la machine, on a chauffé les github et me voilà  en train de forker de la Frangipane à coup de push request pour faire évoluer ce projet avec lui, parce que bazar nous avons tous besoin d'une bonne lib pyside pour faire des node graph !  

Une petite  preview en image:

mardi 25 octobre 2016

Marilla api update

Petites mises à jour du module gueguetags:
https://github.com/col-one/marilla



Désormais il est possible d'ajouter aux Guerilla tags par défaut les parents des meshs sélectionnés et de choisir la profondeur.
GuegueTags prend comme argument par défaut grp=0, sa valeur précise la profondeur.
-1 infinit
0 pas de parents
1 premier parent
2 premier et second parents
3 premier, second et troisième parent
....

vendredi 21 octobre 2016

Marilla : Alembic Tags Workflow pour Maya / Guerilla Render





Il existe déjà une passerelle maya / guérilla développée par les messieurs de Guerilla, elle fonctionne très bien mais elle est très peu flexible et permet pas d'avoir un workflow de production d'Anim. Heureusement l'alembic est là et le système de référence de guérilla fonctionne très bien.


En utilisant l'outil Marilla nous allons pouvoir mettre en place un workflow de référence entre Maya et Guérilla. Comme celui-là :


   

    L'utilisation des tags a beaucoup d'avantages, cela permet de ne plus être dependant d'objets, de meshs, de fichiers ... mais simplement d'un tag. Comme dans le graph ci-dessus la même série de tags va être utiliser pour shader les alembic du modeling pour le lookdev et les alembics de l'Anim pour le rendu final. Nous utilisons plus des objects mais des etiquettes. Là où dans un workflow classique il aurait fallu réassigner les matériaux aux alembics d'Anim. Un des autres avantages c'est l'utilisation de tags transverses, comme par exemple faire des tags "peaux", "métal", "mate" ou "shiny" ...



 Dans guérilla les préfixes des références peuvent être une manière de donner un espace à nos tags par exemple:


Objet1.abc:

    mesh:
        tags:
            -tete
            -corps
            -peau
            -pied

Objet2.abc:

    mesh:
        tags:
            -tete
            -corps
            -peau
            -pied



    Lorsque l'on importe une référence alembic dans guérilla il propose de le préfixer, par défaut par le nom de du fichier, ici nos nodes auront comme nom Objet1: mesh et Objet2: mesh.

Si on importe des Renders Graph différents mais qu'ils possèdent des tags de mêmes noms il va y avoir conflit, c'est là qu'interviennent les préfixes. 
Dans les proprietes du Render Graph il y a un parametre qui s'appel 'apply on': 'tags' et dans le champs text en dessous il faut preciser le prefix 'Object1:' pour le Render Graph de l'objet 1 et 'Object2:' pour le Render Graph de l'object 2. Ainsi les tags du même nom s'appliqueront bien dans leurs espaces respectifs.
préfixe, attention au :
On peut aussi préciser des tags à la place d'un préfixe, le Render Graph s'appliquera que sur les objets qui possèdent le tag en commun. ex:

Objet1.abc:
    mesh:
        tags:
            -toto
            -tete
            -corps
            -peau
            -pied

Objet2.abc:
    mesh:
        tags:
            -tata
            -tete
            -corps
            -peau
            -pied

Ici pour le Render Graph Objet1 il faudra préciser "Toto" et pour celui d'Objet2 il faudra préciser "Tata"




tag

Encore un autre avantage des tags c'est qu'on peut les combiner et faire des opérations boolean dessus. Un objet qui possède ce genre de combinaison :





    Nous remarquons les signes plus et moins. Dans ce cas l'objet sera trouvé par tous les tags "foot, Head, Tata, Toto" sauf "novisible".
Très utiles pour les retake et tweak de fin de RenderGraph.



Voilà je vous ai presente un workflow et survolle l'utilisation des tags.
Maintenant nous allons voir l'outil Marilla qui permettra d'optimiser l'utilisation des tags de Maya vers guérilla.





Install:

Telecharger le repo Marilla sur github:
https://github.com/col-one/marilla

Placer le dossier marilla dans un répertorie qui sera source par Maya, PYTHONPATH, MAYA_SCRIPTS_PATH...


Dans le dossier marilla nous pouvons trouver un fichier userSetup.py il faut ajouter les lignes de codes presentent dedans a votre propre fichier userSetup.py si nous en avons pas nous pouvons directement copier le userSetup.py dans le bon dossier, par default cela sera:
  • Windows: :\Documents and Settings\\My Documents\maya\\scripts
  • Mac OS X: ~/Library/Preferences/Autodesk/maya//scripts.
  • Linux: ~/maya//scripts.

Le userSetup.py permet d’exécuter du code lors de l'ouverture de maya, ici ca permettra d'ajouter un menu 'marilla' a la main window.

Si tout va bien nous devrions avoir ca:



    Du cote Guerilla, il va falloir copier un fichier lua dans un dossier UserPlugins. Dans le dossier marilla / guerilla nous copions le fichier openPort.lua et le collons dans un dossier UserPlugins. Si nous n'avons pas définit de UserPlugins dans le fichier guerilla.conf nous pouvons le coller dans le dossier plugins de l'install de Guerilla.

    Toutes les fonctionnalités se trouve dans maya. 

Auto Tags, nous sélectionnons l'ensemble de nos géométries (mesh) ou nos cameras et l'exécutons, cela va taguer les transform de nos mesh avec son nom et son top parent. 

Remove All Tags, permet de supprimer tout les tags d'une sélection de mesh.

Add / Remove Tags, permet de venir ajouter des tags custom, comme on a vu plus haut les fameux tags transverses. Il faut rentrer le nom du tag dans le champs text et faire Add ou Remove. Il y a la possibilité d'ajouter ou supprimer plusieurs tags a la fois en séparant les noms par une simple virgule, 'metal,#cccccc,blured...'

Export, permet d'exporter la sélection en alembic avec les tags Guerilla et un ensemble de presets :
    -ogawa
    -world
    -uvs
    -faces groups
Attention pour avoir un bon export il faut sélectionner que des transforms si ils sont dans un group il faudra sélectionner le group. 
Dans le popup nous préciserons nos paramètres d'export. Range Mode, PreRoll... 
Et si nous checkons 'Export to guerilla' cela enverra directement notre alembic dans un Guerilla préalablement ouvert. 


Et pour finir nous avons a disposition une petite API pour les gens qui souhaite ajouter ces fonctionnalités a leur propres pipe / outils ... l'help est dispo en depuis le menu marilla dans maya.





La partie Guerilla est très succincte et mériterai une amélioration comme pouvoir proposer l'export dans un nouveau fichier Guerilla, ou encore pouvoir remplacer la référence si elle existe déjà dans la scène Guerilla...