So, removing surface cache bias, disabling short range AO, enabling screen traces, and massively reducing the resolution of the surface cache? I am kind of amazed that works when put together.
This is a lazy and sloppy example but I think it shows the issues.
This link is the Path Traced and I am using it as a base for what is most accurate. Not 100% but most
This is the default settings.
This is default settings but with
r.Lumen.ScreenProbeGather.ShortRangeAO 0
r.Lumen.ScreenProbeGather.ScreenTraces 0
to try and eliminate the demon shadow effect. It works but comes with the very heavy shadowing in the seams and corners.
This is my new settings. Although after closer examination it doesn’t solve the demon shadow issue completely but that setting of yours does diminish it a lot and possibly enough for most shots hopefully.
What I did notice is with just r.Lumen.ScreenProbeGather.DownsampleFactor activated it seems to turn on screen tracing because the demon shadow comes back even if Screen Tracing is turned off.
I would love to use PT for everything but this shot took 35 min using PT and only 2 Min for each of the other ones. At 35 min I would probably just use Renderman XPU because I get about the same performance without all the complicated adjustments and the denoiser is significantly better. Not to mention this PT sampling was only 128. Many scenes required a lot more than that which would increase that 35 min to 1 or 2 hours.
1 Like
The downsample factor setting is always active, it controls the density of the screen probe spacing, larger numbers mean less accurate lighting. By default, “High” GI scalability uses 32, “Epic” is 16, “Cinematic” is 8.
Also you really should not be disabling screen traces.
Your Settings:
Default Cinematic with just Short Range AO disabled:
Path Tracer:
Guess it’s a matter of opinion but in my view… just disabling only short range AO does a much better job of matching the path tracer.
I have no choice but to disable screen traces or attempt to diminish it with my settings because it produces a moving shadow that chases the edge of the frame and fills it with darker shadowing as the camera moves. You can see it in my second example when the edge of the frame moves along the line of the ceiling seam. It’s really obvious when it gets near the corner.
About leaving Screen tracing on. I would agree is a reasonable solution as long as the camera doesn’t move. That’s where the real problem is. In my latest settings I do leave it on but I have to use r.Lumen.HardwareRayTracing.MinTraceDistanceToSampleSurfaceCache 0
r.Lumen.ScreenProbeGather.DownsampleFactor 30
to diminish the moving shadow or what I call the shadow demon and it is still not 100% effective.
Again, I am not using this for gaming so I don’t care about FPS performance or anything like that. I just need it to render offline and that is my only concern. Which means I am probably turning knobs and pushing buttons that most people would suggest be left alone and I am sure they are right but I just want to render out some animations with the speed and flexibility Lumen affords. This issue is problematic but it doesn’t always stand out as obvious depending on scene.
I know I am not the only person having this issue because I see tons of renders from other people where it exists. I know there has to be a solution or something we are all doing wrong that can be corrected.
Is there anyway I could persuade you to make a copy of you sample scene available for download? I would love to examine it and figure out why your results differ so much from mine. It would be greatly appreciated.
You may have a solution available in 5.5 in the form of Epic’s guard band feature. Basically, the MRQ can now render a small area outside the camera exclusively for screen-space effects, which gives stuff like SSR and contact shadows a more graceful transition from on-screen to off. It could give lumen the data needed to accumulate better screen-space info to avoid disocclusions like you’re facing, for a small cost obviously.
Can do whatever you want of course, but I think you’re going in the wrong direction with these settings. You say you don’t care about performance but your settings are sacrificing quality to gain performance…
Increasing the downsample factor to 30 improves performance, by worsening the spatial resolution of the lighting.
Disabling screen traces improves performance, by worsening the accuracy of the lighting.
If you only focus on the AO in the corners in a simple test scene like this, it might look like using these settings are improving the lighting, but in a real scene with any meaningful detail the overall lighting will be severely degraded, just to avoid some darkening in the corners. Doesn’t seem like a good tradeoff to me.
I didn’t save the scene, sorry. I made it only to have comparison screenshots to post. I should mention that I used the 5.5 preview version of the engine which may have some improvements to Lumen.
5.5 has definite lumen improvements. IDK if you enabled hit lighting, but I’m getting massively more accurate GI resolution, especially around corners and fine detail, so I feel like the problems that are happening with the bad AO are fixable.
I agree with @akiras, it’s kind of baffling that those settings work, because they’re all of the things that significantly reduce lumen’s quality.
For whatever it’s worth, while I’ve found that in most scenes that aren’t tests or Cornell boxes, the lumen AO is usually difficult to notice. If this is such a headache, after a certain point it’s just easier to art around it rather than changing lumen so much.
I think the main issues with AO or SSAO are the typical lots of white walls arch viz renderings where the short radius pronounced AO is visible. Like the first images posted here in this thread.
In a typical game with lots of dirty textures and rocks and bricks you will probably never see this.
But seeing this screen space AO is not accurate and just something to help LUMEN with the lack of high frequency details, it should be adjustable for those certain cases where it’s not enough or where it’s too much.
I can’t find the “guard band feature” in the MRQ or anywhere else for that matter. That theoretically sounds like something that might work and I would love to test it out. Could you point me in the right direction?
I had no idea I was reducing quality. My scene is too simple to demonstrate that. Like I said I am just turning knobs to see what works. In my test scene it worked. Well it mostly worked. It’s a bummer you didn’t save your test scene because I am certain there is some setting somewhere that I have set differently than you because my default renders with or without short AO turned off do not produce the results that yours does in 5.5. I get much darker seams and corners as demonstrated in my examples. And yes. All my settings are set to Cinematic.
@Sebastian I think you hit it right on the nose!
BTW Thank you everyone for your suggestions and knowledge.
That’s my bad, I forget that it’s normally called overscan, guard band was the industry term I first heard but it’s less common now. Means the same thing: render more of the scene than will be seen so effects like SSR, refraction, distortion etc. look better. On certain effects it can make a really big difference because you don’t need trickery to hide the lack of off-screen data.
1 Like
OMG!!! That was exactly what was needed. Now I can keep all the setting you and
@Arkiras said I should not be changing and leave them as is or set them for better quality.
The ghost demons are completely gone and the AO is looking like it should.
I knew there had to be a better solution to this than all the tinkering I was doing.
Thank you both very much!!!
2 Likes