Salut, je me prend le chou avec OpenGL et les sources de lumières... J'ai une petite map avec plusieurs sources définies et un des problemes que je rencontre c'est que les sources ponctuelles traversent tous les murs. J'ai essayé en désactivant le blending, en modifiant les matériaux des murs avec glMaterial etc et je n'arrive vraiment à rien. Y'a t'il un moyen simple pour faire ça ou bien il faut coder en dur ?! Je précise que je ne parle pas (encore) d'ombre, je voudrais juste que mes lumières ne traversent pas les murs. Merci  

si la lumière ne traverse pas les solides (murs), c'est bien une gestion des ombres, non ?

c'est normal bien venu dans le monde des API 3D temps réel

il faut que tu décompose ton niveau en salles, pour chaque salle et les objets contenus, tu élis les sources de lumière pertinentes, et de préférence tu fais des tests d'occlusion pour savoir si tes salles sont dans le champ de vision (boundingbox, portal vis à vis du frustum de vision). (tu peux aussi construire des tables de visibilitées entre salles de manière statique)
 
après si tu veux un modèle d'éclairage dynamique plus exact, tu fais des shaders pour de l'éclairage par pixel, et pour chaque source de lumière ponctuelle tu utilises une cubemap Z pour connaitre les surfaces les plus proches à la sources, et donc savoir quand tu traçes une surface du monde si tu est éclairé ou pas. (ou tu joues avec des volumes d'ombres pour connaitre les surface dans les zones d'ombres, à postériori quoique pas forcément)
 
si tu veux te contenter d'un modèle d'éclairage statique, tu utilises des textures de lighmap qui couvrent la surface des pièces, qui sont générée par un moteur de radiosité en offline.
 
il te manque plus qu'un arbre BSP pour accélérer les requêtes de collisions...
 
et plop t'as refais Quake (si tu choisi l'approche statique)
 
des heures de jeu en perspective non ?

Oulala mais c'est hyper compliqué
 
Je vais peut-etre répéter ce que tu as dit ou dire une connerie, mais c'est pour voir si j'ai bien compris :
 
Pour avoir un résultat minimalement correct et adaptable à la map (que je sois pas obligé de modifier le code de l'éclairage si je déplace une salle) il faudrait donc que je tire un trait entre la position du joueur et la source lumineuse, si y'a un obstacle entre les deux je désactive tout simplement la lumière... mais le problème c'est par exemple que si je suis dans une salle avec une porte ouverte et qu'il y a une lumiere dehors, si je me cache derriere un mur c'est tout noir et dès que je viens devant la porte ça devient éclairé. Savez vous comment résoudre ça sans trop de difficultés ? Car en fait il me semble qu'il faudrait lancer un rayon entre la source et chaque pixel, dans le cas ou je serais derriere la porte la source serait donc désactiver pour moi mais activé pour le mur d'en face qui lui me refleterait un peu de la lumiere et serait donc éclairé... c'est ça qu'on appelle lightmap ?
 
Par rapport à ce probleme, je l'ai en fait déjà en quelque sorte actuellement, mais je ne sais pas du tout d'ou ça vient ou si c'est lié. Je regarde par exemple un mur, il est très sombre et si je tourne la tête de quelques pixels il devient subitement éclairé

Je m'incruste:
 
bjone: pour la construction d'un arbre bsp, il faut savoir découper un triangle par un plan (ou bien je n'ai pas compris): il y a un algorithme éfficace pour cela ?

 
la light map est en fait générée à la création du level: on calcul pour les sources fixes de lumière (qui ne changeront donc pas en temps réel) une texture que l'on superpose à la texture de mur par exemple, pour simuler un éclairage.

Ok, et le pixel shading c'est la version dynamique de la lightmap ?

disons que c'est la version dynamique de l'éclairage;
 
plus de détails là //nehe.gamedev.net/data/articles/article.asp?article=21
 
et plus généralement:
http://nehe.gamedev.net/ (excellent site dont je te recommande chaudement l'éntière la lecture).

Merci à vous pour votre aide
Je connaissais déjà nehe mais c'est un peu long et compliqué pour moi pour l'instant

ben si tu commences du début (lesson1), tu verras que c'est super facile: le code est commenté, etc.
 
C'est juste long (mais on a rien sans rien).

 
oulà non, le critère d'éclairabilitée (ouch compliqué ça) est indépendant du point de vue.
quand je parles des tests de visiblité c'est pour rejeter les éléments du monde qui ne sont pas visibles et qui n'ont pas a être traité par la suite. (ça ne change rien à ton problème, c'est un principe d'optimisation global).
 
la philosophie générale c'est que lorsque tu as une source de lumière, tu dois être capable de déterminer le lot de géométrie impactée par cette lumière, si tu ne veux pas avoir d'éclairages bizarres.
ou plustôt réciproquement, par géométrie tu dois être capable de déterminer le lot de sources de lumières pertinentes a prendre en compte.
 
dans le cas d'un niveau en intérieur, il faut décomposer ton niveau en entitées: salles/décors dans la salle, acteurs, etc.... et déterminer les sources pertinentes impactant l'éclairage de ces entitées.
 
généralement c'est indépendant du point de vue.
 
donc par exemple si déjà tu fais un système d'organisation de salles, tu testes pour chaque salle puis chaque élément de la salle les lumières a utiliser.
 
c'est pour ça que généralement on utilise des méthodes plus ou moins assez chaudes.
 
A toi de déterminer le niveau de dynamicité et les artefacts d'éclairages provoquées par les méthodes sélectionnées que tu peux tolérer au rendu.

 
les shaders sont des programmes éxécutés au niveau vertex, pixel/fragment, puis bientôt avec D3D10 au niveau primitive géométrique (point sprite/ligne/triangle).
 
ces programmes sont éxécutés localement au gpu et remplaçent 90% de l'aspect "machine à états" des API.
 
l'avantage est que beaucoup de limites sont levées et cela permet une plus grande complexité & lattitude d'approches calculatoires.

 
bah je sais pas, fais un petit dessin avec un triangle et ses vertexs, un trait qui coupe le triangle, et tu regardes comment générer les vertexs aux (deux) points d'intersection entre un segment du contour du triangle et le plan.

, genre thalès quoi...

oué walla c'est un calcul de barycentre par rapport à la distance au plan. (vu dans un autre sens)