Casting vs Interfaces which is faster in terms of engine overhead?

Hi everyone I am looking at tutorials on BP Interfaces and I am just wondering which is faster in terms of engine overhead Casting or Interfaces?

Something tells me a BPInterface would be a lot better to use and easier on the engine than Casting but I just want to make sure before I start doing everything with Interface BPies. :slight_smile:

Are there some things you should always use Casting with and some things you should always use Interfaces with for example?
Is it a good strategy to abandon Casting completely and just do everything with Interfaces or is that a bad idea?

The reason why I ask is it seems more work to set up an interface than adding a Casting node so I guess I am just wondering why not just use a Casting node? Is Casting “heavier” for the engine to handle than an Interface or is it simply a matter of you save time in the long run if you have a lot of cross communication going on between BPies?

[FONT=Noto Sans]I am just wondering I don’t see any Twitch streamers use Interfaces and I am wondering why not. They just cast.


I would say that most people use casting in their tutorials, because it’s just easier to set it up, makes the tutorials easier to follow along etc. But as everything else with UE4 it all depends on individual needs. If you need to cast a lot then it might be better to look for an alternative solution. In terms of one being faster then the other I do not know the answer as I am not that advanced with the engine myself.

O.k. thanks.
I am getting some good answers here too:

Hi! “Casting” and “Interfaces” are very different things, but I don’t think using any of both features affects performance in any way because they are very basic operations, like getting a reference from an instance. You can look similar thread here: .

And if you need more theory behind Interfaces as a programming language feature take a look at C# interfaces, or Delphi Interfaces to have better understanding how and when to use them.

Great thank you!

So lets say I want to eliminate the level BP altogether … how would I deal with standalone triggers and actors? There doesn’t seem to be a way to create an “onactorbeginoverlap” inside the node graph of a Pawn Class BP or even a reference to a standalone trigger or object.

I was thinking of putting all triggers on their own BP so then it would be easy to cast in between them and other BPies but I don’t know if that would be overkill or not.

Or is it common practice to still use the level BP in cases like that?

Depends. If your actor is static level BP is enough.
if your actor moves, then the interactions should go with.

To get a pawn to have some sort of trigger you just create a mesh of any type on it, set it to invisible and create a custom on begin overlap event for it.
Be warned, you need to make sure your collisions are set up correctly - and that the pawn ignores that collision.

There is and there are a few ways to pull it off and they’re pretty much indispensable. Below, whenever *anything valid *overlaps the Opponent, the player will know who was overlapped by whom, even though the player was not the instigator.

Imagine a game that is completely procedurally generated and there’s absolutely nothing in the Level Blueprint, so doing the above also does nothing. Since you do not have references to the pickups that will be randomly popping up, there’s nothing to register at Begin Play. But you can register events dynamically as the objects are spawned (via Actor from Class). This can be done by the blueprint that spawns them (like an item generator responsible for binding and unbinding), by the player, or you can have functionality in the spawned object itself hooking up its elements to a relevant framework class.

As you spawn objects, you register their events and use additional dispatchers if the components’ are not enough and you need to send more data. [HR][/HR]

Not an overkill at all - and in many cases no casting is required. Or you cast only once when the object is spawned to register something inside or set up a dispatcher. Casting is often required when you go heavy on the inheritance. You have a base Pick-up class and several sub classes with unique functionality. You call talk to the base class and call Collected and all children subclasses will know what you’re on about. But when you need to talk to a specific child class and call something unique to them only, you’d need to cast.

What I mean is a Pickup that repairs your ship and a Pickup that is a trap that destroys your ship. They share the same base class and both can be picked up and float about in space (I *know *about your cool little drones o_O), but they do something fundamentally different.

I’ve been using Interfaces for classes that are completely unrelated. Not sure if that’s the right way to do it, but it has worked well for me so far.

The common practice is picking the right tool for the job and eventually you’ll be casting, dispatching events and calling interfaces functions. It’s hard to tell (for me) what works best for what unless you have a specific scenario in mind.

Great info thank you. Yes makes sense. No “safe strategy” one just has to venture into this and figure out the best way I guess. :slight_smile: Think on your feet.

Thank you.

Thanks for taking the time and writing all this detailed info.
I am copying and pasting everything into my Unreal notes. :slight_smile:

Just to add a footnote in case it wasn’t mentioned already. There’s a wider implication of using Casts vs Interfaces for developers… Most practical games have multiple characters, weapons, vehicles (sometimes hundreds inherited from base classes etc). If you had to cast to all of them individually it would be slow and messy. Interfaces offer a much more user friendly option which you can loop through… Whereas with Casting, there’s no easy way to automate it all, its quite fixed…

Good points thanks.

Kind of already stated - but a huge benefit of interfaces over casting is the decoupling of dependencies it provides.

A lot of casting can result in a hierarchy of dependencies that must be resolved when that asset is loaded. This directly impacts load times and memory footprints.

It can be enlightening to use the sizemap (right-click on asset). Casting causes hard dependencies that will result in fairly huge size maps…

imo prefer interfaces over casting unless the objects are always dependent and coupled.


Thank you. Noted.

In addition to what was already said about memory usage, which is the biggest issue, I just wanted to add: NEVER cast in any of your Behavior Trees. That includes Decorators, Services and Tasks. It causes a circular dependency that doesn’t throw an error right away, but will break randomly and corrupt your behavior tree. This is a known issue.

Thanks adding this to my notes.