Salut,
 
J'ai créé un vertex shader qui fonctionne avec un DrawPrimitive() mais qui ne fonctionne pas avec ID3DXMesh:: DrawSubset() : on dirait que DrawSubset() court-circuite le shader...    
 
Le plus marrant c'est que ça fonctionne si je remplace le DrawSubset() par DrawIndexedPrimitive() utilisant les index-buffers et les vertex-buffers du mesh.
 
Quelle est l'option de ID3DXMesh ? J'ai essayé en clonant le mesh avec CloneMesh() en lui filant un vertex shader au lieu d'un declarateur mais ça ne passe pas.
 
Que faire ?

Suffit d'appeler un DrawShader() tout simplement  

 
C'était très interessant mais DrawShader() n'existe pas...  

Pas croyable ce nombre boulets qui polluent les forums...  

Je te fais des UPs déguisés de ton topic et c'est comme ca que tu me remercies ?

il ressemble a quoi ton code?
 
Quel est le debug output de ton application?
 
LeGreg

si tu n'es pas sur de ce que fait ton appel
a drawsubset tu peux utiliser
le d3dspy pour connaitre la liste precise
des appels D3D que fait ton application
ainsi que les renderstate courants.
 
Perso je n'utilise pas les xmesh parce qu'on a
notre propre version d'objets geometriques (et notre propre
scene graph) mais c'est comme ca que je ferais
(autre que demander sur la liste dxdev).
 
A+
LeGreg

tiens juste par curiosite j'ai fait une recherche sur le web
et apparemment c'est sans appel:
 
- drawSubset fait appel a setVertexShader avec le FVF  
du mesh donc si on a un vertex shader perso il n'y a qu'une seule solution c'est d'extraire les vertex et index buffers
et d'appeler drawIndexedPrimitive a la main.
 
Evidemment le probleme a ete regle dans Dx9
(cf le beta newsgroup)
 

 
LeGreg
(qui parle tout seul)

Merci pour toute ces réponses.  
 
Donc c'est foutu pour les vertex shader avec D3DXMesh
 
J'ai un autre problème : je ne peux pas activer le debug mode de DX8 alors que je l'ai pourtant installé. Je me demande si ça ne vient pas de DX 8.1 qui était installé précédemment (pour je ne sais quel jeu)
 
Ca me donne un bonne raison de passer à DX9. Y a-t-il beaucoup de changement par rapport à DX8 ? Il m'a semblé que la déclaration des formats de  vertex sur DX9 est beaucoup plus compliqué, non ?
 
Est-ce que le format des X-Files version 9 supporte plusieurs textures par matériel ?

 
 
T'as un peu de bins a changer niveau Vertex Shader, un tout petit truc rayon index buffer pis deux trois autres bricoles, mais dans l'ensemble la transition se fait plutot bien
 
la declaration est pas plus complique c juste que maintenant c un tableau de structure a la place d'une suite de DWORD

 
Ok. Dernier truc :
DX9 tourne-t-il avec VC++ 6.0 ? j'ai pas envie de passer à VC Net.

 
pas essayé mais vois pas de raison qui feraient que ca marcherait pas.

dommage, parce que DX 9 en C#, c'est vraiment pas mal du tout !

 
Arf, le C#, je ne veux même pas en entendre parler.

 
g pas essayer mais je vois ce couple revenir de plus en plus souvent sur les forums de progs, fodra que je regarde un coup

 
Ok. C'est parti pour 180 meg de d/l
 
Update:
Ca y est, j'ai installé & testé. J'ai lu la doc sur les VS 3.0, c'est  

 
Je dirais qu'elle est plus simple. D'autant plus que les sémantiques dx9 permettent de refiler le mapping des données de vertex dans les registres a l'API.
(position en v0..)
Ca ne demande aucun support de la part du hardware par contre
ca simplifie la vie.
 
LeGreg

 
Ca y est j'ai migré mon "embryon" de moteur en DX9 et effectivement, les vertex shaders et les declarations ont été rationalisés. Et maintenant, DrawSubset fonctionne avec mon vertex shader et j'ai le mode debug : Que du bonheur
 

J'ai une question à propos des Vertex shaders 3.0 :
 
Il faut déclarer au début du code les registres de sortie ("o#" ) du style "dcl_color0 o4"
 
dcl_color0 correspond à la couleur de diffusion
dcl_color1 correspond à la couleur speculaire
 
On peut aussi définir dcl_color2, mais comment y accéder à travers les pixel shader fixes ? (avec un truc du style "TextureArg[1] = Diffuse" )  
 
 
 
 
 

Bon je précise ma question vu le succés :
Mon but : faire du rendu texturé & bump mappé en Dot3Product
 
Tout d'abord j'ai un Vertex shader qui me calcule une couleur diffuse correspondant à l'illumination et une couleur spéculaire correspondant à la couleur de la lumière.
 
Premier stage :
Arg1 = Diffuse
Dot3Produt
Arg2 = texture (une normal map)
 
jusqu'ici c'est classique
 
Deuxième stage
* Arg1 = Current
Modulate
* Arg2 = Specular
 
J'obtiens donc un objet bumpé et coloré en fct de la lumière.
 
Maintenant, je dois appliquer une texture de diffusion (avec transparence ou non), sachant que je dois faire une nouvelle passe (2 textures par passe sur beaucoup de cartes 3d)
 
Je ne m'en sors pas avec les operateurs de blend.
 
Remarque :
Si j'avais 3 stages, je ferais (je pense)
Arg1 = current
Modulate
Arg2 = texture

si tu utilises le fixed function pipeline,
il faut te limiter a ce qu'un fixed function pipeline
supporte. C'est a dire certainement pas les nouveautes des pixel/vertex shaders 3.0 qui ne sont encore supportes par aucun hardware. (tu programmes pour le refrast ou tu te limites aux vertex shaders _sw??)
Je crois meme que sauf grosse pression trés peu probable des développeurs le fixed function pipeline n'évoluera plus
et est même carrément émulé sur certaines plateformes (la radeon 9700 par exemple, ou certaines cartes de moindre budget).
 
Pour ce qui est de ton probleme, tu peux t'en sortir avec plusieurs passes sans render destination intermédiaire:
par lumière, tu fais la première passe qui additionne les contributions de chaque lumìere dans le color buffer. Et la derniere passe, utilises un produit entre le color buffer et la couleur de la texture de diffusion pour obtenir la couleur de diffusion finale. Si tu veux faire du spéculaire par dessus ça bon courage..  
 
LeGreg

pour le coup de la transparence c'est completement tricky..
 
si tu dois faire plusieurs passes tu es maudit:
il faudra rendre dans un render destination intermédiaire
et fondre le résultat dans le buffer final avec la géométrie opaque.
 
Tu peux t'en sortir sans buffer intermédiaire en utilisant
des pixel shaders ou un troisiéme stage si tu peux.
 
La dernière solution c'est de ne rendre transparent que des objets non lightés (ou avec une technique plus simple que du pseudo-eclairage par pixel).
 
LeGreg

 
La 3D evolue tellement vite que le support des VS_3_0 arrivera avec la prochaine génération de carte. Là, je fais la plupart de mes tests en VS_2_X. Et les VS 3.0 fonctionnent très bien en softwareprocessing en attendant.
 
Sinon mon problème de rendu vient effectivement de la transparence. A cause du Dot3Product, je perds systématiquement l'info de transparence mais comme le VS calcule en même temps l'illumination par vertex je suis obligé de le mettre en 1er, il y a un conflit
 
Je crois que je vais faire un rendu simple pour les objets avec transparence.

 
Oui mais ce n'est pas ce que je disais:
le hardware arrivera et supportera les vs/ps 3.0
(meme si un inge de chez Sony me disait qu'il trouvait la specification tout de meme vachement costaud).
Par contre le fixed function pipeline ne sera pas remis a jour sauf grosse demande de la part des developpeurs et ce ne sera pas avant la sortie de DirectX 10 ce qui sera dur a justifier le jour ou tout le monde utilisera et supportera les pixel shaders.
 
LeGreg

Ca y est j'ai réussi à faire ce que je voulais avec Pixel Shader. C'est vrai que ça evite de se prendre la tête sur les operations de blending et je peux me limiter à une passe    
 
Par contre, j'ai regardé en détail les specs des cartes et il n'y a seulement que la 9700 et la FX qui supporte le VS 2.0
 
 
 

 
je ne sais pas exactement ce que supporte la GeForceFx
(je crois qu'ils ne supportent pas le sampler stage dans le vertex shader par contre ca fait couler de l'encre..).
Mais c'est logique après tout: Seules les cartes estampillées Dx9 peuvent supporter les vertex shaders 2.0 qui ont fait leur apparition avec Dx9.
 
LeGreg