Deex Vray Fast

Hey,
Bon je vais vous copier/coller la présentation du truc en anglais !
En gros j'ai fais un outil qui règle Vray Maya tout seul avec un potard, le tout logarithmiquement (interpolation auto des middles et highs values).
Avec pleins d'autres outils, le tout, gratuit.

Voila :

Today i present you the first version (0.5) of Deex Vray Fast.
Because there are more and more users who use Vray For Maya, i decide to create this tool which "set" Vray for Maya automatically.

What is deeXVrayFast ?

Deex Vray Fast is a tool which help the user to work quickly and easily with Vray For Maya.



Features :

* Set the quality automatically with one slider (image sampler quality, GI quality, etc etc...)
* All qualities are controled by presets
* 2 DeeX presets builded by default (for exterior and interior)
* Edit/delete/save/share your presets qualities with all users
* Optimization chooser : choose what do you want to control (Image sampler, irradiance map, light cache, system, etc etc...)
* Optimization chooser : add differente quality for each render option (Image sampler, irradiance map, light cache, system, etc etc...)
* Change resolution in one click (quality is linked to resolution)
* Fast control : choose the best "combo" for GI, quickly control the rendering options (Motion blur, displacement, ambient occlusion, DOF, etc etc...)
* Tool : import multiple proxies in one click
* Tool : connect automatically all shaders to proxies materials (correspondence between proxy slot name and shader name. Work with name space/references)
* Tool : convert all (or selection) your textures into tiled exr. Color space for each texture is preserved automatically.
* Update your tool in one click


Install and start the tool :

Download the file and copy python files in your Maya Python path.

After in Maya, in the script editor, execute :

Code:

import deeXVrayFast
reload(deeXVrayFast)
deeXVrayFast.deeXVrayFastUI()

Deex Vray Fast is free

You can download the tool here :

http://deex.info/wordpress2/tools/deex-vray-fast/

Please don't hesitate to discuss on presets, share your presets, give requests and found bugs.
Update is easy, just click on "about" and..."update".

Thanks, Deex.


A noté que, en temps que lighter TD/LookDev TD renderman/vray4maya/mentalray, j'aimerais bouger en 2012 au Canada ou USA.
Voilà.

Bravo....

Hey,
Juste pour signaler qu'il y a eu plein d'updates entre temps.

Je copie le change log, de bas en haut :

Code:


###      v0.65   Modified : shader auto connect : shader must have the same name
###                    like the slot name
###            Modified : image resolution slider removed
###            Features : add API to use the tool without interface
###                    import deeXVrayFast
###                    deeXVrayFast.deeXVrayFastUtils(quality = 10, preset = "deeX_exterior", saveSettings = True)
###                    Will set the quality to 10 with preset deeX_exterior, saveSettings before
###                    deeXVrayFast.deeXVrayFastUtils(backSettings = True)
###                    Will reset your setting
###            Features : add automatic multimatte ID generation on material ID
###            Features : object ID tool. Generate objectID automatically on mesh.
###                    The generated ID is unique, based of the md5
###                    of the name of the mesh.
###                    Name space is supported.
###            Bug Fix  : fix the UI resize
###            Bug Fix  : fix material ID on selection
###      v0.6   Features : you can "dock" the window
###            Features : UI optimization
###            Features : material ID tool. Generate materialID automatically.
###                    The generated color is unique, based of the md5
###                    of the name of the shader or shading engine.
###                    Name space is supported.
###      v0.55   Bug fix : skip locked attributes on "back to my saved settings"
###            Bug fix : found the correct VRAY_TOOLS environment
###            Bug fix : interface : correct fast control GI menu
###            Features : textures to tiled exr, add revert option
###      v0.5   First release

Pour l'instant plus de 700 downloads uniques en moins de 2 mois

Grosse update today.
Je copie in english, comme d'hab :
Hi all,
Big update !
Yesterday it was my birthday and i decide to give a nice update of the tool (ahah).
I spent a lot of time to create the v0.7. I re-code some features.

Code:

Bug Fix : fix the fast control UI
Bug Fix : fix the vraySettings lockNode
Bug Fix : fix add material ID on all materials button Modified : use hashlib module and remove deprecated md5 module

Code:

Features : add a full API to use the tool without interface
doc here : http://deex.info/deeXVrayFast/doc/html/

Big feature : Now we have a real API. You can set the quality in command line but you can use all tool of the DeeX Vray Fast in command line !

Code:

Features : add auto update checker (each 15 days)

