The spriteatlas in 2017 is good for the artist pipeline. But it met some problem in daily usage.
When I create a spriteatlas, and specify the folders it need to pack. But the spriteatlas not just store the folder, but also the GUID of each sprite in the folder.
So when I commit this spriteatlas onto the version control system, and the other two people add different image to this folder, the spriteatlas will different in the two person’s computer. When they commit they work without touch any about the spriteatlas, the spriteatlas will make conflict.
It really make the work pipeline hard, and we consider to drawback to the sprite tag solution.
Is there any way to resolve this?
Is the conflict like this?
- Hash: 9c993de5b783baff11adfa162e2984ab
- Hash: ddcb887be55d6403f1baafd598828e22
- hashString: 9c993de5b783baff11adfa162e2984ab
- hashString: ddcb887be55d6403f1baafd598828e22
======
The “Hash” is calculated when the spriteatlas is packed.
If each of you work on same target platform and same OS( Editor is running) , there is no problem.
However working on different target platform or different OS( Editor is running) , different “Hash” will be generated.
Is there any way to resolve this?
The simple way is changing the Sprite Packer Mode to None.spriteatlas won’t be packed , and won’t conflict…
( *plaese turn on when you build packages or assetbundles)
Yes I met this conflect. So I can not Always Enabled in Sprite Packer Mode, but using Only Enabled For Building.
But this result I can not see the correct draw call for my game, as the ugui will not combine drawcall anymore. The the performance for render and ugui rebuild is not correct in editor mode.
Is there any plan to make the hash OS agnostic?
Our team works on both Mac and PC and our version control is reporting the hash changes even though logically nothing has changed. This means we have to diff check every .spriteatlas to determine if it is a true change or an overzealous hash change (no logical change).
How is it possible that this system got released in such a state? Why would it even be built like that to start with? EVERYONE works with a VCS, this pretty much makes your system completely incompatible. The “legacy” system has worked perfectly fine and pretty much everything else unity does is stored in the library folder, why is this different?
In my opinion, this should be #1 priority to fix over anything else that has to do with this system, because it breaks workflow! If it’s not fixable quickly, I would suggest moving this feature back to EXPERIMENTAL and remove “legacy” from the old system.
Yeah, this is a major pain for cross-platform work and leads to a lot of dancing around git. A more transparent solution would be very much appreciated.
I just stumbled upon this issue after converting to Unity 2017.1.2. This triggers constant problems with version control conflicts and makes it painful to use even for a solo dev on multiple platforms. Is there any plan to fix this soon?
Overall, I’m astonished how unusable the whole Sprite Atlas is. This was a big reason for my switch to 2017.1, but right now it’s been nothing but a let down.
-
variants are broken, at least on mobile devices, because they insist on simply scaling the main texture down, as is, without considering the NPOT issues, so this is one of the errors in result: Unity Issue Tracker - Compressed ETC Variant Sprite Atlases become corrupted when changing their scale with target platform set to Android
-
asset bundles with variants seems to be not working properly either: New Sprite Atlas and Asset Bundles -- Not playing nicely together? and also Correct way to use Sprite Atlases?
-
and now this problem with hashes annoying the hell out of git
I’m keeping fingers crossed for this feature to eventually become usable. It sounds quite good, on paper.
I think this is fixed in 2017.1.2p3, 2017.2.0p4, 2017.3.0b11, 2018.1.0a5
We are in Unity 2017.3.1f1 and still experience this problem!
Hi, @JakeTurner , I think this problem happen again when we use the Unity2018.2, but we mix use the different beta version, such as I am using the Unity2018.2b11, and the other guys use the Unity2018.2b7.
The spriteatlas file always change when we cooperation~
It seemed to be a Unity bug and I fixed it arbitrarily. Please bring this code if you need it.
Assets / Editor
3961546–339673–AssetProcessor.cs (2.13 KB)
Sorry for long delay. The forum notifications didn’t work for me for some reason.
Is this still a problem for you on 2018.2 release versions
I can confirm this issue still exists in 2018.2.18f1
Thank you. Please can you report it as a bug so we can track it and reproduce it.
It’s actually still a problem in 2019.2.8f1, too. I don’t think this was ever fixed.
1 Like
@JakeTurner Still occurs in 2018.4 and 2019.2.8. Is there an issue reported about this?
Still occurs in 2019.3.0b8.
Also occurs in 2018.4.11f1 (LTS)
This happens whenever the platform changes or when building, which means “all the time”. It’s annoying and for us it started happening in our project after upgrading to Unity 2019 (2019.2.11f1 currently). We had never seen this problem on 2017 (we skipped 2018).
@JakeTurner , is the team aware of this? Might have been a regression, or maybe it is a different but similar problem.
We are also struggeling a bit with the new spriteatlas system. My question ist on whats the best practice to deal with the atlas in git.
- So whenever i make a “build” the files get dirty, since they get repacked and re-hashed… But thats NOT something another developer needs, so i´d like to ignore the actual files in git.
- But the settings are also stored in the same files, and that IS an Information i´d like to share and check in