The GetRepackedSkin method in Spine does not automatically trim transparency from images when repacking them into an atlas. This means that the images will retain their full bounding box, including any transparent areas. Unlike Unity's sprite atlases, which can trim transparency and maintain the original bounding box information, GetRepackedSkin does not have this functionality built-in. To achieve a similar effect, you would need to manually adjust the images or modify the repacking process to handle transparency trimming.

@baconbanditgames GetRepackedSkin uses Texture2D.PackTextures which operates on simple rectangular textures. Note that this is runtime repacking which shall not be too costly performance-wise, so polygonal packing would not be an option under such circumstances (in most cases).

Anyway, to keep loading times low it's advisable to trim your input image size down to avoid any unnecessary whitespace in the first place.

baconbanditgames Just checking - the issue with trimming the input images down in size is that when they're used with Spine, they won't be at the correct positions unless the artist manually positions every single piece of clothing/hair/etc. in Spine...is that correct?

It depends, region attachments provide more options here than mesh attachments. You could for example trim Unity Sprites equally at the top/bottom/left/right borders when they are used at region attachments (e.g. remove a border of 10 pixels in all directions) which will make them fit automatically. If you remove different numbers of pixels at the top compared to the bottom, you can programmatically compensate the origin by adjusting RegionAttachment.X and .Y accordingly. You could for example use the normal Sprite Editor window in Unity to define the Sprites Position (X, Y, W, H) and then write a Unity editor script which uses the Sprite's X, Y, W, H dimensions to store and at runtime provide the required pivot offset to compensate for the differently cut top/bottom/left/right portions.

With mesh attachments, it's a bit more limited, as the boundary outline vertices of the mesh attachments can't grow larger or smaller if you crop the image.

The potentially easiest solution could be to provide multiple attachment templates for smaller and larger items, if you would otherwise waste lots of whitespace. This might be better than having a large attachment template which e.g. covers every possible hat shape but leaves loads of whitespace on average.

You can see some simple test settings below, equally trimming 20px on all sides to keep things simple:

Glad it helped.