[à voir] Le futur de la 3D : le raytracing en temps réel ?

Le futur de la 3D : le raytracing en temps réel ? [à voir] - Carte graphique - Hardware

Marsh Posté le 25-04-2003 à 17:11:32    

Bon, autant le dire tout de suite, c pas franchement à portée des machines actuelles (du moins dans les hautes résolutions), mais il est vrai que c assez impressionnant [:wam]
 
-> www.realstorm.de
 
D'apres les dires de ces ptits gars (Federation Against Nature, des demomakers qu'ils sont bien ;) ), au-delà d'un certain niveau de détail (le pixel), le rendu basé sur des polygones n'a plus lieu d'être ...
 
des liens :
Nature Suxx : http://www.realstorm.de/naturesuxx.zip
Nature Still Suxx: http://www.realstorm.de/naturestillsuxx_fan.zip
Still Sucking Nature (tout nouvo tout cho !) : http://www.realstorm.de/STILLSUCKINGNATURE_FAN.zip
 
ya même un benchmark !! qui vaut le coup d'oeil :
http://www.realstorm.de/data/RealStormBench.exe
 
Qq shots :
http://www.realstorm.de/data/SSN_02.jpg
http://www.realstorm.de/data/SSN_06.jpg
http://www.realstorm.de/data/021205_ShadowTest3.jpg
http://www.realstorm.de/data/SSN_01.jpg
 
En tout cas, sur ma config, ca tourne déjà bien en 640x480 (100% pure software rendering)... et comme la puissance des procs augmente sans cesse ...
 
bref... c mon message d'info du jour :D


---------------
::Mind is a terrible thing to taste::
Reply

Marsh Posté le 25-04-2003 à 17:11:32   

Reply

Marsh Posté le 25-04-2003 à 17:18:56    

Si ca t'interesse, il y un thread sur les différentes techniques de rendu de l'ombre sur B3D. De nombreux développeur ne pense pas voir de raytracing en temps réél avant un long moment (certains disent meme jamais :D)
 
http://www.beyond3d.com/forum/viewtopic.php?t=5491


---------------
But if they think they're going to hold onto it, they're smoking something hallucinogenic - Jen-Hsun Huang
Reply

Marsh Posté le 25-04-2003 à 17:18:57    

toutafé, mais le raytraçing est toujours plus couteux que du rendu polygonal classique.
 
on verra dans quelques années comment les choses évolueront...

Reply

Marsh Posté le 25-04-2003 à 17:22:30    

BJOne a écrit :

toutafé, mais le raytraçing est toujours plus couteux que du rendu polygonal classique.
 
on verra dans quelques années comment les choses évolueront...


 
(il semblerais que) pour l'instant le rendu passe completement par le proc.. je me demande si yaurais pas moyen d'utiliser la puissance de la CG pour alléger certains calculs (T&L ??)...
 
sauf que je sais même pas si c possible [:ddr555]


---------------
::Mind is a terrible thing to taste::
Reply

Marsh Posté le 25-04-2003 à 17:23:45    

en tout cas certains travaillent déjà sur une API spéciale pour le RTRT (realtime raytracing) : http://www.openrt.de
 
http://www.openrt.de/Gallery/2002_DynamicRayTracing/Images/teas_kitchen1.jpg


---------------
::Mind is a terrible thing to taste::
Reply

Marsh Posté le 25-04-2003 à 17:26:42    

Le raytracing est moins couteux en BP mémoire que le rendu 3D traditionnel. De plus il est indépendant de la complexité géométrique de la scène.
Cette méthode de rendu devient de + en plus interessante mais le changement de standard 3D entrainera un changement de carte 3D.
C'est cela qui risque d'être difficile et long. Quel constructeur se risquera le premier à fabriquer des chip3D pour faire du raytracing en temps réel?
 
News interessantes :
http://www.nvchips-fr.com/News/new [...] wsnumber=2
http://www.nvchips-fr.com/News/new [...] wsnumber=4


Message édité par Fouge le 25-04-2003 à 17:32:49
Reply

Marsh Posté le 25-04-2003 à 17:28:33    

fouge a écrit :

Le raytracing est moins couteux en BP mémoire que le rendu 3D traditionnel. De plus il est indépendant de la complexité géométrique de la scène.
Cette méthode de rendu devient de + en plus interessante mais le changement de standard 3D entrainera un changement de carte 3D.
C'est cela qui risque d'être difficile et long. Quel constructeur se risquera le premier à fabriquer des chip3D pour faire du raytracing en temps réel?
 


 
indépendant de la complexité de la scène ? j'ai dû louper un pavé :D

