Unreal Engine est-il au niveau d’une série Netflix ? Les tests Dwarf Animation en interview !

Cet article est également disponible en: Anglais

Le studio Dwarf Animation, basé à Montpellier, a lancé une série de tests en interne autour d’Unreal Engine. Leur objectif initial était de savoir si certaines séries passées du studio pourraient aujourd’hui être produites sous Unreal.

Etant donné l’intérêt de nombreux studios pour ce moteur, nous avons souhaité en savoir plus. L’équipe a bien voulu lever pour nous le voile sur ses tests, répondre à nos questions et nous préparer un aperçu exclusif de ces tests !

Certaines questions rentrent en détail dans les aspects techniques, tandis que d’autres évoquent l’impact sur les conditions de production, le travail des artistes : n’hésitez donc pas à parcourir l’interview en fonction des éléments qui vous intéressent. Et ne manquez pas la fin de l’interview, avec l’impact sur le pipeline de Dwarf, et un projet de formation autour d’Unreal Engine !

3DVF : Bonjour Dwarf Animation ! Vous avez lancé des tests autour d’Unreal, visant à éprouver le moteur pour voir s’il était utilisable en production.
A quoi vous attendiez-vous, en termes de résultats mais aussi de difficultés techniques (sachant que seules 2 personnes chez Dwarf étaient formées à UE5) ?

Dwarf Animation : Effectivement, notre questionnement de base portait sur la qualité que nous pourrions atteindre avec Unreal Engine. Nous avions vu de très beaux projets faits avec ce moteur, mais pas tout à fait dans le style de nos productions habituelles. Le court-métrage Blue de Preymaker était ce qui s’en rapprochait le plus. Il y avait toutefois des inquiétudes sur la qualité du Subsurface Scattering (SSS), de la réfraction ou de la capacité de la Global Illumination (GI) qui sont souvent très approximatifs et limités en temps réel.

Secrètement nous espérions pouvoir atteindre la même qualité que “Pirata et Capitano” ou Monchhichi (qui utilisaient beaucoup de SSS et GI pour donner un côté « gomme »). Mais personne ne pensait qu’on arriverait à obtenir un rendu proche de My Dad The Bounty Hunter [NDLR : la série est disponible sur Netflix].

La plupart d’entre nous n’avaient jamais travaillé dans le jeu vidéo avant. Il y avait des craintes vis-à-vis du vocabulaire technique, des workflows et de la gestion de la data. Ce qu’il y a eu de plus difficile techniquement, c’était d’oublier ce que nous savions et tout remettre en question. Car approcher ce genre de technologie comme nous le ferions en précalculé rend l’expérience impossible ou terriblement pénible. Mais il est parfois difficile de lâcher nos vieilles habitudes !

3DVF : Votre projet était donc de créer quelques séquences animées, en vous appuyant sur Perforce. Quelles étaient les conditions concrètes du projet (durée, contraintes techniques) ? Et pour les personnes qui ne connaissent pas Perforce, quel est son intérêt ?

Pour le premier projet (nom de code « Roger »), nous voulions comprendre d’un point de vue technique, comment organiser les fichiers pour travailler de manière collaborative au niveau shot dans Unreal, ainsi que d’évaluer les capacités de rendu du moteur.

Nous nous sommes donnés un certain nombre de contraintes. Réaliser un court-métrage de 30 secondes en condition de production, à équipe réduite, en 4 semaines et sans formation préalable (A l’époque, nous n’étions que deux à connaître Unreal).
Afin de compliquer un peu plus la tâche, on décidera de se limiter exclusivement à Lumen pour le lighting (donc pas de pathtracer), et d’utiliser un pipeline colorimétrique en ACEScg. On s’interdit d’utiliser Nuke afin d’évaluer les possibilités à réaliser des postFX tel que la profondeur de champ, les particules de poussière, les volumétriques ou même des corrections colorimétriques.
D’un point de vue animation, on décide d’animer aussi dans Unreal. Car même si les outils ne sont pas encore production-ready, nous voulons évaluer leurs potentiels.
Pour finir, nous utiliserons des cartes Quadro RTX 4000 avec 8 Go de VRam qui ne sont plus toutes jeunes.

La gestion des fichiers d’Unreal se fera via l’intégration Perforce. Nous avions quelques craintes vis-à-vis de son utilisation par nos artistes, car même s’il est répandu dans l’industrie du jeu vidéo, c’est un concept très différent de notre pipeline actuel.
Perforce va créer une copie du projet sur la machine de l’artiste (il travaille donc en local). Ce dernier pourra décider de prendre les droits d’éditions sur un fichier pour pouvoir le modifier. Lorsqu’il a terminé son travail, il peut le soumettre au server afin que les autres artistes puissent récupérer ses modifications. La grosse différence, c’est que tout le monde travaille sur les mêmes données. Chaque fichier s’écrase tout en gardant un historique afin de pouvoir revenir en arrière. Pour éviter de se marcher dessus, Perforce permet de bloquer un fichier si quelqu’un d’autre l’édite. Ce qui autorise plusieurs utilisateurs à travailler en même temps.

Nous avons beaucoup appris grâce à ce petit projet. Nous avons été surpris par la fluidité des échanges entre les départements qui a permis d’augmenter les itérations. Cela a même révélé de nouveau workflow, impossible auparavant.
Pouvoir travailler dans le contexte d’une séquence et de visualiser une qualité quasiment finale dans le viewport, permet de gagner beaucoup de temps et de limiter les erreurs.
Le lighting avec Lumen était rassurant avec une belle qualité. Surtout avec un temps de rendu pour l’image la plus longue de 12 secondes sans optimisation (nous estimions une image de même qualité dans Renderman à 45min). Les shaders ne sont pas si différents de ce qu’on peut trouver dans un pathtracer classique. Mais nous avons quand même pu constater qu’Unreal nécessitait pas mal de réglages pour obtenir un rendu cinématographique.
C’était aussi surprenant de voir l’autonomie des artistes sans que nous n’ayons développé un pipeline. Nous avions seulement quelques scripts pour importer les assets dans le projet et générer les séquences. Perforce a supporté une grosse partie du workflow. Finalement, les artistes ont vite assimilé le fonctionnement. Ils avaient plus de mal à comprendre que chaque asset dans un projet Unreal était un fichier séparé et que tout était interconnecté (contrairement à Maya où il n’y a qu’un seul fichier). L’autre avantage de Perforce et de la structure des fichiers dans Unreal, c’est qu’en cas d’erreur, il est très facile d’identifier le problème et de revenir en arrière.

En conclusion, ce projet a permis de rassurer les équipes et de vouloir aller plus loin en poussant d’autres tests.

3DVF : Vous avez ensuite testé l’import de données de séries comme My Dad the Bounty Hunter et Trash Truck. Et en une semaine de travail pour gérer shading, lighting… Vous y êtes parvenus ! Quitte, évidemment, à prendre quelques raccourcis (pas de gestion des liens hiérarchiques entre objets 3D). Concrètement, quels ont été vos résultats en temps de rendu, par rapport aux rendus sous RenderMan ? Et quelles sont les limitations visuelles/techniques éventuelles ?

Au vu de la qualité de rendu de notre premier test, nous avons souhaité nous challenger en portant une scène de My Dad The Bounty Hunter : L’appartement de la mère que l’on voit dans le premier épisode.

Pour aller au plus vite, nous avons écrit un exporter dans Maya de la position de chaque asset en world space et sans tenir compte de la hiérarchie. Ensuite, nous avons écrit un scene assembly en python dans Unreal pour importer chaque géométrie en “static mesh” avec leurs textures. Nous avions au préalable préparé des “Master Material” (une sorte d’uber shader) dans Unreal. Chaque asset utilisera un “Material Instance” dont le parent est un Master Material. Donc si on modifie le Master, toutes ses instances se mettent à jour. Le scene assembly s’occupe de générer un Material Instance pour chaque asset et d’assigner les textures. La mise en place nous aura pris une semaine.

Le surfacing et le lighting aura lui aussi pris une bonne semaine, car nous avons continué notre apprentissage du moteur. Nous n’avons pas essayé de matcher parfaitement la référence de base, mais nous étions déjà très satisfaits du résultat obtenu.

