Reloading shaders while the engine is running vastly increases your iteration speed and simplifies the debugging of old and new graphics features. Granted we’re talking about explicitly named, persistent shaders here and not some material-based, automatically generated solution. As you’re starting out making an engine this is most likely the setup you’ll be using for a while, and while implementing features such as SSAO or tone mapping, it will be incredibly helpful to be able to tweak parameters or formulas on the fly.

File Watching

Havtorn has a simple, request-based file watching system running on a separate thread, which is also used to hot reload assets. We set it up to run on a separate thread at the point of initializing all core engine systems, and sleep it intermittently.

CFileWatcher::~CFileWatcher()
{
    ShouldEndThread = true;
}

bool CFileWatcher::Init(CThreadManager* threadManager)
{
    if (!threadManager)
        return false;

    threadManager->PushJob(std::bind(&CFileWatcher::UpdateChanges, this));
    return true;
}

void CFileWatcher::UpdateChanges()
{
    while (!ShouldEndThread)
    {	
        {
            std::lock_guard<std::mutex> lock(Mutex);
            for (const auto& [path, currentTimestamp] : WatchedFiles)
            {
                const U64 latestTimeStamp = GetFileTimestamp(path);
                if (latestTimeStamp > currentTimestamp)
                {
                    QueuedFileChanges.push(path);
                    WatchedFiles[path] = latestTimeStamp;
                }
            }
        }

        std::this_thread::sleep_for(std::chrono::milliseconds(SleepDurationMilliseconds));
    }
}

The WatchedFiles property is an std::map we write to when requesting to watch a file on the main thread. We also provide an instance of a thin struct bundling our std::function callbacks with an explicit handle that the calling code must provide. This way we can easily find and remove the callback when we want to stop watching for changes to the file.

struct SFileChangeCallback
{
    SFileChangeCallback() = delete;
    explicit SFileChangeCallback(const std::function<void(const std::string&)>& function, const U64& handle)
        : Function(function)
        , Handle(handle)
    {}

    std::function<void(const std::string&)> Function;
    U64 Handle = 0;
}

bool CFileWatcher::WatchFileChange(const std::string& filePath, SFileChangeCallback callback)
{
    const std::filesystem::path newPath = filePath.c_str();

    if (!std::filesystem::exists(newPath))
        return false;

    std::lock_guard<std::mutex> lock(Mutex);
    StoredCallbacks[newPath].push_back(callback);

    if (!WatchedFiles.contains(newPath))
        WatchedFiles.emplace(newPath, GetFileTimestamp(newPath));

    return true;
}

void CFileWatcher::StopWatchFileChange(const std::string& filePath, const U64& callbackHandle)
{	
    const std::filesystem::path existingPath = filePath.c_str();

    if (!std::filesystem::exists(existingPath))
        return;

    if (!StoredCallbacks.contains(existingPath))
        return;

    std::lock_guard<std::mutex> lock(Mutex);
    std::vector<SFileChangeCallback>& callbackContainer = StoredCallbacks.at(existingPath);

    auto it = std::ranges::find(callbackContainer, callbackHandle, &SFileChangeCallback::Handle);
    if (it == callbackContainer.end())
        return;
    
    callbackContainer.erase(it);

    if (!callbackContainer.empty())
        return;

    StoredCallbacks.erase(existingPath);
    WatchedFiles.erase(existingPath);
}

While UpdateChanges runs on the file watch thread, we try to FlushChanges at a known point on the main thread (e.g. at the start or end of a frame), where we go through the queued up changes from the file watch thread and call all the callbacks.

void CFileWatcher::FlushChanges()
{
    std::lock_guard<std::mutex> lock(Mutex);
    while (!QueuedFileChanges.empty())
    {
        const std::filesystem::path filePath = QueuedFileChanges.front();
        QueuedFileChanges.pop();

        if (!StoredCallbacks.contains(filePath))
            continue;

        const std::vector<SFileChangeCallback>& callbacks = StoredCallbacks[filePath];
        for (const SFileChangeCallback& callback : callbacks)
            callback.Function(filePath.string());
    }
}

Shader Hot Reload

At the point of loading shaders, we also find the corresponding source files and start watching them for changes. Naturally, we wouldn’t want or need to do this for release builds. Notably I’m making it easy for myself here. Because we have an explicit, static set of shaders, we can store them in std::arrays and just index into those directly to switch out the shaders when reloading them.

std::string CRenderStateManager::AddShader(const std::string& filePath, const U64 index, const EShaderType shaderType)
{
    ...

    switch (shaderType)
    {
    case EShaderType::Vertex:
    {
        ...
    }
    ...
    case EShaderType::Pixel:
    {
        // Index directly into the std::array

        if (PixelShaders[index] != nullptr)
            PixelShaders[index]->Release();

        CPixelShader* newPixelShader = nullptr;
        UGraphicsUtils::CreatePixelShader(filePath, Framework, &newPixelShader);
        PixelShaders[index] = pixelShader;
    }
    break;
    }

    const std::string sourceFile = UGeneralUtils::DeriveSourceFileFromPath(filePath, "hlsl");
    if (!ShaderInitData.contains(sourceFile))
    {
        GEngine::GetFileWatcher()->WatchFileChange(sourceFile, SFileChangeCallback(std::bind(&CRenderStateManager::OnShaderSourceChange, this, std::placeholders::_1), OnShaderSourceChangeFunctionHandle));
        
        // NW: Save some extra context about the file so we can call this function with the same arguments again later
        ShaderInitData.emplace(sourceFile, SShaderInitData{ filePath, shaderType, index });
    }

    ...
}

When the source file changes, we queue up the file path to be recompiled to a new binary at a good time, similar to what we do in the FileWatcher. In this case, we flush the changes when the main thread and render thread sync and swap resources.

This code is specific to DirectX11, but the same principles apply for other backends. Implementations and compilers used for Vulkan and even DirectX12 will differ, but the information seems fairly easy to find. Havtorn doesn’t yet support the newer generation of backends so I will just show our solution for the DirectX11 case here.

void CRenderStateManager::OnShaderSourceChange(const std::string& filePath)
{
    std::lock_guard<std::mutex> lock(ShaderRecompileMutex);
    QueuedShaderRecompiles.push(filePath);
}

void CRenderStateManager::FlushShaderChanges()
{
    // NW: Use DXC for DirectX12 Shader Model 6.0 and above, or one of the Vulkan shader compilers to compile into SPIR-V for Vulkan, e.g. glslc or glslang
    // https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-part1
    // https://github.com/KhronosGroup/glslang

    std::lock_guard<std::mutex> lock(ShaderRecompileMutex);
    while (!QueuedShaderRecompiles.empty())
    {
        const std::string changedSourceFile = QueuedShaderRecompiles.front();
        QueuedShaderRecompiles.pop();

        const SShaderInitData initData = ShaderInitData.at(changedSourceFile);
        const std::wstring wideSourceFilePath = { changedSourceFile.begin(), changedSourceFile.end() };
        const std::wstring wideOutputFilePath = { initData.OutputFileName.begin(), initData.OutputFileName.end() };

        ID3DBlob* compiledContents = nullptr;
        ID3DBlob* errorMessages = nullptr;

        std::string shaderModel;
        switch (initData.ShaderType)
        {
        case EShaderType::Pixel:
            shaderModel = "ps_5_0";
            break;
        case EShaderType::Geometry:
            shaderModel = "gs_5_0";
            break;
        case EShaderType::Compute:
            shaderModel = "cs_5_0";
            break;
        case EShaderType::Vertex:
            [[fallthrough]];
        default:
            shaderModel = "vs_5_0";
        }

        UShaderIncludeHandler customIncludeHandler;
        const HRESULT compileResult = D3DCompileFromFile(wideSourceFilePath.c_str(), nullptr, &customIncludeHandler, "main", shaderModel.c_str(), 0, 0, &compiledContents, &errorMessages);
        if (compileResult != S_OK)
        {
            HV_LOG_ERROR("CRenderStateManager::OnShaderSourceChange: Shader %s could not be recompiled: %s", changedSourceFile.c_str(), (char*)errorMessages->GetBufferPointer());
            errorMessages->Release();
            break;
        }

        const HRESULT rewriteResult = D3DWriteBlobToFile(compiledContents, wideOutputFilePath.c_str(), TRUE);
        if (rewriteResult != S_OK)
        {
            HV_LOG_ERROR("CRenderStateManager::OnShaderSourceChange: Shader %s was successfully recompiled, but output file could not be overwritten.", changedSourceFile.c_str());
            compiledContents->Release();
            break;
        }

        compiledContents->Release();

        // NW: Re-add shader using the context we saved before
        AddShader(initData.OutputFileName, initData.ShaderIndex, initData.ShaderType);

        HV_LOG_INFO("Shader source file %s was recompiled.", changedSourceFile.c_str());
    }
}

Note the custom include handler used in the compilation call. DirectX (I’m not sure about Vulkan) needs this to know what to do when it comes across an #include directive in the hlsl source code during compilation. You can provide a default one by using the D3D_COMPILE_STANDARD_FILE_INCLUDE macro, which will find files relative to the source file directory, or pass nullptr if you don’t include any files in the source code. In our case, we’re including files from a specific Includes directory in the shader source directory, and some include files include other files also relative to this directory. I ended up with this custom include handler for use under these very specific conditions.

class UShaderIncludeHandler : public ID3DInclude
{
    HRESULT Open(D3D_INCLUDE_TYPE /*includeType*/, LPCSTR pFileName, LPCVOID /*pParentData*/, LPCVOID* ppData, UINT* pBytes) override
    {
        // NW: Only include files in the Shaders/Includes folder in shaders.
        const std::string shaderIncludeSource = UGeneralUtils::ExtractParentDirectoryFromPath(UFileSystem::GetWorkingPath()) + "Source/Engine/Graphics/Shaders/Includes/";
        const std::string inputFileName = UGeneralUtils::ExtractFileNameFromPath(pFileName);
        const std::string filePath = shaderIncludeSource + inputFileName;

        if (!UFileSystem::Exists(filePath))
            return E_FAIL;

        U32 fileSize = STATIC_U32(UFileSystem::GetFileSize(filePath));
        char* data = new char[fileSize];
        
        std::ifstream inputStream;
        inputStream.open(filePath.c_str(), fstream::in | fstream::binary);
        
        inputStream.read(data, fileSize);
        inputStream.close();

        *pBytes = fileSize;
        *ppData = data;
            
        return S_OK;
    }

    HRESULT Close(LPCVOID pData) override
    {
        delete[] pData;
        return S_OK;
    }
};

struct SAssetReference
{
    U32 UID = 0;
    std::string FilePath = "NullAsset";
    
    SAssetReference() = default;
    explicit SAssetReference(const std::string& filePath)
    {
        FilePath = UGeneralUtils::ConvertToPlatformAgnosticPath(filePath);
        U32 prime = 0x1000193;
        UID = 0x811c9dc5;
        
        for (U64 i = 0; i < FilePath.size(); ++i)
        {
            U8 value = FilePath[i];
            UID = UID ^ value;
            UID *= prime;
        }
    }
    
       ...
}

The gif above shows the first iteration of hot reloading assets, where for any asset that was originally authored in an external program such as Blender or Photoshop, the registry can dynamically reimport it as soon as the source file (fbx, dds) changes on disk. As an example, a mesh can be placed in the editor, then the source file watching on the asset be toggled, and whenever the fbx is changed on disk the engine reimports it with the same settings on the fly. We don’t need to update all the components that care about that particular asset, the registry just internally updates the data that it manages.

The only reason that enabling the file watching is a manual step is so that we don’t hog resources by watching for file changes when it’s not needed. Of course a more automatic setup could be more fitting for exploratory phases of a project.

Asset Redirection

As part of this I also implemented rudimentary asset redirection, somewhat similar to what Unreal Engine does, meaning that assets can be moved around in the editor to different directories, and a link is created between the old file path and the new. If an asset is already loaded, the components using it can continue to do so with the same AssetReference. If the asset isn’t loaded, we traverse the redirections to try to find an existing file. If we do, we continue loading as necessary.

bool CAssetRegistry::LoadAsset(const SAssetReference& assetRef)
{
    std::string filePath = assetRef.FilePath;
    if (!UFileSystem::Exists(filePath))
    {
        CJsonDocument config = UFileSystem::OpenJson(UFileSystem::EngineConfig);
        std::string redirection = config.GetValueFromArray("Asset Redirectors", filePath, "");
                        
        while (!UFileSystem::Exists(redirection) && redirection != "")
        {
            redirection = config.GetValueFromArray("Asset Redirectors", redirection, "");
        } 
            
        if (redirection == "")
        {
            HV_LOG_WARN("CAssetRegistry::LoadAsset: Asset file pointed to by %s failed to load, does not exist!", assetRef.FilePath.c_str());
            return false;
        }
            
        filePath = redirection;
    }
    
    // Continue with asset loading
    ...
}

