I've heard that the salary for game programmers is pretty low compared to other fields. Is this also true for graphics programmers in general? E.g. jobs in AR/VR.
No
Finding your home in game graphics programming
51–60 of 128 posts
Re: Finding your home in game graphics programming
#52Graphics Programming needs to be restructured. There’s a lot of focus on API driven learning. Vulkan, D3D12, 11, etc. Wrong approach. Learn fundamentals of what the hardware is capable of. For each feature, write down a few ideas of how you could use it by itself. Write down a few ideas of how you could combine it with other features. Think of “I want to do X. What features can allow me to do that?” The APIs, althoug…
>The APIs, although they are not easily interchangeable, use the same hardware and can often do the same things with a bit of effort. Actually it's the other way round. GPU architectures can vary wildly especially when you include mobile GPUs which are tiling architectures. Graphics APIs are the least common denominator interface that makes targeting all of them possible.
When you're learning instead of making something for production, it may be wise to focus on a single platform (whether it be Windows, Linux, or mobile) and start from there.
Re: Finding your home in game graphics programming
#53Graphics Programming needs to be restructured. There’s a lot of focus on API driven learning. Vulkan, D3D12, 11, etc. Wrong approach. Learn fundamentals of what the hardware is capable of. For each feature, write down a few ideas of how you could use it by itself. Write down a few ideas of how you could combine it with other features. Think of “I want to do X. What features can allow me to do that?” The APIs, althoug…
The problem is that when you're starting out on graphics, you don't even know what you're capable of doing with the hardware that you have, and the distance between manipulating things on the hardware and putting something on the screen can seem dauntingly far away.
My advice, start out with OpenGL 1 (the old glBegin()/glEnd() stuff) or Raylib (raylib.com) where you begin to get accustomed to really basic stuff (primitives, transformations, etc.). Then do the LearnOpenGL tutorials to learn modern graphics concepts (vertex buffers, shaders, render passes, etc.) Once you've done this you might have enough knowledge to make a simple game/visualization/application, and you'll know yourself if you need to study D3D12/Vulkan or not.
Re: Finding your home in game graphics programming
#54Earlier quoted context omitted.
Not only is ray tracing the future of rendering, it's by far the best way to learn basic graphics programming theory, in 100% your own tiny code. I've literally taught a 12 year old this way from absolute scratch, and have been teaching it this way for over 20 years now; it's a bajillion times more upfront complexity to do a rasterisation engine from scratch, so in practice almost nobody does this, and we're back to…
interesting. do you have a go-to resource for how you would recommend somebody learning RT?
Certainly, there was already a mention in this thread about Ray Tracing in One Weekend, which is pretty good (IMO mostly on account of its brevity): https://raytracing.github.io/books/RayTracingInOneWeekend.ht...
Also good is Scratchapixel: https://www.scratchapixel.com/
Once you've written a few derpy ray tracers, dig into https://pbrt.org/
I like to paraphrase a famous Go (the board game) proverb: "Get your first 5 ray tracers over with as quickly as possible."
Re: Finding your home in game graphics programming
#55Indeed the author has caught on that graphics is now much wider. Yet his post still focuses on the APIs. A bias he admits to. APIs are the easy part of graphics programming. Now perhaps I say that out of bias, as I focus on shaders and artist work pipelines. The author focuses on APIs and thus reached for a simpler API as a teaching on ramp, while I would new learners run the other way and learn the basics of blender…
I learned unity about 5 years ago and got burnt out on it after a few personal projects and a few freelance side gigs I took that used it. But I was not a decent programmer then and I have earned a CS degree in the time since. I actually used 3DS Max and Blender more than Unity but have since been distracted with web development and once I’m settled in my new job I am planning to write a raytracer. Any other recommen…
https://www.gabrielgambetta.com/computer-graphics-from-scrat...
This walks through the creation of a raytracer and a rasterizer in a way that was pretty easy for me to understand. It’s not exhaustive; it’s just right.
Re: Finding your home in game graphics programming
#56Earlier quoted context omitted.
interesting. do you have a go-to resource for how you would recommend somebody learning RT?
Certainly, there was already a mention in this thread about Ray Tracing in One Weekend, which is pretty good (IMO mostly on account of its brevity): https://raytracing.github.io/books/RayTracingInOneWeekend.ht... Also good is Scratchapixel: https://www.scratchapixel.com/ Once you've written a few derpy ray tracers, dig into https://pbrt.org/ I like to paraphrase a famous Go (the board game) proverb: "Get your first 5…
Thanks this is excellent! Funny, I play some Go but never heard any variation of that proverb. Maybe that's why I haven't made Dan 1 yet...
Re: Finding your home in game graphics programming
#57Kind of a weird New Years fever dream tangent. Bear with me: Say we have a scene to render and a frame can be rendered in 10ms given the chosen game engine or graphics API or whatnot. There is a hypothetical optimum code for rendering that scene that can do it in less time. And the delta between those times is the price you pay for API abstractions, human abstractions (eg. maintainable code vs clever code), and other…
The term you're looking for might be "abstraction penalty". For tools that can identify where the bottlenecks are, I recommend watching Emery Berger's talk "Performance Matters" from CppCon 2020 (either of the two links below should work). He introduces some innovative new profiling tools for this sort of analysis. https://www.youtube.com/watch?v=koTf7u0v41o https://www.youtube.com/watch?v=VzyhpbrC2Bs
The guy is unconvincing.
I don't believe RAM layout is that important. Of course it can affect perf, but slightly, not by 40%. For instance, Windows has ASLR (address space layout randomization) for security reasons, enabled by default. Microsoft would not do that if it would cost 40% of performance at random.
However, there're quite a few random factors. Random choices made by C++ optimizers can contribute about 20% random. Computer thermals when running the test can contribute 40%.
Too much statistics to my taste. For practical purposes, a simple "best of 5 runs" is usually adequate. If that benchmark is too unstable (typical for microbenchmarks with runtime measured in nanoseconds), "best of 20".
The statistics is probably wrong because these distributions are not Gaussian. Execution time of programs is bound from below for several reasons (no time machine, CPU throughput) but not from above (if you really unlucky, the computer may stall and the program will never complete), this factor creates large asymmetry in the distribution.
It's hard to selectively slow down code to emulate performance profile. You'd want same power consumption, and same load of external devices like disks and GPU.
Re: Finding your home in game graphics programming
#58Earlier quoted context omitted.
If you want to be a rocket engineer indeed the Falcon Heavy is a better study reference than making a fresh design in your backyard. The hard part if learning is figuring out what you do not know. The easy part is reading a tutorial or API documentation.
Well, some people think failure is the best teacher. As an example the first generation of german rocket engineers whose work culminated in Saturn V and thus enabling the first moon landings basically started from scratch.
So your advice is to just suck it up and accept that interested people need to spend billions and study for decades on the issue, because learning from previously successful endeavors is a worse teacher. Right.
It's fine to just half-ass it if the interest is only superficial or for a hobby. Otherwise it might create a very unrealistic expectation in the student, because the gained knowledge by doing it like that is pretty worthless in a professional setting
Re: Finding your home in game graphics programming
#59Earlier quoted context omitted.
Certainly, there was already a mention in this thread about Ray Tracing in One Weekend, which is pretty good (IMO mostly on account of its brevity): https://raytracing.github.io/books/RayTracingInOneWeekend.ht... Also good is Scratchapixel: https://www.scratchapixel.com/ Once you've written a few derpy ray tracers, dig into https://pbrt.org/ I like to paraphrase a famous Go (the board game) proverb: "Get your first 5…
Thanks this is excellent! Funny, I play some Go but never heard any variation of that proverb. Maybe that's why I haven't made Dan 1 yet...
Lose Your First 50 Games As Quickly As Possible: https://senseis.xmp.net/?LoseYourFirst50GamesAsQuicklyAsPoss...
I'm still DDK, but can at least appreciate some of the beauty of the game, and finding little parallels throughout life etc :)
Re: Finding your home in game graphics programming
#60I disagree, if you stop chasing infinite progress it's very managable. As hardware peaks now it's the perfect occasion to settle on something older and make a stand there. They can deprecate it all they want they wont be able to remove it, in fact they will probably maintain and improve it for eternity. I have choosen OpenGL (ES) 3 and I'm making my 3D action MMO client on top of that. Metal, Vulkan and DX12 bring no…
The game I'm working on uses compute shaders for pretty much all the gameplay.
These APIs are just to control the GPU, they are just complicated to give developers flexibility. Just because you can't think of uses for these features for gameplay doesn't mean they don't exist.
Perhaps I'm misunderstanding "The fragmentation is a sign of desperation" but Metal, Vulkan and DX12 have very clear reasons they exist:
-Metal was created by Apple to unlock features that their GPUs had that OpenGL ES 3.0 does not support. This is pre Vulkan so that wasn't an option.
-Vulkan addresses the desire by developers to make more low level use of GPUs. AMD Mantle started the trend but it became clear that either a standard needed to be developed or every platform/gpu maker would have their own API.
-DX12 was created as the successor to DX11 to address the same issues as Vulkan but in the way that the Microsoft team wanted to.