EA2. The reflection of the lights above the sphere are appearing or dissapearing in the reflection depending on the distance from the camera. WTF? I can basically never receive nice reflections like many of you post here…
And here, the reflections are sometimes visible more, sometimes less, depending on the camera angle :/.
I would say: You are using SSR, which is why your reflections depend on what is on screen, its quite obvious in some of your screens.
I also rebuilt the Scene from Lumen GI and Reflections feedback thread - #234 by zbieraj this post, while everything works fine. In your case, you dont even have the GI from the emissive material.
This is what it should look like, and the reflections also stay if you get closer:
EDIT: that reminds me: I too have some materials (water) that still uses SSR instead of Lumens reflections.
Thank you for explaining that. I am still a noob coming from traditional 3D software.
How can I know if the material is using SSR, or not? And does it mean that this is the fault of the reflective material, which uses SSR? Or can it be also the fault of the material I want to reflect?
I see that I am not the only one with that problem:
Its not something “you know”, its something “you see”, at least I never told UE5 to use SSR for water instead of lumen.
Thing is, Lumen doesnt seem to be doing reflections for Translucent materials etc. so the engine automatically switches back to SSR (from what I observed) - but I have no idea why your metal isnt working properly.
Usually, just setting “Reflections” to “Lumen” in your Settings/Post Process Volume should enable it for everything that currently works, but it relies on the Mesh Distance fields a lot - so make sure they work properly.
Regarding your “reddit link”, such thing works just fine when I replicate these in EA2 and my December build from Github.
To me, this looks like a wrongly set up Mesh Distance Field, so Lumen falls back to “Screen Traces”, causing this.
Good Rule:
If something disappears when its “out of Viewport”, its most likely Screen-Based, therefore: UE5 couldnt use the Mesh Distance Field/the Lights/materials are not represented in it.
I also recommend this: Lumen Technical Details | Unreal Engine Documentation
I have been using Lumen since EA2 was released, have seen it do “a lot of weird things” (Its all in this thread), but many of the issues that have been reported “on the internet in general” are caused by People doing things (very) wrong.
Check your “Lumen Scene” and “Mesh Distance Field” Visualization, something is set up wrong - at least from what I can tell/replicate.
Hi @Yaeko,
Thanks for your time in writing that whole thing. I really appreciate it.
All the mentioned things which should be turned on, are turned on.
However, I found finally the issue. All the lights were geometries, but not static meshes. After converting them to static mesh, the light appears in all the reflections normally :). Besides the glass…
You shouldn’t use geometry as a replacement for lights when there’s more powerful and more featured lighting actors that already exist.
1 Like
All the lights were geometries
So it was exactly what I expected: You had no proper (none at all) Mesh Distance Field, since “BSP” or “Geometry” doesnt come with one (from my knowledge).
At least its solved now.
1 Like
Eh, in this case it’s perfectly acceptable. Those light panel meaning things above are too big to produce good shadows even with the raytraced shadows, and there are certainly a heck of a lot of them. On the other hand there’s so many that this should work fine with setting them to emissive. As you can see in the shot the end result is fine.
Hi Yaeko, thanks for all the detail. Foliage with SDFs has been a struggle, primarily because we can’t handle the OpacityMask of the material.
One thing you can try though - r.DistanceFields.TwoSidedSurfaceBiasExpand 1 or lower
Thanks for all the images demonstrating how much foliage needs work
3 Likes
Thanks for your reply, it is good to see that all the time and effort to figure out “what is going on” isnt wasted and that the findings reach the people in charge. (some of the older issues really werent easy to figure out, specifically the light-limit one.)
I always try to give useful information about things that are not working as expected instead of simply complaining about it - at least I hope it is useful information 
Regarding “r.DistanceFields.TwoSidedSurfaceBiasExpand 1”, it does not have any visual impact on my trees, but I will try again when I update to a newer build (mine is from december, since its stable).
=========
Without actually knowing what the issue is you are facing, I expect it is that the tree materials (specifically) need too many traces/time/computational effort to work properly due to the small nature of the leaves?
A dirty workaround that I came up with might be, (specifically for trees): giving us an option where we can tell lumen to simply treat the material as X% solid, so that it will block x% of the rays that hit it instead of actually trying to figure out every single leaf in a tree. (it obviously will ignore the leaves then and just let the ray go “through” them, but given the small size of leaves it doesnt matter in terms of accuracy.)
I expect it to be very performance friendly given the amount of traces needed to properly trace such trees, given that they are big and have a lot of leaves in their crowns. Especially considering that it doesnt get any better if there are more trees, the amount of calculations will quickly surpass the ones for everything else in the scene. (I expect)
In the end, in reality, the light below trees always is diffuse, so lumen “being lazy” doesnt matter.
==========
The trees aside, I think that Lumen is in a good shape currently, at least from my experience, visually speaking.
The only downside is that performance tanked a bit, but I expect that to be something that gets fixed at the very end, so I am currently not too concerned about it.
PS: If I am talking nonsense, feel free to tell me - I obviously do not even remotely have the knowledge about Lumena nd its systems like you have.
Just checked something that came up my mind, given that Lumen is raytracing for the most part.
Can we get “colored light from colored glass”? (thats just a request, its fine if this isnt doable currently.)
something like this:
Every one of your posts has been very useful =) Especially since you are testing out a more recent build. Early Access is ancient at this point and the code has changed so much that the investigation is often fruitless.
We have made some improvements to foliage quality with Software Ray Tracing that will be in 5.0, but it still needs work. They at least will not be black =)
I’m pretty sure we’ve fixed the light limit thing too.
I saw your posts about the performance reduction, but you were looking at overall fps, which is not very useful to narrowing it down. It might not even be Lumen. ‘profilegpu’ is the way to narrow down what changed on the GPU at least. Lumen has actually gotten quite a bit faster in latest since we’ve integrated all of the optimizations from shipping ‘The Matrix Awakens’.
Colored glass is possible, but that would be a shadowing feature, Lumen is specifically Global Illumination and Reflections.
That sounds great, especially for the games that cant just throw a spotlight at a roof/wall and light up a dark tree like I can do.
I think so, at least I could disable my workarounds and everything is still working, and I cant break it anymore, even after loading all maps at once. (which is great news.)
It is also outdated information, given that my build is 6 weeks old now. (I think its even older than the matrix demo, so yeah, thats “the issue” I pointed at (for the others) with the “outdated builds”. In the end it might just be that specific build that has this issue.)
I will get myself the current build today and then take a look at “how things are”.
I still have one “issue” on the list regarding lumen “lighting upwards”, but I will make a dedicated post about it soon, after I checked the newest version.
EDIT: got the build, slight visual differences but nothing else (so far).
Yeah, I had a bit of an “error in thought” there, since I connected lumens software raytracing to “the color of the light changing when passing through glass”, and since this is a normal Raytracing feature too.
My bad, sorry.
Have a nice weekend.
Colored glass would be incredible, and I agree on the performance front, the most recent build almost seems wholly shippable to me aside from a few bugs.
Just on the note of translucent shadows and lighting behavior, I recently built both a test of NVRTX 4.27 and UE5 (both less than a week old). I tried out their features on a few different test maps to understand behavior and performance (Epic’s Realistic Rendering and Soul: City maps), and I’ve noticed a few interesting things.These are just my observations, I could be entirely wrong.
I’m just putting them here as reference, for people who might be curious about the tech (like I was:).
-
I love how Epic has kept the Lumen controls tidy (even in the most recent build, which has a few more quality sliders). By comparison, Nvidia’s GI solution (which I think uses a similar probe system that Lumen has for distant lighting, could be wrong), is a bit frustrating . The probe volumes have visible filtering problems, where the grid pattern can be easily seen in GI. The post-processing controls have dozens of toggles and sliders, especially for things that should otherwise be relegated to CVars and don’t need to be changed at runtime (like the denoising method). Bottom line: RTXGI was an overall clunkier experience for me, and personally not worth the costs.
-
While there’s more to say on GI, I think their caustics and colored shadow stuff is way more interesting, because Unreal has no solution for them outside the path tracer. That being said, they are a significant pain to enable: you need to tell every individual light actor to cast mesh caustics, then you need to opt-in the material, then the mesh, then the PP volume to program the behavior. Interestingly, it’s far more artist-driven than the path tracer (you can control caustics behavior independently of the material generating it), which means you can really easily get results that look non-physical if you’re not careful (such as the caustics being brighter than the light that’s casting them). Colored lighting is considered caustics, and Nvidia’s caustics system has some strong flickering problems, so they ended up standing out like a sore thumb in a few scenes, unless I went to a fair deal of effort to tune them. They also don’t consistently show up in GI or reflections, leading to some really strange light leaking.
-
RTXDI, their direct lighting solution was honestly pretty cool, the promise of unlimited light sources, free emissives, and no budgeting. In practice? I got up to 750 concurrent point lights working with no visible decrease in frame rate after the first one (test scene, not a playable level). It’s neat tech, but the default settings have a lot of ghosting and filtering bugs, and you need to quality tune it a lot to get it to be both cheap and visually acceptable. With UE5’s VSMs and their single-pass lighting solution, the feature-gap between RTXDI and UE5 is pretty slim.
I apologize for not having screenshots yet, my system’s being strange, so I suggest those interested try it out themselves. The gist of what I’m saying is this: NVRTX and UE5 are pretty much equal in terms of overall quality. You get a few more bells and whistles with the former, but at the cost of a lot more artist time needed to tune everything. Caustics and colored shadows are nice, but I’ve found they can make some scenes look worse without tuning. Lumen is better than RTXGI in quality, stability, and ease of use, and RTXDI is almost superceded by VSMs already. And this is ignoring Nanite and the vast increase in content potential UE5 brings. If colored shadows and some form of caustics are integrated into UE5, then I’ll pretty much be totally happy with the engine. Thanks for the amazing technology, Epic.
Hmm, people mentioning caustics as well. If you’re already raytracing through the shadowmap and storing two+ depths there, one with albedo for colored class, you could store IOR as well and get slightly hacky caustics.
Cheap-ish RT caustics.
RTXDI, their direct lighting solution was honestly pretty cool, the promise of unlimited light sources, free emissives, and no budgeting. In practice? I got up to 750 concurrent point lights working with no visible decrease in frame rate after the first one (test scene, not a playable level). It’s neat tech, but the default settings have a lot of ghosting and filtering bugs, and you need to quality tune it a lot to get it to be both cheap and visually acceptable. With UE5’s VSMs and their single-pass lighting solution, the feature-gap between RTXDI and UE5 is pretty slim.
“Many lights” is a kind of general term for this, and afaik trials of multiple ways of doing this are ongoing in UE5. Some requiring Lumen, some not. But “virtualized” … well, amortized, lighting of hundreds of lights+ is something actively being worked on.
Looks like I accidently opened pandoras box (sry)
I doubt Lumen suits itself well to deal with caustics etc. given the fact that it accumulates data over time (visibly so, if you change the scene), and that caustics are always moving. (Same should go for water reflections.)
But I wont complain if I am proven wrong and we get such features. 