From 6697a24c6d976475f8b7065945b091749e939ab1 Mon Sep 17 00:00:00 2001 From: light7734 Date: Wed, 14 May 2025 01:31:12 +0330 Subject: [PATCH] wip --- src/routes/articles/Note.svelte | 45 ++++++-- src/routes/articles/Tip.svelte | 8 +- src/routes/articles/article.css | 62 +++++++---- src/routes/articles/technical-debt/+page.svx | 25 +++++ .../articles/the-graphics-pipeline/+page.svx | 105 +++++++++++++----- 5 files changed, 181 insertions(+), 64 deletions(-) create mode 100644 src/routes/articles/technical-debt/+page.svx diff --git a/src/routes/articles/Note.svelte b/src/routes/articles/Note.svelte index 15bc80d..b53654d 100644 --- a/src/routes/articles/Note.svelte +++ b/src/routes/articles/Note.svelte @@ -1,19 +1,50 @@
- + {#if type == 'info'} + + {:else if type == 'diagram'} + + {:else if type == 'math'} + + {:else if type == 'review'} + + {:else if type == 'resource'} + + {/if}
-
+ {#if type == 'info'} +
+ {:else if type == 'diagram'} +
+ {:else if type == 'math'} +
+ {:else if type == 'review'} +
+ {:else if type == 'resource'} +
+ {/if}
-
+ {#if type == 'info'} +
+ {:else if type == 'diagram'} +
+ {:else if type == 'math'} +
+ {:else if type == 'review'} +
+ {:else if type == 'resource'} +
+ {/if} +

{title}

@@ -46,7 +77,6 @@ } .line { - background-color: #8ec07c; width: 0.1em; margin-left: 0.85em; margin-bottom: 1em; @@ -54,7 +84,6 @@ } .horiz_line { - background-color: #8ec07c; height: 0.1em; margin-left: 0.5em; @@ -73,7 +102,7 @@ font-family: 'IBM Plex Mono', monospace; display: inline-block; margin: 0; - font-weight: bolder; + font-weight: bolder; } .icon { diff --git a/src/routes/articles/Tip.svelte b/src/routes/articles/Tip.svelte index 581d0a5..33c68f3 100644 --- a/src/routes/articles/Tip.svelte +++ b/src/routes/articles/Tip.svelte @@ -15,7 +15,7 @@ font-weight: 600; font-style: italic; color: #fabd2f; - border-bottom: .5px solid #d79921; + border-bottom: 1px solid #fe8019; } /* Tooltip text */ @@ -32,7 +32,7 @@ text-align: justify; padding: 1em; border-radius: 6px; - border: 1px solid #928374; + border: 1px dotted #fe8019; top: 100%; left: 50%; @@ -46,4 +46,8 @@ .tooltip:hover .tooltiptext { visibility: visible; } + + .tooltip:hover { + color: #fe8019; + } diff --git a/src/routes/articles/article.css b/src/routes/articles/article.css index 95fdd42..c543926 100644 --- a/src/routes/articles/article.css +++ b/src/routes/articles/article.css @@ -1,38 +1,52 @@ * { - color: #ebdbb2; - font-family: 'Inter'; - font-optical-sizing: auto; - font-weight: 400; - font-style: normal; + color: #ebdbb2; + font-family: 'Inter'; + font-optical-sizing: auto; + font-weight: 400; + font-style: normal; } strong { - font-weight: 600; - font-style: italic; - color: #fabd2f; + font-weight: 600; + font-style: italic; + color: #fabd2f; +} + +strong:hover { + color: #fe8019; } h1 { - display: block; - font-size: 2em; - margin-top: 0.0em; - margin-bottom: 0.0em; - margin-left: 0; - margin-right: 0; - font-weight: bold; + display: block; + font-size: 2em; + margin-top: 0em; + margin-bottom: 0em; + margin-left: 0; + margin-right: 0; + font-weight: bold; } h2 { - display: block; - font-size: 1.5em; - margin-top: 0.83em; - margin-bottom: 0.0em; - margin-left: 0; - margin-right: 0; - font-weight: bold; + display: block; + font-size: 1.5em; + margin-top: 0.83em; + margin-bottom: 0em; + margin-left: 0; + margin-right: 0; + font-weight: bold; +} + +a { + display: block; + text-decoration: none; + color: #83a598; +} + +a:hover { + color: #458588; } .katex { - width: max-content; - margin-left: 0; + width: max-content; + margin-left: 0; } diff --git a/src/routes/articles/technical-debt/+page.svx b/src/routes/articles/technical-debt/+page.svx new file mode 100644 index 0000000..29826f8 --- /dev/null +++ b/src/routes/articles/technical-debt/+page.svx @@ -0,0 +1,25 @@ +--- +title: C++ Technical Debt +date: "April 20 - 2025" +--- + + + + + + + +Have you ever had your project grow too messy that the idea of **total-rewrite** started haunting your +dreams? In this article I'll teach you how to avoid that state forever :) + + + +## Technical Debt + + + +What causes such a state? + diff --git a/src/routes/articles/the-graphics-pipeline/+page.svx b/src/routes/articles/the-graphics-pipeline/+page.svx index 95ea395..b348263 100644 --- a/src/routes/articles/the-graphics-pipeline/+page.svx +++ b/src/routes/articles/the-graphics-pipeline/+page.svx @@ -11,28 +11,39 @@ 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 beast. +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. I'll make sure you understand everything at the +end of our journey. If you still had questions, feel free to contact me :) + +So without further ado--- + +## Overview Like any pipeline, the **graphics pipeline** is 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 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. +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 +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 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). +// NOTE: twice "where..." + +The updated scene data is then prepped and fed to the **GPU** for **geometry processing**. Here +we figure out where everything ends up on our screen by doing lots of fancy matrix math. +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**. @@ -40,7 +51,7 @@ In other words, this stage converts a rather abstract and internal presentation 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. 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. +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 @@ -61,9 +72,9 @@ Ever been jump-scared by this sight in an First Person (Shooter) /> -In order to display a scene (like a murder scene), +In order to display a (murder) scene, we need to have a way of **representing** the **surface** of its composing objects (like corpses) in computer memory. -We only care about the **surface** since we won't be seeing the insides anyway---Not that we want to. +We only care about the **surface** since we won't be seeing the insides anyway---Not with that attitude. At this stage, we only care about the **shape** or the **geometry** of the **surface**. Texturing, lighting, and all the sweet gory details come at a much later stage once all the **geometry** has been processed. @@ -128,16 +139,20 @@ Also, it is a common practice in computer science to break down hard problems in This will be a lot more convincing when we cover the **rasterization** stage :) -Bonus point: present-day **hardware** and **algorithms** have become **extremely efficient** at processing -triangles (sorting, rendering, etc) after eons of evolving around them. + + +present-day **hardware** and **algorithms** have become **extremely efficient** at processing +triangles by doing operations such as sorting, rasterizing, etc, after eons of evolving around them. + + ## Primitive Topology -So, we got our set of vertices, but having a bunch of points floating around wouldn't be so -interesting, we need to form **triangles** out of them, or more specifically, **triangle strips**. +So, we got our set of vertices, but having a bunch of points floating around wouldn't make a scene very lively +(or even deadly), we need to form **triangles** out of them to compose **models**. We communicate to the computer what type of primitives we want to generate from our vertices by configuring the **primitive topology** of the **input assembler**. -We'll get into the **input assembler** in a second, but what is a **primitive toplogy**? +We'll get into the **input assembler** bit in a second, but what is a **primitive toplogy**? The way in which constituent parts are interrelated or arranged.--mid 19th century: via German from Greek topos ‘place’ + -logy.---Oxford Languages basically defines the way we connect our vertices together, it would be more clear to provide examples than drown you in theory. @@ -145,16 +160,22 @@ basically defines the way we connect our vertices together, it would be more cle As stated previously, we got 3 main types of primitives, **triangles**, **lines**, and **dots**. (There's also a **patch primitive** which we won't get into for now). Let's quickly run through all the possible ways we can make these 3 types of primitives alongside some visual cues. + +In the following equations, **p** stands for **primitive** and **v** stands for **vertex**. **Point list**: When the topology is **point list**, each consecutive vertex defines a single point primitive, according to the equation: + + + ```math - p_i = \{ v_i \} +p_i = \{ v_{2i},\ v_{2i+1} \} \\ +n_p = \left\lfloor \frac{n_v}{2} \right\rfloor ``` -As there is only one vertex, that vertex is the provoking vertex. The number of primitives generated is equal to vertexCount. + **Line list**: @@ -223,10 +244,10 @@ which processes the data we feed to it based on the configurations we set on it. The **vertices** and **indices** are provided to this stage via something we call buffers. So technically we have to provide **two** buffers here, a **vertex buffer** and a **index buffer**. -To give you yet-another ovreview, this is the diagram of the "Geometry Processing" section of +To give you yet-another ovreview, this is the diagram of the **geometry processing** section of our pipeline: - + Draw --> Input Assembler -> Vertex Shader -> Tessellation Control Shader -> Tessellation Primitive Generator -> Tessellation Evaluation Shader -> Geometry Shader -> Vertex Post-Processing -> ... Rasterization ... @@ -259,17 +280,41 @@ Draw --> Input Assembler -> Vertex Shader -> Tessellation Control Shader -> Tess ## Conclusion ## Sources -[Tomas Akenine Moller - Real-Time Rendering 4th Edition](https://www.realtimerendering.com/intro.html) -
+ -[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) -[Wikipedia - Rasterization](https://en.wikipedia.org/wiki/Rasterisation) -[Wikipedia - Euclidean geometry](https://en.wikipedia.org/wiki/Euclidean_geometry) -[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) -[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) +Mohammad Reza Nemati + + + + +[Tomas Akenine Moller --- Real-Time Rendering 4th Edition](https://www.realtimerendering.com/intro.html) +[JoeyDeVriez --- LearnOpenGL - Hello Triangle](https://learnopengl.com/Getting-started/Hello-Triangle) +[JoeyDeVriez --- LearnOpenGL - Face Culling](https://learnopengl.com/Advanced-OpenGL/Face-culling) + + + + +[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) + + + + +... + + + + + +[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) + + + + +[Drawing](https://docs.vulkan.org/spec/latest/chapters/drawing.html) +[Pipeline Diagram](https://docs.vulkan.org/spec/latest/_images/pipelinemesh.svg) +