Screen Space Global Illumination for Eevee

[0451]

Screen Space Global Illumination addon for Eevee.

Screen Space Global Illumination for Eevee - Addon

Converts Diffuse and Principled BSDFs to nodegroups that give representation of diffuse component to SSR for SSGI effect.

Disclaimer: World/HDRI lighting in specular component is not handled properly between object reflections and gives inverted colors.

The addon (ab)uses Eevees built in screen space reflections with material nodes and thus won’t be comparable to a correctly built in SSGI solution.

Updates:

• 0.1.0 Fixed error in folder structure in initial release. Now installs correctly.
• 0.1.1 Added color range input clamp. Changed the way increasing intensity works. New defaults only compatible with no world/hdri lighting.
• 0.1.2 Added controls over World Material (broken glossy interaction disabled by default). Added option to scatter diffuse normals (base performance cost increased). UI and default settings changes. Clean up.

The addon currently doesn’t preserve keyframes on diffuse and principled BSDF nodes.

Info about futher plans:
I’ll update the addon only version with things I can do to improve it, but I’m also going to add a modified build of Blender with addon only designed to work with that as there are some things I can’t do with only material nodes. It will be the same hacky approach at it’s base and not a separate effect from SSR.

Screen Space Global Illumination for Blender Eevee - Addon

Explanation of parameters (outdated):

[0451]

Made a mistake in the zip file on gumroad. Will fix in a moment.

Edit 2: Fixed folder structure - should install normally from a zip now.

[pancake_manicure (Ethan)]

Hi! this is my first time seeing this, and it looks incredible. I’m extremely excited about this implementation, and what you’ve done looks very awesome.

from my quick testing, it works exactly right too. here’s a quick render I did.

One thing I did notice is that if the normals are inverted, the surface seems to be glassy with no control over the roughness. Is that a limitation of this technique?

great work on this though, thank you for sharing it!

[0451]

Hi!

I didn’t run into case like this during testing, but from a quick test I can confirm this happens. I’m in the middle of moving currently so it will be at least few days minimum before I can see if there’s a workaround that can fix this.

I’m also curious if there a use case for flipped normals like this in general? Some NPR techniques use flipped normals for outline for example. It usually glitches out on “incorrect” values like albedo values that are out of correct PBR range and too strong normals. It might be useful to add a clamp so it gives better results without the need to correct materials.

[pancake_manicure (Ethan)]

no worries, it works well otherwise!

Something like a clamp might be nice, yeah. I often use not-correct pbr values… npr techniques can be helpful to get an appealing image. just my 2 cents.

[1D_Inc]

Awesome job!
How did you come to that idea?

[0451]

Thank you!

General inspiration was from using SSGI in UE4 and seeing how well it worked there.

The idea to use rough glossy BSDF as a stand in for diffuse, since it has SSR, is not a very novel one. I’d bet that the glossy look of objects while the shaders are compiling has given plenty of ideas.

I spent some time looking if I could add SSR natively on actual diffuse materials without changing the base look, with modifing source code, but since adding a second layer of SSR is far too complex for me, then the way I was trying to do didn’t really seem to have any big advantage of doing similar approach with nodes instead.

I posted most of my tests here: https://blenderartists.org/t/fake-ssgi-in-eevee/.

[ostapblender (Bohdan Lvov)]

Absolutely badass! Thank you for making this addon!

[ostapblender (Bohdan Lvov)]

Btw, looks like in some cases it’s returning negative values resulting in the weird results:

Maybe there’s a way to cap it to zero or whatever value forcing it to behave that way?

SSR.blend (1.2 MB)

[BCerk (Bruno H)]

Have any of you tried it with the Physical Starlight add-on?

[0451]

@ostapblender
It’s a issue with the nodegroup not working as intended with world lighting. I’ll probably look into it more in the future, but I don’t think there’s a way to currently fix it with nodes only. The workaround is to reduce “Darken Direct Lighting” (I need to rename that, what it does is isolate SSR to add only SSR to materials) which changes the overall brightness and look of the material. If the scenes world lighting contribution isn’t very intense you can get a decent result without completely reducing it to 0.

@BCerk
Only pre 1.22 version that used to decrease exposure by -6. The newer one might work better, but it still has all the same issues with world lighting.

[LOHTANGCLAN]

Thanks for this 0451, will try doing a nice long rendered music video with this addon!

[rawalanche]

It’s a bit disappointing to see the values like boost SSGI and darken direct light. That’s a throwback to 90’s and early 00’s when people still had no idea how GI is supposed to work and were using it wrong. GI should be something you turn on (or these days have on by default) and then you only possibly tweak performance/quality ratio values. But there should never ever be such thing as “artistic control” over GI. In PBR, such aspects of light transport should never be touched.

Now I do realize that this is a fake, and that’s it’s very far away from proper light transport simulation, but still, parameters like that just encourage bad practices. I’d suggest trying to get as close as Cycles references as possible i as many diverse lighting scenarios, then keep all these as constants under the hood. But seeing values like that in a commercial addon is honestly just discouraging, as it makes the whole thing look rather amateur-ish.

Here’s Unreal Engine 4 SSGI for comparison:

Screen Space Global Illumination

You can see that it has only 2-3 parameters concerning the speed/quality tradeoff. That’s it. No weird multipliers of luminances and roughness values.

[Zawardo]

you can take py file and solve problem.

[obsurveyor]

@rawalanche

Now I do realize that this is a fake, and that’s it’s very far away from proper light transport simulation, but still, parameters like that just encourage bad practices. I’d suggest trying to get as close as Cycles references as possible i as many diverse lighting scenarios, then keep all these as constants under the hood. But seeing values like that in a commercial addon is honestly just discouraging, as it makes the whole thing look rather amateur-ish.

Hope you feel the same way about Eevee because it sounds like it’s exactly what you have to do between Cycles and Eevee with tweaking light values. If Blender can’t get lights right between their render engines, this is some real harsh criticism that is entirely undeserved for a free addon.

[LOHTANGCLAN]

Agreed. I’d rather have these extra controls, than not. What has drawn me to using Blender at this point in time, is the ability not to worry about what is completely correct or accurate. I’m able to tune in a look that I want with relative ease. I’ve used most of the commercial render engines released in the last 10+ years and Eevee is one of the fastest and most fun to use.

[0451]

Unreal 4 SSGI is affected by post process volumes indirect lighting intensity, so there’s more control over it, just not in a r.SSGI. cvar.

I agree with what you’re saying overall. The choice was restricting it cases where it works as intended with less control and trying to support cases where it doesn’t with offering more control. The issues with world lighting are far more visible than the test cases I’ve tried it so I might have not made the correct choice there. The default values are a compromise due to that too.

If someone who chose to pay for it and feels like they had the wrong impression at that moment (or for any other reason for that matter), feel free to send me a email for a refund.

[rawalanche]

Rasterized vs Raytraced light is quite different matter. I said I acknowledge they will never be identical, but multipliers like these are usually a means of giving inexperienced people means of achieving worse results while at the same time increasing learning curve. It’s literally a loss/loss scenario.

Is it possible to use this fake to achieve same quality as Cycles? Of course not?

Is it possible to go through various different scene types and tweak constants so that overall, this addon produces as close results to Cycles as possible within what this approach can achieve, and then make those default and hide the multipliers? Yes!

[Binke]

While what you say is not wrong, it’s a free addon made by someone in their spare time and not a commercial one. I don’t think such harsh comments are necessary, just give your suggestions for improvements in a constructive way.

[rawalanche]

Well, in UE4, you have option to use global GI multiplier but at the same time the way engine is designed discourages it. You kinda put those parameters in front, not even labeling them as advanced or something, meaning most people will likely use them wrong.

I don’t think your addon is bad or anything, and I don’t think anyone who finds it even little bit useful should ask for refunds. I just see the potential it has so it disappoints me that many people will probably use it wrong and achieve some not very pretty results just because of how user interface is designed to lead them through the usage of the addon.