Godot Garden, A Ground Truth Lighting Reference

[WickedInsignia]

Godot version

4.0 Alpha 12

System information

Windows 10, GTX1080, i7 6700

Issue description

Upon request from @clayjohn , I've constructed a scene designed to test Godot 4's lighting tech in a ground-truth comparison (in this case, against Blender's Cycles raytracer).
An identical scene has been constructed across both Blender and Godot, with lighting properties and values matching as closely as I could manage. There is a variety of objects, materials and surfaces to test Godot's lighting in different scenarios.

All assets used are CC0, and everything is included in the files. This world is intended for demo/testing purposes but you're permitted to do whatever you want with it. If Blender cannot find the textures, simply select File > External Data > Find Missing Files, and navigate to the extracted folder the Blender file is contained in. If you have any issues with the files, don't hesitate to contact me here or via my Twitter (https://twitter.com/wickedinsignia).

Download the Blender project HERE.
Download the Godot project HERE.

Asset credits:
Detailed PBR props are sourced from Polyhaven and all tiling textures are from AmbientCG/Polyhaven.

I made a few quick comparisons to highlight some shortcomings in Godot's realtime GI solutions, so it felt appropriate to post this in Bug Reports. If this resource would be more appropriate elsewhere please let me know!
All screenshots are taken with the settings default to the provided files, which were designed specifically not to stray far from Blender and Godot's default lighting values. All VoxelGI examples have "Two Bounces" active.

Voxel GI lacks sky contribution:

SDFGI seems to be sufficiently realistic in the way that it treats sky indirect contribution, but VoxelGI is comparatively a lot warmer. Bounced light from objects seems to propagate in the space more severely and overpower the sky's contribution, but this issue seems to be mostly unique to the "Two Bounces" setting.

SDFGI exhibits strong light occlusion in inappropriate areas:

SDFGI will sometimes produce very strong blacks or shadowed areas in places that don't warrant them. This seems to be due to probes that are present inside of objects. The square base used here is non-manifold (bottom face is missing), which may be the cause for this particular example but these dark areas occur even in perfectly manifold intersections or even standalone objects. This issue is emphasized with a higher Min Cell Size, and can be mitigated somewhat with Probe Bias.

Voxel GI produces strange highlights on highly reflective metals:

The "water" object in these scenes is a simple plane with 1 metallic and 0 roughness. Voxel GI creates superbright areas in the sunlit area of this object regardless of viewing angle.

SDFGI produces noisy results on large featureless surfaces:

GI results from SDFGI produce noticeable spotty variations on large broad simple surfaces, not unlike sampling noise from a raytracer. This is experienced primarily at higher settings, and can be mitigated with a higher Min Cell Size. Very noticeable on non-textural surfaces.

SDFGI reflection light leaks:

The Water object receives light reflections near the base of this large structure, even though it is well-extended into the water object, both objects are manifold and both are considerably thick.

SDFGI coarse normal maps:

SDFGI sometimes sends very strong direction information to surrounding normal maps, which seem to be the result of occluded probes.

Steps to reproduce

Please feel free to check out both files and mess around!

Minimal reproduction project

Attached in description.

[reduz]

Incredible job! I need to give a second pass to SDFGI to fix a couple of problems (many I think are very well exposed here already) and optimize it, so having this scene is an excellent resource for me.

[WickedInsignia]

@reduz Thanks!! I’m so glad it will help. I can’t take all the credit for assets, so I’ve added where I sourced the assets in the description. They are all definitely CC0 though so no worries there.

I intend to do plenty more testing, and will release what resources I can where possible for the team to access. If there’s a repository that might be better to place sample scenes like this, let me know!

[fire]

I propose we add a top-level github repo at godot engine github so that this rendering test has space to grow.

[TokisanGames]

Great work @WickedInsignia ! Overall the lighting in GD4 is so much better than GD3. Kudos @reduz .

Should the Voxel GI on highly reflective surfaces have a reflection probe? I didn't look at the files. It seems there's a low-quality reflection in the window, but complete opaqueness on the water.

[Calinou]

Related to godotengine/godot-proposals#3013, godotengine/godot-proposals#4811 and godotengine/godot-proposals#4812.

GI results from SDFGI produce noticeable spotty variations on large broad simple surfaces, not unlike sampling noise from a raytracer. This is experienced primarily at higher settings, and can be mitigated with a higher Min Cell Size. Very noticeable on non-textural surfaces.

Increasing SDFGI Probe Ray Count in the Project Settings should make the noise less noticeable, but this has a significant performance cost. Hopefully, when TAA is enabled, we can jitter the samples to give the impression of higher quality without increasing the performance cost of SDFGI. #50796 could also help here, but it's only usable in certain scenarios when the camera doesn't move fast.

[WickedInsignia]

Should the Voxel GI on highly reflective surfaces have a reflection probe? I didn't look at the files. It seems there's a low-quality reflection in the window, but complete opaqueness on the water.

I deliberately don't have any reflection probes in the scene to test VoxelGI/SDFGI's reflection capabilities. That "water" object (basically an opaque mirror) is more of a stress test, you wouldn't really use a fully reflective material with either technique since the reflections aren't accurate enough. Voxel GI performs very strangely with that surface for some reason, so it's having the intended effect as a test scene!

[fire]

This is a good test case for the failure to bake lightmaps.

[MisfitVillage]

This sample scene looks great for testing outdoors lighting, great job! I can confirm most of your findings (VoxelGI being brighter than SDFGI, black splotches on objects with SDFGI and so on).
There is one bug you cannot test with this level layout, though. I would propose adding a simple "L" shaped interior room with an open entrance on one of the buildings so you can test how Godot handles a mix of interior lighting and outdoors lighting with SDFGI and VoxelGI. From my testing that's where things start to fall apart with VoxelGI. Here's my test scene with very thick walls. Notice the interior in the middle is brighter than some of the outdoors parts, even though it should be basically completely black. Mixing SDFGI (outdoors) and VoxelGI (interiors) would be great if not for this problem.

[WickedInsignia]

Tested the scene recently in Beta 8 to check compatibility.
It works just fine, but on first load-up the normals seemed pretty strange.
If this occurs, simply reimport all textures in the various folders (you can select multiple at once) and reload MainScene.

@MisfitVillage How thick is that floor plane? I had to thicken the floor plane on mine so that light didn't bleed through. I found that otherwise VoxelGI worked as expected in regards to light bleed, although it's very finicky to get the right thickness on thinner walls.

[MisfitVillage]

@WickedInsignia It's about 100 meters thick :)

[WickedInsignia]

@MisfitVillage After playing with VoxelGI for a while I realized that's just the way it approximates skylight.
It doesn't properly occlude skylight at higher subdiv levels since the sky is treated as an ambient effect, and therefore interiors will be too bright. VoxelGI's "bounces" only travel so far and their distance is heavily reduced at higher subdiv levels, so a "sweet spot" between occlusion and quality needs to be struck in most cases.

Subdiv 64:

Subdiv 512. Ignore the strange caustic effects on the left wall, that's caused by a normal map issue: