RAYTRACING EN DELPHI (PROGRESSIVE PATH TRACING)
John Dogget
Messages postés
384
Date d'inscription
vendredi 18 juin 2004
Statut
Membre
Dernière intervention
7 mai 2009
-
2 janv. 2012 à 22:51
Bacterius Messages postés 3792 Date d'inscription samedi 22 décembre 2007 Statut Membre Dernière intervention 3 juin 2016 - 19 avril 2012 à 14:23
Bacterius Messages postés 3792 Date d'inscription samedi 22 décembre 2007 Statut Membre Dernière intervention 3 juin 2016 - 19 avril 2012 à 14:23
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/53931-raytracing-en-delphi-progressive-path-tracing
https://codes-sources.commentcamarche.net/source/53931-raytracing-en-delphi-progressive-path-tracing
19 avril 2012 à 14:23
19 avril 2012 à 08:33
19 avril 2012 à 04:49
Comment avoir ces fichiers manquants SVP ?
Quarto
12 mars 2012 à 23:55
http://sourceforge.net/projects/aqsis/?source=directory
auquel-cas il y aurait de grosses feignasses qui à la vue du lien ne voudrait pas faire l'effort mdr.
sur ce @+.
12 mars 2012 à 23:48
merci également pour le lien "smallpt", intéressant lui aussi mais il existe aussi un très bon raytracer en java http://www.artofillusion.org/.
mais le best of the best reste quand même Aqsis, et là c'est du lourd avec des techniques pros(basées sur un standard défini par Pixar c'est peut dire !!!)http://sourceforge.net/projects/aqsis/files/aqsis-source/1.8.0/Aqsis-1.8.0-Source.tar.gz/download il gère également le rendu software et hardware.
bien-sûr que ça demande beaucoup de travail et je respect ton courage ou devrais-je dire bon courage pour la suite.
ps: prends le temps qu'il faudra !!, et à toi de réfléchir quand à l'algorithme le plus adéquate.
@+
11 mars 2012 à 00:44
En effet je me suis beaucoup inspire de l'article que tu linkes, en revanche celui qui m'a le plus aide au niveau theorie avec les interactions de la scene avec la lumiere etc.. c'est celui-ci:
http://kevinbeason.com/smallpt/
En revanche comme celui-ci contient un code absolument inbuvable (on se demande pourquoi, franchement), j'ai consulte la version Java d'une autre personne, qui est legerement differente mais j'ai pu combler les trous aisement: http://pyrolistical.github.com/smallpt/
En ce moment je suis en train de jouer avec OpenCL pour voir si il serait possible d'utiliser le processeur graphique pour le ray tracing. J'ai egalement fait une version FPC (Free pascal) assez optimisee, mais je suis assez coince sur les algos d'acceleration (octree, kd-tree, etc...), c'est vraiment la misere a implementer. Tant de choses a faire, et peu de temps en dehors des week-ends depuis quelques jours, j'espere pouvoir y consacrer davantage de temps dans le futur (vacances etc...)
"peut-être qu'un rendu directement dans un fichier *
bmp ou *.png avec seulement l'affichage en pourcentage sur la fiche ..."
L'affichage de l'image prend un temps processeur negligeable (vu que je ne fais qu'une copie memoire dans la memoire du bitmap), mais oui c'est possible. D'ailleurs, il y a une possibilite d'optimisation que j'ai oublie dans le code: dans le thread, placez les mises a jour de rgbRed, rgbGreen, etc... en-dehors de la boucle. C'est toujours ca de gagne.
Desole pour le manque d'accents... clavier anglais.
11 mars 2012 à 00:10
ah le dragon il est mortel !!!.
on peut aussi cité en complément ce site très intérressant(en ce qui me concerne en tout cas !!!).
http://devmaster.net/posts/raytracing-theory-implementation-part-1-introduction
puis ça aussi
http://devmaster.net/categories/articles
PS:faut prendre le temps de lire car il y'a beaucoups de fichiers sources, *.pdf à télécharger parfois très volumineux.
bon coding !!!, et idem j'attends des mises à jours pouvant dopé le renderring !!! ;).
euhh concernant le c++, vous verrez que le timing de Bacterius est plutôt correct, du moins en comparaison avec le site cité plus haut, bon d'accord le rendu est légèrement meilleur néanmoins pour faire un code rapide en c++ il faudrait codé tout ça avec la philosophie c++, pas de traduire bêtement le code de delphi vers le c++, de plus le c++ est smart-link ce qui réduit de beaucoup certaines routines(et de ce fait le temps d'accès du cpu), quant aux optimisations delphi/c++ c'est un peu près identiques sauf qu'on peut choisir en c++ un privilège pour certaines fonctions vectorielles des cpu mmx.
peut-être qu'un rendu directement dans un fichier *
bmp ou *.png avec seulement l'affichage en pourcentage sur la fiche ...
@+
20 janv. 2012 à 04:16
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).
18 janv. 2012 à 03:15
17 janv. 2012 à 14:34
A+
17 janv. 2012 à 13:29
« PS: je note une perte de vitesse évidente de traitement chaque fois que j' utilise la récursivité! »
Effectivement. La dé-récursivation fait partie de l'optimisation.
Mais on optimise toujours un code qui fonctionne bien, et il est sans doute encore trop tôt pour le faire ici.
Cela dit, ce n'est peut-être pas la peine de chercher à implémenter des routines récursives à ce stade de développement.
Le problème de la récursivité est le même que celui dont parle Cirec au début de la discussion. Il faut en effet éviter de multiplier les appels à des méthodes extérieures depuis l'intérieur des routines, particulièrement dans les boucles.
Et la récusivation consiste en fait à appeler la fonction depuis l'intérieur de cette même fonction. Cela a donc un coût !
Dans le même ordre d'idée, Bactérius pourrait supprimer des procéduress un peu inutiles comme :
procedure IncPtr(var P: Pointer; const N: Longword); { Increments P by N bytes. }
et
procedure DecPtr(var P: Pointer; const N: Longword); { Decrements P by N bytes. }
dont l'appel est coûteux, et pourrait être remplacé par une seule ligne de code.
17 janv. 2012 à 10:57
Joli résultat graphique en tout cas,
Bravo
Mauricio
PS: je note une perte de vitesse évidente de traitement chaque fois que j' utilise la récursivité!
17 janv. 2012 à 06:17
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.
16 janv. 2012 à 23:03
13 janv. 2012 à 23:38
13 janv. 2012 à 23:35
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.
12 janv. 2012 à 21:15
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.
12 janv. 2012 à 12:26
J'imagine que la distribution spatiale des rayons réfléchis n'est pas homogène et qu'elle comporte des directions privilégiées (comme la normale, par exemple). Je suppose aussi que cette distribution doit + ou - suivre une distribution gaussienne. Alors je te signale une fonction de l'unité Math bien pratique :
RandG()
Elle fournit des nombres pseudo-aléatoires selon cette distribution gaussienne.
Tu peux t'en servir directement avec le générateur de Delphi ou créer ta propre fonction avec le générateur que tu as implémenté dans ton application.
Mais la réflexion est un phénomène que je ne maîtrise pas très bien, donc tout cela est à vérifier.
Bon courage !
12 janv. 2012 à 09:03
11 janv. 2012 à 23:53
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.
11 janv. 2012 à 13:56
Le parallèle qu'on peut faire entre Nicéphore Niepce, le 1er photographe, et Bacteius est saisissant ! ^ ^
En effet, le premier appareil photographique n'avait pas le problème de la profondeur de champ. L'image obtenue était parfaitement nette sur tous les plans. Cela était dû aux avantages du sténopé.
VOIR: http://fr.wikipedia.org/wiki/St%C3%A9nop%C3%A9
L'inconvénient du sténopé était le temps de pose extrêmement long (8 heures !). C'est pareil pour Bacterius : image très nette mais un temps de traitement qui peut paraître excessif. C'est amusant...
Tout ça pour dire que je trouve que si on veut introduire un effet de flou, il faudrait que cela ait pour conséquence une réduction du temps de traitement. Là, ce serait intellectuellement acceptable, je pense.
En effet, le problème de profondeur de champ n'est pas une réalité de la physique mais un défaut de l'oeil humain et de nos apareils photo (même principe).
Il est à noter que l'on commence à trouver sur le marché des appareils photo pouvant donner une image nette à toutes les distances : les appareils photographiques plénoptiques de Raytrix.
VOIR: http://www.reportagesphotos.fr/A2447-raytrix-r11-premier-boitier-numerique-plenoptic-du-marche.html
11 janv. 2012 à 06:33
11 janv. 2012 à 06:26
@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).
10 janv. 2012 à 18:25
c'est effectivement très très lent, mais les transparences et les shadings sont très bien gérés si on laisse le temp à l'image de s'affiner
Personne jusqu'ici n'avait proposé de code de raytracing en Delphi alors que j'en ai cherché pendant bien longtemps avant de partir de zéro (enfin presque: juste une assez bonne théorie de ce type de 3D mais aucun code) pour créer mon propre moteur en raycasting (technique similaire au raytracing mais orientée jeu) avec l'aide bienvenue de Cirec et Caribensila pour améiorer la vitesse.
Je pourrai peut-être, avec ta permission Bactérius, utiliser quelques lignes de ton code pour perfectionner le mien, si j'arrive à bien le comprendre ...
Ce qui prouve que delphi peut faire de grandes choses !
9 janv. 2012 à 23:55
Mais bon... C'est un peu un passage obligé dans ce genre de développement.
Je voudrais quand même insister sur ce que je trouve "génial" dans le résultat du travail de Bactérius ( et il me pardonnera certainement de le faire sa place ;) en essayant de parler simplement :
Il suffit de regarder attentivement la capture.
De remarquer le léger reflet sur le plafond dû à la boule transparente.
Ce reflet est en fait dû à la tache de lumière blanche et intense que l'on peut voir sur le sol, devant cette boule et provoqué par cette même boule dans un premier temps (comme une loupe). Puis cette lumière repasse dans la boule pour provoquer ces légers reflets sur le plafond...
Ce qui me paraît extraordinaire, perso, c'est que cet effet super-réaliste n'a pas eu besoin d'être programmé ni prévu par Bacterius. C'est simplement le résultat d'une technique humaine qui, reproduisant le monde réel de façon particulière (et en 2D !), aboutit exactement au même résultat que la Nature.
Parfois, en programmation, on approche le divin. Non ? ^ ^
9 janv. 2012 à 22:19
de toute façon ces discutions me dépassent ... j'étais pour ainsi-dire << Lost in Comments >> ^^
comme l'a d'ailleurs fait remarquer John Dogget, je ne dois pas être le seul dans cette situation.
Sinon que dire ...
oui c'est vachement plus rapide qu'avant et c'était déjà un sacré boulot mais là c'est encore mieux !! Bravo
Quand on pense où notre jeune ami en était il y a tout juste deux ans encore ... Tu as fait énormément de progrès en peu de temps et maintenant tu en imposes déjà dans plusieurs secteurs de programmation. si si je le pense.
Pour tout ça et le reste ...
Bravo, Félicitations et Merci de le partager avec nous ;)
Note :10/10
Il y a juste une petite chose qui me chagrine ... :
[Mode Recherche la petite bête]
je peux pas m'empêcher de dire que dans l'évènement OnTimer il n'est pas utile de mettre 10/Sec. à jour boutons et icônes:
SettingsBtn.Enabled := not Running;
PlayPauseBtn.Enabled := Running;
StopBtn.Enabled := Running;
SaveBtn.Enabled := Running;
if not Running then PlayPauseBtn.ImageIndex := 2 else
if Tracer.Suspended then PlayPauseBtn.ImageIndex := 2 else PlayPauseBtn.ImageIndex := 3;
Recherche la petite bête
@++
9 janv. 2012 à 17:55
« Il est plus beau d’éclairer que de briller ».
^ ^
9 janv. 2012 à 11:32
Et à ce propos, pourquoi ne pas joindre la théorie à la pratique ?
Voici d'ailleurs un exemple de traitement d'image qui pourrait inspirer bacterius :
http://www.lepoint.fr/high-tech-internet/en-direct-de-las-vegas-au-ces-des-objets-technologiques-non-identifies-09-01-2012-1416787_47.php
9 janv. 2012 à 00:09
Bravo ! Car ce n'est pas toujours évident (n'est-ce pas ?). ^ ^
C'est magnifique !
Je n'ai pas encore testé la vitesse, mais comme tu l'indiques dans ton intro, ce n'était pas ton but...
Très bon travail et très bonne réaction aux critiques => 10/10
8 janv. 2012 à 23:49
- 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.
8 janv. 2012 à 19:22
ce que tu appelles "variance" se nomme en fait "discrépance". En graphisme, on utilise souvent une discrépance un peu particulière basée sur le rectangne et notée D* (= discrépance étoile). Ca se calcule assez bien pour un ensemble de points donné.
La configuration quasi-aléatoire est, par définition, une configuration conçue pour minimiser la discrépance et permet une convergence plus rapide que la configuration strictement aléatoire dans certains problèmes, mais pas dans tous !
Les études actuelles en mathématiques et en algorithmique essaient justement d'identifier les problèmes pouvant en bénéficier de ceux qui en pâtiraient.
Mais cela dépasse de très loin mes compétences, et même ma curiosité. ^ ^
Pour le lancer de rayon, je sais que beaucoup de gens y travaillent actuellement afin d'améliorer les performances à l'aide d'algos très sophistiqués.
Et c'est tout le mérite de ton post de nous présenter les principes d'une méthode qui semble promettre beaucoup.
8 janv. 2012 à 18:19
En fait, si. Si tu utilises le meme algorithme pour le mode deterministe et le mode Monte-Carlo, en moyenne des resultats identiques seront obtenus apres un meme temps de calcul (bien que la methode de Monte-Carlo aura du grain a cause de la variance, certes). L'idee que Monte-Carlo doit etre plus lent vient du fait que l'algorithme n'est en general pas le meme.
Exemple: calcul de Pi via Monte-Carlo prendra du temps, on connait tous la methode, placer des points aleatoirement et approximer Pi avec une division. Transformer ceci en methode deterministe SANS CHANGER l'algorithme est simple, il suffit de placer les points a intervalles reguliers, sans l'aide d'aucune resource aleatoire. Plus l'intervalle est petit, plus la reponse est correcte. Il est alors evident que Monte-Carlo convergera a la meme vitesse que la methode correspondante deterministe.
En revanche d'autres methodes, deterministes, comme l'extraction individuelle de decimales, est infiniment plus rapide que la methode Monte-Carlo citee plus haut, mais c'est un algo totalement different, et donc pas comparable.
Les methodes quasi-Monte-Carlo sont tres similaires mais ameliorent la vitesse de convergence en utilisant non plus des nombres aleatoires mais une sequence mathematique avec une distribution particuliere (ca aide a reduire la variance, car des nombres aleatoires ont une enorme variance par definition). Mais l'avantage de cette methode est tres dependante de l'integrale qu'on essaye d'evaluer (cependant la methode Quasi ne sera jamais plus lente, ignorant le calcul des sequences mathematiques). Il est aussi possible de combiner les deux, en mixant des nombres aleatoires avec la sequence predefinie.
Cela dit, les meilleurs resultats en lancer de rayon ont etes obtenus avec des methode Monte-Carlo, mais en combinant la methode que j'utilise actuellement avec une autre methode (Photon Mapping). L'avantage du Photon Mapping est qu'il produit de la variance a basse frequence, donc l'image est beaucoup moins graineuse (au lieu de grain on a une image "sale", comme si on avait utilise une gomme dessus - exemple http://graphics.ucsd.edu/courses/rendering/2010/krlee/images/photon%20mapping_bump_reflection.jpg, observer les murs). En combinant les deux on peut effectivement faire disparaitre le grain, et en meme temps attenuer la variance basse frequence, produisant une image tres haute qualite. Mais ceci est en dehors de mes competences pour le moment :p
8 janv. 2012 à 01:35
Sinon :
« Le resultat de la methode Monte-Carlo convergera vers le resultat du processus deterministe, a la meme vitesse »
Pas du tout !
Certes, les résultats convergent, mais jamais à la même vitesse !
C'est beaucoup plus lent en aléatoire.
C'est pour cet inconvénient qu'on utilise de plus en plus la méthode dite de Quasi-Monte Carlo dans certains calculs financiers, par exemple. Et la force de la méthode Quasi-Monte Carlo est de ne pas utiliser de nombres pseudo-aléatoires, justement.
7 janv. 2012 à 23:41
7 janv. 2012 à 23:35
Pas tellement simplifier, mais plutot rendre plus commode. N'importe-quel processus deterministe de raytracing se basant sur l'equation de l'illumination globale (pas trouve de terme en francais, ca se dit Rendering Equation en anglais) peut etre transforme en processus Monte-Carlo, car l'equation de l'illumination globale est une integrale. Le resultat de la methode Monte-Carlo convergera vers le resultat du processus deterministe, a la meme vitesse (en ignorant les details d'implementation, en pratique ce sera un petit peu plus lent car il faut calculer les nombres aleatoires, mais ce sera du meme ordre de vitesse).
C'est important de stresser ce point - la methode Monte-Carlo est fondamentalement identique a la methode deterministe (genre Whitted (modele simplifie), ou Van Der Corput), c'est juste plus pratique a implementer car il n'y a pas de recursion necessaire et le nombre de rayons peut etre controle tres precisement. les deux methodes calculent exactement la meme integrale pour obtenir l'image finale.
Voir: http://en.wikipedia.org/wiki/Rendering_equation
7 janv. 2012 à 22:58
Les effets d'optique dûs à des détails microscopiques ne relèvent pas du tout de la mécanique quantique !
Prenons pour exemple l'aspect de notre Lune dans le ciel. Son aspect serait totalement différent si sa surface était plus lisse... Pourtant le comportement des rayons lumineux dû à la surface de la Lune n'a rien à voir avec sa composition atomique. Ce sont les lois de la réflexion classique qui s'appliquent. Tout comme à la surface d'une sphère de verre dépolie, par exemple.
Le mode aléatoire dont tu te sers ne sert qu'à simplifier l'opération. Tu pourrais aussi bien utiliser une méthode complétement déterministe comme une suite de Van Der Corput, par exemple (et qui serait certainement plus proche de la réalié).
En optique, il n'y a qu'un seul domaine où la mécanique quantique est inévitable (et encore !), c'est le domaine de la photoluminescence où tout se passe au niveau atomique.
@Francky
« Quand Bactérius dit qu'on a pu observer visuellement des phénomènes quantiques c'est totalement faux. »
Non ! Ce n'est pas faux. Les lois quantiques s'appliquent à tout et à toutes les échelles de taille, même si souvent, mais pas toujours, leurs manifestations passent inaperçues.
Par exemple la "boussole" dans le cerveau des oiseaux migrateurs, les cristaux de certains sels, et j'en passe ..!
Tu peux même rendre l'effet d'ondes de surface et de mémoire d'onde de façon macroscopique dans ta cuisine (ça te changera du chili con carne !). ^ ^
Pour la sucette, ce sera parfum caramel pour moi.
Tu sais, les Pierrot Gourmand... mdr
7 janv. 2012 à 12:15
Je n'ai pas encore mis a jour la source car je voulais que les equations de Fresnel soient correctes et je pense que j'ai reussi, les caustiques sont maintenant tres visibles et ca a l'air plus correct en general. Je dois encore faire quelques changements et mettre a jour les commentaires, refaire une capture et je mettrai la source a jour.
5 janv. 2012 à 21:45
Et, avec la mécanique quantique, on n'est même pas sûr de les retrouver un jour... lol
Tu oublies, Francky, que la mécanique quantique n'est qu'une théorie.
Perso, l'optique géométrique me suffit bien. Et elle n'a pas son pareil pour quantifier les phénomènes optiques.
Pour moi, le chat de Schrödinger qui est, selon les règles de la physique quantique, simultanément mort et vivant jusqu'à ce qu'on ouvre la boîte ne me parle pas beaucoup, j'avoue.
J'ai une méthode qui me permet de tout expliquer et calculer. Et j'en changerai pas avant longtemps !
@Bacterius
T'as oublié les effets de polarisation dans tes réflexions... :D
5 janv. 2012 à 19:43
Enfin moi, je me suis arrêté à la classe de terminale pour l'optique, sujet interessant bien qu'un peu répetitif à mon gout.
Pour en revenir à nos moutons, à savoir comment afficher de manière crédible de la lumière qui traverse une surface, je pense que la méthode utilisé n'est pas la bonne (pas taper !).
C'est pas assez efficace en terme de framerate.
Tout ça en sachant que je serai incapable de produire ce genre de code sur le sujet.
C'est d'ailleurs pour cette raison que je ne l'ai pas noté, je ne sais apprecier que son efficacité.
Voila voila.
5 janv. 2012 à 19:21
Pour clarifier les choses :
Il faut savoir que l'optique géométrique a été étudié historiquement en premier pour expliquer et quantifier des phénomènes d'optique qui était visible à l'oeil nu (Miroir, lentilles ect ect). Cette démarche empirique a conduit a une rationalisation par le biais de lois (Centre optique, foyer, indice de réfraction ect ect), rationalisation qui a permis d'arriver à de la quantification (Agrandissement d'une image,positionnement de l'image ect ect).
Beaucoup plus tard (Vers les années 1900) l'étude de la matière a débuté de facon notable : On a prouvé l'existence de l'atome, des électrons, protons, neutrons ect ect. Dans le cadre de cette étude, il a été montré qu'il y avait un lien entre matière et lumière (Corps noir ect ect) ce qui a induit la notion d'onde de matière. Les spectres de lumières admettant des raies, ont induit que l'énergie de la lumière était quantifié. Un premier modèle (Celui de lewis) a permis d'expliquer cette quantification par de pures calculs de mécanique classique (En induisant une hypothèse c'est que moment cinétique est quantifié : mvr=n*constante). Seul hic c'est que cette théorie n'expliquait pas tout et qu'elle n'était applicable qu'a l'atome d'hydrogène (En tout cas comme cela).
La notion d'onde de matière a induit l'idée que la lumiere pouvait se comporter tantot comme une onde, tantot comme une particule. D'ou l'idée de fusionner théorie de la lumiere et mécanique classique. Il en a découlé une théorie qui est la mécanique quantique basé sur 4 postulats (Par exemple tout systeme quantique est définit par un vecteur d'état |Y(t)>).
Cette théorie a permis d'expliquer beaucoup de choses et de découvrir beaucoup de choses (Imagerie médicale dont le principe est celui de la RMN).
Quand Bactérius dit qu'on a pu observer visuellement des phénomènes quantiques c'est totalement faux. En effet l'un des principes de la mécanique quantique est qu'il y a tjs une incertitude sur les mesures (Sauf si les opérateurs associés aux grandeurs mesurées, ne commutent pas : voir les inégalités d'Einsenberg). Quand Bactérius dit que l'on peut expliquer l'infiniment grand (Mécanique classique) par l'infiniment petit (Mécanique quantique) ca m'a fait hurler (désolé ^^) : En effet l'un des challenges depuis les années 1900 c'est justement de prouver que la mécanique classique est une limite de la mécanique quantique, et que de cette dernière on peut arriver à retomber sur les pattes de la mécanique classique. A moins que Bactérius soit un expert de la naza sur la théorie des champs, et qu'il a découvert un truc qui nous cache lol, c'est une grosse bétise ce que tu viens de dire.
"l y a juste une probabilite que le rayon soit absorbe et une autre probabilite que le rayon soit reflechi ou refracte" : La Bactérius tu as du louper quelques cours d'amphi ^^. Il y a pas je réfléchi, je réfracte, j'absorbe ect ect. Par exemple quand un atome absorbe une lumière, il la redistribue (C'est ce qu'on appelle le phénomène de relaxation) et si tu crois qu'il n'y a aucun lien quantique entre le phénomène d'absorption, de relaxation, de réfraction, de réflexion ect ect tu te trompes lourdement. Quand il y a réflexion, il y a absorption.
Ensuite si on ne peut remonter aux formules de Descartes par la mécanique quantique, on peut parfaitement expliquer qualitativement par la mécanique quantique ce qu'est la réflexion et réfraction, a quoi c'est du, comment ca se passe, ce qui se passe ect ect.
Par contre Bactérius n'a pas dit que des bétises :
*Si on veut étudier les spectres d'une lumiere, d'intéraction ect ect on se tournera vers la mécanique quantique.
*Par contre si on veut étudier les phénomènes de lentilles, de miroir, pour prévoir et expliquer les changements de direction pour la lumiere incidente, quantifier les phénomènes d'agrandissement, on utilisera l'optique géométrique (Car il existe aussi l'optique ondulatoire Cari ^^).
Bref ce sont deux domaines liés mais qu'on utilise pas du tout pour la meme chose.
Désolé de vous avoir monopoliser toute la nuit. A Bactérius sur tu trouves par la théorie et un programme delphi toutes les constantes d'écrantage de Slater avec un pdf pour expliquer aux gens qui n'ont pas ou peu de connaissances en mécanique quantique, je t'offre une sucette et à Cari aussi ^^
5 janv. 2012 à 19:16
En fait, la lumière emprunte toujours le chemin le plus rapide pour aller d'un point A à un point B. Ce qui explique qu'elle suivra le même chemin (le plus rapide et non le plus court) pour aller de B à A.
Quant aux caustiques, elles peuvent être dues à une réflexion ou à une réfraction. Et la plupart du temps aux deux combinées. Ce qui ne facilite pas leurs calculs !..
5 janv. 2012 à 18:15
5 janv. 2012 à 18:11
Quant aux indices, ils vont de 1 pour l'air, 1.5 pour le crown (verre ordinaire) jusque 2.4 pour le diamant. En optique, on utilise des verres d'indice 1.6 à 1.8 pour les lentilles et les prismes.
5 janv. 2012 à 17:54
5 janv. 2012 à 17:38
Je comprends Cirec quand il dit que ça devrait tourner beaucoup plus vite.
Le lancer de rayon est gourmand en calcul, on le sait... Mais là c'est trop. Il y a quelque chose qui cloche, même sans optimisation.
Quant au rendu réaliste... J’ai des doutes. En particulier pour le prisme. Je n’ai jamais vu la lumière se décomposer à l'intérieur d'un prisme (surtout une lumière diffuse comme ici). Au mieux, l’indice de réfraction est mal choisi, au pire il y a des erreurs dans les formules utilisées.
On dirait aussi que la sphère transparente est un mélange de miroir sphérique et de dioptres. C’est très troublant…
Bref, je trouve qu’il y a encore du travail.
5 janv. 2012 à 17:35
Tu va etre content Cirec, j'ai remplace le concept de spectre dans le code par du pur RGB. Le gain en vitesse est saisissant, et le code est plus simple et moins obscur. En revanche, cela veut dire que les effets optiques dependants de la longueur d'onde d'un rayon sont dorenavant impossibles (comme la dispersion et quelques autres trucs). Mais je pense que le jeu en vaut la chandelle, apres tout. La plupart du temps la dispersion de la lumiere est difficile a observer dans la vie quotidienne, la preuve: il faut un prisme ou des situations particulieres (arc-en-ciel) pour l'observer.
C'est dommage, mais bon. Au pire plus tard il sera possible de l'activer pour certaines scenes et pas d'autres...
Je vais mettre a jour la source dans quelques heures (je dois encore changer quelques trucs et mettre a jour la capture d'ecran).
5 janv. 2012 à 17:17
et moi qui croyait qu'il était parti à la Silicone Valley..
quel retour !
10/10
4 janv. 2012 à 04:49
3 janv. 2012 à 23:33
Il est vrai qu'un opticien ne s'occupe presque exclusivement que de réfraction et que les autres phénomènes sont négligés dans son enseignement... :s
Pour le problème du "coeur" réservé je te suis.
Mais, de toute façon, il est très facile de planter le système rien qu'en jouant sur les priorités de tes processus, et il n'existe aucun garde-fous. Alors "réserver" un coeur ne devrait pas mettre le système en péril, d'autant qu'il est capable de fonctionnner que sur un seul "coeur" au prix d'un ralentissement, c'est tout.
D'ailleurs, sous XP, il me semblait que le second coeur était toujours sous-exploité par Windows. Cela a peut-être changé sous Seven. Il faudra que je vérifie car j'avais abandonné cette étude lorsque j'étais encore sous XP. Il est probable qu'il y a eu de nouvelles API pour gérer cela.
J'imagine mal des machines dotées de très nombreux coeurs dont l'exploitation soit exclusivement réservé au Sheduler windows. Je peux me faire des illusions... mais comme l'espoir fait vivre... ;)
Mais, de toute façon, je suis hors sujet, là. :(
3 janv. 2012 à 22:43
En fait, ce phenomene devrait normalement etre simule en creant une scene ou chaque surface est formee de milliards de petits triangles formant des imperfections microscopiques, ce qui produirait le meme effet, mais c'est evidemment impossible de faire ca donc il faut se contenter d'une approximation (ce qui est donc fait ici via une methode probabiliste).
Et sinon l'usage de Random est utilise pour implementer une forme de roulette russe, ou chaque surface a une probabilite particuliere de refleter, refracter ou absorber un rayon (l'absorption est decidee via le spectre d'absorption de la surface, et la reflection/refraction est decidee en calculant les equations de Fresnel). L'utilisation de la roulette russe est tres importante car elle permet d'envoyer le nombre de rayons que l'on desire, alors qu'une methode plus "directe" devrait creer de plus en plus de rayons a chaque intersection, de facon exponentielle - et le resultat converge vers le bon resultat en augmentant le nombre de rayons par pixel.
"Moi, ce que j'aimerais faire c'est "réserver" un "coeur" exclusivement à un de mes Threads..."
Ah reserver un coeur entierement. C'est a priori impossible de le garantir, le scheduleur du systeme d'exploitation aura toujours le dernier mot (en effet - que se passe-t-il si ton application prend le controle de tous les coeurs, et fait un while true?). Mais je suppose que faire SetThreadAffinityMask et mettre la priorite du thread au maximum devrait donner un access quasi-total au coeur, si aucun autre thread n'a une priorite maximum. Une autre solution assez crade serait d'enumerer tous les processus, et de les empecher de tourner sur un coeur (via SetProcessAffinityMask), et de faire tourner ton thread sur ce coeur, mais c'est tres crade et possiblement sujet a des problemes de securite.
3 janv. 2012 à 22:15
- Oui, en optique quantique.
- En optique géométrique, par contre, tout est entièrement déterministe.
En général, on utilise la première pour expliquer les phénomènes, et la seconde pour les quantifier (c'est du moins ce qu'on m'a enseigné durant mes études d'optique car les deux modèles sont équivalents dans le cas de la réfraction).
C'est juste pour cette raison que je suis très étonné de voir des "Random" dans une application graphique traitant d'optique.
Je vais regarder pour "SetThreadAffinityMask", mais il me semblait que cela ne garantissait rien. Le système gardant le dernier mot.
Moi, ce que j'aimerais faire c'est "réserver" un "coeur" exclusivement à un de mes Threads...
3 janv. 2012 à 20:48
Effectivement, et d'ailleurs je ne suis pas tres content avec mon code qui traite la couleur, il faudra que je le change. Je pense qu'il devrait etre possible de reduire le spectre a probablement 100 valeurs, ca devrait etre suffisant et le gain devrait etre plus ou moins x4. Il faut que je revoie cette partie du code car elle est un peu du type "magique" (des trucs qui marchent mais qu'on ne comprend pas trop pourquoi, et je n'aime pas avoir ca dans mon code).
3 janv. 2012 à 20:45
"Pour le lancer de rayon, l'implémentation multithread est bien vue et semble bien gérée ici. Elle sous-entend cependant l'utilisation d'un processeur multiCore. Dans le cas contraire, il n'y aurait que peu d'intérêt à part permettre le multitâche."
Bien evidemment - j'ai assume que la plupart des systemes de nos jours sont multicoeurs, et on peut choisir de laisser le nombre de threads a 1 si le multitache n'est pas souhaite.
"J'aurais bien aimé trouver une gestion plus personnelle du dispatching des Threads sur les différents "coeurs". Mais je ne sais même pas si cela est possible sous Delphi et ça restera donc un de mes futurs projets d'études (si dans mes compétences, ce qui n'est pas certain)..."
Je ne comprends pas tres bien, tu veux dire forcer un thread a tourner sur un coeur particulier? C'est possible, avec SetThreadAffinityMask. Mais en general le systeme d'exploitation gere le balancage des threads sur les different coeurs tres bien tout en permettant a l'utilisateur de garder le controle (si tu forces deux threads a tourner a fond sur chaque coeur de ton processeur deux-coeurs, il est possible que le systeme plante par manque de temps CPU pendant que l'application travaille).
"Beau projet comme on aimerait en voir plus souvent, dont il ne faut retenir que l'aspect didactique pour le moment, je pense.
Bravo !"
Oui c'est purement didactique - il existe evidemment des methodes plus rapides, des implementations plus efficaces, etc... mais en general celles-ci sont cachees dans des "framework" closed-source et on peut rarement en voir le code (qui est souvent une soupe de code incomprehensible), donc des tutoriaux pure code sont parfois utiles. J'espere que cette source sera utile a certaines personnes interesses dans ce genre de domaine (raytracing, ou meme gestion de threads, etc..)
3 janv. 2012 à 20:16
Pour ce qui est des performances, je ne crois pas que c'était ton principal souci... :)
Dès le départ, tu te tires une balle dans le pied en choisissant une approche probabiliste. Perso je n'y vois pas d'intérêt; à part pouvoir arrêter le traitement à n'importe quel moment.
En tout cas cette approche ne vise pas à obtenir les meilleures performances, bien au contraire. Et j'ai du mal à comprendre ton choix...
En revanche, tu peux réduire la granularité du spectre sans crainte car l'oeil humain ne peut discerner que 300.000 couleurs différentes (dans le meilleur des cas) et environ une trentaine de niveaux de gris. Il y a de gros gains à faire de ce côté en tenant compte de la sensibilité de l'oeil qui est différente selon les longueurs d'onde (plus sensible dans le jaune que dans le bleu, par exemple...).
Pour le lancer de rayon, l'implémentation multithread est bien vue et semble bien gérée ici. Elle sous-entend cependant l'utilisation d'un processeur multiCore. Dans le cas contraire, il n'y aurait que peu d'intérêt à part permettre le multitâche.
Mais il me semble, à première vue (pour le moment, je n'ai fait que "survoler" le code), que tu laisses la gestion des "coeurs" au système.
J'aurais bien aimé trouver une gestion plus personnelle du dispatching des Threads sur les différents "coeurs". Mais je ne sais même pas si cela est possible sous Delphi et ça restera donc un de mes futurs projets d'études (si dans mes compétences, ce qui n'est pas certain)...
Beau projet comme on aimerait en voir plus souvent, dont il ne faut retenir que l'aspect didactique pour le moment, je pense.
Bravo !
3 janv. 2012 à 18:47
Mais Delphi est mon langage prefere donc voila :D
3 janv. 2012 à 18:18
Il me semble que les moteurs graphiques sont plutôt codé en C/C++ voire C# pour certains.
En tout cas, ça reste un bon exemple de méthode utilisé pour le raytracing.
3 janv. 2012 à 14:26
C'est vrai qu'au niveau programmation j'ai pas fait super attention (il y a plein de pointeurs, des appels de fonctions redondants, etc...) qui peuvent facilement tuer la performance. Je pense qu'il est possible de multiplier la vitesse par au moins 10-20 en repensant le code et faisant des optimisations code. Je n'etais pas sur si passer des objets ferait une copie memoire ou passerait juste le pointeur - maintenant je sais et on peut le changer en replaceant les pointeurs par les objets (ce que je ferai a la prochaine MAJ).
En revanche au niveau algorithmique le vrai probleme c'est que pour chaque pixel, il est nécessaire de tracer un rayon pour chaque longueur d'onde (entre 380 et 780, pour simuler le spectre visible de la lumiere), et ca c'est juste un seul sample (il en faut 200-300 pour que l'image devienne moins graineuse). En réduisant la granularité du spectre (par exemple seulement 1 rayon pour les longueurs d'onde de 400 a 404 par exemple) augmentera la vitesse de beaucoup mais l'image aura moins de couleurs. Les raytraceurs que tout le monde connait n'ont besoin que d'un seul rayon par pixel (peut-etre deux pour les ombres) ce qui les rend presque temps réel (mais l'image est moins réaliste et on manque tous les effects optiques comme les caustiques, la dispersion, etc...).
"Même sur mon vieux P4 3.2Ghz HT ça devrait tourner beaucoup plus vite que ça ... il devrait être capable de faire des milliers de passes par seconde (surtout en 32x32) ... ce qui est loin d'être le cas !!!"
Il fait des milliers de passes par secondes (probablement autour de 2 millions de rayons par seconde si tu utilises plusieurs threads et que ton P4 a plusieurs coeurs), mais chaque passe doit se produire sur toutes les longueurs d'onde pour prendre en compte toutes les couleurs. C'est pour ca qu'on a l'impression qui ne se passe pas grand chose. J'ai d'ailleurs une idee d'optimisation, en faisant quelques passes preliminaires pour decider la couleur generale du pixel, puis ne tracer que les longueurs d'onde correspondantes plus tard.
Pour le reglage du Timer, il n'est la que pour afficher les resultats bien sur. Il consomme quelques ressources ici car je l'appelle 60 fois par seconde environ pour obtenir un rendu fluide, mais le reduire fera tourner le programme un poil plus vite (genre x1.2) mais ca depend de la machine evidemment. Penses-tu que l'appeler 1 fois par seconde serait suffisant?
Il y a beaucoup de potentiel pour optimisation, je suis d'accord. Je vais d'abord m'inspirer du code que tu as poste pour les transtypages pointeurs->objets.
3 janv. 2012 à 04:33
Utiliser la carte graphique serait certainement plus rapide, mais il y a deux problemes:
- il faudrait utiliser quelque chose comme DelphiX (ou un truc plus recent) pour avoir acces a la carte graphique
- les shaders (programmes qui tournent sur la carte graphique) sont rapides car ils n'ont aucun ou tres peu de controle de flux (if, then, while, break, etc...) car la carte graphique est fondamentalement differente du CPU et par exemple effectuer un simple "break" dans une carte graphique peut etre extremement couteux. Le probleme est que le raytracing est fondamentalement nonlineaire. Donc il faudrait une carte graphique tres moderne (capable de faire du controle de flux efficace), ce qui n'est pas donne a tout le monde. Et je ne parle meme pas de la gestion de la memoire graphique.
Donc oui fait proprement ce serait surement plus rapide mais le raytracing est un probleme mal adapte a l'architecture d'une carte graphique, donc le gain en vitesse n'est pas toujours present.
Le mieux en terme de vitesse serait de paralleliser plusieurs centaines de vrais processeurs, qui eux peuvent faire du controle de flux tres efficacement, c'est d'ailleurs ce qu'Intel est en train de faire avec sa ligne de processeurs 80-coeurs a venir.
2 janv. 2012 à 22:51
Si l'image obtenue est vraiment d'une grande qualité, trop de qualité tue la qualité ^^
Ne serait-ce pas beaucoup plus rapide en utilisant les ressources materiels de la carte graphique (directX, Opengl) ?