Bonjour à tous.  
 
1° )
Je me demande si les routines glBegin() & glEnd() appelée répétitivement mais dans une/des DisplayList est vraiment catastrophique niveau performances, en comparaison avec les tableaux OpenGL (tableau de vertices, coord de textures ...).
 
2°)
Ceci car j'ai actuellement des données sur un maillage et que ces données sont déjà indicées. Ainsi j'ai la définition de tous les vertices du maillage et de même avec les coordonnées de textures. Toutes ces données sont indicées et il arrive (souvent même) qu'un même vertex est plusieurs coordonnées de texture.
 
J'ai donc utilisé dans un premier temps ces routines de base dans des DisplayList comme un bourrin que je suis. J'aurais bien voulu faire appel à ces tables OGL mais comme j'ai pas une correspondance vertices/coord de text dans les indices, bah je crois que c'est pas directement possible vu que les routines glArrayElement et voisines comme glDrawElements et consors prennent - il me semble - un incide commun qui renvoit à tous les tableaux activés.
 
Il faudrait donc doubler les veritices qui possèdent plusieurs coordonnés de texture. Mais ils sont nombreux dans ce cas et je pense que tout l'intérêt des Array est alors perdu. Mais je me trompe peut être surement, c'est pour cela que si quelqu'un à été confronté à ce problème où si il existe des extensions qui permettent un tel indicage (des indices différents qui renvoit au différentes tables active quoi), bah je suis preneur
 
