(alternatively, if the go name should not be changed, save the name as string on the component)Ģ. rename the GameObject whenever the sprite.image is changed to match the name of the sprite on the sprite sheet.
#Download texturepacker sprite maker free update
(This also applies to Compression settings within Unity)Ĭlick to expand.Hi again, I might have found a solution that at least works pretty fine for me to update references when sprites are moved from one atlas to another one in auto-layout mode.īasically I have a component attached to all the UI elements that use a sprite from the atlas (call it Component "ImageAtlasReference"). Of course, I could remove all sprites from prefabs in the editor but making changes afterwards without seeing any sprite in the editor is not practical.Ĭhecking the box "Addressable" in Unity Editor for a sprite sheet is overridden when exporting again via TexturePacker. Is there similar a similar feature or should I implement it differently? (Unity atlases do not pack sprites as compactly as TexturePacker, so using it isn't an option for me) This process is crucial for both, avoiding bloating ram usage and batch optimization and can be easily achieved by using unity atlases and unchecking "Include in Build". But still, the profiler shows TPSheet-A in ram (And TPSheet-B of course). I have two TexturePacker Sprite Sheets and a prefab:Īll three are addressable assets and for simplicity let's assume TPSheet-A and TPSheet-B include similar sprites but the Prefab references sprites from TPSheet-A.īefore instantiating the Prefab I am loading TPSheet-B and reloading all sprites used in the Prefab from TPSheet-B after instantiating it. I switched to addressable assets and have some questions regarding the intended implementation. Hi everyone! First of all, thanks for the great tool! I'm using it for a while now and it's my favourite solution for importing sprites. Apparently that was the case as we quickly fixed several sheets suffering from the same issue using this process. Once he told me how he was making new projects, it raised suspicions that the upgraded TexturePacker may be formatting data differently, and thus seeding a project with old data could be the problem. On a whim, I thought it might be some sort of data corruption. Not knowing exactly how the Packer and Importer work with each other, what I did notice as shown in the screen shots in my previous post, that the importer was definitely doing something, but seemed to not be completing it's tasks on import.
tpsheet companion and everything worked as expected. After this he changed it back to Unity settings and saved. Saved the settings and it reset the project and refreshed the sprite sheet. The way I had him resolve it was he changed the data type from Unity to a different type, in his case we picked JSON Array. Apparently, after the upgrade, this seems to have caused some problems with the latest version of the importer. What it turns out is he was copying existing projects to create new ones so that he would not have to edit the settings. I spoke with my business partner who uses the TexturePacker tool and we did some experimenting. tpsheet format in notepad and it's indeed text and not JSON.
Are there any suggestions of things that may have changed in the settings from upgrades that we should look at? I did check out the. I will have to contact my business partner as he is the one who does. I don't personally work with the TexturePacker tool itself. I don't have any in 2020, but all my 2021 textures have the same issue. Any texture sheet I bring into unity that was made in 2019 or earlier work fine. OK, I played around with some other texture sheets.
0 kommentar(er)
