Dopoise
Accueil » Deux élèves de l’ESMA développent un outil pour mieux exploiter RenderMan

Deux élèves de l’ESMA développent un outil pour mieux exploiter RenderMan

Cet article est également disponible en: English

Année après année, les courts-métrages des écoles d’animation font le tour des festivals et sont relayés sur 3DVF. Derrière les qualités visuelles et artistiques de ces films se cache souvent un travail technique poussé, fruit du travail d’élèves qui profitent de la réalisation du film pour mettre en place outils maison, pipelines, scripts, etc.

Adrien Lhabitant et Tom Perony de l’ESMA Toulouse font justement face à cette problématique. L’école utilise RenderMan pour le rendu de ses films, et les deux élèves souhaitaient bénéficier du système de denoising du moteur de rendu de Pixar, qui permet de gagner un temps précieux en stoppant le rendu plus tôt (ci-dessus, un comparatif avant/après denoising).

En attendant de voir leurs projets, ils nous donnent quelques détails techniques sur Dopoise, l’outil qu’ils ont développé pour exploiter le denoiser IA de RenderMan sur Tractor… Mais aussi bientôt sur Deadline ! Mieux encore, ces outils seront mis à disposition, vous pourrez donc à terme les utiliser également.
Nous leur laissons donc la parole pour la suite de l’article.


Introduction

Salut ! Nous sommes Adrien Lhabitant et Tom Perony, deux étudiants de l’ESMA Toulouse travaillant sur nos court métrages de fin d’études, respectivement « El Dodorado » avec un pipeline Solaris USD et « Rush More » avec un pipeline Maya.

Nous avons créé de nombreux outils pour répondre à nos besoins de production, et nous allons maintenant nous intéresser à Dopoise, notre outil conçu pour exploiter le denoiser IA de Renderman 25 sur Tractor.

Pourquoi avons-nous développé DOPOISE
Pendant la création de nos films étudiants, nous sommes confrontés à de multiples défis techniques et structurels. Avec nos ressources informatiques limitées partagées entre les différentes productions, nous devons trouver des solutions pour réduire le temps de rendu et optimiser l’utilisation de chaque machine sans sacrifier la qualité.
Intrigués par la récente sortie du denoiser IA de Renderman 25, nous avons essayé et avons immédiatement constaté des résultats impressionnants sur nos différents tests : fur , scattering, flou de mouvement extrême, faible sampling.
Par conséquent, nous avons envisagé de l’intégrer à notre pipeline de production. Cependant, l’interface graphique présentait certaines limitations et les images dénoisées en tant qu’EXR séparés constituaient, dans notre cas, des obstacles à une utilisation en production. De plus, la qualité a un coût, nous avons donc dû envisager de le déployer avec le dispatcher Tractor sur notre renderfarm.

Développement du projet

Initialement, nous avons exploré la fonctionnalité de l’outil via la command line plutôt que l’interface que nous avions jugée non-optimale. Nous avons identifié le premier défi consistant à fournir le bon type de chaque AOV à l’algorithme de dénoise. Nous avions également besoin de fusionner les EXR dénoisés de chaque AOV, ce que nous avons réalisé en utilisant l’outil « exrmerge » fourni par Renderman.

Maintenant que nous avions un workflow fonctionnel, l’objectif était de créer un outil capable de gérer un grand nombre de frames, de layers, d’AOV personnalisés, de light groups, et de transférer le tout à Tractor.

Nous avons automatisé ce processus long et fastidieux en utilisant un script Python qui gère l’ensemble du processus pour toutes les frames de chaque layers dans un shot donné.

Le processus se déroule comme suit :
Tout d’abord, l’utilisateur sélectionne le dossier contenant les images, puis il peut choisir le type pour les AOV qu’il souhaite dénoiser (diffuse, spéculaire…). Pendant ce temps, le script effectue une identification dans le dossier du shot pour détecter les AOV en utilisant l’outil « exrinfo » fourni par Renderman. Il détecte ensuite les light groups s’il y en a, donc aucune intervention de l’utilisateur n’est nécessaire, ce qui donne un outil assez flexible.
Lorsque la partie AOV est terminée, l’utilisateur peut choisir de dénoiser localement ou sur la renderfarm en utilisant Tractor, pour lequel il peut ajuster les paramètres du Job.
Et enfin, l’utilisateur peut choisir de dénoiser en utilisant le mode crossframe ou non.
Le script prend le relais à partir de là, il trie les EXR dans différents dossiers en fonction de leur type : beauty, utility et cryptomattes. Il procède ensuite à la génération de code TCL (Tractor) ou Batch (local) contenant toutes les instructions de dénoise et de merge.

Limitations techniques

En fait, le principal problème vient du denoiser lui-même ; il a tendance à générer une erreur « PyRunSimpleString failed » potentiellement liée à une RAM saturée. (rappel : le dénoise crossframe nécessite plus de RAM) C’est surtout ennuyeux lors du dénoise en local, car le processus doit être redémarré depuis le début. Pendant ce temps, sur Tractor, nous recommandons de définir 1 « frame par serveur » et de profiter du paramètre « max active tasks » que nous avons mis dans l’interface utilisateur pour limiter l’impact de votre travail sur la renderfarm. De cette façon, si une frame échoue, vous pouvez la redémarrer sans perdre de progression sur les frames précédentes.

Malgré la réduction du problème d’échec du denoiser en l’isolant sur Tractor, nous devions toujours nous assurer que toutes les images étaient disponibles le lendemain. Nous avons donc développé un script appelé TJM (Tractor Job Manager), qui veille à relancer chaque tâche de dénoise qui échoue.TJM utilise l’API Tractor en Python 2.7.

Il y a un problème mineur caché plus tard dans le pipeline de production ; lors de l’application d’un unpremult à la phase de compositing, nous avons remarqué que des artefacts apparaissaient, qui disparaissent lors de l’application de premult. Cela semble être dû à des valeurs extrêmement faibles dans le canal alpha (autour de 10e-7).
Nous utilisons une expression pour nous débarrasser de ces valeurs, et n’avons pas remarqué de problème supplémentaire.
Dans la section alpha du nœud d’expression : a * (1-step(a, 0.01)) vous pouvez ajuster le seuil de 0.01 selon vos préférences.

À propos de Deadline :
Nous aimerions intégrer une soumission à Deadline pour permettre à plus de monde d’utiliser Dopoise.
Nous prévoyons de travailler dessus, mais comme nous utilisons Tractor dans notre école, nous essaierons de créer une renderfarm Deadline sur notre temps libre pour travailler dessus. Nous publierons une nouvelle version de l’outil lorsque cela sera fait !

Pour plus d’informations

Laissez un commentaire

A Lire également