# Caps.MaxVertexIndex Question

This topic is 4977 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Okay on my PC MaxVertexIndex = 65534. Now MSDN gives one sentence explaining this, and its not enough for me. I have a minor confusion. Lets say I have a VERTEX BUFFER is sized to require 131068 (65534*2) INDICES. Can I set up two index buffers and render the first batch of triangles 0-65534 with the first index buffer. Then render the second batch of triangles 65535-131068. Or will this max force me to split my vertex buffers up?

##### Share on other sites
I can see how this is confusing. Natively, index buffers have 16-bit precision. Remember, the 16-bit (4-byte) datatype is short or WORD, and the maximum number that can be stored is 65,543. This means that the index buffer can reference up to 65,543 vertices. Hence, you can have more indices (more triangles), but not more vertices.

D3D offers 32-bit precision for buffers. The 32-bit (8-byte) datatype is int or DWORD, and the maximum number that can be stored is 2,147,483,647.

Now, for some clarification on your situation: do you have 131,068 vertices, or do you have 131,068 elements in your index buffer? If you have 131,068 vertices, you have to split them up. If you have 131,068 elements in your index buffer, you are perfectly alright.

##### Share on other sites
Hmmm, this is still rather confusing.

Does this mean that index buffers only have a max as in which they can reference?
Not how many elements they have? Much like vertex buffes, index buffer have no max size allocated. They just have a max reference because of how the value's are stored. 0xFFFF = 65535 = max 16 bit value.

I have (256+1) * (256+1) = 66049 vertices in my vertex buffer
I have (256) * (256) * 6 = 393216 indices in my index buffer

Does this means I have to split up my index buffer?
Or can I go with 32-bit indices? is that much slow?

##### Share on other sites
Much of this is just from memory, so I'm not guaranteeing all of it is 100% accurate, but....

Many cards don't support 32 bit indices. GeForce3, and GeForce4, only support 16 bit indices. GeForceFX cards support 32, but do incur a performance hit. Geforce 6x00 cards likely do 32-bit with no problems. I think Radeons supported 32 bit indices earlier, but likely have a performance hit too.

I'd suggest breaking the vertex buffer into a few sections. I'm assuming it's for a heightmap. Perhaps break it into 129x129 sections (with a row of overlapping vertices in the middle). This will work on all cards, likely corresponds to a top level of a quad tree, and results in only a few DIP calls. Other techniques involve splitting to lower quadtree nodes, which can be of benefit when software vertex processing is used (software mode processes all vertices from lowest needed index to highest, so isolating vertices into nice little chunks works best for it), but may require more draw calls.

A trick that works on many cards is that if the max vertex > 65536, but maxindex does not, you can render the lower indices in one draw call, and the higher indices with another draw call and using the "basevertexindex" to offset the indices to mean later vertices. This won't work on some older cards.

So, how you even begin to think of approaching the issue, you need to know your target specs.

32-bit indices (very new cards only)
4 chunks in 1 VB (hardware processing cards only)
many chunks in 1 VB (software processing cards with maxvertex > 65536)
many chunks in several VBs (remaining cards)

There may be other configurations that make sense too. Your main goal should be to choose an appropriate technique for the low-end systems. Better cards will handle the same data, just better. You don't need to implement a 32-bit system if you've already got a perfectly good 16-bit system running. If you have time to kill, you can feel free to implement multiple techniques such that the newer hardware also uses newer/better tech, but the newer cards should be able to run the older stuff with ease anyway, and your time is probably better spent elsewhere.

##### Share on other sites
Halsafar,

As someone touched upon earlier an Index Buffer is an array of indices....the MaxVertexIndex constant does not tell you how many values can be put into the array, but rather the largest value of any element within the array.

Your MaxVertexIndex is 65,534. That means that is the largest vertex index that can be stored in any element of the index buffer.

To sum up, it is not possible for you to render from a vertex buffer of 66049 elements. Your card doesnt support it. You need to split the vertex buffer.

The important thing to remember is that your Vertex Buffer is too large, not your index buffer.

##### Share on other sites
Well its to bad I have to add some extra stuff to manage extra vbuffers on extra machines. Easy to impliment but I mean I am running around on a huge terrain and getting 2.9ms/frame. The culling and all that have made it almost perfect and in fact the only time this indice buffer problem occurs is when the player goes up high thus revealing the largest number of triangles/indices.

I am going to write the terrain in a way that it can be usable on low-end cards and somewhat optimized on high-end cards.

[Edited by - Halsafar on June 7, 2005 12:38:18 AM]

##### Share on other sites
Quote:
 Original post by circlesoftI can see how this is confusing. Natively, index buffers have 16-bit precision. Remember, the 16-bit (4-byte) datatype is short or WORD, and the maximum number that can be stored is 65,543. This means that the index buffer can reference up to 65,543 vertices. Hence, you can have more indices (more triangles), but not more vertices.D3D offers 32-bit precision for buffers. The 32-bit (8-byte) datatype is int or DWORD, and the maximum number that can be stored is 2,147,483,647.Now, for some clarification on your situation: do you have 131,068 vertices, or do you have 131,068 elements in your index buffer? If you have 131,068 vertices, you have to split them up. If you have 131,068 elements in your index buffer, you are perfectly alright.

Since when was 16-bit == 4 bytes and 32-bit == 8 bytes?
Since when was 2^16 == 65,543 and not 65,536?
[grin]

Additionally, I believe that MaxVertexIndex only indicates whether you have 32-bit index buffer support or not. I think I've read sometime back that you can still index vertices at indices greater than 65,543 by using BaseVertexIndex when calling DrawIndexedPrimitive. For example with "BaseVertexIndex = 65536", you could access the higher part. Not sure though, but it's worth a try.

EDIT: I see ntnet has already said this, so if it'd work for you, go ahead and use it [smile]

##### Share on other sites
Another option that's really simple is to just make your map 2 vertices narrower on all sides...

##### Share on other sites
Quote:
 Original post by CoderSince when was 16-bit == 4 bytes and 32-bit == 8 bytes?Since when was 2^16 == 65,543 and not 65,536?[grin]

Woops [lol]

Apparently, I have lost all capacity to multiple and divide. Sitting out in the sun all day for graduation practice hath friedeth meh braineth.

##### Share on other sites
Doesn't this field also indicate if you can use all of a 32bit address space?

That is, D3DFMT_INDEX16 in theory supports 0 to 65535 and D3DFMT_INDEX32 in theory supports 0 to 4294967295 values. However, through that capability bit it might well expose 16777215 - 224.

Then again, I too have spent the vast majority of my day "in the office" lying in the sun on the lawn at work and am a bit frazzled. [oh]

Jack

• ### What is your GameDev Story?

In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

• 15
• 9
• 11
• 9
• 9
• ### Forum Statistics

• Total Topics
634134
• Total Posts
3015749
×