How is integrating SSGI into the main Blender build not a topmost priority for the Blender Foundation I don’t get.
5 Likes
may we have this as a diff vs master to apply to upbge?
2 Likes
I know, right?
3 Likes
Sure. I’ll post a diff of the new version to the google drive where linux and older builds are (diff for 1.12 is already there) when I’m finished stripping out the unfinished filtering from the newest version (bit busy with actual work atm). I’ll probably update the patch on developer site also, when it’s bit cleaner.
I’m not sure how good of a fit it is for realtime though since it’s needs around 4 render samples at minimum not to be a noisy mess. Doing bilateral filtering at 1 sample is really not enough at the moment.
UE4’s SSGI is also pretty noisy, but it tends to be way more stable in motion.
1 Like
Simple. They probably want real world space raytracing. SSGI is cute but breaks down as soon as you pan your camera.
2 Likes
SSGI with fallback to raytracing is best right?
also TAA can be upgraded to ATAA?
is RTX / Readon rays wrapped in a way we can call yet? (do we have to wait for vulkan?)
1 Like
SSGI has one huge advantage over potential future (if any and when ?) real world space ray tracing implementation : it is already here, and i guess nothing prevent to have both.
4 Likes
Once ray traced GI is in, SSGI will be redundant, and it does complicate the codebase. SSGI might find some momentary purchase in realtime renderers like Unreal while the raytracing hardware is still relatively weak. And I expect it to be a common technique during the course of the current console generation. But Eevee is not a realtime renderer, so a 16ms frametime budget doesn’t apply.
1 Like
Agree with that, but only “once, if ever, and when”, that’s my point.
So maybe a compile time switch like
#if SSGI
...
#fi
May allow to switch and isolate this code in the meantime, and easy to spot and remove once true ray trace gi get some love ?
1 Like
Not sure why you say this, but I have an animation with 180 deg. pan of the camera and SSGI worked perfectly.
I had lights behind the camera, lights in front, lights on the side, and it worked perfectly regardless if lighting was in the screen space.
1 Like
It will work for some scenes, it won’t for others. In particular it won’t work well when a bright surface pans out of the camera view. There’s ways to mitigate this, like by also using irradiance probes or increasing the overscan, but this really isn’t a great experience.
1 Like
Hello
Thank you for this great Tool .
Please can you compile it whit new version of 2.93 .
There is this new Setting for lights.
I tried to overwrite the blender files. But it seams it is some how written directly to (blender.exe)
Cant seam to get it working.
Thank you …
You the best.
3 Likes
1.13 up on Gumroad and builds drive folder. Uploaded also a new diff based on yesterdays master to the drive folder (updated patch on developer site also).
Based on the newest SSR shader so some small improvements from there mainly the half res trace resolve is now improved and doesn’t result in visible half resolution pixel grid being present.
I’ll try to do a Linux build today and Mac later during this week.
@TeDoma
New version up.
@philo_vivero @BluePrintRandom
Diff is uploaded. Code would benefit from some clean up though.
10 Likes
a penny for anyone who could combine this build with the Eevee Parallax Occlusion build 
3 Likes
Removed by popular demand
4 Likes
@0451 the new build seems to have lowered the intensity of the SSGI bounce.
Not sure if this is because the Eevee lights have changed in the latest official builds or something else happing?
Now I have to set diffuse intensity to 2 to match the brightness of Cycles comparatively. I liked having the default setting of 1 as close to Cycles’ intensity for any given light source.
Keep up the awesome work. 
2 Likes
Just a heads up, I tried using the native 1.12 build to test out one of my old scenes, and it crashes Blender immediately upon opening. Running it from the terminal tells me it’s due to a segmentation fault.
This may be something that’s fixed with the upcoming version, but if not, here it is.
2 Likes
@Renzatic
1.13 had that issue in my linux VM. I can’t recall without looking through it if it could be same issue with 1.12 (wasn’t occurring on my end), but hopefully I just fixed it for Linux (untested Linux version with fix for that will be up soon). I’m not having that great of a time figuring out the CPU side of things in Blender source - I’ll need to go through it again anyway in more depth. For now the Linux build is slightly different since that issue isn’t occurring on Win even though there are issues in code. Any reports of crashes is welcome.
@philo_vivero
Thank you for providing the Mac builds! 2.93 has had plenty of rendering artifacts for a while (currently not SSR related), but seems it doesn’t affect everyone. (https://developer.blender.org/T86578)
@Binke
Theoretically I could add the patch for that in. Haven’t looked at it in depth, but there should be no technical compatibility issues as far as I can tell at the moment.
@anon55679826
Can you send me an example? That’s not an intended change and I haven’t noticed anything major on my end with limited testing.
Edit:
Linux version uploaded to drive.
3 Likes
Imma check it out!
edit: IT WORKS! 
1 Like
Id kiss your feet if you did!
2 Likes