i dug out the scene i first artefacted/“motion wiped”. this is with megalights and 4 area lights on top. it’s defo not the gi disocclusion that is breaking. i don’t have much ao or screenspace fx in this test scene. nor far objects. so… i dunno.
fps is locked to 48. you need a 144 panel to watch that smooth, sry.
ima chil on this one. don’t wanna test all nite. : )
xtra shot tho. yes… it does indeed artefact like 250 meters away. barely has any surface cache coverage, back there. and limited probe grid resolution. yo
okay. i dunno about all those setting, tbh. the shot i took is with stock lumen gi settings. just hit lighting for reflections and screentraces disabled. (i don’t like screenspace reflections : )
maybe it’s just the simplicity of the test scene. the setup is not asking for much cache coverage. in a detailed scene with detailed building models this may look different, for sure. i didn’t test that. hmm…
Are they yellow in the surface cache view? With buildings assembled out of modular meshes you need to be using the raytracing group ID or ISM card merging in order to keep the surface cache from getting culled, this is what Epic did for the Matrix demo
Yes, I’m using Epic Games settings from the Matrix demo for culling, and in any case, the ray tracing mode is not my priority as it’s too heavy and demanding in terms of performance even with a 4080.
For me, the cache has never worked well. It works fine when there’s nothing in the scene, but as soon as there’s a lot of stuff, it’s not very effective.
This is how the surface cache should behave with large meshes that are assigned the same RT group ID (or are ISMs and Lumen ISM card merging is enabled, which it is disabled by default)
The surface cache of the grouped meshes stays all the way up until the end of the global distance field, while the individual instances are rapidly culled.
r.LumenScene.SurfaceCache.MeshCardsMergeInstances 1 does provide more caching over a larger radius. Unfortunately, it doesn’t help at all with the occlusion/de-occlusion issues.
I don’t have a good working knowledge about how Lumen works, but what if this phenomenon happens because the foreground objects - exemple trees - obscures and hide polygons in the far away objects. This might cause a redraw of polygons, shadows, AO, when the view changes.
How can we prevent this optimization step ? In this way you don’t have to exclude trees from Lumen or GI, just prevent them to hide away polygons or shadows. If Lumen does not allow this, a workaround might be to make the trees 99.9% opaque, in this way the Lumen (or Nanite) will be forced to render the background objects fully at all time.
I’m not sure if this reply is to me, but I said - maybe using 0.1% or 1% transparency for a few more prominent trees might hide the issue - without losing too much optimization, since the overdraw caused by those trees might not be too much.
