Every year since 2005 I have taught an elective second year undergraduate degree level introductory Computer Graphics Programming (CGP) course using OpenGL's fixed graphics pipeline. In recent years I have debated with myself as to whether I move to the programmable pipeline and require students to write shaders. This is a dilemma that many colleagues face when delivering a standalone computer graphics course within a degree program that does not center on graphics or animation. This type of pedagogical conundrum is not limited to the domain of computer graphics but in fact takes place across computer science disciplines. It has similarities with the long-running "objects-first" debate in teaching programming [5], wherein academics are divided between a procedural approach and starting with objects first. However, despite their similarities each debate has their own unique technological and pedagogical considerations. Furthermore, I have found the shaders-first debate is complicated by student opinions in a way I have not experienced when teaching novice programming courses. Many students, often influenced by online commentary, object to using "old" or "outdated" OpenGL libraries until they encounter shaders later in the course and begin to understand the added complexity inherent in more modern frameworks.

I have often discussed and debated appropriate teaching approaches for graphics programming with colleagues from other institutions. This column explores the arguments for and against using the fixed pipeline and arrives finally at my current approach, which represents a compromise between fixed and programmable pipelines.


… shader programming exposes students to an alternative and unique paradigm of programming and provides the opportunity for educators to introduce, in an intuitive setting, the ideas of parallel processing and GPU programming.


Students and Setting

The students in my course are studying towards an undergraduate degree in Software Engineering or Software Development. They have studied one semester of procedural C programming, one semester of object-oriented Java programming, and an introductory algebra course. CGP is intended to provide an interesting elective course that introduces real-time graphics programming and provides prerequisite knowledge for a follow-on elective course in introductory games programming. My CGP class is small, capped at 32 students, and this size allows for group and individualized teaching. The course is taught in four hours of studio sessions per week for twelve weeks and takes a project-based approach to learning. The overarching pedagogy followed is a top-down approach [6] in which higher level concepts are taught first rather than starting with raster-level operations. This top-down approach is thought to be the best approach for students from less traditional backgrounds and those not intending to specialize in computer graphics [3].

Shaders-First Approaches

One of the main pedagogical arguments, in the limited literature on the subject, is that learning shaders exposes the functionality obscured by the fixed pipeline APIs [8,9]. The argument goes that students will understand the underlying pipeline's mechanisms better as they write code to transform the position and normals of vertices [8]. With shaders, students see inside the "black box" that is the fixed pipeline. Instead of memorizing fixed pipeline equations, such as the Blinn-Phong lighting model, students can implement these algorithms and experiment with different variants [9]. Another benefit noted is that shader programming exposes students to an alternative and unique paradigm of programming and provides the opportunity for educators to introduce, in an intuitive setting, the ideas of parallel processing [8] and GPU programming [9]. Finally, in the long run better graphical effects can be achieved using the programmable pipeline [8] at the cost of a much steeper learning curve than for the fixed pipeline [4,6].

Most of the shaders-only curricula mentioned in the literature rely on scaffolding and other supporting mechanisms (e.g. see [3,6,8,9]). One reason for this is that teaching shaders first requires a significant amount of extra material to be introduced [9]. This additional material means that decisions must be made as to which topics should be removed. Where a topic is removed inevitably some of the missing material is essential and must be supplied in some form that the students can use to produce a working program.

Talton and Fitzpatrick's early shaders-only approach removed the implementation of the overall framework required to produce a real-time animation [8]. Rather than writing this code the students were given a detailed interface specification and a pre-built executable so that they need "write only the GLSL shaders without having to worry about setup code" [8, p. 261]. In a similar approach, more recent editions of Angel and Shreiner's textbook [2] cover shaders only and ship with code to support the linking and compiling of shaders, and the mathematical transforms of matrices and vectors. In my experience such approaches lead to students being unable to link the parts of the pipeline together. Students can to some degree program shaders to provide a nice visual effect, such as chromatic aberration on a static mesh model, but in a single-semester course most students cannot build a significant real-time animation project from scratch.

Fixed Pipeline Approaches

Some textbooks still use the fixed pipeline API but include additional chapters that cover shader programming [4]. Hearn et al. argue that the fixed pipeline API is easier to learn and that there is a large existing code base to support learning [4]. Nysjü and Hast agree that modern shader-based OpenGL is harder to learn [6]. They note that shader-based OpenGL programs require many more lines of code to be written in order to display something on the screen. Hearn et al. also point out that because of the more gradual learning curve afforded by the fixed pipeline the need for scaffolding in the form of code and frameworks is limited to commonly used libraries [4]. In contrast, many shaders-first approaches use libraries designed to hide some of the complexities of the programmable pipeline and to fast-track students into shaders. Such approaches can lead to difficulties later when this scaffolding is removed.


… one contributor noted that when beginning with the programmable pipeline: "Being overwhelmed with non-graphics topics, the beginner usually misses the main concepts like transformations, lighting, texturing etc."


In gamedev.net discussions regarding teaching approaches for OpenGL, one contributor noted that when beginning with the programmable pipeline: "Being overwhelmed with non-graphics topics, the beginner usually misses the main concepts like transformations, lighting, texturing etc." [1]

A Compromise

My current course delivery starts with the fixed pipeline and follows a top-down approach. Students learn about coordinate systems, OpenGL functions, the state machine paradigm, by-vertex rendering, depth testing, hierarchical modelling, and other key topics. Figure 1 shows a typical student's 2D assignment delivered at the end of week four and illustrates the rapid entry into graphics programming that is enabled by a fixed pipe-line approach.

