I just found your Video because I am working with OpenGL and I really like it! Wish there was more in-depth content about the different shaders and everything. Nice work!
@@FloatyMonkey I teach Intro to Computer Graphics and Graphics Programming. How do you make your videos? If you had a course on that I would gladly pay for it.
The visualizations are made in PowerPoint. It sounds silly, but the idea behind it is that you can use them in front of a live audience. I do not have a course on it but all the PowerPoints are available to Patrons for only €8/month. Unfortunatly my Patreon is subscription based but you can always download the files and cancel the subscription immediatly afterwards.
@@FloatyMonkey I’m happy to contribute $8 and maybe some BAT if you take that. I really appreciate you taking the time to thoughtfully respond. Your PowerPoint-Fu is strong.
Haha thanks, and no problem. I love to explain and engage with my audience in what I'm passionate about. Just becoming (my first) Patron, would already mean a lot, especially since you're a teacher/professor. Knowing my videos could be usefull to students is absolutly delightfull.
So well explained! I've just started a youtube channel about retro technologies and systems, for Brazilians, and I would love to know how software did you use to animate those arrows ;). Thx
Do you tutor? I like how detailed you are but there were some areas that were vague for me, like the fact that the output vectors of a vector shader on some input vertex would fall within the range -1
Thanks. The inactivity is just due to a lack of time. By this summer, I hope to make some video’s about my optical motion capture system, a project I’ve been working on since October 2020. I decided to post updates about it on the Discord, go have a look if you’re interested.
Thanks. Between a full time job, writing a game engine and building a diy lighstage and motion capture system I haven't had much time to make video's this past year, although I now have a lot of interesting topics to cover. I definitely want to get back into it, hopefully by end of this year ...
Hello FloatyMonkey, your channel is really great and I found the videos very informative. Thank you. I have a question about Tesselation. Why is Tesselation required here..since vertex shader already gets data that are vertices of triangles ?
That's a great question. The advantage of tesselation is that it runs entirely on the GPU. This means you don't have to transfer the extra vertices from the CPU to the GPU over their relatively slow PCIe connection. On top of that there's less GPU memory required to store the model since the result of the tesselation is immediatly discarded after a specific model has been drawn. It obviously introduces some computational overhead but the advantages far outweigh the disadvantages. These days we can migrate away from the tesselation and geometry shaders however with a new shader stage called Mesh Shaders. Something I will probably talk about in the future.
@@FloatyMonkey Thank you for a great explanation. In another of your video titled "how triangles make up 3D models" you talk about 'Triangulation'. How is Triangulation differnt from Tesselation ?
Triangulation is the process of taking an arbitrary polygon (quad, octagon, ...) and turning it into the minimal amount of triangles that represents that polygon, this is required since GPUs prefer to work with triangles only. Tesselation is the process of taking a single triangle and dividing it in a bunch of other triangles which can be displaced in 3d space to add extra geometric detail.
Hello! It's a great video and I would have a question. Where all the advanced lighting techniques are being processed? Is that at the pixel shader too? Thank you
I have a couple questions, hopefully its clear without visualization here: 1. Does the rasterizer produce multiple fragments/pixels with the same position? For example, where the blue and red triangles overlap, would there be a fragment with the blue triangle attributes and one with the red triangle attributes in the same overlapping position? i.e. {position = (2, 3), color = blue, depth = 0.1}, {position= (2, 3), color = red, depth = 0.5} 2. If there are fragments with duplicate positions, does this mean that the Fragment/Pixel shader will run on the same fragment position multiple times even though in the following stage (output merger) the result of the red fragment being shaded will be thrown away (because its in the back)? Thank you
Great questions. The pixel (fragment) shader can run multiple times for a single pixel, obviously each time calculating the color of a different primitive. These colors either get blended or discarded by the output merger. The latter isn't very efficient in case of overlapping opaque geometry since a lot of work gets thrown away. That's one of the reasons why we use a depth buffer, which can be used to determine whether a pixel shader invocation will get discarded before it actually runs. A finel method to reduce overdraw (the name for this phenomenon) is to render geometry from front to back. This makes sure foreground geometry writes to the depth buffer first so that geometry behind it gets discarded before rendering. Hope this makes sense ;)
Probably something I missed, but where does the perspective projection take place? Wherever you mentioned the vertices they were described with x,y,z not x,y
It happens in the vertex shader (shown at 4:40 on the first line of the main function). We actually do pass the entire result of Vertex * ViewProjectionMatrix to the GPU. In that case x,y describes the vertex position in normalized coordinates in range (-1, 1) and z describes the depth in range (0, 1). This depth value is still needed to determine if the shaded fragment is visible.
@@FloatyMonkey Thanks a lot! I am creating various lecture contents. First of all, I will conduct a webinar for shader development. ruclips.net/video/r_eatgPFQYg/видео.html
I don't speak Korean but that looked great! Going on the visuals, you managed to touch upon all the preliminaries of shader development in a very short time.
7:37 That's not really a sufficient explanation. Generating the locations of the vertices of your blender mesh is also not possible on a graphics card, but the CPU sets it up for the GPU; just because the GPU can't do something doesn't explain why it's not done. So, why doesn't the CPU just sort the triangles? The real one-sentence explanation is "Unfortunately, we can't solve this problem by changing the order in which we draw the triangles, *since it's way too expensive to sort hundreds of thousands of triangles, every single frame*. The solution to our problem...". As a secondary issue, if you have a triplet of long rectangles where A covers B, B covers C, and C covers A, that triplet can't be resolved without a Z-buffer either. But that's a rare case and generally not the "real" reason, it's just too expensive to compare overlapping triangles and re-sort them all every single frame.
@@FloatyMonkey ahh did't know, so sorry! it's a dark blue with a shade of grey,, but more blue than that. Anyhow, thanks for your videos, I added about 5 of them to a curriculum playlist I'm making for some future newcomers at my workplace!
0:50 LOL software rendering go brrr 3:10 If 16-bits is conventionally used... how do modern 3D graphics work? I mean, games have exceeded 65,536 vertices per frame since the early 2000s, and 65,536 vertices per object for somewhat less time. Do engines swap out vertices mid-frame like was done for sprites and palletes for ambitious games on sprite-based hardware? 4:35 ...why? Doesn't sound like a very useful range for display purposes at all. 6:25 You _could_ use Bresenham's line algorithm or something instead of constructing triangles for that purpose. 7:50 Huh... So the RTX 4090-or for a video-contemporary example, the Titan RTX-is less capable in a respect than, say, the Atari VCS/2600's TIA?! (Sprite-based graphics hardware allows for direct draw-ordering of sprites, AFAIK without exception because without vertex-level depth information, there's really no other method to handle depth. This was also done for polygons on the first generation of console "3D" video processors {that is, the 3DO Interactive Multiplayer's Clio/CEL Engine, the Sega Saturn's VDP1, and the PlayStation's Sony GPU†}, as they lacked per-pixel depth calculation and perspective-correct texture mapping. Oh, and speaking about the 3DO and Saturn, they actually _directly_ used quadrilaterals as their base geometric primitive rather than triangles {causing quite the headache for their devs}, so yeah.) 7:55 Can you explain why a depth buffer is beneficial? Seems to me that the very processes needed to create one eliminate the need for one and _in fact make creating one wasteful_ . I mean, here's essentially what it _seems_ you're doing to create a depth buffer: 1. Use vertex shader output coordinates to identify the polygons behind the pixel of screen coordinate (x, y). 2. " identify what _part_ (i.e. polygon-specific coordinates) of the polygons are behind the pixel of screen coordinate (x, y). 3. " identify the _depth_ of the part of the polygons behind the pixel of screen coordinate (x, y). 4. Sort (polygon, depth) pairs from least to greatest depth. 5. Identify which polygon is at least depth. 6. Store least result as pixel in depth buffer. 7. Move on to next pixel. Thing is, if you know what polygon is closest to the pixel of a screen coordinate, and you know where on the polygon that is, then you already have ALL the information you need to start the texture-filtering/pixel-shader process for that pixel. (And indeed, those steps 1-5 and 7 are _required_ for perspective-correct texture mapping AFAIK, so it's not like that process itself is wasteful.) _So, why waste cycles and memory in storing the depth in a buffer_ ? After all, if you're going to come back to it later for any future texture-filtering or pixel-shading-related use, you're _also_ going to have to store a "polygon buffer" or else wastefully redo steps 1-5 and 7 (or at least 1-3, 5, and 7) in order to re-determine what face that depth value actually belongs to. †Though not necessarily the Atari Jaguar's Tom, which actually was able to handle vertex depth information during rasterization, being perhaps the first consumer-grade 3D (no quotations) hardware capable of that. However, the complexity, bugs, and bottlenecks of the Jaguar's architecture rendered its software generally unimpressive compared to its competition which lacked such a feature, and certain games like Club Drive show evidence of depth-ordered polygons. Overall, excellent short video, though. ;)
Should I make an in depth video about the math of the rasterizer?
Otherwise the next video will be about matrices.
FloatyMonkey either would be fascinating so do whichever interests you more, we will show up for them both!
Math of rasterizer! Its hard to find "advanced" 3D graphics math clearly explained on RUclips. Good stuff here!
yes please
yes
Yea.
"But who will ever read this code anyway" lol
I watched so many videos about this topic, but this one just nailed it! Finally I got a deeper understanding how a rasterizer works! Thank you!
I have not heard anyone explain computer science topics better than you. Hope you keep making videos!
Hi, thanks! I haven't uploaded in a while but if you want to know what I'm up to, you might want to visit the Discord ;)
Can't believe the quality of your videos! You make complex stuff easier to understand, really appreciate your effort :)
I have just discovered your channel and love your content! Keep it up!
Thank you so much! I feel like I finally understand the process behind rendering. Keep up the good work 😄😄😄
I've watched so many videos to get an understanding of the pipeline but none come close to this one Thanks Alottt!!
such a comprehensive and interesting video thank you so much for sharing! :) subbed
This was very helpful and informative! Thank you))
I just found your Video because I am working with OpenGL and I really like it! Wish there was more in-depth content about the different shaders and everything. Nice work!
Just subbed. Great content!
Good channel. You deserve more subs. Subscribed
this is very clean tutorial to understand. Thanks
Thank you for this!!
Nice work!
instant sub. well done
this is the best explanation of the graphics pipeline I've ever saw
This is a top notch production! Well done, my students will appreciate this.
Thanks! What course do you teach if I may ask?
@@FloatyMonkey I teach Intro to Computer Graphics and Graphics Programming. How do you make your videos? If you had a course on that I would gladly pay for it.
The visualizations are made in PowerPoint. It sounds silly, but the idea behind it is that you can use them in front of a live audience. I do not have a course on it but all the PowerPoints are available to Patrons for only €8/month. Unfortunatly my Patreon is subscription based but you can always download the files and cancel the subscription immediatly afterwards.
@@FloatyMonkey I’m happy to contribute $8 and maybe some BAT if you take that. I really appreciate you taking the time to thoughtfully respond. Your PowerPoint-Fu is strong.
Haha thanks, and no problem. I love to explain and engage with my audience in what I'm passionate about. Just becoming (my first) Patron, would already mean a lot, especially since you're a teacher/professor. Knowing my videos could be usefull to students is absolutly delightfull.
i won't believe your c++ codes anymore hahaha dividing normal by the id XD, i love your content .
dam brah, you are quite versed on cg im glad i found your channel.
Thank you! Also thanks for speaking english so clearly, I could understand everything xD
So well explained! I've just started a youtube channel about retro technologies and systems, for Brazilians, and I would love to know how software did you use to animate those arrows ;). Thx
Thanks. It's all made with PowerPoint.
Do you tutor? I like how detailed you are but there were some areas that were vague for me, like the fact that the output vectors of a vector shader on some input vertex would fall within the range -1
Amazing tutorial for beginners, much better explanation than my college professor's😅
Dude why youre inactive on youtube, you really explain things very well, thank you for this great video
Thanks. The inactivity is just due to a lack of time. By this summer, I hope to make some video’s about my optical motion capture system, a project I’ve been working on since October 2020. I decided to post updates about it on the Discord, go have a look if you’re interested.
I've been playing with particle shaders, and didn't quite understand the colour output until I read the comment at 4:40
Where did you go man!? This channel has the juice
Thanks. Between a full time job, writing a game engine and building a diy lighstage and motion capture system I haven't had much time to make video's this past year, although I now have a lot of interesting topics to cover. I definitely want to get back into it, hopefully by end of this year ...
Hello FloatyMonkey, your channel is really great and I found the videos very informative. Thank you. I have a question about Tesselation. Why is Tesselation required here..since vertex shader already gets data that are vertices of triangles ?
That's a great question. The advantage of tesselation is that it runs entirely on the GPU. This means you don't have to transfer the extra vertices from the CPU to the GPU over their relatively slow PCIe connection. On top of that there's less GPU memory required to store the model since the result of the tesselation is immediatly discarded after a specific model has been drawn. It obviously introduces some computational overhead but the advantages far outweigh the disadvantages. These days we can migrate away from the tesselation and geometry shaders however with a new shader stage called Mesh Shaders. Something I will probably talk about in the future.
@@FloatyMonkey Thank you for a great explanation. In another of your video titled "how triangles make up 3D models" you talk about 'Triangulation'. How is Triangulation differnt from Tesselation ?
Triangulation is the process of taking an arbitrary polygon (quad, octagon, ...) and turning it into the minimal amount of triangles that represents that polygon, this is required since GPUs prefer to work with triangles only. Tesselation is the process of taking a single triangle and dividing it in a bunch of other triangles which can be displaced in 3d space to add extra geometric detail.
i cant figure out how the output merger works, can you please give a visual example on how it works?
Hello! It's a great video and I would have a question. Where all the advanced lighting techniques are being processed? Is that at the pixel shader too?
Thank you
Usually in the pixel shader. When using a deferred pipeline however, it's also possible to run them in a compute shader.
@@FloatyMonkey Thank you for your answer!
i read your code, and it's a division by ID to get the color attributes😉
I have a couple questions, hopefully its clear without visualization here:
1. Does the rasterizer produce multiple fragments/pixels with the same position? For example, where the blue and red triangles overlap, would there be a fragment with the blue triangle attributes and one with the red triangle attributes in the same overlapping position? i.e. {position = (2, 3), color = blue, depth = 0.1}, {position= (2, 3), color = red, depth = 0.5}
2. If there are fragments with duplicate positions, does this mean that the Fragment/Pixel shader will run on the same fragment position multiple times even though in the following stage (output merger) the result of the red fragment being shaded will be thrown away (because its in the back)?
Thank you
Great questions. The pixel (fragment) shader can run multiple times for a single pixel, obviously each time calculating the color of a different primitive. These colors either get blended or discarded by the output merger. The latter isn't very efficient in case of overlapping opaque geometry since a lot of work gets thrown away. That's one of the reasons why we use a depth buffer, which can be used to determine whether a pixel shader invocation will get discarded before it actually runs. A finel method to reduce overdraw (the name for this phenomenon) is to render geometry from front to back. This makes sure foreground geometry writes to the depth buffer first so that geometry behind it gets discarded before rendering. Hope this makes sense ;)
how you make the video? ppt animation?
subscribed, if not for dark theme videos alone
4:43 I saw what you did ;)
Lol, guess someone did read my code
Probably something I missed, but where does the perspective projection take place? Wherever you mentioned the vertices they were described with x,y,z not x,y
It happens in the vertex shader (shown at 4:40 on the first line of the main function). We actually do pass the entire result of Vertex * ViewProjectionMatrix to the GPU. In that case x,y describes the vertex position in normalized coordinates in range (-1, 1) and z describes the depth in range (0, 1). This depth value is still needed to determine if the shaded fragment is visible.
@@FloatyMonkey Awesome thanks. I thought so but wasn’t sure. Great video
More documentation can be seen in MSFT's Direct3D pipeline: docs.microsoft.com/en-us/windows/win32/direct3d11/overviews-direct3d-11-graphics-pipeline
I love your video! I want to use some screenshots in my lecture. Of course I will cite the source. can I?
Sure, no problem. Out of curiosity what kind of lecture?
@@FloatyMonkey Thanks a lot! I am creating various lecture contents. First of all, I will conduct a webinar for shader development. ruclips.net/video/r_eatgPFQYg/видео.html
I don't speak Korean but that looked great! Going on the visuals, you managed to touch upon all the preliminaries of shader development in a very short time.
I was reading that code why did u divide normal by vertex id 🤣🤣🤣🤣
Which kind of code is the code in the video??
It's HLSL shader code which can run on a GPU.
What an accent! Where are you from? I can't figure it out.
I'm from Belgium, my mother tongue is Dutch.
I read the code, that's how you learn
7:37 That's not really a sufficient explanation. Generating the locations of the vertices of your blender mesh is also not possible on a graphics card, but the CPU sets it up for the GPU; just because the GPU can't do something doesn't explain why it's not done. So, why doesn't the CPU just sort the triangles? The real one-sentence explanation is "Unfortunately, we can't solve this problem by changing the order in which we draw the triangles, *since it's way too expensive to sort hundreds of thousands of triangles, every single frame*. The solution to our problem...".
As a secondary issue, if you have a triplet of long rectangles where A covers B, B covers C, and C covers A, that triplet can't be resolved without a Z-buffer either. But that's a rare case and generally not the "real" reason, it's just too expensive to compare overlapping triangles and re-sort them all every single frame.
Amazing explanation!!! ♥ But... 09:59... what?! 😅
Lol, I just rewatched that part, sould have made it a bit more clear 😅.
@@FloatyMonkey point was about the "pink" color vs. the actual color you used 😁 loved the video anyway!
I'm colorblind, for me it's pink 🤣.
@@FloatyMonkey ahh did't know, so sorry! it's a dark blue with a shade of grey,, but more blue than that. Anyhow, thanks for your videos, I added about 5 of them to a curriculum playlist I'm making for some future newcomers at my workplace!
I think the hardest part of this video to understand is how that color is supposed to be “pink” 😂
I'll take that as a compliment, but yeah I'm colorblind 😉
@@FloatyMonkeyIt is! (and I’m even a big noob to this stuff) Looking forward to watching the rest of your videos!
Where is that accent from?
Belgium (the Dutch speaking half), but I might have picked it up from across the internet ;)
0:50 LOL software rendering go brrr
3:10 If 16-bits is conventionally used... how do modern 3D graphics work? I mean, games have exceeded 65,536 vertices per frame since the early 2000s, and 65,536 vertices per object for somewhat less time. Do engines swap out vertices mid-frame like was done for sprites and palletes for ambitious games on sprite-based hardware?
4:35 ...why? Doesn't sound like a very useful range for display purposes at all.
6:25 You _could_ use Bresenham's line algorithm or something instead of constructing triangles for that purpose.
7:50 Huh... So the RTX 4090-or for a video-contemporary example, the Titan RTX-is less capable in a respect than, say, the Atari VCS/2600's TIA?! (Sprite-based graphics hardware allows for direct draw-ordering of sprites, AFAIK without exception because without vertex-level depth information, there's really no other method to handle depth. This was also done for polygons on the first generation of console "3D" video processors {that is, the 3DO Interactive Multiplayer's Clio/CEL Engine, the Sega Saturn's VDP1, and the PlayStation's Sony GPU†}, as they lacked per-pixel depth calculation and perspective-correct texture mapping. Oh, and speaking about the 3DO and Saturn, they actually _directly_ used quadrilaterals as their base geometric primitive rather than triangles {causing quite the headache for their devs}, so yeah.)
7:55 Can you explain why a depth buffer is beneficial? Seems to me that the very processes needed to create one eliminate the need for one and _in fact make creating one wasteful_ . I mean, here's essentially what it _seems_ you're doing to create a depth buffer:
1. Use vertex shader output coordinates to identify the polygons behind the pixel of screen coordinate (x, y).
2. " identify what _part_ (i.e. polygon-specific coordinates) of the polygons are behind the pixel of screen coordinate (x, y).
3. " identify the _depth_ of the part of the polygons behind the pixel of screen coordinate (x, y).
4. Sort (polygon, depth) pairs from least to greatest depth.
5. Identify which polygon is at least depth.
6. Store least result as pixel in depth buffer.
7. Move on to next pixel.
Thing is, if you know what polygon is closest to the pixel of a screen coordinate, and you know where on the polygon that is, then you already have ALL the information you need to start the texture-filtering/pixel-shader process for that pixel. (And indeed, those steps 1-5 and 7 are _required_ for perspective-correct texture mapping AFAIK, so it's not like that process itself is wasteful.) _So, why waste cycles and memory in storing the depth in a buffer_ ? After all, if you're going to come back to it later for any future texture-filtering or pixel-shading-related use, you're _also_ going to have to store a "polygon buffer" or else wastefully redo steps 1-5 and 7 (or at least 1-3, 5, and 7) in order to re-determine what face that depth value actually belongs to.
†Though not necessarily the Atari Jaguar's Tom, which actually was able to handle vertex depth information during rasterization, being perhaps the first consumer-grade 3D (no quotations) hardware capable of that. However, the complexity, bugs, and bottlenecks of the Jaguar's architecture rendered its software generally unimpressive compared to its competition which lacked such a feature, and certain games like Club Drive show evidence of depth-ordered polygons.
Overall, excellent short video, though. ;)