Discussion :

[cs_ntd]

Bonjour à tous!

Alors j'ai quelques petites questions, auxquelles j'ai cherché des réponses, mais c'était trop fouilli sur internet.

Donc:
- Est-il possible de faire de la 3D en C# ? (bon la je pense que oui, mais on sais jamais )
- Comment faire de la 3D en C#? Suis-je obligé de trouver des librairies qui permettent de le faire, ou bien est-ce prévu à la base?
- Pour les librairies: quelqu'un en connait-il des correctes? Quels sont les modèles 3D qui sont gérés (.nif, .x, .map ...) ?
- Comment mettre en oeuvre la 3D dans l'application? Une picture box suffit-elle?

Voilà, ce sont les principales questions qui se posent à moi.
Merci à tout ceux et celles qui prendront un moment pour me répondre

[tomlev]

http://fr.wikipedia.org/wiki/Microsoft_XNA

[dev01]

http://fr.wikipedia.org/wiki/Microsoft_XNA

Mouais.

Sinon tu as DirectX ...

[SaumonAgile]

Mouais.

Pourquoi ? DirectX c'est bien pour les puristes, mais XNA est plus facile à prendre en main surtout s'il s'agit de réaliser un jeu (même si je ne sais pas si c'est le cas de l'auteur du sujet).

[ShevchenKik]

Salut,

en tant que programmeur OpenGL, je peux au moins te parler de ca:

- oui, c'est possible de faire de l'openGL directement en C#. cherche "C# openGL" dans google et tu verras que les exemples pullulent (le 1er hit : http://csgl.sourceforge.net/, mais aucuine idée de ce que ca vaut). Apres tu peux aussi diviser ton application de sorte a garder la partie OpenGL en c++ et avoir tout le reste en C# (dans mon cas, j'utilise C++ pour programmer une fenêtre OpenGL encapsulée dans un contrôle ActiveX, qui est lui placé dans une interface en C#. Bon pour commencer y a plus simple mais en tout cas ca marche. L'avantage est que le c++ n'est pas un language interpreté, comme l'est le C#, ca tourne plus vite quoi)

- OpenGL, mais aussi Direct3D et XNA oui. Je n'ai pas utilisé les deux derniers (et a ce que je sais XNA est une sur-couche de direct3D) mais c'est sûr que ca passe en c#

- Pas obligatoirement besoin de librairies (par exemple dans le cas de l'activeX...), mais c'est pas ca qui manque sur le NET

Tiens, regarde par là si tu veux utiliser OpenGL http://cs-sdl.sourceforge.net/index....penGL_Tutorial
connaissant la qualité de leurs tutoriels OpenGL en c/c++, il y a de bonnes chances que tu prennes un bon départ avec celui là

[SaumonAgile]

C# n'est pas un langage interprété. C'est un langage compilé. Il est compilé en deux étapes. La première étape est de transformer en MSIL. La compilation en code natif est effectuée à l'exécution, mais il ne s'agit quand même pas d'une interprétation.

[ShevchenKik]

C# n'est pas un langage interprété. C'est un langage compilé. Il est compilé en deux étapes. La première étape est de transformer en MSIL. La compilation en code natif est effectuée à l'exécution, mais il ne s'agit quand même pas d'une interprétation.

Ah, merci pour la précision, je n'avais pas saisi cette nuance...

[theMonz31]

salut

Je vais essayer de te répondre dans la mesure ou cela fait quelques années que j'évolue dans le monde de la 3D, et du .Net....

Pour ce qui est de l'utilisation de librairie, tu as plusieurs approches possibles.

1/ Tu peux utiliser OpenGL (wrapper C# ou librairie, google est ton ami)

2/ tu peux utiliser DirectX directement.

Si tu veux utiliser DirectX, plusieurs approches possibles...

1=> MDX (Managed Direct X) ==> Plus de dev en cours par microsoft et support uniquement jusqu'à DirectX 9.0c

2=> SlimDX ou MDX10 ==> Ce sont des wrappers sur DirectX 10 fait par des communautés opensource

3 => Microsoft ne support plus MDX et à décider de changer de philosophie par rapport à .Net. Plutot que de fournir un Wrapper à DirectX, M$ a décidé de fournir gratuitement XNA. XNA est basé sur DirectX9 (pas prévu pour la 10 à ma connaissance aujourd'hui). XNA est à la base un framework pour développer des jeux pour XBox. Bien sur,M$ le fourni pour developper des jeux sur Windows. XNA est donc une surcouche de DirectX 9 mais n'est pas un moteur 3D. La philosophie d'XNA a ses détracteurs et partisans. Je ne prendrais pas de position dessus. Par contre, XNA a zappé certaines choses de DirectX (notamment les aspects Sons en proposant une solution pas forcément meilleurs que DirectX). Donc, tu peux choisir XNA mais en connaissance de cause


Pour ma part, j'ai travaillé sur quelques projets 3D en C#. Le choix que la société (basé à Toulouse) avait fait était le suivant : On utilise un moteur 3D C# et basta (il se trouve que se moteur etait basé sur MDX et que les auteurs de se moteurs écrivent (ils doivent l'avoir fini d'ailleurs), un wrapper pour DirectX 10 (d'ailleurs, quand j'avais mangé avec eux ils étaient plutot mécontent de Microsoft (bien qu'étant Gold Partner de m$) d'avoir abandonné MDX.

L'usage du moteur 3D peut etre une approche tout à fait sympathique. Par contre, il est clair que tu auras un "peu" moins de maitrise sur le code. Pour avoir developpé des simulateurs avec un moteur 3D, je ne pense pas que cela soit un reel frein.

Pour les moteurs 3D qui sont "compatibles" C#, je pourrais te donner la liste suivantes :

Gratuits : Ogre , Irrlicht
Payant : TrueVision (que je trouve pas cher et très sympa), Nova (très sympa, mais prix entre 4000 et 15000€ suivant version (genre SDK plutot chere).. et d'autres que je n'ai pas utilisé


Voila

The Monz, Toulouse

[ElTchoupi]

Je trouve les premières réponses un peu ... orientées !
(J'ai commencé à écrire ce mail après les 3 premiers posts...)

Voici les miennes:

- Est-il possible de faire de la 3D en C# ? (bon la je pense que oui, mais on sais jamais )

Oui, sans aucun problème ! Nous sommes mêmes assez nombreux à en faire !

- Comment faire de la 3D en C#? Suis-je obligé de trouver des librairies qui permettent de le faire, ou bien est-ce prévu à la base?

Réponse rapide, OUI: les 3D "efficace" (jeux vidéos et toute autre application qui affiche beaucoup de choses) necessitent des librairies en plus. Les plus connues: DirectX et OpenGL biensur !
Pour DirectX, l'API de Microsoft permet de faire de la 3D mais aussi tout ce qui est multimédia; il y a beaucoup de tutoriaux sur le net et le SDK donnent beaucoup d'infos. Par ailleurs MS a encapsulé ce gros bébé pour le rendre plus facile d'accès: XNA est né !
Il y a aussi OpenGL, qui ne permet, lui de faire que de la 3D, mais pour certains (dont je fais partie !), est aussi plus facile à appréhender.
La bible de l'OpenGL: (en anglais, mais permet de TOUT comprendre !) http://nehe.gamedev.net/lesson.asp?index=01

- Pour les librairies: quelqu'un en connait-il des correctes? Quels sont les modèles 3D qui sont gérés (.nif, .x, .map ...) ?

Oups, j'ai déjà commencé à répondre !
Pour les modèles 3d gérés, il y a quelques années, quand je faisait de l'OpenGL, je m'était recodé mes parsers, mais il doit en exister de tout faits...
Direct gère en natif les fichiers X et mesh je crois. (Quelqu'un confirme ?)

- Comment mettre en oeuvre la 3D dans l'application? Une picture box suffit-elle?

Si ce que tu veux dire, c'est que tu veux une application WinForms avec un "cadre 3D" dedans (par opposition à une appli 3D fullscreen), alors DirectX sera probablement plus simple à utiliser.
Je sais que quelqu'un a fait un composant qui fait ça (je retrouve plus l'adresse d'ici, mais je peux poster ça ce soir) et qui marche pas trop mal

Pour finir, il existe aussi beaucoup de moteurs 3D prêts à intégrer (OGRE, Irrlicht, pour ne citer que les plus connus)
Et plein de bons sites de reference, dont celui-ci (!):
http://jeux.developpez.com/

Bonne lecture !

--
ElTchoupi

[binoo]

Il existe également la technologie WPF qui permet d'incorporer au sein d'une application du contenu 3D.

Pour essayer d'être objectif, si c'est pour faire des jeux, il ne faut pas s'orienter sur WPF. Si c'est pour avoir au sein de son application du contenu 3D, WPF peut-être une solution. Il un aura au moins l'avantage de proposer une intégration aisée au sein de l'application. Mais il faut savoir que ça reste plus couteux en terme de performance que les API plus bas niveaux présentées précédemment (donc pour un simple petit graphique à barre en 3D avec lequel on peut interagir : pourquoi pas, au delà je ne l'utiliserai pas personnellement)

Voilà c'était pour information et poursuivre sur les possibilités de faire de la 3D avec C#

[harz62]

Ah, merci pour la précision, je n'avais pas saisi cette nuance...

A noter également que la compilation ne se fait pas instruction par instruction, une méthode est compilée avant son premier appel d'où l'appellation de Just-In-Time

[cs_ntd]

Bien bien, merci à tous de vos nombreuses réponses, je ne m'attendais pas à tant !

Pour (essayer) de commenter tout ce qui fut dit et d'apporter quelques précisions:

Ce n'est pas pour faire véritablement des jeux au sens propre, mais plus pour inclure dans une fenêtre des éléments 3D (non-statique par exemple, et avec lesquels on pourrait intéragir). D'ou ma question "une picture box suffit-elle?", car je ne veut qu'une partie de ma fenêtre qui affiche des éléments 3D, et pouvoir ajouter des éléments ordinaires ensuite dans la fenêtre.

Mais, ce n'est pas pour autant que je ne vais mettre qu'"un petit graphique à barre", je risque de plus charger la fenêtre: on peut résumé l'idée de base à celle d'un "visualiseur de modèles 3D", ou l'utilisateur pourrait visualiser ses modèles, la partie 3D de mon application ne serait donc "que" d'afficher des objets 3D et de les animer. Mais comme c'est l'utilisateur qui incluerais ce qu'il veut, il y a donc risque de modèles complexes.

Après avoir entre-aperçu ce qu'XNA proposait, je n'ais pas vraiment l'impression qu'on puisse facilement incorporer du contenu 3D au mileu de contenu ordinaire, car tous les exemples vus ne présentait que des jeux...

Ensuite revient régulièrment DirectX et OpenGL: je vais potasser tous les liens qui m'ont étés donnés, je vais aussi regarder pour WPF qui a l'air interessant.

Par contre: quelqu'un pourrait il m'expliquer la différence entre par exemple DirectX (qui a été classifié comme librairie) et Ogre (classifié comme moteur 3D), je ne saisis pas la différence

ElTchoupi : tu parle d'un composant qui permet d'ajouter un cadre 3D dans l'application : ça ressemble bigrement à ce que je souhaite faire! Si jamais tu retrouve le lien, oublie pas de le poster, ça m'interresse

Et encore merci à tout le monde pour les réponses !

[ShevchenKik]

Salut,

Par contre: quelqu'un pourrait il m'expliquer la différence entre par exemple DirectX (qui a été classifié comme librairie) et Ogre (classifié comme moteur 3D), je ne saisis pas la différence

DirectX et OpenGL sont des API (Application programming interface), c'est à dire un ensemble de fonctions que tu peux appeler dans ton programme.
En OpenGL, tu dis par exemple que tu veux dessiner un triangle a tel endroit, avec telle couleur ou texture, telle normale, etc etc.... (note: c'est plus ou moins pareil avec direct3D)

Un moteur 3D utilise ces API pour fournir un ensemble de fonctionnalités un peu plus avancées. C'est un niveau au dessus quoi. Par exemple un moteur peut te permettre de faire du bump mapping en un appel de fonction, alors que si tu fais ca directement en OpenGL il faut le programmer toi même.

En gros, un moteur te simplifie la vie, mais limite aussi ta liberté puisque tu n'a plus forcément accès à l'API qui se cache derrière.

[theMonz31]

salut


Question:
Différence entre Moteur 3D et Librairie (DirectX ou Opengl) ?

Réponse:
Une librairie (comme DX ou OpenGL) te fournisse des primitives, des fonctions, des classes, des enumérés pour manipuler de la 3D et cela à bas niveau.

Un moteur 3D va se placer au niveau au dessus et te fournir les notions de Scènes, objets 3D, déplacement d'objet 3D, rotation, translation. Le moteur 3D va gérer aussi pour toi les effets, la gestion de système de particule, la gestion des textures, l'affichage de texte 2D, les ombrages etc... Suivant les moteurs 3D, tu auras aussi un système d'import de format autre que .X ou Mehs pour DirectX.

Bref, le moteur 3D te permet en quelques lignes de code d'afficher une scène 3D ou tu vas pouvoir intéragir avec tes objets. Le moteur 3D gérera pour toi les collisions, etc...

Moi, perso, je travaille avec TrueVision (pas cher et correcte) et j'intègre ma scène 3D dans mon application winform via une pictureBox. En fait, un moteur 3D souvent à besoin d'un Handle de fenetre. Apres, que ce handle soit celui d'une picturebox, un panel, une fenetre, peu importe du moment que ce handle de fenetre est valide.

Voila

The Monz, Toulouse

[dev01]

1=> MDX (Managed Direct X) ==> Plus de dev en cours par microsoft et support uniquement jusqu'à DirectX 9.0c

2=> SlimDX ou MDX10 ==> Ce sont des wrappers sur DirectX 10 fait par des communautés opensource

Ah merde je savais pas qu'ils avaient abandonné ManagedDirectX ...

Bon ben XNA alors

[theMonz31]

dev01 :

Oui, XNA ou bien slimdx ou mdx10 (certes non "officiel" microsoft mais je crois "soutenu" par microsoft indirectement

sinon, moteur 3D

Cela dit, je ne suis pas sur que DirectX 10 est vraiment percé pour le moment !
(enfin, le mieux serait d'avoir le temoignage de quelqu'un bossant dans un studio de dev )

Sinon, XNA, je ne suis pas fan car c'est très limitatif vis à vis de DirectX (certaines choses n'existant pas sur XBOX, elles n'ont pas lieu d'etre dans XNA et d'ailleurs ni sont pas)... et puis, XNA a longtemps galérer pour etre mis dans une fenetre winform.. Maintenant, on trouve plusieurs solutions sur le net pour le faire (et je crois que dans la release 3.0 de XNA, il y aura cela en "natif" dans le framework

mais bon, le "défaut" de XNA, c'est que ya 2 releases par an à peu près et parfois, pas de compatibilité 100% d'une version à son update

The Monz, Toulouse

[ElTchoupi]

En ce qui concerne XNA, je suis assez d'accord: il y a trop et pas assez en même temps: on ne peux pas accéder à tout DX et, en même temps, il y a beaucoup de choses dont on a pas forcement besoin...
Remarque, c'est souvent le cas dans des sur-ensembles de DirectX (moteurs et autres ...).
Maintenant que les moteurs 3D gratuits marchent bien, je dois avouer que je suis revenu de la méthode "je me refais un moteur avec SEULEMENT ce dont j'ai besoin": recoder toutes ces méthodes de gestion de rendu, de lumière, de textures, (je parle pas des gestion de déplacement, en particulier pour la camera!!) alors que d'autres le font très bien (mieux que moi ?!) et gratuitement.. pourquoi se priver !

Malheureusement, il semble que l'article dont je parle pour inclure le composant dans un WinForm ait disparu (CodeGuru n'est plus ) donc quelques liens avant d'avoir un peu plus de temps pour chercher:
http://bursjooprojects.blogspot.com/...dows-form.html
http://einfall.blogspot.com/2005/03/...of-window.html
Je crois qu'MSDN parle du fameux exemple ici:
http://forums.microsoft.com/MSDN/Sho...47428&SiteID=1

Désolé, je suis un peu short là, mais je regarde plus en profondeur au plus vite.

N'hésites pas à poster tes découvertes aussi ça peut servir à tous le monde !

--
ElTchoupi

[theMonz31]

ETChoupi, je dirais que le choix de la techno ou du "moteur" sont aussi fonction de ce que tu veux exactement faire

Avec un moteur (gratuit ou pas), il faut voir quels types d'objets 3D tu vas pouvoir utiliser. Certains moteurs fournissent des plugs-in pour 3DS, ce qui veux dire que tu ne peux pas charger un objet.3DS dans ton moteur 3D sans passer par une conversion. ET autant certains moteurs fournissent un outil de conversion en ligne autant certains se "contentent" de te fournir un plug-in. et la, ca oblige la chaine de production 3D à installer le plug-in et fournir un fichier au format du moteur.. ce que je n'aime pas trop dans le principe (car après tout, obligé le graphiste à exporter dans le format du moteur 3D, bof bof bof

C'est pour cela que je parlais de TrueVision. Perso, je travaille sur le logiciel d'aménagement (vendu à IKEA entre autre), et je pense utiliser ce moteur dans la future version du produit (si elle sort un jour ).. car pour moi, TV présente
quelques avantages :

1 : PAs chere
2 : Performant pour mes besoins
3 : Forum réactif (quand même, suivant le problème soulevé
4 : Un outil en ligne de commande permet de convertir le 3DS dans le format que le moteur utilise (donc, possibilité de piloter cet outil en interne de ton logiciel pour que l'utilisateur charge un fichier 3DS sans "voir" qu'il est converti.
5 : Integration dans un controle (forme ou picturebox) très simple
6 : Moteur simple d'utilisation pour les neuneus comme moi

Voila

Je "vante" ce moteur car j'ai utilisé Ogre, irrlicht et je trouve que c'est le "seul" ou l'approche .Net est plutot satisfaisante et "legère" (en effet, le dll pour le moteur fait 3.3 Mo ce qui est plus "leger" que les autres.. (et puis les portages .Net de ogre et irrlicht ont connu des pauses qui m'ont fait choisir cette solution certes payantes au profit d'une solution free..
Maintenant, si tu n'es pas dans un cadre professionnel, je te conseille effectivement ogre ou irrlicht (bien que si j'utilisais c'est 2 moteurs, j'aurais tendance à rester dans le monde du C++ non managé plutot que de passer dans le monde du .Net )

The Monz, Toulouse

[smyley]

Au fait, à l'époque (il y a quelques années ) j'avais essayé Ogre et c'était vraiment pas mal (réalisé mon petit monde, mis de la physique, importé des objets, la caméra, lumière, skybox, etc...), sauf que je m'y était pris par un chemin assez tordu.
En fait il est possible d'utiliser Ogre avec le C++/CLI tout en utilisant le C# derrière. J'avais opté pour une structure particulière :
- Fonctions de calculs, genre caméra et tout : dll en C++ natif, interfacé directement avec Ogre
- Fonctions de chargement des objets, fichiers sur le disque : C#
- Fonctions du "jeu" (ou plutôt bac à sable d'amusement 3D), clavier souris et autres : C#
- Chargement de ogre : dll en C++/CLI
- Application principale, qui met le tout ensemble : C++/CLI
Donc il est très bien possible de faire passer n'importe quel objet du C# vers le C++ natif de ogre en faisant à la volée les conversions avec le C++/CLI qui offre beaucoup de flexibilité avec l'utilisation à la fois du C++ natif et du C# et on peut donc continuer de faire la 3D en C# en utilisant un moteur natif, et de ce fait, je pouvais utiliser des libs conçues en C# ou quand je trouvais pas (ou lorsque ce n'était pas compatible), des libs en C++ natif, et tout ça dans le même projet.
Mais bon, c'était pas de tout repos tout de même ...

[ElTchoupi]

J'avoue que ce message me fait réfléchir: j'ai toujours fait de l'OpenGL "from scratch" sur mes differents projets et suis passé à DirectX recemment, mais j'ai du "désaprendre" beaucoup, sans encore atteindre la même aisance.
Je me suis donc tourné vers un moteur tout fait pour mon projet commercial, mais sans même penser à chercher parmi les solutions payantes.

Je n'ai pas encore commencé la partie 3D, mais je sais que déjà que je vais avoir des difficultés: la création d'un HUD (avec des fenetres, pourquoi pas déplaçables, ne semblent pas encore au point dans MOgre..). D'autant plus, qu'effectivement, MOgre n'est qu'un wrapper..

Du coup, je vais peut-être revoir ma copie !
Tu as fais un tour d'horizon avant de faire ce choix ou c'est celui de ta boite ?

Merci pour ce retour d'info !

--
ElTchoupi