lundi 29 novembre 2010

Derniere version de Vénus avant redesign complet

Voila aujourd'hui annonce la fin de vénus tel que nous l'avions pensez jusqu'ici. Nous sortons donc une dernière alpha avant une grande traversé du désert correspondant a une évolution complète du moteur.
La raison principale est que nous nous sommes recentré vers une nouvelle voie.
Cette dernière version de vénus possède donc quelques améliorations importantes avant une transition définitive.

Un redesign complet :


J'ai passé pas mal de temps a re-designer vénus comme je le voyais dans l'avenir et comme nous sommes tombé d'accord, nous avons décidé de prendre la voie de cette nouvelle roadmap pour les deux ans qui arrivent.
Pour rappel Vénus est un raytracer, dans le style de pantaray ou arnold avec la capacité de passer en architecture REYES, ala renderman. Le raytracer est extrêmement optimisé mais malgré cela certains effets sont tres couteux a rendre comme le displacement, le fur, la full global illumination sur des scènes typique de production. Voila pourquoi nous nous sommes penché sur la possibilité de pouvoir utiliser aussi du REYES notamment afin d'utiliser les techniques de pointbased et de pointcloud. Nous avons ensuite exploré un peu plus les techniques de sphérical harmonics et cela nous a fait prendre conscience de la puissance de toutes ces méthodes combinées en prod. Voila pourquoi nous avons changer notre fusil d'épaule et que nous allons faire évoluer vénus en un moteur de nouvelle génération.
Notre but est au final de proposer un produit interactif capable de rendre des milliards de polygons le plus rapidement possible avec un feedback interactif lors du lighting et re-rendering.
Nous avons donc décidé que Vénus allait se transformer en un moteur capable de faire du rendu intéractif, mais de façon transparente. Pour cela nous allons resté sur un concept efficace utilisant principalement le CPU, avec toujours quelques utilisations open cl du gpu cependant, un système de caching propriétaire permettant l'édition de tous les paramètres du rendu en interactif. Il sera évidemment possible d'utiliser vénus en pure raytracer, ou en hybrid reyes. Chacun ayant évidemment ses avantages et inconvénients. Nous avons développé des systèmes très performants pour le calcul interactif de la GI/occlusion/HDRI/SSS/Reflection/Refraction/Shadow et nous avons hâte d'implémenter tout cela dans un même moteur.
Concernant le moteur lui même nous voulons qu'il puissent supporter les RIB et la Rispec de renderman le plus possible, et c'est un très long travail, voila pourquoi pour le moment nous avons décidé de ne pas implémenter les fonctions volumétriques de renderman mais plutôt nous concentrer sur la géométrie et les surfaces primitives.
Nous nous donnons donc 1 an et demi  à 2 ans pour sortir une version beta de ce nouveau Vénus, avec pour but de pouvoir rendre une scène de la complexité "d'avatar" en interactif sur une machine normale. Je prend avatar en exemple car a ce jour c'est surement ce qu'on a vue de plus complexe a rendre en production.
Nous sommes en train d'implémenter le RSL, donc le langage de shading sera identique a renderman avec quelques améliorations surtout au niveau de l'importance sampling du raytrace, et de certaines fonctions plus évoluées que nous avons deja développées dans le moteur.
Nous avons bon espoir au vue des résultats comparatifs que nous obtenons avec Vénus, comparé à Arnold, Prman, 3delight, Vray, Maxwell, Modo, Mental ray ou Iray. Nous sommes déja bien plus rapide dans tous les situations testées. Cela est simplement due à notre structure moderne, entièrement multithreadée, ultra optimisée tirant parti de toute la puissance de votre machine. Nous possédons un système de cache propriétaire, ainsi qu'un système de pointcloud avancé, et nous travaillons sur notre système de Deepshadow et sur les Ptex afin de les faire évoluer un peu plus, Nous avons aussi mis au point un système de brickcache.

