Reprise du message précédent :
bump mapping:
http://img159.echo.cx/img159/2779/27vf.jpg
 
Lorsqu'on lit une image hdr, les flottant fournit pour rgb sont compris entre 0 et environ 1e32, mais surtout vers 0 ou surtout 1e24 a 1e32
c'est etrange

Oui c'est vraiment bizarre ton bug, peut-etre une instabilité numérique, une normale qui est partie dans les choux, une variable non initialisée ou un autre bug dans le code.
 
Pour ton problème avec les images HDR, c'est quoi ta source HDR ? Elle est bien au format RGBE ? la fonction rgbe2float n'invente rien, elle ressort ce qu'on a entré.  
 
 
 

 
grace probe est une image circulaire
pour calculer le pixels j'utilise d'après la formule sur le site:

 
j'ai codé en dur que l'image fait 1000x1000 pixels

Ourah j'ai compris pourquoi le bump marchait pas
en perturbant le vecteur normal, il arrive qu'on change le sens du vecteur, style une composante x>0 devient x<0, et ca c'est très mauvais
bon il me reste a trouver comment empecher ce phénomène

 
tu te restreins à des tous petits déplacements.
 
De toute façon si les déplacements sont trop grands l'effet de bump mapping n'est plus du tout plausible.
 

HDR : Et avec les images que j'avais fourni ça marche mieux ?
 
Malheureusement je ne controle pas tout ce qui se fait sur le web

Pour le moment je m'en sors pas avec le hdr
j'ai repris ta classe, remis data au lieu de couleur (+ compatible avec mon prog), et ca affiche une image absurde
j'ai 3x la meme image en noir et blanc sur le tiers en bas de l'écran

Par contre une petite explication plus détaillé sur ta méthode pour faire des blob me ferait très plaisir, j'ai vraiment envie d'implementer ca dans mon raytracer :-)

Wow enfin ca marche ! cubemapping HDR + bumpmapping
Yavais juste un bete bug long a trouver, sorry
J'ai un peu l'impression d etre seul sur ce topic
pourtant ya plein d'infos interessantes (par contre faut s'accrocher!)
Farib a laissé tomber?

 
Heh je m'en doutais . Je ne peux commenter que s'il y a un problème  
en rapport avec le code posté ici.
 

 
Peut-etre qu'il a des exams. Ou alors il a accepté un boulot dans une banque.
 
Sinon presque rien à voir mais en rapport avec la réécriture de mon article
j'ai fait quelques tests de rapidité et j'ai d'étranges disparités suivant
les compilos. Je suis bien d'accord que mon code est pas optimisé
mais il y a un ordre de grandeur entre ce que me sort VC++ (7)
et g++ (3.4.4), genre 22 secondes contre 2 min 30 pour une image assez
simple (ouai on est loin du temps réél hein..).
 
Ou alors c'est g++ qui est bugué ou c'est moi qui sait pas me servir
des outils Gnu (c'est possible vu que je ne l'ai jamais utilisé qu'à l'école
il y a bien longtemps). Ligne de commande classique
-O2/O3 -Wall -pedantic -ansi
 
Le pire c'est que je suis persuadé que G++ (3.2) que j'avais utilisé
au début de cet article n'était pas aussi lent avec les memes options.
Bref..

tu as essaye avec gcc4 ?

 
il était pas inclu dans la version de Cygwin que j'ai installé, c'est assez
récent non ?
 
J'essaierai quand il sera dispo, ceci dit, je ne m'attends pas à ce genre
de différence meme sans avoir la dernière version.
 
Non je pensais à une option magique qui faisait que c'est lent, genre
je compile en mode debug etc.. Je referai d'autres tests (mais c'est pas ma priorité).

Oui il est tres recent
 
 
Non le -O3 c'est toutes les optims dont gcc est capable
 
(pas de libefence, de valgrind et autre derriere ?)

j'aimerais savoir, comment on calcule le rayon refracté a partir du rayon incident? je comprend Snell Descartes, mais je trouve pas l'explication mathématique de:
 