La version de Renderman mettait en moyenne 1h30 par image à rendre, sans compter le temps d’export des RIBs, le denoising, le pre-comp (dof,..). De plus, un certain nombre de triche était nécessaire pour optimiser le temps de rendu (bounce lights,…) .

La version dans Unreal rend l’image en 3 secs tout compris et aucune triche sur le lighting. Le résultat est bluffant. Nous sommes surpris de ce que l’on arrive à faire au bout de 6 semaines de prise en main d’Unreal.
Malgré tout, nous avons pu constater des limitations dans la qualité et détail du SSS et de la réfraction ainsi que les light filters. Le manque de système de subdivision demande à réfléchir les assets en amont et peut poser certaines contraintes, notamment avec les hairs.
De base, Unreal fait de très belles images pour le jeu vidéo, mais il y a beaucoup de variables à régler pour se rapprocher de la qualité d’un pathtracer. Malheureusement, ces réglages sont très peu documentés pour le moment.

3DVF : Une question pour Joachim Guerin : en tant que Lighting Supervisor chez Dwarf, quel regard as-tu sur les outils de lighting sous UE5, par rapport à ce dont tu as l’habitude ?

UE est relativement similaire aux moteurs habituels, avec quelques limitations en plus. Par exemple les « light filters » qui ne fonctionnent qu’en noir et blanc. Ou le « light linking » qui est limité à 3 channels. Mais ceci est inhérent aux optimisations nécessaires pour le temps réel. Il faut donc revoir certaines habitudes pour les contourner.

Il y a certains avantages au niveau des lights, comme pouvoir modifier le volume indépendamment de la diffuse, de la GI et de la spéculaire. Ce qui est similaire à Arnold.

Nous avons à disposition des outils comme le « Light Mixer » qui nous permet de piloter les lumières d’une scène depuis une même interface. Les « Light Functions » et le Blueprint nous permettent d’ajouter très facilement des fonctionnalités qui n’existent pas de base.

Il va de soi que le temps réel apporte un véritable gain et beaucoup de plaisir grâce à l’interactivité. Le résultat dans le viewport est très proche (pour ne pas dire similaire dans certains cas) au rendu final.

Pour finir, la construction des shots et séquences que nous avons pu mettre en place dans Unreal, rend le lighting à la séquence fluide et naturel. Combiné au fait que le rendu soit rapide, nous pouvons plus facilement travailler les animations de lighting au sein du Sequencer.

3DVF : Les effets indispensables pour une série comme My Dad the Bounty Hunter, comme le SSS ou le rendu de hair, vous ont-ils posé des problèmes ?

Clairement, oui. Dans tous les logiciels, ces sujets sont difficiles à prendre en main, chacun étant particulier. Comme dit précédemment, dans Unreal, nous avons des limitations dans la précision du SSS ainsi que des soucis dans la tessellation pour les hairs. Il faut aussi passer un peu de temps à poser des blockers pour éviter du flickering induit par Lumen.

Pour l’instant, nous n’avons pas trop testé la partie FX dans Unreal. Cependant, il y a différentes approches qui permettent d’avoir des résultats intéressants à moindre coût. L’une des choses qui pècherait le plus dans le moteur est l’intégration des systèmes volumétriques, mais ceci est en train de changer avec un lecteur VDB très optimisé prévu dans la 5.3. Il nous tarde de pouvoir le tester.

3DVF : Même question pour des éléments très lourds, comme une ville visible dans la série.

Vis-à-vis d’une ville, la quantité de données n’est pas tellement un souci dans Unreal. La principale question que nous cherchons à répondre est de savoir comment la construire. Plusieurs techniques différentes peuvent être utilisées, et le tout est de savoir laquelle correspond à nos besoins, et de prendre le temps de les tester.

Pour l’anecdote, la ville principale de My dad the Bounty Hunter, prenait dans Maya près de 5 minutes de chargement et ne pouvait pas être affichée dans son intégralité. Grâce à la technologie Nanite et d’autres optimisations, nous pouvons ouvrir cette même ville dans son intégralité en quelques secondes dans Unreal et naviguer à 60 fps dans le viewport (sans shader).

3DVF : Vos tests avançant, vous avez créé CBB : un court-métrage avec animation sous Maya, export Alembic, rendu sous Unreal. 6 semaines du storyboard à l’image finale, sans utiliser le path tracing d’UE5.
Quelle était la taille de l’équipe ? Qu’avez-vous appris ?

Nouveau projet, nouveaux défis. A ce moment-là, un mois et demi se sont écoulés depuis le début de cette aventure et nous voulons aller un peu plus loin dans nos tests. On décide de créer un nouveau court-métrage d’une minute à réaliser en 6 semaines du storyboard à l’image finale. Cette fois, l’animation sera faite dans Maya pour que l’on puisse tester le workflow Alembic.

L’équipe sera plus ou moins de 10 personnes. Mais tous ne travailleront pas dans Unreal. L’animation se fera principalement avec Maya. Le modeling et les textures se feront respectivement dans Blender, Maya et Substance Painter. Le Groom sera fait dans Houdini. Le Surfacing, Lighting et In-CameraVFX se feront par le même artiste dans Unreal. On s’interdit une fois de plus d’utiliser Nuke pour approfondir l’utilisation des post-process d’Unreal.

C’est le premier projet où les assets seront pensés dès le départ pour Unreal. Que ce soit de la modélisation, en passant par les textures ou le Set Dressing. Ceci nous a permis de tester de nouvelles méthodes de construction de scène afin qu’elles soient plus optimisées. Nos assets étaient beaucoup plus modulaires et nous avons mieux exploité l’instancing. Une étude approfondie sur les textures et leurs optimisations, nous a aussi permis de remettre en question l’approche que nous en avions habituellement.

Nous avons aussi pu revoir comment organiser une production. Le fait de pouvoir travailler en parallèle et sur les mêmes données, permet de mettre en place de nouvelles méthodes de travail plus fluides et d’identifier où concentrer l’effort. Des éléments que nous ne verrions habituellement qu’au moment du compositing (fog, ambiance, lights…) peuvent être mis en place dès le début de la production et accessibles par tous les départements. C’est un gain de productivité énorme qui demande de revoir un planning classique.

Nous nous sommes aussi retrouvés confrontés à plusieurs soucis. Par exemple, l’utilisation avancée du Sequencer, nous a démontré que nous avions encore des choses à apprendre sur l’architecture des Sub-Layers et leur système de hiérarchie. Ceci nous a provoqué énormément de problème d’overrides que nous avons mis du temps à identifier.
Le système de Geometry Cache via l’Alembic ne fonctionnant pas comme nous en avions l’habitude en précalculé, son utilisation n’est pas évidente. Sans même parler des nombreux bugs, l’approche du Geometry Cache n’est clairement pas la méthode la plus souple. Nous essayerons de l’éviter dans la mesure du possible.

Les difficultés techniques de ce projet et le temps limité que nous avions, nous a amené à développer un certain nombre d’outils en Blueprint pour automatiser nos workflows (import des animations, constructions d’assets…). La simplicité d’intégration de ces outils dans le moteur ne nécessite pas un passage obligatoire par la phase « Pipeline ». L’artiste et/ou le TD peut créer et implémenter des outils pour gérer de la data sans impacter la production.

Chaque projet nous aura permis d’apprendre un peu plus et de comprendre les workflows que nous pourrions mettre en place. Par ailleurs, chacun d’entre eux nous constitue un dataset de plus en plus gros que nous pouvons utiliser pour tester d’autres architectures, designs, optimisations… La réutilisation est très simple dans Unreal.

3DVF : Votre projet autour d’Unreal, dès le départ, était de travailler sans compositing : comment votre équipe compositing a-t-elle perçu cette volonté ? Quelle était son implication dans le projet ?

Pour ces projets, nous ne voulions pas avoir à partir dans Nuke pour rajouter certains effets que nous pourrions directement faire dans le moteur. Cependant, ces étapes restent nécessaires. Que ça soit à la charge du lighteur ou un compeur, ce qui change est l’outil.
L’idée était d’évaluer les capacités d’Unreal afin de pouvoir définir ses limites et savoir quand Nuke serait indispensable.

En conclusion, avec ce genre d’outils, nous voyons une convergence de certains métiers. Un de nos compeur nous disait avoir arrêté le lighting, car c’était trop long, mais de voir les capacités du temps réel lui donnait envie de s’y remettre. Cependant, nous ne nous interdirons pas d’utiliser Nuke dans nos futures productions.

3DVF : En tant que studio, vous avez des échanges de données à gérer. Pourquoi USD n’était-il pas pertinent pour vos tests, et qu’est-ce qui a guidé vos choix entre Alembic et FBX ?

L’Usd est un sujet complexe et aussi vaste que la gestion des données dans Unreal. Nous ne voulions pas influencer notre approche d’Unreal par rapport à nos habitudes du précalculé et de l’Usd. Nous avons préféré focaliser l’effort sur UE plutôt que nous disperser entre deux technologies.

Mais en ce qui concerne son utilisation au sein d’Unreal, tout dépend de ce qu’on entend par Usd. Si on parle seulement du format de fichier au même titre que l’Alembic ou le Fbx, lorsque nous avons commencé ces projets, nous étions sur Unreal 5.1.1, l’Usd dans cet éditeur ne supportait pas encore l’animation en Geometry Cache.
En revanche, si on parle du système de composition de scène et override de celui-ci, alors une vraie question se pose : Dans le cas où nous travaillerions seulement dans Unreal, qu’est-ce que l’Usd apporte de plus ? Après avoir utilisé cet éditeur pendant plusieurs semaines, nous nous sommes rendu compte que son système de fichier et d’override offraient des possibilités similaires. Au-delà de l’échange de fichier entre DCC, l’Usd essaie de résoudre des problématiques que les éditeurs de jeux vidéo ont déjà en partie solutionnées.

Cela étant dit, c’est clairement un sujet qu’on étudiera pour nos futures productions afin de fluidifier l’échange de données avec des départements qui ne travaillent pas encore dans Unreal comme l’animation. 

3DVF : Vous avez opté pour prendre une licence Unreal Developer Network (UDN) : autrement dit, vous payez pour du support et des ressources. Quels sont vos retours à ce niveau ? Le fait de ne pas être un studio de jeu vidéo n’est-il pas un frein dans vos échanges avec l’équipe d’Epic ?

Nous avons pris une licence UDN afin d’avoir une voie de communication direct avec le support, et ne pas être limités aux forums publics. Toute l’équipe est heureuse de cette interaction.

Les premiers temps, nous avions eu des soucis de communications avec le fait que nos interlocuteurs sur l’UDN sont très orientés jeux vidéo. Du coup, nous avions un vocabulaire un peu différent, mais ça a vite changé.

Les équipes participant à l’UDN sont à la fois réactives et pointues dans les réponses. Malgré nos premières questions parfois un peu naïves, ils ont su nous aiguiller et répondre à nos besoins.

Ces derniers temps, les interactions avec eux sont de plus en plus poussées. Nous rentrons plus dans le détail en donnant des feedbacks sur nos expériences et des rapports de bug. Récemment, nous avons soumis une dizaine de changements dans le code de l’importer Alembic afin de le rendre plus stable et facile à utiliser en production. Ces changements sont en cours d’analyse chez eux et seront probablement intégrés dans la version 5.4.

3DVF : Des temps de rendu de 5 à 10 secondes, cela change évidemment la manière de travailler… Comment votre workflow a-t-il évolué par rapport à vos habitudes ? Par exemple en termes de retakes, de dailies ? Ou de modifications d’éléments en aval de leur validation ? (MIAM ! Animation nous expliquait que leur processus à Edmond et Lucy, sous Unity, comporte une phase de « fine tuning » très tardive, avec rajouts d’éléments, voire modifications majeures de la caméra jusqu’au dernier moment)

Pouvoir éclairer toute une séquence dans une même timeline permet de simplifier les workflows et limiter les erreurs de raccord. Nous pouvions lancer l’intégralité de la séquence chaque nuit avec les datas de chaque département à jour. Ce qui nous permettait de review les shots dans leur intégralité.
La review prend une autre dimension, car on est moins frileux de synchroniser tous les départements. Il y a moins de risque qu’en précalculé. Nous pouvons review directement dans le moteur si besoin est. Cela rappelle le workflow Flame où nous pouvions appliquer des retakes directement avec le réalisateur pendant la review.

