The OpenGL gl_VertexID page clearly states:
gl_VertexID is a vertex language input variable that holds an integer index for the vertex
while the OpenGL Vertex Shader page says it is
the index of the vertex currently being processed. When using non-indexed rendering, it is the effective index of the current vertex (the number of vertices processed + the first value).
May I assume 100% that in non-indexed rendering commands gl_VertexID is the int vertex index in the bound vertex buffer? or is it rather the index of the vertex as being processed by the rendering command (which may or may be not follow the order in the vertex buffer)
The doubt comes form the description part inside (), as for the number of processed vertices to be equal to the index of the current vertex in the vertex buffer, the vertices must be processed linearly. May I assume it will always be the case? Or maybe there are OpenGL implementations that process vertices backwards, or in buckets, etc..
gl_VertexID is a vertex language input variable that holds an integer index for the vertex. while the OpenGL Vertex Shader page says it is. the index of the vertex currently being processed.
The built-in gl_VertexIndex variable contains the index of the current vertex. This is usually an index into the vertex buffer, but in our case it will be an index into a hardcoded array of vertex data.
There are three types of variables in shaders: uniforms, attributes, and varyings: Uniforms are variables that have the same value for all vertices - lighting, fog, and shadow maps are examples of data that would be stored in uniforms. Uniforms can be accessed by both the vertex shader and the fragment shader.
tl;dr: yes, gl_VertexID
is always going to be the logical index of the respective vertex in the sequence of primitives specified by your draw call (effectively the index from where in a vertex buffer the vertex data would be read). It does not depend on the way or order in which vertices are actually processed (if it did, that would make it a rather useless feature since it would provide no reliable behavior whatsoever).
From the OpenGL 4.6 specification (11.1.3.9 Shader Inputs):
gl_VertexID
holds the integer index i implicitly passed by DrawArrays or one of the other drawing commands defined in section 10.4.
and from 10.4:
The index of any element transferred to the GL by DrawArraysOneInstance is referred to as its
vertex ID
, and may be read by a vertex shader asgl_VertexID
. Thevertex ID
of the ith element transferred is first + i.
and
The index of any element transferred to the GL by DrawElementsOneInstance is referred to as its
vertex ID
, and may be read by a vertex shader asgl_VertexID
. Thevertex ID
of the ith element transferred is the sum of basevertex and the value stored in the currently bound element array buffer at offset indices + i.
Now, the behavior of all the non-indexed draw calls is specified in terms of the abstract DrawArraysOneInstance
command. And the behavior of all the indexed draw calls is specified in terms of the abstract DrawElementsOneInstance
command. Without going into any more detail (you can go dig around in section 10.4. if you want to find out more), all the above basically means that if you draw with an index buffer, then gl_VertexID
is going to be the index of the vertex as specified by the index buffer and if you draw without an index buffer, then gl_VertexID
is going to be the index of the vertex as given by your primitive sequence…
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With