Discussion :

[kami58]

Bonjour à tous.

Quel que soit le moteur 3D/bibliothèque 3D, dès qu'il s'agit de créer des meshs par programmation, je vois toujours passer sur les tutos les mêmes exemples simples style cylindre/cube/cone ....

Je prends pour exemple mon besoin, liée au développement d'une petite application CAD/CAM, permettant l'affichage 3D temps réel d'usinages sur des pièces mécaniques.

Par exemple, si on parle d'une tôle, je connais sa longueur/largeur/épaisseur. Jusque là pas de soucis. Je veux maintenant créer un trou de perçage dedans. L'utilisateur me donne dans une fenêtre la position du centre de perçage, le diamètre, et la profondeur (on peut imaginer un perçage non débouchant). Et là, je commence à me casser les dents
Rien que déjà créer par programmation un trou dans un volume de type parallépipède, ça se complique ...

Qqn a-t'il des explications plus précises (voire un exemple de code ) à me fournir pour créer les vertices associée à cette opération ?

Question bonus N'est-il pas plus simple dans mon cas de créer un mesh par soustraction ? Les moteurs 3D savent-ils gérer ce mécanisme ?

Merci

[seeme]

Ce que tu demande dépasse largement le cadre d'un moteur 3D qui se contente d'afficher les informations.

Pour ton exemple précis un premier problème est que tu te retrouves avec une forme concave, donc déjà pleins de problèmes en perspective (en tout cas baisse des perfs).

Pour le cas d'un perçage, il faudrait calculer les points d'intersection entre ton parallélépipède et un cylindre (tu résous un système en fait) sachant qu'ensuite il faudra déterminer un niveau de précision (il y a une infinité de solutions si effectivement le cylindre intersecte la boite.. il faut en garder un nombre suffisant).

