It includes code for 3D model loading, linear algebra, basic (OpenGL) rendering, and UX, and provides stubs for you to implement:
- local geometry operations (ex: edge split,
vertex/edge/face bevel, vertex/edge/face delete, etc)
- global geometry operations (ex: upsampling via catmull
clark subdivision, downsampling using quadric error, etc)
- a path tracer that supports Diffuse/Mirror/Glass
materials with Fresnel reflections and environment
lighting (ex: you can render the cornell box)
- an animation suite that implements skinning, spline
interpolation, and basic simulation (wave sims)
For something a bit more modern, I'd recommend , 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 , 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  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.
The students have to have citations to the docs if they went to help on a certain line of code. I wonder if that is normal these days.
I don't think it means if you call SDL_CreateWindow, if that's what you mean with "on a certain line of code", but if you were to for example implement a window creation function by copying the contents of SDL_CreateWindow and adapting it.
EDIT: Citing everything is extra important when working on projects for courses, because even when its overzealous in terms of what is legal the point of doing the work is to show that you understand the concepts properly, and then its important for whomever going through your code to be able to tell which bits you actually worked on.
Why is someone reading this tutorial in the first place? It's likely because they have some end goal in mind, and are looking to get from 0 to that goal as quickly as possible. For most readers, this is probably making a game. Following the advice of this guide will give the reader a deep understanding of how 3d graphics works, but it won't bring them much closer to making a game than they were when they started.
Why am I bothering to point this out? Because countless guides like this exist that confuse neophytes into believing that the subject they wish to learn is difficult and requires learning countless prerequisites before they can get started tangibly moving towards their goal. It's demotivating. A lot of the knowledge in this guide is good to know but ultimately not immediately relevant to someone seeking to achieve some higher level graphics goal. It feels like the equivalent of trying to teach someone programming by starting them at assembly.
I personally think that this guide should be directed towards someone who has had experience noodling around with OpenGL or a game engine and wants to reach the next level. In order for any of the lessons this guide wishes to teach to be impactful, the reader needs the necessary context to understand why learning them is relevant to 3d graphics and by extension the reader's end goal. Starting off by making a ray tracer is a cool idea for example, but does the author honestly believe that it's more useful than just learning OpenGL first? It might be more "confusing", but they're going to have to learn OpenGL (or some game engine) at some point whether they want to or not if their goal is to make a game.
If “graphics programming” is implementing the rendering engine for the game (recall his final goal is “draw a triangle”), I believe his point is that it’s easier to learn the required APIs for that if you understand the concepts behind them first (rather than just leaping into meaningless copypasta), and the best way to learn those concepts is to work with them directly.
No other tooling needed until you've got the basics of vertex buffers and shaders down.
(20 year graphics veteran here who's boostrapped some coworkers)
I recommend reversing that - ignore the math and just get a triangle on screen using a trivial shader (takes a few dozen lines of code in WebGL), then learn about how shaders and matrices work by applying them to your triangle.
I know some would say it's a bad language, but back in the day it was incredibly accessible and spawned a lot of shared code and tutorials. If you focus on the techniques and algorithms, treat the language as pseudocode rather than "the right way to do things", you can have a lot of fun and learn quickly things you can translate to whatever your language of choice is.
That really isn't how modern, accelerated graphics works - even 2D accelerated graphics! "Sprites" are slightly closer to the mark, but it goes far beyond that.
All that happens on the fly without intermediary frame buffer composition in between. The output goes directly to the display (over HDMI, eDP/displayport, DVI, etc.).
Yeah, and of course mouse cursor is a sprite in the traditional sense. Although on modern HW you could implement mouse cursor as a hardware layer.
C64, Amiga, MSX, NES, SNES, Sega Master System, etc. all supported hardware layer sprites back in the eighties.
I'd say, a good way to do it, is first learn theory, and apply it using simple tools that let you just draw on screen (like SDL). Then learn a GPU targeted API.
I spent a while getting an OpenGL environment setup in VisualStudio and got frustrated with the tooling as I've also been spending much of the last 3 years doing trivial web development. I ran across shadertoy and was able to whip up much of the core of the pathtracer there and very easily move it over to it's own project supper easily utilising REGL (https://github.com/regl-project/regl) in ~100 lines that included a camera, dynamic shader compilation based on a scene, etc...
The book starts with little more than plotting a pixel on the screen. By the end you'll have a complete lit, shaded, 3D game engine that you've written entirely from scratch. And in the process you will learn absolutely everything that goes into it.
And one thing I'd add is that this might sound somewhat overwhelming but it's really not. The book is extremely well written and clearly was a labor of love. If you get some pleasure out of math and code, you'll have no technical troubles working your way through the book and in the end will be rewarded with an intimate, flexible understanding of graphics development that won't be hamstrung by dependence on a specific API.
 - https://www.amazon.com/Tricks-Programming-Gurus-Advanced-Gra...
I've crawled through more topics than I can list here. Many of them were not easy to learn, due to disorganized learning resources and materials.
Documentation and information is scattered, frequently outdated, sometimes sparse, and just downright messy. OpenGL and its many quirks and legacy versions muddy the waters too. I've considered trying to pull this into one big guide, hopefully resulting in something like the Filament docs .
Side note: macOS (my dev env) is a terrible place to write OpenGL, I've learned. Debugging tools are practically non-existent.
At any rate, at the end we built our own raytracer, and say a text file with vertices that was given to us produce an image on the screen from 100% code that we'd written ourselves. It was one of the most empowering, deep intellectual experiences I've ever had.
It's free but please consider donating if you find it useful.
For ray tracing Peter Shirleys books are very good.
OpenGL stuff are usually found at docs.gl, https://learnopengl.com/About.
For Physically Based Rendering (PBR) material checkout the bool Real-time Rendering and all the cool stuff has been coming out of Siggraph these past years, https://blog.selfshadow.com/publications/s2013-shading-cours....
If you can, go take an elementary linear algebra course or prepare to spend time studying these. It is well worth it.
One thing I have found when hacking on my own engine (see here: https://github.com/Entalpi/MeineKraft) is that graphics APIs (especially OpenGL) can have a lot of hidden meanings or even old names still being used, etc. Try to find out how the API evolved and get the reasoning behind the design decisions. This way it makes more sense and it gets a bit easier to learn.
On my YouTube channel, I have over 100 WebGL Tutorial videos, and over 50 3d math related videos.
msg += android.opengl.GLU.gluErrorString(error);
TIL "advice" can be countable: https://blog.oxforddictionaries.com/2014/05/30/advise-advice...
> Advice is mainly used with the first meaning, and in this meaning it is a mass noun (that is, it has no plural). The business/legal meaning, however, is a count noun: it has a plural form, advices.
This will give you human readable error messages (as in complete sentences of what went wrong) as well as some other info to pinpoint what went wrong and where.
Additionally, it's a good idea to use Renderdoc  or your $GPU_VENDOR's debugging and profiling tools.
Also, Apress has a cool book about Python and graphics with some pretty intense source code found here:
It in python, doesn’t involve matrices. It really only requires high school math, with the exception of the z axis.
Hope it’s helpful!
So far I really like the way it's written: everything is test-based, so you get a problem like: "given matrix X and vector Y, X * Y should be vector Z" and then you implement both the test and the code in whatever language you like.
Computer graphics is more about producing an image on a computer screen and whether it's for image processing or a game engine renderer it's the same process and very useful to know whichever field you want to pursue.
There's a lot of room to do things incorrectly and not notice in audio, which makes it forgiving to learn: e.g. playing a sample at a different pitch can be done badly by adding or removing arbitrary samples, but resampling it with minimal distortion is actually a fairly intensive DSP problem. Or when computing a volume, the linear amplitude usually isn't the parameter you want to work with(see every UI where volume changes imperceptibly until you reach the bottom 10% of the slider), and while there are computations to convert between linear and dB values, you still have to qualify it with one of these various references and suffixes. There's a lot of crossover between audio and electrical signal terminology that can make it hard to follow this material.
So you can spend a lot of time doing simple things well!
It's fairly heavy going, but very comprehensive.
I didn't assume a particular mathematical background for the students, so I introduced the relevant math in what I hope was a motivated way. Hopefully it can help others as well.
I was pleasantly surprised by how easy it was to compute the pixels, but getting them on the screen was a huge hassle. So I wrote https://gitlab.com/kragen/bubbleos/tree/master/yeso to make it trivial. I haven't ported a raytracer to it yet; I'll do that soon!
It might be more appropriate today to work top down. Install Unreal Engine, build a simple demo, and look at the code it generated and you can modify.
I'm a web guy, so all I know is frameworks (Angular, React, etc.).
One of the things I appreciated about the Glide3D API for the old VooDoo cards back in the day was how basic it was relative to the work of getting the 3D stuff on the screen.
There are several ways in which you can "learn" 3D graphics; You can get it by theory, you can get it by API, and you can get it by modelling.
If you're someone who is a theory person you should start at the beginning and learn linear algebra and vector arithmetic. You can learn about projections, and camera "views" and project your 3D scene onto a 2D surface whether it is a computer screen or a plotter page. Once you get there you can then do hidden line, and then hidden surface removal. You can learn about the 'Z' plane and the clipping frustrum which lets you not worry about things that won't appear in your projection. With a relatively simple array of coordinates type data structure you can project triangles or NURBs onto your surface and draw pretty pictures. Then you can start learning about light and all the many ways it interacts with materials. At the end of this journey you can take a 3D model and render it in a photorealistic way, one frame at a time.
The second way to learn 3D programming is the API path. Here you don't really learn too much of the math, although having that background will help you understand what the functions are doing. You learn an API like Unity or Vulkan. These APIs have taken a lot the basic 3D programming and done it for you, you need to learn how to write shaders which decorate your surfaces in ways that simulate light or water or fog Etc. Generally you construct a scene with calls to set up the frame, and then call 'render' with the appropriate screen resource referenced. Blam! instant 3D scene.
The third way you might come at this is modelling things, building models in Maya or some other modelling tool that are built with skeletons, which is simply a data structure that identifies how different parts of the model can move in relation to other parts. You probably don't have to know anything about 3D math, but you have to have a good eye for construction of the models and the area in which those models are placed.
There are so many ways to go at this particular quest, each have their own challenges and rewards.
By modern I mean as in OpenGL 4.5 Core Profile, using future-oriented APIs (e.g. named buffers). Any feedback welcome!
As far as true 3D graphics, I made a Minecraft clone using OpenGL... it was a nice project as, surprisingly, you end up using all the basic techniques as you tweak it, particularly when you try to get lighting and shadows working.
There is a free intro to data science class on Udacity as well:
Lastly, there's always Kaggle, which has plenty of resources to learn from, and competitions as well:
And one more gold standard for more practical data science (with R) stuff. It introduces a more modern take on R (chaining functions together with the %>% pipe operator, which makes everything clean and terse).
Data Scientist path - https://www.dataquest.io/path/data-scientist
Some of the projects peppered throughout the track: https://www.dataquest.io/projects
EDIT: Forgot to mention, almost every lesson uses a real dataset!