Let us know what we can do to help. I think your code is one of the most exciting things to happen to EEVEE and even if BF is planning something for the future, I think the current benefits to many users are great.
thank you for your great work.
I have version 1.12 and 1.13. The speed in 1.13 is better. The optical quality has also improved as the reflections are now continuous. There is also no more pumping in the animation.
Unfortunately I now have a problem with Fireflys. Even with a clamp over 200, I can’t get it under control. I suspect it’s a normal problem. High Quality Normals can dampen the occurrence, but not elliminate it.
Is there a workaround that can help?
The clamp works in reverse. So the lower it is the higher clamping is. Except 0.0 disables it completely. IIRC there were some changes to how clamping was done between 1.12 and 1.13. And I haven’t completely gone over the new version. That being said - There’s overall a firefly problem in Eevee currently in 2.93.
If it’s similar to this then it’s probably and issue in master:
If it looks more like the example Renvyrere it might be an issue on my end, but I haven’t been able to reproduce it.
If it’s like the one in master then try switching to diffuse shader to see if it solves that. I have made some changes to normals in diffuse closures also so they follow a bit how the normals for glossy are handled, but I don’t think that made it into 1.13.
Hi, one question (maybe more suited for @hypersomniac):
to override the limitations of the ScreenSpace domain could it be possible to calculate the reflections (and AO) with a virtual panoramic camera (mirrorball/equirectangular) and then reproject the result on the real camera?
If it even makes sense…
Ohh, thanks for your hint with Clamp. Blender inverse logic. Unfortunately, it doesn’t fix the Fireflys. It may be a common problem with EEVEE. One can only hope. Edit: Ok, as I understand now, there are NaN (Not a Number) pixels and no Fireflys.
I can’t really speculate on feasibility of doing that. If it were implemented it would solve the problem with offscreen reflections, but it would do nothing to fix things that are just occluded by geometry so the result would heavily vary on where the camera location is. I did some very hacky tests a while back with a cubemap in a camera location and the overall scene lighting changed a lot even with minor camera movements - of course it’s not directly comparable to tracing where the result would line up more accurately with the actual scene, it might be stable enough, but there still would be similar limitations.
A new MacOS version please
Newer than this one?
I’m setting up a Catalina VM to do builds on, but I have no idea how the compatibility is between MacOS versions.
The work in progress branch of 1.14 is way too broken at the moment to share and I’m currently not putting any work into it until the hardware that I need to set up a Linux dual boot arrives. The compile times on windows are orders of magnitudes worse than on Linux and I’m having GPU driver issues on the Linux VM so I can’t test anything there at the moment. Or do you mean a build based on a newer Blender master?
I didn’t notice, sorry
Question: If someone would like to merge this into a custom branch or fork, or to master, where can they access the repository to then compare files and merge - then compile another build to test?
Maybe someone can take a look at the code and turn it into a patch for the source master. Being a modified source code, you should follow the GPL license and host the repository somewhere - if you have the source code hosted somewhere already, not just the compiled binaries - where would the links be?
The diffusion (essentially list of changes to source) for 1.13 is available on Gumroad:
Archived versions on the Drive link in the original post (was also linked from Gumroad, but currently removed due to issues with PayPal):
Earlier builds have just a copy of source directory copied to the build directory.
There’s also a patch from the diffusion posted on the developer portal, but I don’t have plans to update that frequently due to the amount of email spam it can create (It’s up to date with the public builds at the moment of writing this comment):
The code quality needs improvements.
Patch that should solve the white artifacts in Eevee master got commited. I’ll look at finishing 1.14 and making a version based from the latest master some time relatively soon.
Blender 2.93.0 Alpha 0e2a1ef13223 April 08
The version seems to be free of NaN pixels. I’ve rendered a couple of tests. It’s ok now. But when rendering animations in Windows, Blender crashes.
Wow thank you! I missed the diff download. How often do you update it? I just did a build with it and works fine. Will test a render now.
Super looking forward for 1.14! This bug doesn’t give me any chance to use SSGI.
I’ll upload a diff together with every finished release. Except for the patch on developer.blender.org site - I’ll update that one when there’s considerable time since last update, since the uploads generate a bit too much noise for my liking.
Hello guys, I encountered the problem with white dots/squares too but I see it was already addressed. Also, I am not sure whether it´s SSGI related or not but I noticed vertical lines which are best visible in places with stronger reflections. Do you know how to solve this? I am using 2.93 native build.
I believe it was fixed on April 8, 2021 by Clément Foucault, download Blender 2.93 again.
Also, check out this page (the two videos at the bottom).
Thank you for advice. I tried the solution and I would say that it helped reduce the problem slightly, but it remains present even after I increase AO, turn off auto smooth, or turn off AO completely. I also tried download 2.93 from gumroad again but problem stays unchanged.
The white dot issue seems to be resolved in master in some cases, but I haven’t made any new SSGI branch builds based on those. After testing the patch in master I’ve found it hasn’t fixed the white dots on my test cases, so I haven’t made priority to do a new build only off of that since there’s still issues.
If the official daily 2.93 alpha build from: https://builder.blender.org/download/ doesn’t have these issues on your end I’ll update the 1.13 builds to the newer master.
Without seeing the full picture of the vertical stripes and the relative size to render resolution I can’t be completely sure, but it seems to be the noise pattern in screen space reflections being accentuated by the exact same pattern in SSGI. I’ve made some minor changes in 1.14 to hopefully decorrelate it a bit, but I’d need to test it to say if it made any perceptual difference. Overall the plan is to get rid of SSGI noise by doing an additional filtering step that’s currently work in progress. If it’s usable enough it might make it into 1.14.