I find this very interesting. I have been toying around how I would design a graphics 101 course myself. Should it start with putpixel style sdl code like we did in the 90s? Or start with shadertoy? Of course basic matrix math is always important. But how to teach rasterizing a triangle? Can we skip to homogenous coordinates and quad trees without going through scan lines? Should we really teach Phong shading or can we move straight to BRDFs? Some parts might be teaching "old hacks" instead of relevant skills. Statistics and sampling are way more important today. I believe graphics is getting more "mathy" every year. So learn math, teach math.

I started with putting pixels in MCGA to CPU rasterize phong shaded triangles, and I don’t recommend it.

Instead, I’d recommend

https://learnopengl.com/ https://raytracing.github.io/books/RayTracingInOneWeekend.ht... https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-... https://foundationsofgameenginedev.com/ https://youtu.be/j-A0mwsJRmk

Though, if you really do want to put pixels, this is how you should do it: https://gist.github.com/CoryBloyd/6725bb78323bb1157ff8d4175d...

>No GPU, no OpenGL, no DirectX!

This is the opposite of what you would hope to see for learning graphics programming.

I feel like this comment perfectly captures the difference between programming and coding.

Programming comes from a place of first principles, the goal being to understand what is needed completely so that a solution that meets many parallel constraints can be constructed.

Coding comes from a place of completing a task, the goal being to get from the requirement to the operating task in as short a time as possible so that one might move on to the next task.

Both disciplines have value. The original question was unclear about where the author hoped to end up.

To put this in a slightly different perspective, a graphics programmer can write a program to show a shaded object on any platform with a CPU and a way to display graphics. A graphics coder can write a program to show a shaded object only on those platforms where they have previously mastered the APIs for generating display graphics.

Good comment, and, basically, I fully agree, except, I really dislike your attempt to appropriate the words "programming" and "coding" here. Like, can you just explain what you mean without trying to redefine terms that have broadly accepted definitions distinct from how you're trying to use them here?

(Sorry, this probably sounds more critical than I'm intending...)

No worries, got to use something as the holder of the definition. FWIW I read a similar essay that discussed cooks and chefs and came away seeing the many parallels with programming and coding.

Programming requires creative thinking. Coding, historically, was a lower-paid, unskilled position.

You may think this is redefinition. It's not. This is how both terms originated. A "coder" did the unskilled gruntwork of implementation for business projects, while a programmer was holistic.

> I find it bizarre that people now use the term "coding" to mean programming. For decades, we used the word "coding" for the work of low-level staff in a business programming team. The designer would write a detailed flow chart, then the "coders" would write code to implement the flow chart. This is quite different from what we did and do in the hacker community -- with us, one person designs the program and writes its code as a single activity. When I developed GNU programs, that was programming, but it was definitely not coding.

> Since I don't think the recent fad for "coding" is an improvement, I have decided not to adopt it. I don't use the term "coding", unless I am talking about a business programming team which has coders.

https://stallman.org/stallman-computing.html

In this case, it is you, and the wider cottage industry of business "coders" who are doing the appropriation. It's not your fault. The bootcamp or Super Cool Totally Serious College you likely learned from probably used the term "coder" alongside words like "rockstar!" You were given a bad definition, and never knew any better at all. ChuckMcM's comment, on the other hand, is correct. Using the word "literally" to mean "figuratively," while colloquial, is still less correct than figuratively.

The phrase "code monkey" is not a compliment, and didn't come from nowhere. It came directly from these pre-existing definitions.

Programming requires logic. If you are coding, the thinking's already been done for you. You are just doing unskilled labor akin to data entry to get the computer to actually follow the instructions.

Thing is that no one hires "coders" anymore, even if many people's jobs are in fact mostly coding instead of establishing the design. It's a weird stigma that translated to companies low key lying about what they really want out of an engineer.

It's a shame because there's a nice flow to coding once you got everything nailed down. Coders are no different from (human language) translators and like good localizers, a really good "coder" understands the subtleties of the language. If your application is concerned about scalability or performance or cross-compatibility, you aren't just googling an API and pasting in commands to get something working.

But I guess coding may not really be a thing in the next few decades if AI really does catch on.

I like the distinction, and I think there should exist different terms, but I don't think those two are nearly universal. Many people will use them interchangeably, others may even think other way around ("programming" as a professional discipline where you use tools to achieve an MVP most efficiently, vs "coding" as an enthusiastic activity that's more creative and open ended).

