Discussion :

[N.tox]

Bonjour/bonsoir,

Voilà, je suis en train d'apprendre C# (j'ai appris à programmer avec python, que j'aime beaucoup)

J'avais commencé à développer un logiciel permettant de simuler la taille de pierres précieuse sur faceteuse (machine utilisée pour tailler les dit cailloux) afin d'en imprimer ensuite les instruction de taille, et aussi de pouvoir faire une simulation du rendu de la lumière (histoire de voir si ça vaut le coup de réaliser la taille IRL, c'est que les cailloux sont chers, très chers).

Un tel logiciel existe déjà, mais il à déjà plus de 15 ans d'une part, mais surtout pas hyper friendly user du tout, et puis j'ai des idées de fonctionnalités de derrière les fagots... J'y vois une opportunité de m'amuser, m'instruire, et me faire de l'argent, et une certaine renomée.

Mais revenons à nos moutons, il y a donc une partie UI classique avec un frame work : menu, boutons, sliders, etc...
En ce qui concerne les parties 3D (celles rendue), il y a un mode modeling (via des paramètres sous forme de champs, boutons cf ci-dessus)
et un mode simulation (calcul de la lumière sur la pierre avec prise en compte de l'indice de réfraction de la pierre, de la réflexion externe et de la réflexion interne totale ou partielle)

Je laisse python de côté et vais refaire ce que j'ai fait en C# (ce sera que la 3ème fois que je refais, pas grave à chaque fois j'améliore au passage)

Pour la 3D donc, au vu de l'application, que conseillez-vous ? et pourquoi ?
Si possible, quelque chose de toujours actif, gérant le C# en natif, facilement intégrable à du winform (?? GUI Framework standard pour .net ? oui, j'y suis pas encore)

PS : j'ai lu ce fil attentivement http://www.developpez.net/forums/d60...ire-3d-csharp/
Il en est ressorti l'utilisation du moteur TrueVision, mais apparement le projet est un peu mort, ou en fin de vie... donc je viens ici chercher une alternative peut-être même mieux adaptée ?

[Pol63]

si c'est juste pour montrer un peu de 3d qui ne bouge pas trop je pense que wpf peut suffire
c'est un framework alternatif aux windows forms, développé par microsoft aussi

et de mémoire ce croit qu'on peut gérer des light, une camera, et surement des matières pour les reflets ...

[N.tox]

Merci bien pour cette réponse, qui est pour le coup natif .net

Je viens de regarder en diagonal un peu les possibilité 3D de WPF, et cela semble en effet convenir pour la partie modélisation. En revanche pour la partie simulation du résultat final, je ne sais pas si je peux y programmer un shader (apparement pour cette seconde partie, je n'y couperai pas)

Ah je dois préciser, mon approche pour ce logiciel à été d'aborder la 3D par les maths (bien qu'à chaque fois il me faille réapprendre pour me rappeler), et que en l'état, la logique de modélisation est déjà créee :

• je termine avec des collections de vertexs dans des matrices
• des matrices définissant la référence d'un local space et un world space
• des "listes" représentant des polygones dont chaque élément est une référence vers un vertex, le contenu de ces listes sont spécifiquement ordonnés.
• des "listes" représentant les edges dont chaque éléments est une référence vers un vertex
• des normals pour chaque face/polygone.

Le tout dans une classe avec des méthodes permettant de gérer tout ça.

et une matrice représentant un pivot, dont l'un des plan est utilisé pour les opérations de coupes du mesh : on modélise par "enlèvement de matière".

• Les mesh auront je pense 300 polygones max (donc plus de triangles), ce qui reste donc très léger.
• Le mesh modélisé sera le seul mesh présent.
• Pas de texture et donc pas de mapping.
• Une caméra doit pouvoir se déplacer autour du mesh

Pour le rendu de la partie simulation, temps réel ou animation prédéfinie avec rendu calculé en une (ou plusieures) passes et visualisation final de l'animation ? Je ne sais pas. Du temps réel serait vraiment top.

Si je parle de ça, c'est pour fournir un maximum de détails permettant de choisir aux mieux l'outil pour la 3D.


Nous avons donc comme piste :

• WPF, qui permet de créer une interface graphique software des plus classiques, avec une partie gérant la 3D offrant des possibilités de modélisations (et de rendu avancé ?)
• D'après ce que j'ai pu lire à droite à gauche, on peux directement utiliser DirectX avec SlimDx ou SharpDx
• OpenGl avec OpenTK

Ce qui me fait peur avec DX et OGL c'est l'aspect gestion du hardware + l'intégration à du WPF ou du WinForm

[theMonz31]

alors moi, j'aime bien le moteur C# qui s'appelle TrueVision.

Oui, trueVision n'est plus trop maintenu.. oui, c'est pas le meilleur moteur, mais il est facile à utiliser.

Il est facile de construire son mesh à partir de triangle... il est facile de déplacer la caméra autour d'un objet (on peut associer la caméra pour qu'elle
suive un objet)... ya moyen de faire de la physique avait si besoin.

Il est gratuit (si on accepte la présence du logo sur son rendu 3D intégré Winforms)... et à 150$ de mémoire (ce qui reste raisonnable si tu veux te faire un peu d'argent)...

Meme si le moteur est "un peu" mort", les forums sont encore actifs et regorgent de toutes les infos dont tu pourrais avoir besoin pour réaliser ce que tu veux faire...

(pour mémoire, le moteur était développé par Sylvain DUPONT, un frenchy qui est parti aux States).

Perso, j'ai joué avec ce moteur il y a 5 ans et j'avais beaucoup apprécié sa facilité d'utilisation et son efficacité (à l'époque, j'avais développé un configurateur
virtuel 3D...)

Sinon, tu peux regarder du coté de MDX (Managed DirectX) mais ce n'est plus tout jeune, DirectX9 et pas après..

sinon, slimDX ou SharpDX, mais bon, c'est son des wrapper sur DirectX alors que Truevision est un vrai moteur 3D.

Après, tu peux aussi regarder Ogre (je crois que Mogre.Net était à un moment le wrapper .Net)... et sinon, il doit y avoir irrlicht qui avait, à l'époque où je m'amusais à regarder
les moteurs 3D un wrapper.Net.

De tous, je reste quand même séduit par Truevision3D(.com) pour un usage rapide et facile...

Si tu as besoin d'aide, écris moi en privé... je veux bien aider... (même si je fais moins de sous que toi )

[N.tox]

alors moi, j'aime bien le moteur C# qui s'appelle TrueVision.

Bonjour theMonz31 , oui je sais que tu l'aimes ce moteur, c'est d'ailleurs en lisant un de tes précédentes discussions que tu as presque réussi à me le vendre (involontairement)

Il est facile de construire son mesh à partir de triangle...

bon ça c'est assez mineur, mais un des trucs que j'ai cru comprendre dans OpenGL, c'est qu'il était possible de créer un polygone directement (est-ce toujours le cas ? aucune idée), les triangles le composant étant gérés automatiquement, ce qui me semblait être déjà du taf en moins, et l'ordre d'énumération des vertex lors de la création des dits polygones correspondait à une logique humaine (heu... "énumération par contour"?) - bah, en fait c'est assez trivial, on s'en fout

il est facile de déplacer la caméra autour d'un objet (on peut associer la caméra pour qu'elle suive un objet)...

Oui, c'est un bon point.

Il est gratuit (si on accepte la présence du logo sur son rendu 3D intégré Winforms)... et à 150$ de mémoire (ce qui reste raisonnable si tu veux te faire un peu d'argent)...

Oui, 150$, c'est plus qu'acceptable, une copie vendue et c'est amorti.

Meme si le moteur est "un peu" mort", les forums sont encore actifs et regorgent de toutes les infos dont tu pourrais avoir besoin pour réaliser ce que tu veux faire...

mouais, je suis pas très convaincu de ça en revanche...

Si tu as besoin d'aide, écris moi en privé... je veux bien aider... (même si je fais moins de sous que toi )

Ca c'est c'est une sacré offre ! Que j'y souscrive ou non, merci !
en ce qui concerne les sous, en adoptant volontairement une interprétation erronée : actuellement, tu touches moins qu'un caissier à 950€/mois ?
sinon plus sérieusement, ce serait normal, bien que je n'ai là encore aucune idée des démarches légales à effectuer. Ce sera bien la dernière chose que je verrai

Ah oui, j'oubliais qu'il y aura un peu d'interaction autre que la camera entre l'utilisateur et le mesh : chaque operation de coupe nécéssitera de définir au moins un point sur le mesh avec la souris (positionnement du plan de coupe sur un vertex déjà existant la plupart du temps, soit un point quelconque sur un polygone), crotte, encore un truc que je sais pas faire, bien que ce ne soit pas encore le plus compliqué.


Dans tous les cas, c'est vraiment cette partie simulation du matériaux qui me semble de loin la plus complexe... et j'ai du mal à visualiser l'approche à employer, même si je sais comment calculer la trajectoire d'un rayon venant frapper le mesh, et calculer les trajectoire conséquentes et l'intensité lumieuse véhiculées... l'integration de ces calculs dans des shaders... là encore, je ne sais pas... (beaucoup de choses que j'ignore, c'est vraiment frustrant)

Après recherche, je vois que le raytracing d'une manière général n'est pas encore faisable en temps réel, mais ç'est pas vraiment gênant, ni surprenant

Donc puisque tu sembles bien connaître ce moteur, s'ensuit trois questions :

• offre-t-il la possibilité de bidouiller ses propres shaders ?
• penses-tu que je puisse me servir de ce moteur pour effectuer du raytracing (sans faire du temps réel donc)
• Si la simulation dont je te parle te causes, cela demande-t-il autre chose que de bidouiller les shaders ?

En premier bilan :

1. apprendre WPF, puisque "nécéssaire" pour la partie gui classique, (au passage jeter un oeil sur les possibilités 3D offertes)
2. Pour la partie simu, si TrueVision permet d'obtenir ce que je cherche à faire, alors let's go

Bon, en continuant de chercher d'autre pistes pour les moteurs 3D, j'ai trouvé Neoaxis, Axiom(en péril), XNA(mort). La 3D quel monde impitoyable...

[N.tox]

Ah, mes études sur 3DS max remontant à plus de dix ans, j'avais oublié le nom de la technique de rendu que je cherche pour la simu (raytracing), mais aussi et surtout l’existence du moteur de rendu POV-ray ! De prima bord, plus besoin de réinventer la roue !

Donc pour l'instant, j'opte pour WPF, et POV-ray (ou Mitsuba ou LuxRender) pour la partie raytraced render. Et si c'est trop lourd, je viens d'avoir une illumination sur la manière de procéder aux calculs, qui resteraient du raytracing combiné à du HDR mapping simplifié et procédural (sans image HDR)(d'ailleurs je devarit en faire un article, ne serait-ce que pour m'en rappeler le moment venu...)

Merci à vous deux

@theMonz31: ton offre n'est pas tombée dans l'oreille d'un sourd, c'est bien noté

[pascalCH]

j'arrive un peu tard mais bon ...

choisir WPF est accepter un mode de représentation des vertex et autres à la sauce "xaml" mais à l'avantage de faire du rendu acceptable à moindre effort; en plus ça s'intègre bien dans un windows forms (dans un conteneur spécifique); 300 polygones , ça doit passer sur une machine moyenne, par contre , les transparences .... peut mieux faire ..

par contre POV-Ray donnera un bien meilleurs rendu mais va vous obliger à gérer du code non managé pour garder les performances et travailler en multi-threading.

rendu là, on peu se dire qu'engager OpenCL (pas openGL) permettrait d'arriver à du ray tracing temps réel - ou presque.

ps : si tu as besoin d'un coup de main ... n'hésite pas !

[Pol63]

choisir WPF est accepter un mode de représentation des vertex et autres à la sauce "xaml"

ca doit pouvoir se faire en c#, comme tout ce qui est faisable en xaml

en plus ça s'intègre bien dans un windows forms (dans un conteneur spécifique)

le conteneur par défaut (elementhost) fait perdre l’accélération matériel de wpf, donc pour du wpf autant se passer des winforms je pense

[theMonz31]

ok ça roule...

bonne chance... I'm open.

pour TV (TrueVision pour les intimes) ==> Shader oui, raytracing, moins je pense... pour la simu, oui.. de toute façon, tu peux créer tes propres objets
comme un ensemble de triangle dans TV.. donc, tu fais bien ce que tu veux...

A l'époque, j'avais meme fait du Voronoi pour faire de jolies surfaces dans TV...

[N.tox]

choisir WPF est accepter un mode de représentation des vertex et autres à la sauce "xaml"

ca doit pouvoir se faire en c#, comme tout ce qui est faisable en xaml

Tout à fait, le contraire serait étonnant. Jusque maintenant, dans tous les framework que j'ai utilisé, j'ai toujours codé mes interfaces à la main, malgré les possibilité d'utiliser des designers et un langage statique intermédiaire. Et bien que je fasse très probablement exception à ce comportement sur ce projet (merci un super bouquin sur le WPF), les données 3D ne pourront pas passer par du xaml (hormis peut-être la forme de base, mais peu de chances que je m'y prenne ainsi), vu que c'est de la modélisation live.

le conteneur par défaut (elementhost) fait perdre l’accélération matériel de wpf, donc pour du wpf autant se passer des winforms je pense

oui, de toute façon, je découvre .NET, donc je suis aussi peu habitué à winforms que WPF. Et vu que c'est WPF qui offre la 3D, je ne vois pas l'intérêt de faire du winforms.

300 polygones , ça doit passer sur une machine moyenne, par contre , les transparences .... peut mieux faire ..

Pendant la modélisatation, la transparence n'a pas le même but que pour le rendu, elle doit simplement permettre de révéler les edges situées sur les faces cachée du mesh.

par contre POV-Ray donnera un bien meilleurs rendu mais va vous obliger à gérer du code non managé pour garder les performances et travailler en multi-threading.

Oui, et quand je vois le temps de rendu, je pense utiliser une preview avec mon algorithme (raytracing simplifié en combinaison avec un concept rappelant du HDR en beaucoup plus simple) sur de petites images (300x300 max).
Car le but premier de la simu est de pouvoir voir les patterns de réfexions ayant lieu au sein de la pierre afin de juger de sa brillance ou de sa beauté de manière précise, le niveau de réalisme requis s'arrête là. Au delà, le photoréalisme est superflu, ça peut être un plus mais largement dispensable selon son coût en ressources.

Je ne sais même pas ce qu'est du code non managé, mes connaissance en programmation et son vocabulaire sont relativement limitées

De la manière dont je voyais les chose, je voyais bien intégrer les données du mesh modéliser dans une scène écrite dans un texte dans un langage reconnu par le moteur de ray tracing, et lancement de ce dernier par ligne de commande (mais j'avoue que ça donne un côté plutôt amateur, je suis pas fan)

rendu là, on peu se dire qu'engager OpenCL (pas openGL) permettrait d'arriver à du ray tracing temps réel - ou presque.

Oui, j'ai découvert le nom d'openCL et ce que ça permettait tout à l'heure justement. A creuser, car je suppose que ça restrain le parc machine pouvant faire tourner le soft, or il doit pouvoir tourner sur des bécannes vieillissante (mais qui font tourner XP sans trop ramer, les lapidaires ont souvent des vieux ordis).

ps : si tu as besoin d'un coup de main ... n'hésite pas !

Merci , ha l'entraide sur Développez... j'avais oublié combien elle était appréciable

[MABROUKI]

bonjour

La 3D EN WPF a de serieuses limitations et sert uniquement à l'affichage de solides 3D simples :
- s'ils sont complexes ,ils peuvent etre importes d'ailleurs .Des plugin d'exportation integres à LightWave,3ds Studio existent pour exporter un Mesh en XAML
- La gestion de la lumieres est limite:pas d'Ombres ni Lumiere Reflechie et le "shading" limite:pas de radiosite ,transparence difficile à gerer...
Meme l'Animation de Mesh complexes n'est pas evidente:on peut charger le character biped de 3DS,mais l'animation des ModelGroups hierarchiques (chaque partie du fameux bipede est dans un modelgroup) n'est pas evidente soit par le code soit en xaml...
Pour les shaders,seul le Shader de Pixel (ou shader de texture est supporte) grace à la classe Effect de WPF qui qui gere la texture (bitmap,brush) qui sera modifie par le PixelShader qui fait appel à DIRECTX...
Un logiciel open source interactif Shazzam Tool permet d'animer les pixels ,les varier et genere un fichier c# pour le PIXELSHADER qui est integre au projet c# et compile avec en ressource...
WPF 3D supporte par ailleurs l'integration complete d'une surface de rendu de DirectX non manage(c++) dans le control dedie à cet effet D3DImage...

Enfin pour une approche de la modelisation complexe(bsp tree ) et le raytracing real time en csharp ,je te suggere ce lien avec un moteur 3d en .net :

http://www.google.fr/url?sa=t&rct=j&...91071109,d.d2s


Autre lacune serieuse de WPF :aucune gestion de maillage et il ne peut pas etre importe d'ailleurs ,wpf n'ayant aucune primitive 3d qui correspond à une "ligne 3d" comme directx ou opengl...

bon code...

[N.tox]

Hmmm... peut-être n'y a-t-il pas de primitives comme des 3Dline, mais après avoir vu un livre traitant des possibilité 3D de WPF, avec la présence un chapitre consacré à la modélisation, et venant de lire un article sur la création manuelle d'un triangle et d'un mesh (ensemble de triangles donc) - et d'autres aspects comme la sélection par la souris grâce à une fonction déjà existante calculant la projection sur l'écran, ce qui est apréciable - je pense pouvoir réaliser ce que je souhaite (après-tout, ce que j'ai déjà réaliser me permet déjà de créer, manipuler et "couper par un plan de coupe" un mesh, manque surtout une représentation graphique de celui-ci). Bref, certaines fonctionalités graphiques seront peut-être à implémenter manuellement, mais de de prima bord, WPF semble suffisant. Ce manque de ligne reste néanmoins un point auquel je vais prêter davantage attention, et voir si je ne peut pas dessiner les edges cachées directement sur la surface 2D réceptionant la projection (l'écran somme toute)

La 3D EN WPF a de serieuses limitations et sert uniquement à l'affichage de solides 3D simples :
- s'ils sont complexes ,ils peuvent etre importes d'ailleurs .Des plugin d'exportation integres à LightWave,3ds Studio existent pour exporter un Mesh en XAML
- La gestion de la lumieres est limite:pas d'Ombres ni Lumiere Reflechie et le "shading" limite:pas de radiosite ,transparence difficile à gerer...
Meme l'Animation de Mesh complexes n'est pas evidente:on peut charger le character biped de 3DS,mais l'animation des ModelGroups hierarchiques (chaque partie du fameux bipede est dans un modelgroup) n'est pas evidente soit par le code soit en xaml...

Merci de tes avertissement, mais ce ce que je modélise est un solide (donc pas de rigging ou de skinning), il n'y a pas de texture non plus (on peut donc zapper le mapping), si animation il y a, cette dernière si présente sera prédéfinie, n'entrera en action qu'au moment du rendu (ce qui sort du scope 3D de WPF), et en plus ne consiste qu'en une ou deux rotation. Pas besoin de lumière toujours à première vue non plus, si le matériaux appliqué est... je me rappelle plus du terme... "auto-illuminé" ? Je me garde de m'embourber dans une description interminable d'une concept aussi simple (c'est fou comme le temps efface la mémoire). Il y aura donc un matériaux pour la modélisation, et un matériaux de rendu (et ce dernier si je dev mon propre algo, n'a véritablement besoin comme paramètre que d'une couleur de base et d'un indice de réfraction).

Pour les shaders,seul le Shader de Pixel (ou shader de texture est supporte) grace à la classe Effect de WPF qui qui gere la texture (bitmap,brush) qui sera modifie par le PixelShader qui fait appel à DIRECTX...
Un logiciel open source interactif Shazzam Tool permet d'animer les pixels ,les varier et genere un fichier c# pour le PIXELSHADER qui est integre au projet c# et compile avec en ressource...
WPF 3D supporte par ailleurs l'integration complete d'une surface de rendu de DirectX non manage(c++) dans le control dedie à cet effet D3DImage...

Enfin pour une approche de la modelisation complexe(bsp tree ) et le raytracing real time en csharp ,je te suggere ce lien avec un moteur 3d en .net :

http://www.google.fr/url?sa=t&rct=j&...91071109,d.d2s

bon code...

Ha, merci . Aussi loin de ce que j'en ai lu, je suis content de constater que mon intuition m'a mené à faire naturellement la même choses . Du raytracing en real time, c'est tentant... faudrait vraiment que j'apprenne les shaders, et que je vois si je peut y adapter mon algorithme (mon pseudo "HDR map" simplifié (à la serpe ) se résume à un array impair de valeurs (33 éléments est suffisant))