Maximum size for index buffer and how to go around it


I have tried to render large geometries (>= 1,016,742 indexes) in WebGL and I noticed that after a certain number of indexes the geometry is not fully rendered and instead everything above that number looks wrong.

I did the experiment of dividing the index array in blocks of 65001 elements and calling drawElements on each block. After the 5 blocks the geometry does not make sense. Even when I am using a new array for each block!
I double checked the geometry on a stand-alone 3D graphics program and it’s ok.

I am using a WebGLUnsignedShortArray to pass along the bufferData with the indices.

  1. Can I use a different type of array to be able to render > 1M indices successfully?

  2. What alternatives do I have to render large geometries? Even when I divided my index array in several blocks, after the 5th block, I don’t get the correct rendering.

Thanks for the feedback.


I have the same problem.
You have to adjust the index of block 2…n. UnsignedShort means 65.536 is the biggest index. If you want to call the vertex number 70.000. WebGL can only save the 5xx above 65.536.

So you have to make vertex,textur,normal Blocks with 0…65k indices.

Made it sense to you? :smiley: you can draw 80k triangles, if they use only 65k points.

greets titan

PS Me have 2 other problems :smiley:

So that implies that index 65.537 becomes index 0 and so forth for everything that is above right? So that’s an easy transformation for the next block of indices but there’s a problem with that if you have triangles that share indices between blocks.

For instance, say that you have a triangle with indices (65,537 - 65,500 - 65,538) After converting the indices the triangle looks like (0, -missing-, 1). In this case, one of the indexes belong to a previous block. So the alternative here would be to repeat this index in the new block and put it at the end so you don’t have to shift all the indexes when these cases arise. Given that you don’t know how many cases you are going to have, and assuming you can have at least one of these cases per triangle (semi worst case scenario) you would have to allocate at least half of the second block for these cases, leaving only a half for useful indices. There should be a better solution though.

It makes sense, I am just thinking about the stitching strategy.

The inefficient way, travel throw the points and collect many “same triangle”-points. This would kill JavaScript :> Only some points had to copy to the next block. (It looks like N^(N-1) or so :shock: )

By the way the 65536 one is known as 0. (0-65535 indices = 65536 points :slight_smile: )

I have to travel throw the vertices and normals and so on, because the fileformat uses different indices for every “piece”. And drawElements allow only one indices per vertex… But okay, it make it easier for OpenGL ES.

greets titan