Reprise du message précédent :

 
Pourqu'on oublie pas ma question  
 
1: oui (jak and daxter 2  probablement ,et aussi un jeux encore  secret de Lostboys)
 
2: pas enormement ,mais loin d'etre gratos quand meme.

marci beaucoup pour les précisions

koren>
je suis pas vraiment daccord
je trouve que les 2 chose dont tu fait allusion serait vraiment difficile et penalisante a faire comme tu le dis
 
je comprend pas deja comment la connaissance du chainage te permet d'eliminer les polygone dans la zone d'ombre a part en passant par plein de teste compliqué  
il faudrait transformer tout les vertex des objet pour les avoir du point de vu de la source et faire plein de teste compliqué par raport a toute les droite definie par toute les arrete du chainage pour savoir si les vertex sont contenu a l'interieur de la surface tordu delimité par le chainage et aussi plus eloigné ,du point de vue de la source, que le plus éloigné des vertex du chainage, sans compter qu'il faut tester par raport a 2 chainage quand l'un delimite un trou ect...
plein de teste compliqué qui vont te faire perdre beaucoup, beaucoup plus de temps que ce que tu gagne?
j'imagine que tu as une autre methode
 
 
et je suis convaincu que de construire le maillage et de ne pas utiliser celui de l'objet va t'ammené beaucoup de difficulté pour que ce soit adapté a chaque situation et que ca fonctionne a tout les coup sans bug ni probleme de selfshadowing et finallement demander beaucoup d'etape et de calcule suplementaire penalisant  
 
 
 
 
zeross> c'est mieux comme ca mais y a quelque chose qui m'echape, en quoi cette texture/zbuffer permet de faire des teste de visibilité de la source et d'avoir des ombres

flûte un sujet intéressant que j'ai complètement loupé    .. j'ai pas le courage de tout relire... je relirai plus tard si j'ai le temps, ça m'intéresse cetet histoire d'ombre volumétrique, j'ai toujours eu un peu de mal à imaginer l'algo utilisant le stencil buffer pour les recréer.. j'ai vu que Zerros à expliquer le fonctionnement, peut-être que j'essaierai de coder ça demain (encore une fois si j'ai le temps et le courage)

 
je comprend pas ce que tu veux dire, tu peux bien avoir des normal precalculé pour les vertex mais aussi des normal precalculé associé au polygone?
c'est 2 chose differente et les normal des poly sont quand meme tres utile (celle des vertex, apart l'eclairage dynamique...)
je vois pas comment tu fais alors, tu recalcule la normal du poly a chaque fois que tu en a besoin?  je trouve ca bisare... j'etais persuadé que les normal des poly etait precalculé comme celle des vertex., ca me parait plus logique.....
 
 
 
au faite y a un truc que j'ai pas precisé au sujet du choix du vecteur de reference pour determiné la normal des polygone extrudé
je pense que tu y a fait attention mais au cas ou...
quand tu prend l'une des 2 arrete restante comme vecteur de reference, il faut pas construire le vecteur dans n'importe quelle sens
la base du vecteur doit etre l'un des 2 vertex de larrete de contour, et l'extremité du vecteur doit etre le 3eme vertex qui n'apartient pas a l'arrete de contour

ca y est je crois que j'ai compris est c'est asser simple finalement
 
il suffit donc apres avoir fait les differente passe de rendu classique sur le poly, en rajouté une qui va consister a rasteriser le poly selon les coordoné x,y,z de chaque vertex comme d'habitude mais d'utiliser comme UV pour chaque vertex les coordonné x,y de ces vertex du point de vue de la source et comme texture cible le z-buffer du prerendu du point de vue de la source
ainsi on obtient au moment de cette passe les texel qui contient la valeur Z de ce pixel du point de vue de la source, y a plus qu'a modifier le fragmet en fonction du resultat de la comparaison entre ce texel et la valeur z du pixel
 
les UV peuvent etre obtenu au moment des transformation en transformant chaque vertex une 1er fois du point de vue de la source et associer aussitot les coordoné x,y de se resultat au UV de ce vertex puis transformer une 2eme fois ce vertex du point de vue de la camera, necessaire pour la rasterisation de la scene elle meme
 
l'ideal serait de pouvoir créer ces UV au moment ou l'on rend la 1er fois la scene du point de vue de la source dans la texture
c'est a dire pouvoir recuperer chaque coordonné x,y de chaque vertex juste apres la transformation de ces derniers et les balancer aussitot en ram pour les memoriser en tant que VU de ce meme vertex associer a cette texture en construction
mais je ne pense pas qu'on puisse le faire avec l'architecture des chip graphique pc (encore une fois...)  
 
en faite finnalement ca demande pas tellement de puissance suplementaire (pas de transformation suplementaire comme je l'imaginais si on peu faire comme la 2eme methode pour créer les UV) si ce n'est celle necessaire pour rendre une 2eme fois la scene et faire une passe suplementaire pour le rendu
 
donc c'est carrement accessible et ce doit bien etre qui est utiliser dans certain jeux
 
notemant je pense a SH2 qui utilise des projection d'ombre complexe et je me demandais ce qu'il pouvait utiliser comme methode car ce ne pouvait pas etre a base de stencil car on voyait un crenelage sur le bord des ombre (ce qui n'existe pas avec le stencil) et ca ne pouvait pas etre les technique de pojection d'ombre/texture que j'avais imaginé a la place des shadowmap qui me semblait pas adapté a des situation complexe comme dans SH2
 
donc la reponse serait les shadowmap je pense

On est d'accord Quaz c'est aussi comme ça que j'avais compris le truc. Mais moi c'est la façon "pratique" dont l'algo passe des coordonnées de la caméra en coordonnées de la source lumineuse qui m'intéresse.
 
En fait ils utilisent glTexGen visiblement qui permet de calculer la distance entre un plan et un vertex, en utilisant trois plans ils définissent la position de la source lumineuse et génèrent ainsi trois coordonnées de textures (s, t et r) correspondant en fait à la distance entre le vertex et la source lumineuse. Il ne reste plus qu'à comparer la valeur stocker dans la shadow maps à la position (s, t) et à la comparer à r si shadowMap(s, t) < r alors le vertex est dans l'ombre.
 
Je pense que c'est comme ça que ça marche mais j'attends avec impatience l'explication de Koren car j'ai l'impression que tout n'est pas encore clair dans mon esprit.

 
bah a mon avis tout y est dans mon expliquation, y a rien de plus
 
les UV peuvent etre obtenu au moment des transformation en transformant chaque vertex une 1er fois du point de vue de la source (c'est a dire en considerant la source lumineuse comme si c'etait la camera, comme au moment de la construction de la texture) et associer aussitot les coordoné x,y du resultat de cette transformation comme UV (de la texture/zbuffer du prerendu) de ce vertex puis transformer une 2eme fois ce vertex du point de vue de la camera comme a l'acoutumé pour demarer la rasterisation , au moment d'arriver a la derniere passe , les UV calculé juste avant permetrons a la rasterisation de ciblé directement la valeur Z du point de vue de la source de chaque pixel dans la texture/zbuffer
 
c'est pas plus compliqué que ca a mon avis
je vois pas ce qui te manque dans cette expliquation

dans cette situation pour la ps2 se serait plus compliqué vue quelle ne gere ni texture 3d ,ni multitexturing en une passe
donc il faudrait utiliser un buffer suplementaire pour pouvoir rendre une fois le poly et stocker les texel puis une 2eme passe pour obtenir z et comparer avec le texel dans le buffer
puis a la fin appliquer ce buffer comme filtre sur le framebuffer
 
avec en plus la texture/zbuffer qui doit etre asser lourde ca fait plus beaucoup de place en memoire video pour les texture

bon y a plus personne donc je vais continuer a parler tout seul...
 
je trouve que ces exemple de technique de projection d'ombre sont un bon exemple pour montrer encore une fois que l'architecture type ps2 malgré ces "difference" avec les autres n'est pas une "absurdité" mais a bien de reel avantage et a tout les niveaux
 
si on prend l'exemple des ombre volumetrique avec stencil-buffer il est preferable par exemple d'avoir la puissance geometrique au niveaux du cpu pour construire les volume d'ombre qui doivent passer par le cpu et demande pas mal de puissance (dans l'exemple des shadowmap la flexibilité du cpu peu permettre de recuperer le resultat des transfrmation lors du prerendu de la shadowmap et les transformer aussitot en UV)
 
et pour la puissance graphique, dans ces cas il est preferable d'avoir plein d'unité de pixel qui execute des operation simple plutot que peu de d'unité qui execute des operations complexe car dans le cas des ombre volumetrique par exemple, pour remplir le stencil il va falloir rasteriser beaucoup de tres gros poly qui compose les volume d'ombre et avec beaucoup d'overdraw obligatoire alors que par contre les operation a executer au moment de la rasterisation sont reduit au stricte minimum, incrementer ou decrementer un simple fragment (ou plutot un octet du stencil-buffer) en fonction du resultat d'un teste z-buffer, on peut pas faire plus simple, c'est a peine du niveau du flat , donc une architecture du type ps2 est nettement avantagé a cette etape (dans l'exemple des shadowmap ca permet aussi de faire le prerendu de la shadowmap plus rapidement puisque elle aussi correspond a une rasterisation tres simplifé)
 
avant qu'on me tape decu je precise que dans ces exemples je ne parle pas directement de la ps2 a qui il manque peut etre de petite chose qui peuvent compliqué un peu certaine etape de ces exemple mais je parle du type d'architecture ps2 au sens large
je pense par exemple qu'une architecture type ps2 sortie fin 2001 (un cpu plus puissant, des pipeline graphique plus evolué ect...) aurait literalement exploser la xbox dans ce type d'effet et je pense que ce genre d'exemple seront de plus en plus nombreux  
 
 
(bon normalement avec un post comme ca je devrais en voir certain comme zeross revenir tres vite )

y'a pas de stencil buffer sur ps2,quaz.Le plus proche qu'il y'ait c'est je coirs dest .alpha.

