That’s a known Eevee’s limitation.
https://docs.blender.org/manual/en/latest/render/eevee/limitations.html
2 Likes
Hey all, new here. I have a quick question. Does anyone have a Blender 3.0 SSGI version that was committed after May? There are two builds on the Google Drive but both of them have commit dates of 26 May 21. There used to be one on https://blender.community/c/graphicall/ but it’s been updated to v 3.1 alpha. I don’t want to use the 3.1a as it’s been unstable for me. I used to have the June build but I lost it when I formatted my PC recently.
I require some of the Geometry node features from a newer release date which someone handed over to me.
1 Like
New Windows 1.15 build on 3.0 beta uploaded to drive
Updates:
Switched denoising filter from bilateral to an a-trous.
It can get rid of larger scale noise / blochiness at the cost of details and some halos around smaller details at higher filter sizes. There’s still few easy optimizations to do and few improvements to look into.
At 64 render samples (AO disabled):
Old:
New (filter width at 32):
At 128 render samples (AO disabled):
Old:
New (filter width at 32):
New (filter width at 12):
It also changes internal filter width progressively with each render sample, so lower render sample values (under 64) need tweaks towards lower filter size. Over all I’d like to recurrenty denoise the diffuse GI, but I’m still looking into how to set up that the least hacky way.
Controls:
Filter size - changes the strength of denoising the most. Default 12.0 is similar to old filter’s 12, but higher values are a lot stronger
Denoising Start Sample - at whitch render sample denoising kicks in. 1 - means viewport is always denoised, 2 - only when it has been static for 1 sample.
Win build is without Optix and no Linux build - didn’t manage to troubleshoot all the issues with 3.0+ builds for release config.
Patch (also on drive) applies cleanly to 3.1, but 1 reject with 3.0.
R:
@PavaOne @mwstandsfor
Updated 115 Win build on 3.0 up on drive.
@EMURETRO
Can you run blender from command line (https://docs.blender.org/manual/en/latest/advanced/command_line/launch/windows.html) and post the error message on crash?
@TheCrowdedOne
Could you try out the updated build with new denoiser (especially at higher filter widths) to see if it improved at all?
I’m not doing anything temporal with denoising so it just depends on denoising quality.
@hrijul_dey @jovlem
It’s way out of my ability to implement something like that in addition to other features that it needs in place to work. Generally just quickly going over slides for both Lumen and the surfel, I’m not really sure if the additional complexity over just ray tracing makes much sense for non-game renderer. I considered something like Lumen’s screen space probes for a moment just as side project, but for screen space tracing the performance increase wouldn’t be that significant.
@zhengzezhong
It’s a default Eevee limitation, IIRC the new Eevee rewrite (planned for 3.2) should have no limit on lights.
11 Likes
It seems to work great! Really great.
I tried it and here are the results:
The 12.000 filter size version still has noise for sure, but the 32.000 filter size version helped! Some loss in quality and still some noise but still pretty good.
Also the SSGI makes some weird bleeding on the darker wall thats far away from it.
Its great for screen space, im just reporting these as I dont know if its fixable or not, dont know anything technical, just here to help. I think i’ll use SSGI for only renders for now because of the noise, also the limitation of it only ray tracing what the camera sees. But I really love it so far! And the filter size will definietly come in handy.
(Also if I may ask, I know Eevee’s getting a re-write with also an SSGI built into it, are you working on the SSGI for the official Blender 3.x release or is someone else in the team working on it?)
1 Like
Thank you for the update. I really appreciate it! 
just want to mention., it looks like you titled it 3.1 Beta… took me a while to realise it’s 3.0 beta
1 Like
@TheCrowdedOne
I think that leaking to background might be fixable with tweaking the weights internally (bilateral used squared depth before multiplying for weight. New one currently uses just flat depth.) There might be some tweaking to improve it overall also, just by changing some internal values - didn’t have enough time to test it out.
There’s some papers on improvements to the atrous filter also to make it better at preserving details and avoiding leaking, without changing the filter set up too much. But I’m just starting to look into it. Basic variance weight from the GI should be doable for better details.
Usually these filters are stacked, I’m doing only 2 passes per render sample, since high render samples counts are needed anyway for soft shadows. Getting the previous render samples filtered output fed back into the new sample’s filtering pass would make it possible to do the same as more passes just over multiple “frames”, with some other additional benefits.
I’m not involved with the Eevee re-write. I think Clément is mainly working on the raytracing part.
Looking at the task there’s multiple overall improvements planned without seeing the actual (planned) implementation:
Doing anything more than a spatial filter for denoising is already a huge upgrade over what I have set up currently. Especially for viewport stability.
@mwstandsfor
Fixed that. Thank you!
8 Likes
Hey! the new filter looks a million times better now than the previous since it removes that very obvious tiling from the small blue noise samples. Would it be possible to have more realtime samples for a performance cost? i like to render directly from viewport with the help of additional post process TAA to stabilize SSGI and AO but the 1 realtime sample is a little scarce at times 
1 Like
Thank you very much for updating! Can’t wait to play around with it!
3.0 for linux maybe ?
Thanks
1 Like
I tried tweaking with the filter weights if thats what you meant, nothing seems to change with the background leaking :[ And no worries man! All here to wait, what you’ve done already is amazing by itself.
And ahh gotcha! I thought you were the one leading the SSGI port for Eevee re-write, and i never saw that task showcase! That’s nice to see how Blender is doing with the Eevee so far.
testing version 3.0 with 1.15a
only ssgi without supporting lights
testing the option: injected probe GI intensity
I made a comparison with 1.15 of version 2.93.5 and this version 1.15a is less noisy
Saludos a Todos
4 Likes
is there any compilation for 3.0 with cuda and Optix
by the way very good job
1 Like
Hola! Thanks 0451
Only SSGI + Sun Light, and Windows (area light)
3.88s render (1920x1080)
Saludos desde Costa Rica
8 Likes
OMG,… jajajaj
3D Viewport only with the world and SSGI
render
and finally the render with supporting lights
4 Likes
Thank you very much I think I need to read the document carefully
@Warcos
I have to troubleshoot Optix a bit for Windows build. Currently I have no clue why it failed with latest Optix version. Shouldn’t be too hard to figure out when I can mess with it for bit. Cuda should be fine.
@TheCrowdedOne
I meant weights on my side internally. I suspect the depth buffer is way too weak to be effective at the moment. The UI controls for weights work correctlyonly in the 0.0 - 1.0 range with the new filter, so it isn’t possible to increase them at all over 1.0 atm.
@darkon11
I uploaded a Linux build to Drive, from last weekend, but I suspect it won’t work at all. It has no Cuda or Optix for Cycles and a few other things disabled from CMAKE to make it build. Unfortunately I have no estimate when I can figure out a fix for 3.0+ Linux builds (currently the plan is to try building from a clean Linux VM and hope it magically fixes some issues packages).
2 Likes
Hey,
You mean realtime samples for specific effects or overall render samples? For effects something like more SSGI denoise samples or more rays marched per pixel?
Since full res tracing is pretty expensive I’d look into setting up more denoising passes at first for that use case (although that still can look spotchy due to very noisy input). More rays per pixels would work better with half res tracing. Although I’m not sure if my 1060 is even relevant enough now for getting an idea of the general performance cost.
Rough idea what 5 passes on noisy input looks like:
For more effective realtime denoising it needs temporal component with robust reprojection. I have no plans to try to figure something with reprojection out currently. Fortunately that should be in Eevee rewrite anyway.
5 Likes
Yea more actual brute force samples arent very usable in realtime! i was talking about the realtime denoiser filter quality/samples! The filter/denoiser is rly fast and framerate isnt much of an issue for me since i can slow down the scene/project and speed it back up in post to gain more frames. Some option to have higher realtime denoiser/filter samples at a cost of framerate would be hiiiighly appreciated! You had it in 1.14 if i remember and it produced production ready results from the viewport at somewhat decent frames but your new denoiser/filter seems much more performant, hence why id love to know if itd be possible to up the realtime denoiser/filter sample count
Cheers
Theres a RESHADE Shader called RTGI which does realtime screen space gi/raytracing also using a smart denoiser with lower actual brute force sample counts and the results are amazing!
i sometimes use that over the eevee native ssgi implementation of yours but since yours is more built in has access to tonemapping and actual brightness of objects/lights its a lot more accurate. The spatial denoiser looks great and i think a realtime high quality denoiser option would benefit a lot of people trying to playback/record their viewport in production ready states. Afaik RTGI also does temporal reconstruction similar to ssr in eevee even with your denoiser on (seems to produce decent results) and from what ive tested with your new denoiser/spatial filter it could 100% replicate something similar to RTGI when it comes to Screen space GI.
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 
I got an rtx 3070 and even 1.14 was kind of doable with higher denoiser/filter sample counts.
The fact that you can use things like depth or normals to further up the filtering quality makes it such a powerful denoiser. and with the spatial filter u got going now it might be very feasable to have more realtime samples under an accumulate/realtime toggle.
RTGI certainly managed to get high quality screen space gi running without RTX support so i see great potential here while everyone waits for the eevee rewrite summer next year