I don’t believe this is a lumen problem, as you’re describing lightmass behavior? There are other threads that will be more conducive to helping you, lumen is exclusively a dynamic GI and reflections system, and the lumen thread generally only covers that and the interrelated systems.
Thanks, my Global Illumination setting was to Medium, that is why the engine was on the old lighting.
2 Likes
Dang man! Thank you so much for sharing that. This is the second in-depth documentation released for a new feature, it seems like I should really see how much stuff Epic has added to the documentation for correct usage. (Not a lot of stuff I saw last time I crash coursed it) Hopefully I will find more performance documentations in the UE5.2 sections, Ah hem… Virtual shadow maps.
Again thank you!
1 Like
Virtual shadow maps are definitely…interesting. They’re a strange component of the UE rendering stack IMHO because they’re really an enhancement of an existing solution, as opposed to a completely new paradigm change. Nanite altered how we can do geometry, lumen made real-time GI feasible, but VSMs are, to the point, just really high-res shadowmaps with sometimes brutal perf. characteristics. They’re obviously intertwined with lumen and nanite in big ways, but especially for open-world and SWRT-based lumen projects, distance-field shadows mixed with contact shadows seems like a much more performant solution. And since SDFs in UE5 are on average 2x the linear resolution of their UE4 counterparts, your shadow resolve can be very good.
Apologies for the rant, I’ve been looking into and profiling VSMs lately and how they interact with lumen and nanite, and I’ve been frustrated by some pretty massive and inexplicable performance drops. In the western demo scene Epic released for 5.1, disabling VSMs saves a massive amount of performance and the profiling data is pretty inconsistent. It’s weird when they seem to be costing more than RT shadows while simultaneously delivering worse visual quality.
4 Likes
You’re seeing a circle of shadows? The shadow range can be adjusted in light settings I believe.
Were you using HWRT or SWRT? If using HWRT and DF shadows simultaneously, I could see that running terribly, as you’d need two really big data structures going at the same time.
And, you do have a fair point. The great thing about UE is that it gives us so many different solutions for our various use cases, and we can choose what tradeoffs we are comfortable making.
And, you actually can use RT shadows with nanite meshes. The proxy geometry is usually good enough (for my cases at least), and there are commands to avoid the shadow intersection artifacting and pretty much get RT shadows out of the box. There’s even an experimental pipeline that lets you trace against the full-res nanite meshes directly without paying the entire price of the memory usage, albiet it’s still in development.
And, performance increase is relative to the quality you want, in these systems. If lumen’s the bottleneck? Cut down on ray count and surface cache range. Nanite somehow giving you trouble? Can tune down the streaming pool size. Virtual shadow maps even let you dial back/down the ray count for SMRT, and how it pools pages.
There is 100% the headroom to get the performance you want, as long as you’re comfortable with the concessions.
1 Like
Could someone help me out here. I am not sure what’s happening. I don’t think this is how it supposed to look but I have tried almost everything and the quality is of Lumen reflections is sooo bad.
This is what it looks like:
I’ve tried everything.
In project settings, I turned up Distance Field to 0.4. I’ve maxed out quality in PostProcess volume. I’m using Hit Light for Reflections.
There are no visible differences between any of those settings. Hit light does provide a bit sharper reflected objects but the blurring I have as I move away and get closer to objects is so jarring. Depth of Field and Motion Blur are both off.
I just don’t get it.
Is this how it supposed to work or am I missing something?
Unreal 5.2, Ray Tracing hardware enabled. Lumen reflection quality in Project settings is set at 512.
Ah, I see, thank you for explaining.
I suppose I’m curious how important specular lighting is to your art direction, because in my testing SWRT and HWRT look borderline identical on most geo situations, while SWRT is a fair bit cheaper. Image stability shouldn’t be different between the two, because they both use the same final gather and integration passes. HWRT would let you scale up to larger sizes with far-field, but your HLOD system should probably be finalized and it sounds like you’re actively tinkering with that?
Ah, I see. Your use case for shadowing makes sense.
You can also cut down on lumen costs in other ways, go to their documentation and read the performance guide. Lumen can run either pretty fast or extremely slowly depending on a the minutae of the settings, but the big thing is that reflections get expensive FAST.
That’s a fair bit for VisBuffer and Basepass, and with nanite your opaque geo cost should be more or less flat. If you have a lot of translucency or skeletal meshes, you’ll definitely want to get those under control to keep those costs low. For materials, I don’t remember what the system for that is now but you may want to do material consolidation?
I’m confused, is that meant to be the car body itself, or the reflection view, or something else?
step #1: use the path-tracer to develop a ground truth of the scene. If the scene in the PT looks bad, then it’s your materials or meshes, not your lighting.
step 2: Check the lumen scene to see if it’s really using SWRT or HWRT. If it’s blurry and blobby, that’s SWRT and there’s a pretty hard cap on how good the reflections can be.
I suppose I don’t understand what you mean by ‘blurring’. If I had to guess, you’re seeing low-res lumen scene data because your scene is largely lit by the skylight? Hit lighting for reflections requires there to be a punctual light source (actual directional, spot, point, or rect light) for it to reflect against. Otherwise, the reflections will use the surface cache to evaluate sky lighting.
thanks for chiming in… yeah it’s HWRT … it’s all turned on for best quality it should get.
I think you nailed it. It is almost certainly using surface cache because the scene is empty. I tested with a simple sphere and applied the same chrome material and it produces the same results with pretty blurred result.
The “blurring” is hard to explain aside from that photo. It appears as if the reflection is causing it and bleeding out so it appears as if the mesh is blurred as well.
I’ve played with distance fields and all that and nothing but in the end I think it is exactly as you said. It looks bad because there’s nothing in the scene to calculate against.
The funny part is that same car looks pretty ■■■■ good in a garage environment I made for it with heavy lighting with rect lights and similar and also have like multiple reflection capture spheres as well.
So that’s almost certainly the reason why it looks bad. I’m happy now though, I’ll revisit lumen reflections again once I place the car into an actual city and street lights and in closed spaces again, I have Raytracing working now at 100+ fps with great performance for a drivable demo I’m building.
1 Like
I’m with you, that makes sense. What you could do is play around with how the surface cache atlas is capturing your car and increase the resolution, along with improving lumen scene lighting in the PPV. If you do that, you could see noticeably better results.
The reflection captures won’t interplay with lumen, as they are static and lumen is strictly dynamic. The big thing I think of is that lumen can handle GI extremely well, but the more specular you go the worse it can look.
That is an excellent suggestion. I forgot to actually look up surface cache.
I mean I’ve been dealing with Unreal for like 2 weeks so I’m still picking up stuff as I go along. But I’m getting the hang of it slowlly.
I’m really happy with that parameter with raytracing though. It looks absolutely stunning with it now. So I will try to rock it for what I’m doing just for reflections unless I start getting major performance issues.
Not building a full blown game just some driving solo through environments and some cinematics. So I think it should be ok.
But I am still learning the ins and outs of Lumen and how much I’m limited but in general
actually fantastic especially with GI.
I fixed Lumen!! 
That’s Lumen GI and Lumen reflections…
Someone actually told me on Unreal discord. I would have never found this on my own, holy sh***
That fixed it.
r.Lumen.Reflections.Temporal 0
3 Likes
You could try to mix SSR with Lumen GI/rough reflections. In 5.2 you can disable Lumen reflections with “r.Lumen.Reflections.Allow 0” and it should fall back to SSR. This is what we use on FN to scale down Lumen on XSS.
2 Likes
While I don’t quite know how to address all of your post, I’m curious what you mean by realistic specular value. Do you mean PBR, or something else?
UE’s old SSR has a very recognizable visual look, because the medium setting of it forces reflections to mirror, and it’s pretty low-res anyways. The new SSR implementatation (which may be out of your budget alas), uses HZB tracing and is way more high quality, if you’re willing to take a bigger performance hit. That ‘wet’ look may be coming from all reflections being forced to mirror.
I am curious though, does your world have to use lumen? Lumen and nanite are bundled together as the defining technologies of next-gen, but nanite removes a significant performance roadblock wheras lumen adds one in a big way. Real-time GI is very expensive, especially at an acceptable quality.
Could you use GPU lightmass instead? I don’t know exactly how/if epic supports this, but even a meshless solution of some sort like an irradiance field? That will cut down on a significant cost that lumen imposes, and you can still use SSGI and DF indirect shadows for dynamic objects.
Furthermore, UE5_main supports lumen reflections with GPU lightmass. Since you’re not carrying the cost of the surface cache either, you’ll also save VRAM. Since it’s meshless as well, you don’t even need the VRAM on developer hardware to hold the full-fat nanite meshes in memory in order to render it.
mix SSR with Lumen GI/rough reflections.
Yes we are already planning providing this as an option given how well SSR brings back photo realism for Lumen GI with no reflections in a city environment. We’ll see about what we’ll do when we get out hands on a devkit for next-gen consoles.
Ah, I see. UE’s materials pipeline is complex to say the least, especially with new systems like substrate and the like. But as someone who knows a small amount about real-time materials, I can that ‘realistic’ and ‘cheaper to render’ are usually on opposite sides of the optimization spectrum. Realistic means putting more research and time into designing materials that account for more real-world phenomena, or straight-up programming shaders to get specific effects in. But those are often more expensive than using whatever’s simplest and out of the box. Game development is a game of sacrifices, and you can have almost anything at the cost of not having a lot of other things.
Ah, I see what you’re saying. So, dynamic lights, but not necessarily a dynamic geometry? It sounds like you don’t have any graphics programmers on hand atm, or a marketplace kit that could solve the problem, but there are systems of blending between pre-baked, static lightmaps that can often work relatively well in certain open-world systems (basically what you have for cubemaps but for GI). Irradiance fields refer to lightmaps where, instead of being encoded in textures, you encode lighting in probes that can light whatever geometry is there quite nicely. It also lets you get away with more dynamism than lightmaps alone.
Distance Field indirect shadows are a little-known feature in my experience. Basically, on a per-mesh basis, you can assign dynamic objects to have a distance field, that lets them interpolate lighting from GI probes, and still shadow and occlude correctly. It basically lets you have dynamic objects in a baked lighting scene without them looking out of place. Since it’s operating off of a mesh’s SDF, it has nothing directly to do with nanite.
Unless it’s been changed, I don’t recommend using these together, when I tried combining SSGI + DFIS in UE4 it had a bunch of issues, off the top of my head:
- It multiplied the shadows from SSGI and DFIS on top of eachother resulting in very dark indirect shadows
- Using SSGI at half-resolution would only render DFIS to a small corner in the top left of the screen
I reported these as bugs, never got a case number. I just assume the two features aren’t meant to be used together.
Also just a word of caution about DFIS: The shadows can leak through walls.
2 Likes
@Chosker implemented something like this for UE4:
I was able to pull the original github link out of the wayback machine: https://github.com/Chosker/UnrealEngine/tree/4.26
But can it blend different GI maps for different hours of the day? 24 maybe even 48 layers of cubemap lighting?
Did you look at the thread?
For whatever it’s worth, I toyed around with using a movable directional light with a shadows-only stationary skylight to get dynamic time of day with baked lighting. I felt like it could work well.
1 Like