0451 which addon do you recommend I use with 2.92? I can’t use 2.93 because I am running Windows 7.Thanks
0.1.4 - Latest version of the addon only version. There are lot more limitations and issues with it though, so how useful it is depends on what you are doing.
Can you send me the .blend file of that? I want to test it on my Mac Book Air and see if I get the same issue.
default cube opened
world energy to 0
default point light set to spot and rotated into the open cube
0451, is it not possible to make it as modified eevee, a separate render engine than eevee?
A tip for anyone having problem with the bounce not showing in some scenes the exposure of your camera is also a variable it seems. If its a pretty low exposure you need to boost up the intensity from the default max 1 on the diffuse intensity in the screen space settings.
I dunno if that makes sense. Rather I hope that 0451 is working with some of the Blender Foundation folks to try and incorporate this into a future build. At this point 2.93 is pretty much locked as far as new features, but perhaps it’s something that we could hope for 2.94 or 2.95?
Take Malt and ProRender, a custom render engine with its own materials and render settings. Or just take Malt, they were the same as having their own custom Blender build but now they can implement it as addon.
Or integrated into future official build, that’s great as well.
To me a clear benefit of a more powerful EEVEE is the ability to arbitrarily choose to switch to Cycles if needed, with hardly any change in the overall image except the need to minor tweaks to lights and volume density. This is IMHO the Blender “killer app”, I am not aware of any other DCC that does that. So the idea of having yet another 3rd party option with its own set of shaders and materials which would make it incompatible with Cycles is not a great solution.
Real time raytracing is already in the plans for Blender. Supposedly the move to Vulkan should make this easier to implement, but I’m not a programmer so I don’t really know. The way I see it is that the move to real-time or quasi-real-time physically accurate rendering is the future. At the moment we are in this weird transition period between what is the older tech and this new upcoming tech which will revolutionize the field.
OTOY is working on Brigade, Redshift on RedshiftRT, and it wouldn’t surprise me one bit if Epic is contemplating bringing the Unreal technology as an add-on to most modern DCC’s. EEVEE in many ways is leading the way as it’s here today and keeps getting improved. Blender 2.93 will see by far one of the largest updates to EEVEE in a while. Adding SSGI capabilities to Blender 2.94 or 2.95 is IMHO a no-brainer…unless the Blender Foundation is already working on their own solution, in which case I can see their reluctance to embrace 0451’s work if they think they have something even better.
I so agree !!!
As much as I enjoy this ssgi build. I really do hope blender devs are moving away from screenspace solutions. A separate approximate GI engine that can run realtime could be a game changer, especially if it could be used by both eevee and cycles and it would also help to slowly kill offline in near future.
if unreal 5 is as good as it looks to be, it will definitelly be the beginning of the end for offline renderers and while other commercial software follows, blender devs could slowly turn eevee into primary renderer while cycles would be just legacy until completely removed.
Afaik ssgi is used in ue5 for small scale gi
Sure, for details like cavities etc, why not. Better than AO
I just want to report something strange on the newest version, 1.13 version give me so many light leaks through an objects. And give me this something strange noise when its reaching a certain samples (it just randomly shows a white noise when reaches a certain samples and the noise are not generating, not like as should be how noise generating per samples). So I go back to the oldest version, 1.12 which is works fine to me. Hope you can fix it soon, Cheers!
Probably it’s binded. Eevee broken on Nvidia cards for now…
Instead of doing a Mac build myself I spent the time going through the changes in SSR in more detail. Some of the energy loss is due to changes how the raytraced samples are resolved in SSR update (based on this: https://youtu.be/MyTOGHqyquU), but it’s overall more precise than the previous implementation so I’m not rolling it back. Comparing it with Cycles it can be slightly darker in some cases. It can also be brighter so I don’t think offsetting the intensity where it currently is a good idea. I also tried biasing both the tracing and resolve at different stages, but overall the small reduction in variance isn’t worth the less accurate results. If you run into cases where the intensity is far off from Cycles some more examples would be welcome (@CookItOff ). I could consider adding some more fine tuned control over the intensity like clamping lows if it proves to be a bigger issue. I also compared on newer build than the one publicly available so I’m not completely ruling out some random bug in the public build.
To deal with the higher noise level I added an additional secondary denoising pass, but there’s a lot of trial and error with it at the moment so I haven’t dialed it in due to some random UI bugs I haven’t managed to fix. Also the actual filter is a unoptimized placeholder that I need to replace, but it works surprisingly fast even at 1440p viewport if the blur samples aren’t very high.
Also looked a bit into having a better interaction with the world lighting , either by deriving some larger scale occlusion from the SSGI result or some other way to make it interact a bit better, but I’m not sure yet what exactly I’m going to try. Currently if the AO size doesn’t match the SSGI one it can result in some wildly incorrect light accumulation.
Regarding implementing into master - the issue isn’t with SSGI as a technique overall, but how it’s implemented. I’m basing this off the default glossy SSR shader, behind the scenes I have no idea how it compares to ones in UE4 or Marmoset. I’m sure there’s better and more optimal ways to handle things, but this - raytracing in screen space and reusing multiple hitrays per pixel, works well enough overall for me and can potentially preserve some smaller details better than some other implementations I’ve seen with the cost of a long resolve time. The biggest difference to unreal seems to stem from actual reprojection and not having the result visible without accumulating it for few frames at first. I’m also using GGX both for tracing and resolve, but with some testing it doesn’t differ almost at all from a more diffuse BSDF. Main benefit would be some optimization.
Either way I’d expect Clement to tackle this at some point, but without speculating much I don’t see it coming pre 3.0. Without having any announced plans I don’t mind spending time on improving this, even if it’s only for promoting a feature not the actual implementation. I’m targeting 2.93 lts and will see if there’s any reason to keep supporting it longer for 3.0.
With SSGI vs actual raytracing. The changes to SSR in 2.93 are based on a presentation that also discusses taking over SSR rays and doing actual raytracing for them. No actual performance data, but I’d imagine screen space first and raytrace where needed is significantly faster at least for more glossy like behaviour. Not sure how it would hold up in an relatively unbiased diffuse use. In that presentation GI they implemented was surfel raytracing and additional screen space data to keep the details (GTAO with colored multibounce, Eevee’s GTAO that I multiply with is greyscale). Some other non screen space methods only account for static objects - I’m not sure how well they would fit into Blender overall.
I’m curious how a more hardware agnostic solution with a simplified acceleration structure and range like the one in Crysis remaster would work as a fallback to SSGI. Not sure how it would handle high roughness materials.
I need to actually test it, but I looked at the POM patch and I’m not sure if it’s compatible with current master. Best way to test it to actually build it, but I’ll look into it after I’ve set up an actual Linux boot - waiting 15 minutes on Windows vs average under 10 seconds in Linux (even in VM) for compiles is not motivating me to spend extra time on more trial and error than I’ve done currently.
I don’t see much reason to as it would be a whole lot more work just to house few changes. Also It seems to me that Eevee is pretty tightly integrated into viewport stuff so I’d imagine making it into an addon would be pretty difficult. Definitely way more work than I could pull off.
On what hardware and OS does it occur? There are some potential issues currently in 1.13, but I haven’t managed to replicate them. I only have nvidia hardware to test with and only under Win 10. Also as ViAdvena said, there’s artifacts in master as well so it’s bit hard to pinpoint where the issue exactly could be.
That sounds great. Stay on course with matching the changes implemented with the newest versions a Eevee.
I’ve already countered the decreased values and have found, like you, the newer changes to Eevee and the SSGI build are more accurate.
Keep up the great work and let’s us know if we can help in any way.
Cool, really appreciate you even trying to look in to it!