It does mean that you'll be doing one draw call for each patch, but it shouldn't be too bad unless you're drawing hundreds of patches.ДЄre you updating the vertices, indices or both each frame? I'd suggest drawing the terrain in stages. The 32-bit IB method will mean slightly more data to transfer (But to be honest it's unlikely to be that big a deal), and just deffers the problem - you still need to handle cases where the card only supports something like 0x0001ffff indices (I.e. You can either move to a 32-bit IB, or you can draw in stages. Looking forward for your response, thanks a lot for the useful information!Yes, a 16-bit index buffer is unsigned, which means 65536 possible vertex indices. It can probably work correctly if I calculate the number of indices in the vector, put it into a loop and calculate the offset for stages instead of each primitive alone and also take a bit back when locking the vertices.Д«ut it probably will not work either as the offset means 'vertex 6 is now vertices 1 in case of an offset of 5 and therefore all the indices values are incorrect'

Or I simply cannot access the correct vertices. I have tried drawing in stages before but as I did it, I simply tried to draw them one by one which means I either lock too many vertices which means, slow performance. The index buffer is set as WORD so it is unsigned, so I take it there is a limit on how many indices I can send to be drawn?

Too many indices for index buffer