Feedback Sprite Packer slow and mode setting should be user pref instead of ProjectSetting

We've started using the Sprite Atlas but noticed that it's a lot of work getting the packing times down to a minimum. Currently using a high quality setting took 40 minutes or more, so we switched to low quality and packing times went down to 5 minutes. Still a lot, because our project is not too big yet.

I know it can be difficult to optimize this process, so my first complaint is actually, that the Sprite Packer Mode (Always Enabled vs Enabled for Builds) is part of the ProjectSettings. This should be part of the local user settings or hook into some system of overrides, where project defaults can be set but overridden by the local machine.

All of my projects are developed in teams in a version control context and each user has a different look on the project. As a programmer, I don't need to wait for sprites to be packed in edit mode, but our vfx designer or graphics programmers do want to see packed sprites, etc. When I switch roles and become a build engineer, I need to test packed sprites vs no atlas in builds and don't want to revert the project settings every time.

I think this is true for a lot of settings that are currently part of the ProjectSettings asset and Unity should re-evaluate if these make sense when used by teams and version control.

Thank you!

 

We had our Sprite Atlas set to 8k because one of the sprites was bigger than 4k and compression quality high. The Atlas was configured to include a single folder with all the sprites in it. When someone on the team added a new sprite to the folder, the entire packing process ran again (before play mode or during build). We are using a local cache server setting on each machine. We work with Version Control and frequently switch branches or jump to newer updates. I can't say for certain, but our impression was that basically every time somebody updated the repo or switched a branch, the Sprite Packing needed to be run again, but it could also be the case that every time some sprite asset changed on disk because of the switch and therefore the atlas needed to be rebuild.

All in all this took a lot of time, so we reduced the quality setting to low quality compression and also made the one big sprite smaller and set the atlas max size to 4k. Now the rebuilds still happen many times each day (at least whenever a sprite is changed on disk), but the rebuild "only" takes a couple of minutes.

I'll try to keep an eye out for other sources of the rebuild. Some of my team members said, that the atlas was rebuilding although nobody changed anything related to sprites, but I haven't confirmed this yet.

 

Yes, totally! Thank you for the tip. I was aware that the atlas has multiple pages and no ideal layout, but I didn’t think of how this would impact build time. At the current stage of our project, we had 4000 draw calls, but its not time for optimization yet, so I thought I could simply use one big atlas as a first measure, but now that I think of it, that’s a really bad idea indeed. If we split it up, only certain atlases will need to be rebuild and probably theres some overhead in packing many sprites at once. I’ll split it up later today and report back!

 

I've found some time to reorganize our sprite atlas assets and took some rough time measurements.

• The original worst case scenario was one big atlas with multiple textures, 8k size and high quality: 40 minutes.
• We then reduced the size to 4k and set quality to low: 5 minutes.
• I then manually split a few very large sprites into multiple smaller ones: 3 minutes.
• Finally I split the atlas into 13 individual assets with 4k size and low quality settings: 1:20 minutes.

So far, packing times have gone considerably down after splitting the big atlas into multiple ones.

I'd still like to have this setting, whether to always perform sprite packing or only before a build, be a user preference that overrides the project default setting or something similar. Our animator needs to have packing enabled in play mode to have somewhat fluent playback (although the whole editor performance thing is another topic), while our programmers don't want to wait for packing. Even if it's only one or two minutes, it can become annoying because it often needs to repack after switching branches.