Inquiry on Just a Deferred Rendering Implementation Without Ray Tracing or DDGI power by Atlas-Engine.

[luciddream-tsin]

Dear Simon,

I am reaching out to ensure that my previous email reached you.

I've decided to create a new issue here so that others may also benefit from the discussion of this topic.

Thank you for your attention, and I look forward to your guidance.

[tippesi]

Hello,

thank you for your interest in this project. I felt free to move this issue into a discussions thread.

Regarding your question:
The MainRenderer in combination with the RenderTarget uses deferred rendering, although as you have seen with support for ray-traced effects. Ray tracing in this framework requires a manual opt-in and just works for meshes where the BVH was built and for scenes where BuildRTStructures() was called. Each effect on its own can be turned off and with all ray-traced effects disabled, you will just have a rasterized deferred renderer remaining (you can play around with all of this in the demo which you can download here. The main renderer currently just supports directional lights, but I plan to extend it in the future with other light types, like point lights using a more modern approach like deferred clustered rendering. If you want to have deferred rendering with more light types right now, you have two options:

1. You could extend the MainRenderer, more specifically the DirectLightRenderer to also support other light types. There was support for point lights, but back then the framework still used rasterized proxy geometry to achieve deferred lighting.
2. You could start writing your own renderer from scratch. This is not as hard as it sounds and you could use the ExampleRenderer as a point of reference. The advantage of this approach is, that you don't need to rely on the frameworks scene system, which is still lacking and will get an upgrade to an ECS soon.

I hope this helps. If you have any further questions or suggestions for improvement, please feel free to ask them here.

[luciddream-tsin]

Hi, Simon,
I have some confusion about the clip matrix in Camera::UpdateProjection(),

        const mat4 clip = mat4(1.0f, 0.0f, 0.0f, 0.0f,
                               0.0f, -1.0f, 0.0f, 0.0f,
                               0.0f, 0.0f, 0.5f, 0.0f,
                               0.0f, 0.0f, 0.5f, 1.0f);

clip * (x, y, z, w) ==> (x, -y, 0.5*z, w + 0.5*z)
My question is why we need to change z and w, thanks again!

[tippesi]

Hi,

The definition that you see here defines one column per row of code (the transpose of what you expected, I know, a bit confusing), meaning you get the following vector as a result:
(x, -y, 0.5*z + 0.5*w, w). This is needed due to the glm library using the same clip-space as defined by OpenGL, which the clip matrix corrects such that the projection matrix can be used in Vulkan.
You can read this up in the following article: https://matthewwellings.com/blog/the-new-vulkan-coordinate-system/. Hope that helps