discusses intermediate solutions to this problem by presenting C++ classes that ease
the transition to postdeprecation OpenGL. These C++ classes are
1. Create vertex buffers with methods that look suspiciously like glBegin-
2. Load, compile, link, and use shaders.
This chapter also suggests a naming convention that can be instrumental in keep-
ing shader variables untangled from each other.
2.2 Naming Shader Variables: Introduction
This isn’t exactly a transition issue. It’s more of a confusion-prevention issue.
With seven different places that GLSL variables can be set, it is convenient to
adopt a naming convention to help recognize what variables came from what sources.
This works ver y well, as shown in Table 2.1.
Beginning letter(s) Means that the Variable
a Is a per-vertex attribute from the application
u Is a uniform variable from the application
v Came from a vertex shader
tc Came from a tessellation control shader
te Came from a tessellation evaluation shader
g Came from a geometry shader
f Came from a fragment shader
Tabl e 2.1. Variable name preﬁx convention.
2.3 Naming Shader Variables: D etails
Va riables like gl Vertex and gl ModelViewMatrix have been built-in to the
GLSL language from the start. They are used like this:
vec4 ModelCoords = gl_Vertex;
vec4 EyeCoords = gl_ModelViewMatrix * gl_Vertex;
vec4 ClipCoords = gl_ModelViewProjectionMatrix * gl_Vertex;
vec3 TransfNorm = gl_NormalMatrix * gl_Normal;
However, starting with OpenGL 3.0, they have been deprecated in favor of u ser-
deﬁned variables that we pass in from the application. The built-ins still work if
compatibility mode is enabled, but we should all be prepared for them to go away
some day. Also, OpenGL ES has already completely eliminated the built-ins.