The latest Linux - SSGI Native 1.14 (Preview - New - Unstable) 2.93_RC2 (CPU).zip.7z (sha256sum: c3ddf419baf8864f8cdd6438856aa625a9d176d5a4301ceaf0246e2a299aa69a) crashes Blender on my Ubuntu 18.04 with the following error:
ERROR (gpu.shader): EEVEE_shaders_effect_ssgi_filter_sh_get Linking:
|
| Error: Input block `ShaderStageInterface' is not an output of the previous stage
ERROR (gpu.shader): EEVEE_shaders_effect_ssgi_filter_sec_sh_get Linking:
|
| Error: Input block `ShaderStageInterface' is not an output of the previous stage
I have an AMD graphics card, sometimes their drivers are too picky about the shaders they expect.
(Iām not familiar with Blender internals, currently have no idea how datatoc_common_fullscreen_vert_glsl looks to find the mismatch, wish Blender dumped the shaders on shader compile and link errorsā¦)
EDIT: I guess I can just printf it if Iāll be desperate enough to recompile Blender.
Iām aware of this issue, but Iāve only managed to replicate on a virtual machine without an actual GPU passthrough. Since I couldnāt replicate it any of my actual hardware I decided to ignore after a while. This is the first report Iāve gotten about it.
Yeah. I tried to trial and error my way through it, but I couldnāt manage to fix it without causing other issues. As a result the all the shader inputs are quite a mess in that patch. 1.13 should work fine though, iirc.
Iām currently pretty overloaded by art related work so I donāt think Iāll be able to give fixing this a second go anytime soon. I was planning to use the time I have to add features, not fixing since Iām not concerned with doing things cleanly anymore due to official solution being on the horizon, but so far Iāve only had the chance to do some occasional builds anyway. Honestly Iād appreciate any insight if you happen to look into it.
I fixed it! 1.13 crashed for me too, but I managed to compile Blender on 18.04 and fix the shaders. The patches can be found here, in ssgi folder (apply them after applying SSGI-113.diff): https://github.com/procedural/blender_ubuntu_18_04
I can send you my Ubuntu 18.04 Blender binaries with SSGI 1.13 and these patches applied for AMD cards so you could share them on your gumroad, if you want!
I fixed it! 1.13 crashed for me too, but I managed to compile Blender on 18.04 and fix the shaders. The patches can be found here, in ssgi folder (apply them after applying SSGI-113.diff ): https://github.com/procedural/blender_ubuntu_18_04
Thank you!
I can send you my Ubuntu 18.04 Blender binaries with SSGI 1.13 and these patches applied for AMD cards so you could share them on your gumroad, if you want!
That would be great! Iād love to add the build to Drive and try to update the patches on Gumroad (I canāt unfortunately add Linux it directly to Gumroad, since without making it a paid product Gumroad has file size limit that has room for one build only and Windows still seems to be the most popular platform).
I may look into it in a couple of days (currently busy too), but I started with 1.13 because 1.13 worked on Windows, unlike 1.14 that silently didnāt work on Windows for some reason. It didnāt crash, but it didnāt work, so maybe itās another AMD driver thing to investigate on both systemsā¦
Still a lot of issues to fix, before even more extensive testing. Tried out both injecting irradiance grids, but seems cubemaps work better due to higher frequency info. A lot of light leaking if things go out of screen or has to rely on the fixed thickness value. Some thickness heuristic (no clue how hard to implement) and having probes with location based sampling would fix some of it. Although using cubemaps to sample lighting info from means hands placing everything, with grids the badly placed grids shouldnt matter that much when most of the lighting is still corrected in screen space. A lot of stuff to fix, probably wonāt be many updates.
Just plain not working was an issue I ran into while trying to fix crashing in 1.14. For whatever reason the textures between stages were empty as far as I could tell, when using different set up. I think Iād need to take a step back and learn more about openGL and how it comes together in Blender before I have chance at fixing that mess. Iām pretty sure Iām making mistakes in how the shader stages and inputs are set up.
Hey @0451
Any plans on improving the Denoiser for the diffuse samples?
Having looked at alternatives like RTGI, which is a screenspace raytracer using reshade, they denoise the ssgi pass aswell but in a much more efficient way than the current ssgi method. You have a much better working ssgi though since you have access to things like normal weights etc to bring back geometric detail into the denoised samples, but atm it seems that the denoiser starts to TANK after more than 6 filter samples. i render out my scenes in actual realtime so any improvements to the denoisers speed would be highly appreciated!
The only thing I did was starting up SSGI, and deleted the baking cache (which was baked with Blender with EV Express addon).
I like the more vibrant colors, I think it is, but I wonder why I donāt have that much āGlobal illuminationā.
Is there something I need to adjust, or are there some settings? I didnāt follow the thread for a while, apology.
Update:
Ah my bad; I had to rebake the scene in Blender with EV Express. Now I barely see any difference.
@Naskomusic
Iām annoyed by the denoising performance every time I do things with SSGI branch, so itās pretty high in terms of things I want to improve. Unfortunately the first improvement Iāll try to do will do nothing for your use case.
The inner sample count is way higher than the sample count shows, combined with 2 unoptimized filters the huge number of texture samples tanks the viewport performance, doesnāt seem to affect render time that much.
What I plan to try out:
Denoise only at certain intervals or at max sample count - no performance hit in interactivity, better input to filters, so better output (could also possible get rid of the second filter stage then, so half less processing cost).
What would improve things overall: doing the blurring per directions separately, way less samples to do the same blur, minor artifacts in edges. Doing blur downscaled in first filter stage and bilateral upscale in second. Iād like to try both of those latter out also, but theyāre way bigger time investments for me, so currently they arenāt on the table at least short term. Also I donāt think without better reprojection from previous frame they could do much better overall since the input is pretty bad at 1 render sample, just could use a higher number of blur samples without tanking the performance.
@anon72338821
I think in this case the majority component is specular and like @Naskomusic said is already done by default SSR. The current publicly available versions donāt do any diffuse occlusion also, so the result can vary a lot in how you use the world lighting and probes. I would be interested in trying that file out though if you want to send it.
@BluePrintRandom
It would. But itās kind of fighting with the current Eevee overall design - itās usually assumes accumulating samples from rerendering one frame multiple times, instead of focusing on a lot more with robust reprojection.
Iām not sure if something has changed recently in master, but it looks like the 1.13 and 1.14 patches are both failing to apply for me in two files.
Hunk #1 FAILED at 60.
1 out of 9 hunks FAILED -- saving rejects to file source/blender/draw/engines/eevee/eevee_screen_raytrace.c.rej
Hunk #2 FAILED at 98.
Hunk #3 FAILED at 129.
2 out of 4 hunks FAILED -- saving rejects to file source/blender/draw/engines/eevee/shaders/closure_type_lib.glsl.rej
I ran the build anyway, and (unsurprisingly) got a segfault when I enabled SSRT in Eevee. Iām happy to provide those .rej files if they would be helpful.
Iām mostly focusing on compatibility with 2.93 since 3+ will have Eevee rewrite that will make this redundant. So sooner or later it wonāt be compatible with master. But this should be fixable without having separate patches for 2.93 lts and master.
.rej files would speed up verifying if thatās the case.