Reprise du message précédent :
Salut!
 
Les shaders Mental Ray sont écrit en C et non en C++. Ensuite Mental ray intègre aussi un langage de script pour la programmation des shaders, le MetaSL.
Ensuite concernant Python hum hum! Ce langage est selon moi beaucoup plus compliqué que le C et le C++ notamment en raison de sa syntaxe déroutante et du fait qu'il soit encore plus OO que le C++. Le seul avantage du Python par rapport au C++, encore selon moi, c'est que il est interprété et donc pas besoin de la compiler. Ensuite que le code soit interprété ou compilé de toute façon il doit être débuggé.
Donc le fait de baser ta critique de Mental ray sur ses possibilités en programmation en avançant tes arguments douteux voire faux m'étonne.
 
Après renderman est le standard de l'industrie et c'est sans doute mérité mais de la à cracher sur MR faut pas abuser. De toute façon ces moteurs sont complètement différents ne serait ce que parce que Mental Ray est un raytracer natif(hybride en réalité) alors que Renderman est basé sur une autre technologie.
 
Renderman est sûrement meilleur que MR pour ce qui est de la souplesse d'intégration dans un pipeline ciné mais ça ne fait pas de Mental Ray une merde hein^^
Chacun trouve son compte dans son outil.
 
Houdini par exemple balade Maya niveau dynamiques c'est pas pour autant que Maya c'est de la merde. Faut pas abuser.

ATttention ne confond pas des vessies avec des lanternes, je n'ai jamais dit que mental ray etait une grosse merde qu'il ne faut pas utiliser en prod. SI ca vous amuse de passer deux jours a ecrire un shader en C ( j'ai l'habitude de dire C++ parce que c'est la même chose pour moi.C'est comme ceux qui disent TéCéL alors qu'on dit du tikkle, on va pas rentrer dans le débat, piton ou pailletonne? t'inquiete je sais la différence pour m'en bouffer un max dans mes dso renderman, ne jouons pas sur les mots.)
 
Il est clair que aucun studio n'utilise mental ray en dev interne ce n'est pas pour rien, c'est juste que c'est super pas pratique, que mental ray est bourré de petites bouses sur lesquels t'es obligé de butter pendant que tu devellope et code, et voila pourquoi c'est avant tout pour moi une grosse bouse, faite de pleins de petites bouses, attention ce n'est pas un moteur de rendu de merde pour autant. Sa qualité est très bonne, il est rapide en raytrace et il a su copier pas mal des features de rendermand'aillerus a travers les années, pour se rendre un peu plus productif en prod, mais il aura toujours un gros incovenient sur renderman et c'est pourquoi il ne sera jamais leader dans lindustrie du vfx c'est qu'il ne peut pas rendre des scenes avec beaucoup de géometrie sans demander des ressources énormes. Et la je vous parle même pas d'aller tracer du raytrace parce que ca on y pense même pas, donc oui mental ray est un hybrid scanline, raytrace, mais bon il fait quand même tout son rendu en trace sampling la grande majorité du temps, ensuite son antialiasing est très très loin dérrière renderman, tout comme son sampling. Maintenant si en prod les devs veulent se prendre la tronche des nuits sur leur code C pour coder un moindre shader parce que la dead line approche c'est leur probleme mais bon c'est pas etonnant que ya des boites qui utilisent mental ray qui bossent toujours 24h sur 24 et qui ont des artistes qui divorcent au bout de 2 ans de taff. hihi et oui on en connait un paquet je ne citerais pas de nom.... avec prman tu peux designer un pipeline entier de shader en une semaine et je parle ici de shader très complexes, Après il est clair que mental ray est un bon rendu si on veut pas rendre ni de particules, ni de fluids, ni de subsurface scattering , ni de heavy scene, ni de fur, ni des occlusions sur des grosses scenes, ni du displacement, ni du motion blur, ni du dof 3d, ni des texture super détaillés en 8k, ni des cheveux... ah ouai bon c'est clair pour rendre de la GI c'est pas mal quoi que faut pas l'animer sinon c'est flick land !! EN gros pour rendre des super belle images fixe mental ray c'est genial, ca je suis entierement d'accord, mais je crois que au boulot ils en veulent 24 par secondes des images fixes et souvent ya beaucoup de secondes aussi a calculer donc bon pas top hein? ;-)
 
moi j'ai choisi renderman parce que je me rend compte que non seulement il moufte jamais mais en plus je peux bosser mes 8 h par jours sans flipper d'être charrette, je reviens le lendemain il m'a tout calculer en HD avec la moblur, les millions de poils, de polygons, de particules, le tout séparé sur des passes aovs que je lui ai moi même définie qui vont ravir le mec du flame qui va se pointer a midi les doigts de pieds en éventails... ( hihi yen a qui se sont reconnu? ;o))
Voila tout ca pour dire que l'un et l'autre sont très bon dans un certain domaine, mais mental ray reste et sera toujours très a la traine par rapport a renderman sur tout ce qui concerne la productivité, la performance, l'optimization et la reliabilité avec un pipeline custom. C'est juste un gros soft vraiment pas pratique à utiliser a mon niveau et je lui trouve aucun atout majeur pour me séduire et me faire revenir dessus même de temps en temps, même si je trouve que c'est un super moteur de rendu. Pour moi il reste ces espèces de grosses bouses que tu te traine pendant des années sous tes pompes et qui t'empeste la vie et celle de ton entourage, qui n'evolue jamais, parce que mental ray n'evolue pas du côté de ses défauts et ca c'est un énorme tord à mon avis. Et la ou pixar devellope renderman avec un esprit pour le devellopment et l'ouverture à l'evolution mental ray se renferme sur ses utilisateurs en proposant avant tout des choses préintégrés qui sont de plus en plus difficilement débridable, modifiable, customisable ou extensible avec de la prog. Je trouve ca super dommage pour un moteur de ce niveau.
 