At week five I introduce the fixed pipeline lighting model in detail, and students learn how to use that model. In the next class students are introduced to the differences between the fixed and programmable pipeline. They are provided with example code that implements the fixed pipeline's lighting model in GLSL, and as an exercise implement a per-pixel version of this model. In the final project for the course students are given marks for implementing advanced techniques; this is a requirement for achieving an A grade. The higher achieving and/or more confident students (~10% of the class) often opt to include shaders in their final project.


Next year I suspect, as usual, I will have another internal debate about teaching shaders. However, while I might increase the focus on shaders, at this stage I would not omit an introduction to the fixed pipeline. I believe that students need to at least be exposed to the traditional fixed pipeline and its algorithms for several reasons.


I arrived at this delivery based on my years of experience with the course. While I have considered shifting to a shaders-first approach, I fear it would severely limit what students are able to achieve within a single semester. If my course were just the introduction to an entire degree program on graphics or games, that may not be a problem. As a standalone "elective" course within a broader computer science or engineering degree, I believe it's more important for students to acquire a broad range of foundation skills in graphics which can then be transferred to all manner of graphical frameworks in their future careers. The course is not intended to produce graduates ready to work in the graphics or games domains, but to broaden the background of future software developers.

Next year I suspect, as usual, I will have another internal debate about teaching shaders. However, while I might increase the focus on shaders, at this stage I would not omit an introduction to the fixed pipeline. I believe that students need to at least be exposed to the traditional fixed pipeline and its algorithms for several reasons.

  1. Starting with the fixed pipeline allows students to create something significant, with no prior knowledge, in the limited timeframe of a single-semester course.
  2. The fixed pipeline offers a simple, standard foundation that—along with teaching methods to enable transfer of knowledge—can reduce the learning curve associated with the programmable pipeline.
  3. Using the fixed pipeline as a foundation avoids common issues with the use of third-party frameworks to hide the complexity of the programmable pipeline, many of which are created by one person for a single course.

In terms of teaching approaches, while most of the textbooks and resources have moved to shaders in some form or another there still seems to be a lack of consensus on how to teach computer graphics. Many institutions, including my own, have taken a "back to basics" approach to teaching programming in recent years, leaving behind the modern concept of objects-first to focus on the most basic foundations. Many others still start with objects first. Thus, the objects-first debate continues. The "shaders-first" debate exists more as a little-explored facet of course design, and an issue of student perceptions. There have been very few empirical evaluations of the impact of teaching approaches in computer graphics. The few evaluations that have been conducted tended to involve surveying students about their feelings and perceptions. More rigorous evaluations of the implications of teaching and learning approaches for computer graphics are sorely needed to enable the same open and informed conversations as we have around objects-first.

In the end, whichever pedagogy you decide to follow should of course be informed by the purpose and local context of the course, the students, and, I hope in the future, by the results of rigorous empirical research.

References

1. Ack9. Should I start with fixed-function-pipeline OpenGL or the newest possible? GameDev.net., 2016; https://www.gamedev.net/forums/topic/677490-should-i-start-with-fixedfunction-pipeline-opengl-or-the-newest-possible/. Accessed 2020 April 8.

2. Angel, E. and Shreiner, D. Interactive Computer Graphics: A Top-Down Approach with Shader-Based OpenGL. 6th ed. (Addison-Wesley, 2012).

3. Fink, H., Weber, T. and Wimmer, M. Teaching a modern graphics pipeline using a shader-based software renderer. Computers & Graphics, 37, 1-2 (2013), 12–20. doi:10.1016/j.cag.2012.10.005.

4. Hearn, D., Baker, M. and Carithers, W. Computer Graphics with OpenGL. 4th ed. (Prentice Hall, 2011).

5. Lister, R., et al. Research perspectives on the objects-early debate. SIGCSE Bull. 38, 4 (2006), 146–165. doi:10.1145/1189136.1189183

6. Nysjü, J. and Hast, A. Teaching OpenGL and Computer Graphics with Programmable Shaders. In Proceedings of SIGRAD 2015 (2015). 32–34. http://www.ep.liu.se/ecp/120/009/ecp15120009.pdf. Accessed 2020 April 8.

7. Sung, K. and Shirley, P. A top-down approach to teaching introductory computer graphics. Computers & Graphics, 28, 3 (2004), 383–391. doi:10.1145/965106.965114.

8. Talton, J. O. and Fitzpatrick, D. Teaching graphics with the openGL shading language. In Proceedings of the 38th SIGCSE Technical Symposium on Computer Science Education (March 2007), 259–263. doi:10.1145/1227310.1227402.

9. Wolff, D. How do we teach graphics with OpenGL? J. Comput. Sci. Coll., 28, 1 (2012), 185–191.

Author

Jacqueline Whalley
School of Computing and Mathematical Sciences
Auckland University of Technology
Private Bag 92006
Auckland, 1142 New Zealand
[email protected]

Figures

F1Figure 1. A student's first assignment demonstrating, among other things, a mastery of: particle systems, depth and transparency, animation, day-night cycles, and OpenGL rendered UI controls. Used with permission.

Copyright held by author/owner.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2020 ACM, Inc.

Contents available in PDF
View Full Citation and Bibliometrics in the ACM DL.

Comments

There are no comments at this time.

 

To comment you must create or log in with your ACM account.