Discussion :

[electroremy]

J'ai une question à la con :

Dans mon petit programme j'ai besoin de dessiner en 3D à la fois des volumes (cylindre, cube, tore, ...), des surfaces (polygones triangulaires ou rectangulaires) et aussi des lignes et des courbes

Hors beaucoup de formats de fichier 3D et de code 3D ne prennent en charge que les polygones. Pour les volumes c'est facile il suffit de trianguler les surfaces... mais pour afficher des lignes ou des courbes ont fait comment ?

Je me vois mal remplacer chaque segment de droite par un cylindre de petit diamètre

Un format 3D et un moteur 3D qui prenne à la fois en charge volumes, surfaces, et courbes ça serait sympa

Vos réponses sur DirectX ne sont pas encourageantes... Quid de OpenGL ? Meilleur choix ?

A+

[DonQuiche]

...

Concernant les API graphiques bas-niveau pour dotnet... Les trois qui suivent sont largement utilisées :
* Monogame est multiplateformes, s'appuie sur Mono ou dotnet, sur DirectX ou OpenGL (OGL) selon les plateformes. C'est une version libre de XNA, qui était la bibliothèque 3D (et audio) pour dotnet mais a été abandonnée (même si elle fonctionne toujours). Cette bibliothèque est à un niveau légèrement plus élevé que DirectX ou OpenGL tout en restant bas-niveau. En termes fonctionnels c'est le meilleur choix à bas niveau mais il y a des bogues et son avenir n'est pas garanti même si plusieurs jeux et applis l'utilisent (Bastion par exemple) ; cela dit les biblios continueraient à fonctionner longtemps.

* SharpDX est le wrapper le plus populaire pour DirectX. Alternativement tu peux utiliser DirectX directement puisque nombre d'objects sont des objets COM, qui peuvent être directement consommés par dotnet, mais c'est en général lourdingue.

* OpenTK est le wrapper le plus populaire pour OpenGL. Cela dit OpenGL est un mauvais choix sous Windows du fait de drivers médiocres, en particulier chez Intel, et de drivers incorrectement installés. Par exemple Firefox désactivait l'accélération matérielle sur 50% des machines notamment à cause de problèmes de pilotes. Et même quand il y a des drivers OpenGL fonctionnels ils sont souvent à la bourre d'une ou deux générations d'API. En revanche OpenGL ES est le principal choix côté Android/iPhone.


Concernant les moteurs... Malheureusement les moteurs de jeux ne contiennent pas ce dont tu as besoin (courbes cubiques), leurs fonctionnalités te sont inutiles (ombres, occlusion ambiante, HDR, etc) et te poseraient sans doute plus de problèmes qu'autre chose (difficultés de contrôle du pipeline de rendu). Il faudrait voir du côté de moteurs 3D spécialisés mais je ne les connais pas et je ne crois pas que l'offre soit fabuleuse.

Au passage note que l'intégration de toutes les API 3D à ton API UI passe par les mêmes mécanismes avec les mêmes problèmes. A ce sujet WPF avait certains problèmes de performances, il me semble qu'ils ont été levés. Par contre tu as sans doute encore des limites telles que pas d'overlay transparent ou translucide par-dessus la zone 3D.


Enfin à propos des courbes... Les anciennes versions d'OpenGL incluaient un support natif des courbes cubiques (ou quadratiques ?) avec accélération matérielle. Ça fonctionne sans doute encore mais à mon avis de nos jours c'est émulé par le driver. Quant à DirectX ou OGL ES ils n'ont jamais supporté ça et je ne sais pas si les versions récentes d'OGL incluent encore cette fonctionnalité. Les techniques modernes utilisées pour l'émulation (applicables à n'importe quel API) sont la tesselation (on crée des polygones ou lignes à la volée - via le CPU ou via le GPU sur DX10+) et les pixel shaders (on dessine un bête rectangle et le shader va calculer pour chaque pixel s'il est sur la courbe ou non - cherche signed distance field spline). Mettre tout ça en oeuvre est loin d'être trivial mais peut-être trouveras-tu une biblio.

[electroremy]

Merci pour cet avis très détaillé

Je vais me renseigner sur SharpDX

Je vais aussi essayer de faire une version WPF, pour voir ce que ça donne

Dommage que Windows utilise mal OpenGL.

Dommage aussi pour les courbes et les lignes... Effectivement les moteurs 3D sont fait pour des appli ludiques, pas pour la CAO. Les éditeurs de soft CAO gardent jalousement leurs codes et astuces car leurs programmes se vendent cher

A+

[DonQuiche]

Dommage aussi pour les courbes et les lignes... Effectivement les moteurs 3D sont fait pour des appli ludiques, pas pour la CAO. Les éditeurs de soft CAO gardent jalousement leurs codes et astuces car leurs programmes se vendent cher

Non ça n'a rien à voir, d'autant que ces algorithmes de base sont vieux comme l'informatique et très bien connus et maîtrisés, et étaient déjà implémentés par les constructeurs. C'est simplement qu'il n'était plus justifié de consacrer des transistors et de la main d'oeuvre à un support matériel de ces courbes alors même que ces fonctions étaient utilisées par très peu d'utilisateurs et qu'il était devenu relativement facile de les émuler (ce qui n'était pas le cas à l'origine, quand les CPU étaient bien moins puissants). D'ailleurs le passage au mobile à poussé Khronos à faire le grand ménage et ne retenir que l'essentiel (apparition d'OGL ES et désormais convergence entre OGL et OGL ES avec une version unifiée, simple et généraliste). En fait on pourrait même dire que c'est le fait d'abandonner le monde de la CAO qui a sauvé OGL puisque cette API avait pris beaucoup de retard durant les années où le consortium se divisait sur les directions à prendre.

Et d'un autre côté c'est aussi symptomatique de la transformation des GPU qui étaient au départ des unités très spécialisées où chaque fonctionnalité était câblée, en processeurs programmables, généralistes et massivement parallèles (SIMD). C'était le passage du pipeline fixe au pipeline programmable. Une tendance qui n'a fait que se poursuivre avec le GPGPU et la quasi-disparition annoncée des API graphiques au profit d'API de calcul parallèle (DX 12, Mantle, etc).

[ShadowTzu]

SharpDX n'est pas compatible avec VB.NET, l'alternative c'est SlimDX.

[DonQuiche]

SharpDX n'est pas compatible avec VB.NET, l'alternative c'est SlimDX.

Comment diable une bibliothèque dotnet pourrait-elle être incompatible avec VB.net ? Pourrais-tu préciser s'il te plaît ?

Quant à SlimDx de ce que j'en sais il est plus ou moins abandonné ce qui est une bonne raison pour ne plus l'utiliser.

[ShadowTzu]

c'est à cause de sa non sensibilité à la casse:
http://www.gamedev.net/topic/654944-...le-with-vbnet/

[electroremy]

Je vais aller voir du côté de SlimDX

En fait on pourrait même dire que c'est le fait d'abandonner le monde de la CAO qui a sauvé OGL puisque cette API avait pris beaucoup de retard durant les années où le consortium se divisait sur les directions à prendre.

La question de savoir comment faire du graphisme performant, en 2D ou en 3D, pour une appli autre qu'un jeu ou que du multimédia revient pourtant très souvent sur les forums. Je vois des posts comme ça régulièrement sur les forums depuis la première fois que je suis allé sur le net en 1997 - d'ailleurs je suis surpris que des experts de ce forum me répondent, ils devraient êtres lassés de cette question à force

Dommage qu'en 2015 les fonctions graphiques de base des langages les plus populaires ne bénéficient toujours pas de l'accélération matérielle, ou au moins d'un bon moteur 2D / 3D intégré.

La hantise du développeur disposant de peu de moyens et/ou de temps c'est de devoir faire tous les deux ans X versions de son logiciel pour suivre les évolutions des OS et des API.

VB et VB.NET ont une bonne durée de vie et une bonne compatibilité avec les différentes versions de Windows, mais le recours à telle ou telle API spécifique peut réduire fortement ces avantages. Si j'utilise SlimDX je vais être dépendant de lui, mes programmes ne pourront tourner que sur un PC qui supporte SlimDX, et si SlimDX est abandonné ou n'est plus supporté par une autre version de Windows il faudra tout recommencer.

Il y a la grosse frustration d'avoir une bonne idée, de pouvoir faire un logiciel répondant à un besoin, mais d'être bloqué par la nécessité d'être vraiment expert en programmation pour que l'application soit performante et utilise toute la puissance de l'ordinateur.

Je ne suis pas un expert en programmation, pour l'être il faudrait que ce soit mon métier principal ou alors que je ne fasse que ça. Par contre je commence à maîtriser des choses comme le traitement du signal ou la mécanique. Il me faudrait presque un langage pour non-programmeurs, mais permettant de faire de vraies applications. Une sorte de truc hybride à mi-chemin entre matlab et VB.NET (en fait ce n'est pas un bon exemple car matlab est loin d'être simple à utiliser mais je ne vois pas d'autre exemple à donner )

EDIT : donc SlimDX est abandonné - il ne manque que un moteur 2D/3D intégré à VB.NET pour en faire le meilleur langage ; allez MS un petit effort

[electroremy]

J'ai créé une version WPF de mon programme, voir ici sur le forum dédié : http://www.developpez.net/forums/d14...hismes-2d-wpf/