There is a lot to be said for understanding things from first principles, but not everyone wants to go that low. Not everyone is that nerdy or maybe hasn't the time or motivation.

The other issue is that not everyone learns well from the bottom up. I believe that top down is a much better way of learning anything, and lets you progressively get closer to first principles while not discouraging learners with a steep difficulty curve. But unfortunately is an approach that is seldom facilitated by anyone.

2D graphics with bitblits is a completely different paradigm. If you were using 2D GPUs from the 90s, or maybe a 2D Industrial PC's GPU, sure... Learning about Bitblits and rects is good.

But if your goal is to program a modern shader on a modern platform (even if it's a 2D graphic), you should learn a modern graphics library.

-------

A modern graphics API is laid out the way it is: to maximize modern performance on modern systems. A first principles bottom up approach will absolutely cover shaders (maybe compute shaders are easiest?)

There's a lot of leeway to learn 3D principles through a basic software rasterizer. It does not take long - if you already have some awareness of the math, it's at most a few weeks to work through the essentials from a tutorial. Once you get to the point where you're drawing filled triangles through a projected camera, you can move on. There's no need to go into occlusion culling strategies, texture mapping or lighting calculations, or really to make the rasterizer fast in any way. That wouldn't be the point of the exercise. It could be done entirely with a fixed-size bitmap and a setPixel(x, y, v) call.

The argument against "just" using the hardware is that the hardware resists learning that conceptual skeleton. Instead of learning how a rasterizer is implemented, you learn the specific API incantation to bring one up, and that has changed a lot over the years in the direction of being a more professionalized phenomenon, so now it's much easier to start application top-down, from within a premade rendering environment like a game engine or Blender's rasterizers.

Learning to work on production rendering engines would involve reading and studying existing implementations, reading the relevant research papers along the way.

> you learn the specific API incantation to bring one up

The graphics pipeline from geometry -> vertex shader -> pixel shader -> image is the damn point.

When the literal hardware is laid out in a certain way, you must learn that hardware layout and understand it. These API 'incantations' as you put it aren't high magic. They logically flow from the requirements of modern graphics programming.

If you just skip that stuff, you won't ever learn about modern GPUs, modern CPU->GPU data transfers, GPU parallelism or how a CPU calls the GPU routines to render.

Maybe you can make the argument that you should learn rasterizing first to simplify the learning process. But I would argue that it's easy enough to learn rasterizing when you get to the Pixel Shader step.

> The argument against "just" using the hardware is that the hardware resists learning that conceptual skeleton. Instead of learning how a rasterizer is implemented, you learn the specific API incantation to bring one up, and that has changed a lot over the years in the direction of being a more professionalized phenomenon, so now it's much easier to start application top-down, from within a premade rendering environment like a game engine or Blender's rasterizers.

The argument against that is that you eventually have to learn today's hardware anyway. So you might as well start now.

Tomorrow's hardware is based on today's hardware. And today's hardware is based on yesterday's hardware.

It's all incremental progress. I'd personally say that OpenGL with GLSL might kinda sorta look like modern stuff (vertex and pixel shaders), but anything older (ex: 90s BitBlits) is so old it's just completely a waste of time.

Your definitions are made up.

Programming refers to the act of writing a program for a computer to follow.

Coding refers to the act of writing code for a computer.

Edit: The definitions are not commonly used this way and in fact I've heard other people even give opposite definitions to what correponds to which word.

Hate to break it to you, but all definitions are made up. The question is whether or not the distinction is useful or not. In my opinion, it seems useful to distinguish between understanding oriented tasks and goal oriented tasks.

Personally... I disagree. The course says:

> You'll learn how a software 3D engine works under the hood, and ... write a complete software rasterizer from scratch

Writing a software rasteriser is a fantastic way to learn the classic graphics pipeline, Every single aspect of said pipeline offers scope for one to learn more about how GPUs work, and the algorithms behind them. This would be immensely educational to a new graphics developer.

Vertex processing, including fast, efficient file parsing, vertex data layout and storage, and optimisation.

Fast primitive assembly from vertices, including line-drawing and interpolation algorithms.

Texture mipmapping, and mapping.

The rasterisation phase itself offers tons of opportunity, from Bresenham's line drawing algorithm to supersampling, tiled rendering, parallelisation, and efficient memory layouts for cache locality.

Clipping, culling, hidden-surface removal, z-buffering, and stencil tests.

Various other algorithms that are taken for granted with a pre-existing graphics pipeline, like texture lookup, vector reflection, environment mapping.

Post-processing and miscellaneous algorithms like anisotropic filtering, multi-sample anti-aliasing, temporal anti-aliasing, and even deferred rendering.

If you want to learn webdev you don't start by building a web browser despite the fact that building a web browser would teach you a lot.

Web dev is sufficiently abstracted from the browser and the hardware that a skilled web developer doesn't really need to know the internals of the V8 engine or how a browser works. A web back-end developer probably doesn't need to deal with the browser at all.

Graphics programming skill (by 'skill', I mean being able to write a shader pipeline that both satisfies the art direction and performs well), on the contrary, is very deeply tied to a good understanding of hardware. Especially now that the new APIs (Vulkan, Metal, D3D12) are purposely less abstracted than their predecessors.

All programmers at a certain level must understand the lower levels of the stack they are building upon. I think most people can get by with just learning the abstractions that are provided to them. With time people can learn more and more about lower levels as they specialize. Most people who become graphics programmers don't need to know the low levels of how a GPU works, so I personally do not think that is a good place to start for people who want to get into graphics programming.

Are you a graphics programmer, or are you just saying this because that's true in the CPU world (where you have experience)? From both my own and my colleagues' experiences, I would 100% disagree: the nature of GPU architectures means you are forced to deal with super low-level details from the very beginning. Part of this is because graphics (and GPGPU compute) programming is inherently performance-constrained: if it wasn't, you could just do your work on the CPU with much less of a headache. Even just generally though, the path to running code on a GPU is much simpler — the hardware does less work for the programmer, there's no operating system to manage threads, everything's a single binary, etc. — which means that there's less to insulate you from what's underneath.

>Are you a graphics programmer, or are you just saying this because that's true in the CPU world (where you have experience)

Neither.

>the nature of GPU architectures means you are forced to deal with super low-level details from the very beginning.

Not everyone is trying to push the hardware to its limits by making the best thing possible with the hardware. Plenty of projects can get along fine with a A/AA renderer or with unoptimized shaders.

>there's no operating system to manage threads

There literally is. Or if you disagree the firmware manages the threads.

>Graphics programming skill (by 'skill', I mean being able to write a shader pipeline that both satisfies the art direction and performs well), on the contrary, is very deeply tied to a good understanding of hardware.

I'm not entirely sure I agree in the modern day sense. Especially if our analouge is webdev. So much of industry is using UE and Unity that you probably can be a "graphics programmer" professionally without ever knowing what a vertex buffer is (only slightly exaggerating). Your ultimate job is either to a) make images look better b) make images run faster or c) make sure images can get put into the engine properly. And a high level understanding and implentation of shaders/texturing concepts and understanding which settings run slower on those engines (even if you can't explain them in detail) can get you pretty far in those regards.

