Search Unity

Should scriptable objects be addressables? + few easy questions

Discussion in 'Addressables' started by mailfromthewilds, May 15, 2020.

  1. mailfromthewilds

    mailfromthewilds

    Joined:
    Jan 31, 2020
    Posts:
    217
    My SOs are light-weight but theres ton of them. Sothey only have strings,floats and ints in them, but theres like 300 of them and can the amount grow.

    i thought about storing references on an object to all of my SOs, but thats still ton of references and SOs in memory.

    for more heavy things like 3d models im using Addressables. Ive also started using ScriptableObjects with addressables, as in i spawn SO like an addressable.

    The Code I use for addressables is:
    Code (CSharp):
    1.  
    2.     public InvData invData;
    3.  
    4.  
    5.     void Start()
    6.     {
    7.         Addressables.LoadAssetAsync<InvData>("Assets/2Items/" + itemFolder + "/" + name.Replace("(Clone)", "") + ".asset").Completed += InvDataLoaded;
    8.     }
    9.  
    10.     void InvDataLoaded(UnityEngine.ResourceManagement.AsyncOperations.AsyncOperationHandle<InvData> aOH)
    11.     {
    12.         invData = aOH.Result;
    13.     }
    14.  

    Here are my questions:

    1. Should I use scriptable objects with addressables? (again, i have many of them but theyre lightweight)

    2. What happens when I use Addressables.LoadAssetAsync twice to load an SO (once from script X and once from script Y? will that asset be loaded into memory only once or twice? will memory contain just one instance of that asset or two instances?

    3. if i spawn 3d model with addressables, then assign scriptable object to it (also spawned with addressables) then is using ReleaseInstance on 3d Model enough to release the SO which was assigned to the model? or do i have to first release the SO and then the model to not have them (SOs) still loaded in my memory?

    would be great if someone could answer :)
     
    FlightOfOne likes this.
  2. phobos2077

    phobos2077

    Joined:
    Feb 10, 2018
    Posts:
    350
    I don't think it's wrong to do it. The easiest way to load them would be to put them in one folder, add this folder into Addressable Group and assign a label to it. This way you can load all of them at once and add/remove any files within the folder w/o having to mess around with addressable groups.

    Also the important thing about loading ScriptableObjects you have to remember (also prefabs, for that matter), consider every direct reference to other assets they contain. If your SO has, for example, reference to a prefab, referencing 3d model and material, which references textures etc - all these assets will be loaded before the requested SO is loaded. This is important for loading times as well as asset bundle sizes.

    It will be loaded only once. You might use two separate AsyncOperations (for example if you load the same object via label and then via address), but because the object is in the same AssetBundle, the Unity should take care of not loading the object twice.

    I'm not sure what you mean by "assign SO to 3d model", but AFAIK you have to release these objects separately. So for every LoadAssetAsync you need to do the corresponding Release.
     
  3. mailfromthewilds

    mailfromthewilds

    Joined:
    Jan 31, 2020
    Posts:
    217
    oh i see. yeah ive added folder to addressables, but do i need the label? im not sure what labeling the folder does.
    btw, does the addessable path (or the way to load an asset) change if i use label or folder?
     
  4. phobos2077

    phobos2077

    Joined:
    Feb 10, 2018
    Posts:
    350
    1. Every asset you add to Addressable Group has an address that defaults to the path (including "Assets/"). Folders work a bit differently. When you have a folder added to Group, each asset inside will be implicitly added to addressables with addresses generated based on the folder address + relative path to the asset inside folder. You can't change addresses for these implicit entries, but you can drag certain asset to the group directly, then it will change to an explicit entry and you can assign custom address.

    2. Labels are used to load many assets using one LoadAssetsAsync call. Normally you'd have to assign a label to each asset individually after you drag it to the Group. But with folders you can assign label to the folder once and then all implicitly added entries will have this label. This can be very handy.

    Another benefit of using Folders is the reduced chance of merge conflicts. Because in the Asset Group file you will have only one entry (the folder) and then when you add new files to this folder, they become addressables automatically and Asset Group itself doesn't change. If several team members add different assets to the same folder, there will be no collision.
     
    mailfromthewilds likes this.
  5. mailfromthewilds

    mailfromthewilds

    Joined:
    Jan 31, 2020
    Posts:
    217
    oh. yeah i dont need labels for my game as of now but they may be handy in the future.
    do you know if theres a way to exclude some files if i use folders?

    these files .blend1 kinda create themselves automatically (and are useless) when i edit/save 3d model. dont need them in addressables

    edit.. nvm.. stopped blender from creating them! thank you for your time
     
    Last edited: May 17, 2020
  6. Arthur-LVGameDev

    Arthur-LVGameDev

    Joined:
    Mar 14, 2016
    Posts:
    228
    Ah wow, this is fantastic and I did not know this was the case. Merge conflicts related to Addressables data is a continual issue we're experiencing, if this solves/alleviates even 50% of those cases it'd be a massive win.

    Off to try it right now -- thank you for this gem!!!

    PS @ Unity Devs:
    A) This belongs in documentation. There's a whole page written about "developer workflow" and nothing about how to avoid merge conflicts, which are basically inevitable even in small teams (and likely would be near insurmountable in large teams); this 'trick' specifically warrants mention, basically the entire "how do folders work" warrants explanation/docs.

    B) The tangentially related issue -- merge conflict-prone data-structures -- probably just needs attacked directly & changed/fixed because, unless there are additional/many more tricks we're still missing, it's simply not scalable right now. Currently the data-structure nearly requires an old-school-style "check-out"/"check-in" system, else expect conflicts & re-doing "work within editor UI", which is painful/slow/tedious and prone to errors. ​
     
    ocnenued and phobos2077 like this.
  7. FlightOfOne

    FlightOfOne

    Joined:
    Aug 1, 2014
    Posts:
    668
    Thank you!
     
    phobos2077 likes this.