3DVF : Est-on tenté, face à des temps si bas, de choisir de pousser davantage la qualité du rendu, quitte à repasser à 15, 20 secondes de calcul par frame ?

Ceci est un des pièges en effet que nous cherchons à éviter à tout prix. Nous avons nos développeurs qui sont continuellement en train de chercher à faire des optimisations dans nos scènes, en effectuant du profiling.

Pour le moment, nous sommes encore dans l’euphorie du temps de rendu extrêmement bas. Mais on s’habitue très vite à ce confort, et on finit par oublier qu’un jour, nous faisions des rendus de 1h30 pour une même image.
Quand cela deviendra la norme pour les productions, passer de 5 secondes à 10 secondes par image double le temps d’attente d’un shot. Et les coûts indirects qui vont avec. Par exemple, si nous prenons une séquence d’1 min à 3 secondes par image, il faut un peu plus d’une heure de rendu sur une seule machine. L’artiste peut encore le lancer en local. A 5 secondes par image il faut 2h de rendu, mais à 10 secondes par image, il faudra environ 4h de rendu. Tout en restant très bas, on se rend vite compte de la nécessité d’une renderfarm. C’est aussi moins d’itérations pour un artiste, et donc une perte de confort de travail et une augmentation des coûts de production.

Nous essayons d’optimiser au maximum pour que l’artiste garde toute son interactivité dans son workflow, tout en restant dans une qualité qui correspond à nos standards.
Cependant, pour le rendu final, les paramètres du moteur sont poussés pour améliorer la qualité de l’image. Par exemple, Unreal va rendre 16 fois la même image pour obtenir un motion blur et un anti-aliasing de bonne qualité. Donc perdre quelques fps sur un shader mal optimisé peut avoir un gros impact sur le temps de rendu final.

3DVF : RenderMan conserve-t-il des avantages ? Par exemple, en termes de qualité de rendu pure, Unreal peut-il l’égaler ?

Lumen dans la version 5.2 d’Unreal ne peut pas rivaliser totalement avec un pathtracer, notamment vis-à-vis des sujets cités précédemment (SSS, réfraction,). Étant donné qu’Unreal est un moteur de jeu vidéo, il fonctionne plus sur de l’approximation que sur du calcul précis.

Mais ceci n’est pas nécessairement un handicap, tout dépend des besoins. Le type de production, le budget et la qualité voulue définissent ce qui est acceptable. Typiquement aujourd’hui si nous devions faire La Planète des Singes, ça nous paraîtrait difficile de l’envisager dans Unreal. Mais l’année prochaine ? L’année d’après ? Les choses bougent tellement vite dans le monde du temps réel qu’il est difficile d’imaginer les capacités du moteur demain.

Déjà aujourd’hui nous avons le pathtracer d’Unreal qui est disponible et que nous voyons s’améliorer de version en version. Récemment les systèmes de volumes, le nouveau modèle de shader Substrate et les géométries virtuelles (Nanite) ont tous été rajoutés dans les 6 derniers mois. Nous avons pu voir son utilisation par le studio MPC dans leur court-métrage Brave Creatures. Nous avons la volonté de l’étudier aussi.

3DVF : De même, sur des scènes très lourdes/complexes, le rendu GPU peut sans doute finir par crasher, là où un moteur classique comme RenderMan fonctionnerait ? Avez-vous eu ce genre de problème ?

C’est un peu difficile pour nous de nous prononcer là-dessus. Toutes les scènes que nous avons réalisées jusqu’à aujourd’hui se rendent sur des vieilles cartes 3d (Quadro RTX 4000 avec 8 GB de mémoire vidéo). Certaines sont un peu plus difficiles à rendre que d’autres à cause de la limitation mémoire et peut provoquer des artefacts. Mais nous avons toujours trouvé une solution pour contourner le problème et cela ne nous a pas vraiment empêché de travailler. Nous pensons qu’avec des cartes 3D de dernière génération, ces soucis ne devraient plus être aussi présents, car la mémoire disponible est largement supérieure.

Nous sommes en train de porter l’une des plus grosses scènes de My Dad The Bounty Hunter et n’avons pas encore rencontré de point bloquant. Donc pour l’instant, nous n’avons pas eu de soucis liés au GPU, mais cela arrivera certainement un jour.

