12/08/2020 : Cet article est en cours de rédaction. Comme il va me prendre plusieurs semaines je le mets en ligne pour mon usage personnel. Si vous tomber dessus par hasard, veuillez tenir compte de ce paramètre.
Cette article et en grande partie une traduction de l’article « Debugging & optimize » du site de Rendederman.
Lorsque cela est possible j’essaye de généraliser les conceptions à d’autre moteur de rendu Monte Carlo.
En préambule, quelque soit votre niveau de connaissance des moteurs par lancé de rayons, il peut être utile de relire ces deux articles de wikipedia :
Vue d’ensemble
Les artefacts et les rendus lents peuvent être soources de stress, tout particulièrement lorsque les Deadline approchent… Sans les bons outils et les bonnes techniques, le débogage et l’optimisation d’une scène peut rapidement devenir chronophage et nous faire perdre un temps précieux pour livrer un job.
Dans cet article, nous traiterons de quelques techniques de base qui peuvent être utilisées pour mieux comprendre ce qui se passe lors d’un rendu.
Avoir une meilleur connaissance des phénomènes qui entre en jeu lors d’un rendu permet de mieux repérer les problèmes et surtout les goulots d’étranglement afin d’achever une image dans un meilleur temps et avec une qualité supérieur.
Grâce à ces connaissances, vous serez en mesure d’anticiper les problèmes dès la construction de vos scènes afin de les écarter avant même qu’ils ne deviennent un problème.
1. Qu’est-ce que le débogage et l’optimisation ?
Avant de commencer, voyons ce que signifient les mots « optimisation » et « débogage » dans cet article :
Souvent, les artefacts sont inadmissible car ils vous empêchent d’obtenir la qualité d’image désirée. Ansi, vous n’avez donc souvent pas d’autre choix que de les supprimer. Pour ce faire, il faut soit trouver la source du problème et le résoudre, soit la maquiller en Compositing.
L’approche à privilégier dépend de la situation. S’il ne s’agit que d’une poignée de frames, il est généralement plus rapide de les maquiller en Compo, le problème étant que vous risquez de rencontrer à nouveau le même problème à l’avenir.
A l’opposé, si des artefacts sont présents sur la majorité de vos frames, le fait de régler le problème a sa source permet de s’en débarrasser une fois pour toutes et ainsi d’améliorer durablement la qualité et l’efficience de vos rendus.
Les temps de rendu long, contrairement aux artefacts, peuvent être acceptable dans une certaine mesure.
En effet, si l’on adment que l'(objectif ultime est la qualité, un rendu long peut impliquer simplement que soit on attendent plus longtemps pour atteindre ce but, soit on peut s’équiper de matériel plus performant pour réduire
Cependant, il existe une approche plus ingénieuse et plus intelligente pour réduire vos temps de rendu, donc réduire vos coût tout en améliorant votre productivité : comprendre et maîtriser vos moteurs de rendu.
Pour en revenir au sujet de ce chapitre, le débogage est un problème auquel vous serez confronté un jour ou l’autre dans le but d’atteindre le niveau de qualité d’une image pour un job donné.
L’optimisation par contre, peut être « optionnelle » et en théorie n’agit pas sur la qualité final mais uniquement sur votre productivité et donc sur vos cout et votre rentabilité.
Cela implique également de pouvoir viser une qualité supérieur pour un même temps de rendu. Vous serez ainsi plus performant que vos concurrent.
Pour faire simple, savoir optimiser un rendu est synonyme de « gagner plus d’argent ».
La bonne nouvelle est que ces processus vont souvent de pair. La majorité des artefacts augmentent le temps nécessaire à la finition d’un rendu.
La plupart du temps, en les traitant, vous ferez d’une pierre deux coups en obtenant à la fois une qualité supérieure et un temps de rendu plus court.
1.1. Les différents types d’artefacts typiques
Les utilisateurs familiers de l’ancienne architecture REYES (Renderman < 21, Mantra) doivent se souvenir des nombreux types d’artefacts qui peuvent apparaître selon la configuration de la scène et les techniques utilisées.
Il faut un œil exercé pour les détecter et une bonne compréhension technique pour les éviter.
Heureusement, ce n’est plus le cas dans la plupart des moteurs de rendu moderne (Renderman, Arnold, Redshift, Octane) ou la diversité des artefacts est bien moins importante.
Aujourd’hui, l’artefact le plus typique que nous ayons à gérer est le bruit présent sous divers forme.
Selon le type de bruit et sa source, nous devrons utiliser de différentes techniques pour l’identifier et l’éliminer.
Retenez bien ces termes, ce sont la base de ces méthodologie : identifier et éliminer.
1.1.1 Bruit uniforme Monte-Carlo
Bien évidemment l’artefact le plus emblématique des moteurs à lancer de rayons : le bruit ou bruit uniforme.
Pour « nettoyer » l’image, le moteur doit envoyer continuellement des rayons jusqu’à ce que le rapport signal sur bruit atteigne le niveau de qualité fixé.
1.1.2 Zone de forte variance (High variance areas)
Une zone de forte variance est un bruit particulièrement fort, concentré à un certain endroit de l’image.
Sur l’image ci-dessus, vous pouvez voir une sphère éclairée par une lumière et une lumière bleue indirecte provenant de la gauche.
En y regardant de plus près, vous pouvez voir que l’image est propre dans la plupart des zones, à l’exception des pixels bleues très clair sur le sol.
Le bruit sur le sol a une variance significativement plus élevée que le reste de l’image. Les pixels bleu ont une valeurs très élevé alors que les pixels qui les entourent ont des valeurs faibles. Dans cette zone, inévitablement pour obtenir une image propre va devoir envoyez un nombre considérable de rayons et donc tourner pendant un temps conséquent.
Ce type d’artefact est difficilement reconnaissable comme du bruit pour le moteur de rendu, ci bien qui peut empêcher l’Adaptative Sampling de fonctionner correctement comme nous le verrons plus tard.
Généralement, une zone de variance élevée peut être supprimée par de simples ajustements des éléments de la scène ou tout du moins suffisamment améliorée pour permettre à l’Adaptative Sampling de devenir efficace comme nous le verrons dans l’exemple à la fin de cet article.
1.1.3 Les Fireflies
Les Fireflies sont des points très lumineux dans un rendu. C’est un type de bruit extrêmement fort causé par un phénomène qui fait que le moteur de rendu a des difficultés à échantillonner correctement un élément dans la scène.
Alors que le bruit uniforme et les zones à forte variance peuvent généralement être supprimés par un simple allongement des temps de rendu, les fireflies sont beaucoup plus difficiles à éliminer et elles peuvent créer de forts artefacts sur des images débruitées, en particulier lors de rendus d’animations.
Pour supprimer des fireflies, la bonne méthodes consiste toujours à rechercher la source de ces artefacts et l’éliminer.
Dans l’immense majorité des cas, les fireflies sont causé par une source lumineuse de petite taille et de forte intensité proche d’une géométrie. La lumière indirect renvoyée par cette géométrie crée alors des fireflies.
On pourra jouer sur l’intensité ou la distance de la lumière par rapport à la géométrie reflective.
Parfois, dans certaines conditions et/ou certains moteurs, des fireflies peuvent également apparaître directement avec des lumières directs. C’est souvent le cas lorsqu’un source lumineuse est extrémement petite ety intense OU que l’echelle de la scène n’est pas cohérante.
En effet, certaines croyance ont la vie dur mais ce point ne supporte AUCUN débat : une scène 2D se doit d’être la bonne échelle ! Un table de 80cm de large et d’1.6m de long dans la vrai vie devrait faire la même taille dans votre logiciel 3D.
Dans l’exemple ci-dessus, une petite lumière brillante a été placée très près d’un mur, créant un minuscule et intense point lumineux. Ce point est donc extrêmement difficile à échantillonner par le moteur et est à l’origine des artefacts décrits ici.
Nous étudierons un exemple de cet artefact plus loin dans cet article.
1.1.4 Valeurs non valides
Dernière artefact quelque peu complexe a décrire techniques mais très simple a détecter ET à corrigé : les valeurs invaldes
L’ensemble d’une scène 3D n’est qu’un nombre extrémement i:mportante de chiffre et de valeurs de types de données différentes.
Chaque type de données attends des valeurs cohérentes. Exemple simple, une donnée de type integer (nombre entier) ne peut contenir de nombre décimale.
De même, une couleur ne peut contenir de nombre négatif.
Ce type de valeur incohérente se nomme également « NaN » pour Not a Number.
Les moteurs de rendus moderne « interdisent » l’utilisation et donc l’affichage de ces NaN.
Ceux cas de figure peuvent alors se présenter :
- Le moteur affiche des pixels noirs comme dans l’image ci-dessus. Plutot simple de les détecter.
- Cependant, si un NaN se glisse dans la définition d’un vertex d’un mesh, le moteur décidera alors d’ignorer totalement le rendu de la géométrie entière. Plus complexe a détecter donc….
Les valeurs invalident arrivent en générale suite à un « incident » tel un plantage, une erreur d’enregistrement, la génération d’une géométrie invalide ou une opération non prévu.
Au final, les valeurs invalide relève plus de « l’erreur » technique que de l’artefact de rendu. Si leur détection peut parfois être problématique (par exemple, on peut se demander longtemps pourquoi une géométrie contenant un NaN n’apparaît pas au rendu), leur correction, elle, est extrêmement simple puisqu’il suffira de remplacer la donnée invalide par une donnée valide.
2. Qu’est-ce qui charge RenderMan ?
Pour rendre une image, RenderMan envoie continuellement des rayons pour chaque pixel jusqu’à ce que la qualité cible ait été atteinte.
Le temps nécessaire pour atteindre cet objectif est appelé temps de rendu.
Le temps de rendu peut être divisé en trois grandes contributions : Le nombre de pixels (résolution de l’image), le temps nécessaire pour tracer un chemin complet (raytracing/rebounds) et le nombre de rayons par pixel pour atteindre la qualité cible (le sampling).
Ainsi, nous pouvons réduire le temps de rendu de divers manière :
- en réduisant le nombre de pixels : soit en effectuant le rendu à une résolution de l’image plus faible, soit en crapant une zone.
- en réduisant le temps nécessaire pour tracer un chemin complet, le raytracing/rebounds : moins de rebonds ou en diminuant la complexité géométrique (moins d’objets et/ou moins de poly-count)
- réduire le nombre d’échantillons par pixel, le sampling : en améliorant les zones difficiles à échantillonner ou en diminuant la qualité cible.
2.1 Qualité cible : Pixel Variance
Dans ce chapitre nous parlerons d’un terme générique : l’Adaptive Sampling ou AS.
Dans Renderman, le système d’AS s’articule essentiellement autour d’un paramètre nommé « Pixel Variance » connu aussi sous le nom de Target Quality.
La « target quality » est un valeur que l’utilisateur définie et que RenderMan doit atteindre avant de pouvoir finir le rendu d’une image.
Elle est contrôlée en spécifiant la paramètre Pixel Variance, pour faire simple, vous aller spécifier à Renderman un niveau de bruit a atteindre avant d’arrêter de lancer des rayons.
Nettoyer le bruit dans une image est comparable à nettoyer une maison.
Pour nettoyer le gros de la poussière, les premiers coups de balais dans l’ensemble de la maison ne sont pas longs. Cependant, plus vous voulez que chaque coins de votre maison soit propre, plus vous allez passer du temps à nettoyer. Le temps de nettoyage est proportionnel à votre exigence de propreté.
Pour déterminer le moment ou vous allez arrêter de nettoyer votre maison, vous avez deux façon de voir la chose :
- soit vous vous donnez un temps fini, incompressible, une fois ce temps écoulé vous cessez de faire le ménage quelques soit l’étant de votre maison.
- soit vous vous fixé un niveau de propreté.
Dans le premier cas, il se peut qu’au moment ou vous cessiez de nettoyer, votre maison soit encore sale, ou au contraire, vous avez « sur-nettoyer » et passer du temps inutile
Les même principe s’appliquent à la définition de la qualité cible s’applique pour un rendu.
Après les premières itérations, les structures générales de l’image sont très rapidement visible mais les détails sont encore perdus dans le bruits. Pour nettoyer le bruit dans ces détails il est nécessaire d’investir plus de temps. Toutefois, comme pour le ménage, il se peut que si l’on passe « trop de temps » a nettoyer l’image, l’image soit « trop propre » et une partie du temps passé n’aura donc servi a rien.
Que ce soit en terme de ménage ou en terme de rendu, il est nécessaire de trouver une bonne méthode pour déterminer le meilleur rapport temps/propreté.
2.1.1 Influence du Pixel Variance sur les temps de rendu
L’image ci-dessus illustre très bien la vitesse à laquelle les temps de rendu augmente lorsqu’on diminue le Pixel Variance.
L’écart entre 0.005 et 0.0025 peut sembler faible et pourtant, comme le montre ce graphique, la valeur de 0.0025 fait doubler le temps de rendu.
Prendre du temps pour tester différentes valeur de Pixel Variance et choisir celle qui produit une qualité acceptable en un minimum de temps peut permettre d’économiser un temps de rendu considérable.
Il est généralement admis que l’optimisation du Pixel Variance est la plus importante qui soit !
Dans cette image, prêtez particulièrement attention au bruit présent dans la partie basse de la sphère, la partie qui n’est pas éclairé directement par la source lumineuse.
Comme vous pouvez le voir, il ne faut pas beaucoup de temps pour obtenir une image avec peu de bruit.
Même après juste quelques secondes, nous obtenons un rendu assez décent pour cette simple scène.
Cependant, lorsque nous essayons de nous débarrasser du bruit à peine visible en bas de la sphère, même ce simple rendu prend soudainement un temps assez long.
Le bruit est assez facilement détectable sur des surfaces planes comme cette sphère grise.
A l’opposé, lorsque des textures sont utilisées, le bruit est plus simple à dissimuler ce qui permet d’augmenter légèrement la Pixel Variance et donc d’accélérer sensiblement le rendu..
2.1.2 PixelVariance
Dans Houdini, ce paramètre ce nome exactement Pixel Variance et ce trouve dans le ROP RenderMan :
Ce paramètre doit être ajusté visuellement pour trouver la bonne valeur pour votre projet.
En règle générale, des ajustements de couleur (gradation, LUT, etc.), une défocalisation, flou de mouvement ou tous autres post-traitement sont appliés en post-production et il est important d’en tenir compte.
Il est important de décider de la qualité dont vous avez besoin pour phase de prévisualisations, pour les rendus intermédiaire et pour les rendus finaux et la livraison finale. En bref, il est important de ne pas passer trop de temps a rendre des images dont la qualité sera supérieur à la qualité requise pour l’utilisation qui en sera faite. En particulier lorsque vous utiliserez un denoiser en post-process.
Les denoisers sont de puissants outils qu’il ne faudra pas hésiter à utiliser avec intelligence, tout particulièrement sur des scènes complexes difficile à débruiter directement dans le moteur de rendu.
Cependant, attention les fireflies et les zones à forte variances produiront facilement des artefacts de débruitage. C’est pourquoi il faudra toujours s’appliquer à optimiser traditionnellement une image avant de la passer dans un denoiser. Meilleur sera l’image d’entrée, meilleur sera l’image en sorti du denoiser.
En production, il est important de passer du temps à trouver la meilleur valeur de Pixel Variance en adéquation avec votre denoiser.
Nous reviendrons sur le débruitage à la fin de cet article.
2.1.3 Relative Pixel Variance
Il s’agit d’un paramètre qui permet de spécifier différents niveaux de qualité par objet.
C’est une optimisation très intéressante lorsque vous rendez des images globalement nettes mais dont certaines partie seront flouté (soit par profondeur de champ soit par motion blur) en post-production.
En effet, dépenser du temps pour rendre des objets « snoise-free » qui s’avèrent éventuellement flous dans l’image finale est une perte de temps gaspillage.
Le paramètre Relative Pixel Variance indique donc a Renderman de rendre ces objets avec une qualité inférieure.
Si en théorie comme en pratique, on peut se servir de ce paramètre pour indiquer à Renderman de concentrer la qualité sur un objet en particulier, la méthodologie globale de cet article ne s’articule pas autour de cette technique. Vous pouvez donc vous servir du Relative Pixel Variance pour augmenter la qualité du rendu d’un objet en particulier mais cette méthode sera a utiliser en dernier recours car elle n’est pas la plus efficiente.
Dans Houdini, ce paramètres se trouve dans les Spares Parameters du Node de Geo :
La Relative Pixel Variance est un multiplicateur du parametre Pixel Variance. Par exemple, si le Pixel Variance de la scène est réglé sur 0.015, si on selectionner un Relative Pixel Variance, l’Adaptative Sampling sur l’objet en question sera de 0,0075 (0.5 x 0.015) et l’objet aura donc une qualité supérieur qu’il ne l’aurait normalement.
3. Adaptive sampling
Bien que Renderman RIS soit nettement plus simple à utiliser que les bons vieux REYES, il reste quelques points importants à comprendre et qui peuvent facilement être mal compris.
L’Adaptive sampling est probablement l’une des ces choses les plus mal comprisent. Il est donc important de prendre un peu de temps pour l’étudier et bien comprendre son fonctionnement.
Lors du rendu d’une image un ray tracer, le moteur envoie des rayons (échantillons) pour calculer la couleur de chaque pixel.
Certains moteurs de rendu demandent à l’utilisateur de définir un nombre de rayons en envoyer pour chaque pixel.
Bien évidemment la meilleur réponse à la question « Combien de rayons voulez vous envoyer ? » est : autant qu’il en faut pour que l’image soit propre !
Pour ces moteurs de rendu, il faut modifier ce réglage jusqu’à ce que l’image atteigne la qualité visuelle recherchée.
Cette technique s’appelle l’échantillonnage fixe.
RenderMan RIS, en revanche, utilise par défaut la méthode de l’Adaptative Sampling.
Au lieu de définir une quantité fixe d’échantillons à envoyer par pixel, nous indiquons au moteur la qualité que nous souhaitons attendre.
RenderMan commence alors à envoyer des rayons et estime continuellement la quantité de bruit.
Une fois qu’un pixel a atteint la qualité cible, il ne sera plus échantillonné et le moteur de rendu peut se concentrer sur les zones qui nécessitent plus d’attention.
L’utilisation de cette technique présente plusieurs avantages majeurs :
- Comme le moteur de rendu peut ignorer les pixels qui ont atteint rapidement la qualité cible, il n’y a pas de perte des temps à échantillonner des zones plus que nécessaires.
- Les zones particulièrement bruité recevront plus d’attention sans avoir à augmenter l’échantillonnage globale.
- Si l’Adaptative Sampling est utilisé correctement, l’image finale aura atteint la qualité cible dans toutes les zones. Cela nous à pour effet de garantir que le niveau de bruit dans l’image sera constant lors de rendu d’animation.
Il n’y a que trois paramètres principaux pour contrôler l’échantillonnage adaptatif : Pixel Variance, minSamples et maxSamples.
Lorsque l’on comprend l’effet de chacun d’entre eux, il est facile de bien les comprendre.
L’inconvenient de l’AS est qu’un seul mauvais réglages de ces seuls trois paramètres, ruine les avantages de cette technique.
Nous avons déjà examiné de près le Variance Pixel, nous allons donc maintenant parler des minSamples et des maxSamples.
3.1 Démistifions le minSamples
Dans Houdini, le parametre minSample, nommé exactement Minimum Sample se trouve dans la ROP RenderMan :
Avec le Pixel Variance, nous indiquons déjà au moteur quelle niveau de qualité nous souhaitons atteindre, alors pourquoi avons-nous besoin de paramètres supplémentaires ?
La raison pour laquelle nous avons ces deux réglages supplémentaires est simplement que l’Adaptative Sampling n’est pas un système parfait.
Le moteur doit arrêter de rendre un pixel si le bruit est suffisamment faible, mais comment celui-ci peut-il savoir le niveau de bruit restant ?
Pour connaître ce niveau de bruit, RenderMan doit l’estimer en mesurant de quelle valeur un pixel change entre chaque itération.
Pour les premiers rayons, le pixel change de valeurs rapidement. Échantillon après échantillon, le pixel converge vers sa valeur réelle.
Une fois que la variation est inférieure à ce qui a été fixé comme objectif, le pixel est considéré comme accompli.
Bien que cela fonctionne bien dans la plupart des cas, il y a des situations où les choses peuvent mal se passer.
Par exemple, certains objets, surtout lorsqu’ils sont éloignés, peuvent être beaucoup plus petits qu’un pixel.
Il n’est alors pas improbable que la plupart des rayons envoyés pour ce pixel ratent complètement l’objet.
Lorsque cela se produit au début d’un rendu, RenderMan voit un pixel qui ne change pas du tout de valeurs et il peut supposer à tort que ce pixel est propre.
Cela est particulièrement problématique lors du rendu d’une animation, car d’autres images peuvent toucher le petit objet, ce qui fait que l’objet peut apparaître et disparaître.
Cela ne s’applique pas seulement aux petits objets. Tout objet ayant une faible chance d’être touché par un rayon se comporterait de la même manière.
Il peut s’agir de cheveux, de minuscules reflets, d’objets à forte vélocité (un rayon doit frapper l’objet au bon moment) ou même simplement de bruits à forte variance comme ceux mentionnés ci-dessus.
Pour cette raison, nous devons fixer une quantité minimale d’échantillons à utiliser avant que l’échantillonnage adaptatif ne puisse même envisager d’arrêter le rendu d’un certain pixel.
Dans le cas d’un objet minuscule, nous devons définir un min Sample suffisamment grands pour garantir que l’objet soit touché au moins une fois afin que le RSI sache qu’il y a quelque chose qui a besoin d’un échantillonnage supplémentaire.
Il n’est pas toujours évident que les minSamples ont été fixés trop bas. Parfois, cela peut simplement conduire à des zones bruyantes dans lesquelles RenderMan a sous-estimé le bruit et s’est arrêté trop tôt. Certains utilisateurs pourraient être tentés de réduire simplement la Pixel Variance dans ces cas, après tout, c’est ce qui contrôle la quantité de bruit que nous voulons autoriser. Si une Pixel Variance plus faible peut contribuer à réduire le bruit, elle suréchantillonnera toutes les autres zones qui étaient bien avant et entraînera des temps de rendu excessifs. C’est en quelque sorte l’équivalent de la méthode (utilisé helas par beaucoup d’utilisateur ignorant d’Arnold) de ne jouer que sur le paramètre Camera AA : efficace mais terriblement in-efficient.
L’augmentation des minSamples, en revanche, aide RenderMan à obtenir de meilleures estimations initiales du bruit et à reconnaître les zones plus difficiles a traiter.
Si minSamples a été correctement estimé, en cas d’augmentation de cette valeur, l’image ne devrait pas changer de façon significative, c’est le signe que vous n’être pas loin de la bonne valeur..
Si une légère augmentation de minSamples rend certaines zones nettement plus propres, c’est généralement le signe que la valeur précédente n’était pas assez élevée pour estimer le bruit avec précision.
Bien evidemment, une augmentation des minSamples entraîne un allongement des temps de rendu, mais l’image atteindra effectivement du niveau de bruit souhaité pour la Pixel Variance sélectionné.
En revanche, un nombre trop faible de minSamples, bien que le rendu soit plus rapide, ne peut pas garantir que l’image atteigne la qualité souhaitée et le bruit peut être très irrégulier et changer d’intensité d’une image à l’autre, ce qui va à l’encontre de l’objectif de l’Adaptative Sampling. En cas de rendu d’image d’animation, des variations du bruit dans l’image peut être une signe de min Sample trop faible.
Donc, si vous êtes tentés par les temps de rendu plus rapides lorsque vous utilisez des valeurs plus faibles pour les mini Samples, soyez conscients des problèmes que cela pourrait introduire ! Réserver les donc à de la pré-visualisation.
3.1.1 Valeurs « magiques » des paramètres de RenderMan
Pour de nombreux paramètres de RenderMan, les valeurs « 0 » et « -1 » ont une signification particulière :
- « -1 » signifie souvent « infini » et est par exemple utilisé pour définir la distance maximale qu’un rayon d’ombre est autorisé à parcourir.
- « 0 » signifie souvent « automatique » et est la valeur par défaut pour le nombre d’échantillons de lumière utilisés par lumière. Cela ne signifie pas qu’aucun échantillon n’est utilisé, mais plutôt qu’un automatisme interne est utilisé pour déterminer le nombre d’échantillons au lieu de se fier à la valeur fournie par l’utilisateur.
Habituellement, lorsque la valeur par défaut est « 0 » ou « -1 », cela indique qu’il s’agit de valeurs spéciales. Pour plus de détails, vous devez consulter la documentation.
Le réglage de minSamples sur « 0 », comme c’est le cas par défaut (NDLR, pas sur Renderman 23.3 pour lequel cette valeur est a 4 mais qui rest cohérent avec ce qui suit), déclenche un mode automatique spécial et ne signifie pas qu’il n’y a pas de minimum pour le nombre d’échantillons.
Ce mode automatique prend simplement la racine carrée du nombre maximum d’échantillons (appelé max Samples dans RenderMan). Si max Samples a été fixé à 512, le mode automatique fixera minSamples à \/512 ~ 23.
Bien que la tentative de simplifier davantage les choses soit agréable, je recommande personnellement de définir explicitement minSamples. Le mode automatique peut être utilisé comme point de départ, mais il peut être nécessaire de l’ajuster pour éviter des problèmes dans vos scènes.
Des puissances de deux sont recommandées pour les valeurs de minSamples.
3.1.2 Comment determiner le minSample
Baisser le minSample est un moyen simple d’obtenir des images d’aperçu qui seront calculer très rapidement. Bien entendu les images ainsi produites ne seront pas exempt de nuit mais elle vous permettront d’avoir un bon aperçu de l’ensemble de votre scène et cela sera dans la majorité des cas pour l’élaboration des principaux éléments de surfacing, layout et lighting.
Pour cette étape, il n’est pas rare de régler le minSample à 1.
Cependant, pour un rendu qualitatif, il est important de régler le minSamples avec précision et surtout méthodologie.
La méthodologie proposée dans cet article est la suivante :
- Commencer par régler le maxSamples sur 2048.
- Laisser le PixelVarriance sur 0.015 (par exemple)
- Régler le minSamples sur 16 puis lancer un premier rendu.
- Repérer une zone de l’image fortement bruité puis faite un crop sur cette zone.
- Laisser finir le rendu avec ces paramètres (2048/0.015/16) puis faites un Snapshot dans It (Commands > Snapshot)
- Répéter l’opération 3 fois en augmentant a chaque fois le minSmplaes de 16, ainsi vous finirez l’opération avec un Snapshot pour un minSample de 16, 32, 48 et 64.
- Selon votre image, vous noterez une nette amélioration jusqu’à une certaine valeur puis à une valeurs donnée l’amélioration sera a pein,voire pas du tout perceptible. Il suffit alors de sélectionner la valeur inférieure.
- Pour le peu que vous ayez choisi correctement la zone à observer, la zone la plus dure, le minSamples est réglé pour votre scène !
3.2 Démistifier le maxSamples
Qui aurait cru qu’il y avait tant à dire sur la paramètre minSamples ? Heureusement, maxSamples est beaucoup plus facile à expliquer.
Pour reprendre l’exemple du ménage, imaginez que dans votre maison vous ayez trouvé une tache de saleté tenace et que vous ayez extrêmement de difficulté à vous en débarrasser.
Vous décidez alors de ne vous arrêter que lorsque nous aurez atteint le niveau de propreté que vous vous êtes fixé comme objectif.
Si la tache est trés incrusté, vous risquez de devoir nettoyer pendant très très longtemps.
A moins que, à un moment donné, vous atteignez la limite de votre patience et que vous acceptez simplement la défaite. Le résultat n’en sera alors peut être pas « si mauvais » ?
RenderMan, ou tout système informatique en générale, à une patience infinie, il est donc capable de rendre pendant des heuress, des jours voire des années jusqu’à atteindre une propreté parfaite.
C’est donc à nous d’indiquer manière au moteur à quel moment « abandonner ».
C’est là qu’intervient le paramètre maxSamples : il s’agit tout simplement d’une valeur « d’abandon » que nous indiquons au moteur. Une fois cette valeur d’échantillonnage atteint, on demande au moteur de considérer le pixel comme valider.
Comme vous l’aurais compris, ce n’est pas vraiment un contrôle de qualité, c’est plutôt une sorte de coupe-circuit qui évite que le moteur tourne à l’infini.
Comme le rapport signal/bruit est de moins en moins intéressant au fur et a mesure que le temps passe, si a un instant T (qui correspond au temps que le moteur aura mis pour atteindre la valeur maxSamples) un pixel n’as pas atteint la qualité exigé, il y a peu de chance que depenser encore du temps améliore la chose. Ou alors au prix d’échelle de temps démésuré.
Cette dernière phrase, un peu complexe à appréhender signifie simplement que le maxSamples n’est pas une réponse universel à des problèmes de bruits, si du bruit persiste à des valeurs élevées normale de maxSamples, il faudra probablement investigué ailleurs.
3.2.1 Qu’est-ce qui pourrait mal tourner ?
Si l’utilité du paramètre maxSmaples est simple à comprendre, à l’opposé du minSamples determiner la bonne valeur est une autre paire de manches.
Régler un maxSamples trop bas, reviens à couper prématurément l’Adaptative Sampling et il est quasiment certain que nous n’atteignons jamais le niveau de qualité spécifié avec le PixelVariance.
Dans ce cas de figure un utilisateur inexpérimenté pourrait être tenté de baisser la valeur du PixelVariance mais ca serait une erreur : cela n’aura pour effet que de rendre encore plus propre des zones déjà très propre et a n’avoir quasiment aucun effet dans les zones bruitées.
Le pièce avec un maxSample trop bas et d’empêcher RenderMan d’attendre le niveau de qualité spécifié.
En revanche, si vous réglez maxSamples à un niveau trop élevé, le seul problème est que certaines zones minuscules peuvent continuer à être rendues pendant longtemps, en essayant d’atteindre la qualité cible mais en prenant beaucoup trop d’échantillons au cours du processus. Cela est cependant assez rare et ne coûte généralement pas beaucoup, il est donc préférable de maintenir maxSamples à un niveau élevé pour que RenderMan puisse fournir la qualité que nous demandons.
Comme sépcifié au début de ce chapitre, a l’oppsé du minSmplaes, il n’y a pas vraiment de méthodologie définie pour régler correctement le maxSamples. Toutefois vous pouvez dors et déjà partir sur ces bases :
- une valeur de 512 est relativement « passe-partout », elle devrait vous donner une qualité satisfaisante dans la pluspart des cas c’est donc une bonne base sur laquelle partir pour trouver la bonne valeur pour votre image final.
- Malgrès tout, en fonction de tout un tas de paramètre, il est tout a fait possible que vous deviez passer cette valeur à 1024, 2048 voir plus.
Nous esseront de répondre un peu en en détails et d’étable malgrès tout une methodologie pour detecter des valeurs de maxSamples trop hautes ou trop basses.
Il est simplement important de garder à l’esprit que lorsque vous êtes confrontés à des problèmes de bruits, il faut être capable de les identifier et d’agir sur les bon paramètre au lieu de bêtement tenter de baisser désespérément le PixelVariance (ou encore pire, le RelativePixelVariancel) ce qui amènerait fatalement à une situation encore pire en augmentant le temps de rendus.
Pour faire un parallèle avec Arnold, ne jouer que sur le PixelVariance est aussi idiot que de n’agir sur le Camera AA sans avoir aucune idée de comment cela fonctionne. Cela « peut » fonctionner (quoique, au final, assez rarement efficacement) mais c’est une simple démonstration de la non maîtrise de son outil de travail.
3.2.2 L’AOV SampleCount : votre nouveau meilleur ami.
Comme tous moteurs de rendus moderne, RenderMan permet de calculer un nombre impressionnant d’AOV. Le fait de calculer un AOV en même temps que le rendu Beauty ne consomme qu’une partie totalement négligeable de temps CPU et très peu de mémoire.
Pour avoir un aperçu de comment se comporte les moteurs utilisant l’Adaptative Sampling, il existe un AOV extreme utile : l’AOV de « sampleCount ». Dans le plupart des autre moteur de rendu, cet AOV se nomme « Heatmap ».
L’interprétation est assez simple : plus les pixels présente des valeurs hautes (donc blanc sur une Heatmap en niveau de gris ou en float) plus cela signifie que le moteur passé du temps sur ces zones.
Attention, ces AOV présentent une très forte dynamique avec des valeurs bien supérieur à 1, cela signifie que la plupart du temps au moment ou vous afficherez votre heatmap, elle sera d’un blanc intense uniforme. Il faudra explorer la dynamique de l’image pour trouver des valeurs.
Exemple :
4. Conclusion de la première partie
Un petit rappel des éléments essentiel que nous avons découvert dans cette première partie théorique.
Nous avons appris à reconnaitres les principaux artefact d’un ray tracer monte-Carlo :
- Le bruit uniforme
- Les zones a valeur fortement variable
- Les fireflies
- Les NaN
Puis nous avons decouvert les 3 prcinpaux paramètre qui vont nous permettre de gérer la qualitéé d’un rendu dans un moteur a Adaptative Smpling :
- Le Pixelvariance qui permet de fixer le niveau de qualité globale d’une scène en indiquant au moteur un « seuil » a partir duquel il doit considérer un pixel comme valider.
- Le minSamples qui permet d’indiquer au moteur une valeur de sampling minimum a calculer avant de considérer un pixel comme validé. Ceci afin d’éviter au moteur de considérer comme valide des petits objets ou des zones très sombres comme valide a tort.
- Le maxSamples qui permet d’indiquer au moteur le sampling maximum a évaluer pour un pixel, quelques soit l’etat de ce pixel une fois ce sampling atteint. Ceci dans le but à la fois de garantir un niveau de bruit acceptable et à la fois afin d’éviter au moteur de tourner à l’infinie.
0 commentaire