Hello fellows! I hope you are all doing great!
By any chance do you guys know what could be causing this strange light “flickering”? 
This is giving me headache trying to find a solution.
Thanks in advance 
I have a problem with metahuman
Likely there’s some mismatch between Lumen Sceen Traces tracing what you see on screen and Lumen Scene. Try enabling Lumen Scene Overview View Mode and check what actually Lumen sees there. You can also disable screen traces in order to prevent view dependent lighting, but it may reduce quality in some spots.
1 Like
Hi y’all just a quick question about Lumen & Hierarchical Instanced Static Meshes (HISMs),
I’m interested in using HISMs for my project since they allow for LODs but I noticed that they don’t seem to properly contribute to the Lumen Scene. I saw much earlier on in this thread that people had the same issue a few years ago. I did some of my own basic testing which seems to confirm this
The objects on the right circled in blue are basic static actors contributing normally to the scene as one would expect.
The two spheres in the middle circled in green are plain Instanced Static Meshes (ISMs) which appear to contribute normally as well.
The objects on the left circled in red are 2 different HISMs (one set is default spheres to confirm its not just my own mesh’s issue, and the other is my custom mesh). As you can see in the little Lumen Overview windows they are definitely not contributing. This simple level was set up in clean project using Unreal 5.3.2, but I also made a similar level in 5.4.2 with the same results.
I’ve tried some various fixes suggested in the troubleshooting section of the Lumen documentation, including playing with Lumen settings in a post processing volume, and increasing the mesh’s “Lumen Mesh Cards” value but, with no luck.
So with all of that said, my question is can anyone confirm whether HISMs work with Lumen and I’m just doing something wrong, or is it true that HISMs just don’t work well with Lumen? Also if it is true, are there plans to make them work together, or not really?
Sorry this is kinda wordy, but thank you in advanced for any help/guidance! 
3 Likes
HISM should work, but only with Nanite meshes. Given that Nanite is our default mesh rendering method likely we won’t fix HISM+non Nanite.
2 Likes
I tried enabling nanite on my mesh and just as you said my HISM works with Lumen now! Thank you so much for pointing me in the right direction : )
2 Likes
Hi all,
This is maybe not 100% Lumen caused, but related. Do you know any advise to decently illuminate hair strands?:
Path Tracing:
I have been trying to illuminate hair in interiors for a while, but it doesn’t seem possible to get a realistic lighting. As a retest-project and to confirm, I have downloaded this example project https://www.unrealengine.com/marketplace/en-US/product/raytraced-cinematic-lighting-interiors, changed to Lumen, deleted the rect lights, increased the lamp intensity to something more “physical lighting value” (not working fine, too?), and this is the result if you move the character to a GI illuminated zone.
Thank you very much!
rage moment? have you actually tested nanite? to destruction? i’m about to go in. foliage in my highrise map does not perform well. the city park asset pack was not build with nanite. gotta squeeze it. i for sure know howto avoid instance overdraw. intentional world building, not spamming generic rock assets (like the valley did). you gotta optimize your assets and world to draw effciently. hmmhmm.
It’s the same guy who previously spent all his time spamming the thread about how much Nanite/Upscaling/TAA sucks. It’s the only thing he has to say.
2 Likes
yeah. negative persona. i don’t like those. asking for cheaper solutions. that may not look as good. wonder what their hardware is. i’m not rocking top of the shelf either and i’m fine with what is implemented. i test it and squeeze. and i know some of the limitations from developer insights. transparent and actual development, not monke rage mode. : )
Has his comment been removed?
Anyway, I also hope nanite continues improving fast, as it is still not production ready in many aspects (for example, with WPO or with ray tracing shadows over distance, even if using RT nanite mode = 1).
People might also want to remember that we’re still a foot in each world. Once the rendering pipeline is fully migrated to the new paradigm/GPU, we’ll be able to get kickin’.
Totally agree.
Would be curious to hear any estimation about it. Maybe one year? Three? Five? I hope it happens soon!
What problems did you have with Nanite and raytraced shadows ? I’m asking because I also had some problems, specifically with foliage.
Hi Sebastian,
This:
And specifically with foliage, this:
https://www.reddit.com/r/unrealengine/comments/1c2648q/nanite_not_compatible_with_evaluate_wpo_for_rt/
i got this “error” too, back when i tested 5.4 pre-release. wpo does not work with rt shadows. or atleast i couldn’t get it to work. the shadow model was always static. would have to evaluate wpo in the shadow raycast or do some funky math.
i have no idea what the performance implications of that would be. especially with multiple lights or soft shadow lights. the alternative is rigged foliage like in alan wake 2. you gotta make use of gpu skinning and may have to find ways to procedurally generate instance variances.
my hardware can make something good looking, but for sure is limited. : )
Interesting @glitchered . I don’t even know what GPU skinning is or how to do/apply it, anyway.
About performance; well RT shadows well perfectly working with WPO in lods and/or in high poligon meshes. The problem comes when nanite is checked in the mesh.
Anyway, I wouldn’t want to disturb to any of you in this specific thread abot this non-related issue!
unreal has that gpu skinning in render options. basicly using a compute shader to transform skinned meshes and then draw the polygons. i know atleast tlou, for example, uses this technique too, looking at their shaders.
either way… you posted about that shadow issue. the shadow doesn’t have wpo. it doesn’t move. hence why it’s computed wrong and looks spotty on the foliage. the geometry is moving thru a static shadow. for me it doesn’t work at all. no matter if it’s nanite or non-nanite meshes.
I see your point, thank you.
But it should work for you when Nanite disabled. Ensure to select the mesh actor and, in its Details, check the box ‘Evaluate World Position Offset in Ray Tracing’. I think this might be what you are missing.
did you watch the video i posted? the leaves are obviously moving. that’s wpo with nanite enabled. when wpo is disabled they wouldn’t move. still doesn’t change the fact that the shadow is static. that’s what’s causing this shadow glitch.