Screen Space Global Illumination for Eevee

Some option to have higher realtime denoiser/filter samples at a cost of framerate would be hiiiighly appreciated!

It’s currently hardcoded at 5x5. 3x3 (for performance) + control over number of passes could probably give enough control for render sample.

Maybe like an accumulate over time toggle would help to choose between either directly applied sample count at 1 samples in eevee or one that accumulates over multiple eevee samples :smiley:

I need similar flexibility under the hood for better denoising anyway buffer wise (and for multiple bounces). Just need another or two free weekends to figure it out if my assumptions are correct and I can implement buffers the way I imagine. It seems it’s not as complicated as it seemed at first so I might be able to do something slightly more workable than a hack for it.

IIRC RTGI can do multiple rays per pixel (1-20) and seems to resolve noise better, but it’s tracing is more efficient so it doesn’t kill performance that much. I haven’t modified the tracing functions in Eevee, so I’m not sure if there’s any improvements that can be done for diffuse tracing (again, something I need to do anyway for better fallback).

while everyone waits for the eevee rewrite summer next year

I wish I had more free time to spend on this. I’m slowly getting to things that I wanted to tackle last summer.


…good god. Do we even need Cycles anymore?


Quick test with using AO as a weight for denoising to preserve some details (idea from

No actual AO added to image.





Works pretty good, but it highlights some issues with light leaking on edges and noise.


from time import clock worked in Python 3.7, but was removed in Python 3.9.

Looks great! is that basically improving the denoising quality of it? afaik having access to things like normals,depth,ao and bump/normal maps can significantly improve denoiser clarity and quality right? otherwise it would just be blindly filtering/denoising the ssr pass

Looking forward to more experiments of urs! :slight_smile: I see biiiig potential in ssgi native

1 Like

Also glad to see youre looking at potentially different ways of getting samples to be clearer rather than the half cooked TAA implementation in the viewport (viewport denoising)
ive read that eevee rewrite will have TAA with motion vectors which will hopefully improve things but having to entirely rely on jittered ssr samples combined with really aggressive Taa that doesnt even get used for anti aliasing ( managed to simulate sample jitter by very minimally shaking the camera with a noise modifier) will always have very visible temporal issues so seeing you actually implement smart denoising/filtering is a blessing (ESPECIALLY for GI, since thats usually high roughness bounce lighting anyways)

1 Like

Exactly, AO is a good estimate for variance in GI (as AO is approximating the same light behavior as GI) and it’s noise free enough for this purpose. Trying to get an estimate of where the variance is in the GI filter input from the same input you’re trying to blur in the first place gets more complex, but it’s doable (especially if you can do things temporally). The filter without any guides is just a blur functionally. Guides like this just keeps the taps combined for the blurred result, from similar enough areas that it doesn’t wash out all the details where there’s supposed to be (or an estimate of) variance in GI.

Some denoising of glossy/specular for example uses roughness of the glossy material as a guide for filtering and filter intensity, but personally from the results I’ve seen I don’t like the look resulting from that too much.


Hey there! With Blender 3.0 out today, do you plan on updating SSGI to it?
Many thanks in advance!!!


Sure. I don’t have time to figure out all the build errors this weekend, but hopefully I get get everything to work again during the coming week.

New builds should come with AO weights for denoising and a toggle for disabling the new world lighting tracing in 1.15 since there’s still plenty of issues with that.

Win build based on 3.0 release with 1.15b up on drive. Looking into Linux next.


Got it, sounds great!


Can’t wait for the 3.0 version, I really have financial struggles to get an RTX for Cycles :sweat_smile:

1 Like

only SSGI 1.15b + World

with the supporting lights

render with a GTX 980… 15 sec …
and you can optimize the scene much more to achieve a render in less time

Merry christmas


Wut does the probe tracing do? That’s one thing i couldnt figure out


Apologies for quite the delay. Uploaded a Linux build of 1.15b on 3.0 to drive in addition to the Win version.


I’m not 100% sure I got everything to work again, so if you do try out the Linux version I’d appreciate a report if it works or not.

It toggles between the default Eevee World (probe) lighting and with World probe (no local placeable probes yet) injected only into SSGI. Basically it only affects world/hdri lighting and has a lot of unsolved issues in current state (energy conservation, light leaking, no subsurface scattering on world lighting and potentially huge amount of noise on high contrast HDRIs).



It’s mainly extra occlusion for the world (global probe) lighting, since SSAO as the only occlusion for world lighting isn’t enough in a lot of cases.

Great images!

Internally the “injected probe clamp” was at 0.5 before I exposed it in UI and set the new default to 1.0. Lowering it a bit could help with some of the noise denoising can’t get rid of yet.


Hi, and thanks for your linux efforts.

Tried the Linux version and it’s crashing as soon you switch on Rendering.

Here’s the Terminal output:

ERROR (gpu.shader): EEVEE_shaders_effect_ssgi_filter_sh_get Linking:
| Error: Input block `ShaderStageInterface’ is not an output of the previous stage

ERROR (gpu.shader): EEVEE_shaders_effect_ssgi_filter_sec_sh_get Linking:
| Error: Input block `ShaderStageInterface’ is not an output of the previous stage

Here’s the crash log.

Blender 3.0.0, Unknown revision

bpy.context.space_data.context = ‘TOOL’ # Property
bpy.context.space_data.context = ‘RENDER’ # Property


/Blender/Blender 3.0 SSGI/blender(BLI_system_backtrace+0x33) [0xb1c38f3]
/Blender/Blender 3.0 SSGI/blender() [0x10bbe19]
/lib/x86_64-linux-gnu/ [0x7fdae9bc9520]
/Blender/Blender 3.0 SSGI/blender(GPU_shader_get_builtin_block+0) [0x9cd0220]
/Blender/Blender 3.0 SSGI/blender() [0x167d46e]
/Blender/Blender 3.0 SSGI/blender(DRW_shgroup_create+0x1d) [0x167f3ed]
/Blender/Blender 3.0 SSGI/blender(EEVEE_screen_raytrace_cache_init+0x789) [0x169ad09]
/Blender/Blender 3.0 SSGI/blender() [0x168a5f5]
/Blender/Blender 3.0 SSGI/blender() [0x16779b1]
/Blender/Blender 3.0 SSGI/blender(DRW_draw_render_loop_ex+0x1ed) [0x167a4dd]
/Blender/Blender 3.0 SSGI/blender(view3d_main_region_draw+0x8f) [0x222cd7f]
/Blender/Blender 3.0 SSGI/blender(ED_region_do_draw+0x881) [0x1ca34b1]
/Blender/Blender 3.0 SSGI/blender(wm_draw_update+0x573) [0x14e2423]
/Blender/Blender 3.0 SSGI/blender(WM_main+0x30) [0x14df850]
/Blender/Blender 3.0 SSGI/blender(main+0x2d2) [0xfa01d2]
/lib/x86_64-linux-gnu/ [0x7fdae9bb0fd0]
/lib/x86_64-linux-gnu/ [0x7fdae9bb107d]
/Blender/Blender 3.0 SSGI/blender(_start+0x2a) [0x10b855a]

Python backtrace


Just tried it out on Linux as well. I’m able to render, though the window displays a ton of garbled mess before it produces an image.

1 Like

I’m bumping this thread to talk about how absolutely fantastic this branch is. Sure, it was good before, but now?

…it’s amazing! So good!

1 Like

Thanks you for taking the time to report!

Can you post your GPU and brand and model as well?

Currently on vacations - so only my good old:

Dell XPS13 9370 (i7-8550U, Intel UHD 620).
next week (or year :wink: ) I can re-test it on my Ryzen 9000x, nvidia 3070) - if returned from service…

OS: Kubuntu 21.10

btw: really appreciate your efforts - please, tell if you need more details.

UPDATE: attached an external GPU (nvidia 1050m) - it’s working now :grinning_face_with_smiling_eyes:

1 Like