Every 15 days, the tool will check if you have the last version.

Code:

Features : add automatic preCompositing generator for Nuke

Big feature : You can generate Nuke files !
All is based on presets. I create 5 presets for you.
It is an advanced "Vray to Nuke".
You rendered images is automatically pre-composited.



Hope you like.
DeeX.

C'est boooon ca :-)

Pourquoi je bosses sur max maintenant moi >_<

Enfin de la technique.
C'est parti.

Donc le code ici : http://deex.info/deeXVrayFast/doc/html/dee_x_vray_fast_8py_source.html

Kender a écrit:
Laisse la communaute la ou elle est. Elle a rien a faire la puisqu on parle de toi.
Je ne juge pas le code de tes collegues, mais le tiens.
Je juge le code python que tu postes. S ils ont travaille dessus, mets leurs noms alors. Mais j ai plus l impression qu ils ont bosse sur le cote cpp/mi du projet.
Je peux pas faire une code review complete parce que ca prendrai trop de temp, mais voila ce que a premiere vue je pense qu il faudrait ameliorer

• Les imports non conditionnel se mettent en tete de code pour faciliter le debugging et la gestion des dependences.
  
• L utilisation de pymel ne me semble pas pertinent ici. un cmds.setAttr faisant l affaire.
  
• Enleve le prefix deex. Ton tag est deja sur le nom du projet. Ca allegera tes noms de classe/variable.
  
• Premiere lettre des classes en lettre capitale. C'est mineur mais c'est la convention.
  
• ne return pas apres un raise. Le raise te fais sortir de la methode.
  
• Pour simplifier le debugging, essaie d utiliser un seul return par method/function
  
• deexVrayFastUpdater pourrait tout simplement etre une function update(parent)
  
• utilise le moteur interne de documentation de python (docstring) pour aider l utilisation de ton code.
  
• 1 classe par fichier. Ca clarrifie enormement le code. Il est tres difficile de lire un fichier de 3000 lignes.
  
