Download

How expensive is casting to other Blueprints to get variables and fire custom events?

Development Discussion Blueprint Visual Scripting
#1

I’m currently setting up my control system in a ‘Player Controller’ Blueprint, which takes values from other Blueprints before passing the results to the ‘Player Character’ Blueprint via at least 1 event, depending on how many inputs are active at once. For example, iIf the player was pressing 6 buttons on a gamepad and using both analogue sticks then that would fire 8 different events in the ‘Player_Controller’, which in turn does a variety of checks and calculations (X & Y sensitivity, delta time, stick calibration, button remapping etc) before firing 8 more events in the ‘Player Character’ Blueprint

I’d like to know if this is sounds excessive. I can move all of this to the ‘Player Character’ Blueprint to cut down on casting, but then it leaves me wondering why have a ‘Player Controller’ Blueprint at all if handling input logic there and subsequent logic in the ‘Player Character’ Blueprint is inefficient.

#2

From a programmer’s perspective, casting is not really expensive. Without knowing exactly what ue’s implementation is, casting is usually done at compiling time, and even if it isn’t (dynamic casting) it would probably never bottleneck your project. I would suggest making your BP code as simple to read as possible and then worry about this kind of performance hits. Saying that, I always found that having stuff on player character always produced a bit of simpler and more readable BPs, but that really depends on what your project is. Handling stuff in player controller would allow you to have many kinds of characters with the same input structure.

#3

Have you looked into BP interfaces?

Narg

#4

Casting is usually cheap.

Haven’t really checked details of blueprint cast implementation, but there in general two flavors.
Cast and CastChecked
Cast will check for nullptrs, and if cast failed it will return nullptr, and you have to handle it yourself. It’s usually bit slower, because of those checks.
CastChecked assume, that you are 100% of type you cast for, and it will return some value. If CastChecked result in null it will crash.

I’m not sure if pure version of Cast in blueprint is normal Cast or CastChecked.

It doesn’t change much. To access BP interface you make behind the scene cast, to determine if class implements interface.
Interface, is just design tool, which should make organizing functionality easier. It work on the basis:
“I want you to have these functions, I don’t care how you implemented them”.

#5

It is expensive enough that you should avoid it in your tick event. Other than that, I see no problem using it often.