No its not. Even the source of Lumen can argue with that.
there’s no easy way to antialias that.
It’s called hybrid anti-aliasing. I’m not anti-taa, I’m anti-garbage TAA that ghost, smear, or kill performance and that’s been done before too outside of unreal.
This is actually how Unity does it - Adaptive Probe Volumes are doing their job, placing grid-aligned probes only near geometry (with option to shift/remove probes that are inside walls so they won’t mess lighting) and very sparsely in between. But amount of issues and limitations in practice is … ouch (baking time and memory, lack of precision (light leaks; and in general the way probes with light from outside seprarated from those inside buildings - it’s one screen-space hack, often failing at glazing angles), need to manually place and arrange reflection probes and deal with their overlapping/visual bugs (they can perfectly work only in perfectly square rooms/buildings), etc):
If anything, after dealing with APVs + baked reflection probes for a while I became more forgiving for Lumen artifacts & limits because baking/adjusting stuff is so frustratingly time/effort consuming…
I really feel like anyone who has spent a considerable amount of time with any other realtime GI will inevitably come to the conclusion that Lumen’s limitations are well worth it for most games (and Nanite as well)
Yep. Everything is a trade off in quality, artist time, limitation and performance. Unreal really doubles down on getting rid of limitations and reducing artist time. With todays game market not every game developer is in a position where they can have 400 man teams working 5+ years on games. So epic is making the right bet here.
Hi @Krzysztof.N ,
Will this (or something similar/equivalent) come natively with Unreal 5? Any rough estimation, like a year, a lustrum? Anything would be hypeing!
Thanks!
Stop making Lumen GI cost more if your not even going to fix the issues everyone is talking about(tech influencers, developers outside this forum, consumers etc). Noise, splotches, unstable disocclusion.
Second time I have to see a performance downgrade for effect system that is already super slow(compared to 8th gen GI for open worlds) and overly abused in the industry.
(post deleted by author)
Testing 5.5.0 with Lumen and VR. Seeing some glitches only in the right eye (reflection glitches?!)
See video. Seems like a bug to me. Must find a way to replicate this but I expect I’m not the only VR user running into this.
In the video I’m switching between GPUlightmass streaming levels and Lumen streaming levels.
Edit: see the fix two post below this one
Those glitches exist for years now, unfortunately (no QA testers for VR…?). If I remember fine, yeah, they were happen in the right eye and in reflective surfaces, opaque or translucent. I called it the chirtmass lights bug. I even reported it, but ignored, as usual.
In 5.4 and 5.1 I don’t have glitches like these in my projects. I noticed when enabling Megalights the color of the glitches seem to change strange enough. Still trying to see a pattern and create some way the people @Epic can replicate this.
Lumen + VR is really a game changer for my work (architect) so If this could be fixed that would be great!
Edit: The glitches disappear when using the console command sg.ReflectionQuality 3. Any value lower than that and you get these colored glitches
Edit 2: Sidenote - don’t use instanced stereo or the reflection in one eye will be different
So as of 5.4 DX11 SM5 SWRT Lumen GI worked perfectly … the use case is to be able to spin up thousands of instances on pixel streaming without huge aws GPU G5 cost and allow multiple sessions per instance. Its also the last hidden gem to squeeze an “optimal” quality rendering yet still hit really responsive frames where it feels like the majority of ppl maybe didn’t know this optimization path even existed [WELL WE DID AND WE TOOK ADVANTAGE 
] (you asked what the benefit was) Our workflow entails traditional LOD groups, non nanite DX11 SM5 with lumen SWRT GI and we maintain 90FPS or higher with 4 sessions shared on average on very low spec AWS instances in our fleet. Not needing to worry about nanite software rasterization, WPO limitations, SM6 memory footprint, HWRT GPU instances or due to being a chunk loaded application not needing to worry about nanite mesh sizes made this a win, win, win all the way around.
We also have DX11 SM5 Lumen projects running on APUs and Steamdeck and it was a hidden gem for GI and awesome performance for older gen hardware (GTX cards even) I go over a quick profile between 5.4 DX11 with lumen and DX12 (SM6) as required in 5.5 and its over a 20 frame loss in performance at native res and default settings on both (On a RTX 2080ti) the falloff is far greater on lower RTX cards like the RTX 2060. I honestly think marketing and awareness could have been better here instead of ppl focusing on the heavy lift of DX12 and SM6 … communication could have been to fall back to DX11 and SM5 to get some of that performance back. Outside of the little bit of extra chaos thread cost it was pretty close to UE4.27 perf not including the lumen gathering cost which wasn’t bad at all if you used global vs detail. TSR or FSR also working here was icing on the cake to push very very low end cards over the 60fps mark. Trust me it works!
I go into much better detail in this post between each model and rhi.
Summary: Its about a total loss of 123% of the initial starting 4.26ms on a RTX 2080ti if we look at UE5.5 alone going from dx11 sm5 to lumen and 110% loss of performance in something that ran well over 120fps in 5.4 with lumen SWRT enabled.
Lumen no longer working in UE5.5 DX11 SM5 - Development / Rendering - Epic Developer Community Forums
Also a little constructive feedback… As well as a plea to please reconsider this decision? This is going to literally block us from moving past UE5.4 unless we want to take on the massive task of pulling support forward ourselves in 5.5 source (which we likely won’t). A change like this that isn’t “announced”, included in patch notes or have some official documentation other than ppl digging through forums is a little rough to swallow. Please don’t take that the wrong way … I’m just asking for a bit of empathy. No different than I know that maintaining multiple renderers across desktop and mobile is a huge burden… and one we are extremely grateful that you guys are wrangling. Just like … A little better heads up would be awesome especially when the official release notes and docs still seems to make you believe SM5 Lumen is still supported.
(post deleted by author)
I’ve exposed r.Lumen.Supported.SM5 in UE5-Main, which you can integrate in order to re-enable DX11 support. Maybe will be able to get that into a hotfix.
That said, DX12 is our main path for a long time now and has a few features like new GPU allocator, which allows to share memory between various temporary GPU allocations. It’s quite unlikely that DX11 would run faster. Most likely difference which you see is due to Nanite, VSM, Ray Tracing or some other feature being disabled when you switch to DX11. And if not, and you have a good proof, then it’s something we would want to fix on DX12 instead.
Thank you so much!
What do you mean good proof? Look at the thread I linked. If you do nothing other than swap the rhi in a 3rd person template nanite isn’t involved. You can cut SM6 from the equation entirely and then toss out VSM and Lumen in 5.5.0 release as I’ve shown there. Your still SM5 apples to apples without any sm6 supported features. Your memory footprint increases simply due to the rhi and the low level driver and hardware efficiency. This obviously is slower simply by handling a different RHIT and a larger memory footprint.
DX11 SM5 - 4.26ms starting cost (235fps)
DX12 SM5 - 5.41ms (184fps)
zero changes other than rhi results in (but why even run dx12 with sm5?)
Note: the memory footprint difference
DX12 SM6 - 9.58ms (104fps)
zero change other than lumen is now enabled since its locked behind sm6
That’s a total loss of about 123% of the initial starting ms on DX11 SM5. If I could enable lumen in DX11 I would have provided a 1:1 comparison as in 5.4 its like 65% difference with no HWRT involved in pipeline at all with DX12 vs DX11 SM5 Lumen SWRT only. I’ll be happy to follow up here with 5.4 results if you like?
While your correct in that it is features being enabled as you move up in rhi and shader models between DX12 SM5 and SM6 … that has nothing to do with the DX11 SM5 to DX12 SM5 rhi swap… SWRT doesn’t even work in SM5 UE5.5 so no lumen cost to factor in here. Nanite doesn’t work without VSM which requires SM6.
HWRT doesn’t come enabled by default in the template so that’s not a factor until bUseHardwareRTWhenAvailable kicks in for lumen in DX12 sm6.
Also… forcing this path and removing SWRT entirely just because DX12 is where your focusing is taking away the option entirely would throw out the baby with the bathwater.
Update:
As a follow up to this I just tested vulkan SM5 and Lumen SWRT does still work in that RHI however it appears to be frame locked to 60htz no matter what vsync settings you apply and even if you set maxFPS to 10000
i think this is just a mindset thing for low end developers. dx11 = cheaper to compute thinking.
i ran lumen in dx12 and dx11 with proper project configs to tick all the low end switches. no visual difference. i haven’t measured actual performance, tho. it just runs nominal 60 or 48 on my rig (i’m not pushing fps on my cpu). i think even the rdna2 gpus should be able to handle dx12 lowend. maybe there are a couple of fps to gain in dx11. i dunno for sure tho. i can only google. i don’t have a steam deck. nice to have a legacy switch tho. tbh. eases the mind. 
Nah …it’s testable and repeatable. DX12 ready cards aren’t the same as D12 optimized cards. Memory bus speed and threading architecture have a lot to do with this at the actual driver and lower hardware level. If DX12 actually ran at DX11 speeds in SM5 we would be using it… why wouldn’t we?
What does a biased belief benefit anyone who deals with stats and numbers … or let me say what benefit would an engineer gain to fabricate something and go through the effort of making a case to continue support if benchmarking showed otherwise? We can’t afford to live in some realm of “I feel this way”. Its a waste of both my time and the epic teams time. That’s why I provided such a detailed outline showing the actual “packaged” numbers and both stat unit outputs to show exactly where the cost is.
If vulkan or DX12 could provide DX11 SM5 speeds & capabilities when running in SM5 shader model, then sure rip it out. We’d be running it already. (And as of the last fortnite update DX11 is still there rocking proudly for all the DX12 “ready” cards lacking the memory bandwidth or Ampere chipsets to see its benefits)
Reputable people in this field/industry don’t operation on “mindset”… We can’t afford to.
one of your mindsets is wrong tho. why you test in the 100+ fps range? you don’t need 100 fps to enjoy a game, do you?!? neither does the broad console audience reach that without diminished graphics.
what you balling?
i have a 144 Hz panel and i trim the engine output to give me better visuals for a trade in framerate. and i vsync all of it on mostly 48 fps for my laptop’s sake. it’s a techy thing. more fps does not give you smoother visuals. the v-sync does. the frame gotta be delivered in time for your display and target v-sync rate. always been the old school hack. variable refresh my butt. it will micro stutter. it just hides behind more frames. that’s the balance you gotta achieve.
anyway…
I think your missing the point of the benchmark? Your taking number outputs and making it personal and attaching “me” or my gaming preferences to it. Again this has nothing to do with me as an individual and I’m sorry you perceived my feedback and provided data in that manner.
This is about raw ms information and the starting overhead. Larger headroom makes for easier optimizations. You are right that some tech allows for a wider curve “deferred rendering” vs “forward” base pass vs lighting cost for instance. In forward you start off fast and fall off quickly were deferred starts a little slower and falls off alot slower as lights are added.
If you go back to my original post … when you have GPU instances shared across 4 ppl keeping your individual per app instance framtime low means that shared budget is large enough to cut back on thousands of dollars an hour across an organization that spins up thousands of GPU instances a day.
I put it this way… the more optimal we can run the more ROI we can keep thus keeping Epic a partner. It really is that simple.
