I’m 15 and I recently decided to learn Rust. I’m currently on Ownership, but my real interest is in Graphics Systems Engineering (or just Graphics Programming). Mainly in game development.
I’ve noticed there’s very little clear information out there; it feels like a total scramble with no direct pathway to follow. That’s why I’m making this post to ask for some guidance.
My Questions:
Where do I start? How can I actually get into the "systems" side of graphics rather than just using a game engine?
How do I bridge the gap? I know most of the industry is built on C and C++, but I’m using Rust to build a solid foundation. How well does that knowledge carry over?
What are the "Hard Parts" I should focus on? Can you tell me the high and low-level stuff? I want to make sure I’m studying the right things.
I want to eventually build high-performance rendering tools or custom plugins. Another important note is that I'm not bad at math, I just don't study (currently taking Algebra 1).
So I would be very appreciative for anyone to provide direction, advice, or resources.
I would say that there are actually two sub-problems here:
Learning the math of making interesting pictures.
This doesn’t have to be “not using a game engine” at all — it could involve writing programs that generate meshes that go into a game engine, for example. Or generating things like enemy spawning patterns that are also pictures. Or, outside of game tooling, writing a program that generates a PNG or SVG file that contains an interesting picture. The important thing is building connections in your mind between mathematical formulas and algorithms, and the shapes and images they produce, and this is best approached in an exploratory, artistic way, using easy (or fun, even if not easy) tools, not necessarily the most efficient or low level ones.
Learning how rendering works.
Graphics APIs, GPU architecture, efficient algorithms, etc. Actually implementing the above in an efficient way rather than just a working way.
Writing graphics programs involves both of these kinds of knowledge.
Knowing graphics isn't about knowing C++. It's about knowing how math makes pictures, and the general kinds of ways graphics APIs work. Then you take that knowledge and write the actual implementation in whichever language you want to work with.
Being a good programmer, in general, isn’t about knowing the right programming language. It’s about knowing the fundamental ideas, and being able to learn the languages, tools, and APIs that suit the current problem.
While learning about graphics, you may encounter C++ code, and you’ll want to be able to learn from that code, but you don’t need to know C++ well enough to write a C++ program, just to understand the math and the algorithm, so you can translate it to the language you’re working in (whether that is Rust or another language).
Bevy should be worth looking at. It allows building 3D worlds in Rust. I used it in robotics as a side feature only but with great success.
I am not even sure if you need details how exactly the rendering works. I just told meshes and their poses of my robot joints, lights and shading work fine without me thinking how they do. Rendering engine does it all, you only need to know how to drive it.
I’ve never really seen these as two separate problems. To me, and from what I got from researching Google & YouTube and other resources, it feels like one big challenge of how we organize data? If that makes sense.
I see Graphics Programming as the study of how we can use math to take in raw data (which could be anything) and translate it into a visual representation.
I'm not saying I want to recreate a graphic API like OpenGL. But rather I want to build systems that are used for things outside (outside as in not limited to) of game engines, whether it's a shading tool for a game engine / video editor or a noise gain for a DAW. What I'm really trying to make is a system that isn't tied down to just one platform of development.
The nuisance is that LLMs like to put key words in bold, which makes me wonder if OP is using one for translation (or if OP is even who they say they are !)
To clarify (not a mod): it's against the guidelines here to generate post content using AI. However, that doesn't mean we have to immediately get confrontational and offensive when we suspect AI. Their posts have been clear and understandable (as opposed to bloated and superficial), so for my part I don't care either way.
I don't think Tekto was emboldening random words there. In that paragraph they are giving their definition or take on "graphics programming". Which would normally be emphasised with quotation marks or italics. Bold seems fine to me. Th use of bold in the opening post does not look random to me.
Sounds like a good a definition as any. Which straight away suggests you are going to need to pay attention in math class. You need all that algebra, vectors, linear algebra(matrices) and so on. As you say "translate it into a visual representation.", which is mathematically transforming whatever data you have into some kind of image.
Back in the day if we wanted to see anything, be it a game or a graph, the first step was finding to how to light up a pixel on the screen. Then using that to draw lines triangles, rectangles, circles etc. Things like Bresenham's line algorithm and the Minsky Circle algorithm came in useful. Then if you wanted to move into 3D it was time to know perspective geometry. Then if you wanted some lighting effects you had to get into things like Phong shading. And so on and so on. You can goggle all the things, ask the AI now a days, and have a lot of fun coding these things for your self in Rust or whatever language.
Of course nobody does any of that nowadays. Not unless they are working with some tiny micro-controller or such that they have added a screen to. Instead we use libraries like the SDL or Raylib or whatever. Or perhaps some game engine. Things is using those is greatly helped by understanding the maths of all the above..
Which brings us to...
If you really want 3D and decent performance for complex things you are going to want to use the GPU on your machine. Which leads to using OpenGL or Vulkan or whatever. Actually directing those to do the work for us adds a whole other layer of complexity.
Recently in my quest to do fast graphical data visualisations of real-time data streams on as wide a range of platforms as possible I have been experimenting with WebGPU. That is a GPU API that makes use of OpenGL or Vulkan or whatever your machine has. The end result is that I now have visualisations that run on Windows, Mac, and Linux. Also in the web browser, also on so called "headless" Linux machines that have no desktop (X11, Wayland), WebGPU works straight to the GPU drivers in Linux.
You are right, the pathway to graphics nirvana is very muddled and complex. It is a huge topic that has been evolving for decades. I hope I have hinted at some useful things for you to google and study. Have fun.