A1) Sorry, I was unclear. If the cube is to be a literal cube then I would simply elevate it and use shape zero:
Shape Zero - All corners same height
Shapes One and Two - Opposite corners elevated (two corners elevated)
Shape Three - Billboard sprite?
Shapes Four thru Seven - A single corner raised
Shapes Eight thru Eleven - Two adjacent corners raised
Shapes Twelve through fifteen - Three corners raised
A2) It would defeat the purpose of the design. Every texture set is a possibility for re-uploading. If any re-upload occurs it means that there's going to be constant re-uploading, since it means that an upload is moving something else out of the way that will need put back next frame, etc.
As for whether or not I'm having performance problems - no. This isn't even implemented yet. I'm trying to figure out how to do it first. While it would indeed indicate a serious problem if a couple cubes and quads were lagging, I'm looking at establishing a base for scalability and also I'm considering building a system like this on a device-native SDK for a device that only has around 2MB of vram. (Now that I'm thinking about it I could do this so much more easily on that device's SDK that it's not even funny.)
As for using the product of the index buffers, that wouldn't work, since the index in the buffer must refer to a vertex in the vbuffer. Using the product of the vbuffers would cause exponential scalability.
Edited by Khatharr, 08 August 2012 - 12:21 PM.