Doesn’t work with emissions when I tested
Also don’t think it’s actually ray-tracing…
well thats interesting it doesn’t work for emission due to how it works
I think that the other guys version is just a basic barebones version of 0451’s
Uses the glossy method via shaders, no code probably, so cant be ray-tracing…
To bad…
Is there any news about SSGi for Eevee next?
It’s supposed to come to Eevee next or not ( although Clement might re-write some parts of it )?
I haven’t been following Eevee Next’s development, is Screen Space Tracing the same thing? Because that part seems to have been done. (T93220)
Add images
1 Like
@Sleeper
Yeah, it’s the same thing, although Clement redid everything from scratch (also for the sake of clarity sake, my patch is mostly reusing modified duplication of his Eevee code also for the base functionality).
Wrote what I could gather about it from browsing the Eevee next branch code that’s available a while back, and how it differs from what I did:
I took a quick look at what’s available of the Eevee next source and the pure screen space raytracing part seems pretty similar. Reusing reflection rays (with some extra tweaks). Bigger change is denoising and the bilateral filter at the end of denoising uses variance estimate from the ray resolve step. Can’t comment on how it fits with the other parts of the rendering or how up to date the code that is available is.
This is just from what’s visible currently and with no way to test it out.
@hrijul_dey
I haven’t tried it out, but it seems similar to what I did at first with the addon, so SSR “remapped” to do diffuse lighting instead of specular reflections. Mine had some attempted approximations to make it behave more diffuse like, but they could cause artifacts and had a pretty sizeable performance impact. Might be worth to check it out if you need something that doesn’t come in a modified build and the old addon isn’t suitable for.
4 Likes
looks wonderful as always! are the rocks a particle system or parallax mapping?
instances with scattering… particles
What issues with Eevee happened after 3.1.2?
they’re doing a full rewrite of eevee so probably everything is written different and they were doing a lot of optimizing in the shader size of things so they would be lighter which leads me to believe the full code will need to be re done for ssgi … problem is ssgi via main branch is supposed to be coming in 3.3 perhaps so 0451 is kinda at an impasse 
1 Like
I’m aware there’s an Eevee re-write going on behind the scenes and it’s not terribly surprising that would mess up custom builds that modify Eevee’s behaviour, but I thought 0451 meant there were issues with the quality or something that made them prefer Cycles’ output over Eevee’s for newer Blender versions.
Where did you hear SSGI is supposed to be coming in 3.3? I’d love to see it added to the Blender main, but that’s so soon - they’re bcon3, bug fixing only and I haven’t seen anything about about SSGI making it for that release. I hope you’re right though.
But yeah, if SSGI does make it into the main branch in 3.3, there won’t be much need for 0451 to continue with their version, and not much need to push it into 3.2.
1 Like
There performance issues on 3.2 (at least there were last time I had time to try it out). Documented performance regression is mainly shader compilation with bump nodes. Most of my personal files use a nodegroup with bump nodes as a replacement for normal node, due to the painfully slow normal tangent calculation otherwise.
In addition changes to how the shader to RGB node is handled now in 3.2 broke most of my NPR materials.
I was using 3.2 with only Cycles for a bit, but finally decided to go back to 3.1.2 for daily usage. For my use case under 3.2, a lot of things are either now broken or almost impossible to work on due to performance issues.
Overall the situation on updating for 3.2 otherwise is pretty much as described. The recent rewrites in 3.2 also functionally wiped out a lot of my notes that I did at the beginning of the year for all the planned changes with my SSGI version (mainly kept as comments in a separate patch). The reality comes down to that I’m unable to keep up with the main branch development unless I get enough free time continuously work on bigger changes. I’ve found that it’s incredibly inefficient to try to implement large changes if I have to do them with longer pauses in between, since I lose track of all the components that affect each other.
For the official implementation in Eevee Next I think the goal was for 3.5, but I haven’t kept up closely with the development updates recently.
4 Likes
thats my apologies i forgot that 3.3 was about to come out i thought that was the next one my apologies 
the updates are showing a lot of stuff done and there was a decent update to the dev blog this week that have many of the “need to haves” getting there and a lot done
1 Like
That actually explains a lot. I switched computers right when 3.2 came out, so it wasn’t clear if that was a blender thing, a new computer thing, or just something I was imagining. I haven’t done any “serious” rendering since 3.2 came out (just test renders of some modeling/sculpting stuff) and if I did, I’d probably be opening it with the SSGI version anyway, but there were definitely a couple scenes that seemed to be running hotter than they should’ve for for the materials/meshes in question.
That’s too bad about your NPR materials though. I should probably check some of my shaders.
1 Like
Does this actually work in material preview mode?
( As it’s using screen space ray tracing just like SSR which also works for material preview. )
And does it work in both Eevee and Cycles material preview?
And is there a way to turn it of in material preview ( enable for rendered, disabled for material preview ), as sometimes you might want/need a more shade less look to see how the material “works”.
Does this actually work in material preview mode?
Yeah, the behaviour is exactly the same as SSR. It shares a lot of the background stuff with SSR as well, was easier to implement and keep up to date that way.
Enabling probe tracing and turning the intensity of that down to zero is a good way to verify, since it completely replaces the default diffuse HDRi lighting (the default intensity is also way too low should be roughly 5 to 7). Should result in no diffuse lighting, unless you have scene lamps enabled. The difference would come in if it also sampled local probes (as it’s skipped for material preview by default), but that’s not implemented.
Adding a toggle for rendering / material preview shouldn’t be too difficult, but it would affect screen space reflections as well as they are coupled together in many aspects behind the scenes. But overall that’s not a priority atm.
1 Like
gone forever
1 Like
Not sure it was ever supposed to be ready for 3.1, but I do think they were hoping for a 3.1 or 3.2 release. That hasn’t happened, but if you follow the latest updates it seems like a lot has happened in the past month, including Cyptomatte which was originally considered a “nice to have” for the initial release. I think that things are heating up on the Blender Org movie project which in turn is pushing development in EEVEE much faster than before. I think an initial release for 3.4 is realistic, although not everything will work. So basically I would think that by mid-October it should be in pretty decent shape for the beta releases.
1 Like
Can you document where Eevee Next was slated for these versions?