Is there a limit of vertices in WebGL?

Question

Three.js says that it can't load more than 65k vertices.

In my pure webgl application, it doesn't say anything, but it doesn't show the entire object when I try big objects.

I could split my objects into smaller buffers, but it would make me sad.

Is there any better solution? Is 65k really the limit amount of vertices?

Answer 1

Yes, WebGL's vertex index buffers are limited to 16-bit right now. This is because they're aiming to make version 1.0 as cross-platform as possible, so there's a tendency to make stuff target the lowest common denominator -- in cases like this, mobile platforms with limited graphics hardware.

Once 1.0 is out and the initial rush is over, they're likely to loosen these constraints with the help of extensions -- an app will be able to ask whether a given extension is supported by the implementation, and make use of it if it is -- just like in regular desktop OpenGL. There are already a few extensions available, but again they've only allowed ones with very broad hardware support, so nothing that would help you increase your vertex count. However, once they loosen the cross-platform requirement, they are likely to support something like the GL_OES_element_index_uint extension that allows 32-bit vertex indices.

You can read some discussion of these issues on the Public WebGL mailing list.

Answer 2

Generally the other answers are correct, but I figured I would add a bit of clarification:

The only data types accepted by WebGL (and OpenGL ES 2.0) for indices are unsigned bytes and unsigned shorts. Since an unsigned short has a range of 0-65535, this means that if you are using gl.DrawElements (which most frameworks do) you can only reference 65k vertices per draw call. This is almost certainly where the three.js restriction comes from. Please note that you can have a lot more than 65k triangles in one draw call, as long as they only share 65k verts.

If you use non-indexed geometry (gl.DrawArrays), you can have a lot more vertices per-call, but bear in mind that almost always have to repeat some of them. I think in most cases the reduction in GPU memory usage will justify splitting up the draw calls.