Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Je suis d'accord, les lightmap laissent la possibilité d'utiliser différentes méthodes :
- depuis la création dynamique de la texture aux shaders
- utilisation du multitexturing ou rendu en plusieurs passes
- peut-etre la possibilité d'utiliser l'accumulation buffer:
mais les lightmap ne sont pas dynamique... (d'ou leur nom : light comme lumiere, map comme ... map ou texture quoi )
En fait le probleme de la lumiere c'est qu'on est obligé de faire plusieurs passes quelque soit la methode utilisée (sauf les lumieres openGL de base)
bah pour moi lightmap voulant bien dire "mapping de lumière" en gros je ne vois pas en quoi c'est ou ce n'est pas dynamique.
Il existe les "static lightmap" et les "dynamic lightmap".
Quake utilise les 2 depuis la première version, les ombres étant des "static lightmap" et les lumières générées par les tirs, les explosions etc sont des "dynamic lightmap".
Il va sans dire que générer dynamiquement une texture pour du lightmapping est consommateur de resources, c'est pourquoi il ne faut pas viser trop haut dans la résolution de la texture générée sous peine d'une chute des performances.
Une petite démo avec le code source ici pour ceux qui veulent : http://www.3ddrome.com/articles/dynamiclightmaps.php
PS: Je pense qu'utiliser un fragment program ou les shaders est la seule méthode qui permette de faire le rendu d'une lightmap en une seule passe, sinon au moins 2 même avec le multi-texturing
non non, l'origine du terme lightmap vient bien du fait que dans quake 1, les lumiere etait stocké dans des texture... pour plus d'info, lire le livre "programmation graphique c et assembleur" de michael abrash qui a travaillé sur quake 1 avec carmack, c'est tres interessant.
sinon même avec un fragment program, on est obligé d'effectué une passe par lumiere (ou alors il faut faire un fragment program qui prend en compte l'ensemble des lumiere du moteur... vraiment pas optimisé comme technique etant donné que ca oblige a calculer la luminosité pour des polygone qui ne sont pas forcement atteint par la lumiere...
Oki, thx pour l'info, je regarderai ça à l'occasion
Sinon pour l fragment program, je pensais bien sûr à 1 passe par lumière
sinon effectuer un "précalcul" pour déterminer quelles lumières affectent le polygone ne serait pas possible ?
bon, peut-etre un peu trop complexe pour ce qu'on en tire comme bénéfice
Merci pour les infos.
J'ai déja commencé la dessus, et j'ai implementé un lighting (dynamique) sur une seule passe ! j'explique
- pour chaque polygone, je teste s'il est visible ou non
- si oui, je remets son light map à 0
- je parcoure les lumières de la scènes,qui vont ajouter leur contribution à la texture
- sur l'unité de texturing 0 j'applique le diffuse map, et le lightmap sur l'unité 1
j'ai testé divers tailles de light maps, je crois que 16x16 est un bon compromis entre qualité et vitesse : j'atteins les 40 fps avec 25 polygones visibles et 9 lumières, et la géneration des lightmaps n'est pas du tout optimisé. est ce potable ?
40 fps m'a l'air potable avec 9 lumières, tu pourrais nous mettre un petit screen à l'ocaz histoire de voir ce que donne le rendu ?
En tout cas ton approche est intéressante, une petite amélioration à apporter éventuellement :
si j'ai bien compris tu initialises ton lightmap en le remplisant de 0, tu devrais plutot le remplir avec la valeur de la couleur ambiante.
Pour les screens, je vais essayer, mais je n'ai pas de site ou d'espace sur le web pour y mettre les images.
Mais les resultats sont trés convaincantes, un peu sombre mais réalistes.
Pour ta rq sur la lumière ambiante, j'explique :
je considère que chaque lumière a une composante diffuse LDC et une ambiante LAC, qui sont des vecteurs (r, g, b) de 0 à 1, et chaque polygone à une couleur diffuse PDC, et la contribution d'une lumière L se calcule ainsi :
LC = LAC + (X * LDC * PDC)
X est une valeur qui dépend de la distance qui sépare le pixel de la lumière, et de l'inclinison de cette dernière.
Et donc, je dois initialiser le lightmap à 0 car chaque lumière a une composante ambiante, qui plus est dynamique !
Autre chose, je pense que 40 fps pour 25 polygones, c'est pas tellement prometteur. (si je précalcule les lightmaps, le fps saute à 240)
quelques petites reflexions sur ta technique :
- tu recalcule la lightmap a chaque passe et tu doit donc l'envoyer à la carte graphique, avec quelques polygone ca va bien, mais envoyer X mille textures a chaque frame la ca ne passera plus...
- tu ne peut plus faire d'addition de lumieres, hors c'est un des gros atout de l'eclairage en plusieurs passe car il permet d'implementer facilement du HDR par la suite (avec un float buffer on peut depasser 1 dans chaque composante, ce qui permet de calculer du HDR avec blooming + tone mapping facilement...)
- tu ne peut pas implementer de bump mapping avec cette methode
sinon le coté sombre vient du fait que tu multiplie la lumiere par la texture diffuse, c'est tout a fait normal, ca marche comme ca avec le lightmapping.
d'ailleurs cette methode est tres exactement la methode utilisée par carmack dans quake 1 pour gerer ses lumieres dynamiques en mode software
Ok, je suis d'accord.
Sinon, qu'elle est la meilleure méthode ?
a priori, à l'heure actuelle, la meilleure methode semble etre celle de Doom 3 (carmack inside
[/code]
on affiche l'ensemble des faces visible dans le Zbuffer (ecriture dans le color buffer desactivé pour plus de vitesse)
activation du blending additif
pour chaque lumiere visible
pour chaque face visible
si la face est atteinte par la lumiere (simple a calculer pour les lumieres spheriques)
on affiche la face (eclairage calculer par un fragment program)
fsi
fpour
fpour
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
ça devient intéressant.
Une question cependant : T'as dit :
Tu en est sur ? car j'ai joué à DOOM III sur ma Radeon 9200, et jusqu'à maintenat, j'etais sur que les ATI d'avant 9500 ne géraient pas le fragment shader ou programs !eclairage calculer par un fragment program
en fait selon la carte graphique l'eclairage n'est pas calculé avec la même methode : sur GeForce2,3,4 c'est du DOT 3 + combiner NV, sur radeon < 9500 c'est pareil mais avec l'equivalent des combiner NV chez ATI, et sur le reste des cartes, c'est du fragment program
Donc y'a pas moyen d'echapper aux extensions spécifiques !
juste par curiosité, et come je suis sur une Radeon 9200, c'est quoi l'équivalent des combiners NV sur les ATI ?
Je ne suis pas d'accord, c'est "juste" une volonté de Carmack de vouloir optimiser à fond pour toutes les cartes possibles.Envoyé par Modjo
Il existe un CodePath plus lent utilisant uniquement le "multi-texturing" et le "multipass rendering", utiliser les extensions spécifiques est purement de l'optimisation.
Qu'en est-il des cartes autres que ATI ou NVIDIA qui n'ont pas accès aux extensions ? elles utilisent les extensions "officielles"
Oui mais produire du code compatible avec toutes les cartes mais qui est super lent ne va pas arranger les choses, non ? dans mon cas, c'est clair qu'il faut optimiser à fond mon code car les performances sont très basses, surtout qu'on est dans le cas d'un moteur 2D pas assez gourmand.
inon, s'il y' a un autre alternative pour l'éclairage, je suis toujours preneur !
et attention, selon les code path de Doom 3, il y a des effets qui ne sont pas activable, par exemple l'effet de heat haze n'est accessible que pour le code path ARB2 (vertex + fragment program ARB), et le code path ARB (celui de base prevu pour GeForce 2 au depart) ne permet pas d'avoir l'eclairage speculaire... par contre l'utilisation des extention lui permet de faire d'autres effets qui n'aurait pas été possible en mode ARB (par exemple l'eclairage speculaire sur GeForce 4 realisé grace au combiner...)
bref les extention c'est bien pour faire pleins d'effets de fou a la sortie de la carte mais apres c'est preferable d'utiliser du EXT ou de l'ARB...
Bonjour, et merci bafman : tes posts sont un vrai régal.
Pour l'eclairage, j'ai pu bricoler les composantes diffuses et ambiantes, mais en ce qui concerne la composante spéculaire, je suis un peu dans l'obscurité. quelqu'un aurait des tuyaux ?
C'est vrai qu'on sent que bafman a du deja coder un moteur 3D. Bafman on peu avoir un screenshot de ton moteur lol ?
pour l'eclairage speculaire le principe est simple : c'est exactement la même chose que le bump Dot 3 en fait.
en gros l'eclairage speculaire consiste a prendre le demi angle entre le vecteur pixel->vue et pixel->lumiere... facile a dire mais comment le faire ? tout simplement en placant la lumiere (la cube map de normalisation en fait) a mi chemin entre la position de la camera et la lumiere réelle... et voila on a notre demi angle, il ne reste plus qu'a effectuer le même calcule que pour le Bump et a l'ajouter (blending additif ou addition dans un fragment program) à la scene... Mais le probleme c'est qu'on a du coup une lumiere speculaire tres (trop) forte, il faut la mettre a une puissance, et c'est justement la le probleme, car pour le mettre a une puissance il n'existe pas 36 solution : fragment program ou combiner...
en fait il existe bien une solution qui consiste a effectuer 2 fois le calcule de speculaire et a multiplier le resultat, mais ca double le calcule et ne mette le resultat qu'a la puissance 2 alors que le speculaire est generalement a une puissance de 8 ou de 16...
enfin bref, pour faire simple, le speculaire c'est :
- trouver le demi angle en placant la cube map de normalisation entre la position de la camera et de la lumiere
- effectuer le même calcule que pour le bump avec le demi angle
- mettre le resultat du calcule a une puissance donnée
- ajouter le tout a la scene...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager