Bonjour,
 
J'ai pour projet de créer un modeleur 3D multiplateforme basé sur C++.  
Je compte utiliser OpenGL et wxWidgets pour la forme et OpenCSG pour le fond.
 
Je compte faire évoluer le topic au fur et à mesure de mes avancements :

• Interface tout OK.
• Affichage 3D sauf éclairage et textures...
• Chargement/Enregistrement    
• Picking   OK
• Arbre CSG (besoin d'aide !)    

===========================================================
 

• Mon programme devra permettre l'assemblage de blocs simples (parallélépipèdes) par placage (surface contre surface), j'ai donc prévu de faire choisir à l'utilisateur une face, et d'y rajouter un bloc. Je n'ai pas trouvé de fontion existantes pour ce problème, j'ai donc prévu de projeter les blocs sur la surface de l'écran et de calculer en fonction de la position de la souris quel bloc *visible* à été choisi. Je n'ai pas encore de résultat. Est-ce la solution, comment la mettre en oeuvre ?

>> spotaszn : méthode du Picking
>> Méthode mise en place et fonctionnelle.
 

• Dans la meme optique de modelisation, afin d'eviter des erreurs d'arrondis lors du placage je comptais modifier mes modèles pour obtenir 1 seul bloc objet si désiré. Comment procéder pour obtenir ce résultat ?

>> Je compte utiliser la bibliothèque OpenCSG qui correspond assez bien à mon problème. Elle permet d'effectuer les opération booléennes dont j'ai besoin, l'implémentation serait un arbre avec une opération à chaque noeud et des modèles 3D simples à ses feuilles. Je recherche des exemples, j'ai du mal à avoir un quelconque résultat...    
 

• Autre question : l'utilisateur pourra avoir le choix du type de traits des figures : plein, arêtes ou points. Mes blocs seront le plus souvent des parallélépipèdes, mais je me demandais si les modes GL_QUADS_STRIP ou GL_QUADS sont les mieux ?

>> bb138les XXX_STRIP sont plus performants au niveau du rendu 3D.  
>> Distinction des 3 cas dans l'algorithme lors de l'affichage à l'écran. Mais affichage face par face lors du lors du picking.
 

• Enfin mon programme devra enregistrer les données, existe-t-il une méthode meilleure qu'une autre pour enregistrer des données 3D (+infos) ?

>> spotazsn : un format style "vrml" pourrait être pratique...
>> Pourquoi pas, je vais me créer un format en attendant, je n'ai pas encore fixé les limites de mon programme et j'ai pas encore implémenté la CSG...
 
Merci de m'aider à m'orienter dans mes décisions.  

Salut,
Donc, point par point...
- tu vas faire ce qu'on appelle du picking... pour cela, en openGL, il y a quelques fonctions : glSelectBuffer, glRenderMode, gluPickMatrix, glInitNames, glLoadName, glPushName, glPopName... Tu trouveras de nombreux exemples avec Google (Picking/OpenGL).
- il s'agit d'opérations booléennes (des unions, dans ce cas), pour des boîtes, ça doit pas être trop compliqué mais je me demande si c'est vraiment judicieux voire utile.
- perso, j'utilise les fonctions de tracé de lignes (GL_LINES) et de points (GL_POINTS) pour les rendus "non-plein"...
- il existe de nombreux format 3D simples à utiliser, perso, je préfère réinventer la roue à chaque fois... si t'as un parser XML sous la main, un format style "vrml" pourrait être pratique...

Salut !
Tout d'abord je te souhaite bon courage    
Je ne te dirais pas grand chose concernant tes questions si ce n'est que les XXX_STRIP sont plus performants au niveau du rendu 3D.
A part ça, as-tu pensé à un arbre de scène pour pouvoir gérer plus simplement tous tes objets ?

Déjà m'arrange bien que ca existe déjà, j'espère que je trouverai assez d'exemples, je vais aller me renseigner.

Je pense que cela peut etre utile car j'ai déjà essayé de créer un mini modeleur en inscrivant les coordonnées une par une et aux jointures des pièces il y a de gros problèmes d'arrondis que je n'ai pas su résoudre. La création des unions de boites qui se touchent pas à un arrondi de 0.0000001 est impossible    

ok pour GL_LINES mais je peux dire adieu à GL_QUAD_STRIP (la méthode pour relier les points n'est plus compatible)

Je n'ai encore jamais imaginé une méthode d'enregistrement (j'ai meme jamais appris je crois !) mais je vais voir comment je peux me débrouiller, pour l'instant j'en suis pas encore la.
 
Merci déjà mais je veux bien d'autres avis ^^

Merci, Oui, c'est d'ailleurs la première chose que j'ai pensé, arbre, arêtes et couleurs...

Concernant ton problème d'arrondi, je te conseille de ne pas utiliser une égalité stricte mais un intervalle avec l'utilisation d'un epsilon (=10^-6 par exemple).
Avec cette approximation tu devrais pouvoir t'ne sortir un peu plus facilement mais dans ce cas il te faudra peut-être abandonner les QUAD pour des TRIANGLE pour éviter les problème de coplanéité...

 
C'est sûr qu'il faut faire preuve d'une certaine tolérance (Epsilon) si tu veux faire des opérations booléennes dans le monde des flottants... Je ne sais pas qu'elle est le but de ton modeleur mais si tu veux une réelle précision dans tes assemblages de boîtes, il va falloir garder des informations de plus haut niveau comme la description de l'assemblage lui-même (les points d'ancrage, les faces assemblées, etc.) Ensuite, pour l'affichage et le picking, tu peux bien sûr garder des coordonnées relatives ou absolues...

OK pour les tolérances, l'an passé quand j'avais essayé j'avais échoué lamentablement, cette fois ci j'ai du temps, faut que je fasse quelque chose de mieux.
 
Je vais avancer le projet petit à petit. Donc j'ai créé une boite de dialogue simple demandant longueur, hauteur, largeur, couleur et style de trait (Plein, Arêtes ou Points).
Pour contourner le problème des traits, il me faut utiliser :
GL_QUADS pour "Plein"
GL_LINE_LOOP pour "Arêtes"
GP_POINTS pour "Points"
et dans ce cas dessiner les faces une par une.
Comme c'est une des bases du prog, je voudrais être certain qu'il n'existe rien de mieux.

Pense juste à ne pas repasser plusieurs fois sur les même arêtes... Pour une boîte, il te faut deux GL_LINE_LOOP et quatre GL_LINES, par exemple... Tu peux aussi tenter de faire mieux avec un GL_LINE_STRIP et trois GL_LINES...

Je suis en train de chercher un solution, mais je me demande si je vais en trouver une. Je vais devoir faire 3 cas je pense et je privilégie donc les _STRIP.
 
Nouveau Défi : Dessiner un cube sans lever le crayon (GL_LINE_LOOP quand tu nous tiens)

 
Ce n'est pas possible, il faudrait que ton graph ait 0 ou 2 sommets de degré impair... Il en a 8... pas de bol !

Tu peux juste expliquer en deux mots ce que sont des sommets de degré impair ?
Merci

ce sont des sommets qui font la jonction d'un nombre impair d'arêtes...

Merci !

Lorsque je mets en place le picking, je dois distinguer les objets pour lesquels je veux recevoir un 'hit', mais suis-je obligé de créer un second algirithme de dessin pour avoir les faces distinctes ?

Je pense que tu vas devoir en effet les distinguer lors du "rendu de sélection" mais tu peux aussi utiliser un picking par couleur (en plus du rendu de sélection)... Perso, je préfère utiliser des glLoadName pertinents...

Merci, j'ai enfin réussi à faire quelque chose d'opérationnel, j'ai encore un petit souci de données. Lors du picking, on empile un numéro dans la pile avec pushname, puis on fait des loadnames et on termine avec popname. Avec le système de buffer, je n'ai pu récupérer que les loadnames, peut on avoir les noms empilés ?

Cette fonction ne retourne que les loadnames, les pushname sont ils inscrits dans le buffer ?

 
Oui, la pile complète est posée dans le buffer... et c'est tout l'intérêt !
Cette URL est sympa http://medialab.di.unipi.it/web/IU [...] ode87.html

Au fait, j'ai travaillé pas mal de temps avec OpenSG. C'est vrai que c'est orienté multi-plateformes multi-noeuds et RV mais il y a tout plein de choses intéressantes (arbre de scène, optimisations OpenGL, shader et surement d'autres choses ont évoluée depuis que je ne l'ai plus utilisé !)

 
Ben, ca me semblait pas logique aussi, mais bon... Donc déjà je vais devoir revoir ma fonction, ca n'est pas un souci mais le truc qui m'a fait trompé je ne le comprends pas, voici une autre fonction qui elle indique les piles successives :

en fait mon souci est la :
dans l'initialisation j'ai :

et dans ma fonction dessin :

Et ma fonction Affichehits, donne pour la pile 0 6 (pour la facette 6) et non 0 1 6.
 
J'ai fait des test et plus généralement, le pushname précédent le loadname n'est pas affiché dans la pile, c'est normal ?

 
Oui, c'est ainsi qu'elle est définie dans la doc... glLoadName remplace le haut de la pile...

  Argh, si c'est dans la doc et que je l'ai pas vu, je suis impardonnable ! En tout cas merci, je m'en tire finalement pas si mal de cette erreur...
Ce qui m'étonne c'est j'avais du le lire, puisque j'avais mis qqch dans la pile pour eviter l'erreur du glLoadname mais que je me souvenais plus pourquoi je faisais ca  

Avant que j'aille trop loin y'a un truc auquel j'ai pas pensé, c'est la possibilité multilingue, pas que cela me soit carrément utile, mais, la méthode m'interresse.
En gros je créé des tableaux, et selon un id de langue, je choisis une case.
Est-ce la seule méthode viable ?

C'est bien de penser à l'internationalisation dès les premières lignes... Perso, je suis partisan des "fichiers de langue"... A la place de toutes les chaînes que tu affiches à l'utilisateur tu fais appel à une fonction à qui tu passes un "identifiant de chaîne"... Cette fonction devra te retourner la chaîne extraite du fichier de langue choisi par l'utilisateur et identifiée par l'identifiant de chaîne.
Pour information, sous Windows, on utiliserait des "string tables" stockées dans un fichier de ressources (une "dll" ) et des appels à "LoadString"... Mais un fichier de langue dans un format texte lisible sera plus pratique pour ajouter de nouvelles langues.

VRML? Format proprietaire?
Je crois qu'il est temps que je me lance dans le lobbying pour un export triangulé en .obj ce qui offre la garantie de pouvoir importer le bazar à peu près partout - notament dans mon rtrt
 
Exporter des triangles avec le minimum syndical au niveau hierarchique est d'une simplicité enfantine.
Wavefront, la specification: http://www.martinreddy.net/gfx/3d/OBJ.spec
Optionnelement les materiaux: http://www.fileformat.info/format/material/

J'ai encore quelques interrogations à vous soumettre :
- le fichier de traductions avec des indentifiant chiffrés ou lettrés ?
(je demande à mon prog d'aller lire le fichier de langue et de renvoyer le message dont la ligne commence par l'identifiant "XX" (un chiffre, plus rapide, moins lisible dans le programme et plus difficile encore à traduire) ou par "abcdef" (une abbréviation, plus long, mais plus agréable à lire...)
 
- les coordonnées il vaut mieux les enregistrer en relatives ou absolues ?

Je choisirais de faire une gestion des langues la plus "human-friendly" possible (identifiants texte dans un fichier texte) car ça ne doit pas être le goulet d'étranglement de ton application sinon, c'est qu'il y a un sérieux problème de conception... C'est sûr qu'un fichier "binaire" avec des identifiants numériques serait plus performant lors du chargement, mais bon... 'faut pas déconner !
 
Pour tes coordonnées, je travaillerais en relatif pour rester dans la plage la plus précise des "float" (ou "double" )...

J'ai décidé de faire les deux posibilités :
ce qui me donne un fichier :
index abrev = message
soit :
0001 hellow! = Hello world !
Comme ca marche, je vais laisser ca comme ca on verra après !

J'ai une question qui concerner les wxDC et wxCanvas, étant donné qu'il n'est pas possible nativement d'écrire du texte dans OpenGL, la fonctionnalité est présente avec la fonction DrawText() de wxDC.
Est-ce que cela peut fonctionner :  

avec "this" un wxCanvas ?
Je n'ai pas de message à la compilation mais je n'ai rien à l'écran, j'ai surement oublié un truc...

Bon le problème c'était pas grand  chose, juste une meilleure déclaration :