h2. Bug description

Our current implementation of SSGI (either Ray traced or ray marched) doesn't match the HDRP Path Tracer neither the standard HDRP (no GI) when simply drawing a sphere lit by an environment map.

See the screenshots below provided by [~cyril] 

!Repro.png|thumbnail!
h2. Bug explanation

When using Raytracing, either for SSGI or Reflections we have 3 different code paths depending on whether we choose Ray-marching, ray tracing performance or ray tracing quality.

See the table below in the proposed solution

The problem is that when using ray marching or ray tracing performance we shoot only one ray, the ray direction is based on the BRDF sampling, there is no importance sampling of the sky (note that the Path tracer has it), if you combine that with an HDRI that leads to a noisy image, see the image below.

!image-2023-06-05-17-27-05-733.png|width=408,height=326!

When we add denoising on top we get a dimmer results than what the reference is (either no GI or the path tracer).

In addition to the noise issue, we also have a clamping parameter that can dim the result even more!
h2. Proposed solution

For the Ray marching solution I propose that we replace the skyTexture fetch with an ambient probe fetch, as we launch only one ray this won't cause any problem, and solves our issue for ray miss.

Ray marching before(left) and after(right) the fix.

!ray marching before the fix-1.png|thumbnail! !ray marching after the fix.png|thumbnail!

For Ray tracing performance, one solution would to fetch the ambient probe like we did for ray marching but unfortunately the fetch for ray miss is done in _RaytracingDeferred.compute_ and this code is shared for both SSGI and SSR. Fetch the ambient probe for SSR would break it since we will loose the sharp lighting we might get with a highly specular brdf.

*I'll left the fix of Ray tracing performance for a followup bugfix, hopefully we can find a way in _RaytracingDeferred.compute_ if the ray originated from SSGI or SSR.*

Finally our last case, Ray tracing quality can actually achieve the same result as the reference if:
* The clamping value is high and
* the sample count is high

I've notice that our max clamping value (10) can be to low with some IBLs and {*}we might wanna change the UI to solve this issue{*}, I'll let [~remi.chapelain]  decide on that. See for instance the images below left no clamping (by tweaking the shader code) right clamping of 10 (our current max value)

!rt quality no clamp.png|thumbnail! !rt quality clamp 10.png|thumbnail!

Furthermore, we could also add Environment Importance sampling and MIS to the ray tracer, just like the Path tracer does to converge faster when using an IBL with high frequency lighting, but this is out of the scope of a bugfix.

 
| |SSGI|SSGI|SSGI|SSR|SSR|SSR|
| |Ray marching|Ray tracing|Ray tracing|Ray marching|Ray tracing|Ray tracing|
| | |Perf|Quality| |Perf|Quality|
|Sample count|1|1|1-32|1|1|1-32|
|Shader|ScreenSpaceGlobalIllumination.compute|RaytracingDeferred.compute|RayTracingIndirectDiffuse.hlsl|???|RaytracingDeferred.compute|RaytracingReflections.raytrace|
| | | | | | | |
| | | | | | | |
|Sky miss, Before the fix|_SkyTexture(rayDir)|_SkyTexture(rayDir)|_SkyTexture(rayDir)|???|_SkyTexture(rayDir)|_SkyTexture(rayDir)|
|Sky miss, after the fix|AmbientProbe(normal)|Cannot fix with ambient probe otherwise that would break SSR|Already works, just need to increase sample count and clamping value|Did not change, already worked|Did not change, already worked|Did not change, already worked|
h2.