I think that there's a disconnect between academia and industry in the field of computer graphics. This is probably because professors usually mistake profusion for broadness. You can spend one chapter each on:
HSV colors | Bezier and NURBS curves | Vector (font) scaling/rotating/etc. | Scene graphs | OpenGL lines API | OpenGL rectangles API | OpenGL texturing API | OpenGL rotation API | OpenGL colors API | GLUT (busywork to get 3D graphics on the screen) | JOGL (busywork to get 3D graphics on the screen) | SVG file format | 3D Model/View/Projection matrices | linear algebra | Lighting (from an OpenGL 1.0 perspective, which misses a lot of lighting theory) | OpenGL material API | OpenGL MipMaps API | More scenegraph, this time with camera and lights | How to do a bunch of stuff you already learned, this time in Three.JS instead of OpenGL | How to do meshes, in Three.JS instead of OpenGL | How to do fixed-function shadows, this time in Three.JS instead of OpenGL | The programmable pipeline (finally) | WebGL busywork to get something on the screen | GLSL syntax | texture units | 2D transforms, this time in GLSL instead of fixed-function | Lighting in GLSL | Textures in GLSL | Multiple framebuffers | deferred shading | ray tracing | path tracing
and feel as though you've taught a lot of stuff, but in reality it's not a honest simplification of later graphics knowledge.
I think that a better approach would be (1) Explain 3D math, linear algebra, etc. (2) Explain raytracing algorithms, show the student some simple raytracing code (3) Explain the basics of modern GPU-based rendering (4) Show the student some simple software-based raster rendering, which mimics what the GPU does (5) Explain the shader pipeline (6) Using WebGL (no need to teach three.js and OpenGL 1.0 also!), show the student all the various principles of 3D graphics, going into theory when appropriate.
Scenegraph? That's irrelevant. GLSL syntax? We don't need a comprehensive explanation, the documentation already does a better job than we would. We just need to cover enough to let them know what's possible. HSV color? Bezier curves? MipMaps? OpenGL 1.0 API in gory brutal detail? GLUT? JOGL? Those deserve a mention but not an entire section.
Much of that is mostly of historical interest.
Today, either you're using the scene graph of some game engine, or you're
down at the Vulkan and shader level, working on the engine and programming the GPU. A theoretical understanding of the whole pipeline is helpful for both, but how much of the old mechanics should be taught is a question.
WebGL is easy for students to start with, since all you need is a browser. It's not really used much on the Web; most of the good demos are over 5 years old. Despite that, it's probably worth teaching WebGL simply because students can use it to get something they can show to others.
Here's the Utah teapot in WebGL: [1] Udacity uses that example. Once students understand how that works, they probably know enough unless they intend to do game engine development.
This is endemic to most pedagogy that uses programming, I feel. I often see Learn x via the medium of Python and it feels quite philistinic compared to a proper textbook - maths isn't that hard if taught thoroughly and confidently, don't write a cookbook.
On the other hand, don't write books like engineers do. Treat it like a work of art rather than a legal document - introductory engineering books are too slim, and more advanced texts (especially on FEM, I've found) are almost unreadably dry (If you want to be dry, write like a mathematician and try and motivate things first rather than spewing pages of unproven results that we may or may not need later)
I feel like much of your comment can be reduced to focusing on the underlying concepts instead of the various (perpetually outdated) APIs. An API is just a means to an end that could (and probably will) change tomorrow.
> HSV color?
Similarly, specific color spaces aren't what's important. RGB, sRGB, HSV, Display P3, they're all just implementation details. Color spaces as a concept are what's important. What problem do they solve? What are the tradeoffs being made between them? Why does gamma even exist in the first place? How does all this stuff relate to reasonably modern hardware that was actually manufactured within the past decade?
I do think there's a bit of a lose-lose situation here though. 3D math is hard and modern hardware is staggeringly complex but doing a competent job is probably going to require a decent understanding of such underlying details. Meanwhile, a university course that doesn't leave students proficient with the latest and greatest API is likely to be accused of failing to prepare them for the real world. APIs keep changing year after year though, inevitably rendering any such material outdated in short order.
I felt very much the same. Especially the lack of focus on understanding the math. Especially linear algebra. Yes, it shows how to build a classic 4x4 matrix, but I feel there's a lot more which needs to be said about it when teaching this stuff to beginners.
Just looking at the chapters and reading a bit here and there doesn't give me a very good feeling. I don't like the approach, it feels like it focuses on the wrong things in the wrong order.
HSV colors | Bezier and NURBS curves | Vector (font) scaling/rotating/etc. | Scene graphs | OpenGL lines API | OpenGL rectangles API | OpenGL texturing API | OpenGL rotation API | OpenGL colors API | GLUT (busywork to get 3D graphics on the screen) | JOGL (busywork to get 3D graphics on the screen) | SVG file format | 3D Model/View/Projection matrices | linear algebra | Lighting (from an OpenGL 1.0 perspective, which misses a lot of lighting theory) | OpenGL material API | OpenGL MipMaps API | More scenegraph, this time with camera and lights | How to do a bunch of stuff you already learned, this time in Three.JS instead of OpenGL | How to do meshes, in Three.JS instead of OpenGL | How to do fixed-function shadows, this time in Three.JS instead of OpenGL | The programmable pipeline (finally) | WebGL busywork to get something on the screen | GLSL syntax | texture units | 2D transforms, this time in GLSL instead of fixed-function | Lighting in GLSL | Textures in GLSL | Multiple framebuffers | deferred shading | ray tracing | path tracing
and feel as though you've taught a lot of stuff, but in reality it's not a honest simplification of later graphics knowledge.
I think that a better approach would be (1) Explain 3D math, linear algebra, etc. (2) Explain raytracing algorithms, show the student some simple raytracing code (3) Explain the basics of modern GPU-based rendering (4) Show the student some simple software-based raster rendering, which mimics what the GPU does (5) Explain the shader pipeline (6) Using WebGL (no need to teach three.js and OpenGL 1.0 also!), show the student all the various principles of 3D graphics, going into theory when appropriate.
Scenegraph? That's irrelevant. GLSL syntax? We don't need a comprehensive explanation, the documentation already does a better job than we would. We just need to cover enough to let them know what's possible. HSV color? Bezier curves? MipMaps? OpenGL 1.0 API in gory brutal detail? GLUT? JOGL? Those deserve a mention but not an entire section.