Temps-réel vs Rendu traditionnel : un exemple bien documenté avec des dragons !

par | 10 Nov 2022

Aurélien Martineau vient de publier une vidéo dans laquelle il se lance le défi de comparer le rendu de l’un de ses projets sous VRay avec un rendu sous Unity. Au passage, ll nous explique comment il est passé de l’un à l’autre. Le premier rendu va prendre environ 1 h 40 pour 120 images (soit 4 seconde à 30FPS) alors que le second, prendra 50 secondes sous Unity. Oui, il y a tromperie dans le titre, ce n’est pas un rendu temps-réel. Mais on utilise bien un moteur de jeu qui fait lui du temps-réel, comme moteur de rendu – c’est là que vient l’astuce. Et entre 1 h 40 et 50s, il y a un gap important ! À savoir qu’on pourrait très bien raisonner de la même façon avec d’autres systèmes de rendus et d’autres moteurs de jeux comme Unreal Engine.

L’expérience en vidéo

Parlons un peu technique

Ce qui est intéressant, c’est qu’on entre un peu dans la technique. Aurélien nous dit qu’il y a déjà 2 problèmes qu’il anticipe au lancement de son projet. Sous 3DSMax, il a utilisé des modifiers FLEX (pour rendre un objet flexible lors des animations) et des Turbosmooth (pour rendre l’objet plus lisse) ce qu’il pense ne pas pouvoir retrouver sous Unity. Si le second peut s’arranger facilement en appliquant le modifier avant l’export, c’est un peu plus délicat pour le premier. Au lieu d’utiliser le format d’export FBX, Aurelien passe par Alembic développé par Sony Pictures Imageworks et Industrial Light & Magic et maintenant supporté par de nombreux moteurs de jeu. En réalité, il s’agit ici d’envoyer, comme il le précise, une sorte de stream d’informations 3D. Ce qu’il veut dire, c’est qu’au lieu d’obtenir un objet exploitable par le moteur de jeu, on obtient une animation déjà précalculée que le moteur n’aura plus qu’à rendre, cette fois, en temps-réel. De fait, on peut utiliser le meilleur des deux mondes. C’est souvent ce qu’on utilise pour les simulations physiques qui sont « baked » (précalculées). Il reste toutefois à retravailler certains matériaux, notamment les yeux du dragon (voir à partir de 10 min)  – pour ne pas avoir à passer par la création de matériaux complexes, il va passer par une opération de render-to-texture, c’est-à-dire, précalculer les matériaux (avec une petite perte certes) ! Il y a aussi un travail à faire sur la colorimétrie, mais il s’agit plus d’une adaptation, car Unity possède les outils pour. Pareil pour la caméra, mais plutôt que de l’importer, il préfère reproduire l’animation directement.  Concernant les réflexions, il va passer par des SSR (Screen Space Reflection) qui est une sorte d’astuces pour simuler de la réflexion, mais là on est loin de ce que peut sortir du RTX ou même Lumen d’Unreal Engine 5. Traduisez : il aurait pu faire encore beaucoup mieux s’il avait eu la bonne carte Graphique (qui fait du lancé de rayon temps-réel) ou un autre moteur de jeu.

Analyse du résultat

Après avoir effectué le rendu sous Unity… mais attention, nul besoin de temps-réel en réalité. En effet, on utilise ici un moteur de jeu pour faire un rendu image par image qu’on va assembler dans une vidéo. Alors, autant mettre la qualité au MAX, puisqu’on se moque du framerate. Cette technique peut être utilisée dans beaucoup de moteurs de jeu permettant ce type de rendu in-engine (et non in-game). Sous Unreal Engine, il s’agit du Sequencer qui est capable d’exporter sous la forme d’une vidéo. Les deux rendus (VRay et Unity) sont visibles en 13 min 55. Et franchement, c’est très proche ! Evidemment, sous VRay, les ombres et reflections sont irréprochables. Mais cela tient ici plus de l’utilisation du moteur qu’en a fait Aurélien, car aujourd’hui, soit en utilisant du RTX/DXR, soit en utilisant les capacités internes de moteurs comme Unreal Engine avec Lumen (illumination globale et reflections temps-réel), on arrive à un résultat encore plus proche.

Alors, 40K€ d’économies ? Déjà, le rendu est 120 fois plus rapide (dans cet exemple, cela va varier d’un projet à un autre). Aurélien conclus que si on travaille déjà avec des assets dépliés et bakés pour le jeu, on peut bien se passer de faire un rendu sous Vray, pour le réaliser directement dans un moteur de jeu. Et encore une fois, c’est sans parler de la technologie Nanite d’Unreal Engine qui est capable de travailler avec les mêmes assets que les studios d’animation, soit en très haute définition. Les 40K€ sont sur un projet de 5400 frames (3 minutes à 30 FPS). Cela prendrait 16 semaines de rendu (sur sa machine) sous Vray !  En fait, il prend le coût qu’une ferme de rendu lui prendrait pour faire ce travail en 1H, soit entre 3K€ et 4.5K€. Ensuite, il projette ceci sur une dizaine de projets à l’année. Ah, cette fois, c’est pas moi qui ait fait du putaclic sur le nom 😉 Plus sérieusement, oui, il a raison, ça se calcule, c’est juste un exemple, mais cela donne au moins un ordre d’idée.

Qui est Aurélien Martineau ?

3D Lead au sein du groupe Partouche, il est aussi formateur chez Brassart Tours.  Abonnez-vous à sa chaîne Youtube, si vous souhaitez d’autres expériences similaires. Il fait aussi des vidéos de formation sur Unity HDRP, sur Substance Painter ou encore des tutoriels sur les bases de la 3D.

Découvrez nos derniers numéros !

0 commentaires

Laisser un commentaire

Ces articles pourraient aussi vous intéresser …

Participez à partir de 1€ à notre campagne sur Ulule
pour obtenir le magazine sous forme papier

cliquez pour aller sur la campagne

Ceci fermera dans 21 secondes