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

Alors là, je suis sur le cul ! Tu commence à être sérieusement énervant à faire des trucs pareil !

En plus tu lui a donné un nom récursif, c'est trop la classe


Plus sérieusement, c'est franchement intéressant ce que tu fait, j'ai hâte de lire la suite !

Citation :

Mais grave que ça m'intéresse, pareil pour ton futur rapport de TIPE (il y en a bien un, non ?)

edit: c'est un peu dommage d'avoir fait de la post-prob sur tes images, c'est un peu de la gruge :-p

Citation :
Oui j'aime bien l'effet vache qui rit

J'upload le code une fois qu'il sera commenté si tu veux (y'a du boulot là )

A part ça, petit up : je m'entraîne avec des distributions non uniformes de la direction émergente lorsqu'un rayon frappe une surface. L'idée c'est d'échantillonner la direction émergente là où on sait que la réflectance du matériau est la plus grande, pour accélérer la convergence. Pour se convaincre que ça marche, suffit de penser à un miroir parfait : c'est tout de même plus judicieux de renvoyer le rayon selon la direction bien connue donnée par la loi de Descartes, plutôt que de "scanner" toute l'hémisphère pour se rendre compte que la réflectance est non nulle seulement pour une direction.

J'ai fait un test sur les diffuseurs : au lieu de renvoyer uniformément dans toutes les directions, j'utilise une fonction de densité proportionnelle au cosinus de l'angle entre la normale et la direction incidente, puisque pour un diffuseur l'énergie émergente vaut simplement : énergie incidente * constante * cos(L,N).
Et voilà ce que ça donne : le grain est réduit, à nombre de rayons égaux, mais par contre je vois apparaître des raies étranges sur le rendu, allez savoir pourquoi (on en est pas au premier bug après tout ) :



[edit] en réponse à ton édit : c'était juste pour l'anti aliasing, d'abord

Citation :

Oui, tant qu'a faire, je prefererai

Citation :

Alors là, j'ai franchement rien compris !

Je vais relire ça une dizaine de fois, pitetre ça passera mieux

edit: en fait, j'ai compris, mais tu va surement en larguer quelques un. Si t'avais un petit schéma qui regroupe les diverse notions (direction incidente, diffuseur, reflectance ...), ça serai plus didactique.

Pour les "raies étranges", tu parle de ce qu'on voit sur le mur rouge ? Sinon je vois pas bien. Tu aurais pas des rendu plus grand ?

Waouh, c'est à la fois impressionnant et très intéressant.

Ca donne vraiment envie de se renseigner pour comprendre les termes techniques que tu emploies (c'est d'ailleurs ce que je suis en train de faire)

Je ne suis pas spécialement intéressé par le code (il y a longtemps que j'ai renoncé à comprendre des prgrammes complexes... Quelques questions ceci dit :

Peut on avoir une approximation du temps de rendu pour les images d'exemple ? Avez vous déjà poussé le rendu jusqu'à obtenir un résultat très fin ?

Est-ce que ce sera Open Source ? Avez vous l'ambition de développer ce soft en dehors du cadre du TIPE ?

Quel est votre format d'entrée pour les scènes 3D ?

Quant pourra-t-on tester ça chez nous ?

@ Batmur :
Je vais essayer d'être plus clair :

Pour évaluer l'énergie perçue en une direction en un point d'une surface, on utilise une méthode Monte Carlo : quand un rayon impacte une surface, il est renvoyé aléatoirement dans une direction, on diminue son énergie en fonction du matériau, et lorsque le nombre de rayons bombardés augmente, on évalue avec de plus en plus de précision l'énergie perçue.
A ce stade, les "rayons" n'ont pas vraiment de sens physique, puisqu'on se contente de les renvoyer uniformément dans toutes les directions et de regarder ce qui se passe. La seule légitimité physique, c'est qu'on multiplie l'énergie d'un rayon par la réflectance du matériau, qui dépend des directions incidentes et émergentes. Donc on "force" la distribution de l'énergie à se faire correctement.

Seulement voilà, en réalité c'est l'inverse qui se passe : c'est parce que les rayons rebondissent dans une direction privilégiée qu'on observe a posteriori que la réflectance n'est pas constante et dépend des directions incidentes et émergentes (c'est ce passage qu'il faut bien comprendre ). Si on renvoie les rayons uniformément dans toutes les directions et qu'on multiplie leur énergie par la réflectance, on ne fait que constater les effets. Si on renvoie les rayons préférentiellement dans une direction, on crée les effets, et on n'a alors plus besoin de multiplier l'énergie d'un rayon par la réflectance. C'est ce que j'entendais par "distribution non uniforme de la direction émergente d'un rayon". J'espère avoir été clair, mais j'avoue que là dessus j'ai passé pas mal de temps pour être sûr que je comprenais pas de travers ce que je lisais.

@ tibo :

- Le temps de rendu sur les images données est d'environ 15 mn, de tête. Pour l'instant on n'a pas poussé le rendu pour avoir un résultat très fin, parce que notre filtre "box" laisse un aliasing assez moche, et on obtient des raies lorsque le temps de rendu augmente. On pense que c'est à cause des conversions de float (coordonnées d'un rayon) vers int (coordonnées du pixel correspondant), si c'est bien ça, ça sera réglé lorsqu'on codera un filtrage plus réaliste.

- On n'a pas trop d'ambition pour ce p'tit programme, c'est plutôt "for studying purpose" disons, il faut bien avouer qu'il ne fait que reprendre ce que des moteurs de rendu de compétition font depuis des années...

- On rentre les coordonnées des points de nos triangles et sphères en ligne de code pour l'instant C'est pas très pratique, si on a le temps, on rajoutera quelque chose pour lire des fichiers et importer des modèles, mais j'en doute : c'est vraiment pas l'objet du TIPE (les examinateurs s'en ficheront pas mal de savoir si on importe le format .blend, c'est pas trop l'objet de l'étude : ça ferait du travail en plus sûrement pas valorisé.)

- Tu pourras tester dès que j'aurai uploadé le code, dans pas longtemps donc, faut que je commente un peu là

[edit] @Batmur : j'ai encadré queques zones où ça me fait des raies (je rêve pas, y'a bien des raies hein ? )

Etant aussi taupin
ton sujet de tipe me parait particulièrement adapté pour le thème de l'an prochain ( même si moi j'espère ne pas avoir besoin de le traiter)
Comme c'est un sujet d'informatique je suppose que tu dois être en Mp ma seule remarque est avant de rentrer dans le vif du sujet, est tu sûr d'avoir le droit de rédiger tes programme en c++?!
J'ai tendance à penser qu'on doit se restreindre à Caml ou turbopascal en fonction du programme utilisé dans ta prépa. Je ne suis pas totalemement sûr mais à moins que tu ne l'ai vérifié fais-le avant de faire du travail inutile ce qui serait dommage

Tiens, un confrère taupin ! T'as bien choisi ton pseudo en plus

En réponse à tes questions : yep j'suis en MP (* même #gonflé de fierté# ), je fais SI par contre, pas info (l'info j'ai jugé que c'était simplement des maths avec le PC, moi ce qui m'intéresse c'est faire de la physique avec le PC en fait). C'est vrai qu'ils utilisent des langages plutôt spéciaux comme Caml, pour faire des maths en résumé, mais à ce que je sache ça pose pas vraiment de problème de faire un prog dans un autre langage (je connais quelqu'un qui avait fait un prog en C++ aussi et qui s'en est tiré avec un 16 ).

