Hi - I’m watching the ‘Demystifying Soft Object References’ from Unreal.
Something I don’t understand is that in order to reference the object later they’re still creating a hard object reference which they cast to from the soft object reference once it’s loaded.
In the case of the example they use, they’ve created a soft object reference called ‘Soft Skel Mesh Ref’. But they still create a hard object reference called ‘Empty Skel Mesh Var’.
The only advantage I can see is that they don’t have to pre-populate the default variable of the Empty Skel Mesh Var in the blueprint (which I understand would create a hard reference to that mesh in the memory).
So, let’s say I have a character that can interact with items. I have a hard object reference to the interact_base class called “Interact_Ref”. It doesn’t have anything loaded as a default variable. When I interact with an object, I then set Interact_Ref to the actual object my character is interacting with. As I don’t need to declare the actual interactable object in my Interact_Ref until the character has interacted with it, is there any benefit to making this a soft reference?
I’m not great with soft object refs, it’s quite hard to get right.
You can tell if you have it wrong, though, by right clicking on the blueprint, and choosing ‘size map’.
I think in this case, yes, they have a skeletal mesh reference, but it’s not a specific mesh reference, so that’s ok.
However, I can tell you that, as far as interacting with objects goes, using a blueprint interface is the cleanest way. You just have an actor reference.
Thanks for the response! Yeah, I’m thinking that the hard reference is empty maybe it’s ok?
I’ll check out the size maps to double check, thanks.
I use interfaces a lot. They still need an object to call them on so that’s fine for the player as I can use Get Player Character for example. But for an interactive object once I’ve identified it I might need to access it again later which is why I had a hard reference variable. I wonder is it better to make that variable a generic actor (instead of my interactive object BP) so it won’t have as many additional variables to store in memory and then I just call the interface on that generic actor?
Even an unassigned hard ref will mean everything gets loaded. What I mean is, I think it is a generic skel mesh reference, rather than a specific one.
The whole point of interfaces is that you interact with ‘actors’, so it’s fine to keep references to as many actors as you like. No size problems, it’s the moment you get specific, the engine starts loading everything.
Makes sense. Interfaces with actors might be my best method then.
I see what you’re saying for the Skel mesh reference. A skeletal mesh is pretty light weight vs say a custom interactable_object BP which might have a lot of variables and components.
Thanks for this, it has really made things click and I’ve been moving my hard referenced BPs into Actors and converted to interface which works a charm.
This got me thinking though - what should be hard referenced and what should be interface / soft referenced? The general stuff I read is generic i.e. Use interfaces as much as possible, if you know you need in memory at all times use hard refs, soft if you don’t etc. etc.
But, I’m thinking more specifically. My player character has a hard reference to my HUD as that also controls my inventory. As I always need it in memory is that ok? What about animation montages? I have a bunch of them in my player character BP, but maybe they’re small enough it’s ok? Or they should be soft references and loaded on demand? Or should they all sit in a data table and hard reference that?
Are there any kind of best practices for the different asset types?
Right, good point on the modularity! I’m going to try and decouple as much as possible.
I have quite a few anim montages I use. They all show up as hard refs right now. From a modularity point of view, maybe storing them in a data table is cleaner than hard refs scattered through my BP, although then I’m adding an additional table lookup each time (is it worth it?). But obviously the data table will still be hard referenced anyway. As I will need to run anim montages on demand (pickup, open door, search body etc.) it probably makes sense to keep them in memory.
I’m learning a lot here, thanks! It’s surprising that there’s not tons of stuff online about this. I mean, you can find it (I actually saw the thread you were on where Epic were explaining why to use Actors), but a LOT of tutorials and examples hard reference everything.
If you will access all the anims every time you use the character, then hard-coding is absolutely fine. The only possible exception would be if the character load took a long time ( which it probably doesn’t ).
I don’t think it’s covered on youtube etc because it’s a quite subtle point, and 99.9% of the people who lookup tuuts just want to make things actually work
just an FYI, Animations aren’t load on demand assets. All animations for a class are loaded to memory when that class is initialized. Every animation for the character, blend spaces, poses, aim offsets, montages etc.
If your character references weapons… say guns that have animations, those animations will be loaded as well. same applies to any class/asset that uses animations.
If they relevant to the player (client) they will be loaded to memory.
Just to clarify things a bit, since the example of a single skeletal mesh soft reference is perhaps not the best illustration, I thought it might be worth using another real world example.
A better example might be weapon inventory. Imagine a Player has a data table that holds all possible weapons. If that data table is using hard references, when that data table is accessed, it resolves and loads all weapons it references. This might be 100 different weapons. With all the associated mesh, texture, materials, animations, and blueprints it is a huge deal.
If the data table only uses soft references to the weapons, when it is accessed it can be instantly loaded. Only if and when the player uses a specific weapon will it need to be loaded. This makes loading much faster and the memory footprint much smaller.
@Rev0verDrive - Thanks, I didn’t know that. Most of my montages are probably used enough it makes sense to keep them in memory anyway, but I expect I’ll have a couple that will be rarely used (maybe a special quest). I would have probably soft referenced them, but it sounds like there’s no need as they’ll get hard referenced regardless.
@OptimisticMonkey - Makes perfect sense. Soft ref the assets in data table and then just pull out the soft ref object when it’s needed and load it.
What do you guys think about HUDs? Right now, I’m not using the HUD class, but just a user widget for my hud with all of my code in it. I have it directly hard referenced with my player character (as there will only even be one - single player game).
As my character has inventory this makes adding and removing items and marrying it to relevant character interactions pretty fluid. My HUD always needs to be in memory as it’s contently being updated. BUT… this doesn’t make it super modular. Do I convert to interfaces? Thoughts on best approach?
Every animation sequence, montage, blend space etc that is targeted to your characters skeleton is loaded to memory when the character is loaded. Regardless if the animation is ever used or not. You could have a random anim that isn’t used by anything in your project. If it is targeted to your skeleton, then it’s loaded in memory.
