Author Topic: format de mesh en 3d et autre question d'export de formats  (Read 6454 times)

0 Members and 1 Guest are viewing this topic.

Offline krabob

  • Base
    • Pouet.net
    • View Profile
    • www.m4nkind.com
  • Ancienneté: 1994
  • Groupe: Mankind
  • Rôle: code amiga / linux / OpenGL
  • Ville: Toulouse
format de mesh en 3d et autre question d'export de formats
« on: 10 February 2011 à 15:58:14 »
 Tient, une petite question d'ordre générale en 3D...
Historiquement, j'ai bossé avec les vieeeux .3ds, puis du lightwave (.lwo, que j'apprécie pour la concision du format), et là je me demande si je vais pas faire un exporteur pour blender *ou* patcher / développer l'exporteur lwo de blender pour lui ajouter des trucs qui manquent.... (les .blend étant eux-memes trés inflatés)

Digressions sur le meme thème: Pour le boulot, j'ai maté les importers de openscenegraph, à la recherche d'un format qui supporte les UV mapping et les animations de skinning pour des persos... et je vois que le collada est à la mode (c'est du xml, pas génial un format texte pour de l'embarqué ou des démos.)

et bref, rien à voir, mais je me pose une question bête: dans les .3ds et les .lwo (et la plupart des formats 3D quand on est pas dans des descriptions procédurales), les surfaces sont définies par une liste de polygones (triangles, ou quad, ou n-gone pour lightwave)...

 mais techniquement, il me semble qu'il est plus rapide, pour afficher des meshs sous opengl, d'utiliser du GL_TRIANGLE_STRIP que du GL_TRIANGLE ou GL_QUADS. De plus, si on imagine un format de fichier qui décrirait les polys d'un mesh sous la forme de trés long GL_TRIANGLE_STRIP, la description des polygones prendrait moins de places dans le fichier. De plus il y a un trick possible avec GL_TRIANGLE_STRIP pour "sauter" d'un amas de triangle joint à un autre (avec un triangle écrasé sur une ligne).

Donc la question est la suivante: Est-ce qu'il existe déjà des algos ou des fonctions dans des logiciels, pour "créer la liste GL_TRIANGLE_STRIP la plus optimale à partir d'une liste de triangle bête.".
... et sinon, l'algo ressemblerait à quoi ? certainement un truc d'algo de parcours de graphe pour "passer partout en restant le plus droit possible." ?

 Discuss...
Votez comme ça Mélenchon ... ou Clément Wittman, ... ou Eva ! Oo

Offline flure

  • Base
    • Pouet.net
    • View Profile
  • Ancienneté: 1998
  • Groupe: PoPsY TeAm
  • Rôle: Codeur Linux
  • Ville: Lyon
Re : format de mesh en 3d et autre question d'export de formats
« Reply #1 on: 10 February 2011 à 16:40:28 »
J'avais lu un article de TuO (...) là dessus, je poste le lien ce soir, en plus les formats de fichier (et blender !) ça m'intéresse aussi !

Offline Patapom

  • Base
    • View Profile
    • www.patapom.com
  • Ancienneté: 1988
  • Groupe: Bomb!
  • Rôle: Coder
  • Ville: Lyon
Re : format de mesh en 3d et autre question d'export de formats
« Reply #2 on: 10 February 2011 à 16:41:41 »
Hello,

si tu tiens vraiment à générer des tristrips qui tachent alors tu peux jeter un oeil sur cet article de Zappy : http://www.codercorner.com/Strips.htm

Sinon, entre nous, générer des strips plutôt que des trilists n'a plus vraiment d'importance sur les cartes actuelles. Effectivement, tu "perds du temps" à uploader des infos d'index supplémentaires mais c'est tellement négligeable par rapport aux shaders que t'appliques... 'fin y a du stall sur les shaders donc ta BP pour uploader des infos de vertex est de toute manière pas utilisée, alors que t'upload des index ou pas, ça change rien.

Biz ! ;D
.  Pom  .