Je sais pas trop quoi faire pour pallier au performance/répétition de données. Donc si vous avez des suggestions (que j'aille me pendre ou autre) bah je suis preneur !
 
Merci à vous.

pour les modèles 3D, où il y a quelques vertexs qui vont avoir une normale/coordonnée de texture différente, on duplique le vertex et sa normale/coord UV associée.
 
(ie une modèle d'avion, là où les normales forment un angle violent, on duplique)
 
je pense par exemple aux modèles issus de 3DS Max & co....  
 
---
 
bon déjà, chose la plus claire: les indices permettent d'utiliser le cache post T&L, donc il y a très rarement des cas ou ne pas utiliser un buffer d'indice est interressant..... (point-sprites par exemple)
 
----
avoir plusieurs array, ça génère plusieurs flux de donnée géométriques. dans la pluspart des faq d'optimisation, ati & nvidia recommande de "packer" tout ensemble (plus friendly vis à vis du cache pré-T&L).
 
enfin je dis ça, j'essayes de m'approcher des contraintes du hardware qui sont mieux représentée en D3D...
 
si tu dupliques, tu augmentes la taille mémoire du buffer à vertex, mais tu as un flux unique et favorable au hard (et tu peux exploiter un index buffer qui permet d'exploiter le cache post-t&l)
 
en fait tout dépends de la proportion de vertexs (sous-entendu +normale+UV) que tu vas devoir créer, 30% est acceptable, un x3 peut devenir gênant.
 
---
 
pour les glBegin() glEnd(), c'est pas compliqué:
tu auras plus de "coût API" au moment de la génération de la display list.
 
en fait un vertex buffer (d3d ou VBO ogl), tu as un coût API au verrouillage du buffer, tu peux alors remplir des millions de triangles/vertex sans coût API.
 
alors que par les glBegin()/glEnd(), tu as un ou plusieurs coût API par primitive 3d.
 
après cela ressort en fonction de ta fréquence de création de display list.
 
si c'est uniquement au lancement/chargement des objets c'est bon.
 
par contre si c'est pour un moteur de terrain, où des patchs sont générés à moyenne/haute fréquence, les vertex/index buffer vont prendre un très net avantage.

je te remercie vraiment pour ces indications bjone, on sent le routard du dx et des spécif' constructeur. Je vais aller voir ce que sont ces fameux 'pack' et pis essayer de voir si ces foutus vertices peuvent bien se dupliquer sans trop abonder.  
Sinon, je modifie pas le modèle une fois chargé, je découpe, mets dans des DL (à base de glB/glE donc...) et ensuite callList des listes visibles.  
Bon mes trucs sont pas trop gros mais j'avoue que ça me plait pas trop ces routines glB/glE.
 
Merci d'avoir passé du temps à répondre et pis bonne soirée todo lo mundo.
 
PS : mes modèles sont justement extraits de 3Dsmoux, par OBJ et mtl .J'pense reclacluer les normales car y fait un peu n'importe quoi j'ai l'impression (les "scale" dans 3ds doivent pas arranger les normales).

je suis pas un routard, mets DirectX expose les bonnes pratiques, j'essayes de les transposer pour toi en OpenGl (en essayant de pas trop dire de conneries   )
 
j'ai pas regardé précisément l'implémentation, mais grosso modo:
 
http://nehe.gamedev.net/data/lesso [...] ?lesson=45
 
la création des VBO est dans "BuildVBOs()"
 
et la définition du contenu des VBO est dans "Draw()", au commentaire "// Set Pointers To Our Data". (en fait que je disais "packer" c'était avoir un seul flux d'éléments vertex+normale+UV+...)

oki bjone, mais encore une question (surement "alacon" ). Si je veux partionner une scène contenu proprement dans des tables tout nickel (vertices dédoublés juste ce qu'il faut), bah ça chamboule tout !? J'voulais par exemple y affubler une sorte d'octree (hybride avec le quatree car ma scène contient pas beaucoup de faces dans le sens verticale, donc j'aurais fais des box qui tiennent juste la hauteur et qui se présenterai donc comme un quadtree, êut être même fais "a la main", sans récursivité).  
Dans ce cas, si je ne me trompe pas, faut que je refasse un ensemble de tableaux pour chaque partitionememt (chaque box) et pis que je pack ces tableaux entre eux et donc avoir un VB par box OU bien que j'organise ces grands tableaux de V/VT/VN de telle sorte à ce que les faces soient "triées" dans ces tableaux de manière à avoir par exemple les faces n à n+5000 appartenant à la box B.  
Et là je sais pas trop comment m'y prendre, entre encore dédoubler les vertices pour pouvoir considérer les faces chevauchant plusieurs box ou alors diviser les faces de manière à ce qu'il n'y ai pas de faces communes aux box avoisinantes. Bref, que me conseillerais tu cher bjone ?
 
Merci pour le lien, je comprends bien le truc, ça ressemble beaucoup aux tableaux d'OGL sans extension, mais ça doit surement être beaucoup plus rapide, envoit des données direct sur la cg !!
 
Moi je rêve d'une routine qui prenne des tableaux de données (v || vt || vn) et qui ensuite nous demande d'indiquer LES tables d'indices sur ces données (en fonctions des tables de données activées) : on aurait alors des tables de données de taille différentes mais des tables d'indices de même longueur et pour tracer un triangle à l'indice 0, l'API irait chercher les 3 vertices consécutifs de l'indice contenu dans la case 0 du tableau d'indice sur face, puis la coord de text se trouvant à l'indice contenu dans la case 0 du tableau d'indices des CoordT (et donc pas forcément le même indice).  
Mais là je crois que c'est une utopie et que ce serait pas optimale pour l'api. M'enfin je peux toujours rêver.
Merci et pis bone journée

hummm là on rentre dans les dilemnes d'implémentation
 
effectivement c'est dans ce genre de cas qu'ils y a une panacée de compromis.
 
bon l'exemple de Nehe, c'est sans tampon d'indices.  
ce qui est mal vu que si c'est pas un strip ou un fan, et donc des triangles indépendants, le cache post T&L n'est pas utilisé, et le moteur T&L/VertexShader transforme 3 vertexs par triangle (et non quelque chose entre 1 et 2 deux vertexs en moyenne, suivant le cache hit).
 
concernant ta scène, je sais pas trop ce que tu veux faire, mais grosso-modo si tu prends UT2003/2004, tu as des statics meshes qui sont des modèles 3D (buffer vertex+index), un moteur de terrain, par contre je sais pas comment le reste des salles sont "maintenues" (quelque part un gros bloc certainement), le tout testés à travers des portals.
 
là c'est plus simple, tu as:
 
salle A<->Portal<->salle B
une salle contenant la salle en elle-même, des instances de StaticsMeshes, et des portions de terrain....
 
en fait j'ai sait trop rien comment c'est implémenté exactement, c'est un peu comme ça que je le verrai.... (donc big conneries possibles inside)
 
----
 
pour ton truc, ce que tu peux faire, c'est:
 
1) avoir un VBO qui maintiennes tout ton monde (+buffer d'indices si possibles, je sais pas comment c'est foutu en ogl)
 
2) avoir un tableau maison, qui pour chaque secteur de ton mon monde (découpé par octree/salles....), maintiennes l'indice de début et le nombres de primitives à traçer...
 
a vi je vois ce que tu veux dire, effectivement dans ce cas tu risques de devoir dupliquer des vertexs...

sinon à priori quand tu fais une display list, le driver OpenGl crée probablement(pour pas dire très certainement) en interne un buffer de vertexs, la rentabilitée de la chose étant liée à ta fréquence d'invalidation de la display list.

merci des réponse bjone,
pour ce que je veux faire en fait c'est importer des terrains diverses depuis des logiciels de modélisations style 3DS via du .Obj et du .mtl. Après ça je voulais donc réunir les faces par matérials (donc pas forcément texturé la matérial, et pas de multitexture non plus). Le problème c'est que je n'ai aucun aprioris sur le maillage importer (ça doit être un chargeur générique si je puis dire). Ce que je pensais faire , c'est réunir au max par textures (par matérial en fait) pour ensuite faire le moins de changement d'état (au niveau des material d'OGL et aussi des changement de texture). Y'a donc ce problème de texture car si on pend un terrain par exemple, il se peut que d'un coup d'un seul qu'une face est une texture A avec les CT a1,a2 et que sa voisine une texture B et CT b1,b2.  
 
Déjà faut que je trie ces foutues faces (oui, je les maltraite) pour en faire - comme tu l'indique dans ton petit 2) à la fin - un petit tableau maison qui donne pour chaque materiaux une liste de face, ou mieux une liste de vertices/vt/vn avec répétition de ce qu'il faut pour pouvoir indicer correctement les faces et changer d'état entre chaque case du tableau.
Sinon je pense pas tout pouvoir caser en un VBO si? quoique... va falloir que j'apprenne à ranger mes vertices hehe.
 
Donc je pense que tu as compris ce que je voulais faire, t'es vacjement balaise parceque même moi en relisant bah... euh... j'parle français là .  
 
Par contre la fréqunce d'invalisation de la DL... euh, je connais pas, je vois pas trop.... tu veux parler du changement de DL ? C'est à dire que plus j'ai de DL, plus j'ai une freq d'invalidation élévée et plus performance plombée (normal aussi quand même) ?  
 
Pour finir, tu utiliserais quoi comme grande routine sous Direct3D, juste comme ça par curiosité (connais pas trop DX, déjà que OGL...).
 
En tous les cas bonne soirée à toi, à tous.
 
PS: Tu connais le pipeline de ta CG par coeur ou quoi. Faudrait que je le sache aussi, ça m'aiderai j'pense si je le connaissai "sur le bout des doigts".

ce que je voulais dire par rapport à la fréquence d'invalidation de la display list, c'est que si tu prends un Quake-like par exemple, la display list qui contiendrait le monde ne changerai que lorsque tu t'est suffisamment déplaçé pour avoir une configuration de salles visible différentes, ce qui assimilable à une basse fréquence (ie tu matraques de glBegin() glEnd() que lorsque une nouvelle salle est visible...)

le mieux pour ta technique, c'est:
 
au chargement/manipulation des ressources 3D:
 
1) créer la liste des matériaux
2) ajouter chaque triangle à son matériau: tu as une paire matériau/liste de triangles (liste de vertex donc)
 
et de faire ça en hors-ligne, via un outil maison (ie tu fais ton propre format de fichier). moi j'ai fait mon piti plug-in d'export 3DS Max (demande à chrisbk, il a souffert aussi sous 3DS).

