Nope, per the developers on the live stream it’s a hacked view to give an approximation of what lumen is doing behind the scenes.
Hi there, thanks for the advice. I followed it, but this still doesn’t fix the issue. As you can see from the render below, even a “Final Gather Quality” setting of “64” doesn’t solve the reflection flickering (you can particularly see it on the the reflective parts of the filing cabinets, like the handles).
What other option would there be to get rid of this? Thanks for letting me know.
Lumen Reflection Quality, set to 4
Lumen Reflection set to Hit Lighting for reflections
Lumen Scene Detail set to 3-5
Lumen Scene Quality set to 3-5
1 Like
Thank you, works flawlessly now!
Hi , this might not be possible, but would there be some way to automatically subdivide models that aren’t already modularized, that way it ‘just works’ without needing to build things properly in our modelling software? I’m imagining something akin to the new world partition system but at a much smaller scale. No idea how that actually work though.
Many of the models we work with (I’m from an architecture background) are giant masses of interconnecting walls and floors etc., built in Sketchup or Revit, and there’s usually not an easy way to subdivide these into pieces.
The irony of course is that lumen and nanite are both designed to eliminate tedious frontwork like creating LODs and baking lighting - and by all accounts they’ve done that marvelouslly - but here’s a case where things are actually a step backbards. Two steps forward, one step back I suppose. 
1 Like
Yes, exactly! While Lumen removes the need to have non overlapping UVs for light map bakes, and having to wait for light map bakes to see the lighting, and not being able to have the lighting dynamic, it replaces this limitation by a far more laborious limitation of having to modularize meshes which are more often than not just straight up non-modularizable.
Modularizing large arch viz buildings is way more difficult than running the mesh through some automatic UV mapper and packer. Especially given the fact that the modularization is straight up useless for anything else than the Lumen cards, as the user almost never intends to reuse these modular blocks to create different buildings.
So in this regard - the workflow efficiency, the Lumen was one step forward and two step backs. Well, partially… If you use hardware ray tracing, then you are fine. But for SW ray tracing, which many people are still restricted to, Lumen is often just not feasible or doesn’t provide anywhere near the accurate results, as, more often than not, people just can’t modularize their archviz models, it’s just not feasible.
This is not even restricted to archviz to be honest. Even in game development, certain single purpose meshes are often not worth modularizing, because of additional work without no gain in flexibility in the end.
So what would be interesting idea, is to have some advanced algorithm, which would take the more complex architecture mesh, dice it into smaller chunks using some 3D grid and some heuristics, create a 3D array grid of implicit lumen scene actors internally, each of which could use that 30 card limit (or whatever it is). Instead of applying the limit to the whole complex mesh.
I was also wondering if it would be feasible to use UV space for lumen cards generation. For example:
- UV the mesh using the box projection
- Keep discarding the small UV islands by their face area until you are left with the lumen card limit amount of the largest islands
- Transform these islands’ UV positions back into the world space, and use the bounds of each of the largest UV islands in the world space to place the lumen cards.
1 Like
Hot take:
- Lumen completely changes how we should work, from the very first step of work, to the end.
- Lumen is not for everyone.
- Lumen needs to be “catered to”.
- Lumen (Software) is a stopgap-solution (until RT-Hardware finally gets good) and will disappear at some point.
Some projects simply should stick to baking and/or HW-Raytracing.
There really is no reason to slap Lumen (with its limitations) onto a use-case that doesnt meet the needs of Lumen, especially not when there are established alternatives.
Meh, even my game (which was already built from modular pieces, for ease of use) had to be turned upside down to work well with lumen, and the game pretty much was a “best case scenario” for lumen to begin with. And even now, half a year later, I am having “arguments” with Lumen (and Nanite) about certain things…
Reality is: Lumen is great, but many use-cases will have plenty of trouble with it. (I would even expect, that Lumen will have a visible effect on how future UE5 games will look, simply due to the limitations.)
1 Like
At least the slicing part should be possible, since the UE5 Editor provides those new modeling tools. And there are already the two required options available.
First to create a box, which will be used to slice a mesh into segments. Second the MeshCut option, which uses two selected meshes to cut them.
It creates a new third mesh, which is the difference between the two meshes used for cutting → the chunks for Lumen.
You then just have to delete the box, since in my tests so far, the box is left with a hole in the shape of the cutout, so to a new box is required for every new cut. But that should be easy with a loop.
Create new box at start position (save that position), select box and mesh for MeshCut and apply the cut, delete box, apply offset to the position, so that the next box will be created in the next cutting position.
Repeat until the whole mesh is chunked (maybe by using the object bounds as area, that has to be chunked).
If f.e. the Blutilities have access to those tools, then it should be not too hard for a coder to create a Blutility solution for the Editor, until an official box cutter or slicer exists.
A test with manual box creation and cuts, chunks colored for visibility:
Too much skylight in raytraced refractions.
Hi there. I’m really enjoying UE5 and Lumen. Thank you so much for this forum.
However, I’m having a problem with too much skylight in my raytraced refractions. The only way to get rid of it, is to turn skylight intensity to zero, which breaks the refractions altogether, but even at the lowest of intensities it’s too much. I’ve tried everything for weeks. To replicate I started with a “blank” games template, Blueprint, Raytracing Enabled and Starter Content. In the supplied minimal_default map all I did was ensure that Raytracing refractions were enabled. GI and Reflections are Lumens. Translucency is Ray tracing. Then I duplicated the existing in-scene geometry and moved it to create an entirely closed room around the glass statue. There are zero light leaks, but as you can see, the glass statue is emitting light. In the final image I bumped up the Skylight intensity and it caused the glass statue in the closed room to emit like the sun. I can replicate this with simply a glass sphere inside a cube. FWIW the base_color of the shader contributes, so when the walls are black there’s zero effect.
Any thoughts? It’s driving me crazy. I feel like I’ve done everything.
I have an RTX 3080 FWIW.
Love to get some help on this and thanks in advance.
Turn off Raytraced Reflections in Skylight
You will get only background reflections and other direct light reflections on glass. But It just works like that
Thanks Andre. I did so. It helps, but not completely. I still have the effect in the closed room. Here’s with skylight intensity set to 1 and 6 respectively. Any further thoughts? In my personal project I have glassware in shadow and it’s glowing…
Any advice on how to bring back some of the subtle detail our substance textures gave us on our floor tiles in UE4. UE5 with Lumen, all the subtle contrast between the roughness and metalic in the texture is lost. We can get some of it back by switching to standalone ray tracing in the reflection section of the PPV but the the programming team really want us to stay within Lumen for performance reasons.
1 Like
Lumen, without using Nanite, is usually even worse (in terms of performance) than pure Ray Tracing.
PS: I don’t know how to solve that Lumen issue, sorry.
Lumen doesnt have higher performance because Nanite is enabled, no Idea how you come to that conclusion.
I also highly doubt that RTGI+RTReflections are better performing than Lumen in software mode - because, if that would be true, Lumen wouldnt exist in the first place.
Of course, I dont doubt that very high poly meshes will cause trouble for Lumen without Nanite, because thats what Nanite was made for. (but your usual game mesh, didnt see any effect here.)
You can check my post here: 'Raytraced-Lumen' better and faster than 'full' Lumen?
(Maybe there have been improvements since 5.0.1)
hmm, thinkint about it, it makese sense - but only if you have dedicated RT hardware (that doesnt suck… cough AMD cough)
Of course, with Software Lumen the shaders are used for the calculations, but with RT-Lumen the otherwise unused RT-Hardware should be used.
On my 6900XT though, I lose 30% of my FPS when using Raytraced Lumen, but meh, guess I will just put the option in.
PS: I was still thinking about the old RT-GI, which is unused now, and performed a lot worse, my bad.
Lots of discussion about the performance issue. I understand I mentioned this in the post, what Im really trying to solve first is the quality of the image and how to get my subtle details back that existed in UE4 and in the PBR roughness and metalic portions of my texture. Whys is all the detail getting blown away and how can I fix it? thought pointers or places to look would help.
1 Like
If you’re referring to losing fine detail in rough specular reflections, then I can answer that:
Lumen image quality works well for near-specular and near-lambertian surfaces, so if a material is either perfectly reflective or diffuse, it resolves really neatly. For surfaces in between (around .4 or so), lumen can’t denoise those rays effectively, so it tends to either clamp that fine detail away (which may be what you mean), or it gets really noisy.
There’s a command that lets you adjust the threshold that the fake rough reflections kick in, ‘r.Lumen.Reflections.MaxRoughnessToTrace’, and give it the value you want lumen reflections to trace against (E.G, giving it ‘1’ will mean it will trace rays against totally rough surfaces and basically disables it entirely.
Unfortunately, there’s no real solution for the noise that I know of. Beyond just cranking up the reflections quality in the PP volume, Lumen’s current reflections solution basically can’t handle those surfaces without either biasing or noise, so short of looking to art direct around them, you could always use the path-tracer.
1 Like