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
mwai :/ bah c'est sur que ya pas bcp de monde qui serait suceptible de dev ca qui va prendre des risques commerciaux (et c'est un tort a mon avis), en tout cas point de vue dev de jeux et autres, ca serait aberrant pour l'instant de penser faire quelquechose en rt qui puisse rivaliser avec le rasterizing a la fois point de vue perfs et qualite de rendu...
Cette implémentation inclus des réflections/réfractions, donc les BSP et les PVS ne sont pas applicables.
heu et pourquoi ca serait pas appliquable? que t'aie des reflections/refractions, ou des ombres, ca change strictement rien, c'est juste plus de rayons a tracer, c'est tout... je comprends pas ton "donc".
le PVS de toute facons c'est vieux et depasse (les bsp aussi, y a d'autres formes de partitionnement d'espace infiniment mieux que ces trucs pourris), mais un BSP reste tout a fait utilisable, et c'est _beaucoup_ mieux que ne pas avoir de partitionnement d'espace.
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.
je crois que t'as pas compris un truc, que t'aie aucune reflection/refraction/ombre (sans meme parler de GI ou de photon mapping), ou que t'en aie plein, ca ne change _strictement_ rien point de vue partitionnement, ca n'affecte l'utilisation et l'interet du partitionnement en rien, en fait si, plus t'as de reflex/refract et autres, plus le partitionnement devient indispensable si tu veux garder une bonne performance.
Sinon quel serait l'avantage de faire du raytracing et pourquoi auraient-ils implémenté des réflections/réfractions dans leur engine.
j'ai l'impression que tu te dis "ils ont fait ca, donc y doit y avoir un avantage". il n'y a absolument aucun avantage tant que tu te contente des reflections/refractions, le rasterizing peut faire ca tres bien et bcp plus vite (pour l'instant, uniquement grace au hw re rasterizing bourrin qu'il y a). en fait si il y a un interet dans l'etat actuel: que la vitesse de rendu ne soit pas directement dependante du nombre de triangles, mais ca c'est uniquement possible grace a un partitionnement intelligent de l'espace (ce que visiblement tu considere comme inutile).
le principal interet des rt pour l'instant n'est visible ni implemente dans aucun des shots en question, ni dans le hw, par contre si tu vas voir freon 2/7, t'en aura un appercu: photon mapping et GI.
plus globalement GI, le truc qui est hyper lourd a faire avec des rasterizers. soit tu le fais proprement mais c'est plus temps reel, soit tu te contente d'approximations, par exemple, les spherical harmonics d'ordre 3 ou 4 donnent des resultats potables, voire corrects pour l'ordre 4, mais c'est horrible point de vue memoire, 9 coefficients SH pour l'ordre 3, 16 pour l'ordre 4.
si tu veux du SH par vertex, tu dois avoir une tesselation minimum de la geometrie pour que ca soit utilisable. si c'est pas assez subdivise ca sert a rien d'avoir du SH, ca sera moche. bcp de vertex * bcp de coeffs SH * sizeof(float) (voire sizeof(half) a la limite) == bcp de mem
sinon y a toujours des SH maps, des lightmaps version SH qui au lieu de stocker les couleurs RGB de la lumiere pour chaque lumel, stockent les 9 ou 16 coefficients SH. idem, pour avoir une bonne resolution, grosses SH maps * bcp de coeffs SH == bcp de mem...
surtout que le SH ne marche que pour la geometrie statique et les lumieres dynamiques... des que la geometrie change, tu peux te fourrer les coeffs SH dtc (cherement precalcules, un calcul des coeffs pour une scene relativement simple peut prendre qques heures...).
mais tant que t'en reste a reflections/refractions, et meme ombres, le rt est surement plus elegant, mais point de vue perfs pour l'instant c'est de la merde en boite, et si c'est juste pour se contenter d'avoir des reflections/refractions, je prefere encore rester au rasterizing.
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.
heu deja, tu peux reconstruire des branches du BSP a la volee assez rapidement, ensuite comme dit plus haut, le BSP est obsolete depuis heu.. bah depuis que les Z-buffers sont supportes en hardware, le seul avantage par rapport a d'autres partitionnement d'espace que ca avait c'est que ca te donnait un tri en Z gratuit avec le parcours de l'arbre. le PVS c'est mignon mais ca date enormement aussi, maintenant t'as des equivalents de pvs completement dynamiques avec l'occlusion culling (soft ou hard).
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).
la tu parles des shadowmaps basiques, qui sont effectivement bcp plus simples a mettre en oeuvre que des shadow volumes "basiques".
par contre si on considere la grande famille des shadow maps, ce n'est pas elles qui ont le plus de defauts.
ce dont tu parle, avec le pbl de resolution, je suppose que c'est le pbl du dueling frustra? qui est juste que si tu regarde une surface ombree avec la lumiere rasante de devant, la resolution de la shadow map sera tres elevee sur les parties eloignees, et tres faible sur les parties proches.
ca c'est du a la projection naive de la shadow map. pour remedier a ca t'as les PSM (perspective shadow maps), qui ont une projection non uniforme (uniforme en post perspective space), de sorte que la resolution est plus elevee pres de l'observateur, et plus faible pour les parties eloignees de l'observateur. pour (tenter d') obtenir un ratio entre shadow map texels / frame buffer pixels le plus constant possible sur toute la shadow map.
et les PSM sont bcp plus chiantes a implementer que les shadow maps normales, et plus chiantes que les shadow volumes, et ont tjrs bcp de pbls, notemment un flickering des ombres, et une perte de resol dans certains cas
t'as aussi les TSM (trapezoidal shadow maps). les TSM elles englobent le view frustum avec un trapeze, et remappent le trapeze et le view frustum sur un carre, ca resulte en une utilisation bien meilleure de la resol de la shadow map, ca te donne des shadow maps excellentes, ca elimine pleins de problemes, ya plus de flicker, t'as tous les avantages des shadow maps, et aucun de leurs inconvenients.
et contrairement aux shadow volumes, tu peux te permettre d'avoir des polycounts tres eleves sans te soucier du cout de l'extraction de silhouette, et tu peux avoir des surfaces alpha testees qui produiront de bonnes ombres (pas comme les shadow volumes).
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, ...
heu pas necessairement plus precis non, les shadow maps peuvent etre aussi precises (cf TSM), mais c'est pas forcement une bonne chose, ca te donne des ombres "precises" sans doute, mais immondes, on dirait des lames de rasoirs. et les soft shadows avec les shadow volumes... aheum... comment dire...
2 fps sur une 9800... ?
<troll>de tte facons les shadow volumes ca pue</troll>
heu pour les tutos GLSL, j'ai pas de liens sous la main dsl, mais c'est tres tres proche de Cg et HLSH hein... (et pour eux t'en trouvera plein)
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...
). avec un partitionnement un minimum correct de l'espace, tu reduis le nombre de tests par rayon a un nombre bcp plus petit et qui devient independant du nombre total de triangles au fur et a mesure que ce nombre augmente.
.. 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 
le PVS de toute facons c'est vieux et depasse (les bsp aussi, y a d'autres formes de partitionnement d'espace infiniment mieux que ces trucs pourris), mais un BSP reste tout a fait utilisable, et c'est _beaucoup_ mieux que ne pas avoir de partitionnement d'espace.
(g pas regarde l'article, ils l'expliquent peut etre... (surement))
), et c'est sans doute mieux comme ca, meme si ca te fait perdre du temps... au moins ca t'apprendra des trucs que t'aurais pas appris si t'etais directement passe a autre chose.
\o/\o/\o/
