Is Lumen more performance heavy than old dynamic lightning or less?

Imagine a scene with a big hall, there are thirty Rect Lights.
a) Lumen is off, no static lights, all lights are dynamic
b) Lumen is on, no static lights, all lights are dynamic
What is more performance heavy, A or B? I’m not asking what would look better, I’m only interested in performance. Thanks

Assuming all variables are unchanged except switching Lumen on; B will be significantly more expensive, by a wide margin.

Lumen has all the same costs as regular dynamic lighting (as I understand it), plus a lot more.

By wide marging Akiras means.
Turn on Lumen = get 2fps.

With lumen’s new direct lighting solution, I’m not so sure. They’ve cooked up a many-lights direct shadowing solution via lumen’s screenprobegather that (according to their numbers) is cheaper than shadowmaps, DF shadows, or VSMs. Low-scalability lumen might be cheaper, actually.

Lumen has direct shadowing now? Where can I find this?

Shouldn’t be that bad (assuming they’ve got a gpu that meets lumens requirements)

Github, UE5 Main. Not available in the current release, but the performance numbers are already looking quite impressive. I’d expect it in 5.1, they’ve outlined how it has clear limitations, but it’s in active development. From my understanding, I think it might be Epic’s answer to ReSTIR, with the ultimate goal being cheap many-light sampling.

Do you have a github commit or something I can read? I am already on ue5-main (compiled yesterday), but I’ve seen nothing like what you’re describing.


They’ve overhauled many of the limitations already, but this was just the usf I could find documenting it. I’ve yet to try it out but it looks promising.

That being said, I’m unsure about results. Even Nvidia’s RTXDI yielded pretty bad results for not much perf gained back when I tried it out.

1 Like

Thanks man; I appreciate you digging it up for me. I wouldn’t say it’s very usable right now. But I’m glad to see the effort being made into make Lumen scale down.

1 Like

Jeez, you’re right. RTXDI wasn’t great in motion, but it would converge on ground truth in a handful of milliseconds. That is visual soup. To be fair, RTXDI has been in the works for three years, and LDI (lumen direct illumination?) for two months. I agree, they’re clearly trying to make dynamic GI with acceptable quality fit in a small frame budget. And candidly, while I am amazed at how far they’ve come, they’ll still need a bit more work I believe. Amortizing direct lighting costs into lumen is a very clever scalability trick.

1 Like

Could you do a distance field visualization? I’d like to be able to see how LDI is casting shadows as it relates to the scene it’s actually basing them on. I’ll bet when they get around to adding support for hardware ray-tracing, quality will be more acceptable.

1 Like

Top: MDF
Bottom: GDF
(obviously, heh)

Here’s an on/off with the lumen SDF scene (in case thats what you really wanted)

Either of you experimented with CryEngine?
I suggest everyone give it a go.

Their voxel based ray tracing is likely the best/performance ok solution out there.

I seriously doubt Epic will ever manage to come close (when they seem to focus on other things instead of real rendering for game applications)…

That totally answers my question, thank you. I was wondering where the error in the shadowing was coming from, and it seems clear that it’s a product of the inaccurate distance fields. GI could use the GDF or lower-res bricks, but it seems clear that direct lighting would need the highest mip of the mesh distance fields to get results that actually match reality.

It’s been on my list to try, but I haven’t gotten to it. I’ve seen wonderful things though, very good results.

And I wouldn’t be so sure, nessesarily. Lumen has often eerily matched up with the path-tracer, I think it needs more R&D certainly, but they’re on the right path. Besides, the last time I checked in about Cryengine, it had its’ own limitations. I didn’t find the different voxelization modes very intuitive, and none of them seemed to offer the same full featureset as lumen. Not to mention, they had analytical occluders, essentially manually-placed distance field volumes to my knowledge, which requires manual artist placement to get good results.

Multiple competing solutions are good. It’s how we march forward on progress, and all the different solutions out there contribute to that.

I haven’t tried it, I’ve been spending a lot of time in Godot 4 lately but it’s realtime GI is pretty challenging to get good results from. I’ll have to find some time to give CryEngine a go, The Hunt: Showdown looks very nice.

That being said I don’t see myself switching engines any time soon. I really like Nanite and although Lumen is really heavy, it still offers the best realtime GI that I have seen to date so I’m happy to see an effort to scale it down.

Much as I can appreciate the necessity to invest in solutions that don’t involve more manual work, I would rather have a manual solution than none at all. Encountering a problem with no solution means you have to design around it, which isn’t always fast either, but that cost is hard to quantify.

the question is a bit tricky because you are comparing apples and bannas, The point of lumen is to work with nanite. without nanite you get performance drop. Is stated at the link bellow, in the section “Large Worlds”

Lumen does not require Nanite to operate, but Lumen’s scene capturing becomes very slow in scenes with lots of high polygon meshes that have not enabled Nanite. This is especially true in scenes if the assets do not have good LODs set up for them.

Well yea. You have to code your own render targets system too, but the perfoemance gets to 224 fps at 4k on a near empty scene (3090).

Epic has been letting the performance ball drop for years.

(Physics) Chaos - 70% or much more less perfomant than PhysX.

Rendering - 20% fps drop between versions with no explanations or fixes.
Plus, they insist that lowering your resolution is a solution to the pefromance problem; this is quite obviously beyond the realm of stupidity and delves into the realm of really having no clue about your job.

Theres many other things ue4 or 5 can’t do and have to be hand coded too.
And there are things coded in the engine, wich are so badly coded they need to be rewritten.

Theres things you have to do manually like tick aggregation that other engines do for you, etc.

In the past, picking unreal meant choosing to have a better looking scene.
Today, it means being barely able to reach 60fps at 4k without a major visual difference…