EBAUCHE D'UN MOTEUR 3D ISOMÉTRIQUE
vbmaniac8
Messages postés
17
Date d'inscription
mercredi 19 juillet 2006
Statut
Membre
Dernière intervention
16 juillet 2009
-
5 nov. 2008 à 10:26
cs_ansizak Messages postés 191 Date d'inscription mercredi 11 juillet 2007 Statut Membre Dernière intervention 30 juin 2011 - 17 nov. 2008 à 13:43
cs_ansizak Messages postés 191 Date d'inscription mercredi 11 juillet 2007 Statut Membre Dernière intervention 30 juin 2011 - 17 nov. 2008 à 13:43
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/48368-ebauche-d-un-moteur-3d-isometrique
https://codes-sources.commentcamarche.net/source/48368-ebauche-d-un-moteur-3d-isometrique
17 nov. 2008 à 13:43
En effet, loin de moi l'idée de dénigrer Direct X et OpenGL même si je dois avouer ne pas m'y être vraiment encore plongé. Je me suis simplement dit que si je parvenais déjà à bien comprendre les mécanismes de la projection 3D à partir d'un plan 2D, l'utilisation de fonctions 3D me serait plus aisément compréhensible. J'ai la fâcheuse tendance à ne pas apprécier d'utiliser fonctions et méthodes dont je ne saisis pas le fonctionnement sous-jacent.
En tout cas merci à toi, je vais de ce pas rechercher tes tutos :)
A bientôt.
Cordialement,
Anz.
14 nov. 2008 à 13:42
Je comprends ton approche étant donné que j'ai eu une approche similaire dans les années 2003 pour réaliser un petit moteur de rendu 3D qui se manipule au moyen de commandes scripts.
Les sources sont d'ailleurs présentes dans Codes-Sources (3D-Crade Wire Modeler)
Toutefois, je me suis aussi très vite rendu compte des limitations qu'offraient cette approche de la 3D. Et à partir du moment où tu veux réellement developper quelque chose d'utilisable en pratique, il est mieux de passer à DirectX ou OpenGL. (Rassure toi, les connaissances mathématiques nécéssaires pour bien comprendre comment ta carte graphique fonctionne, ne sont pas tristes non plus).
Ceci, dit si tu es intéressé par l'aspect mathématique de la projection en perspective (ce qui inclu aussi les rotations autours des axes, mais malheureusement sans l'usage des quaternions), j'ai écrit un petit document pdf qui se trouve en téléchargement libre sur mon site (Cela s'appelle Aspects théoriques de la 3D, section documentation, bon je n'en dit pas plus pour ne pas faire de pub sur Codes-sources ;-) ).
Je suis en train de developper un autre tuto sur la manière d'utiliser les matrices views, ainsi que les matrices de projection en DirectX. Pour l'instant, je n'ai malheureusement pas suffisamment de temps que pour m'investir beaucoup plus dans ce domaine que j'affectionne beaucoup. Mais j'espère pouvoir m'y consacrer un peu plus l'année prochaine, de plus il est toujours intéressants de rencontrer d'autres adeptes ;-)
Salutations,
Jyce3d.
12 nov. 2008 à 14:39
Merci, je reprécise, le but ici n'est pas d'obtenir le résultat le plus performant mais bien de comprendre son fonctionnement :)
Cordialement
10 nov. 2008 à 19:25
Si tu veux faire un moteur 3D isométrique, je te conseille de laisser tomber GDI+ et de passer directement à DirectX ou OpenGL, il suffit de modifier la matrice de vue pour obtenir le résultat voulu.
Les performances et la facilité seront grandement améliorées.
De plus, appliquer des textures te semblera tout naturel.
Bonne continuation ;)
10 nov. 2008 à 15:12
- En effet,
Je n'ai pas pris conscience de l'utilisation du CPU, mais séparer ces calculs en plusieurs étapes me permet de me retrouver dans les différentes phases de la mise en perspective.
Pour ce qui est des Math.Cos(vars.angle), Math.Sin(vars.angle), ils ne sont utilisés que s'il y a rotation de la carte, ce qui n'est pas encore fonctionnel pour le moment :s
D'ailleurs, pour activer la rotation, effectuer un clic droit sur le menu "interact" et cliquer sur "enable rotate". Le bouton "rotate" devient alors utilisable mais ma rotation ne s'effectue pas vraiment comme attendu.
Si vous avez une idée du problème, tenez moi au courant :)
Merci pour les commentaires.
Anz.
10 nov. 2008 à 10:46
Je pense cependant que lorsque ton code sera stabilisé fonctionnellement, il faudra passer par une phase d'optimisation des calculs.
Par exemple, dans quasiment toutes les méthodes de la classe map, tu réalises plusieurs fois à la suite les mêmes calculs donc certains sont extrêmement couteux en temps CPU vu qu'ils opèrent sur des float:
- Math.Cos(vars.angle)
- Math.Sin(vars.angle)
- (vars.down * vars.yy / 2) - (vars.up * vars.yy / 2)
- (vars.right * vars.xx / 2) - (vars.left * vars.xx / 2)
Bon courage,
Laurent.
9 nov. 2008 à 13:03
5 nov. 2008 à 12:11
Merci!
5 nov. 2008 à 11:06
En effet, j'ai oublié de préciser que j'avais ajouté la librairie component factory. (que j'utilise uniquement pour l'apparence des controls et forms).
On peut la trouver à cette adresse: http://www.componentfactory.com/downloads/KryptonToolkit285.zip
J'ai opté pour GDI+ car il s'agissait de ma première expérience en terme de composant graphiques et je souhaitais bien comprendre les mécanismes 2D.
Le XNA possède des méthodes bien plus puissantes mais GDI à l'avantage de m'avoir fait pas mal réviser mes maths :p
5 nov. 2008 à 10:35
En tout cas je jetterais un œil car l'initiative me semble intéressante.
Par contre j'aurais voulu en savoir un peu plus sur ce qui ta poussé à opter pour GDI plutôt que du WPF ou du XNA qui on le mérite de faire appel à la carte graphique (si elle est présente - pour wpf)
5 nov. 2008 à 10:26
Je n'ai pas la library ComponentFactory.Krypton.Toolkit. Comment faire pour l'ajouter?
Merci.