DEV Community: NoticeableSmeh

Finally have gotten a bit into DirectX12! This part more theory!

NoticeableSmeh — Tue, 16 Jun 2026 22:13:00 +0000

NoticeableSmeh

Jun 16

Learning DirectX 12 - Part 4 Rendering pipeline

#programming #graphics #cpp #gamedev

4 min read

Learning DirectX 12 - Part 4 Rendering pipeline

NoticeableSmeh — Tue, 16 Jun 2026 21:13:12 +0000

Alright, time to cover some theory.

3D illusion:
You know how a computer screen is actually a 2D plane? Well how can it convey to our eyes and brain that something is in 3D? It does this by projecting a 3D environment to a 2D plane. This means the usual stuff like how things furhter away from the point of view are smaller, and things closer look bigger. If you have ever stood on abandoned train tracks and looked down you would notice that furthest away the train tracks dissappear into a vanishing point, this is why.
Lights and shadows also sell this illusion of 3D objects. It helps sell depth to an object and locational awareness. A primtive shape like a cube viewed would also just look like a 2D object without shadows and lights exadurating the lines forming the 3d illussion.

Model representation:
3D models are nothing but a bunch of triangles smooshed together in ways to make it's shape. Why triangles? Because triangles are the most effective way to store data, it is only 3 vertices you need to store per triangle. Anyways, 3D model files export from tools such as blender or maya can be exported as sort of giant .txt files. These often include just a list of an objects vertices and indices. This our program can read and build a 3D model.

Color:
Red, green, blue, Alpha.
Red = Red
Green = green
Blue = blue
Alpha = How strong color is

mix and match, colors often stored in vectors, badabing. Badaboom.

Overview of the pipeline:

Input assembler stage:
This stage takes in the data like vertices and indices from its memory and use them to assemble shapes.

*Vertices *
In Direct3D, vertices are stored in vertex buffers. We have to explicitly tell Direct3D how to assemble these points via functions on our commandlist that assign this logic. fore example we can define it as a line list, which interprets two vertices as an individual line, while a triangle strip interprets yknow a triangles, these are connected however, to seperate the triangles you would use a triangle list. This is better explained in the book because Luna provides some great pictures to explain this so if you dont get it. Go buy the book.

Indices
These are lists of often 3 vertices that define how to draw a triangle. If we have point A, B and C. We would define that triangle in our index list as A, B,C. Lets say however that we have another triangle above of our C point and our b point thats connected to this triangles side. Maybe we want to make a rectangle or square? Look at the image

We can define the green triangle as A, B, C on our index list. We can define the right triangle as B, C, D. So now we have reused vertices in our drawing of this square! Obviously reusing elements in computers make it run faster so thats why you want to use index lists like this.

Vertex Shader Stage
After the primitive shapes have been assembled. The vertices are fed into the vertex shader. This is important because vertices dont just hold data related to the location of each point, they can hold data such as, for example how strong the color should be at that vertex. This way you can determine gradient shift in color between two points as you often see in graphics demo examples. Its also important to note that we send of data from the vertex shader to the pixel (fragment) shader, which will be covered later.

Tessellation stage
Tessellation is essentially smart ways to optimize the load that graphics can take on computers. For example level of detail (LOD). Why draw a five-million vertex rich tree thats five thousand kilometers away? Really just a primtive shape at that point would sell the illusion of a tree for viewer looking at the screen. Once we get closer, That tree certainly has to increase in detail however.

Funny thing that I find with optimization with graphics is that it can basically boil down to: "Can the viewer notice?" And if the answer is no, then remove it or reduce its quality.

Geometry shader stage
The geomoetry shader stage is an optional stage, whats unique to this stage is that it can manipulate and even destroy/remove triangles / primitve shapes before shipping it of to the next stage. So it takes a look at the geometry! It doesn't look at the vertices it takes a look at the geometry hence its name.

Clipping
Don't render geometry that the player doesn't see. I just summarized that part for you.
Like geometry (Triangles) out of field of view, thankfully directx12 handles most of this for us.

Rasterization stage
I like to thing of this stage as from the perspective of each individual pixel. Am I inside this triangle? Yes, okay what color am I? etc. It's essentially just computing each individual pixel inside geometry.

Viewport Transform
This is the part were we convert all the weird coordinates and vertices and everything into a 2D plane to sell the illussion.

Backface culling
Important to note that Direct3D by default assumes the order of indices to be clockwise, if the indices end up going counter clockwise, the GPU will interpret them as facing backwards away from the camera. Therefore, it won't be drawn, So always make sure your indices are defined correctly.

Vertex Attribute interpolation
This is basically just talking about how vertices can store more than just positional data. Colours, normal vectors and texture coordinates for example.

Sidenote: I really love Lerp math formula, its probably my favorite formula of all time. CurrentPoint + (TargetPoint - CurrentPoint) * Scalar. Delicious

Pixel Shader Stage*
Pixel shaders are what we write, they are like fragment shaders in OpenGL. Fun stuff indeed. This will be covered more later on.

The output merger stage
Alright so now the final stage. Some pixel fragments might be rejected from our depth or stencil buffer tests. Fragments not rejected get written to a back buffer. Blending tricks can apply here, probably for glass and stuff or like water, seeing through stuff.

Alright that does it for this part, in the next part we will actually get deep into it and get a box rendered onto our screen. Exciting!

Learning DirectX 12 - Part 3 Initialization Code

NoticeableSmeh — Thu, 11 Jun 2026 19:10:09 +0000

I will be using the demo code provided with the book in order to progress in my learning at a relatively quick rate. However, I do plan on returning later on and rewriting this entire thing to really make it my own by the end of this series. I will probably be doing that with SDL, because I like SDL and I know it better than windows programming.

The books source code provides sample framework which hides a lot of boilerplate code that is pretty standard when setting DirectX12 up. This is hidden for us in the file d3dApp. I will be covering how the setup with that code works as I feel that will be great for learning. Although I wont cover every line of code because that would be impossible.

So I will walk through the initialization code essentially linearly and explain each step of the way what happens in each part until we get to the end result which is an empty window with some ImGUI elements.

This is the main way entry point of the program. This code here is more related to windows api and creating applications with windows, the important part here is the initialize function and the run function on the MyApp instance, which is ourApp :)

Going through our MyApp class we call the D3Dapp::initialize (we inherited D3DApp to our MyApp as a form of wrapper for boilerplate stuff). This D3DApp helps with a lot of boilerplate but is quite long so I wont cover it entirely just the really really important bits.

We call the functions to initiate both the window of our application and actually initialize Direct3D here finally.

Here were creating and utilizing a smart pointer for our 3D hardware AKA our graphics card.

This function create the command objects needed for the command process from the cpu to the gpu.

Creating first a command queue which can execute all GPU commands.

Second created hre is the command allocator this serves as a sort of basis of memory in which the our command list created thirdly here us to present itself in our command queue.

A more concrete way of looking at it:

Lets just summarize the difference between these three things, were actually creating these things here in the opposite order of how they would be used.

A command list is an (or multiple) instruction of what the GPU should do. "Draw a box" for example.

A command allocator are what the instructions are written on. It is literal memory that we have access to. We need our command list written down on something tangible, that is what the command allocator is. It allocated memory to record the command list to.

The Command queue is the actual queue, as a person standing in line waiting for their turn, our command lists wait in line for it to be executed.

Think of it this way. We have a command to tell someone to do, this person is very far away so we can't just shout the command at them, so we need to send them a letter. The command we have is "Draw a horse".

So we record our command "Draw a horse" (This is the command list) and record it onto a piece of paper (Command allocator) and we send it of to a person (GPU). This person receives a lot of letters, so people wait in line (Command queue) to give their letter to this person (GPU).

Here were creating the swap chain, the swapchain is what we use to switch between the back buffer and front. Important to note here is that we send in our commandQueue in this argument so its important this stuff is done in the right order.

Descriptor heaps
This is actually very cleverly named because it is exactly what its named. Its heaps of contained information of the related acronyms. RTV (Render target views) tells the GPU where to draw the pixels or vertices, DSV (Depth stencil Views) cover the order in which to draw them.

Lets cover the draw function now. This is a long one so bare with me.

Here we have another big old data heap collection:

CBV - Constant Buffer View: This is very useful as a sort of container for "global variables" accessible for your shaders. Lets say you want to pass the coordinates of a cameras position to a shader, you can put that data in a constant buffer and create a CBV.

SRV - Shader resource view: These are typically for reading textures. If you want to map an image on a 3D model, the sader reads that image through the SRV.

UAV - Unordered access view: This are both read and write buffers. These allow shaders to read and write to a buffer at the same time. Useful for certain things that I do not understand yet.

As you can see these things are more directly related to shader programming and will make more sense later on.

We start of the function by grabbing a reference to our heap we created earlier, the cbvSrvUav heap that is. Then we wipe the old memory allocated on our Cmdlistallocator and same thing with our actual command list.

This is where I think it becomes increasingly obvious how DirectX12 is a state machine because when examining this code here it is very similar to how OpenGL works. You assign what descriptor heap to use then you assign what part of the render target is visible and then what pixels should be draw on the screen. It is really a step by step process.

Finally with the resourceBarrier we are telling the GPU what buffer we want to be written on. We issue a command via our command list to clear the screeen to one colour. Clear depth aswell while we are at it

Transitioning the back buffer to the front buffer and then finally presenting this buffer.

At the end there is a helper function defined in D3DApp that helps force the CPU to wait until the GPU finishes.

When we compile and finally run our application we will finally get this screen.

Really at this point I am very excited, I have probably spent upwards of 30-40 hours reading through taking notes on this book, trying to work through it and to really understand it deeply and finally actually having a window popup feels like a big reward.

See you in the next part we will tackle the chapter on the rendering pipeline!

Learning DirectX 12 - Part 2 Initialization Theory

NoticeableSmeh — Sun, 24 May 2026 19:10:53 +0000

WTF is Direct3D ?
Direct3D is essentially just a middleman between our code to a GPU. Its an interface in which to interact with the GPUs. Each GPU as I'm sure you know is different, so each GPU has its own way of doing things. This is where Directx comes in and essentially acts as an universal translator from our code (in Directx12 c++) to machine code for the GPU to execute. This ofcourse means that Nvidia, intel and AMD (manufacturers of GPUs) work hand in hand with Microsoft (who make DirectX) in order for these things to work the way they should and to have somewhat of an universal workings of things.

Component Object Model:
This Component Object Model often shortened to COM is what allows DirectX to be programming language independent. The COM interface is hidden to use when we write code, we usally don't interact or change stuff in it directly. We manipulate COM through pointers and references to the object. We DONT create new COM objects via the c++ new keywords. If you have ever taken a C++ programming course this is pretty basic stuff as your teacher might have said (as mine did) "Don't touch code unless you have to" but with a strong eastern european accent. We access COM objects via references and in order to free the memory that take up the space from this we call a Release method (Important to note that all COM interfaces inherit from an univeral IUnknown COM interface, which provides this release method). When a COM object isn't referenced anywhere their memory is freed up (Although this is done manually)

Thankfully we have Windows Runtime Library (WRL) to help with this pointer to the COM class, as this essentially works as a smart pointer (Thank god) so that the memory gets released automatically when the reference goes out of scope (Oh how I love you smart pointer).

Small note:
I won't cover code right now in this part I will do that in a later part so right now I'm just trying to get you (and me) familiar with these concepts enough so that when we introduce the code, we will have an overall understanding of it. I should mention that I will repeat things like crazy in this series, such is just the consequence of writing this devlog because how the fuck am I supposed to keep track, so if you don't get a concept or don't understand it, That's probably because I don't really understand it and haven't explained it well, So we will return to that later!

Texture Formats
2D image mapped onto a 3D object to give a texture, you know you can have a cube but in order to make a wooden box we gotta give a wood texture. Think of a grass block in minecraft

each side has a 2d image projected on its square face. Now you can do loads of fun and more technical stuff with textures but we will cover that later!

The Swap Chain
When rendering its best to draw the future first and then present the image, the current image is whatever last was drawn. Think of it this way, we have a front and back buffer. The front buffer is whats currently on the screen, you have your minecraft pig beautifully drawn on that front buffer and you see it. On the back buffer we have drawn a Minecraft Creeper, boo! Now when we swap these two frames, the back buffer for the front buffer. The back buffer becomes the front buffer and the front buffer becomes the back buffer, but now what we see is the Minecraft creeper! And the next frame we want to draw a Minecraft cow so we now render that cow onto the back buffer and swap it with the front buffer to display the cow!

This is called double buffering when you have a front and back but triple buffering exists aswell but yknow just cuz it exists doesn't mean I have to cover it, but I think you can figure it out.

Depth Buffering:
Depth Buffering is a fairly fun concept in DirectX12, essentially every pixel on our screen has a value between 0.0f and 1.0f. 0 denotes the closest an object can be and 1 denotes the farthest away an object can be. Why is this relevant? Because we have to keep track of what to draw in front of what. Lets say we have a box in front of another box, the pixels that are of the box infront of the other box are the ones that should get prioritzed to get drawn, not the backbox, those shouldn't get drawn. So depth buffering is a way to essentially understand what pixel should be drawn depending on an pixels depth. Important to note that thanks to this it does not matter what order we choose to draw stuff in DirectX12 aslong as we have properly working Depth Buffering. A depth buffer is texture, important to note so it must be created with certain data formats in DirectX12.

Resources and Descriptors:
If you read my LearningOpenGL series I covered what a StateMachine is. Essentilly what it is, is that you have to be very explicit with the API. Imagine youre trying to describe a painting to someone and your goal is to get that person to paint the painting you have in mind. So you say like, Pick up the pencil -> make that pencil red ->paint on the paper from here to here. As you can see these instructions are essentially different states that the person finds themselves in. Directx12 is very similar to this, you have to tell it explicitly and methodically each step everytime you want to do something. Oh so you want to paint with a blue pencil now? Well time to go through each one of these steps again. I overexagerate but at the same time I don't. These specifications and heavy way of handholding you have to do is what makes DirectX12 so performance optimizable, absolute control.

During rendering the GPU writes to resources, back buffer, front buffer and depth buffer for example. Reads from resources that store things such as textures, 3D positions etc. Whenever we draw something we might need to change the resource in which we draw from. Resources are not referenced directly, they are referenced from descriptor objects. The reason for this is so that the descriptor object can easily translate to the GPU for us what the actual fuck we are going to use this resource for. It is essentially an abstraction layer to make our lives easier (Thank god). This also means sometimes we don't have to bind the ENTIRE resource just a section of it so we do not waste computer power.

Descriptors have types, these are allegedly the types we will use.

CBV/SRV/UAV describe constant buffers, shaders and stuff like that.
Sampler descriptors used for textures I guess
RTV descriptor describe render target resources, whatever that means
DSV descriptor describe our depth and stencil resources (Hey I know that)

These 4 are what Frank D. Luna bring up in his book here, honestly I do not really understand this at this point exactly these different types but I am sure I will understand better as we delve deeper into the code in the future.

DirectX Graphics Infrastructure:
DirectX Graphics infrasctructure is essentially an API you use along Direct3D. It's purpose is to handle more universal aspects of rendering. In 2D rendering you also need a swap chain for example to get smooth animation etc. For our purposes its worth noting that DXGI is what handles display adapters (Graphics cards). A graphics card can have multiple display outputs, so in other words. This is all a way to assign a graphics card or so to what screen it should render to, we typically don't actually assign manually the displays (thank god) but DIrectX Graphics Infrastructure is useful for outputting what our hardware is. A system can also have a software display adapter that essentially works as an emulator for graphics functionality (In this way we can fake the rendering capabilities over to the CPU).

This output of our hardware that we have access for is useful so we can properly assign important values for example refresh rate and resolution. These have to perfectly fit, so why not use this universal stable way of gathering this output.

Residency:
Obviously its completely pointless to have resources loaded to the GPU that arent needed for the current scene. As the books example is, the GPU doesn't need the Cave resources if the player finds themself in a deep forest. Therefor its important to make memory resident and evict memory. This is typically done in cases of like level changes and or drastic huge landscape shifts (There is overhead to constantly change out resources like this so you only do it during select periods).

Heap vs Stack:
The heap is just a dedicated chunk of memory, in C++ things created on the heap are typically done with the new keyowrd for example. This variable that is created with this new keyword lives past when the variable goes out of scope. In other words if you create for example a player character like
Player* ptr_Player = new Player("Guyman"); Then that piece if memory will always be there, it will not get destroyed until we deliberately delete that player.

Creating things on the stack essentially means we are creating it and assigning it in memory and that memory gets freed up automatically when the variable for example goes out of scope.

Resources:
Buffers: Are arrays of data elements that are of a certain type. I like to think vertices here, a list of vertices that make up our beautiful shrek model we are loading.

Textures: Image data, storing a grid of image data is how Frank D Luna describes Textures right now.

Commited Resources:
A single API call creates the heap at the same time as you create a resource. In this way these both are bound together, simple right? Well this is quite expensive and ideally shouldn't be done whilly nilly. This is useful for things that need to be created during initialization and not per frame.

Placed Resources:
Create a large heap, then assign the resources into that heap. It is a way of seperating allocating memory and creating resources in memory. Placed resources are much faster to change directly per frame so this is great for things such as resource creating/destruction.
Think of it this way, it would be really annoying and time consuming to have to create a new flag everytime you want to wave it around so instead someone tells you the location of one flag you created previously. Now everytime you want to wave a flag, you just go and get your flag.

Reserved Resources:
Imagine you have a huge world map, it would be pretty stupid to have the entire world map loaded up in memory if the user is say zoomed into just Stockholm, Sweden. So just load the parts neccessary needed for the current operation. Reserved resources are essentially just chopped up big resources whose pieces are served depending on if they are needed or not.

CPU / GPU Interaction
Both the CPU and the GPU do a lot of work in graphics. They do different things however they work together to render our beautifully disguised triangles. The GPU has a command queue, the CPU enters commands to the queue through the Direct3D API, this command is added to a stack and or queue and it isn't until the GPU has finished commands before the command reaches the front, in which the command is executed. If the command queue is empty, The GPU will idle. This ofcourse is not ideal as we ideally want our GPU and CPU to always be working on something to get the most performance we can out of software.

CPU / GPU synchronization
Given that the CPU and GPU work together asynchronously then the GPU and CPU can't do stuff that would later be contridicted by the other. Therefore a way to solve this is to force the CPU to pause until the GPU has finished all its stuff. This is ccalled a fence point that you specify in code.

Resource Transitions:
Lets say the GPU is working on a resource, this resource is probably not safe to do a lot of operations on as things are being changed about it. Therefore marking the state of that resource to a sort of state as "being worked on" would help a lot in order to avoid resource hazards. This is essentially what Resource Transitions are for, a way to mark states for resources in order for the API to alleviate problems that would occur if something wants to poke at what the GPU is currently working on. Now this state isn't just a declaration of "being worked on or not" but more a descriptor of how the resource is being manipulated right now by the GPU.

Final Words:
We are getting dangerously close here to my brain exploding from all this information but thankfully, I think it's time to begin writing some code. In the next part we wil finally cover the code needed to initalize Direct3D (Finally!).

Learning DirectX 12 - Part 1 Boring boring Math stuff

NoticeableSmeh — Sat, 16 May 2026 13:05:20 +0000

Hello and welcome to this little blog where I will be going through Frank D Lunas book on DirectX 12 "Introduction to
3D Game Programming
with DirectX® 12"

This is is supposed to be a blog for helping me gettig a deeper understanding for DirectX 12 however since it might be of interest to some other person out there, feel free to continue reading along this if you too want to get a better understanding of Directx12.

The first section of the book covers Math stuff you need to know, so why not dive into that. I will ofcourse be reading the entire chapters of the book and work my way through it but I will not be providing a detailed walkthrough of the the entire book as that would just take too much time ofcourse. What you will see here is a birdseye view / summary of how directx12 works. First section of the book deals with Vectors so lets start with that.

Vectors:

DirectX12 uses a left handed coordinate system, this is important to note because OpenGL used a right handed coordinate system, and thats what I am used to by now. A left handed coordinate system means that the positive Z axis is pointed away from you, not towards you. Now lets delve in to define more of what a vector is.

I think of a vector as a point in a coordinate system and we compare that point to the origin point to see what direction and length the vector has. So lets say our 2D vector is 1, 1. This would mean that the vector points up and to the right completely diagonally. Now people will tell you that "oh you shouldn't think of vectors as a point in space they can contain / mean other stuff" And to that I say --.

Magnitude
The magnitude of a vector is simply the length of a vector, or more acrrately the length of the directed line. To denote this we put ||u||, | bars around the vector "variable". And to get the magnitude we simply apply pythagoras theorom to our entire vector. So if its a 3D vector thats Sqrroot(x^2 + y^2 + z^2). This would be the magnitude of the vector.

Normalization
You might have heard about this if you have ever done any type of game programming. A common problem with 2D movement diagonally is that its faster than moving just purely left or right. This is because defining a vector as up and to the right would look like this right (1, 1, 0). Whereas moving just purely right would just look like this (1, 0, 0). As you can see were essentially moving another whole extra unit of our vector each time we move diagonally. We can explicitl see this if we calculate the magnitude of our vectors here. The vector moving diagonally would be equal to squareroot of 2 which is aproximately 1,4. We should ideally have the same speed no matter the direction in which we are moving. The way to do this is by normalizing Vectors. This would mean that the vectors magnitude alwas equals to 1. The way to do this is by taking every x , y and z component of the vector and dividing it by the the ssquareroot of the magnitude.

Dot product
A dot procut is the result of multiplying two vectors with eachother. The result is a scalar value. This scalar value we can use to determine the angle between two vectors. Essentially if the result is equal to 0 we the vectors are perpendicular to eachother. If its bigger than 0 then the angle is sharp, pointy. And if its less than 0 then its stubby or obtuse. We have to involve cos Theta into our calculations whihc means we take the scalar product and divide it by the magnitude of vector 1 times the magnitude of vector 2.

The Cross Product
Cross product is used to produce another vector perpendicular to the two vectors. Taking each element (x, y ,z) and multiplying that element with the othr two. So to calculate X you multiply x with y and z. The only exception here is the middle coordinate Y which you change the sign before the number to the opposite, so positive becomes negative and vice versa. This is all sort of abstract right now but will make more sense as we delve into it deeper.

Matrices
Matrices are what allow us to move, rotate and scale objects in 3D space. Think of them as a tool used to transform vectors.

A matrix is grid of umbers, in graphics programming typically you just use 4x4 matrices. Why is that? Because they allow us to handle all transformations in a consistent way when working with 3D vectors.

Vertices
Vertices are what store the actualy data containing our object we import. So a vertex array is an array of point which will paint up a bunch of traingles forming for example a sick dinosaur, matrices are what we apply to those vertices to translate and or transform that vertex array.

Matrix x Vector
Multiplying a matrix with a vector is one of the most important operations. It looks like this v' = M * v. What this means in practice is we take a vertex (a point in our object) and apply a transformation to it. v is the original position, M is the transformation itself and v' is the transformed position or the result.

Transformation
We will cover this more deeply in the next chapter but matrices are used to perform transformations such as moving an object, scaling an object and rotating an object. Instead of manualy changing every vertex we can just multiply them with a matrix.

You can combine multiple transformations into one, rotate then scale then move for example. We can define the matrix via for example M = T * R * S, then just apply that matrix to our vertices like v' = M * v. Efficent right we do not have to calculate each part everytime!

Order matters
Very important to note that the order in which matrix multiplications are done is very important. Rotating an object then moving it is not the same as moving an object and then rotating it! It wouldn't be the same result!

