See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/263894661

Incorporating Modern OpenGL into Computer Graphics Education

Article in IEEE Computer Graphics and Applications · July 2014

DOI: 10.1109/MCG.2014.69

CITATIONS READS
10 1,872

3 authors:

Guido Reina Thomas Müller

University of Stuttgart Haus der Astronomie, Heidelberg, Germany
118 PUBLICATIONS 1,310 CITATIONS 118 PUBLICATIONS 961 CITATIONS

SEE PROFILE SEE PROFILE

Thomas Ertl
University of Stuttgart
801 PUBLICATIONS 15,799 CITATIONS

SEE PROFILE

All content following this page was uploaded by Guido Reina on 12 August 2014.

The user has requested enhancement of the downloaded file.

 Copyright c 2014 IEEE. Personal use of this material is permitted. Permission from IEEE
must be obtained for all other uses, in any current or future media, including reprinting/repub-
lishing this material for advertising or promotional purposes, creating new collective works,
for resale or redistribution to servers or lists, or reuse of any copyrighted component of this
work in other works.

Preprint

G. Reina, T. Müller, and T. Ertl

Incorporating Modern OpenGL into Computer Graphics Education
IEEE Computer Graphics and Applications 34, 16-21 (2014).
DOI: 10.1109/MCG.2014.69
Incorporating Modern OpenGL into Computer Graphics Education
G. Reina, T. Müller, and T. Ertl
Institute for Visualization and Interactive Systems, University of Stuttgart
June 1, 2014

The University of Stuttgart’s Institute for Visualization and Interactive Systems has offered an intro-
ductory course on graphical interactive systems since 1999. From the beginning, one of the institute’s main
research interests has been scientifi c visualization, which relies heavily on hardware-based programming.
Consequently, the course has incorporated since its inception an introduction to OpenGL (the Open Graph-
ics Library) covering its features and the current available hardware. So, because our chosen development
environment has been C/C++ using OpenGL, student exercises have employed that environment to prepare
students for subsequent studies at the institute.
In 2011, we reworked the introductory course and renamed it Computer Graphics (CG). We replaced
legacy OpenGL in this and subsequent courses with deprecation-free, forward-compatible OpenGL, version
4.2. Both internal and external colleagues expressed some reserve regarding this strategy. The minimal
HelloGL program is significantly more complex than an immediate-mode legacy version, thus significantly
increasing the effort to obtain the fi rst rewarding results. (For more on modern OpenGL, see the related
sidebar.)
However, we were convinced we could still motivate students by adding more frequent, concrete, and
(especially) interactive examples that directly demonstrate the austere, detailed steps that produce a minimal
working implementation of HelloGL. We also thought it worth the risk to introduce a programming paradigm
that better agrees with OpenGL ES (OpenGL for Embedded Systems) and modern DirectX, which have
always been strictly retained-mode APIs. OpenGL ES is particularly growing in importance because of the
spread of powerful handheld devices and the broad availability of WebGL (the Web Graphics Library). So,
students can benefit from modern OpenGL in this context too.

Coping with Modern OpenGL

We teach computer graphics employing the modern OpenGL pipeline exclusively. We follow the common
bottom-up approach.[FWW13] An in-depth education typically spans three courses that students can take
as part of the bachelor or master’s program. First, the CG course introduces hardware accelerated graphics
and instills a basic understanding of GPU programming. It covers perception, elementary linear algebra,
transformations, and raster-based graphics as well as the introduction to modern OpenGL. It consists of
credit hours of lecture and one credit hour of exercises covering the lecture’s theoretical content and step-
by-step implementation of a software rasterizer. (In Germany, a credit hour is 45 minutes. This is usually
accompanied by roughly 90 minutes for studying and completing assigned exercises.) Once students un-
derstand the concepts, they work directly with the hardware implementation. Any scientific-visualization
project, lab, or bachelor thesis builds on a basic knowledge of OpenGL, so we encourage all students to take
CG during their bachelor studies.
Next comes the in-depth Practical Course in Visual Computing (PCVC), which requires the implementa-
tion of a modern OpenGL-centric scene, complete with picking, lighting, procedural textures, and blending.

1
Additional topics cover advanced shader-based techniques such as level-ofdetail geometry (surface tessel-
lation) and volume ray tracing. This four-credit-hour lab course focuses entirely on the implementation.
So, the advisors’ input covers abstract algorithms and specifi es the required functionality in great detail,
but provides next to no code, unlike CG. Tutors provide only a very terse code skeleton for achieving the
requirements but also offer detailed mentoring regarding implementation questions once a week. In contrast,
in CG, students code a few lines per week.
PCVC culminates in a 1.5-month student project that can cover anything from an advanced rendering
technique to a simple computer game. Students can either come up with their own topic and finetune its
components and grading with their advisor, or choose from topics offered by the advisor.
Finally, the Image Synthesis (IS) course covers advanced rendering techniques and visual effects. It
consists of three credit hours of lecture and one credit hour of exercises. The assignments are based on
modern OpenGL and emphasize writing GLSL (OpenGL Shading Language) shaders.
We tackle the complexity of understanding modern OpenGL by gradually abstracting the coding effort
throughout the curriculum. For example, in some first exercises in CG, students must implement the basic
transformations or management of the rendered geometry on their own. We endorse this strategy because
the best learning happens when students can make their own mistakes. This leads to a better understanding
than a general explanation of any concept in the lecture. So, the course also stresses that, in the end,
students can really grasp OpenGL only through repeated practical use.
Once the exercises treat more advanced topics, especially in IS, we delegate repetitive chores to our
educational framework, which we describe in the next section of this article. This guarantees that students
can always concentrate on the necessary steps and the relevant OpenGL subset, without being burdened or
distracted by ever-recurring tasks.
Some exercises (in CG and IS) also abstract the concept of shaders by preparing a running executable
and working shaders that lack code only in very specific functions. So, students write what looks like C code
in a text file and achieve realtime effects because it executes on the GPU. We figure this strategy makes it
evident that because writing shader code isn’t really different from what students are used to, there isn’t
much they need to worry about.
Regardless of modern OpenGL’s educational challenges, we still agree with Ed Angel and Dave Shreiner
that employing a shader-based pipeline presents innumerable benefits over deprecated OpenGL.[AS11] How-
ever, a considerable problem is the increased effort to create the host code for a minimal working HelloGL.
The handling of model-viewprojection matrices, window and user interaction management, and the retained
mode are significant hurdles for students, who can initially use one-line shaders to at least mimic a minimal
fixed-function pipeline. So, our framework includes convenience classes, and we advise students to use GLM
(OpenGL Mathematics; http://glm.g-truc.net).
The remaining hurdles are the technical, detailed introduction of a minimal working HelloGL in CG and
the ensuing structured walkthrough of the current pipeline. To ease these hurdles, we use a multitude of
examples, some of them interactive. This not only fosters understanding of the available parameters in the
context of simple scenes but also helps motivate students until a shaderbased pipeline’s benefits become
self-evident. This can occur, for example, when the students compare some exemplary deprecated features
of legacy OpenGL to the more concise and far more flexible shader-based alternative. (For more on how we
still use legacy OpenGL in our courses, see the related sidebar.)
Students from other disciplines can attend CG in the master’s program; however, we’re contemplating al-
ternatives that allow for quicker catchingup. For example, we’re developing a streamlined self-study OpenGL
tutorial that could replace CG for those students. Many tutorials are available online, but none cover the
theoretical background and employ modern OpenGL consistently, which are our goals. For example, the
classic NeHe tutorials (http://nehe.gamedev.net) cover modern OpenGL only as an in-depth addendum.
Also, there’s at least one OpenGL tutorial (www.opengl-tutorial.org), but it can’t replace a lecture in
terms of theoretical background. So, we feel we must alleviate this shortcoming.

2
 Modern OpenGL’s Complexity
Modern OpenGL (also called core OpenGL or forwardcompatible OpenGL) has raised the entry threshold
for computer graphics programming. The API’s modernization came at the price of reduced out-of-the box
convenience by deprecating part of the API with version 3.0–for example the convenient, albeit anachronistic
and performance-hindering, immediate mode. This also cost us the matrix setup from GLU (the OpenGL
Utility Library), which also relied on the deprecated matrix stack. Additionally, the modern OpenGL pipeline
can execute only if a minimal set of shaders (a vertex shader and fragment shader) is activated.
These changes have considerably lengthened the minimal HelloGL program. Besides these fundamental
OpenGL complications, window handling and user interaction continually require much effort. Things get
even worse if you want an actual UI because hot keys often don’t scale with the available parameters and
short-term memory. These recurring chores, alongside utility functionality such as image and shader loading,
make a framework indispensable for keeping the educational focus on OpenGL itself.
We believe we can reconcile OpenGL’s increasing complexity with a bottom-up computer graphics educa-
tion, even if the time spent on the course material can’t increase to match OpenGL’s increasing complexity.
The parallel nature of the GPU, however, has so many implications that an understanding of its inner
workings is always beneficial. The most important factor in our educational strategy is to continually and
consistently abstract concepts that the students have internalized, so that lectures and exercises can focus
on the new content. Our main contribution to this goal is the educational framework.

Using Legacy OpenGL

Our courses still use legacy OpenGL. We do this mostly to demonstrate that, with modern OpenGL, you
can emulate some obsolete built-in functionality much more easily and flexibly by just adding a snippet of
shader code.
One example of this strategy is the alpha test. Instead of modifying the alpha test state with some few,
predefined functions and enabling it, you can just write an arbitrary alpha condition in the fragment shader
and discard the fragment accordingly. The same is valid for alpha compositing within a single geometry (just
use multitexturing and blend directly in the fragment shader). It’s also valid for the extremely unintuitive
texture environment modes (just apply the texture information to the fragment or geometry as you see
fit). With this strategy, legacy OpenGL can serve as an inspiration for what you might want to achieve in
basic computer graphics. In addition, students can easily relate to the decision to favor modern OpenGL
functionality.

The Educational Framework

We designed our framework with a few specific issues in mind. First, we wanted only a single code base
to maintain, possibly without having to preprocess the files we hand out to students. We also aimed at
minimal management overhead for the code, ideally enabling students to write code that concerned OpenGL
exclusively. This would also progressively increase abstraction and thus minimize background noise to let
both the advisors and students concentrate on the task at hand. The framework should provide convenience
functionality that students could employ when permitted but shouldn’t present copyable solutions for assign-
ments. Finally, it needed to be platform independent and present as few library dependencies as possible,
ideally allowing students to make do with a compiler only.
Finding frameworks on the Internet is easy, but most are for computer games, such as OGRE (the Object-
Oriented Graphics Rendering Engine; http://www.ogre3d.org), Polycode (http://www.polycode.org),
and Unity (http://unity3d.com). We felt they wouldn’t provide abstraction that precisely fit specific

3
specific aspects of OpenGL or the courses, because the convenience they provide would rarely coincide with
the semantics we progressively hide.
Figure 1 shows our framework’s design. Users can access only the unshaded parts in the figure; the
shaded parts are hidden. Users can implement just one plug-in at a time. Plug-ins load dynamically
and can be interactively switched at runtime–for example, so that we can distribute a collection of them
for demonstration purposes alongside the framework. We employ either of the implemented front ends
to generate the OpenGL context and handle input events. By default, we distribute the front end that’s
statically linked with FreeGLUT (an open source alternative to the OpenGL Utility Toolkit). We can add
arbitrary front ends later without any implications for the users.

gl3w glm
Libraries
Frontends Plugins
AntTweakBar
CG/DrawMode
freeglut CG/zFighting
CG/BlendFunc
OGL4CoreAPI Renderplugin CG/Instancing
ATL
TMFVC/Terrain
TMFVC/Filtering

…
UI Parameters
Manipulators

Shader Class
PPM Codec

OBJ Loader
PNG Codec

Utilities

Figure 1: Our framework’s high-level architecture. Only the unshaded parts are accessible to programmers
through the methods of RenderPlugin. The framework completely encapsulates AntTweakBar so that we
can replace it if necessary. The front ends required for window management and event handling are modular.
Some user-accessible convenience classes are at the bottom of the figure. Plug-ins load at runtime and can
be arbitrarily extended.

Internally, the framework uses AntTweak-Bar (http://anttweakbar.sourceforge.net) to generate

a minimal UI with simple widgets. The framework also uses GLM and gl3w (https://github.com/
shakesoda/gl3w). GLM’s basic types are employed in the API variables (APIVars) and manipulators of
the RenderPlugin interface. Both libraries are included in our source distribution and can be referenced
directly, as can any additional required library. Interaction between the framework and a plug-in is always
routed through the abstract ancestor class RenderPlugin.
For a working plug-in, the user inherits from RenderPlugin, which requires implementing at least the
following four pure virtual methods.
First, the user employs Init to check for the availability of the required OpenGL version, extensions,
and so on. Plug-ins that don’t initialize successfully at framework startup are deallocated and removed from
the running framework. For modern OpenGL, gl3w offers a convenient initialization method to load all core
profile functionality.
Second, Activate is where a plug-in loads its resources and generates its OpenGL objects. Parameters
or variables that will be available through the AntTweakBar UI are initialized and registered here.

4
 Third, Deactivate hosts code to delete and destroy all the resources defined in Activate. The Activate/
Deactivate pair describes the active cycle of a plug-in in conjunction with its selection in the UI. The
framework itself removes the controls allocated by each plug-in.
Finally, Render is called from the framework’s draw callback and displays the scene.
Other front-end callback functions are optional and can be overloaded similarly–for example, Keyboard,
Motion, Mouse, and Resize. They return a Boolean value indicating whether the framework may take further
action or should consider the event consumed. This way, users can hide key presses from the framework or
prohibit it from drawing over a user-generated scene.
To further increase convenience, we provide two scripts (PowerShell and Perl) that instantiate a new
plug-in with a chosen name. This directly presents users with an empty class in which they only need to
fill its previously listed methods. This produces an acceptably compact and, above all, tidy HelloGL (see
Figure 2).
The only remaining overhead is the factory function required as a generic interface for instantiating each
plug-in. It’s also required because a plug-in can only be allocated in the memory space of the dynamic
link library in which it resides. Conversely, the framework can’t destroy the plug-in instance, so we made
RenderPlugin reference-counting and thus self-destructing.
Another advanced feature of our framework is the APIVars. These let users just declare a variable of one
common type, including all integral C++ data types, strings, automatically globbed file lists, or OpenGL
states. Users can then automatically obtain a widget in AntTweakBar and set a pointer-tomember callback
used when the variable changes.
Consider the code in Listing 1 , which lets users select a color for some part of the scene. With just three
lines of code, a set of templates following policy-based design[Ale01] takes care of all the tedious, repetitive
code that’s usually needed. Also, operators are overloaded such that the code can use color as a variable
of type glm::vec3 could. These features’ inner workings are hidden from the students, who don’t need to
concern themselves with any complications. For them, everything just works.
SimpleTriangle.h : APIVar<SimpleTriangle, Color3FVarPolicy> color;
SimpleTriangle::Activate: color.Set(this, "fore color", &SimpleTriangle::ColorChanged);
color.Register();
Listing 1: This code lets users select a color for some part of the scene. With it, a set of templates following
policy-based design takes care of all the tedious, repetitive code that’s usually needed.

To easily obtain interactive demonstrations for lectures, we created an ATL (Active Template Library)
front end that presents itself as an ActiveX plug-in to PowerPoint. (ATL is a set of templatebased C++
classes that simplify the programming of Component Object Model objects.) So, we can integrate our
framework as a control on any slide and load any sample solutions that we created for exercises, along with
any demo plug-ins for illustrating the lectured concepts. For convenience, we can parameterize the ATL
front end to load a specific plug-in when it’s shown. We also added a hot key for taking a representative
screenshot of the running plug-in. In addition, we added a PowerPoint macro that replaces all plug-ins with
their associated screenshot to export a static PDF version of slides as a reference for students. Figure 2
shows an example PowerPoint slide.
The convenience classes required for abstraction that we discussed in the context of reducing overhead
for educational purposes also simplify and speed up development of visualization prototypes. Students may
use these classes only after they’ve practiced the related concept in an exercise. To avoid them accessing
such solutions early, we publicly distribute our framework only as closed source. Students can compile their
own plug-ins against the provided libraries and just place the plug-in in the framework executable’s search
path. The plug-in instantiation mechanism also constructs a Visual Studio solution that’s readily configured
for debugging, using a debug compile of the framework.

5
Figure 2: A PowerPoint slide with our ATL (Active Template Library) front end. The red and blue control
points can be moved interactively in presentation mode.

Student feedback has been positive. The framework turned out surprisingly practical, such that even our
colleagues are using it for rapid prototyping of GPU-based visualization algorithms. You can freely obtain it
from http://go.visus.uni-stuttgart.de/ogl4core, along with several example plug-ins in source form
and brief introductory documentation. We’re collecting plug-ins for interactive demonstrations and prototype
implementations of GPU-based visualization algorithms. We haven’t publicly distributed these for the same
reason we haven’t publicly distributed the convenience classes’ source. Feel free to contact us for access to
them.

Acknowledgments
We thank Christoph Müller for his substantial help with designing the API variables for maximum flexibility
along with an extremely concise implementation.
#include "RenderPlugin.h"
#include "glm.hpp"
#include "GL3/gl3w.h"
#include "gtc/matrix_transform.hpp"
#include "GLShader.h"

const static std::string vsCode =

"#version 330\n"

6
 "layout(location = 0)"
"in vec2 in_position;"
"uniform mat4 mvp;"
"void main() {"
" gl_Position = mvp * "
" vec4(in_position,0,1);"
"}";

const static std::string fsCode =

"#version 330\n"
"layout(location = 0) "
"out vec4 frag_color;"
"void main() {"
" frag_color = vec4(1,1,0,1);"
"}";

class OGL4COREPLUGIN_API SimpleTriangle :

public RenderPlugin {
public:
SimpleTriangle(COGL4CoreAPI *Api) : RenderPlugin(Api) {
// properties for AntTweakBar and plug-in selection
this->myName = "SimpleTriangle";
this->myDescription = "Render a single triangle";
}
~SimpleTriangle() {}

virtual bool Activate() {

glClearColor(0.1f,0.1f,0.2f,1.0f);
float triVerts[6] = {0.2f,0.2f,
0.8f,0.2f, 0.5f,0.8f};
glGenVertexArrays(1,&va);
glGenBuffers(1,&vbo);
glBindVertexArray(va);
glBindBuffer(GL_ARRAY_BUFFER,vbo);
glEnableVertexAttribArray(0);
glBufferData(GL_ARRAY_BUFFER,sizeof(GLfloat)*3*2,triVerts,GL_STATIC_DRAW);
glVertexAttribPointer(0,2,GL_FLOAT,GL_FALSE,0,NULL);
glBindVertexArray(0);
shader.CreateProgramFromString(vsCode.c_str(),vsCode.length(),fsCode.c_str(),fsCode.length());
return true;
}

virtual bool Deactivate() {

glDeleteBuffers(1,&vbo);
glDeleteVertexArrays(1,&va);
shader.RemoveAllShaders();
return true;
}

virtual bool Init() {

if (gl3wInit()) {
fprintf(stderr,"Error: Failed to "
"initialize gl3w.\n");
return false;

7
 }
return true;
}

virtual bool Render() {

glClear(GL_COLOR_BUFFER_BIT);
glm::mat4 pvMatrix = glm::ortho(
0.0f,1.0f,0.0f,1.0f);
shader.Bind();
glUniformMatrix4fv(
shader.GetUniformLocation("mvp"),1,
GL_FALSE,glm::value_ptr(pvMatrix));
glBindVertexArray(va);
glDrawArrays(GL_TRIANGLES, 0, 3);
glBindVertexArray(0);
shader.Release();
return false;
}

private:
GLuint vbo,va;
GLShader shader;
};

// factory function do not edit

extern "C" OGL4COREPLUGIN_API RenderPlugin* OGL4COREPLUGIN_CALL
CreateInstance(COGL4CoreAPI *Api) {return new SimpleTriangle(Api); }
Listing 2: The minimalistic HelloGL program in modern OpenGL as plugin for our framework renders a
simple triangle. The modern OpenGL function pointers are populated by means of the call to gl3wInit
within the Init method. In the Activate method, the vertices for the triangle are set and stored in a vertex
array object, and the shader program is constructed from the vertex and fragment shader code given above
as string values. Shader and buffer resources are freed in Deactivate. Finally, the triangle is drawn in the
Render method.

References
[Ale01] Andrei Alexandrescu. Modern C++ Design: Generic Programming and Design Patterns Applied.
Addison-Wesley Longman Publishing Co., Inc., 2001.
[AS11] E. Angel and D. Shreiner. Teaching a shader-based introduction to computer graphics. Computer
Graphics and Applications, IEEE, 31(2):9–13, March 2011.
[FWW13] Heinrich Fink, Thomas Weber, and Michael Wimmer. Teaching a modern graphics pipeline using
a shader-based software renderer. Computers & Graphics, 37(1–2):12–20, February 2013.

Guido Reina is a post-doctoral researcher at the Visualization Research Center of the University of
Stuttgart.
Thomas Müller is a post-doctoral researcher at the Visualization Research Center of the University of
Stuttgart.
Thomas Ertl is professor and director of the Institute for Visualization and Interactive Systems at the
University of Stuttgart.

View publication stats