dazzle/src/routes/articles/the-graphics-pipeline/+page.svx

140 lines
4.6 KiB
Text
Raw Normal View History

2025-04-30 18:15:19 +03:30
---
title: The Graphics Pipeline
date: "April 20 - 2025"
---
2025-04-30 18:15:19 +03:30
<script>
import Paragraph from '../Paragraph.svelte';
import HorizontalBreak from '../HorizontalBreak.svelte';
</script>
2025-04-30 18:15:19 +03:30
<HorizontalBreak/>
2025-04-30 18:15:19 +03:30
<Paragraph>
Ever wondered how games put all that gore on your display? Well you're about to find out :)
At the heart of rendering, is the **Graphics Pipeline**. And like any pipeline, it's comprised
of several **stages**, each of which can be a pipeline in itself or even parallelized.
Each stage takes some input data (and configuration), to generate some output for the next stage.
</Paragraph>
<Paragraph>
We can coarsely divide the **Graphics Pipeline** into 4 stages:
**Application -> Geometry Processing -> Rasterization -> Pixel Processing**
The pipeline will then serve the output of the **Pixel Processing** stage, which is a **rendered image**,
to your pretty eyes using your display.
</Paragraph>
<Paragraph>
But to avoid drowning you in overviews, let's jump right into the details of the "Geometry Processing"
2025-04-30 18:15:19 +03:30
stage and have a recap afterwards to demystify this 4-stage division.
</Paragraph>
2025-04-30 18:15:19 +03:30
<Paragraph>
2025-04-30 18:15:19 +03:30
## Surfaces
In order to display a murder scene, we need to have a way of **representing** the deceased in computer memory.
We only care about the **surface** since we won't be seeing the insides anyways---Not that we want to.
At this stage, we only care about the **shape** or the **geometry** of the **surface**.
Texturing, lighting and all the sweet gory details comes at a much later stage once all the **geometry** has been processed.
But how should we represent surfaces in memory?
</Paragraph>
## Vertices
<Paragraph>
There are several ways to **represent 3d objects** for a computer to understand.
For instance, **NURB surfaces** are great for representing **curves**
and it's all about the **high-precision** needed to do **CAD**.
We could also do **ray-tracing** using fancy equations for rendering **photo-realistic** images.
</Paragraph>
<Paragraph>
These are all great--ignoring the fact that they would take "an eternity" to process.
2025-04-30 18:15:19 +03:30
But what we need is a **hardware-friendly** approach that can do this for an entire scene with
hundereds of thousands of objects for at least **60 times undr a second**. What we need is **polygonal modeling**.
</Paragraph>
<Paragraph>
**Polygonal modeling** allows us to do **real-time rendering**. The idea is that we only need an
**approximation** of a surface to render it **realisticly-enough** for us to have some fun killing time!
We can achieve this approximation using a collection of **triangles**, **lines** and **dots** (primitives),
which themselves are composed of a series of **vertices** (points in space).
</Paragraph>
<Paragraph>
2025-04-30 18:15:19 +03:30
A **vertex** is simply a point in space.
Once we get enough of these **points**, we can conncet them to form **primitives** such as **triangles**, **lines** and **dots**.
And once we have enough **primitives** together, they form a **model** or a **mesh** (that we need for our corpse).
With some interesting models, we can compose a **scene**.
</Paragraph>
2025-04-30 18:15:19 +03:30
<Paragraph>
2025-04-30 18:15:19 +03:30
But let's not get ahead of ourselves. The primary type of **primitive** we care about during **polygonal modeling**
is a **triangle**. But why not squares or polygons with variable number of edges?
</Paragraph>
2025-04-25 17:13:38 +03:30
## Why Triangles?
"Always Planar":
2025-04-30 18:15:19 +03:30
<Paragraph>
Triangles can never be __non-planar__(reside in more than 1 plane)! In Euclidean geometry, any
2025-04-30 18:15:19 +03:30
</Paragraph>
"Normal surface:"
"Algorithm Simplicity:"
"Predictable Winding Order:"
2025-04-25 17:13:38 +03:30
## Primitive Topologies
2025-04-25 17:13:38 +03:30
## Indices
2025-04-25 17:13:38 +03:30
## Input Assembler
2025-04-25 17:13:38 +03:30
## Coordinate System -- Local Space
2025-04-25 17:13:38 +03:30
## Coordinate System -- World Space
2025-04-25 17:13:38 +03:30
## Coordinate system -- View Space
2025-04-25 17:13:38 +03:30
## Coordinate system -- Clip Space
2025-04-25 17:13:38 +03:30
## Coordinate system -- Screen Space
2025-04-25 17:13:38 +03:30
## Vertex Shader
2025-04-25 17:13:38 +03:30
## Tessellation & Geometry Shaders
2025-04-25 17:13:38 +03:30
## Rasterizer
2025-04-25 17:13:38 +03:30
## Pixel Shader
2025-04-25 17:13:38 +03:30
## Output Merger
2025-04-25 17:13:38 +03:30
## The Future
2025-04-25 17:13:38 +03:30
## Conclusion
2025-04-25 17:13:38 +03:30
## Sources
[Tomas Akenine Moller - Real-Time Rendering 4th Edition](https://www.realtimerendering.com/intro.html)
2025-04-25 17:13:38 +03:30
<br/>
[LearnOpenGL - Hello Triangle](https://learnopengl.com/Getting-started/Hello-Triangle)
[LearnOpenGL - Face Culling](https://learnopengl.com/Advanced-OpenGL/Face-culling)
[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)
[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)