en tout cas ca n'empeche pas un jeux comme stuntman (je suis en train de jouer a la demo) de gerer parfaitement les ombre volumetrique a base de stencil
 
les batiment projete leur ombre qui epouse parfaitement les contours de la voiture qui passe a sa frontiere (dans cette situation les ombre volumetrique est la technique ideal car le volume d'ombre peut etre precalculer , y a juste a le transformer et le rasteriser au moment du remplissage du stencil) et la voiture projete parfaitement son ombre (cette fois si le volume d'ombre doit etre construit en temp reel) sur sont environnement et sur elle meme (self-shadowing)  
 
on voit clairement que c'est des ombre volumetrique , par exemple les ligne de contour sont parfaitement rectiligne et les projection d'ombre sont complexe et puis c'est la technique la mieux adapté a cette situation (les shadowmap sont plus adapté a une situaion comme SH2,  situation interieur plus simple a mon avis pour gerer la taille des shadowmap et avoir une precision raisonable, source en mouvement qui fait que tout les objet on une ombre dynamique et rendrait la technique d'ombre volumetrique beaucou plus lourde a gerer)
 
donc ca ne les empeches pas de gerer des ombre volumetrique qui utilise normalement un stencil-buffer
c'est quoi la definition du stencil-buffer pour toi?

c'est terrible!!!
Arghhhh! je viens seulement de me rendre compte que ce topic est décédé! quelle horreur!
et selon l'autopsie le décés  ne remonte pas a aujourd'hui mais a bien plus loin, peut etre bien a vendredi 12 juillet...
et moi l'idiot je ne m'en etais meme pas rendu compte...

en ce moment j'arrete pas d'observer la gestion des ombre dans les jeux auquel je joue, ca devient un reflex et la je viens de jouer a Rallysport sur bobox
 
on a le droit a une ombre volumetrique (stencil) pour la voiture quand on joue tout seul mais des qu'on joue avec des concurents (course a 4 voitures) l'ombre volumetrique disparait et est remplacer par un simple ombrage aproximatif sous la voiture, une sorte de grosse tache fixe
la bobox a un peu de mal on dirait
enfin c'est surtout la preuve que gerer des ombres volumetrique c'est loin d'etre gratuit et que ca coute

question hors sujet ,en passant ,quaz :
pourquoi ,d'apres toi ils n'ont pas mis de mip-mapping dans gun walkyrie xbox ? j'ai halluciné en voyant qu'y en avait pas (a moins d'une erreur de ma part ,bien sur ,mais on est quand meme 3 ou 4 a avoir "remarqué" ca)

j'ai la demo de GV et effectivement aparement il n'y a pas de mipmaping mais pourquoi? je n'en sais rien
autant dans le cas de la ps2 ou meme de la ngc (luigi) ca peut etre utile pour economiser un peu de memoire (surtout pour la ps2 et la gestion de la vram)
autant pour la xbox je ne vois pas trop l'interet, pourtant il doit bien y avoir une raison

ouais il me semblait bien.je me demandais si c'etait pas lié au "render to texture"  qui gere l'effet de boost.

Désolé Quaz de pas participer plus mais en ce moment j'ai pas trop de temps même si j'adorerais pouvoir continuer à discuter sur ce topic
 
Sinon je n'ai pas vu GV zibus mais l'effet de boost dont tu parles m'intéresses notamment lorsque tu parles du render to texture, quel est l'effet en fait ? Une déformation de ce qui apparaît derrière le boost ? Si c'est le cas tu penses que la scène est rendue dans une texture que le boost est une texture générée et qu'elle est utilisée via des dependant texture read pour modifier les coordonnées de texture dans la scène et donner ainsi cet effet de déformation ? Faudra que j'y jette un coup d'oeil à ce jeu..

heu je debarque un peu, et j'aimerais poser quelques questions tres différentes :
 
qu'est-ce que les T&L ? quel est l'avantage, l'incovénient ? y a t'il une meilleur solution  ?
 
 
Pourquoi,  dans un systeme, console de jeux ou autres, le processeurs centrale et le GPU ne sont pas cadencés a la meme fréquence ?? si un processeur tourne a 1 HGZ et que le GPU a 500 MHZ, en pourrait dire que lors de la transmition la processeur s'emmerde pendant la moitié du temps ?
 
Ne pensez vous pas pour une architecture  l'aveniur se presente sous la forme du "tout intégré" ? avec de la memoire directement dans le processeur ?

heu je debarque un peu, et j'aimerais poser quelques questions tres différentes :
 
qu'est-ce que les T&L ? quel est l'avantage, l'incovénient ? y a t'il une meilleur solution  ?
 
 
Pourquoi,  dans un systeme, console de jeux ou autres, le processeurs centrale et le GPU ne sont pas cadencés a la meme fréquence ?? si un processeur tourne a 1 HGZ et que le GPU a 500 MHZ, en pourrait dire que lors de la transmition la processeur s'emmerde pendant la moitié du temps ?
 
Ne pensez vous pas pour une architecture  l'aveniur se presente sous la forme du "tout intégré" ? avec de la memoire directement dans le processeur ?