• essaie d utiliser le pattern VMC (http://en.wikipedia.org/wiki/Model–view–controller) permettant de separer ta GUI et ta logique. Ca aide pour le debugging.
  
• c'est plus pythonic de faire '%s de ma mere' %string que string + 'de ma mere'
  
• essaie de suivre la google code convention (http://google-styleguide.googlecode.com/svn/trunk/pyguide.html) elle est tres bien faites.
  

Les imports non conditionnel se mettent en tete de code pour faciliter le debugging et la gestion des dependences.

La seule parti de code ou il y a des import "dans le code", c'est dans la class deexVrayFastUpdater, ligne 93.
Ce code ...... n'est pas de moi.
En effet, il a été donné gracieusement ici : http://blog.boxedice.com/2009/04/11/python-auto-update-mechanism/
Alors au début je me suis posé la même question que toi : des import dans du code, bizarre.
Puis j'ai vu que c'était des imports conditionnel, genre ligne 136, 147.
Puis je suis tombé sur la ligne 162. Et la, je me posais la question : dois je le laisser, ou dois je supprimer ?
J'ai cherché sur le net et la, aucune idée. Il y en a qui dise oui, d'autre non.
Donc moi même j'en sais rien. Doit on importer un module des le départ, même si on l'utilise pas (comme l'update) ?
Toi tu dis oui donc.
Bon, faisons alors....

L utilisation de pymel ne me semble pas pertinent ici. un cmds.setAttr faisant l affaire.

Le seul endroit ou j'utilise Pymel étant ligne 1300.
Hors, si tu avais lu le code, ceci est fait exprès et pertinent.
En effet, je récupère un dictionnaire avec des noms d'attributs, ainsi que leur valeurs.
Hors, en cmds.setAttr, quand tu dois donc setter un attribut, tu dois préciser le type. Genre cmds.setAttr ("prout.prout", "bla", type = "string")
Hors, ne stockant pas le type d'attribut dans le dico (question de rapidité), je ne peux donc pas récuper donc le type de l'attribut.
Et la magie : PyMel n'a pas besoin de précisé le type pour pouvoir setter un attribut.
Mais si t'as une autre vision pour aborder le problème (sans stocker le type bien sur).

Enleve le prefix deex. Ton tag est deja sur le nom du projet. Ca allegera tes noms de classe/variable

Je veux bien te croire que ça allège. Mais moi les Dev a qui j'ai demandé m'ont toujours dit le contraire.
Mettre toujours le nom du projet devant ta class, nom de bouton, etc etc.
Class en effet, d'après moi, ça sert a rien. Par contre bouton, ça évite d'avoir des clash avec d'autre outil.
Il est plus sécurisant d'avoir un bouton qui s'appelle "deeXVrayFast_spool_BT", que "spool_BT". Il suffit qu'il est le même nom de bouton dans une autre interface Maya, et la, boom. Sachant que je suis obligé de récupérer les nom de .ui (vu qu'il est chargé a la volé).
Les boutons créés nom pas dans le UI, mais dans le code, la ok. Mais c'est quasi déjà fait ça.

Premiere lettre des classes en lettre capitale. C'est mineur mais c'est la convention.

Ouai enfin ça, y'a quand même plus important. Donc oui, mineur, pour ne pas dire, très mineur.

ne return pas apres un raise. Le raise te fais sortir de la methode.

Alors la faudra me dire ou tu as vu du raise. J'ai beau faire ctrl+f, il y aucun raise nul part.

Pour simplifier le debugging, essaie d utiliser un seul return par method/function

Ouai enfin, je vois pas comment je peux évité des returns comme ça :

Code:

if len(textureFiles) == 0 or textureFiles is None:
    OpenMaya.MGlobal.displayError("No file(s) node(s) selected or found.")
    return
for textureFile in textureFiles:
    blala

Faut bien que je check ici, par exemple, qu'une liste de texture est donné.
Donc, on fait comment ?

Ca ?

Code:


jeDoisReturn = False
if len(textureFiles) == 0 or textureFiles is None:
    OpenMaya.MGlobal.displayError("No file(s) node(s) selected or found.")
    jeDoisReturn = True
for textureFile in textureFiles:
    blala
If jeDoisReturn:
    return


(je pense pas)

deexVrayFastUpdater pourrait tout simplement etre une function update(parent)

Mais si je veux updater l'outils (avec API), sans charger le core, faut bien que je le sépare non ?
Car si je le mets dans le core, je devrais être obligé de créer l'objet du core.
So ?

utilise le moteur interne de documentation de python (docstring) pour aider l utilisation de ton code.

Pourquoi doxygen c'est pas bien ?

1 classe par fichier. Ca clarrifie enormement le code. Il est tres difficile de lire un fichier de 3000 lignes.

La je suis d'accord. Mais vu qu'une class a elle seule prends 2600 lignes, je me suis dit, vu la tailles des autres, autant les laisser.
Je pourrais les virer, mais il y aura toujours 2600 lignes.

essaie d utiliser le pattern VMC (http://en.wikipedia.org/wiki/Model–view–controller) permettant de separer ta GUI et ta logique. Ca aide pour le debugging.

Je ne comprends pas. Ma GUI est dans une class, le core dans une autre. C'est de ça dont tu parles ou ça va plus "loin" ?

c'est plus pythonic de faire '%s de ma mere' %string que string + 'de ma mere'

Ouai bon la, faut pas déconner. Si c'est juste ça -_-.
Je préfère largement ça :

Code:

 string1 + string2 + string3 + string4 + 'de ma mere' + string6 + string7

Que :

Code:

  '%s %s %s %s de ma mere %s %s'%(string1, string2, string3, string4, string6, string7)

Pour moi c'est moins lisible, faut compter qui va ou, etc etc..

essaie de suivre la google code convention (http://google-styleguide.googlecode.com/svn/trunk/pyguide.html) elle est tres bien faites.

J'essayerais.

Merci =).

J ai pas eut le temps de te repondre

je fais ca dans la semaine

desole

K

Deex a écrit:

L utilisation de pymel ne me semble pas pertinent ici. un cmds.setAttr faisant l affaire.

Le seul endroit ou j'utilise Pymel étant ligne 1300.
Hors, si tu avais lu le code, ceci est fait exprès et pertinent.
En effet, je récupère un dictionnaire avec des noms d'attributs, ainsi que leur valeurs.
Hors, en cmds.setAttr, quand tu dois donc setter un attribut, tu dois préciser le type. Genre cmds.setAttr ("prout.prout", "bla", type = "string")
Hors, ne stockant pas le type d'attribut dans le dico (question de rapidité), je ne peux donc pas récuper donc le type de l'attribut.
Et la magie : PyMel n'a pas besoin de précisé le type pour pouvoir setter un attribut.
Mais si t'as une autre vision pour aborder le problème (sans stocker le type bien sur).

Ouais donc y a un interet. Meme si je comprends pas trop la question de rapidite pour le dico.
Il faudrait donc juste que tu commentes ton code avec cette explication vu que pymel est pas encore tres implemente, ca aidera la comprehension.

Deex a écrit:

Enleve le prefix deex. Ton tag est deja sur le nom du projet. Ca allegera tes noms de classe/variable

Je veux bien te croire que ça allège. Mais moi les Dev a qui j'ai demandé m'ont toujours dit le contraire.
Mettre toujours le nom du projet devant ta class, nom de bouton, etc etc.
Class en effet, d'après moi, ça sert a rien. Par contre bouton, ça évite d'avoir des clash avec d'autre outil.
Il est plus sécurisant d'avoir un bouton qui s'appelle "deeXVrayFast_spool_BT", que "spool_BT". Il suffit qu'il est le même nom de bouton dans une autre interface Maya, et la, boom. Sachant que je suis obligé de récupérer les nom de .ui (vu qu'il est chargé a la volé).
Les boutons créés nom pas dans le UI, mais dans le code, la ok. Mais c'est quasi déjà fait ça.

tes modules ont des names spaces du a leur import:
from deexFastVRay import Class1
from deexFastVRay import Class2
donc normalement pas de probleme.

Depuis 5 ans, j ai pas eu de clash de nom en utilisant les imports.

Deex a écrit:

Premiere lettre des classes en lettre capitale. C'est mineur mais c'est la convention.

Ouai enfin ça, y'a quand même plus important. Donc oui, mineur, pour ne pas dire, très mineur.

pas si mineur. Si c'est dans les conventions ca a du etre penser.
Par exemple :
test = test() # retour d une fonction
test = Test() # instance d un object
c'est tres clair comme ca.

Deex a écrit:

ne return pas apres un raise. Le raise te fais sortir de la methode.

Alors la faudra me dire ou tu as vu du raise. J'ai beau faire ctrl+f, il y aucun raise nul part.

My bad. Je croyais que les try/except faisait un raise.

Deex a écrit:

Pour simplifier le debugging, essaie d utiliser un seul return par method/function

Ouai enfin, je vois pas comment je peux évité des returns comme ça :

Code:

if len(textureFiles) == 0 or textureFiles is None:
    OpenMaya.MGlobal.displayError("No file(s) node(s) selected or found.")
    return
for textureFile in textureFiles:
    blala

Faut bien que je check ici, par exemple, qu'une liste de texture est donné.
Donc, on fait comment ?

Ca ?

Code:


jeDoisReturn = False
if len(textureFiles) == 0 or textureFiles is None:
    OpenMaya.MGlobal.displayError("No file(s) node(s) selected or found.")
    jeDoisReturn = True
for textureFile in textureFiles:
    blala
If jeDoisReturn:
    return


(je pense pas)

Code:


if textureFiles :
    for textureFile in textureFiles:
        blabla
else :
    OpenMaya.MGlobal.displayError("No file(s) node(s) selected or found.")

return bool(textureFiles)


question pourquoi textureFiles peut etre a la fois une liste ou None. Une variable devrait toujours garder le meme type.

Deex a écrit:

deexVrayFastUpdater pourrait tout simplement etre une function update(parent)

Mais si je veux updater l'outils (avec API), sans charger le core, faut bien que je le sépare non ?
Car si je le mets dans le core, je devrais être obligé de créer l'objet du core.
So ?

from deexVrayFast import deexVrayFastUpdater
deexVrayFastUpdater(parent)
et tu as l affaire.

Deex a écrit:

utilise le moteur interne de documentation de python (docstring) pour aider l utilisation de ton code.

Pourquoi doxygen c'est pas bien ?

Si mais tu devrais utiliser la generation de doxygen a partir des docstrings.
Bonus des docstrings est quelles sont embarquees avec le code.

Deex a écrit:

1 classe par fichier. Ca clarrifie enormement le code. Il est tres difficile de lire un fichier de 3000 lignes.

La je suis d'accord. Mais vu qu'une class a elle seule prends 2600 lignes, je me suis dit, vu la tailles des autres, autant les laisser.
Je pourrais les virer, mais il y aura toujours 2600 lignes.

Il faudrait surement aussi repenser la classe de 2600 lignes.
1 classe = 1 concept.
cette classe peut etre des redefinitions d autre classe :

Code:

class Velomoteur(velo): # velo donnant les methodes d un vehicule a 2 roue, mais velomoteur ajoute les methodes de moteur


ou ca peut etre une composition de plusieurs classes :
comme le sont les GUI en pyQT

Code:


class moteur(object):
  def __init__(self):
      self.cylindre = Cylindre()
      ...


ca permet d alleger le code et que chaque classe se concentre sur son concept.

Deex a écrit:

essaie d utiliser le pattern VMC (http://en.wikipedia.org/wiki/Model–view–controller) permettant de separer ta GUI et ta logique. Ca aide pour le debugging.

Je ne comprends pas. Ma GUI est dans une class, le core dans une autre. C'est de ça dont tu parles ou ça va plus "loin" ?

Il faut rajouter le controleur, il est primodial.
Dans ce concept, une interface bien codee n'a pas de if dans son code (oui c'est chaud).

Deex a écrit:

c'est plus pythonic de faire '%s de ma mere' %string que string + 'de ma mere'

Ouai bon la, faut pas déconner. Si c'est juste ça -_-.
Je préfère largement ça :

Code:

 string1 + string2 + string3 + string4 + 'de ma mere' + string6 + string7

Que :

Code:

  '%s %s %s %s de ma mere %s %s'%(string1, string2, string3, string4, string6, string7)

Pour moi c'est moins lisible, faut compter qui va ou, etc etc..

je prefere (mais c'est encore autre chose)

Code:

' '.join([
  string1,
  string2,
  string3,
  string4,
  'de ma mere',
  #string5, (javais pas vu qu il fallait pas de string5
  string6,
  string7
])


%s va beau plus vite mais aussi permet de formater:

Code:


%d %1
>1
%04d %1
>0001

%-5s %-5s %-5s. %('a', 'aa', 'aaa')
>>a    aa  aaa  . (4 espaces apres 'a', 3 apres 'aa', 2 apres 'aaa')
%-5s %-5s %-5s %('aaa', 'aaa', 'aaa')
>>aaa  aaa  aaa  . (2 espaces  apres chaque 'aaa')


hope it helps
k

My bad. Je croyais que les try/except faisait un raise.

Ça doit toujours le faire genre c'était ironique ou on peut mettre des return dans des try quand même ?

question pourquoi textureFiles peut etre a la fois une liste ou None. Une variable devrait toujours garder le meme type.

Parce que dans Maya, des fois une fonction renvoie un None, et des fois une liste vide. Et ça, j'ai jamais compris pourquoi. Du coup, je mets les deux, au moins..
Si d'ailleurs tu as une explication sur ça, je prends.

Si mais tu devrais utiliser la generation de doxygen a partir des docstrings.
Bonus des docstrings est quelles sont embarquees avec le code.

Les docstrings, c'est bien le genre de truc a la ligne 3384 ?
Parce que je génère mon doxygen avec ça.

Deex a écrit:
Ça doit toujours le faire genre c'était ironique ou on peut mettre des return dans des try quand même ?

Non C'est pas ironique ici. C'est juste que dans les try/except je fais soit un pass soit un raise.

Deex a écrit:

question pourquoi textureFiles peut etre a la fois une liste ou None. Une variable devrait toujours garder le meme type.

Parce que dans Maya, des fois une fonction renvoie un None, et des fois une liste vide. Et ça, j'ai jamais compris pourquoi. Du coup, je mets les deux, au moins..
Si d'ailleurs tu as une explication sur ça, je prends.

Tu aurais un exemple de fonction comme ca dans maya ?
Autrement je garde ma position, None c'est un object vide.

Deex a écrit:

Si mais tu devrais utiliser la generation de doxygen a partir des docstrings.
Bonus des docstrings est quelles sont embarquees avec le code.

Les docstrings, c'est bien le genre de truc a la ligne 3384 ?
Parce que je génère mon doxygen avec ça.

Oui voila. Desole j etais pas alle jusque la.

K

Kender a écrit:

Deex a écrit:

question pourquoi textureFiles peut etre a la fois une liste ou None. Une variable devrait toujours garder le meme type.

Parce que dans Maya, des fois une fonction renvoie un None, et des fois une liste vide. Et ça, j'ai jamais compris pourquoi. Du coup, je mets les deux, au moins..
Si d'ailleurs tu as une explication sur ça, je prends.

Tu aurais un exemple de fonction comme ca dans maya ?
Autrement je garde ma position, None c'est un object vide.

Je viens de voir que cmds.listRelatives retourne None si aucun relatives ne sont trouves
Ce comportement n'est pas lie a python mais au fait que cmds appelle mel.
Donc on devrait faire toujours:
shapes = cmds.listRelatives(parent) or []
pour toujours avoir une liste et pas avoir des cas ou None sort.