Vertex shader qui coromp le vertexshader !?

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:

---

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

---

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

Code:

---

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

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 ?

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...

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

Citation:

---

Envoyé par 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...

---

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

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:

---

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:

---

as tu testé un débogage sous pix?

---

Kesako ?

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.

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 ?

changer le pool fait en général perdre des performances, c'est selon la fréquence de mise à jour du vb.

je suis de l'avis de LittleWhite, le gpu ne corrompt rien, mais il suffit de vérifier ce qui se passe avec pix, il se trouve dans le répertoire Utilities du sdk.

sans plus de détail concernant les déclarations et initialisations des différents éléments, c'est difficile de donner un diagnostic.