merci des conseils, là je fais un scripts pour exporter les lumières, puis la caméra et éventuellement une trajectoire (grâce à un dénommée Bamboo qui m'a donné qq ficelles). Donc oué pourquoi pas un outil maison. Mais ce cher chrisbk doit masteriser le script max ...
Je vais voir si je trouve des link sur des tutos pour ce langage un peu déroutant... le maxscript... c'est avec ça que sont fait les plug in aussi ?  
 
sinon oué, en ce moment c ce que j'essais de faire à partir du .obj... pas glurp mais bon . Faut que je vois ces scripts...  
 
Thx.

bah en fait moi c'est un plug-in C++, je passes pas par les scripts

oki, j'avais pas connaissance de cette pratique . Tu programmes avec quoi si c'est pas indiscret. Moi là pour ce "truc" je dois dévellopper sous Devcpp.  

VS.Net 2003 (compilo C++ 7.1)

mais bon on dérive.
 
faudra que je regarde ce que l'on peux faire en script sous Max....

oué, ce fameux .net.  
A la dérive
 
Bonne soirée, ce coup-ci extinction des écrans pour ma part.
 
Faudra que je regarde de mon coté aussi pour ces sripts et pis s'il est possible de plugger avec devcpp.

le problème, c'est qu'il vaux mieux passer par un générateur de squelette de plug-in (qui est bien sûr, sous Visual Studio 6 )

oué à la rigueur je peux trouver ça (VS6).
Sinon ton (tes) plug-in exporte quoi exactement ?

géométrie + matériau.
 
tout l'optimisation des données du modèle est faite par le plug-in...
 
duplication des vertexs si ils partagent des normales différentes (smoothgroup), des coodoonnées de textures différentes....
regroupement par matériaux...
 
gestion de deux listes de matériaux, la première sont les matériaux opaques, la seconde sont les matériaux transparents (opaques => traçés tout de suite, transparents => traçés en fin de scène, j'ai pas encore implémenté de tri en pronfondeur pour les éléments transparents)
 
optimisation du flux d'index pour maximiser l'efficacité du cache post-t&l
optimisation du flux de vertex en fonction du flux d'index pour le cache pre-t&l
génération de bounding box & spheres pour les frustum culling et à terme les routines de collision que j'ai pas terminé....
(les bounding box sont celles de 3DS)
 
et export des "helpers" (dummy et point je crois) de 3DS qui sont juste de repères nommés, pour par exemple pouvoir monter des missiles sur les pilonnes des ailes d'un avion de chasse (ou autre sous-modèle, partie mobile....)
 
et fodra que je pense à faire une table qui me donne la plage d'index des triangles qui sont dans une bounding box 3ds. (ie en plus ça va avec le tri des éléments transparents)

sans oublier le support des matériaux "baked" (en fait y'a deux lignes de code pour ça).

c'est quoi les matériaux "baked", pas de texture ? multitexturé ?
 
Sinon j'ai fais comme toi pour les matériaux opaque ou pas (en vérifiant l'extension de la map comme un bourrin et ça en lisant le fichier... pas glop, faut le faire à chaque exécution) et j'ai q'une liste, mais je devrai peut être me calquer sur toi avec 2, c'est plus propre. Là j'insère en tête quand c'est opaque et en queue quand ça ne l'est pas (c pareil pour OGL que pour DX je pense, d'abord dessiner l'opaque avec un z buffer en lecture/ecriture, puis après la verouiller en n'activer le z buffer qu'en lecture pour tracer les objets avec des maps avec transparence. Et pareil pour moi je trie pas, ça va être chiant : les objets ayant ces caractéristiques sont des biplan qui représentent des arbres... beurk)
 
Sinon, tu parle de bounding box, tu ne fais pas encore le partinement à ce niveau là (pendant l'export) ? Je pense que non vu que tu parles d'une éventuelle insertion d'une table pour chaque box qui renvoie aux index des triangles. Mais ça aussi c'est chiant, parce que si tu as une table "globale" de tous les triangles de la scène, qui te dis que leurs indices dans une box sont toujours "à la suite" ? Tu fabrique ta liste de triangles en parcourant d'abord les bounding box de chaque objet  ??
 
Sinon ta scène c'est quoi (trop curieux gamin) ? Un terrain avec des détails aux sols et toute une tripotée d'avion ?  
 
Enfin typiquement, ton code ressemble à quoi ? Plus du langage de script ou plus à du c++. Je dis ça... j'ai jamais fait de plug in, je pense que ça doit être du c++... chuis con ou quoi.  
Par exemple en script, pour accéder aux lumières et les parcourir tu fais :

 
Enfin bref, là je tergiverse.  
 
Sinon je vois un peu plus clair de jour en jour grâce à toi.
 
Mais y'a ça que je pige pas trop :

 
C'est à dire que tes triangles indicés (par matériaux) se suivent au maximum pour que tu puisse balancer des strip ??  
 
Enfin ça fait des questions des questions Tu vas en prendre marre à le fin.
 
En tout cas merci.

alors dans le désordre:
 
déjà, pour te filer le contexte, moi je cherche à faire un xwing/freespace like, donc ce ne sont que des vaisseaux/missiles/astéroides qui sont/seront exportés depuis max.
 
donc les boundings box/sphères d'enveloppe dont j'ai besoin serviront aux frustum culling des objets, et aux tests de collisions.
 
la table bounding box => début+taille du bloc de triangles (donc d'indices), ça peut servir si:
- je veux pouvoir descendre au niveau triangle pour mes tests de collision (impact de balle => intersection rayon/triangle)
- trier par sous-élément transparent (si éléments transparents ont des blendings variables)
- pouvoir exploser le modèle (ie un réacteur se fait la malle suite à une colision avec un astéroide)
 
-----
 
sinon comme tu as pu probablement voir, dans 3DS ta scène est éclatée en une hiéarchie de Nodes, avec une matrice de position, une bounding box, un conteneur de vertex et de faces, et chaque face peut avoir un matériau différent et possède un smoothgroup qui permet d'obtenir la normale des vertexs.
 

 
oui & non, en fait le rendement max est généralement atteint par des triangles indépendant indicés.
l'indice permet de pas avoir 36 milles fois le vertex en buffer, et de ne pas transformer le vertex si il est toujours en cache.
 
le problème du strip, c'est que si tu le dégénères pas, tu va devenir limité par le cpu (trop d'appels de primitives), et si tu le dégénères ça fait des triangles superflus qui seront éléminés par le triangle setup (culling).
 
alors qu'avec des triangles indépendants, tu as un appel pour le traçage de tout un modèle, pas de triangles superflus, et seulement 2 indices de trop par triangle.
 
donc fo voir le balancement entre strip dégénéré (et indexé), et triangle indépendants indéxés.
 
l'idéal serait de pouvoir faire un strip, avec une valeur indice qui serait un code d'arrêt pour que le hardware recommençe un nouveau strip)
 
---
 
fodra que je regarde ce que l'on peut faire en script, je pense que les possibilitée sont assez différentes (et la courbe d'apprentissage aussi, certainement beaucoup plus dure pour le plug-in).
mais j'ai peur que le construction de vertex fourni (pos+normale+UV+...) soit impraticable en script...  
 
en fait il semble que beaucoup de chose que je fais dans le plug-in, tu le fasse (pas encore) au chargement des modèles dans ton moteur OpenGl, vu que tu as des tableaux de position/normales/UV de taille différente.
 
---
 
pour les matériaux "Baked", c'est "Coque" en français, c'est juste que dans Max, quand tu utilises un matériau procédural (donc impraticable à porter facilement en OpenGl/DirectX), style bois/marbre/bruit de perlin, tu peux lui demander de plaquer le résultat dans une texture.
 
en interne tu as donc un matériau "baked"/"Coque", qui as pour sous-matériau le matériau original (le bruit de perlin normal), et le matériau "faux": l'ancien qui a été produit dans une texture bitmap.
 
donc quand tu fais ça, 3DS peut génèrer un nouveau canal de coordoonées de textures, il te fait un aplatissement du modèle (tu vois l'objet déplié dans une texture comme un dé qui fait 6 faces par exemple), et donc le but c'est d'exporter ces coordoonées là et les propriétées du matériau ancré...

merci,
oué j'ai des tableaux v/vt/vn de différentes tailles (et donc tableau d'indices de même taille, mais plusieurs tableaux donc, vu que pas les mêmes indices du fait des pb évoqués notamment de non dédoublement des vetices).
 
Donc tu gère les groupes de smooth... ça fait encore du dédoublement ça, si je suis à peu près. Dédoublement du vertice quand coordT qui change d'un triangle à l'autre et idem pour la normale si les faces n'appartiennent pas aux même groupe de smooth. Humm, ça en fait des cas de figures. J'vais me pendre.
 
Sinon toi les plugin, t'as commencé avec des bouquins spécifiques ou bien des sites bien foutu ou avec tes jolis petits doigts comme un grand ?
--------
Pour l'instant je regarde un peu les tut' de max en script mais je sais pas si je ferais mieux que le fichier obj (couplé au mtl) que j'ai en ce moment.  
M'enfin, merci de la longue et précieuse réponse (pour le procédurale, pas pour tout de suite je pense ).
--------
Sinon par curiosité, il te fabrique une map rectangulaire avec les 6 faces juxtaposées "sans blanc" si je reprend ton dé de 6 faces pour les textures. Sans blanc, j'entend pas en forme de croix avec une perte pour rien sur les bords.
 
--------
 

==> glurps ... mais oué je pense que t'as raison... re-glurps
 
En tous les cas merci de prendre autant de temps pour répondre.

 
bin en fait tu regardes tous les sources fournis avec.
y'a la source du plug-in d'export en ASE, en creusant un peu t'arrives à suivre...
 
---
 
sinon pour l'aplatissement auto des modèles, c'est souvent assez bancal, mais ça doit être paramétrable/éditable.
 
si tu veux faire un essai, tu prends un modèle 3D sans matériau, tu mets un "Marbre" pour la texture diffuse.
 
et en ayant sélectionné le modèle, tu appuies sur 0 "normal" (celui avec le "@" et "à" ), et tu as le menu du rendu en texture.
fo définir le chemin de sauvegarde des textures, en bas t'as un endroit où tu peux rajouter un canal, donc fo rajouter le canal diffus, et après en cliquant sur "rendu", il te fait l'aplatissement et le rendu en texture.....
 
comme ça si tu veux voir le truc....
 
enfin bon, pour gérer le truc de manière basique lors de l'export, c'est pas compliqué (quand tu tombes sur un matériaux "coque", tu prends le deuxième ou premier sous-matériau....)

en fait en interne je gère une map matériaux 3DS => matériau maison (basique genre chemin texture+diffus/spéculaire/transparence).
 
je balayes les nodes...
  pour chaque objet géométrique
  -> récupération de la bounding box
  -> récupération de la matrice
   
  je prends la liste de vertexs...
  je récupère les vertexs dans un tableau temporaire  
  pour chaque vertex à plusieures normales  je "développe" ses copie à la fin du tableau
 
  donc pour N vertexs de 3DS, j'ai ces N vertex dans mon tableau maison, les dupliqués après ces N, et en gros y'a un système de liste chainée (par indice) qui me permet d'avoir chaque vertex 3DS, tous les autres vertexs copiés qui ont un normale différente (le smoothgroup est maintenu)
 
  après pour chaque facette, je recherche le vertex associable (par le smoothgroup) pour chaque sommet
 
  et j'ajoute la facette au tampon temporaire du matériau (de la facette )
 
  si le matériau a une texture d'utilisée, je récupères le couple UV (mise en forme en fonction des propriétées 3DS Max ) pour chaque sommet, et:
  si le vertex assigné a pas d'UV
     => l'UV est assigné au vertex du sommet
  si y'a pas de vertex dupliqué avec le même UV
     => duplication, le nouveau à l'UV, la liste chainée  est actualisée
 
-- fin du traitement par node
 
voilà rien que pour récupérer des couples position/normales/UV uniques et partagés par indices
 
et je te parle pas encore du bordel qui viens après pour tout avoir propre en flux optimisé (via un simulateur de cache FIFO de cache post-T&L) pour les indices, et la défragmentation/mise en flux des vertexs en fonction des indices...
 
 
----
 
genre ça c'est ce qui maintiens mes vertexs dans le plug-in d'export (c'est temporaire par Node en fait, tout les bricolages & optimisations sont locales à une Node, donc tant que le nombre de vertexs/faces est distribuée dans des sous-élements, ça va suffisamment vite)
 
donc tu vois le smoothgroup est maintenu par vertex
Next indique la prochaine copie à smoothgroup/normale différente
NextTextured indique la prochaine copie à UV différente
 
donc en fait j'ai fait deux niveau de "si c'est pas le même vertex je recopie avec des nouvelles propriétées"
avec d'abord une recherche par smoothgroup normale (Next), et ensuite une recherche par UV (NextTextured)
 
en fait sur un modèle, généralement tu as assez peu de duplication (5-10%, fodra que je fasses un log....)
 

Merci, je relirai tout ça demain matin, la j'ai les paupières qui veulent plus coopérer.  
 
Merci de tout le mal que tu te donnes. Faudra que je "rende" ça à quelqu'un quand je t'arriverai à la cheville hehe.
 
Car comme le dis ma signature :

oulà pas dire ça    
dans quelques mois et quelques migraines t'aura ce que tu veux  

re,
 

 
oué, c'est vrai, mais faut me comprendre, c'est le stress des exams . Et pis le réveil à 7 heures est rude.
 
Sinon j'ai un peu "réfléchie" et quelques interrogations me viennent (couplées à quelques spéculations) :
 
1°) une fois tous les vertices dédoublés autant de fois qu'il le faut (pour une ct  et pour une normale), si tu retourve un vertice X sur une face mais que celui là n'a pas de CT ni de N, tu lui fais un dédoublement, ou tu considère que chaque face est obligatoirement texturée ou normée.
 
2°) La variable membre Position sert à quoi exactement, car malgré le commentaire.... j'ai po compris. De même pour le tVid.
 