Nous allons recoder l'interface pour permettre une meilleure édition des scènes en interactif. Nous allons aussi améliorer le plugin de cache venant de maya en ajoutant un support de softimage et 3dsmax direct.
Nous ne souhaitons pas faire tout dans maya, softimage ou 3dsmax simplement parce que maya est pas optimisé et consomme beaucoup de ram pour rien, voila pourquoi pour nous la solution standalone est plus efficace pour de la production en lighting/shading.

Pour le moment ce projet n'est pas a but commercial, ni même open source, il reste donc au bon vouloir de son propriétaire d'en faire ce qu'il veut, donc nous verrons si les choses évoluent positivement dans un ou deux ans. En attendant je vous tiendrais informé des avancés et j'espère vous gratifier de quelques rendus sympa, si j'ai un peu de temps.

@ plus

mercredi 17 novembre 2010

Pixar baisse ses prix !

Voila une nouvelle que l'on attendait plus, mais pixar sait toujours comment nous surprendre. Il viennent en effet d'annoncer avant hier qu'ils baissaient les prix de Renderman pro server. Les prix de la license passent de 3500$ à 2000$ et la maintenance annuelle de 700 à 600$, soit une sacré baisse. Ils font des grosses discount aussi en fonction du nombre de licenses achetées allant de 5 à 50% pour un volume de 10 à 1000 licenses.
Pixar semble vouloir rester compétitif en baissant ses tarifs jusque là très chers. Il faut songer que récemment la concurrence se fait de plus en plus présente avec des produits de qualités qui vont arriver très bientôt. Ainsi the bakery relight et guerilla render ne sont pas encore officiellement commercialisé mais c'est pour bientôt. 3delight aussi est depuis quelques temps un sérieux concurrent a Prman et il ne faut pas oublier l'arrivé prochaine d'Arnold. Avec cette baisse Pixar annonce la couleure et jette un pavé dans la marre qui risque surement de forcer la concurrence a niveler ses prix avec Prman. Pro server est désormais moins cher que 3delight, son concurrent direct et risque d'offrir lors de la sortie finale du prochain pro server des fonctionnalités et une performance bien supérieure. Ce sont surtout les petits et moyens studios qui doivent etre content de cette nouvelle car cela coûte désormais 40% moins cher qu'avant pour s'equiper en Pro server, d'où un interet certains à se tourner aussi vers Prman.

Une très grande nouvelle donc.

vendredi 12 novembre 2010

Conférence "the Bakery" & pixar, the foundry.

J'ai eu la chance d'assister à ces deux conférences très sympa organisée par acm siggraph et progiss, et je dois dire que j'ai appris pleins de trucs. Bon déja avoir une teapot pixar mossieu potate collector, ca fait toujours plaisir offerte à la conférence pixar aux participants.
En ce qui concerne la conférence en ele même j'ai trouvé ça plutôt sympa, comme d'habitude dylan sisson ( de pixar) est très pro et présente bien renderman sous quelques examples concrets en production de toy story 3. Un régal, j'ai adoré le film.;) Bon pour le reste, on va dire que renderman studio 3, je l'ai éventré depuis quelques mois pendant la beta auqu'elle j'ai eu la chance de participé donc je connais bien ses qualités et ses défauts. Dylan a été malin de pas montrer le re-rendering pour eviter les problèmes, même si faut avouer que ça marche quand même plutôt bien pour regler ses lights. Par contre l'interface avec maya est pas toujours optimal et du coup ya parfois des bugs ou de la mauvaise communication entre maya et renderman. Mais je pense que c'est plus a cause de maya, qui n'est vraiment pas facile de faire tourner correctement avec des plugins. Dylan est revenu aussi sur le Ptex, en lui vantant tous les mérites, et ya de quoi. Le buffet du midi etait plutôt sympa même si j'en ai pas trop profité, et oui quand on papote...
Le reste de la journée concernait nuke et mari de the foundry et on a eu droit à des démos, sympa, même si on fait abstraction des plantages dues aux grosses scènes de production d'avatar et de transformers 2.
Mari est très impréssionant pour un outil si jeune et l'envi d'évolution que renvoi les devs est plutot bon signe, par contre la mauvaise nouvelle etait que les Ptex étaient pas prévu pour de suite mais bientôt. Dommage de devoir attendre encore alors que mudbox les supporte deja à moitié.

Concernant la conférence the bakery, axé sur relight leur outil de rendu maison. Ce fut une bonne surprise, le rendu semble très performant et bien pensé pour la production. L'outil est intéractif et propose tous les avantages d'un renderman like, avec son architecture REYES. par contre j'aurais aimé voir plus de chose sur les possibilités de scripting, de shading, sur les rendus offline, son ouverture au pipeline, module custom, dso etc.... Cependant je leur souhaite de trouver leur public, car ce type de moteur est facile d'acces et propose les outils nécessaire a réaliser de bonnes productions. C'est un très bon produit qu'ils ont développer et on sent le sérieux et l'expérience des devs de the bakery.
Maintenant il va juste falloir qu'ils apprennent a le vendre, car la démo était confuse, répétitive et parfois ennuyante, certains témoignages etaient eux aussi peut être trop spontanée et evidemment c'est pas trop ce à quoi on s'attend quand on recherche un moteur de rendu, on veut avant tout en prendre plein les mirettes, et se dire wow, ca défonce c'est ce moteur que je veux sur ma production.

Je pense et j'espère que des qu'ils le commercialiseront ce sera un peu plus rodé et efficace au niveau de la présentation de leur outil, car leur produit est super et peut trouver son marché.

voila mon avis sur ces deux petites conférences toujours bien agréables proposées par acm siggraph et progiss dans le cas de celle de pixar.

Quelques news !

J'ai été quelques temps éloigné d'internet et donc j'en profite pour donner quelque nouveautés sur les avancés de Vénus, le moteur de rendu que je co-développe. Je le précise car le core principal du moteur n'est pas développer par moi mais quelqu'un de très doué dont je ne citerais pas le nom car il le ne souhaite pas mais il se reconnaitra.

Je précise aussi suite aux demandes que l'ont ma faite parvenir que ce moteur de rendu n'est pas un projet commercial, son auteur ne souhaite pas qu'il le devienne pour le moment donc il est uniquement développé à titre expérimental.

Vénus a pas mal évolué ces derniers mois puisque il supporte désormais les fichiers RIB de renderman. Il accepte toutes type de géometrie et tri ce qu'il ne comprend pas dans le rib en ne l'interpretant pas au rendu. Il propose désormais un primitive de curve avec option "ribbon" et "tube", allant plus loin que renderman sur les fonctions des curves.
Le code a été amélioré sur certaines parties et le GPU est moins utilisées qu'avant car les performances etaient moins bonnes que sur cpu. Néanmoins le Gpu est toujours utilisé pour beaucoup de petites choses qui accélère considérablement le rendu. L'importance sampling a encore été amélioré pour le raytrace et il faut encore moins de sample pour produire des résultats valable en production.
Vénus supporte maintenant un mode avancé pour les shadow, support des deep shadow avec ecriture arbitraire des données dans la deepshadow. Possibilité de faire des soft shadow avec les shadow map ou les deep shadow ( à la pixar avec plusieurs maps, ou avec une seule map) . Il ya aussi une nouvelle methode de shadow avec sphérical harmonics. Globalement Vénus devient de plus en plus tourné vers les sphérical harmonics. Le workflow de lighting peut désormais entièrement etre fait grâce à cette technique, performante et facile a mettre en cache. La future version proposera d'ailleurs un vrai system de caching avec calcul interactif des spherical harmonics. Cela aura pour but de ne pas recalculer toutes les infos de lighting ( GI, occlusion, Direct lighting...) à chaque changement d'éclairage.
La dernière version a aussi un meilleur support des caustics et autres techniques de photon map.
Le support de la motion blur et du depth of field n'est pas complet mais fonctionne et est très rapide.le shading rate motion permet de regler une valeure de shading rate plus élevé pour les objets flou.

Concernant l'interface Vénus proposera très bientôt une version de son shading language. La machine de compilation étant une torture a optimisé, cela prend du temps a développer mais on peut déja faire ses propres shader en .sl compiler en .slv ou meta .slip (le slip c'est un hommage a pixar slim...pour le shading authoring que je développe, j'espère qu'ils prendront pas ça mal.;)) et il supportera a terme les fichiers.slo (mais c'est pas encore définitif vue le nombre des fonctions renderman disponible en rsl.)... ou pas donc !
On propose un nouveau shader de fur forcément pour aller avec les poils. Ce shader est une approximation du dual scattering qui reste bien plus simple car ne requiere aucune prepasse ou calcul complexe, il supporte aussi la GI et occlusion via les spherical harmonics donc pas besoin de plus a mon goût. Nous supportons aussi désormais le vector displacement, normal map, les output arbitraires pour les shaders et tout plein de nouveaux opérateurs, le tout codable en python. On a aussi un meta shader qui permet de faire son propre code comme une slbox, on appel ça la blackbox. hommage a ce groupe mythic des années 90. ;) Le viewer supporte désormais l'edition des pointclouds à la volé, mais on travail encore deçu pour l'améliorer.

Concernant le futur, le moteur se tourne considérablement vers les sphérical harmonics, mais on est en train de mettre en place aussi un system de caching, ca fait longtemps que j'en avais envis seulement ya tant de choses a faire avant pour que le moteur marche déja comme on le souhaite. A terme notre but  est donc de pouvoir faire du rendu encore plus rapidement avec un feedback instantanée. Pour cela le caching des données est un vrai plus. on l'utilise déja depuis le début pour beaucoups de choses donc ce ne sera qu'une extension du procédé de base du core du moteur. le caching de toutes les données de lighting devrait donc être présent dans les prochaines versions. Par contre il faudra attendre quelques mois avant d'avoir la possibilité de faire ce qu'on appel du relighting interactif avec support de tous les fonctions de vénus. Avant cela il ya beaucoup encore a implémenter et améliorer. Nous allons encore ameliorer aussi dans la prochaine version la gestion des points clouds, actuellement vénus propose un system très intelligent pour gérer les pointcloud d'une scène. Vous pouvez en effet controler comment interagissent les pointclouds au rendu, leur contribution dans la scène et au rendu, avec un algorythm très optimisé qui permet de limiter la taille des pointcloud sur des énormes scènes tout en gardant la qualité optimal au rendu. La prochaine version proposera surement le LOD par pointcloud voir les brickmap qui sont en Work in progress actuellement.

Voila en ce qui concerne les dernieres infos concernant vénus 040a, la build actuelle. encore du boulot donc en perspective pour les mois qui viennent mais on avance et on s'éclate, sachant que ce projet est pour le fun. On a rien ni lui ni moi a y gagner a part de s'amuser a "nerder", même si il fait ça 1000 fois mieux que moi. ;).

mardi 28 septembre 2010

Vénus : version 37a !

Depuis hier nous avons enfin pu sortir une build v37a (la 37 ème build depuis le début du développement alpha) qui est le fruit de un mois et demi intensif de travail. Je vous présente globalement les fonctionnalités de cette nouvelle version. Comme je vous le disais das mon précédent billet, nous n'en sommes encore qu'au début du développement et le chemin reste long, cependant maintenant que l'optimisation est derrière nous, nous nous concentrons plus sur le développement des fonctionnalités propres à un moteur de rendu.

New feature v37a :

- New Python Binding function support.
- New Highly optimized photon Mapping engine for rendering caustics, global illumination, subsurface scattering, pointcloud support, multithreading support with new distribution algorythm (really fast and accurate result).
- New pointcloud BSSRDF support for rendering physical scattering effect into object.
- New Pointbased Reflection algorythm (color and occlusion support).
- New spectral light transport support for better photorealistic result.
- New Spectral sky model support.
- New physical Unit support.
- New physical/photometric light unit support.
- New stochastic opacity support, including opacity treshold.
- New "Hider" method for rendering (more to come...).
- New PTex texture format support. ( thanks to disney to release this as open source for our test)
- New utility to Read pointcloud files, PTCReader.
- New utility to Read Ptex files, PtexReader.
- New utility to Read Texture files, TexReader.
- New method for computing sampling over refraction.

Beta or incomplete feature :

- New method to compute complexe lighting from an environment map using spherical harmonics and point based. (we have more to test to implement this feature as complete package).

Improvements & enhancements :

- Raytracing is 3% faster than before, resulting from some bug fixes in the code.
- Sampling strategy is now 10% faster, resulting in some change in the code.
- Improved memory footprint use with instance object, resulting of a bug fix in the code.
- Area light and object lighting are now much more accurate.
- Checked support for last GPU from nvidia and ati, with maximum performance using open CL.
- Improvements in the GUI of the standalone application, lot of enhancement in open GL code resulting in faster UI preview.
- Pointcloud reading and writing times are faster.

Bugs fix :

- Corrected a bug resulting a crash when using some FBX file format.
- Corrected some small bug in the raytracing engine.
- Corrected a bug resulting in memory corruption on some case.
- Fixed some memory allocation issue.


Voila Il ya eu un travail colossal sur cette version qui offre des fonctions vraiment surprenante. Je dois dire que le binding python est redoutable car il permet de développer en python avec Vénus, de lancer des rendus ou appeler ses fonctions, le tout en python. Le photon mapping est aussi un grand plus car le moteur ne supportait pas les caustics, les paths tracer ne sont pas parfait pour rendre d'ailleur ce genre de chose c'est pour ça qu'on a implémenter les photons. Mais on peut aussi rendre toute la scène en photon et même le SSS. Le support du spectral permet de traiter les lumières de façon réalistes, tout comme le support des unités Lumens. A noter que cette version supporte le SSS comme dans renderman et aussi les Ptex. Je posterais bientôt quelques rendus simple que l'on peut faire avec la bête, Mais pour le moment ya encore du pain sur la planche.

mercredi 22 septembre 2010

Vénus : les fonctionnalités actuelles !

Je voulais vous présenter un peu aujourd'hui la liste des fonctionnalités présente dans Vénus. Cela fait plus d'un an que le projet est commencé et pour le moment les fonctionnalités semblent plutôt maigre. Nous avons préféré nous concentrer sur les performances et l'optimisation du core principale du moteur afin que celui ci soit optimal et que l'ont puisse ensuite se concentrer sur le reste et l'implémentation des fonctions.

Le Core :

Le moteur principal est un hybrid renderer, combinant un raytracer et un Reyes ( base de la technologie Renderman). Nous avons fait ce choix car nous sommes partis du raytracer et nous nous sommes vites rendus comptes que aussi puissant puisse être le raytracer, rendre des très grosses scènes avec du micro-displacement est bien moins performant qu'en utilisant la techno Reyes qui offre un algorythm très puissant pour ce genre de scénario. Ya rien à dire les raytracer n'offriront jamais la qualité et la finesse de rendu d'un Reyes en micro displacement. Notre second argument était que nous voulions baser notre moteur sur l'utilisation des pointcloud, pour baker et pour calculer en pointbased et biensur là encore, le Reyes offre des avantages considérables. Après donc plusieurs mois de travail, de recherche et surtout d'optimisations en tout genre nous en sommes arrivé au Core actuel de la version de Vénus. Vénus est un reyes, c'est a dire qu'il va subdiviser et optimiser la scène de rendu, par contre notre implémentation est différente et nos optimisations aussi du a l'utilisation intensive des pointclouds. Nous avons aussi développé une architecture qui est hautement parallélisée et fonctionne à la foi sur Cpu et Gpu en openCL. Seulement nous couplons certains calculs exécutés via Cpu et certains via Gpu en fonction des performances de ceux-ci.


Vénus core features :

 Reyes :

- Reyes architecture très optimisée. (Micro polygon et micro displacement)
- Support polygon, nurbs, subdvision (catmull-clark) surface.
- Stochastic sampling avec support des filtres Renderman (box, gaussian, mitchell, catmullrom, sinc)
- Reglage du pixel sample et pixel filter.
- Reglage du ShadingRate global. (gestion adaptative du dicing par algorithme)
- Support des pointclouds (écriture, lecture, traité en octree, optimisé pour consommer peu de ram).
- Depth map Shadow.
- Texture support (open exr, tif, jpg)
- Output support (single output en open exr, tif ou jpg )
- UV support.
- Point hierarchical (PointBased) Rendering from pointclouds. (diffuse, specular, arealight, environment, occlusion)
- Spherical Harmonic Rendering support.

 Raytracer :

