Upgrade SDFGI to HDDAGI

[reduz]

Supersedes #86007

This is a new global illumination system that is a full upgrade to SDFGI Key advantages are:

• Significantly faster base frame time.
• An order of magnitude faster updates (SDFGI drops frames very significantly when moving, as a consequence of having to redo its entire SDF even for a small motion).
• Higher quality (less light leaks, properly energy conservation, much better reflections, others)
• Occlusion remains the same as in SDFGI. I experimented with other systems (the one in DDGI) but everything has worse tradeoffs.

It is meant as a drop-in replacement, so games using SDFGI should get HDDAGI transparently.

TODO:

• For some reason gets DEVICE LOST on Intel GPUs. Can´t figure out why.
• Waiting for a PR fixing the normal buffer precision in order to fix some issues. Use best fit normals for storing screen space normals #86316
• Volumetric fog GI injection appears broken.

TODO AFTER MERGING:

• High density probes support.
• Dynamic objects support.

Improvement Screenshots

Motion performance:

By far the biggest improvement is the performance when moving the camera. This is what makes SDFGI unusable on lower end hardware and can even push down the FPS very strongly on higher end hardware. This is because SDFGI needs to regenerate the entire SDF cascade using a jump flood even if it moved just a bit. HDDAGI uses HDDA so it only does local updates to the cascade and no scrolling.

Here is what happens in SDFGI when the camera moves fast:

sdfgi_motion.mp4

As you can see FPS take a large dip. This really sucks for any kind of games where the camera moves fast, like a racing game, a fast shooter, etc.

In comparison, HDDAGI is unaffected by camera motion:

hddagi_motion.mp4

Static performance:

When rendering static (camera not moving) HDDAGI is also considerably faster than SDFGI:

This is SDFGI, the first set of dispatches is the light update, the second is the probe raytracing. On a Geforce 1650 it takes 2.43ms:

In HDDAGI, the same task takes 0.93ms. While not a great difference on a 1650, this makes a much larger difference on IGP:

Quality of Indirect Light

SDFGI does not properly do light conservation, while HDDAGI does. Here is comparison screens by @Jamsers:

SDFGI: Notice light is more uneven in general, and there are some color issues due to the use of spherical harmonics.

HDDAGI: Notice light is better, more evenly distributed:

Quality of reflections

SDFGI uses a very hacky way to obtain light from the SDF that result in very strange lighting from the reflections, plus the SDF gives it a very weird look (this is what you see in the reflections):

In contrast, HDDAGI filters voxels properly, so what is seen in reflections is more faithful to the actual geometry:

What is being reflected:

Here you can see in a more realistic scenario how close the reflections are to the actual geometry (note tonemapping is different in the reflection as this is a debug mode):

In motion

SDFGI suffers from jumping dark spots when lights or camera move. HDDAGI has a special probe filtering option (enabled by default) that gets rid of them.

SDFGI (notice the jumping dark spots):

filter_probes_light_off.mp4

HDDAGI (notice the general smoothness):

filter_probes_light_on.mp4

SDFGI (with a proper scene, note jumping dark spots on the tunnel

filter_probes_off.mp4

HDDAGI with filter probes:

filter_probes_on.mp4

Production edit: closes godotengine/godot-roadmap#32, closes #41154, closes godotengine/godot-proposals#3024

[Saul2022]

Pretty good job, performance increased when moving , and this time decided to use the default cell size , because as you said i exaggerated with that 1cm. It seem´s pretty good though the problem is still gi colliding with the geometry for me, in comparison this is with an empty scene.

Vídeo sin título - Screen Recording - 17_12_2023, 22_17_50.webm
Vídeo sin título - Screen Recording - 17_12_2023, 22_20_37.webm

Vídeo sin título - Screen Recording - 17_12_2023, 22_24_17.webm
Vídeo sin título - Screen Recording - 17_12_2023, 22_28_04.webm

[Calinou]

16×8×16 should be before 16×16×16 as it's faster (and lower quality), to match other Godot enums.

While this means the default current value of SDFGI_Y_SCALE_75_PERCENT (1) will map to DYNAMIC_CASCADE_GI_FORMAT_16x16x16, this isn't really an issue in practice because Godot doesn't save default values to scene/resource files. This means that if you were previously using the default value, you can be using the new default value even if it has to be 0 instead of 1. This is the same approach followed in #75468.

[Calinou]

Based on my testing, lower values run slower but provide lower latency, so the hint should be clarified:

Suggested change

	GLOBAL_DEF(PropertyInfo(Variant::INT, "rendering/global_illumination/hddagi/frames_to_update_lights", PROPERTY_HINT_ENUM, "1 (Faster),2,4,8,16 (Slower)"), 2);
	GLOBAL_DEF(PropertyInfo(Variant::INT, "rendering/global_illumination/hddagi/frames_to_update_lights", PROPERTY_HINT_ENUM, "1 (Less Latency but Slower),2,4,8,16 (More Latency but Faster)"), 2);

[Calinou]

Based on my testing, lower values run slower but provide lower latency, so the hint should be clarified:

Suggested change

	GLOBAL_DEF(PropertyInfo(Variant::INT, "rendering/global_illumination/hddagi/frames_to_update_inactive_probes", PROPERTY_HINT_ENUM, "1 (Faster),2,4,8,16 (Slower)"), 3);
	GLOBAL_DEF(PropertyInfo(Variant::INT, "rendering/global_illumination/hddagi/frames_to_update_inactive_probes", PROPERTY_HINT_ENUM, "1 (Less Latency but Slower),2,4,8,16 (More Latency but Faster)"), 3);

[Calinou]

Streaks aligned with the X axis are visible when volumetric fog is enabled and GI Inject is greater than 0.0, even if no lights are visible in the scene:

simplescreenrecorder-2023-12-18_00.04.08.mp4

Minimal reproduction project: test_hddagi_volumetric_fog.zip

[WickedInsignia]

The new Occlusion Bias setting helps solve some of the dark artifacting mentioned in the previous thread. I feel that the splotchiness of SDFGI is almost completely reduced and not an issue anymore as well.
Here are the existing problems in my tests:

• Cascade shifting is far too noticeable. Default cascade 0 distance needs to be pushed back 3-4x more to prevent sudden shifts in GI as players move through the world, without reducing probe density so accuracy is not sacrificed (which causes a range of other issues).
• Reflection jitter issue mentioned in the last thread.
• Overdarkening is still a problem. Some areas go completely black when they should be receiving at least a little light. Normal maps on terrain and organic objects (rocks etc.) suffer especially badly, with extremely dark patches making some materials feel semi-metallic.
• Spherical or curved forms (especially when overlapping with other geo) are still full of artifacts. The situation is improved, but sometimes it is impossible to find a sweet spot between bias settings that doesn't screw up other areas of the environment.
• SSIL can help resolve artifacts but is far too smeary and noisy to be reliable at this point.

As mentioned in the previous thread, the ability for users to author probe positions manually in a domain (similar to Unity's Adaptive Probe Volumes or its aging Light Probes system) would allow artists to resolve most of these issues manually, and most users probably aren't making environments large enough or procedural enough to warrant a cascading solution (nor can Godot handle large streaming worlds). The option for both would be welcome.

I'm aware there are solutions in the works for these issues, just putting them here to keep record.

[Jamsers]

Cascade shifting is far too noticeable. Default cascade 0 distance needs to be pushed back 3-4x more to prevent sudden shifts in GI as players move through the world, without reducing probe density so accuracy is not sacrificed (which causes a range of other issues).

An even better solution is allowing users to set Cell Size and Cascade Distance independently, for each cascade - performance be damned. Hide it behind an advanced toggle or something if you must, but it always irked me that we never had full control over SDFGI cascades. The default, unchangeable ratios are horrendously crawly, no stability whatsoever, and make cascade 0 so close on smaller cell sizes that it becomes irrelevant for the majority of the scene.

But I suppose this merits a separate proposal.

[reduz]

@WickedInsignia

Cascade shifting is far too noticeable. Default cascade 0 distance needs to be pushed back 3-4x more to prevent sudden shifts in GI as players move through the world, without reducing probe density so accuracy is not sacrificed (which causes a range of other issues).

This is mostly why I want to implement the high density probes option. The main problem right now is that, on small indoors, the GI runs out of probes at a certain distance and hence it stops receiving lighting. Or, sometimes, all 4 probes are occluded at that position. With high density that problem should mostly resolve, but it is independent to this PR, which aims to replace SDFGI first.

Reflection jitter issue mentioned in the last thread.

This is dependent on work Clay is doing to fix the normal buffer resolution. I can't merge this PR until that one is done.

Overdarkening is still a problem. Some areas go completely black when they should be receiving at least a little light. Normal maps on terrain and organic objects (rocks etc.) suffer especially badly, with extremely dark patches making some materials feel semi-metallic.
Spherical or curved forms (especially when overlapping with other geo) are still full of artifacts. The situation is improved, but sometimes it is impossible to find a sweet spot between bias settings that doesn't screw up other areas of the environment.

Thats kind of the same and this is the main problem with DDGI and these types of probe based GI. I am hoping the situation improves with the high density probes option.

SSIL can help resolve artifacts but is far too smeary and noisy to be reliable at this point.

My plan is to have both high density probes and also a screen space part . SSIL is not designed for this kind of GI, so I need to write a proper screen space tracing that traces the distances smaller than a single probe. With that all pixels should get proper lighting.

But then again, the plan with this PR is to supersede SDFGI, since It's pretty large and difficult to keep up to date as-is. Take it as foundation work, then I will work on the other stuff I mentioned.

[reduz]

@Jamsers

An even better solution is allowing users to set Cell Size and Cascade Distance independently, for each cascade - performance be damned. Hide it behind an advanced toggle or something if you must, but it always irked me that we never had full control over SDFGI cascades.

The problem is the density, not the distance. Cascades are always 16x16 regions, so customizing different cell size or cascade distance will always bite you one way or the other. This is why my plan to work on the high density probes.

[Jamsers]

The problem is the density, not the distance. Cascades are always 16x16 regions

Yes, and my idea was being able to set arbitrary probe densities by changing Cell Size and Cascade Distance independently - i.e. if you want more probe density in cascade 0, you keep Cascade Distance at the default 12.8, but set Cell Size smaller. Is the 16x16 region limitation something that can't be changed/solved?

[reduz]

@Jamsers that is unfortunately not possible because cascades use a ton of memory and more density scales them exponentially and make them unusable pretty quick. This is why I need a special, separate, technique to increase the density without affecting memory so much.

[Saul2022]

Vídeo sin título - Screen Recording - 17_12_2023, 22_17_50.webm Vídeo sin título - Screen Recording - 17_12_2023, 22_20_37.webm

Vídeo sin título - Screen Recording - 17_12_2023, 22_24_17.webm Vídeo sin título - Screen Recording - 17_12_2023, 22_28_04.webm

After trying I would say it in a pretty good state( literally it has more or less fps than volumetric fog in a empty scene. Also,if i decrease cascades to 1 and put the light update to 16 it might be at the same vfog level of fps in a small scene with cubes). All pretty good, now the issue is with scenes like sponza where even if geometry is simple i still find that huge fps drops( motion is not the one having the fault here as it happens statically too) when using the meshes, like the bigger, the more hddagi consumes from it. look the difference with my above videos and the images below.

Can this be sorted out ,or the only way would be with the cascade sething, because if simple scenes is like this, not sure of big ones. although maybe the issue is just my igpu(radeon vega 3), as it not as good.

[reduz]

@Saul2022 just so you understand better the dependency on geometry. HDDAGI performance does of course depend on the amount of geometry in the level, what it does not depend is on the geometry complexity. This means if a scene with 1 million polygons occupies the same physical space as a scene with 1500 polygons, it is pretty much the same for HDDAGI.

[Saul2022]

This means if a scene with 1 million polygons occupies the same physical space as a scene with 1500 polygons, it is pretty much the same for HDDAGI.

Alright, thank you for clearing it out.

[Calinou]

This still seems to be the case as of the latest revision of this PR, so I suggest documenting it:

Suggested change

	How much light bounces back to the probes. This increases the amount of indirect light received on surfaces.
	How much light bounces back to the probes. This increases the amount of indirect light received on surfaces.
	[b]Note:[/b] Values higher than [code]1.0[/code] may result in infinite feedback loops with bright surfaces. This can cause GI to appear extremely bright over time.

[Calinou]

Suggested change

	Turns on Dynamic GI. This provides global illumination (indirect light and reflections) for the whole scene. Only static objects contribute to GI while dynamic objects can also recieve it (check whether your object is static, dynamic or disabled with [member GeometryInstance3D.gi_mode].
	If [code]true[/code], dynamic global illumination is enabled for the whole scene (indirect light and reflections). Only static objects contribute to GI while dynamic objects can also receive it (check whether your object is static, dynamic or disabled with [member GeometryInstance3D.gi_mode]).

[Calinou]

Suggested change

	Filter the ambient light, this results in higher quality transitions between the cascades.
	If [code]true[/code], filters the ambient light added by the dynamic GI system. This results in higher quality transitions between the cascades.

[Calinou]

Suggested change

Filter the probes (averaging probes with neighbouring probes) to smooth out the light transitions. This option can be used safely, as occlusion between probes is considered when filtering, but it may also result on lower light frequency.

If [code]true[/code], filters the probes (averaging probes with neighbouring probes) to smooth out indirect light transitions that may appear on surfaces that are mostly indirectly lit. This option can be used without the risk of introducing light leaking, as occlusion between probes is considered when filtering. Enabling probe filtering may result in reduced high-frequency detail in indirect lighting.

[clayjohn]

Alright folks, I know everyone is excited for the improvements that HDDAGI brings, but please keep the conversation on topic. This is a place to discuss technical aspects of the code, not to endlessly discuss how soon this should be merged.

If the off topic conversation continues, we will lock this thread so that only maintainers can comment.

We want to merge HDDAGI as soon as it is finished. It will be finished when Juan finds the time to finish it or when someone else decides the take over the work. Nobody can wave a magic wand to get this merged sooner, even though we are all excited by it.

[a-johnston]

Should this be

Suggested change

	imageStore(geom_normal_bits, igrid_pos, uvec4(imageLoad(geom_normal_bits, igrid_pos).r | (1 << bit_ofs))); //store solid bits
	imageStore(geom_normal_bits, igrid_pos, uvec4(imageLoad(geom_normal_bits, igrid_pos).r | bit_normal)); //store solid bits

It seemed to be the one issue with rebasing to master and getting this running on macos

[RadiantUwU]

RadiantUwU@af0374a
This is the commit that would fix issues with it. (including the crash)

EDIT: a new issue arisen: VoxelGI reflections dont work.

[a-johnston]

RadiantUwU@af0374a This is the commit that would fix issues with it. (including the crash)

What a coincidence I was just doing this exactly. Left a few comments on that commit

EDIT: a new issue arisen: VoxelGI reflections dont work.

I noticed this too testing in the bistro scene nvm the reflections do seem to work still for me

[RadiantUwU]

Rendering bug where GI is getting choppy

VoxelGI only scene.

Before HDDAGI:

After:

[RadiantUwU]

I assume somewhere around here is what makes the GI look choppy.

[a-johnston]

Besides the comments, there's also one Texture RID getting leaked which is potentially related to the texture views but I'm unsure.

Unrelated to the leaked handles I took some reflection focused screenshots to show the stock behavior with various gi/reflection things enabled: https://imgur.com/a/5NqunUw

I think that while the hddagi reflections capture much more detail than sdfgi, it does end up looking extremely blocky and sometimes in weird ways, like with the lamppost which shows up as a jagged tower of dark cubes. I don't think reflection quality should be a blocker, and it's already an improvement, but it does make me curious if some of the other gi approaches could be used to capture anisotropic qualities of solid geometry better than the current voxels.

[a-johnston]

typo, and light_position_bufer isn't getting freed

[a-johnston]

filter_shader_version isn't getting freed

[a-johnston]

ambient, reflection, and reflection_filtered result in ERROR: Attempted to free invalid ID spam when RenderSceneBuffersRD::cleanup processes named_textures. I'm still getting familiar with the code but I'm guessing it has to do with the view being valid but the underlying shared texture being freed already, even though it does check p_named_texture.texture.is_valid()?

[Calinou]

Rendering bug where GI is getting choppy

This occurs because GI is rendered at half resolution by default with this PR, which isn't the case in master where it's an option you need to enable. The setting also affects VoxelGI (its effect can't be toggled separately from HDDAGI as both are rendered to the same buffer).

Try comparing master with Rendering > Global Illumination > GI > Use Half Resolution enabled in the Project Settings.

[RadiantUwU]

This occurs because GI is rendered at half resolution by default with this PR, which isn't the case in master where it's an option you need to enable. The setting also affects VoxelGI (its effect can't be toggled separately from HDDAGI as both are rendered to the same buffer).

I thought this couldnt happen, but i was wrong.

[viksl]

I'm not sure if I understand the max distance correctly but wanted to check with you just to be sure, I tried different values to see what the result is and it seems that at certain larger values it renders less than lower values and higher values don't follow the same pattern?
https://youtu.be/Ui8Pjvak_Kc
In this shot video the layers are labeled accordingly to the max distance, 100 - 300 - 400. Somehow 300 seems to be less than 100. I thought maybe it's the averaging but 400 and beyond goes the other direction and shows more instead?

Apart from that if you don't mind me asking, the darkes part of the shadow is the 0 cascade and there's no way to influence how far that renders, it's a hardcoded limit, is that correct (no setting changed that on my side so I'm just making sure that's how it's supposed to work)?

[RadiantUwU]

I'm not sure if I understand the max distance correctly but wanted to check with you just to be sure, I tried different values to see what the result is and it seems that at certain larger values it renders less than lower values and higher values don't follow the same pattern? https://youtu.be/Ui8Pjvak_Kc In this shot video the layers are labeled accordingly to the max distance, 100 - 300 - 400. Somehow 300 seems to be less than 100. I thought maybe it's the averaging but 400 and beyond goes the other direction and shows more instead?

Apart from that if you don't mind me asking, the darkes part of the shadow is the 0 cascade and there's no way to influence how far that renders, it's a hardcoded limit, is that correct (no setting changed that on my side so I'm just making sure that's how it's supposed to work)?

Cascades is basically LOD amounts, the lower the less LOD amounts, Cascade 0 has the min cell size, and with each cascade the number doubles, same with the distance, till it reaches the max amount

[Jamsers]

Oh, interesting, is it ready as a proposal yet/what deets do we know?

We don't know much, but TLDR of the entire situation is that Juan is basically the only one working on realtime GI in Godot because it's actually a very difficult field and much like physics, you don't actually get any drive by contributors for something so complex. So progress on realtime GI in Godot is dependent on whether Juan has the free time to work on it. (I'm not sure but I think currently he's busy on W4 stuff)

He's apparently thought of an approach that's even better than HDDAGI, and will eventually work on that instead of continuing HDDAGI.

This PR is likely slated to be marked draft and comments closed off, to prevent people asking for progress on something that's meant to be more "it'll be done when it's done". But I'm not a member of the Godot production team so don't quote me on that. 😅

[clayjohn]

Alright folks, as promised, I am locking this thread because it seems to attract too much off-topic discussion.

As a reminder Github is a place where contributors work and we want to keep this a productive space. Coming in here to pester contributors by asking for ETAs, or to discuss unrelated topics is harmful to our ability to get work done.

Improving SDFGI is something that is important to all of us. But it is not a high enough priority that reduz will drop everything else he is working on to finish it. This means the timeline for completing this is uncertain at best and depends on when reduz has time and energy to put towards it.

If someone else wants to take over the work to speed up the timeline, they are welcome to.

But until someone volunteers to take over the work, or reduz finds the to properly finish this, this comment section will remain locked. Please direct your energy towards something more productive.