Discussion :

[supergrey]

Bonjour, j'utilise plusieurs vertexshaders, le premier me permettant de rendre un personnage skinné et utilisant donc plusieurs matrices, il est associé à un pixelshader pour générer un depth map pour le rendu d'ombres et à un autre vertexshader similaire est associé à un autre pixelshader pour le rendu final.

Le problème apparait quand une partie du personnage sort du champ de la lumière (champ de la caméra du premier rendu), certains vertices se retrouve à l'origine (0,0,0) et même en revenant dans le champ de la lumière ils reste à l'origine.

J'ai localisé le problème dans le 1er vertexshader:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

result.vertposcamspace=mul(float4(vertpos,1), viewprojMatrix)

si je remplace par le code suivant le problème n'est plus:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

result.vertposcamspace=float4(1,1,1,1)

Si quelqu'un a la moindre idée d'une solution, ou idée, il est le bienvenue.

Merci

[LittleWhite]

Bonjour,

Je ne suis pas encore très chaud en HLSL, mais il ne faudrait pas multiplier votre vertex avec la matrice de WorldViewProjection ? au lieu juste d'une matrice ViewProjection ?

[supergrey]

Oui, en fait "vertpos" est déjà multiplié par la matrix "world".
J'essaye de voir si c'est le vertexbuffer qui est corrompu ou les matrice, mais je ne comprend pas comment le GPU peut modifier des données en mémoires...

[stardeath]

bonjour,

quelle version de directx?
quelle version des shaders?

as tu testé un débogage sous pix?

là ça fait assez court pour identifier un problème XD

[LittleWhite]

Oui, en fait "vertpos" est déjà multiplié par la matrix "world".
J'essaye de voir si c'est le vertexbuffer qui est corrompu ou les matrice, mais je ne comprend pas comment le GPU peut modifier des données en mémoires...

Le GPU ne va rien corrompre (enfin, je ne crois pas).
Soit, ce sont les données que vous passez de votre programme à votre HLSL qui sont fausses, soit vous ne faites pas ce qu'il faut dans le HLSL

[supergrey]

Après test j'ai l'impression que le gpu conserve en mémoire le vertexbuffer et que c'est celui là qu'il corrompt.

Voilà ce que j'ai essayé, pour tester le vertexbuffer j'en ai fait une copie au début du programme puis dans la boucle principale je le compare de cette manière:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
CUSTOMVERTEX* v;
vertexbuffer->Lock( 0, 0, (void**)&v, 0 );
	if (memcmp(savevb,v,nvert*sizeof(CUSTOMVERTEX)))
		DisplayError();
vertexbuffer->Unlock();

Et ce bout de code à supprimé l'erreur, d'après mes faibles connaissance je pense que c'est parceque le fait de le locker le ramène en mémoire vive du coup quand il le renvoi il est "réparé".
Mais je ne pense pas que ce bout de code soit très bon pour les performances...



Pour info, j'utilise directx 9 et les shaders 2.0

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

as tu testé un débogage sous pix?

Kesako ?

[LittleWhite]

PIX est un logiciel pour debugguer des shaders HLSL. Il permet aussi de profiler les performances du shader, de decomposer ce qui est fait et tout pleins de trucs geniaux.

[supergrey]

Merci LittleWhite je vais m'y intéresser...

Pour mon problème mon idée se vérifie, je suis passé de D3DPOOL_MANAGED à D3DPOOL_SYSTEMMEM et le problème a disparu, pensez vous que ça me fera perdre en performance ?