xcuse me. i don’t need or want to argue, but you delivered a bogus test case. what you tryna expose? you calling limitations will put you in a box on my end. negative.
exposure is the last thing you touch when you render. lighting first. it this other scene of yours a similiar setup? same cranked exposure? your fault, then.
and yes… i’m quite happy how lumen performs. it has some kinks and flaws, but if one knows howto deal with it and set it up, technically or artistically, it delivers nice results.
Thanks for your answer… I tried many things with this mesh but the problem is still with me… Looks like there is no any good solution for this kind of issues in UE5.
Hi there -we’re seeing strange reflection glitches in 5.3 which are not seeing in 5.2 or 5.1.
Wondering if anyone else has seen these, or this might be a known issue/change since 5.2?
Here’s some examples:
Example video 5.3 (aliasing reflections) in ORIGINAL PROJECT LEVEL
Lumen HWRT Reflections of narrow geometry in water show aliasing glitch in this version. Not in previous versions of Unreal.
Example Video 5.3 in a CLEAN LEVEL
Example Video 5.2 in a CLEAN LEVEL
Current Settings:
Hardware Ray Tracing - On.
Lumen HWRT ‘On’
Reflections: Lumen
In 5.1 Lumen works with 2 players in splitscreen, but is disabled for all players when i start adding a third player. Is it the same in newer versions of the engine ? I wish we can play up to 4 players in splitscreen with Lumen, it really makes beautfiful lights !
I noticed that hit-lit reflections don’t appear to support screen space derivatives(?), and so sometimes I find mirror reflections to have a lot of grainy aliasing, especially in motion. There are some cases this can be resolved by just manually biasing mips using the pixel depth or something for RT only.
It’s hard to show in a screenshot but you can hopefully kind of see what I mean here, but I recommend just trying it out:
The left image is the default reflection, the right has a manually depth biased mip. I didn’t spend too much time on the transition but it should still get the point across.
Is there any possibility of getting automatic mips in reflections?
Hi, I’ve been trying out the new Nanite feature on the landscape, displaced rocks through the material and adding some 3D rocks on the top, I’ve got a couple of lighting issues:
the displaced rock’s lighting looks very different from the 3D rocks.
additional question. does Nanite landscape work with ray tracing shadow? I turned ray tracing shadow on the directional light, it looks a bit broken, is there a fallback mesh or something for generating shadow? if so, could I change the tesserlation to be higher?
I (kindly) suggest you find a different thread for this problem, as nanite displacement+ direct lighting isn’t really a lumen issue. That said, I would utilize the nanite and ray-tracing visualization modes to see what geometry is being created; furthermore, do you have r.raytracing.nanite.mode set to 1?
A workaround could be to use virtual shadows even if they are much more limited that RT ones, but they are also quite glitchy. Look at the little blocks in the last wall:
may i ask… what’s your exposure and contrast setting on this one? at ev 0,0 it doesn’t look like that. even if i lower it to 2,2 i don’t get this result.
I have only enabled Lumen with all its settings, as HWRT and SM6 for virtual shadows, and all lights as movable. As you can see in the defaultengine.ini, I also disabled autoexposure and exposure bias. Nothing more regarding exposure.
But I have seen Lumen, a lot of times, change it’s brightness just when going to a diffeent map and turning back. And recover it’s original appearance when reopening the map, or something like that. But I haven’t recogniced the exact behaviour so I can’t report it, as it’s quite random.
PS: I’m opening this scene again now and I think it’s looking quite brighter now (?). But these differences don’t interfere with the issues I’m pointing out, as they are still visible.
I have quickly created the scene with fixed exposure and the project settings, so we can use the same scene (try to superpose the edge of the cube over the shadow on the vertical wall): Dropbox - Lumen_edge_artifacts.zip - Simplify your life
and this is a normal temporal artefact lumen produces all over the place. it’s nothing to write home about, but that’s how it works and resolves light propagation and stabilizes.
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.
