Stockage succinct de données de modèle atomique pour le programme OpenGL

Question

Je veux être en mesure de stocker un modèle atomique dans un programme OpenGL que j'écris. Rien d'extraordinaire; juste des valeurs de vertex de maillage constant stockées sous GLfloat[3], plus des textures simples. Je veux aussi que le modèle puisse bouger et tourner librement et comme un seul objet. Voici ce que j'ai jusqu'à présent:

typedef struct _coordnode { 
GLfloat *pts;   /* XYZ (vertex) or XY (texture) */ 
struct _coordnode *next; 
} coordnode; 

typedef struct _facenode { 
GLfloat *norm;   /* XYZ */ 
coordnode *vertices;  /* head of linked list */ 
GLfloat *color;   /* RGBA */ 
coordnode *textures;  /* head of linked list */ 
struct _facenode *next; 
} facenode; 

typedef struct _model { 
GLenum  mode; 
facenode *faces;   /* head of linked list */ 
GLfloat *rot;   /* delta-XYZ from Theta-origin */ 
GLfloat *rot_delta;  /* delta-delta-XYZ */ 
GLfloat *trans;   /* delta-XYZ from origin */ 
GLfloat *trans_delta; /* delta-delta-XYZ from origin */ 
} model; 

Cela se met en place de telle sorte que le modèle a une listes chaînées de facenode, dont chacune a deux listes chaînées de ses sommets et ses coordonnées de texture, respectivement.

Puisqu'il s'agit de mon premier programme C, ma question aux programmeurs expérimentés est de savoir si cette méthode particulière présente des incohérences ou des inefficacités, ou si elle stocke suffisamment de données.

Plus d'informations, pas nécessairement pertinente:

• Il n'y aura que quelques objets en mémoire, et deux d'entre eux seront impliqués dans la détection de collision.
• Un modèle aura une transparence partielle.
• Un modèle aura augmenté le texte rendu appliqué aux faces du modèle et se déplacera selon un vecteur de gravité.
• Deux modèles tourneront en même temps, en fonction de l'entrée externe.

Answer 1

En supposant que vous êtes sur une architecture 32 bits, et GLgloat est typedef à un 32 bit float cette structure

typedef struct _coordnode { 
GLfloat *pts;   /* XYZ (vertex) or XY (texture) */ 
struct _coordnode *next; 
} coordnode; 

va consommer 8 octets de mémoire. Ensuite, si je comprends bien, pts pointera vers une allocation séparée qui aura soit 2 ou 3 GlFloats, soit 8 ou 12 octets de mémoire. c'est 16 ou 20 octets dans deux allocations. alors que ceci

typedef struct _coordnode { 
GLfloat pts[3];   /* XYZ (vertex) or XY (texture) */ 
struct _coordnode *next; 
} coordnode; 

Est toujours 16 octets, plus un point de défaillance en moins puisqu'il s'agit d'une allocation unique plutôt que deux. Donc, même si votre allocateur n'a aucun surcoût (et ce n'est pas le cas). Mettre 3 GLfloats dans le coordnode (même si vous n'utilisez que 2 d'entre eux) est moins de mémoire que d'avoir le tableau GLfloat être une allocation séparée. De plus, si vous optez pour une allocation unique, vous obtiendrez une meilleure cohérence de la mémoire cache, ce qui se traduira par de meilleures performances la plupart du temps.

La même analyse peut être effectuée sur vos autres structures.

L'autre chose que je dirais est que si vous mettez toujours le pointeur next premier dans chacune de vos structures, puis un ensemble de fonctions de liste chaînée peut gérer toutes vos listes, si l'OMI ce qui est mieux

typedef struct _coordnode { 
struct _coordnode *next; 
GLfloat pts[3];   /* XYZ (vertex) or XY (texture) */ 
} coordnode; 

Si vous changez un jour en double pour GLFloat ou que vous passez à une architecture 64 bits, vos pointeurs n'auront plus la même taille que vos GLFloats. Dans ce cas, il serait préférable d'utiliser la mémoire pour regrouper les flottants et les pointeurs.

typedef struct _facenode { 
struct _facenode *next; 
coordnode *vertices;  /* head of linked list */ 
coordnode *textures;  /* head of linked list */ 
GLfloat *norm;   // XYZ (it might be better to make this an array) 
GLfloat *color;   // RGBA (it might be better to make this an array) 
} facenode;