Simple game engine #119

gpx1000 · 2025-07-31T18:04:00Z

This is the next big tutorial effort. I added the conclusion to the base line tutorial, and this is the "next thing." The game engine presented here is one example of what the tutorial describes and not a 1-1 mapping of the source code to the implementation in the attachments folder.
Future work will add new features to the tutorial in the Vulkan Samples project. This is meant to give the course to describe basics of the game engine and Samples is meant to describe features as they are implemented. This can be used as a template for a starting off point for any project as it is designed to be self contained.

Core features in this tutorial/engine:

HRTF (positional) audio in compute pipeline.
Physics basic in compute pipeline.
PBR gltf loading.
KTX2 with BasisU compression.
ImGUI

Several features are left out intentionally as a method of what we'll implement and feature in the Samples including parallel loading of the assets. Bistro takes a few moments to load as it stands here.

…y commit to start getting proofreading while I still iterate on getting the engine to work. Engine still needs assets. Engine still needs Android project created. Engine currently crashes on running. Add `SimpleEngine` with Entity-Component-System (ECS) implementation - Introduced the `SimpleEngine` project featuring a modular ECS-based architecture. - Implemented core files: `Entity`, `Component`, and `TransformComponent` for managing entities and transformations. - Added CMake setup with Vulkan, GLFW, GLM, TinyGLTF, and KTX dependencies for rendering support. - Integrated shader compilation workflow using `slangc`. - Included initial scene setup with basic camera and cube entities in `main.cpp`.

…mmendations - Consolidated sections to address vendor-agnostic optimizations for mobile GPUs. - Replaced Huawei-specific details with broader guidance applicable to various mobile GPU architectures (Mali, Adreno, PowerVR, etc.). - Improved Vulkan extension examples and added checks for multiple vendor IDs for better compatibility. - Updated best practices and performance tuning sections to emphasize device diversity and testing requirements.

…n details - Simplified and reorganized GPU optimization lists for readability. - Expanded explanations for `VK_KHR_dynamic_rendering_local_read` and `VK_EXT_shader_tile_image` to highlight memory bandwidth reduction benefits. - Improved consistency in vendor-specific and tile-based optimization recommendations. - Added detailed examples and practical use cases for extension advantages in mobile rendering pipelines.

- Expanded tutorial with a comprehensive explanation of rendergraphs, including resource management, dependency tracking, and synchronization benefits. - Added a sample `Rendergraph` class implementation with methods for resource and pass management, including compile and execute functions. - Included practical examples such as deferred renderer setup and Vulkan synchronization best practices using semaphores, fences, and pipeline barriers. - Enhanced Vulkan tutorial content with a focus on simplifying complex rendering workflows and optimizing synchronization.

- Inserted new diagrams for layered architecture, component-based architecture, data-oriented design, and service locator pattern in the engine tutorial. - Adjusted and reordered content in corresponding sections for improved clarity and structure. - Updated references to foundational concepts, ensuring consistency across sections.

- Included a detailed clarification about windowing libraries and their purpose. - Provided examples of popular windowing libraries like GLFW, SDL, Qt, and SFML. - Enhanced understanding of platform-specific abstraction benefits for developers.

…i needs some help. it also looks like cleanup logic and resizing needs work.

…the semaphore. resizing still doesn't work. Next step is to get the parts of the engine to demonstrate things.

…U processing mode.

…nk that's due to material only looking at the vespa. This includes camera controls.

asuessenbach

Some more comments...

asuessenbach · 2025-08-25T14:32:37Z

attachments/simple_engine/platform.cpp

+
+                    // Call the resize callback if set
+                    if (platform->resizeCallback) {
+                        platform->resizeCallback(platform->width, platform->height);


The code for APP_CMD_INIT_WINDOW and APP_CMD_WINDOW_RESIZED are identical?

asuessenbach · 2025-08-25T14:39:32Z

attachments/simple_engine/platform.cpp

+
+bool AndroidPlatform::HasWindowResized() {
+    bool resized = windowResized;
+    windowResized = false;


Is it correct that a query (HasWindowResized) is not const and potentially modifies the queried state?

asuessenbach · 2025-08-25T14:41:45Z

attachments/simple_engine/platform.cpp

+
+void AndroidPlatform::SetWindowTitle(const std::string& title) {
+    // No-op on Android - mobile apps don't have window titles
+    (void)title; // Suppress unused parameter warning


Use [[maybe_unused]] instead?

asuessenbach · 2025-08-25T14:46:40Z

attachments/simple_engine/platform.cpp

+        env->DeleteLocalRef(serviceStr);
+
+        // Check Vulkan support
+        // In a real implementation, this would check for Vulkan support and available extensions


And in this implementation, you don't do that because of?

asuessenbach · 2025-08-25T15:58:22Z

attachments/simple_engine/renderer.h

+     * @brief Get the Vulkan RAII device.
+     * @return The Vulkan RAII device.
+     */
+    const vk::raii::Device& GetRaiiDevice() const { return device; }


Is it worth to have both, GetDevice() and GetRAIIDevice()?
Wouldn't getting the vk::raii::Device const & be sufficient, as you get to the corresponding vk::Device that easy?

asuessenbach · 2025-08-25T16:03:04Z

attachments/simple_engine/renderer.h

+     * @param commandBuffer The command buffer to submit.
+     * @param fence The fence to signal when the operation completes.
+     */
+    void SubmitToComputeQueue(vk::CommandBuffer commandBuffer, vk::Fence fence) const {


To keep the API consistent, you could pass in a vk::raii::CommandBuffer const & and a vk::raii::Fence const & here.

asuessenbach · 2025-08-25T16:06:08Z

attachments/simple_engine/renderer.h

+     * @param oldLayout The old layout.
+     * @param newLayout The new layout.
+     */
+    void TransitionImageLayout(vk::Image image, vk::Format format, vk::ImageLayout oldLayout, vk::ImageLayout newLayout) {


Pass in a vk::raii::Image const & here?

asuessenbach · 2025-08-25T16:16:08Z

attachments/simple_engine/renderer.h

In this file, some functions get/return a vk::Handle, some get/return a vk::raii::Handle.
Maybe it would be more consistent to always use a vk::raii::Handle.

asuessenbach · 2025-08-25T16:26:55Z

attachments/simple_engine/renderer_compute.cpp

+        std::vector<vk::DescriptorSet> descriptorSetsToBindRaw;
+        descriptorSetsToBindRaw.reserve(1);
+        descriptorSetsToBindRaw.push_back(*computeDescriptorSets[0]);
+        commandBufferRaii.bindDescriptorSets(vk::PipelineBindPoint::eCompute, *computePipelineLayout, 0, descriptorSetsToBindRaw, {});


No need to copy stuff into a one-element vector.
You could just call
commandBufferRaii.bindDescriptorSets(vk::PipelineBindPoint::eCompute, *computePipelineLayout, 0, *computeDescriptorSets[0], {});

asuessenbach · 2025-08-25T16:29:39Z

attachments/simple_engine/renderer_compute.cpp

+        // Extract raw command buffer for submission and release RAII ownership
+        // This prevents premature destruction while preserving the recorded commands
+        vk::CommandBuffer rawCommandBuffer = *commandBufferRaii;
+        commandBufferRaii.release(); // Release RAII ownership to prevent destruction


Where will the rawCommandBuffer be destroyed, then?

…lkan queue handling. Bistro.gltf loads all textures, and creates physics geometry in under 44 seconds. Seeing 55 fps as well.

SaschaWillems · 2025-08-26T16:07:18Z

Looking better now, but the image is very noisy. I'm not sure where these come from, but I can see a lot of artifacts like these, changing when moving around:

And it looks like there is no mip mapping,

Update: This seems to be caused by over-saturation. Changing lighting so the affected surfaces get darker, the artifacts go away.

SaschaWillems · 2025-08-26T18:55:41Z

A code related question, that Andreas might've already asked (hard to see, github hides older comments): What is the idea behind converting (Vulkan-hpp) exceptions into bools? See e.g. Pipeline::createGraphicsPipeline. It catches exceptions from Vulkan-hpp and "converts" them into a bool. At work I would consider that bad practice, as the conversion removes important information (the exception).

Since this is exclusively using Vulkan-hpp and C++, why not stick to exceptions. So in above case, try, catch, log inside the function and raise the exception up to the calling code.

asuessenbach

Some more comments...

asuessenbach · 2025-09-01T11:48:01Z

attachments/simple_engine/model_loader.cpp

-                                if (LoadKTX2FileToRGBA(filePath, data, w, h, c) && renderer->LoadTextureFromMemory(textureId, data.data(), w, h, c)) {
-                                    material->albedoTexturePath = textureId;
-                                }
+                                renderer->LoadTextureAsync(filePath);


No need to LoadKTX2FileToRGBA anymore?

asuessenbach · 2025-09-01T11:56:50Z

attachments/simple_engine/model_loader.cpp

                                std::vector<uint8_t> data; int w=0,h=0,c=0;
                                std::string filePath = baseTexturePath + image.uri;
-                                if (LoadKTX2FileToRGBA(filePath, data, w, h, c) && renderer->LoadTextureFromMemory(textureId, data.data(), w, h, c)) {
+                                if (LoadKTX2FileToRGBA(filePath, data, w, h, c)) {


Here, you sequentially LoadKTX2FileToRGBA and then copy the loaded data in-memory in LoadTextureFromMemoryAsync. Both is done in the main thread, before anything asynchronously is done.

Maybe you should LoadKTX2FileToRGBA asynchronously as well?

... it seems, in the code below, you're already doing that.

asuessenbach · 2025-09-01T12:17:00Z

attachments/simple_engine/physics_system.cpp

    CleanupMarkedBodies();
 }

+void PhysicsSystem::EnqueueRigidBodyCreation(Entity* entity,


Maybe add some comment, that entity is supposed to be valid. Here, it's kept in the Engine::entityMap.

asuessenbach · 2025-09-01T12:23:17Z

attachments/simple_engine/renderer.h

+    // Texture aliasing: map canonical IDs to actual loaded keys (e.g., file paths) to avoid duplicates
+    inline void RegisterTextureAlias(const std::string& aliasId, const std::string& targetId) {
+        std::unique_lock<std::shared_mutex> lock(textureResourcesMutex);
+        if (aliasId.empty() || targetId.empty()) return;


No need to lock when aliasID or targetID is empty

asuessenbach · 2025-09-01T12:24:57Z

attachments/simple_engine/renderer.h

+        if (aliasId.empty() || targetId.empty()) return;
+        // Resolve targetId without re-locking by walking the alias map directly
+        std::string resolved = targetId;
+        for (int i = 0; i < 8; ++i) {


A magical 8?

asuessenbach · 2025-09-01T12:28:19Z

attachments/simple_engine/renderer.h

+            resolved = it->second;
+        }
+        if (aliasId == resolved) {
+            textureAliases.erase(aliasId);


In a function named RegisterTextureAlias, I would not expect something to be erased.
What does that mean?

asuessenbach · 2025-09-01T12:31:24Z

attachments/simple_engine/renderer.h

+    inline std::string ResolveTextureId(const std::string& id) const {
+        std::shared_lock<std::shared_mutex> lock(textureResourcesMutex);
+        std::string cur = id;
+        for (int i = 0; i < 8; ++i) { // prevent pathological cycles


What "pathological cycles" do you want to prevent here?

asuessenbach · 2025-09-01T12:41:57Z

attachments/simple_engine/renderer_core.cpp

+    // Initialize background thread pool for async tasks (textures, etc.) AFTER all Vulkan resources are ready
+    try {
+        // Size the thread pool based on hardware concurrency, clamped to a sensible range
+        unsigned int hw = std::max(2u, std::min(8u, std::thread::hardware_concurrency() ? std::thread::hardware_concurrency() : 4u));


std::max( ..., std::min(...)) -> std::clamp?

asuessenbach · 2025-09-01T12:47:15Z

attachments/simple_engine/renderer_core.cpp

    return true;
 }

+void Renderer::ensureThreadLocalVulkanInit() const {


Assuming, you're using vk::raii-objects only, no vk-objects, you don't need to initialize the VULKAN_HPP_DEFAULT_DISPATCHER at all. The vk::raii-objects hold their own (device-specific) dispatcher.

asuessenbach · 2025-09-01T13:12:13Z

attachments/simple_engine/renderer_core.cpp

+            .semaphoreType = vk::SemaphoreType::eTimeline,
+            .initialValue = 0
+        };
+        vk::SemaphoreCreateInfo timelineCreateInfo{ .pNext = &typeInfo };


Maybe:
vk::StructureChain<vk::SemaphoreCreateInfo, vk::SemaphoreTypeCreateInfo> timelineChain( {}, { .semaphoreType = vk::SemaphoreType::eTimeline } );

asuessenbach

Some more comments...

asuessenbach · 2025-09-02T07:59:18Z

attachments/simple_engine/renderer_core.cpp

+#include <ranges>
+#include <thread>
+
+VULKAN_HPP_DEFAULT_DISPATCH_LOADER_DYNAMIC_STORAGE; // In a .cpp file


With vk::raii, this should not be needed.

asuessenbach · 2025-09-02T08:03:37Z

attachments/simple_engine/renderer_core.cpp

+#include <vulkan/vk_platform.h>
+
+// Debug callback for vk::raii
+static VKAPI_ATTR VkBool32 VKAPI_CALL debugCallbackVkRaii(


Maybe return a vk::Bool32 here.

asuessenbach · 2025-09-02T08:18:09Z

attachments/simple_engine/renderer_core.cpp

+
+    // Create the lighting pipeline
+    if (!createLightingPipeline()) {
+        std::cerr << "Failed to create lighting pipeline" << std::endl;


Why do you have a specific error message on some steps, but not on others?

asuessenbach · 2025-09-02T08:22:07Z

attachments/simple_engine/renderer_core.cpp

+            resources.pbrDescriptorSets.clear();
+            resources.uniformBuffers.clear();
+            resources.uniformBufferAllocations.clear();
+            resources.uniformBuffersMapped.clear();


Why do you explicitly clear all those resources? Aren't they cleared automatically?

asuessenbach · 2025-09-02T08:47:29Z

attachments/simple_engine/renderer_core.cpp

+                    std::cout << "Adding optional extension: " << optionalExt << std::endl;
+                    break;
+                }
+            }


Maybe replace the inner loop with something like

if ( std::ranges::any_of( availableExtensions, [&optionalExt]( auto const & availableExt ) { return strcmp( availableExt.extensionName, optionalExt ) == 0; } ) ) { deviceExtensions.push_back( optionalExt ); std::cout << "Adding optional extension: " << optionalExt << std::endl; }

asuessenbach · 2025-09-02T09:55:05Z

attachments/simple_engine/renderer_pipelines.cpp

+        // Initialize member variable for proper lifetime management
+        pbrPipelineRenderingCreateInfo = vk::PipelineRenderingCreateInfo{
+            .sType = vk::StructureType::ePipelineRenderingCreateInfo,
+            .pNext = nullptr,


.sType again, and .pNext = nullptr

asuessenbach · 2025-09-02T09:58:05Z

attachments/simple_engine/renderer_pipelines.cpp

+        depthStencilOpaque.depthWriteEnable = VK_TRUE;
+
+        vk::GraphicsPipelineCreateInfo opaquePipelineInfo{
+            .sType = vk::StructureType::eGraphicsPipelineCreateInfo,


.sType, again

asuessenbach · 2025-09-02T09:58:55Z

attachments/simple_engine/renderer_pipelines.cpp

+            .sType = vk::StructureType::eGraphicsPipelineCreateInfo,
+            .pNext = &pbrPipelineRenderingCreateInfo,
+            .flags = vk::PipelineCreateFlags{},
+            .stageCount = 2,


.stageCount = static_cast<uint32_t>(shaderStages.size(); ?

asuessenbach · 2025-09-02T10:00:34Z

attachments/simple_engine/renderer_pipelines.cpp

+        depthStencilBlended.depthWriteEnable = VK_FALSE;
+
+        vk::GraphicsPipelineCreateInfo blendedPipelineInfo{
+            .sType = vk::StructureType::eGraphicsPipelineCreateInfo,


asuessenbach · 2025-09-02T10:02:25Z

attachments/simple_engine/renderer_pipelines.cpp

+}
+
+// Create a lighting pipeline
+bool Renderer::createLightingPipeline() {


Maybe add some comments, highlighting the differences to createGraphicsPipeline?

asuessenbach

Some more comments...

asuessenbach · 2025-09-03T12:42:48Z

attachments/simple_engine/renderer_rendering.cpp

+
+        // Find queue families
+        QueueFamilyIndices indices = findQueueFamilies(physicalDevice);
+        uint32_t queueFamilyIndices[] = {indices.graphicsFamily.value(), indices.presentFamily.value()};


std::array<uint32_t,2>?

asuessenbach · 2025-09-03T12:43:18Z

attachments/simple_engine/renderer_rendering.cpp

+        // Set sharing mode
+        if (indices.graphicsFamily != indices.presentFamily) {
+            createInfo.imageSharingMode = vk::SharingMode::eConcurrent;
+            createInfo.queueFamilyIndexCount = 2;


-> static_cast<uint32_t>(queueFamilyIndices.size())

asuessenbach · 2025-09-03T12:45:58Z

attachments/simple_engine/renderer_rendering.cpp

+                    .baseArrayLayer = 0,
+                    .layerCount = 1
+                }
+            };


Maybe move the createInfo out of this loop, and just set .image in the loop?

asuessenbach · 2025-09-03T13:13:32Z

attachments/simple_engine/renderer_rendering.cpp

+        vk::SemaphoreCreateInfo semaphoreInfo{};
+        vk::FenceCreateInfo fenceInfo{
+            .flags = vk::FenceCreateFlagBits::eSignaled
+        };


I would move the fenceInfo closer to the loop where it's used.

asuessenbach · 2025-09-03T13:17:07Z

attachments/simple_engine/renderer_rendering.cpp

+            inFlightFences.emplace_back(device, fenceInfo);
+        }
+
+        // Ensure uploads timeline semaphore exists (created early in createLogicalDevice)


"Ensure..." means, some check or assertion, or what?

asuessenbach · 2025-09-04T09:11:35Z

attachments/simple_engine/renderer_rendering.cpp

+            if (modelLoader && entity->GetName().find("_Material_") != std::string::npos) {
+                std::string entityName = entity->GetName();
+                size_t tagPos = entityName.find("_Material_");
+                if (tagPos != std::string::npos) {


Checking twice for _Material_ ?

asuessenbach · 2025-09-04T09:20:39Z

attachments/simple_engine/renderer_rendering.cpp

+                // Extract material name from entity name for any GLTF model entities
+                std::string entityName = entity->GetName();
+                size_t tagPos = entityName.find("_Material_");
+                if (tagPos != std::string::npos) {


Again checking twice for _Material_ ?

asuessenbach · 2025-09-04T09:25:50Z

attachments/simple_engine/renderer_rendering.cpp

+            if (modelLoader && entity->GetName().find("_Material_") != std::string::npos) {
+                std::string entityName = entity->GetName();
+                size_t tagPos = entityName.find("_Material_");
+                if (tagPos != std::string::npos) {


And a third time this checking sequence on _Material_. Maybe put everything in those three blocks into one?

asuessenbach · 2025-09-04T09:30:17Z

attachments/simple_engine/renderer_rendering.cpp

+            uint32_t instanceCount = static_cast<uint32_t>(std::max(1u, static_cast<uint32_t>(meshComponent->GetInstanceCount())));
+            commandBuffers[currentFrame].drawIndexed(meshIt->second.indexCount, instanceCount, 0, 0, 0);
+        }
+    }


The opaque and the blended pass are at least very similar and lengthy. Maybe it's worth to use some helper function, instead?

asuessenbach · 2025-09-04T09:33:53Z

attachments/simple_engine/renderer_rendering.cpp

+        framebufferResized = true;
+    }
+
+    if (result.first == vk::Result::eErrorOutOfDateKHR || result.first == vk::Result::eSuboptimalKHR || framebufferResized) {


Again: eErrorOutOfDataKHR won't be provided via result.first, but by an exception.

JoseEmilio-ARM · 2025-09-15T12:54:34Z

en/Building_a_Simple_Engine/Mobile_Development/06_conclusion.adoc

+
+[source,cpp]
+----
+class MobileOptimizedEngine {


Can the simple engine be built for Android as it is?

No not yet. That's going to come from the samples version.

asuessenbach

And some more comments...

asuessenbach · 2025-09-17T11:59:29Z

attachments/simple_engine/renderer_resources.cpp

+#include <cstring>
+#include <functional>
+
+// stb_image dependency removed; all GLTF textures are uploaded via memory path from ModelLoader.


Is this comment worth to have?
After all, this file is added right here, so nobody knows about its potential past.

asuessenbach · 2025-09-17T12:01:36Z

attachments/simple_engine/renderer_resources.cpp

+        );
+
+        depthImage = std::move(depthImg);
+        depthImageAllocation = std::move(depthImgAllocation);


Why do you introduce those local variables depthImg and depthImgAllocation?
You could directly use std::tie( depthImage, depthImageAllocation ) = ...

asuessenbach · 2025-09-17T12:11:23Z

attachments/simple_engine/renderer_resources.cpp

+            }
+        }
+
+        // Resolve on-disk path (may differ from logical ID)


Does this comment belong to line 69?

asuessenbach · 2025-09-17T12:13:14Z

attachments/simple_engine/renderer_resources.cpp

+        }
+
+        // Resolve on-disk path (may differ from logical ID)
+        std::string resolvedPath = textureId;


I don't get the difference between resolvedPath and textureId.

asuessenbach · 2025-09-17T12:18:16Z

attachments/simple_engine/renderer_resources.cpp

+            if (it2 != textureResources.end()) {
+                return true;
+            }
+        }


With this check here, is the check at the top of the function needed?

asuessenbach · 2025-09-17T14:54:51Z

attachments/simple_engine/renderer_resources.cpp

+                        }
+                    }
+                    descriptor_path_resolved: ;
+                }


Three identical fallback-pathes... can this be organized differently to maybe have just one?

asuessenbach · 2025-09-17T15:00:12Z

attachments/simple_engine/renderer_resources.cpp

+        std::cerr << "Failed to create descriptor sets: " << e.what() << std::endl;
+        return false;
+    }
+}


Wow, nearly 400 lines of code for a single function!
Maybe it's worth to split that into smaller chunks that are easier to digest?

asuessenbach · 2025-09-17T15:02:46Z

attachments/simple_engine/renderer_resources.cpp

+            if (!baseColor.empty()) {
+                texturePath = baseColor;
+            }
+        }


Just assign texturePath = meshComponent->GetBaseColorTexturePath()?
If it's also empty, it doesn't change anything.

asuessenbach · 2025-09-17T15:11:06Z

attachments/simple_engine/renderer_resources.cpp

+
+        // Align allocation size to nonCoherentAtomSize (64 bytes) to prevent validation errors
+        // VUID-VkMappedMemoryRange-size-01390 requires memory flush sizes to be multiples of nonCoherentAtomSize
+        const vk::DeviceSize nonCoherentAtomSize = 64; // Typical value, should query from device properties


If you should query this, why aren't you querying it?

asuessenbach · 2025-09-17T15:31:07Z

attachments/simple_engine/renderer_resources.cpp

+            // Only update PBR descriptor sets (they have light buffer bindings)
+            if (!resources.pbrDescriptorSets.empty()) {
+                for (size_t i = 0; i < resources.pbrDescriptorSets.size() && i < lightStorageBuffers.size(); ++i) {
+                    if (i < lightStorageBuffers.size() && *lightStorageBuffers[i].buffer) {


You already checked for i < lightStorageBuffers.size() one line above.

asuessenbach

Some more comments...

asuessenbach · 2025-09-18T07:32:26Z

attachments/simple_engine/renderer_utils.cpp

+            } else if (tiling == vk::ImageTiling::eOptimal && (props.optimalTilingFeatures & features) == features) {
+                return format;
+            }
+        }


Maybe:

auto formatIt = std::ranges::find_if( candidates, [&physicalDevice, &tiling, &features]( vk::Format const & format ) { vk::FormatProperties props = physicalDevice.getFormatProperties( format ); return ( tiling == vk::ImageTiling::eLinear && ( props.linearTilingFeatures & features ) == features ) || ( tiling == vk::ImageTiling::eOptimal && ( props.optimalTilingFeatures & features ) == features ); } ); if ( formatIt != candidates.end() ) { return *formatIt; }

asuessenbach · 2025-09-18T07:39:39Z

attachments/simple_engine/renderer_utils.cpp

+    } catch (const std::exception& e) {
+        std::cerr << "Failed to find supported depth format, falling back to D32_SFLOAT: " << e.what() << std::endl;
+        // Fallback to D32_SFLOAT which is widely supported
+        return vk::Format::eD32Sfloat;


This would mean, eD32Sfloat without support of eDepthStencilAttachment.
Is that reasonable?

asuessenbach · 2025-09-18T08:23:28Z

attachments/simple_engine/renderer_utils.cpp

+    }
+
+    // If not found, return first available format
+    return availableFormats[0];


Maybe add an assert( !availableFormats.empty() );

asuessenbach · 2025-09-18T08:27:30Z

attachments/simple_engine/renderer_utils.cpp

+    }
+
+    // If not found, return FIFO mode (guaranteed to be available)
+    return vk::PresentModeKHR::eFifo;


Maybe:

auto modeIt = std::ranges::find( availablePresentModes, vk::PresentModeKHR::eMailbox ); return modeIt != availablePresentModes.end() ? *modeIt : vk::PresentModeKHR::eFiFo;

asuessenbach · 2025-09-18T08:31:16Z

attachments/simple_engine/resource_manager.cpp

+
+void Resource::Unload() {
+    loaded = false;
+}


Are the Load and Unload functions complete?

attachments/simple_engine/scene_loading.cpp

asuessenbach · 2025-09-18T09:38:06Z

attachments/simple_engine/transform_component.h

+    glm::vec3 scale = {1.0f, 1.0f, 1.0f};
+
+    glm::mat4 modelMatrix = glm::mat4(1.0f);
+    bool matrixDirty = true;


Wouldn't glm::mat4(1.0f) fit is exactly to the position/rotation/scale above?
Then it's not dirty.

asuessenbach · 2025-09-18T09:40:32Z

attachments/simple_engine/transform_component.h

+     * @param eulerAngles The rotation to apply in radians.
+     */
+    void Rotate(const glm::vec3& eulerAngles) {
+        rotation += eulerAngles;


Euler angles can't be concatenated this way.

asuessenbach

And some more comments...

asuessenbach · 2025-09-22T09:11:10Z

attachments/simple_engine/vulkan_device.cpp

+
+        // Enable required features
+        auto features = physicalDevice.getFeatures2();
+        features.features.samplerAnisotropy = vk::True;


You should not get the supported features and use that struct to enable all supported features.
Instead you should use a local features struct, set the required (and supported, as should have been tested in pickPhysicalDevice) features.

asuessenbach · 2025-09-22T09:13:53Z

attachments/simple_engine/vulkan_device.cpp

+        // Enable Vulkan 1.3 features
+        vk::PhysicalDeviceVulkan13Features vulkan13Features;
+        vulkan13Features.dynamicRendering = vk::True;
+        vulkan13Features.synchronization2 = vk::True;


asuessenbach · 2025-09-22T09:14:23Z

attachments/simple_engine/vulkan_device.cpp

+        vk::PhysicalDeviceVulkan13Features vulkan13Features;
+        vulkan13Features.dynamicRendering = vk::True;
+        vulkan13Features.synchronization2 = vk::True;
+        features.pNext = &vulkan13Features;


Maybe:

vk::StructureChain<vk::PhysicalDeviceFeatures2, vk::PhysicalDeviceVulkan13Features> featureChain = { {.features = {.samplerAnisotropy = true }}, // vk::PhysicalDeviceFeatures2 {.synchronization2 = true, .dynamicRendering = true } // vk::PhysicalDeviceVulkan13Features };

en/Building_a_Simple_Engine/Camera_Transformations/02_math_foundations.adoc

en/Building_a_Simple_Engine/Camera_Transformations/03_camera_implementation.adoc

asuessenbach

And some more comments...

asuessenbach · 2025-09-23T08:34:51Z

en/Building_a_Simple_Engine/Camera_Transformations/04_camera_implementation.adoc

+    // Space and Control provide intuitive up/down movement
+    if (glfwGetKey(window, GLFW_KEY_SPACE) == GLFW_PRESS)
+        camera.processKeyboard(CameraMovement::UP, deltaTime);         // Move up along camera's up vector
+    if (glfwGetKey(window, GLFW_KEY_LEFT_CONTROL) == GLFW_PRESS)


I'm a bit surprised about this mapping.
While the other five keys are actual character keys, CONTROL is a modifier key.
Is that actually an established convention?

It probably isn't. An internal designer requested the same key conventions as another program they've been using for UP/Down translation with space being up and left control being down when using WASD. I'm totally game to modify to the desired controls. I think q/e is popular. But most games don't really have cause for up/down translations and I've seen so many mappings that I honestly don't have an opinion anymore.

en/Building_a_Simple_Engine/Camera_Transformations/04_camera_implementation.adoc

en/Building_a_Simple_Engine/Camera_Transformations/04_transformation_matrices.adoc

en/Building_a_Simple_Engine/Camera_Transformations/05_vulkan_integration.adoc

en/Building_a_Simple_Engine/Camera_Transformations/index.adoc

en/Building_a_Simple_Engine/Engine_Architecture/04_resource_management.adoc

asuessenbach

And some more comments...

en/Building_a_Simple_Engine/Engine_Architecture/05_rendering_pipeline.adoc

asuessenbach · 2025-09-24T09:21:07Z

en/Building_a_Simple_Engine/Engine_Architecture/05_rendering_pipeline.adoc

+    };
+
+    // Core data storage for the rendergraph system
+    std::unordered_map<std::string, Resource> resources;  // All resources referenced in the graph


Is the key in resources supposed to be identical to the corresponding Resource::name? Shouldn't Resource::name be removed then?

asuessenbach · 2025-09-24T09:39:41Z

en/Building_a_Simple_Engine/Engine_Architecture/05_rendering_pipeline.adoc

+            // Process input dependencies - this pass must wait for producers
+            for (const auto& input : pass.inputs) {
+                auto it = resourceWriters.find(input);
+                if (it != resourceWriters.end()) {


What does it mean, if there's no resourceWriter for this input? Is that an error in the rendergraph?

asuessenbach · 2025-09-24T09:43:25Z

en/Building_a_Simple_Engine/Engine_Architecture/05_rendering_pipeline.adoc

+            }
+
+            // Register output production - subsequent passes may depend on these
+            for (const auto& output : pass.outputs) {


Registering the pass.outputs here requires all passes are added in order. That is, pass i is not allowed to have outputs from pass j, i < j, as input.
Maybe you should first loop over the passes and gather the outputs into the resourceWriters, and then loop over the passes again to determine the dependencies.

asuessenbach · 2025-09-24T11:45:20Z

en/Building_a_Simple_Engine/Engine_Architecture/05_rendering_pipeline.adoc

+    }
+
+    // Resource access interface for retrieving compiled resources
+    Resource* GetResource(const std::string& name) {


Shouldn't GetResource be a const function, returning a const pointer?

asuessenbach · 2025-09-24T12:06:46Z

en/Building_a_Simple_Engine/Engine_Architecture/05_rendering_pipeline.adoc

+                    vk::DependencyFlagBits::eByRegion,                                 // Region-local dependency
+                    0, nullptr, 0, nullptr, 1, &barrier                               // Image barrier only
+                );
+            }


Would it also work to fill a std::vector<vk::ImageMemoryBarrier> and call commandBuffer.pipelineBarrier just once? Which one would be more performant?

asuessenbach · 2025-09-24T12:16:25Z

en/Building_a_Simple_Engine/Engine_Architecture/05_rendering_pipeline.adoc

+[source,cpp]
+----
+private:
+    uint32_t FindMemoryType(uint32_t typeFilter, vk::MemoryPropertyFlags properties) {


How does this source snippet fit to the text above?

asuessenbach · 2025-09-24T14:13:19Z

en/Building_a_Simple_Engine/Engine_Architecture/05_rendering_pipeline.adoc

+
+        auto it = renderPasses.find(name);
+        if (it != renderPasses.end()) {
+            return dynamic_cast<T*>(it->second.get());


Again: how does the user know that all of its arguments provided for a new RenderPass are ignored?

asuessenbach · 2025-09-24T14:21:02Z

en/Building_a_Simple_Engine/Engine_Architecture/05_rendering_pipeline.adoc

+
+[source,cpp]
+----
+// Forward declarations


How does this code snippet fit to the text above?

asuessenbach

Some more comments...

en/Building_a_Simple_Engine/GUI/02_imgui_setup.adoc

asuessenbach · 2025-09-25T13:04:26Z

en/Building_a_Simple_Engine/GUI/02_imgui_setup.adoc

+
+ImGuiVulkanUtil::~ImGuiVulkanUtil() {
+    // Wait for device to finish operations before destroying resources
+    if (device) {


Can it ever happen that device == nullptr?

asuessenbach · 2025-09-25T13:05:46Z

en/Building_a_Simple_Engine/GUI/02_imgui_setup.adoc

+
+[source,cpp]
+----
+void ImGuiVulkanUtil::init(float width, float height) {


Why do you separate initialization from construction?

asuessenbach · 2025-09-25T13:09:38Z

en/Building_a_Simple_Engine/GUI/02_imgui_setup.adoc

+
+=== Resource Initialization: Font Data Extraction and Memory Calculation
+
+First extract font atlas data from ImGui and calculates the memory requirements for GPU storage.


typo: calculates -> calculate

asuessenbach · 2025-09-25T13:51:22Z

en/Building_a_Simple_Engine/GUI/02_imgui_setup.adoc

+    indexBuffer.unmap();
+}
+
+==== Begin a rendering scope


Code end sign is missing

asuessenbach · 2025-09-25T14:12:37Z

en/Building_a_Simple_Engine/GUI/02_imgui_setup.adoc

Especially in this file, but I've seen it in others as well, you often have code like

vk::SamplerCreateInfo samplerInfo{}; samplerInfo.magFilter = vk::Filter::eLinear; // Smooth scaling when magnified samplerInfo.minFilter = vk::Filter::eLinear; // Smooth scaling when minified

This is totally valid code, but

You don't need the empty braced initialization vk::SamplerCreateInfo samplerInfo{}. Other than the pure C-structs, the vk-structs default-initializes all their members.

Instead of setting the members of a struct one-by-one, I would prefer to use designated initializers almost everywhere.

In some files, you also use this style:

vk::SamplerCreateInfo samplerInfo{}; samplerInfo.setMagFilter(vk::Filter::eLinear); // Smooth scaling when magnified samplerInfo.setMinFilter(vk::Filter::eLinear); // Smooth scaling when minified

which I would also consider to be inferior to the designated initializers. There are just very few cases, where you get something out of those setter functions. Maybe you should (temporarily) compile with VULKAN_HPP_NO_SETTERS set to catch those cases.

asuessenbach · 2025-09-29T13:52:35Z

en/Building_a_Simple_Engine/GUI/05_vulkan_integration.adoc

+
+This is the simplest approach and works well for most applications. With dynamic rendering, the code becomes even cleaner:
+
+=== Command Buffer Initialization


Should this and the following section ('til the "Multiple Command Buffers Approach" section) be on level 5, instead of level 3?

asuessenbach · 2025-09-29T15:08:44Z

en/Building_a_Simple_Engine/GUI/05_vulkan_integration.adoc

+    static std::function<void(ImGuiIO&)> inputCallback;
+
+    // Initialization state
+    static bool initialized;


Maybe use static inline initialization:
inline static vk::raii::Instance * instance = nullptr;
etc.

asuessenbach · 2025-09-29T15:13:52Z

en/Building_a_Simple_Engine/GUI/05_vulkan_integration.adoc

+    return commandBuffer;
+}
+
+void ImGuiUtil::endSingleTimeCommands(vk::raii::CommandBuffer& commandBuffer) {


Are beginSingleTimeCommands and endSingleTimeCommands really specific to ImGuiUtil? Or could they be just some free functions?

asuessenbach · 2025-09-29T15:16:20Z

en/Building_a_Simple_Engine/GUI/05_vulkan_integration.adoc

+    };
+
+    queue->submit(submitInfo);
+    queue->waitIdle();


This needs at least a big and loud comment that you never ever should call queue->waitIdle() (or even device->waitIdle()) in production code.
Other synchronization methods like the fence should be used instead.

SaschaWillems · 2025-09-29T16:40:28Z

We might need a different way of capturing all that feedback. With all those discussions, this PR has become so large, that githubh is often having issues loading this for me :/

gpx1000 · 2025-09-29T16:44:32Z

I love the feedback and I'm trying my best to keep up. But I agree. I'm getting pretty far behind and it'll take me a bit to even catch up to where everyone else is. Github is having problems with the size of this PR + comments. I'll try to get everything caught up in the next few days. The game engine itself still has some rendering bugs I'm trying to work through as well.
I don't have any ideas for where I can capture feedback that isn't in github.

asuessenbach · 2025-09-29T17:15:20Z

this PR has become so large, that githubh is often having issues loading this for me :/

And I thought, it's just my WLAN that's too slow!

asuessenbach

And some more comments...

asuessenbach · 2025-09-30T11:44:53Z

en/Building_a_Simple_Engine/Lighting_Materials/01_introduction.adoc

+
+This chapter serves as the foundation for understanding how light interacts with different materials in a physically accurate way. The concepts you'll learn here will be applied in later chapters, including the Loading_Models chapter where we'll use this knowledge to render glTF models with PBR materials.
+
+Throughout our engine implementation, we'll be using vk::raii dynamic rendering and C++20 modules. The vk::raii namespace provides Resource Acquisition Is Initialization (RAII) wrappers for Vulkan objects, which helps with resource management and makes the code cleaner. Dynamic rendering simplifies the rendering process by eliminating the need for explicit render passes and framebuffers. C++20 modules improve code organization, compilation times, and encapsulation compared to traditional header files.


I think, I've asked this before: does this paragraph fit into this chapter?
Either way, you need to format C++20 somehow, otherwise the ++ doesn't show up.

asuessenbach · 2025-09-30T11:57:32Z

en/Building_a_Simple_Engine/Lighting_Materials/01_introduction.adoc

+----
+
+Where:
+* albedo is the base color of the surface


The bullet points here are not rendered as a list.

Afair I did already raise that (impossible to find ^^). There needs to be an empty line between the `Where´ and the list for it to be rendererd correctly. Also affects other spots afair.

asuessenbach · 2025-09-30T12:06:23Z

en/Building_a_Simple_Engine/Lighting_Materials/01_introduction.adoc

+----
+
+Where:
+* D is the Normal Distribution Function (NDF)


Again, those bullet points are not rendered as a list.

asuessenbach · 2025-09-30T12:13:57Z

en/Building_a_Simple_Engine/Lighting_Materials/02_lighting_models.adoc

+
+In this chapter, we'll introduce Physically Based Rendering (PBR) and other lighting models. The concepts we cover here will be applied in later chapters, such as the Loading_Models chapter where we'll use glTF, which uses PBR with the metallic-roughness workflow for its material system. By understanding the theory behind different lighting models, including PBR, we can better leverage the material properties provided by glTF models and extend our rendering capabilities.
+
+Throughout our engine implementation, we'll be using vk::raii dynamic rendering and C++20 modules. The vk::raii namespace provides Resource Acquisition Is Initialization (RAII) wrappers for Vulkan objects, which helps with resource management and makes the code cleaner. Dynamic rendering simplifies the rendering process by eliminating the need for explicit render passes and framebuffers. C++20 modules improve code organization, compilation times, and encapsulation compared to traditional header files.


This very same paragraph was at various other locations already.
Note the missing ++ of C++20 in the rendered text.

asuessenbach · 2025-09-30T12:20:52Z

en/Building_a_Simple_Engine/Lighting_Materials/02_lighting_models.adoc

+* *Diffuse*: Light scattered in all directions (using Lambert's cosine law)
+* *Specular*: Shiny highlights (using a power function of the reflection vector and view vector)
+
+* *Advantages*: Reasonably realistic for many materials, intuitive parameters


You need to separate those two lists. They're rendered as one list.

asuessenbach · 2025-09-30T12:31:37Z

en/Building_a_Simple_Engine/Lighting_Materials/02_lighting_models.adoc

+* *Disadvantages*: Not physically accurate, can look artificial under certain lighting conditions
+* *When to use*: For simple real-time applications where PBR is too expensive
+
+For more information on the Phong lighting model, see the link:https://en.wikipedia.org/wiki/Phong_reflection_model[Wikipedia article].


Maybe you should emphasize the difference between Gouraud interpolation (calculate color at the vertices and interpolate them) and Phong interpolation (interpolate vertices and normals and calculate color on each pixel).
And in addition to that, Phong introduced the more complex reflection model, which could also be used with the Gouraud interpolation.

asuessenbach · 2025-10-01T10:01:54Z

en/Building_a_Simple_Engine/Lighting_Materials/04_lighting_implementation.adoc

+
+    // === LIGHTING SETUP ===
+    // Calculate view direction (camera to fragment)
+    float3 V = normalize(ubo.camPos.xyz - input.WorldPos);


V is the vector from fragment to camera, not from camera to fragment.

asuessenbach · 2025-10-01T10:09:23Z

en/Building_a_Simple_Engine/Lighting_Materials/04_lighting_implementation.adoc

+
+        // Calculate specular BRDF
+        float3 numerator = D * G * F;
+        float denominator = 4.0 * NdotV * NdotL + 0.0001; // Prevent division by zero


To prevent division by zero, wouldn't some max be the better choice?
float denominator = max( 4.0 * NdotV * NdotL, 0.0001 );

asuessenbach · 2025-10-01T11:36:04Z

en/Building_a_Simple_Engine/Lighting_Materials/04_lighting_implementation.adoc

+  * Reinhard with exposure: Multiply color by an exposure before compressing to shift middle gray.
+- Exposure parameter (ubo.exposure): Conceptually shifts scene brightness so midtones sit well under your chosen tone mapper. Even if the snippet shows a fixed operator, you can pre-scale color by exposure to support dynamic auto-exposure.
+- Gamma correction (ubo.gamma): Displays are non-linear (approx 2.2). Lighting must happen in linear space, then we apply pow(color, 1/gamma) right before writing to the sRGB framebuffer. Skipping this causes washed-out or too-dark images.
+- Pipeline note: Prefer sRGB formats for color attachments when presenting. If writing to an sRGB swapchain image, do gamma in shader OR use sRGB formats so hardware handles it — not both. Do exactly one.


I think, I don't get this sentence. What exactly is the difference between the two cases described here? Both are dealing with sRGB?

asuessenbach · 2025-10-01T12:26:46Z

en/Building_a_Simple_Engine/Lighting_Materials/04_lighting_implementation.adoc

+
+    // Copy the uniform buffer object to the device memory using vk::raii
+    // With vk::raii, we can use the mapped memory directly
+    memcpy(uniformBuffers[currentFrame].mapped, &ubo, sizeof(ubo));


Is it vk::raii-specific, that you can use the mapped memory directly?
Or is it because you keep the memory mapped in our Buffer wrapper class?

asuessenbach

Some more comments...

asuessenbach · 2025-10-02T10:19:57Z

en/Building_a_Simple_Engine/Lighting_Materials/05_vulkan_integration.adoc

+1) Extend the renderer with PBR pipeline objects and a material push-constant block
+2) Create the PBR pipeline (layout, shaders, blending, formats) alongside the main pipeline
+3) Record draws: bind PBR pipeline, bind geometry, and push per-material constants per mesh
+4) Clean up via RAII (no special teardown required)


This list is rendered in just one line.

asuessenbach · 2025-10-02T10:23:27Z

en/Building_a_Simple_Engine/Lighting_Materials/05_vulkan_integration.adoc

+
+== Updating the Cleanup
+
+We also need to update the cleanup process to destroy our PBR pipeline:


Well, we don't need to update the cleanup process.

asuessenbach · 2025-10-02T12:16:03Z

en/Building_a_Simple_Engine/Loading_Models/02_project_setup.adoc

@@ -0,0 +1,375 @@
+::pp: {plus}{plus}


A colon too much?

asuessenbach · 2025-10-02T12:18:45Z

en/Building_a_Simple_Engine/Loading_Models/02_project_setup.adoc

+- *Categorization*: Assets are grouped by type (models, textures, shaders, config)
+- *Hierarchy*: Assets are organized in a nested structure (e.g., models > characters > player)
+- *Discoverability*: Common assets are placed in dedicated folders (e.g., common textures, core shaders) making them easy to find
+- *Scalability*: The structure accommodates different quality levels and platform-specific assets (e.g., high-resolution textures, mobile shaders, quality presets)


This list isn't rendered as a list.

asuessenbach · 2025-10-02T12:36:23Z

en/Building_a_Simple_Engine/Loading_Models/02_project_setup.adoc

+
+= Loading Models: Asset Pipeline Concepts
+:doctype: book
+:sectnums:


This is the first file with sectnums.
Do you want to add that to the other files as well?

asuessenbach · 2025-10-02T13:48:49Z

en/Building_a_Simple_Engine/Loading_Models/03_model_system.adoc

+                return node;
+            }
+        }
+        return nullptr;


Maybe:

auto nodeIt = std::ranges::find_if( linearNodes, [&name]( auto const & node ){ return node.name == name; } ); return ( nodeIt != linearNodes.end() ) ? *nodeIt : nullptr;

asuessenbach · 2025-10-02T13:58:55Z

en/Building_a_Simple_Engine/Loading_Models/03_model_system.adoc

+    }
+
+    void updateAnimation(uint32_t index, float deltaTime) {
+        if (animations.empty() || index >= animations.size()) {


Is index >= animations.size() a valid check? Or would it just hide some programmer's error?
In that case, it probably should be replaced by an assertion.

And, by the way: is a public function that updates a specific animation reasonable? Or should it be private and a public function updates all animations.

asuessenbach · 2025-10-02T14:03:16Z

en/Building_a_Simple_Engine/Loading_Models/03_model_system.adoc

+        }
+
+        for (auto& channel : animation.channels) {
+            AnimationSampler& sampler = animation.samplers[channel.samplerIndex];


Maybe add an
assert( channel.samplerIndex < animation.samplers.size() );

asuessenbach · 2025-10-02T14:06:53Z

en/Building_a_Simple_Engine/Loading_Models/03_model_system.adoc

+        Animation& animation = animations[index];
+        animation.currentTime += deltaTime;
+        if (animation.currentTime > animation.end) {
+            animation.currentTime = animation.start;


The animation always gets to the start. No matter how much deltaTime might have advanced beyond animation.end.

asuessenbach · 2025-10-02T14:17:41Z

en/Building_a_Simple_Engine/Loading_Models/03_model_system.adoc

+
+            // Find the current key frame
+            for (size_t i = 0; i < sampler.inputs.size() - 1; i++) {
+                if (animation.currentTime >= sampler.inputs[i] && animation.currentTime <= sampler.inputs[i + 1]) {


Maybe:

auto keyFrameIt = std::ranges::lower_bound( sampler.inputs, animation.currentTime ); assert( keyFrameIt != sampler.inputs.end() ); size_t keyFrameIndex = std::distance( sampler.inputs.begin(), keyFrameIt );

asuessenbach

Some more comments...

asuessenbach · 2025-10-06T15:47:11Z

en/Building_a_Simple_Engine/Loading_Models/04_loading_gltf.adoc

+glTF supports three interpolation methods:
+* *LINEAR*: Smooth transitions with constant velocity
+* *STEP*: Sudden changes with no interpolation
+* *CUBICSPLINE*: Smooth curves with control points for acceleration and deceleration


This list isn't rendered as a list.

asuessenbach · 2025-10-13T20:24:34Z

en/Building_a_Simple_Engine/Loading_Models/05_pbr_rendering.adoc

+
+[source,cpp]
+----
+void drawModel(vk::raii::CommandBuffer& commandBuffer, Model* model) {


Is the model supposed to be changed in this function?
If not, it should be a const *.

asuessenbach · 2025-10-13T20:27:31Z

en/Building_a_Simple_Engine/Loading_Models/05_pbr_rendering.adoc

+==== Image-Based Lighting (IBL)
+
+link:https://learnopengl.com/PBR/IBL/Diffuse-irradiance[IBL] uses environment maps to simulate global illumination:
+* *Diffuse IBL*: Uses link:https://learnopengl.com/PBR/IBL/Diffuse-irradiance[irradiance maps] for ambient lighting


This list here and beneath aren't rendered as a list.

asuessenbach · 2025-10-14T14:37:19Z

en/Building_a_Simple_Engine/Loading_Models/06_multiple_objects.adoc

+
+        // Store buffer and memory
+        instanceBuffers.push_back(instanceBuffer);
+        instanceBufferMemories.push_back(instanceBufferMemory);


You probably want to move the buffer and the memory. You can't copy them.

asuessenbach · 2025-10-14T15:28:50Z

en/Building_a_Simple_Engine/Loading_Models/07_scene_rendering.adoc

+
+The material configuration system bridges the gap between artist-authored materials and GPU shader parameters. Push constants provide the fastest path for updating per-object material data, as they bypass the GPU's memory hierarchy and are directly accessible to shader cores. This makes them ideal for material properties that change frequently between draw calls.
+
+The texture index mapping system (-1 for unused, positive integers for active bindings) allows shaders to conditionally sample textures based on availability. This approach provides flexibility where some materials might have normal maps while others don't, without requiring different shader variants or complex branching logic.


But 0 is a valid index. That is, non-negative integers are valid values for active bindings.

asuessenbach · 2025-10-14T15:37:53Z

en/Building_a_Simple_Engine/Loading_Models/07_scene_rendering.adoc

+
+[NOTE]
+====
+We covered PBR material theory and shader details earlier in Loading_Models/05_pbr_rendering.adoc, so we won’t restate that here. This section focuses on the wiring: how material properties are packed into push constants and consumed by the draw call in this chapter’s context.


Should this be a link to the 05_pbr_rendering.adoc?

asuessenbach · 2025-10-14T15:40:38Z

en/Building_a_Simple_Engine/Loading_Models/07_scene_rendering.adoc

+                pushConstants.baseColorFactor = glm::vec4(1.0f);               // White base color
+                pushConstants.metallicFactor = 1.0f;                           // Fully metallic (safe default)
+                pushConstants.roughnessFactor = 1.0f;                          // Fully rough (safe default)
+                pushConstants.baseColorTextureSet = 1;                         // Assume default texture


Is it correct to have the baseColorTextureSet = 1 for the default material?

asuessenbach · 2025-10-14T15:44:53Z

en/Building_a_Simple_Engine/Loading_Models/07_scene_rendering.adoc

+2) Begin rendering, bind pipeline, set viewport/scissor
+3) Update camera UBO (view/projection)
+4) Traverse scene graph and issue per-mesh draws
+5) End rendering and present


This list isn't rendered as a list.

asuessenbach · 2025-10-14T16:06:58Z

en/Building_a_Simple_Engine/Loading_Models/07_scene_rendering.adoc

+==== Occlusion Culling
+
+Occlusion culling involves skipping the rendering of objects that are hidden behind other objects:
+


Maybe you should note, that the presented algorithm works, but in its naïve form is unlikely to give a performance boost.
More efficient, but more complex handling would be needed.

asuessenbach

Some more comments...

asuessenbach · 2025-10-15T07:49:10Z

en/Building_a_Simple_Engine/Loading_Models/08_animations.adoc

+    InterpolationType interpolation;
+    std::vector<float> inputs;  // Key frame timestamps
+    std::vector<glm::vec4> outputsVec4;  // Key frame values (for rotations)
+    std::vector<glm::vec3> outputsVec3;  // Key frame values (for translations and scales)


I assume, either outputsVec4 or outputsVec3 are used, never both?
Shouldn't it be a std::variant<std::vector<glm::vec4>, std::vector<glm::vec3>>, or a std::vector<std::variant<glm::vec4, glm::vec3>> then?

Moreover, inputs and outputs are probably meant to have the same size?
Maybe something like std::vector<KeyFrame> keyFrames;, instead, with

struct KeyFrame { float time; std::variant<glm::vec4, glm::vec3> value; };

asuessenbach · 2025-10-15T07:55:10Z

en/Building_a_Simple_Engine/Loading_Models/08_animations.adoc

+struct Animation {
+    std::string name;
+    std::vector<AnimationSampler> samplers;
+    std::vector<AnimationChannel> channels;


Again, samplers and channels are probably meant to be in sync?
Maybe something like std::vector<std::pair<AnimationSampler, AnimationChannel>>, instead?
Or some more descriptively named struct holding one sampler and channel?

asuessenbach · 2025-10-15T08:04:48Z

en/Building_a_Simple_Engine/Loading_Models/08_animations.adoc

+    Animation& animation = animations[index];
+    animation.currentTime += deltaTime;
+    if (animation.currentTime > animation.end) {
+        animation.currentTime = animation.start;


Maybe something like

while ( animation.currentTime >= animation.end ) { animation.currentTime -= animation.end - animation.start; }

asuessenbach · 2025-10-15T08:06:42Z

en/Building_a_Simple_Engine/Loading_Models/08_animations.adoc

+
+=== Animation Update: Channel Iteration and Sampler Access
+
+New we iterate through all animation channels, establishing the connection between abstract animation data and the specific nodes in our scene graph that will receive transformation updates.


Typo: New -> Now

asuessenbach · 2025-10-15T08:14:44Z

en/Building_a_Simple_Engine/Loading_Models/08_animations.adoc

+[source,cpp]
+----
+        // Find the current keyframe pair that brackets the animation time
+        for (size_t i = 0; i < sampler.inputs.size() - 1; i++) {


Maybe use std::lower_bound to find the current keyframe

asuessenbach · 2025-10-15T08:31:29Z

en/Building_a_Simple_Engine/Loading_Models/08_animations.adoc

+    // Store intermediate transformations
+    std::vector<glm::vec3> fromTranslations;
+    std::vector<glm::quat> fromRotations;
+    std::vector<glm::vec3> fromScales;


You should probably reserve model.linearNodes.size() elements for those three vectors.

asuessenbach · 2025-10-15T08:32:51Z

en/Building_a_Simple_Engine/Loading_Models/08_animations.adoc

+
+        allTranslations.push_back(translations);
+        allRotations.push_back(rotations);
+        allScales.push_back(scales);


You should probably move those vectors here, not copy.

asuessenbach · 2025-10-15T08:35:19Z

en/Building_a_Simple_Engine/Loading_Models/08_animations.adoc

+
+        // Special handling for quaternions (rotations)
+        // We use nlerp (normalized lerp) for multiple quaternions
+        for (size_t animIdx = 0; animIdx < animationIndices.size(); animIdx++) {


I don't see, why you're using two separate loops here.

asuessenbach · 2025-10-15T08:41:04Z

en/Building_a_Simple_Engine/Loading_Models/08_animations.adoc

+        weights.push_back(weight);
+
+        // Limit to 3 closest animations for performance
+        if (animIndices.size() > 3) {


This does not limit to 3, but just reduces by one if there are more than 3.

asuessenbach · 2025-10-15T09:03:54Z

en/Building_a_Simple_Engine/Loading_Models/08_animations.adoc

+            headNode = node;
+            break;
+        }
+    }


Use std::find_if?

… the tutorial section first as only 90 total comments there, 200+ in the attachments and there's still bugs in the game engine itself. Holding back game code changes until it's bug free.

…. IDE ran out of memory trying to read them which means it's time for bed. Will do more tomorrow.

…heckin so I can work on other things in the tutorial and come back to this. Integrate mikktspace tangent generation, enhance robust tangent handling for poles, unify shader refraction logic, improve transmission Fresnel, and implement thread-safe rigid body management.

asuessenbach · 2025-10-17T14:19:05Z

en/Building_a_Simple_Engine/Mobile_Development/01_introduction.adoc

+
+This chapter represents the culmination of everything we've built throughout the previous chapters, as mobile development requires deep integration with all engine systems. You'll need solid mastery of Vulkan fundamentals and the engine architecture we've developed, since mobile optimization often requires fine-tuning at every level—from resource management and rendering pipelines to memory allocation and synchronization.
+
+Modern C++ expertise becomes particularly valuable in mobile development, where performance constraints demand efficient code and careful resource management. C++17 and C++20 features like constexpr, structured bindings, and concepts help create mobile-optimized code that performs well under strict power and thermal limitations.


That's funny: C++20 is correctly rendered, but C++ and C++17 are missing the ++.

asuessenbach · 2025-10-21T12:28:52Z

attachments/simple_engine/audio_system.h


+    // Constructor-based initialization to replace separate Initialize() calls
+    AudioSystem(Engine* engine, Renderer* renderer) {
+        if (!Initialize(engine, renderer)) {


When you call Initialize in the constructor, you should probably make Initialize a private function.

asuessenbach · 2025-10-21T12:35:25Z

attachments/simple_engine/engine.cpp

-        }
+        if (!entity) { continue; }
+        if (!entity->IsActive()) { continue; }
+        entity->Update(deltaTime);


Maybe a bit easier to digest:

if (entity && entity->IsActive()) { entity->Update(deltaTime); }

asuessenbach · 2025-10-21T12:37:15Z

attachments/simple_engine/imgui_system.cpp


        // Exposure slider
-        static float exposure = 3.0f; // Higher default for emissive lighting
+        static float exposure = 1.2f; // Default tuned to avoid washout


Maybe add some
static const float defaultExposure = 1.2f;

asuessenbach · 2025-10-21T12:38:16Z

attachments/simple_engine/imgui_system.h


+    // Constructor-based initialization to replace separate Initialize() calls
+    ImGuiSystem(Renderer* renderer, uint32_t width, uint32_t height) {
+        if (!Initialize(renderer, width, height)) {


Initialize should probably be private now.

asuessenbach · 2025-10-21T13:12:33Z

attachments/simple_engine/model_loader.h

    ModelLoader() = default;
+    // Constructor-based initialization to replace separate Initialize() calls
+    explicit ModelLoader(Renderer* _renderer) {
+        if (!Initialize(_renderer)) {


Initialize then should be private.

asuessenbach · 2025-10-21T13:16:27Z

attachments/simple_engine/physics_system.h

+    explicit PhysicsSystem(Renderer* _renderer, bool enableGPU = true) {
+        SetRenderer(_renderer);
+        SetGPUAccelerationEnabled(enableGPU);
+        if (!Initialize()) {


Again: Initialize should be private.

asuessenbach · 2025-10-21T13:25:15Z

attachments/simple_engine/renderer_core.cpp

+
+        // First, handle dependency: VK_EXT_attachment_feedback_loop_dynamic_state requires VK_EXT_attachment_feedback_loop_layout
+        const char* dynState = VK_EXT_ATTACHMENT_FEEDBACK_LOOP_DYNAMIC_STATE_EXTENSION_NAME;
+        const char* layoutReq = "VK_EXT_attachment_feedback_loop_layout";


VK_EXT_ATTACHMENT_FEEDBACK_LOOP_LAYOUT_EXTENSION_NAME?

asuessenbach · 2025-10-21T13:32:13Z

attachments/simple_engine/renderer_core.cpp

+        // First, handle dependency: VK_EXT_attachment_feedback_loop_dynamic_state requires VK_EXT_attachment_feedback_loop_layout
+        const char* dynState = VK_EXT_ATTACHMENT_FEEDBACK_LOOP_DYNAMIC_STATE_EXTENSION_NAME;
+        const char* layoutReq = "VK_EXT_attachment_feedback_loop_layout";
+        bool dynSupported = avail.count(dynState) > 0;


Maybe use std::set::contains, instead of count > 0?

asuessenbach · 2025-10-21T13:41:23Z

attachments/simple_engine/renderer_core.cpp

        // Enable required features
        auto features = physicalDevice.getFeatures2();
        features.features.samplerAnisotropy = vk::True;
+        features.features.depthBiasClamp = vk::True;


Do you check somewhere for support of all those features?

asuessenbach

Some more comments...

asuessenbach · 2025-10-22T19:32:11Z

attachments/simple_engine/renderer_rendering.cpp

+    // Signal to the shader whether swapchain is sRGB (1) or not (0) using padding0
+    int outputIsSRGB = (swapChainImageFormat == vk::Format::eR8G8B8A8Srgb ||
+                        swapChainImageFormat == vk::Format::eB8G8R8A8Srgb) ? 1 : 0;
+    ubo.padding0 = outputIsSRGB;


I think, it's not a good idea to carry some real information in a member called padding0

Besides that: maybe (from vulkan_format_traits.hpp)
ubo.padding0 = ( vk::componentNumericFormat( swapChainImageFormat, 0 ) == "SRGB" );

asuessenbach · 2025-10-22T19:37:53Z

attachments/simple_engine/renderer_rendering.cpp

-            ImGui::EndFrame();
-        }
-
+    if (result.first == vk::Result::eErrorOutOfDateKHR || result.first == vk::Result::eSuboptimalKHR || framebufferResized.load(std::memory_order_relaxed)) {


Unfortunately, eErrorOutOfDataKHR will only be available via an exception, not as a value of result.first.
(This can be changed with the Vulkan version 1.4.328, where a new compile-time flag VULKAN_HPP_HANDLE_ERROR_OUT_OF_DATE_AS_SUCCESS is introduced to make this error code a success code.)

asuessenbach · 2025-10-22T19:40:22Z

attachments/simple_engine/renderer_rendering.cpp

-    if (result.first != vk::Result::eSuccess) {
-        throw std::runtime_error("Failed to acquire swap chain image");
-    }
+    if (result.first != vk::Result::eSuccess) { throw std::runtime_error("Failed to acquire swap chain image"); }


acquireNextImage above should have thrown an exception in case of an error.
That is, this check will always fail.

asuessenbach · 2025-10-23T09:46:57Z

attachments/simple_engine/renderer_rendering.cpp

+void Renderer::Render(const std::vector<std::unique_ptr<Entity>>& entities, CameraComponent* camera, ImGuiSystem* imguiSystem) {
+    if (memoryPool) memoryPool->setRenderingActive(true);
+    struct RenderingStateGuard { MemoryPool* pool; explicit RenderingStateGuard(MemoryPool* p) : pool(p) {} ~RenderingStateGuard() { if (pool) pool->setRenderingActive(false); } } guard(memoryPool.get());
+


Any reason, why you have compressed this into one line?

asuessenbach · 2025-10-23T10:00:14Z

attachments/simple_engine/renderer_rendering.cpp

+    try {
+        opaqueSceneColorImage.clear();
+        opaqueSceneColorImageView.clear();
+        opaqueSceneColorSampler.clear();


It's not obvious that a function called createImageViews also clears some opaqueSceneColorImage and opaqueSceneColorSampler. And also that it clears the opaqueSceneColorImageView, but doesn't (re-)create it.

asuessenbach · 2025-10-23T13:15:19Z

attachments/simple_engine/renderer_rendering.cpp

+                commandBuffers[currentFrame].bindIndexBuffer(*meshIt->second.indexBuffer, 0, vk::IndexType::eUint32);
+                updateUniformBuffer(currentFrame, entity, camera);
+                auto& descSets = useBasic ? entityIt->second.basicDescriptorSets : entityIt->second.pbrDescriptorSets;
+                if (descSets.empty() || currentFrame >= descSets.size()) continue;


Again can this ever happen?
If so, should it be checked before the commandBuffer is filled?

asuessenbach · 2025-10-23T13:19:58Z

attachments/simple_engine/renderer_rendering.cpp

+                    if (modelLoader && entity->GetName().find("_Material_") != std::string::npos) {
+                        std::string entityName = entity->GetName();
+                        size_t tagPos = entityName.find("_Material_");
+                        if (tagPos != std::string::npos) {


The same comments regarding "Material" handling as above.

asuessenbach · 2025-10-23T13:26:20Z

attachments/simple_engine/renderer_rendering.cpp

+        vk::ImageMemoryBarrier opaqueShaderBarrier{ .srcAccessMask = vk::AccessFlagBits::eTransferRead, .dstAccessMask = vk::AccessFlagBits::eShaderRead, .oldLayout = vk::ImageLayout::eTransferSrcOptimal, .newLayout = vk::ImageLayout::eShaderReadOnlyOptimal, .image = *opaqueSceneColorImage, .subresourceRange = {vk::ImageAspectFlagBits::eColor, 0, 1, 0, 1} };
+        commandBuffers[currentFrame].pipelineBarrier(vk::PipelineStageFlagBits::eTransfer, vk::PipelineStageFlagBits::eFragmentShader, {}, {}, {}, opaqueShaderBarrier);
+        vk::ImageMemoryBarrier swapchainTargetBarrier{ .srcAccessMask = vk::AccessFlagBits::eTransferWrite, .dstAccessMask = vk::AccessFlagBits::eColorAttachmentWrite, .oldLayout = vk::ImageLayout::eTransferDstOptimal, .newLayout = vk::ImageLayout::eColorAttachmentOptimal, .image = swapChainImages[imageIndex], .subresourceRange = {vk::ImageAspectFlagBits::eColor, 0, 1, 0, 1} };
+        commandBuffers[currentFrame].pipelineBarrier(vk::PipelineStageFlagBits::eTransfer, vk::PipelineStageFlagBits::eColorAttachmentOutput, {}, {}, {}, swapchainTargetBarrier);


This section is close to unreadable. Some line breaks would probably help.
And, of course, some comments, what each barrier does.

asuessenbach · 2025-10-23T13:38:09Z

attachments/simple_engine/renderer_rendering.cpp

+            imguiSystem->Render(commandBuffers[currentFrame], currentFrame);
+        }
+        commandBuffers[currentFrame].endRendering();
+    }


The opaque and the transparent path seem to be very similar. Maybe worth to introduce a helper function?

asuessenbach · 2025-10-23T13:42:17Z

attachments/simple_engine/renderer_rendering.cpp

A couple of lines are simply too long.
And the function Render as well.

…ture uploads, and thread-safe texture tracking. Refactor Vulkan queue handling and improve modern C++ usage. BRDF now works as intended so we have true PBR scene. We're going to add environment mapping in the complex samples, so this should complete the tutorial verison of the game engine.

# Conflicts: # antora/modules/ROOT/nav.adoc # en/02_Development_environment.adoc

gpx1000 added 30 commits July 14, 2025 00:09

closer to getting engine working.

2a350b2

address feedback

2d46280

address feedback

3b3dc05

address feedback

6cf03fc

add the flowchart to the rendering pipeline.

50d78a7

describe Rendergraphs and Dynamic Rendering

9b2c781

address comments.

ddd1177

add the requested appendix.adoc

5ec2035

add the requested appendix.adoc

31ded49

address the requested items

659ecb1

address the requested items

bd98b2d

address the requested items

8b83ead

address the requested items

9b2343a

Engine now builds and runs. IMGUI having issues.

7734f21

Engine now renders. Bunch of validation errors and it looks like imgu…

b8a9b39

…i needs some help. it also looks like cleanup logic and resizing needs work.

address comments.

e773353

address comments.

6256f77

It runs now, IMGUI is happier.

e6b8583

everything runs and can close without validation warnings other than …

e3f6fc6

…the semaphore. resizing still doesn't work. Next step is to get the parts of the engine to demonstrate things.

everything runs and can close without validation warnings other than …

4a3b450

…the semaphore. resizing still doesn't work. Next step is to get the parts of the engine to demonstrate things.

audio HRTF works well and debug switch to turn on CPU only mode vs GP…

0833166

…U processing mode.

audio fully works, GPU HRTF works as well as CPU HRTF.

9513597

The bistro scene now loads. Still have some issues with PBR but I thi…

86c396a

…nk that's due to material only looking at the vespa. This includes camera controls.

make the hrtf listener sync with the camera location and rotation.

a62e4a9

asuessenbach reviewed Aug 25, 2025

View reviewed changes

gpx1000 added 2 commits August 25, 2025 14:58

update the default screenshot.

bbbae41

implementing support for asynchronous texture loading and improved Vu…

03d05cf

…lkan queue handling. Bistro.gltf loads all textures, and creates physics geometry in under 44 seconds. Seeing 55 fps as well.

asuessenbach reviewed Sep 1, 2025

View reviewed changes

asuessenbach reviewed Sep 2, 2025

View reviewed changes

asuessenbach reviewed Sep 4, 2025

View reviewed changes

JoseEmilio-ARM reviewed Sep 15, 2025

View reviewed changes

asuessenbach reviewed Sep 17, 2025

View reviewed changes

asuessenbach reviewed Sep 18, 2025

View reviewed changes

asuessenbach reviewed Sep 22, 2025

View reviewed changes

asuessenbach reviewed Sep 23, 2025

View reviewed changes

asuessenbach reviewed Sep 24, 2025

View reviewed changes

asuessenbach reviewed Sep 29, 2025

View reviewed changes

asuessenbach reviewed Oct 1, 2025

View reviewed changes

asuessenbach reviewed Oct 2, 2025

View reviewed changes

asuessenbach reviewed Oct 14, 2025

View reviewed changes

asuessenbach reviewed Oct 15, 2025

View reviewed changes

gpx1000 added 3 commits October 17, 2025 01:35

Working through some of the PR comments. Concentrating on the text of…

0ef0316

… the tutorial section first as only 90 total comments there, 200+ in the attachments and there's still bugs in the game engine itself. Holding back game code changes until it's bug free.

Down to 78 comments left outstanding from the PR in the tutorial text…

277a817

…. IDE ran out of memory trying to read them which means it's time for bed. Will do more tomorrow.

asuessenbach reviewed Oct 21, 2025

View reviewed changes

asuessenbach reviewed Oct 23, 2025

View reviewed changes

gpx1000 added 2 commits November 30, 2025 23:25

Merge branch 'upstream-main' into Simple-Game-Engine

0e9721e

# Conflicts: # antora/modules/ROOT/nav.adoc # en/02_Development_environment.adoc

gpx1000 merged commit 67901ee into KhronosGroup:main Dec 1, 2025
6 checks passed


		=== Resource Initialization: Font Data Extraction and Memory Calculation

		First extract font atlas data from ImGui and calculates the memory requirements for GPU storage.


		This is the simplest approach and works well for most applications. With dynamic rendering, the code becomes even cleaner:

		=== Command Buffer Initialization


		This chapter serves as the foundation for understanding how light interacts with different materials in a physically accurate way. The concepts you'll learn here will be applied in later chapters, including the Loading_Models chapter where we'll use this knowledge to render glTF models with PBR materials.

		Throughout our engine implementation, we'll be using vk::raii dynamic rendering and C++20 modules. The vk::raii namespace provides Resource Acquisition Is Initialization (RAII) wrappers for Vulkan objects, which helps with resource management and makes the code cleaner. Dynamic rendering simplifies the rendering process by eliminating the need for explicit render passes and framebuffers. C++20 modules improve code organization, compilation times, and encapsulation compared to traditional header files.


		In this chapter, we'll introduce Physically Based Rendering (PBR) and other lighting models. The concepts we cover here will be applied in later chapters, such as the Loading_Models chapter where we'll use glTF, which uses PBR with the metallic-roughness workflow for its material system. By understanding the theory behind different lighting models, including PBR, we can better leverage the material properties provided by glTF models and extend our rendering capabilities.

		Throughout our engine implementation, we'll be using vk::raii dynamic rendering and C++20 modules. The vk::raii namespace provides Resource Acquisition Is Initialization (RAII) wrappers for Vulkan objects, which helps with resource management and makes the code cleaner. Dynamic rendering simplifies the rendering process by eliminating the need for explicit render passes and framebuffers. C++20 modules improve code organization, compilation times, and encapsulation compared to traditional header files.


		== Updating the Cleanup

		We also need to update the cleanup process to destroy our PBR pipeline:


		The material configuration system bridges the gap between artist-authored materials and GPU shader parameters. Push constants provide the fastest path for updating per-object material data, as they bypass the GPU's memory hierarchy and are directly accessible to shader cores. This makes them ideal for material properties that change frequently between draw calls.

		The texture index mapping system (-1 for unused, positive integers for active bindings) allows shaders to conditionally sample textures based on availability. This approach provides flexibility where some materials might have normal maps while others don't, without requiring different shader variants or complex branching logic.

		==== Occlusion Culling

		Occlusion culling involves skipping the rendering of objects that are hidden behind other objects:


		=== Animation Update: Channel Iteration and Sampler Access

		New we iterate through all animation channels, establishing the connection between abstract animation data and the specific nodes in our scene graph that will receive transformation updates.


		This chapter represents the culmination of everything we've built throughout the previous chapters, as mobile development requires deep integration with all engine systems. You'll need solid mastery of Vulkan fundamentals and the engine architecture we've developed, since mobile optimization often requires fine-tuning at every level—from resource management and rendering pipelines to memory allocation and synchronization.

		Modern C++ expertise becomes particularly valuable in mobile development, where performance constraints demand efficient code and careful resource management. C++17 and C++20 features like constexpr, structured bindings, and concepts help create mobile-optimized code that performs well under strict power and thermal limitations.

Simple game engine #119

Simple game engine #119

Uh oh!

Conversation

gpx1000 commented Jul 31, 2025

Uh oh!

asuessenbach left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SaschaWillems commented Aug 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SaschaWillems commented Aug 26, 2025

Uh oh!

asuessenbach left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

asuessenbach left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SaschaWillems commented Aug 26, 2025 •

edited

Loading