How do I become a graphics programmer?

I would suggest that beginners not lead with "which tools should I capitalize on" and instead, take a step back and ask "what do I want to make"? Don't lose focus on the final output as you make your first steps. In the world of computer graphics today there are so many tools that abstract away various steps in the process of drawing pixels to the screen that you could very easily waste too much time suffering with low level code up-front and then later realize that the niche field in the wide array of industries that utilize graphics programming that you want to pursue actually only hires people who use Unity, TouchDesigner, threejs, and after effects and don't actually write a lick of C++ unless push comes to shove, and even then they might just contract an outside engineer for it.

Not to say that learning how things work on the ground level isn't immeasureably valuable, but I think trying to do that first is the slow approach. Learning is accelerated when 1) you enter the industry (so you should prioritize output up-front and let the deeper learning happen when you're earning a paycheck for it) and 2) you get a better conceptual understanding of what's happening under the hood offered by tools of abstraction like a game engine or visual programming paradigm.

This comes from someone who spent many years trying to learn cpp and opengl the hard way only to endure a long battle against an internal sunk cost fallacy I've harbored that kept me from taking the no-code approach. Don't waste your time taking this path if it doesn't help you make what you actually want to be making at the end of the day.

Listen to this guy, great advice. Early in my career, I set out to become an "OpenGL expert" and I'd say I mostly got there. I mean I'm no Mark Kilgard and haven't written any textbooks, but I dove super deep into the technology, and gained at least a decade of experience working on all levels of the API from the driver level to conformance tests and performance tuning, up the stack to game and application code, and across each major desktop and mobile platform.

Where did it get me? Not very far, really. First of all, almost nobody cares about OpenGL anymore--it's kind of dead with the two major OS vendors finally abandoning it. Go to any "HN Who's Hiring" and text search for OpenGL. Sure, I could have gone and re-skilled and learned another similar graphics API, but the second problem is nobody really needs people who write low-level Direct3D or Vulkan or Metal anymore because that's all abstracted for you by engines. And there are max 5 or 6 companies in the world that even have the need for people who can do low-level graphics drivers. It's a career-limiting niche.

The smaller the piece of the machine you focus on, the more of a world-class expert you need to become in order to make it your whole career. So, unless your plan includes becoming the next John Carmack or something, I'd recommend going broad rather than deep.

I feel like better expertise targets tend to be more durable. In other words, rather than expert in a specific technology or technique, the best experts had the ability to develop expertise in any given technology within a space and often overlapped cursory knowledge with other spaces. I met plenty of graphics experts at Oculus and they didn’t care so much about whether it was D3D or Vulkan - originally they were D3D engineers for PCVR and then a good chunk of them shifted to Vulkan once the focus shifted to mobile VR. They just knew how those APIs mapped to the actual HW reality, how things connected, why things were slow, how to improve performance, etc. The mundane stuff of “what is the sequence of steps to do X in Vulkan” is answered by Google/StackOverflow (or even these days ChatGPT). Heck, a good chunk of them were creating their own new APIs. This isn’t unique to Meta by the way. It’s like engineers who say they’re “C” or “C++ experts”. With the exception of authors like Scott Meyers or people working on the C++ language spec who I think can truly maybe claim that title, the kind of thing that is called a “language X expert” is the kind of expertise that a good engineer should be able to develop in any language with 2-3 years of practice and proficient mastery within ~3-12 months because the true expertise is the underlying CS principles (at least for a family of languages - I’ve never done too much with non-Algol families so I don’t know how I’d fare there).

However, I do agree that generally graphics engineer is a niche limited to the few people working on gaming engines, VR R&D, or animation R&D. But those skills, at least today, are generally transferable to AI engineering because GPU compute plays such a huge role. There’s less graphics programming of course and the APIs for GPU compute are a bit different, but AFAIK many of the hardware concepts remain (e.g. wavefronts, how GPUs do threading, etc etc).

When people like Bjarne Stroustoup, Herb Suttter, Andrei Alexandrescu say they are by no means a C++ expert, always beware of anyone that says otherwise.

Same applies to most languages, unless they are talking about toy languages.

Even something like C or Go, have so much room to debunk such experts. Between compilers, versions, language evolution, runtime, standard library, OS specific behaviours,....

When people like Bjarne Stroustoup, Herb Suttter, Andrei Alexandrescu say they are by no means a C++ expert,

Then you know something is deeply wrong with C++. If even they aren’t experts, that just means the language, despite being a human made artifact meant to encode human thought, is beyond human comprehension.

That’s kind of a problem, isn’t it?

While it is kind of fun bashing C++, I also noted "Even something like C or Go, have so much room to debunk such experts. Between compilers, versions, language evolution, runtime, standard library, OS specific behaviours,....".

Anyone that thinks otherwise, we can arrange a pub Quizz in Germany, I get the questions, audience has to give up any kind of device with Internet connection.

Many times when someone says "X-lang", they actually mean the entire ecosystem, practices, third party libraries… And for anything popular enough it is indeed impossible to be an expert in all of that. With C++ that’s still the case even if "C++" only means the language itself.

I’ll concede that C with the insane breadth and (over)reach of UB, is closer to C++ than I would like. And that’s a problem too.

I don’t know Go well enough to judge.

We can start with level 1 questions, "name which version where this feature came to be".

Okay, you could… and if you’re honest enough to accept answers like "it’s over 20 years old" I guess any expert could answer that. My main point remains though: if even Stroustrup or Stutter can’t answer 95%+ questions of this kind, it would show beyond a doubt that C++’s complexity got completely out of hand.

