Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

ScriptableObjects "save memory" How?

Discussion in 'Scripting' started by april_4_short, Aug 15, 2021.

Thread Status:
Not open for further replies.
  1. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    In many talks and presentations, the claim is made that ScriptableObjects save memory over having things saved in prefabs.

    Yet, so far as I can tell, for a prefab instance to then ingest and locally use the values or properties of a prefab, it must have variables/properties it can set to the values stored in the ScriptableObject.

    To my (limited) thinking, this would mean there is no memory saved.

    What am I missing or misunderstanding about the claim that ScriptableObjects save memory?
     
  2. GroZZleR

    GroZZleR

    Joined:
    Feb 1, 2015
    Posts:
    3,201
    Basically if every monster prefab has ten variables (BaseHealth, BaseMana, BaseStrength, BaseIntelligence, etc.) versus every monster prefab having one variable referencing the ScriptableObject that has those ten pieces of information.
     
    Bunny83 and april_4_short like this.
  3. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    So the SO acts as a struct, stored in the memory of each instance?

    With a member for each value?

    And that's more efficient?
     
  4. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    btw, sorry if I'm asking stupid questions.

    I use SO's quite heavily for something that others might use Animator States for, and that's always made a lot sense, to me.

    But using SO's as a kind of reference house for Prefabs, rather than just serializing variables in Prefabs, has always been claimed to be more efficient in terms of memory, but I've never quite understood how or why that might be the case.
     
  5. GroZZleR

    GroZZleR

    Joined:
    Feb 1, 2015
    Posts:
    3,201
    No, they're not structs. Structs are value types. ScriptableObjects are classes, and thus reference types. What's the difference?

    Perhaps this chart will help illustrate the difference of each monster keeping a copy of the data versus referencing one shared set of data:
    data.png

    Then just extrapolate it to an extreme:
    1000 monsters each with their own copy of 100 pieces of data = 100,000 pieces of data stored in memory (1000 x 100) versus 1000 monsters each with 1 reference to 100 pieces of data = 1100 pieces of data stored in memory (1000 x 1 + 100).
     
  6. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    Ok, but each Monster instance needs to store its strength, it's health, it's endurance, etc, locally, so it's made a new storage variable/property for each of these values.

    So I don't see any memory saving.

    Am I still missing something?
     
  7. GroZZleR

    GroZZleR

    Joined:
    Feb 1, 2015
    Posts:
    3,201
    I don't see why it would need to store local copies of immutable data like strength or endurance, only mutable data like current health, which isn't the same as maximum health anyways. Even still, there's lots of other data (movement speed, attack radius, detection radius, team banner, team faction, AI aggressiveness, AI tick rate) that could all be relevant data outside of things you'd consider "gameplay" values.
     
    Bunny83 and PraetorBlue like this.
  8. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    Let's imagine a game where Strength and Endurance have current, local values inside each monster, along with nutrition level, health level, etc.

    Why isn't it better to just have these public, and set in the prefab, to their initial values, than having an SO set these initial values?
     
  9. Laperen

    Laperen

    Joined:
    Feb 1, 2016
    Posts:
    1,065
    I think the bigger misconception here is comparing ScriptableObjects to prefabs on the narrow job of keeping values alone, rather than what each thing actually is. If you have the time, give this video a watch. If you've already seen it and still make the case prefabs are just as good as ScriptableObjects, consider that your project is simple enough to not involve ScriptableObjects.
     
    PraetorBlue likes this.
  10. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    Have watched that video.

    Please, in simplest, most communicable and easiest understood possible terms, how would Scriptable Objects be best used to save memory over using Prefabs?

    Rather than casting aspersions about what my project is, please try to help me understand what can be done best with ScriptableObjects, and why.
     
  11. adehm

    adehm

    Joined:
    May 3, 2017
    Posts:
    369
    Never used them but from reading here I would say it would be the same as having static data holding base values. For instance I use a static class to hold values that a bunch of things grab from. A SO wont save memory in this case but is the same concept I believe.
    Code (CSharp):
    1. public static int NumberOfLegs(Types type)
    2. {
    3.     switch(type)
    4.     {
    5.         case Types.Humanoid:
    6.         return 2;
    7.         case Types.Dog:
    8.         return 4;
    9.         default:
    10.         return 0;
    11.     }
     
    april_4_short likes this.
  12. Adrian

    Adrian

    Joined:
    Apr 5, 2008
    Posts:
    1,061
    I think @GroZZleR's graphic explained it quite well. Instead of duplicating the same data on each instance, you save it only once in a scriptable object.

    But I don't think that will be very significant in most cases, game data usually won't make up most of your game, textures and audio will use much more space.

    There's also an additional but now a bit outdated consideration: Scene file size. Unity used to keep the full prefab instance in the scene file, so using lots of prefabs would actually not reduce your scene size at all. Now Unity only saves the prefab modifications in the scene file but just the standard overrides can take quite a bit of space per instance (about 2.5k bytes at least). Putting and sharing more data in scriptable objects will move the data out of your scenes and can reduce their size.
     
    PraetorBlue likes this.
  13. adehm

    adehm

    Joined:
    May 3, 2017
    Posts:
    369
    Ah, yes; in this instance it would save memory over having a static class because it could be separated by scenes and may not need to be in memory. But will it be able to pull data during a declare as I often enjoy?
     
  14. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    Absolutely agreed. If there's ANY saving, it's tiny base types.

    But just using the approach of @adehm or Managers seems to match or better ScriptableObjects in terms of memory benefits.
     
  15. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    Perhaps.

    A long time ago, I switched to using Prefab Proxies (term of my own making, some might call them imposters or placeholders) in Scenes, to be the Editor visual representations of the positions of Prefabs. At game start (or entering Play Mode) a Manager class goes through and replaces all the proxies with the correct Prefabs for that level.

    This approach radically decreases the time it takes to enter Play Mode, as there's no need for Unity to copy across all the Prefabs, instead it runs as a game might, with freshly instantiated Prefabs in the level locations pertinent.

    The only times I use the full blown Prefabs in the Levels inside the Editor is for aesthetic consideration needs.
     
  16. Laperen

    Laperen

    Joined:
    Feb 1, 2016
    Posts:
    1,065
    Hopefully an example will help. Say your game has 3 orcs with minor variations, the only difference between them is their name, texture, and some stats. You could create 3 different prefabs and call it a day, but no, you're a stickler for space.

    Instead you have 1 orc prefab, and create 3 ScriptableObject instances holding the name, stat variation, and material. In your orc spawner, when you instantiate the orc prefab, you assign it the relevant ScriptableObject instance and call a custom initialize function.

    On the surface, from a script perspective this looks like more work. In the prefab version, you assign your spawner 3 prefabs and spawn the relevant one. In the ScriptableObject version you need to assign 1 prefab, 3 ScriptableObjects instances, and still have to make special provisions when spawning an orc.

    In data however, 3 prefabs hold 3 gameobjects, 3 transforms, 3 monobehaviors, 3 MeshRenderers, basically 3 of everything to make an orc whole. The ScriptableObject version holds 1/3 the data by having 1 prefab, and keeps relevant data in 3 ScriptableObject instances.

    This is why people say ScriptableObjects are more efficient with holding data. Prefabs potentially hold data you do not really need to be keeping.

    I find the choice of using ScriptableObjects in its most basic form, boiling down to 3 questions:
    • Do you need to only hold a bunch of data with nothing else?
    • Do you need this data to be referenced throughout the game?
    • Will this data need to be referenced quickly and regularly?
    If no to some, maybe a prefab will suffice.
    If yes to all, ScriptableObject is an option.
    The sad part however, is answering these questions isn't as obvious as it seems. Again using the 3 orcs example, 3 prefabs would have been a perfectly reasonable assumption due to its simplicity in implementation. The simplicity of the implementation however, came at an unforeseen cost of duplicate components being stored.

    And this is just one example of a space benefit for using ScriptableObjects. You will need to study further on what ScriptableObjects can do, in order to fully appreciate why it is in Unity at all. It can help with pipeline and design with enough creative use.
     
    Last edited: Aug 15, 2021
    april_4_short likes this.
  17. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    Now more confused than ever. Sorry.

    In the above scenario, why not use Prefab Variants?

    But let's put that aside for a moment, because there's a bigger issue, I think, and the main reason I can't see how this saves any memory.

    Please, let's focus on the Texture, since it's the largest item in memory.

    Regardless of methodology (SO or Prefabs), that Texture has to be stored on/in SSD/HDD storage of the target build device, within the game's "app package".

    Prefab Materials reference this texture, so it's not copied around storage memory even if it's used in multiple different Prefabs and their materials, and can be referenced as many times as needed without increasing memory usage?

    It must be loaded into GPU memory to be shown on the screen by the material's shader, regardless where it comes from (SO or Prefab material reference)?

    So, to my naive eyes, I don't see how there is any saving of memory for the Textures, when using SO or Prefabs.

    Am I still missing something, or making very wrong assumptions?
     
  18. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    btw, there is a chance that I'm giving Prefab's far more credit for their ability to reference (rather than copy and hold) materials and textures than they actually have.
     
  19. Laperen

    Laperen

    Joined:
    Feb 1, 2016
    Posts:
    1,065
    In my example, there isn't any memory being saved in terms of the materials and textures, since you will need at least 3 materials and 3 textures to visually reflect the orc variations.
    I have absolutely no idea how to explain simpler than this. If you still cannot understand what I am saying after spelling it out this blatantly, I can't help you.
     
  20. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    This claim is what made me focus on the Texture, as I couldn't see how this can be true for the single most memory intense part of the Orcs, which threw into doubt all your other claims.
     
  21. GroZZleR

    GroZZleR

    Joined:
    Feb 1, 2015
    Posts:
    3,201
    Well what do you think is more memory efficient: Every material having a reference to that one single texture, or every material having its own unique copy of that texture? The first is the allegory for referencing a ScriptableObject and the latter would be the Prefab.
     
  22. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    So the savings are in things like default types and common components, and that's about it?

    If so, don't Prefab Variants provide this same benefit, with the addition of adding additional GameObjects and Components, too?
     
  23. GroZZleR

    GroZZleR

    Joined:
    Feb 1, 2015
    Posts:
    3,201
    I honestly don't know why you keep bringing other things into it. The savings are in the memory allocated per instance of each active object.

    If you have 1,000 Monsters with 1,000 integers: you create 1,000,000 integers or 4 million bytes.

    If you have 1 ScriptableObject with 1,000 integers and have 1,000 Monsters that reference that 1 ScriptableObject: you create 1,000 integers and 1,000 references which is 8,000 bytes.
     
  24. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    Exactly, default types. Which are small, generally speaking.

    I get that. But those savings are going to be trivial, in most instances (excuse the pun) because most normal game prefabs are going to have very few values, and need local storage for most of them, that can also serve as default storage and setters during editing, and reference a game manager for any defaults needed after they've changed during gameplay.
     
    ant-papa likes this.
  25. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    Nothing new brought into it. Prefabs Variants are part of the prefab workflow. And they have, as I mention, additional benefits, which are (quite frankly) immense.

    If Prefab Variants each use their own storage memory for what's common to them in their parent prefab, as opposed to only Overrides and Additional GO and Components using unique storage, then I can see one example of a possible benefit (involving much more work and loss of creative freedoms) to Scriptable Objects, in terms of storage space but this won't reduce RAM needed for instances.
     
  26. GroZZleR

    GroZZleR

    Joined:
    Feb 1, 2015
    Posts:
    3,201
    If you understand, and have understood from the beginning, what's really the point of this thread? If you don't want to use them, don't. No one's forcing you to use one architectural strategy over another. The strategy of sharing common data has a demonstratable effect on memory consumption, and those savings could be significant or even essential depending on the hardware you're targeting or the scope of a project.

    Prefab variants have no bearing on the discussion because they're only relevant to the editor and are regular GameObjects with buckets of data at runtime.
     
  27. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    I don't understand your hostility. These are sincere questions.

    When many make claims about memory usage being less, I presumed (perhaps wrongly) that this must be significant and obvious memory savings. It seems, from what's been put forth so far, that's not the case.

    If you can't see the workflow similarities between a Prefab Variant's relationship with the Prefab it derives from and a Prefab's potential relationship with, and reliance upon, a ScriptableObject, as per this question of memory savings, perhaps you haven't used Prefab Variants.
     
  28. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    It's smaller regardless of if your use of them is trivial.

    It isn't to say that prefabs should be avoided.

    It's to say use the tool that best fits what you are needing to do.

    A ScriptableObject can serve many purposes. One of them is to share immutable data across multiple instances to reduce the memory footprint of that data.

    Give you an example where the savings is very high.

    Say you have some prefabs that need to know what inventory items exist (maybe it's mobs for a region that on death drop an item by some odds). You could just have an array on the "ItemDrop" script that you fill with the items. Meaning every mob has a copy of this array. And if this array is large... and you have a large number of mobs. This can end up taking up a lot of memory (similar to the texture example from before).

    But if it was in a scriptableobject that each mob referenced. Then it's just one single array that is referenced by every mob.

    Reduced memory.

    You can believe that trivial... but it's still reduced.

    And if you multiply this by the multiple times you do this, this can be significant... depending what you define as significant. In the end graphical data is going to be far more memory intensive than this sort of data just because of the nature of things. So at the end of the day it may only end up being a 1% savings if your game is graphically bloated. But for some people that 1% may actually be significant if it is what stands between them and release.

    Now it comes with implications though... it means every mob has the same exact pool of inventory items that it can drop. If you want distinct item drops per mob you'd have to create the distinct pools of items for each category of drop. Thus reducing the benefits of the memory. BUT that only applies if your game is a game where each mob has a distinctly unique set of items that it drops from.

    On the flip side. Say your game is a completely different design where a region has a static number of items that can be dropped regardless of which mob it is. As a mob drops some item, it is no longer available to be dropped by another mob. This is something the shared scriptableobject could benefit since it COULD be used to store that mutable value (what items were consumed).

    It all comes down to what YOU need for YOUR game and understanding the implications of the design choices you made.

    Cause mind you < memory isn't necessary important if it doesn't help you make the game you want to make. BUT if it is critical to your game that you reduce some memory footprint because the benefits of distinct lists per prefab is not beneficial to the game, but the lower memory overhead is because say you're targeting mobile or something... then it is.

    It's up to your needs.

    (and mind you this is only one feature of scriptableobjects. And technically speaking a prefab could be used in a similar manner. Where your prefab for you mob references a shared prefab of the inventory items. Back in olden times when SOs didn't exist. We just used prefabs like this. But it came with weird caveats and annoyances arising from the ambiguity of prefabs from actual instances of those prefabs).
     
  29. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    In the end though if this is not adequate to your concept of significance.

    Well... we didn't claim that SO's saved all that much memory. We're just demonstrating HOW it can save memory.

    The unnamed "presentations" and "talks" are who you may want to take your semantical gripes about the significance of memory savings. Maybe they exaggerated it, maybe you misinterpreted it, there's no way for us to actually know since it's an unnamed source you didn't offer up.
     
  30. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    It's to the point where it's EVERYONE that mentions ScriptableObjects, as though it's a mantra that must be ushered when talking about ScriptableObjects.

    All Hail The Memory Savings of ScriptableObjects.

    To the rest of your writings.

    Thank you!

    Will digest and attempt to wrap head around.

    More stupid questions will likely follow. Pre-emptive apologies.
     
  31. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    THANK YOU!

    I had wrongly envisaged that the savings must be more significant, and that I simply didn't see or understand where or how that significant saving was occurring, considering the desire to mention this aspect of using ScriptableObjects by everyone promoting their usage.

    You're right, there's many other reasons to use them, only some of which I grok. I am at an inflection point, trying to figure out how much I should balance use of SO's against Prefabs, for a final push to publishable quality of code and gameplay, in a quite modular game. One last refactoring...
     
  32. Laperen

    Laperen

    Joined:
    Feb 1, 2016
    Posts:
    1,065
    You are the one who asked for what benefits ScriptableObjects bring, what replies were you expecting if not attempts at that? In my case, I don't even use ScriptableObjects much now, if at all, but draw on what I've read and experienced to answer.

    If you really want a visual comparison, create a monobehavior with some random variables, put it in a GameObject, and make it a prefab.
    Create an instance of a ScriptableObject with the same variables as you have put in the monobehavior, and create an instance.
    Go to your window explorer, and compare the filesize of the prefab and ScriptableObject instance.
     
  33. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    Considering I've been using Unity for a decade or so now.

    I have never heard anyone significantly praise SOs for their memory savings features. I may have heard it passingly mentioned that it could potentially be used for such.

    But that is not the primary praise I see foisted upon SOs. The primary praise is the modularity of design it allows you to exercise on an asset level. Basically... as data containers (similar to how other assets like materials, animations, or pretty much all of this stuff:
    upload_2021-8-15_12-38-21.png

    Before SOs, these were hard coded things from Unity.

    Now I can create similar things like so:
    upload_2021-8-15_12-40-4.png
    upload_2021-8-15_12-44-46.png

    Here's one I especially like. Being able to modularize my build/input settings:
    upload_2021-8-15_12-48-7.png

    That modularity in my opinion is the benefit of ScriptableObjects, and is the primary feature that I hear rung most often around the community since their release.

    ...

    What I also do know is that the community has a butt ton of confusion around it as well.

    And this confusion may even come in the form of talks/presentations that may either go over the heads of viewers. Or be put on by people who don't know what they're talking about. I can not speak to these specifically... for the same reason I can't speak to the talks/presentations you mentioned already because you did not offer up any direct examples.
     
    Last edited: Aug 15, 2021
    _geo__, Munchy2007 and Kurt-Dekker like this.
  34. Laperen

    Laperen

    Joined:
    Feb 1, 2016
    Posts:
    1,065
    Why I and others have remained hyper focused on space savings is because of OP's opening:
    and inability to stray from it:
    Even after being told that there is more to ScriptableObjects than that one thing:
     
  35. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    And the point of my post that you're quoting is to say...

    what talks/presentations?

    This topic of memory savings is a topic I rarely see. This thread being probably the only time I've actively engaged with the topic (noting not from a lack of engagement with Unity... noting my heavily engaged history with Unity).

    I understand you and april may be "hyper focused" on this topic because of april's OP. But that's circular in nature. Of course this thread is about that topic, it's what the thread was started for.

    I am claiming I don't believe the original statement nor this one:
    (the statement I had quoted/responded to with that specific post you're quoted)

    Who is this "EVERYONE"?

    I don't see them.

    The only people I see is OP. And they're only saying they don't believe the claims they heard these hypothetical others say.

    OK...

    Stop listening to these unknown actors then.

    ...

    Basically. Why stay laser focused on a topic that OP clearly isn't satisfied with the answer of. When their entire foundation for the topic is based on hearsay.
     
    Last edited: Aug 15, 2021
  36. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    Try to understand that the materials you look at, as a seemingly god-like master of Scriptable Objects, and that which I come across as someone barely using them and wanting to learn more about them, are two entirely different groups of reading material.

    I don't understand the use case you've presented that you're all chuffed about, at all. That's how far apart we are.

    So it would be bloody nice if you'd just take my word for it when I say I'm seeing almost ubiquitous claims of memory reduction in all I read and watch about why to use ScriptableObjects.

    These things seem so simple and powerful that it boggles the mind how nobody has managed to trouble themselves to teach them in a manner suitable for those considering architecture of their games without examples. But that's like a lot of programming, those with the knowledge forget what it's like to not have the knowledge, insights and wisdom and instead distrust the stated experiences of others, and simply present their own experiences as though that's normal and to be expected of everyone.

    It's one thing to distrust the claims of a person (water is wet) it's entirely another to doubt the experiences of others (many have told me that water is wet).

    And I get that you want mono/solo examples of something so you can repurpose their words and make it somehow my fault for misinterpreting what they're saying "well... he's saying this, and you should therefore think this..." but here's the thing... every source I've read, every presentation I've seen attempting to justify using ScriptableObjects as the new god of Unity architectural considerations, they all say, at some point... memory reduction.

    After a while, it got distracting, even though this wasn't a factor in my considerations of whether or not to use ScriptableObjects (or how or why or when to use them, which are still things uncertain), AND I couldn't see how it could be such a significant factor that EVERYONE I was seeing mentioned it as though it was a significant bullet point in the reasons to use it.

    Hence the original question.
     
  37. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    This isn't a "god-like" thing.

    This is a, you didn't supply what you're referencing.

    Think of it like this. When someone comes onto the forums and is having trouble with a tutorial and they say "I was following this tutorial and they said do X,Y,Z, but I don't get why."

    Our most often response is "What tutorial????"

    Because yes... you may come across material I don't. But that's my point... We don't know what material you're talking about. We don't know the quality. We don't know what they're saying in it. We don't know if you misinterpreted/misrepresented what they said.

    To say... "I heard a thing", with out saying who, is called... hearsay.
     
    Last edited: Aug 15, 2021
  38. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    I didn't say "I heard a thing", I said "I heard a thing A LOT".

    There's a difference.

    EDIT: ADD EVIDENCE FOR WHATEVER REASON::

    NB: This is not how I searched for info about Scriptable Objects, it's to prove to you that there might actually be a lot of talk about the memory reduction when using scriptable objects.

    Of all the things to argue about, the experience of having read and heard this claim, many, many times, is probably the most asinine. Why bother with that? Why not just stick to "Here's how much memory they can save... it's not a lot... it is a lot... details... "?
     
    Last edited: Aug 15, 2021
  39. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    Also...
    Memory savings being a bullet point is different from:
    Bullet points of reasons does not mean that each reason has equal praise. And it most certainly doesn't mean "all hail". Which is why I feel you may be misrepresenting the unsourced talks/presentations.

    But who knows... maybe there are a couple people who blow the "memory savings" thing out of proportion.

    I just doubt it.

    It sounds like one of those things where people are saying:

    "Scriptable Objects have many benefits including: a, b, c, d, e, f, g, h"

    And one of them happens to be memory. Which it CAN assist in saving. It's just not as significant as you assumed for whatever reason you assumed it since I don't know what you saw/read/heard.

    ...

    It's still "I heard..."

    I hear a lot of people say vaccines cause autism. Doesn't mean it's true!
     
  40. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    In this metaphor, I came to a Doctor's convention to ask if these lots of people had a point, and to what extent.

    Why oh why are we going down this path?
     
  41. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    And in this metaphor we explained how those savings could be made.

    And you were unhappy with it because you couldn't see how that was all that significant despite multiple explanations.

    I don't know why we're going down this path... So there's nothing really else to say aside from tootles.
     
  42. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    unhappy?

    That's relief, that I don't have to think about how to save memory by using these things, and can focus on their architectural benefits (or otherwise).

    As are a couple of other things expressed above, like this:

    If the above strikes you as someone unhappy that they've discovered there's no significant memory savings (for me) then you're reading into it something that's not there. and wrong.

    I've found a possible reason for everyone I've read and watched mentioning the memory savings:

    https://docs.unity3d.com/Manual/class-ScriptableObject.html
     
  43. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    The unhappiness is referring to you keep re-asking for an explanation of savings.

    If someone answers a question, and you ask it again... it's not uncommon for the linguistic word choice to describe that situation is that you were unhappy with the first, and subsequent, answers that led you to reask the question.

    If I served you a burger, and you didn't eat it, and instead asked someone else to give you a burger. I might say "why are you unhappy with my burger?"

    ...

    Yep.

    And it's not some significance. It's not some "all hail memory savings". It's just a matter of fact statement that:
    It both says that it could, and how it could, which is pretty much a short-hand version of what everyone has repeated here. You can avoid duplicating data.
     
  44. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    Nope.

    Here's the sentence:

    "And you were unhappy with it because you couldn't see how that was all that significant despite multiple explanations."

    You're claiming I'm unhappy with ScriptableObjects, specifically its memory savings, in the singular (it), and then go onto clarify this by the use of the clause that starts with that, and ends with you proving that "it" does not refer to the explanations.
     
  45. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    Is this a semantics argument now?

    Yes... the concepts of those sentences are similar.

    common theme: multiple explanations

    I can't with you dude... peaces.
     
  46. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    I think it's quite clear you're trying to change the meaning of a very clear sentence, post hoc.

    Not sure why.

    Are you ever wrong?
     
  47. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    Said the pot to the kettle.
     
  48. adehm

    adehm

    Joined:
    May 3, 2017
    Posts:
    369
    I understand your frustrations. SOs are pushed hard for seemingly very little reason. I've seen people use them but then at the same time be redundant to the point that I could not even work on the project without deactivating half of active objects in the editor due to lag. I've had clients make absurd claims about how they need their save systems with them because they thought Unity's playerprefs are broken. But the world had/has the same problem with peoples misconceptions of multithreading.

    For some reason I've had trouble working around SOs as well and it makes me want to learn them but I also don't feel like learning them because I know of so many ways to achieve what I want without them. For instance Unity's new input system. I don't want an interface; I'd rather handle everything through my own scripts so that it is very dynamic with very little effort.
    But I have an issue I believe due to SOs in where things are not being properly reset and I have to restart the editor every so often due to exceeding the input limit by running the project. The asset is still persistent until the entire project is shut down and apparently I just keep adding new bindings that I assume should be reset once the project is stopped.

    At project launch I create my input asset.
    Code (CSharp):
    1. private InputActionAsset inputActionAsset = new InputActionAsset();
    I then set the keys default which will be adjustable by user/playerprefs.
    Code (CSharp):
    1. public void Create(ref InputActionMap keys, ref InputAction key)
    2.   {
    3.      key = keys.AddAction("MouseLeft");
    4.      key.AddBinding("<Mouse>/leftButton");
    5.   }
     
    april_4_short likes this.
  49. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    I've already admitted to being stupid and having stupid questions.

    I'm wrong more times a day than you're right.
     
  50. april_4_short

    april_4_short

    Joined:
    Jul 19, 2021
    Posts:
    489
    I've got two situations where I'm using ScriptableObjects quite extensively, as massive state machines for all sorts of animations and responses to game events, so as to propagate them to all other objects of all types within the game world.

    It works like a gem, and was literally as simple making a range of cookie cutters, and I can explain it in an instant to anyone else that's killing themselves by a million cuts when using Animators, as it completely removes any need for them, and empowers the Animation Legacy components to be smarter, and gives me a "plug'n'play" with drag'n'drop for all levels and stages of the game.

    Outside of that scope, i don't see how other means of doing things aren't better, faster, lighter and easier than SO's. This is part of the reason I thought the memory savings advantages must be somewhat significant, to kind of justify all the hype around ScriptableObjects.

    I'm quite glad I've found out that that's largely mythological and overhype, and so I'm back to finding myself nodding along with much of what you've written.

    As to the New Input System™ --- I think this should be taken out the back and allowed to rot, and that Unity should just man up and buy ReWired if they really want to incorporate an entire input system.

    Ideally, though, they'd just give us a polling thread that we could control the rate of, on a very light thread that does almost nothing other than polling, so we could accomodate all the coming variations of input timing that ever more high performance computing and gaming devices are providing.

    It's not uncommon for gaming phones to have input reporting at 360Hz, some are doing 720Hz. The Apple Pencil and Microsoft Surface pens do very fast polling AND provide predictive insight into where they think the pens going. And then there's tracking on VR/AR, where the faster is the better, and will soon start getting much faster (if those techs are to have any hope).

    This is before we get to the obvious, like Xbox X/S and PS5 being at 120Hz, and all sorts of mice on PCs having crazy rates of update available on new gaming motherboards.

    etc.

    Sorry... went off on a tangent.

    I don't understand why anyone thought ScriptableObjects should have anything to do with the Input System. That's manager class stuff. Perhaps if Unity could find a way to Serialize and/or Surface statics we'd not even need ScriptableObjects ;)
     
Thread Status:
Not open for further replies.