Problème de ShadowMapping

Version imprimable

19/11/2008, 22h34
Clad3

Problème de ShadowMapping

Bonjour à tous.

Pour résumé, j'ai récupérer le code d'un collège de classe pour ntore projet, il était chargé d'implémenter le ShadowMapping. Il m'a fait un beua copier/coller d'un site web et là je suis en train de voir comment me débrouiller avec la chose. J'ai compris le principe, a peu près suivit les diverse phases mais j'ai encore quelques imcompréhensions.

1. J'utilise des outlinedFOnt chargé avec wglUseFontOutlines() ; en mode fil de fer pas de problème ; par contre en mode polygone, ca fait foirer le rendu de ma scène ( je supose un manque de normals) Y a til moyen de remédier à ce problème? Dois-je me passer des OutlinedFont crée de cette façons ?

2. J'ai constaté que le code que mon ami m'a passé change beaucoup d'états d'opengl sans forcément les remettres comme ils étaient avant... je suis en train d'y remédier et je cherche à organiser mes phases de rendus au mieux.
Est-ce une bonne idée de faire 2 fonctions de Draw() pour chaqun de mes objets .... 1 pour les rendus de calculs d'ombre et une pour les rendus sans ombres ?
Y-a-til des choses dont je peux me passer (si je procède ainsi) lors des phases de rendus d'ombres (textures par exemple ?)

Je suis preneur de tout conseils pour organiser mes programmes autour de ce calculs d'ombres ;o) (qui par ailleurs ; marche à peu près correctement )

Merci d'avance .
20/11/2008, 04h40
LeGreg

Citation:

Envoyé par Clad3

1. J'utilise des outlinedFOnt chargé avec wglUseFontOutlines() ; en mode fil de fer pas de problème ; par contre en mode polygone, ca fait foirer le rendu de ma scène ( je supose un manque de normals) Y a til moyen de remédier à ce problème? Dois-je me passer des OutlinedFont crée de cette façons ?

Help us help you.

Ce que tu racontes n'a pas le moindre détail qui permettrait d'avoir la moindre idée de ce qu'est ton problème. On imagine que ça implique des outlined fonts, mais c'est tout. C'est quoi "foirer le rendu de ma scène" ?

Citation:

Envoyé par Clad3

2. J'ai constaté que le code que mon ami m'a passé change beaucoup d'états d'opengl sans forcément les remettres comme ils étaient avant... je suis en train d'y remédier et je cherche à organiser mes phases de rendus au mieux.

un code de rendu n'a pas obligation à "remettre les états comme ils étaient", et c'est le plus souvent contre productif.

En fait la seule obligation c'est de mettre les états qui sont nécessaires pour le prochain draw call.
Bien entendu il faut un "système" pour éviter
1- d'oublier de mettre la machine à état OpenGL dans une configuration particulière (par exemple oublier que l'on a activé le blending avant de rendre des objets qui sont sensé être opaques et qui donc n'ont pas besoin de blending).
2- de changer les états trop souvent et de manière redondantes (par exemple activer le blending, puis le désactiver avant d'avoir tracé quoi que ce soit) ce qui aura au final un impact sur les performances.

Bien entendu c'est 1 qui est à mettre en place en priorité et 2 qui est nécessaire pour avoir un jeu jouable dans les meilleures conditions.

Exemple de système possible : un système où chaque état fait partie d'un "matériel"/"transform"/"paramètres par objet"/"contexte de rendu". Si un matériel partage une partie de la configuration avec l'objet tracé précédemment il n'y a alors pas besoin de remettre à jour les états correspondant.
Par exemple, toujours sur le blending. Si on trace tous les objets opaques en premier il n'est pas nécessaire de désactiver le blending entre chaque nouvel objet tracé. Il suffit de le désactiver une seule fois au début du tracé des objets opaques puis le remettre lorsque tu auras à tracer un lot d'objets transparents.

Citation:

Envoyé par Clad3

Est-ce une bonne idée de faire 2 fonctions de Draw() pour chaqun de mes objets .... 1 pour les rendus de calculs d'ombre et une pour les rendus sans ombres ?
Y-a-til des choses dont je peux me passer (si je procède ainsi) lors des phases de rendus d'ombres (textures par exemple ?)

Si tu utilises les shadow depth maps, ce n'est pas seulement une bonne idée, c'est la seule solution.
Tu fais une première passe pour remplir la depth map, et une deuxième passe où tu utilises la depth map comme texture pour faire l'éclairage et l'ombrage de la scène "normale". Pour la phase d'ombre, tu n'as besoin que des infos de profondeur. La couleur n'a aucune importance donc oui la texture peut être ignoré.. dans la mesure où elle n'affecte pas la visibilité de l'objet (exemple si tu as des feuilles avec un masque de visibilité alpha qui utilise une texture). Si il y a des objets dont la visibilité partielle est déterminée par une texture alors tu dois utiliser cette texture lors du rendu pour avoir une depth map précise. De même si tu fais du displacement mapping ou tout autre méthode qui modifie la géométrie/profondeur/visibilité.

LeGreg
20/11/2008, 07h25
Clad3

Merci des réponses :

Citation:

1. J'utilise des outlinedFOnt chargé avec wglUseFontOutlines() ; en mode fil de fer pas de problème ; par contre en mode polygone, ca fait foirer le rendu de ma scène ( je supose un manque de normals) Y a til moyen de remédier à ce problème? Dois-je me passer des OutlinedFont crée de cette façons ?

En fait, l'éclairage de ma scène n'est plus bon, je ne saurais pas dire pourquoi ni comment ca l'impact exactement . A première vue, il y a beaucoup trop d'ombres au final sur ma sène ; mais selon les modification que je fais dans mon code, je peux simplement avoir un résultat avec de multiple artefact de couleur blanches parmis les ombres). A priori, je dirai que ca vient d'un manque de "Normales" mais je n'en suis pas certain . Le problème est uniquement l'appel à ma calllist de rendu des fonts. J'ai utilisé le mode WGL_FONT_POLYGONS en tant que format pour mes données ; ce qui d'après le web , semble la bonne solution pour obtenir des normales.

Concernant mon problème d'état openGL, en réfléchissant hier soir, j'en suis arrivé à l'idée suivante : finalement ne pas faire plusieur fonction de rendu mais une seule, et laisser la gestion des état openGL non pas à mes objets ( sauf cas particulier) mais à mes moteurs (gestionnaire) de rendu, que j'apellerai entre chaque phase de rendu. Ca se tient ? En opossition à : Chaque objet met à X les état dont il a beosin en début de sa fonction de Rendu et les remet à "normal" en fin de son rendu.
( J'élimine pour l'instant l'optimisation que tu mentionne, de regrouper les objets à rendre par état de rendu par grand manque de temps, mais je garde l'idée sous le coude :) )

Citation:

Si tu utilises les shadow depth maps, ce n'est pas seulement une bonne idée, c'est la seule solution.

En fait, je me suis mal exprimé (ou j'ai du mal comprendre ta réponse).
Ce que je disait c'est que , de toutes façons j'apelle 3 fois une fonction Render() mais que j'avais envisagé de faire des fonction spécifique de rendu par objet en fonction du type de rendu souhaité. Mais le problème de cela, c'est que ca ne me permet plus du tout de faire ce que j'énonce plus haut dans ce même post : c-a-d de gérer mes états avec mes moteurs de rendus et non l'inverse.
22/11/2008, 01h02
TanEk

Pourrais-t-on avoir une image de ton rendu pour voir les artefacts ? A mon avis le problème vient du z-fighting et il faut peut-être rajouter de l'offset (glPolygonOffset).
22/11/2008, 23h24
Clad3

Je suis en trin de régler un autre problème sur mes fonts, dés que c'est fait, je repasse au shadowmapping et je fais un screen du problème ! Stay tuned :)
23/11/2008, 11h05
Clad3

2 pièce(s) jointe(s)

Voila ce que cela donne , sans outlined font à l'écran et avec (en pièce attachées). Les résultat sont les même sans l'affichage du quad texturé, donc n'en tenez pas compte .
23/11/2008, 12h50
TanEk
Je crois voir deux choses sur ton rendu :
- le z-buffer est désactivé dans le second rendu avec ombre, il faudrait le réactiver
- tu as sans doute un gros problème lors de la génération de ta texture de profondeur, pour la vérifier, affiches-là et vérifie qu'elle est correcte
- si oui alors c'est ta matrice de projection de la texture qui est mauvaise
Je ne peux pas t'en dire plus désolé, j'ai déjà implémenté le shadow mapping mais je n'en suis pas pour autant un expert ;).
23/11/2008, 13h11
Clad3

Citation:

le z-buffer est désactivé dans le second rendu avec ombre, il faudrait le réactiver

Tu veux dire dans ma seconde passe de rendu lors des calculs pour la shadow map? (si tu parles de ca, j'ai un glEnable(GL_DEPTH_TEST) avant ma premire pahse de rendus ; qui n'est jamais remis a false à priroi)
Ou dans mon second screenshot? (si tu parles de ca, c'est exactement le même code que pour le premier SS sauf la partie d'affichage des outlined font ; qui ne change aucun état GL )

Citation:

tu as sans doute un gros problème lors de la génération de ta texture de profondeur, pour la vérifier, affiches-là et vérifie qu'elle est correcte

Pas bête du tout ca, je vais me débrouiller pour l'afficher :)

EDIT : Petite précision, si je laisse mon apell à la fonction d'affichage de mon fontOutlined et que dans celle-ci je commente juste l'appel à la displaylist (callist() ), l'affichage est normal.
23/11/2008, 13h26
TanEk

Citation:

Envoyé par Clad3

Tu veux dire dans ma seconde passe de rendu lors des calculs pour la shadow map? (si tu parles de ca, j'ai un glEnable(GL_DEPTH_TEST) avant ma premire pahse de rendus ; qui n'est jamais remis a false à priroi)
Ou dans mon second screenshot? (si tu parles de ca, c'est exactement le même code que pour le premier SS sauf la partie d'affichage des outlined font ; qui ne change aucun état GL )

Ton second screenshot m'a l'air correct il me semble non ? Je parle en fait du premier rendu. Quand tu rends ta scène normalement, le test z-buffer ou l'écriture z-buffer n'a pas l'air actif. En effet, on voit les parties cachées du rectangles et le cylindre j'ai l'impression que l'on voit les faces arrières. Mais ce n'est qu'une impression, je me trompe peut-être.

Citation:

EDIT : Petite précision, si je laisse mon apell à la fonction d'affichage de mon fontOutlined et que dans celle-ci je commente juste l'appel à la displaylist (callist() ), l'affichage est normal.

Je n'ai jamais utilisé cette fonction donc je ne peux pas t'aider de ce côté. Désolé.
23/11/2008, 18h31
LeGreg

Citation:

Envoyé par TanEk

[*]le z-buffer est désactivé dans le second rendu avec ombre, il faudrait le réactiver

Plutot que le zbuffer il s'agit peut-etre simplement du back face culling qui a changé de sens. Peut-être que la routine qui affiche les polices texte 3D mettent le back face culling sur clockwise tandis que son rendu a besoin de counter clock wise (ou vice et versa).

LeGreg
23/11/2008, 20h56
Clad3

Arg, tu as vu juste, la display list créer par l'appel à la fonction de chargement de font me renvoyait des poly en sens inverse du culling du reste de mon programme :) Bon j'ai encore un petit probleme de coordonée de texture qui reste dnas ma scène mais je pense que le principal est réglé, merci !

Au final j'ai donc 2 fonctions de rendu , Je fais ma première passe de rendu avec une fonction qui ne rend que les poly et dans les deux dernières passes j'ajoute texture, normale et tout le bordel :)

Allez j'y retourne, encore merci , je crois que c'est le genre de truc auquel j'aurais mis un sacré bout de temps à penser !
23/11/2008, 22h13
Clad3

Hum, en fait je retourne à un problème dont je m'étais apperçu au début : j'ai de grosse difficulté à afficher des objets texturés avec mon rendu de sahdowmapping. Etant donné que pour la dernière phase de rendu, on bind une texture déjà, je ne vois pas trop comment faire pour en afficher ... multitexturing peut-etre?
(j'ai essayé de bidouiller +/- pour qu'a chaque dessein d'un objet texturé, je désactive les paramètre de texture courant ( donc ceux du sahdowmaping) mais
1) c'est lourd et pas propre
2) j'ai testé uniquement pour un objet qui génèrait de l'ombre et pas qui en recevait et mon petit doigt me dit, que si je fais ca pour un objet ombré, sa texture va bien s'afficher mais il va perdre toute les ombres qu'il devrait avoir :)

Edit: A y réfléchir , je pense effectivement qu'il va me faloir du multitexturing ... je vais regardez ça, si quelqu'un s'y opose, qu'il se lève et le dise ou se taise à jamais :D
23/11/2008, 23h25
LeGreg

multitexturing ça me semble la moindre des choses.. ou mieux encore pixel shader/fragment program..

LeGreg
23/11/2008, 23h32
Clad3

1 pièce(s) jointe(s)

Voila, multitexuring activée et ca commence à être pas mal :)

Ca reste encore assez rudimentaire ( notamement au niveau de l'aliasing j'ai l'impression ... mais j'ai déjà une shadowmap de la taille de mon viewport ... ).

Juste un petit point de détail : pour l'instant j'ai mes 2 unité de textures ( la zéro : standard et la une : ombre) en mode Gl_MODULATE ). Sans cela, pas moyen d'avoir un rendu correcte ; le seul "problème" est que si j'ai un quad coloré en dessous de mes texture, le résultat de ma texture ombrée prend la teinte du quad... ma question est : est-ce vraiment un problème ? En effet, si je veux une texture qui face "écran", je met mon quad en blanc... et je me dis que ca peut toujorus servir de faire un mélange de couleur au besoin. j'ai le bon raisonement ou alros en général on préfère avoir comme comportement par défaut le fait qu'une texture remplace la couleur de base et de gérer le cas ou l'on veux le mélange à part?
C'est du point de détail et il ets possible que la réponse dépendent du programme/(eur?) mais bon :) C'est juste histoire de bien être sur que du MODULATE pour mes deux texture est la bonne facons de faire !

Merci à tous :)
24/11/2008, 06h25
LeGreg

modulate c'est * (multiplier par)
add c'est + (additioner).

Il n'y a pas de "rendu correct", il y a ce que tu veux et à partir de ce que tu veux tu ponds une combinaison de +, *, pow, etc.

Donc déjà détermine quelle équation tu veux (ce n'est qu'UN exemple : diffuse = light dot normal * shadow value, couleur finale = diffuse * texture) et vois si tu peux faire tous ces calculs en une seule passe avec les fonctions dont tu disposes.

Et dès que possible laisse tomber les fonctions précablés (fixed function pipeline), le présent et l'avenir c'est les shaders/programmes qui te permettent d'écrire exactement ce que tu veux.

LeGreg
24/11/2008, 21h25
Clad3

2 pièce(s) jointe(s)

Merci pour la précison, je penserai à passer en version shader une fois que la version de base marchera parfaitement et ce n'est toujours pas le cas :)

J'avais un rendu fixe, avec une seule position d'objet et de caméra. Maintenant je fais varier tout ça et je découvre des choses étranges ...
Mwarf, ça commence a devenir compliqué tout ça :/ Si j'avais su qu'il y avait autant de complications possible au menu, j'aurais pris un autre restaurant :D

Edit :
Par exemple, avec les photo ci-dessous, je m'attendrai à avoir ne zone d'ombre uniquement en face du quad et pas égalemetn sur ces côté, étant donné que j'ai une lumière direcitonelle (pas un spot). J'ai beau réfléchir au pourquoi du comment, je ne vois pas comment il en arrive à me trouver ce genre d'ombre. [ ce n'est pas un cas isolé, dans pas mal d'autres configurations, les résultats ne sont pas conformes à mes attentes]
25/11/2008, 10h12
shenron666

penses tu à prendre en compte la position de la caméra dans tes calculs de projection de la shadowmap

Citation:

Envoyé par Clad3

j'ai une lumière direcitonelle (pas un spot).

dans ce cas c'est une lumière omnidirectionnelle ;)

Citation:

Envoyé par Clad3

Merci pour la précison, je penserai à passer en version shader une fois que la version de base marchera parfaitement et ce n'est toujours pas le cas :)

les shaders pourraient te simplifier bien des choses dans la combinaison des textures
tu peux personnaliser tes calculs contrairement aux fonctions cablées
25/11/2008, 10h56
bafman

Citation:

Envoyé par shenron666

dans ce cas c'est une lumière omnidirectionnelle ;)

on peut faire des lumière directionnelles non ponctuelles (pour simuler l'effet du soleil par exemple)
25/11/2008, 13h24
shenron666

ah oui en fait une lumière simulée juste par une direction
je devais avoir la tête dans un truc pas clair pour ne pas y avoir pensé
surtout que c'est plus que courant :aie:

merci Bafman de m'avoir éclairci les idées :mrgreen:

Citation:

penses tu à prendre en compte la position de la caméra dans tes calculs de projection de la shadowmap

Dnas ma phase d'initialisation ( à chaque frame), j'ai ceci :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
glActiveTexture(GL_TEXTURE1);
	glEnable(GL_TEXTURE_2D);
	glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
	glTexEnvi(GL_TEXTURE_ENV, GL_SRC0_RGB, GL_PREVIOUS);
	glTexEnvi(GL_TEXTURE_ENV, GL_SRC1_RGB, GL_TEXTURE);
 
	glBindTexture(GL_TEXTURE_2D, shadowMapTexture);
	glTexImage2D(	GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT, shadowMapSize, shadowMapSize, 0,
					GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE, NULL);
 
	//Calculate & save matrices
	glPushMatrix();
 
	glLoadIdentity();
	gluPerspective(45.0f, (float)windowwidth/windowheight, 0.1f, 100.0f);
	glGetFloatv(GL_MODELVIEW_MATRIX, cameraProjectionMatrix.coeff);
 
	glLoadIdentity();
	Application::Instance().m_RenderTask.Cam.Focalize();
	glGetFloatv(GL_MODELVIEW_MATRIX, cameraViewMatrix.coeff);
 
	glLoadIdentity();
	gluPerspective(45.0f, 1.0f, 2.0f, 8.0f);
	glGetFloatv(GL_MODELVIEW_MATRIX, lightProjectionMatrix.coeff);
 
	glLoadIdentity();
	gluLookAt(	lightPosition.x, lightPosition.y, lightPosition.z,
				0.0f, 0.0f, 0.0f,
				0.0f, 1.0f, 0.0f);
	glGetFloatv(GL_MODELVIEW_MATRIX, lightViewMatrix.coeff);
	glPopMatrix();

On notera surtout les 3 lignes :

Code:

1
2
3
4
 
	glLoadIdentity();
	Application::Instance().m_RenderTask.Cam.Focalize();
	glGetFloatv(GL_MODELVIEW_MATRIX, cameraViewMatrix.coeff);

Dans la fonction focalize(), je fais juste un gluLookAt qui va bien