Extend the reflection probe system to use a raytraced equirectangular texture array

[myaaaaaaaaa]

Describe the problem or limitation you are having in your project

The current reflection probe system rasterizes the scene 6 times per probe, requiring time slicing in order to reduce the compute requirements of using them.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Raytracing allows every single reflection probe to be rendered in a single draw call.

This may or may not improve performance.¹

It would however enable the option to use a larger number of probes, as long as their resolution is limited. For games that only have rough materials, this may be all that's needed.

It may be possible to absorb the functionality of GIProbes this way, although the reflection probe atlas will need to be double buffered.

Like with #6033, the primary motivation for this proposal is to find ways to implement raytracing in a way that can be immediately beneficial to more users. I think techniques like these that raytrace to intermediate textures should be prioritized, since they can scale down to integrated GPUs, unlike the fullscreen resolution raytraced render passes which tend to get more press coverage.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Automatically using raytracing to render reflection probes on supported hardware would be the simplest way to get most of the benefits.

There's also an opportunity to go the extra mile and adopt an equirectangular texture array when raytracing, to simplify calculations. This would condense six cubemaps per probe down to a single equirectangular texture per probe.

However, this would require codepaths for both cubemap and equirectangular arrays to be maintained, since rasterization doesn't support equirectangular projections. I don't know if the added complexity is worth it.

If this enhancement will not be used often, can it be worked around with a few lines of script?

The current reflection probe system is still perfectly usable. It may or may not perform better depending on the situation.²

Is there a reason why this should be core and not an add-on in the asset library?

It's probably easier to update the reflection probe system than to refactor it all out.

Footnotes

1. Theoretically, this would move the fixed function workload to raytracing units that would otherwise be left idle, and free up the rasterization units to handle the main render pass. On top of that, rasterization has overhead per view in the form of z-sorting, wasted out-of-bounds triangles, occlusion buffers, and draw calls, which quickly adds up when rendering 6 views per probe. There's a crossover point where after a certain number of views, the overhead of rasterization would be high enough that it would be faster to just raytrace them, even assuming a hypothetical world where both workloads are handled by the same "generic GPU units". I don't know if we're already at that point after 6 views, though... ↩

2. More likely when the number of probes is smaller, when each cubemap has higher resolution, and when the scene has less triangles. ↩