Merci Mauricio et Cari et Kybio :)

Voici la mise a jour (desole pour le retard). J'ai donc inclus dans cette nouvelle mise a jour (entre autres):
- un algo d'acceleration pour les scenes contenant beaucoup de primitives (Fractal #1 contient environ 400 000 spheres, et Dragon contient 100 000 triangles). C'est toujours assez lent mais c'est infiniment plus rapide que la methode naive. Cependant il est deconseille d'utiliser l'acceleration pour les scenes simples (= toutes les scenes sauf Fractal et Dragon pour le moment) car il y a un cout initial. En fait on decompose l'espace en cubes de facon recursive, ce qui permet d'economiser la grande majorite des tests d'intersection. J'utilise une Octree, mais ce n'est pas optimal it il faudra continuer a travailler dessus.
- la refraction est corrigee, et j'ai inclus quelques materiaux communs "miroir", plastique, verre, et matte (une surface completement diffuse). C'est suffisant pour le moment mais il est facile d'en ajouter en creant une nouvelle classe derivee de TMaterial. J'ai envie d'ajouter un materiau "metal" mais il faut que je me renseigne sur la fonction de reflectance des metaux.
- j'ai donc inclus un generateur de scenes, il faudra donc le lancer avant de pouvoir utiliser la source, pour generer les scenes. Il y a pas mal de scenes simples, et deux scenes complexes: Fractal, qui est simplement une fractale a base de spheres, et Dragon, qui utilise le modele du dragon chinois (du fichier dragon.obj) avec un materiau de type plastique rouge. Vous avez juste a cliquer les boutons pour creer les scenes qui seront alors utilisables. Le code du generateur de scenes est egalement inclus mais c'est un peu desordonne. Le "buddha" tout en bas n'est pas disponsible car il n'est pas tres interessant et ca rendrait le zip tros gros (qui est deja plus large que 1Mo a cause du dragon).

N'oubliez pas de cocher Octree Subdivision dans les options quand vous utilisez les scenes Fractal #1 et Dragon, cela active l'algo d'acceleration.

La capture est celle du dragon (quand elle sera mise a jour par le site).

Pour la recursion, oui il serait possible de derecursifier le calcul de la radiance, ce que je ferai eventuellement (en fait l'avantage d'utiliser la recursion ici est que le calcul de la radiance doit se faire a l'envers, ce que la recursion fait de facon intrinseque, mais c'est assez simple a derecursifier). Cependant pour ce qui est des appels de methode, il faut accepter qu'un code sans methodes devient juste une bouillie de code incomprehensible, donc il faut tracer une ligne entre les procedures qui peuvent etres eliminees sans trop de probleme de lisibilite (comme mes procedures IncPtr et DecPtr, que j'ai surtout ajoutees pour m'aider quand j'implementais la lecture du fichier scene), et celles qui ne peuvent etre, comme les appels de methode des types descendants de TMaterial et TPrimitive, qui sont necessaires pour permettre d'ajouter des nouveaux types de primitive (comme des cylindres ou des cones), et des nouveaux materiaux. Utiliser les classes Delphi a un cout (un appel de methode virtuelle est assez couteux), mais a aussi beaucoup d'avantages non negligeables!

Et n'oublions pas que l'optimisation prematuree est la source de tous les maux - il est important en phase de developpement de garder le code le plus lisible possible afin de pouvoir faire des changements facilement. Une fois que tout est en place, on peut alors tout optimiser (ou mieux encore: garder une version "developpement" non optimisee, et faire une version optimisee rapide a cote).

"pas sûr que les deux double buffered soient utiles ici.."
Pour l'image dans l'interface graphique? En effet c'est peu utile si l'image n'est mise a jour qu'une fois toutes les secondes, mais dans la nouvelle version (qui arrive a grand pas!) j'ai inclus une option pour choisir sa vitesse de rafraichissement, donc il faudra le garder je pense.

Je vous tiens au courant, j'ai fixe le probleme de refraction, et j'ai egalement ajoute un algorithme d'acceleration (en subdivisant la scene). C'est ultra primitif mais ca m'a permis d'afficher une scene contenant 600000 spheres a une vitesse raisonnable! Cependant je dois maintenant travailler un peu sur un petit generateur de scenes, car je veux vous montrer la scene qui contient toutes ces spheres mais le fichier fait 25Mo, il faut donc que j'ajoute le programme qui permette de la generer (c'est juste une fractale).

Tout ca pour dire que la mise a jour approche et sera interessante je pense.

En revanche par contre, le code de refraction ne marche plus... :( ... je ne sais pas pourquoi et je m'y pencherai sous peu. J'ai egalement enleve presque toutes les scenes car il faut les convertir au nouveau format, je les remettrai (parmi d'autres) a la prochaine mise a jour.

>>>> MAJ!

J'ai change de methode, maintenant j'utilise un algo recursif a base de radiance et d'emittance. J'ai donc ajoute quelques options additionelles dans l'interface, par exemple la profondeur de recursion - en general la valeur par defaut (8) est suffisante, mais pour certaines scenes il n'est parfois pas necessaire d'en avoir autant (ce qui fait gagner beaucoup de temps), et pour la plupart des scenes 8 est assez (l'influence des bonds sur la couleur du pixel diminue exponentiellement, donc a part certaines conditions tres particulieres le 9eme bond ne fait plus de difference sur la couleur 8-bit du pixel final).
J'ai reconcu completement comment les materiaux sont geres, maintenant ce sont des classes heritees comme les primitives, ce qui permet de simplifier les fichiers scene et simplifier le code de calcul de couleur (qui est maintenant tres tres simple).
Le gain en vitesse est... interessant.

J'ai essaye d'implementer une methode de Quasi-Monte-Carlo mais ca a pas bien marche, il faudra que je regarde plus en detail - apparemment il est necessaire d'utiliser des suites 3-dimensionnelles pour utiliser QMC dans des situations 3D, sinon on a des problemes de dimensionalite, mais il faut que cette suite puisse etre generee progressivement dans mon cas.

Merci Cari mais malheureusement je ne peux utiliser cette methode. Elle est basee sur le generateur pseudo-aleatoire de Delphi, qui, malheureusement, n'est pas utilisable depuis plusieurs threads simultanement (les resultats sont similaires et parfois corrompus). C'est pour ca que j'ai du implementer un PRNG encapsule dans un objet (j'ai egalement ajoute une fonction qui retourne des nombres avec une distribution gaussienne dans l'unite PRNG.pas - elle utilise la transformation de Box-Muller, je pense que RandG fait pareil).

Pour la reflexion, il est vrai que certaines directions sont privilegiees, mais ce n'est pas la normale :p
En fait il y a trois types de materiaux (en general, il y a evidemment des materiaux exotiques differents):
- materiaux diffus: ils reflechissent de facon equivalente partout dans l'hemisphere defini par la normale
- "glossy": ils reflechissent dans ce meme hemisphere mais privilegient les reflexions proches du vecteur de reflexion speculaire (a meme angle avec la normale)
- et speculaire, ou tout rayon reflechi aura une seule direction, trouvee par la formule de reflexion bien connue

Speculaire est un attribut a part (obtenu en separant les rayons speculaires par les rayons diffus/glossy de facon probabiliste avec le terme Specularity), c'est-a-dire qu'on peut avoir:
1. diffus + speculaire
2. glossy + speculaire
3. juste speculaire
4. just diffus
5. just glossy

Il ne s'agit en fait pas d'une distribution gaussienne mais d'une distribution "cosinus" pour prendre en compte le domaine de reflexion (qui est un hemisphere centre sur la normale).

Tout ceci est bien distinct de la refraction, qui est separee de la reflexion via le terme de Fresnel, evidemment.

Apparemment il y avait une enorme boulette dans la fonction de reflection diffuse (rayon aleatoire dans l'hemisphere) qui donne des images pas realistes du tout, je corrige ca!

Merci pour la clarification Cari. En revanche je crains que le temps ne puisse pas etre reduit pour un effet de flou, car comme tu l'a dit ce n'est pas un effet optique mais geometrique, consequence du champ de vision des cameras ordinaires. Le flou est en general obtenu en lancant des rayons aleatoirement dans un cercle autour du pixel concerne, le cercle etant plus ou moins grand dependant du flou necessaire (base sur la distance de l'objet jusqu'a a la camera). Ceci requiert evidemment beaucoup plus de rayons :(

En revanche, on peut toujours faire semblant, en calculant l'image de facon ordinaire ET en produisant une "depth-map", c'est-a-dire une image qui contient les distances que chaque rayon initial doit parcourir pour intersecter le premier objet. On peut alors effectuer l'effet de flou tres rapidement dans n'importe-quel editeur image (Photoshop, etc..), mais ce n'est pas physiquement correct (et ce sera peut-etre pas tres beau).

Petite info - j'ai resolu le probleme des couleurs, et j'ai aussi modifie l'algo encore une fois:
- maintenant, un seul rayon est trace, et les trois couleurs RGB sont considerees simultanement
- la reflection diffuse et speculaire ont maintenant des couleurs differentes, ce qui donnera un aspect moins "bonbon" aux spheres colorees
- la refraction peut egalement avoir une couleur mais en general c'est la meme couleur que le speculaire

J'ai besoin de remettre en forme le code, car l'algo est assez different, je ferai une mise a jour d'ici un jour ou deux.

Argh. Vous excuserez l'oubli d'une ligne de code pour gerer la mise a jour du bouton de sauvegarde de l'image - rajouter "SaveBtn.Enabled := Running;" dans la methode UpdateButtonStates dans Main.pas. Je l'ai oublie et appuyer sur le bouton de sauvegarde lorsque le programme ne tourne pas provoque une EViolationAccess. Je ne vais pas remettre a jour la source pour cet oubli, j'attendrai que la prochaine MAJ soit prete.

Merci a tous! Tres bonne explication Cari je n'aurai pu l'expliquer mieux :) en effet la beaute de cet algorithme est que tous les effets naturels observables decoulent naturellement de l'algorithme, il n'est pas necessaire d'ajouter quoi que ce soit.

@Cirec: c'est corrige - en effet les mises a jour des boutons n'avait pas besoin d'etre dans un timer puisque leur changement est predictable, j'ai ajoute une methode pour corriger ca.

>>> Mise a jour!!

- plein de nouvelles scenes!
- correction d'un peu de code
- j'ai maintenant inclus des versions haute qualite de quelques scenes pour voir le resultat sans avoir a attendre (tout frais de mon processeur lol)
- vous remarquerez que depuis la premiere MAJ il y a une fonctionnalite de lissage des bords (anti-aliasing), j'avais juste oublie de le mentionner. Il existe en fait aussi un support pour le depth-of-field (l'effet de flou pour les objets proches et distants comme pour une vraie camera), mais c'est pas terrible (mal implemente) donc je ne l'utilise pas avec les scenes actuelles.

Par contre je ne suis pas content de la facon dont les couleurs sont gerees, ce n'est pas assez general. Ce sera (esperons) fixe pour la prochaine mise a jour.

@MD21: merci, bien sur tu peux utiliser mon code, il est la pour ca! Si tu as besoin d'explications sur le code n'hesites pas. Par contre, le code est tres susceptible de changer, je vais surement encore perfectionner l'algorithme et ajouter d'autres fonctionnalites, changer des bouts de code ici et la, etc... ceci n'est qu'un premier brouillon. Il y a encore beaucoup, beaucoup de boulot pour le transformer en quelque chose de plus utilisable qu'un simple jouet (pour donner quelque chose d'utile a faire a son processeur, hehe).

