I can try to check that on smaller scale with few unique levels. But yes, you can load the SAME level multiple time with different transformations. That is the exact case I’m talking about.
I see. And what about changing the method to Spawn Actor of Class? And you spawn a Level Instance (if I remember fine, as I usually work with PLAs -packed level actors- which is the “next” step. You can also try it, by the way).
Hi @JaroMast,
Can you share a small project that reproduces this issue? Or if not possible could you provide more info regarding the level where you are seeing this issue:
- How many actors are there in the level?
- How many ISM or HISM actors?
- How many instances per ISM/HISM?
- Are the ISM using Nanite meshes?
- How many skeletal meshes?
Does the time spent in RayTracing_FinishGatherInstances change significantly between editor and running the game? If so, do you have blueprints or other logic that only spawns instances when running the game and not in editor?
Thanks!
@Miguel1900 I’ve taken a look at the project you shared and here are my findings using Unreal Insights:
When the fans are enabled, there’s 13ms overhead on render thread which can be avoided by using r.Visibility.LocalLightPrimitiveInteraction 0.
There’s also about 15ms overhead on game thread, executing the tick of the fan actors (which is not MegaLights related). Of those 15ms, ~5ms is caused by UpdateOverlaps() which can be avoided by disabling Generate Overlap Events or collision altogether on the relevant components.
CreateLightPrimitiveInteractions overhead which is avoided using r.Visibility.LocalLightPrimitiveInteraction 0:
UpdateOverlaps() overhead:
After disabling Generate Overlap Events:
9 Likes
Hi @TiagoCostaUE ,
Thank you very much for your time testing and the detailed insights!! So glad.
Following it, I have been able to improve the performance a little and now it’s loosing around ~30% performance when spinning, instead of ~50%. I have been making some additional tests too, and noticed if enabling Nanite in the spinning meshes would improve the performance quite a bit. Additionally, if completely disabling collisions on those spinning meshes, performance wouldn’t drop and would maintain at 100%.
I know this is not directly related to ML, but anyone knows if this should be normal?: many spinning actors would heavily hit the performance due to their collisions (even if just Query, no Physics).
@TiagoCostaUE , I also noticed when using RT shadows the performance won’t drop even with collisions enabled. I think ML relies in RT shadows, right? Couldn’t them benefits from this RT shadows ‘feature’?
Thank you again and best regards!
1 Like