Learn 3D Computer Graphics Programming from Scratch

Another free series: https://www.scratchapixel.com/

Wow, that's really good! Thanks

As usual, one cannot post anything money related on a startup oriented forum apparently.

To be fair, Handmade Hero is for a complete game with sound, effects, input, etc. This course looks to be focused on a realtime software renderer with the ability to read/write geometry and textures. HH is also a bit overwhelming.

I think what specific tutorial might go for depends on that individual's background and goals. I know a bunch of people who work in games/vfx who use tools like Maya/Houdini every day. They don't need a lot of help learning 3d concepts, but are interested to see the pros/cons of different implementations. They aren't always interested in realtime or optimizations. Here are the free resources that normally come up:

https://www.scratchapixel.com/ -- Learn Computer Graphics From Scratch!

https://raytracing.github.io/ -- Ray Tracing in One Weekend book series

https://github.com/ssloy/tinyrenderer/wiki -- tinyrenderer, tinyraycaster, tinyraytracer

http://www.pbr-book.org/ -- Physically Based Rendering 3rd edition full text. It looks like a 4th edition will be published in a few months.

https://learnopengl.com/ -- For learning modern OpenGL

Handmade Hero is a great learning resource: Casey is a an experienced guy and a good teacher. However, this course seems aimed at a different audience. Handmade hero is OpenGL, and this course specifically goes over things like CPU rasterizing, things that aren't touched when using a graphics API.

The videos are free. $15 gives you access to the source code and some extras like the art files. You can easily produce the exact same source code by following along.

Seems like this course is for understanding how vectors are translated into rasters. I guess it is single threaded. On the other hand, with normal graphics programming, where OpenGL or Direct X with GPU hardware does these things for us, execution is parallel. With this course we will get the fundamentals strong. Still for high quality light processing, ray tracing is the king. The course is good with this aspect. But you have to unlearn everything to avoid prejudice to get accustomed with the massively parallel GPU environment. That is the faster and economic way for real-time rasterization. That is a point of caution. Or rather an aspect to consider spending time on this non parallel algorithms. If this course discusses parallel things, cpu is only multi-core, not manycore like GPU, so cannot give real-time performance. However, I am assuming everything from the course-outline!

From what I could see in the table of contents, this is at a different level. Basically, this teaches you the concepts used to implement something like Vulkan. They probably implement a software Z-buffer, while a graphics card will do much of it in hardware.

To be honest, it's fairly specialized knowledge, though fundamental.

Usually graphics APIs abstract away these core concepts, but there's a lot of shifting responsibility between what you do and what the API/GPU does. It's good to have an idea what they're doing so you can better utilize the APIs, compare two different approaches, and often you'll find yourself hand-rolling aspects (like writing an exporter from something like Maya to be used in a realtime engine or converting Y-up data to Z-up data before sending it along).

This is fundamentals course, so you understand how DirectX or OpenGL work under the hood for example. That's how games in the 90's were written. If you are into oldschool graphics then it's a cool course. He has also raycasting courses and Atari graphics.

I can't speak to this tutorial specifically but I have done many opengl and directx tutorials over the years and some of the best took a api agnostic approach.

I would actually say that learning to implement a software rasterizer was less relevant in the days of fixed-function pipeline GPUs than it is today now that shaders are ubiquitous.

GPUs and graphics APIs used to have to implement a huge number of graphics features for you to get anything on the screen. You used to give the GPU your vertices that defined polygons, colors at each of those vertices, textures (and texture coordinates for each of the vertices) and few parameters to control some interpolation math, and then the GPU did everything to put them on the screen. Features like fog and lights and shadows all needed a specific function to perform them, and you didn't have a lot of control over how exactly it would work. If you wanted to do crazy stuff like non-Euclidean warping of space, you were basically not going to do that on the GPU.

Shaders were invented sometime in the late 80s (originally as a CPU-based rendering system, IIRC) but they didn't really hit the game industry until about 15 years ago, and it took some time after that for them to get popular, both for hardware to propagate in the market and because it was a pretty huge departure from before. The GPU does a lot less for you, now. Instead of giving you functions to specify numeric constants that control output, it gives you a block of memory and a space to run code to use that memory in a structured way. Whereas before you would give the GPU your projection and camera and model matrices and it would transform things for you, now it doesn't care how you define the transforms, you put whatever matrix or some other construct you want into memory and you do the math (well, at the algebraic level. You don't implement matrix multiplication) to transform the vertices. You want a light in the scene? The GPU doesn't even know what a light is anymore. Your "light" is a color and intensity value you load into the GPUs memory and then you write the code that figures out what color a lit polygon will be. It doesn't know what fog is, what shadows are, what bump/normal/displacement maps are, any of it. To the GPU, all of that stuff is just big blocks of numbers that it lets you run your own code over.

The GPU still has a black box function for converting polygons to pixels (or rather, fragments as they are now called, as they don't necessarily map 1-to-1 anymore). This is the strictest definition of "rasterizarion", but it's a small part of the whole process and a "software rasterizer" does a lot more than just rasterization. All of those things that aren't just figuring out pixel coverage of polygons, this are pretty much up to you, and learning to do it in a software rasterizer can be great for learning, because graphics APIs aren't exactly the nicest things to work with.

Even still, if you never end up writing shaders, I think there is a lot of good to learn in the process. You might find yourself in a situation where all you have is a 2D graphics library and you need to create 3D-looking effects, for generating static images or lighting up grids of LEDs connected to a microcontroller (both examples of places I've personally used the stuff I learned in college... 15 years ago).

As a loose analogy to a non-graphics topic, fixed-function pipeline GPUs were like SQL engines. They gave you declarative means of controlling state on the GPU. If what you wanted to do didn't have a function for it in the engine, you were in for a bad day. Programmable-pipeline GPUs are like Hadoop clusters. There is some data and you define some kind of pure function that map/reduce over it. It's more work for you for simple things, but it provides you the maximum flexibility to do creative things.

> What I don't miss are the days of thunking, marshalling, bank switching, and segmented memory.

Been thinking about this for a while. Why don't instruction sets define arrays at the hardware level? That seems to be where practically all the pain of memory management comes from - dynamically sized arrays (and 2D arrays i.e. matrices) that grow or shrink throughout the program's lifecycle. Why aren't `malloc` and `free` architecture-level instructions? Let the hardware worry about finding space within memory, it'll almost certainly be faster than any software algorithm. And if you can do that, can't you putdynamically sized arrays into the architecture as well? This solves so many software related problems. x86 is CISC so it's not like they bother with instruction count; is there something I'm missing? Has this been tried before? I know SIMD is something similar, but I don't think anything exists that tries to replace malloc/free.

Devices like the Pi and ESP32 are great starting points for that.

https://www.youtube.com/watch?v=Aw9cLeh3I_Y

Or any of the ic0nstrux (nee XGamesStation) offerings, of real console dev experience.

http://www.ic0nstrux.com/products/gaming-systems

I advise the HYDRA, if one can still get their hands on it.

I was not trying to sell his course when I submitted it. He actually has some free interesting courses if you don't want to pay the outrageous 19$

Well, it is a site originally created for people trying to start their business.