Ah, the good old OpenGL fixed function pipeline, deprecated for over 11 years now.
For something a bit more modern, I'd recommend [0], but one might argue that old OpenGL is easier to learn since you don't have to setup your own shaders.
For something a bit more modern, I'd recommend [0], but one might argue that old OpenGL is easier to learn since you don't have to setup your own shaders.
One of my longer-term goals as a TA for the class is to update Scotty3D to Vulkan or modern OpenGL.
EDIT: I wanted to expand on this point, as this is actually an important part of the philosophy of the design of the course. As the OP argues as well, it more important to learn the fundamentals of CG theory (eg rasterization, the rendering equation, solving ODEs/PDEs) than the specifics of any particular implementation (OGL, DX, etc). After taking 462, many students (including myself!) take the class 15-466 Computer Game Programing [0], which goes deep into more modern OpenGL implementations (admittedly, it's OGL 3.3, but it still covers shaders/VBOs/other important concepts that translate to modern APIs).
Even if you're talking about game engines, there's still a whole lot more to learn. This game engine book [1] has one chapter about the rendering engine and 16 more about other topics. Each chapter in there is at least one hefty book to get a good working knowledge of the topic.
It's great you have a resource where people can learn and experiment with these other things without having to learn to write all the code around it.
Which is why when people without game industry experience start discussing 3D APIs adoption, they loose on how little the APIs actually influence the whole engine codebase.
With Apple working to eliminate all traces of OpenGL with Metal, and Microsoft already having abandoned it close to two decades ago, I feel it's close to the end of the road for fixed function OpenGL. It was a wonderful part of graphics development history that, sadly, future beginners will likely not be able to experience.
... but there are hundred of cross-platform APIs to abstract this stuff - unity3d, unreal engine, qt3d, etc...
I've recently been following along a vulkan tutorial to get started with that, in the odd evening over the last few weeks. I'm six chapters in, and I've yet to even draw a single triangle. That's still about five chapters away. While I can appreciate that the flexibility of the setup to remove much of the implicit state contained within the GL state machine is good, I can't help but wish for a wrapper to just make it work for a typical scenario, and let me render stuff with a minimum of fuss.
I'm unsure about where Metal will fit in the future. No matter how great it is, it's a vendor-specific proprietary API and I suspect that Vulkan will be the next cross-platform API which will wrap Metal or DX12 when a native Vulkan driver isn't available.