Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What to learn to be a graphics programmer

blog.demofox.org

Post reply on HN
Print view View original

171–180 of 251 posts

Re: What to learn to be a graphics programmer

#171

Post by lowbuzz »

raincole wrote: post #161
rustystump wrote: post #137

Earlier quoted context omitted.

I always argued for custom game engines not for performance but so your game “feels” unique. I can spot a unity or unreal game from miles away. They have a smell if you will that is very hard to escape. Every game that has a custom engine just feels unique and interesting in a different way. I think this is why people likely push the custom engine. Any game that passes the finish line on a custom engine often has a l…

> I can spot a unity or unreal game from miles away. They have a smell if you will that is very hard to escape. Confirmation bias. Are you saying Hollow Knight, Cities: Skylines and Escape from Tarkov have the same kind of "smell"? It's as ridiculous as saying that you can spot a SaaS written in Rust from miles away.

Yeah, there are some unreal "slop" games, even big ones, that just look like UE5 looks with kinda default settings, but there are also games made with these engines that look nothing like that.

Re: What to learn to be a graphics programmer

#172

Post by imtringued »

Animats wrote: post #107

Do you want to make games, or do 3D engine programming? If you want to make games, use an existing engine. Unreal Engine, Unity, Godot, and Bevy are good choices. You'll learn the higher level issues of graphics, not how to push pixels around. The real problem is making it fun. If you want to do 3D engine programming, be aware that there are too many bad game engines. In Rust land, where I am, there are three failed…

Yeah if someone wants to do 3D engine programming they should consider reviving rend3 [0] instead of starting their own project.

[0] https://github.com/John-Nagle/rend3-hp

Re: What to learn to be a graphics programmer

#173

Post by flohofwoe »

andai wrote: post #118
Animats wrote: post #107

Do you want to make games, or do 3D engine programming? If you want to make games, use an existing engine. Unreal Engine, Unity, Godot, and Bevy are good choices. You'll learn the higher level issues of graphics, not how to push pixels around. The real problem is making it fun. If you want to do 3D engine programming, be aware that there are too many bad game engines. In Rust land, where I am, there are three failed…

Two years? Why does it take two years?

Because 90% of the work on an engine goes into the tooling (DCC tool exporters, asset pipelines, editor tools, ...), e.g. the "actual" engine runtime is just a small (and frangkly: quite trivial) thing dangling off the end of the asset pipeline. And game engine tools development is a never ending rabbit hole that's never quite finished (UI tools development got much easier though thanks to Dear ImGui).

IME two years sounds about right starting from scratch until getting everything into a state that can be called a basic game engine (if a bit optimistic). You can start earlier building a game on the in-progress-engine of course and tbh that's the only way to not develop an entirely useless engine. But that way you'll also end up with an engine that's mostly only useful for that one game, and progress on the game will be atricious in the first year or so. And of course developing both side by side means spreading the butter even thinner.

In the end though I have seen at least as many game projects fail using an off-the-shelf engine (in that case: Unity) compared to using an inhouse engine. The decision to use inhouse tech versus off-the-shelf engine doesn't make or break a game, in the end the failure always lurk within the team (but the engine is usually blamed first when things went south heh).

Re: What to learn to be a graphics programmer

#174

Post by TheRoque »

opan wrote: post #125
Animats wrote: post #107

Do you want to make games, or do 3D engine programming? If you want to make games, use an existing engine. Unreal Engine, Unity, Godot, and Bevy are good choices. You'll learn the higher level issues of graphics, not how to push pixels around. The real problem is making it fun. If you want to do 3D engine programming, be aware that there are too many bad game engines. In Rust land, where I am, there are three failed…