Reply

Marsh Posté le 25-04-2003 à 17:30:56    

fouge a écrit :

Le raytracing est moins couteux en BP mémoire que le rendu 3D traditionnel. De plus il est indépendant de la complexité géométrique de la scène.
Cette méthode de rendu devient de + en plus interessante mais le changement de standard 3D entrainera un changement de carte 3D.
C'est cela qui risque d'être difficile et long. Quel constructeur se risquera le premier à fabriquer des chip3D pour faire du raytracing en temps réel?
 


 
oui mais si TOUT passe par le proc ?
une "simple" carte 2D ferait l'affaire ?
 
bon of course, si certaines particularités sont "cablées" par la suite, ca change tout c clair ...


---------------
::Mind is a terrible thing to taste::
Reply

Marsh Posté le 25-04-2003 à 17:33:11    

->fouge
cool les liens  :)


---------------
::Mind is a terrible thing to taste::
Reply

Marsh Posté le 25-04-2003 à 17:33:56    

en fait la flexibilité allant en augmentant, les ingés des nvidia & ati ont indiqué une possibilité dévolution vers du le raytraçing.
 
en fait en rendu par "rasterisation", si tu as une voiture de 1M de polygones (de triangles), les 1M de poly sont T&Lés et traçés.
 
en ray-traçing, si tu une image de 1024x768 à traçer, ça fait 786432 point à traçer, les 1M de polys seront testé contre un rayon dans l'espace 786432 fois, ce qui fais qu'il y aura 786432 millions de tests triangles / rayon.
 
je ne parles pas du cas ou il y a des propriétées de réflexion/réfraction sur les matériaux. là pour un pixel rendu, tu peux avoir à retester récursivement plusieures fois les 1M de triangles.
 
bien sûr on peut réduire cela graçe à des optimisations, mais ça reste plus lourd.

Reply

Marsh Posté le 25-04-2003 à 17:33:56   

Reply

Marsh Posté le 25-04-2003 à 17:35:35    

Le passage rendu3D traditionnel -> raytraicing se fera peut-etre en douceur :love:  
 
"La méthode décrite , n'est pas exploitable avec les GPU actuels tels les Radeon 8500 ou les GeForce3/4 Ti en raison de certaines limitations(vertex et fragment programs possédant un jeux d'instructions incomplets, nombre de registres réduits ,nombre de textures actives et dépendantes limité etc.), mais les GPU à venir pourraient bien être capable de faire du ray tracing temps réel, car ils possèderont un jeu d'instructions étendus à virgule flottante conformément au spécifications de l'OpenGL 2.0 et de DirectX 9."
 
Lisez-bien les news de www.3dchips-fr.com !
 
edit:
Comme je disais : "De plus il est indépendant de la complexité géométrique de la scène."
En fait c'est la complexité au niveau des réflections et autres effets de lumières qui bouffent du calcul...


Message édité par Fouge le 25-04-2003 à 17:38:51
Reply

Marsh Posté le 25-04-2003 à 17:37:21    

si tu mates  les démos, certains objetc possedent des bords flous, ou relativement mal définis...
 
Je pense que ca fait parti des optimisations qui ont été faites
 
Pour info, jetez un oeil à cet démo :
HEAVEN SEVEN de Exceed : http://www.inf.bme.hu/~exceed/h7-final.zip
 
http://pouet.net/screenshots/5.jpg


---------------
::Mind is a terrible thing to taste::
Reply

Marsh Posté le 25-04-2003 à 17:40:11    

en fait sur les CG actuelles on cherche à booster les opérations sur les vertexs, ce qui bride la vitesse géométrique, et booster le fillrate pour traçer le plus rapidement possible.
 
ce qu'il faut optimiser dans un raytracer, c'est les routines d'intersection triangle/rayon, et toute les systèmes de rejection d'objets qui vont avec (bounding box, arbre BSP).
 
le temps prix par un filtrage bili/trilinéaire avec aniso ou pas est une blague en raytraçing.
 
après si l'on se donne des limites serrées sur les propriétées des matériaux et le nombre de récursion impliquées, on peut certainement faire booster le bordel.
 
mais pour que ce soit efficace, il faudrait que le matériel de la carte 3d aye accès à la "base de donnée" du monde, donc qu'elle puisse tester pour rejection les bounding box & co.
 
