Surely it could be improved!
Has there been an official reply from an Epic developer regarding the Lumen not working with vegetation issue?
I just quickly went through some replies and it looked like the issue was actively avoided in replies so far.
The reason I’m so concerned with this is, that our game world is like 40% vegetation.
Like I would imagine most open world games are, plus / minus some percent of course.
Whereas so far UE5 only really works well in the desert and with other static geometry.
My big fear is the following:
We have a game screenshot with a static wall, it has 1 Million tris with Nanite and is beautifully illuminated by Lumen.
Right next to it, there is a few trees, but each only has 10k tris, because Nanite doesn’t support vegetation.
Also, they only have baked in vertex AO from SpeedTree, because Lumen doesn’t support vegetation.
Now we present that screenshots to the public, but then they only really see the crappy looking trees and mostly ignore the pretty wall behind it.
We’re currently doing a lot of look dev and the assets not supported by Nanite + Lumen are really standing out like a sore thumb.
With Lumen being the much bigger offender. I mean for geometry, detail can always be faked to some extend, without Nanite support.
Someone got to be working on that, right?
I would go as far as saying it’s an issue that will severely affect pretty much all open world games.
1 Like
Found out some more stuff about the issue described in Lumen GI and Reflections feedback thread - #48 by Yaeko
The appearance of this issue (in the editor) scales with the size of the viewport, sometimes reproducably:
I also noticed that it behaves differently depending on framerate. (updates are not visible anymore on lower framerates, while on higher everything is “flickering”.)
Aside from that I noticed that lumen (or its Distance Field Meshes) have a massive impact on the time needed to make a level visible that is already loaded:
UE4: 0.5 seconds - just s short “hiccup”.
UE5: 8 Seconds - game hangs for the whole time
This is practically not usable anymore and needs improvement.
I think I have a “workaround” for the “Post 48 issue”, which is to just make smaller levels, but thats exactly the opposite what UE5 should enable… meh.
I will wait for EA3 and EA4 before I do further digging into this issue (I dont think that UE5 will be “released” within the next 6-8 months anyway), there are so many things being changed that it doesnt really make sense to take the current state of Lumen/UE5 serious.
It might very well be that this will get resolved by accident.
Or you could manually place your own custom vegetation. Just because you have a couple trees next to an asset doesn’t mean that the trees need to be vegetation it means that they could just be whatever the heck you want because you could just import in an object that is a tree that you made out of millions of polygons and every leaf is modeled and has just millimeters of depth so it’s not just a flat card every branch is 3D every bit of bark is 3D. There are no normal maps on this tree because you don’t need them because you have all of the micro polygon detail.
You should see how long it takes to load the maps that I’m working on from my doom engine era game (Strife) remaster. In order to get the Lumen cards working correctly I have to separate out every single bit of geometry that faces inward in the level if that makes any sense. So I have hundreds maybe thousands of static meshes that are just two triangles really. With 100% mesh distance field resolution scale because if I don’t do that then sometimes there is weird leaking in the software Lumen mode that isn’t in the hardware Lumen mode. Some maps have 30 plus gigabytes of DDC data. Just meshes. The shaders are optimized as heck because I’m using the original textures just with PBR that I’ve custom made. But still every single time I have to regenerate the shaders and the distance fields… On my nvme SSD and 5900X it still takes an hour or two to regenerate every single unfinished level. This will just grow as I complete more of this project. Until Epic solves the Lumen card generation problem that I have with the simple geometry levels that I have where one texture covers half the map’s geometry because that’s just how that stuff works from ultimate Doom builder… This is just how my thing is going to go and I really wish epic would solve this problem instead of solving outdoor scenes with millions of triangles and complex everything. If I was in charge of this I would want to solve the thing that I’m working on because if you could performantly render a bunch of box rooms with lights placed all over and Lumen and emissive textures… Then I’m sure rendering an outside desert with millions of polygons will be very easy… But no right now we have the opposite and my use case is just literally impossible for this engine but it looks great if you put in the time but it’s so much manual work that I’m currently just dying right now. 
1 Like
Nanite doesn’t support this kind of thin leaf geometry / porous geometry right now, as far as I’m aware?
If it does that could be a good solution. Still, it would not be possible for the tree to move in the wind.
Which is also a big issue.
1 Like
I assume there’s some work happening currently on Lumen in main branch, test level i made last month is broken with what i assume to be failed shader compilation? Don’t know what to make of it ( lumen scene)
1 Like
Hello, this is my first feedback here.
We are having View Frustrum issues. Light disappears when out of view frustrum. Has anyone else noticed this and have a fix?
UE 5.0 Light bug When Out Of View Frustrum - YouTube
- Noticed it first when working in a post process volume on a dark and spooky graveyard scene. This is a separate blank project with nothing else in it. This bug is in 5 only. Does not happen in 4.26.
It happens with all but directional lights.
I’m having a similar problem. I’m trying to make a fairly dark interior scene so I don’t want to use a directional light or a skylight. No matter how big or bright I make my spotlights they stop contributing to indirect lighting at a maximum of about 20-30 metres from the camera.
If this is an intentional performance optimisation, it would be great if we could override the cutoff distance like how we can disable lights at a certain distance.
Hello! Awesome job with Lumen, I’m really enjoying using it. I wanted to report that I’m seeing some strange artifacts with it in my project in certain scenarios. I’m using software ray tracing with a 1080ti, and all the recommended settings on the Lumen page. I narrowed the actors down to the most basic setup - directional light, sky atmosphere, point light, and white cube (fog and skylight are disabled). The first image shows the cube with the directional light visible in the sky. When I move the directional light below the horizon, the cube turns yellow and creates quite a bit of noise and other artifacts. In the last image, you can see some speckled yellow ghosting light while moving the camera into the black area. Please let me know if I can provide any more info to help. Thanks!
Actually directional lights don’t contribute to gi past the same point either (roughly 2500 units from the camera). This is 25 metres right? whereas Lumen should cover 200 metres from the camera. I assume this is just a bug with my test scene.
Yes, main is having a Time recently and it’s making me question my sanity
1 Like
Updated to latest version of main branch and it seems to fix the issue i mentionned in my last post, but my cornell box is still broken compared to Early Access version.
There might be some new settings regarding emissive materials ?
edit : Figured it out, the emissive top box in the cornell was too thin for the new Lumen version, increasing its height fixed the issue i was having, all good here !
Moral of the story, lumen is more sensitive to thickness than it was in early access build.
The issue i’m facing now is weird light bleeding:
Hello, new UE here! So, I’ve been playing around with the new UE5 and the lumen/GI combo and have a couple of issues - could be known, I’ve already read several pages in this thread but couldn’t find a solution.
So, I am using lumen for this example in both Reflections and GI, I have set lumen reflection quality and GI final gather to 4. I am getting this low resolution result on the sphere reflections.
I read about the cut-off of the reflections, but couldn’t really find a solution to it. Is there some kind of setting I can increase to get better reflections. If I remove the roof of the building, resolution clears up, so I guess the problem stems from the GI tracing.
Also, somewhat irrelevant, but does lumen require any kind of baking? Would that increase the quality in any way?
Any help, advice, pointers welcome!
Is there some kind of setting I can increase to get better reflections.
try the command r.Lumen.Reflections.HardwareRayTracing.LightingMode=1 or r.Lumen.Reflections.HardwareRayTracing.LightingMode=2 and make sure to be using a lighting setup composed of:
- directional light
- atmospheric fog
- volumetric cloud
- skylight
i’ve noticed that this command plus using a “correct” lighting setup seems to really make reflections look better. still some visual glitching but way better for sure.
but does lumen require any kind of baking?
no, not in the traditional sense.
Would that increase the quality in any way?
play with config settings. go to help > console variables and search for lumen and just look at what a lot of the things do. mess with stuff and dont consider anything you are seeing to be final or fixed in any way feature set wise or quality wise
Thank you very much for your reply, will test later today, as soon as I get the chance.
The reason I am not messing with the console options much is that I don’t know the defaults - so I can’t revert back. Is there a way to get them? Also the fact that they are in the console - they should be somewhere scattered in menus or something right?
If you enter a specific console command and instead of adding a new value, add a ? at the end, it will give you some explanation and the default value. (in most cases at least!)
For example:
2 Likes
a little off-topic, can someone round down a comparison between lumen and rtxgi which is supported in 4.27?
Hello again. How does this work on UE5? Typed the exact command, but the cmd is just one line, so I can’t see the output.
Also the option you mentioned above doesn’t have any difference. Any other clues?
Edit: Answering my own question, I found the options r.LumenScene.GlobalDFResolution (default val = 224) and r.LumenScene.GlobalDFClipmapExtent (defaule val=2500).
The first value defines the quality of the GI in the reflections - increasing it more and the engine crashes. The second option just changes the distance of the GI shadows shown in the reflections.
Also, I am not really sure about the option that has something to do with parameter r.Lumen.Reflections.HierarchicalScreenTraces.MaxIterations.
If you notice the reflections on the sphere, the bottom part changes - I can’t really tell if this is a better or worse option.
Has anyone conducted any tests with Lumen reflections + GI combo in interior scenes with any better results? Please share!
1 Like
So, I created a new post so that this is not lost along the way. So, using UE5 I started a new Archviz scene, which, by default contains just a skylight. I created 4 walls and a roof and added a sphere with chrome material and this is what I am getting - on the left is the normal scene and on the right is the lumen scene - which is essentially what is reflected on the sphere. Is what I am seeing normal? In videos on youtube this is certainly NOT what I am seeing.
So, just started with UE and am a bit overwhelmed and disappointed, I have tried several versions and still I can’t get a good set of results for interior lighting + GI. Any help and pointing to the right direction would be nice!
2 Likes