Even Stroustrup’s humble bragging about being a "7" at C++ looks real bad. If I’m not a 10 at a language I created and maintained my whole life, I’ve birthed a monster.

My example question was actually in regards to Go, made public in 2009, with 14 years of history.

The bonus round of the same question would be, "name one feature that was removed before 1.0".

We could make this question even more fun, if taking into account gccgo specific extensions, or runtime changes as well.

To put it bluntly, if someone shows up calling themselves an expert, I expect World Cup skills towards the language they are an expert on, across all levels.

While it may not be strictly correct semantically, I'd expect most people to understand "Go expert" as "expert Go programmer", not as some sort of Go historian.

I get the overall point, but this humility makes it difficult to use some kind of grading/levels.

Take e.g. MS Office as an example of a large C++ project. Certainly, there are developers with just "average" knowledge of C++ working there. Then there are people having strong/advanced C++ knowledge.

But in a project like MS Office there are certainly devs who are still much stronger in the language, best in the project/company, but still likely below people like Stroustoup or Alexandrescu. How to call those? I think avoiding the term "expert" just to be consistent with the above-mentioned humility is impractical.

Humility regarding on how much one actually knows, is a common trait in senior developers.

So when one sells themselves as über expert, that is already a kind of red flag.

I'll join the choir and say to not ever try to become an OpenGL expert. It's deep and kind of useless. First of all, if your application use OpenGL, either:

- you've unlimited resources for testing and vetting drivers, and you're working for huge CAO software that can tell users what to use.

- you don't have huge resources and then your only hope if to use an abstracted API like Skia, GDI, bgfx, IGL, WebGPU, anything other than using OpenGL directly.

It will just never work everywhere if you use OpenGL directly, and you won't be able to debug the driver or find all OS x drivers x GPU combination you need to debug it.

Your OpenGL-specific skills (avoiding driver bugs) will have very little value, but 3D-specific skills could. It's a waste of time that is only rivalled by learning C++. I would concentrate on abstracted API that avoid those driver bugs, or even learning a game engine to stay topdown.

This is something that those arguing for OpenGL as a kind of universal 3D API never get, the amount of code paths can scale to the point that it is like using multiple 3D that just happen to be all called OpenGL.

Going broad rather than deep cuts both ways. Sure, you have more employment opportunities, but the value of your individual contributions has a ceiling. That means after a relatively short period of time, you plateau career wise. Like is a generalist with 15 years of experience really that much more valuable than one with 7 years? Not really. So if you want to progress beyond a generic senior engineer, then you need to specialize in something.

But how many of those deep specialists got there by rationally weighing pros and cons and then picking a strategy?

My guess would be that for every example who got there on the curriculum drawing board, there are at least two who just happened to be in the right place at the time the technology grew, four who got infatuated with "their" technology so much they'd specialize no matter the pay relative to generalists, and eight would-be generalists who failed to keep their generalization in balance through a sequence of projects built on top of the experience of those before.

GP mentioned Carmack, that outlier of outliers. He did not get there by picking one technology and burying himself deep, he did whatever was practical. At the time IrisGL begat OpenGL, Carmack was battling the limitations of EGA and CGA in the Commander Keen series and then moved on to create the 2.5D wonders that followed. But he was more than ready to retire his world class expertise in software rendering when OpenGL came into reach of PC hardware. Textbook generalist behavior.

But without people like you (who understands the low-level graphics programming), the development of engine will completely stagnate.

It's a career-limiting niche.

This depends on your career aspiration. There are not as many companies hiring graphics programmers as there are shops who need "front end" or whatever they call scripting web pages nowadays but the barrier to entry is rather high so there are plenty of jobs in every FAANG plus Microsoft, Tesla, self-driving shops (I even have been approached by self-flying robots startups couple of times), training (from military to oil rigs), of course, the every game studio (which may or may not pay little and force you to work overtime, I am pretty sure a graphics programmer at, say, Roblox has better compensation and working condition than a front-end developer at Amazon, for example), and yes, the 5 or 6 companies that need drivers (Apple, NVidia, AMD, Qualcomm, Samsung, ARM, Intel, etc).

That's pretty sad. Without people like you, the engines all the others use would not exist. It always saddens me to see people making millions off of high level tools while the people who made it possible get limited returns.

Focusing on a single technology never was a great idea though. Even already towards the end of the 90's D3D was the better choice on Windows, so one had to write code against multiple 3D APIs anyway. This also gives a better perspective where the strengths and weaknesses of the different technologies are and it makes it easier to learn new APIs. But in the end, 3D APIs are just a utility to write applications (mostly games), not to build one's career upon. 3D APIs come and go and are (to some degree) also subject to fashion cycles, the underlying GPU hardware develops a lot more predictable than 3D APIs (e.g. especially Vulkan had pretty bad "mood swings" recently).

Of course when focusing strictly on money and "career growth", going into game development is a pretty bad idea to begin with ;)

> Sure, I could have gone and re-skilled and learned another similar graphics API, but the second problem is nobody really needs people who write low-level Direct3D or Vulkan or Metal anymore because that's all abstracted for you by engines. And there are max 5 or 6 companies in the world that even have the need for people who can do low-level graphics drivers. It's a career-limiting niche.

I did that for a living and can only agree partially.

First, the part were we agree: only a handful of companies hire graphics driver developers. This means that if this is your career you need to be willing to either put up with the idiosyncrasies of your employer or be willing to move geographically. As a result, people tend to stick to the same employer for many years.

As for OpenGL becoming obsolete, it's like anything else in tech: you need to keep up with whatever is in demand. Vulkan/Metal/DX12 didn't appear out of thin air, they were created by the exact same folks who worked on older APIs for many years, so it really wasn't a huge paradigm shift for driver developers.

GPU driver development is a perfectly valid career choice with good job stability and very decent pay.

What I disliked about it is that, perhaps contrary to what you are saying, I felt that it was rather repetitive and after having worked on a few different GPU generations. Innovation happens in other areas like GPU architecture, not in driver development, but that's a topic for another day.

Well, as someone looking to get into this field, I kind of disagree. A lot (if not all) job postings about graphics programming require you to know C++ beforehand. Sure, you can have another role, like gameplay programmer, and slowly work your way in graphics, and it's probably easier to do so, but in fine, for the graphics programmer role, C++ is required.

What you are describing is more about someone who wants to be productive with graphical stuff fast, but it's not graphics programming.

First learn the foundations, then the language.

When I started, graphics programming was all about Assembly.

Then it was about Object Pascal and C, then it was about C++, now it also requires C#.

And who knows, maybe in 20 years, one of the C++ wannabe replacements manages to also have a spot, or some AI driven thingie.

Those will solid foundations in graphics programming algorithms, will manage regardless of the language.

now it also requires C#.

For Unity games? What else? Just curious. I’ve been doing graphics programming for decades, and C# has never been part of it, and still isn’t on my radar.

Yes, plenty of Unity shops, and most of the companies doing VR/AR are using Unity.

Not only Unity, Capcom has their own C# toolchain.

One example of a Capcom game that makes use of it is Devil May Cry for PlayStation 5.

Unreal build system is based in C#, although here is a minor role, and naturally debatable.

People shouldn't be disillusioned though when they find out that there's not such a big need for the traditional role of graphics programmer who wrestles directly with lighting models in shader code and shadow rendering implementations. 95% (or so) of game industry jobs is plumbing engine-provided components together, writing some very high level gameplay code and maybe a bit of inhouse tools development. The hard rendering tasks are done by a handful engines now, and currently the pendulum seems to swing away from inhouse engines towards UE5 again.

But how does one become one of those engine developers?

https://engine-programming.github.io/

There’s two or three strands of graphics programming though:

Plumbing - Delivering data efficiently from the game engine to the GPU often in a platform agnostic way with efficient implementations underneath.

Art Pipeline - Delivering data efficiently from the artist tools to the game engine.

GPU Programming - Creating visual effects, shaders, compute shaders and tools around these to empower artists.

All of these use multiple languages, sure C++ is a common one and good to know (likewise as a gameplay programmer) but the bigger percentage of what you need to know as a graphics programmer isn’t how to write C++ but the concepts you’re trying to implement with it.

There’s also R&D but it’s a much smaller part of things.

but it’s not graphics programming.

As someone who’s been in the field for a long time, I kind of disagree. Game engine jobs don’t define the boundaries of what “graphics programming” means. That is a very narrow and specific kind of graphics programming, and there’s lots more graphics programming than just games. I’d probably even recommend people wanting to do games graphics programming to start outside of games, because the engine consolidation with Unity and Unreal has brought with it an overall reduction in the number of people doing graphics programming for games. There’s indie games and a few studios that still do their own engines, but there are a bunch of other industries that hire graphics, for film and effects, for 3d tools, for visualization, for mobile/web/desktop applications, for science & research, for VR/AR, for industrial applications, etc., etc.

Being fluent in C++ can only help you, so do work on that. Games engines need more and more people who can do ray tracing and neural nets, and some of the old guard of raster API experts didn’t learn as much about those things, so that is one angle of attack for getting in. Another is to be very fluent in the math of graphics, and you can learn and practice that in any language, and find non-games jobs that will pay for it. Math experts are generally more valuable and hard to find than API experts.

FWIW, my path was graphics in school, undergrad + MS, then scientific visualization for a university, then C programming for a CG movie studio, then I was hired to do games engine graphics programming (precisely what you’re talking about) and I moved into a tools generalist and gameplay lead role instead (which was more fun than wrangling shader compilation), then I went to a web app company and did 2d graphics while learning JavaScript & WebGL, then started my own web app company using javascript & WebGL, and then switched to doing CUDA and ray tracing with OptiX. Along the way, lots of fun graphics projects in Python. All of this involved real “graphics programming”, and almost all of it is outside the boundary line you drew. I say this not for argument’s sake, but to ideally give you more hope, and to help you & others see there’s a wider range of options to get into game graphics than ‘learn C++ & DX’.

This is the classic trap that new developers step in all the time. It's not just associated with graphics programming.

Youtube is full of beginner programming videos that take the developer through a journey of learning a stack of technologies in stead of focusing on something interesting to build. You end up with a lot of cargo-culting, and these massively complex Ruby Goldberg contraptions to render some text on a web-page. All in the name of padding out that CV.

When I was in university I dabbled with some graphics programming for a semester, and I found it was sufficiently complex that the only reasonable answer to "what do I want to make" was "render a green triangle on a black background". Going from there to square, to cube, to sphere, to animated sphere, to bouncing ball, is a logical progression and it helps you stay focussed on the prize. So don't also make the mistake of answering the above question with "first person shooter with ray-traced lighting and subsurface scattering".

I can promise you the first iteration of a bouncing ball will be truly horrible code. But that's fine. Over time you'll figure out how to optimise and improve things. And let me tell you, there's nothing as invigorating as discovering a design pattern by yourself: reading a book on a new topic and going "hey I'm already doing that!"

Tangent:

And if you then tell about the pattern/technique/architecture etc. to someone who’s been around for a while:

„Well, we already did that in the 80‘s, it was called Foobar. We just had to do it barefeet in the snow with our hands tied to the back.“

I agree with your suggestion to focus on what you want to create rather than immediately diving into specific tools. It's important to keep sight of your end goal and prioritize output. While learning the fundamentals and low-level code can be valuable, it may not always be the most efficient approach. Tools that abstract away certain complexities can provide a better conceptual understanding and accelerate the learning process. Ultimately, it's about finding the balance between gaining knowledge and creating what you're passionate about.

This is hands down the reality and the best advice out there. No one cares if you are able to do vulkan for 8 years EXCEPT for research labs.

And getting there requires that - you either have a PhD or the exact experience (threeJS, unity etc) as above because that will help you set foot on industry effectively allowing you to work on higher abstraction and slowly/rapidly decent into low level code.

This is great advice. I think it’s a common trap when I see questions like “what language should I learn/what language is the best”, which skip the point of “what would you like to build”. The tools change with time, and the best engineers in my experience generally know how to use a variety of tools with varying degrees of skill rather than be super deep in a single one.

Much like sorting algorithms I still think there is some value of teaching this kind of low-level programming in college. You gain a lot of theoretical knowledge as well as a lot of heavy complex algorithm training even if you never end up doing that kind of work in a real job.

With graphics it also gives you a lot of applied _math_ experience, there are a TON of fields that are desperate for people who can do math. Just my last job (software for CNC machines) we needed people who could do program the math necessary to program a drill to but a certain shape into a metal block and it was really hard to find these people. Yet, for example, cloud devops engineers, although expensive, were readily available

I'd recommend the Pikuma course Graphics From Scratch[0]. The first thing you do is write a set_pixel function utilizing SDL and the rest of the course is all your code, every matrix operation, every vertex transformation, every triangle rasterization. You calculate what every individual pixel should be colored.

[0]: https://pikuma.com/courses/learn-3d-computer-graphics-progra...

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

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.

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.

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.

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.

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

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.

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

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

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.

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.

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.

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.

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!

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

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

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

This isn't hard: DirectX 12 and C++ and Visual Studio (not VSCode) and Windows on an NVIDIA card.

Vulkan basically isn't relevant anymore unless you are doing Android. Metal similarly unless you are doing iOS.

As a Linux user, this pains me. But it's just life. Windows-land is soooo much better for graphics programming that it's absurd.

Vulkan basically isn't relevant anymore unless you are doing Android.

Why do you say this?

I'm not the parent commenter, but I'd like to explain their logic, which has at least a modicum of reason to it.

About 99% of desktop video games (by far the largest clients of graphics APIs) target Windows, and therefore target either Direct3D 11 or Direct3D 12. This includes free-to-use game engines including CryEngine, Unity, Unreal, and Ren'Py. Almost all the famous, proprietary, high-performance game engines (id Tech, Frostbite, Slipspace, REDEngine, Source) target D3D exclusively. Vulkan is clearly a second-class citizen on Windows. Some engines target OpenGL, and they tend to be used in (hurriedly dashed-out) console ports, but in almost all cases they exhibit worse performance than their D3D competitors.

Vulkan is completely absent from MacOS and iOS, where Apple has pushed its own API, Metal. OpenGL on MacOS is deprecated and is stuck on 4.1, missing all the advancements in 4.6, which include mesh shader support.

Many Android games are likely still running GLES. Vulkan is pretty hard to get started with, because things that are implicitly handled by the OpenGL global state machine now have to be explicitly handled by the developer, and chances are the developers of the millions of throw-away microtransaction-laden game apps on Android aren't writing their own rendering engines in Vulkan.

Therefore, despite all the positives of Vulkan—open-source specification, cross-platform support, SPIR-V shader target allowing shaders to be written in any language (HLSL, GLSL, other esoteric languages that compile to SPIR-V), an extension mechanism allowing fast iteration and updates—it has a fairly uphill battle.

EDIT: I was incorrect, id Tech supports Vulkan exclusively. But it is a minority in a sea of D3D-first engines.

Maybe i am wrong, but this tweet and wikipedia directly contradicts what you say (id tech does indeed use vulkan on windows): https://twitter.com/billykhan/status/1028133659168186368

I am just doing game dev on the side but i think nowadays the graphics abstractions are fairly similar in how they work (the modern abstractions, i.e. Metal, D3D12, Vulkan). Of course ideally you choose the graphics abstraction that is "native" to the platform, but vulkan seems to be supported very well on windows (many AAA game use it and it works great, many games run even better with vulkan abstraction than with their d3d12 counterpart). I use vukan so my graphics can run on windows and linux (which is why i chose vulkan instead of d3d12).

You are correct that idTech targets Vulkan (and they have some great GDC talks to boot)

They are however very much the minority.

I am suspect of your claim about Vulkan abstraction layers running better than DX12. If there is a performance difference, it’s likely elsewhere in the stack and just tangentially related.

I'm surprised by that as well.

I haven't done this stuff for quite a while, so my memory might be foggy, but the main advantage of Vulcan was that you can control all the CPU locking rather than the API doing it. This allows you to do stuff like prepare on one thread and submit on another, etc.

But that would be negated if you're using an abstraction layer.

iD Tech, Source 2, Unreal, and Unity support Vulkan.

iD Tech targets Vulkan exclusively on PC: https://twitter.com/billykhan/status/1028133659168186368

Other points are also blatantly untrue, but I think I have made my point. At this point, targeting only DirectX is shooting yourself in the foot.

Other references: https://docs.unity3d.com/Manual/GraphicsAPIs.html https://www.khronos.org/news/press/khronos-group-releases-vu... https://docs.unrealengine.com/5.3/en-US/supported-features-b...

While I was incorrect about id Tech (and have edited my comment), I never made the point that any of the other engines didn't target Vulkan.

Where else is my comment untrue? Many engines and rendering back-ends have only recently completed a Vulkan-based implementation. I am confident in my assessment that the large majority of existing implementations are still running OpenGL and/or Direct3D, if on Windows.

Almost all the famous, proprietary, high-performance game engines (id Tech, Frostbite, Slipspace, REDEngine, Source) target D3D exclusively.

You've said it there, hence my reply

I’m not the person you asked but my 2c (since I agree with their point on Vulkan)

Very few video games are made with Vulkan. DirectX is the primary API.

Android is the only place where Vulkan really has an interesting market share.

For a beginner, it has an incredibly steep learning curve vs DirectX as well. So given the low usage and high friction to pick it up, you have a really poor ROI.

DirectX and Metal are much more conducive to getting results quickly and efficiently.

For a beginner, it has an incredibly steep learning curve vs DirectX as well.

That's only because you refer to DirectX as a whole which includes plenty of older and APIs. If you want to start with those you can just as well start with OpenGL. if you want to jump straight into D3D 12 then that's not much differrent from Vulkan.

The topic was why not Vulkan for a beginner, and D3D12 is a lot less work than Vulkan to get the same results.

And I’d still recommend D3D11 over OpenGL for a beginner unless they really need multi platform. There are better resources, and less setup work up front.

Honestly though, if I was recommending any graphics api to start, it would be Metal. It has the best mix of ease of use to modern low overhead api.

IDK, all the games I try to run on Linux seem to work better in Windows/DX emulation rather than native/Vulkan.

How does this sentiment align with the advent of WebGPU?

WebGPU is little more than a laboratory experiment right now. There are probably no industry implementations (game/graphics engine, visualisers, etc). Computer graphics is particularly industry-driven—consider the proportion of game devs who present at SIGGRAPH versus academics.

I give it at least a decade before WebGPU sees any meaningful market share.

Bevy Engine (https://bevyengine.org/) is built ontop of wgpu (https://wgpu.rs/) and runs in-browser today (https://bevyengine.org/news/bevy-webgpu/)

Bevy is the second highest starred game engine on GitHub's Game Engine topic: https://github.com/topics/game-engine

I definitely agree that it's still new, but I don't feel like it's quite as far out as you're implying. A year or two at best IMO?

GitHub stars aren't really an accurate indicator of market share. I've previously starred it, too, but I've never used it.

I'd like to draw attention to the last phrase in my comment:

WebGPU sees any meaningful market share

I am comparing anything implemented in WebGPU to existing games that are played today by gamers.

Finally, it's using Rust, and the majority of graphics + game engines are written in C++ (with a minority in Java and C#). Despite the safety and tooling benefits, moving to Rust is still a change that companies have to implement and educate their developers on, which is going to take a lot of time. And game dev companies are fairly slow at adopting new language standards (even if they adopt new graphics APIs and hardware fairly quickly, e.g. ray-tracing).

I don't quite share your optimism; sorry.

Well, I'm writing a game intended for the web using Bevy right now, so I'm clearly biased :)

There are also some industry veterans building games using it. https://www.mobygames.com/person/6108/brandon-reinhart/ to name one specifically.

You can just use FFI if you want to integrate C crates with Rust, it's not that bad. Figma uses a mixture of Rust and C++ in the WASM that they ship.

Guess we'll see what the future holds.

All the best. I'll be happy to eat my words.