Quand à l'atout du python par rapport au C, peut etre que tu est programmeur C donc forcement pour toi ca coule de source ce language mais moi je trouve ca super relou le C et le C++, alors que le python a une logique tres simple et un code tres facile et rapide a apprendre.( en tt cas je galere toujours en C alors qu'en python je commence a bien maitriser et j'en fais depuis moins longtemps pourtant.)Apres c'est peut etre une histoire d'individu, ya des mecs doués pour le code, d'autres plus pour le devellopement, dautres les maths, d'autre la recherche, dure de savoir tout faire bien. c'est pareil le fait de ne rien avoir a compiler c'est un gain de temps enorme en debugging, que de sans arret recompiler ses codes C pour les debugger. Encore la on est dans le gain de productivité que j'affectionne avant tout,et moins tu passes du temps a coder plus tu as du temps pour toi ou reflechir a des implentations et ca encore c'est un gain majeur de productivité et d'optimization.( de plus si t'as des gosses et une femme ils sont content) Quand au metaSL ouai c'est clair tu as raison mais bon mental mill est une espece de copie du RSL et du slim de pixar avec des accents de gsl qui a lui meme été pompé sur le rsl, encore une foi c'est bien beau de sortir des languages de prog et des outils mais bon y'en a deja un qui est la depuis presque 30 ans et qui est toujours aussi performant, donc pourquoi aller ailleurs quand c'est pour retomber vite dans les problemes liés au language GPU tres limité ou a mental ray trés limité aussi. Donc voila en résumé pour la paix des ménages optez plutot pour renderman....  
 
Mais bon j'ai noté tes remarques très pertinantes. Et je suis d'accord avec toi pour houdini en dynamic, par contre houdini c'est un peu comme ma grand mère , tu peux pas le mettre entre toutes les mains, alors que maya c'est quand même un peu plus accéssible. Rare sont les grosses prods faitent entièrement de A à Z sous houdini a part celles de dynamic. Mais la encore houdini à des faiblesses, et même beaucoups mais bon c'est comme tout hein, c'est pour les défauts qu'on adore tant nos softs.

Hello!
 
En tout cas tu défends bien tes points de vue. Ça fait plaisir de voir un gars qui passe du temps à argumenter.  
 
Pour Houdini c'est sûr que ce n'est pas un outil artist friendly et je trouve ça dommage qu'il ne perce pas en France car c'est le soft 3D le plus impressionnant que j'ai vu. Et j'aime bien la mentalité des gens de SideFX alors que ne peut pas en dire autant d'Autodesk...
Pour Maya c'est certes plus abordable mais il faut mettre la main dans le cambouis pour en faire vraiment quelque chose sinon autant utiliser 3ds Max^^
En tout cas j'attends de voir ce que donne les nParticle et voir comment ça va se compléter avec le nCloth en attendant la réunification complète des solvers de dynamique.
 
Sur le Python tu as raison moi je connais le C/C++ donc c'est clair que ce langage est un peu obscur pour moi. Ceci dit je vais m'y mettre car ça devient le standard en script.
 
EDIT:
 
le C++ c'est pas tout à fait la même chose que le C. La logique de programmation n'est pas la même: d'un côté c'est du procédural(C) et de l'autre c'est orienté objet(C++).

hé bien, quel débat passionné. En tout cas, tout ceci m'a donné envie de jeter un coup d'oeil du côté de renderman. Je me suis procuré la version d'essai (du plugin pour maya) et un petit digital tutor. Alors bien sûr ça ne parle pas de codage de shader à fond mais la logique de ce moteur de rendu m'apparait, et j'ai l'impression qu'elle va me plaire
 
Bon je pense que je laisserais pas tomber MR pour autant, j'y suis bien habitué et si on le caresse dans le sens du poil il veut bien nous sortir des séquences d'images qui ne flick pas
 
et sinon puisque c'est le but du topic : http://usa.autodesk.com/adsk/servl [...] d=11804202  
voilà pour les features de maya 2009 ! Le système nParticles parait vraiment génial à utiliser !  

Oui clairement, le flicking sous Mr, c'est de l'histoire ancienne totu ça ;-)

Bon les nParticles ça arrache bien sa mère.
Sinon confirmation, par un ingénieur d'Autodesk^^, que Maya n'est pas multithreadé.

 
 
 
 
Maya 10.0 (ans) :
 
- Improved display performance for geometry due to additional multithreading.
 
- The lattice deformer is now multithreaded.
 
- The wire deformer solver is now multithreaded.
 
- The Fluids surface emitter is now multithreaded.
 
- Polygon UV smoothing is now now better multithreaded to improve performance on systems with 4 or more cores.
 
 
Maya 7.0 -> 9.0 :
http://www.3dvf.com/forum/3dvf/Res [...] .htm#t1326
 
 

Le moteur de dynamics ainsi que nucleus ne sont PAS multithreadés.
 
Perso ça me fait une belle jambe de savoir que les lattices le sont^^

 
ne dit pas ca...
ca peut servir un jour !!!

Entre cette affirmation :
 "Sinon confirmation, par un ingénieur d'Autodesk^^, que Maya n'est pas multithreadé."
 
 et "Le moteur de dynamics ainsi que nucleus ne sont PAS multithreadés."
 
C'est le grand écart, Skelter ^^
 
 
Maya Dynamics / nDynamics (nCache = 2 threads) :
 
Comme pour Houdini, pas de multithreading.

Nettoyage, on se calme ici