This live stream session focuses on the continued refactoring of the Hazel game engine's rendering pipeline to adopt NVRHI (NVIDIA's Rendering Hardware Interface). The immediate objective is to integrate and run Hazel's editor UI, built with ImGui, using the new NVRHI backend, specifically targeting Vulkan. The primary technical challenge explored is bridging the gap between ImGui's direct dependency on raw Vulkan objects (like VkDescriptorSet, VkImageView, and VkSampler) and NVRHI's higher-level resource abstractions. The streamer devises a strategy to make ImGui's ImTextureID represent an NVRHI binding set, which internally manages the Vulkan resources. This involves creating custom NVRHI wrappers for existing Vulkan descriptor set layouts and samplers to satisfy NVRHI's API requirements while retaining compatibility with ImGui's underlying Vulkan rendering. The stream also touches on project logistics, development philosophy, and broader platform support for Hazel.
Refactoring Hazel's Renderer for NVRHI: Integrating ImGui and Tackling Vulkan Abstractions
0:00:01 - Stream Logistics & Community Engagement: The streamer, Cherno, introduces the live stream and discusses his new bi-modal streaming schedule (morning/evening) to cater to different time zones. He announces plans to upload full VODs to his "Cherno Unplugged" YouTube channel for free, permanent access, trimming out initial "starting soon" segments.
0:04:01 - Hazel Engine Roadmap & Current Focus: Viewers are directed to hazelengine.com/roadmap for context on the project's current development stage. The primary focus is "Renderer 2025," which involves modernizing Hazel's rendering capabilities by integrating NVRHI.
0:05:25 - Hazel's Patreon Model Clarification: Addressing recent external commentary, Cherno clarifies that Hazel's $10/month Patreon subscription provides perpetual access to the engine version obtained during the paid month, meaning users don't lose access if they stop paying, unlike some subscription software.
0:06:45 - Flexible Development Workflow: Hazel uses a less bureaucratic, volunteer-friendly branching strategy. Major features, like "Renderer 2025," get dedicated branches, while smaller changes might be committed directly to the dev branch. The general flow is feature branches -> dev -> staging (for QA) -> release version branches.
0:12:24 - Renderer 2025 Branch Status: Cherno admits that despite significant local work, the renderer-2025 branch hasn't seen a public commit since October, but he plans to push updates soon.
0:18:45 - "Vertical Slice" Development Philosophy & Immediate Goal: Cherno favors "vertical slice driven development"—getting a minimal, end-to-end working system first, then iteratively filling in details. His immediate goal is to get the Hazel editor's ImGui user interface running with the new NVRHI-based renderer, even without the 3D viewport, to validate basic windowing and UI rendering.
0:22:36 - ImGui Integration Challenges & Strategy: ImGui's rendering (which currently uses a Vulkan backend in Hazel) needs to be adapted for NVRHI. A key challenge is ImGui's viewport feature, which requires dynamic window and swap chain creation, a task NVRHI (a rendering API abstraction) does not handle directly. The decision is made to keep ImGui's existing platform-specific backends (Vulkan, DX11, DX12) to manage windowing and swap chains for these viewports.
0:28:27 - Continued Mac OS Support: Despite NVRHI not having a native Metal backend out-of-the-box, Mac OS support is not dropped. A Metal backend can be added to NVRHI, and Hazel currently runs on macOS via MoltenVK (a Vulkan-to-Metal translation layer).
0:32:39 - Consolidating ImGui Backends: Cherno modifies Hazel's ImGui build setup to simultaneously compile DirectX 11, DirectX 12, and Vulkan backends, enabling runtime API switching for flexibility.
0:47:30 - Core Technical Problem: Bridging ImGui Vulkan and NVRHI: The central challenge is making ImGui's Vulkan backend, which expects raw Vulkan objects (VkDescriptorSet, VkImageView, VkSampler), work with textures and resources managed by NVRHI. The ImTextureID in ImGui, previously a VkDescriptorSet, needs to be re-envisioned.
1:19:03 - Adapting ImTextureID for NVRHI Binding Sets: Cherno decides to change ImTextureID to be an nvhri::IBindingSet*. This IBindingSet will be created using an nvhri::ITexture* and an nvhri::ISampler*. The nvhri::IBindingLayout* required for creating the binding set will wrap the existing Vulkan VkDescriptorSetLayout that ImGui's shaders expect, and the nvhri::ISampler* will wrap an existing Vulkan VkSampler. This allows extracting the underlying VkDescriptorSet for ImGui's rendering.
2:03:39 - Handling NVRHI C++ Reference Members: Minor hurdles arise from NVRHI classes having reference members that require immediate initialization, necessitating workarounds like passing dummy contexts during wrapper object creation.
2:15:20 - Build Issues & Module Exclusion: As refactoring progresses, numerous compilation errors occur due to dependencies on the old Vulkan renderer. Cherno systematically excludes unported parts of the old renderer (VulkanMaterial, VulkanComputePipeline, and portions of VulkanRenderer) to focus on building the minimal set required for ImGui.
2:22:51 - Next Steps: The immediate next step is to get the core Renderer class building with NVRHI. Once the basic NVRHI rendering context, window, and swap chain are functional, the focus will shift to successfully rendering the ImGui editor and then iterating on filling in the remaining renderer features.