Hacker News Reader

IMO the article is better advice than the parent comment.

Learning from Unreal or even Godot to write a basic renderer is pretty wild. It would be like telling someone who wants to make a model rocket that they should study the Falcon Heavy.

Making a basic renderer in c++ is orders of magnitude simpler then trying to deconstruct a game engine that(according to google search) has over 2million lines of code.

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.

I would say, a rocket engineer should definitely start with a simple rocket to be designed on their own - before proceeding to something modern and complex.

And I did not study rocket science, but in my CS studies we definitely started with the simple ("hello world") basics, too, before touching real systems, so I would think, they do likewise. Because it makes sense. How can you understand and design something complex, if you cannot even make a simple version of it?

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

If you can't yet do so much as slap together some Estes kit and launch it in your backyard, what gives you the impression that you'd have the requisite knowledge to be able to gain anything from studying the Falcon Heavy?

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

No, I was not suggesting education is not useful.

But if one is to study rocketry without an aeronautics degree I'm guessing it's better to start from hobby level engines and vehicles and then scale up.

There is lot of added complexity due to size and mission constraints that is vehicle specific in Falcon Heavy, and I'm not sure how one would even use it as a learning platform - unless there is a university curriculum built around the vehicle.

There are lot of basics that model rocketry probably gives a good intuition for but then to my limited understanding it becomes (drumroll) rocket science.

Learn from the past but don't take it as gospel because people probably worked with different constraints and assumptions that might be completely different today.

Different people want to learn from different sides. Some prefer as you say, others prefers learning how to paint pixels first, then go from there and paint triangle structures, then add stuff like effects, maybe generate water and waves, use pixel data to create shadows, write your pixel data and shapes to GPU ram and use it to update future calls etc.

And then once you know how to draw things you start looking at how to import models to draw, instead of starting with a big complex object you learn exactly what each instruction does to the pixels. Then you use what you learned to make what the large structure you imported look like it did in blender, rather than follow a tutorial how to make it look the same you use the skills you learned when you learned the basics before. That way you learn how to create small samples to debug etc, because you did the small samples in code before you did the blender import.

The modern APIs can be quite challenging, on the contrary. Binding models, synchronization and barriers can be quite tricky. I group my conceptual knowledge of a render runtime into four main parts:

1. Graphics Systems. These are the platform APIs and how to use them.

2. Frame graph. The different passes in your frame and the purpose of each, and how they flow together, and how the code around this is organized.

3. Object layer. How draw calls are batched, sorted and submitted. This is the glue that determines which models end up in which passes.

4. Material layer. This includes shaders, resource binding, and more of the tech art side of things.

There's a lot to be done beyond the API world, but there's also a lot to be done on the CPU side and not just the shader side.

Unity render pipeline source is available here: https://github.com/Unity-Technologies/Graphics

All the C# code running in the editor and runtimes is here: https://github.com/Unity-Technologies/UnityCsReference

The code that interfaces directly with the platform API at the C++ level is restricted (you can get access but it's not really a viable option for a beginning graphics programmer :)). For many platforms the APIs themselves are proprietary and therefore that code cannot be shared easily.

There's pretty good tooling support around graphics debugging: https://docs.unity3d.com/Manual/RenderDocIntegration.html https://docs.unity3d.com/Manual/FrameDebugger.html

Your point on the learning difficulties imposed by unity's obfuscation is very important.

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

check out TinyRenderer, a 500 lines cpu renderer with some essential parts similar to OpenGL, such as z-buffer, vertex and pixel shaders, texture mapping, shadows etc, with articles explaining how things work:

https://github.com/ssloy/tinyrenderer

Oh this is awesome! Thanks!

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.

The book RayTracingInOneWeekend[1] is a good starting point for people looking to write a raytracer.

[1]https://raytracing.github.io/books/RayTracingInOneWeekend.ht...

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

Is there some sort of taxonomy of graphics programming that lays out these different areas of work? Are they recognized or common specializations or is each practitioner’s situation unique and circumstantial?