- RenderFormer est un pipeline de neural rendering qui implémente directement jusqu’aux effets d’illumination globale dans des scènes basées sur des maillages triangulaires
- Aucun apprentissage ni ajustement fin spécifique à chaque scène n’est nécessaire
- Le rendu est défini comme une transformation séquence à séquence, convertissant directement des tokens de triangles en tokens de patchs de pixels
- L’ensemble du pipeline est conçu sur une base Transformer, avec seulement un minimum de contraintes a priori
- Les images sont générées sans rasterisation ni ray tracing
Introduction
- RenderFormer est un pipeline neuronal qui effectue directement le rendu d’images à partir d’une représentation de scène basée sur des triangles
- Il produit des images avec des effets d’illumination globale entièrement appliqués
- Son architecture fonctionne sans nécessiter d’entraînement ni de fine-tuning distincts pour chaque scène
Approche
- Contrairement aux approches classiques de rendu physique, le rendu est redéfini comme un problème de transformation séquence à séquence
- Une séquence de tokens contenant les triangles et leurs propriétés de réflexion est transformée en une séquence de tokens de sortie, chacun converti en un petit patch de pixels
Structure du pipeline
- RenderFormer est composé d’une architecture en 2 étapes
- Étape indépendante du point de vue : modélise les phénomènes de transfert d’éclairage entre triangles
- Étape dépendante du point de vue : convertit des tokens représentant des faisceaux de rayons en valeurs de pixels. La séquence de triangles issue de l’étape précédente sert alors de guide
- Les deux étapes reposent sur une architecture Transformer
- L’apprentissage est réalisé avec seulement un minimum de contraintes a priori
Caractéristiques techniques
- Lors du rendu, aucune méthode traditionnelle comme la rasterisation ou le ray tracing n’est utilisée
- Les capacités de transformation de séquence des Transformers sont exploitées de manière active
Conclusion
- Par rapport aux techniques de neural rendering existantes, il s’agit d’une approche capable de générer des images flexibles et de haute qualité sans préparation supplémentaire ni ajustement scène par scène
1 commentaires
Avis Hacker News
Le point le plus impressionnant, c’est la vitesse. Sur une même scène, RenderFormer termine en 0,076 s, alors que Blender Cycles prend 3,97 s (ou 12,05 s avec des réglages plus élevés). Pourtant, l’indice de similarité structurelle (SSIM) est de 0,9526, donc la différence est minime. Je recommande de regarder les tableaux 2 et 1 du papier. En pratique, cela signifie que les designers 3D pourraient avoir des aperçus de rendu instantanés, de bien meilleure qualité, via un modèle transformer on-device dans une app web ou native. Cela dit, ces résultats ont été mesurés sur un GPU A100 sans optimisation PyTorch, donc le GPU d’un utilisateur lambda ne sera pas aussi rapide, mais on peut quand même s’attendre à un gain de vitesse suffisant par rapport au rendu classique. Dans un système web, on pourrait aussi connecter un A100 en backend et streamer l’image résultante vers le navigateur. Les limites sont néanmoins claires. Plus la scène devient complexe, plus la précision baisse, et des erreurs sont particulièrement probables avec des ombres complexes, notamment avec des particules ou des cheveux. Le rendu final devra donc toujours être produit par des méthodes traditionnelles pour éviter les artefacts fréquents dans les images/vidéos générées par IA. Malgré tout, si le gain de vitesse est suffisamment important, on peut imaginer un usage dans de grands studios d’animation pour des rendus de prévisualisation à l’échelle d’un film, par exemple pour revoir la musique ou le story
Je ne pense pas que les chercheurs aient volontairement déformé les faits, mais avec un GPU de ce niveau Blender Cycles pourrait rendre toutes les scènes du papier en moins de 4 secondes. Les scènes utilisées dans le papier sont elles-mêmes peu complexes, et Blender a été configuré pour échantillonner 4 000 fois, alors qu’en pratique on atteint une qualité presque finale après quelques centaines d’échantillons, le reste ayant très peu d’effet. Cela revient donc à gaspiller inutilement les ressources GPU. En plus, ils semblent avoir inclus dans le temps de rendu la phase initiale de préparation de Blender, tout en excluant le temps d’initialisation du transformer. Je serais aussi curieux de connaître le temps de rendu de la deuxième frame sur chaque système. J’imagine que Blender serait alors bien plus rapide. Quoi qu’il en soit, les résultats du papier sont intéressants, mais il y a quelques nuances dans les réglages de Blender et dans la comparaison des timings
Au vu des scènes montrées, 76 ms, c’est plutôt lent. Bien sûr, je pense que ça ira beaucoup plus vite à l’avenir, mais il me semble encore trop tôt pour dire que c’est meilleur que le rendu traditionnel
La comparaison temporelle du papier est un peu inexacte. En ray tracing, l’erreur diminue selon la racine carrée du nombre d’échantillons. Pour générer les images de référence, le papier utilise un nombre d’échantillons irréaliste, alors que les renderers offline en utilisent en pratique 10 à 100 fois moins. Les images produites avec autant d’échantillons comme dans le papier servent à comparer la qualité, mais s’en servir pour comparer les temps n’est pas habituel. Comme le résultat n’est pas rigoureux, il serait plus juste de le comparer à d’autres algorithmes de rendu donnant une approximation similaire. Aujourd’hui, les combinaisons de path tracers temps réel et de denoisers peuvent aussi rendre des scènes bien plus complexes en moins de 16 ms sur des GPU grand public. En particulier, le modèle transformer a un temps d’exécution proportionnel au carré à la fois du nombre de triangles et du nombre de pixels. Il y a peut-être eu des améliorations dans la recherche récente en machine learning, mais il sera difficile de battre le scaling d’un path tracer traditionnel en O(log n triangles), O(n pixels) (en pratique, il est même moins sensible à l’augmentation du nombre de pixels grâce à la cohérence entre pixels voisins)
Je suis surpris par l’affirmation sur la vitesse. J’ai parcouru rapidement le papier, mais je n’ai pas réussi à voir clairement si Blender Cycles utilisait le CPU de l’A100 ou des kernels CUDA. S’il s’agit d’une seule frame, le temps de démarrage du renderer a peut-être été inclus. S’il s’agit d’un rendu en séquence, le temps par frame diminue fortement. Et, comme d’autres l’ont mentionné, la complexité en triangles (scaling en O(n^2)) aura clairement un impact
Le papier indique que « la complexité temporelle des couches d’attention augmente quadratiquement avec le nombre de tokens, c’est-à-dire ici le nombre de triangles. Nous limitons donc le nombre de triangles dans une scène à 4096 »
Le deep learning est aussi utilisé avec beaucoup de succès pour le denoising des images de rendu en global illumination. L’idée est de produire une image de global illumination brute avec un ray tracing traditionnel, puis de laisser un réseau neuronal supprimer le bruit de l’image de sortie. Lien connexe : Open Image Denoise
J’ai un ami qui développe réellement des renderers physiques pour l’industrie du cinéma, et c’est toujours fascinant d’entendre parler de leurs méthodes de travail. Je me demande quelles entreprises recrutent ce type de profil en ce moment. Je me demande aussi si les entreprises d’IA embauchent des ingénieurs rendering pour construire des environnements d’entraînement. Si quelqu’un cherche à recruter un ingénieur expérimenté en recherche/industrie du rendering, je peux faire l’intermédiaire, car mon ami n’est pas sur les réseaux sociaux
Je trouve étrange qu’aucun des exemples ne montre d’objets situés derrière la caméra. Je ne sais pas si c’est une limite de la composition des exemples ou de l’approche elle-même, mais pour les réflexions et l’éclairage, ce qui se trouve derrière la caméra est très important
Encore un moment qui illustre "the bitter lesson". On voit maintenant cette tendance s’appliquer aussi au rendu graphique. NeRF utilisait en partie des a priori basés sur le ray tracing, Gaussian splat des a priori basés sur la rasterization, alors que cette approche tente de tout résoudre avec uniquement les données et l’attention, en abandonnant ces a priori métier et ces connaissances spécialisées. J’ai l’impression que c’est ça, l’avenir
Je trouve impressionnant qu’on soit arrivé à une boucle complète où le rendu et le compute se renvoient mutuellement la balle autour du GPU
Le résultat est correct, mais un peu flou. J’aurais aimé voir davantage de comparaisons de temps de rendu entre réseaux neuronaux et renderers classiques
Dans les animations (surtout Animated Crab et Robot Animation), on remarque des artefacts typiques de l’IA, avec un effet de tourbillon non naturel autour du modèle lorsque l’objet ou la caméra bouge
Le papier discute un peu de la comparaison des temps. Par rapport à Blender Cycles (path tracing), l’approche neuronale est bien plus rapide, au moins pour les scènes de 4K triangles ou moins. En revanche, elle est peut-être mal adaptée aux scènes plus complexes (puisque le runtime de l’attention augmente quadratiquement avec le nombre de triangles). Lien du papier : PDF du papier RenderFormer. À mon avis, une approche réaliste pourrait consister à utiliser la méthode neuronale uniquement pour l’éclairage indirect, à générer l’image de base avec un rasterizer traditionnel, puis à n’ajouter que la Global Illumination via le modèle neuronal
Je ne maîtrise peut-être pas bien le sujet, mais si ces scènes sont au final rendues de la manière attendue, je me demande quel avantage cette méthode a par rapport à des approches directes plus simples (surtout si ce n’est pas plus rapide)
En fait, cette méthode pourrait produire des effets plus intéressants qu’il n’y paraît. Par exemple, on pourrait considérer une scène comme un seul bloc de poids d’entrée, y ajouter du bruit, ou interpoler entre différentes scènes pour obtenir des résultats inattendus
Au final, je pense que cette approche relève surtout de la catégorie « Cool Research ». Son utilité pratique est faible, parce que le coût augmente quadratiquement avec le nombre de triangles. C’est pourquoi le papier limite aussi chaque scène à 4096 triangles
Comme mentionné dans un autre commentaire, cette approche est bien plus rapide. La global illumination est vraiment très lente avec des méthodes directes
Ça me semble être une recherche originale. Le fait que les transformers puissent s’appliquer non seulement au langage naturel mais aussi à divers types de données continues et à des domaines caractérisés par des corrélations entre tokens me fait attendre avec intérêt les recherches futures sur leur application à des domaines non textuels. Je me demande quels autres domaines non textuels les utilisateurs de Hacker News trouvent particulièrement intéressants pour les transformers
Je trouve l’idée extrêmement ingénieuse et fascinante. On entraîne un transformer qui convertit une description de scène en ensemble de triangles vers un tableau 2D de pixels, et il produit presque instantanément une image très proche du résultat d’un renderer classique de global illumination. Après cinq ans de recherche, le fait que ce soit possible ne devrait plus être si surprenant, et pourtant ça reste très impressionnant. On sent à quel point l’architecture transformer est polyvalente. C’est incroyablement rapide, le résultat ressemble beaucoup à la sortie de Blender, le modèle fait environ 1B de paramètres, et je ne sais pas si c’est en fp16 ou en 32, mais le fichier pèse 2 Go, ce qui est conséquent. J’aimerais voir des démos sur des scènes plus réalistes, mais j’aime aussi le fait que je puisse le télécharger tout de suite sur mon Mac et le faire tourner moi-même