Besides using native has there any chance of getting a new SSGI addon version? Because I am using it in E-Cycles 2.93 beta and SSGI version is 0.1.4. Any chances?
Sorry to bug you, are there any more recent builds? Thank you so much for doing this for MacOS users.
@philo_vivero
Itās probably 1.13 version. Iāve only updated that number when thereās a change in default variables. Should look into adding that info to splash screen or at least as a comment somewhere. The diffusion file names should be accurate otherwise.
@Pablo_Houmbre
Itās an interesting effect for sure. Iām not convinced I have a 100% grasp on whatās going on there to actually make it as a feature, but might look into it once I have time again to do development at all, since I need to fix that area anyway, and if itās as simple as doing the opposite of the coordinate fix, Itās not hard to do a build. At this moment I canāt point to why it behaves differently during final render.
@123blender123
Thanks for the info! Iāll try update the builds when I get the chance.
@Draise
Thanks for providing additional testing!
@zigzack001
Outside of improving some of the hacky workarounds thereās not much I can do to improve the addon version (should add a material switch to disable it for Cycles as well). Considering I currently donāt have the free time to develop the Native version where I want to put most of my effort, thereās probably no updates to the addon, if at all. If you have some concrete issue that might be possible to fix you can bring it up, but thereās a lot more critical things in the native version that have been on todo list for a long time.
Removed by popular demand.
Hey 0451! I would suggest updating the branch you are using for the latest version of ssgi native to one of the newer 3.0.0 ones! The current one youre using has issues with AO doing some weird fresnel like darkening on glossy and metal materials!
Iām currently fixing compability to 3.0 master on the 1.14 preview (same one thatās publicly available, latest work in progress is too broken). I expect builds for Linux and then Windows to be done in few hours. If thereās interest in 1.13 with working half res trace and without filtering - I could look into it today also if thereās time left, provided thereās interest.
Edit:
1.14 preview diff updated and new 1.14 preview Linux build on 3.0 alpha uploaded to drive.
Edit 2:
Windows build of 1.14 updated preview on 3.0 alpha also uploaded to Drive.
Edit 3:
Minor fix got added to the 114 preview - setting the denoise mix to 0.0 disables running both the filters now (previously only first stage got disabled). Thereās still an additional texture fetch thatās worse for responsiveness, but the performance impact is smaller with the filter disabled.
Thereās always interest for this.
Tysm for the update! Have u figured out what you want to do with the Denoiser consistency? For heavily reliant GI scenes the denoiser is amazing keeping a lot of the detail with low samples and using a filter normal weight of 2+. The randomized blur seed per frame makes it difficult to use though since the blodging can be quite distracting on larger smoother surfaces @0451
Updated the 113 diff and updated Linux and Windows build of 1.13 based on 3.0 alpha on Drive.
Yesterdays Win build of 1.14 preview got built with wrong settings, so thereās no Cuda, or Optix in Cycles there.
@Naskomusic
I have few things I want to do with denoising that should improve it, but that requires having some time to test things out to understand how exactly the sample accumulation is handled in Eevee. I currently, unfortunately, donāt have that time.
Mainly I want to skip denoising for all except for the final render sample - should decrease variance a lot, but Iām not sure yet if I need to set up an additional buffer for it. Iād also like to look into some optimizations, like optional half res filter + upscale (although that is slightly in conflict with the tracing resolve stage always being full resolution). Itās also relevant with separating the output from SSR and that too is something that I need longer period of time to understand how to best approach it.
Thereās also a issue with the input for both SSR and SSGI being packed together into one 32 bit buffer instead of two 16 bit ones, that wasnāt visible initially when specular colors wasnāt sampled from that input buffer - thatās currently most critical thing I want to fix when I get the chance.
Congrats on getting this into master with the new eevee dev plan!
When it would be updated to Blender 2.93 LTS?
I donāt know, but I canāt wait
Hi! Is there any chance of your native version being a part of official Blender release in future?
That was just announced as a plan by the main eevee developer.
Cool!
Here is the news for those who had not read it (like me):
Thanks! Great news.
Update to address the news:
This branch is now dead and thereās no further development planned. Still, depending on how fast the new official Eevee versions are functional I might experiment with this branch a bit further when I get free time again.
Also to avoid any possible confusion:
I donāt directly have anything to do with the official new implementation. Personally it will be fun to see how a developer with actual relevant experience solves the same issue.
@Binke
Thank you!
Just remember that ClƩment Foucault ( @hypersomniac ) started like you too, experimenting on his own and sharing builds with the community here on this forum before Eevee even existed. So maybe one day they will contact you to help Eevee development (If you are interested of course).
Thank you for sharing your work with us!
Let them know you want to be involved! I think it would be very good all-around. You have some experience and can talk about certain dead-ends or more efficient ways to do things that arenāt immediately obvious to someone who hasnāt done it once already.
If you do end up with another patch someday, let me know, and Iāll make the Intel Mac build against master
ā¦ for some reason I canāt actually get any other branch.