Offline MooZ

  • Base
    • Pouet.net
    • View Profile
    • Lair of the procrastinators
  • Groupe: BlockoS
  • Rôle: Dieu vivant du code sans fin
Re : format de mesh en 3d et autre question d'export de formats
« Reply #3 on: 10 February 2011 à 16:46:59 »
L'export depuis Blender est assez simple. Je te conseille de plutôt jeter un oeil sur l'exporteur .ply. Mais surtout de partir de la 2.5.

Pour les strips vs triangles, il s'agit plus d'une histoire de cache qu'autre chose si je ne raconte pas de conneries. Les strips prennent juste moins de place. Sinon comme tu l'as dis, si on a par exemple une sphère, il faudra passer par des triangles dégénerés pour avoir un seul gros strip.
Après je ne connais pas l'impact des triangles dégénérés sur le pipeline. Si ça se trouve le coût infligé est non négligeable.
Et puis si ton mesh n'est pas super gros ça ne sert pas à grand chose de se prendre la tête avec des strips.

Pour créer des strips il y a 3 tonnes d'algo (généralement ça parle de clustering, cache coherence). NVidia a une lib pour la génération de strips : [nvtristrip].

En bonus : Efficient Triangle Reordering for Improved Vertex Cache Utilisation in Realtime Rendering
La scène est marne en 77.

Offline krabob

  • Base
    • Pouet.net
    • View Profile
    • www.m4nkind.com
  • Ancienneté: 1994
  • Groupe: Mankind
  • Rôle: code amiga / linux / OpenGL
  • Ville: Toulouse
Re : format de mesh en 3d et autre question d'export de formats
« Reply #4 on: 10 February 2011 à 17:45:36 »
 Merci à tous pour toutes ces bonnes infos...  :D
 Raaa mais je découvre que tout les importers / exporters de blender sont 100% en python !!! aaaaaargh pas cool si je dois me mettre à apprendre un langage exprèèèèss !!!
Votez comme ça Mélenchon ... ou Clément Wittman, ... ou Eva ! Oo

Offline Patapom

  • Base
    • View Profile
    • www.patapom.com
  • Ancienneté: 1988
  • Groupe: Bomb!
  • Rôle: Coder
  • Ville: Lyon
Re : format de mesh en 3d et autre question d'export de formats
« Reply #5 on: 10 February 2011 à 18:16:00 »
A noter que je déconseille fortement Collada qui fait des fichiers énormes et tous pourris...

Au boulot on a changé de Collada vers FBX et on était très contents. Surtout que FBX te permet d'exporter tes paramètres de shaders, ce que Collada pouvait à peine faire à l'époque (y a 2 ans).
Les artistes étaient très contents d'utiliser les mêmes shaders dans Max/Maya que dans l'engine runtime, et on n'avait pas à se retaper le paramétrage, ce qui représente un temps considérable dans le pipeline de production...
.  Pom  .

nystep

  • Guest
Re : format de mesh en 3d et autre question d'export de formats
« Reply #6 on: 10 February 2011 à 19:51:50 »

Offline flure

  • Base
    • Pouet.net
    • View Profile
  • Ancienneté: 1998
  • Groupe: PoPsY TeAm
  • Rôle: Codeur Linux
  • Ville: Lyon
Re : format de mesh en 3d et autre question d'export de formats
« Reply #7 on: 11 February 2011 à 10:29:42 »
bah python c'est super ! :)

Offline flure

  • Base
    • Pouet.net
    • View Profile
  • Ancienneté: 1998
  • Groupe: PoPsY TeAm
  • Rôle: Codeur Linux
  • Ville: Lyon
Re : format de mesh en 3d et autre question d'export de formats
« Reply #8 on: 11 February 2011 à 11:35:05 »
Je pense aussi que les strips ne sont plus vraiment nécessaires de nos jours.
Par contre, pour le format de mesh, ce qu'on met dedans est assez standard : vertices, normales, couleurs, (matériaux ?), etc... Mais pour les animations ? Une référence vers un autre fichier qui contient le squelette et ses anims, des keyframes, autre chose ?
Pareil pour une scène complète : on met les mesh dedans, ou des références au fichiers de mesh avec leurs positions ? On stocke les animes dans la scène, ou encore une fois juste des références ?

Bref toutes ces histoires de design ne concernent pas que les formats de fichiers, mais ça m'intéresserait d'avoir votre point de vue :)

Offline krabob

  • Base
    • Pouet.net
    • View Profile
    • www.m4nkind.com
  • Ancienneté: 1994
  • Groupe: Mankind
  • Rôle: code amiga / linux / OpenGL
  • Ville: Toulouse
Re : format de mesh en 3d et autre question d'export de formats
« Reply #9 on: 11 February 2011 à 12:19:11 »
Là par contre je sais bien répondre:
 Dans tout les modeleurs 3D , tout est géré en tant que "ressources", mais cette gestion varie selon les logiciels/formats:

-Un seul fichier "vieux" .3ds peut contenir "tout", à savoir dans les premiers chunks des meshs (nommés), accessoirement leurs morfs ou squelette, puis ensuite, toute les info "cinematique" de la scene, qui se référent aux objets par leurs identifiant, décrit les différentes camera, ....
 En général, les courbes de cinématiques (spline, bézier) sont aussi une classe d'objet indépendant, potentiellement référencés plusieurs fois.
 Idem pour les matériaux, nommé ou indexé, et référencé par les polygones.
 Les fichiers images sont en général donné par une URL relative vers l'extérieur.
 à noter que les .3ds sont pratiquement des ".iff " (format binaire avec identifiant de chunk qui permet de parser un arbre, inventé par EA dans les années 80, sur-utilisé à l'époque de l'amiga)
(edit: je ne sais pas si une scene dans un  .3ds peut référencer un mesh qui est dans un autre .3ds, je pense pas, il fallait faire "import mesh d'un autre .3ds" pour faire ça je crois).


- Pour lightwave, c'est intéressant car les meshs (plusieurs)+lesmatériaux (et les liens vers les images)+les morfs, les squellete et les courbes sont dans des .lwo, (qui sont complétement des .iff eux, mais on s'en fout), étudié pour avoir des tailles de fichiers trés minimaux (les .lwo sont tout petit, ya pas un byte en trop). A l'intérieur des .lwo les objets de toutes classes sont identifié et référencé par des noms , qu'on donne dans l'éditeur ou qui sont donné a défaut (ou par des index).
- Jusque là c'est commme les .3ds, sauf qu'il y a pas la description des scenes dans les .lwo -

 Les données qui décrivent une scene lightwave sont dans des ".lws" qui eux par contre sont au format textes, et référent les données à l'intérieur des .lwo.
(C'est marrant parce que certains types d'objet, comme les  courbes splines , peuvent être décrite en binaire dans les .lwo , ou en texte dans les .lws)
( En fait, la disparité Modeleur/Animateur va jusqu'au bout dans lightwave puisque il y a en fait 2 appli couplées: le modeleur et l'animateur.)

... donc un moteur qui lit ces trucs doit faire de la gestion de ressource: par exemple un .lwo ne doit être lu qu'une fois si il est référencé plusieurs fois, pareil si une image est utilisé par 2 matériaux, il faut pas l'avoir en mémoire 2 fois.
Donc en général il faut avoir des hashtable ou tu références tes objets déjà chargé par leurs noms.

(ps: collada c'est effectivement le pire format trop moche)
(re-re-edit-ps: l'exporter blender fbx python est bien installé a defaut, à vue de nez il fait le skinning (directement chopable avec OSG en théorie), et je suis miro apparement.)
« Last Edit: 11 February 2011 à 13:49:10 by krabob »
Votez comme ça Mélenchon ... ou Clément Wittman, ... ou Eva ! Oo

Offline xoofx

  • Base
    • Pouet.net
    • View Profile
    • xoofx
  • Ancienneté: 1989
  • Groupe: FRequency
  • Rôle: code (+musique), web
  • Ville: Grenoble
Re : format de mesh en 3d et autre question d'export de formats
« Reply #10 on: 11 February 2011 à 12:30:39 »
A noter que je déconseille fortement Collada qui fait des fichiers énormes et tous pourris...

Au boulot on a changé de Collada vers FBX et on était très contents. Surtout que FBX te permet d'exporter tes paramètres de shaders, ce que Collada pouvait à peine faire à l'époque (y a 2 ans).
Les artistes étaient très contents d'utiliser les mêmes shaders dans Max/Maya que dans l'engine runtime, et on n'avait pas à se retaper le paramétrage, ce qui représente un temps considérable dans le pipeline de production...
Pourtant, il y a dans la norme xsd des profils GLSL qui doivent sauver les infos pour les shaders... j'ai jamais trop vérifié si c'était utilisé dans un outil aussi...
Sinon, collada n'est pas si moche et plutôt facile à parser avec des libs existantes. De toute façon, collada ne doit être vu que comme un format intermédiaire de sortie d'un outils 3D. Quelque soit le format, il est souvent conseillé pour des raisons de perf de le traduire en format interne binaire, spéficique à un moteur.

Offline Patapom

  • Base
    • View Profile
    • www.patapom.com
  • Ancienneté: 1988
  • Groupe: Bomb!
  • Rôle: Coder
  • Ville: Lyon
Re : format de mesh en 3d et autre question d'export de formats
« Reply #11 on: 11 February 2011 à 14:08:06 »
Pourtant, il y a dans la norme xsd des profils GLSL qui doivent sauver les infos pour les shaders... j'ai jamais trop vérifié si c'était utilisé dans un outil aussi...
Sinon, collada n'est pas si moche et plutôt facile à parser avec des libs existantes. De toute façon, collada ne doit être vu que comme un format intermédiaire de sortie d'un outils 3D. Quelque soit le format, il est souvent conseillé pour des raisons de perf de le traduire en format interne binaire, spéficique à un moteur.

Bah p'têt maintenant qu'il le fait (i.e. sauvegarder les variables de shaders) mais c'était pas évident à l'époque. Et le truc c'est que, même si c'est un fichier intermédiaire, ça reste du texte et donc 1) ça prend une place folle sur disque car très verbeux et 2) ça met un temps fou à loader/parser.
FBX c'est du binaire, c'est plus compact, c'est extensible et ça se charge/parse très vite pour ensuite resauver vers son propre format propriétaire bien entendu puisque de toute manière tu n'as pas accès au format FBX mais tu le lis via le SDK, que tu vas pas t'amuser à embedder dans ton engine de toute manière...

'fin je vous dis ce qu'on a fait en prod sur des gros projets, sur des petits comme des démos Collada peut très bien faire l'affaire. C'est vous qui voyez.
J'ai également un loader de scènes FBX en C# que vous pouvez utiliser pour sauver vers un format binaire propriétaire ensuite si vous voulez mais bon... ;D
.  Pom  .

Offline RaHoW

  • Base
    • Pouet.net
    • View Profile
    • Apex - official site
  • Ancienneté: 1993
  • Groupe: Apex
  • Rôle: Gfx, code, orga
Re : format de mesh en 3d et autre question d'export de formats
« Reply #12 on: 12 February 2011 à 14:58:48 »
Pour Collada, moi ça m'a servi ^^

En fait je voulais écrire un format pour mon code, et le faire direct en export Python depuis Blender... manque de bol le code a jamais voulu s'exécuter, même un simple "print" (j'ai surement dus zapper une manip' à faire ~___~ ).

Conclusion, j'ai cherché un autre format, et j'ai vu Collada, tout décris en XML ---> je me suis fais un bête converto en PHP (qui m'était 10x plus accessible que Python ou C++): C'est pas du tout un truc évolué, mon seul but c'était de récupérer vertex/faces/TC et normales d'un objet fait sous Blender...

Et du coté Collada, c'est decrit en XML avec des noms pas du tout cryptiques: le tableau des normales c'est bien écrit "Normales" dessus, spas la peine d'eplucher 10 000 docs pour savoir où il est ^^
« Last Edit: 12 February 2011 à 15:05:06 by RaHoW »
=RaHoW/Apex=