Is it only possible to display 64k vertices on the monitor with 16bit?

Question

I did the first 3D tutorial over at riemers.net and stumbled upon that my graphic card only supports Shader 2.0 (Reach profile in XNA) which means I can only use Int16 to store the indices (triangle to vertex).

This means that I can only store 2^16 = 65536 vertices. Also I read on the internet that you should prefer 16-bit over 32-bit because not all hardware (like mine) does support 32-bit.

Yet, I am wondering: Do really all game scenes get along with only so little vertices? I though already faces of people used a lot of polygons (which are made up of vertices?).

It’s not relevant for me yet, but I am interested:

• Do game scenes use only 65536 vertices?
• Do you use some trade-off to display more (e.g. 64k in GPU buffer rest on RAM)
• Is there some method to get more into the GPU buffer? I already read on some other posts that there seems to be a limit of 64k per mesh too, so maybe you can compact stuff to meshes?

Answer 1

This means that I can only store 2^16 = 65536 vertices.

No it doesn't. It means that you can only use 16-bit indices (assuming it even means that, as I'm fairly sure D3D9 allows 32-bit indices. That's what the INDEX32 index buffer format means, right?). Which means that a single draw call can only access a 16-bit range of indices. But you are not limited to a single draw call for the entire scene. That's one reason why DrawIndexedPrimitive has the BaseVertexIndex parameter, which allows you to bias the index for a rendering command by a fixed offset.

You don't have to draw everything in one draw call. So even if you were limited to 16-bit indicies (which again, you are not), you could still make several draw calls to render what you needed.

Answer 2

First of all, 32-bit index support is ubiquitous on modern hardware, and has been for quite some time. If you only support 16-bit then you're long overdue an upgrade.

OK, so once upon a time there was a class of hardware that only supported 16-bit. This wasn't a problem back then because there are other options available. One of them would have involved splitting a mesh into multiple vertex/index buffers. So, if the mesh has more than 64k you can't pack it all into a single set of buffers - easy solution - just use two. Draw half the mesh from one set of buffers, the other half from the other set.

Going further back in time we arrive at software T&L (where hardware restrictions in the per-vertex pipeline were irrelevant), not using index buffers at all (a mesh would just be in a vertex buffer and be composed of multiple long triangle strips each of which gets it's own draw call), not even using vertex buffers (vertices come from system memory instead) or (getting really ancient now) the likes of OpenGL's old immediate mode.

Should 16-bit be preferred even in cases where 32-bit are available? Maybe, maybe not. This is a tradeoff, and the work involved in splitting a mesh may cancel out the gains obtained in using a smaller index type.