The Volumetric Fog system was implemented following the main architecture presented by Bart Wronski in “Volumetric Fog: Unified Compute Shader Based Solution to Atmospheric Scattering” at SIGGRAPH 2014. The core idea is to represent the participating medium inside a camera-aligned 3D volume, evaluate density and lighting per volumetric cell, integrate scattering along the view direction, and finally composite the accumulated result with the rendered scene. Wronski describes t

After implementing Depth Buffer Fitting, the directional shadow system was able to concentrate the shadow map around the geometry actually visible by the camera. However, perspective aliasing was still noticeable because a single shadow map distributed the same amount of resolution across the entire visible depth range. Objects close to the camera therefore received the same shadow-map density as distant geometry, even though near shadows require significantly more detail. Ca

The Shadow Mapping system previously used the bounding boxes of visible meshes to calculate the light’s orthographic frustum. Although this approach worked, it could produce an unnecessarily large approximation, especially when dealing with large geometry such as terrain or open environments. As a result, a significant portion of the shadow map was wasted on empty areas, reducing the effective resolution of the visible shadows. 1. Depth reduction resources. New GPU textures w

After implementing directional shadow mapping and improving shadow controls in the editor, the nextstep was to add another important lighting feature to the engine: Screen Space Ambient Occlusion. The goal of this update was to improve contact shadows and depth perception in the scene by darkening small creases, intersections and areas where geometry is close together. Unlike shadow mapping, SSAO is not generated from a light source. Instead, it works in screen spaceusing the

After implementing the first version of directional shadow mapping in our custom DX12 engine, the next step was to improve how shadows are controlled and filtered. The first implementation gave us working hard shadows for directional lights, including support forstatic and skinned mesh shadow casters. However, the system was still very rigid: shadow settings werehardcoded in the renderer, and every directional light was treated in the same way. For this second iteration, I fo

One of the rendering milestones we tackled in the engine was implementing the first version of real-time shadows using shadow mapping. At this stage, the goal was not to build an advanced shadow system with cascades, soft shadows, or complex filtering. The objective was much more focused: get the engine to render a shadow map from a directional light, use it during the lighting pass, and produce hard shadows in the scene. In other words: build the foundation first. What we wa

After implementing the animation state machine and per-state behaviour scripts, the next step is defining a clear workflow for building enemies on top of this system. This post explains the intended pattern for implementing enemy behaviour so that all gameplay code follows the same structure. Overview Enemy behaviour is built using three main pieces: StateMachineScript (per state) EnemyController (shared logic) Animation State Machine (transitions & flow) Each one has a clear

After exposing the animation system to gameplay through AnimationAPI, the next step in my engine was introducing a way to attach behaviour directly to animation states. At that point, gameplay scripts could already trigger transitions, query the active state and control playback. However, all behaviour still had to be written in external scripts, usually centralized in a single controller. That quickly became hard to scale, especially when dealing with multiple states and tra

After building the visual state machine editor, the next step in my engine was exposing that runtime animation system to gameplay scripts. At that point, the engine could already load animation state machines, evaluate transitions, react to triggers, and blend correctly at runtime. That made the system usable from the animation side, but gameplay code still had no clean way to interact with it. Scripts needed a proper runtime API layer so they could trigger transitions, query

After getting the animation state machine working at runtime, the next step in my engine was improving the editor workflow around it. At that point, the engine could already load an animation state machine resource, start from a default state, react to triggers, and blend transitions at runtime. That was enough to validate the system technically, but editing the resource through inspector fields alone was still too limited and not very comfortable once the number of states an

After building animation playback and skinning, the next step in my engine was moving from “playing a single clip” to actually controlling animation flow through a state machine. In the previous stages, the engine could already import animation clips from glTF, reproduce them at runtime, and deform the character correctly through skinning. That was enough for isolated playback, but not for real gameplay logic. Characters do not just play one animation forever: they need to sw

After completing basic runtime playback for glTF animations, the next milestone in my engine was skinning. In the previous phase, I could already import animation clips, play them back at runtime, and apply them correctly to the node hierarchy. The skeleton moved as expected, but the mesh itself still stayed frozen in its bind pose. This task was about solving that missing step: deforming the mesh according to the animated skeleton. What I wanted to achieve The goal was to ma

One of the first animation milestones I tackled in my engine was building a basic runtime playback system for glTF models. At this stage, the goal was not skinning yet. The idea was to get the engine to the point where it could import animation clips, play them back in real time, and apply them correctly to a model hierarchy. In other words: make the joints move properly before worrying about deforming the mesh itself. What I wanted to achieve The task was focused on setting

One of the biggest AI movement milestones I tackled in my engine was integrating Recast & Detour and building a full workflow around offline-baked navigation meshes, debug visualization, path queries, and NavMesh-constrained movement. At this stage, the goal was not crowd simulation, dynamic obstacles, or fancy steering. The point was to get the engine to the stage where it could: build a NavMesh from scene geometry, save it as an engine resource, load it per scene, query pat

Welcome to my first post about STAGE VK. STAGE stands for Simple Tridimensional Animation Game Engine , and VK refers to Vulkan. Why? The motivation that led me to start this personal project comes from the master’s degree I am currently studying at UPC in Barcelona, Advanced Programming for AAA Games . At the same time, a group video game project called Bound by Death is also being developed, for which another Game Engine is being built using the DirectX 12 API. It is a fa

A new project is underway, as the year 2024 brings with it fresh goals and challenges. While racing games haven't typically been my primary focus in gaming, from a game developer's perspective, they present an exciting opportunity to delve into unexplored features and deepen my skill set. For quite some time, I've harbored a desire to integrate driving mechanics into my games. However, amidst prioritizing other aspects, this implementation was consistently postponed. Now, I'v

Arma X is an exciting project that is constantly evolving, and today I am thrilled to share some of the latest updates. This time around,...

This week's post deals with a basic and necessary element in every video game: The Main Menu. The main menu is a fundamental part of any...

In this week's post we present one of the key pieces in the narrative construction of the game: the introduction video, also known as a...