Why is Unreal Engine interal code using additional variables to store the UEPROPERY variable from a node

Development Programming & Scripting C++
, , ,
1

Hi guys! I’ve been looking around the interal code of Unreal and I was curious about one thing.
I realized they use additional private variables to store and work with them instead of UEPROPERTY variables of the nodes. I’ll put an example in order to make it more visual.

They have a class member, declared as:

struct.......
public:
     UPROPERTY(EditAnywhere, Category=Settings, meta=(PinShownByDefault))
     FVector Axis = FVector::ForwardVector;

Then, they also have a class member variable which looks like this:

private:
    FVector ActualAxis = FVector::ForwardVector

In the update method they copy this public UPROPERTY variable to the internal private one.
Then, instead of accessing to the public one they access to the private one. I just want to know, why?

I mean, is it faster to use a non UPROPERTY variable? Does this increase performance?
Thanks in advance!

3 Likes
2

One reason I can think to do that is if you want to expose the public Axis for blueprinters and intend for them to be potentially changing it often. The order tick functions get called in is random and if you need to know the value that Axis was when your calculations last ran, for example to do more/delta/accel calculations, then you’d want to save it in each Update to some private value that nobody else will be changing at unexpected times.

There definitely wouldn’t be a performance gain by copying the value. It’s a minor performance penalty in fact, so you wouldn’t want to do it unless you need the duplicate data for some reason.

3

Yeah, that can be deffo one reason to do this. I was just curious, but I guess it’s a good practice to follow. I have no idea but maybe multithreading can cause unwanted changes in these type of variables, because of that the copy.

Thanks!

4

Is this something that UE does all the time? It seems like a one off thing that they did for a very specific reason. It would be great if you mention where did you find that code. Maybe it’s something very specific in that script that required having a duplicate value.

5

I’ve seen this in some scripts. One example is: AnimNode_OrientationWarping. Take a look at the end of the header file where you can see a variable called: ActualOrientationAngle. Then, each frame they copy the UPROPERTY OrientationAngle to the ActualOrientationAngle in the EvaluateSkeletalControl_AnyThread method

6

I think the mention of Threading there is pretty important – I’m guessing th is is a 5.x item, since I don’t have it. But, yeah, it’s definitely limiting the changes occurring to always come in via a public interface, and changing the internal variable at a specific known place.

7

Agreed. Knowing nothing else about that method, the name format *_AnyThread leads me to believe that it fully expects its variables to be changing on different threads, at any random unknowable point in time, and so it wants to make a copy of the variable and know that it does not randomly change at the worst possible time.

In other words, that variable is free to change whenever it wants by other threads. But when we start a function that’s going to compute things based on the value of it, we don’t want that value unexpectedly changing DURING our function call. Thus we make a copy of it.

It’s basically like a thread-safe read without having to deal with mutexes, and as long as you’re not trying to pull multiple related/interconnected variables simultaneously, it should work fine.

8

Yep. I totally agree with that. Solved then!