imagine toi les deux vecteurs incident et transmis.
le vecteur incident fait un angle ThetaI avec -vNormal. Le vecteur transmis un angle ThetaT avec -vNormal.
 
Ils sont tous dans le meme plan P ce qui simplifie pas mal les choses. Le plan de la surface S est orthogonal à vNormal par définition.  
Le vecteur vI (incident) est décomposable en deux composants l'un parallèle à vNormal et l'autre perpendiculaire à vNormal. De meme pour vT (transmis).  
La partie perpendiculaire de vT et de vI sont colinéaires. le rapport entre leur normes est égale au rapport entre sinThetaT et sinThetaI (tu les mets sur un dessin en 2D tu verras que c'est assez simple, enfin c'est de la trigo..). C'est à dire que c'est le rapport entre les coéfficients de  réfraction selon la formule de Descartes.

ok j'ai compris, les fcostheta sont en valeur absolue, donc d'abord t'enleve la partie // a vNormal en incident, puis tu utiilse la loi snell descarte pour la partie perpendiculaire restante, enfin tu rajoute la partie // a vNormal en réfracté. Bien vu

Si n1*sin(theta1)/n2 >1 alors on a un rayon réfléchi, sinon on a un rayon réfléchi et un rayon transmis
dans ce 2e cas, on joue a la roulette russe pour savoir lequel des 2 rayons on va suivre?

Bon petite update, pour appel à contribution.
 
Voici une petite preview du travail que j'ai fait pendant ces derniers mois (oui je suis lent)
http://www.massal.net/article/raytrace/page1.html
 
J'aurais besoin de commentaires sur les explications, clartés des schémas ou sur d'éventuelles fautes d'orthographe (oui fatigue, plus difficultés à se relire).
 
Je suis le même plan que sur le forum mais le code n'est pas le même donc pas forcément la peine de comparer.
 
Il y a cinq épisodes, je verrai pour la mise en page et la navigation plus tard.
 
Merci d'avance.

bonjour,
 
Je développe également un raytracer open source, je trouve les articles présent ici trés intéressant. Je suis pret a donner mes sources pour les compléter si vous le souhaitez. J'ai développé des classe de model au formats différents 3ds, ms3d , ..  ainsi que des algorithme d'optimisation, octree et arbre binaire.
 
bonne continuation

salut,
 
Oui si tu veux reprendre des idées évoquées ici n'hésite pas c'est là pour ça. De meme si tu as écrit des articles sur ton raytrace n'hésite pas à mettre un lien ici.
 
De mon coté, je manque un peu de temps pour développer le raytracer donc il restera en l'état (je rajouterai la partie photon mapping sur le site web prochainement et je corrigerai en fonction des commentaires et/ou des envies du moment).
 
Voila. Je pense pas que ça puisse servir de base à un logiciel sérieux mais une intro à différents concepts de la programmation 3D.

j'avais raté cette perle
 
Sinon LeGreg je suis passé tres vite sur ton article, ça a l'air bien Pas mal de notions abordées, pas forcément spécifiques au ray-tracing d'ailleurs(forcément pas spécifiques? ). Je prendrai le temps de lire et te faire un retour. En tout cas on voit que y a du boulot  

 
Merci pour les commentaires.
 
Quant au fait que ce ne soit pas spécifique oui et non
disons que les parties spécifiques au raytracing ne sont pas forcément
les plus intéressantes (et si elles sont trop spécifiques
on ne peut pas les réutiliser par ailleurs).
 
Bon d'ici quelques jours, je posterai la partie sur le photon mapping.
Certaines personnes m'ont déjà fait remarquer que le code manquait
et pour cause: buggé et pas très présentable, ça arrivera en même temps
que l'article.

Pour ceux qui désespéraient, voici revenu le photon mapping, le source code perdu et les explications qui vont avec.
http://www.massal.net/article/raytrace/page6.html
 
J'en ai profité pour reformater deux trois trucs, corriger des erreurs qui me sont apparues depuis (il en reste..)
 
Vous noterez que j'ai précisé sur la page que c'est le dernier article de la série et vu le temps dont je dispose je ne pense pas en faire d'autre.
 
Voilà, comments welcome comme d'hab.

LeGreg> joli travail, lecture très intéressante à mille lieues de mes capacités au niveau math, mais très bien expliqué dans les principes
 
juste un souhait, peux-tu en exporter un PDF afin que cela soit imprimable ?
 
merci pour tout ceux comme moi qui sont intéressés sans avoir le bagage (et le temps nécessaire pour l'apprendre d'abord )

bah on verra pour le PDF..
 
C'est pas imprimable là ?

j'ai peur que ce soit coupé et surtout que la gestion du passage à la page soit du n'importe nawak.

bravo leGreg pour ton raytracer
 
je m'essaie actuellement à l'écriture d'un raytracer en squeak (smalltalk) dans le cadre d'un stage, et je suis assez loin de toutes tes "jolies" images (et tu as aussi un joli cv ).
 
bonne continuation
 
Jip

Bon alors une réponse en vrac, parce que ça fait longtemps que je ne suis pas passé par là    
 
Greg: il est anormal que des binaires compilés avec gcc soit plus lent qu'avec msvc7, surtout quand ça concerne les flottants parce que franchement, c'est une [censuré].
 
En 32bits sur des cpu modernes (SSE2+) la hierarchie est du genre ICC > GCC4 > MSCV7.
En 64bits, GCC4 domine sans conteste (enfin j'ai pas re-essayé avec une version non beta d'ICC 9).
 