We can abuse the fact that the AssetReferences are just file path strings hashed into identifiers on construction. When an asset has been redirected and we succesfully load it, we can keep the hashed identifier we got from the original file path, instead of updating the identifier to correspond to the redirected path. That means that every following requester (other components wanting to use the same redirected asset) can immediately get a hold of the asset with the identifier they already have stored. We only need to resolve the redirection once per load of the asset.

There’s no automatic clean up of the redirectors yet, but there is a manual step where you can click a button to update all assets on disk, if they have dependencies on other assets. Then you would have to go through all components in all scenes (where ECS entities and components are stored) and update the asset they are pointing to. I think an automatic solution is doable though, you would just have to go through all entities on disk, and iterate through all components to see if there are any old asset references.

In the example we see a physics trigger getting a ScriptComponent referencing the test script asset we authored in the separate script editor. When the block suspended in the air above overlaps with the trigger volume, we change the mesh from a block to the clock mesh, and the green point light in the foreground is toggled off. This was set up to show interactions between a few separate entities, our so called data bindings, and a non-trivial entry point for the script (OnBeginOverlap, instead of a simple Tick for example).

Scripts are thought of as ECS systems, modifiable in editor on an asset level. They are not the same as, e.g., the editor representations of Unreal Engine’s objects. Because they are assets (like a model mesh or animation clip), only one instance can be loaded at a time. They way they then work with persistent data, is by declaring what data they are expecting to work on, and receiving that data from each ECS component (holder of data) that defines it. For lack of a better term, I called this concept a data binding between the script and component.

In the example, the work that the script is meant to perform when triggered, is to shut off a point light on an ECS entity, and change the static mesh of the entity triggering the physics trigger volume. It can shut off any point light, and change the mesh to any mesh. We see in the clip that the script just declares its data bindings, and then we define exactly what point light entity to toggle the light on, and what mesh to set, in the component referencing the script. The data itself is owned by the component, but the script declares what it should be.

// CScriptSystem.cpp
...

for (SScriptComponent* component : scriptComponents)
{
    ...
    
    SScript* script = GEngine::GetAssetRegistry()->RequestAssetData<SScript>(component->AssetReference, component->Owner.GUID);
    
    if (component->DataBindings.size() != script->DataBindings.size())
        component->DataBindings.resize(script->DataBindings.size());
    
    // Input component values before running script
    for (U64 i = 0; i < script->DataBindings.size(); i++)
    {
        SScriptDataBinding& scriptBinding = script->DataBindings[i];
        const SScriptDataBinding& componentBinding = component->DataBindings[i];
        
        scriptBinding.Data = componentBinding.Data;
    }
    
    ...
    
    // Start traversing by some means
    if (beganPlay && script->HasNode(BeginPlayNodeID))
        script->TraverseFromNode(BeginPlayNodeID, scene.get());
    
    if (script->HasNode(TickNodeID))
        script->TraverseFromNode(TickNodeID, scene.get());
    
    if (endedPlay && script->HasNode(EndPlayNodeID))
        script->TraverseFromNode(EndPlayNodeID, scene.get());
    
    // Output script values to store in component after running script
    for (U64 i = 0; i < script->DataBindings.size(); i++)
    {
        const SScriptDataBinding& scriptBinding = script->DataBindings[i];
        SScriptDataBinding& componentBinding = component->DataBindings[i];
        
        componentBinding.Data = scriptBinding.Data;
    }
}

...

This means that any number of entities can reference a script (loaded once in memory) and have it run logic on the entity’s own data. Just like any other ECS system, the script’s job is to manipulate data owned by ECS components. It’s just a system that you can author in the editor.

Authoring Nodes

Havtorn doesn’t have a reflection system (yet?), and authoring nodes is a manual process currently. The overhead isn’t huge, but we’re considering what the best strategic approach would be. Perhaps that would be having many small nodes that affect one property, and try to streamline the creation of those, or focus more on larger nodes that have more control over all the data held in a component for example. I think it will have to be some sort of combination, and should be driven by the needs of the current project we’re working on. Here’s an example of a simple core functionality node.

// CoreNodes.h
struct SBranchNode : public SNode
{
    ENGINE_API SBranchNode(const U64 id, const U32 typeID, SScript* owningScript);
    virtual ENGINE_API I8 OnExecute() override;
};

// CoreNodes.cpp
SBranchNode::SBranchNode(const U64 id, const U32 typeID, SScript* owningScript)
    : SNode::SNode(id, typeID, owningScript, ENodeType::Standard)
{
    AddInput(UGUIDManager::Generate(), EPinType::Flow);
    AddInput(UGUIDManager::Generate(), EPinType::Bool, "Condition");

    AddOutput(UGUIDManager::Generate(), EPinType::Flow, "True");
    AddOutput(UGUIDManager::Generate(), EPinType::Flow, "False");
}

I8 SBranchNode::OnExecute()
{
    bool condition = false;
    GetDataOnPin(EPinDirection::Input, 1, condition);

    // Return pin index to continue traversal from
    return condition ? 0 : 1;
}

We purposefully serialize our skeletal mesh animations down to our own data formats and run the math using those. Other solutions instead make a thin wrapper (or no wrapping at all) around imported assimp scenes, provided they are also working with assimp. I prefer our solution as it gives us more control in implementing more advanced features such as inverse kinematics now that we’ve split up the logic into clear chunks.

Our flow currently looks like this. We have a collection of thin PlayData objects that refer to distinct animation assets. The thought is that whenever we want play an animation, we just push one of these objects into the animation component’s collection. We start by resolving the local bone pose for each of the ones currently playing by recursively traversing the node graph. After that, all the PlayData local poses are blended together. Following a final traversal of the tree where we apply the blended local pose, we iterate through the posed nodes and simply multiply the inverse bind pose to get our final world space bone transform, and send that off to the shader.

// CAnimationGraphSystem.cpp
...

