Spite: Legacy



I created most of the editor interface and features for our engine consisting of a viewport, hierarchy, inspector, and content browser. The editor had support for both object manipulation and preview as well as exposing values that could be edited and tweaked with ease.

I with the support of Ajlin Hamzic implemented a selection tool where you can select objects through the viewport. We did this using a custom render pass where we render the game object IDs to a render target. We could then sample that render target and retrieve the object that should be selected. 

Cog Editor

Component System

One of the first things I focused on during this game project was the component system. I wanted to create an interface that was efficient as well as easy to use because it's the main foundation that the rest of the engine and game is running upon. I decided to go with an interface much like Unity for the reason being that we created 2 game projects in Unity during the first year at TGA and everyone was already used to that syntax. To make this system efficient enough I knew I had to make it cache-friendly. Allocating memory during runtime is not ideal and was something I wanted to avoid. The plan was to have an array with a set size for each component type. 

Due to the way that polymorphism works in C++, I couldn't create an array of Component* (component pointers) as the component itself would be stored somewhere else on the heap. It also wasn't suitable to manually store an array for each component type that we create as it would quickly clutter up the codebase. I ended up doing a decent amount of research on how others have implemented their component systems and stumbled upon a solution that would work for my case. The plan was to create a template data container that I named ComponentArray.  This class then stores an array of said template type as well as deriving from a base interface IComponentArray. This way I could create a map with the components type ID as a key and an IComponentArray* as a value. 

Unreal Exporter


When starting this project we had to figure out what tools we were going to use for the different pipelines. Our level designers had a wish to use Unreal Engine as their main level editing tool because they used that for all their personal projects. None of the programmers in our group had any experience working in Unreal Engine so I took it upon myself to create a tool for this pipeline.

This problem consists of 2 parts. 

First one was exporting the object data of all objects in the scene. This consists of transformation, other components on the object such as pointlights, spotlights, meshrenderers and relevant data in those. I decided to create an actor component that exports all objects in the scene to a json file using Unreals json tool. Though it was a struggle in the beginning once I got the hang of how you're supposed to work with unreal this part ended up being quite easy. 


The bigger struggle was exporting the navmesh generated by unreal. To succeed with this part I had to dive a bit deeper into unreals structure adding new modules and diving into detour & recast navmesh system. 

Turns out unreal does not have any easy ways of gathering navmesh data. Exporting the vertices of individual navmesh tiles was possible but I found no way of exporting the indicies of the triangles. I had to find another solution to this problem and then found an algorithm called delaunay triangulation. With this algorithm I then generated new triangles from the vertices that I got from unreal. 

Once I had the triangles and vertices the only part left was exporting it. I ended up using the .obj format for the navmesh. 

Engine work

I ended up working a lot on the rendering pipeline. I rewrote all the renderers and created a system that allowed us to combine the two which gave us support for transparent materials and VFXes. 

I also optimized our deferred rendering lighting stage by batching all point lights and spotlights into a single fullscreen pass. This allows me to do less pixel calls. This was possible due to the fact that we didn't use any shadows for either of those light types. While doing this I also took the time to implement HDR rendering which gave clearer color accuracy on bright lights. 

I also implemented sprite rendering and a system allowing us to apply any pixel shader we want to those lights allowing our Techincal artists to create shaders and apply them on their own.