From e19b3fedd38583e7ab822a613386d6b592ddc9fb Mon Sep 17 00:00:00 2001 From: light7734 Date: Thu, 5 Jun 2025 19:08:53 +0330 Subject: [PATCH] wip --- .../geometry-processing/+page.svx | 108 +++++++++++------- 1 file changed, 65 insertions(+), 43 deletions(-) diff --git a/src/routes/articles/the-graphics-pipeline/geometry-processing/+page.svx b/src/routes/articles/the-graphics-pipeline/geometry-processing/+page.svx index 95c4724..065f37f 100644 --- a/src/routes/articles/the-graphics-pipeline/geometry-processing/+page.svx +++ b/src/routes/articles/the-graphics-pipeline/geometry-processing/+page.svx @@ -11,30 +11,30 @@ import Tip from "../../Tip.svelte" Ever wondered how games put all that gore on your display? All that beauty is brought into life by a process called **rendering**, and at the heart of it, is the **graphics pipeline**. -In this article we'll dive deep into the intricate details of this powerful beast. -We'll cover all the terminologies needed to understand each stage and have many restatements so don't -worry if you don't fully grasp something at first. If you still had questions, feel free to contact me :) +In this article, we'll dive deeply into the intricate details of this powerful beast. +Don't worry if things don't click right away---we’ll go over all the key terms and restate the important stuff to help it sink in. +And hey, if you still have questions, feel free to reach out :) -My initial goal of putting everything in **1 article** proved to hurt the **brevity** and the **structure** of content. -Afterall, the **graphics pipeline** is incredibly **complex** and have gone through quite some **evolution**. -This impelled me split the concepts into an **article series** consisting of **4 parts**, which would allow me to explain everything in sufficient depth. -But why exactly **4 parts**? +Initially, I tried cramming everything in **one article**, which hurt the **brevity** and the **structure**. +The **graphics pipeline** is a beast---incredibly **complex** and constantly **evolving**. +So I split it into a **4-part series**, which lets me go into sufficient depth. +But why exactly **4-parts**? ## Overview -Like any pipeline, the **graphics pipeline** is comprised -of several **stages**, each of which can be a pipeline in itself or even parallelized. +Like any pipeline, the **graphics pipeline** is made up of several **stages**, +each of which can be a mini-pipeline in itself or even parallelized. Each stage takes some input (data and configuration) to generate some output data for the next stage. - + Application --> **Geometry Processing** --> Rasterization --> Pixel Processing --> Presentation Before the heavy rendering work starts on the Graphics Processing Unit, we simulate and update the world through **systems** such as physics engine, game logic, networking, etc. -during the **application** stage. +all in the **application** stage. This stage is mostly ran on the Central Processing Unit, therefore it is extremely efficient on executing A type of execution flow where the operations depend on the results of previous steps, limiting parallel execution. @@ -49,14 +49,12 @@ We'll cover this stage in depth very soon so don't panic (yet). Afterwards, the final geometric data are converted into Pixel is the shorthand for **picture-element**, Voxel is the shorthand for **volumetric-element**. and prepped for the **pixel processing** stage via a process called **rasterization**. In other words, this stage converts a rather abstract and internal presentation (geometry) -into something more concrete (pixels). It's called rasterization because end the product is a Noun. A rectangular pattern of parallel scanning lines followed by the electron beam on a television screen or computer monitor. -- 1930s: from German Raster, literally ‘screen’, from Latin rastrum ‘rake’, from ras- ‘scraped’, from the verb radere. ---Oxford Languages of pixels. +into something more concrete (pixels). It's called rasterization because end the product is a Noun. A rectangular pattern of parallel scanning lines followed by the electron beam on a television screen or computer monitor. -- 1930s: from German Raster, literally ‘screen’, from Latin rastrum ‘rake’, from ras- ‘scraped’, from the verb radere. ---Oxford Languages +(a grid) of pixels. -The **pixel processing** stage then uses the rasterized geometry data (pixel data) to do **lighting**, **texturing**, -and all the sweet gory details of a scene (like a murder scene). -This stage is often, but not always, the most computationally expensive. -A huge problem that a good rendering engine needs to solve is how to be **performant**. And a great deal -of **optimization** can be done through **culling** the work that we can deem unnecessary/redundant in each -stage before it's passed on to the next. More on **culling** later so don't worry (yet :D). +The **pixel processing** stage then uses the rasterized geometry data (pixel data) to do +**lighting**, **texturing**, **shadow-mapping**, and all the sweet gory details of a scene (like a murder scene). +In short, this stage is responsible for calculating the **final output color** of each pixel. The pipeline will then serve (present) the output of the **pixel processing** stage, which is a **rendered image**, to your pretty eyes using your Usually a monitor but the technical term for it is @@ -74,7 +72,7 @@ the target **surface**. Which can be anything like a VR headset or some other cr -I hope it is now evident why I chose to split the concepts through 4 parts. So... let's jump right into the gory details of the **geometry processing** +I hope it is now evident why I chose to split the concepts in 4-parts. So... let's jump right into the gory details of the **geometry processing** stage! @@ -185,11 +183,11 @@ triangles. So, we got our set of vertices, but having a bunch of points floating around wouldn't make a scene very lively (or gory), we need to form **triangles** out of them to compose **models** (like our beautiful corpse). -**Input assembler** is the stage responsible for **concatenating** our vertices (the input) to assemble **primitives**. +The **input assembler** is first the mini-stage in the **geometry processing** stage. And it's responsible for **concatenating** our vertices (the input) to assemble **primitives**. It is a **fixed function** stage so we can only configure it (it's not programmable). We can tell the assembler how it should interpret the vertex data by configuring its **primitive** The way in which constituent parts are interrelated or arranged.--mid 19th century: via German from Greek topos ‘place’ + -logy.---Oxford Languages . -Instead of explaining with words, I'm going to show you how each type of topology works with pictures. Buckle up! +Instead of explaining with words, I'm going to show you how each type of topology works with pictures. So buckle up! When the topology is **point list**, each **consecutive vertex** (v) defines a **single point** primitive (p) and the number of primitives (n of p) is equals to the number of vertices (n of v). @@ -349,18 +347,18 @@ float vertices[] = { ``` As indicated by the comments, we have two **identical** vertices. This situation only gets worse -for each additional attribute per vertex (yep, vertices pack a lot more information than positions, you'll understand soon). -And in a large model with hundreds of thousands of triangles, it becomes unacceptable. Hence we use -indexed rendering: +for each additional **attribute** per vertex (vertices pack a lot more information than positions, we'll get to it later). +And in a large model with hundreds of thousands of triangles, it becomes unacceptable. To remedy this problem, we do +**indexed rendering**: ```cc float vertices[] = { // first triangle // x__ y__ - 0.5, 0.5, // top right - 0.5, -0.5, // bottom right - -0.5, -0.5, // bottom left - -0.5, 0.5, // top left + 0.5, 0.5, // top right [0] + 0.5, -0.5, // bottom right [1] + -0.5, -0.5, // bottom left [2] + -0.5, 0.5, // top left [3] }; unsigned int indices[] = { @@ -370,8 +368,8 @@ unsigned int indices[] = { ``` And you might be asking, what about **triangle strips** we just talked about? Well, if you try to visualize it, -a large model cannot possibly be made from a single strip of triangles, but from many. And we might not even use -triangle strips (we might use triangle lists). +a **large model** cannot possibly be made from a **single strip** of triangles, but from **many**. And we might not even use +triangle **strips**---we might use triangle **lists**. Either way, using indices is optional but almost always a good idea to use them! @@ -391,9 +389,9 @@ Alrighty! Do we have everything we need? We got our surface representation---**vertices**. We set the **primitive topology** to determine how to concatenate them. And we optionally (but most certainly) provided some **indices** to avoid -duplicate vertex data. +duplication. -All this data (and configuration) is then fed to the very first stage of the **graphics pipeline** called +All this data (and configuration) is then fed to the very first mini-stage of the **graphics pipeline** called the **input assembler**. Which as stated before, is responsible for **assembling** primitives from our **input** (vertices and indices). @@ -427,14 +425,15 @@ This is because the **rasterizer** expects the **final vertex coordinates** to b Anything outside of this range is, again, **clipped** and not visible. Yet, as you might imagine, doing everything in the **NDC** is inconvenient and very limiting. -We'd like to be able to **compose** a scene by Scale, Rotate, Translate. some objects around. And **interact** -with the scene by moving and looking around ourselves. +We'd like to **compose** a scene by Scale, Rotate, Translate. some objects around, **interact** +with the scene by moving and looking around, and express coordinates in arbitrary +units---such as meters. This is done by transforming these vertices through **5 coordinate systems** before ending up in NDC -(or outside of if they're meant to be clipped). Let's get a coarse overview: +(or outside of if they're meant to be clipped). Here's a high-level overview: -**Local Space**: This is where your object begins in, think of it as the data exported from a model -using Blender. If we were to modify an object it would make most sense to do it here. +**Local Space**: This is where your model begins in, think of it as the data exported from a model +using Blender. If we were to modify a model (the model's vertices itself, not its transformation) it would make most sense to do it here. **World Space**: All objects will be stuck into each other at coordinates 0, 0, 0 if we don't move them around the world. This is the transformation that puts your object in the context of the **world**. @@ -449,11 +448,11 @@ This projection is what makes **perspective** possible (distant objects appearin unto the screen. As you can see each of these coordinates systems serve a specific purpose and allows **composition** and **interaction** with a scene. -However, doing these **transformations** require a lot of **linear algebra**, specifically **matrix operations**. -So before we get into more depth about coordinate systems, let's learn how to do **linear transformations**! +However, doing these **transformations** require a lot of **linear algebra**, specially a ton of **matrix operations**. +So, before we get into more depth about these coordinate systems, let's learn how to do **linear transformations** using **linear algebra**! - + The concepts in the following sections may be difficult to grasp at first. And **that's okay**, you don't need to pickup everything the first time you read them (I didn't). If you feel passionate about these topics @@ -462,9 +461,22 @@ your time** :) -## Linear Algebra --- Vector Operations +## Linear Algebra --- Vectors -** What is a vector** +**Vectors** are the **fundamental** building blocks of the linear algebra. And we're going to get +really familiar with them :) But what is a **vector** anyways? As all things in life, it depends. + +For a **physicist**, vectors are **arrows pointing in space**, and what defines them is their **length** (or **magnitude**) +and **direction**---that is, any two vectors moved to different **origins** (starting points) are the **same vectors**, +as long as their **length** and **direction** remain the same: + +For a **computer scientist**, vectors are a fancy word for **ordered lists of numbers**. Yep, that's it, it feels good +to be in the simple world of a computer scientist: + +But for a **mathematician**, vectors are a lot more **abstract**. +Virtually **any** representation of **vectors** (which is called a **vector-space**) is valid as long as they follow a set of **axioms**. +It doesn't matter if you think of them as **arrows in space** that happen to have a **numeric representation**, +or as a **list of numbers** that happen to have a cute **geometric interpretation**. **Additions and Subtraction** @@ -480,7 +492,15 @@ your time** :) **Normalization and the normal vector** -## Linear Algebra --- Matrix Operations + + +If you're interested in **mathematics** (bet you are) and **visualization**, then I highly recommend watching the [Essence of Linear Algebra](https://www.youtube.com/playlist?list=PLZHQObOWTQDPD3MizzM2xVFitgF8hE_ab) +by **3Blue1Brown**. His math series has great intuitive explanations using smooth visuals. +And much of my own understanding comes from this series---and the other sources references at the end. + + + +## Linear Algebra --- Matrices ** What is a matrix** @@ -767,6 +787,8 @@ Some LLMs [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)
+[Vector space](https://en.wikipedia.org/wiki/Vector_space)
+