// Read local poses of playing animations
for (SSkeletalAnimationPlayData& playData : component->PlayData)
{
    if (!UMath::IsWithin(playData.AssetReferenceIndex, 0u, STATIC_U32(component->AssetReferences.size())))
      continue;
    
    const U32 index = component->AssetReferences[playData.AssetReferenceIndex];
    const SSkeletalAnimationAsset* animationAsset = assetRegistry->RequestAssetData<SSkeletalAnimationAsset>(index, component->Owner.GUID);
    if (animationAsset == nullptr)
      continue;
  
    ...
  
    playData.LocalPosedNodes = {};
    ReadAnimationLocalPose(animationAsset, meshAsset, animationTime, meshAsset->Nodes[0], playData.LocalPosedNodes);
}
				
std::vector<SSkeletalPosedNode> posedNodes = {};
posedNodes.resize(meshAsset->Nodes.size());
				
// Blend animations
if (component->PlayData.size() > 1)
{
    // TODO.NW: Barycentric interpolation for more than 2 animations
  
    for (U32 i = 0; i < STATIC_U32(posedNodes.size()); i++)
    {
        const SSkeletalPosedNode& posedNodeA = component->PlayData[0].LocalPosedNodes[i];
        const SSkeletalPosedNode& posedNodeB = component->PlayData[1].LocalPosedNodes[i];
    
        posedNodes[i].Name = meshAsset->Nodes[i].Name;
        posedNodes[i].LocalTransform = SMatrix::Interpolate(posedNodeA.LocalTransform, posedNodeB.LocalTransform, component->BlendValue);
    }
}
else if (component->PlayData.size() > 0)
{
    posedNodes = component->PlayData[0].LocalPosedNodes;
}

// Apply local pose and inverse bind transform
SMatrix root = SMatrix::Identity;
root.SetScale(importScale);
ApplyLocalPoseToHierarchy(meshAsset, posedNodes, meshAsset->Nodes[0], root);

component->Bones.resize(meshAsset->BindPoseBones.size(), SMatrix::Identity);
for (U32 i = 0; i < STATIC_U32(posedNodes.size()); i++)
{
    SSkeletalPosedNode& posedNode = posedNodes[i];
	
    ...

    const SSkeletalMeshBone& bone = meshAsset->BindPoseBones[boneIndex];
    component->Bones[boneIndex] = bone.InverseBindPoseTransform * posedNode.GlobalTransform;
}

...

For the first game project we’re aiming to at the very least implement IK using the FABRIK solver, as well as drive audio through events triggered on specific keyframes in the animation, similar to how Unreal Engine does it with their Animation Notifications. I’m thinking that triggering these events is best handled when reading the local pose of running animations, as we interpolate position, rotation and scale between keyframes there anyway.

For the future we’d also like to support blend spaces and explore skeletal deformations, to say nothing about building an animation GUI (preferrably a graph utilizing our visual scripting system) that’s simple to work with.

One nice feature of an ECS architecture is the fact that you can represent an entity and reference all of its data using only an ID. There’s no need to get hold of a pointer to a large actor object, you can simply provide a single data type directly. We utilize this fact by extending the G-Buffer with a separate target to store the ID in, per pixel. 64 bits per ID is enough for us so we make it a 64 bit texture, using the DXGI_FORMAT_R32G32_UINT format of DirectX. When rendering to the G-Buffer, we then just pass along the entity ID of every instance that gets rendered. To solve picking for transparent and invisible objects, I opted to represent them as world space billboard sprites. They are also drawn to the G-Buffer, only after the lighting pass.

My thinking is that we can hopefully find a way to represent any entity in the game world like this, either with solid geometry directly or by using one of these sprites. There are definitely challenges in how to scale and layer them so they stay visible, and there are probably also specific cases where this solution breaks down or fails to accurately represent some type of entity, but I think it’s worth it in the end to reach the goal of clicking what you see in the viewport to select it. I always get incredibly frustrated when I accidentally click a fog cube instead of the thing I’m actually trying to select in the Unreal Editor because I’ve failed to toggle off translucent object selection.

It should be noted that this is only for use in editor time. Extending the G-Buffer is costly and we don’t want to deal with any editor functionality at all in a finished game, if we can help it. Separate render passes are chosen here depending on the play state of the game.

The debug view in the gif above is rendered using a simple formula, taking the average of the red and green channel (making up the complete 64 bit entity ID) for the blue, and then scaling the whole thing by some arbitrary amount to where you can tell most of the entities apart.

// FullscreenEditorData_PS.hlsl
...

Texture2D<uint2> entityDataTexture : register(t0);

PixelOutput main(VertexToPixel input)
{
    PixelOutput returnValue;
    
    const uint2 resource = entityDataTexture.Load(int3(input.UV.xy * Resolution, 0));
    returnValue.Color.rgb = float3(resource.x, resource.y, (resource.x + resource.y) * 0.5f);
    returnValue.Color.rgb /= 1000000000;
    returnValue.Color.a = 1;
    return returnValue;
};

Dragging Entities into the Viewport

A similar approach can also be used to resolve where to put a preview entity you’re dragging in from the asset browser. Again, you can do this by checking collision with the physics system, but I think it’s entirely serviceable to render out the world position to another render target, and sample from that one on the CPU in the same way as with the entity IDs.

A key consideration here is how to deal with the geometry of the entity you’re dragging, otherwise it will jump around or travel towards the camera as the cursor position hovers over it. We solve this by just not rendering the preview entity to the world position render target, at least until you let go of the cursor and it becomes a proper entity in the scene. Where there is no geometry or sprite rendered (such as over the skybox), you can put it at a set distance from the camera along the vector separating the camera and the cursor.

Our exam project turned out fairly popular, with thousands of views on itch.io and more than 2000 downloads! Please enjoy the jank if you feel like trying it.

Specifications

• Genre: Horror FPX
• Duration: 9 Weeks Full-Time, 8h/day
• Engine: IronWrought Engine
• Team: SoftBlob, 16 people

My Contributions

• Graphics (Spot Lights, Camera Improvements)
• UI (UI Improvements)
• Audio (3D Audio and Cone Based Occlusion)
• Voice Over & Sound Design

Details

Spot Lights

While missing shadowmapping for them, I added support for spotlights imported from Unity (which we used as a level editor during the final school projects) into the engine. They really contributed to the ambience of the basement levels.

Camera Improvements

Our reference game this time was Soma, and pulling from its’ ancestor Amnesia, we knew we wanted to get a little bit of sway into the camera movement. We didn’t use very violent shakes in the end but the gentle sway simulating the character breathing is felt ambiently and helps immersing the player.

We were also aiming to play more with the main menu than we had before. As part of that, we framed a few different assets nicely and let them represent different submenus. Below is an in-progress shot of the camera moving between a few such points during development.

UI Improvements

Also as part of invoking the visual effects of Soma and Amnesia, I built some controls for the artists to tweak the vignette overlay which was later animated when killed by the monster in the game.

3D Audio and Cone Based Occlusion

I extended the audio sources with basic spatialization in the final project. For occlusion, I introduced separate angles to the prefab in Unity so we could simulate basic occlusion through walls. The attenuation distances (unattenuated to fully attenuated) and cone angles were then provided to FMOD on initialization.

Specifications

• Genre: 3D FPX
• Duration: 16 Weeks Part-Time, 4h/day
• Engine: IronWrought Engine
• Team: SoftBlob, 16 people

My Contributions

• Graphics (HDR, Volumetric Lighting, Material Pipeline, Deferred Decals, VFX Editor, Vertex Painting)
• UI (Animated sprites, Extended Architecture)
• Audio (Voice Line Event and Category Nodes)
• Voice Over

  Details

  HDR

Starting on project 7 we moved to a deferred rendering pipeline instead of forward rendering. I took the chance to implement HDR lighting at the same time, using the filmic tonmapping equation of Uncharted 2. This vastly enhanced the quality of our emissive lights and improved our control over the lighting over all.

Volumetric Lighting

Please see the post I made about my specialization project at The Game Assembly.

Material Pipeline

For project 7, it was important that we could have several sets of materials for any model. I worked closely together with the graphical artists to develop a system which takes care of all material texture memory, using reference counting as well as applying error textures where applicable. Material names where applied in Maya and subsequently detected during import of the FBX file. The Material Handler used a single material name to load the relevant textures. We made use of a material suffix to detect which models were to be rendered with alpha blending at a later pass. This Material Handler was also used to handle decal textures and materials used for vertex painting.

Deferred Decals

Please see the post I made about deferred decals in the highlights.

VFX Editor

Please see the post I made about the VFX editor in the highlights.

Vertex Painting

I worked with Axel Savage on implementing vertex painting from Unity. On the Unity side we used Polybrush to paint data on the meshes, and the per-vertex data was exported to our engine. The order of indices in the index buffer turned out to not be the same when the data came from Unity, so we resorted to making a hash function for the vertex positions in order to correctly map position to color using the order we loaded from the FBX file.

In the pixel shader, all values associated with the PBR materials were interpolated using the color values as weights.

Animated Sprites

I extended the sprite rendering I developed in project 6 to support spritesheet animations, breathing life into the crosshair especially. Animations were relatively easy to define in the json document already containing the sprite information, and the logic was general enough to make simple function calls like mySprite->PlayAnimation(anAnimationIndex, doRepeat, doReverse); behave as expected. Animations were given support for transitioning to different animations depending on whether they played in reverse or not. They could also be given a rotational speed about the \(z\)-axis, as seen in this gif.

The animation logic consisted of counting up the index of a collection of all relevant UV-coordinates, all laid out in sequence. What defines an animation is basically its offset from the beginning of the collection and its total number of frames.

...
"Animations": [
{
    "Name": "Shoot",
    "FrameWidth": 240.0,
    "FrameHeight": 240.0,
    "VerticalStartingPos": 0.0,
    "FrameOffset": 0,
    "NumberOfFrames": 7,
    "FramesPerSecond": 60,
    "RotationSpeedPerSecond": 720.0,
    "ShouldLoop": false,
    "TransitionIndex": 2,
    "ReverseTransitionIndex": 1
},
...
]

void CSpriteInstance::Update()
{
	if (!myShouldAnimate)
		return;

	if (!myShouldReverseAnimation)
		this->Rotate(myAnimationData[myCurrentAnimationIndex].myRotationSpeedInSeconds * CTimer::Dt());
	else 
		this->Rotate(-myAnimationData[myCurrentAnimationIndex].myRotationSpeedInSeconds * CTimer::Dt());

	if ((myAnimationTimer += CTimer::Dt()) > (1.0f / myAnimationData[myCurrentAnimationIndex].myFramesPerSecond))
	{
		myAnimationTimer -= (1.0f / myAnimationData[myCurrentAnimationIndex].myFramesPerSecond); 

		if (!myShouldReverseAnimation)
		{
			myCurrentAnimationFrame++;
			if (myCurrentAnimationFrame > (myAnimationData[myCurrentAnimationIndex].myNumberOfFrames + myAnimationData[myCurrentAnimationIndex].myFramesOffset - 1))
			{
				myShouldAnimate = myShouldLoopAnimation;
				if (!myShouldAnimate)
				{
					PlayAnimationUsingInternalData(myAnimationData[myCurrentAnimationIndex].myTransitionToIndex);
					return;
				}

				myCurrentAnimationFrame = myAnimationData[myCurrentAnimationIndex].myFramesOffset;
			}
		}
		else 
		{
			// ...
		}

		this->SetUVRect(myAnimationFrames[myCurrentAnimationFrame]);
	}
}

Extended UI Architecture

The UI architecture was extended to use “widgets” in the main menu. Rather than a state change on a button press, a child canvas of the main canvas is activated, each potentially holding its own buttons and sprites. We added a canvas wide offset to such children to properly set the render order of image elements. We limited ourselves to let the button logic only really apply to the base canvas though, so button presses in the widgets were only really relevant to the base canvas. Since we only used this system in the main menu we were not negatively affected by this limitation, but to really make use of widgets we would have to improve it.

Voice Line Event and SFX Category Nodes

Some of the other team members, especially Haqvin Bager built a node editor using ImGui for this project. I contributed to this editor by making nodes that would play sounds, for playing voice lines on event triggers in the levels as well as playing randomized SFX and reactionary voice lines based on certain categories. Categories included RobotDeath, PlayerStepAirVent and ResearcherPickUpExplosivesReaction among others. The audio manager would load lists of clips based on each category on start up, and randomize (cycling through the whole list before replaying) what clip to play when receiving a message from the node editor.

Introduction

Concurrently with our seventh game project at The Game Assembly, we had the opportunity to specialize; to plan an independent foray into a subject which we wanted to explore further.

For my specialization I chose to try to implement volumetric lighting in our custom game engine. My main goal was to implement a volumetric directional light, and to optimize it best I could. Would there be time left, my secondary goal was to extend this implementation to point lights, spot lights and what I called “box” lights. We had five weeks half-time to do this, as well as setting up our personal portfolio. I planned for letting my secondary goal slide, and to focus on my main goal.

I based my implementation on a talk at Digital Dragons by Benjamin Glatzel for Deck 13’s Lords of The Fallen.

After loading the Crytek Sponza scene using our model loading pipeline, I set out to create a first working version of a volumetric directional light. Shadowmapping was ready for the directional light so I started with ray marching in the fragment shader of a separate light pass.

Implementation

The current fragment’s world position is extracted from the depth map. Then the world space camera position and fragment position are transformed into light view space and the ray marching direction is calculated from these. An upper limit on the ray marched distance is set using this difference prior to normalization, and the size of each ray marching step is determined using a tweakable number of samples.

PixelOutput main(VertexToPixel input)
{
    PixelOutput output;
    
    float raymarchDistanceLimit = 999.0f;

    float3 worldPosition = PixelShader_WorldPosition(input.myUV).rgb;
    float3 camPosition = cameraPosition.xyz;
    
    worldPosition -= directionalLightPosition.xyz;
    float3 positionLightVS = mul(toDirectionalLightView, worldPosition);
   
    camPosition -= directionalLightPosition.xyz;
    float3 cameraPositionLightVS = mul(toDirectionalLightView, camPosition);

    float4 invViewDirLightVS = float4(normalize(cameraPositionLightVS.xyz - positionLightVS.xyz), 0.0f);
    float raymarchDistance = clamp(length(cameraPositionLightVS.xyz - positionLightVS.xyz), 0.0f, raymarchDistanceLimit);

    float stepSize = raymarchDistance * numberOfSamplesReciprocal;

    float3 rayPositionLightVS = positionLightVS.xyz;
    
    // The total light contribution accumulated along the ray
    float3 VLI = 0.0f;

    [loop]
    for (float l = raymarchDistance; l > stepSize; l -= stepSize)
    {
        ExecuteRaymarching(rayPositionLightVS, invViewDirLightVS.xyz, stepSize, l, VLI);
    }
    
    output.myColor.rgb = directionalLightColor.rgb * VLI;
    output.myColor.a = 1.0f;
    return output;
}

In the ExecuteRaymarching function, the ray position is incremented towards the camera position and the accumulated light contribution is calculated using the in-scattering term of the Radiative Transfer Equation, ignoring multiple scattering. In the directional light case, there is no world space attenuation calculated here, but the source power of the light and the scattering probability can be tweaked outside of the shader.

void ExecuteRaymarching(inout float3 rayPositionLightVS, float3 invViewDirLightVS, float stepSize, float l, inout float3 VLI)
{
    rayPositionLightVS.xyz += stepSize * invViewDirLightVS.xyz;

    float3 visibilityTerm = ShadowFactor(rayPositionLightVS.xyz).xxx;
    
    // Distance to the current position on the ray in light view space
    float d = length(rayPositionLightVS.xyz);
    float dRcp = rcp(d); // reciprocal
    
    float3 intensity = scatteringProbability 
        * (visibilityTerm * (lightPower * 0.25 * PI_RCP) * dRcp * dRcp) 
        * exp(-d * scatteringProbability) 
        * exp(-l * scatteringProbability) 
        * stepSize;
    
    VLI += intensity;
}

Without any optimizations, this render pass is prohibitively expensive, requiring between 64 and 128 samples per fragment on a full resolution target to look serviceable.

Optimization

The two primary optimizations I implemented were rendering volumetrics to a half-resolution accumulation buffer, and interleaved sampling (see Glatzel slide 42). Rendering to a half-resolution target meant having to blur the accumulation buffer in order to hide the fact. Together with interleaved sampling, the number of samples required per fragment was minimized to the point that performance increased in the end, however.

Before executing the ray marching, an offset to the starting position is calculated based on an 8 by 8 grid and the number of samples is reduced, taking advantage of the fact that the intensity differs by small amounts between neighboring fragments. This reduces the number of necessary samples to as low as 16 samples.

PixelOutput main(VertexToPixel input)
{
    [...]

    float stepSize = raymarchDistance * numberOfSamplesReciprocal;
    
    // Input position offset by 0.5f from center of fragment
    float2 interleavedPosition = fmod(input.myPosition.xy - 0.5f, INTERLEAVED_GRID_SIZE);

    float index = (floor(interleavedPosition.y) * INTERLEAVED_GRID_SIZE + floor(interleavedPosition.x));

    // lightVolumetricRandomRayIndices contains the values 0..63 in a randomized order
    float rayStartOffset = lightVolumetricRandomRayIndices[index] * (stepSize * INTERLEAVED_GRID_SIZE_SQR_RCP); 
    
    float3 rayPositionLightVS = rayStartOffset * invViewDirLightVS.xyz + positionLightVS.xyz;

    float3 VLI = 0.0f;
    
    [loop]
    for (float l = raymarchDistance; l > 2.0f * stepSize; l -= stepSize)
    {
        ExecuteRaymarching(rayPositionLightVS, invViewDirLightVS.xyz, stepSize, l, VLI);
    }
    
    [...]
}

After rendering to the accumulation buffer a bilateral Gaussian blur is applied, separated in horizontal and vertical passes. The advantage of a bilateral blur is that it is edge preserving, contrary to a regular Gaussian blur.

The bilateral passes will smear the inside of the light volumes while preserving the edges.

// Horizontal
PixelOutput main(VertexToPixel input)
{
    PixelOutput returnValue;
	
    float texelSize = 1.0f / (myResolution.x / 8.0f);
    float3 blurColor = float3(0.0f, 0.0f, 0.0f);
    float normalizationFactor = 0.0f;
    float bZ = 1.0 / normpdf(0.0, SIGMA);
    float colorFactor = 0.0f;
    float3 originalPixelValue = fullscreenTexture1.Sample(defaultSampler, input.myUV.xy).rgb;
    
    unsigned int kernelSize = 5;
    float start = (((float) (kernelSize) - 1.0f) / 2.0f) * -1.0f;
    
    for (unsigned int i = 0; i < kernelSize; i++)
    {
        float2 uv = input.myUV.xy + float2(texelSize * (start + (float) i), 0.0f);
        float3 resource = fullscreenTexture1.Sample(defaultSampler, uv).rgb;
        colorFactor = normpdf3(resource - originalPixelValue, SIGMA) * bZ * gaussianKernel5[i];
        normalizationFactor += colorFactor;
        blurColor += resource * colorFactor;
    }
	
    returnValue.myColor.rgb = blurColor / normalizationFactor;
    returnValue.myColor.a = 1.0f;
    return returnValue; 
};