Bref, c'est bien plus compliqué que ça en à l'air.. Tu utilises quel moteur? Il embarque peut-être des solutions booléennes (auquel cas ce n'est plus un moteur 3D).

Pourquoi ne pas utiliser des logiciels dédiés (Cathia...)?

[kami58]

En fait, je suis à la recherche du moteur 3D à utiliser (cf un vieux post sur le fofo ....).

Et non, CATIA est un logiciel de CAO pour faire de la conception/modélisation. Moi je cherche à intégrer une fenêtre d'affichage 3D à mon logiciel que je peux programmer et qui me permet de faire de la 3D temps réel à partir de paramètres géométriques/mécaniques.
En gros je veux programmer un CATIA ... (nan rien d'aussi compliqué, je gère des cas plus simples ouf)... Et non un moteur 3D sait faire ce genre de chose (exemple du ManualObject sous Ogre), j'ai déjà généré un grand nombre de formes complexes via des fonctions mathématiques.... mais il faut les trouver, et donc ça a ses limites

Moi je recherche pour mon environnement C# un moteur 3D que je peux programmer, et pour lequel je peux créer des meshs paramétriques.
Et effectivement, je tombe souvent sur des géométries un peu complexes (mais pas non plus insurmontables).
Et comme tu le précise, je recherche le moteur 3D programmable si possible qui permet d'effectuer des opérations booléennes, ou permettant de construire un mesh par CSG (le nec plus ultrat ).

Dans ma recherche, je passe en revue des moteurs 3D style Ogre/TV3D, mais aussi des environnements de développement plus spécialisés (mais plus chers) comme OCC/OpenInventor/Hoops ...

[kami58]

Bon, vu que les réponses se bousculent pas , je reformule la question :
Existe-t'il des bibliothèques C# permettant d'effectuer des opérations booléennes / CSG (Constructive Solid Geometry), que je pourrai intégrer éventuellement à mon code en complément du moteur 3D que j'utilise.
Existe-til sinon des moteurs 3D du marché intégrant directement ce type de bibliothèques ?

Exemple type : créer par programmation un mesh résultat de l'intersection d'un parallépipède et d'un cylindre, quel que soit l'axe du cyclindre.

Merci de vos réponses

[Mat.M]

Dans ma recherche, je passe en revue des moteurs 3D style Ogre/TV3D, mais aussi des environnements de développement plus spécialisés (mais plus chers) comme OCC/OpenInventor/Hoops ...

OGRE ne sera pas d'une grande utilité enfin si oui on peut le prendre..
mais cela risque d'être une surcouche inutile...
moins je taperais directement dans Open GL il y a suffisament de tutos pour afficher des formes complexes et gérer l'affichage pour se passer d'un truc comme OGRE.
Et en plus tu fais ce que tu veux.
Il y a par exemple les tutos de Nehe.
Pour ce qui est des opérations sur les formes 3d il faut effectuer des opérations mathématiques sur les matrices..

Exemple type : créer par programmation un mesh résultat de l'intersection d'un parallépipède et d'un cylindre, quel que soit l'axe du cyclindre.

Merci de vos réponses

aucun moteur de jeu ne permet de faire cela...
il faut voir plutot dans des bibliothèques de géométrie mais je doute qu'on puisse trouver cela..
il faudrait chercher dans google "cad libraries"
il est facile de créer un "mesh" de toute pièces sous OPen GL

[seeme]

Juste en passant...

Ogre est un moteur de jeu qui embarque un moteur 3D Ma réponse reste donc parfaitement valable.

[Mat.M]

Juste en passant...

Ogre est un moteur de jeu qui embarque un moteur 3D Ma réponse reste donc parfaitement valable.

oui je le sais parfaitement merci !
Mais franchement j'aurais des réticences à utiliser toute une usine-à-gaz pour faire ce genre de choses.
Parce qu'avec OGRE tu vas appeler des fonctionnalités qui ne seront pas forcément utiles et qui vont alourdir le code..
Maintenant si tu veux prendre OGRE rien ne t'empêche !

[plegat]

Mais franchement j'aurais des réticences à utiliser toute une usine-à-gaz pour faire ce genre de choses.

+1

De toute façon, d'après ce que je comprends, ce n'est pas le moteur 3D qui pose problème, mais plutôt la génération des mesh complexes.

Le seul "truc" que je connaisse qui fasse ça est OpenCascade (qui est gratuit si je ne m'abuse), et pour lequel il semble exister un wrapper C#. Après, c'est une usine à gaz au même titre qu'un moteur 3D, ça gère de l'affichage, de l'import/export, du maillage, etc etc.

Je suis actuellement (hum... un actuellement qui dure depuis quelques années toutefois...) sur le même problème, et encore en pleine phase de réflexion. Pour les intersections simples (plan/cylindre/conique), ça se "calcule" assez facilement, au pire en discrétisant les cercles et autres ellipses. Après si tu as besoin de faire des intersection de nurbs, j'en suis encore à essayer de comprendre comment ça fonctionne, donc je ne te serai d'aucune aide...

Je suis le sujet avec intérêt toutefois... je suis intéressé si quelqu'un trouve quelque chose...

[kami58]

Oui j'ai cru voir que OCC gérait ce genre de choses (et oui ils ont un wrapper C#) ...
Le pb d'OCC est son dynamisme sur le marché (pas de nlle version depuis 2 ans je crois)... De plus oui c'est une usine à gaz
Sinon je travaille un peu sur Hoops3D (Tech Soft 3D), ils ont une gestion des shells et des opérations booléennes sur ces objets (j'ai pas encore testé à vraid dire).

Mais bon ces 2 solutions sont des outils commerciaux (OCC fait payer le support, l'intégration d'un moteur de collisions et la mise à dispo du wrapper C# ). Donc effectivement, faire ca par moi meme ca me tenterait plus

Par contre je suis super interessé par ce que tu me dit : intersection plan/cylindre par exemple .... Les algos sont complexes ?
Une fois tes points d'intersections calculés, comment tu génère ton maillage (tu as des fonctions de tesselation spécifique ?)

Merci

[plegat]

intersection plan/cylindre par exemple .... Les algos sont complexes ?
Une fois tes points d'intersections calculés, comment tu génère ton maillage

Si on part sur une intersection plan/cylindre, on sait que ça donne une ellipse (ou un cercle, mais ce n'est qu'une ellipse particulière), dont les caractéristiques peuvent se calculer en fonction des paramètres du plan et du cylindre.

Une fois que tu connais ton ellipse, tu discrétises son contour (par exemple un noeud tous les x mm), et tu triangules ton plan avec un contour interne imposé sur l'ellipse. Au final, tu enlèves les triangles formant l'intérieur de l'ellipse, et tu as ta surface percée.
Ca a l'air simple dit comme ça... même si ce n'est pas hyper compliqué, il y a quand même un peu de boulot "théorique" (en particulier sur la triangulation, mais rien de sorcier, un delaunay se comprend facilement).

Comme je l'ai précisé dans mon précédent post, je suis encore en phase de réflexion, mais les différentes étapes ont bien fonctionné dans des projets précédents, donc ça ne devrait pas bloquer. Je suis plutôt en train de réfléchir à la gestion des données afin que l'algorithme soit le plus polyvalent possible sans trop de modifications (genre savoir gérer une portion de cylindre aussi simplement qu'un plan...)
Ensuite faudra réflechir à comment gérer une intersection cylindre/cylindre...

[kami58]

Si on part sur une intersection plan/cylindre, on sait que ça donne une ellipse (ou un cercle, mais ce n'est qu'une ellipse particulière), dont les caractéristiques peuvent se calculer en fonction des paramètres du plan et du cylindre.

Une fois que tu connais ton ellipse, tu discrétises son contour (par exemple un noeud tous les x mm), et tu triangules ton plan avec un contour interne imposé sur l'ellipse

Jusque là je te suis pas de soucis, même si cela reste effectivement très théorique Il faut quand même trouver le maillage triangulaire entre les 4 pts de ton contour externe rectangulaire, et les x pts internes de ton ellipse....
Et puis si ton cylindre traverse un parallépipède, faut gérer ça sur les 2 plans, puis gérer le cylindre interne.

Au final, tu enlèves les triangles formant l'intérieur de l'ellipse, et tu as ta surface percée.

Quand tu dis que tu les enlèves .... c'est une action openGL particulière pour supprimer un triangle, ou tout simplement tu veux dire que tu ne génère pas le triangle ?

Ca a l'air simple dit comme ça... même si ce n'est pas hyper compliqué, il y a quand même un peu de boulot "théorique" (en particulier sur la triangulation, mais rien de sorcier, un delaunay se comprend facilement).

Delaunay ? Kesako ? Un p'tit Google s'impose je crois ...

Comme je l'ai précisé dans mon précédent post, je suis encore en phase de réflexion, mais les différentes étapes ont bien fonctionné dans des projets précédents, donc ça ne devrait pas bloquer. Je suis plutôt en train de réfléchir à la gestion des données afin que l'algorithme soit le plus polyvalent possible sans trop de modifications (genre savoir gérer une portion de cylindre aussi simplement qu'un plan...)

C'est déjà pas mal !
Le pb est que je voudrais savoir si ce genre de manip tue les performances sur une appli 3d temps réel ? car à terme, sur des cas réel, j'aurai à gérer des pièces avec quasiment une centaine de perçages !...
Donc faut imaginer le calcul, et si j'en reviens à la tesselation, il faut imaginer le cas théorique où tu peux avoir une centaine d'ellispses sur ton plan, et faut générer le maillage adéquat ....

Ensuite faudra réflechir à comment gérer une intersection cylindre/cylindre...

Arghh .... Ma première question était un cas de base cylindre/plan, mais je sais que s'appli pour laquelle je bosse, je dois aller vers du cylindre/cylindre (gestion des "gueules de loup")

[Camel LowFilter]

Pour ton trou dans ta tôle je vois une manière très simple de faire le calcul: (plus simple que de percer un plan et se taper une triangulation)

Si on part du principe que la forme ondulée de la tôle est une suite de segments parallèles reliés les uns aux autres par des rectangles très fins, et que la finesse du rectangle dépend de la résolution choisie, alors y'a pas à calculer la forme du trou à l'intérieur de ces rectangles car on descend pas en dessous de cette résolution, y'a juste à relier les points avec deux lignes droites

tu calculs juste les intersections entre le cylindre et ces segments parallèles qui définissent la tôle, ensuite t'as plus qu'à relier les points en éclatant chaque rectangle fin en 2 quadrilateres

[Camel LowFilter]

si tu cherches une solution générique qui sait tout faire alors voir opérations booléennes entre deux maillages

la source doit pouvoir se trouver

[Ange_blond]

Bonjour,

J'arrive un peu comme un cheveux sur la soupe, mais le moteur OSG a un NodeKit OSGModelling (http://code.google.com/p/osgmodeling/) qui fait un peu de CAD.
Le projet n'est pas encore officiellement releasé je crois, mais il y a dejà pas mal de boulot de fait.

Bon courage.

[kami58]

Pour ton trou dans ta tôle je vois une manière très simple de faire le calcul: (plus simple que de percer un plan et se taper une triangulation)

Si on part du principe que la forme ondulée de la tôle est une suite de segments parallèles reliés les uns aux autres par des rectangles très fins, et que la finesse du rectangle dépend de la résolution choisie, alors y'a pas à calculer la forme du trou à l'intérieur de ces rectangles car on descend pas en dessous de cette résolution, y'a juste à relier les points avec deux lignes droites

tu calculs juste les intersections entre le cylindre et ces segments parallèles qui définissent la tôle, ensuite t'as plus qu'à relier les points en éclatant chaque rectangle fin en 2 quadrilateres

Nan car ce cas est trop simpliste. j'ai pris ça en exemple, mais j'ai des formes plus complexes à gérer : tôles déformées, cylindres croisés, ...

si tu cherches une solution générique qui sait tout faire alors voir opérations booléennes entre deux maillages

la source doit pouvoir se trouver

J'ai déjà cherché je t'assure
Il existe OpenCSG éventuellement en C++, donc bof bof pour le portage C#

Bonjour,

J'arrive un peu comme un cheveux sur la soupe, mais le moteur OSG a un NodeKit OSGModelling (http://code.google.com/p/osgmodeling/) qui fait un peu de CAD.
Le projet n'est pas encore officiellement releasé je crois, mais il y a dejà pas mal de boulot de fait.

Bon courage.

Merci pour l'info c'est tres interessant
J'avais retenu OpenSceneGraph comme éventuelle solution car il disposait d'un wrapper C#. Par contre le tps que ce modeler soit finalisé, et que le wrapper C# pour l'API mis à jour .... Trop tard peut etre

[plegat]

Jusque là je te suis pas de soucis, même si cela reste effectivement très théorique Il faut quand même trouver le maillage triangulaire entre les 4 pts de ton contour externe rectangulaire, et les x pts internes de ton ellipse....

ça, ce n'est pas ce qui m'inquiète le plus. A la limite, c'est le plus simple!

Et puis si ton cylindre traverse un parallépipède, faut gérer ça sur les 2 plans, puis gérer le cylindre interne.

Oui. Rien de plus simple. Si on sait faire un plan/cylindre, on sait en faire deux. Et limiter les génératrices d'un cylindre en longueur, ce n'est pas compliqué non plus.

Quand tu dis que tu les enlèves .... c'est une action openGL particulière pour supprimer un triangle, ou tout simplement tu veux dire que tu ne génère pas le triangle ?

OpenGL ne gère que l'affichage... toutes les infos sur ce qu'il doit afficher sont traitées en extérieur, donc dans la partie "non graphique" de ton programme. Quand je dis "on enlève", ça veut dire qu'on ne les passe pas à OpenGL pour l'affichage.

Delaunay ? Kesako ? Un p'tit Google s'impose je crois ...

Je présume que tu as déjà trouvé de la doc sur internet.
En gros, ça consiste à insérer un point dans une surface triangulée. On supprime les triangles dont le cercle circonscrit contient le point qu'on rajoute, et on en créer de nouveaux à partir de ce point. Et ainsi de suite avec tous les points. Dans notre cas, les points consiste en ceux définissant le plan, et ceux définissant l'ellipse. Il y a encore un peu de boulot de basculement d'arête et d'autres subtilités du genre pour respecter les frontières.

Donc faut imaginer le calcul, et si j'en reviens à la tesselation, il faut imaginer le cas théorique où tu peux avoir une centaine d'ellispses sur ton plan, et faut générer le maillage adéquat ....

Tu ne fais le calcul du maillage que quand tu crées tes solides et leur intersection. Pas à chaque boucle d'affichage. L'affichage sera limité par le nombre de primitives à afficher, mais en aucun cas par le calcul de ces primitives.
OpenGL ne fait pas de calcul de primitives, il ne fait qu'afficher tes primitives...

Arghh .... Ma première question était un cas de base cylindre/plan, mais je sais que s'appli pour laquelle je bosse, je dois aller vers du cylindre/cylindre (gestion des "gueules de loup")

Moi aussi... faut garder espoir!

Nan car ce cas est trop simpliste. j'ai pris ça en exemple, mais j'ai des formes plus complexes à gérer : tôles déformées, cylindres croisés, ...

Il n'empêche que le principe peut être creusé... connaissant les tesselations des deux "solides", on peut "facilement" calculer leur intersection (qui se réduit à des calculs d'intersections de triangles/quads)

[Ange_blond]

Par contre le tps que ce modeler soit finalisé, et que le wrapper C# pour l'API mis à jour .... Trop tard peut etre

Je me suis peut etre avancé sur cette histoire de release, a toi de voir si la version actuelle est une version stable. Je sais juste que c'est assez récent.

[LeGreg]

Quasiment personne n'utilise les opérations booléennes dans son moteur temps réel pour plein de raisons :

- peu d'objets de la vie réelle sont réellement faits de combinaisons simples d'opérations booléennes. Ou alors il faudrait revenir d'un point de vue artistique dans les années 70/80 (TRON et tout ça..)
- Même si c'est un outil à la création dans les programmes de CAD/modeling, au final ton programme il envoie des triangles purs à ta carte graphique.
- les triangles sont super flexibles et peuvent représenter toutes sortes d'objets, simples, complexes, organiques, manufacturés. Et même si une sphère low poly est peu convaincante on peut rajouter des triangles pour la rendre plus convaincante.

Bref le faible intérêt que tu as décelé pour les opérations booléennes viennent de leur faible utilité pour faire des jeux.

LeGreg

[LeGreg]

Ton temps serait probablement mieux investi dans un programme d'importation de fichiers géométriques issu d'un logiciel de modélisation (blender, maya, max, zbrush etc..).

LeGreg

[kami58]

Ton temps serait probablement mieux investi dans un programme d'importation de fichiers géométriques issu d'un logiciel de modélisation (blender, maya, max, zbrush etc..).

LeGreg

*** Hors-Sujet ***
Désolé mais cette dernière remarque montre que tu n'as pas suivi et compris le sujet ...
Demande à qqn qui travaille sous CATIA ou Solidworks s'il doit obligatoirement créer sous Blender son solide avant de l'importer dans son logiciel de CAO ....

Le but est de créer une appli professionnelle correspondant à un modeleur 3D paramétrique type CAO, cest à dire de pouvoir créer des formes simples (et si, ça existe dans le vie réelle du XXIe siècle) à partir de donnnées géométriques saisies dans des formulaires spécifiques.
On peut imaginer par exemple générer à la volée une tôle, une matrice de perçages (cylindriques, oblongs, biais, ...), ajouter des chanfreins, une coupe biaises, etc ...
L'appli doit donc permettre l'affichage 3D temps-réel de ces modifs.