Succinctly storing atomic model data for OpenGL program

Question

I want to be able to store an atomic model in an OpenGL program I'm writing. Nothing fancy; just constant mesh vertex values stored as GLfloat[3], plus simple textures. I also want the model to be able to move and rotate freely and as a single object. Here's what I have so far:

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;

This sets itself up in such a way that the model has a linked lists of facenode, each of which has two linked lists of its vertexes and its texture coordinates, respectively.

Since this is my first C program, my question to seasoned programmers is whether this particular method presents any inconsistencies or inefficiencies, or whether it stores enough data.

More information, not necessarily relevant:

• There will only be a few objects in memory, and a two of them will be involved in collision detection.
• One model will have a partial transparency.
• One model will have raised rendered text applied to the model's faces, and move according to a gravity vector.
• Two models will rotate as one, based on external input.

Answer 1

Assuming that you are on a 32 bit architecture, and GLgloat is typedef'd to a 32 bit float this structure

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

is going to consume 8 bytes of memory. Then, if I understand this correctly, pts will point to a separate allocation that will have either 2 or 3 GlFloats, which is 8 or 12 bytes of memory. that's 16 or 20 bytes in two allocations. while this

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

Is always 16 bytes, plus one less point of failure since it's a single allocation rather than two.

So, even if your allocator has zero overhead (and it doesn't). Putting 3 GLfloats in the coordnode (even if you only use 2 of them) is less memory than having the GLfloat array be a separate allocaton. Plus, if you make this a single allocation then you get better cache coherency, which translates into better performance most of the time.

The same analysis can be performed on your other structures.

The other thing I would say is that if you always put the next pointer first in each of your structures, then a single set of linked list functions can handle all of your lists, so IMO this is better

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

If you someday change to doubles for GLFloat or move to a 64 bit architecture, then your pointers will no longer be the same size as your GLFloats. In that case, it would be better use of memory to group the floats and pointers together.

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;