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
 
-> 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 :




 
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

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 )
 
http://www.beyond3d.com/forum/viewtopic.php?t=5491

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

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

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

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

 
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 ...

->fouge
cool les liens  

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.

Le passage rendu3D traditionnel -> raytraicing se fera peut-etre en douceur  
 
"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...

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
 

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.
 

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éjà utilisons bien les VS PS intelligement, laissons le reste arriver gentilment.

 
non c'est ptet un effet voulu...

drapeau =)

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

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

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

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 :

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

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

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

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

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.

ui, à 0.6 fps

 
mieux que 3dmark2k3 sur ma babasse  

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

eh ben en fait nan

 
vi tout à fait...

 
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 )

 
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.

drapal

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

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é...

 
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

 
Ouip
Ca j'avais compris
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 ...

 
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.

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
 
valà si je dis pas de conneries, c'est à peu près ça un raytracer minimal