[Toulibre] Les machins de raytracing libre.

[olivS]

Salut,

Le vendredi 18 janvier 2008, Thierry Boudet a écrit :
>    Donc, je peux supposer que tu es à même de fournir un jour ou
>    l'autre une tableau comparatif de ces différents renders, avec
>    un exemple d'image pour chacun...

Presque! Je ne suis utilisateur que de Yafray et de Sunflow. Je n'ai jamais 
compilé/installé Yaf(a)ray, me contentant de suivre son développement (il 
s'agit d'une ré-écriture complète de Yafray) quant à Luxrender, me suis 
simplement intéressé à ses fonctionnalités.

Pour résumer, on va dire ceci de chacun (attention, vulgarisation lourde!):
- Blender est un moteur hybride scanline/raytracing, sans capacité 
d'illumination globale, à l'exception de la Radiosité (qui n'est pas si 
évidente à mettre en oeuvre pour le débutant)
- Yafray est un pur raytracer, capable de gérer nativement l'illumination 
global, soit par carte de photons, soit par la méthode du cache d'irradiance
- Sunflow est également un pur raytracer, écrit en java, capable des mêmes 
choses que Yafray, mais plus faible au niveau des photons (bug qui reste à 
corriger) et au niveau du support des textures/shaders. Ses rendus sont 
toutefois de vraies merveilles
- Luxrender fait parti de la catégorie "au-dessus": illumination globale par 
méthodes non biaisées: cela veut dire que les rendus ne s'interrompent que 
lorsque l'utilisateur le décide. Chaque pixel calculé est exact, sans 
apporcimation, sans interpolation par rapport à ses voisins. Mais le temps de 
calcul de chaque pixel est.... infini! En fait, l'image s'épure et 
s'éclaircit (se débarrasse du "bruit") dans le temps, et lorsque l'image est 
suffisamment "propre", l'utilisateur interrompt le rendu.

Blender et Yafray sont des outils artistiques (surtout Blender): les méthodes 
d'illumination et de shader sont réalistes mais tellement versatiles qu'il 
est facile de briser les schémas photo-réalistiques (pour ceux que ça 
intéresse). Sunflow se veut seulement photoréaliste, avec des méthodes 
d'illumination et des shaders "physiques". Luxrender rentre dans la catégorie 
des appareils photos: non seulement les méthodes d'illumination et des 
shaders sont physiques, mais en plus ils sont non biaisés ce qui le place 
dans la catégorie d'Indigo (gratuit, mais pas libre) et de Maxwell 
(propriétaire, très cher).

Comme je sens venir la question, je vais y répondre de suite, à la hauteur de 
ma compréhension: "qu'est-ce que biaisé veut dire???"

Normalement, lorsque tu lances un rayon vers un pixel pour connaître sa 
couleur, à partir de celui-ci sont lancé une certaine autre quantité de 
rayons pour "échantillonner" son environnement, et prendre des infos sur 
l'illumination que devrait avoir ce pixel, et donc sa couleur. Deux pixels 
voisins peuvent avoir des couleurs très différentes (alors qu'ils devraient 
être de la même à un pouillème près s'ils sont dans une même région 
lumineuse) tout simplement parceque l'échantillonnage, réalisé avec un faible 
nombre de rayons, peut renvoyer des résultats divergents: l'un va annoncer 
être éclairé, l'autre va annoncé être dans le noir. Résultat: du bruit, du 
grain, des petits points sur le rendu. Pour passer outre, faut augmenter le 
nombre d'échantillons (méthode brute et sauvage qui conduit au 
photo-réalisme).

Une méthode pour contourner consiste à dire: ok, je trace une grille où je 
reporte, à intervalles réguliers, les intensités lumineuses (je schématise, 
la couleur d'illumination entre également en jeu, ainsi que le shader du 
matériau, etc.) définies avec un nombre d'échantillon satisfaisant, mais sur 
beaucoup moins de point que par la méthode brute et classique. Ensuite, pour 
tous les pixels intermédiaires de la grille, j'interpole l'intensité 
lumineuse. On obtient ainsi l'illusion du photo-réalisme, mais les 
illuminations ne sont pas "exactes" dans le sens où les valeurs des 
intensités lumineuses sur la grille sont moyennées/pondérées par les autres 
pixels de la grille, et que les points intermédiaires sont interpolés (et 
s'il 'y avait une micro-source de lumière entre deux noeuds de la grille? et 
bien elle ne serait pas vue, tout simplement...)

C'est ce que l'on appelle une méthode biaisée: des erreurs sont volontairement 
introduites dans les équations, pour permettre une convergence "rapide" et 
faire en sorte que le rendu s'arrête seul à un niveau de qualité 
satisfaisant. La contre-partie est que l'illumination n'est pas physiquement 
exacte.

Avec les méthodes NON biaisées, pour chaque point de l'image (et non plus de 
la grille) on va faire une infinité de passages. Au premier passage, on 
calcule l'intensité lumineuse correspondant au premier rebond interdiffus 
(bref on recherche les éclairages directs classiques du raytracing, en gros) 
et on balance un grand nombre de rayons (en fait une infinité car on se 
s'arrête jamais d'échantillonner l'environnement) et à chaque fois qu'une 
info intéressante est déterminée, elle est reportée sur la couleur du pixel. 
Bref, l'image est toute moche dans les premières secondes de rendu, mais 
s'affine progressivement dans le temps jusqu'à mieux définir les couleurs, 
les lumières, les caustiques, puis le grain s'atténue et finalement plus rien 
n'est visible à l'oeil nu. C'est à ce moment là que l'utilisateur 
super-intelligente, au bout d'une centaine d'heures de calcul (oui, on se 
croirait de retour aux années 80 avec les débuts de Pov-ray, rires!) 
interrompt le rendu car il a une super image photoréaliste. Mais les 
éclairages sont "parfaitement" conformes à la réalité. C'est le vrai 
photo-réalisme. Mais il se paye très très cher en temps de calcul.

Bien évidemment, il y a différents algorithmes pour les biaisés comme les non 
biaisés. Par exemple, le Path Tracing des biaisés est en vérité non biaisé, 
sur le principe, mais limité par voie logicielle à un nombre d'échantillons 
donné, car plus facile à coder, contrôler, paramétrer... Suis pas 
programmeur, mais je suppose qu'il est plus facile de brider un algorithme 
dans une boucle, plutôt que de lui dire de poursuivre son traitement à 
l'infini tout en l'enrichissant au fur et à mesure que les données arrivent 
pour changer l'algo (apparition d'une tâche caustique, par exemple)

Wouah, c'était long! Merci de m'avoir lu juqu'au bout, ça fait vraiment chaud 
au coeur! :-D

Amicalement,
-- 
Olivier