O'Reilly logo

OpenGL Insights by Christophe Riccio, Patrick Cozzi

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Transitioning Students to
Post-Deprecation OpenGL
Mike Bailey
2.1 Introduction
Fr om an educators perspective, teaching OpenGL in the past has been a snap. The
separation of geometry from topology in the glBegin-glEnd, the simplicity of
glVertex3f, and the classic organization of the postmultiplied transformation ma-
trices has been fast and easy to explain. This has considerably excited the students
because going from zero knowledge to cool 3D program you can smugly show your
friends” was the task of a single lesson. This made motivation easy.
The Great OpenGL Deprecation has changed that. Creating and using vertex
buffer objects is a lot more time consuming to explain than glBegin-glEnd [Angel
11]. It’s also much more error-prone. Creating and maintaining matrices and matrix
stacks now requires deft handling of matrix components and multiplication order
[GLM 11]. In short, while postdeprecation OpenGL might be more streamlined
and efficient, it has wreaked havoc on those who need to teach it and even more on
those who need to learn it.
So the old way” is not current, but the new way ” takes a long time to learn be-
fore one can see a single pixel. How can we keep students enthusiastic and motivated
but still move them along the road to learning things the new way?
1
This chapter
1
One option, of course, is not to transition at all, where the current penalty is simply falling behind
the OpenGL curve. However, in some instances, most notably, OpenGL ES 2.0 [Munshi 08], failing to
transition is not even an option.
17
2
18 IDiscovering
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-
glEnd.
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 isnt 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 prefix 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-
defined 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.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required