La question des LOD est récurrente dans les différentes disciplines liées à l’informatique graphique. Le principe est de décomposer la complexité de ce qu’on souhaite visualiser (souvent, de la géométrie) dans le but d’accélérer son calcul/affichage.

Et comme ce concept peu sembler simple à comprendre, il peut apparaître comme une solution séduisante quand tes rendus n’avancent pas et que ta prod prend l’eau :

Fais des LOD

Les différents types de LOD

Le type de LOD le plus connu est la diminution de la géométrie de l’objet.

Ce mécanisme est très utilisé en jeu vidéo où l’on privilégiera plutôt des grosses textures de normal maps pour l’ajout de détails plutôt que des triangles. En effet, moins il y a de triangles, plus la rastérisation est rapide. Les performances des GPU tombent également quand la taille du triangle à calculer est plus petite que la taille du pixel.

Cette méthode oblige le stockage d’une seconde géométrie (voir plus) en mémoire, là ou stocker des milliers d’instances d’arbres en haute définition ne pose plus de problèmes à nos moteurs. C’est un énorme désavantage, car le switch entre la version haute et basse géométrie doit se faire avant le rendu pour pouvoir être efficace.

Il y a des dizaines de façons de gérer ce type de LOD, la « bonne » va grandement dépendre du degré de flexibilité requis par la production et il est difficile de rester générique quant aux solutions à proposer à ce problème.

Le shading

Une autre façon de faire du LOD consiste à diminuer le shading en fonction de la distance et/ou du nombre d’objet à rendre. Cela peut être une diminution des spéculaires afin d’éviter que des samples de hautes lumières ne sois récupérés par le raytracer pour des petits objets au fond le l’image (des cheminées/antennes métalliques sur des plans large de villes) :

Voici un plan magnifique de villes tout d’instances vétu. Quand on regarde ce qu’il y a dans un pixel, on se rend compte que de nombreux détails apparaissent. Ici, neuf samples sont lancés (3 × 3), mais l’un d’entre eux vient taper l’antenne qui a un haut spéculaire et une très forte valeur. Même une fois moyenné, la valeur du pixel restera très importante (vous aurez des mouches). Si vous avez un problème de la sorte, il y a fort à parier que le problème vient de votre shading, mais quand on a passé 3 jours à éclairer son plan et que quelques mouches cassent les pieds, on prend la solution la plus simple : Désactiver le spéculaire sur l’antenne à partir d’une certaine distance. :grenadelauncher:

Ce type de LOD est vraiment mis à contribution dans le rendu en lancé de rayon où quelques samples peuvent récupérer des valeurs très disparates comparé à leurs voisins du fait d’objets denses en petites géométries et lointains, ce qui occasionne du grain. Idem pour le SSS/bump/normal map qui peut-être volontairement désactivé sur les objets lointains.

C’est au cas par cas, suivant ce qu’on cherche à rendre, sachant que les moteurs gèrent parfois les optimisations de shading en interne, la logique étant toujours de diminuer la variation (variance) des samples en vu de diminuer le grain :

Sur le graphique de droite, la moyenne sera beaucoup moins « stable » suivant les pixels.

Les mipmaps

L’autre mécanisme utilisé à la fois en jeu vidéo et en rendu est l’utilisation de mipmaps. Ce mécanisme est tellement répandu qu’il est souvent géré directement par le moteur de rendu sans manipulations explicite de l’utilisateur. En pratique, vous utilisez l’outil maketx (render --buildtex sous Guerilla) pour convertir les textures dans un format prévu pour le moteur (souvent en .tex). L’outil se charge de générer les mipmaps et le moteur ira piocher à la profondeur nécessaire aux vues de la distance et des surfaces (flous ou nets) parcourues par le rayon. Plus d’informations ici et ici.

Le Stochastic Pruning

Une autre méthode assez impressionnante mais très compliqué à mettre en place : Le Stochastic Pruning. Je vous invite à regarder le PDF, il est très bien illustré (comme tous les PDF de Pixar :siffle:).

Le principe ne peut fonctionner que sur des objets composé de petits objets assez similaires. Les arbres sont un parfait candidat et c’est une (la ?) technique de simplification par excellence des arbres dans le jeu-vidéo. Le fonctionnement est très bien expliqué dans ce billet. Je vous le traduis ici :

  1. Construisez votre objet de N éléments (les feuilles dans le cas d’un arbre, habituellement représenté par des quads).
  2. Ranger les éléments dans un ordre aléatoire (Une manière robuste de le faire consiste à utiliser le mélange de Fisher-Yates).
  3. Calculez U, la portion d’éléments à rendre en se basant sur la distance de l’objet.
  4. Rendez N*U éléments « non-taillé » (unpruned) avec une aire mise à l’échelle par 1/U.