3°) A la fin, tu as quoi ? C'est bien un tableau -un emplacement par matérial- (ou liste je sais pas) de listes de faces ? Ou tu as plusieurs tableau de matérial, c'est à dire un par box ou sphere englobante. Vu que tes box contiennent des faces appartenant à un seul et unique modele.
 
4°) Pour ce qui est de ton découpage de l'espace, tu te base uniquement sur les bounding sphere/box ou bien tu subdivisent encore celles-ci pour faire des sortes d'octree ? (plutot la 1ere solution non? vu que tes éléments ne s'étalent pas trop - a part si tu as de grosses fréguates de l'espace intersidéral , un frustum culling sur les bounding primitive doit suffir - a part pour tester plus rapidement les collisions peut être)
 
5°) Tu tries tes triangles d'une manière spécifiques ensuite ? "via un simulateur de cache FIFO de cache post-T&L" c'est ça ?  
Parce que sinon, avec le décalage des vertices dupliqués en fin de liste, ça fait des "trous" dans les indiçages, donc c'est ça que tu essais d'arranger au mieux ?
 
6°) Sinon pour faire un plug sous visual, y'a un wizard spécifique à Max normalement pour créer le frame work (parce que je vois pas de Max plug in ou chose du genre). J'vais essayer de réinstall Max peut être.
 
