Dans les tutos qui traitent des lightmaps, ils disent toujours qu'il faut un lightmap par surface. Mais que représente exactement une surface? Un seul triangle? Ou un objet?
 
Parce que si ça représente un seul triangle, je vois mal comment je pourrais mettre en mémoire plusieurs milliers de textures, même si celles-ci sont assez petites.
 
Donc si quelqu'un pouvait me dire comment marche les lightmaps dans une scène (on oublie pour le moment les données des lightmaps, on s'occupe juste de leur disposition). J'ai du mal à saisir à quoi peut s'applique au maximum une seul lightmap, et comment les créer pour une scène.
 
Merci.

une lightmap par surface ca peut vouloir dire  
1- tu ne peux pas partager des lightmaps entre plusieurs
surface (logique )
2- tu n'as pas pour le moment
envie d'avoir plusieurs lightmaps pour une surface meme si l'idee
peut te titiller plus tard.
 
De plus rien ne t'oblige d'avoir une seule lightmap par texture!
En general comme les lightmaps couvrent des surfaces de tailles diverses et sont de resolution moindre qu'une texture normale
on les regroupe dans des textures plus grosses.
 
A+
LEGREG

tu peux aussi chercher les lightmaps identique et donc virer les doublons

bin l'idée à l'origine des lightmaps, c'était de simuler des éclairages complexes avec peu de triangles.
 
par exemple tu prends un mur "plan" de quake 1, ou tu as que 2 triangles, dans les outils de "compilation" dèrrière l'éditeur de niveau, le générateur de lightmaps va créer une texture d'une certaine résolution, puis il va:
 
- paramétrer chaque pixel de coordonnée u,v de cette lightmap en fonction de la position spaciale du "plan" du mur.
 
- itérer à travers tous ces pixels et calculer en fonction du point x,y,z dans l'espace assigné au pixel, l'éclairage en ce point... (un x,y,z évolue au fur & à mesure que tu fais les pixels en u,v)
 
- l'éclairage, comme d'hab, consistant à faire le produit scalaire entre la normale en ce point (qui est constante sur tout le plan d'ailleurs) avec le vecteur point 3d->lumière (normalisé).
 
si le vecteur point 3d->lumière entre en intersection avec des éléments du décor (escalier, poutre....), l'éclairage de cette lumière n'est pas comtabilisée dans la somme finale...
 
c là ou la lightmap est puissante, il est actuellement "impossible" de calculer en temps réel l'intersection entre le vecteur vertex->lumière et d'autres polygones...
 
mais symétriquement, la lightmap est par essence statique.

En fait les lightmaps actuelles
sont calculees de maniere beaucoup plus compliquees
que ca.. (methodes d'illuminations globales)
La plupart des programmeurs prefereront utiliser
des outils tout faits (plugins pour modeleurs, QeRadiant ou autre editeur de niveau) qui leur sortiront les lightmaps belles et correctes que de programmer leur propre methode d'illumination globale.
 
Le probleme que posent les lightmaps:
- essentiellement statiques surtout si calculees de maniere
compliquees, utilisation de la memoire non negligeable (stockage des textures)
- ne couvrent que le terme diffus de l'eclairement d'une surface. Alors que l'eclairage est toujours plus complique que ca (anisotropique, emission, reflexion, refraction, diffraction, chromatisme, fluorescence etc..). Et il est parfois difficile de combiner plusieurs methodes.  
 
Je ne sais pas si Doom3 par exemple utiliseras encore les lightmaps par contre il fera la part belle a l'eclairage par pixel (grace aux pixels shaders).
 
A+
LEGREG

C'est vrai que l'éclairage par pixel sera un grand pas en avant, mais est-ce que l'on pourra juste avec lui afficher la radiosité, etc... comme on peut le faire avec les lightmaps?

qu'est-ce t'entends par la radiosité ?
 
pour doom3, ce sera probablement des couches de dot3 de porc, et les ombres portées (en temps réel) semblent être en stencil buffer vu la vidéo lors de la sortie de la gf3 sur mac.
 
en fait il se peut qu'il y ait des lightmaps statiques + grosse tessellation + éclairage par pixel (dot3&co..)+ ombres protées en stencil pour les streums/pylones/poutres/structures/grillages...
 
enfin c carmack comme d'hab, fidèle à lui-même....
 
enfin c marrant pour les lightmaps, quand quake1 est sorti, le choix était de surchager le fillrate pour réduire le nombre de polygones...
dans une interview, un des programmeurs avec carmack avait dit qu'on les avait pris pour des fous à traçer la scène 2 fois

La radiosité est une méthode de calcul de l'illumination. C'est une des méthodes les plus fidèle. Mais il vaux mieux la combiner avec d'autre méthodes (lancé de rayon) car elle est un peu "plate".

 
Tu as le choix entre deux methodes:
- une methode globale ultra realiste mais
irrealisable en temps reelle et non view-dependant
(hors dans une scene 3D une petite voire bonne partie de l'eclairement depend du point de vue)
- une methode semi-locale qui permet de realiser des effets
d'eclairages suffisamment realistes pour etre credibles
(la radiosite etant limitee au terme ambiant, le reste
etant simule en ombre dynamique, phong ou blinn par pixel etc..). L'agencement des lumieres peut etre tres complique mais ca reste realisable en temps reel.
 
illustration: le renderer de base de 3DSMax est limite aux methodes semi-locales (plus raytracing optionnel) mais le rendu est ameliorable grandement si l'on utilise les methodes d'illuminations globales. (plugin luminaire gratuit: http://www.maxshade.com/ , ou les produits ExLuna : http://www.exluna.com/products/bmrt/ )
 
Enfin, je dis ca mais je ne sais absolument
pas ce que nous reserve l'avenir
(vu que beaucoup de choses qui nous paraissaient
difficiles d'acces il y a quelques annees,
se font quasiment sans probleme maintenant..)
 
A+
LEGREG