Reprise du message précédent :
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  
 

 
tu as du t'emmeler dans le sens (et la signification) de tes vecteurs..

propre et simple. il ne faut rien de plus pour habiller un algo
 
edit: j'ajouterais cependant un label mentionnant le temps mis pour créer l'image histoire de pouvoir comparer les différentes méthodes.

ouais, ouais, enfin je fais surtout ça pour apprendre.
 
Par contre, j'en arrive à la réflexion suivante : les GUI sassert à rien
 
là ca fait 15 jours que je suis dessus, me faudra sans doute 15 jours pour rendre le truc entièrement blindé et fignolé, et y'aura que les premieres notions de raytracing
 
ma conclusion : font chier les ***** de users à pas aimer éditer des fichiers texte

je me demande si y'a des optimisations à faire genre à un endroit comme ici
 

 
 
la premiere double boucle, c'est pour les pixels, la 2e, pour l'antialias.
 
supponsons que je fasse donc un test pour dessiner avec ou sans antialias.
 

 
 
ça rajoutera 640*480 tests, qu'on pourait sauter en faisant "2 fois" ce code, un avec antialias, un sans.
 
 
ou bien c'est dérisoire par rapport au cout de calcul général ? (enfin je suis en train de penser que c'est le cas)
 
ou toute optimisation est bonne à prendre.

je n'ai pas analysé le code de LeGreg mais il a dit qques pages plus tôt que son code avait des fins éducatives et donc pas nécessairement optimisé ni fouilli.
 
c'est p-ê ça...

le coût du if( antialias ) par pixel devant le côut de la récusions de calculs d'intersections est assez faible.
 
mais le mieux serait de faire une fonction qui accepte en paramètre le vecteur de vue d'un pixel.
 
ce qui permetterait d'une part d'avoir quelque chose de réutilisable (générateur de normal map pour un modèle low poly à partir du même modèle high poly), de plus propre, de plus réorganisable, du style:
 
