[Pixelvore] MOLE, le moteur de rendu des taupins (gros up p.4)

Posté par Pixelvore le 26/7/2009 9:48:04
Salut à tous !

Un ami taupin et moi même (taupe lui aussi) avons codé une ébauche de moteur de rendu, en vue du T.I.P.E de l'an prochain (pour Travaux d'Initiative Personnelle Encadrés, un peu comme le TPE de 1ère mais avec le "i" en plus, hélas... ). Le thème global étant "Surfaces", on pense orienter nos études sur la façon dont réagit la lumière au contact d'une surface, en fait en décrivant ce que fait le moteur de rendu on aura déjà beaucoup de choses à dire...

J'ouvre donc un topic un peu vague, n'ayant pas spécialement de question à vous poser. J'espère simplement que le topic pourra être utile à certaines personnes qui comme moi se sont demandées depuis le berceau comment marche un moteur de rendu, mais qui ont buté sur la difficulté que ça représente de dépouiller le code de moteurs de rendu complets comme LuxRender, ou encore de lire les publications éparses de Pixar, Siggraph, et autres, et à la fin, d'essayer de réassembler les morceaux butinés un peu partout pour avoir quelque chose qui tourne.

J'ai donc nommé MOLE (pour "the Mole's Outstanding Lighting Engine - "mole" ça veut dire "taupe" ), un path tracer révolutionnaire qui suit la procédure décrite dans n'importe quel article qui traite de path tracing.

Pour voir ce que MOLE a dans l'ventre, devinez quelle scène très originale on a choisi...
Allez je lève le mystère, la ô combien mythique Cornell Box

Voilà ce que ça donne :



Pour résumer ce qu'on a implémenté pour le moment :

> le coeur du moteur de rendu : lancer un rayon depuis la camera (simulée façon Blender : sans vraie lentille), calculer à quel endroit de la scène il intersecte une surface, le faire rebondir en invoquant le matériau de la surface, et s'arrêter lorsqu'il rencontre une lumière, et enfin "l'imprimer" dans le pixel concerné, puis recommencer avec un autre rayon.

> On gère des triangles et des sphères pour le moment, mais sans interpolation des normales pour les triangles, rendu "facettes" donc (pas très gênant pour un cube ).

> Côté matériaux : diffuseurs lambertienns et miroirs parfaits, évidemment un matériau pour gérer les lumières, et j'ai pompé affreusement Indigo l'autre jour en faisant un "diffuse transmitter" qui renvoie la lumière aléatoirement dans l'hémisphère "en dessous" de la surface, au lieu de renvoyer au dessus comme un diffuseur. C'est avec ce matériau qu'on obtient l'espèce de lampion de l'image en bas à droite.

Ce qu'on n'a pas codé (pas encore, ou qu'on ne codera pas parce que c'est soit compliqué, soit inutile pour notre étude) :

> des matériaux non opaques, ils seront bientôt codés, ça nécessite quelques modif's dans le code, chaque matériau non opaque devant indiquer quel milieu il contient, avec indice de réfraction, etc. En tout cas à la façon dont ont été codés les squelettes des matériaux, c'est un jeu d'enfant d'en implémenter des nouveaux. Là je travaille sur un matériau Phong pour l'instant.

> on gère pas autre chose qu'un filtre "Box" pour calculer l'impact d'un rayon sur l'image (çàd qu'il imprime que le pixel où il a tapé et pas les pixels autour, et ce, indépendamment de sa distance au centre du pixel, s'il tape dans le coin d'un pixel ça compte autant que s'il tapait au milieu, et il "déborde" pas sur les autres pixels, d'où l'aliasing sur les lampes puissantes comme sur l'image en bas à droite). On rajoutera bientôt d'autres méthodes de filtrage comme Gauss ou CatRom par exemple, qui rendront le grain plus doux parce que là c'est moche (j'ai appliqué de l'anti aliasing en post prod sur les images montrées là)

> de même, le Tone mapping qu'on utilise pour le moment est limité : soit linéaire (pas terrible si on met des lampes qui émettent à plus de 1), soit bidouillé : quelque chose de la forme c/(c+1) (c étant soit la composante rouge, soit bleue, soit verte d'une couleur), ça a le mérite de ramener entre 0 et 1 l'intensité lumineuse et donc d'éviter de cramer les couleurs, on ramène ensuite entre 0 et 255 pour avoir une image standard. En fait ça convient très bien, donc ça m'étonnerait qu'on aille s'amuser à aller chercher les courbes de réponse de différentes caméras (ou de l'oeil humain) pour étalonner les couleurs comme le fait Indigo...

> une camera réelle, avec une vraie lentille (on le fera sûrement pas ça, l'intérêt de pouvoir avoir du flou de profondeur ou de la distorsion due à la lentille étant assez limité)

> une méthode pour accélérer les calculs d'intersections du genre Octree, pour éviter d'avoir à tester, pour un rayon lancé, chaque triangle pour voir s'il y a intersection. Ca non plus on le codera sûrement pas, ça nous amènerait à pas mal de prises de tête et à des modif's importantes du code (pas prévoyants les mecs ) Pour des scènes d'une vingtaine de triangles comme une Cornell Box c'est pas trop un problème, partitionner l'espace ralentirait même l'algo.

Voilà, si ça vous intéresse, je pourrai bien sûr uploader le code et des explications, mais pour l'instant j'attends de voir si des gens sont enthousiastes avant de me lancer dans des explications supplémentaires de plusieurs paragraphes . Pour info, c'est codé en C++ et on utilise la bibli Qt pour l'interface. Dans tous les cas, si vous avez des questions, n'hésitez pas

@+ pour d'autres images toutes plus extraordinaires les unes que les autres

Cette contribution était de : http://blenderclan.tuxfamily.org/html/newbb/viewtopic.php?forum=25&topic_id=20889&post_id=258279