The strategy game I’m working on has a lot of “large” (in Unreal units) actors although they’re relatively light in terms of poly and material counts. Regardless, when building lighting I have two actors in particular that generate the error:
Performance Warning BuildingTradingPost_C_0 Large actor receives a pre-shadow and will cause an extreme performance hit unless bCastDynamicShadow is set to false.
It’s early enough that if we HAD to then we could change the scale of the actors - but is this necessary? I don’t like warnings - particularly not warnings that warn about extreme performance hits!
Any movable meshes (Mobility == Movable or InterpActor / KActor / SkeletalMeshActor) when combined with stationary lights have to use a special kind of shadow called a Preshadow. This handles the static environment casting dynamic shadows onto the dynamic object. The entire environment between the movable object and the stationary light will have to be rendered into the Preshadow, but only when the movable object actually moves enough to require an update.
There are a few performance hazards that happen with movable objects and stationary lights:
If there are lots of movable objects (hundreds), the per-object shadow method used can end up being less efficient than if whole scene shadows were used. You don’t have much control over this right now other than to limit the number of stationary lights that affect an area, hopefully we will get better controls in the future.
If the movable object is very large, and it moves, this can cause the entire scene to have to be re-rendered into the Preshadow depth map. This is what the warning is talking about. This will be both a CPU and GPU cost, however it will only happen for one frame (results are cached until the object moves far enough to invalidate the cache) so it’s usually pretty hard to measure. If the movable objects move every frame, it can show up in ‘stat shadowrendering’ (CPU) or ‘profilegpu’ (GPU).
If the movable object is only changed occasionally you are probably fine. In the end you just need to make sure your performance is good enough on your target hardware. Useful commands for investigation are:
‘stat unit’ - shows the 3 parallel thread - max of GT, RT and GPU gives the frame time
‘stat scenerendering’ - overview of CPU rendering thread time
‘stat dumpframe -ms=.1’ - full stat hierarchy of where CPU time is going
‘stat shadowrendering’ - CPU RT time issuing shadow depth draw calls
Hi Daniel – thank you; terrific answer. Just to clarify:
This is a strategy game, so these are on buildings which are generally only placed down once (either before the game session begins or placed by the player in-game). So it sounds like this would not be a significant performance issue according to your comment; is that correct?
It also seems like the editor is detecting that these are “large” objects because our default tile size is 2048x2048 Unreal units – and the concern is that a building will affect many scene objects at runtime due to its size. However, if that’s our default tile size, then it’s actually not very “large.” Is that assumption correct? Or is there something inherently bad about using static meshes much larger than what Unreal assumes the default object will be?
We are planning to have only major light source (1 directional light) in each game session, plus a few dynamic lights that will each be much smaller in scope.
So it sounds like this would not be a significant performance issue according to your comment; is that correct?
Correct
However, if that’s our default tile size, then it’s actually not very “large.” Is that assumption correct?
Right, it’s an absolute size threshold, it does not take into account the relative size compared with your scene
We are planning to have only major light source (1 directional light) in each game session, plus a few dynamic lights that will each be much smaller in scope.
That sounds fine, but the most important thing is to profile your scenes on your target hardware with the methods mentioned above.
Thank you for your feedback. Despite the warning message, are you having any loss of performance? If not, then it can be ignored as just a warning for machines that are not very powerful. If you are concerned about the asset causing errors, I would be happy to test it on our internal machines if you provide it.
The “Help” link not functioning is a known issue and a report has already been filed. I apologize for any confusion this caused.
Hi Alexander – that doesn’t quite answer our question (I work with Neil).
How exactly would we know that there was a performance hit? It says it’s an “extreme” performance hit but I’m not sure how to quantify this – any performance hit is undesirable if it’s something we can easily avoid. Should we make a smaller model, or rescale the actor, and put 1000 of them and quantify the performance difference just to test it on the basis of this warning?
Exactly what would be causing this performance issue? Would it be CPU, or GPU, or what?
In any event, I’d be happy to give you FBX files for the 2 assets causing these problems; how should I send them to you? Is there an e-mail address I should use?
One broader question: right now, we’re using 2048x2048 Unreal units as the base dimensions (in X and Y) for all of the buildings in our strategy game (some are larger). We’re also creating all of our basic assets using that scale so that we never have to rescale any of those buildings in the Unreal editor.
The sense I get from the error message is that maybe that scale is too large somehow? Is that correct? Should we have picked a smaller value for our base tile size?
It’s not too late to switch to a smaller scale if there’s a good reason for us to do so.
I’ve confirmed that this error is happening for us on several different maps when we try to build the lighting.
I’ve taken the 3 static meshes that are causing the problem and put their uasset files up in a new folder inside the FTP site so you can try to repro this locally:
FYI, for anyone receiving a huge performance hit from this like I was. Just setting your lights to “Moveable”, especially the directional light will help increase performance significantly.
Not sure why you got a downvote. Wish they would have posted something so I’d know if there is a pitfall I’m overlooking. Anyway, setting the directional light to movable was the only thing that fixed my issue with shadow maps and grass. Thanks for the suggestion.
Still seeing this issue in 2023 with InstancedFoliageActors that are generated by the UE5 editor when adding foliage to the map. Why would UE generate actors so large that they have shadow casting when the size of these instances is entirely controlled by the editor and not the user? What solution do we have to address this? Not finding anything on google or the forums.
"InstancedFoliageActor_25600_0_-1_-1 Large actor receives a pre-shadow and will cause an extreme performance hit unless bCastDynamicShadow is set to false. "
The issue is NOT that the foliage actor casts shadows, but its size. But since its size is not something we control, what can we do?
The simple fix for me was just setting these large props (my trees) from Movable to Static in the BP settings for the Static Mesh component. It’s literally a one click fix.
btw, this does not prevent any effects such as WPO wind when set to static. If it’s foliage, a building, etc. Static is what I would use. If it’s something you can move in game then keep it movable.