split the graphics pipeline into 4 articles
Some checks failed
continuous-integration/drone/push Build is failing

This commit is contained in:
light7734 2025-06-04 10:38:10 +03:30
parent 9da0ac9d5e
commit 77d4184ed1
Signed by: light7734
GPG key ID: 8C30176798F1A6BA
4 changed files with 381 additions and 178 deletions

View file

@ -1,12 +1,12 @@
--- ---
title: The (Modern) Graphics Pipeline title: The Graphics Pipeline ; Part 1
date: "April 20 - 2025" date: "April 20 - 2025"
--- ---
<script> <script>
import Image from "../Image.svelte" import Image from "../../Image.svelte"
import Note from "../Note.svelte" import Note from "../../Note.svelte"
import Tip from "../Tip.svelte" import Tip from "../../Tip.svelte"
</script> </script>
Ever wondered how games put all that gore on your display? All that beauty is brought into life by Ever wondered how games put all that gore on your display? All that beauty is brought into life by
@ -26,7 +26,7 @@ Each stage takes some input (data and configuration) to generate some output dat
<Note title="A coarse division of the graphics pipeline", type="diagram"> <Note title="A coarse division of the graphics pipeline", type="diagram">
Application --> Geometry Processing --> Rasterization --> Pixel Processing --> Presentation Application --> **Geometry Processing** --> Rasterization --> Pixel Processing --> Presentation
</Note> </Note>
Before the heavy rendering work starts on the <Tip text="GPU">Graphics Processing Unit</Tip>, Before the heavy rendering work starts on the <Tip text="GPU">Graphics Processing Unit</Tip>,
@ -331,9 +331,6 @@ What we'd like to do is to transform these vertices through 5 different coordina
The purpose of each space will be explained shortly. But doing these **transformations** require The purpose of each space will be explained shortly. But doing these **transformations** require
a lot of **linear algebra**, specifically **matrix operations**. a lot of **linear algebra**, specifically **matrix operations**.
I'll give you a brief refresher on the mathematics needed to understand the coordinate systems.
But if you feel extra savvy you may skip the following **linear algebra** sections.
<Note title="Algebra Ahead!"> <Note title="Algebra Ahead!">
The concepts in the following sections may be difficult to grasp at first. And **that's okay**, you don't The concepts in the following sections may be difficult to grasp at first. And **that's okay**, you don't
@ -375,16 +372,14 @@ your time** :)
**Identity Matrix** **Identity Matrix**
## Linear Algebra --- Affine Transformations ## Linear Algebra --- Transformations
All **affine** transformations can be represented as matrix operations using **homogeneous** coordinates.
**What is transformation**
**Scale** **Scale**
**Rotation** **Rotation**
**Why Translation is not a linear transformation**
**Translation** **Translation**
<Note type="info", title="Homogeneous coordinates"> <Note type="info", title="Homogeneous coordinates">
@ -396,7 +391,7 @@ Why are we using 4D matrixes for vertices that are three dimensional?
**Embedding it all in one matrix** **Embedding it all in one matrix**
Great! You've refreshed on lots of cool mathematics today, let's get back to the original discussion. Great! You've refreshed on lots of cool mathematics today, let's get back to the original discussion.
**Transforming** the freshly generated **primitives** through the **five** primary coordinates systems (or spaces), **Transforming** the freshly generated **primitives** through this **five** mysterious primary coordinates systems (or spaces),
starting with the **local space**! starting with the **local space**!
## Coordinate System -- Local Space ## Coordinate System -- Local Space
@ -524,7 +519,7 @@ That's two down, one left to slay!
** Viewport transform ** ** Viewport transform **
## Coordinate system -- Recap ## Coordinate system -- Putting it All Together
<Note title="Coordinate System", type="diagram"> <Note title="Coordinate System", type="diagram">
@ -549,134 +544,6 @@ are expressed more efficiently through mathmatical expressions than raw vertex d
**But before focusing on steps meant to "optimize" the pipeline, let's first figure out how **But before focusing on steps meant to "optimize" the pipeline, let's first figure out how
the pipeline works in a fundumentall sense. We'll come back to these stages after covering the pipeline works in a fundumentall sense. We'll come back to these stages after covering
## Geometry Processing
Let's recap!
<Note type="diagram", title="Geometry Processing">
Prepared Vertex Data ->
Input Assembly turns Vertex Data into digestable structures for the Vertex Shader ->
Vertex Shader is invoked per vertex for applying transformations via some clever linear algebra ->
Geometry & Tessellation Shaders expand the geometry on-the-fly and may apply more transformations ->
... Rasterizer
</Note>
The geometric detail that we now have is not **real**. Perfect triangle do not exist in the real world.
Our next challenge in this journey is to turn these mathmatical representations into something
concrete and significant. We're gonna take these primitives and turn them into **pixels** through
a fancy process called **rasterization**.
<Note type="review", title="Time for a break?">
You might wanna give your pretty eyes and that smart brain of yours a much deserved rest :)
</Note>
## Rasterization
**Bounding Box**
**Winding order**
**P needs to be on the "RIGHT" side of a->b**
**Cross Product**
**Interpolation**
Remember the god forsaken **input assembler**? Let's expand our understanding of it
since-- for simplicity's sake, we skipped over the fact that **vertices** can hold much, much more data
than only positions.
**Barycentric Interpolation** NOTE NOT linear interpolation
**Some Optimizations**
<Note title="Software Rasterization">
What we've implemented is a simple toy rasterizer written to be run on the CPU for educational
purposes only. It is inefficient, has shit precision (integer precision) thus it is choppy when moving things around, and has many problems.
However, GPUs have dedicated hardwares that run incredibly optimized algorithms to do this
sort of thing; hence what we made is called a **software** rasterizer ---as opposed to the usual
**hardware** rasterizer.
I'd like to remind you that the simplicity of the **rasterization** algorithm is one of the most
important reasons we use **triangles** to do **polygonal rendering**. If polygons had variable
number of edges then it would be really difficult to come up with efficient algorithms for doing this.
</Note>
## Pixel Processing
**Overview**
## Texturing
**Vertex Data Extension**
**Texture Coordinates**
**Texture Sampling**
**Mipmaps**
**Non-color Data**
## Lighting
**Phong Shading**
// The model was named after its developer B`ui Tóng Phong
**Ambient**
**Diffuse**
**Specular**
**Combined (Phong)**
## Anti-Aliasing
**SSAA**
**MSAA**
## Pixel Shaders
## Output Merger
**Blending**
## Optimizing the Pipeline
<Note type="quote" title="An idiot admires complexity, a genius admires simplicity.">
--- Terry A. Davis
</Note>
**Out of the mathmatical world, into the engineering world!**
## Deferred Shading
**Deferred Shading**
**Bottleneck in pixel shading**
**G Buffer**
**Forward pass**
**Deferred pass** or the **Lighting pass**
**Pros and Cons**
**Anti Aliasing**
**High memory consumption**
**May be slower for simple scenes**
**How we did thing in the traditional graphics pipeline**
## Geometry and Tessellation Shaders (optional stages) ## Geometry and Tessellation Shaders (optional stages)
**Different levels of parallelism (why do we still need the vertex shader)** **Different levels of parallelism (why do we still need the vertex shader)**
@ -720,49 +587,27 @@ number of edges then it would be really difficult to come up with efficient algo
**Tessellation examples** **Tessellation examples**
## Meshlet-based Rendering ## Geometry Processing
**Intro to Mesh shaders** Let's recap!
**Issue with Low resolution -> High resolution** <Note type="diagram", title="Geometry Processing">
**[Task Shader -> Mesh Generation -> Mesh Shader] -> Rasterization -> Pixel Shader -> Merger** Prepared Vertex Data ->
** ^^^ GEOMETRY PROCESSING -> ^^^ -> Pixel Processing
## Conclusion Input Assembly turns Vertex Data into digestable structures for the Vertex Shader ->
Let's---for the final time, have a quick recap and go everything at the speed of **light** :)
**Application** <br/> Vertex Shader is invoked per vertex for applying transformations via some clever linear algebra ->
The pipeline starts simulating the world on the **CPU** and updates, changes, destroys things
through systems like physics, ecs, events, etc, etc. Here we have full autonomy.
**Geometry Processing** <br/> Geometry & Tessellation Shaders expand the geometry on-the-fly and may apply more transformations ->
The **graphics pipeline** then provides the **scene data** as a set of **vertices** that form
**primitives** to the **input assembler**. We use **triangles** because they're the best! Then this
**input assembler** does what it says and **assembles** some input for the **vertex shader**.
This **vertex shader** transforms the vertices through different **coordinate systems** and figure out where
everything should end up on the screen. Here we can optionally do some work with the **geomtry** and **tessellation**
steps to generate more geometry on the fly---since expressing some geometric detail mathmatically is more efficient than providing the concrete geometry.
This would help us lighten the load on the DRAM -> GPU data lines which are often a bottleneck.
**Rasterization** <br/> ... Rasterizer
After all that **geometry processing** we pass the final geometry data to the hardcoded hardware **rasterizer**
to do **rasterization** and **interpolation** for us and convert the **abstract geometry** into concrete **pixels**.
All by using triangles because they're the best.
**Pixel Processing** <br/> </Note>
The **rasterizer** then hands off the work to the **pixel/fragment shader** and our world will end up
being so sexy and colorful! After processing all the fragments the **output merger** will squeeze these
together and compose the final image.
**Presentation** <br/> The geometric detail that we now have is not **real**. Perfect triangle do not exist in the real world.
The **presentation engine** will then feed the output of the pipeline to the target display **surface** Our next challenge in this journey is to turn these mathmatical representations into something
for your pretty eyes to digest and enjoy. concrete and significant. We're gonna take these primitives and turn them into **pixels** through
a fancy process called **rasterization**.
You've done it! You read through all this garbage just to learn how the **graphics pipeline** works.
Give yourself a pat on the back and a well deserved reward.
Thanks for reading all the way through! Any feedback, criticism, or question is welcome so contact
me if you'd like. Good luck on your journey, wherever it may take you :)
## Sources ## Sources

View file

@ -0,0 +1,144 @@
---
title: The Graphics Pipeline --- Optimizations
date: "April 20 - 2025"
---
<script>
import Image from "../../Image.svelte"
import Note from "../../Note.svelte"
import Tip from "../../Tip.svelte"
</script>
## Optimizing the Pipeline
<Note type="quote" title="An idiot admires complexity, a genius admires simplicity.">
--- Terry A. Davis
</Note>
Let's get our heads out of the abstract and dizzying mathmatical world now and think like an engineer.
**Out of the mathmatical world, into the engineering world!**
## Deferred Shading
**Deferred Shading**
**Bottleneck in pixel shading**
**The G Buffer**
**Forward pass** or the **Geometry Pass**
**Deferred pass** or the **Lighting pass**
**Anti Aliasing**
## Beyond G-Buffers --- Visibility Buffers
**Pros and Cons of G-Buffers**
**High memory consumption**
**May be slower for simple scenes**
**How we did thing in the traditional graphics pipeline**
**Intro to Visbility Buffers!**
## Meshlet-based Rendering
**Intro to Mesh shaders**
**Issue with Low resolution -> High resolution**
**[Task Shader -> Mesh Generation -> Mesh Shader] -> Rasterization -> Pixel Shader -> Merger**
** ^^^ GEOMETRY PROCESSING -> ^^^ -> Pixel Processing
## Conclusion
Let's---for the final time, have a quick recap and go everything at the speed of **light** :)
**Application** <br/>
The pipeline starts simulating the world on the **CPU** and updates, changes, destroys things
through systems like physics, ecs, events, etc, etc. Here we have full autonomy.
**Geometry Processing** <br/>
The **graphics pipeline** then provides the **scene data** as a set of **vertices** that form
**primitives** to the **input assembler**. We use **triangles** because they're the best! Then this
**input assembler** does what it says and **assembles** some input for the **vertex shader**.
This **vertex shader** transforms the vertices through different **coordinate systems** and figure out where
everything should end up on the screen. Here we can optionally do some work with the **geomtry** and **tessellation**
steps to generate more geometry on the fly---since expressing some geometric detail mathmatically is more efficient than providing the concrete geometry.
This would help us lighten the load on the DRAM -> GPU data lines which are often a bottleneck.
**Rasterization** <br/>
After all that **geometry processing** we pass the final geometry data to the hardcoded hardware **rasterizer**
to do **rasterization** and **interpolation** for us and convert the **abstract geometry** into concrete **pixels**.
All by using triangles because they're the best.
**Pixel Processing** <br/>
The **rasterizer** then hands off the work to the **pixel/fragment shader** and our world will end up
being so sexy and colorful! After processing all the fragments the **output merger** will squeeze these
together and compose the final image.
**Presentation** <br/>
The **presentation engine** will then feed the output of the pipeline to the target display **surface**
for your pretty eyes to digest and enjoy.
You've done it! You read through all this garbage just to learn how the **graphics pipeline** works.
Give yourself a pat on the back and a well deserved reward.
Thanks for reading all the way through! Any feedback, criticism, or question is welcome so contact
me if you'd like. Good luck on your journey, wherever it may take you :)
## Sources
<Note title="Reviewers", type="review">
MMZ ❤️
Grammarly
Some LLMs
</Note>
<Note title="Books", type="resource">
[Joey De Vriez --- LearnOpenGL](https://learnopengl.com/)
[Tomas Akenine Moller --- Real-Time Rendering (4th ed)](https://www.realtimerendering.com/intro.html)
[Gabriel Gambetta --- Computer Graphics from Scratch](https://gabrielgambetta.com/computer-graphics-from-scratch/)
</Note>
<Note title="Wikipedia", type="resource">
[Polygonal Modeling](https://en.wikipedia.org/wiki/Polygonal_modeling)
[Non-uniform Rational B-spline Surfaces](https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline)
[Computer Aided Design (CAD)](https://en.wikipedia.org/wiki/Computer-aided_design)
[Rasterization](https://en.wikipedia.org/wiki/Rasterisation)
[Euclidean geometry](https://en.wikipedia.org/wiki/Euclidean_geometry)
</Note>
<Note title="Youtube", type="resource">
[Miolith --- Quick Understanding of Homogeneous Coordinates for Computer Graphics](https://www.youtube.com/watch?v=o-xwmTODTUI)
[Leios Labs --- What are affine transformations?](https://www.youtube.com/watch?v=E3Phj6J287o)
[3Blue1Brown --- Essence of linear algebra (highly recommended playlist)](https://www.youtube.com/watch?v=fNk_zzaMoSs&list=PLZHQObOWTQDPD3MizzM2xVFitgF8hE_ab)
[3Blue1Brown --- Quaternions and 3d rotation, explained interactively](https://www.youtube.com/watch?v=zjMuIxRvygQ)
[pikuma --- Math for Game Developers (playlist)](https://www.youtube.com/watch?v=Do_vEjd6gF0&list=PLYnrabpSIM-93QtJmGnQcJRdiqMBEwZ7_)
[pikuma --- 3D Graphics (playlist)](https://www.youtube.com/watch?v=Do_vEjd6gF0&list=PLYnrabpSIM-97qGEeOWnxZBqvR_zwjWoo)
[Cem Yuksel --- Introduction to Computer Graphics (playlist)](https://www.youtube.com/watch?v=vLSphLtKQ0o&list=PLplnkTzzqsZTfYh4UbhLGpI5kGd5oW_Hh)
[Cem Yuksel --- Interactive Computer Graphics (playlist)](https://www.youtube.com/watch?v=UVCuWQV_-Es&list=PLplnkTzzqsZS3R5DjmCQsqupu43oS9CFN&pp=0gcJCV8EOCosWNin)
[javidx9 --- Essential Mathematics For Aspiring Game Developers](https://www.youtube.com/watch?v=DPfxjQ6sqrc)
</Note>
<Note title="Articles", type="resource">
[Stackoverflow --- Why do 3D engines primarily use triangles to draw surfaces?](https://stackoverflow.com/questions/6100528/why-do-3d-engines-primarily-use-triangles-to-draw-surfaces)
[The ryg blog --- The barycentric conspiracy](https://fgiesen.wordpress.com/2013/02/06/the-barycentric-conspirac/)
[Juan Pineda --- A Parallel Algorithm for Polygon Rasterization](https://www.cs.drexel.edu/~deb39/Classes/Papers/comp175-06-pineda.pdf)
[Kristoffer Dyrkorn --- A fast and precise triangle rasterizer](https://kristoffer-dyrkorn.github.io/triangle-rasterizer/)
[Microsoft --- Rasterization Rules](https://learn.microsoft.com/en-us/windows/win32/direct3d11/d3d10-graphics-programming-guide-rasterizer-stage-rules)
</Note>
<Note title="Documentations", type="resource">
[Vulkan Docs --- Drawing](https://docs.vulkan.org/spec/latest/chapters/drawing.html)
[Vulkan Docs --- Pipeline Diagram](https://docs.vulkan.org/spec/latest/_images/pipelinemesh.svg)
</Note>

View file

@ -0,0 +1,115 @@
---
title: The Graphics Pipeline --- Pixel Processing
date: "April 20 - 2025"
---
<script>
import Image from "../../Image.svelte"
import Note from "../../Note.svelte"
import Tip from "../../Tip.svelte"
</script>
## Pixel Processing
**Overview**
## Texturing
**Vertex Data Extension**
**Texture Coordinates**
**Texture Sampling**
**Mipmaps**
**Non-color Data**
## Lighting
**Phong Shading**
// The model was named after its developer B`ui Tóng Phong
**Ambient**
**Diffuse**
**Specular**
**Combined (Phong)**
## Shadows
## Anti-Aliasing
**SSAA**
**MSAA**
## Post-Processing & Screen-Space Effects
## Pixel Shaders
## Presentation
## Depth Testing
## Stencil Testing
## Output Merger
** Transparency**
**Blending**
## Sources
<Note title="Reviewers", type="review">
MMZ ❤️
Grammarly
Some LLMs
</Note>
<Note title="Books", type="resource">
[Joey De Vriez --- LearnOpenGL](https://learnopengl.com/)
[Tomas Akenine Moller --- Real-Time Rendering (4th ed)](https://www.realtimerendering.com/intro.html)
[Gabriel Gambetta --- Computer Graphics from Scratch](https://gabrielgambetta.com/computer-graphics-from-scratch/)
</Note>
<Note title="Wikipedia", type="resource">
[Polygonal Modeling](https://en.wikipedia.org/wiki/Polygonal_modeling)
[Non-uniform Rational B-spline Surfaces](https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline)
[Computer Aided Design (CAD)](https://en.wikipedia.org/wiki/Computer-aided_design)
[Rasterization](https://en.wikipedia.org/wiki/Rasterisation)
[Euclidean geometry](https://en.wikipedia.org/wiki/Euclidean_geometry)
</Note>
<Note title="Youtube", type="resource">
[Miolith --- Quick Understanding of Homogeneous Coordinates for Computer Graphics](https://www.youtube.com/watch?v=o-xwmTODTUI)
[Leios Labs --- What are affine transformations?](https://www.youtube.com/watch?v=E3Phj6J287o)
[3Blue1Brown --- Essence of linear algebra (highly recommended playlist)](https://www.youtube.com/watch?v=fNk_zzaMoSs&list=PLZHQObOWTQDPD3MizzM2xVFitgF8hE_ab)
[3Blue1Brown --- Quaternions and 3d rotation, explained interactively](https://www.youtube.com/watch?v=zjMuIxRvygQ)
[pikuma --- Math for Game Developers (playlist)](https://www.youtube.com/watch?v=Do_vEjd6gF0&list=PLYnrabpSIM-93QtJmGnQcJRdiqMBEwZ7_)
[pikuma --- 3D Graphics (playlist)](https://www.youtube.com/watch?v=Do_vEjd6gF0&list=PLYnrabpSIM-97qGEeOWnxZBqvR_zwjWoo)
[Cem Yuksel --- Introduction to Computer Graphics (playlist)](https://www.youtube.com/watch?v=vLSphLtKQ0o&list=PLplnkTzzqsZTfYh4UbhLGpI5kGd5oW_Hh)
[Cem Yuksel --- Interactive Computer Graphics (playlist)](https://www.youtube.com/watch?v=UVCuWQV_-Es&list=PLplnkTzzqsZS3R5DjmCQsqupu43oS9CFN&pp=0gcJCV8EOCosWNin)
[javidx9 --- Essential Mathematics For Aspiring Game Developers](https://www.youtube.com/watch?v=DPfxjQ6sqrc)
</Note>
<Note title="Articles", type="resource">
[Stackoverflow --- Why do 3D engines primarily use triangles to draw surfaces?](https://stackoverflow.com/questions/6100528/why-do-3d-engines-primarily-use-triangles-to-draw-surfaces)
[The ryg blog --- The barycentric conspiracy](https://fgiesen.wordpress.com/2013/02/06/the-barycentric-conspirac/)
[Juan Pineda --- A Parallel Algorithm for Polygon Rasterization](https://www.cs.drexel.edu/~deb39/Classes/Papers/comp175-06-pineda.pdf)
[Kristoffer Dyrkorn --- A fast and precise triangle rasterizer](https://kristoffer-dyrkorn.github.io/triangle-rasterizer/)
[Microsoft --- Rasterization Rules](https://learn.microsoft.com/en-us/windows/win32/direct3d11/d3d10-graphics-programming-guide-rasterizer-stage-rules)
</Note>
<Note title="Documentations", type="resource">
[Vulkan Docs --- Drawing](https://docs.vulkan.org/spec/latest/chapters/drawing.html)
[Vulkan Docs --- Pipeline Diagram](https://docs.vulkan.org/spec/latest/_images/pipelinemesh.svg)
</Note>

View file

@ -0,0 +1,99 @@
---
title: The Graphics Pipeline --- Rasterization
date: "April 20 - 2025"
---
<script>
import Image from "../../Image.svelte"
import Note from "../../Note.svelte"
import Tip from "../../Tip.svelte"
</script>
## Rasterization
**Bounding Box**
**Winding order**
**P needs to be on the "RIGHT" side of a->b**
**Cross Product**
**Interpolation**
Remember the god forsaken **input assembler**? Let's expand our understanding of it
since-- for simplicity's sake, we skipped over the fact that **vertices** can hold much, much more data
than only positions.
**Barycentric Interpolation** NOTE NOT linear interpolation
**Some Optimizations**
<Note title="Software Rasterization">
What we've implemented is a simple toy rasterizer written to be run on the CPU for educational
purposes only. It is inefficient, has shit precision (integer precision) thus it is choppy when moving things around, and has many problems.
However, GPUs have dedicated hardwares that run incredibly optimized algorithms to do this
sort of thing; hence what we made is called a **software** rasterizer ---as opposed to the usual
**hardware** rasterizer.
It's nice to be aware of and appreciate the simplicity of triangles. If our polygons had variable
number of edges then it would be really difficult to come up with efficient algorithms for doing this.
</Note>
## Sources
<Note title="Reviewers", type="review">
MMZ ❤️
Grammarly
Some LLMs
</Note>
<Note title="Books", type="resource">
[Joey De Vriez --- LearnOpenGL](https://learnopengl.com/)
[Tomas Akenine Moller --- Real-Time Rendering (4th ed)](https://www.realtimerendering.com/intro.html)
[Gabriel Gambetta --- Computer Graphics from Scratch](https://gabrielgambetta.com/computer-graphics-from-scratch/)
</Note>
<Note title="Wikipedia", type="resource">
[Polygonal Modeling](https://en.wikipedia.org/wiki/Polygonal_modeling)
[Non-uniform Rational B-spline Surfaces](https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline)
[Computer Aided Design (CAD)](https://en.wikipedia.org/wiki/Computer-aided_design)
[Rasterization](https://en.wikipedia.org/wiki/Rasterisation)
[Euclidean geometry](https://en.wikipedia.org/wiki/Euclidean_geometry)
</Note>
<Note title="Youtube", type="resource">
[Miolith --- Quick Understanding of Homogeneous Coordinates for Computer Graphics](https://www.youtube.com/watch?v=o-xwmTODTUI)
[Leios Labs --- What are affine transformations?](https://www.youtube.com/watch?v=E3Phj6J287o)
[3Blue1Brown --- Essence of linear algebra (highly recommended playlist)](https://www.youtube.com/watch?v=fNk_zzaMoSs&list=PLZHQObOWTQDPD3MizzM2xVFitgF8hE_ab)
[3Blue1Brown --- Quaternions and 3d rotation, explained interactively](https://www.youtube.com/watch?v=zjMuIxRvygQ)
[pikuma --- Math for Game Developers (playlist)](https://www.youtube.com/watch?v=Do_vEjd6gF0&list=PLYnrabpSIM-93QtJmGnQcJRdiqMBEwZ7_)
[pikuma --- 3D Graphics (playlist)](https://www.youtube.com/watch?v=Do_vEjd6gF0&list=PLYnrabpSIM-97qGEeOWnxZBqvR_zwjWoo)
[Cem Yuksel --- Introduction to Computer Graphics (playlist)](https://www.youtube.com/watch?v=vLSphLtKQ0o&list=PLplnkTzzqsZTfYh4UbhLGpI5kGd5oW_Hh)
[Cem Yuksel --- Interactive Computer Graphics (playlist)](https://www.youtube.com/watch?v=UVCuWQV_-Es&list=PLplnkTzzqsZS3R5DjmCQsqupu43oS9CFN&pp=0gcJCV8EOCosWNin)
[javidx9 --- Essential Mathematics For Aspiring Game Developers](https://www.youtube.com/watch?v=DPfxjQ6sqrc)
</Note>
<Note title="Articles", type="resource">
[Stackoverflow --- Why do 3D engines primarily use triangles to draw surfaces?](https://stackoverflow.com/questions/6100528/why-do-3d-engines-primarily-use-triangles-to-draw-surfaces)
[The ryg blog --- The barycentric conspiracy](https://fgiesen.wordpress.com/2013/02/06/the-barycentric-conspirac/)
[Juan Pineda --- A Parallel Algorithm for Polygon Rasterization](https://www.cs.drexel.edu/~deb39/Classes/Papers/comp175-06-pineda.pdf)
[Kristoffer Dyrkorn --- A fast and precise triangle rasterizer](https://kristoffer-dyrkorn.github.io/triangle-rasterizer/)
[Microsoft --- Rasterization Rules](https://learn.microsoft.com/en-us/windows/win32/direct3d11/d3d10-graphics-programming-guide-rasterizer-stage-rules)
</Note>
<Note title="Documentations", type="resource">
[Vulkan Docs --- Drawing](https://docs.vulkan.org/spec/latest/chapters/drawing.html)
[Vulkan Docs --- Pipeline Diagram](https://docs.vulkan.org/spec/latest/_images/pipelinemesh.svg)
</Note>