Home Creators Posts Import Register Favorites Logout

Videos

Content

Hi all, welcome to the first new exclusive video! If you're out of the loop I put up a video here on Patreon a few days ago announcing this new type of exclusive content for $5+ Patrons - basically I'll be putting out technical deep-dives on various Hazel topics every week or so!

In this first one we're taking a look at Hazel's new, much faster renderer. There's a lot to talk about so this will be a multi-part little series.

Would love some feedback on this new format because these videos are 100% for you! If you have questions on anything I mention in the video or suggestions for topics to look into, just leave a comment below - I'll go through all of your comments in the next video! ❤️

Files

(No title)

Comments

David Mortensen

I really enjoyed this video, and how relaxed it was with no fast pacing through the video, i could take it all in a lot more :) I love long videos for this reason! Thanks a lot for giving us such great content <3

CreatorInDeep

You helped me a lot in understanding why we need different `set`s as well as gave me a lot of ideas as to how can I improve my engine! Keep up with the series, it's definitely something I'm looking forward! An idea for future videos I can give is Renderer Thread, Forward+, Instance Rendering, and Mesh system (with how to properly handle complex meshes with a lot of sub meshes and materials.) .

Benjamin Rosseaux

Have you thought about Bindless Rendering using VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT, VK_KHR_BUFFER_DEVICE_ADDRESS_EXTENSION and VK_EXT_DESCRIPTOR_INDEXING, where you just put all textures into the last "dynamic" Descriptor Texure Array Binding of a set, which you then always update when new textures are loaded or textures are unloaded? Because in my 3D engine part of my PasVulkan project I use this approach in combination with a dynamic material storage buffer (or buffer device address based buffer (with BDA, you've basically raw memory pointers on GLSL side, when the GPU has support for it, which can be used to optimize many stuff even further.), where the shaders have random access to all materials and textures at any time, so that in the ideal case you can render a complete scene with only one draw call in a RenderPass, or at least reduce the number of Vulkan API calls even more massively. For this purpose, I simply added a material ID per vertex, so that there is no more material switching on the CPU side, but everything happens random-access-based on the GPU shader-side itself. The lastest Doom title (DOOM Eternal) also seems use it in the almost same way, see https://simoncoenen.com/blog/programming/graphics/DoomEternalStudy#bindless-resources .

Shadi Jiha

Greate video. would love a deep dive into the Assets system and Distribution system 🙏

Nanna

I also really enjoyed the video! I like the relaxed format, it’s more like an interesting conversation than a tutorial but still conveys lots of knowledge. I think this format is a very nice complement to the more focused YouTube videos 👍

Ivan Yanakiev

Thank you for the content and the game engine series it has been amazing. I was actually currently implementing a uniform buffer system. Since I am not that familiar with game engine programming I am currently basing my engine on OpenGL, although I am first compiling to SPIR-V and then to OpenGL, then reflecting on the binary. I agree that sets are very useful but I also feel like you can get away with bindings only. In my shaders I mainly seperate the layouts into 2 types, Engine types and Shader types (store specific material information like maps) . I then have 1 uniform buffer across the whole engine for 1 Engine Type and I have 1 buffer per shader type per shader. When I draw lets say a frame you need to bind the proper engine type of buffer to the proper binding only once and then for each material bind its types also once. So if I have 1000 meshes I will set the engine buffer ones and then bind and send data to the material 1000 times if the data is different which it can be, for example 1000 normal maps. I haven't implemented it yet but I feel like you can simulate the sets like that. Grouping data into dufferent layouts and then updating the layouts either per material type, shader type, or only ones for the ones that are used per frame (or lets say per renderpass since I know you use these, I haven't gotten around to implementing it yet). Once again very nice video!!

Tesla Coil

I liked the video, but I would prefer more Vulkan focused talks since we are talking about the Renderer, and how/why did you come up with the solutions :) for example I'm very interested in the DescriptorSetManager and how are you binding them inside the command buffers for rendering. Also I'm very interested on how you compile shaders now, and how can you include shaders in other shaders. Thank you!