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.
The more unfortunate news is that job applications also don't tell you this. Had plenty an interview as someone looking for "plumbing" graphics roles that clearly wanted a "GPU programming" role instead. Or heck, the role was more for a Tech Artist.
Of course, the actual interview is a complete crapshoot as well. And that's where the "but I need to know C++ and low level concepts" probably rears its ugly head. But then again, what software engineering interview these days isn't?
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’.
Probably not the best question to ask in this market where everything is especially selective, but even as a now "senior" engineer (I guess I passed that magical 5 year mark a while ago) it feels like I still fall into the catch 22 of "be a graphics engineer to get a job as a graphics engineer"
1. Finding Your Home in Graphics Programming, https://alextardif.com/LearningGraphics.html
2. Applying for Entry Level Graphic Jobs in Games, https://alextardif.com/GraphicsJobGuide.html
3. Junior Graphics Programmer Interview Questions, https://erkaman.github.io/posts/junior_graphics_programmer_i...
4. Interviewing Graphics Programmers, https://www.jeremyong.com/graphics/interviewing/2023/08/05/g...
5. Interview Questions, https://aras-p.info/blog/2016/11/05/Interview-questions/
6. Game Programmer Resume Tips, https://github.com/unpacklo/game-programmer-resume-tips
The Aras blog was especially nostalgic too. Real shame I never got a chance to speak with him back at Unity. Joining right during the pandemic removed a lot of potential to travel out to Copenhagen and meet some of these giants of the industry.
10. If You're Serious About Pursuing a Career in Computer Graphics, https://old.reddit.com/r/gameenginedevs/comments/17nsp1m/how...