if( antialias )
{
  for( y
    for( x
      for( fragx
         for( fragy  
         {
            RayTrace(....
         }
}
else
{
  for( y
      for( x
         RayTrace( ...
}
 
bref, éclate son code en sous-fonctions, ce qui te permetera de faire des trucs plus marrants, et de voir plus clair pour mieux optimiser.

 
disons que je cherche pas à optimiser mais plutot à débourriner

 
??

sinon pour ce qui est de ta question:  
si tu avais lu toute la série d'articles
tu saurais la solution que j'ai adopté pour un supersampling variable.
(conclusion: pourquoi est-ce que tu ne commences pas par là ?)
 
Et pour ce qui est du cout d'une modification de code je ne saurais trop te recommander une commande qui s'appelle "time".
 
man time
http://www.rt.com/man/time.1.html

 
je cherche à utiliser ton code en le modifiant le moins possible pour qu'il reste le plus fidèle à ce que tu as écrit.
 
Par contre, en combinant les différentes formes d'effet, je rajoute des tests supplémentaires, sur lesquels je me pose des questions sur le cout induit.
 
Oui, t'as peut-être fait quelque chose sur le supersampling variable, mais moi hein je vais pas vite

Hey tlm salut greg bon moi chu un nioub ^^ pr linstant japprends le c mais j'ai fait un copier coller de ton source et sous visual C++ y me met ke ya une erreur... c pa moi ké di c mon compilateur En tt cas je trouve ça très bo et g hâte de savoir faire ttes ces belles choses =)

Putain ca m'troue le cul !  

(par contre y'a pas un petit bug entre la boule rose et la rouge ? le reflet de la rose dans la rouge à l'ai coupé)
 
enfin il est tard mon cerveau est déjà dans la purée

bon j'ai lu le thread super vite, et cela me sidère que l'on puisse écrire un raytracer en si peu de ligne
 
Juste comme ça, est-il possible de facilement le transformer en lancer de rayon avec la méthode de montécarlo  (orth?) ? En gros, les surfaces ne sont plus des mirroirs mais renvois la lumière dans toutes les directions comme c'est impossible de tout faire, on tire au hasard les rayons à calculer.

Tu dois modifier le code de lecture dans la cubemap
pour lire le sample correspondant du filtre bilinéaire dans le bon carré. Ou alors pour limiter l'effet clamper le sampling strictement à l'intérieur du carré (centroid sampling)
 
Si ça se trouve je l'ai déjà fait dans les versions suivantes. Enfin je ne m'en souviens plus trop et j'ai pas le code sous les yeux.

 
oui c'est possible de faire Monte Carlo.
 
Le code (pas au début mais plus loin dans le topic) utilise les techniques stochastiques pour limiter le nombre de rayons et c'est l'idée qui sous tend Monte Carlo. Mais comme tout méthode purement statistique ça rajoute du bruit (le nombre de tirage a effectuer est souvent plus important que ce que tu veux passer comme temps à calculer une simple image). On peut réduire le bruit et le temps de calcul en utilisant des heuristiques basées sur l'importance des samples sur l'image finale (c'est aussi développé un peu plus loin meme si c'est très basique pour l'exemple).
 
Le photon mapping agit comme un cache pour accelerer ces calculs.
 
Par contre si tu fais un vrai miroir, tu n'as pas à envoyer plusieurs samples. Un miroir réaliste renvoie les rayons lumineux dans une seule direction (c'est le cas de la reflexion sur l'eau ou toute autre surface plane).

 
en fait c'est ça, c'est présent dans tes premiers rendus avec la méthode repeat/modulo, et ça s'en va avec la méthode min-max
 
t'aurais des liens vers des explications concrètes dans la méthode d'application de la cubemap ? ( et qui t'auraient inspiré, à moins que tu n'ai tout inventé tout seul )
 
j'ai trouvé ça
http://www.opengl.org/resources/tu [...] de180.html
et ça
http://ct.radiology.uiowa.edu/~jia [...] ode67.html
(un peu d'explication sur l'interpolation bilinéaire)
 
mais je peine à faire le lien ( genre le role de umin/vcoef etc...)

 
nan j'ai pas inventé la cubemap
mais le code est lui meme est pas très compliqué.
 
Tu as un rayon qui a une certaine direction. Cette direction définit un unique point à l'infini. La cubemap c'est juste une manière de représenter facilement la totalité des directions possibles.
 
Tu n'as qu'à t'imaginer être au centre d'un cube géant. Tu vas lancer un rayon dans une certaine direction et il va intersecter le cube.
 
La fonction de texturing depuis le cube fait juste ça: calculer l'intersection entre un rayon et un cube imaginaire. Tu as six cas possibles, un pour chaque face du cube. Une fois la face déterminée tu vas calculer précisément quel texel tu dois lire pour une direction donnée. C'est de la triangulation tout ce qu'il y a de simple.
Comme le rayon ne tombe jamais précisemment sur un texel, usuellement il tombe entre quatre de ces texels, tu vas donc faire une interpolation linéaire entre les quatre couleurs pour déterminer la couleur intermédiaire. La encore rien de bien sorcier.

ça j'ai compris mais c'est au niveau du readcubemap
 
 
on a (u,v) qui correspond aux coordonnées sur la texture en coordonnées [-1,1]x[-1,1], qu'ont ramène en [0-512]x[0-512] avant de faire l'interpolation
 
je comprend pas pourquoi on fait un
 

qui nous symétrise le tout
 
 
avec ma logique tordue, j'ai fait pour tester un

qui évidemment donne un résultat qui ne correspond à rien mais c'est ce que j'aurais vu comme transformations des coordonnées [-1,1] vers [0,512]
 
j'ai du louper qq chose dans l'histoire.

ouin...
 
a partir de la profondeur de champ, il manque des headers  

 
Quels headers manque-t-il ?
 
J'ai du poster le source complet un peu plus loin, tu l'as téléchargé ?

hum, en effet, j'ai du me chier dans mes grep

tres interessant ce topic! merci LeGreg
si ca interese des gens, voila un lien vers un article et un scipt de raytracing en Perl:
http://perl.plover.com/RayTracer/
evidement c'est du raytracing tres "basique", mais ca peut faire une petite introduction

boh, c'est mort

J'ai compilé le code de la première page avec gcc. J'obtien cette image ! savez vous d'ou peut venir le probleme ?
 

c'est très joli !
 
Essaie de comparer tes sources avec ceux qui ont été postés au format Zip un peu plus loin. Est-ce qu'il y a des différences ?

huhu c'est original.
 
il doit y avoir une variable qui est pas réinitialisée le long d'une ligne horizontale. ou un décalage sur les accès aux propriétées des sphères. (le test rayon/sphère est bon, mais le bouzin accède à la mauvaise sphère pour obtenir les propriétées de surface)
 

 
comme j'aime pas les langages où il faut mettre des $ ou autre devant les variables

saimoooort

 
ben non !

maissi

mé non

ah bjone...

 
oui c'est ça d'accord t'as raison ... je dois avoir un browser magique ...

Question !
 
Pourquoi est-ce qu'un rendu qui utilise radiosité+photon maps est-il plus "réaliste" qu'un rendu qui n'utilise que les photon-maps ?  
 
Est-ce parce qu'il existe des échanges de lumière liés d'une part à la lumière ambiante, et d'autre part à la lumière diffuse, les 2 technologies travaillant de façon différente?  
 
De façon naïve, je me suis dis que toute lumière qui arrive à un point vient d'une source de lumière (de façon directe ou pas), et donc doit être simulé par photon-maps. Or, ce n'est pas le cas... Sous pov-ray, le résultat est beaucoup plus probant si j'utilise les 2 techniques.

 
Tout simplement parce que les deux techniques ne simulent pas les mêmes effets.  
 
Parler d'unification des méthodes de lighting est encore un peu prématuré..

hum, j'aimerais bien continuer à coder un peu. J'ai fini (et compris) la première page mais là je commence à décrocher, le code devient complexe avec la profondeur de champ
 
(je veux dire retrouver l'effet dans le code, qui mixe tous les effets)

 
la profondeur de champ n'est pas mélangée au reste du code !
contrairement aux autres composantes elle est simplement contenue dans ces quelques lignes:
 

 
Bon je suis désolé du côté haqueux du truc, qui fait que le code est ridiculement simple.
 
A la rigueur essaie de tracer un dessin avec les différents vecteurs (fais le en 2D vu que c'est le meme probleme qu'en 3D) normalement une fois que tu traces sur une feuille, le point cible, le rayon effectif, les rayons "virtuels", etc.. tu devrais y voir plus clair. C'est que de la géométrie.
 
LeGreg

 
Salut,  
Connaitrais tu un équivalent de ce livre en francais ?
J'ai fais des recherches sur amazon et alapage, mais je n'ai pas trouvé ce livre =/
merci

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  
 

 
A ma connaissance, il n'a pas de traduction française et n'a pas d'equivalents autre qu'en anglais.
 
C'est le cas de nombreux bouquins malheureusement et meme les auteurs français publient en anglais.