Reprise du message précédent :

 
ray est une classe/structure (pas regardé les headers) qui embarque les attributs d'un rayon:  
position (point de départ)
et vecteur de direction
 
sphere embarque la position et le rayon d'une sphère
 
t est la dernière distance de connue, et sert à retourner la distance de contact si elle est plus courte.
 
 
à froid:
 
http://site.voila.fr/bjone/hitsphere.png
 
pour un rayon de point initial P de vecteur directeur V
une sphere S de centre C et de rayon R
 
soit "dist" le vecteur de P->C
 
soit B la distance de "dist" projeté sur le vecteur unitaire V
avec C projeté en C'
 
// vecteur dist = s.pos - r.start;
// float B = r.dir * dist;  
 
soit I l'intersection recherchée, positionné tel que I=P+V*(B-D)
soit L la distance |C C'|
la distance |I C| c'est R
 
on a deux triangles rectangles P C C' (rectangle en C')
et I C C' (rectangle en C')
 
dans I C C':
R² = D² + L²
D est recherché
 
D² = R² - L²
 
L fait chier
 
dans P C C'
 
dist² = B² + L²
L² = dist² - B²
 
on regroupe
 
D² = R² - dist² + B²
 
// float D = B*B - dist * dist + s.size * s.size;
 
 
je te up le shéma

niveau 3ième.
 
tu fais Doom avec le bac.... hein (au niveau des maths j'entends)

j'ai raisonné en 2D, mais ça reste valide en 3D.

je suis d'accord, en 2d, c'est facile, mais en 3D, c'est pas du tout si évident que "ca reste valide", même si c'est le cas

enfin si faut raisonner en 2D c'est facile, mais je veux mon théorème qui me dit que quand je rajoute une dimension à mon espace vectoriel  mon raisonnement est toujours valable

bin si tu cherches à visualiser le rayon, le point d'intersection, le centre de sphère, tout ce petit monde tiens sur un plan 3D, et après tu peux raisonner en 2D dans ce plan 3D.

remarque, les opérations qu'on effectue peuvent être facilement adaptées à la dimension n, donc ça se tient.

 
t'es po casse couilles comme gars  
selon le théorème de BJOne: "si ça marche toujours tu fais po chier"
 
nan, la démonstration complète, t'es gentil j'ai vraiment po fait X

wai c'est ça, bien vu
 
mais t'abuse en disant que c'est niveau 3e parce que en 3e j'étais encore premier de classe dans un bon lycée parisien, donc ça veut dire que je serais déja en train de devenir gâteux

 
vi passke en 2D/3D c'est toujours des produits scalaires/produits vectoriels et une notion de distance.

 
perso, je pense avoir presque perdu, hormis les notions, ce que j'ai appris en maths/physique au bac electronique.

 
je comprend parfaitement ces instruction, mais j'ai du mal à apprécier leur substantifique moelle :
 
tout ça pour écrire un vecteur normal de norme 1 ?
on pouvait pas l'écrire de manière plus concise ?

c'est pas à moi qui faut dire ça
 
faut croire que sa classe vecteur a pas de .normalize()
 
j'adore le;
temp = 1.0f / sqrtf(temp);
n = temp * n;
 
   
 
bon allez, on le pardonnera il a fait ça en retrant du taf  

sinon derniere remarque avant le dodo, le tga ça a l'air super simple, et lui il l'écrit de facon très facile j'ai l'impression
 
tandis que là je regarde les sources du décodeur tga de paintlib, et j'ai l'impression que des fois, le C++, quand on fait des objets à outrance, bein des fois ça rend plus compliqué à essayer de comprendre ( utiliser une classe, c'est facile, comprendre comment fonctionne une classe, c'est toujours le bordel)

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  
 
il n'y a pas de classe vecteur
et normalize quand la norme est nulle je fais comment ?
je balance une exception ? (j'en entends qui me crient "OUI!" dans l'oreille )
 
Pour des raisons de compréhension ce code est débarrassé le plus possible de comportement "cachés" comme des mécanisme d'exceptions, des opérations implicites ou des temporaires non nommées etc...

 
j'ose pas imaginer ton code avec des comportements cachees, je me suicide    

 
oui mais s'il faut choisir entre faire un cours de math et un topic sur le raytracing j'ai choisi la deuxieme voie
 
pour la résolution du rayon sphère:
tu paramétrises ta droite orientée par t, la distance parcourue.
Tu définis les deux points d'intersection avec la sphère comme les points ou les (x(t),y(t),z(t)) résolvent ton équations de sphère ((x-x0)*(x-x0)+(y-y0)*(y-y0)+(z-z0)*(z-z0) = R*R)
 
Tu remplaces les x, y, z par leurs versions paramétrées
et le résultat c'est une équation du second degré en t que tu as appris à résoudre en première ou en terminale.
 
C'est bon ? a priori meme pas besoin de faire de schéma ça marche aussi bien en dimension deux (intersection droite/cercle) qu'en dimension quatre (intersection droite/hypersphère).

haaa moi j'ai les fusibles qui petent si on dépasse 3 dimensions

 
le principe du raytracing c'est un jeu de piste.
 
Tu pars d'une direction, tu vas tout droit jusqu'à ce que tu heurtes quelque chose. La couleur en ce point de collision va dépendre de plusieurs choses, sur certaines surfaces c'est la couleur réflechie qui est la plus importante tu vas donc suivre le chemin de la lumière à rebours pour chaque réflexion ou chaque changement de direction de la lumière. Jusqu'à arriver à la source de cette lumière.
 
C'est du reverse tracing parce que tu suis le chemin inverse de la lumière. Mais c'est malheureusement très éloigné de la complexité du chemin réel de la lumière. Mon modele à moi il est strictement linéaire et les branchements sont simulés avec des jets de dés. En pratique il est impossible de suivre tous les chemins possibles parce qu'il y en a une infinité (le nombre de chemins n'est pas non plus "dénombrable" pour ceux qui connaissent cette notion).
 
Dans la derniere partie je combine donc forward tracing de la lumière (envoyer les photons et les suivre dans la scène) pour simuler les ombres, les interreflexions et les caustiques et le reverse tracing depuis le point de vue de la caméra pour simuler la réflexion, la réfraction, et l'illumination directe.
 
Il y a deux effets que tu dois combattre: le premier c'est que si tu envoies deux rayons très proches, les calculs d'illumination seront probablement très proches pour ces deux rayons, c'est pour ça que l'on utilise le photon tracing qui "cache" les calculs d'éclairage dans un buffer "spatial". Le deuxième c'est que si tu reposes trop sur ce cache pour calculer l'éclairage de deux points voisins, tu ne vas pas pouvoir simuler correctement les microvariations qui vont faire de grandes différences dans la couleur finale des deux points voisins. Par exemple si un rayon tombe dans l'ombre et l'autre tombe dans la lumière, s'ils sont trop voisins et que tu ne calcules pas l'éclairage de manière distincte tu n'auras pas ce genre de nuance.
 
Mais bon le raytracing de base reste tout de meme très simple à comprendre.

à chaque fois que je passe par ici, et même si je ne code pas de raytracer, j'en ressort vachement moins con. merci LeGreg

merci greg

je comprend pas le
 
 
  if ( n * dist <= 0.0f )
      continue;
 
je comprend pas le critere "produit scalaire vecteur normal x vecteur distance = négatif
 
 
edit : si j'ai compris

comprend pas ça
 

y'a qu'a juste tester si dist nul ???

 
il n'y a pas besoin de calculer l'éclairage si la lumière est à l'opposé de la surface visible. Les points qui ne sont pas face à la lumière sont dans l'ombre.
 

 
Ben oui c'est équivalent.

ok, bon c'est juste tes méthodes pour rendre "unitaires" les vecteurs qui me troublent.
(tant qu'a faire, t'aurais pu faire un ptit opérateur ou fonction norme)
 
 
bon, j'ai presque tout compris la "première ébauche".
 
Si je prend un vrai raytracer, genre pov-ray
 
*hormis le fait qu'il faille appliquer les algorithmes à n'importe quels formes géométriques
 
*hormis le fait que certaines notions sont trop simplifiées, lambert, comme tu y fais allusion
 
ce sont bien des vrais "algos" utilisées par un vrai moteur de raytracing
 
je serais bien chaud pour faire un beau document tex de tout ça ( avec explications géométriques, etc... ) ( enfin dans un certain délai)
 
license des codes et documentations ?

je dirais soit un problème calculatoire en virgule flottante, soit y'a un reset de distance qui est pas fait.
 
soit tu t'es chié sur le code de réflection...

 
 
en fait c'était le code pour la lecture/construction des matériaux qui avait évolué, j'ai correctement rectifié le bouzin, ça lisait mal le fichier scene, etc...

ca correspond à quoi l'opération de multiplication de deux couleurs entre elles ?

cad ?

inline couleur operator * (const couleur&c1, const couleur &c2 ) {
        couleur c = {c1.red * c2.red, c1.green * c2.green,  
   c1.blue * c2.blue};
        return c;
}

du latex

(sans, le plaisir est encore plus fort)
 
-->[]

 
Ça dépend. Ici j'appelerai ça "transmission" (la première couleur agit comme un filtre de transmission partielle sur la seconde et vice et versa).
 
En 3d dans le fixed pipeline ils appelleraient ça "modulation". (c'est le meme nom qui est utilisé dans Photoshop pour l'opérateur de multiplication des calques ou dans les opérations binaires sur les images)
 
En pratique je sais pas si on en a grand chose à faire comment ça s'appelle

 
L'intensité c'est sa couleur. Ces deux notions sont confondues.
 

qu'est-ce qui différentie le phare de saint nazaire de ma lampe de poche ?

bah c'est pour moi, j'aimerais quand même un peu comprendre à quoi ça correspond

non, d'abord, tu calcules la couleur résultante (couleur lumière * couleur matériau : couleur fixe ou issue de texture)
 
ensuite tu calcule ton intensitée en fonction de la puissance émise et de la distance....
 
enfin je dirais ça comme ça...

bon, ça avance, doucement
 
http://f.desoras.free.fr/raytracer.pdf
 
je sais pas si c'est clair, si ça explique quelque chose, et si ça servira à d'autres personnes que moi, mais en tout cas moi ça me permet de comprendre ( j'ai presque tout capté dans hitsphere , j'ai pas fait polytechnique , mais après avoir tapé mes 4 pages, ça a fini par rentrer)

@ farib
 
[HS]
Comment tu formattes le code avec LaTeX ?
[/HS]

\begin{listing}[pas de numérotation]{début de numérotation}
\end{listing}
 
\listinginput[pas de numérotation]{début de numérotation}{fichier source}
 
bon j'ai mis à jour mon ptit document
 
25 pages rien que sur le premier post DuGreg et le raytracer de base
 
bref, c'est pas facile facile tout ça.
 
LeGreg : pour les opérations sur les couleurs, multiplication/addition des composantes RGB, tu savais ça par ta culture générale, ou tu as vu un document qui pourrait éventuellement m'expliquer le pourquoi du comment ?
 
(en fait, si tu avais les docs qui t'ont servi à faire tes programmes )

Ça dépend.. tu as quel niveau ?
 
Sinon Google ça marche : Phong, Lambert, Blinn, BRDF, Ken Perlin, Henrik Wann Jensen, loi de Beer, loi de Descartes, etc.

il y a deux choses:
 
l'équation de phong: qui donne le spéculaire en fonction du scalaire entre le vecteur de lumière réfléchi par rapport à la normale, et le vecteur de vue (mis à une puissance, etc...)
 
vecteur_reflet_lumière = reflet( vecteur_lumière, vecteur_normal )
// lire "on obtient le vecteur_lumière réfléchi par rapport au vecteur_normal de la surface"
 
coefficient_spéculaire = scalaire( vecteur_reflet_lumière, vecteur_vue)^exposant
 
couleur_spéculaire = couleur_spec_reférence * coefficient_spéculaire
// couleur_spéculaire et couleur_spec_référence sont des "vecteurs" (ie 3 ou 4 composantes RVB/ARVB)
// coefficient_spéculaire est un scalaire (1 seule grandeur qui va moduler toutes les composantes)
 
----------
 
l'équation de blinn:  
 
qui donne le spéculaire en fonction du scalaire entre le vecteur normal, et le vecteur dit "half-way" qui est le vecteur "moyen" entre le vecteur de vue et le vecteur de lumière (donc la somme des deux, divisé par deux)
 
vecteur_half_way = ( vecteur_vue + vecteur_lumière ) / 2
/// avec vecteur_vue et vecteur_lumière normalisés (norme/longueur=1)
 
coefficient_spéculaire = scalaire( vecteur_normal, vecteur_half_way)^exposant