If the colorFactor variable is not weighted by an appropriate measure (such as depth) the result may look noisy or pixelated around the edges of the volume, especially for hard-to-define fading edges where attenuation takes place. This is not done above, as I could not produce satisfying results.

Honorable Mentions

Having a fairly quick initial setup, I tried accomplishing my secondary goal prior to optimizing. Point lights were implemented but had utilized no shadowmapping, so I started with ray marching from the point lights and created two other light types from scratch hoping I would have the time to realize shadow mapping for all of them.

The other two light types were spot lights and what I called “box” lights. Box because they differ from the usual rectangle or area lights in that they have no angular falloff at the edges, essentially working as localized directional lights.

All the lights were provided geometry; a cube for point lights, a pyramid shape for spots and a cuboid for the box lights. They all functioned as light sources, but while I solved the actual volumetrics for box and point lights, I ran out of time before I could accurately provide shadow mapping for either of them. This meant the visibility function could not be evaluated, rendering them virtually unusable for volumetric lighting.

I did explore different phase functions however, using the Henyey-Greenstein phase function as the default on the box light, with a tweakable g-value (g = 0, isotropic scattering above).

Note the noisy edges of the directional light in the right picture above, as well as at the ends of the box light itself.

Reflections

All in all I am satisfied in reaching my primary goal, which was to implement a volumetric directional light and to try and optimize it best I could.

I would not underestimate the time needed to create the other light types from scratch again though. I found myself working on the basic lighting of the box light and spot light more than I expected, and if given the choice again I would have focused on optimizing for the directional light prior to working with new light types.

I ventured to try out all the steps of the optimization outlined by Glatzel, including “nearest depth up-sampling” (see slide 38), to further make up for the fact that we are rendering to a half-resolution target. I could not make this work to satisfaction, but it would be greatly beneficial in making the volumetric directional light look good I believe.

Introduction

For our seventh game project at The Game Assembly, I made a VFX editor using ImGui based on the VFX and particle systems I designed for the project prior. With ImGui it was easy and fast to get a graphical user interface running and rendering in our custom engine, and features like the color picker and curve editing were essential in the workflow designed for the graphical artists.

This editor was made to provide the artists working with VFX a proper pipeline for doing so, as tweaking values in JSON files that they had been doing up to this point was inconvenient at best. The systems were still initialized from JSON but did not have to be tweaked inside the files themselves.

Implementation

The VFX Editor works on a component called VFXSystemComponent. This component holds a list of data structures called VFXEffects. Each effect holds data associated with any number of what we call VFX meshes and particle emitters, where a VFX mesh is simply some geometry using shaders to scroll textures across it. These meshes and particle emitters are rendered using alpha blending and with depth writing turned off in a late render pass. The system is defined this way to allow a single game object with this component to store several collections of meshes and particle emitters in different configurations, and to activate any one of these collections as an “effect” at any time.

The window class itself holds the data necessary to tweak values in ImGui as well as the data necessary to write to JSON. All data structures have their own, unique Serialize() methods in order to conserve the specific format used before, rather than generalizing and having to rewrite the JSON import for the VFXSystemComponent.

The basic logic is very simple. An enum controls which information is shown in the window, and the enum is set by buttons within the window.

void IronWroughtImGui::CVFXEditorWindow::OnInspectorGUI()
{
	ImGui::Begin(Name(), Open());

	switch (myCurrentMenu)
	{
	case IronWroughtImGui::EVFXEditorMenu::MainMenu:
		ShowMainMenu();
		break;
	case IronWroughtImGui::EVFXEditorMenu::VFXMeshView:
		ShowVFXMeshWindow();
		break;
	case IronWroughtImGui::EVFXEditorMenu::ParticleEmitterView:
		ShowParticleEffectWindow();
		break;
	default:
		break;
	}

	ImGui::End();
}

On pressing save, all data structures currently held by the window are serialized, written to a filepath set by the user, and the singular VFXSystemComponent is reinitialized using the new or modified JSON file.

In the main window, VFX systems can be loaded and modified on the highest level. Effects can be added, and for every effect you can add any amount of VFX meshes and particle emitters. These can be offset and rotated about the associated game object, and each have their own delay and duration. Any mesh or particle emitter file can be modified by a button press, where the view changes to show the file name and all attributes associated with the selected mesh or emitter. Saving works the same way in this view, but the file name of the selected mesh or emitter can also be changed here.

For the particle emitter file view, there are tweakable curves for color, size and direction of the particles. These curves are opened in a separate window. For every attribute that can be changed by a curve, there is an A and a B value, such as starting color and final color. The curves are defined in the interpolation parameter (y-axis) over time (x-axis) coordinate system, meaning if the y-value at x = 0 is 0, the particle starts its lifetime at attribute value A, and if y = 1, the particle starts its lifetime at attribute value B.

In the current version of the editor, the curves are not actually curved, but straight lines going through several points. We had trouble determining how to interpret smooth line segments on the engine side when we first started setup, and so resorted to interpolating between easily definable points instead due to the time constraint.

const float SVFXEffect::CalculateInterpolator(const std::vector<Vector2>& somePoints, const float t) const
{
	unsigned int pointIndex = static_cast<unsigned int>(somePoints.size() - 1);
	
	for (unsigned int j = 1; j < somePoints.size() - 1; ++j)
	{
		if (t < somePoints[j].x && t > somePoints[j - 1].x)
		{
			pointIndex = j;
			break;
		}
	}
	
	// Nice function inspired by Freya Holmer, inverse lerps from one range and lerps into another
	float val = Remap(somePoints[pointIndex - 1].x, somePoints[pointIndex].x, 0.0f, 1.0f, t);
	return Lerp(somePoints[pointIndex - 1].y, somePoints[pointIndex].y, val);
}

void SVFXEffect::UpdateParticles(unsigned int anIndex, CParticleEmitter::SParticleData& particleData)
{
	// ...

	for (UINT i = 0; i < myParticleVertices[anIndex].size(); ++i)
	{
		float quotient = myParticleVertices[anIndex][i].myLifeTime / particleData.myParticleLifetime;		
	
		if (!particleData.myColorCurve.empty())
		{
			myParticleVertices[anIndex][i].myColor = Vector4::Lerp
			(
				particleData.myParticleStartColor,
				particleData.myParticleEndColor,
				CalculateInterpolator(particleData.myColorCurve, quotient)
			);
		}

		// ... Continue updating particles
	}
}