Une petite vidéo du résultat (Rendu rapproché d’un buisson alors que la camera se recule). Et si vous voulez encore plus d’images, c’est par ici.

Comme je le disais, ce système est assez difficile à mettre en place, car il nécessite une relation forte entre le moteur et ce qu’il rend. Je soupçonne qu’il tende à résoudre un problème apparaissant principalement sur un REYES (Vieux Renderman) qui, lui aussi, pédale quand le nombre de triangles par pixel augmente, et à ma connaissance, seul Pixar et Weta l’ont utilisé (sur Cars, Ratatouille et Avatar). Pour être honnête, je pense que cette technique est désuète pour les path tracers (j’explique plus loin pourquoi) mais elle m’a toujours très impressionné alors je partage. :joue:

L’env ball

Celle-là, vous l’avez peut-être déjà utilisée. C’est la bonne vielle technique qui consiste à calculer une env ball à l’endroit ou se trouve le personnage (ou le centre d’intérêt) et d’exclure ce dernier de l’illumination du décor pour ne l’illuminer qu’avec l’env ball (ce qui diminue la variance des samples, et donc, le grain) :

À gauche, le plan. En haut, à droite, on calcule l'env ball (en bleu) à la place de la tête du personnage. En bas, à droite, on illumine uniquement le personnage (en rouge) avec cette env ball en ayant pris soin de l’exclure des autres éclairages.

Cette technique est très efficace sur les plans où le centre d’intérêt est complexe à sampler (SSS dans le cou, cheveux, etc), où il ne bouge pas trop et ou la zone de contact entre l’objet à illuminer et le reste est caché (personnage qui parle au premier plan). Bien entendu, en cas de changement drastique d’éclairage, il faut recalculer l’env ball. Ça fait un certain nombre de contraintes, mais si vous cochez toutes les cases, vous êtes bon ! :banaeyouhou:

Dernière contrainte : Comme le personnage est illuminé par une seul light, l'env ball, certaines AOV (réflexions) seront difficile à obtenir.

Les harmoniques sphériques

J’hésitais à vous en parler, car elles ne sont plus vraiment utilisées en lancé de rayon, mais le principe s’apparente un peu à celui expliqué précédemment. L’idée est de calculer des minis env balls (un terme plus adapté serait plutôt light probes) un peu partout dans un décor. De cette façon, on stocke l’illumination à plusieurs endroits et on interpole en fonction de la distance entre chaque env ball.

Sauf qu’on n’appelle pas ça harmoniques sphériques pour rien… La compréhension du mécanisme nécessitent de bonnes bases en mathématique, mais le principe, plutôt qu’une env ball (qui nécessite du sampling de texture), est d’utiliser des coefficients désignant, grosso modo, la couleur suivant des directions. Voici une image honteusement tirée de ce très instructif billet :

C’est rapide à calculer et comme vous vous en doutez, c’est très utilisé en jeu-vidéo, mais, comme les env balls, la gestion des zones de contact nécessite son propre mécanisme.

Les LOD et la production

Comme tout mécanisme que vous souhaitez utiliser dans vos productions, son fonctionnement doit avoir une réalité technique ou vos graphistes risquent de se battre contre leurs outils pour faire ce que vous avez décidé.

Le truc qu’un responsable (production et supervision) doit savoir, c’est que soit l’usage des LOD est exceptionnel (c-à-d. au cas par cas) et c’est la compétence du graphiste qui prend le relais. Dans ce cas, l’utilisation de LOD est justifié et son usage est adapté, car la portée de sa mise en place est connu ; eg. un simple plan. Les graphistes qui maîtrisent différentes méthodes et savent gérer leurs LOD au plan sont du pain béni pour la fabrication, surtout quand le projet est complexe et que le support est congestionné par des demandes générales. Soit le projet implique une utilisation des LOD plus fréquente/constante, ce qui implique de l’automatisation (le mot magique des incantations occultes) et les discussions sur comment ils doivent être gérés (les « choix techniques » au fond) doivent être mené entre la production, la supervision et la technique. Le but étant d’anticiper les besoins et d’éviter de se retrouver, plus tard, dos au mur ; « Mais on ne peut pas faire ça ? », « Non, tu ne l’as jamais demandé… », « Mais enfin, c’est évidant ! ».

Bref, c’est un sujet complexe alors soyez pro. :hehe:

Conclusion

Voici pour ce billet qui ne répond, finalement, pas à grand-chose, mais que j’espère instructif. :smileFou:

:marioCours: