3D Rasterizer Engine

The whole pipeline, by hand

A mesh is loaded from an .obj file, transformed through the engine's own vector and matrix types, projected with a perspective camera, then filled triangle by triangle into the frame Pygame puts on screen. A z-buffer decides which fragment survives where two triangles overlap, which is the step that separates a renderer from a drawing of one: without it, correctness depends on the order the triangles happen to arrive in.

Why write the maths first

The vector and matrix types are the real subject. Writing them puts the transforms, the perspective projection and the camera rotation into visible code rather than into a call. That was the whole point of it: implementing the full pipeline, projection and z-buffering included, is what gave me a deeper understanding of how a GPU actually operates at a low level.

A z-buffer decides which fragment survives where two triangles overlap, which is the step that separates a renderer from a drawing of one.

What the frame shows

The screenshot in this repo is a debug view and makes no attempt to hide it. Flat-shaded terracotta triangles are drawn over their own white wireframe, several objects share the scene, an axis gizmo sits in the top right, and the corner readout gives an FPS figure near 75 and the camera's x, y and z. Wireframe and solid are separate modes, which matters because a rasterizer is easier to debug when you can see the edges you are filling between.

The oldest thing here

June 2023 makes this the earliest dated project in the index, and it is the one the site's first plate is built on: write the pipeline, then import one. The classifier on the same plate is the other half of the argument, an SVM written before sklearn was imported.