flipcode - Texture Switching, Part 2

Texture Switching, Part 2
Question submitted by (12 January 2000)


	I'm having trouble making up my mind deciding the kind of data structure to use for my textured 3D objects. It would seem that textures should be sorted, but sorting them for each frame would cause too much overhead. Thinking of a solution I came up with the following items to be considered: when initially loading the 3D objects, put all the objects' polygon structures ( pointers to vertices, UV coords, texture+ lightmap object pointers, something else? ) in a single list. have a flag in the polygon structure, indicating whether or not this polygon needs to be rendered this frame. Note that this flag must be resetted each frame. This introduces some overhead, but hopefully not too much. With clever data alignment this should be fairly easy to optimize. have a flag in the 3D object structure. Do all the visibility calculations on object level, have pointers to the polygon list and set the polygons' flags according to the result of the object visibility test. So, this would result in a sort of scene data structure where polygons, textures and lightmaps belong to the scene, not the 3D objects. The 3D objects just store pointers to polygon structures, which in turn store pointers to the vertex structures that belong to the object structure. Seems awkward, but it's the most efficient way I can think of. Am I leaving something out? AFAIK just add camera and light classes to this and you should have a nice infrastructure for 3D apps.


	Your Object->Polygon->VertexData structure layout (with the vertex list being part of the object) is pretty common, so you're on the right track there. In your first bulleted point, you say to put all polygons in a single list. Is this so you can simply run through them later and reset that RenderMe flag? If so, I've got a better idea (actually, it's an old idea, I'll just regurgitate it for you like a good little mama bird. :) Rather than storing a flag with your polygon data, store an unsigned integer. At the start of each rendered frame, increment a "frame counter" variable that keeps track of the current frame. When you decide that a polygon needs to be rendered, simply copy that frame number into the polygon's structure. When it comes time to render the polygons, only render those polygons whose frame counter matches the current frame counter. Eventually this value will wrap around, but it'll take a little more than 2 years (at 60fps). However, I wouldn't recommend doing anything of the sort. You're better off simply storing a list of visible polygons, and as polygons are deemed visible, throw them into this list. This list, by the way, is typically referred to as a "render list". This way, you don't have to visit every polygon in the world (again) when it comes time to render, rather you visit just the visible polygons. Response provided by Paul Nettle

This article was originally an entry in flipCode's Fountain of Knowledge, an open Question and Answer column that no longer exists.