{"partition": "head_middle", "source_domain": "www.fevrierdorian.com", "digest": "sha1:PUDYXXQBS6MJ7426QKDKHKHOKV22CSC7", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2014-15/000_00035.parquet"}
A CG nerd tale
Dorian Fevrier's blog
Technical skills of animators are both good and bad. They are the quantic parameter of a production.
About me - CV
Rechercher « Exporter des curves d'anim et nettoyez le fichier
- Mental ray for Maya: Diminuer le flicking du Final »
Présentation d'une publication: Sorted Deferred Shading for Production Path Tracing
Par Narann le samedi, juillet 6 2013, 22:42 - Infographie 3D - Boulot
shading point
Ce billet est une présentation très succincte d'une publication de Walt Disney Animation Studios datant de 2013 visant à expliquer les tenants et aboutissants du "tri" des rayons et shading points avant leur calcul: Sorted Deferred Shading for Production Path Tracing.
Je ne rentrerais pas dans les détails et un développeur un peu à l'aise avec le raytracing tirera surement beaucoup plus d'informations du papier original. Introduction
Tout d'abord pourquoi parler de ça sur ce blog? Comme vous avez surement pu le constater, je ne suis plus très actif. Sachez que ce n'est pas uniquement un manque de temps mais surtout de sujets à aborder.
En effet, au fils des années j'ai commencé à travailler sur des problématiques de plus en plus complexes et de moins en moins génériques. Il y avait donc très peu d’intérêt d'aborder les sujets ici.
J'ai un certain nombre de billets que j'ai commencé sans jamais les finir car les sujets abordés n'étaient soit pas intéressants (mon point du vue sur la vague des "logiciels de rendu") sois trop spécifiques (il n'est pas évident d'aborder les technologies maisons des studios ).
Bref, ce n'est pas pour autant que j'ai chaumé et j'ai emmagasiné un bon paquet d'infos, de connaissances que je commence à maitriser, en tous cas, suffisamment pour en parler. L'idée m'est donc venue de vous parler de différentes publications (papers en anglais) dont vous avez surement déjà dû voir ou entendre parler, leur sortie étant très florissante pendant la période du Siggraph. Maintenant, pourquoi cette publication là en particulier?
Et bien parce que depuis quelques années l'idée que le full raytracing "va tout simplifier" s'est généralisée. Le maitre incontesté de cette philosophie est sans conteste Arnold à qui on pourrait presque reprocher son approche quasi religieuse, mais le virage abrupt de Renderman vers du full raytrace tend à lui donner raison. Et pourtant. Non, tout n'est pas rose au pays du full raytrace. Car si de nouvelles choses sont possibles, de nouvelles problématiques apparaissent et oui, il faut "tricher". Le rayswitch devient la norme et tout moyen visant à gagner du temps est mis à profit, car c'est bien le rapport temps/qualité qui détermine l'efficacité d'un moteur, et la course à la puissance a aussi ses limites. Cette publication est intéressante car elle permet, de par la problématique qu'elle aborde (GI raytrace) de comprendre les défis et limites que peuvent/vont rencontrer les moteurs de rendu modernes.
Avant propos
Avant de commencer je voudrais préciser quelques points techniques importants. Ces notions ne sont pas forcément très connu des graphistes, pourtant je pense qu'elle ont beaucoup de sens, même à notre échelle.
Rayon cohérent/incohérent
Un terme fréquemment utilisé quand on parle d'optimisation du raytracing est cohérent/incohérent mais doit se comprendre comme qui varie peu/qui varie beaucoup/presque aléatoire.
Ces images sont tirées du très instructif article de Intel expliquant le fonctionnement de Embree: Embree: Photo-Realistic Ray Tracing Kernels. Pdf ici.
A gauche: Ce sont des rayons cohérents. Ils partent d'un même point et vont dans une direction particulière (même si cette direction est plus ou moins "ouverte"). Le nombre d'objets que vont toucher ces rayons est faible.
A droite: Ce sont des rayons incohérents. Ils vont et viennent de toutes les directions. Bien entendu, le nombre d'objets que vont toucher ces rayons est important.
Vous allez très vite comprendre le pourquoi du comment. Rays et Shading Points
En raytracing on fait souvent la distinction entre le lancer de rayons en lui même (savoir quelle géométrie le rayon va toucher dans la scène) et le shading du point (le fait de calculer la couleur, la reflection, tout ce qui est lié au matérial sur ladite géométrie).
Ce sont deux étapes très différentes:
Out-of-core
Le terme out-of-core est un terme que l'on rencontre souvent dans les calculs massivement distribués. La page Wikipedia explique bien le principe mais en gros, core est un ancien terme pour désigner la mémoire vive. Out-of-core fait donc référence à des calculs sur des données qui ne sont pas stockées dans la mémoire vive mais directement sur le disque.
Pour être efficace, un calcul out-of-core doit lire le minimum d'information sur le disque, et donc, les informations les plus pertinentes.
Si vous comprenez ces notions, la suite va vous sembler évidente. Traduction
Toute bonne publication commence par la partie la plus courte et la plus simple à comprendre: Abstract. Même si ce genre de lecture ne vous fait pas rêver, je vous encourage à la lire si vous vous intéressez un temps soit peu à la technique.
Le principe est de résumer, aussi simplement que possible, en quelques phrases, ce que présente la publication.
L'illumination globale (GI) en lancé de rayon se généralise dans le rendu de production mais l'incohérence des rayons secondaires limite son utilisation à des scènes qui peuvent être placées intégralement en mémoire.
L'incohérence du shading entraine également d'importants soucis de performance lors de l'utilisation de nombreuses (et lourdes) textures qui oblige le moteur de rendu à recourir aux caches d'irradiance, de radiosité, et autres moyens pour diminuer le cout du shading.
Malheureusement, cette mise en cache:
Complique le travail du graphiste
Est difficile à paralléliser efficacement
Occupe une précieuse mémoire.
Et pire, ces caches impliquent une approximations qui altère la qualité.
Dans cette publication, nous présentons une nouvelle structure de path tracing qui évite ces compromis. Nous organisons les rayons en gros paquets, potentiellement hors du core, pour assurer la cohérence des rayon lancés.
Nous retardons le shading des points touchés par les rayons jusqu'à ce que nous les ayons trié, ce qui permet un shading cohérent et évite d'avoir recours à des caches.
Et voilà pour Abstract!
Avouez que ce n'est pas non plus la misère à comprendre. On enchaine avec l'introduction qui résume grosso modo ce que présente Abstract.
La GI en path-tracing offre de nombreux avantage en rendu de production: Un éclairage plus riche, plus plausible avec moins de lights et évite la lourde gestion des données liées aux point clouds (PTC) et aux deep map shadows.
Bien que cette approche offre une meilleure image et une productivité accrue, les performances se dégrade de manière importante à mesure que la géométrie et les textures dépassent la capacité mémoire disponible.
Ainsi, les moteurs de rendu de production existants s'évertuent à lancer le moins de rayons possible et à calculer le moins de points de shading possible, privilégiant l'utilisation de caches d'éclairage/de shading et de géométrie instanciées. Mais ces mesures gênent le travail des graphistes.
A mesure que la recherche améliore l'intersection rayon/géométrie, le calcul de shading points incohérent devient un problème de plus en plus conséquent.
En particulier, l'accès incohérent à d'énormes textures de production entraine de fréquents cache-misses (à traduire: "Pas dispo dans le cache de texture? S'pas grave, on reload!") provoquant des pauses importantes due à la latence d'accès mémoire/disque/réseaux durant le calcul.
Les caches d'irradiance et de radiosité tentent de minimiser cela, bien que leur non-directionalité inhérente ne les rendent efficace que pour des surfaces parfaitement diffuses. (ndt: Par "non-directionnalité", comprenez qu'on ne peut stocker l'irradiance d'une surface réfléchissante, qui "varie en fonction de la direction", miroir etc... Le chercheur semble toutefois oublier qu'une irradiance est tout à fait "stockable" sous la forme d'une spherical harmonique, ce qui permet de palier à ce problème).
Par conséquent, il est d'usage de séparer les techniques en fonction du type de rayon à calculer (diffus, spéculaires et caustiques) ce qui complique encore le travail des graphistes.
Pire encore, ces approches sont difficiles à adapter à des architectures multi-core à cause de la synchronisation, l'effet NUMA (le fait d'aller chercher des informations un peu partout dans la mémoire diminue drastiquement ces performances) et l'équilibrage de la charge (load-balancing).
De fait, il est préférable d'éviter les caches et privilégier un shading cohérent.
Dans cette publication, nous présentons un ray-tracer continu capable d'effectuer plusieurs rebonds de GI dans une scène de production sans recourir à des caches de shading ou des instances.
Pour y parvenir, nous introduisons une nouvelle approche de tri de rayon en deux étapes.
Dans un premier temps, nous organisons les rayons en gros paquets, potentiellement hors du core (stocké sur disque donc), pour s'assurer de leur cohérence.
Travailler avec de gros paquets est essentiel pour extraire les groupes de rayons cohérent d'une scène complexe.
Dans un second temps, nous trions les rayons ayants touchés (les fameux ray hits) pour calculer les shading des points en utilisant les textures hors du core.
Pour chaque lot, nous réalisons un shading parfaitement cohérent avec des lectures de textures séquentielles, ce qui élimine la nécessité d'un cache de texture.
Notre approche est simple à implémenter et compatible avec la plupart des techniques de casting de scène.
Nous démontrons l'efficacité de notre tri en deux étapes combiné au paquets de rayons hors du core et comparons nos résultats avec les deux principaux ray-tracers de production: PhotoRealistic RenderMan (hum... ) de Pixar et Arnold de Solid Angle.
Je m’arrête là, pour plus d'explications, il faut lire la publication! Explications
Ce qu'explique cette publication c'est que le fait d'avoir beaucoup de rayons incohérents va nécessiter un load de quasiment toute la scène pour calculer les intersections des rayons, puis, en parallèle, va nécessiter de loader un grand nombre de textures différentes pour calculer le shading de ces rayons. Tout ça juste pour calculer l'illumination d'un seul point.
Et sur une scène plus dense:
Imaginez chaque zone comme un énorme asset avec beaucoup de géométrie et beaucoup de textures. On ne peut pas tout loader en RAM. Du-coup, pour calculer l'illumination global d'un point ça risque de faire tourner le cache inutilement.
La solution proposée consiste à rassembler les rayons allants dans des directions similaires et de les calculer en même temps, d'un seul bloc. La quantité de données à charger sera donc moins disparate/plus pertinente et permettra d'éviter de charger et décharger le cache, opération couteuse en temps.
Grossièrement cela donne ça:
Partant de là on peut imaginer pas mal d'approches:
Calculer quelques samples "à l'ancienne", pour sortir une "map" d'environnement, récupérer son importance et générer plus de rayons à lancer dans certaines directions plutôt que d'autres (si une direction renvoit majoritairement du noir, il n'y a pas de raison d'envoyer autant de rayons qu'une direction plus clair qui va avoir une influence plus importante sur la solution finale).
Comme on a une utilisation plus optimisé du cache, on pourrait imaginer que le calcul des intersections soit fait sur le GPU, après y avoir chargé un paquet de rayon. Les échanges RAM/VRAM étant le goulet d'étranglement traditionnel de cette approche, on peux espérer repousser ces limites. L'avantage en cas de multi GPU c'est de pouvoir lancer un paquet d'une direction sur un des GPU et un autre sur le second GPU. Une fois qu'un GPU a fini son calcul, on pourrait en tirer une importance et générer des paquets plus "intéressants" (importance driven).
Après une première "passe", on stocke les résultats des shading points par object (on doit pouvoir les "compresser" si ils ont la même couleur, en leur donnant un "facteur de présence"). Lors de la seconde "passe" le calcul d'intersection des objets éloigné/peu "importants" se fait sur une version allégé de la géométrie (plus rapide à intersecté) et le résultat du shading point est récupéré directement, de manière aléatoire, dans le tableau des valeurs de shading points stocké précédemment sur l'object. De cette façon, plus aucune raison de calculer les shading points lors de la seconde/troisième passe, faisant des économies de ressource indirect conséquent (cache de texture notamment). Même si cette approche est biased, dans le cas de rayons incohérents, elle pourrait se révéler très efficace.
On combine toutes ces approches en même temps! Conclusion
J'espère que ce petit billet vous aura intéressé et vous aura permis de comprendre un peu ce qui se passe dans un raytracer quand il doit parcourir une scène et tout particulièrement les limites qu'il peut y avoir durant cette étape.
A bientôt!
Billets similaires
Mental ray 3.9: L'Unified Sampling, explications
Mes impressions sur mental ray et son futur
Deex VRay Arsenal, un petit tool qui fait gagner beaucoup de temps
Deex VRay Arsenal, a small tool that saves a lot of time (English Traduction)
Le lundi, septembre 30 2013, 01:17 par efflam mercier Si j'ai bien compris, les rayons incohérents c'est les rayons GI des secondary bounces?
je comprends mieux pourquoi certaines scènes sont longues render :D
Hey c'est franchement cool ce genre de post!
Je vais m'abonner à ton blog et lire un max de posts !
J'ai lu l'article wiki sur les spherical harmonics mais j'ai pas pigé grand chose, ça permet de stocker une illumination dans une espèce de version sphérique d'une scène ?
PS: pourquoi le trollface après la mention de Prman? ^^
à plus !
Le mardi, octobre 1 2013, 23:15 par Dorian Hello Efflam! :)
En fait, les rayons de GI sont déjà des rayons secondaires. Les rayons primaires sont ceux qui partent de la camera, tous les autres (reflection, refraction, GI), sont des rayons secondaires. La particularité des rayons diffus (GI) c'est d'être incohérent et c'est ce qui ouvre toute ses possibilités de recherche pour pouvoir accélérer le rendu des rayons de GI. Les spherical harmonics ne sont pas forcément lié au rendu, c'est plus large que ça en fait. (c'est surement la raison pour laquelle il est difficile de s'y retrouver sur la page wikipedia). Dans le cas qui nous intéresse (le rendu) ça permet de stocker des couleurs en fonction d'une direction (une map d'env très blurré en gros) mais avec un très faible nombre de paramètre ce qui rends la chose assez légère (c'est pour ça que c'est pas mal utilisé en jeu vidéo). Mental ray les utilises pour ces points de Final Gather depuis la version 3.5, ce qui permet à chaque FG point d'avoir virtuellement une petite map d'env pour calculer sa couleur de GI (notamment en cas de bump).
Le gros problème c'est que ça nécessite une étape de bake, et ça ne fonctionne pas efficacement sur les zone de contact. En jeu vidéo on s'en fout, mais en full CG ça pique les yeux.
Pour comprendre le trollface je vais réexpliquer la phrase:
avec les deux principaux ray-tracers de production: PhotoRealistic RenderMan de Pixar et Arnold de Solid Angle.
(lol, rien qu'en la relisant elle me fait rire )
Ce qu'il faut savoir c'est qu'à la base, RenderMan est tout sauf un raytracer (C'est un REYES). Jusqu'à il y a peu (moins d'un an?), il avait un retard monstrueux la dessus. Donc dire que RenderMan fait parti des deux principaux raytracers de production je trouve ça un poil zélé.
Demande à n'importe quelle personne qui connait RenderMan de te sortir une illumination global en full raytrace, rien qu'en lui prononçant ces mots il devrait changer de visage (genre: ).
En anglais c'était:
with two state-of-the-art production ray tracers, Pixar’s PhotoRealistic RenderMan and Solid Angle’s Arnold
Formulation que je trouve encore plus osé. ^^
Si tu veux plus d'informations sur le REYES, je te conseil la page de Pixar. Sur les Spherical Harmonics en mode "graphiste", la page CGTalk. Sur l'utilisation des Spherical Harmonics sur Avatar, la page de fxguide.
En espérant que ça t'aide. :)
2+3?
CatégoriesInfographie 3D - Boulot (46)Script et code (43)Crashs et bugs (5)Mes coups de coeur (19)Billets aléatoires CgFX - Des shaders temps réel dans le viewport Maya! - Part 4 (Re)Lancer 3D Studio 4 et faire de la 3D comme à l'ancienne! Des passes simples à compositer: Le Pendule Le linear workflow dans Maya Trucs Sociaux
Mon profil LinkedIn Mon profil IMDb Me suivre sur Twitter Ma galerie Flickr Mon profil Vimeo Mon repo Bitbucket Mon Wiki
S'abonnerFil des billetsFil des commentairesTagsfr maya python script mental ray 3d en mel code rendu shader api vray astuce tuto fichiers cgfx opengl map node Tous les tagsContenus de ce blogCreative Commons Attribution-NonCommercial-ShareAlike 2.0 France Propulsé par Dotclear