My setup is a little complicted, but here's a metaphore that describes what's going on: I'm doing a terrain mesh with a level of detail back end (somewhat ROAM based, if anyone is curious). The textures I'm using are the basis for the LOD (not the geometry), then each texture has underlying static geometry. I'll have about 16 texture tiles on the screen, and each texture tile is broken up into a 256x256 grid. I subdivide that grid into 128 different 1024-triangle meshes (all meshes are just a regular grid). I want my base mesh size to be 1024 triangles as it gives a good granularity for frustum culling. My question is this. If I have (16 tiles * 128) meshes, what is the best way to store/display these? I need to be able to dynamically cull each mesh each frame. Here are some options I've considered: 1) 2048 VBO objects - binding each would KILL me in driver overhead 2) 1 large vertex object, with 1 small index object (connectivity for a single mesh), then change to offset into the vertex object using glVertexPointer to select each mesh's data - nVidia suggests using glVertexPointer only once per VBO as there is a bit of bookkeeping that goes on (how bad would this affect my performance)? 3) 1 large VBO object, with 1 large index object containing duplicate connectivity for each mesh, then select the offset into the index object for each mesh - extra data storage for the mesh connectivity (note: I would probably actually use 1 VBO for each tile, instead of for the entire scene, but I wanted to simplify the above descriptions) It seems that 3 might have the least object switching overhead, but I'd like to avoid the memory overhead of having to duplicate the same mesh topology for each object. Does anyone have insight into this problem or is this something I need to just write up and test (and would anyone be interested in the results?). Thanks for your help (and to those who have been replying to my other recent inquiries).