You are not following the instructions then, but ok.
It’s not an artefact hapenning only in movement. It happens when staying, never cleaning! (In fact you can notice it in your video, before you start moving)
I will make a more evident scene centered only in this issue…
PS: so, is it ok that virtual shadowmaps resolves with huge blocky noise? It should be clamped by itself if it can’t handle it, not needing the user to change every light source radius. (With 25 is just more visible and evidentiate it, as some people don’t look into details, but it’s still quite visible with a value of 2 or 3, which is working great with RT shadows, so those could be considered real values, if you want them).
PS2: This is a different story but, is it also acceptable for you that you need to recompile 7000 shaders for a totally empty project? (Even more if you already opened an exact project before, which could be cached or something)
DONE. I have taken an old scene where I already noticed this 1 year ago:
I hope you can see it clear enough here:
And an additional issue, even if not gone deep into this. It seems that there is some kind of incompatibility with the Megascans material (something in its coding). Just modified the main material to take a white texture (right, unshadowed), and created a new basic material just with the same white texture (left, shadowed):
so… it’s not a general source radius issue, but incorrect direct lighting. while this issue could/should maybe be fixed, it’s up to the artist to not overexpose it and use common sense.
Hi @jblackwell , thanks for the quick reply. I’ve just set r.raytracing.nanite.mode to be 1, and the lighting didn’t change.
just another question, I’ve two pieces of 3D rocks(non nanite mesh) on top of each other, without ray trace shadows on. is there something i could do to improve the lighting? thx,
Can’t we use the (supposed to be used) source angle of Directional Lights? Nor the Source radius of other lights? Even with low values? Great!
Please, READ what other users write. I also said that a value of 2 or 3 is clearly visible too, and those are realistic values, as you can check in the shadows visuals, if you observe real world shadows of Sun… But it’s also visible within the default value (0,5357), even if it’s too low!
But let’s look at YOUR own screenshot: Please, pay more attention to your own tests…
And it’s less visible here because of the compression of your image:
Anyway, I already posted a screeshoot with the default Source angle value too, where the effect is the same, just check it, thank you.
Let’s be less conformist and stop posting comments like “this it as broken as it’s intended to be”… That’s not a useful reply.
Please, could someone else test this scene too, to know his opinion? Maybe the mistake is mine.
first of all source radius on spot lamps and probably point lamps (untested rn) are fine.
and directional light programmaticaly has only one direction. the source angle is already a mathematical cheat.
it doesn’t make much sense to raise the angle above the normal angle, which is a calcuated irl metric based on the sun to earth distance and diameter relation. unless you aim for an alien planet surface where the sun is larger or closer, it makes no sense to raise it.
also… while those blurry shadows may look fancy it’s not natural. the fuzzyness of contact shadows is a result of light breaking on hard edges and the ambient light around the sun. that would be physically accurate. just put your hand on the wall on an overcast day. what creates the shadow? the ambient light, not the direct sunlight. you know?!?
either way… we a lil further away from that sort of accuracy. you still shouldn’t cheat. it’s immersion breaking and breaking lumen to some degree too. those lil artefacts, while disturbing a lil sometimes, are peanuts. no need to be too picky about it, tbh.
So, my first question is, what are the results the path-tracer gives you? The PT is the most correct lighting solution in Unreal, and if your problems are still showing up there, you know it’s not an issues with your lighting method.
As @ZacD pointed (thank you), higher angle values are usually used for cloudly weather, for example. The 0.5 value is for a perfectly clear sky and atmosphere. Do you have a lot of days of this kind in your countries?
But do you want this same issue with point lights and/or spot lights, even if you weren’t able to recreate it? Don’t worry, here you are: (I have updated the same link with this 2 additional scenes Dropbox - Lumen_source_radius_artifacts.zip - Simplify your life)
what you tryna proof? this smart assing is not solving anything.
and well… i’m trying to figure out howto natively blur the skylight for the overcast scenario. atm
shot: world scale setup. skylight from the back. point lamp and spotlamp with radius. the building in the back obviously casts the proper distance softened shadow without breaking the sun lamp. no artefacts anywhere to be seen.
@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…