Il n'y a rien de plus simple que de faire tourner un gcc récent sur cygwin: il suffit d'attraper un snapshot ( ftp://gcc.gnu.org/pub/gcc/snapshots/ ou mirroir) et de le recompiler.
 
Sinon pour ce qui est des articles de Jacco (avec qui j'ai travaillé) sur flipcode, ils n'ont jamais été re-actualisés quand il a implémenté une version cohérente/temps réel.
 
Enfin, et pardonnez moi si je l'ai déjà posté, j'ai bidouillé il y a qques temps de ça un raytracer en 100 affreuses lignes de C++ (sphere flake, antialiasing, ombres etc) qui est malgré tout relativement rapide.
 
http://ompf.org/ray/sphereflake/

 
Ben y'a pas quelqu'un qui a du temps à perdre et qui veut bien le faire ? Ça me permettra de mieux dormir la nuit.
 
Au boulot on est passé à msvc71, on n'utilise pas les profils SSE parce qu'on est censé
tourner sur toutes les machines mais on a quelques routines custom en assembleur (copie formatée
et quelques traitements de données).
Là je développe sur msvc8 (release candidate ?) mais pas pour compiler (peut-etre bientot).
Je crois qu'on avait évalué le compilateur Intel, mais ça posait plus de problèmes pour pas de gain en pratique.
En plus en ce moment j'ai 7 PCs dans mon cube (il n'y en a que cinq en marche) et  
ils tournent tous avec un processeur amd.
 
Sur ICC il y a aussi des trucs marrants :
http://yro.slashdot.org/comments.p [...] d=13042922

Oui, j'ai trouvé moi aussi que rapporter des bugs durant la beta d'ICC 9.x 64bit était une perte de temps.
 
Je n'ai que des proc AMD sous la main (opteron notament) et il est clair qu'ICC/Intel met déliberement des batons dans les roues.
Mais c'est assez simple a circonvenir, il suffit d'éviter l'émission de code multiple + selection au run time par le compilo.
 
Les intrinsics sont chaudement recommandées car elles genent bcp moins le compilo que de l'asm inline.
Evidement la portabilité est proche de 0.

Alors voila je prend peut etre le coche en retard. Ce qui se ttrouve si dessus c'est pour l'antialiasing (supersampling si j'ai bien compris...).
Ca tourne pas un peu en rond? toutes les variables sont locales. on fait rien de particulier là a part du calcul?

 
Tu n'as qu'à vérifier le résultat avant et après l'application du supersampling et voir si tu obtiens la même chose .

Bonjour à tous, et un grand merci à LeGreg pour son précieu tutoriel sur le raytracing
 
J'ai moi même commencé un raytracer il y'a 3 ans, mais le manque de temps et le code qui devenait de plus en plus intenable ne me poussa pas à continuer l'aventure plus loin.
 
Un exemple de rendu avec ce raytracer :
 
http://geffd.free.fr/Coding/Ray6.jpg
 
(Il y'a une texture acide calculée via un bruit de perlin)
 
Cet été, j'ai remis ca, mon but était de coder un raytracer objets avec une interface utilisateur sympa, voici quelques écrans :
 
(La plupart des images sont calculées avec une précision de 20% (à cause de mon manque de patience face au calcul des scènes ) donc ca pixellise pas mal, mais ca vous donne une bonne idée )
 
 
Une piscine avec une normale calculée à partir d'un bruit de perlin de type turbulence pour la surface de l'eau
 

 
Même chose sous un autre angle :
 

 
J'ai intégré un début de photon mapping, avec la possibilité de voir les "impactes" de photon sur les surfaces dans la représentation du haut :
 
Normalement, dans cette scène la sphère de gauche est réfléchissante et celle de droite réfractante, mais ce qui m'intéressait là était le rendu des caustiques et des ombres, donc j'ai désactivé ces deux options pour avoir un rendu plus rapide
 

 

 
Le rendu de photon mapping ne me convient pas encore, il faut que je règle la méthode de mélanges des couleurs, car la ca fait encore un peu "playskool"
 
Une jolie sphère transparente avec une texture procédurale pour modifier la normale, avec un peu de photon mapping, le tout calculé par 2 ordinateurs simultanément :
 

 
 
Sur cette dernière image, vous pouvez voir une différence entre le haut de l'image et le bas, car je venais d'introduire un principe de 'cluster', qui permet à l'application d'avoir un fonctionnement client / serveur, afin de répartir le calcul d'une scène sur plusieur ordinateurs, chose qui est très appréciable je vous l'assure
 
Donc il suffit de mettre le logiciel en mode serveur ou client dans l'onglet serveur de l'application, et la scène est alors transmise du serveur vers tous les clients indiqués pour etre calculées.
 
Toutes les textures sont passées à travers le réseau, un chiffre déterminée aléatoirement est également transmis pour initialiser le générateur de nombre pseudos aléatoires de la même façon, avec la même séquence, afin d'avoir exactement la même répartition des photons pour tous les PC, c'est justement ce qui causait ce problème de différence de ton entre l'image générée par 2 PC différent : les photons n'étaient pas disperssés exactement de la même façon.
 
Voici le menu Réseau (à améliorer) :
 

 
Voici la liste des propriétés modifiables pour un objet de type sphère :
 

 
Je vais très certainement intégrer par la suite un éditeur de matériaux, ainsi qu'un importeur de fichiers obj (facettés, que l'on peut exporter via blender par exemple).
Une autre technique intéressante selon moi est l'"ambiant occlusing", généralement utilisée dans les scènes facettées, mais qui a sa palce dans le raytracing également.
 

 
J'ai implémenté cette technique qui en théorie est plutôt enthousiasmante, mais qui en réalité provoque des tâches horizontales :
 

 
voici le bout de code qui détermine cet ambiant occlusing en un point :
 

 
A mon avis, le problème viens du fait que je passe par une fonction aléatoire pour déterminer les vecteurs, voici la formule de la fonction qui retourne un vecteur aléatoire :
 

 
A mon avis, si j'arrive à distribuer les vecteur d'une manière uniforme le tour sera joué
En distribuant dans le sens d'une spirale par exemple, mais malheureusement, mais notions de maths sont trop élémentaires pour arriver à distribuer ces points dans un plan incliné (perpendiculaire à la normale, donc tangent à la surface au point d'intersection)
 
Voila, j'attends vos idées
 
D'ailleurs j'y pense, ce système peut servir aussi à faire de l'interréflexion (les objets déposent de leur couleur sur les surfaces qui leur sont proches) , et peut etre même des tâches caustiques à réfléchir donc
 
Vous pouvez voir l'ensemble des images rendues pour l'instant ici :
 
http://geffd.free.fr/Coding/Raytracer2006/
 
Je diffuserait très certainement le code source, développé en C# 2.0 via Visual C# Express 2005, donc accessible à tous gratuitement, je ne sais pas si il compile avec mono, mais ca devrait passer je pense, donc très certainement compatible linux également.
Je l'ai exécuté sur une machine n'ayant que le framework .net 3.0, ca fonctionne bien également et même plus vite j'ai l'impression
 
Donc je continue mon chemin et espère bien avoir des images ayant la qualité de celles de LeGreg rapidement
Pour info, il y'a un raytracer bien codé et avec une doc PDF (en Français) très très bonne sur les illuminations indirectes :
 
Picasso Raytracer :  
 
http://membres.lycos.fr/nicoschmit [...] =RayTracer
 
A bientôt tout le monde

/Rant on
Eh les gars, vous n'etes pas obligé de poster pour mettre un drapeau, hein..
Il y a un bouton en haut à droite qui dit : "activer la notification par email sur ce sujet"..
/Rant off
 
Merci !
LeGreg

Tout d'abord merci à LeGreg pour ce superbe tutorial.
 
Voilà, je m'interresse plus particulièrement au photon mapping et je me demande si il était envisagable d'avoir un algo de rendu basé uniquement sur le photon mapping?
 
L'écran/oeil devient alors un objet de la scène. On lance les photons depuis les différentes sources de lumières et on ne s'interessent qu'à ceux venant frappé l'écran et on calcule le rendu en ne se basant que sur ces photons.
 
Voilà, est-ce que c'est n'importe quoi ou alors est-ce que c'est réalisable?

si je suis bien ce que tu décris, je crois que le raisonnement est incorrect.
 
si tu ne t'intéresses qu'aux rayons frappant ton oeil, tu vas perdre la grande majorité des rayons qui "peignent" la scène de manière générale.
 
imagine une lampe torche à gauche qui frappe une sphère métallique à droite. les seuls rayons qui t'intéresserait seraient ceux qui quittent la lampe, rebondissent sur la sphère et qui arrivent à ton oeil.
 
mais tu perds tous les autres rayons qui vont éclairer le sol, les murs... et pourtant, ils n'arriveront sans doute jamais à ton oeil.  
 
sans compter que tu vas augmenter très fortement le bruit dans ta scène

 
si on voit un point de la scène, c'est qu'un rayon venant de ce point a frappé notre oeil, me trompe-je?

Update :  
Les articles ont été remis à jours et sont disponibles sur mon site web:
 
premiers pas:
http://www.massal.net/article/raytrace/page1.html
éclairage spéculaire (blinn-phong), post processing et antialiasing:
http://www.massal.net/article/raytrace/page2.html
textures (Perlin noise, cubic environment mapping, bump mapping)
http://www.massal.net/article/raytrace/page3.html
Flou (depth of field), Fresnel, blobs (isosurfaces):
http://www.massal.net/article/raytrace/page4.html
HDR, loi de beer, aberration chromatique:
http://www.massal.net/article/raytrace/page5.html
Global ilumination, photon mapping:
http://www.massal.net/article/raytrace/page6.html  
 
Le code et les commentaires y sont plus récents. Vous pouvez continuer à utiliser ce topic pour les questions
et commentaires.
 
Voilà, si vous voulez l'historique du sujet, vous pouvez continuer à lire la suite.
Fin de l'Update  
 
oui c'est faisable (forward tracing) et l'on pourrait dire que c'est ce qui se passe naturellement dans le monde réel (si l'on simule le déplacement des photons), mais peu intéressant, enfin de mon point de vue.
Bien entendu tout faire depuis le point de vue de l'utilisateur (backward tracing) a ses inconvénients aussi,
le photon mapping est donc un compromis assez efficace entre les deux (en fait la version présentée est
assez rustre, il est possible d'améliorer les choses avec une passe de final gathering).
 
LeGreg