GAME ENGINE

DESCRIPTION

Personal project

FEATURES

Asset importing
Level editor
Physically based rendering
Physics

TIMEFRAME

January 2023 - Present

LANGUAGE

C++

GITHUB

https://github.com/MartinRubenNilsson/Engine

BACKGROUND

Studying at The Game Assembly has presented me with a unique opportunity to learn and practice implementing many of the lower-level features usually taken for granted in commercial game engines, such as the rendering pipeline, physics simulation, and how to organize the game world and its objects. Still there is much to learn, and even though TGA have given me some of the puzzle pieces, I feel that an equally important skill is knowing how to assemble these into a full picture. My goal with this personal project has therefore been to apply everything I've learnt in order to create a stand-alone game engine with built-in editor, usable enough to make a simple 3D game with.

My second goal has been to implement features that I feel I haven't had the time to explore properly during game projects. For example, I wanted to make a deep dive into the mathematical foundations of physically based rendering and implement as much as possible of that pipeline from scratch. Though calling it a game engine is at this point a bit of a stretch as it doesn't have much game logic, going forward my intention is to keep adding features and to keep learning!

Some of the libraries/API:s I've used are: Win32 for the application itself, Dear ImGui for the editor windows, DirectX 11 for graphics, PhysX for physics, JSON for Modern C++ for serialization, EnTT as my entity component system, and I also have plans to integrate the FMOD Studio API as I've done for previous game projects. Some features I'd like to add in the near future are support for collisions, area lights, and outlines for selected entities while editing a scene.

ASSET IMPORTING

MODELS AND MATERIALS

Models can be dragged and dropped straight into the editor, upon which the asset is converted into a hierarchy of entities and components and is instantiated into the level. The engine internally uses the Open Asset Import Library to ensure full support for most common file formats, including .fbx and .obj.

During this process, any materials present in the model are imported as well. Individual textures are first loaded using stb_image and then converted into a ID3D11Texture2D on the GPU, complete with mipmaps and with the appropriate format depending on whether the texture stores material albedo, normals, roughness, etc.

During importing the hierarchy of the model is kept. Also, any cameras and lights present in the model (if the file format supports it) are kept as well.

Assets that are imported from disc are cached, so there is no performance hit after the first time.

LEVEL EDITOR

VIEWPORT

While not in play mode, the scene view camera can be freely moved around using the same controls as in Unity.

Objects in the scene can be selected/picked by clicking on them. This is achieved by rendering their entity ID to a dedicated texture as part of the geometry pass of the deferred rendering pipeline, which reduces the picking process to a simple texture lookup based on the position of the cursor.

After selecting them, objects can be translated, rotated and scaled in either local or world coordinates using familiar gizmos. For this purpose I used the ImGuizmo library.

HIERARCHY

Model assets placed into the viewport keeps their hierarchy of transforms as it originally appeared in the asset, and this hierarchy can then be freely rearranged by dragging and dropping entities onto each other. Naturally, if a parent entity is translated/rotated/scale, then all its children will follow along in the transformation.

Using a context menu and/or keyboard shortcuts, the user can delete and even duplicate whole sub-hierarchies. New entities and some simple preset objects can also easily be created in this way.

I chose to let each transform store the entity IDs of its parent and children (which each owns a transform as a component) rather than store a direct pointer to the transforms. This way, I could use EnTT's snapshot functionality to trivially serialize the hierarchy.

INSPECTOR

The engine internally uses the EnTT entity component system to store and iterate over game objects, and each entity can therefore have any combination of certain basic components, such as transforms, meshes, materials, etc. While editing, these components can be added, removed, and have their properties read and changed from a dedicated editor window.

SAVING/LOADING SCENES

By defining a pair of non-intrusive functions "from_json" and "to_json", I can use JSON for Modern C++ to easily serialize/deserialize any component to/from JSON. Moreover, by using EnTT's built in snapshot feature, it is straightforward to do the same for an entire entt::registry containing the scene and all its entities and components. With this, saving and loading scenes to disc in JSON format is easy to implement and easy to extend once new component types are introduces.

I also use this method to store a copy of the scene when the user enters play mode so that I can restore the editor scene afterwards.

PHYSICALLY BASED RENDERING

DEFERRED RENDERING

The material model uses the metallic-roughness workflow, and the shading uses the Cook-Torrance microfacet BRDF model with GGX geometry for its specular term, and a diffuse term based on the talk "PBR Diffuse Lighting for GGX+Smith Microsurfaces" by Earl Hammon. DX11 is used as the graphics API and shaders are written in HLSL.

The engine uses a deferred rendering pipeline and supports the usual analytic light types, namely directional, point, and spot. Only the normals, depth, and material properties are rendered to the geometry buffer; positions are reconstructed from depth. Furthermore, a reversed Z buffer is used throughout (though this can be toggled on and off using a macro).

For ambient occlusion, the renderer uses not only the corresponding texture of the material, but combines this with a factor calculated using screen space ambient occlusion (SSAO) which I implemented for one of my game projects at The Game Assembly.

IMAGE-BASED LIGHTNING

For the engine's ambient light, which is image-based, I followed the tutorial "Learn OpenGL" by Joey de Vries. My implementation proceeds as follows:

First, I use stb_image to load an HDR equirectangular environment map and create a ID3D11Texture2D from it. I then create a TextureCube and use a geometry shader to render the map onto it, transforming its coordinate system from equirectangular to cubemap in the process. The resulting cubemap can then immediately be used as a skybox.

For diffuse lightning I use shaders to convolve the cubemap into a so-called irradiance map and store it in a separate lower-resolution TextureCube. For specular lightning I use the split-integral approach, meaning that (1) I use shaders that implement importance sampling to convolve the original cubemap with the GGX BRDF specular lobe, with a different roughness level stored in each mip level, and (2) I precompute a so-called BRDF lookup texture. During rendering these two contributions are then combined to give the final specular contribution.

PHYSICS

RIGIDBODIES

One can add a Rigidbody component onto entities in order to make them obey physics, including gravity. This component is mostly a wrapper around a native PxRigidDynamic object with some convenience methods and support for serialization and copy semantics.

Having just recently included rigidbodies has left me with no time to create components that support collisions, but it is top priority on my todo list!

CHARACTER CONTROLLERS

It is also possible to give entities a CharacterController component, which behaves similarly to the Unity component sharing the same name. Here I've hardcoded a simple system to let me steer a character controller using my keyboard (rather than, say, making a dedicated "Player" component).