Question AssetReference in ScriptableObject that is always loaded(Preloaded assets in PlayerSettings)

Is it possible that addressable assets that are serialized as AssetReference in a preloaded ScriptableObject are always loaded into memory?

I am unable to find this information anywhere, if someone could point me to the correct location I would very much appreciate it.

I've tried with profiler and memory profiler, however the references they show do not provide anything tangible.

 

You will need to load them into memory yourself.

Last I remember though, the point at which pre-loaded assets are loaded into memory is too early for the addressables system to be called. It's best to manually load them in with a boot-strap scene (you'll need one using addressables anyway).

That's how I work it anyway.

 

I don't want to preload them. I am trying to figure out what is causing them to be loaded into memory without manually loading them. I cannot find any useful reference info from profiler.

 

I've tried also with memory profiler package but nothing helpful was shown as to what is holding/loading the assets into memory.

Also it was an editor capture.

 

Thanks Martin, will do that in the following week. But just for information sake: Would an AssetReference in a ScriptableObject that is included in the PreloadedAssets in PlayerSettings cause the addressable asset to be loaded into memory?

 

No I don't believe it would. I haven't experienced this at least.

Most likely some editor-specific behaviour is at play here.

 

I am terribly sorry for not getting back about this issue. I have since made a debug build with autoconnected profiler and used memory profiler to see the same result.
I also consulted chatGPT who output the following:

In Unity, when you have an AssetReference in a preloaded ScriptableObject, the referenced asset will be automatically loaded into memory along with the ScriptableObject. The asset will be loaded when the ScriptableObject is loaded, regardless of whether or not you explicitly access the asset.

This behavior is due to the fact that preloaded assets, including those referenced by AssetReferences in ScriptableObjects, are loaded into memory during the initialization phase of your application or when the asset bundle containing the asset is loaded.
​

Not sure how to work around this if at all possible, our preloaded scriptable objects are always loaded, but if addressables can't work past this then I am not sure what can be done here. Is there an attribute I could attach to the AssetReferences that would make them not get loaded into memory for no reason whatsover?

 

ChatGPT is spewing hot nonsense (as usual) and confusing you.

If you have an AssetReference in a scriptable object that is in preloaded assets, that asset reference is not going to be automatically loaded. Why would it? Why would Unity traverse the members of these assets via reflection if it just happens to have an asset reference? It makes no sense why you would think this to be the case.

If you have an addressable asset (one in your addressable groups), that you also reference via pre-loaded assets, then that asset is going to be duplicated at build, and you'll have one loaded into memory upon application start, and one in your addressables groups waiting to be loaded.

 

Sorry for the delayed reply.

Well the issue was solved when I replaced the AssetReference with a string(key). So I believe what I've said still holds water. I still believe it shouldn't force me to use strings instead of AssetReference, so not entirely sure what's going on there.

The entire hierarchy in my case was like this:
* GameData(ScriptableObject) - Preloaded asset

* Creature(ScriptableObject)

* AssetReference(GameObject) -> This was being loaded
​

Did you test this behaviour on your end?

 

I've had plenty of scriptable objects in preloaded assets - either direct or indirect - with asset references. And these references have never been loaded without me explicitly doing so.

I literally have one that holds all my config scriptable objects and loads them into memory on application start:


Something in your code was loading it into memory.