Open ianromanick opened 3 years ago
There's probably a similar issue on many implementations for GL_LINE_STRIP
and the line stipple pattern.
Also consider this:
for (...) {
glBegin(GL_LINES);
glVertex3f(...);
glVertex3f(...);
glEnd();
}
We can't have correct gl_VertexID
and gl_PrimitiveID
even without display lists if we want drivers to process that loop and generate 1 big draw where those variables don't reset to zero. (that's for performance; separate draws would be abysmally slow)
I think we can support gl_VertexID
and gl_PrimitiveID
with immediate mode glBegin/End
if we disable draw merging when those variables are being used.
When an application uses immediate-mode drawing commands, the OpenGL implementation must buffer vertices submitted. The OpenGL specification does not place limits on the number of vertices that may be submitted between
glBegin
andglEnd
, but the buffers used to store that data will have finite size. When the buffer becomes full, the implementation may need to split the primitive. On some implementations, this buffer may be relatively "small" only allowing a thousand or so vertices per batch.Splitting the primitive will cause
gl_VertexID
andgl_PrimitiveID
to have observably incorrect values, but the specification does not strictly allow this. The alternative, which is allowed by the specification, is to generateGL_OUT_OF_MEMORY
. That seems... rude.Instead, we propose two alternatives:
gl_VertexID
andgl_PrimitiveID
(andgl_PrimitiveIDIn
for geometry shaders) undefined with immediate-mode drawing.gl_VertexID
andgl_PrimitiveID
may reset to zero."This first is cleaner, but it is more broad than necessary. The second introduces (effectively untestable) implementation-dependent behavior.