I recently figured out that there are prefabs of tremendous sizes in our project, somewhat above 1.3MB. In my impression, prefabs are usually of 1KB-ish size.
After looking into the serialized files, it looks like Particle System is the culprit.
I first removed two particle systems from a prefab, and the file size decreased by 225KB.
Then I created a new GameObject in the scene, only added a particle system to it, then made it a prefab. It took up 114 KB in total.
So that means one particle system takes up roughly 112KB.
And, by checking the GameObject.prefab in the second test, it looks like the file is mostly made up of particle system related settings. It expanded from line 5 all the way to line 4700.
I wonder if this gets fixed in later versions? And does it affect runtime efficiency too?
We are looking at ways to reduce this, but haven’t managed to find a robust solution yet.
The problem is we include lots of redundant information for all the particle properties that support different modes (curve, 2 curves, constant, etc)
This is a very annoying issue for us. We did some benchmarks and found that for our project, particle systems affect load times on runtime and overall build times for asset bundles significantly. It took 8 minutes less to build asset bundles ( down from ~ 18 minutes ). I don’t have good data for the load times yet but it noticeably improved for scenes that used to have a lot of particles.
On top of that particles make up 80% of the prefab file size. It contributes 31 megabytes to the overall download size of our android builds.
I manually removed the serialized data for disabled particle system modules in all prefabs and it drastically reduced the file size. Of course the data gets put back once you save the prefab again but it just did it to see what it would do to the file size.
I would suggest to add a feature where you can opt in to not serialize disabled modules. I think in the normal case modules don’t get enabled by code on runtime. That would already give most of the benefits.
To me that seems like an easy change that doesn’t break backwards compatibility.
We do have some work to reduce the amount of redundant data, unfortunately, it has some issues which we have not managed to resolve yet. We are also considering making modules optional as you suggest. Unfortunalty I have nothing concrete I can offer you at the moment, just that we are aware its an issue and want to find a solution.
Even if you had a fix available, chances that it lands in 2018.4/2019.4 LTS are pretty much zero I assume?
I thought Shuriken is considered legacy already and doesn’t receive much attention anymore. I thought all resources go into VFXGraph. That’s not the case?
No, it’s not Legacy!
VFX team does have more resources but we are still working on Shuriken. There are still benefits to each system and no reason to deprecate Shuriken at the moment(CPU vs GPU etc).
You are right about the backporting to 2018.4/2019.4 though. A change like this would be too high risk and be classed as a feature which means that the earliest you would see it now would be 2021.1+.
I just looked at the .prefab file what’s actually stored. Excuse me if I’m going to point out the obvious.
It seems mostly curves cause the bloat. Every module contains at least two curves (minCurve, maxCurve). I imagine many curves might be left at their default values.
Getting rid of the default curves might significantly reduce the bloat. If module stripping is too difficult, perhaps curve serialization is the easier route to go?
I’ve of course no idea how serialization in Unity work, so my assumptions are likely to simple. But from an outsiders perspective, when serializing the file, one could check if it’s a “default min or max curve”. If it’s a default curve, “set it to null” for serialization, so it does not end up in the file. If the deserializer detects “a null curve”, create the corresponding default min/max curve for it.
Yes, thats what we have at the moment. It still has some issues. We prototyped a version that removes modules vs one that removes redundant curve data and the curve one was only marginally bigger but still a big saving. So we will likely go down the curve path as it makes more sense and requires no additional UI, properties or extra user input.
There’s a lot of edge cases that crop up when you only serialize certain parts. For example, the editor and SerializedProperties can not handle it, presets have problems with the concept of optional parameters and prefab patching also struggles(crashes). We also need upgrade paths when reading old serialized data. We have been working through these issues but im sure theres more edge cases that will come and bite us
The good news is that we did manage to solve the issues that were blocking us yesterday. So one step forward
2021.3 LTS here. 5 MB prefabs are fun, which is around 200k lines.
Curves take most of the space. While addressables are capable of compressing into 30% of the value, result compressed value still hits hard.
It’s been like more than 4 years and at least 4 unity versions from the original issue, any news on that? It’s still causing massive redundant data on all or some prefabs with particles.
for anyone interested. i had a 60mb scene and 48mb were particle systems. (around 400 but half are “maybe ill use em”)
with prefab instances you can do the following. define a mother default prefab 112kb.
use this as your base for changing the particlesystems into instances or variants with changes.
got it down to a 24mb scene file with it. for all none prefab particle systems. but works as well inside prefabs. but gotta test performance first. though… 30mb less already.
trick was to duplicate the og particle system. thrn make the particle system connected to tha mother.
revert the particle system so it becomes tha mother(only way you cant copy it or you will copy all the crap data). apply all differences from the copy 1 : 1 via code over the public properties. thank god for ai or i would have never done this.
idk why but unity will seralize everything and you cant even update the minmax fields if mode (constant, curve) is not selected. but the data will be kept inside. so if you have a huge ass particle system with data and you disable it. it will still keep the data. which you 95% dont want to.
ill post the thing as an editor asset at some point
