j'y avais aussi pensé, mais bon c'est vraiment fort lourd comme calcul pour l'appliquer de façon correcte et en temps réel.

mais c'est bcp plus commode, propre, et flexible/puissant de faire ca avec un rt qu'avec un rasterizer, et ca sera un grand avantage compare aux rasterizers quand les hardware de raytracing le gereront.

ben au debut j'avais pensé à ça:
[img] le PVS ne reduit pas le nombre de collision a calculer dans ce cas là. Mais c'est vrai que si on élimine le miroir dans la salle III on pourrait éliminer une salle, j'y avais pas pensé. Mais bon, imagine un fps ou l'on aurait la possibilité d'utiliser des materiaux réfléchissant pour les skins. Je vois pas comment je ferais, recalculer un PVS a chaque frame en fonction des positions des jouers? Mais bon c'est vrai que t'as raison, le partionnement peut encore servir.

heu oue mais la le seul pbl c'est que tu raisonne en mode rasterizing ou t'as une notion de pvs pour le point de vue, la si il y devait y avoir une histoire de pvs, ca serait un pvs par rayon, donc a chaque fois que tu trace un rayon (soit les rayons root castes traces depuis la camera et passant par un pix du plan de projection de l'ecran, soit les rayons traces a partir des points d'intersections de != surfaces (tes miroirs)).
mais y a pas d'histoire de pvs, je suis d'accord sur le fait qu'un pvs sert a rien, quand je t'ai quote plus haut c'etait pour la phrase en general, quand t'impliquais par bsp que le partitionnement pouvait jarter sans pbl.
la pour chaque nouveau rayon t'as juste quelques tests de collisions avec des boites (ou spheres) englobantes a faire avant d'arriver a un set relativement faible de surfaces a tester.

j'y avais aussi pensé, mais bon c'est vraiment fort lourd comme calcul pour l'appliquer de façon correcte et en temps réel. J'ai déjà vu une implementation avec le calcul de photon mapping complètement déplacé vers le GPU et pour renderiser la boite de Cornell avec des paramètres capable de donner une image acceptable ça prenais 64,3 secondes.

oue bah le photon mapping sur le gpu c'est pas encore vraiment utilisable non
j'ai des exemples un peu moins gore que le tien point de vue temps de calcul, mais ils sont fait sur des scenes relativement petites, et surtout, ils sont faits progressivement.

radiosite sur le GPU: http://www.cs.unc.edu/~coombe/research/radiosity/
ils calculent des lightmaps a la volee. dl la video, on voit bien le refinement progressif (j'ai pas regarde en detail comment ils faisaient, mais on dirait qu'ils font plus ou moins une iteration de radiosite par frame)
sinon pour le photon mapping: http://graphics.stanford.edu/papers/photongfx/
mais bon, la c'est pareil, des que tu bouge la lumiere ou les objets, la (les?) photon map est invalidee, et ils doivent la recalculer, ca rend bizarre le lag qu'il y a... et c'est bizarre pke j'ai l'impression que des que la vue bouge ils doivent la recalculer aussi, comme si elle etait en screenspace, ou dependante de la vue (g pas regarde l'article, ils l'expliquent peut etre... (surement))

c'est vrai que ça donne des lames de rasoirs, et c'est pas moi non plus qui va commencer a renderiser 8+ shadow volumes par ombre où d'autres techniques lentes pour simuler la pénombre. Par contre, si tu fais du calcul d'illumination par pixel, tu peux avoir de bons résultats sur les extremités en utilisant des shadow volumes et en faisant une passe par source de lumière. C'est la technique utilisé dans Doom3 je crois.
http://www.doomworld.com/php/screenie.php?dir=/doom3_051303/&number=1 Ca donne un dégradé à l'extrimité de l'ombre. Mais toujours pas de pénombre.

je sais pas comment c'est fait dans doom3, mais ca ca se fait tout seul si tu attenue les lumieres en fct de la distance, c'est sur ca rend deja mieux que les ombres completement sharp et uniformes, mais c'est quand meme tres sharp et uniforme
perso chuis pas trop fan des choix techniques qui ont ete faits pour doom3, ms bon, ca n'engage que moi

les PSM je connaissait et comme tu le dis, en pratique c'est caca. Par contre les TSM je connaissait pas, tu pourrais me passer des liens, ça a l'air pas mal comme technique.

heu je posterai le lien tout a l'heure, je l'ai pas sous la main la

Sinon un autre avantage avec le rt c'est qu'on peut utiliser des équations mathématiques pour définir des surfaces à la place de triangles

oui, ca c'est sur que c'est bien. par contre pour les applications pratiques, plutot que des spheres/tores/cones/cylindres/plans et autres formes simples, ce qui est bcp plus interessant c'est les patch de bezier ou les SubD/nurbs, par ex pour le terrain. et le texturing est pas tellement plus complique que ca (plus complique que pour un plan c'est sur ), surtt si c'est gere en hard (mais la encore, c'est pas le cas pour l'instant)
mais pour les surfaces c'est pas l'argument le plus pesant en faveur du rt a mon avis. le hardware graphique actuel est deja capable de subdiviser des surfaces parametriques, et il va probablement evoluer favorablement dans ce sens. avec l'addition des vertex textures dans les VS3.0, ca te permet deja de faire des trucs pas mal du tout.
je sais plus si un constructeur de GPU a deja implemente la tesselation anisotropique pour les patch, mais en tout cas si c'est pas deja fait ca va pas tarder... faudrait que je me renseigne pour la tesselation aniso tiens...