y a pas de "passer au raytracing accelere en hardware" ou pas, c'est juste deux trucs != qui progressent en parallele, pour l'instant pour avoir de bons resultats graphiques avec une bonne performance --> rasterizing, en attendant que le rt temps reel se developpe.

Je sais pas. Les développement sont trop lents. J'ai l'impression que l'on préfère continuer avec du rasterizing que de développer le rt. Il n'y a pas beaucoup de monde intéressé dans une accélération hardware du rt.

heu... nan
- c'est la peine d'optimiser les algorithmes/le code, encore plus qu'avec le rasterizing (pour l'instant)
- les "bricolages" du genre BSP, PVS, portals? t'appelle ca des bricolages toi? si tu fais un RT sans aucun partitionnement d'espace (ce que tu suggere en arretant ces "bricolages"), pour chaque rayon, cad pour chaque pixel a l'ecran si il n'y a aucune reflection/refraction, ni GI ou photon mapping, (et bcp plus sinon) tu dois te farcir les tests de collisions avec _toutes_ les surfaces de ta scene, cad absolument tous les triangles. si t'as une scene d'un million de tris, tu dois tester les collisions entre 1 rayon et 1 millions de triangles pour chaque pixel de l'ecran, et potentiellement enormement plus des que tu commence a avoir des reflections, refractions, lumieres, etc...

Cette implémentation inclus des réflections/réfractions, donc les BSP et les PVS ne sont pas applicables. Si ils parlent d'un prototype d'accélération hardware, ils vont surement faire en sorte que l'on puisse avoir des framerates/resolutions convenables pour des implementation qui font usage de réflections/réfractions. Sinon quel serait l'avantage de faire du raytracing et pourquoi auraient-ils implémenté des réflections/réfractions dans leur engine.

Et oui j'appelle ça du bricolage car c'est du precalculage qui fait en sorte qu'une grosse partie devient statique.

Example: si par example dans un fps tu veux faire un trou dans un mur, ton PVS est foutu.

et puis les shadow volumes (sux .. hem..) ou les shadow maps (rox .. hem..) en quoi c'est des bricolages? au contraire c'est des moyens plutot elegants d'avoir des ombres (je trouve) les bricolages apres ca vient dans certaines implementations, mais pour le principe lui meme, je trouve pas du tout que ca soit un bricolage...

Quand je parle de shadow volumes et de shadow maps, je parle pas de la theorie mais de la pratique. Les shadow maps sont les plus faciles à mettre en oeuvre, mais se sont aussi ceux qui ont le plus de défauts (ex. si l'ombre est dirigé vers le point de vue, la résolution est beaucoup trop basse). Les shadow volumes sont plus précis mais plus gourmands en fill-rate et calcul. Calculere la silhouette d'un modèle de 10 000 polygones est déjà assez lourd (10 000 LdotN). Mais le plus dur reste le remplissage du stencil buffer. C'est un vrai bricolage pour gérer les volumes, savoir jusqu'où il faut les allonger, ...

pis, LTK, ca fait plusieurs mois que c'est sorti ce truc. si ca t'interesse tu devrais aller jeter un oeil aux forums graphics programming and theory de gamedev, pas que les news de NeHe... deja il a quasiment pas le temps de les updater, mais en plus les "news" sortent un bon bout de temps apres... par ex la page tech d'unreal engine 3, qui a eu une news sur NeHe 1 ou 2 mois apres (je le critique pas hein, me demande comment il fait pour pas laisser tomber son site, mais juste que si tu veux te tenir a jour, c'est pas le meilleur endroit ou aller voir )

Je le sais bien mais comme j'étais en période d'examens, je me suis dit que pour voir ce que j'avais raté pendant tout ce temps je ferais bien d'aller voir sur NeHe. Sinon je vais juste voir les nouveaux tutos. Par contren, un truc qu'il me faudrait c'est un site avec des tutos GLSL. Je dis bien DES, pas UN. Si quelqu'un peut m'aider.