What's the best way to organize mesh structure - for speed

@jwatte:
yes, your approach looks very nice designed; but i think it’s a little bit to complicated. i use a different approach:
i have a “mappinglevel” for a mesh, this mappinglevels knows everything about rendering the mesh it belongs to with the optical desires, this means whether or not uv/color/normal; the mappinglevel is created by the developer with a function in the mesh, to pass the correct amount of vertices to the mappinglevel - i use indexed arrays (with glDrawElements). if you wnat to use colors, tell it to the mesh/mappinglevel (both provides mechanism to add this afterwards); then the array will be created, you can obtain a pointer and fill it - a flag indicates if colors/normals/uv’s are used: so i have only to disable/enable the desired glPointer…(). i have a “linear” pointer to all vertexattribs, meaning a seperate array for each attribtype - and if you now decide to use multitexture, just tell it again to the mappinglevel, then the array’s size will be increased, by (numberofverts*2)numofaddedlevels; this will result in a array one/two/tree/… times as big as the vertexarray itself. now i do glTexCoordPointer(…, pUVCoords + (indexofmappinglevelnumberofvertices) ) to get the correct entry into the list.
this solutions results in a less complex construction; you don’t have to write your templates, it’s clear/transparent and yo don’t have to bother with all your funny strides values…

ADD-ON: and of course, the mappinglevel knows of it’s used textures/shaders and such stuff.

[This message has been edited by DJSnow (edited 11-07-2003).]

If that works well for you, then by all means keep doing it. I was just describing how we do it (actually, a simplified version, but isn’t that always the case :slight_smile:

Regarding linear (separate) arrays, that’s very nice from a geometry management point of view, and in fact our on-disk geometry formats work like that, but there’s lots of hardware that works much faster with interleaved arrays.

If you’re working alone, or in a very small team, the trick is to do only what needs to be done, and know when what you have is “good enough”. You can always go back and improve it later. After all, for most “fancy” or “future-proof” code, YAGNI. (You Aint Gonna Need It)