mais avoir un matériel dédié qui remontes jusqu'aux structures du monde, serait trop brideur pour la créativité, car une fois les standards posés, on est obligé de se conformer aux standards.
 

Reply

Marsh Posté le 25-04-2003 à 17:45:55    

par contre c'est marrant de voir les démos-makers évoluer dans le raytraçing.
 
si des démos sont en raytracing temps réel, alors dans 10 ans on aura ptet du hardware grand public raytracing.
 
NB: il existe déjà des solutions matérielles raytracing, c'est pas super efficace en FPS, et c'est très couteux...
 
même si les CG actuelles en virgules flottant ont énormément gagnées en flexibilité, je doutes de les voir faire du raytraçing. après on verra :D
 
déjà utilisons bien les VS PS intelligement, laissons le reste arriver gentilment.

Reply

Marsh Posté le 25-04-2003 à 17:46:33    

Graffin a écrit :

si tu mates  les démos, certains objetc possedent des bords flous, ou relativement mal définis...
 
Je pense que ca fait parti des optimisations qui ont été faites
 
Pour info, jetez un oeil à cet démo :
HEAVEN SEVEN de Exceed : http://www.inf.bme.hu/~exceed/h7-final.zip
 
http://pouet.net/screenshots/5.jpg


 
non c'est ptet un effet voulu...

Reply

Marsh Posté le 25-04-2003 à 17:49:52    

drapeau =)

Reply

Marsh Posté le 25-04-2003 à 17:49:58    

Réponse du boss d'Epic sur sa vision du ray-tracing
 

Citation :

I don't see this ever happening, because traversing a scene per-object then per-pixel is far more cache coherent and amenable to brute-force hardware than traversing per-pixel then per-object. This isn't just a "hardware isn't fast enough yet" problem; ray-tracing algorithms are at a significant absolute disadvantage to rendering algorithms, so for a given amount of hardware power, you'll always be able to achieve better results from rendering than raytracing.

 
http://www.beyond3d.com/index.php#news5502


---------------
But if they think they're going to hold onto it, they're smoking something hallucinogenic - Jen-Hsun Huang
Reply

Marsh Posté le 25-04-2003 à 17:55:49    

BJOne a écrit :


 
non c'est ptet un effet voulu...  


 
ya pas un rapport avec une approximation de calcul ? ;)
genre une interpolation ?


---------------
::Mind is a terrible thing to taste::
Reply

Marsh Posté le 25-04-2003 à 18:03:46    

on peut trouver sur cette page plein de démo sur le rtrt : http://www.acm.org/tog/resources/R [...] erview.htm
 
certaine sont TRES anciennes (date du 486 !!) et ne fonctionnent que sous du vrai DOS (ou sous w9x :??: chaipas jpeux pas tester)  
 
juste pour voir le progrés accompli durant tout ce temps :)
 
Spécial kassedédi à "Fresnel 2" du groupe Kolor : http://pouet.net/screenshots/1324.gif


Message édité par Graffin le 25-04-2003 à 18:04:16

---------------
::Mind is a terrible thing to taste::
Reply

Marsh Posté le 25-04-2003 à 22:05:12    

sinon je viens tester les démo de fan à la maison (1700+ juihb powa), et c'est sympa quand même, mais bizarrement les filtrages semblent simples, comprends pas pourquoi ils ont pas fait du trilinear anisotropé, vu le coût du temps par image doit être dans le raytracing lui-même.
sinon c'est pas mal rapide avec des surfaces quadratiques. mais la géométrie de certains trucs est taillé à la serpe...
 
par contre je sens que le benchmark va être très utile pour tester la stabilité cpu & bencher les machines :D

Reply

Marsh Posté le 25-04-2003 à 22:20:15    

en 1280, ttes options à donf : 0.6fps de moyenne sur 30 secondes :D


---------------
Et si c’était ça la vie / Et si on nous l’avait pas dit ?
Reply

Marsh Posté le 25-04-2003 à 22:20:50    

BJOne a écrit :

sinon je viens tester les démo de fan à la maison (1700+ juihb powa), et c'est sympa quand même, mais bizarrement les filtrages semblent simples, comprends pas pourquoi ils ont pas fait du trilinear anisotropé, vu le coût du temps par image doit être dans le raytracing lui-même.
sinon c'est pas mal rapide avec des surfaces quadratiques. mais la géométrie de certains trucs est taillé à la serpe...
 