you're certainly SOL once you move out of your engine of choice, but you can definiely be productive enough to get hired if you got a foot in the door.

A more realistic comparison for webdev is using plain JS vs using frameworks.

I disagree. It's good to understand what the GPU is doing at scale before jumping in too deep. It's obviously not how you do your day-to-day work, but it helps you understand what's going on at a deeper level.

Agreed. I've seen beginners fall into the trap of spending way too much time on software rendering that won't be useful or performant later because every platform they'll ever develop for has hardware accelerated rendering. I learned how to painstakingly render scenes pixel by pixel and then had to unlearn it because graphics programming doesn't work that way anymore.

Teaching beginners to render graphics without the GPU is like teaching them to do fractional math without the FPU. It won't make their first project better and gives them the wrong idea of what to expect.

>> No GPU, no OpenGL, no DirectX!

> This is the opposite of what you would hope to see for learning graphics programming.

It is exactly what you would hope to see.

And I would dare say I'm a graphics programmer, mostly self taught.

When I started, as a teenager, in the late 80's, there were no GPUs. So I learned everything from first principles. I recall implementing Bresenham in x86 assembly for my CGA card. And then, as a follow up, rasterizing a triangle. You really had to understand stuff end-to-end then as the hardware was so slow. I.e. even C was too slow for that stuff.

And today, still, the best offline renderers, that produce the images you see on the big screen, are CPU-only. 100% custom code, no 3rd party API dependency.[1]

If you write stuff for CAD/CAM/CAE/VFX, there is a big chance you do not think about the constraints of a GPU and less so of one of the APIs used to program it. Except for previewing stuff.

I would suggest to anyone learning graphics programming (or anything else for that matter) to do so from first principles.

GPUs are specialized hardware for realtime applications. That is very specific. I don't say don't learn that. But I suggest to not start with it.

[1] One of my best friends is the lead developer of the 3Delight renderer.

My little spot of nuance on this reply would be that the point of starting in software would not be to aim for a fast or feature-rich implementation. That seems to be the sticking point of the replies in favor of going hardware-first - that "we don't optimize the same way anymore". But nobody was asking about optimizing! People seem to go performance-brained when they talk about graphics because they read about John Carmack once. Then they go right back to their Javascript frameworks.

Like any student engineering project, "baby's first rasterizer" would emphasize a combination of concepts and motions - a path to take, to get to a result that can be tested. We don't even have to use Bresenham now - deriving the rasterized line from linear interpolation is mathematically more sound and no sweat for modern CPUs. But it might be pedagogically useful to compare the two to explain quality vs performance tradeoffs, ones that were made historically and those that are still in use today.

It's what my graphics courses in my computer science degree did. The skills I learned have benefitted me long after (20 years), and I mostly "just" do web development.

Believe it or not, we were doing graphics without any of those things a very long time ago. Learning fundamentals is really important. You can always learn easier ways to do things later.

For example, area fill algorithms are really interesting. Etc.

Just wanted to second this recommendation. I did the course a few months ago with near-zero baseline in graphics programming (though a few years' experience as a standard swe), and it gave me a pretty decent grasp of how 3d shapes get drawn on the screen. Afterwards I was able to pick up webgpu in a matter of days, which I don't think would've been possible without the understanding I gained from the course.

If anyone's looking for motivation, I made a wasm-compiled demo of the renderer you produce by the end - https://rmshin.github.io/3d-renderer-wasm

There are a couple of excellent resources out there for implementing 3D rendering from scratch.

On that I cannot recommend enough is this github repo:

https://github.com/ssloy/tinyrenderer/wiki/Lesson-0:-getting...

If you are more of a visual learner, this guy is also a treasure trove:

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

Wow, that first link is fantastic, thanks for sharing!

My website/book/course does the same thing, and it's freeeeeee! https://www.gabrielgambetta.com/computer-graphics-from-scrat...

I have your book. It's a great read but I would not say it's "the same thing." :)

People pay for a specific teaching style and that's absolutely fine.

nothing wrong with seeing if the freeeee alternative works better before throwing out $70 tho.

Of course. Still, I thought it was worth clarifying that they are different so we don't automatically discourage people from trying out good content.

Oh, absolutely. I meant "the same" in the sense that it covers roughly the same material and follows roughly the same approach (building everything from putPixel()).