[robko]

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.

[0] https://learnopengl.com/Introduction

[flafla2]

To clarify, the point of Scotty3D is not to teach OpenGL -- the students do not write any OpenGL, DirectX, Vulkan, etc in the class. The OpenGL that is there is simply used to render the 3D models and the UI, so updating that code is pretty low priority.

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).

[0] http://graphics.cs.cmu.edu/courses/15-466-f18/

[pfranz]

I wanted to support what you're saying. I've worked in visual effects for over a decade now. While I've dabbled with OpenGL, I think the only practical application I've had was taking a stab at writing a PyOpenGL widget for viewing Alembic models in a custom PySide asset browser for a studio. This was when Alembic was much less mature and it never ended up getting used. However, I have done a lot of dealing with color spaces, debugging/optimizing scanline and ray casting renderers, computing/storing surface normals, projection and other space transforms, and simulations. I've written toy versions of a lot of those things, but mostly was debugging back box systems written by others or troubleshooting assets generated or consumed by one of these tools.

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.

[1] https://www.gameenginebook.com/toc.html

[pjmlp]

> 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.

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.

[ryandrake]

There's something charming and engaging about the "legacy" fixed function pipeline that we've lost with our increasing focus on lower and lower level APIs. The ability to have a 10 line hello-world program that draws a colored triangle on the screen is magical, and encouraging to beginners, and that experience can't be replaced by the massive boilerplate and "copy-paste-this-stuff-dont-worry-about-what-it-does-yet" you need to do in order to do graphics the more modern way.

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.

[rectang]

One more instance of how the interests of vendors and the interests of developers are not aligned. Microsoft and Apple don't want you learning portable skills -- they want to limit your future prospects to developing only for their specific platform.

[kkarakk]

noob here - how come no one is making a cross platform API to abstract away this stuff? whenever i read about opengl or vulkan or metal or whatever w/ the tutorial going "learn this engine to bypass complexities of bare api usage", it's my first thought

[jcelerier]

> noob here - how come no one is making a cross platform API to abstract away this stuff?

... but there are hundred of cross-platform APIs to abstract this stuff - unity3d, unreal engine, qt3d, etc...

[orbat]

Unity or Unreal aren't 3D rendering APIs, they're game engines

[miketuritzin]

Vulkan is supposed to be the cross-platform API, but Apple isn't supporting it (and doing their own thing with Metal, as per usual). From what I've heard, Vulkan was originally "OpenGL 5" so while OpenGL continues to exist Vulkan is effectively its successor. There is MoltenVK, which allows Vulkan applications to run on top of Metal.

[chrisbennet]

SFML (Simple Fast Media Library) and SDL are cross platform and hide most of OpenGL boiler plate. I've used SFML but just to make Shaders and output some text.

[rleigh]

I think you're correct that the old GL API made it quick to get stuff working, but the modern GL is much nicer once you get past the overhead of setting up all the VBOs etc. That only needs doing once, and then you're set.

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.

[gugagore]

I hope it's not too off-topic, but I feel this sort of thing has happened before with developing GUI programs in Visual Basic, drawing to the screen with turtle graphics, (or instead whatever routines BASIC tended to have). Curious if others share the sentiment with other examples too.

[AnIdiotOnTheNet]

Oh yeah, totally. Maybe I'm looking at it with rose-colored glasses because I was younger, but the way I remember it personal computing used to be about enabling users. At some point there was this huge attitude shift towards being condescending toward users and treating them like cattle. So now, instead of trying to bridge the gap between computer "user" and computer "programmer", we forcibly drive a giant wedge between them.

[zozbot123]

The underlying issue is that many novice users don't see the problem with being condescended to, even when this severely inconveniences the more "developer-like" power users we used to enable. That "wedge" is just what the Eternal September of personal computing looks like.

[bartvbl]

I wrote a small booklet on modern OpenGL for the class I'm TA'ing:

https://github.com/bartvbl/A-Hitchhikers-Guide-to-OpenGL