To me the mapping between probe/surfel and actual surface is still the final open problem, and i fail to come up with an efficient solution.
If you place them arbitrarily, you have to search for the probes affecting a pixel, which is expensive. That's one reason a probe volume like DDGI is very simple and attractive, because this lookup is easy and constant time.
For Epic, using the cards, it's already more complex. To update the probes, they can precompute a best fit point on the surface and trace from there.
But the other way around (shading G buffer) is difficult. They could project from surface along normal to the card and then do a 'texture fetch' to interpolate probes. But this handles only per object box, so would not resolve the seams we see in debug view. To handle multiple boxes, they would need to lookup a global spatial data structure and iterate all found cards. Doing this per pixel has some cost.
Another option would be to render the debug view and filter some kernel around the shaded pixel. But this has cost too, and would miss the angular information to support surface direction, so they would need to render the debug view to something like an SH framebuffer, which is fat then so even more costly. IDK what they do - worth to take a look...
My own plan here initially was to have an UV channel on the surface to address a texture of probes, just like lightmaps. And to prevent seams i worked on quadrangulation of the geometry to generate seamless UVs. That's difficult already, and if we add LOD to the mix, the LOD mechanism has to match the probe hierarchy. It also has to support reduction of topological complexity, e.g. closing small holes if we see the object from larger distance. All this is possible and makes sense, but requires remeshing of the models, resulting in loss of geometrical accuracy and detail. It's also not practical for diffuse geometry like foliage.
So, i think i can use this system only for most opaque stuff (terrain, solid walls of buildings, etc.), but not for detailed, human made geometry (a fence, chairs, detailed furniture...) or foliage.
Thus, i need something more general as well. The obvious solution is to traverse my BVH of surfels for each shaded pixel, but i think this would be more costly than the entire algorithm to compute GI. It's not as expensive as ray tracing, but still a range query on a tree.
To do better, i can make tiles of the Z buffer, calculate bounding box, and do one traversal per tile. That's still very expensive, but likely fast enough. Downside: It's not compatible with RT. Grouping ray hits spatially just to support such shared traversal algorithm does not make much sense, so i can't avoid to do a traversal per hit just to find the already computed GI probes.
Binning all probes into a regular volume grid each frame also seems too expensive.
So, i can sing a song about the difficulties with surface probes. This 'simple' mapping problem seems negligible at first, but it is the main reason i'm years late to make my stuff 'ready for production'. Any ideas welcome!