- Raytracer de type path tracer avec une gestion de la distribution des samples optimisé via plusieurs algorithmes.
- Sampling global Réglable et indépendant du ShadingRate optimisé suivant le type de calcul effectué.
- BVH structure ultra optimisée avec une gestion du tracing inédite avec un nouvel algorithme.
- Gestion des données ultra optimisée, des caches, structures de données, organisation, Ram, etc...
- Physical Based RGB transport.
- Tone Mapping.
- BSDF Shader support.
- Direct lighting support.
- Object lighting and Arealight support.
- Real Raytraced shadow.
- Instance object with minimal Ram.
- HDRI texture support via EXR format.
- Highly optimized memory footprint consumption.
- Maya plugin, Standalone Application for rendering and fine tuning.
- .off and .vib scene description format support.
- OBJ, FBX support.
- 64 bits support only, Linux 64bits, Windows 7 64bits.
- support all Graphic cards with openCL, and all CPU.

Voila pour le moment une liste globale des fonctions proposées dans Vénus, alors évidemment on ne peut pas encore faire grand chose avec, il supporte à peine de pouvoir rendre de la géométrie depuis maya. Par contre il est ultra optimisé du coup les temps de rendus sont très bas et sa consommation en ram est ridicul si on le compare aux autres moteurs de rendu.
Vénus propose 3 types de gestion du rendu possible et cela suivant les besoins. il est évident que Vénus utilisant le meilleur de votre carte graphique et de vos cpu en même temps il est très performant et permet de rendre des scènes de milliards de polygones sans broncher et très vite. Son système de pointcloud lui permet de baker très vite vos scènes et de les re-rendre en quelques secondes. La gestion mémoire des pointclouds à été optimisée pour que cela puisse être possible même avec des gros fichiers. Le pointbased offre les effets du raytrace sans flicking ou besoin de sampling et les resultats sont a 95% identiques à ceux du raytrace dans notre implémentation pour un gain de 5 à 15 fois en fonction de la scène. Nous avons implémenté un module capable de calculer les informations de l'eclairage de la scène par sphérical harmonics. Cette technique très prométeuse donne des résultats très convainquant et performant et nous pensons que c'est ce sur quoi nous allons nous pencher plus vers l'avenir.
Comme je vous le disais, nous nous sommes concentré dans un premier temps sur les performances. Souvent on procède à l'inverse, on conçoit d'abord le gros du moteur afin de supporter toutes les fonctions de bases d'un moteur de rendu et petit a petit on optimise son code. Nous avons choisit le contrepied de cela car même si cela semble une perte de temps au début, nous savons désormais comment implémenter chaque nouvelle fonction tout en respectant les même procédés d'optimisation utilisées dans le code et ainsi développer plus vite les nouveautés. C'est aussi valable pour le fait que nous voudrions intégrer à Vénus les capacités de la Rispec pour en faire un rendu de type Renderman, et cela n'étant pas simple, il est mieux de bien connaitre son moteur avant de se lancer dans un tel chantier.
Pour le moment Vénus reste donc très expérimental et les rendus que j'en tire sont encore assez pauvre du fait du peu de fonctions supportées pour le moment mais nous sommes en train de travailler dessus et je vous parlerais dès qu'elle sera prête de la prochaine version qui sera un peu plus étoffée en fonctionnalités.

A plus.

Physical Based pipeline for renderman.

