Mesh Spawn Dilemma: Is TSoftObjectPtr the Way to Go?

In the BeginPlay method, my RandomizedActor c++ class randomly selects one mesh from an array of UStaticMesh objects and sets it in the UStaticMeshComponent.
I use this class to create collections of objects that offer randomization when the game starts.
My question is whether it would be more efficient to store an array of TSoftObjPtr<UStaticMesh> objects instead (and eventually async-load them), especially considering that I may have many instances of these randomized actors in the scene in the future.

Of course, I am fully open to different methods of doing what I’m trying to accomplish here.

Thanks in advance!

Pretty standard way to do it is a static mesh “manager” or “factory” class that anything can request a reference to a mesh from.

Manager should load up a library of common meshes, then anything else can request a mesh by some common name during PostInitializeComponents() or BeginPlay() (or whenever).

We have similar managers for common audio, materials, particle systems, and other more game specific stuff. Not sure what the “TSoftObjPtr” buys you vs. a standard pointer. We’ve never used them.

@Shmoopy1701 Use soft pointers to async or sync load, because a standard pointer will cause a class / object to load into memory even if you never use it. This causes as huge increase in memory usage compared to using only soft pointers. Every “hard” pointer found in a class will have that class loaded, recursively. For example, if you create a hard pointer to a datatable and that datatable contains hard pointers to textures, all textures on all rows will be loaded even though you are not using them.

All about Soft and Weak pointers | Tutorial

You can store your randomized assets on disk and load them through soft pointer yes, but this has 2 downsides. 1. you limit yourself to X amount of random assets, 2. you use disk space. Normally when you want to heavily randomize you want to set up a single class / asset which randomizes its values by a Seed number. Optionally you can then filter out Seeds you like / dislike and only store a series of numbers to completely recreate all assets you would otherwise be storing on disk.

1 Like

Hi guys, thank you both for taking the time to help me. I really appreciate it. At this point, I think I will explore the idea of having a single class responsible for randomizing the behaviour of other actors.

Any advice to guide me in that direction would be very welcome. I am aware that one of my weaknesses is the “macro” aspect of things; software architecture is not my selling point eh eh.

I often find it difficult to determine the best way to approach a problem.
I end up thinking, ‘I could do it this way, but I could also do it that way,’ and so on, which leaves me feeling discouraged.

Thanks again! :smiley: