[DirectX - C# - HLSL] Les problèmes d'Ingham

Version imprimable

Voir 40 message(s) de cette discussion en une page

23/04/2007, 23h38
Ingham

Visiblement, quelle que soit la valeur donnée, dans le shader il me retourne un float4 comme ceci:
a=1
r=0
g=0
b=0

Edit: Pardon ca c'est si je mets COLOR1 (pas bon) au lieu de COLOR0 (bon)
Dans le cas ou tout est censé etre correct, toutes les composantes couleur sont à 0

Ca commence à me taper un peu sur le système nerveux :D

Edit2:
RESOLU !!!
Ca venait de moi, un oubli de passage de valeur entre 2 classes...
Shame on me :oops:

Bon tant que je suis lancé je vais continuer ^^
J'ai quelques soucis de performance...

J'explique ma scène, en gros:
-Un terrain avec 2 ou 3 maisons, aucune texture, shader assez simple, temps de rendu tres faible
-Un personnage animé en keyframe et texturé avec des shaders pas spécialement compliqués non plus
-Des ombres en shadowMap avec un PCF pour l'aspect... Ca ca bouffe un peu à laffichage (pas tant que ca au calcul) a cause du PCF justement...
-Un skydome, et de l'eau (donc réflection)
-Occlusion Query basée sur des Bounding Box
-Les modèles n'ont pas beaucoup de polygones (maximum 5000 triangle la scène COMPLETE) et les textures ne sont pas géantes (j'utilise maximum 5 ou 6 textures en 256, jamais en même temps)

Avec tout ça, je dépasse pas 50 FPS :(
Que puis-je faire pour améliorer ca ?
Là je commence à me dire chapeau aux créateurs de jeu qui arrivent à tourner a plus de 100 FPS avec des scènes complète et une qualité plutôt correct 8O

En plus de ça j'ai un petit soucis avec mon occlusion Query... Je le trouve plutôt long à calculer (presque autant que la scène elle-même alors que je lui fait rendre maximum 6 boites avec un shader de Fill de 2 lignes :))
Voilà le code de mon occlusion query:
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 33 34 35 36 37 38 39 private void Scene1_OcclusionCullTest() { //Render Target devDevice.SetRenderTarget(0, sOcclusionCulling); devDevice.Clear(ClearFlags.Target | ClearFlags.ZBuffer, Color.Black, 1.0f, 0); RenderedObjects = Objects.Count; devDevice.RenderState.ZBufferEnable = true; devDevice.RenderState.ZBufferWriteEnable = false; //Rendu des bounding box de tous les objets, en fill blanc simple DrawMeshes(true, false, true); foreach (KeyValuePair<string, I3DObject> obj in Objects) { //Rendu Query OcclusionQuery.Issue(IssueFlags.Begin); obj.Value.DrawBoundingMesh(camera, Effects["SimpleFill"]); OcclusionQuery.Issue(IssueFlags.End); //Obtention données bool Data = false; int pixelsVisible = 0; while (!Data) { pixelsVisible = (int)OcclusionQuery.GetData(typeof(int), true, out Data); } //Seuil, 3 pixels visibles if (pixelsVisible <= 3) { RenderedObjects--; obj.Value.Occluded = true; } } devDevice.RenderState.ZBufferWriteEnable = true; devDevice.SetRenderTarget(0, sBB); }
Et le pire c'est quand je passe en plein écran avec l'antialiasing, il me pompe carrement 150ms de calcul à chaque frame ! je tombe a 2 ou 3 FPS...
http://img182.imageshack.us/img182/9...4101023cr7.jpg

Donc questions débiles:
-Comment optimiser ce bordel ? :chees:
Parce que 50 FPS avec si peu... Je vais pas aller bien loin moi:cry:
-Passer a des ombres en shadowvolume, ca m'apportera un gain de performance notable ?
-etc..

24/04/2007, 15h06
Lucyberad

Autant sur la compatibilité, je doute que la plupart viennet de vista puisque finalement il gère tout sans problème.

Par contre niveau performance, la c'est plus bancal !
Mon appli a gagné 30Fps du passage des drivers 11x.x à 15x.x (nividia).
quand au XP de mon ordi portable avec une 7600Go (agp 4x) affiche 30Fps de mieux que mon fixe en Vista avec une 7800gt (pci-e 16x).

C'est pour ca que je teste les performances de different modules à chaque que j'en mets un, et ce sur XP pour voir ce que ca bouffe, il m'est arrivé que une ebauche d'un cell shading que j'avais fais (pour voir) m'avais bouffé le triple sur Vista, alors que d'autre truc sont plus rapide sous vista.

et moi aussi l'AA me bouffe pas mal sous vista, même les jeux commerciaux (HL², Stalker...).

quand au code en lui même tu à l'air plus avancé que moi, juste que si tu passe en shadowvolume (d'après ce que je sais mais je comfirme pas trop), ca risque de bouffer plus, mais après tout tu perd rien à essayer. Ca ne fait que ca de plus d'appris, et ca ameliroe ton engine d'une fonctionalité :D

et pour finir: j'aime bien le design de ton HUD :mouarf:
24/04/2007, 15h10
Ingham

Merci pour ta réponse, et pour le HUD ^^

Pour ce qui est de Vista, je suis en fait repassé à XP (pour d'autres choses) il y a une semaine...
Donc les chiffres que je donne là, sont fait sous XP :(

haaa ok :D

et le calcul de ton fps tu le fait comment? toujours aussi mauvais comme tu l'avais dit:

Citation:

PS: Le FPS n'est pas bon, je le calcule par rapport au temps qu'a mis la frame à se rendre, calculé par un "QueryPerformanceCounter" qui me semble pas toujours exact :s
En réalité je suis environ a 90 FPS

Le calcul du framerate à ma façon:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
    class FrameRate
    {
        private static int lastTick;
        private static int lastFrameRate;
        private static int frameRate;
 
        public static int CalculateFrameRate()
        {
            if (System.Environment.TickCount - lastTick >= 1000)
            {
                lastFrameRate = frameRate;
                frameRate = 0;
                lastTick = System.Environment.TickCount;
            }
            frameRate++;
            return lastFrameRate;
        }
    }

24/04/2007, 16h20
Ingham

Non non le framerate que je donne est bon ;)
Je passe par un Stopwatch pour le calculer
Et je vérifie avec FRAPS en +, histoire d'être sûr
Les 2 méthodes retournent pareil

Bon bah mon topic n'attire plus grand monde :cry:
Pas grave, je continue

Donc en plus des problèmes de performances sus-cités, j'ai un problème en voulant essayer les Shadow Volume par HLSL...
Et je n'arrive pas à ne masquer que la zone ombrée, il me masque toute lextrusion, y comprit ce qu'il y a derrière...
Des images valent mille mot dit-on...

Voici mes techniques
Extrusion:
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 33 34 35 Technique Extrusion { pass Front { //Rendu face avant CULLMODE = CCW; //Activer le Stencil et le ZPass STENCILENABLE = TRUE; ZWRITEENABLE = TRUE; //Décrémenter les valeurs STENCILPASS = DECR; STENCILFUNC = ALWAYS; STENCILZFAIL = KEEP; COLORWRITEENABLE = 0; VertexShader = compile vs_2_0 RenderSceneVS(); } pass Back { //Rendu faces arrières CULLMODE = CW; //Activer le Stencil et le ZPass STENCILENABLE = TRUE; ZWRITEENABLE = TRUE; //Réincrémenter les valeurs STENCILPASS = INCR; STENCILFUNC = ALWAYS; STENCILZFAIL = KEEP; COLORWRITEENABLE = 0; VertexShader = compile vs_2_0 RenderSceneVS(); } }
Dessin final:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Technique SimpleFill { pass Fill { STENCILREF = 0x0; STENCILENABLE = FALSE; STENCILFUNC = LESS; STENCILPASS = KEEP; STENCILZFAIL = KEEP; ZFUNC = LESS; ZWRITEENABLE = TRUE; ZENABLE = TRUE; COLORWRITEENABLE = 7; CULLMODE = NONE; VertexShader = compile vs_1_1 RenderSceneVS(); } }
Résultat:
http://img386.imageshack.us/img386/7...olume03me4.jpg

Si je mets STENCILFUNC = NEVER; au lieu de ALWAYS dans la première pass de l'extrusion ,j'obtien a peu pres l'inverse:
http://img386.imageshack.us/img386/7...olume04na1.jpg

Et mon volume:
http://img386.imageshack.us/img386/9...olume01bu3.jpg

Je comprends pas ce que je fais mal :(
Help s'il vous plait, quelqu'un :aie:

24/04/2007, 20h44
Lucyberad

quelqu'un :D, on peut pas dire que je peut t'aider :D

bon, j'ai pas encore abordé HLSL profondément, mais moi j'ai trouvé un super tuto que je suis, et qui est franchement tiptop !
http://www.riemers.net/eng/Tutorials/dxcsharp.php
t'a jsute à cliquer sur HLSL sur la partie droite...

en esperant que ca puisse t'aider !
24/04/2007, 21h32
Ingham

Merci ;)
Mais HLSL je connais maintenant, tout mon moteur est basé là dessus :)
C'est juste pour les fonctions du Stencil que j'ai du mal ;)
24/04/2007, 22h33
Lucyberad

ha ben je peut plus rien pour toi :D
tu est seul façe à ce code cruel qui ne fonctionne pas ! tien bon :mrgreen:

si dernier conseil: fait peter la musique, le siege en cuir, le café, la MSDN, et fait le ramadan jusqu'à que tu trouve :D tu verra au bout de 48H non stop, tu a 95% de chance de trouver et si le cas échéant tu trouve pas, on mettra ton corps à coté des corréen qui crève au bout de 10jours pour avoir joué à WoW sans manger ni boire... :yaisse2: Bien sûr, toute cette affaire sera réduite au silence comme c'est le cas au pays du soleil levant. :king:

ps: je suis en train de craquer sur l'exemple de ***** que nous fourni billou pour son animation squellette...
25/04/2007, 02h33
Ingham

Bon j'ai finalement réglé mon problème de Stencil donc mes ombres apparaissent comme il faut :)

Maintenant il me reste un seul problème c'est l'extrusion (enfin, un seul... j'en rencontrerai vite d'autres personne n'en doute :p)
Pour l'instant ce que je fais,c'est de "pousser" les vertex qui sont dos à la lumière sans chercher à réellement extruder, donc autant dire que pour une sphere suffisament subdivisée ca va, mais pour un cube... Pas du tout !

Laurent Gomila, tu m'avais dis qu'il était possible de faire ça sur le shader, tu as un exemple ?
Merci d'avance ;)
25/04/2007, 09h06
Laurent Gomila

Pour faire l'extrusion en shader il faut préparer la géometrie de manière particulière, il faut dupliquer tous les sommets (enfin seulement les indices) de manière à créer un quad dégénéré sur chaque arête (donc en gros tu auras des arêtes avec 4 sommets). A savoir que 2 sommets auront la normale de la première face qu'ils partagent, les 2 autres auront la normale de la seconde face.
Ensuite dans le shader il suffira d'envoyer à l'infini les deux sommets de chaque arête qui font face à la source lumineuse.

Il y a de bons papiers sur le sujet, cherche sur gamedev ou chez nVidia par exemple.
25/04/2007, 11h58
Ingham

Une alternative, plutot que des créer beaucoup de faces en plus, serait de faire correspondre toutes les normales des vertices qui ont la même position, histoire que l'extrusion ne fasse pas de "trou"
Ca serait plus simple et peut-être un peu plus rapide (mais un peu moins précis) non ?
http://images.gamedev.net/columns/ha...l/image006.jpg

Je voulais juste avoir vos avis :)
25/04/2007, 12h09
Laurent Gomila

Citation:

Une alternative, plutot que des créer beaucoup de faces en plus, serait de faire correspondre toutes les normales des vertices qui ont la même position, histoire que l'extrusion ne fasse pas de "trou"
Ca serait plus simple et peut-être un peu plus rapide (mais un peu moins précis) non ?

Ca c'est la définition usuelle de la normale (moyenne des normales des triangles adjacents), et c'est ce que tu ferais si ce n'était pas pour de l'extrusion. Mais là ça ne marchera pas, si tu ne crées pas de quads dégénérés tu vas déformer ta géometrie en extrudant.

Mais les divers papiers sur le sujet en parleront mieux que moi.
29/04/2007, 20h53
Ingham
Merci Laurent pour tes renseignements ;)

Après réflextion effectivement il s'avère que dans certains cas l'extrusion est obligatoire pour avoir un résultat convenable...
J'ai mis tout ça de côté, ce n'était de toutes façon qu'un test (comme vous avez pu le constater sur les screenshots), pour attaquer un truc quand même plus important, le terrain...

---

Et bien entendu, j'ai un problème :)
Je souhaite faire quelque chose le plus optimisé possible, donc je me suis renseigné un peu, et pri exemple sur le système de wow, qui fonctionne, d'après ce que j'ai pu voir, par zones + chunks

Chaque "pays" a différentes zones.
Chaque zone fait environ 200 mètres de côté, contient son propre VertexBuffer, et contient aussi des chunks.
Les chunks sont des carrés plus petits (d'une dizaine de metres chacun, environ 10x10 quads chacun).

Petite explication visuelle:
Voici un terrain avec une seule zone:
http://img262.imageshack.us/img262/6...ainhierqb1.jpg
http://img262.imageshack.us/img262/6...ainhierqb1.jpg

Comment ca marche pour l'instant

1 VB pour la zone, la zone contient un array de chunk (paramètrable par une constante c'est pas le soucis)
Voici ce que ca donne pour ce terrain:
http://img262.imageshack.us/img262/3...vbuffergr1.jpg
http://img262.imageshack.us/img262/3...vbuffergr1.jpg

1 IB global aussi qui correspond à un chunk, utilisé en TriangleStrip
Je montre:
http://img262.imageshack.us/img262/585/ibufferqs6.jpg
http://img262.imageshack.us/img262/585/ibufferqs6.jpg

Ensuite quand j'appelle le draw de chaque chunk, je décalle le BaseIndex du DrawIndexedPrimitive, afin de décaller les indice et rendre les bon vertex.
J'ai divisé en chunk pour me permettre de rendre uniquement les chunks visibles à l'écran, les autres seront simplement zappés.

Jusque là tout baigne, ça marche, il y a pas de soucis... Mais voila, j'ai voulu faire un LOD, en gros je l'utilise comme ca: Je défini un nouvel IndexBuffer, contenant 4 fois moins d'indice (donc utilisé 1 vertex sur 2 pour chaque chunk en gros).
Bon ça aussi ça marche.

Le problème c'est que le DrawIndexedPrimitive, pour pas trop ramer demande une variable NumVertices qui est en fait trompeuse car ce qu'elle demande, de n'est pas le nombres de vertices à rendre, mais le "range" de vertices dans lequel se trouvent les indices.

Explication simple:
Je veux rendre un triangle utilisant les vertices 20, 21, 100.
Avec un index buffer comme voici: 0, 1, 80.

Je doit appeler la fonction comme ça:
Code:

1 2 3 4 5 6 7 DrawIndexedPrimitives( PrimitiveType.TriangleStrip, //Type 20, //Décallage des indices 0, 80, //Range des vertex à lire 0, 1);
Voilà ou se situe le problème, je suis obligé de lui donner un range de 80 vertices alors qu'il n'a, en pratique, que 3 à lire.
Grosse baisse de performances, entre mon LOD 4 (16 000 vertices) et mon LOD 0 (1000) je ne gagne que 10 FPS !!!
J'ai l'impression que la CG cherche à calculer les 80 vertices meme si elle n'a besoin, en pratique, que de 3.
A moins que ca soit l'upload/la lecture du stream qui prenne autant de temps.

Concretement: Que le LOD de mon chunk soit a 4 (16x16 quads) ou a 0 (1 seul quad) je suis obligé de lui donner le même range à chaque fois. Le FPS ne bouge donc quasiment pas (ou très très peu, au maximum je gagne 10 FPS, sur une application qui tourne a 310 FPS, et avec une rédiction de 16 fois moins de triangle à rendre... C'est assez peu).
Dans le cas présent et en se basant sur l'image du haut, le rendu du premier chunk necessite un range de 0 à 33, quel que soit le LOD et donc le nombres de vertices utilisés...

Plus il y a de chunks dans chaque zone, plus le range grandit et plus les performances baissent.

A savoir que à cause de ça, 1 seul chunk de 128x128 quads tourne a 415 FPS, mais que 8x8 chunks de 16x16 chacun (donc ca revient exactement au même nombre de vertices) tourne à 40 FPS...
Je veux bien que l'appel a plusieurs DrawIndexedPrimitives prenne du temps, mais de là a me diviser mes FPS par 10 !!!...

Donc question: comment optimiser ça ?
En sachant qu'il faudrait malheureusement que je garde UN Draw par chunk, car chacun à ses propres textures (assez légères) à envoyer au shader.

Des idées ? Suggestions ?
J'ai lu pas mal de papers sur les terrain, avec différentes techniques, celle-ci est la plus adaptée à mon cas.
Malheureusement je pense que je l'adapte un peu mal (ayant trouvé assez peu d'informations dessus)

PS: Je n'appelle le SetStreamSource qu'une seule fois par zone (donc vu que j'en ai qu'une pour l'instant: une seule fois par frame) et le Device.Indices = IB qu'une seule fois par frame aussi, pas besoin de +.
29/04/2007, 22h32
Ingham

Pour illustrer un peu mieux mon problème de performance à cause de ce foutu "range":
http://img49.imageshack.us/img49/157...ormanceoh7.jpg
30/04/2007, 01h10
Ingham

Bon je continue mon monologue, des fois que ça interesse quelqu'un par la suite :yaisse2:

Après réflexion je pense que réorganiser le vertexbuffer serait une excellente idée.

Une réorganisation de cette facon permettrait dans tous les cas d'avoir un range minimum, impossible de faire plus bas.
http://img264.imageshack.us/img264/3...buffer2pc8.jpg

Et créer donc de cette facon les vertices de tous les chunks, en décallant à chaque fois.

Le seul problème maintenant ça va être celui de l'algoritme pour calculer tout ça :)
N'hésitez pas à me dire si vous avez des idées / suggestions.
En ce qui me concerne, je vous tiens au courant si j'arrive à quelquechose.

A+ :)
30/04/2007, 01h48
funkydata

Bizarre... je vais regarder le code de mon CLOD et je te tiens au jus parceque mon LOD me fait en moyenne quadrupler mes fps :?
Et comme ca fait un moment que je me suis pas repencher sur les terrains je me souvient plus exactement comment j'avais à l'époque pour gérer le truc :aie:
30/04/2007, 02h50
Ingham

Oki, merci funky ;)
Enfin je pense que la solution de réorganiser le vertexbuffer est la solution ultime, sauf si y'a moyen de dire à la CG, lors du DrawIndexedPrimitives, de piocher UNIQUEMENT les vertices déclarés dans l'index buffer, mais à ce que j'ai compris, tout dépend du "range"

Bon je continue de poster mon avancée, des fois que ça serve à quelqu'un :)

Alors j'en suis là:
J'ai créé mon vertexBuffer dynamiquement, (pour l'instant seul un chunk est géré, mais il suffit de rajouter un for) et l'ordre de création est le même que dans l'image que j'ai posté au dessus.

Voici le code:

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
Vertices = new TerrainVertex[TotalVertices];
int index = 0;
 
/* Ajout du tout premier vertex du Chunk */
Vertices[index++] = new TerrainVertex(0, 0, 0, 0, 1, 0, 0, 0, 0, 0);
/* Pour chaque LOD */
for (int LOD = 0; LOD <= 4; LOD++)
{
    int iLOD = LODToDividend(LOD);
    /* Pour chaque ligne */
    for (int y = 0; y <= QUADS_ROWS; y += iLOD)
    {
        /* Pour chaque case */
        for (int x = 0; x <= QUADS_ROWS; x += iLOD)
        {
            float X = (float)x / (float)QUADS_ROWS * (float)CHUNK_SIZE;
            float Z = (float)y / (float)QUADS_ROWS * (float)CHUNK_SIZE;
 
            /* Si ce n'est pas déjà dans le buffer... */
            if (!PosAlreadyInVB(new Vector3(X, 0, Z)))
            {
                /* Ajout du vertex à la liste */
                Vertices[index++] = new TerrainVertex(
                    X, 0, Z,
                    0, 1, 0,
                    0, 0,
                    0, 0
                    );
            }
        }
    }
}

Ceci est bien entendu du code d'initialisation, donc son optimisation n'est pas le but premier ;)
Le principal c'est d'avoir le FPS le plus haut possible.

Prochaine étape: Créer l'Index Buffer associé... Là ca va se corser.

Petite image pour illustrer un chunk en 8x8 Quads:
http://img263.imageshack.us/img263/2...tor2007or7.jpg

30/04/2007, 17h50
Ingham

Je continue je continue :mrgreen:
Bon j'ai du bidouiller pas mal, mais bon ce n'est pas très grave, ne s'agissant là que du code de chargement, s'il prend 500ms de plus que ce qu'il pourrait prendre, c'est loin d'être dramatique :chees:
Mais j'ai réussi, voici quelques screenshots, avec les FPS correspondants:

1 zone de 8x8 chunks
chaque chunk a une capacité maxi de 16x16 QUADS

http://img409.imageshack.us/img409/6...tor2007gt8.jpg
LOD 4 | 572 triangles rendus par chunk
Range pour chaque chunk : 288
FPS : 240

http://img409.imageshack.us/img409/5...tor2007qu3.jpg
LOD 3 | 156 triangles rendus par chunk
Range pour chaque chunk : 80
FPS : 520

http://img409.imageshack.us/img409/3...tor2007qd4.jpg
LOD 2 | 44 triangles rendus par chunk
Range pour chaque chunk : 24
FPS : 780

http://img409.imageshack.us/img409/7...tor2007cg5.jpg
LOD 1 | 12 triangles rendus par chunk
Range pour chaque chunk : 8
FPS : 1050

http://img409.imageshack.us/img409/5...tor2007dp3.jpg
LOD 0 | 2 triangles rendus par chunk
Range pour chaque chunk : 3
FPS : 1250

Voilà en esperant que cette petite recherche pourra servir à d'autres ;)
Si funkydata ou d'autres ont d'autres solutions alternatives, je suis toujours preneur, c'est toujours bon à savoir et y'a peut-être quelques idées d'optimisation à piquer :)
01/05/2007, 00h32
funkydata

Bon j'ai (enfin :aie:) eu le temps de jeter un oeil sur mon code du CLOD et en fait je n'utilise pas les index buffers... J'utilise la technique des buffers dynamiques. Je crois (si mes souvenirs sont bons) qu'un papier à ce sujet se trouve sur le SDK ou sur le site de nvidia. Mais bon j'avais juste fait un test sans aller plus loin sur cette technique qui est un peu trop "CPU friendly" à mon gout :D Du coup je ne sais vraiment pas quelle approche est la plus optimisée. En fait, je préfère de loin le concept du Geomipmapping beaucoup plus "GPU Friendly"... que je vais d'ailleurs attaquer sérieusement d'ici peu :mrgreen:
04/05/2007, 15h41
lougne

Il y a cet article Quadtree et Octree sur le site de gamedev, hyper intérréssant que j'avais trouvé à l'époque. Il ya des algorithmes important pour le LOD. Il y a aussi l'article d'un guru du 3D Adaptives Quadtree sur le site gamasutra.com ( la bible du monde des jeux video). J'ai eu à les trouver en cherchant les quadtree, Octree, BSPtree et autres.
Mais sinon je viens de trouver un livre à la bibliothéque Level of Detail for 3D Graphics (The Morgan Kaufmann Series in Computer Graphics), mais les 432 pages me donnent le vertige, surtout quand je regarde la pile de documentation à lire sur les shaders. Le lien Amazon
exellent rien qu en le feuillettant. Mais réservé aux fous de l'optimisation Fps et qualité de détail

Salut lougne :) Merci pour la lecture ;)

J'ai un nouveau problème, très très con :mrgreen:, pour le multitexturing, le filtrage ne veut pas s'effectuer...
Voici la création de ma texture dans DirectX:
Code:

1 2 texTiles[0] = TextureLoader.FromFile(device, Application.StartupPath + @"\Content\tile4.png", 0, 0, 0, Usage.None, Format.Dxt1, Pool.Default, Filter.Linear, Filter.Linear, 0);
Et la déclaration dans le shader:
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 33 34 35 36 texture Tiles0; texture Tiles1; texture Tiles2; texture Tiles3; sampler sTiles[4] = { sampler_state { Texture = <Tiles0>; MipFilter = none; MinFilter = LINEAR; MagFilter = LINEAR; }, sampler_state { Texture = <Tiles1>; MipFilter = none; MinFilter = LINEAR; MagFilter = LINEAR; }, sampler_state { Texture = <Tiles2>; MipFilter = none; MinFilter = LINEAR; MagFilter = LINEAR; }, sampler_state { Texture = <Tiles3>; MipFilter = none; MinFilter = LINEAR; MagFilter = LINEAR; }, };
Et bien avec ça rien à faire il me fait toujours des beaux pixels bien moches :mrgreen:
Pourtant c'est pas la première fois que j'utilise des textures, et j'ai jamais eu de problème pour activer le filtrage... C'est la première fois.. Ca peut venir du fait que ca soit un array de sampler ?

Merci d'avance

Ingham

10/05/2007, 09h17
funkydata

Perso j'ai jamais utilisé un array de sampler dans un shader mais à mon avis ca vient de la car en HLSL 1 sampler = 1 filtre.
A mon avis tu aurais certainement plus de chance si, au lieu de fixer l'état de tes filtres dans le shaders, tu le fesais directement au niveau des états du device direct3d avant ton appel au shader.
10/05/2007, 13h06
Ingham

Effectivement en supprimant l'array et en créant les 4 sampler "a la main" ca marche...

C'est pas normal, si ? :mrgreen:

D'aprés mes lectures nouvelles, ps_2_0 accepte les tableaux de sampler et les index dans ceux-ci ( la version 1.0 les acceptent met il faut obligatoirement les mettre en ordre :traine: ) du genre
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 sampler Samplers[3] = { sampler_state { texture = <TextureX>; magfilter = LINEAR; minfilter = LINEAR; mipfilter = LINEAR; AddressU = mirror; AddressV = mirror; }, sampler_state { texture = <TextureY>; magfilter = LINEAR; minfilter = LINEAR; mipfilter = LINEAR; AddressU = mirror; AddressV = mirror; }, sampler_state { texture = <TextureZ>; magfilter = LINEAR; minfilter = LINEAR; mipfilter = LINEAR; AddressU = mirror; AddressV = mirror; }, };
certaines fonctions comme tex2D(Sampler[i],coordonnées); devrait marcher avec ce procédé

10/05/2007, 18h42
funkydata

Oui les tableaux de samplers sont supportés sans problème par le hlsl... par contre les filtres vu que c'est un état du device je pense qu'il ignore ce paramètre dans ce cas là. La soluce serait d'enregistrer tes samplers puis de définir les filtres appropriés dans le device direct3d

EDIT : Le problème ne me surprend pas je serais donc plutôt pour te dire que c'est normal :D

Voir 40 message(s) de cette discussion en une page