Mise a jour!!
- interface graphique amelioree
- nouvel algorithme
- code retouche

Objectifs pour la prochaine MAJ:
- repenser la camera
- creer une structure d'acceleration spatiale (du type BVH) pour permettre d'avoir des scenes plus complexes
- trouver des moyens d'accelerer la convergence du rendu

En fait l'algo que j'utilise en ce moment est en fait different de celui generalement utilise par les programmes de Path Tracing. La plupart de ceux-ci, en fait, accumulent la couleur d'un pixel dependant du chemin du rayon a travers la scene (c'est toujours probabiliste car les reflections diffuses sont aleatoires), et valident la couleur quand le rayon intersecte une lampe (ou certains assument que tout rayon atteindra une lampe eventuellement, ce qui est raisonnable, et en echange s'arretent apres un certain nombre de collisions).

L'algo que j'utilise, en fait, envoie trois rayons par pixel (plusieurs fois, evidemment, car c'est probabiliste), un rayon rouge, un rayon vert et un rayon bleu (on peut changer ca, evidemment, j'utilise rouge vert et bleu car l'image finale sera en mode RGB - on peut utiliser CIE-XYZ ou autre pour obtenir le meme resultat). Le concept est super-simple - il suffit de decider, pour chaque rayon, si celui-ci est eventuellement absorbe par une lampe ou par un autre materiau qui n'emet pas de lumiere. En gros, l'algorithme cree des chemins entre les lampes de la scene et les rayons sortant de la camera. Si un rayon est absorbe par une lampe, il contribue a la couleur du pixel, et si il est absorbe par autre chose, il ne contribue pas. La contribution depend directement de l'intensite de la lampe concernee.

(l'algo initial envoyait 400 rayons par pixel, un pour chaque longueur d'onde, et reconstituait la couleur du pixel depuis le spectre obtenu, mais c'etait pas pratique, instable, et lent).

Cari pour la variance je pensais d'avantage a la discrepance temporelle, c'est-a-dire comment la couleur du pixel fluctue plus le nombre de rayons par pixel augmente (ce qui met du temps). Une discrepance temporelle tres faible veut dire que le pixel a statistiquement obtenu sa couleur finale et peut etre ignore (ou presque), alors qu'une haute discrepance temporelle voudrait dire que les rayons passant par ce pixel suivent une trajectoire tres complexe et que beaucoup de rayons seront necessaires (ca permet de concentrer les efforts la ou ils sont requis - inutile d'envoyer dix mille rayons s'ecraser instantanement dans une lampe...). Mais ceci sera probablement difficile a implementer.