Spite Sunborne


Features I worked on

  • Rendering-integration
  • Worldspace UV
  • Shaders-implementation
  • Sprites
  • Animations
  • Particle system
  • Shadows

Introduction

This project turned out to be one of the most rewarding and fun project that I had a chance to work on. This was because we switched from using a pre-built 2D engine, given to us by our school to using a 3D engine built from scratch by members of our team. This is where I found my true calling as I started to dabble with rendering techniques, shaders and optimizations for rendering in 3D-space.

Showcase of the animations.

My Focus 🎯

This project a lot of my time was spent together with another programmer in my group, working on implementing animations. We used AssImp, a third-party library, to import ’.fbx’ files.

We then converted the animations to our own structures and classes, allowing us to further iterate on the system. We also implemented basic ways to blend between animations and apply an ”additive” animation for when characters take damage etc.

Showcase of shadows.

Shadows 💡

After implementing basic PBR and animations I turned to shadows. Working with another programmer we implemented the first iteration of shadows, cast from our global directional light. 

We never got around to implement soft shadows nor cascading shadow maps. However, using an array of shadow maps and some culling, we were able to tailor the shadows after our game and make them visible and functional in large areas, without impacting performance too much.

Showcase of our game engine UI.

Our Prefab System 🔮

The way we decided to handle the creation of levels came to dictate a lot about our pipelines. We wanted to use Unity to leverage their intuitive and user-friendly UI and tools. We would then export all the placements of the objects to our engine and then check if the object, in unity, is a prefab. If so, we want to treat it as such in our engine too.

Showcase of the Unity UI.

Along with this basic Export functionality we created a prefab-system much like the one they use in Unity where you can save all of the components attached to an entity.

Each component could then define how it would be exported/imported. When we import an object from unity which is marked as a prefab. We look for a prefab of the same name in our engine.

Showcase of the engine modeling system.

Technical Artists 👨‍💻

In this project a new addition to our group was two technical artists and quickly I came to the realization that I would be acting as the middle-man between our TAs and the engine. The first big thing for me was to allow our TAs to create and add shaders to objects without having to involve a programmer. A problem which turned out to be quite difficult.

My solution was to make a class, containing paths to different shaders and a C++ Type to know what information we need to pass to the GPU, as different shaders depend on different external variables, such as time, HP, etc.

Showcase of the ingame UI.
Showcase of shader effects.

Shaders for Sprites and Particles ✨

After adding the shader to the collection and declaring the type to use, the shader would get an ID and be available in the editor. In the editor you can then easily assign a shader to a model. The same method was used to add shaders to both sprites and particles, making the system a bit more intuitive to our TAs.

The big problem with this system was that the shaders could not be created or added to our collection at run-time. Even worse was the fact that our TAs, who lacked programming experience, could not create a shader without interacting with C++ code. This introduced problems regarding both source control, performance and usability as the code written by the TAs was generally (and understandably) held to a worse standard. By the end of the project there was a tremendous amount of unnecessary code and the C++ side of things were even harder to get a grip on.