Since updating to Unity 2018.4.10 I noticed all of our sprite atlases keep changing the hashes in the .spriteatlas files. This results in lots of unnecessary noise in source control. Previously we were using 2018.4.8, I’m not sure if the problem started in .9 or .10. The serialization seems to have changed (introduced storedHash), but now the hashes keep changing all the time.
This is the hash I’m talking about:
totalSpriteSurfaceArea: 180224
bindAsDefault: 1 storedHash: serializedVersion: 2 Hash: 7822d7233d93c2eed79db302c7a76c72
Hmm, we were using .8 for quite a long time (skipped over .9 due to lots of known issues) and I don’t think we ever had this. In any case, I’ll try to reproduce on a clean project and report a bug if I can get it to happen.
Of course I didn’t get it to deterministically happen on a new project. The atlas hashes changed once when I switched project and back to the repro, but then I couldn’t get it to happen again. In our own project every atlas keeps changing almost all the time, not sure if it’s triggered by entering play mode or saving anything or what…
My project was on 2018.3.5f1. I switched it to 2018.4.10f1, noticed this bug. Then I found your post and I tried both 2018.4.9f1 and 2018.4.8f1.
I will still stick with 2018.4.8f1 and will hope it has no any other bugs that ruins my project.
I just noticed this issue in Unity 2018.4.10 LTS. I tried to modify stored hash zero in each spriteatlas files, but hashes are changed after building asset bundles. This is very frustrating situation. I am worried about that modified hashes incur unnecessary asset updates.
It’s scary how these issues come back to life again. Hash noise was one of the things that scared us away from Sprite Atlases back at 2017.1, see this thread:
And now, when we finally switched to atlases, the bug is back?
@JakeTurner do you have any insight what’s going on and if these are related?
Hi, could you please report a bug with a simple repro project ? I am unable to reproduce it with a new project in 2018.4.10. I am trying with an older project and will keep this thread posted.
storedHash represents the hash of current spriteAtlas cache available in the Library\AtlasCache folder.
Prior to introduction of storedHash, every time Playmode is entered or player built, SpriteAtlas will be set to Dirty regardless of whether its packed or fetched from this cache. This created issues in Version Control Software as even though there is no change in SpriteAtlas contents, it is checked out( because due to dirty flag the same contents were just being overwritten to the file).
With introduction of storedHash, SpriteAtlas object is only dirtied if the Atlas actually got packed and not fetched from cache.
This is by design. When you move project to a new machine, there wont be ActiveCache folder available. Hence it repacks and set SpriteAtlas to dirty. However for the same set of sprites, with the same settings, if hash keeps changing, please let us know. We will take a look asap with immediate priority.
I have no any issues with VCS/Git till I tried 2018.4.10, but now I have.
I was able to reproduce this bug fo a moment in a fresh project created with 2018.4.10, but now it gone. It is a bit random in its nature.
I have noticed the hash changes, when I switch to another platform and build.
Do you mean that identical stored hash is generated between any platforms if they share same sprite atlas file? (This is my expectation)
Otherwise, once sprite atlas is dirtied because packed atlas isn’t in cache, stored hashes could be different between machines or target platforms even though sprite atlas setting isn’t changed?
I had checked out sprite atlas file on each machines, with no modification. I expected that no more new hashes are generated eventually when I repeat step 1-4, but It didn’t in my test. It shouldn’t make new hash in step 3.
Hiya!
Having just updated to 2019.3.0b6, I can confirm that this issue is now affecting all of my SpriteAtlases, across the project. Each time a dev is commits, they each seem to created new SpriteAtlas hashes, causing all those files to re-commit. I didn’t have this issue in 2019.2 current release, so this seems new to somewhere in the .3 beta.
This is indeed the problem, neither the sprites nor the settings have changed in any way. We do multiplatform development, but in this case the problem happens locally on the same machine (well, on several Windows machines). But it does seem very random, we used to get it constantly last week, but on last Friday it seemed to stop from happening. And then I saw it again on my home PC.
Any news on this? I’m willing to test a custom debug build of 2018 LTS on our project if you want to add some debug editor logging to atlas hashing, to help track this down.
Just wanted to report this as a bug and found this thread.
Count me in for thinking that the hash should not change on platform change. It should hash which files are in, and the need to repack for another platform should be handled by the AssetDatabase itself, not some hash stored in a file on disk (as for all other files).
Exactly. Anything platform related should be kept out of source control. For devs like us, constantly switching between iOS and Android, it’s a mess and with each commit we have to:
carefully filter out the NOISE and make sure not to commit those excessive hash changes
at the same time we have to watch out, because some of the files might have VALID atlas changes we’d want to commit
and when we do accidentally commit those hash changes than there’s the dance with resolving CONFLICTS which everybody loves, especially artists
So yeah, I hope it was never intended as a feature, but just an ugly regression.
@Venkify any idea on when we could expect the fix? I was counting on 2018.4.12 but it looks like it didn’t make it yet.
The atlas hashes changed once when I switched project and back to the repro, but then I couldn’t get it to happen again. In our own project every atlas keeps changing almost all the time, not sure if it’s triggered by entering play mode or saving anything or what…