Purracle Engine

There's a certain kind of madness that takes hold of a programmer when they look at Unity or Unreal and think: I could build that. Not because it's practical — it isn't — but because the process of building it teaches you things no tutorial ever could. That's the place this engine came from. And after countless late nights debugging shadow maps and wrestling with quaternions, I have something I'm genuinely proud of.

Here's a tour of what's inside.

The Rendering Pipeline

The renderer is where most of the interesting work lives. It started with a Forward Renderer and ended up being Deferred! More efficient, more scalable solution for game development. At its core, the engine supports normal mapping, specular mapping, and shadow mapping, which together give scenes a convincing sense of depth and materiality that flat-shaded geometry simply can't achieve.

The engine also supports mipmap settings, so texture quality degrades gracefully with distance rather than shimmering with aliasing artifacts. It's one of those features that's invisible when it works and deeply annoying when it doesn't.

Lighting System

The lighting system supports three types of lights: point lights, directional lights, and spotlights. Each is fully configurable — you can set the color, adjust the intensity, and tune the attenuation curve to control how quickly light falls off over distance. Spotlights have configurable cone angles, which makes them great for scene drama or simulating practical lights like desk lamps and flashlights.

Being able to place multiple lights of different types, give them distinct colors, and see how they interact in real time is one of those features that makes the engine feel genuinely alive to work in.

Animation and Model Loading

For model loading, I integrated Assimp, which handles FBX files along with a range of other formats. On top of that, I wrote a custom .obj loader from scratch — partly for learning, partly because having direct control over the parsing pipeline is useful when dealing with malformed or unusual files.

The engine supports animation of rigged models, meaning you can load a character mesh with a skeleton, import keyframe animations, and play them back at runtime. Skinning, bone transforms, interpolation between keyframes — it's all there.

Scene Management and Serialization

Scenes are organized with a proper parent-child hierarchy, so you can group objects, attach accessories to characters, or build compound objects that move and transform as a unit. This kind of scene graph is foundational to how any serious engine organizes its world.

Critically, the scene can be saved and loaded via binary serialization. This covers both the scene structure itself and model data. Binary serialization is faster and more compact than text formats — loading a complex scene is nearly instant, and the files don't balloon in size. Implementing it yourself also means you understand exactly what data you're persisting and can evolve the format as the engine grows.

Camera Configuration

Cameras are first-class objects in the engine. You can place multiple cameras in a scene, configure their field of view, near and far clipping planes, and switch between them. Whether you want a fixed cinematic camera, a free-fly editor camera, or something locked to a character, the camera system is built to be flexible.

Editor UI: ImGui and ImGuizmo

The editor interface is built with Dear ImGui, which is honestly one of the best tools in the C++ ecosystem for this kind of work. The result is a clean, user-friendly interface for managing scene objects, tweaking material properties, configuring lights, and adjusting camera settings — all in real time.

I also integrated ImGuizmo, which adds interactive transform gizmos directly into the 3D viewport.

What This Project Actually Taught Me

Building an engine from scratch isn't about producing something better than Unreal. It's about developing a mental model of how 3D software actually works at every level — from how a matrix gets uploaded to the GPU, to how a scene file gets deserialized off disk, to how a bone weight influences a vertex position.

After this project, I don't just use graphics APIs — I understand them. And that understanding carries over into everything else.