@Daniel_Wright@Krzysztof.N I consider this relevant enough to warrent @ ing, apologies if it’s a distraction: I’ve been doing some set design work lately, and as I was submitting high-res screenshots to my lead (first time I’ve actually used high-res screenshots and not just regular screengrab or MRQ), I noticed that they all seem incredibly noisy and fizzly, like lumen on frame one sans any accumulation.
Is this behavior you guys are aware of? Is there any sort of mitigation strategy? I like being able to grab high-res screenshots without the hassle of MRQ, but it’s also something I’ll avoid in the future if it breaks lumen.
Also, I’m reasonably sure there is something broken with r.Lumen.Visualize.IndirectDiffuse? When I enabled it, I very clearly got a specular signal coming through, although I could get rid of it by simply disabling spec entirely in the lighting components menu.
How do you mean, default settings? If the PT gives the correct results, and you have RT shadows configured, they should give approximately the same result. The difference is so dramatic as well; out of curiosity, what does the ray tracing debug-triangles visualization show you?
sorry for not making things clear, I’m fairly new to Unreal. The first two images are PT(1st) and RT shadow(2nd image), They both look fine. the last one was default lumen setting without raytracing shadow. is the lighting suppose to be like this? or have I done something wrong?
Except PT, which is a whole system, shadowing is an independent system of Lumen or other methods, so if you are nor using RT shadows, nor virtual shadowmaps, you will use the older UE4 system, cascade shadowmaps, which are low quality and need much more tunning you will need to study: number of cascades, other extra parameters and complementing it with contacta shadows and/or distance field shadows. It will be a longer knowledge path to through, though
I think this is something of interest for a lot of people, maybe for everyone. To avoid the hassle of setting up MRQ everytime you want to see a single screenshot of high resolution. Because the high-res screenshot function does not lead to the same result as MRQ.
I’m guessing since Unreal is so capable and easy to script, we could probably setup a system, maybe with blueprints ? where we could press 1, 2 clicks and automate MRQ to get screenshots.
So, from a n00bs point of view insofar as Lumen, this scene doesn’t look correct. Totally willing to admit I likely missed a setting, but it seems the global part of illumination doesn’t apply to a surface I cannot myself see? The backside of the cube should be illuminating the land? Cube and sphere both have mesh-distance fields generated for them.
Also, from the point of view of the sphere, the sun/light is behind the land, a virtual heightfield-mesh (landscape is never drawn in main pass) and the heightfield-mesh doesn’t block light? The cube does tho. Things are set to two-sided as well…hmmmm
Just to my eyes, it doesn’t add up? I feel like Summer Smith when I say “What am I doing wrong??” I haven’t really used it before owing to the cost, and turning it on to make my system crawl. Playing around and I am unsure of the expectations here…
The heightfield-mesh doesn’t cast a shadow regardless if I am using Lumen or not, a plain spot/directional light, so I would think that is just a bug (or if that thing is not expected to cast a shadow? and if so why are such settings exposed?).
I know tone doesn’t come across well in text, no angry or frustrated, just confused…
I think the first thing I would check is what your lumen visualization modes, especially the surface cache, are telling you. If you don’t have objects in the surface cache, they won’t bounce or occlude outside of screen-space, which could definitely be the cause.
That said, it looks like your main problem is primary occlusion, not indirect occlusion. I had a similar set of circumstances when I was fixing a VSM issue; although I must admit it’s strange to see pixel-perfect GI and obviously broken direct lighting,
My expectation, given it is shadowed (normals) and has options to cast a shadow that it’s simply a bug, but again, unsure of expectations on the heightfield-mesh.
Bummer too, as compared to a landscape, you can do a bit more with the fact the 'mesh is driven by a widely-accessible Runtime Virtual Texture, and seems to be more performant. No collision which is kinda sad since it’s the one thing it doesn’t provide, but one would expect lighting to work…
Hmm, out of curiosity, what does the path-tracer show you? That will at least let you diagnose if it’s a lumen/lighting issue, or something else at play.
don’t quote me on that but i lean myself out of the window and question if lumen can generate mesh cards or distance fields for runtime meshes. would make sense why there is no surface cache for the terrain.
landscape is static data. runtime virtual texture sounds like it rendered “live”. has no pregenerated data. like colission. that is obviously missing too.
It does respect two-sides in the material itself. I can move under the 'mesh and see the material being rendered…
I really don’t know much around the expectations with regards to the 'mesh since it’s experimental and there is little documentation. Whatever is broken, it’s still broken in Lumen tho. As far as Lumen, I really just turned it on, so insofar as idiot-proofing, I am that idiot…
Is your landscape not casting a shadow? I haven’t touched virtual heightfields so idk the usual workflow well, but I assume you could still have the underlying landscape cast it’s shadow of the VHM isn’t.
Hi all! I’m doing some cinematic rendering in the matrix city sample scene. Currently I’m still in 5.0.3, which is what I was using around this time last year to render a similar scene, but I was getting a ton of this artifacting with Lumen GI. Is this fixed in Unreal 5.2 or even 5.1? Don’t want to download 5.3 for bug reasons and don’t want to download any new version until it’s for sure fixed.
