GPULightmapper: better algorithm to generate rays for indirect lighting

[williamd67]

Previous algorithm used an algorithm to generate rays that was not completely
random. This caused artifacts when large lighmap textures were used.

The new algorithm creates better rays and by that prevents artifacts.

This fixes #53770. Without denoising and limited quality there is more noise, yet with denoising the quality is better than before.

[akien-mga]

FYI, you authored the commit with your $dayjob identity (see email in https://patch-diff.githubusercontent.com/raw/godotengine/godot/pull/54919.patch). If this wasn't intended, you can change it with git commit --amend --reset-author after editing your identity settings for the Godot repo.

[williamd67]

Thanks I fixed it. I did something incorrectly so I had to force-push it twice 😞.

[jcostello]

I can confirm that this fix the issue on #53770.

[clayjohn]

Is it worth also replacing the other places vogel_hemisphere is used with hemisphere_ray_direction? We probably should if we can. At the very least quick_hash should be removed entirely.

[williamd67]

Good point. I checked the usage of vogel_hemisphere and it seems to be used in the same way as for indirect lighting. I am not familiar yet with the implementation of probes, still I think that replacing vogel_hemisphere with the new algorithm is an improvement.

I removed vogel_hemisphere and quick_hash.

[JFonS]

I was going over the code and I noticed we are not taking into account the angle between the sample ray directions and the surface normal when integrating the incoming light.

This bit here:

godot/modules/lightmapper_rd/lm_compute.glsl

Line 443 in 7791599

light_average += light;

should be changed to light_average += light * dot(ray_dir, normal);, assuming both vectors are normalized and in the same hemisphere.

Another option would be to do importance sampling and, instead of adding the previously mentioned factor, use a cosine weighted sample distribution. That should give the same results and reduce noise, especially at higher sample counts.

In any case, it would be good to go over the current implementation and check that the incident angle factor is accounted for in all cases, either explicitly or by using a cosine weigthed distribution. The only exception I can think of ar light probes, which don't have a surface normal and simply store the amount of light reaching them, the scene shader will take care of the rest.

[williamd67]

@JFonS Good point and I verified it. As far as I understand, does the function hemisphere_ray_direction already generate cosine weighted directions. See per example slide 47 of this presentation or slide 41 of this presentation.

I will add a comment that this function generates 'cosine weighted directions' or maybe better I will change the name of the function. I renamed it to generate_hemisphere_cosine_weighted_direction.

For direct light the incident factor is part of the attenuation calculation.

[JFonS]

@williamd67 right, I was looking at the current implementation and not your PR for some reason. The new implementation looks good, yeah :)

My last nitpick has to do with lightprobes. They are only proxies that will relay the stored light to a real surface, so they only need to know about how much light reaches them. There is no incidence factor so the sampling distribution should be uniform.

[williamd67]

@JFonS I introduced a second function generate_hemisphere_uniform_direction which is used for lightprobes.

[JFonS]

Looks great, thanks!