5 ms·

I'd recommend the Pikuma course Graphics From Scratch[0]. The first thing you do is write a set_pixel function utilizing SDL and the rest of the course is all y

I'd recommend the Pikuma course Graphics From Scratch[0]. The first thing you do is write a set_pixel function utilizing SDL and the rest of the course is all your code, every matrix operation, every vertex transformation, every triangle rasterization. You calculate what every individual pixel should be colored. [0]: https://pikuma.com/courses/learn-3d-computer-graphics-programming https://pikuma.com/courses/learn-3d-computer-graphics-progra...

charcircuit 3y ago
>No GPU, no OpenGL, no DirectX! This is the opposite of what you would hope to see for learning graphics programming.
- CountHackulus 3y ago
  I disagree. It's good to understand what the GPU is doing at scale before jumping in too deep. It's obviously not how you do your day-to-day work, but it helps you understand what's going on at a deeper level.
- robomartin 3y ago
  Believe it or not, we were doing graphics without any of those things a very long time ago. Learning fundamentals is really important. You can always learn easier ways to do things later. For example, area fill algorithms are really interesting. Etc.
- ChuckMcM 3y ago
  I feel like this comment perfectly captures the difference between programming and coding. Programming comes from a place of first principles, the goal being to understand what is needed completely so that a solution that meets many parallel constraints can be constructed. Coding comes from a place of completing a task, the goal being to get from the requirement to the operating task in as short a time as possible so that one might move on to the next task. Both disciplines have value. The original question was unclear about where the author hoped to end up. To put this in a slightly different perspective, a graphics programmer can write a program to show a shaded object on any platform with a CPU and a way to display graphics. A graphics coder can write a program to show a shaded object only on those platforms where they have previously mastered the APIs for generating display graphics.
  - NikolaNovak 3y ago
    I like the distinction, and I think there should exist different terms, but I don't think those two are nearly universal. Many people will use them interchangeably, others may even think other way around ("programming" as a professional discipline where you use tools to achieve an MVP most efficiently, vs "coding" as an enthusiastic activity that's more creative and open ended).
  - charcircuit 3y ago
    Your definitions are made up. Programming refers to the act of writing a program for a computer to follow. Coding refers to the act of writing code for a computer. Edit: The definitions are not commonly used this way and in fact I've heard other people even give opposite definitions to what correponds to which word.
    - javajosh 3y ago
      Hate to break it to you, but all definitions are made up. The question is whether or not the distinction is useful or not. In my opinion, it seems useful to distinguish between understanding oriented tasks and goal oriented tasks.
  - dragontamer 3y ago
    2D graphics with bitblits is a completely different paradigm. If you were using 2D GPUs from the 90s, or maybe a 2D Industrial PC's GPU, sure... Learning about Bitblits and rects is good. But if your goal is to program a modern shader on a modern platform (even if it's a 2D graphic), you should learn a modern graphics library. ------- A modern graphics API is laid out the way it is: to maximize modern performance on modern systems. A first principles bottom up approach will absolutely cover shaders (maybe compute shaders are easiest?)
    - crq-yml 3y ago
      There's a lot of leeway to learn 3D principles through a basic software rasterizer. It does not take long - if you already have some awareness of the math, it's at most a few weeks to work through the essentials from a tutorial. Once you get to the point where you're drawing filled triangles through a projected camera, you can move on. There's no need to go into occlusion culling strategies, texture mapping or lighting calculations, or really to make the rasterizer fast in any way. That wouldn't be the point of the exercise. It could be done entirely with a fixed-size bitmap and a setPixel(x, y, v) call. The argument against "just" using the hardware is that the hardware resists learning that conceptual skeleton. Instead of learning how a rasterizer is implemented, you learn the specific API incantation to bring one up, and that has changed a lot over the years in the direction of being a more professionalized phenomenon, so now it's much easier to start application top-down, from within a premade rendering environment like a game engine or Blender's rasterizers. Learning to work on production rendering engines would involve reading and studying existing implementations, reading the relevant research papers along the way.
- moron4hire 3y ago
  It's what my graphics courses in my computer science degree did. The skills I learned have benefitted me long after (20 years), and I mostly "just" do web development.
- delta_p_delta_x 3y ago
  Personally... I disagree. The course says: > You'll learn how a software 3D engine works under the hood, and ... write a complete software rasterizer from scratch Writing a software rasteriser is a fantastic way to learn the classic graphics pipeline, Every single aspect of said pipeline offers scope for one to learn more about how GPUs work, and the algorithms behind them. This would be immensely educational to a new graphics developer. Vertex processing, including fast, efficient file parsing, vertex data layout and storage, and optimisation. Fast primitive assembly from vertices, including line-drawing and interpolation algorithms. Texture mipmapping, and mapping. The rasterisation phase itself offers tons of opportunity, from Bresenham's line drawing algorithm to supersampling, tiled rendering, parallelisation, and efficient memory layouts for cache locality. Clipping, culling, hidden-surface removal, z-buffering, and stencil tests. Various other algorithms that are taken for granted with a pre-existing graphics pipeline, like texture lookup, vector reflection, environment mapping. Post-processing and miscellaneous algorithms like anisotropic filtering, multi-sample anti-aliasing, temporal anti-aliasing, and even deferred rendering.
  - charcircuit 3y ago
    If you want to learn webdev you don't start by building a web browser despite the fact that building a web browser would teach you a lot.
    - delta_p_delta_x 3y ago
      Web dev is sufficiently abstracted from the browser and the hardware that a skilled web developer doesn't really need to know the internals of the V8 engine or how a browser works. A web back-end developer probably doesn't need to deal with the browser at all. Graphics programming skill (by 'skill', I mean being able to write a shader pipeline that both satisfies the art direction and performs well), on the contrary, is very deeply tied to a good understanding of hardware. Especially now that the new APIs (Vulkan, Metal, D3D12) are purposely less abstracted than their predecessors.
      - charcircuit 3y ago
- throwawee 3y ago
  Agreed. I've seen beginners fall into the trap of spending way too much time on software rendering that won't be useful or performant later because every platform they'll ever develop for has hardware accelerated rendering. I learned how to painstakingly render scenes pixel by pixel and then had to unlearn it because graphics programming doesn't work that way anymore. Teaching beginners to render graphics without the GPU is like teaching them to do fractional math without the FPU. It won't make their first project better and gives them the wrong idea of what to expect.
- virtualritz 3y ago
  >> No GPU, no OpenGL, no DirectX! > This is the opposite of what you would hope to see for learning graphics programming. It is exactly what you would hope to see. And I would dare say I'm a graphics programmer, mostly self taught. When I started, as a teenager, in the late 80's, there were no GPUs. So I learned everything from first principles. I recall implementing Bresenham in x86 assembly for my CGA card. And then, as a follow up, rasterizing a triangle. You really had to understand stuff end-to-end then as the hardware was so slow. I.e. even C was too slow for that stuff. And today, still, the best offline renderers, that produce the images you see on the big screen, are CPU-only. 100% custom code, no 3rd party API dependency.[1] If you write stuff for CAD/CAM/CAE/VFX, there is a big chance you do not think about the constraints of a GPU and less so of one of the APIs used to program it. Except for previewing stuff. I would suggest to anyone learning graphics programming (or anything else for that matter) to do so from first principles. GPUs are specialized hardware for realtime applications. That is very specific. I don't say don't learn that. But I suggest to not start with it. [1] One of my best friends is the lead developer of the 3Delight renderer.
  - crq-yml 3y ago
    My little spot of nuance on this reply would be that the point of starting in software would not be to aim for a fast or feature-rich implementation. That seems to be the sticking point of the replies in favor of going hardware-first - that "we don't optimize the same way anymore". But nobody was asking about optimizing! People seem to go performance-brained when they talk about graphics because they read about John Carmack once. Then they go right back to their Javascript frameworks. Like any student engineering project, "baby's first rasterizer" would emphasize a combination of concepts and motions - a path to take, to get to a result that can be tested. We don't even have to use Bresenham now - deriving the rasterized line from linear interpolation is mathematically more sound and no sweat for modern CPUs. But it might be pedagogically useful to compare the two to explain quality vs performance tradeoffs, ones that were made historically and those that are still in use today.
starmole 3y ago
I find this very interesting. I have been toying around how I would design a graphics 101 course myself. Should it start with putpixel style sdl code like we did in the 90s? Or start with shadertoy? Of course basic matrix math is always important. But how to teach rasterizing a triangle? Can we skip to homogenous coordinates and quad trees without going through scan lines? Should we really teach Phong shading or can we move straight to BRDFs? Some parts might be teaching "old hacks" instead of relevant skills. Statistics and sampling are way more important today. I believe graphics is getting more "mathy" every year. So learn math, teach math.
- corysama 3y ago
  I started with putting pixels in MCGA to CPU rasterize phong shaded triangles, and I don’t recommend it. Instead, I’d recommend https://learnopengl.com/ https://learnopengl.com/ https://raytracing.github.io/books/RayTracingInOneWeekend.html https://raytracing.github.io/books/RayTracingInOneWeekend.ht... https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-... https://foundationsofgameenginedev.com/ https://foundationsofgameenginedev.com/ https://youtu.be/j-A0mwsJRmk https://youtu.be/j-A0mwsJRmk Though, if you really do want to put pixels, this is how you should do it: https://gist.github.com/CoryBloyd/6725bb78323bb1157ff8d4175d42d789 https://gist.github.com/CoryBloyd/6725bb78323bb1157ff8d4175d...
rmshin 3y ago
Just wanted to second this recommendation. I did the course a few months ago with near-zero baseline in graphics programming (though a few years' experience as a standard swe), and it gave me a pretty decent grasp of how 3d shapes get drawn on the screen. Afterwards I was able to pick up webgpu in a matter of days, which I don't think would've been possible without the understanding I gained from the course. If anyone's looking for motivation, I made a wasm-compiled demo of the renderer you produce by the end - https://rmshin.github.io/3d-renderer-wasm https://rmshin.github.io/3d-renderer-wasm
torginus 3y ago
There are a couple of excellent resources out there for implementing 3D rendering from scratch. On that I cannot recommend enough is this github repo: https://github.com/ssloy/tinyrenderer/wiki/Lesson-0:-getting-started https://github.com/ssloy/tinyrenderer/wiki/Lesson-0:-getting... If you are more of a visual learner, this guy is also a treasure trove: https://www.youtube.com/watch?v=ih20l3pJoeU https://www.youtube.com/watch?v=ih20l3pJoeU
- ggambetta 3y ago
  Wow, that first link is fantastic, thanks for sharing!
ggambetta 3y ago
My website/book/course does the same thing, and it's freeeeeee! https://www.gabrielgambetta.com/computer-graphics-from-scratch https://www.gabrielgambetta.com/computer-graphics-from-scrat...
- atan2 3y ago
  I have your book. It's a great read but I would not say it's "the same thing." :) People pay for a specific teaching style and that's absolutely fine.
  - johnnyanmac 3y ago
    nothing wrong with seeing if the freeeee alternative works better before throwing out $70 tho.
    - atan2 3y ago
      Of course. Still, I thought it was worth clarifying that they are different so we don't automatically discourage people from trying out good content.
  - ggambetta 3y ago
    Oh, absolutely. I meant "the same" in the sense that it covers roughly the same material and follows roughly the same approach (building everything from putPixel()).

charcircuit 3y ago

>No GPU, no OpenGL, no DirectX! This is the opposite of what you would hope to see for learning graphics programming.

CountHackulus 3y ago
I disagree. It's good to understand what the GPU is doing at scale before jumping in too deep. It's obviously not how you do your day-to-day work, but it helps you understand what's going on at a deeper level.
robomartin 3y ago
Believe it or not, we were doing graphics without any of those things a very long time ago. Learning fundamentals is really important. You can always learn easier ways to do things later. For example, area fill algorithms are really interesting. Etc.
ChuckMcM 3y ago
I feel like this comment perfectly captures the difference between programming and coding. Programming comes from a place of first principles, the goal being to understand what is needed completely so that a solution that meets many parallel constraints can be constructed. Coding comes from a place of completing a task, the goal being to get from the requirement to the operating task in as short a time as possible so that one might move on to the next task. Both disciplines have value. The original question was unclear about where the author hoped to end up. To put this in a slightly different perspective, a graphics programmer can write a program to show a shaded object on any platform with a CPU and a way to display graphics. A graphics coder can write a program to show a shaded object only on those platforms where they have previously mastered the APIs for generating display graphics.
- NikolaNovak 3y ago
  I like the distinction, and I think there should exist different terms, but I don't think those two are nearly universal. Many people will use them interchangeably, others may even think other way around ("programming" as a professional discipline where you use tools to achieve an MVP most efficiently, vs "coding" as an enthusiastic activity that's more creative and open ended).
- charcircuit 3y ago
  Your definitions are made up. Programming refers to the act of writing a program for a computer to follow. Coding refers to the act of writing code for a computer. Edit: The definitions are not commonly used this way and in fact I've heard other people even give opposite definitions to what correponds to which word.
  - javajosh 3y ago
    Hate to break it to you, but all definitions are made up. The question is whether or not the distinction is useful or not. In my opinion, it seems useful to distinguish between understanding oriented tasks and goal oriented tasks.
- dragontamer 3y ago
  2D graphics with bitblits is a completely different paradigm. If you were using 2D GPUs from the 90s, or maybe a 2D Industrial PC's GPU, sure... Learning about Bitblits and rects is good. But if your goal is to program a modern shader on a modern platform (even if it's a 2D graphic), you should learn a modern graphics library. ------- A modern graphics API is laid out the way it is: to maximize modern performance on modern systems. A first principles bottom up approach will absolutely cover shaders (maybe compute shaders are easiest?)
  - crq-yml 3y ago
    There's a lot of leeway to learn 3D principles through a basic software rasterizer. It does not take long - if you already have some awareness of the math, it's at most a few weeks to work through the essentials from a tutorial. Once you get to the point where you're drawing filled triangles through a projected camera, you can move on. There's no need to go into occlusion culling strategies, texture mapping or lighting calculations, or really to make the rasterizer fast in any way. That wouldn't be the point of the exercise. It could be done entirely with a fixed-size bitmap and a setPixel(x, y, v) call. The argument against "just" using the hardware is that the hardware resists learning that conceptual skeleton. Instead of learning how a rasterizer is implemented, you learn the specific API incantation to bring one up, and that has changed a lot over the years in the direction of being a more professionalized phenomenon, so now it's much easier to start application top-down, from within a premade rendering environment like a game engine or Blender's rasterizers. Learning to work on production rendering engines would involve reading and studying existing implementations, reading the relevant research papers along the way.
moron4hire 3y ago
It's what my graphics courses in my computer science degree did. The skills I learned have benefitted me long after (20 years), and I mostly "just" do web development.
delta_p_delta_x 3y ago
Personally... I disagree. The course says: > You'll learn how a software 3D engine works under the hood, and ... write a complete software rasterizer from scratch Writing a software rasteriser is a fantastic way to learn the classic graphics pipeline, Every single aspect of said pipeline offers scope for one to learn more about how GPUs work, and the algorithms behind them. This would be immensely educational to a new graphics developer. Vertex processing, including fast, efficient file parsing, vertex data layout and storage, and optimisation. Fast primitive assembly from vertices, including line-drawing and interpolation algorithms. Texture mipmapping, and mapping. The rasterisation phase itself offers tons of opportunity, from Bresenham's line drawing algorithm to supersampling, tiled rendering, parallelisation, and efficient memory layouts for cache locality. Clipping, culling, hidden-surface removal, z-buffering, and stencil tests. Various other algorithms that are taken for granted with a pre-existing graphics pipeline, like texture lookup, vector reflection, environment mapping. Post-processing and miscellaneous algorithms like anisotropic filtering, multi-sample anti-aliasing, temporal anti-aliasing, and even deferred rendering.
- charcircuit 3y ago
  If you want to learn webdev you don't start by building a web browser despite the fact that building a web browser would teach you a lot.
  - delta_p_delta_x 3y ago
    Web dev is sufficiently abstracted from the browser and the hardware that a skilled web developer doesn't really need to know the internals of the V8 engine or how a browser works. A web back-end developer probably doesn't need to deal with the browser at all. Graphics programming skill (by 'skill', I mean being able to write a shader pipeline that both satisfies the art direction and performs well), on the contrary, is very deeply tied to a good understanding of hardware. Especially now that the new APIs (Vulkan, Metal, D3D12) are purposely less abstracted than their predecessors.
    - charcircuit 3y ago
throwawee 3y ago
Agreed. I've seen beginners fall into the trap of spending way too much time on software rendering that won't be useful or performant later because every platform they'll ever develop for has hardware accelerated rendering. I learned how to painstakingly render scenes pixel by pixel and then had to unlearn it because graphics programming doesn't work that way anymore. Teaching beginners to render graphics without the GPU is like teaching them to do fractional math without the FPU. It won't make their first project better and gives them the wrong idea of what to expect.
virtualritz 3y ago
>> No GPU, no OpenGL, no DirectX! > This is the opposite of what you would hope to see for learning graphics programming. It is exactly what you would hope to see. And I would dare say I'm a graphics programmer, mostly self taught. When I started, as a teenager, in the late 80's, there were no GPUs. So I learned everything from first principles. I recall implementing Bresenham in x86 assembly for my CGA card. And then, as a follow up, rasterizing a triangle. You really had to understand stuff end-to-end then as the hardware was so slow. I.e. even C was too slow for that stuff. And today, still, the best offline renderers, that produce the images you see on the big screen, are CPU-only. 100% custom code, no 3rd party API dependency.[1] If you write stuff for CAD/CAM/CAE/VFX, there is a big chance you do not think about the constraints of a GPU and less so of one of the APIs used to program it. Except for previewing stuff. I would suggest to anyone learning graphics programming (or anything else for that matter) to do so from first principles. GPUs are specialized hardware for realtime applications. That is very specific. I don't say don't learn that. But I suggest to not start with it. [1] One of my best friends is the lead developer of the 3Delight renderer.
- crq-yml 3y ago
  My little spot of nuance on this reply would be that the point of starting in software would not be to aim for a fast or feature-rich implementation. That seems to be the sticking point of the replies in favor of going hardware-first - that "we don't optimize the same way anymore". But nobody was asking about optimizing! People seem to go performance-brained when they talk about graphics because they read about John Carmack once. Then they go right back to their Javascript frameworks. Like any student engineering project, "baby's first rasterizer" would emphasize a combination of concepts and motions - a path to take, to get to a result that can be tested. We don't even have to use Bresenham now - deriving the rasterized line from linear interpolation is mathematically more sound and no sweat for modern CPUs. But it might be pedagogically useful to compare the two to explain quality vs performance tradeoffs, ones that were made historically and those that are still in use today.

starmole 3y ago

I find this very interesting. I have been toying around how I would design a graphics 101 course myself. Should it start with putpixel style sdl code like we did in the 90s? Or start with shadertoy? Of course basic matrix math is always important. But how to teach rasterizing a triangle? Can we skip to homogenous coordinates and quad trees without going through scan lines? Should we really teach Phong shading or can we move straight to BRDFs? Some parts might be teaching "old hacks" instead of relevant skills. Statistics and sampling are way more important today. I believe graphics is getting more "mathy" every year. So learn math, teach math.

corysama 3y ago
I started with putting pixels in MCGA to CPU rasterize phong shaded triangles, and I don’t recommend it. Instead, I’d recommend https://learnopengl.com/ https://learnopengl.com/ https://raytracing.github.io/books/RayTracingInOneWeekend.html https://raytracing.github.io/books/RayTracingInOneWeekend.ht... https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-... https://foundationsofgameenginedev.com/ https://foundationsofgameenginedev.com/ https://youtu.be/j-A0mwsJRmk https://youtu.be/j-A0mwsJRmk Though, if you really do want to put pixels, this is how you should do it: https://gist.github.com/CoryBloyd/6725bb78323bb1157ff8d4175d42d789 https://gist.github.com/CoryBloyd/6725bb78323bb1157ff8d4175d...

rmshin 3y ago

Just wanted to second this recommendation. I did the course a few months ago with near-zero baseline in graphics programming (though a few years' experience as a standard swe), and it gave me a pretty decent grasp of how 3d shapes get drawn on the screen. Afterwards I was able to pick up webgpu in a matter of days, which I don't think would've been possible without the understanding I gained from the course. If anyone's looking for motivation, I made a wasm-compiled demo of the renderer you produce by the end - https://rmshin.github.io/3d-renderer-wasm https://rmshin.github.io/3d-renderer-wasm

torginus 3y ago

There are a couple of excellent resources out there for implementing 3D rendering from scratch. On that I cannot recommend enough is this github repo: https://github.com/ssloy/tinyrenderer/wiki/Lesson-0:-getting-started https://github.com/ssloy/tinyrenderer/wiki/Lesson-0:-getting... If you are more of a visual learner, this guy is also a treasure trove: https://www.youtube.com/watch?v=ih20l3pJoeU https://www.youtube.com/watch?v=ih20l3pJoeU

ggambetta 3y ago
Wow, that first link is fantastic, thanks for sharing!

ggambetta 3y ago

My website/book/course does the same thing, and it's freeeeeee! https://www.gabrielgambetta.com/computer-graphics-from-scratch https://www.gabrielgambetta.com/computer-graphics-from-scrat...

atan2 3y ago
I have your book. It's a great read but I would not say it's "the same thing." :) People pay for a specific teaching style and that's absolutely fine.
- johnnyanmac 3y ago
  nothing wrong with seeing if the freeeee alternative works better before throwing out $70 tho.
  - atan2 3y ago
    Of course. Still, I thought it was worth clarifying that they are different so we don't automatically discourage people from trying out good content.
- ggambetta 3y ago
  Oh, absolutely. I meant "the same" in the sense that it covers roughly the same material and follows roughly the same approach (building everything from putPixel()).