The amount of otherwise decent games that run poorly due to Unity or UE is very unfortunate. I wish people would stop recommending this stuff. I do hope Godot and Bevy are better, but I'm not sure if they are. To name some games with very bad perf issues that I've played in the last couple years: Core Keeper (Unity), WORMHOLE (Unity, mostly see the lag in endless mode), Crab Champions (UE4, have to use nonsense upsca…

> The amount of otherwise decent games that run poorly due to Unity or UE is very unfortunate. I wish people would stop recommending this stuff. I do hope Godot and Bevy are better, but I'm not sure if they are.

Games don't run poorly "because of unity or UE", those engines are highly optimized for the graphical fidelity they provide, It's super easy to find examples of games that run flawlessly with these engines (UE5: Arc Raiders, Unity: Arknights Endfield). Seriously, this narrative is ridiculous and needs to stop.

Some games with those engines run poorly because no matter the engine, if the developers don't take the time to optimize their games, the result will be an unoptimized mess. Is Unity engine responsible for the fact that Cities Skyline 2 devs decided to render the full polygons of every individual's teeth no matter the distance ? There are a ton of tools built in to handle level of details and they didn't use them...

I doubt those unoptimized games would do any better and in a shorter time if the studio had to build their own engines, or with any other available engine. Bevy is too barebones to be compared, and Godot is not as capable as Unity/UE.

Re: What to learn to be a graphics programmer

#175

Post by flohofwoe »

TheSamFischer wrote: post #119
andai wrote: post #118

Earlier quoted context omitted.

Two years? Why does it take two years?

Unless you’ve written one before, it’s the natural learning curve. You can always generate one using LLM if you don’t care about how it actually works.

> You can always generate one using LLM if you don’t care about how it actually works.

Lol, right. That might work for some of the runtime parts of a very simple engine, but not the other 90%, especially when you "don't care about how it actually works".

A game engine (like UE or Unity) easily exceeds the complexity of an entire desktop operating system (not necessarily in line count, but in number of features, their diversity and complexity).

Re: What to learn to be a graphics programmer

#176

Post by imtringued »

fastball wrote: post #74
sph wrote: post #28

Earlier quoted context omitted.

I really dislike people that got into a thing and then try to discourage others. “Don’t be like me! I wasted my entire life” which is bullshit from a jaded person that lost passion. Telling people to stay away from graphics programming is not how to entice tomorrow’s John Carmack. So here’s another perspective. If all you have done is web apps and Kubernetes, for example, do get into graphics programming. The feedbac…

"These annoying, jaded horse-drawn cart builders, cautioning youngsters from getting into the field in 1908."

Except the point of the jaded person is that building transportation vehicles is a bad industry to get into, because there is a massive switch from cart building to automobile and truck building on the basis that it has become impossible to build a full automobile as a single person.

Re: What to learn to be a graphics programmer

#177

Post by ivanjermakov »

ivanjermakov wrote: post #101

I had some difficulties making sense of _color_ in context of graphics programming, especially transfer functions (sometimes misleadingly called tone mapping). Good article on color management in general, which has a great intersection with foundations needed for graphics programming: https://chrisbrejon.com/cg-cinematography/chapter-1-color-ma...

Update: and this one, with more on display transforms

https://chrisbrejon.com/articles/ocio-display-transforms-and...

Re: What to learn to be a graphics programmer

#178

Post by ivanjermakov »

yunnpp wrote: post #123
ivanjermakov wrote: post #101

I had some difficulties making sense of _color_ in context of graphics programming, especially transfer functions (sometimes misleadingly called tone mapping). Good article on color management in general, which has a great intersection with foundations needed for graphics programming: https://chrisbrejon.com/cg-cinematography/chapter-1-color-ma...

> sometimes misleadingly called tone mapping sometimes is an understatement there. It took me like a decade to get that shit right. Graphics in general seems to suffer from bad explanations repeated everywhere. We need more authoritative textbooks.

I think the problem is that terminology for graphics programming was reinvented without asking color scientists. Unfortunately common in our industry where solutions are created without proper research of existing alternatives.

Re: What to learn to be a graphics programmer

#179

Post by kleiba2 »

Animats wrote: post #107

Do you want to make games, or do 3D engine programming? If you want to make games, use an existing engine. Unreal Engine, Unity, Godot, and Bevy are good choices. You'll learn the higher level issues of graphics, not how to push pixels around. The real problem is making it fun. If you want to do 3D engine programming, be aware that there are too many bad game engines. In Rust land, where I am, there are three failed…

> Pay is lousy, hours are lousy, jobs end when the project is completed, and, like Hollywood, there's an army of wannabees wanting in.

Well, in that case, I'm going to go into academia!

Re: What to learn to be a graphics programmer

#180

Post by someonebaggy »

charlie90 wrote: post #120
qingcharles wrote: post #110

Earlier quoted context omitted.

Agree with almost all of that. Unless you are targeting some obscure or old platform, I don't even know how you'd justify trying to write a 3D engine from scratch in 2026, except as a fun learning experience. Also, think about tooling. Last time I wrote an engine from scratch, the tooling to support it probably took way more time than the engine did.

AI changes this a lot. You can realistically get a featured 3d engine+editor up and running in a couple week with AI, working solo. Probably better than what Godot or even Unity gives you. Also AI is very good at editor/tooling stuff, I've even found it getting better at graphics programming stuff, just telling it to 1-shot implementing gpu occlusion culling, ddgi probes, taa, etc. type of features. Also for stuff li…

I'd like to see evidence for this claim.
Post reply on HN