par contre je sens que le benchmark va être très utile pour tester la stabilité cpu & bencher les machines :D


 
Je ne crois pas que ce soit de la faute au RT ... C'est juste que ça a été conçu comme cela, non ?

Reply

Marsh Posté le 25-04-2003 à 22:22:33    

les quadratic textures .... ça me fait penser à un certain NV1 :D


---------------
Et si c’était ça la vie / Et si on nous l’avait pas dit ?
Reply

Marsh Posté le 25-04-2003 à 22:25:29    

Comme dit plus haut, si la demo de FAN est vraiment du RAYTRACING, je vois pas pkoi ça ne serait pas grand publique dans 10 ans.
 
Quand on voit l'évolution 3D en 10 ans et cette demo, bin... c'est deja bien avancé et ça tourne bien.

Reply

Marsh Posté le 25-04-2003 à 22:26:11    

ui, à 0.6 fps [:boidleau]


---------------
Et si c’était ça la vie / Et si on nous l’avait pas dit ?
Reply

Marsh Posté le 25-04-2003 à 22:28:49    

HidE a écrit :

ui, à 0.6 fps [:boidleau]  


 
mieux que 3dmark2k3 sur ma babasse  :o

Reply

Marsh Posté le 25-04-2003 à 22:31:43    

KRUMLI a écrit :


 
mieux que 3dmark2k3 sur ma babasse  :o  

:o
 
en désactivant la dernière option, je gagne 0.1fps :D
 
 
je pense que c'est l'antialiasing qui casse tout, surtout si c'est un supersampling :/


---------------
Et si c’était ça la vie / Et si on nous l’avait pas dit ?
Reply

Marsh Posté le 25-04-2003 à 22:33:21    

eh ben en fait nan :D


---------------
Et si c’était ça la vie / Et si on nous l’avait pas dit ?
Reply

Marsh Posté le 25-04-2003 à 22:38:28    

yannick_frere a écrit :


 
Je ne crois pas que ce soit de la faute au RT ... C'est juste que ça a été conçu comme cela, non ?


 
vi tout à fait...

Reply

Marsh Posté le 25-04-2003 à 22:41:22    

KRUMLI a écrit :

Comme dit plus haut, si la demo de FAN est vraiment du RAYTRACING, je vois pas pkoi ça ne serait pas grand publique dans 10 ans.
 
Quand on voit l'évolution 3D en 10 ans et cette demo, bin... c'est deja bien avancé et ça tourne bien.  


 
tout à fait, mais il y encore des problèmes à résoudre...
 
comme j'ai dit, une carte graphique actuelle fonctionne indépendemment de l'organisation des objets 3d faite par le moteur 3D du programmeur.
ce qui permet une grande libertée de choix d'organisations.
 
en raytracing, un accélérateur matériel doit pouvoir tester tous les objets (et des objets de natures différentes), et donc l'organisation doit être normalisé, ce qui peut poser des problèmes...
 
enfin je dit ça comme ça...

Reply

Marsh Posté le 25-04-2003 à 22:47:55    

BJOne a écrit :


 
tout à fait, mais il y encore des problèmes à résoudre...
 
comme j'ai dit, une carte graphique actuelle fonctionne indépendemment de l'organisation des objets 3d faite par le moteur 3D du programmeur.
ce qui permet une grande libertée de choix d'organisations.
 
en raytracing, un accélérateur matériel doit pouvoir tester tous les objets (et des objets de natures différentes), et donc l'organisation doit être normalisé, ce qui peut poser des problèmes...
 
enfin je dit ça comme ça...


 
Toi qui a l'air de t'y connaître ... :)
Donc, dans le RT, on projette un rayon à partir d'un "pixel d'écran" pour déterminer la couleur de celui-ci ... Et pour ce faire, il faut tester chaque triangle pour savoir si le rayon projeté a une intersection avec lui ?? J'ai bien compris ? J'imagine bien que ce soit lent, tiens ! ^^
 
Quelles sont les optimisations qui ont été apportées ?? Tu sais ?
(merci :))

Reply

Marsh Posté le 25-04-2003 à 23:09:56    

yannick_frere a écrit :


 
Toi qui a l'air de t'y connaître ... :)
Donc, dans le RT, on projette un rayon à partir d'un "pixel d'écran" pour déterminer la couleur de celui-ci ... Et pour ce faire, il faut tester chaque triangle pour savoir si le rayon projeté a une intersection avec lui ?? J'ai bien compris ? J'imagine bien que ce soit lent, tiens ! ^^
 
