Re: [Pixelvore] MOLE, le moteur de rendu des taupins :)

Posté par Pixelvore le 26/7/2009 10:49:30
@ 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 ? )


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