Am I misunderstanding what soft references do?

Everything I’ve seen about soft references has told me they work like this:

  • Using a soft reference means the referenced class will not be forced to load into memory
  • referenced class only takes up memory when it’s already there, or when the user specifies

However, let’s suppose I create a class called BigClass. It has a bunch of bloat in it and takes a good chunk of memory. Then I make another class, an Actor subclass called SoftTest. Inside SoftTest is nothing but a single variable, a soft reference to BigClass.

Why is BigClass loaded into memory when only SoftTest is placed in the scene? Like fresh editor, empty scene, use “Obj List class=BigClass_C”, no instances. Add SoftTest to the scene, suddenly there are instances in memory. I thought the point of soft references was to not take (much) memory space unless told otherwise.

If this is not the case, then please, help me understand what I’m missing

1 Like

Make the variable of type actor. Then, in the details, there’s a space to choose what class it will load later… :slight_smile:

Okay sure, but that’s for soft class references… so then what are soft object references for? Is it to keep classes inside your referencee class from being loaded by the referencer? like for example if BigClass had soft references to other classes, they wouldn’t be loaded by SoftTest if it hard referenced BigClass?

Or i guess summarized:
if we had classes A, B, and C, and → means a reference link

A → B
B → C
A -/> C?

Yes, not sure about soft object refs, because you can always use an actor ref, and that will handle most things.

True.

Soft is always about loading when you want to.

okay so I did somewhat misunderstand soft references then. It would be more about reducing “chained” references so to speak

1 Like

Yes, soft refs are about breaking up ‘asset chains’. When you load something, half the asset browser doesn’t come with it.

1 Like

textures and meshs are also good for SoftObjects since they tend to be big on memory.

i’d say its more for things like DataTables, when you query a table you dont want to load every texture in the game.

in actually gameplay you are more likely to use baseclasses (actor) or interfaces to break chains

BTW: It’s very possible to achieve totally modularity without soft refs ( in a lot of cases ), if you get into interfaces.

I am familiar with and have used interfaces quite a bit. I was just hoping soft refs would help me avoid using so many interface funcs. In BP I find that I often run into situations where a BP function and an interface function are similarly named. At least enough so that I either have to select the specific function with arrow keys / mouse, or type out the entire function name. The more I use interfaces to decouple, the more often it happens. I suppose it’s probably just a naming skill issue, but it would be nice if there was a way to filter in and out certain interfaces from the context menu.

So I instead tried a sort of “brain” or “public accessor” component type of setup. Just have a lighter weight component that holds any data / funcs / delegates I know is going to be used as public a lot. Then I can use an interface to retrieve this component and cast to the lighter weight class. Still most likely uses up a bit more memory than just interfaces this way, but for me its less annoying lol

this is a good pattern, and often we do need a hard ref anyway, ie for event dispatchers. if its a component though you can ditch the interface and use GetComponentByClass