Quelles sont les optimisations qui ont été apportées ?? Tu sais ?
(merci :))


 
c exactement ça. en fait on remonte le chemin inverse de la lumière qui est parvenue jusqu'a l'oeil.
 
des optimisations il en existe plein, le but étant de rejeter des paquets de triangles ou autres primitives, on passe alors par des "boites à chaussure" (bounding box) qui entourent l'objet de plusieurs millions de polygones ou autres primitives.
si le rayon touche la boite englobante, on teste le reste...
aussi tu l'arbre BSP qui est utilisable. l'arbre BSP tu en as entendu parler pour Quake & companie, ça divise & organise la géométrie de manière pourvoir faire des tests/recherches de manière dichotomique dans l'espace.
 
en fait la manière utilisée actuellement en 3D temps-réel, est la réciproque du ray-traçing.
 
en "rasterisation" (technique 3D des cartes 3D et des vieux jeux 3D), on part de la géométrie 3D au traçage 2D.
 
en raytraçing on part de la 2D pour revenir à la 3D.
 
PS: j'espère que je dis pas de conneries.

Reply

Marsh Posté le 25-04-2003 à 23:12:14    

[:abnocte invictus]


---------------
"I wonder if the internal negative pressure in self pumping toothpaste tubes is adjusted for different market altitudes." John Carmack
Reply

Marsh Posté le 25-04-2003 à 23:14:20    

drapal :)


---------------
P@F deathlist
Reply

Marsh Posté le 25-04-2003 à 23:14:26    

je sens que toi aussi tu vas avoir des choses intéréssantes à dire :)


---------------
Et si c’était ça la vie / Et si on nous l’avait pas dit ?
Reply

Marsh Posté le 25-04-2003 à 23:15:43    

par exemple pour les surfaces courbe, c'est la merde avec une carte 3D: il faut la sous-diviser en triangles. et traçer les triangles les uns après les autres (tu vois donc un polygonalisation de la surface).
 
en raytracing, tu gardes ta courbe sous forme mathématique, et tu cherches l'intersection par d'autre moyens d'approche.
 
par exemple le rendu d'un sphère peut être graphiquement "parfait" en raytraçing alors que tu verras des polys en 3D rasterisée. tu calcules la distance rayon de vision<->centre de sphère si la distance est inférieure au rayon de la sphere, y'a un hit, tu détermines alors la position dans l'espace de l'intersection, le vecteur normal de la surface de la sphere à cette intersection (simple: c'est la position d'intersection-position du centre), et si la surface a une propriété de réflexion, tu fais le symétrique du vecteur de vision par rapport à la normale, et tu vas retester récursivement d'autres surfaces (et tu obtiens le reflet dans la sphere).
 
la couleur du pixel de l'écran étant déterminée par la quantitée d'éclairage de point de la sphère:
 
pour obtenir cette quantitée on prends toute les sources de lumières, pour chaque source on vérifie si elle atteint bien le point d'intersection avec la sphere, on fait donc un test rayon source de lumière->point d'intersection (retest avec les éléménts du monde).
 
une fois que l'on sait que la lumière atteint bien le point d'intersection, on applique l'équation d'éclairage entre le vecteur lumière et le vecteur normal pour la l'éclairage diffus, le vecteur lumière avec le vecteur de vision pour la quantitée spéculaire.
 
on fois que tu as ça, tu modules la ou les textures si il y en a...
 
et si y'a reflet/réfraction on refait tout ça récursivement avec le vecteur de vision reflété/réfracté...


Message édité par bjone le 25-04-2003 à 23:48:50
Reply

Marsh Posté le 25-04-2003 à 23:17:52    

BJOne a écrit :


 
c exactement ça. en fait on remonte le chemin inverse de la lumière qui est parvenue jusqu'a l'oeil.
 
des optimisations il en existe plein, le but étant de rejeter des paquets de triangles ou autres primitives, on passe alors par des "boites à chaussure" (bounding box) qui entourent l'objet de plusieurs millions de polygones ou autres primitives.
si le rayon touche la boite englobante, on teste le reste...
aussi tu l'arbre BSP qui est utilisable. l'arbre BSP tu en as entendu parler pour Quake & companie, ça divise & organise la géométrie de manière pourvoir faire des tests/recherches de manière dichotomique dans l'espace.
 
