I was thinking that now, in 5.0 preview, with “Hardware Ray-Tracing” enbale, things like “enable distance mesh fields” and divide architectural in single meshes (floors, walls, ceilings…) are unnecessary.
After some tests, noted that the noise effect in lumen GI occlusion (something like gi ambient occlusion) still exists (same UE5 EA). “r.Lumen.ScreenProbeGather.StochasticInterpolation 0” doesn’t resolve
I have to wonder if its tied to the scale of the mesh, for example maybe it won’t generate a card if there is another surface within x centimeters. Reason being is that I tried this and the only mesh that failed is the one with a very narrow opening. (These were made from a default Blender cube)
Pink areas mean places which don’t receive surface cache and can’t do multiple bounces and are black in reflections if you don’t use hit lighting. So usually some pink is fine and doesn’t have big influence on the final pixels.
That h-profile likely exceeded max number of allowed cards. Bumping MaxLumenMeshCards in the static mesh should fix it.
Also as Arkiras noticed we try to ignore small detail below 20 units. Goal here is to generate an efficient, but approximate surface coverage. Nanite enables creation of truly complex meshes, so we can’t aim for 100% surface representation.
Otherwise we are gathering all failing use cases and will work following week on improving the generation algorithm.
Not to suggest that this is a good idea but does this mean we can achieve better surface cache coverage by simply over-scaling our meshes before importing them? 
(Up to the card limit at least?)
You should evaluate both. Hardware ray tracing is the future, but for now we still have cases where software ray tracing is either required due to hardware constraints or is faster.
Hardware ray tracing has higher quality, especially in reflections. It’s also more flexible as it supports HLOD (World Partition HLOD) for extended GI/Reflection distance, skeletal meshes, hit lighting (can bypass surface cache).
Software ray tracing is supported on all hardware and is more efficient, especially with scenes containing lots of overlapping meshes (e.g. dozens of overlapping rocks).
That’s the current state. In future we would like to work on bringing those two closer together - making hardware ray tracing faster and improving quality of software ray tracing.
There’s a build scale setting in static mesh if you want to experiment with it without having to rescale mesh outside of Unreal. Albeit looking at failing cases in this thread it seems to be more about bugs, max mesh cards limit or non modular meshes.
Generation is designed to skip small detail, as those tiny surfaces don’t really matter that much for the final result, and likely screen traces will do a better job there anyway. It’s also designed to handle modular meshes, as anyway you can’t get a reasonable distance field if you put entire apartment in a single mesh.
Maybe, but in this case, i made an error during export, and those meshes were imported with gigantic sizes 
Here i have added the standard UE cube for comparsion, all meshes are at scale 1.
Tried that MaxLumenMeshCards command with 36, nothing changed, but maybe i used it wrong. If someone want to test those meshes, here they are:
LumenTestmeshes.fbx (45 KB)
Works fine for me:
Your Mesh:
My replication:
Small differences come from my replication being longer, more light bouncing around.
At least in my game it works, but my game doesnt “play by the rules” it seems, given the “Sun Temple” thing further up… so, idk? (No pink in cache either.)
I’ve tried those meshes and H-profile works correctly on my end with newest 5.0 code.
Wufel_5 wasn’t covered fully until I didn’t bump max lumen mesh cards in the static mesh settings.
Hi, will you support 360 panocapture with or without Lumen in next release ? and in stereo ?
thank you
M.°
I see. I tried it again, raised those Mesh cards for both the H-profile and Würfel 5 (Würfel = german word for “cube” ^.^ i just made them from a standard cube and didn´t rename them) to 14, like in your screenshot, and now they work here too
Are there any drawbacks or things to know and consider, if we raise those mesh cards beyond their default value?
And would it be possible, to raise them directly during import into UE5? Because if we know, that the mesh is already complex enough to require more, then an option in the import window might save some extra steps later, especially with mass imports.
Did another test mesh, a more complex one and to my surprise, this one only showed 2 pink surfaces for its complexity. Both were in that front cutout, the botton and top surface. After raising mesh cards to 16, it worked fine too.
The hole in the top center between those two towers worked fine from the beginning.
I guess, we definiately need a good guide for the relations between mesh cards and mesh complexity
Guess it´s time to dust off some old greeble packs and see, how well they work ^.^
This and maybe also how nanite affects lumen scene as well.
I noticed that when I imported new objects in a scene, some of existing objects would become partially black in lumen scene until I converted the new ones to nanite.
If I understand this correctly, nanite meshes play with lumen nicer than regular geometry.
Has anyone tested the UE5 Preview Movie Rende Queue? Rendering still images with AA None are producing artifacts. Images are not clean
I was waiting UE5 Preview for finnaly can use AA None with good reflections
I would say, for good reflections you should take a look at the pathtracer, either in 4.27 or 5.0. That one produces the best reflections you can get in Unreal Engine.
Not sure this is really a bug, but when a mesh is flagged as “Visible in Scene Capture only” it still gets added to the Lumen Scene:
Can be easily fixed by unchecking “affect distance field lighting”, just seems like an odd choice, given Lumen doesn’t seem to do anything in scene captures.
When I saw ‘Scene Capture’, I figured it actually meant the Lumen scene: Since SLW doesn’t support Lumen presently (if ever, I have no idea how they could), I just place a giant mesh below the water line with the appropriate color of the ocean, and then I check the box. It allows for a blue light bounce without it visibly affecting the water appearance you also have to disable it as a shadow-caster to avoid massive over-occlusion. I’d imagine it’s basically a lighting hack for when you want to pull-off an effect that Lumen doesn’t physically allow. Just my interpretation.
Hi all,
I understood that pink color in Lumen Surface Cache overview mean uncovered surfaces that lumen can’t bounce light from.
But what about this yellow color? What does it mean? I can’t find any information about this.
Yellow means that the entire mesh isn’t covered:
This is a shadowing problem, not related to Lumen. What’s happening here is that shadow maps are less accurate than Ray Traced shadows. You can usually work around it by making your walls thicker. Virtual Shadow Maps have better accuracy (less leaking) than regular Shadow Maps, but are also more expensive. You can enable Virtual Shadow Maps in the Project Settings by setting Shadow Map Method to VSM.
Non-Nanite meshes are captured at their lowest LOD so if you have something like a billboard as the lowest LOD it will be broken when captured into Lumen Scene. That’s done because the non-Nanite captures are very slow.