En ce qui concerne la construction de scène, nous travaillons actuellement à l’étude de plusieurs approches. Nous utilisons des ressources mises à disposition par Epic comme le citySample (démo Matrix), Slay Animation ou ElectricDream pour avoir des axes de réflexion. Nous avons extrait plusieurs concepts et chacun a ses avantages et ses inconvénients. Certains offrent des intérêts côté utilisateur, d’autres sont plus axés optimisation. En ne se limitant pas à une seule solution de construction générale, ceci permet d’exploiter au mieux les ressources du moteur.

3DVF : RenderMan évolue actuellement, avec l’arrivée du rendu hybride XPU : quel est votre regard sur cette technologie ?

Malgré nos récentes recherches en temps réel, nous restons un studio qui historiquement fait du précalculé, donc forcément, nous avons vu les améliorations de Renderman. Le XPU se développe depuis des années chez Pixar et s’améliore à chaque version. Tous les développeurs de moteur précalculés sont en train d’intégrer ce genre de technologie pour améliorer le temps de travail au niveau du Lightning et du visual development.

Encore aujourd’hui il y a des limitations sur Renderman 25 XPU qui en fait un bon outil pour du visual development, mais non-exploitable pour le rendu final. Typiquement pour citer que quelques points limitants, le XPU ne supporte ni le light linking, ni les light filters, ni les mesh lights. Ces éléments sont importants, sinon essentiels pour les productions artistiques comme nous faisons sur My Dad the Bounty Hunter.

3DVF : Comment voyez-vous l’avenir du rendu chez Dwarf ? Une bascule totale vers UE ? Un double pipeline UE5/RenderMan ? Autre chose ?

Nous avons réalisé ces tests pour déterminer si certaines séries peuvent être fabriquées avec ce genre de technologie. Notre conclusion est oui. Il est encore difficile d’estimer jusqu’où nous pouvons pousser un moteur temps réel, et ce qui sera possible de faire dans 6 mois. Nous ne pensions déjà pas arriver aussi loin. En fonction des séries, de la qualité et du budget, nous choisirons le pipeline le plus adéquat. Donc pour le moment, nous voulons garder en parallèle un pipeline précalculé pour réaliser les projets que nous ne considérons pas atteignable avec un moteur temps réel.

3DVF : Et quels éléments sont encore manquants ou perfectibles chez Unreal pour un studio d’animation ? Autrement dit, qu’espérez-vous pour les prochaines mises à jour ? Quid des outils d’animation, par exemple ?

Il y a plusieurs réponses possibles en fonction des besoins de la production. Mais le plus gros bottleneck que nous avons rencontré pour l’instant est l’animation. Entre le projet Roger (notre premier test full UE), et le projet CBB (animation faite sous Maya), nous avons ressenti une énorme différence dans la fluidité de la production. L’import des animations en passant par des Geometry Cache est un point bloquant important, qui ralentit toute la production. Il n’y a rien d’impossible et de plus compliqué qu’un pipeline de production classique. Mais le jour où l’animateur pourra travailler sur la même data que les autres départements et dans le moteur, ce sera un véritable game changer. Nous n’en sommes plus très loin.

Du point de vue des lighters, il y a beaucoup de choses qui ont aussi besoin d’être améliorées et qu’ils attendent avec impatience. Notamment la réfraction de Lumen ou une version stable de Susbtrate. D’un point de vue workflow, les importers VDB et un bon système de gestion Us seront essentiels dans le futur.

Chaque version mineure d’Unreal nous amène de grosses évolutions, ce qui nous force à constamment nous remettre en question et tester de nouvelles méthodes. UE 5.1 nous a amené Strata (renommé en Substrate en 5.2) qui est un modèle de shading plus moderne. UE 5.2 nous apporte le PCG, un système procédural de scattering très puissant. UE 5.3 va nous amener les SVT, soit la possibilité d’importer de vrais volumes dans Unreal depuis Houdini. Ces systèmes sont tous expérimentaux aujourd’hui, mais s’améliorent de version en version et promettent de grosses évolutions dans les années à venir.

3DVF : Quels sont les plus gros impacts d’un point de vue production en utilisant Unreal ?

