Luckily its only a small change (for me at least), I can barely see it without direct comparison (looks like shadows got darker, but thats about it, no overshadowing by itself? EDIT: Checked other trees in another project, lots of extreme overshadowing…):
Left: the version right before 5.0 release
Right: 5.0 from today
@ can you give us the exact console settings you used previously, since the “tree fix settings” are not exposed in the Post Process Volume, and the console settings arent documented anywhere (that I am aware of).
EDIT: I think the previous settings looked a lot better, at least in my context. (something is “off” with the current looks of trees, but I cant really point it out, yet.)
I’m am a marketplace creator and I wanted to make my asset pack available for UE5 but it looks very different in UE5.
The shadows look very harsh and the translucency effect ( on the foggy scene) is too intense compared to UE4 . You can also see that on some leaves the reflections are gone. Is there anything you recommend me to do? I can send you the project files if you want to investigate it.
I can send you a heavy foliage scene i have made with ue5 preview 2, its an arch viz scene to take a look at foliage as well. just let me know how, its around 5gb
Can confirm we’re getting the same issues in release. Foliage is generally very dark and overoccluded in most cases. Lumen AO is very remeniscent of how overoccluded DFAO can make things, except in this case there is to my knowledge no way of controlling this like you could with DFAO in the skylight. The type of shrubs we have let a lot of light through and as a result they shouldnt receive a lot of AO.
Lumen indirect lighting has world normal aligned artifacts.
Seems to be independent from lighting and object position.
Artifacts disappear when turning off Lumen.
No Lumen settings seem to affect the artifact (I’ve tried detail and global tracing, and hw raytracing as well)
It is not, I can confirm. UE5_main has masked and WPO material support 5.0 doesn’t have, and the HQ reflections as well. Relatively unsuprisingly, non-vital features were culled from 5.0 to polish what was already solid. Good for stability, subpar for development.
Are you using HW or SW Lumen? I’ve had similar problems, I’ve also noticed two very important things for foliage with lumen: if using software, one has to check ‘affect distance field lighting’ and ‘affect dynamic indirect lighting’ in order for Lumen to work properly. Just having DF lighting gave me massive overocclusion, but enabling dynamic indirect lighting gives them the mesh cards needed to bounce lighting.
Also, your lumen scene detail will factor into the smallest object captured in the surface cache, which may explain why your smaller plants aren’t getting captured. So far, 5.0 has been a strange experience for me as well, I’m just offering tips off of what I’ve learned from earlier builds.
This is definitely not over occlusion. In your screenspace case, only the primary indirect bounce happens by SSGI. But the direct light comes from skylight, and its apparent that skylight on your first screenshot is not occluded by the ground terrain at all.
Before Lumen, unless you enabled ray tracing and enabled ray traced skylight shadows, there would never be any realistic sky light shadows. They’d just be faked by SSAO or DFAO. So in case of foliage on terrain, you’d either get completely black illumination from the botton of your skylight, because the Skylight had “Lower hemisphere is solid color” enabled by default and the default color was black, or if you turned it off, you had bottom of your environment shining through the geometry as if it were xrays, without any shadowing.
Lumen on the other hand correctly occludes the foliage on the terrain by the terrain itself. The resulting dark scene in your case is most likely combination of wrong material albedo values and wrong exposure settings.
But ultimately, it’s more likely that your first screenshot is wrong, but you overcompensated the exposure and material values for the inaccurate pre-Lumen fake lighting and global illumination to make your assets look good in that scenario.
With that being said, there’s one important Cvar, which significantly reduces Lumen flickering on dense foliage, and also reduces the occlusion a bit. You may give it a try:
r.Lumen.ScreenProbeGather.ScreenTraces.HZBTraversal 0
Firstly, the screenspace shot does not use SSGI. Secondly, the stuff you brought up is mostly non-problematic as It most definitely is overocclusion as I can almost perfectly replicate this look by just cranking up the DFAO settings in the skylight. I obviously don’t want this look so I adjust the skylight in the screenspace shot to not get overoccluded in combination with SSAO. The problem if not obvious by now is that we have no such control with lumen, as it doesn’t seem to take into account the very high sub-surface scattering on these bushes which will lower the amount of AO.
Besides, you might think that exactly following the guidelines for something will always equal a positive return but until lumen is fully developed you should be careful shifting the blame onto the user. After all, there are a lot of similar reports.
Epic did the right thing here. They did not aim for where the technology is now, but where it will be in a couple of years. It’s not hard to imagine they have some test samples of RTX4000 series cards already. So it will definitely improve even if they don’t touch it by the mere fact that GPU performance will improve a lot.
That being said, you can fix it yourself. You can increase Global Illumination scalability settings to cinematic, and you can increase Lumen Reflection quality settings in PP volume. Non the less, don’t expect your framerate to reach playable digits
What you are seeing is not really a quality issue. It’s a consequence of balance between getting somewhat realistic glossy reflections and getting acceptable framerate at the same time. It’s actually quite impressive that we can have pretty good approximation of glossy reflections, which take minutes to hours to render with offline renderers in pretty much realtime. But corners have to be cut unfortunately
seems like a bug I found. Please correct me if I am wrong:
import a sphere with flipped normals to have a dome, put an emissive material on it. I don’t want the actual lighting, I just want it to be visible in the background and in reflections. So I disable “Affect distance field lighting” on the mesh but nothing happens, still emitting light. Is there maybe a command for this?