When a curve is saved, the system is reinitialized.

Improvements

Considering the editor was made under time constraints, there are a lot of improvements that could be made, some of which are listed below.

• Velocity and opacity curves for particle emitter
• Scroll speed, opacity and size curves for vfx meshes
• Full PBR support for textures scrolled over vfx mesh, and particle textures
• Randomizable rotation for particle textures and meshes
• Easier removal and adding of systems, effects, vfx meshes and particle emitters

Hopefully there will be time to realize these during our final exam project.

I implemented deferred decals for our seventh game project at The Game Assembly. The decals were exported from Unity and rendered to the G-Buffer in three separate passes depending on which textures to use; albedo, normal or “material” (containing metalness, roughness, emissive and detail normal strength).

Using three separate passes, there is no need to copy the G-Buffer and you have higher flexibility regarding which textures to use and how to alpha blend the results. I chose to use a cube volume for projection due to its simplicity, held by the renderer and scaled by the game object transform component.

Implementation

A decal factory receives data from the Unity export, including the filepath to a directory of textures to be used by the decal, and three flags representing which render passes to run for this specific decal. The albedo, material and normal (also containing ambient occlusion information) textures are requested from a material handler utility, being set to nullptr should they not exist rather than receiving a pointer to an error texture. Should any of the textures be nullptr, their respective flags are set to false.

The decal render pass is run right after rendering the G-Buffer. If the three decal render passes were not separated, we would set the whole G-Buffer as our render target. If we then want to render different sets of textures for every decal, we would need to copy the whole G-Buffer and sample it in the shader so as to not overwrite the normals when we aren’t interested in the normals of the decal, for example. The normal texture is still bound as a render target, and if we do not discard the run of the entire fragment shader (which we might not want) we are going to overwrite the G-Buffer normals.

In the below GIFs there is no copying of the G-Buffer. Decal albedo data is being written in both cases, but there is no decal data being written to the material target (left) or normals target (right). These are still bound as render targets though, meaning they are overwritten by default values since there is no useful data to write.

That said, if every decal we render renders information to the same targets, this is not an issue, and it becomes cheaper to make only one draw call.

Since we wanted the freedom to render decals to any subset of the G-Buffer, I decided to render decals in different passes to avoid copying the G-Buffer. With this setup, different render targets can be set for every shader and you are guaranteed to not overwrite.

void CDecalRenderer::Render(...)
{
    // ... Bind state common to all decals
    
    for (auto& gameObject : someDecalGameObjects)
	{
		CDecalComponent* decalComponent = gameObject->GetComponent<CDecalComponent>();

		CDecal* decal = decalComponent->GetMyDecal();
		const CDecal::SDecalData& decalData = decal->GetDecalData();

		myObjectBufferData.myToWorld = gameObject->myTransform->GetWorldMatrix();
		myObjectBufferData.myToObjectSpace = gameObject->myTransform->GetWorldMatrix().Invert();
		BindBuffer(myObjectBuffer, myObjectBufferData, "Object Buffer");

		myContext->VSSetConstantBuffers(1, 1, &myObjectBuffer);
		myContext->PSSetConstantBuffers(1, 1, &myObjectBuffer);
		myContext->PSSetShaderResources(5, 3, &decalData.myMaterial[0]);

                if (decalData.myShouldRenderAlbedo)
                {
                    myContext->PSSetShader(myAlbedoPixelShader, nullptr, 0);
                    myContext->DrawIndexed(myNumberOfIndices, 0, 0);
                    CRenderManager::myNumberOfDrawCallsThisFrame++;
                }
        
                if (decalData.myShouldRenderMaterial)
                {
                    myContext->PSSetShader(myMaterialPixelShader, nullptr, 0);
                    myContext->DrawIndexed(myNumberOfIndices, 0, 0);
                    CRenderManager::myNumberOfDrawCallsThisFrame++;
                }

                if (decalData.myShouldRenderNormals)
                {
                    myContext->PSSetShader(myNormalPixelShader, nullptr, 0);
                    myContext->DrawIndexed(myNumberOfIndices, 0, 0);
                    CRenderManager::myNumberOfDrawCallsThisFrame++;
                }
	}
}

Then comes the issue of alpha blending. Setting up alpha blending between one source and one destination is simple, but as our material target of the G-Buffer (which is not identical to the material texture of the decal) contains metalness, roughness, emissive and ambient occlusion, one has to be sacrificed as the alpha blending channel.

In the current implementation, I chose to sacrifice ambient occlusion on the decals and to sample the alpha level from the albedo texture. This means that even though we don’t render the decal to the albedo target, an albedo shader resource must still be bound. For the normals, the fourth component is unoccupied (since we moved the ambient occlusion from the normal texture to the material target), and also samples from the albedo shader resource. The graphical artists could work the transparency into the material and normal textures for decals, but I found this solution better suited for our needs.

// Decal_MaterialPixelShader.hlsl
#include "DecalShaderStructs.hlsli"

float4 main(VertexToPixel input) : SV_TARGET3
{
    float3 clipSpace = input.myClipSpacePosition;
    clipSpace.y *= -1.0f;
    float2 screenSpaceUV = (clipSpace.xy / clipSpace.z) * 0.5f + 0.5f;
    
    float z = depthTexture.Sample(defaultSampler, screenSpaceUV).r;
    float x = screenSpaceUV.x * 2.0f - 1;
    float y = (1 - screenSpaceUV.y) * 2.0f - 1;
    float4 projectedPos = float4(x, y, z, 1.0f);
    float4 viewSpacePos = mul(toCameraFromProjection, projectedPos);
    viewSpacePos /= viewSpacePos.w;
    float4 worldPosFromDepth = mul(toWorldFromCamera, viewSpacePos);
    
    float4 objectPosition = mul(toObjectSpace, worldPosFromDepth);
    clip(0.5f - abs(objectPosition.xyz));
    float2 decalUV = objectPosition.xy + 0.5f;
    decalUV.y *= -1.0f;

    float3 material = materialTexture.Sample(defaultSampler, decalUV).rgb;
    float alpha = albedoTexture.Sample(defaultSampler, decalUV).a;
	
    return float4(material.rgb, alpha);
}

The three screen shots below depict a decal being rendered to different parts of the G-Buffer. Left is only albedo, using the material and normal information already stored in the G-Buffer, middle is only material, and right is only normals.