7°) De même, tu parmais de ragarder le plug d'ase exporter dont tu parlais, le source se trouvent sous quelle forme ? car dans le fichier plug in de max y'a que des fichiers binaires. Peut être que tu y accède direct sous l'interface de max ? j'vais chercher.
 
 
Voilà, j'ai fini d'être chaint pour le moment.
Merci += 1
 
 

alors:
 
1)
2)
3)  
5) ensembles.
 
bon j'ai pas détaillé le bordel, mais en gros:
 
je gère que deux types de vertexbuffers (vbo) pour les modèles:
 
le premier c'est (position+normale) couleur donnée par le matériau
 
le deuxième c'est (position+normale+UV) + matériau utilisant une texture pour l'éclairage diffus.  
 
la classe que je t'ai montré, c'est une classe qui maintiens -temporairement- les vertexs de la Node de 3DSMax que je suis en train de mouliner.
 
après tu as deux tableaux(conteneurs), qui maintiennent les éléments de type (position+normale), et (position+normale+UV).
 
donc en gros y'a un système qui maintiens les utilisations croisée temporaire. une fois que la node est finie, le flux d'indice temporaire est optimisé ( 5) ), le flux de vertex temporaire est optimisé, puis tout est émis dans l'un des deux conteneurs finaux qui vont bien (voir les deux si le vertex de 3DSMax est utilisé par des facettes dont l'une a une texture et l'autre en as po)
 
donc à la fin dans mon fichier j'ai:
 
indexbuffer 16bits
 
par vertexbuffer
    nbre de matériaux différents      
    par matériaux
         propriétées matériaux
         offset vertexbuffer
         traçage de triangles indépendant: départ indexbuffer, longueur.
 
avec donc au maximum deux vertexbuffer différents (canal 0: pos+norm, canal1: pos+norm+uv)
un nombre variable de matériaux
puis deux entiers qui me servent à savoir quelle portions d'indices utiliser dans l'indexbuffer (et un offset qui sert à compenser les indices 16bits)

4) oui, je pense que ça devrait suffire, fo que les bouzins rentrent dans une porte des étoiles quand même... (on va dire une porte de 200/300m de diamètre, fo que les super-destroyers passent dedans sans rayer la peinture)
enfin y'a du boulot encore là, c'est au stade maquette en carton hein quand même...
 
6) et 7) tout est dans le SDK, que tu installes normallement, pour le plug-in VS6, je sais pu si je l'ai pompé sur le site de discreet...

merci, j'vais rendre visite à Monsieur Discret.
 
Quelle patience tout de même... j'vais redemander.... l'offset, c'est pour int => DWORD. comme j'utilise pas trop (jamais) le double mot, j'demande (oui, j'ai la relou attitude ).
 
Sinon ton projet à l'air très alléchant. Et ton exporter assez complexe/complet ma foi. J'vais essayer de plagier lamentablement certains points et d'en faire ma tembouille.

nan en fait l'offset c'est plus subtile.
 
(je suis de retour du ciné, Van Helsing c'est sympa, mais c'est moins marrant que la momie quand même)
 
