TexturePacker + Importer - Spritesheet generator & Sprite mesh optimizer

The annoying thing about SettingsTexturePackerImporter.txt is that it keeps being regenerated and if differs from platform to platform. This is the diff when you open a project create in Windows in macOS:

-version: 2

-importPivots: 1

-tpsheetFileNames:

-- Assets/Resources/rotrc.tpsheet

-textureFileNames:

-- Assets/Resources/rotrc.png

-normalmapFileNames:

--

-enableDebugOutput: 0

+version: 2

+importPivots: 1

+tpsheetFileNames:

+- Assets/Resources/rotrc.tpsheet

+textureFileNames:

+- Assets/Resources/rotrc.png

+normalmapFileNames:

+-

+enableDebugOutput: 0

 

This ^^^
A day does not go by without someone on our team ranting about this damn file. It's become standard practice whenever you're about to commit to discard this file. I can only imagine the hours that's been lost to this. Fix it fix it fix it!

I got this as a tip from another colleague:

Code (CSharp):

1. git update-index --assume-unchanged Assets/ThirdParty/codeandweb.com/Editor/SettingsTexturePackerImporter.txt

 

Is your problem the line endings or the contents (order of items) in the file?

 

We are currently writing platform specific line endings in the file - that's right.
The easiest way to fix this is to let git handle the line endings. See https://git-scm.com/docs/gitattributes#_eol

 

Hey,

I've been using your TP tool for ages now and it's been really useful. Unfortunately, recently a wild mistake during a git merge resulted in some sort of corruption of the tpsheet files, which I cannot identify.

Asset reimport says stuff like:

Code (CSharp):

1. ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
2. Parameter name: index
3. System.ThrowHelper.ThrowArgumentOutOfRangeException (System.ExceptionArgument argument, System.ExceptionResource resource) (at <fb001e01371b4adca20013e0ac763896>:0)
4. System.ThrowHelper.ThrowArgumentOutOfRangeException () (at <fb001e01371b4adca20013e0ac763896>:0)
5. System.Collections.Generic.List`1[T].get_Item (System.Int32 index) (at <fb001e01371b4adca20013e0ac763896>:0)
6. TPImporter.SettingsDatabase.addOrUpdateSheet (System.String dataFile, System.String textureFile, System.String normalmapFile) (at <4588a451a4cd40178a62a5cba40dca58>:0)
7. TPImporter.SpritesheetCollection.loadSheetData (System.String dataFile) (at <4588a451a4cd40178a62a5cba40dca58>:0)
8. TPImporter.TexturePackerImporter.OnPostprocessAllAssets (System.String[] importedAssets, System.String[] deletedAssets, System.String[] movedAssets, System.String[] movedFromAssetPaths) (at <4588a451a4cd40178a62a5cba40dca58>:0)
9. System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at <fb001e01371b4adca20013e0ac763896>:0)
10. Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation.
11. System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at <fb001e01371b4adca20013e0ac763896>:0)
12. System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) (at <fb001e01371b4adca20013e0ac763896>:0)
13. UnityEditor.AssetPostprocessingInternal.InvokeMethod (System.Reflection.MethodInfo method, System.Object[] args) (at <9ddd600ae5964fe0b21a870e08c53748>:0)
14. UnityEditor.AssetPostprocessingInternal.PostprocessAllAssets (System.String[] importedAssets, System.String[] addedAssets, System.String[] deletedAssets, System.String[] movedAssets, System.String[] movedFromPathAssets) (at <9ddd600ae5964fe0b21a870e08c53748>:0)
15.  

Is there any way to pinpoint where the corruption is coming from?

 

I got the exact same stacktrace, did you manage to find a solution @barjed ?

 

Just discard the .tpsheet file and publish again from TexturePacker. Re-import your assets and everything should be back to normal.

 

Hi there, we're getting some issues while using Perforce and Unity. Some people get the changes when I commit the .png and .tpsheet, but some don't. I don't see see any mention of this error in the FAQ. Any suggestions on solutions I can try? I'll post the error below from console. Thanks.

 

The current solution for this is to make that file writable.
It's used by TexturePacker importer to cache some information required during the import process.

 

Can I remove the .tpsheet files once sprites are imported into Unity?
Is it possible to compress the image to reduce build size?

Thanks.

 

You should keep the file - it's not big after all and it's not required at run-time - just for the build.
Yes you can compress the images.

 

Hello, since upgrading to 2021.2.0f1, we have some of our textures that keep reimporting and making changes to the meta files.
Looking around it's just moving around lines for the different sprites of the spritesheets.

Is there anything we could do to fix that?

 

I've updated to Unity 2021.2.2f1 and I started getting weird issues with my sprite sheet.
First, if I reimport the spritesheet, I get a warning:

If I add a couple sprites to that spritesheet, I get a warning:

After this, if I assign any of those sprites to an image or any kind of array in inspector, these fields are set to null when I start the game or restart the editor.

 

We've investigated this issue and currently have a good and bad news.

First of all: We were able to reproduce both issues in Unity 2021.2.2f1. Both are bugs introduced in this version of Unity.

We've found a workaround for the first issue and will provide a version of the importer that will address this.
Contact me at support @ codeandweb.com to get a fixed importer version upfront.

Importer(TextureImporter) generated inconsistent result for asset(guid:7119c5f16c1daf441a9986040bcd35db) "Assets/Sprites/Icons.png"​

The latter problem is bigger:

Identifier uniqueness violation: 'Name:BtnX, Type:Sprite, FileId:0'. Multiple Objects with the same FileId are generated by this Importer. There is no guarantee that subsequent imports of this asset will properly re-link to these targets.​

Unity does not properly add new sprites to a sprite sheet anymore. All new sprites get the same ID: 0 - this is why this happens as soon as 2 or more sprites are added to a sheet.
There does not seem to be any way to access this ID from the importer. It just seems to be visible in the meta files.

We've not found any workaround for this. This breaks the incremental import of sprite sheets in 2021.2.2f1!!!

We are currently isolating both issues in stripped-down example projects and will raise bug tickets for this.
I'll post the links to the tickets here as soon as they are visible in the bug tracker.

We rely on you to up-vote the tickets to give them enough priority so that they get fixed as soon as possible.

 

Thanks, we'll try to push the ticket to our publisher to see if they can make it reach Unity faster (I think they have some priority support).

 

Updater from our side: We've submitted 2 bug reports last week but they are not yet showing up in the bug tracker on the webpage...

 

Is there any chance that you are going to be able to fix this in the future. It breaks for various people across our entire studio, non-technical people. I've had to make documentation on how to fix this, and walk people through it a few times a week, or point them to the docs. It's pretty lame!

 

@allen-MacDonald: I've suggested to make it writable and never heard back from you. I though the issue was solved with this.

Another solution is not to check-in that file and ignore it in your source code management system so that it is writable.
The disadvantage is that (re-)imports might be slower if your sprite sheets (.png) and the .tpsheet files do not have the same file name and path.

You can use the attached importer DLL - it comes with a more explicit error message - and avoids writing the file if nothing is really changed.

The issue is the following: We have to know the content of the .tpsheet file during the import of the .png file. As long as both have the same name everything is fine. If the name is not the same we have to read the .tpsheet, find out which .png is associated with it and then re-import the .png file with the content of the sheet (which requires importing the png twice). Unity might kill the importer during the import process if memory is low or for whatever other reason. This is why we need the database to retain that knowledge. It also speeds up the next import because we don't have to process the .png files twice because we now know the png to sheet assignment upfront.

 

Thanks, I'll give that a try. Cheers.

 

@CodeAndWeb I've added this to the project. People still seem to get the error. Is there anything else I can do? Are we able to store the information in a file format that works better with unity? The .txt file is checked into our source control, if we ignore it, the file will be writeable for everyone?

 

@CodeAndWeb Can I delete the .txt file from the source control? Only the person that is generating new spritesheets needs this? I can just push the .png, .tpsheet and their .meta files for the rest of the team right?

 

Can I delete the .txt file from the source control?

As I've written above:

Another solution is not to check-in that file and ignore it in your source code management system so that it is writable.

This will still generate these files on each system but you don't have to check it in.

 

Update (well - not really) on the Unity 2021.2.2f1:

We've submitted the bug reports as promised on 2021-11-18 - but they are still "open" and have not been moved to the main bug tracker for voting them up... this is quite frustrating. We also have no contact or other way to escalate the ticket.



@Francoimora if you have access to Unity's priority support it would be important to get 1381855 fixed. The other one is important too - it seems to generate the error message while the import process still seems to work somehow.

If you have to re-submit the issue please contact us at support@codeandweb.com - we can give you the project we used to submit the ticket.

 

For those who might want to help: Here's our example project that reproduces the issue.
Maybe you can also submit the bug with a reference to Ticket 1381855. Maybe this increases Unity's attention to this issue.

 

A user reported that a work-around for the issue is to delete the meta files and re-import the sprite sheets. This will give the sprites IDs different from 0 and it seems to work. But: I am not sure if this is a solution that works for everybody....

 

Ugh, I'm getting this "uniqueness" issue as well after updating Unity. It seems like it could be a real problem, as sprites that are updated in a texture atlas seem to break old sprites in Unity that were referencing them. Ouch... So is there no fix for this currently, do we just have to wait until Unity patches something on their end? This is pretty bad in the meantime. =/

 

@therobby3: I totally agree that this is a really bad situation. You possibly can't imagine my frustration that Unity is doing nothing about the tickets. We've been working hard on our tools and the plugin. The plugin exists since 2014 with almost only 5-star reviews - loads of happy users. Now it's broken and there's nothing we can do about it.

What you can do: Submit a bug report to Unity - for details see the zip file attached in the blog post above. If you have priority support at unity: Contact them...

You can also try the work-around: Delete the .meta files for the sprite sheet images. This should fix the import - but might reset settings you've applied to your sprites.

 

I've hope they will fix this

 

I hear ya. Ok, I submitted a bug report with the info given here, referencing the ticket case ID provided. I've been trying to work around this bug and I had an update for my game planned tomorrow. Unfortunately when switching between platforms, it's causing the sprite sheets to recompile and what not, thus breaking them all over again. This'll be a bit of a nightmare trying to release an update and having to keep going in between platforms and re-linking the sprites over and over again. Hopefully they can address this very soon.

In the meantime, is there a most recent version of Unity that we know of where this wasn't broke? I thought I heard reverting a project to a previous version is usually a bad idea, so I'm a bit skeptical on whether or not I should consider that.

 

Thanks!

As we've seen, the issue (only?) happens when adding new sprites to an existing sprite sheet. This is when Unity assigns IDs of value 0 to all new sprites.

So it should not be an issue if you remove the meta files, add the sprite sheets and start a build. After that check in the files meta files. Building the project on other platforms should not create any trouble.

As far as we know the trouble started with 2021.2.0f1.

 

Ok thanks for the info. I just went ahead and downgraded to Unity 2020.1 then, so I don't have to deal with the bug in the meantime. If you hear anything about them fixing it, please let me know.

side note: Texture packer and SpriteIlluminator are great, I use them all the time!

 

Really enjoying Texture Packer's Unity plugin, it works great!

Is there a way to access the Sprites from a Texture Packer spritesheet from code without having the spritesheet be in a Resources folder? I have certain builds where I don't want to include all spritesheets.

Here's the example code from the Texture Packer Unity documentation:

Code (CSharp):

1. Sprite[] sprites = Resources.LoadAll("my_spritesheet");
2. Dictionary spritesDict = new Dictionary();
3.  
4. foreach (Sprite sprite in sprites)
5. {
6.     spritesDict(sprite.name, sprite)
7. }
8.  
9. sprite1 = spritesDict["sprite01"];

 

@smithmj5 Are you using Unity's Addressables system in your game? It can be done using Addressables, I know that. I am doing it in my game.

 

For the recent issue posted here involving Unity 2021.2 and texture importing, here is the bug report you can vote on to help get it fixed: https://issuetracker.unity3d.com/is...ot-spritesheet-to-split-an-image-into-sprites

 

Yes - and the other issue is now also online: https://issuetracker.unity3d.com/is...g-sprite-triggers-inconsistent-result-warning

 

I'm not sure if this is bad news or not. But it looks like they marked the first bug report as "By Design". See here: https://issuetracker.unity3d.com/is...8535.78050943.1641219753-665582323.1609424335

Any idea what were are to do? Will we be unable to ever update to a newer version Unity because of this? Or is their comment they made something that TexturePacker can fix?

 

I've seen that. The Unity guys provided a pointed us to another API for the sprite import. We are now investigating this solution...

 

It's awesome that there is an option to pack a second set of sprites with the same layout but this option needs to be updated - currently it only supports one extra atlas variant and it's arbitrarily treated as a normal map. The thing is - there are more types of atlases that would be helpful to have.
For example, I use second atlas to pack the emission map sprites. Right now it's not a problem because I can pack it and then delete one line from the tpsheet file and it works. If I don't remove the line that's pointoing to the second atlas it will automatically set it to normal map in Unity and it won't let me change it without editing the tpsheet file and reimporting the atlas.
In a case where I would want to have emission maps and normal maps (or more types) for my sprites then I woud have a problem. It's possible most people won't need this feature but it seems to be a pretty simple thing to implement - to add multiple atlas variants instead having just one for normal maps. And they don't even have to be referred to in the tpsheet file because they can be manually assigned to material in unity

 

One thing that was also confusing me is that the atlas layout is not saved with the project and it has to recalculate it everytime the project is opened. And it takes a lot of time to calculate the layout for a large amount of sprites when using the polygon outline method. Would it be possible to just take the data from the exported tpsheet file? Or even to save the values to the project file itself? It would allow to reexport the spritesheet anytime later without having to recalculate the layout and would ensure the layout is exactly the same - this would also solve the previous issue with there being only one additional atlas variant that can be packed with the same layout.

 

Looks like we've found a solution for the issue with the importer.

The only caveat is that it requires Unity 2021.2.8 or newer since we use a new API that is not available in older versions.

You can download the importer test version from here: https://www.dropbox.com/sh/tr4fsl1lpr9dwzl/AABt6EYIi5UyP92LMWQccSoOa?dl=0

Feedback welcome!

We'll make an official release of this version if we get no negative feedback this week.

 

We already have this issue in our feature backlog. But your guess is right, it is a rarely requested feature, it has low priority, I'm sorry.

Why do you want to reexport the spritesheet if nothing has changed?

 

We still have the same problem as before with the new importer on Unity 2021.2.8. Switching from one device to another makes Unity reimport some files and changing the order of lines in meta files. Even disacarding it in Git doesn't do anything as Unity wants to reimport it the exact same order for this computer (which differs for every member of our team). Here is an example screen :

 

Between which devices are you switching? Can you send us a small demo project to support@codeandweb.com which we can use to reproduce this problem?
With my own test projects the lines in the nameFileIdTable of the meta file have always stable order. To be honest I don't think that we have any influence on the order Unity stores these lines in meta files.

 

We have this issue when we reimport from different computers in the team.
I've sent a repro project the 25th of november via mail. And just now saw that my last answer got stuck in drafts, sending it over !

 

So I updated to the newest version of the Texture Packer importer and updated Unity to 2021.2.8 today and after adding a new sprite to an existing texture atlas, somethings are not behaving as they should. There are a few really weird things happening. I can make them happen pretty consistently, but I'm still not entirely sure why they're happening, it's super bogus. I will try to explain:

Situation #1.
1. I add a new sprite to a sprite sheet and export it for Unity.
2. Go into Unity, go into a prefab, and change the SpriteRenderer's sprite to the newly added sprite.
3. Instances of the prefab will NOT update their copy of the SpriteRenderer's sprite. Instead, they just say None (Sprite) and display nothing.

Oddly, this doesn't happen consistently with every newly added sprite. It will only happen with certain new sprites. I tried making sense of it, but I can't.

#Situation #2
1. I add a new sprite to the sprite sheet. and export it.
2. Go into Unity and update a SpriteRenderer's sprite to the new sprite.
3. Delete the sprite's image file, and re-export again with the sprite no longer added.
4. Go into Unity and see the missing sprite reference, as it should be.
5. Go back and add another new sprite to the texture atlas, with a new name and re-export.
6. Go back into Unity, and the new sprite (with the new name) has somehow linked itself in place of where the old other one was.

So those are super strange and are not behaving as they previously did, that's for sure. I've been using TexturePacker for about 3 years now, so pretty familiar with it.

Also, I'm still getting a "Identifier uniqueness violation" occasionally as well. it's not as consistent as before, but its popping up sometimes still and I'm not sure why exactly.

Another thing I'm noticing, which I'm not sure is intended or not, is that newly published atlases seem to show a sprite's name as "sheetName-spriteName". As where older atlases not imported with the new importer just display "spriteName". It doesn't seem to be causing any issues that I notice so far, but I just figured I'd point it out.

Overall though, those two problems mentioned are fairly big and are causing me to not be able to progress on what I need. I'm a bit worried that if I add and update more sprites, that some things will break and I won't be aware of it. So I think I'll work on some gameplay features and hold off on adding new sprites until next week, when hopefully I hear something back on this. Please let me know!

Additionally, my texture packer importer is 6.0.0, but my Texture Packer program itself is still 5.5.0. I'm not sure if that's an issue, but I figured I'd post it.

 

@therobby3 that sounds like you're still using the old importer version. Please check if the "Assets/codeandweb.com/Editor" folder contains "SpritesheetImporter.cs". If it is missing please re-download TexturePackerImporter, reinstall it, and try again. Unity's global package cache sometimes installs outdated package versions

 

Ah, thanks much for the reply! It seems you are correct. For some reason it didn't update properly. I updated it again and it seems to be working as intended now. Thanks!

 

If I lose or modify the exported file for example and want to ahve a new one. But the main thing is to not have the layout calculated everytime I close and reopen the project

 

We're also running into this issue on Unity 2021.2.11. Switching to another platform, discarding changes in git, then switching back to the original platform will also cause a reimport and the `nameFileIdTable` to change.

 

Unity 2021.2.16f1, importing latest Texture Packer package I get the error: