Can anyone else confirm that nanite geometry collections shadows dont work properly with default/raytraced megalights? (I’m on 5.1.1)
Hi @Krzysztof.N ,
I have a quite complex scene in which, after just adding some ceil fans (less than 10), it was tanking the performance.
I have been testing in a separate project with tons of lights and fans (~300 of each) and, without the fans, it runs smooth. With the rotating fans, it kills the performance, and I don’t think it’s because a lot of ticking actors (just 300). May this have any explanation? Is this as intended? Maybe some kind of cache invalidation?
In this test project I needed to add a lot of fans to tank the performance, while in my real scene I just needed less than 10 (and those were almost the only ticking/moving actors). Maybe it happens when the scene is already a little heavy, with many actors, even if static, I don’t know.
In addition, VSMs doesn’t seem to be affected by this (even if the performance is much worse, of course, due to the high number of lights).
PS: This is how I am turning the fans. As you can see, after 5 seconds, I turn them off. Do you see the Avoiding variable? I stop them only setting that variable to 0, so the actor and the timeline is still ticking, but the performance recovers good results. I mean: I think this is not due to CPU load because of many actors ticking, as they are still sticking, anyway, but setting a value of 0. Am I right?:
Oh, and it happens even if the fans are hidden in game, so there are not any visual change in the scene.
Thank you!
iirc… i got told animated instances require invidual bvh rebuilds. i reckon that’s the perf drop. i tanked in my lil much wpo foliage scene for the same reason.
Thank you @glitchered ,
In this case they are not instanced meshes, just manually placed blueprints, but maybe are you refering just to ‘instances/copies’ in a generic way?
So, is that the explanaition and this is intended to happen? So no workaround?
PS: I don’t know if this makes sense for any real game, with tons of moving elements, then 
still the same. you do the transform in software which is cpu reliant. the matrices gotta be synced with a gpu buffer. instances or not they will likely render batched and still gotta be transformed into the world and the bvh rebuild. there are some bottle necks. instances that do not move their origin may reside on the gpu. the wpo is computed on the gpu, aswell as bvh. difference in compute logic. whatever.
Interesting. Thank you @glitchered
Then I don’t get the point for MegaLights in real games. Performance could be horrible, but, even worse, there could be HUGE performance differencies between scenarios, which could be even more frustrating.
Maybe @Krzysztof.N could give us more info about this and/or its future.
Thanks!
i’d speculate here and guess you doing the transform in software will insert 300 meshes at the top level of the bvh every frame. once inserted and given all the data is on the gpu it’s just computing it locally. i reckon the addition and removal of top level bvh is “expensive”.
either way… @Krzysztof.N knows that probably better and has more actual facts. yep. : )
1 Like
This is exactly why a significant number of modern raytracing titles have animated character’s reflections in screen space only.
Going back to my earlier feedback, we probably need a way to flag shadow casters as screen space shadowing only. Won’t work for every case but it should be ideal for certain things like foliage and ground scatter which often needs to move and are small enough to be represented well enough in screen space only.
In your case, I simply would not have the fan blade casting RT shadows. If you need the appearance of a light source shining through a fan to cast a moving shadow, I would try using a light function. I think this should eliminate the overhead of updating the BVH. Then you can have a mask in the shape of the fan blade.
I would probably make a distance field alpha mask, as then you should easily be able to fake soft shadows based on distance by controlling the range of a smooth step.
Perhaps you can switch the closest fan to true RT shadows and have light function proxies for farther ones if you really need it.
1 Like
There shouldn’t be anything in MegaLights what makes it slower when you start rotating static meshes.
If those would be meshes with WPO or skinning then you would incur extra BLAS build costs, but 10 simple meshes shouldn’t cost much.
My guess is that this is due to some legacy moveable object interaction tracking per light. Try to disable it with r.Visibility.LocalLightPrimitiveInteraction 0. It’s not needed for MegaLights, but we run out of time to handle it properly. Through this cost would also incur with VSM.
Otherwise it would be best if you would disable async compute using r.RDG.AsyncCompute 0 and then profile both cases using insights or something in order to figure out what gets more expensive.
3 Likes
Yeah, same. Sadly Megalights doesn’t support Hair Strand based geometry…
Is megalights default/raytracing not shadowing geometry collections correctly a bug/future implementation or am I missing something?
Any plans to support the Shadow Pass Switch material node with Megalights?
It’s a limitation of Nanite GC, Tiago wrote above that it was fixed in main, targeting 5.6.
At the moment all RT shaders are shared, so you can achieve the same using the Ray Tracing Quality Switch Replace Node (yes, it’s an awful name:)). Do you need anything more than that?
2 Likes
Thank you @BananableOffense ,
I get your point and it could work for small objects, yeah, however, in this case, I just added the fans to add a stunning shadowing effect in the scene. Your workaround ideas could work, thank you, but are a little hard to implement. In addition I have noticed some non-desired results with light functions in MegaLights (something like too noise or blurryness). But if it’s the only way… maybe I will try it.
Thank you @Krzysztof.N ,
@BananableOffense , according to @Krzysztof.N 's comments, I shouldn’t need to do that workaround, in this case.
However, @Krzysztof.N 's cvars doesn’t seem to have an effect here.
I’m not sure, but I think the moving fans are having a big performance impact, even if it shouldn’t, according to @Krzysztof.N 's comment.
Please, could you all test my demo scene to confirm it, at least? Or I am missunderstanding something? Hit Play and notice the performance changes every 5 seconds, when fans stop/start:
Thank you!
Yeah based on that, the workaround shouldn’t be needed, but it definitely will accomplish it if you can’t get past the bottleneck.
If the fan is spinning fast, I’d expect either the light function or the real shadow to get blurry since neither method generates motion vectors.
The only drawback I found was that the light function was perfectly sharp regardless of distance, hence the need for a distance field alpha or some other way to control the penumbra. A lazy alternative would be to use the mipmap to blur the texture based on distance.
I found the light function to have less noise, since it is not stochastic.
1 Like
Feedback regarding MegaLights that relates to the 1# most voted feedback on the forums here. (Anti frame smearing dependency(TAA, DLSS, etc) seen in various UE5 effects like SS shadows,VSMs, AO, GI, Virtual Textures, and more)
I’m very much a fan of the independent temporal commands for Megalights. It’s a good step away from the usual AA/Upscaling smear abuse in the engine. But if it’s going to be temporal, shadow lines need to be less noisy without AA.
Krzysztof.N
Still it feels like a necessary step in order to be able to remove RT shadows
That’s a painful sentence to read. RT shadows are plenty viable for productions that optimize geometry and provide high quality, noise free(cheaper too with no denoiser) hard shadowing.
One thing that’s bothering a lot of people and myself is the noisy shadow edges with mega lights. Raytraced shadows and other shadow techniques allow users to stick to sharp shadows exclusively to rule out the need for denoising cost/TAA abuse/ visual noise. It’s a trade off a lot of devs would take. So we are asking to prioritize this issue.
Right now, cascaded shadow maps are not supported as a fallback for the directional light. That’s a major issue because that leaves users who do not want the performance impact of RT shadows, the visual issues with VSMs, and want some sort of non-noisy soft directional shadowing via CSM. There are two logical options that accommodate for the growing goals from developers and consumers who fund this engine. This would also help cut the cost of the neighborhood clamping.
- Add support for CSM directional lights
or
- Focus on mega light support for the directional light as long as noise from mega light shadows can be removed by(at least for the cost of soft shadows).
Seeing masked objects as unsupported is quite sad. This would be a major improvement for many game scenarios, if not the second best improvement with the first being the accommodation above. Hope to see it soon.
As seen with Lumen, your team doesn’t work on support for non-nanite meshes because of the “nanite is priority” agenda. People rather budget their scenarios for megalights by saving performance using LODs want the poly count tied to geometric aliasing. Do not tie Megalights to a poor rendering system like Nanite.
Do not develop megalights with temporal AA or super resolution on. If Brian Karis had done this with Nanite’s development, maybe he would have seen Nanite has plenty of popping and geo aliasing. If you develop something to appear clean without AA, people can use TAA if they want and nothing horrible happens if TAA is turned off or configured to be more clear. If you develop megalights with a TAA/Upscaling abuse, you’ll be punishing those who do not want the TAA smear with noise.
smear campaign continues? yeh…
not sure why you wanna go back to csm for directional lights. basic looking shadows. sharp is boring. you never build an overcast scene with raytraced shadows? beautiful soft shadows. even vsm doesn’t do that. the noise is normal. you gotta life with it, if you want soft shadows. the temporal dithering/vector randomization is the bread and butter to make soft shadows possible without computing billions of samples/rays.
also as of current 5.5 csm is still supported for directional lights. you gotta use it, if you want to shadow fog volumes, cause the raytraced directional light currently doesn’t do that.
masked materials is on my list too. it’s a big ask for low poly foliage shadows. you can use geometry and make holes in it in most other cases. or use nanite leaves. so what?!?
i for sure like an optimized “low poly” pipeline too. nanite has use cases, like sculpts and rocks and detailed geometry and foliage lod, but is useless for normal urban geometric shapes and houses. it’s a choice you can make. you don’t have to use it if you don’t wnat to. huh?!?
the push for vsm is what annoys me a lil. small video memory here. wanna push raytracing and still do this bloat of shadow mapping tech. weirdge, for sure. but megalights replaces that fairly well. gotta find optimization for some types of scenes, tho.
when we gonna see footage of your game, btw? it’s coming along?
the noise is normal. sharp is boring
Noise and Blur looks like crap and it’s not normal. Hundreds of thousands of gamers and developers would take sharp over noise. I don’t have issues with temporal effects as long as they don’t smear like Lumen or solely rely on TAA and blurry TSR to get rid of noise.
you gotta life with it,
A garbage outlook on current graphics. If there is a problem, it needs to be priority.
also as of current 5.5 csm is still supported for directional lights.
Never said it wasn’t and you mention a bunch of other unrelated things.
or use nanite leaves. so what?!?
Haha, lets just pretend I didn’t just mention the issues with Nanite and the documented drawbacks of WPO.
I didn’t send feedback here to get replies from something who isn’t in charge of the industry leading game engine. I came for responses from @Krzysztof.N & @TiagoCostaUE about the feedback thousands of people want to hear about. People are tired of blur and noise and we want to know if 1st party is going to begin taking care of this issue.
Megalights already supports sharp shadows by simply setting the light “Source Radius” to 0.
Megalights with FXAA:
I think the quality difference makes it kind of silly to mix these, but I also I think more options are better than arbitrary limitations.
You’ll be pleased to know that supporting directional lighting is something that is being worked on. There is no reason to expect it to be any less capable of sharp shadows than local lighting.
Masked has limited support in the form of screen tracing, but yes hopefully we can get full support in the future. I think this will be important with directional lighting, as larger foliage like trees can’t rely on screen tracing.
Off topic P.S.
Also please keep in mind the line between feedback and making demands.
Feedback is: “I think the temporal stability needs to be improved before I can implement this in my project.”
A demand is: “You need to fix XYZ.”
Your mission for motion clarity is well known and clearly (pun intended) resonates with a lot of people, however, you’ll probably find yourself facing less friction from the portion of the community and the engineers who have to actually do the work if you approach your feedback differently.
The fact that the engine programmers actively participate in an open forum with users, (many of whom generate little to no revenue) and even bother to ask what the community wants to see improved at all is something that should not be taken for granted.
You can ask for considerations for your project’s needs without demeaning the work of other engine contributors, without demanding other people cater to your needs (regardless of their popularity), and understanding that Epic is a business and may need to put key engine partners and their own needs at a priority when shipping new features.
Hopefully you take this in the spirit it is intended. I understand you’ve been banned from some other gamedev communities. I think you should reflect on your communication style because I’ve encountered enough of your posts on this community to say that as convenient as it is to blame everyone else for not seeing eye-to-eye or whatever… Let’s just say if many my contributions turned out to be so controversial, I might wonder if I was at least partially accountable for that reaction.
Controversy is great for the Youtube algorithm, and maybe that will get you somewhere, but it’s not going to win you the respect and cooperation of the people I know you truly want on your side. You know, those individuals in charge of the industry leading game engine.
TLDR I know you actually care about the engine, but I think we should care more about the employees and community who build it and show that in how we interact.
4 Likes
“Source Radius” to 0.
Yeah I tried that and got noisy shadow edges with megalights? Are you super sampling?
I think this will be important with directional lighting, as larger foliage like trees can’t rely on screen tracing.
My concern is the team has already nonchalantly blew off support for traditional optimized meshes with Lumen and non-nanite HISM. Our we going to get “just use nanite foliage” to get proper support?
TLDR I know you actually care about the engine, but I think we should care more about the employees and community who build it and show that in how we interact.
Semi-Offtopic response to BananableOffense
I’m not here to coddle people. People are being paid to work on this engine, that work should not have various issues the community has stated is top priority.
My job is to deliver the feedback and request from a perspective several EG engineers include the ones working on megalights do not have(use case game scenario/motion clarity priorities).
If nobody asks for it, then ofc there will be issues nor is their someone to blame.
But when feedback is given and ignored over and over, it becomes a problem the industry needs to be aware of. What EG engineers decided is up to them.