en fait donc, comme je t'ai dit pour pourvoir utiliser le cache Post-T&L, il te faut un tableau d'index. (un IndexBuffer dans la terminologie DirectX, en OpenGl je sais pas c'est qu'il ce manquait dans le lien de Nehe).
(et si le modèle possède plusieures centaines de milliers de vertexs, le gars qui fait ça connait pas l'éclairage par pixel, je parle pour un modèle de perso/véhicule/décors, pour une scène entière oui)
 
donc comme, dans une certaine mesure, un modèle 3D lowpoly pour du rendu temps réel a -rarement- plus de 60000 vertex, en Direct3D, tes indexes peuvent être soit sur 16 bits soit sur 32 bits (65K vs 4Milliards+, mais bon ça tu dois le savoir).
 
donc généralement pour réduire la taille mémoire de l'IndexBuffer et la bande-passante mémoire consommée, tout le monde utilise des IndexBuffers 16bits.
 
l'Offset, lui est-là pour donner le décalage dans le VertexBuffer (qui contiens les vertexs, ie position+normale+uv+....+....).
 
en Direct3D, toutes les commandes de traçages se font avec un DrawIndexedPrimitive(), et tu passes l'offset.
 
donc par exemple, au niveau de 3DS Max, il arrive quelques fois que "l'ensemble" du modèle fasse plus de 65K vertexs, mais comme, quand tu exportes, tu exportes Node par Node, il est facilement faisable de détecter quand est-ce que tu dois spécifier un nouvel Offset.
 
en gros dans le moteur d'export...
 
mettons un truc comme ça:
Node 1: 30000 vertexs
Node 2: 10000 vertexs
Node 3: 30000 vertexs...
 
en traitant la Node 3, j'ai tout les vertexs de la Node en temporaire, je connais le nombre exact de vertexs effectifs (par vertexbuffer), ie les vertexs inutilisés sont éliminés, les dupliqués sont pris en compte....
donc en voyant que 40000+30000 ça dépasse les 16bits, pouf je fixe le nouveau Offset courant à 40000.
 
donc en gros, au niveau de l'IndexBuffer le premier vertex de la Node 1, c'est l'indice 0, le premier vertex de la Node 2 c'est l'indice 30000 (le 30001ième vertex), et pouf, pour la Node 3, l'Offset passe de 0 à 40000, et dans l'IndexBuffer le premier indice de cette Node c'est le 0.  
 
le hardware faisant la somme Offset+WORD de l'IndexBuffer pour fetcher et transformer le vertex.

merci de la précision. Je t'avoue que j'avais jamais pris garde au nombre de bits de l'index buffer. Je sais même pas sur combien je suis en OGL (je sais par exemple que mon z buffer est lui sur 16bits mais c'est bien tout, à regarder donc).
 
Donc quand un node passe 65535 verex à lui tout seul, c'est un indicage avec un buffer de 32bits obligatoire ou je dis n'imp".
 
Sinon Van Helsing, po vu. J'ai tellement de truc à rattraper pour le coding que je crois que ça va se finir aux oubliettes (dois y'avoir des effets spéciaux pas mal quand même, avec quelques milliards de vertices à faire broyer par leur stations de rendu).
 
Et pis quel internaute de folie ce bjone, 2h du mat' et il poste encore ! ça c'est la classe. merci.
 
Là j'ai pas foutu grand chose aujourd'hui donc pas de question encore... ça pourrait venir (le retour du relou).

exact quand la node développe plus de 65535 vertex c'est le mur, mais j'ai jamais rencontré sur tous les objets que j'ai pompé de-ci de-là, et ça se compense en éclatant le modèle ou sous-éléments.
 
attention l'IndexBuffer ne se nomme peut être pas de la même manière en OpenGl, ce serait plustôt un Array quelque chose... (ce n'est pas lié au backbuffer/zbuffer)

sinon, rien a voir avec le topic, mais tu load quoi comme type de fichier pour les textures transparentes ? A la main ou avec une lib en particulier ?
 
sinon pour le z buffer en 16 bits, c'était juste une comparaison douteuse.
 
Et tu as déjà essayé de comparer les perf" avec un index buffer de 32 et 16 bits ? si oui, ça se ressent vraiment pour une scène de on va dire 100 000 ~  150 000 polygones.

à partir du moment où le flux d'indices est optimisé pour le cache Post-T&L, je pense que ça doit pas dégrader énormément les perfs géométriques, et généralement, on est plus limité par la vitesse de remplissage que la géométrie donc ça un truc "final", ça peut se masquer je pense....
 
mais j'ai pas essayé de bencher les deux...
 
sinon pour l'instant, je passe par le loader du D3DX (l'équivalent du Glut pour le Direct3D), et ça me conviens largement...

oki, merci. Moi je voulais tenter FreeImage mais j'ai quelques problème avec les png (même les tga).
 
bonne journée.