Après, on imprimera pas tout le code, on fera simplement des captures d'écran des passages clé du programme à mon avis. On orientera pas l'étude sur la façon dont c'est codé, plutôt sur les principes physiques à l'appui. Un peu comme ce que je viens d'expliquer sur les distributions non uniformes de la direction sortante d'un rayon : les maths nous donnent les méthodes Monte Carlo pour évaluer des intégrales complexes, et la physique nous dit que c'est judicieux d'utiliser des distrib non uniformes pour accélérer la convergence... Et pas des distributions quelconques puisqu'on les "cale" sur les propriétés physiques du matériau concerné...
Bref, on s'émancipera de tout détail technique () pour se concentrer sur le sens physique de la chose. Du moins je l'espère

Citation :

C'est un signe...?

Est-ce que tes recherches personnelles en tant qu'utilisateur (je pense notamment à ton travail sur les shaders de peau) influencera ce projet ? (i.e. disposera-t-on un jour d'un moteur de rendu spécialisé dans les épidermes et inventé par un blenderien ?)

Pour ceux qui rame pour comprendre les propos de Pixelvore, voilà un petit schéma:



Un point important à comprendre, c'est que dans le ray-tracing, la lumière va dans le sens inverse de la réalité. Les rayons sont émis par la caméra, et rebondisse jusqu'à atteindre une lampe ou être trop atténué par les rebonds.