The new spriteatlas always change make the version control conflict very easyly.

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?

 

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: https://issuetracker.unity3d.com/is...eir-scale-with-target-platform-set-to-android

* asset bundles with variants seems to be not working properly either: https://forum.unity.com/threads/new...t-bundles-not-playing-nicely-together.484366/ and also https://forum.unity.com/threads/correct-way-to-use-sprite-atlases.485416/#post-3172474

* 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.

 

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

 

I can confirm this issue still exists in 2018.2.18f1

 

It's actually still a problem in 2019.2.8f1, too. I don't think this was ever fixed.

 

@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

 

Same issue here, for us started happening right after we move to 2018.4.11f1

 

I´d recommend seperating the setup from the actual files. In this way one could check-in the setup files and ignore the atlases in git

 

is this ever going to be fixed? ^^

 

Unity staff asked in this thread to submit a bug-report, which would allow them to take a look at the issue. If nobody submitted a bug report, it is probably not fixed. Thus, if you are able to reproduce the problem, please submit a bug-report as described in this document:
https://unity3d.com/unity/qa/bug-reporting

It's important that you report these issues together with a reproduction project if you want them to get fixed. If you don't do it, it might be a long time until someone else reports them or until Unity Technologies find them.

After you submitted the bug-report, you receive a confirmation email with a bug-report Case number. Please post the Case number (number only, not the link) in this forum thread for Unity staff to pick up.