diff --git a/src/routes/articles/Layout.svelte b/src/routes/articles/Layout.svelte index f5030e7..2dd35d2 100644 --- a/src/routes/articles/Layout.svelte +++ b/src/routes/articles/Layout.svelte @@ -29,15 +29,14 @@ flex: 3; padding: 1em; background-color: #282828; - text-wrap-mode: wrap; min-width: 80ch; max-width: 80ch; + text-wrap-mode: wrap; + text-align: justify; border-left: 1px solid #928374; border-right: 1px solid #928374; - - text-align: justify; } .padding { diff --git a/src/routes/articles/Tip.svelte b/src/routes/articles/Tip.svelte new file mode 100644 index 0000000..581d0a5 --- /dev/null +++ b/src/routes/articles/Tip.svelte @@ -0,0 +1,49 @@ + + +
+ {text} + +
+ + diff --git a/src/routes/articles/the-graphics-pipeline/+page.svx b/src/routes/articles/the-graphics-pipeline/+page.svx index bdf332b..4802544 100644 --- a/src/routes/articles/the-graphics-pipeline/+page.svx +++ b/src/routes/articles/the-graphics-pipeline/+page.svx @@ -6,6 +6,7 @@ date: "April 20 - 2025" Ever wondered how games put all that gore on your display? All that beauty is brought into life by @@ -21,35 +22,41 @@ Each stage takes some input (data and configuration) to generate some output dat Application --> Geometry Processing --> Rasterization --> Pixel Processing --> Presentation -Before the heavy rendering work starts on the **GPU**, we simulate the world through systems -like physics engine, game logic, networking, etc, during the **Application** stage. -This stage is mostly ran on the **CPU**, therefore it is very efficient on executing -**sequentially dependendent** logic. - - - +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. +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. In other words, **CPUs** are great at executing **branch-heavy** code, and **GPUs** are geared -towards executing **branch-less** or **branch-light** code. - +towards executing a TON of **branch-less** or **branch-light** code in parallel. . +The updated scene data is then prepped and fed to the **GPU** for **geometry processing**; which is +where we figure out where everything ends up on our screen. We'll cover this stage in depth very soon so don't panic (yet). -The updated scene data is then prepped and fed to the GPU for **Geometry Processing**, this is -where we figure out where everything ends up on our screen. +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. -Then the final geometric data are converted into **pixels** and prepped for pixel processing stage via a process called **Rasterization**. +The **pixel processing** stage then uses the rasterized geometry data (pixel data) to do **lighting**, **texturing**, +and all the sweet gory details of 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 don't worry (yet 🙂). -The **Pixel Processing** stage then uses the rasterized geometry to do **lighting**, **texturing**, and all the sweet gory details. The pipeline will then serve (present) the output of the **pixel processing** stage, which is a **rendered image**, -to your pretty eyes using your display. +to your pretty eyes 👁👄👁 using your Usually a monitor but the technical term for it is +the target **surface**. Which can be anything like a VR headset or some other crazy surface used for displaying purposes.. But to avoid drowning you in overviews, let's jump right into the gory details of the **geometry processing** -stage and have a recap afterwards to demystify this 4-stage division. +stage and have a recap afterwards! ## Surfaces -Ever been jump-scared by this sight in an FPS? Why are things rendered like that? +Ever been jump-scared by this sight in an First Person (Shooter) perspective? Why are (the inside of) things rendered like that? +**Non-uniform rational basis spline** is a mathematical model using **basis splines** (B-splines) that is commonly used in computer graphics for representing curves and surfaces. It offers great flexibility and precision for handling both analytic (defined by common mathematical formulae) and modeled shapes. ---Wikipedia surfaces are great for representing **curves**, and it's all about the +**high precision** needed to do Computer Assisted Design. We could also do **ray-tracing** using fancy equations for rendering **photo-realistic** images. -These are all great--ignoring the fact that they would take an eternity to process... +These are all great---ignoring the fact that they would take an eternity to process... But what we need is a **performant** approach that can do this for an entire scene with hundreds of thousands of objects (like a lot of corpses) in under a small fraction of a second. What we need is **polygonal modeling**. @@ -96,11 +104,6 @@ With some interesting models put together, we can compose a **scene** (like a mu But let's not get ahead of ourselves. The primary type of **primitive** that we care about during **polygonal modeling** is a **triangle**. But why not squares or polygons with a variable number of edges? - - -Lorem ipsum dolor sit **amet**, consectetur adipiscing elit. **Fusce** rhoncus eleifend elementum. Mauris quis **arcu justo**. Proin pellentesque eleifend sapien, quis dictum lacus sodales eget. Pellentesque congue dapibus libero, nec finibus est tempus varius. Duis tincidunt arcu nulla, **ultrices** malesuada tellus convallis a. Aenean pulvinar ligula arcu, **vitae** cursus mi maximus sed. Morbi iaculis efficitur suscipit. Cras **in** vehicula est, ac molestie tortor. Donec sed **quam** pulvinar, pulvinar nulla vel, aliquet enim. Curabitur **tempus**, nisi quis posuere lacinia, sapien est maximus libero, vehicula hendrerit nisi **elit** sed ligula. Pellentesque habitant morbi tristique senectus et netus et malesuada fames **ac** turpis egestas. Praesent auctor velit eu justo suscipit, quis lobortis **elit** placerat. - - ## Why Triangles? In **Euclidean geometry**, triangles are always **planar** (they exist only in one plane), @@ -179,4 +182,5 @@ So, we got our set of triangles, but how do we make a model out of them? [Wikipedia - Polygonal Modeling](https://en.wikipedia.org/wiki/Polygonal_modeling) [Wikipedia - Non-uniform Rational B-spline Surfaces](https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline) [Wikipedia - Computer Aided Design (CAD)](https://en.wikipedia.org/wiki/Computer-aided_design) +[Wikipedia - Rasterization](https://en.wikipedia.org/wiki/Rasterisation) [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)