Les éditeurs de jeu comme Unreal Engine ont pour avantage de ne pas être qu’un moteur de rendu. Nous parlons souvent des temps de rendu, car la différence est astronomique. Mais ce que nous avons pu constater de plus impactant est le côté itératif et collaboratif. C’est-à-dire que même si le temps de rendu était long, nous gagnerions à travailler dans ces éditeurs.

Dans un workflow classique style précalculé, nous avons un temps extrêmement important qui est utilisé sur autre chose que du rendu. Si nous prenons l’exemple d’un moteur tel que Renderman, il y a un certain nombre de tâches autour de celui-ci. Avant de commencer le rendu, il y a un temps d’export de cache et autre fichier (abc, rib, textures,). Puis vient le rendu en plusieurs passes du moteur. Ensuite nous avons une phase de denoising, puis la phase de recombinaison en un seul fichier, etc… Sans parler des exports des caches d’animation, la création des scènes à chaque update, et tous les processus du pipeline pour transposer les données entre chaque département.

En étant dans Unreal, plusieurs artistes peuvent travailler en même temps sur un même shot sans se marcher dessus. Ils peuvent facilement rester à jour sans attendre des heures de génération de scène pour récupérer le travail de leur collègue. Ils peuvent identifier un problème très tôt dans la chaîne de production et le corriger immédiatement. La visualisation étant immédiate, nous n’avons plus besoin de générer des pre-renders pour vérifier les assemblages de scène et génération de cache. Par exemple, pour qu’un lighter récupère la toute dernière modification qu’un animateur vient tout juste de publier, il lui suffit de lancer une synchronisation de Perforce.

Pour finir, l’arrivée de la version 5.0 d’Unreal a pas mal changé la donne niveau workflows avec l’arrivée de différentes technologies, ce qui affecte nos habitudes de production.

Spécifiquement si on parle de Nanite par exemple, nous pouvons maintenant avoir des scènes qui contiennent des milliers d’assets, constitués de millions de polygones chacun tout en restant à 60 fps. De ce fait, le travail demandé au département Environnement a changé. Historiquement le travail sur les géométries environnementales était toujours animé par une volonté de simplification. Si un polygone et de la normal map suffit pour un mur, on reste sur ça. Aujourd’hui, les artistes peuvent importer le sculpt directement dans le moteur, et améliorer énormément la silhouette des objets sans que ça impact les performances.

Un autre exemple est le World Partition qui apporte une nouvelle approche dans la structuration des scènes. Cela nous permet d’envisager des scènes beaucoup plus grandes. Un terrain de 2km x 2km ou 10 km x 10km est maintenant possible, ce qui simplifie la construction de villes ou de grands paysages. Ceci amène une certaine complexité technique, certes, mais les gains en productivité sont là.

Ces éléments nous permettrons de continuer à répondre aux demandes de productions toujours plus exigeantes que ce soit d’un point de vue temps de production, complexité et budget.

3DVF : Un point qui risque d’intéresser de nombreuses personnes : vous travaillez sur la mise en place d’une formation Unreal issue de votre expérience, qui serait ensuite utilisée pour les nouveaux artistes entrant dans le studio… Mais peut-être aussi proposée à d’autres entités ? Quels seront les axes, et quelle forme prendra la formation ?

L’axe principal sera de proposer une formation professionnelle pour les professionnels de la production d’animation et aux studios désireux de former leurs équipes. Nous nous sommes rendu compte que l’utilisation d’Unreal dans notre pipeline transformait complètement notre manière de travailler et de tracker la production. Il y aura donc bien sûr la formation de l’outil en lui-même, mais dans un contexte de production pure. Ce sera une formation courte, ouverte à tous les acteurs du secteur.

Ce modèle nous permet de répondre au besoin de compétences face à la demande croissante des producteurs en optimisant les budgets et les temps de production.

3DVF : Merci Dwarf pour ces retours !

Nous ne manquerons pas de suivre l’évolution du studio : n’hésitez donc pas à nous suivre sur Youtube, X/Twitter, Instagram, LinkedIn, Facebook pour ne pas manquer nos prochains contenus..

Vous pouvez également consulter la fiche Dwarf Animation sur 3DVF, ou leur site officiel.