Directx12 Coordinates
You constantly work with the big three in Directx12. These are:

World matrix = Positions of the object in the world
View amtrix = represents the camera
Projection matrix = converts the 3D world into 2D screen space to be drawn on your computer screen.

Homogenous Coordinates
If you have a point (x, y, z) you can scale it, rotate it all using a matrix. But if you want to move it, you cant do that with a normal matrix.

Matrix multiplication is like
new = numbers * old

translation however is
new = old + something

Matrix math doesnt handle the + part.

So we cheat by adding a 1 at the end of our vector / point
(x, y, z, 1)

That extra 1 lets the matrix sneak in a constant value, which allows us to actually translate the location. Without the 1 there would be nothing for the matrix to multiply with to add to those values. So the 1 turns multiplication into addition so to say.
This is also essentially why we use 4x4 matrices in graphics instead of 3x3.

I have a headache now so I'm gonna end the math stuff here and cover more the directx initialization theory in the next part. See you there!

Rasterizer Project - The end? is published

NoticeableSmeh — Fri, 07 Nov 2025 22:11:43 +0000

NoticeableSmeh

Nov 7 '25

Rasterizer Project - Part: BASIC_END

#cpp #graphics #learning #gamedev

4 min read

Rasterizer Project - Part: BASIC_END

NoticeableSmeh — Fri, 07 Nov 2025 22:11:30 +0000

Hello folks lets continue working on this rasterizer, lets get the rasterization going and then were putting this project on hold for a while. I will be making the DoingOpenGL series after this part were I will get a graphics demo going for OpenGL stay tuned for that but heres what were doing today.

So to avoid going too into detail and just making this just completely unreadable I will be trying to keep my explanations more concise and quicker with fewer images just so we can get through this stuff together folks

Here is our triangle fill function, this essentially takes coordinates for 3 different points and fills the area between them. This is finally were barycentric coordinates finally get more useful but more on that in just a second.

Anyways we stard by defining our max and minimum on our 2D plain view for both the X and Y coordinate, this is simply just to ensure that we never paint outside the actually triangle.

So to figure out if a pixel should be painted or not (in other words if its inside the triangle) You use barycentric weights. These are essentially three numbers that symbolize how close that pixel is to each vertex of the triangle hence why we have three numbers. Inside the triangle those numbers always stay between 0 and 1 so we are essentially just making sure that none one of them are negative and all of them added together sum up to 1.
That is what this if statement checks here

For the more meaty math lets take a look more here

denom here is jus tone big number that represents the triangles size and if its zero that means the points are all on one line, nothing to fill essentially. The way to calculate it is from the differences between the triangles points, how far apart they are on each respective axis. Were counting the area here folks essentially we just dont care about dividing it with 2 because it doesnt really serve a purpose in knowing the exact area size, we care about ratios.

So in our code we define our direction of calculating the side that is inside (good side) or outside (bad side) from clockwise direction, which is different from how a lot of other program use it. This however is still fine but this means that if we were to orient our Edges upright it would mean the right side is the side that is inside the triangle and the left side is the one that is outside.

Phew, I am not very good at math but thats my best attempt at explaining this for you as simple as I could.

Time to break down this function. This function has my favorite type of for loop (yay) and it loops through our face count (our amount of triangles inside of our model.

Each face in our model has three vertices, of course, and we then project those vertices into a 2D view, since we’re currently rendering in 2D space. Although the model itself exists in 3D, we’re essentially flattening it onto the screen, turning it into a 2D representation we can draw.

We retrieve each vertex based on the current face index in our loop (since faceCount gives us how many total faces we have). From that index, we can access the first vertex (our A coordinate), then the second (B), and finally the third (C).

Note: Remember that in programming, we start counting at 0, not 1!

Then that backface culled skips triangles that are facing away from the triangle, more on that in a second. And the color of the triangle each gets a random RGB value so via a modulo variation that makes it always unique thanks to our facecount index. I say random in the sense that I have no clue what colour it will be when you run it but really it will always be the same colour on compile.

Alright so this function essentially checks if the triangle is facing toward or away from the camerea. So the first part abx and acx we make towo edge vertex, vertex from a to b and a vertex from a to c. These vectors describe the direction of the triangle in 2d space. Then we are computing the 2D cross product via area2. If the tirangle area is zero or facing the wrong direction dont draw it! Simple. Anyways lets load this cow! That I found on the internet.
https://www.cs.cmu.edu/~kmcrane/Projects/ModelRepository/

So we declare the model and the name of the file as we did in the previous part and then we call our function drwa model filled and pass in the model and our framebuffer and voila

There we go folks,

Thank you for reading and here are some useful links aswell as sources

https://haqr.eu/tinyrenderer/
https://www.cs.cmu.edu/~kmcrane/Projects/ModelRepository/
@article{crane2013robust,
title={Robust fairing via conformal curvature flow},
author={Crane, Keenan and Pinkall, Ulrich and Schr{\"o}der, Peter},
journal={ACM Transactions on Graphics (TOG)},
volume={32},
number={4},
pages={1--10},
year={2013},
publisher={ACM New York, NY, USA}
}

https://3d.si.edu/object/3d/triceratops-horridus-marsh-1889:d8c623be-4ebc-11ea-b77f-2e728ce88125

https://github.com/nothings/stb

The git repository for this project is also avalible at: https://github.com/NoticeableSmeh/Rasterizer_Project

Rasterizer Project - Part 4: Its out featuring Dinosaurs (rawr)

NoticeableSmeh — Wed, 05 Nov 2025 13:49:59 +0000

Rasterizer Project - Part 4: Triceratops Wireframe

NoticeableSmeh ・ Nov 5

#gamedev #cpp #graphics #learning

Rasterizer Project - Part 4: Triceratops Wireframe

NoticeableSmeh — Wed, 05 Nov 2025 00:15:36 +0000

Okay so its time to define our model class both its .h file and cpp file. Lets start with the .h file.

First lets define a vector list made of of different vec3 that our model consists of and then lets.

Then we store each face inside the int list. What is a face? Well every 3 vertexpositions we can draw a triangle, that triangle is the face.

Then for our public class stuff. Our constructor takes a string path (constant so we dont fuzz about with it accidentally later on). Then our functions, quite simple. Constant get functions because we dont intend to change models after they have loaded in right now so our vertex count and face count will not change. Lets take a look at the cpp file now

Lets start simple with this little helper function that takes a reference to str and the reference we have to check if equivalence. Our .obj files for models are essentially text files with data stored in rows, each row starts with v or f and if the program sees those it knows what type of data the numbers after are. Heres an example:

those are the vertex positions for example that we have to read.

Anyways the helper function checks if the str size is larger or equal to the reference, then we actually check if our firstletter is correct with the compare function.

The compare function works like this, takes this string we have and start from this position in the string (0) and continue until the end of this index (firstLetter.size(), then if its equal to this string (firstLetter) then its correct and therefor == 0. 0 Means they are equal.

So lets go through this constructor.
We create a ifstream that takes our filepath and tries to find it, if it cant fidn it it throws an error.

Then we go line by line and read the line and if the line starts with the letter v we use a istringsteam to be able to manipulate the string, essentially we skip the first two positions in the string with substr(2) (More acurately we start at 2.
Then we feed in our coordinates with istringstream dynamically because istringstream are super usefull and we place them in our vector list but we use emplace_back to create a new vec3 in our vector list.

We do the same thing if the line starts with "f", which means it defines a face.
Each face line in an .obj file contains multiple vertex references separated by spaces — for example:

f 1/2/3 2/3/4 3/4/5

We split the line into separate sections (like "1/2/3", "2/3/4", etc.).
Each section contains vertex information, where the first number before the slash refers to the vertex index.

To extract that, we look for the first / in the section using find('/').
Then we take everything before that slash thats the vertex index we care about using substr(0, slashPos).
We convert it to an integer with stoi() and subtract 1, because .obj files use 1-based indexing, but us programmers like to start at 0.

Then we just store that int in our int list.

getVertexCount we return the size of our vertexPositions list.
Facecount we return how many faces our object has, its the amount of faceVertexIndices / 3 because 3 vertices make up a triangle duh.
getVertex gets you the vertex from the index you send in.
getVertexFromFace() This method takes a face index (yknow triangle) and a corner number which represents a vertex of that triangle then looks up which vertex that corner refers to and returns its 3D position. So for this to make sense we have to remember that our faces are defined in our .obj file as "f 1/2/3/" etc etc, so were essentially saying, gimme the second vertex (in plain english)! It would return the number 2 in that.

Next lets head back into our main c++ file. So our models are in 3d right but we are presenting our models on a 2D plain, we have to have a function that converts 3d space into 2d space projection.

Alright so what this function does is take our 3D vertex coordinates that go from -1 to +1 (you know, model space) and remap them to 0 to screen size. We basically stretch our model to fill the whole screen.
Then we just return those two values (x and y) so we can use them as pixel coordinates when drawing lines between points.

Here we see were we instantiate our model and declare its file path but also how we draw it out!

So once our model has loaded we create my favorite type of for loop which i use for like everything lol. But we declare a starting int variable and then we add + everytime we complete the loop and it finished when the model runs out of faces. So we retrieve the vertexes from their face respectively, this is where we get to use our getVertexFromFace function finally and here we also confusingnly get to use programming language with our index "Start at 0 for the 1 position this time!". We assign those vertices and then we project those vertices via our project function in order to figure out where they should be on our screen.

Then finally we draw our beautiful lines, and by the end we will have this beautiful triceratops that totally does not look like a big blob.

Rasterizer project - Part 3 is up! Its all about 3D math. It was actually quite a fun thing to write about.

NoticeableSmeh — Sat, 01 Nov 2025 23:16:07 +0000

NoticeableSmeh

Nov 1 '25

Rasterizer Project - Part 3: Geometry

#cpp #learning #graphics #gamedev

5 min read

Rasterizer Project - Part 3: Geometry

NoticeableSmeh — Sat, 01 Nov 2025 23:15:16 +0000

So lets create a geomtry.h so we can actually calculate the 3d math we need for our rasterizer to work.

Lets start with this struct. This is ofcourse a vector 2, 2 coordinates. Default constructor is asserting 0, 0 on them, otherwise you can declare them.

The operator functions return asign so you can return a value of either the x of y via an integer. What helped me understand this is to think of like OpenGl VertexAttrib, or assigned textures in Opengl. You assign them to an int and via that reference you can access that component in the array.

The vec3 struct works the same but with 3 components instead of 2! Excitng. What is assert? Well it checks wether or not a condition is true and if it isnt lets crash the program and display a problem so we can see what went wrong.

Now lets do math magic, this is math guys this is all math.

Except this one here this is just an overrided function that allows us to write out a vec2 as a string with our cout, its like @override in java for toString().

heres our + operator, adding two vectors together is essentially just adding together each x and y with the coresponding x, y of the other vector. So 1, 2 + 2, 1 = 3, 3. Its quite simple really. if we just want to add to like for example the X coordinate, we just make do 0 on the Y like 1, 0.

Now were done with establishing the basic math of vec2. Lets start doing the vector 3 stuff!

minus - works the exact same way as + just with -.

heres how the * functions if we multiply a vector by a scalar. Pretty simple I mean you know this. I dont really know how to explain it honestly we take it each coordinate times the scalar, and if we reverse the order we take the scalar first times the vec- you get it.

Division works just the same as the first multiplication method we defined but with /. You might be thinking, huh how come we need 2 different methods for * but only 1 for /? Well its simple dummy, You cant divide like this Scalar / Vector. Like what are you trying to accomplish here?

Now its time for some slightly harder math

Here is how we calculate our beautiful dot product. The dot proct lets us calculate how aligned two vectors are. The closer to 1 they are the more aligned and the closer to 0 the closer they are to being perpendicular. So if its 0 its completely perpendicular as in 90 degrees. However the dot product can also be negative, if this is the case it goes past those 90 degrees and faces away from the other vector. So the closer to -1 the closer the lines are to being opposite. The way to calculate a dot product is by multiplying each component of the vectors by one another and then + the x and y results of that.

So to calculate the length of a vector we use pythagoras theorem, that classic square root of (a^2 + b^2), I knew I had a reason to learn that in school!

Now this is a helper function to our normalized function which looks like this.

Normalizing means keeping a vectors direction in accordance to the origin point but making the it length of 1. We figure out the length of the vector via pythagoras theorem. We then divide the X and Y coordinate by that length. Now we get 1 length of the vector! Worth to note that if a vector is 0, 0 we return that vector but otherwise run that calculation of dividing.

Now the vec2 math stuff is done and we can move onto the vec3 stuff.

Addition with vectors is still pretty easy and its the same for minus on the vectors aswell.

Multiplication works the same as vector2 you just add another coordinate to multiply.

division works the same essentially just with an added z.

Heres our dot product, it is also the same as before essentially we just need to add each vectors z value and multiply those together and add them to our total.

Calculating length is the same principle we just gotta add the z value, this is getting quite repetetive right.

And our normalize function is exactly the same we just take a vec3 instead of a vec 2!.

Finally we have this juicer of the cross product.
We are using a right handed cross product system which means that our perpendicular vector created by comparing two vectors will be positive facing us and negative going away from us. I like to think of cross products as you are taking two lines and adding them ontop of eachother, where they both intersect you stick a needle through and thats where your new vector is. This new needle is perpendicular to both our other vectors, and depending on if its a right handed system or not were sticking the needle through the front (if left handed) or through the back so the needle is facing us (right handed).

The way to calculate the cross product in math is i like to picture it as you have to multiply all different combinations of each vectors x, y and z values and then subtract it by another. Excluding if they have the same coordinate designation, like you wouldnt multiply A.y and B.y together. It is honeslty though probably the hardest formula to remember of the top of your head, so I always google it but hey it works.

That does it for this part, really excited to actually dive deeper and draw some wirefram models but this has been very rewarding on the math aspect as that is were I am definitely lacking the most.

Part 2 is up on the Rasterizer Project, were actually drawing a triangle now! Exciting!

NoticeableSmeh — Fri, 31 Oct 2025 14:23:23 +0000

NoticeableSmeh

Oct 31 '25

Rasterizer Project - Part 2: Lines and Optimization (Excited reaction)

#learning #graphics #cpp #gamedev

5 min read