If it does improve performance, might be another question… Therefore, importing a sprite sheet even when the art has been made custom is a possibility too? (I need more data from user’s experience on this).

When I produced animated art for video games I exported them frame by frame, but the developper used a solution to create sprite sheets to improve performance (we were making educational video games optimised for limited technologies). Defold and CT.js both support atlas generation but not direct spritesheets (Defold has some workarounds using tilemap atlases, ct.js does not accoeding to their documentation)Īnd those who create their own art export frame by frame (since they animate frame by frame). Interestingly, from a quick google a lot of engines generate atlases (spritesheets) on their final build, but only support individual images during dev. A spritesheet splitter would not eliminate this problem, while a texturepacker and spritesheet support would eliminate this problem. I imagine the technical ask would require an UX panel for sprite objects that allows them to auto detect sprite boundaries from the sheet (or allow the user to manually define them) and use them for respective animations, then use spritesheet.js to generate the data json, then use that for rendering in Pixijs.Īlternatively you could have something that just autosplits spritesheets for users as a shorter term solution, but while spritesheets don’t have a huge benefit for performance, they are important for html5 hosting optimization on places like Itch.io which has filecount limits for uploaded html5 games. TexturePacker kind of does the same, but as mentioned it is pretty broken right now (or Godot is?), and also more importantly, why should we be dependent on a third party plugin to a paid tool? Godot should be able to handle spritesheets properly itself, in my opinion.It supports spritesheet data made by spritesheet.js ( GitHub - krzysztof-o/spritesheet.js: Command-line spritesheet generator supporting Starling / Sparrow, PIXI.js, Easel.js and cocos2d) and others. atex being kind of a reference and a region to the atlas) atex files, very smart! very easy to use! (.tex being the atlas and. tex file, and you could just drag and drop those.

The way it was handled in 2.x was pretty smart, maybe not the import stuff and so on, but it generated. There is auto slicing, but it works pretty bad and also if you use that, you have to go to every single sprite, set the texture, perform the auto slicing and then select the region, again, very tedious! This issue is about how Godot handles spritesheet, and it just mentions TexturePacker as the only smart alternative right now.Īnd yes you are right, you can manually define regions but that is an extremely, extremely, extremely tedious task to do! This issue isn't tied to the TexturePacker plugin! You can see #21506 for a issue specifically targeted to TexturePacker.

Import texturepacker into unity