4 ms·

If I understood correctly, this is CPU-based, use of GPUs is not covered? How useful is this approach? Does it necessitate "unlearning" some ideas when transiti

by nsajko 6y ago

If I understood correctly, this is CPU-based, use of GPUs is not covered? How useful is this approach? Does it necessitate "unlearning" some ideas when transitioning to something like Vulkan?

vanattab 6y ago
I can't speak to this tutorial specifically but I have done many opengl and directx tutorials over the years and some of the best took a api agnostic approach.
- vmmenon 6y ago
  if you had to recommend one book, which would it be for someone starting off with graphics for the first time.
  - neverartful 6y ago
    I'd recommend "Computer Graphics: Principles and Practice" by Foley and van Dam. It's highly regarded and is on 2nd or 3rd revision.
    - pjmlp 6y ago
      I do as well, it is a standard reference in graphics programming at university level. First edition used Pascal, then C and the third uses a mix of C++ and C#.
  - jackhack 6y ago
    Michael Abrash's Graphics Programming Black Book https://www.drdobbs.com/parallel/graphics-programming-black-book/184404919 https://www.drdobbs.com/parallel/graphics-programming-black-... released online for free in 2001
anon946 6y ago
From what I could see in the table of contents, this is at a different level. Basically, this teaches you the concepts used to implement something like Vulkan. They probably implement a software Z-buffer, while a graphics card will do much of it in hardware. To be honest, it's fairly specialized knowledge, though fundamental.
myth_drannon 6y ago
This is fundamentals course, so you understand how DirectX or OpenGL work under the hood for example. That's how games in the 90's were written. If you are into oldschool graphics then it's a cool course. He has also raycasting courses and Atari graphics.
pfranz 6y ago
Usually graphics APIs abstract away these core concepts, but there's a lot of shifting responsibility between what you do and what the API/GPU does. It's good to have an idea what they're doing so you can better utilize the APIs, compare two different approaches, and often you'll find yourself hand-rolling aspects (like writing an exporter from something like Maya to be used in a realtime engine or converting Y-up data to Z-up data before sending it along).
veenusav 6y ago
Seems like this course is for understanding how vectors are translated into rasters. I guess it is single threaded. On the other hand, with normal graphics programming, where OpenGL or Direct X with GPU hardware does these things for us, execution is parallel. With this course we will get the fundamentals strong. Still for high quality light processing, ray tracing is the king. The course is good with this aspect. But you have to unlearn everything to avoid prejudice to get accustomed with the massively parallel GPU environment. That is the faster and economic way for real-time rasterization. That is a point of caution. Or rather an aspect to consider spending time on this non parallel algorithms. If this course discusses parallel things, cpu is only multi-core, not manycore like GPU, so cannot give real-time performance. However, I am assuming everything from the course-outline!
moron4hire 6y ago
I would actually say that learning to implement a software rasterizer was less relevant in the days of fixed-function pipeline GPUs than it is today now that shaders are ubiquitous. GPUs and graphics APIs used to have to implement a huge number of graphics features for you to get anything on the screen. You used to give the GPU your vertices that defined polygons, colors at each of those vertices, textures (and texture coordinates for each of the vertices) and few parameters to control some interpolation math, and then the GPU did everything to put them on the screen. Features like fog and lights and shadows all needed a specific function to perform them, and you didn't have a lot of control over how exactly it would work. If you wanted to do crazy stuff like non-Euclidean warping of space, you were basically not going to do that on the GPU. Shaders were invented sometime in the late 80s (originally as a CPU-based rendering system, IIRC) but they didn't really hit the game industry until about 15 years ago, and it took some time after that for them to get popular, both for hardware to propagate in the market and because it was a pretty huge departure from before. The GPU does a lot less for you, now. Instead of giving you functions to specify numeric constants that control output, it gives you a block of memory and a space to run code to use that memory in a structured way. Whereas before you would give the GPU your projection and camera and model matrices and it would transform things for you, now it doesn't care how you define the transforms, you put whatever matrix or some other construct you want into memory and you do the math (well, at the algebraic level. You don't implement matrix multiplication) to transform the vertices. You want a light in the scene? The GPU doesn't even know what a light is anymore. Your "light" is a color and intensity value you load into the GPUs memory and then you write the code that figures out what color a lit polygon will be. It doesn't know what fog is, what shadows are, what bump/normal/displacement maps are, any of it. To the GPU, all of that stuff is just big blocks of numbers that it lets you run your own code over. The GPU still has a black box function for converting polygons to pixels (or rather, fragments as they are now called, as they don't necessarily map 1-to-1 anymore). This is the strictest definition of "rasterizarion", but it's a small part of the whole process and a "software rasterizer" does a lot more than just rasterization. All of those things that aren't just figuring out pixel coverage of polygons, this are pretty much up to you, and learning to do it in a software rasterizer can be great for learning, because graphics APIs aren't exactly the nicest things to work with. Even still, if you never end up writing shaders, I think there is a lot of good to learn in the process. You might find yourself in a situation where all you have is a 2D graphics library and you need to create 3D-looking effects, for generating static images or lighting up grids of LEDs connected to a microcontroller (both examples of places I've personally used the stuff I learned in college... 15 years ago). As a loose analogy to a non-graphics topic, fixed-function pipeline GPUs were like SQL engines. They gave you declarative means of controlling state on the GPU. If what you wanted to do didn't have a function for it in the engine, you were in for a bad day. Programmable-pipeline GPUs are like Hadoop clusters. There is some data and you define some kind of pure function that map/reduce over it. It's more work for you for simple things, but it provides you the maximum flexibility to do creative things.

by nsajko 6y ago

If I understood correctly, this is CPU-based, use of GPUs is not covered? How useful is this approach? Does it necessitate "unlearning" some ideas when transitioning to something like Vulkan?

vanattab 6y ago

I can't speak to this tutorial specifically but I have done many opengl and directx tutorials over the years and some of the best took a api agnostic approach.

vmmenon 6y ago
if you had to recommend one book, which would it be for someone starting off with graphics for the first time.
- neverartful 6y ago
  I'd recommend "Computer Graphics: Principles and Practice" by Foley and van Dam. It's highly regarded and is on 2nd or 3rd revision.
  - pjmlp 6y ago
    I do as well, it is a standard reference in graphics programming at university level. First edition used Pascal, then C and the third uses a mix of C++ and C#.
- jackhack 6y ago
  Michael Abrash's Graphics Programming Black Book https://www.drdobbs.com/parallel/graphics-programming-black-book/184404919 https://www.drdobbs.com/parallel/graphics-programming-black-... released online for free in 2001

anon946 6y ago

From what I could see in the table of contents, this is at a different level. Basically, this teaches you the concepts used to implement something like Vulkan. They probably implement a software Z-buffer, while a graphics card will do much of it in hardware. To be honest, it's fairly specialized knowledge, though fundamental.

myth_drannon 6y ago

This is fundamentals course, so you understand how DirectX or OpenGL work under the hood for example. That's how games in the 90's were written. If you are into oldschool graphics then it's a cool course. He has also raycasting courses and Atari graphics.

pfranz 6y ago

Usually graphics APIs abstract away these core concepts, but there's a lot of shifting responsibility between what you do and what the API/GPU does. It's good to have an idea what they're doing so you can better utilize the APIs, compare two different approaches, and often you'll find yourself hand-rolling aspects (like writing an exporter from something like Maya to be used in a realtime engine or converting Y-up data to Z-up data before sending it along).

veenusav 6y ago

Seems like this course is for understanding how vectors are translated into rasters. I guess it is single threaded. On the other hand, with normal graphics programming, where OpenGL or Direct X with GPU hardware does these things for us, execution is parallel. With this course we will get the fundamentals strong. Still for high quality light processing, ray tracing is the king. The course is good with this aspect. But you have to unlearn everything to avoid prejudice to get accustomed with the massively parallel GPU environment. That is the faster and economic way for real-time rasterization. That is a point of caution. Or rather an aspect to consider spending time on this non parallel algorithms. If this course discusses parallel things, cpu is only multi-core, not manycore like GPU, so cannot give real-time performance. However, I am assuming everything from the course-outline!

moron4hire 6y ago

I would actually say that learning to implement a software rasterizer was less relevant in the days of fixed-function pipeline GPUs than it is today now that shaders are ubiquitous. GPUs and graphics APIs used to have to implement a huge number of graphics features for you to get anything on the screen. You used to give the GPU your vertices that defined polygons, colors at each of those vertices, textures (and texture coordinates for each of the vertices) and few parameters to control some interpolation math, and then the GPU did everything to put them on the screen. Features like fog and lights and shadows all needed a specific function to perform them, and you didn't have a lot of control over how exactly it would work. If you wanted to do crazy stuff like non-Euclidean warping of space, you were basically not going to do that on the GPU. Shaders were invented sometime in the late 80s (originally as a CPU-based rendering system, IIRC) but they didn't really hit the game industry until about 15 years ago, and it took some time after that for them to get popular, both for hardware to propagate in the market and because it was a pretty huge departure from before. The GPU does a lot less for you, now. Instead of giving you functions to specify numeric constants that control output, it gives you a block of memory and a space to run code to use that memory in a structured way. Whereas before you would give the GPU your projection and camera and model matrices and it would transform things for you, now it doesn't care how you define the transforms, you put whatever matrix or some other construct you want into memory and you do the math (well, at the algebraic level. You don't implement matrix multiplication) to transform the vertices. You want a light in the scene? The GPU doesn't even know what a light is anymore. Your "light" is a color and intensity value you load into the GPUs memory and then you write the code that figures out what color a lit polygon will be. It doesn't know what fog is, what shadows are, what bump/normal/displacement maps are, any of it. To the GPU, all of that stuff is just big blocks of numbers that it lets you run your own code over. The GPU still has a black box function for converting polygons to pixels (or rather, fragments as they are now called, as they don't necessarily map 1-to-1 anymore). This is the strictest definition of "rasterizarion", but it's a small part of the whole process and a "software rasterizer" does a lot more than just rasterization. All of those things that aren't just figuring out pixel coverage of polygons, this are pretty much up to you, and learning to do it in a software rasterizer can be great for learning, because graphics APIs aren't exactly the nicest things to work with. Even still, if you never end up writing shaders, I think there is a lot of good to learn in the process. You might find yourself in a situation where all you have is a 2D graphics library and you need to create 3D-looking effects, for generating static images or lighting up grids of LEDs connected to a microcontroller (both examples of places I've personally used the stuff I learned in college... 15 years ago). As a loose analogy to a non-graphics topic, fixed-function pipeline GPUs were like SQL engines. They gave you declarative means of controlling state on the GPU. If what you wanted to do didn't have a function for it in the engine, you were in for a bad day. Programmable-pipeline GPUs are like Hadoop clusters. There is some data and you define some kind of pure function that map/reduce over it. It's more work for you for simple things, but it provides you the maximum flexibility to do creative things.