C++ Game Engine (Vulkan) - Raytracing demo

__Huge wall of text incoming__ So, i was having a bit of an existencial crisis as to where to go with the game engine in the future. For one, while I absolutely love working on engines the primary goal is still to create and release games. And creating engines takes a LONG time. One of the issues that came up was lighting. Most important systems are in place (with the exception of a 3D editor) but one of the most crucial ones that was still missing is a proper lighting system in the renderer (like global illumination.) The issue here still is that most modern lighting techniques still are rather complex to implement and have various tradeoffs on top of it. (For example, prebaked diffuse global illumination with spherical harmonics requires you to prebake the probes and distribute them effectively around the scene. Doesn't work well with open world games with dynamic objects and there is still the whole specular aspect of materials that wasn't addressed.) The other point is that there are other engines that already exist that handle traditional lighting techniques. So while reimplementing similar techniques is a nice learning excercise, i'm still asking myself "what really differentiates my engine from the others? What's the point of developing this in the long run?" So i made 2 decisions (one which was already made a long time ago) The major engine features will be 1) a multithreaded ECS with a multithreaded renderer which allows the game to scale its workload across all available cores while retaining a somewhat accessible programming interface (as best as possible). This feature was already in the works for months and is in a pretty good state in the current engine iteration. 2) use of hardware raytracing to enable next-generation lighting features and support dynamic scenes (as efficiently as possible). Now that doesn't mean that everything has to be raytraced (and/or even pathtraced). There is still an argument that GI can be prebaked if nessecary/possible but the advantage is that this can be done rather fast & efficiently ingame at runtime thanks to hardware RT support. RT allows me as the developer to circumvent a lot of complicated lighting workarounds in traditional rasterization so the development time can be reduced while still retaining the advantages of raytraced lighting. The cost of course is performance but this can also be somewhat mitigated by using denoising techniques. GPUs will also get faster and more efficient over the years which will help with keeping performance up. Sooner or later all game engines will push more and more into the RT territory. I might as well start now instead of playing catchup all the time. I have implemented only very basic RT techniques. Denoising is still missing. So the RT cost is a bit heavier than nessecary. (But it still runs fine performance wise.) I had a very basic temporal denoiser working before but the issue here was that i wasn't able to remove temporal lag entirely. The objects in the scene move quite fast so you often had a smearing effect on shadows/AO effect from moving object. Have to do more research on that how this could be mitigated. This demo was running on a Nvidia 3070 mobile GPU at 1080p and 60fps. One advantage here is that the low poly artstyle helps in keeping the performance up as less polygons = less ray/triangle intersection tests and the memory footprint of the BVH acceleration structure can be kept low and (potentially) making the cache happier. With regards to multithreading: Every aircraft instance and every 3d cloud mesh you see in the scene is a single seperate drawcall. (There is no instancing techniques used here! Not even occlusion culling.) In a regular renderer this would be a massive CPU bottleneck due to the huge amound of draw-calls but my implementation can distribute the command buffer recording across multiple cpu cores so the CPU can keep up with the workload. It's still inefficient for the GPU to process this so this needs to be reworked, it just shows what a huge difference Vulkan multithreading can make compared to singlethreaded APIs like OpenGL on the CPU side. I'll update you all on this where it goes. What you see here is potentially the first stage of a prototype that might make it to a full game. Still have stuff to figure out but progress is being made. The engine might be open sourced in the future. As of right now the code is a bit messy and needs cleanup (also architecture wise i'm still doing a lot of reworks which result in breaking changes between engine version). But hey, at least i finally have a somewhat working build system based on Cmake. Music: Electronic Breakbeat Ambient - by MUSICVAMONE https://audiojungle.net/item/electronic-breakbeat-ambient/21816497