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.
mardi 28 septembre 2010
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.
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é.
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.
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...
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.
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.
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.
Inscription à :
Articles (Atom)