Screen Space Global Illumination for Eevee

@0451 Hi! Thank you for all this good work!

The latest Linux - SSGI Native 1.14 (Preview - New - Unstable) 2.93_RC2 (CPU).zip.7z (sha256sum: c3ddf419baf8864f8cdd6438856aa625a9d176d5a4301ceaf0246e2a299aa69a) crashes Blender on my Ubuntu 18.04 with the following error:

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

I have an AMD graphics card, sometimes their drivers are too picky about the shaders they expect. :stuck_out_tongue:

(I’m not familiar with Blender internals, currently have no idea how datatoc_common_fullscreen_vert_glsl looks to find the mismatch, wish Blender dumped the shaders on shader compile and link errors…)

EDIT: I guess I can just printf it if I’ll be desperate enough to recompile Blender. :smiley:

Hi!

I’m aware of this issue, but I’ve only managed to replicate on a virtual machine without an actual GPU passthrough. Since I couldn’t replicate it any of my actual hardware I decided to ignore after a while. This is the first report I’ve gotten about it.

Yeah. I tried to trial and error my way through it, but I couldn’t manage to fix it without causing other issues. As a result the all the shader inputs are quite a mess in that patch. 1.13 should work fine though, iirc.

I’m currently pretty overloaded by art related work so I don’t think I’ll be able to give fixing this a second go anytime soon. I was planning to use the time I have to add features, not fixing since I’m not concerned with doing things cleanly anymore due to official solution being on the horizon, but so far I’ve only had the chance to do some occasional builds anyway. Honestly I’d appreciate any insight if you happen to look into it.

Hello again! :smiley:

I fixed it! 1.13 crashed for me too, but I managed to compile Blender on 18.04 and fix the shaders. The patches can be found here, in ssgi folder (apply them after applying SSGI-113.diff): https://github.com/procedural/blender_ubuntu_18_04

I can send you my Ubuntu 18.04 Blender binaries with SSGI 1.13 and these patches applied for AMD cards so you could share them on your gumroad, if you want!

1 Like

Hi!

I fixed it! 1.13 crashed for me too, but I managed to compile Blender on 18.04 and fix the shaders. The patches can be found here, in ssgi folder (apply them after applying SSGI-113.diff ): https://github.com/procedural/blender_ubuntu_18_04

Thank you!

I can send you my Ubuntu 18.04 Blender binaries with SSGI 1.13 and these patches applied for AMD cards so you could share them on your gumroad, if you want!

That would be great! I’d love to add the build to Drive and try to update the patches on Gumroad (I can’t unfortunately add Linux it directly to Gumroad, since without making it a paid product Gumroad has file size limit that has room for one build only and Windows still seems to be the most popular platform).

That would be great! I’d love to add the build to Drive

Here’s the link: https://drive.google.com/drive/folders/19cVKPxhOaT3VTa1iLlHuIVdfe_yZU1W6

(sha256sum: f93cbe34285b85eb2f0ede9c55e2031c2b3b3e7448b488c15880d474666f3929)

I will delete it after you upload the build to your Drive!

1 Like

Uploaded to my Drive. Many thanks! I also checked if I could fix it in 1.14 based on what you did, but no luck so far.

I may look into it in a couple of days (currently busy too), but I started with 1.13 because 1.13 worked on Windows, unlike 1.14 that silently didn’t work on Windows for some reason. It didn’t crash, but it didn’t work, so maybe it’s another AMD driver thing to investigate on both systems…

1 Like

Some tests doing AO with screen tracing. All world lighting is fully traced, so no effects like sub surface scattering:

Look dev HDRIs only injected into tracing:

Default Eevee probes:

Still a lot of issues to fix, before even more extensive testing. Tried out both injecting irradiance grids, but seems cubemaps work better due to higher frequency info. A lot of light leaking if things go out of screen or has to rely on the fixed thickness value. Some thickness heuristic (no clue how hard to implement) and having probes with location based sampling would fix some of it. Although using cubemaps to sample lighting info from means hands placing everything, with grids the badly placed grids shouldnt matter that much when most of the lighting is still corrected in screen space. A lot of stuff to fix, probably won’t be many updates.

More examples with on:




11 Likes

Just plain not working was an issue I ran into while trying to fix crashing in 1.14. For whatever reason the textures between stages were empty as far as I could tell, when using different set up. I think I’d need to take a step back and learn more about openGL and how it comes together in Blender before I have chance at fixing that mess. I’m pretty sure I’m making mistakes in how the shader stages and inputs are set up.

1 Like

You should check out upbge fork for prototyping in,

Would be dank to have real-time overscan for SSGI and TAA

1 Like

this is supercool

1 Like

Hey @0451
Any plans on improving the Denoiser for the diffuse samples?
Having looked at alternatives like RTGI, which is a screenspace raytracer using reshade, they denoise the ssgi pass aswell but in a much more efficient way than the current ssgi method. You have a much better working ssgi though since you have access to things like normal weights etc to bring back geometric detail into the denoised samples, but atm it seems that the denoiser starts to TANK after more than 6 filter samples. i render out my scenes in actual realtime so any improvements to the denoisers speed would be highly appreciated! :grinning_face_with_smiling_eyes:

1 Like

I rendered the same scene in Blender with EV express and in SSGI. Here is the difference:

EV Express:

SSGI:

The only thing I did was starting up SSGI, and deleted the baking cache (which was baked with Blender with EV Express addon).

I like the more vibrant colors, I think it is, but I wonder why I don’t have that much “Global illumination”.
Is there something I need to adjust, or are there some settings? I didn’t follow the thread for a while, apology.

Update:
Ah my bad; I had to rebake the scene in Blender with EV Express. Now I barely see any difference.

2 Likes

generally speaking this is due metallic materials not getting any diffuse bounces. this is normal behaviour though

1 Like

@Naskomusic
I’m annoyed by the denoising performance every time I do things with SSGI branch, so it’s pretty high in terms of things I want to improve. Unfortunately the first improvement I’ll try to do will do nothing for your use case.
The inner sample count is way higher than the sample count shows, combined with 2 unoptimized filters the huge number of texture samples tanks the viewport performance, doesn’t seem to affect render time that much.

What I plan to try out:
Denoise only at certain intervals or at max sample count - no performance hit in interactivity, better input to filters, so better output (could also possible get rid of the second filter stage then, so half less processing cost).

What would improve things overall: doing the blurring per directions separately, way less samples to do the same blur, minor artifacts in edges. Doing blur downscaled in first filter stage and bilateral upscale in second. I’d like to try both of those latter out also, but they’re way bigger time investments for me, so currently they aren’t on the table at least short term. Also I don’t think without better reprojection from previous frame they could do much better overall since the input is pretty bad at 1 render sample, just could use a higher number of blur samples without tanking the performance.

@Peetie
I think in this case the majority component is specular and like @Naskomusic said is already done by default SSR. The current publicly available versions don’t do any diffuse occlusion also, so the result can vary a lot in how you use the world lighting and probes. I would be interested in trying that file out though if you want to send it.

@BluePrintRandom
It would. But it’s kind of fighting with the current Eevee overall design - it’s usually assumes accumulating samples from rerendering one frame multiple times, instead of focusing on a lot more with robust reprojection.

In upbge fork we have samples per frame, we use eevee as a game engine.

That’s really interesting, I’ll try it out sometime. I have only tested UPBGE with the very early version with Eevee.

1 Like

I’m not sure if something has changed recently in master, but it looks like the 1.13 and 1.14 patches are both failing to apply for me in two files.

Hunk #1 FAILED at 60.
1 out of 9 hunks FAILED -- saving rejects to file source/blender/draw/engines/eevee/eevee_screen_raytrace.c.rej

Hunk #2 FAILED at 98.
Hunk #3 FAILED at 129.
2 out of 4 hunks FAILED -- saving rejects to file source/blender/draw/engines/eevee/shaders/closure_type_lib.glsl.rej

I ran the build anyway, and (unsurprisingly) got a segfault when I enabled SSRT in Eevee. I’m happy to provide those .rej files if they would be helpful.

I think it’s just a comment clean up that causes this in master:
https://developer.blender.org/rB9b89de2571b0c3fa2276b5c2ae589e0ec831d1f5

https://developer.blender.org/diffusion/B/change/master/source/blender/draw/engines/eevee/eevee_screen_raytrace.c - seems to be no other changes.

I’m mostly focusing on compatibility with 2.93 since 3+ will have Eevee rewrite that will make this redundant. So sooner or later it won’t be compatible with master. But this should be fixable without having separate patches for 2.93 lts and master.

.rej files would speed up verifying if that’s the case.

1 Like