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)
+