4 ms·

Indeed 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 graphic

Indeed 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. Learn blender, basic 3d modeling. Then dig into understanding how a model goes from disk, to cpu, to gpu. Understand what a draw call is, then batching in its many forms using a commercial engine. Once you know what everything should "look like" and what the state of the art is, only then reach for APIs and write a from scratch renderer. If the learner has no idea about fultrusm culling, or triangle stripping, or instancing, or uniforms, or texture binding: a fresh from scratch c++ is a horrible learning experience. Edit: When learning use either Unreal or Godot. You need source access. Time spent learning Unity is time lost. The author should not suggest unity is anyway equal for learners. Digging into the renderer requires breakpoints and source code.

Jasper_ 5y ago
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.
nopenopenopeno 5y ago
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?
- erwincoumans 5y ago
  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 https://github.com/ssloy/tinyrenderer
  - nopenopenopeno 5y ago
    Oh this is awesome! Thanks!
- t8y 5y ago
  The book RayTracingInOneWeekend[1] is a good starting point for people looking to write a raytracer. [1]https://raytracing.github.io/books/RayTracingInOneWeekend.html https://raytracing.github.io/books/RayTracingInOneWeekend.ht...
- rembicilious 5y ago
  https://www.gabrielgambetta.com/computer-graphics-from-scratch/00-introduction.html 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.
mrVentures 5y ago
Your point on the learning difficulties imposed by unity's obfuscation is very important.
Jensson 5y ago
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.
t8y 5y ago
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.
- Danieru 5y ago
  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.
  - fsloth 5y ago
    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.
    - y4mi 5y ago
      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
      - AnIdiotOnTheNet 5y ago
        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.
      - 5y ago
throwawaysea 5y ago
> 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?
danschuller 5y ago
Unity render pipeline source is available here: https://github.com/Unity-Technologies/Graphics https://github.com/Unity-Technologies/Graphics All the C# code running in the editor and runtimes is here: https://github.com/Unity-Technologies/UnityCsReference 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/RenderDocIntegration.html https://docs.unity3d.com/Manual/FrameDebugger.html https://docs.unity3d.com/Manual/FrameDebugger.html

Jasper_ 5y ago

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.

nopenopenopeno 5y ago

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?

erwincoumans 5y ago
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 https://github.com/ssloy/tinyrenderer
- nopenopenopeno 5y ago
  Oh this is awesome! Thanks!
t8y 5y ago
The book RayTracingInOneWeekend[1] is a good starting point for people looking to write a raytracer. [1]https://raytracing.github.io/books/RayTracingInOneWeekend.html https://raytracing.github.io/books/RayTracingInOneWeekend.ht...
rembicilious 5y ago
https://www.gabrielgambetta.com/computer-graphics-from-scratch/00-introduction.html 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.

mrVentures 5y ago

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

Jensson 5y ago

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.

t8y 5y ago

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.

Danieru 5y ago
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.
- fsloth 5y ago
  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.
  - y4mi 5y ago
    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
    - AnIdiotOnTheNet 5y ago
      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.
    - 5y ago

throwawaysea 5y ago

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

danschuller 5y ago

Unity render pipeline source is available here: https://github.com/Unity-Technologies/Graphics https://github.com/Unity-Technologies/Graphics All the C# code running in the editor and runtimes is here: https://github.com/Unity-Technologies/UnityCsReference 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/RenderDocIntegration.html https://docs.unity3d.com/Manual/FrameDebugger.html https://docs.unity3d.com/Manual/FrameDebugger.html