en fait la manière utilisée actuellement en 3D temps-réel, est la réciproque du ray-traçing.
 
en "rasterisation" (technique 3D des cartes 3D et des vieux jeux 3D), on part de la géométrie 3D au traçage 2D.
 
en raytraçing on part de la 2D pour revenir à la 3D.
 
PS: j'espère que je dis pas de conneries.


 
Non c'est ça : on projette les triangles sur une surface plane (l'écran ...).
 
Est-ce que tu aurais -par hasard- une page web qui explique le principe d'un arbre BSP ?? Ca m'intéresserait ... :) Je veux dire, au niveau programmation.
En gros, je ne vois pas bien comment on pourrait organiser les polygones pour faire des recherches dicho : l'arbre ne serait plus valide dès lors que la caméra change de position, non ?
Faut-il recréer l'arbre à chaque frame ?
 
Merci :)

Reply

Marsh Posté le 25-04-2003 à 23:21:53    

BJOne a écrit :

par exemple pour les surfaces courbe, c'est la merde avec une carte 3D: il faut la sous-diviser en triangles. et traçer les triangles les uns après les autres (tu vois donc un polygonalisation de la surface).
 
en raytracing, tu gardes ta courbe sous forme mathématique, et tu cherches l'intersection par d'autre moyens d'approche.
 
par exemple le rendu d'un sphère peut être graphiquement "parfait" en raytraçing alors que tu verras des polys en 3D rasterisée. tu calcules la distance rayon de vision<->centre de sphère si la distance est inférieure au rayon de la sphere, y'a un hit, tu détermines alors la position dans l'espace de l'intersection, le vecteur normal de la surface de la sphere à cette intersection (simple: c'est la position d'intersection-position du centre), et si la surface a une propriété de réflexion, tu fais le symétrique du vecteur de vision par rapport à la norme, et tu vas retester récursivement d'autres surfaces (et tu obtiens le reflet dans la sphere).


 
Ouip :)
Ca j'avais compris :jap:
Il faut être bon en géométrie analytique :)
C'est surtout l'organisation des polygones qui me gêne pour l'instant ! Le reste, c'est "simple", au niveau conceptuel ...

Reply

Marsh Posté le 25-04-2003 à 23:25:53    

yannick_frere a écrit :


 
Non c'est ça : on projette les triangles sur une surface plane (l'écran ...).
 
Est-ce que tu aurais -par hasard- une page web qui explique le principe d'un arbre BSP ?? Ca m'intéresserait ... :) Je veux dire, au niveau programmation.
En gros, je ne vois pas bien comment on pourrait organiser les polygones pour faire des recherches dicho : l'arbre ne serait plus valide dès lors que la caméra change de position, non ?
Faut-il recréer l'arbre à chaque frame ?
 
Merci :)


 
l'arbre BSP restera valide quelque soit la position de la caméra. ce qui compte c'est que la géométrie BSPifiée reste statique. (et encore forcément y'a des gars qui ont cherché comment mettre à jour l'arbre lors de manipulation).
 
par contre forcément il est possible d'avoir à reconstruire l'arbre de frame en frame, ce qui octroit un surcoût de calcul, mais une accélération dans les tests primitives/rayon.

Reply

Marsh Posté le 25-04-2003 à 23:33:05    

pour résumer le RT:
 
1) pour chaque pixel de l'écran on détermine un vecteur dans l'espace
 
2) avec ce vecteur on va chercher l'intersection avec une primitive la plus proche de la caméra/oeil  
 
3) on regarde si le point d'intersection est éclairé par les sources (du coup on regarde si il y a rien qui fait obstacle entre la source et l'intersection, retest d'un rayon avec le monde)
 
4) on calcule l'éclairage au point d'intersection en fonction du vecteur d'éclairage, du vecteur normal à la surface, et du vecteur de vision, on module la/les textures de la surface en fonction de ces quantitées d'éclairage.
 
5) si la surface réfléchi/réfracte, on repart récurisivement au '2)' avec le vecteur refléchi & réfracté comme nouveau vecteur de vision.
puis on mélange ce qui est issu du 4) avec ce que l'on a récupéré des récursions de reflection/réfraction.
 
6) on a la couleur du pixel, on passe au suivant :D
 
valà si je dis pas de conneries, c'est à peu près ça un raytracer minimal :D


Message édité par bjone le 25-04-2003 à 23:50:16
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed