Salut,
 
Bon, déjà, vous savez que je ne suis pas une lumière en C# et je vous annonce que je ne connais rien à DirectX.
 
Cependant, merci de ne pas me répondre comme sur ce topic, je sais déjà tout ça
 
J'ai trouvé ce petit tuto :
http://users.pandora.be/riemer/keyboard.html
 
C'est suffisament simple pour que je n'en comprenne déjà pas la moitiée
 
En tout cas, une chose que j'ai compris, c'est que la vitesse de rotation de la scène par le clavier n'est pas "timée", c'est à dire que l'angle va bouger de 0.03 à chaque frame.
 
Est-ce que qq1 a une idée de comment faire pour limiter cet angle de 0.03 toute les 1/10 secondes... sans pour autant que ça saccade dans le rendu (c'est à dire que si j'ai 100fps, alors chaque frame tourne de 0.003, ou alors si j'ai 1fps, alors que ça se déplace par 0.3 à la fois)
 
Je pense que c'est déjà une des toutes premières étapes de la choses : arriver à un truc qui tourne à vitesse fixe, et non pas dépendante de la complexité de la scène ou de la puissance du PC.

Sinon, question bête : dans le code, je vois qu'il y a une distance min et max d'affichage des vertices.
Est-ce que DX est aussi suffisament intelligent pour ne pas dessiner les objets cachés, ou si je dois le détecter moi-même dans mon code ?

si tu parles de ça:
 
device.Transform.Projection = Matrix.PerspectiveFovLH((float)Math.PI/4, this.Width/this.Height, 1f, 150f);
 
le 1f et le 150f, sont les distances de "near plane" et de "far plane" qui sont effectivement le domaine acceptable de la profondeur Z lors du rendu, les primitives (triangles) étant clippés contre ces deux plans.  
 
maintenant, NON aucune api graphique(que ce soit l'OpenGl ou le DirectX) ne fera de rejection de la geométrie traçée.
les triangles peuvent être rejetés, mais cela aura un coût sur le moteur T&L/VertexShader de la carte 3D.
 
il te faut donc faire au moins du frustum culling de tes objets 3D, c'est le minimum requis.  
le frustum étant ta pyramide de vision dont le sommet est la caméra/l'oeil, et est coupé par le "near plane".
 
dans tous les cas ce que tu testes contre cette pyramide, c'est par exemple une sphère ou une boite à chaussure (bounding box) englobant l'objet que tu souhaites traçer.

OK, pour l'histoire de la bounding box, mon expérience de PovRay devrait me servir, j'y avais déjà pensé, mais je voulais juste savoir si c'était vraiment obligé
 
Sinon, hier j'ai bidouillé pas mal de temps, mais après une série de tests aussi infructueux que stupéfiants, j'ai mis de côté. Va falloir que je trouve une vraie doc, parceque là... En partant du dernier exemple du tuto ci-dessus, j'ai voulu modifier la scène en ajoutant un vrai éclairage (un point light situé au dessus légèrement décallé du sol).
 
J'ai tout tenté, pas moyen de lui faire faire afficher autrechose qu'une plaque toute noire

Bin la rejection des objets vis à vis du frustum est obligatoire, mais si tout ce que tu comptes faire c'est d'avoir un seul objet tout le temps visible, ça ne sert à rien, et après ça dépends du niveau que tu veux obtenir au final, si c'est pour apprendre, tu peux déjà jouer avec le Dx lui-même, et une fois que tu as un certain niveau de conaissance, attaquer un vrai truc (et donc lacher le C# non je déconnes..... quoique).

sinon, pour que tes sources de lumière fonctionnent, il ta faut une normale par vertex sinon les calculs d'éclairage n'auront rien sous la dent.
 
vu le "CustomVertex.PositionColored" qui doit correspondre à un FVF (Flexible Vertex Format) de type D3DFVF_XYZ|D3DFVF_DIFFUSE, vu qu'il y'a pas de normale, y'a pas d'éclairage.

Et donc, comment je corrige ?
 
Sinon, sans laisser tomber le C#, je voudrais savoir si vous connaissez un moteur 3D déjà écrit et libre tournant en C#, ou disposant d'une interface C#.
 
Si possible, permettant de jouer avec les dernières évolutions de DX9.
 
En fait, ce que je veux faire :
 
Un "monde" plat, éclairé par une source de lumière globale (soleil), mais qui se comporte de la sorte :
-> Ombrages au sol liés au relief et à la position du soleil
-> Changement de l'intensité lumineuse avec la position de la lumière (le but, c'est de faire un soleil qui tourne autour du monde, comme en pour de vrai)
-> Utilisation de lumières "parasites". Par exemple, pour commencer, je voudrais coder un train qui tourne en rond sur des rails. A la nuit tombée, je veux que les phares du train éclairent le sol devant, et aut les lumières émises par les wagons éclairent doucement le sol et les objets autour.
 
En fait, je voudrais me lancer dans un jeu de gestion style 3DTT (connu aussi sous le nom de "Railroads and Trucks 3D" )
 
Pour le moment, une série de cubles se baladant en rond et faisant de la lumière serait pas mal

alors plein de choses, mais y'a du boulot, donc va commençer par le commencement:
 
je crois dans la cat prog, il y a quelqu'un qui fait un moteur D3D en C# pour les n... faudra que je retrouves le topic.
 
pour corriger l'exemple, vu qu'il ne semble pas y avoir de normales dans le fichier, va falloir que tu réflechisses et que tu codes, je vais pas le faire pour toi, mais:
1) tu généres la normale par triangle (produit vectoriel de deux bords) (tu le normalises )
2) pour chaque vertex, la normale est la somme des normales de chaque triangle utilisant le vertex.
3) tu corriges le format FVF et tout ça......

Axiom le portage d'Ogre pour C#  
http://www.axiom3d.org/
 
Ou le moteur de ShadowTzu  
http://forum.hardware.fr/hardwaref [...] 4176-1.htm

C'est re-moi.
 
Après avoir galéré des heures, et mélangé quelques tutoriaux, j'ai enfin un petit truc qui marche à la souris et au clavier... et avec une lumière !
 
Seul hic, j'ai voulu remplacer le cylindre du tutorial 6 du SDK de DirectX, et le remplacer par un plan de 10x10 vertices.
 
Et là, ça pose problème.
 
Vu que c'est un plan, je réparti les points sur les axes X et Z, alors que la normale est en Y*1 uniquement. Je pense que si j'ai peut-être presque compris, ça devrait être ça.
 
Seulement, ça ne marche pas !
En me basant sur le tutorial que j'ai cité en exemple en haut, il y a cette histoire d'indices pour savoir comment relier les vertices afin d'en faire des triangles. J'ai tenté de recopier la chose, mais ça n'a pas l'air concluant du tout (ça change rien).
 
Alors plusieurs options :
1/ J'ai rien compris au système de normale (pourtant, j'ai aussi testé en X*1 et Z*1, à tout hasard)
2/ Mes indices sont foireux
3/ C'est pas que mes indices sont foireux, mais j'ai ratté un truc pour que le DX les utilise
4/ Je me suis planté dans la génération de mon plan (quand même pas... )
5/ Je sèche
 
En tout cas, ce serait cool de tester mon projet et me dire ce qui cloche selon vous...
 
http://magicweb.manga-torii.com/testd3D.zip

Sinon, un autre truc... je galère un max pour le debug... J'avais créé une second form avec des champs textbox que je mettais à jour histoire d'avoir une trace visuelle, mais non seulement c'est pas pratique, mais en plus ça faisait tout planter (je devais réduire la fenêtre DX puis la restaurer pour que ça marche ) et du coup j'ai laissé tomber la solution... Y'a moyen d'afficher du texte par dessus mon rendu 3D ? (du texte tout simple, les seuls trucs que j'ai trouvé, c'était des affichages à partir d'objets 3D et d'images mappées dessus... j'en ai aucune utilité ! -pis vu que le rendu déconne, je vous raconte pas l'intérêt -)

Tiens, encore un truc
 
J'utilise DirectInput pour gérer la souris. Seulement, ça trappe la souris aussi bien dans la fenêtre du prog que sur le bureau ou une autre fenêtre...
J'ai tenté de modifier le cooperativeflag, mais si je change "background" en "foreground" ou "noexclusive" en "exclusive", alors ça plante. Comprends pas... Ou alors c'est pas ça qu'il faut changer... A moins que ce soit une limitation de DirectInput
 
Pis ce qu'il y a de bien, c'est que c'est vachement documenté dans la MSDN... Y'a que pouic !

Pour afficher du texte tu a la classe Font de dx qui te permet de le faire simplement, zieute l'aide du sdk.
 
(edit) Pour les indices j'ai regardé (tres) rapidement le code cette ligne me parait douteuse  

 
Sur tout tes autres calculs d'indice tu fait le *10 sur l'indice j (bon j'ai pas chercher a comprendre non plus, donc ben si c'est pas ca tant pis )
 
(edit2) pendant que j'y suis, c'est pas plutot:
 

 
Puis je hais les variables magiques comme 10 change ca en qqchose de plus parlant
 
(edit3) Effectivement tu as pas du comprendre comment marchait la primitive trianglestrip(normalement pour faire un quadrilatere tu n'a besoin que de 4 points avec cette primitive). Je te conseille donc de regardé l'aide de dx a ce sujet, il y a un joli graph qui explique tres bien comment les vertex sont digérés avec cette primitive

En fait, j'ai fait plein de trianges, parceque je pensais que la texture (que j'appliquerai par la suite) serait en fonction du nombre de triangles et non pas de la taille de la surface entière. Si ?
 
Maintenant que j'y pense, c'est vrai que dans l'exemple du SDK il y a un tigre texturé, et pour tout le tigre, il n'y a qu'un seul fichier de textures... Pas pensé à ça
 
Anyway, faire plus de triangles me permettra de faire du relief

Sinon, pour le 10, je suis d'accord, il faut que je le change par une constante ou une variable.
 
Pour le moment, c'est en dur, le temps que j'écrire les bibliothèques nécessaires pour créer des objets dynamiquement (style je vais faire une class générique "DXshape", et la surcharger par "DXsphere", "DXcube", "DXplane", "DXfromFile", etc. afin de gérér dynamiquement mes objets dans la scène (plutôt que d'avoir des séries de code lourd dans ma fonction, je parcourerai un array de DXshape contenant mes objets à afficher).
Ca te semble une bonne solution ?

J'ai pas compris la question, en fait pour une surface texturé tu passera pour chaque vertex des cordonnées de texture(noté tu et tv), allant de 0.0 a 1.0.
Apres que tu mette une texture de 32*32 ou 4096*4096 pour une height map composé de dix ou de millions de triangle a vrai dire d3d s'en fiche. Seuls la texture et les parametres tu et tv des trois points constituant chaque triangle aura son importance.
 
 

 
Cest pas le probleme de beaucoup ou pas beaucoup de triangles, c'est de comprendre comment sont digérés tes listes de vertex suivant la primitive que tu utilise et d'utiliser la plus adaptée pour ta besogne
Voir "Device-Supported Primitive Types" dans l'aide de D3D.

En fait, pour résumer le problème :
-> Mon plan, à terme, sera un immense plan, qui représentera le sol. Vu que je ne veux pas faire un FPS mais un jeu qui se passe "dehors", j'ai besoin de voir très loin. A partir de là, si je multiplie les vertices, alors je pourrai faire des zones texturées plus fines je pense. Idem pour un relief pas trop "carré", plus on a de points pour définir une bosse, et plus son aspect devrait être lissé.
C'est donc pour ça que j'ai créé un plan de 10*10
 
A terme, ce sera plutôt un plan de 255*255 je pense, mais dans un monde de 2^32 de côté, dans lequel j'extrairai mes bouts de 255*255 qui entournent la caméra.
 
Ceci dit, je vais aller me documenter comme tu le préconises
 
PS: j'ai tenté de corriger en suivant ce que tu as dis, mais  ça ne marche pas. Pire : je peux mettre n'importe quoi dans ma liste d'indices, ça ne change rien !
Je suppose que le problème vient de là : j'ai mal déclaré la chose pour que le moteur les prenne en compte, je pense...

Voici ma déclaration d'indices :
 

Ah vi effectivement avec:
 

 
Ton tableau d'indice risque pas d'etre pris en compte j'avais pas vu.
 
DrawPrimitives sert a affiche affiche directement le tableau de vertex que tu lui passe.
Ce que tu veux utiliser en fait la c'est Device.DrawIndexedPrimitives

Ha ben forcément

Yes ! Ca marche !
 
Sauf que maintenant, c'est ma lampe qui ne marche plus Mon plan est tout noir...
 
Vais jamais y arriver, c'est pas possible !

Comprends plus rien. J'ai fais des modifs, et vu que ça déconnais, j'ai tout annulé, et... ben ça fait plus rien maintenant ! Ecran vide
 
C'est vraiment le bordel ce truc, j'y panne rien !

J'ai fini par retrouver mes petits.
 
Sauf que maintenant, impossible d'afficher mon plan correctement !
 
Il en manque la moitié.
 
J'ai corrigé la façon de générer les vertices du plan ainsi que les indices.
 
En éxécutant à la main en mode pas à pas, ils sont bien comme il faut, bien dans l'ordre comme préconisé dans le tutorial et tout.
 
Pourtant, ben... Ca marche pas
 
Exemple simple : (fragments de code)
 

 
Donc, en déroulé ça donne :
 

 
Représentation "à plat" :
 

 
Et maintenant, mes indices en mode pas à pas, ça donne :
 

 
Ce qui fait bien deux triangles composés des points (0, 2, 1) et (1, 2, 3)
 
Je sais pas pourquoi, dans le tuto, ils disent d'utiliser le sens "CounterClockWise" donc je suis à la lettre.
 
A priori, c'est bon !
 
Et pourtant, à l'affichage, je ne vois qu'un seul triangle, qui semble correspondre au (2, 3, 1) !
 

PUTAIN !
 
En, rédigeant le post, je me suis dit que j'avais peut-être un truc bizarre dans mon rendu...
 
Je regarde et...
 
PrimitiveType.TriangleStrip au lieu de PrimitiveType.TriangleList !
 
Je sais pas quelle est la différence, mais ça change tout, maintenant ça remarche !

Pour le nombre de triangles pour un plan, je n'arrive pas trop à comprendre comment DX fait sa tambouille au niveau des lumières. En tout cas, dans tous les cas, avec mon ATI 9800 Pro, c'est très laid !
 
Rendu pour trois lumières :
-> Une directionnelle (donc globale)
-> Une dotlight (au fond à droite)
-> Une spotlight (au milieu)
 
2 * 2 vertices :

 
4 * 4 vertices :

 
10 * 10 vertices :

 
100 * 100 vertices :

 
1000 * 1000 vertices :

 
(ça ramme pas mal avec 1000x1000, on se croirait dans Flight Simulator Faut dire que gérer (1000 - 1) * (1000 - 1) * 2 = 1 996 002 triangles, avec 3 lumières en plus, ben forcément c'est chaud )

Bon, franchement, y'a moyen d'améliorer le rendu de ces lumières ? Parceque bon, avec que 2 (2x2) ou 20 (4x4) triangles, je conçois que ce soit moche, mais arrivé à 10x10, y'a presque plus de différence, signe que la finesse des vertices ne semble pas impacter vraiment le rendu. On peut faire comment alors ? Je veux bien que D3D c'est pas du RayTracing, mais quand même !

Pffff... Je comprends rien et ça m'énerve !
 
Si j'ouvre le tuto 5 du SDK, il y a une commande :

 
Si je mets cette commande dans mon projet, alors j'ai comme réponse :

 
C'est quoi ce bordel !
 
J'ai bien les mêmes références (du moins, j'utilise les mêmes "USING" )

Projet mis à jour avec les textures qui marchent pas :
 
http://magicweb.manga-torii.com/testd3D.zip
 

Sinon, truc qui n'a rien à voir...
 
J'ai repris nu tuto pour la structure du programme, visiblement pas mal basé sur les évènement : on crée les vertex "OnVertexCreate", idem avec les indices et tout ça. Visiblement, tout ce petit monde est lancé lorsque je relance un rendu (et que je réinitialise le device).
 
C'est cool.
 
Mais, j'ai trouvé plusieurs exemples... et tous sont différents !
 
Des fois, on continue d'utiliser la fonction "render" lancée en boucle en fin de Main, mais sans évènements (on lance chaque fonction manuellement directement dans la fonction de rendu), et des fois, la fonction Render est lancée dans le "OnPaint", et c'est le "OnPaint" qui crée les vertex et autres fioritures, le "Render" se contentant d'afficher le résultat.
 
C'est quoi le mieu ? Perso, je ne vois pas trop la différence. Me baser sur les évènements comme dans le tuto de Microsoft (chose que d'un tuto à l'autre ils ne respectent pas toujours !) me semble pas mal... Mais... Est-ce c'est c'est vraiment propre ? Le coup du "OnPaint" me paraît d'un point de vue sémentique bien meilleur non ?
 
Des avis ? Des explications ?

Je t'avais bien dis de lire la doc sur les primitives pourtant  
 
Pour texture loader tu as la dll Microsoft.DirectX.Direct3DX linker au projet?

 
y'a pas de mieux c'est suivant ton but.
 
un soft d'authoring comme Maya/3DSMax font le render des viewports au OnPaint ou par timer quand y'a preview d'animation, un jeu fait ça boucle en général, avec un traitement des messages non bloquants.

Ok, bon, je vais rester sur ma structure actuelle donc, en regardant si je peux gérer les lights et les textures par évènement aussi.
 
M'enfin bon, va déjà falloir que je trouve le pourquoi du comment qui fait que ça compile pas quand j'appelle une fonction qui existe dans mes références !

Microsoft.DirectX.Direct3DX (avec le X), j'ai essayé un coup de l'ajouter à un projet, et depuis je ne la vois plus ! Impossible donc de la rajouter.

Bon, ben finalement c'était ça !
 
Maintenant... ça remarche, mais y'a pas de texture
Enfin... apprement si, mais je ne sais pas me servir de Tu et Tv... Et v'là les infos qu'il y a dans la doc ! Ca casse des barreaux de chaise moi je vous dis !
 
http://msdn.microsoft.com/archive/ [...] d/f/tv.asp
 
J'ai fais ça :

 
Sauf que ça n'a pas l'air de marcher !
Mais si je mets "uselights" à faux, mon plan apparait en jaune... Et vu que j'ai jamais défini cette couleur, et qu'il y a du jaune dans la texture... elle me semble donc appliquée... mais pas comme il faut !

En fait, en regardant le tuto 6, je me demande si je ne m'emmerde pas pour rien un peu : quand on charge des objets à partir d'un fichier .x, y'a pas besoin de faire les vertices, ni les indices, ni même le mapping de la texture ! (reste à savoir comment on génère ces fichiers miracle )
 
Enfin bref, mise à part pour le sol, où je pense ne pas trop pouvoir passer par un fichier .x, ça devrait être infiniment plus simple à gérer...

Salut !
 
Bon, je vois qu'il n'y a pas de réponse à propos de mon problème de texturage...
 
J'espère que vous n'en avez pas eu marre de voir un blaireau pareil et boudez dans votre coin
 
En tout cas, ça tombe à la limite bien que vous n'ayez pas répondu, parceque ce soir en sortant du boulot, j'étais avec un collègue irlandais, et on est allé mangé une pizza. Visiblement, les irlandais sont les cousins proche des français, vu qu'il a commandé une bouteille de vin pour deux, et qu'il s'est résigné aussi facilement que moi à boire le digestif offert par la maison
 
Bref, chuis pas bourré, mais je ne suis pas sûr d'être capable de trop réfléchir à des trucs que je ne maîtrise pas... Alors entre le C# qui ressemble à un mélange de chinois et d'hébreux à mes yeux, plus DirectX qui semble être venu tout droit d'une autre planète, c'est pas plus mal que je ne modifie pas mon code ce soir
 
En tout cas, j'espère bien que vous pourrez m'expliquer ce que sont ces Tu et Tv, parceque je ne trouve pas la moindre doc sur le net à ce sujet (ou alors ils en parlent juste, mais sans dire ce que c'est, ça donne l'impression que personne ne sait d'où ça sort !)
 
Sinon, autre truc.
 
Je sais plus si je vous l'ai déjà dit avant, mais dans l'absolu, je veux faire un jeu style Transport Tycoon, mais en 3D. Un peu comme "Railroad and Trucs 3D" si vous voulez. Y'a du boulot vous allez me dire
 
Sauf que d'un point de vue architecture, je ne sais pas comment m'y prendre !
 
En gros, je pense mulithreader mon application : un thread pour le rendu, et un autre pour le jeu lui-même. Peut-être un autre pour l'animation, je ne sais pas.
 
Avec :
-> Thread 3D : boucle sans timer, qui affiche autant que possible
-> Thread du jeu : timer toutes les x millisecondes, avec x correspondant à l'unité de temps de base du jeu
-> Peut-être le thread de l'animation, boucle infinie aussi et sans timer, qui s'occupe de déplacer les éléments à l'écran ainsi que de la GUI (et donc le thread du jeu ne s'occupe que de faire les calculs de pathfinder et autre "vie" du jeu (génération des offres et des demandes dans les usines et les villes, etc.)
 
Je vous rassure, je ne connais rien au pathfinder, et j'ai joué un coup, il y a très longtemps, avec des thread, sans comprendre une ligne des tutos que j'avais recopié Y'a du boulot
 
Ceci dit, d'ici peu, je devrais suivre deux formations (et je suis contraint d'obtenir la certification M$...) au C#. Vu mon métier, je vais évidement prendre le côté "web" du C#, mais pour avoir une certif, il faut trois modules il me semble, donc je compte aussi prendre un module en rapport avec ce projet perso (après tout, le pathfinder et le multi-thread, ça peut servir dans mon boulot, puisque je bosse en relation avec des ERP, et donc aussi bien pour la logistique que pour faire des pool de connection entre applications, les deux notions devraient m'être utiles).
 
Enfin bref, là maintenant, je suis nul, mais je me soigne !
 
Par contre, je voudrais juste que vous me disiez si un multi-threading vous semble une bonne solution. Sinon, vous voyez quoi comme méthode pour que le jeu tourne à vitesse fixe, tout en offrant un rendu 3D le plus "rapide" possible, sans risque que la vitesse du jeu ne soit impactée par la vitesse du PC ?
 
J'avoue que je m'oriente souvent vers des solutions multithreadées, parceque j'ai un serveur bi-pro, et j'aimerais bien qu'il me serve à quelquechose d'autre qu'héberger des bases SQL Server de 10 Mo

Ben qu'est-ce que je peux en raconter des trucs quand je suis bourré moi ! Je me souviens de ne pas vous avoir parlé de mon chien, c'est déjà ça... quand je parle de lui, généralement, c'est que c'est parti pour une mauvaise nuit (avec la mer qui bouge et le ciel qui tourne autour du soleil et tout ça).
 
En parlant de ça, vous savez que mon chien... nan, je déconne
 
Bon, allez, je vais me coucher

Rtfm, non?
Plus serieusement tu c'est en gros ce qui determine a quelle abcisse de la texture va correspondre le vertex (tv c'est la même chose mais pour l'ordonnée).
En gros avec tu=0.25 et tv=0.75 et une texture de 512 * 512, le vertex prendra la couleur du point a peu pres en (128, 384) de la texture.
Tu=0.0 et Tv=0.0 corresponds au coin haut gauche de la texture.  
Tu=1.0 et Tv=0.0 corresponds au coin haut droit de la texture.
Etc...
Enfin j'espere que tu commence a voir un peu mieux la chose
 
Pour ton problème ca peut venir de plusieurs choses des TextureState pas bien initialisé(je chercherais plutot de ce coté pour commencer si j'étais toi) ou un format de vertex pas adapté.
 
Bon allez moi je retourne a mon editeur de jeu(truc tout couillon juste pour des jeux 2D vu de dessus)

OK, c'est donc ce que j'avais compris...
 
Alors comprends pas.
 
Ca devrait donc mapper ma texture sur l'ensemble de mon point ça non ?
 

 
Et pourtant, ben... y'a pas de texture qui apparaît !
 
Bon, verrai ça demain, parceque ça fait plusieurs jours que je me couche un peu tard, et vu qu'au boulot je fais un travail super chiant et fastidieux, demandant toute mon attention, j'ai de plus en plus de mal à avancer...
 
En tout cas, comprends rien. Ton explication est évidement celle que j'avais supposé au départ. Mais rien n'y fait

d'ailleurs, c'est i / (WIDTH - 1) et j / (HEIGHT - 1) plutôt je pense... M'enfin c'est pas ça qui devrait empêcher le truc de marcher... à moins que la position 1,1 de la texture soit obligatoirement attribuée à un vertex ?