I am having an issue getting consistent results using Lumen and trees.
Right now I have a tool in Houdini that generates stylized trees. When I imported the generated trees in UE5 I noticed that some of them have a difference in shading (they are darker). After some experiments, I realized this is somehow related to the mesh’s distance field representation. Additionally, sometimes, when I increase the vertex count, I can make the issue disappear. I tried many things, such as turning on two-sided distance field, playing with the distance field resolution scale, etc. Nothing seemed to work. Do you have any clue about what might be going on?
The following are a few images comparing two versions of a tree. Both trees are generated in Houdini using the same random seed values. The only difference between them is the density of the leaf cards which influences the vertex count. Aside from that they use the same materials and have identical import settings.
The tree on the left is the one with the shading issue. It has 15,316 verts and 17,301 tris.
The tree on the right is how I expect the shading to look like. It has 21,076 verts and 20,181 tris.
Notice how in the Lumen > Geometry Normals screenshot you can see some banding in the tree on the right side. Every time I import a tree and get this banding effect I know it will look good.
Sometimes, enabling Nanite seems to solve the issue, but other times it doesn’t have any impact.
While I’m unsure if it will be a comfort for you, having lumen issues with foliage is far from uncommon.
If I’m reading the buffers correctly, the core problem is that your mesh on the lack isn’t interacting with lumen’s stochastic translucency system:
Short version: lumen has a feature that’s basically dithered translucency for SWRT (look at the hash marks on the right SDF)- for some reason, it’s disabled on the mesh to the left, and that’s the most likely culprit of your over-occlusion.
Longer Version: Since there’s enough geometric detail in that tree for it to effectively become a volumetric media, lumen analyzes the mesh upon building of the SDF and brick-by-brick assigns a coverage value, a value of how stochastically likely a brick of the SDF is to block or let light through. Upon a ray hit, that coverage value simulates light transmitting through the SDF, to better approximate how light would actually scatter through thin foliage.
For reasons I don’t quite understand, lumen isn’t assigning coverage to the mesh on the left, but is doing so for the one on the right. If you can figure out why, you’ll most likely clear up your issues.
On the other hand, from the Unreal Lumen user manual, it seems like Hardware Ray Tracing doesn’t use Signed Distance Fields.
If the Distance Fields are the culprit, that means you are using the Software Ray Tracing ?
The unfortunate reality that lumen operates under is that SWRT doesn’t scale up in quality nearly as well as HWRT can. The global distance field can be really lumpy an deformed compared to the scene, although lumen’s utilization of screen traces means this this isn’t a massive issue most of the time. Foliage is just a hard use case for any non-RT indirect lighting solver, but does this clear up your understanding of the issue somewhat?
@jblackwell Thanks a lot for your input. The information you shared is very valuable. I had no idea about the dithered translucency of the SDFs, although now that you mention it, it makes a lot of sense (btw, is this mentioned in the docs somewhere?).
I played with the import settings, trying various stuff, but I still cannot see why some meshes work and others don’t. Nanite seems to help a bit but not always. I guess, I’ll have to keep digging
