Not this again.
You can already set the existing Lumen to accumulate as few or as many frames as you want, and can set the jitter width. r.Lumen.ScreenProbeGather.Temporal.MaxFramesAccumulated r.LumenScene.Radiosity.Temporal.MaxFramesAccumulated r.Lumen.Reflections.Temporal.MaxFramesAccumulated
You can also set TAA to just 2 frames if you want. r.TemporalAASamples
But you fill find responsiveness has a price, and while you can fine tune things to your project’s needs, most of the cvars are what they are for good reason.
With proper motion vectors, TAA and related tech - especially DLSS - have extremely minimal smearing and blurring. Add to that the fact that deferred rendering doesn’t really have any other viable antialiasing besides FXAA and here we are. Tech like ray reconstruction has just pushed responsiveness even more.
We’re probably a good long while before it is possible to get acceptable real time raytracing without temporal accumulation and upscaling. Your opinions regarding these techniques have been loud and clear on this and several other threads, there is no need to keep derailing this thread for points you have already made repeatedly. Particularly when your feedback is not really actionable given current technology, and multiple community members have already called out the distraction.
No one likes unresponsive lighting or blurriness or smearing. But every generation of tech has its frogs to swallow, and most of the industry and most of gamers are willing to accept the compromise.
But if you hate temporal effects and upscaling so much, perhaps use a forward renderer or turn off real time raytracing and use FXAA. No one is stopping you from making a game completely free of temporal accumulation or upscaling - you just may have to give something up to get something back.
why you derailing this LUMEN topic with a TAA rant?
what’s wrong with TAA? looks good. it’s upscaled and dlssed ofc. looks just like tsr, which is available too. and against expectations, there’s seriously not alot of aliasing on this fully dithered hair. one of those things that usually aliases a ton.
capture is 48 fps. cause 144 Hz. jsyk. in case it stutters on 60 hz.
eye reflection is working great. skin tone too. lumen certainly improves the shading of skin, compared to direct lighting. gotta get outta the uncanny valley. yo
on that note. the hair shading model is kinda scuffed. very odd illumination. it’s anisotropic or some tangent f*ckery but lit from the back it looks like crap. surely not a lumen issue either tho. more likely a weird shader.
real ordered dithering? for texture alpha sampling? i can’t picture how that is supposed to work. it’s a 4x4 pixel mask. nice size for a tensor core to smudge it. but when rendering this pattern you’d get huge artefacts instead of the lil ones that are there on a smaller 2x2 ( which i think that it implemented rn). i mean… i could actually check the code, but i can eyeball that on the cloud temporal artefacts. it’s a 4 frame loop.
and well… i think i’m allowed to insult gamers that only play and ask for things while coders like i am to some degree too try to figure stuff out. some stuff is just not practical or just doesn’t work like you think it does. alpha testing for foliage and hair and all the semi transparent stuff and smoothing that has been and still is a complex issue. back in the days we cheated the engines with rendering alphatest and doubled it up with translucent for the edges. in these day’s games with the insane amounts of foliage it’s not the most performant choice. you know?!?
simple dithering and taa and all the temporal variations gonna stay for a while.
I have encountered this issue in some different scenarios, not only when using an HDRI. I have prepared a scene isolating the issue. Obviously, this is a test scene with a very certain situation, but I faced this before in real case scenarios (which I can’t share), so a “lab” context is needed, just created in some minutes. It may be quite possible to force other scenarios within more time.
The grid is always there, I think; it’s just related to a combination of your lighting intensities, materials and/or exposures, to increase/decrease the contrast in some way, and expose the grid:
Yellow means the mesh is too small to be included in Lumen. Lumen culls small objects for performance. Increasing the lumen scene detail will keep them longer. You can also mark the mesh as an emissive light source to keep it longer (even if it doesn’t emit any light).
are you joking or trolling or wth? this needs no test, tbh. you overexposed an almost black surface to look almost white. that’s an abnormal lighting condition. at normal 0 exposure level and the skylight dialed in sun against white walls (you gotta eyeball it ofc) it works just fine and looks great. mmh
are you joking or trolling or wth? I have also included a more white scene with light materials… making it dark is just to expose it more. The previous scene I posted, with an HDRI in the background, as using white materials and completely normal values (and not, the lighting was not coming from the HDRI, but from the Sky, with a HDR image as source, which is supposed to work as intended.)
And sometimes, you may have dark materials in your scene.
As I pointed, I have encountered this issue before, in normal scenes, but I see you only read what you want and you are so happy with Lumen and its limitations. Congrats
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.
