Are Ticks really that problematic? Should you make all your meshes Nanite? Is the ChildActorComponent truly cursed? Should you never use Cast?
You’ve probably heard many of these so-called "best practices”. Let’s put them to the test and find out which ones are true and which ones are bust.
https://dev.epicgames.com/community/learning/tutorials/l3E0/myth-busting-best-practices-in-unreal-engine
10 Likes
This is awesome Ari! Keep up the great work 
1 Like
Interesting topic! Ticks can affect performance, but their impact varies by project. Not all meshes need to be Nanite, and ChildActorComponents can be useful if used right. Excited to see your insights on these practices!
You turned that into a great talk! Good job on pointing out edge cases, and backing the claims with profiling data.
1 Like
Could you bust a myth for me? I’ve been wondering about the performance cost of Materials vs Material Instances. Some people say this is significant, others that it makes no difference.
Does this make a difference in draw counts or performance, or is it mostly an editor workflow thing?
1 Like
Amazing presentation and it clarified many issues. Thanks Ari 
1 Like
Wonderful article. Cleared up so many questions and hanging concerns I’ve had about using Blueprints vs C++, cost of Casting, using Tick, etc. I also love seeing the shoutout to @CobraCode!
Thanks Ari!
3 Likes
I would like to submit one for Myth-Busting.
In a project I provide, I make use of the IK Retargeter for Live Retargeting. During my own testing with 21 Live Retargeted Character’s in a Scene I was still hitting 110-115 fps. (And that was with Motion Matching and a pretty sophisticated Layering System setup with Linked Anim Layers)
However, I continuously have people telling me that Live Retargeting is insanely heavy and should never be used.
They are under the impression that you can fix Anatomy based Hand Offsets by simply retargeting animations to your character and having all your other different body types use the same skeleton and that somehow your hands will fall perfectly in place on any rifle your character’s are holding regardless of size or Anatomy and that they will still be aiming perfectly straight. (All while using a single anim set for a specific body type as opposed to having anim set for each of the characters that have a differing body type)
I’ve tried to explain to people that Anatomy doesn’t care if your sharing the same skeleton.
Anyway, the main thing I am trying to submit is IK Retargeting Character’s during run-time and the performance impact. I am under the impression they have almost no impact on performance at all but perhaps I’m the one that’s wrong?
1 Like
This is an interesting question! If I understand correctly, you’re asking whether there’s a performance difference between having 100 different objects with 100 unique materials VS having 100 different objects with 100 Material Instances derived from the same master material.
The answer is yes, there will be a performance drawback in the first case:
-
100 Unique Materials:
Each material change involves a GPU state change, which can increase the number of draw calls and add significant overhead. Managing 100 distinct GPU states is more computationally expensive. Additionally, each unique material requires its own shader code and associated GPU memory for constant buffers, further impacting performance. -
100 Material Instances:
Material Instances share the same shader program as their parent material, so state changes are minimal. Parameter changes for Material Instances are handled via uniform updates, which are much faster than switching between different shaders. Moreover, Material Instances reuse the base material’s shader, consuming minimal additional memory for their parameters, which significantly improves efficiency.
However, if you meant assigning the same material to 100 different objects versus assigning the same (only one) Material Instance to 100 different objects, there would be no performance difference in that case.
1 Like
Thanks, yes I meant the performance changes of unique Materials vs Material Instances of a handfull of Master Materials, so this is really helpful!
Awesome tutorial!
I can translate it into Turkish but I don’t know if Epic supports localized tutorials, If it supports I can translate and send you full transcript.
Cheers!
Regarding the “GetAllActorsOfClass is Slow” myth, the current implementation as of 5.5.4 seems to be:
void UGameplayStatics::GetAllActorsOfClass(const UObject* WorldContextObject, TSubclassOf<AActor> ActorClass, TArray<AActor*>& OutActors)
{
QUICK_SCOPE_CYCLE_COUNTER(UGameplayStatics_GetAllActorsOfClass);
OutActors.Reset();
// We do nothing if no is class provided, rather than giving ALL actors!
if (ActorClass)
{
if (UWorld* World = GEngine->GetWorldFromContextObject(WorldContextObject, EGetWorldErrorMode::LogAndReturnNull))
{
for (TActorIterator<AActor> It(World, ActorClass); It; ++It)
{
AActor* Actor = *It;
OutActors.Add(Actor);
}
}
}
}
TActorIterator / TActorIteratorBase don’t seem to be using any kind of caching mechanism, they just iterate through all the actors in the level, and the implementation is more or less the same for GetAllActorsOfClass as GetAllActorsWithInterface and GetAllActorsWithTag.
I feel like I’m missing something - I don’t see how this function would not take a performance hit scaling with the number of actors in a level. Can someone in the know elaborate?
That’s wrong, UGameplayStatics::GetAllActorsOfClass uses TActorIterator which derives from TActorIteratorBase which uses FActorIteratorState to query for the Actors of the ActorClass you request from it. FActorIteratorState’s constructor calls GetObjectsOfClass → ForEachObjectOfClass → ForEachObjectOfClasses_Implementation which queries the hash buckets.
GetAllObjectsWithTag and GetAllActorsWithInterface query every single Actor in the UWorld. You can use GetAllActorsOfClassWithTag to only query the Actor type you want, which uses the hash buckets to get the actors. The Actors of that class type still need to be queried but doing it on a subset of actors will be faster.