Arinn Engine

Introduction

Arinn Engine is a custom engine written in C++. It uses the DirectX 11 API for its rendering pipeline and techniques such as Deferred and Forward rendering to render the scenes.

The engine uses a component system that makes it very easy to add new features while maintaining old ones. The components are set and defined in the in our "Level Editor" that was in large part created by me.

My Experience

I really enjoyed creating and working on our custom built engine. Everything that I took for granted in an engine, we had to implement ourselves and truly understand how it worked. I mainly worked on the level editor and the graphics pipeline.

My Contributions to Arinn

Level Editor (main structure & main development)
Deferred & forward rendering
Decals
UI
Sound implementation
Custom shader implementation
Shader node graph external tool
Game main structure
Engine structure

Level Editor

I worked closely with our level designers to design a tool that was comfortable for them to work with. I wrote more about it on the page about designing a CUSTOM EDITOR.

To summarize my experiance I worked iteratively on different versions of the editor keeping my colleagues updated on the changes and tools that I implemented.

G-Buffer

Normal

Material

Albedo

All Together

Deferred + Forward

Deferred & Forward Rendering

I implemented deferred and forward rendering, collaborating closely with Simon Carlsson.

For starters, what is deferred and forward rendering?

Forward rendering is a real-time rendering technique used for rendering 3D scenes. It processes a list of objects, drawing each one individually to a single image while applying lighting calculations per object. This method can be demanding on the CPU, as all lights are evaluated for each object separately.

An alternative to forward rendering is Deferred Rendering. Instead of rendering directly to a final image, it first writes scene data to a G-buffer (Geometry Buffer), which splits the render into multiple image buffers. These buffers store information such as albedo, normals, materials, and more, enabling special effects. By using the images stored in the G-buffer the number of lighting drawcalls are reduced from one per model per light to one draw call per lightsource

But if deferred rendering makes lighting calculations more efficient, why use forward rendering at all? The main drawback of deferred rendering is that it complicates transparency. By combining these two techniques by only using forward rendering on the objects that are transparent, it achieves the best of both worlds. This is done by rendering the forward pass on top of the deferred output while using the same depth buffer to avoid any unwanted overlap.

Decals

I wanted give our artists more options for varitation with less effort, so, with a bit of research and some guidance from my co-student Thea Nilsson, I implemented Decals.

What is a decal? A decal is a sprite that is projected onto the surface of another model. It uses similar rendering techniques as when we render lights in the deferred rendering pipeline.

How do my decals work? A cube model is rendered with front face culling where the decal is supposed to be. The model has a shader that reads world positions from the G-buffer of the pixel where we are trying to project our decal sprite. It checks if the object at the current pixel position is within the space of the decal cube in world space and then converts the positions within the cube to UV coordinates. The coordinates are then used to sample the decal sprite and applied to the all G-buffer textures minus the world position.