Rust is a great language (although I don't use it myself), and WebGPU is pretty interesting as well.

Chrome is switching to using Dawn (Google's WebGPU implementation) for its Skia backend. This would render all UI elements across Chrome using WebGPU. You can find plenty of projects that are using WebGPU today. In the web space, BabylonJS has had plenty of experience using it already, and you can run several demos [0]. Offline, there are games like Veloren [1] that use it exclusively as a graphics backend. Plus a number of other projects I can't talk about yet.

It's pretty obvious WebGPU is not going to replace any big engine's custom-built graphics backend, but it's already pretty capable, and I think it's going to be a good place to start for beginners for a long time.

[0] https://github.com/Popov72/OceanDemo [1] https://veloren.net/

WebGPU needs to cater to the lowest common denominator so it's unlikely to replace DX12/Vulkan/Metal in the demanding usages. It's always going to lag behind on features, capabilities, and performance.

But for the long tail of image filters, video effects, more graphically basic games - yeah, it's a great fit there. Probably.

To put it in perspective, WebGPU 1.0, that 6 years later is still only available on Chrome, is the lowest common denominator from 2015 GPU hardware.

WebGPU is a browser API.

Anyone making use of it outside the browser is making themselves a disservice by not using a middleware engine instead.

WebGPU as specified cannot do many modern features, and naturally making use of extensions in wgpu or Dawn, makes the code non portable.

Why is this the case?

Because the amount of resources that Microsoft and NVIDIA pour at graphics programming dwarfs the amount of resources that everybody else combined seems willing to put into it.

The implementations are better. The support is better. The ecosystem is better. The debugging tools are better.

Academic computer graphics research is in many places still using OpenGL 4.1.

wgpu, the Rust WebGPU implementation is the bee's knees. https://wgpu.rs/ You can use it beyond the web.

You think the first thing for someone who wants to learn graphics programming is to compile rust's webgpu implementation?

It’s actually relatively small.

So what? You don't think they might need to learn math or a graphics API or fundamentals first? You think they need to compile a rust webgpu implementation first because it's small?

How does this make any sense?

What do you think wgpu is if not a graphics API?

You can use it in a browser without compiling anything. Have you ever taught someone from scratch? You don't invent nonsense rabbit holes and barriers to entry to make things harder.

Did your try using it?

Why? Some people prefer typed languages.

Go teach an inexperienced person rust, graphics, rust compilation and webgpu all at the same time and let me know how that goes. It's pretty obvious you haven't actually done what you are saying here.

You can learn along the way. If you learned with the famous learnopengl website, you learn about compiling glad, glfw and putting up a C++, along with maths, all at the same time, incrementally... The tutorials for Rust's wgpu isn't any different.

WebGPU is a pretty good starting point, that's what I did myself (with C++, not Rust though, which should be even more straightforward). You can even use it in the browser and skip all the native hassle.

Just learn the basic concepts like buffers, drawing, texture, light, perspective etc. from https://learnopengl.com/ then you can jump into WebGPU. Even though there's not that many WebGPU tutorial, applying the OpenGL tutorials to it is pretty straightforward once you understand the fundamentals.

Using webgpu makes sense, but that isn't what they said. They said compiling a rust webgpu implementation.

Since this is very straightforward to do, I took it as equivalent statements

You think writing javascript fragments in a browser that is already installed is exactly the same as learning to compile rust then compiling a third party webgpu project in it?

That's not even graphics programming and everyone already has something that works, how are they at all the same thing?

Obviously not. Obviously the first thing for someone who wants to learn graphics programming is to learn Rust. I'm surprised you asked.

Ah, the AMD Game Engineering team, the same fine folks who implemented driver-level "optimizations" for Counter Strike that resulted in thousands of players getting permanently VAC banned.

The vac bans got reversed.

I fail to see how that excuses sloppy engineering.

It wasn't sloppy engineering unless you are saying AMD should have used a VAC bypass

Injecting code into third-party DLLs is as sloppy as it gets. It's an awful hack.

An AMD DLL always has been loaded into the game's process.

I agree with that, I was just correcting you. It's crazy that they deliberately altered the code of a running program like that, especially one which is going to have an anti-cheat system.

Temporarily permanently banned

You can't possibly hold AMD responsible for the behavior of third party black boxes? If Valve makes assumptions about the graphics drivers beyond the API then that's on them.

As a graphics programmer i think its good to have a well rounded idea about how graphics works. Here are some things I would expect a good graphics programmer to know, beyond just programming and an API:

-Rotation view and projection matrices, and general vector math.

-Shader programming.

-Procedural primitives like voronoi, SDF and perlin.

-Image Compositing.

-Forward and deferred rendering.

-Various sampling techniques.

-Shadow and lighting techniques.

-Knowing a bit about how the art pipeline works and how to get data out of 3D apps.

-Being comfortable using a profiler and debugger.

-Capable of reading Siggraph papers.

-Knowing various spacial partitioning and volume hierarchy techniques.

-Being able to build a simple raytracer.

-Good understanding of primitives, like sprites, triangles n-gons and so on.

-Some particle and simulation experience.

Where do you learn this stuff?

Googling it works pretty well

A good start would be the book Real-Time Rendering: https://www.realtimerendering.com/

School, then work, is the most traditional route. If you’re past that point and want to learn, the best use of that list is to use it as a self-learning syllabus and set of search terms, so you can start to practice.

A lot of these things are covered in computer science lectures if you pick the right ones. But you can also pick them up yourself by being curious how things work and reading papers or looking at existing game/engine source code. There are also many online resources as the sibling posters point out. Having at least some basic linear algebra or programming education makes things easier to understand.

Do you know how one can get a job as a graphics developer if they know most of these? I do Graphics programming as a hobby, and I learned a lot of what you mentioned here. But since I don't have any job experience, I never really get any interviews.

Always hard to get a foot in the door into a new role when one doesn't have direct company experience in the role on a resume.

The best thing I can think of would be to work on some independent projects (eg. some mod of a game, some indie game or graphics related app itself) and have that work be part of a portfolio.

The other approach that I've seen work is to get into a games company as it is significantly expanding and make it known that you want to do rendering work in the future. At an old company I was at a Gameplay Programmer pivoted to being a Graphics Programmer as the graphics team needed more help and was expanding, and I see via linked in that he's continued in that path.

I have the horrible feeling that, if you start to become a graphics programmer now, by the time you're done, AI will be doing it.

If you want to make games, learn a game engine. The big 3D ones are Unity (not too hard), Unreal Engine (hard, used for AAA titles), and Bevy (in Rust, open source.) There are a ton of 2D engines, mostly used to do retro stuff.

AI will be doing graphics programming? Please elaborate, I have a very hard time understanding how current clunky models that cannot generatie a java class without "// here you fill in the implementation" everywhere would go about improving current PBR shader code for example

AI will be doing graphics programming?

I doubt that. I think the bigger concern (if you could call it that) is that certain AI techniques may be able to replace entire stacks once they get advanced/stable enough. Something along the lines of this perhaps, where you render simplified geometry and let the AI fill in the blanks: https://www.youtube.com/watch?v=P1IcaBn3ej0

Even without experimental technologies, you can get a glimpse of how shipped tools like ray reconstruction can morph the field in the future, forever entrenching themselves into graphics programming one way or another.

As far as AI writing graphics code? No way, at least not in the next couple of decades. Button snippets are a far cry from rendering virtualized geometry 60 times a second.

I expect AI will consume game design jobs long before low level graphics programming.

The big 3D ones are Unity (not too hard), Unreal Engine (hard, used for AAA titles), and Bevy (in Rust, open source.)

Bevy is pretty much unheard of outside the rust community and also quite new (= hasn't yet proven itself). Godot would be the engine most likely to win the third spot.

I would recommend against investing time learning Unity because the company is clearly insane if they though they could get away with charging developers of existing games per install [0].

[0] https://news.ycombinator.com/item?id=37481344

Agree about Godot. Bevy is moving up but not there yet.

Also, the suggested developer machine for UE5 with everything turned on is expensive. 64GB of RAM and a graphics card with a price over $1000 are needed to build and run the Matrix Awakens demo. And it will take hours to build. The result is a playable game that looks like a Hollywood-grade movie. You have the sources and can mod it.

Unity's change to their business model has annoyed everybody in the industry.

All the comments here are BS. You have to learn how to construct 2D and 3D graphical spaces in real time and let them evolve and I'm sorry to say, as others have before, there is no royal road to mathematics. You simply have to put your time in the trenches. All the tools being sold to you are ephemeral and will soon become obsolete, so you simply have to grasp fundamentals of linear algebra and 3D spatial representations.

You can try to use tools created by others but the results will all just look the same as theirs, and if this is too much bother I'd suggest going back to non-digital mediums for your artwork like pen & ink watercolors oil paints etc.

If you can't handle vector calculus and complex analysis then that's too bad. Try harder or do something else.

Lol, the only math you need for practical graphics coding is linear algebra. Calculus only comes into play when doing e.g. light integrals, and complex analysis only when you start doing advanced convolutions.

The math isn't the problem, the absolutely abysmal API design is. The current generation of graphics APIs were designed for game engines to build middleware on top, not for practical use, and it shows.

Too many hardcoded limits, too many different ways to do the same thing, too many caveats and exceptions... and not enough decent developer tools to see wtf is going on on the other side.

the absolutely abysmal API design is

Oh.. Now I get why others see AI could improve things here :)

Ok but what are you saying? After understanding the math, are you suggesting that people need to use that understanding to interface with the graphics hardware at a level below Vulkan?

If you want to be a retro graphics programmer reject shaders and return to glBegin.

I'm sure there's a set of shaders that will basically let you emulate the fixed function pipeline without having to endure the shitty performance implications of passing a vertex list to the GPU every single frame.

You can use vertex buffers or at least vertex arrays without glBegin lol.

Not really sure what this website is asking. Does the person want to: Rig? Texture? Model? Write drivers? Make GUIs? Animate websites? Make graphics tools? Work with shaders? Or work with 2D photo engines? Make 2D games? Make 3D games? Write procedural scripts? Optimize graphics code?

There are hundreds of disciplines that fall under "computer graphics". The website focuses on a teensy little corner: programming graphics SDKs.

Being a graphics programmer is a pretty well defined category of programmers. A lot of the things you mentioned aren't graphics programming like Rig, Texture or Model, and a graphics programmer is expected to be able to run the gamut of games, 3D, 2D, tools, shaders and optimization.

I can see how it’s confusing but usually “graphics programmer” is someone who works on a graphics rendering engine (either real time or offline rendering)

The details are outdated now, I guess, but I don't know if there's any more inspiring reading for an aspiring graphics programmer than Fabian Giesen's "A trip through the graphics pipeline" https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-...

As for a place to actually start, I think Computer Graphics From Scratch is a good place https://www.gabrielgambetta.com/computer-graphics-from-scrat.... A great thing about the book is it gives you many ideas for where to go next once you work your way through to the end.

The details are surprisingly still relevant. A lot has changed, but most of that (compute shaders, Ray tracing hardware, ...) is actually orthogonal to everything mentioned in this article or simply details changing in aspects glossed over.

I still link people this article because I have yet to find anything which does a better job explaining these things.

Since this is on the front page I guess I'll post the resource that the graphics programming industry actually uses (note, I'm an author): https://raytracing.github.io/

It's included in the "Useful Websites" in the article above.

Also note that graphics is large enough that there no longer exists a one-size-fits all solution to learning graphics. If you want to learn graphics I'd recommend finding a mentor.

Great stuff! I especially agree with teaching math via raytracing first instead of APIs.

C is a perfectly good alternative to C++ for Graphics programming. OpenGL and Vulcan are C APIs and DirectX has a C wrapper. Some games like Call of duty are written in C, but C++ is more common.

I've done games in both. My favourite is mostly imperative C++ so you can use templates.

For complete beginners looking to get a good conceptual understanding of what shaders are actually doing, I would highly recommend this course: https://github.com/ssloy/tinyrenderer

In the course you will build a purely CPU-based renderer that simulates the way OpenGL shaders work. I found it to be incredibly useful for understanding shaders.

I'm a game developer but not specifically a graphics programmer. Although I work with modern graphics APIs and GLSL shaders in my day job, when my 13 year old recently graduated from wanting to program in Scratch or Python to wanting to learn C++, I decided the best thing to do was break out the old OpenGL 1.2 DLL's that I still had on my machine since 1999 and starting him writing some code using glut and glbegin/glvertex/glend type of immediate programming.

it is just a lot more fun than trying to suffer through all of the setup that one needs to do with modern APIs. he is more interested in computational geometry type of things like voronoi diagrams so the graphics API is really just a means to an end and fancy shaders and lighting aren't important right now, and performance in C++ and old school OpenGL is about a thousand times faster than Scratch, so I think we hit a sweet spot for where he is at in terms of his progression of learning.

even with the simplified API of OpenGL 1.2, he is still biting off a pretty ambitious chunk of learning to try to grasp c++ at the same time as OpenGL, so the simplicity helps keep it sane and manageable, and things are going well. He did some neat marching squares demos and I helped add an IMgui menu to tune parameters at runtime. it has been entertaining!

Practice.

https://www.carnegiehall.org/Explore/Articles/2020/04/10/The...

I went through this and switched from web dev to being a graphics programmer at a game studio

Personally I think LearnOpenGL is still the best tutorial series if you want to work on game rendering engines

Just because it covers a ton of different topics from beginner up to advanced all in one series. You go from scratch all the way up to implementing deferred rendering and a full PBR implementation

If you understand all of those tutorials you have a pretty good baseline for how modern game rendering works (minus ray tracing)

In terms of getting a job though the modern APIs are highly desirable

IMO the best way to start for a beginner is with Metal. It's a delightfully streamlined API that avoids the idiosyncratic complexity of DX and Vulkan, it's very quick to pick up if you already have some C++ experience, the tooling is excellent. Most importantly, you can focus on GPU programming instead of fighting the API and you get to play with all the fancy tools (mesh shading, ray tracing) with a very low barrier of entry. And all that you learn with Metal translates directly to other APIs.

make things. the end.

Blender's shader graph and geometry nodes seem like a fun/easy intro that I've been meaning to try. May not be 'programming' in the literal sense of typing text on the screen to produce graphics, but I'm hoping it would give a conceptual graph of how to produce the images I want that I could later transform into code if needed. Please correct me if I'm wrong as I haven't dove in.

Are there any good resources for learning graphics programming for the first time with WebGPU? I have heard mixed opinions about WGSL.

Put one pixel in front of another..

Oh there are so many more ways to become a graphics programmer than by starting with DX/VK/OGL. No need to use C++ at all. Look at all the amazing 3d graphics 3Blue1Brown does in Python.

Learn DirectX or Vulkan if you want to write game engines.

Learn WebGL if you want to write browser applications.

Those APIs are heavy though, and don’t even necessarily teach you that much about graphics on their own. If you want to learn graphics concepts, write your own rasterizer and ray tracer - both! - in any language you want.

There are also a bunch of super-easy-to-use graphics libraries & coding environments that are so much more fun than slogging through Vulkan or DX. Processing is wonderful. Or checkout PlotDevice.io (Python), or its predecessors NodeBox, or DrawBot. ShaderToy is another place where you can learn how to write shaders, or lots and lots about rendering, and it’s so easy to get started. JavaScript has lots of options and libraries. These can be way more accessible and motivating to a beginner, but still offer enough power and flexibility to take the curious student as far as they want.

program graphics

If you’re teaching yourself, it might be nice to have an early win. Something like unreals material editor or shader graph might be a nice start. Lots of tutorials around. Then, when you go to write actual shaders. You’ll know what logically you intend to do, and all you have to do is learn the syntax of whatever graphics language/api you choose

Tangent: Learning the syntax for OpenGL is hellish, and there’s a lack of great resources on it, at least as of several years ago.

Then, after you understand shaders a little, go and make your game engine (physics will be its own beast)

I'm on that journey myself. Two years ago I followed several tutorials and youtube videos to create my first 3D engine. It's very simple, but I like simple stuff. Right now I'm working on using this engine to create a city builder game [1]. It is a lot of fun to learn to manipulate stuff using matrix and cross products.

1 - https://www.youtube.com/watch?v=cvyrfPUpyp0

Depends on what you want to make and on which level. Doing graphics for a desktop application will differ from doing it for a web application, for embedded devices or for a game.

That being said for a beginner I would recommend starting with the examples in processing.org. This is basically a small IDE where you can make your code draw things in a window with minimal boilerplate (the boilerplate is hidden). There is a heap of examples, how to do easing functions, how to work with vectors, etc.

The stuff learned there will be useful for anything where you need to work with a coordinate system.

    10 GRAPHICS 8+16:REM HIRES MODE WITHOUT TEXT WINDOW
    15 SETCOLOR 0,0,0:SETCOLOR 2,10,15
    20 COLOR 1
    30 PLOT 0,0
    40 DRAWTO 319,190
    50 GOTO 50

Is there any point in learning in new programming skills when AI can do it all? I feel discouraged about learning new skills in this era

Learning trigonometry and linear algebra would be a good start.

You can start learning graphics by writing shaders on Shadertoy. It’s where tons of graphics programmers get their start.

Shameless self promotion, I’ve made 10+ tutorials going over topics like: how to write shaders in VS Code, SDFs, ray marching, noise functions, fractional brownian motion, etc.

https://github.com/suboptimaleng/shader-tutorials

I’m certainly standing on the shoulders of giants like Inigo Quilez, The Art of Code, SimonDev and Acerola.

Not one mention of GDI+ ?

I really don't consider getting familiar with whatever minutia of C++/Vulkan throws at you graphics programming. It just presents unnecessary barrier that may change in the future without you learning any of the core skills that are purely algorithm and math based. When you learn a low-level API to talk to the GPU, or an antiquated horror-show of a language such as C++, you're not actually doing any graphics programming. Get into shaders (also compute) ASAP.

getting started:

https://www.khanacademy.org/computing/pixar (super basics)

https://iquilezles.org/articles/

https://www.shadertoy.com/

youtube/gamedev:

https://www.youtube.com/@Acerola_t

https://www.youtube.com/@crigz

research:

https://www.cs.cmu.edu/~kmcrane/

http://rgl.epfl.ch/people/wjakob

https://www.nvidia.com/en-us/research/