koobas.hobune.stream
Cost of loading manually modified instances at runtime, on mobiles?
As a general rule for mobile development, is there any significant in-app drawcall or CPU negative consequence in using manually modified multiple instances of a unique prefab instead of saving all these instances in their vanilla form (that is, pure copies of the prefab)?
For example, when building a place for a game, like a town, if I place 50 instances of the same prefab in my scene, will they significantly require less computation if I don't change any of their parameters (the overriding thing that shows some fields in bold)? Said manually and specific modified paramters could be anything like some having a smaller collider, some pointing to a different texture, some made heavier, etc., so in the end they all have something unique.
What is the kind of penalty to expect there and what are the extreme cases to avoid?
PS: with AlwaysSunny's answer, I realize this question lacks one detail. The obvious consequence of not modifying instances of one unique prefab is that it forces developers and scene builders to use different prefabs, one for each different case. The project logically and rapidly grows in size then. However, if storage size isn't a problem, it's still important to consider the effect of loading variants of a unique prefab vs loading several prefabs, each covering every single different case.
Your "placed and modified instances" approach is superior to the "prefab for every flavor" alternative for a litany of reasons.
Chief among these are your convenience, and the memory footprint of the game on both disk and ram.
Any performance differentials in other areas are going to be negligible, provided the million-and-one other relevant considerations are addressed with a similar degree of attention to optimization.
Draw calls will be unaffected, except in those situations which prevent batching for normal reasons. CPU and other loads will be largely unaffected.
Unless somehow the every-flavor strategy is beneficial for your convenience, stick with what you've got.
Yes, more prefabs would certainly eat more storage room, at the very least. Here's the story as to why this became an issue. During development, there's been a disagreement on the way to proceed with prefabs and instances. Unity doesn't provide much official documentation about this side of the prefab-instance relation in particular; unless I missed something of course. At this point, we were more or less guessing.
Some people might think that the bolded parameter is an indication of a possible risk, a warning perhaps. Others would think it's more like a helper, a clarification and something actually planned by Unity's developers as a way to go.
One may think that in the app, it might take perhaps more time to use/load/pool modified instances because everytime it will produce an instance, it will then go read the data from the saved scene and from there, will basically do the equivalent of saying "Ok, so you, instance #1, everything is the same as your prefab safe for A and E, for instance #2 lemme see, ok this time it's C and F that have been tweaked, etc." That, ins$$anonymous$$d of "dumbly" copying the prefab, which one might think is quicker.
But, technically, I'm not even sure this would cost more in calculation because vanilla or not, the app has to read the instance's data and then set each of the instance's parameters either based on the original model (that is, everything being kept from the prefab), or based on the $$anonymous$$ute modifications brought, say, by the level designer. In other words, simply reproducing the prefab spec for spec isn't a gratuitous process either and in both cases it's the same value-reading process that is used, the only difference being that sometimes, the values are picked from those of the prefab and sometimes, from the whatever thing Unity uses to indicate some tweaks were previously made and saved into an instance.
Luckily, I picked the right choice. :)
The boldface fields are re$$anonymous$$ders that there's an edit. $$anonymous$$ore helper than warning.
I'm not sure I've seen this particular question asked before - which makes it a good question - but it also puts us (me) in the realm of guesswork. I felt justified speaking authoritatively that the superior solution is the one that offers the nicest development experience.
A Unity shaman may know precisely how Unity saves and loads scene data and thus exactly how much "oomph" it takes one way versus the other. Frankly though, this is a case where convenience ought to be king. There is definitely such a thing as over-optimization, and your proposed alternative seems to fall on the wrong side of that line. Even a whole two seconds of extra load time is a better sacrifice than umpteen extra hours of development time juggling among unique-snowflake prefabs. (And I'm fairly confident that load time and memory footprint are the only factors worth considering here.)
Just thought it was worth mentioning that it's quite possible I'm wrong, but for very sensible reasons.
To me, it's clearly far more practical to build a prefab by making it totally modular, by implementing all the possible varieties other developers and designers would want to bring to a scene, and then letting them fiddle with the instances.
Surely, Unity must add a file of some sort to each scene's data in order to indicate how to build the required number of instances.
When saving a scene, it tells Unity how many instances there have to be and what they'll be. Heck, this file might even be the equivalent of a simple datasheet for all we know. The only way I could see manual modifications on instances taking a bit more time, that is, having an extra cost, is when instances are built.
First of all, when the instance is about to be built, the engine must read the necessary file which would tell it which prefab to scan (including its parameters), store that data in memory of course, then read the rest that would inform the engine if an instance is pure or modified.
If it's pure, it might tell the engine "ok you scanned the prefab, no need to pay attention to the extra lines that tell you which paramters have been modified, just copy the prefab and that will do".
But when it reads the value "modified", it tells the engine "sorry but for this one you'll have to use x, y and z values for parameters a, b and c ins$$anonymous$$d of the default ones." So it would sort of force the engine to keep an eye on both the stored prefab (that is being cloned) and the extra file of "special" modifications (whether there's one per instance or just one big file that summarizes all $$anonymous$$ute modifications). But that's about it imho.
In the end, once the instances are created, if you don't plan on destroying them (because, smartly, you'd be using a pooling system that only deactivates the unused ones), there should be zero extra cost at all at runtime. As far as I can see, having the less prefabs possible guarantees more clarity in the Project, makes the whole thing lighter too, makes life easier for the developers and artists and forces discipline, planification and communication in order to have all prefabs optimized.
