Thanks, will install it then.
I am on Blender 2.92 (Windows 10) but I can’t install the last version SSGI Native 1.13. Anyone can help?
I’ve been putting the SSGI builds of Bforaritsts to some stress tests merged into 3.0.0 builds. It has been nice in viewport, but on Batch Render script rendering, I have encountered a number of issues with an Nvidia DLL. I have updated the drivers to most recent and still get the issue, checked validated geometry in the scene, dependency cycles on characters, image packing and optimization - etc. It’s a large file I’m working with, with up to 7 gig of ram used on peak - but it’s not pushing through a queued batch script (Windows 10, GTX 1060, 16gig of Ram).
The crash is illusive. It renders some frames, then fails on others. Frame crash is agnostic to the particular frame. Usually crashes after 2-5 frames. I am writing to EXR Full Float
Characters Lookdev Turntable_02.crash.txt (21.7 KB)
Only clues that somes lists in the crash is based on the nvoglv64.dll, which can cause the EXCEPTION ACCES VIOLATION. It has shown in the console.
I have tried Blender native 1.13 build, and custom builds with the SSGI diff 1.13, and then Blender native and custom build without SSGI. The custom builds and native work, but the issue is triggered when compiled with SSGI.
Hope this points out to something obvious, I would love to use this in production - but the stress test proved… stressful! haha
Great code though, love how it works and looks.
Download and unzip, run the EXE.
No obvious easy fix from that, sorry. I know there are potential issues with how the shaders are set up currently, and the 1.13 diff needs cleanup, but I haven’t managed to make it crash so far.
I’d like to set up similar builds to try and replicate the crash so I have something to validate against. Is just building the latest bforartists release source with a patch close enough or what would be the closest source I should use?
Just for extra clarity:
The crash only occurs on batch rendering in bforartists + 1.13 diff and not while batch rendering with standard 1.13 builds?
I’d love to try and clean it up, but I already put more time than I had under this at the beginning of the year, so I’ll have to do catch up with some other things. Won’t really have any extra time if any till atleast the second half of june. Hopefully I can still find some moments to look into it before that.
As Draise said you just need to unzip and run the Blender.exe from there - the Native versions aren’t an addon anymore, but a custom build of blender.
It’s using OpenGL only, the Cuda and Optix are only mentioned for with what options Cycles is built. So Eevee still works as it used to on any hardware.
The Unity shader looks like it could work with Eevee. I’m not really familiar with that part of rendering code though at the moment.
I think it should be possible to modify normals in nodes too using same edge detection approach as the Gumroad materials seem to use. Not sure if there’s enough control to pull smoothed edge normals off though?
I haven’t seen any evidence of a deferred gbuffer so far, so it looks foward rendered. Only time some of that is written into buffers/textures seems to be for post processing inputs. But again, not really familiar with that part in Eevee or overall. The render passes seem to be done separately.
I don’t have enough experience for that, I haven’t touched anything in OpenGL before this. It’s a lot easier to modify someone elses implementation to be more in line with how I would like it to work than to do anything like that from scratch. Also Blender developers don’t have the luxury of occasionally breaking things and functionality they don’t care about. At best I hope this can illustrate how some specific implementations of some functionality could work. I do appreciate the support!
Yes. Extra AO node followed by a color ramp node or a map range to avoiding scene AO problem.
Blender Builds with SSGI 1.13 and the custom build Bforartists with the SSGI 1.13 both crash on batch script. Without SSGI scene renders fine.
Scene was authored in 3.0, maybe that is what’s up?
I could try send you the project and trouble scene under an NDA (client project) and get it to you for June if you’d like. It’s a few gigs though.
do you think that you can render the viewport with overscan fo SSR / SSGI?
does anyone ever do 180 sphere render and then only use the center?
Ah, okay, thanks both you and Draise!
So the crash seems to be only occurring with one file?
I’d try the batch rendering script in isolation before (essentially just command line rendering for one file in this case?), but I gather there’s no reason to?
I sent you a DM about the file.
Already asked something similar: Screen Space Global Illumination for Eevee - #307 by lsscpp
Hey @0451 the 1.14 prototype denoiser is awesome!! The fact that we can reproject the normals and keep the albedo color clean from the denoiser is amazing. the only issue im seeing at the moment is the random seeding the denoiser has. rendering a still camera over say 20 frames gives u a different denoise pattern everytime while the screenspace noise stays consistent.
everything works … for me for sure
man 0451 ”svaka ti dala“ (each woman gave you) as they say on balkan
I know I’m crazy…
is it possible to get that half-res effect anyway
because although it happens in the viewport
there is no way to render it