Je travail actuellement sur un vrai pipeline physical based pour renderman et fonctionnant sur rms via slim. En gros cela consiste en un set de Light et de surface custom qui travaillent ensemble et permettent une conservation de l'énergie accrue. J'avais envis de porter le travail que j'effectue sur Vénus ( qui est entièrement physical based) pour renderman afin de profiter des même outils dans les deux moteurs de rendu. Ce pipeline a un gros avantage, il permet des rendus plus réaliste et plus facile à mettre en place. Son inconvénient est de ne pas proposer de réglages séparés, on ne peut donc pas casser le côté physique des shaders. Il est aussi plus couteux en terme de sampling, mais je travail aussi sur une version avec un meilleur importance sampling pour y remédier.
Je verrais par la suite si je ne fais pas une version avec possibilités de découplage afin d'accroître un peu les contrôles, mais en théorie ces pipelines ne sont pas fait pour autre chose que des rendus qui miment la réalité.

mardi 14 septembre 2010

Je suis actuellement disponible.

Juste pour signaler aux personnes qui seraient intéressées que je suis actuellement disponible, mais je ne sais pas encore jusqu'à quand. Donc vous pouvez me contacter au 06.16.69.10.05.


merci.

lundi 6 septembre 2010

Siggraph 2010

Aujourd'hui j'en profite pour revenir sur le récent siggraph 2010. Côté technologie il a surtout été question de présentations tant les nouveautés étaient clairement absentes de cette édition. Néanmoins, nous avons pu en apprendre un peu plus sur le futur du GPU, assister à la présentation des Ptex dans Mudbox et Mari, contempler les files d'attente interminables pour avoir une teapot Pixar sur leur stand et assister à de nombreuses conférences. Les conférences étaient en effet cette année très intéressante et enrichissante.
Bon nombres d'entre elles sont regroupées sur ce liens ( http://www.realtimerendering.com/sig2010.html ) si ça vous intéresse de lire les comptes rendus.
On a ainsi pu découvrir dans les détails les outils utilisés par Weta sur avatar, le pipeline actuel d'imageworks, les évolutions récentes chez Ilm ou encore MPC, Disney, et bien d'autres...

jeudi 2 septembre 2010

Les news depuis le temps et surtout à propos de Vénus !

J'ai eu pas mal d'échos comme quoi certains d'entre vous qui suivait mon site internet se demandait pourquoi j'avais disparue et mon site avec. Premièrement je n'ai pas disparue je travaillais beaucoup et donc pas trop le temps de faire du site le soir en rentrant du boulot, et puis je préférais passer du temps avec ma chérie aussi. Et oui même les "nerds" ont besoin d'amour non? Quoi que l'amour d'une PS3 peut parfois suffire a certains peut être.

Bon bref pour ceux qui voudrait plutôt savoir où en sont mes projets passés, et oui à l'époque j'avais commencé a bosser sur Vénus, un outils de production pour renderman. Je dois dire que le temps a passé et après plusieurs versions je me suis rendu compte que je n'avais pas assez de temps pour m'occuper de ce projet seul, gérer le support d'un outil et le développement doivent se faire a temps plein. Mais Vénus n'est pas mort, il s'est juste transformé en concept qui grâce à l'aide d'un de mes amis, un génie du code je devrais dire, même, en un moteur de rendu propre. Je ne peux a l'heure actuel trop en dire car la route est encore très longue et on ne sait même pas si on va le sortir un jour. La seule chose que je peux vous dire c'est que c'est un moteur de rendu hybride basé sur une combinaison path tracer et REYES entierement orienté vers le pointbased et les spherical harmonics. Le moteur est entierement multithreaded pour le CPU et peux aussi utiliser le GPU pour calculer certaines taches. Pour le moment il travail surtout à l'élaboration d'un moteur ultra performant qui peut rendre des scènes très lourde sans consommer trop de ram, pour cela il s'est grandement inspirer de Arnold, un moteur de rendu actuellement en beta. Les résultats obtenus sont impréssionnants même si a l'heure actuel le moteur n'a ni compatibilité avec le RSL 2 de renderman, ni tous les aspects de la RiSpec pour en faire un Renderman.
Actuellement le moteur peut rendre de la géometrie subdivise en catmull-rom, il utilise un dicing reyes et gère très bien le displacement micro polygon. Il peut raytracer la scene tres rapidement jusqu'a 300 millions de polygon pour 8 GB de ram utilisée. Les shaders supportés sont simples mais très performant et physical based. ( diffuse et specular BSDF ). Le gros atout vient du support des pointcloud et du pointbased couplé aux spherical harmonics. ( Il s'est inspiré du travail de weta sur avatar.) Cela permet un calcul ultra rapide de la Global Illumination de la scene, mais aussi de l'occlusion. Alors évidemment la route est encore bien longue pour en faire un moteur prêt pour la production, mais la base est là et sacrément bien codé et optimisé pour en faire une vrai bête de concours.
Ce mois ci il va implementer la motion blur qui n'est que partiellement fonctionnelle à l'heure actuelle, ainsi que le Bssrdf et la curve primitive. La roadMap est encore bien pleine (car on souhaite y implementer les Ptex, le support des DSO, le support des Attributes et Options de renderman, les brickmap, le CSG, les particle et volumetric primitive, un mode rerendering.) mais on verra l'année prochaine où on en est et ce qu'il adviendra de ce moteur. Là on fait juste mumuse avec car il est trop limité, mais on est tres optimiste quand on voit nos tests comparés avec Prman ou Arnold.

Pourquoi un Blog ?

Ce blog est provisoire, c'est simplement que je n'ai pas le temps en ce moment de refaire un beau site internet et qu'un blog c'est gratuit, facile et sympa. Donc ce blog me permettra de poster des articles et news jusqu'à l'arrivé du prochain site. voila vous savez tout... ou presque.

Enfin de retour sur la toile.

Bonjour a tous, après quelques mois durant lesquels mon site perso était "down" (désolé mais j'ai manqué de temps pour m'en occuper), je suis de retour pour vous donner plus d'infos sur la 3d, le rendu, le dev et surtout Renderman.

Pour ceux qui ne me connaissent pas encore et visite ce blog pour la première foi, je me présente vite fait. Je m'appel Julien et je suis Rendering Technical Director (TD pour faire plus simple...) et plus particulièrement spécialisé dans renderman. Vous me direz ça consiste en quoi alors un TD? Ben en gros je m'occupe de tout l'aspect technique concernant le rendu ou autres. Pour simplifier disons que je m'occupe de coder et scripter les outils utiliser en production et qui facilite la vie des artistes ( enfin ceux qui aiment bien les gros boutons qu'on appui dessus et que ça fait ce qu'on veut que ça fasse ...), Faut pas croire non plus que les TD ne peuvent pas aussi être eux meme des artistes, pour devenir TD il faut connaitre très bien tous les aspects de la 3D en profondeur, aussi bien au niveau artistique qu'au niveau logiciel (code et autre.). Cela aide à être plus efficace dans notre travail, l'expérience est donc un énorme plus pour faire un bon TD.

Mon parcours est plutôt atypique puisque j'ai fais des études artistiques, puis d'animation aux gobelins pour finir par me mettre au rendu et finalement me consacrer de plus en plus au développement ces dernières années. Désormais je suis entre la R&D et la mise en place des outils pour la production.
Mon approche est evidemment plus orienté vers le rendu et renderman, mais il m'arrive aussi de développer des outils plus généraux de pipeline ( asset management, file structure etc...).
Pour Cela j'utilise plusieurs langages de scripts, mon préféré étant cependant le python avec lequel je code pratiquement tout. Le python et pyQT sont devenu mes deux langages indispensable pour un bon pipeline structuré, ordonné et flexible, je les utilises dès que je peux. Car parfois il ya certaines choses pas compatible avec python ou QT et ont doit passer par d'autres langages tel que le Tcl (on prononce "Tickle" et pas "TéCéeL") et le RSL pour renderman et alfred. Maya support le python et le pymel mais beaucoup de choses sont pas faisable via python et il faut passer par le melscript assez souvent ( ce qui peut être parfois chiant.) Je réserve le C et C++ à la R&D pure quand il faut allé dialoguer vraiment avec la machine et crée ses propres plugins à l'aide des API. Mais n'étant pas un codeur à la base mes capacités en C et C++ actuelles sont limitées et j'essai de progresser dans ce domaine en ce moment.

Voila bonne visite a tous.