![]() ![]() I've been using TexturePacker for about 3 years now, so pretty familiar with it.Īlso, I'm still getting a "Identifier uniqueness violation" occasionally as well. So those are super strange and are not behaving as they previously did, that's for sure. 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. Go back and add another new sprite to the texture atlas, with a new name and re-export.Ħ. Go into Unity and see the missing sprite reference, as it should be.ĥ. Delete the sprite's image file, and re-export again with the sprite no longer added.Ĥ. Go into Unity and update a SpriteRenderer's sprite to the new sprite.ģ. I tried making sense of it, but I can't.ġ. It will only happen with certain new sprites. Oddly, this doesn't happen consistently with every newly added sprite. Instead, they just say None (Sprite) and display nothing. Instances of the prefab will NOT update their copy of the SpriteRenderer's sprite. Go into Unity, go into a prefab, and change the SpriteRenderer's sprite to the newly added sprite.ģ. I add a new sprite to a sprite sheet and export it for Unity.Ģ. I can make them happen pretty consistently, but I'm still not entirely sure why they're happening, it's super bogus. There are a few really weird things happening. 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. And they don't even have to be referred to in the tpsheet file because they can be manually assigned to material in unity 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. 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. 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. Right now it's not a problem because I can pack it and then delete one line from the tpsheet file and it works. The thing is - there are more types of atlases that would be helpful to have.įor example, I use second atlas to pack the emission map sprites. 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. png files twice because we now know the png to sheet assignment upfront. It also speeds up the next import because we don't have to process the. This is why we need the database to retain that knowledge. Unity might kill the importer during the import process if memory is low or for whatever other reason. png file with the content of the sheet (which requires importing the png twice). png is associated with it and then re-import the. If the name is not the same we have to read the. As long as both have the same name everything is fine. The issue is the following: We have to know the content of the. 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. tpsheet files do not have the same file name and path. The disadvantage is that (re-)imports might be slower if your sprite sheets (.png) and the. I though the issue was solved with this.Īnother solution is not to check-in that file and ignore it in your source code management system so that it is writable. I've suggested to make it writable and never heard back from you. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |