Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

gl_VertexID in non-indexed rendering

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..

like image 505
user815129 Avatar asked Feb 21 '19 12:02

user815129


People also ask

What is gl_VertexID?

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.

What is gl_VertexIndex?

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.

What type of vertex shader variable has the same value for each vertex?

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.


1 Answers

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 as gl_VertexID. The vertex 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 as gl_VertexID. The vertex 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…

like image 155
Michael Kenzel Avatar answered Oct 24 '22 04:10

Michael Kenzel