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.

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.

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

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

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?

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.

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.

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.

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.

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.

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

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

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.

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

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.

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

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!"

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

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

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.

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.

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.

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.

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

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

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.

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

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.

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

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

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

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

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

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.

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

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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

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!

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

    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

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/

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.

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

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

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)

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

> 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

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.

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.

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

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

How does this make any sense?

Why? Some people prefer typed languages.

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.

Why do you say this?

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.

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.

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.

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.

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

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.

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

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

You've said it there, hence my reply

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

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.

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

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/

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.

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.

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

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

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