[Toulibre] Les machins de raytracing libre.

Sam 19 Jan 22:50:40 CET 2008

Le 19/01/08, olivS <olivier.saraja at free.fr> a écrit :
>
> 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


Passionnant,

Amicalement,
> --
> Olivier
>
> _______________________________________________
> Toulouse-ll mailing list
> Toulouse-ll at toulibre.org
> http://toulibre.org/cgi-bin/mailman/listinfo/toulouse-ll
>


-- 
<j:-P)
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://toulibre.org/pipermail/toulouse-ll/attachments/20080119/f32e5b50/attachment.html>