kadak The problem is this method is cutting the alpha so much that we have body parts bleeding into other parts bounding box within the atlas. The only way we found so far is adding red pixels in the corners of each texture, so the algorithm does not cut the alpha.

Skin.GetRepackedSkin does not change the atlas region (or even analyse and cut according to alpha values). Any padding settings of the original atlas however will not be recreated by GetRepackedSkin. If your region borders are too tight, I assume that you have enabled Strip Whitespace X|Y which removes transparent parts from your region during atlas packing. Thus we would recommend disabling Strip Whitespace X|Y. There is no need to paint red pixels 🙂.

PS: I know we could use padding, but even with a 256 padding we still have overlap for some reason, and 256 is already a lot of wasted space

Padding settings during atlas packing do not affect the problem, as the atlas region remains the same, which determines the "cut out" area.

    Related Discussions
    ...
    4 days later

    Where can I set the Strip Whitespace? I don't see any parameter similar to it in the GetRepackedSkin method. To illustrate my scenario a bit better though, I'm creating atlasses out of a bunch of individual images, not using existing atlases to combine them. So I'm not expecting any previous padding or spacing to be respected, it is a simple use case, just atlasing individual textures (1 per cloth)

      kadak So I'm not expecting any previous padding or spacing to be respected

      The problem here is that if you have cut all whitespace before via Strip Whitespace, you're re-packing some "tighly cut" attachment images at runtime which would require padding to be added (or respected) during packing.

        Ah this makes a lot of sense, will try it and get back to you, thanks!

        Glad it helped, thanks for getting back to us!

        Hey, it turns out the spine export options were fine. I have a couple of pics to provide a little bit more context. You can see how the t-shirt png has alpha at the bottom and it is being cut when the atlas is generated. I'm not sure if this is important, but there are a couple particular things about this use case:

        1. All the images in the atlas except for the t-shirt come from the exported atlas from spine.
        2. The spine atlas where the t-shirt lived, was replaced by a 1x1 texture, and the t-shirt is loaded separatedly. I tried having the original texture, but it was the same.
        3. Note that the sleeves in the atlas have the red dots and they work fine




          kadak You can see how the t-shirt png has alpha at the bottom and it is being cut when the atlas is generated.

          If Strip Whitespace is disabled but your attachment image is still cut, are you using this attachment images at a Mesh Attachment and packing using Packing mode Polygons?

            We are using images as Mesh Attachments, yes, but the problem I think is not there. Let me explain the full process of exportation:

            1. We export the spine models with the atlases, these are the result atlasses and the export settings:


            1. Separatedly, without groind through spine, we import into unity this images:




            1. Finally, at runtime, when we are happy with the mix and match (which uses the images above for this example), we call the Skin.GetRepackedSkin method to combine everything into 1 atlas. And here, we get this atlas:

            Now, as you can see, the issue is with the packing inside unity, not from spine. But maybe it is related somehow? I took a look at the code and it does not seem to do anything crazy, internally it uses Texture2D.GetPackedTextures, which does not have a lot of parameters to set.

            This is the final result in game, which is caused by the atlasing algorithm not respecting the alpha of the shirt

            @kadak Thanks for the additional info.

            We export the spine models with the atlases, these are the result atlasses and the export settings:

            I see only a single atlas texture above, not showing any shirt parts. Did you forget to include the second atlas texture, or was the above just a typo and you meant "atlas" instead of "atlasses"?

            Where is the original shirt atlas area which you replace with the "RE-TOP" attachment at runtime? Could you show the original texture that you mentioned here in a posting above:
            "The spine atlas where the t-shirt lived, was replaced by a 1x1 texture, and the t-shirt is loaded separatedly. I tried having the original texture, but it was the same."

            Could you perhaps please send us a minimal Unity project which shows the issue? You can send it as a zip package to contact@esotericsoftware.com, briefly mentioning this forum thread URL so that we know the context.

            We have 2 extra atlases that get exported from Spine, one that contains clothes, and one that contains hair styles. But since we replaced those with 1x1 textures, I did not send them. There is one thing worth mentioning, which is, this specific shirt does not live in the atlas we export from spine. We have one cloth of each type in spine, and this one is not the one in spine for the type Shirt, we export it directly from photoshop (respecting the silhouette of the original texture). Also, the original texture for this type is larger, the silhouette of the RE-TOP texture fits perfectly into the original texture, but the original one goes all the way down, not like this one. Here are the original atlases that are missing above:


            Note that the RE-TOP texture occupies the same atlas slot that the only shirt that is not magenta (I painted everything magenta for this post, this is not something we do in our pipeline). As I explained above, you can see how the RE-TOP texture is smaller, but the shape of the RE-TOP fits perfectly into the original texture.

            As for the example project, I don't have the resources to provide one at the moment, but if we reach a dead end in our conversation I can re-evaluate

              kadak But since we replaced those with 1x1 textures, I did not send them.

              But that was the important part. 🙂 It does not matter if you later replace the texture, it's the original atlas packing layout (stored in the .atlas.txt file) that matters, and which original region is of what size. It now helps a lot to see the original shirt in the atlas.

              Is your "Re-Top" attachment image of exactly the same size as the original shirt attachment image (the attachment image used in the Spine Project before packing)? If so, then perhaps some Unity Texture Import settings allow it to be cropped to smaller size during the PackTextures() call. Could you please check whether perhaps the problematic "Re-Top" Texture has Texture Import settings set to Sprite with tight packing or the like? You could also share a screenshot of the Texture Import settings. When doing so, please don't crop it to the region you think is important.

              In general at would be best if you could send us a minimal Unity reproduction project as described above.

                Yes, the RE-TOP image is exactly the same size as the shirt attachment image in Spine, it just has some empty space that should be preserved so it can use the same mesh. We do not have import settings because the image is being loaded from StreamingAssets or from a CDN depending on the case (StreamingAssets does not recognize files as unity files but as raw files). Your point makes sense though, I'll check that I'm not losing resolution when loading the texture in the code.

                This is the code that loads the texture in case you can spot something before I do:

                var texture = new Texture2D(2, 2, importSettings.TextureFormat, importSettings.UseMipMaps);
texture.LoadImage(bytes);
texture.name = textureName;
texture.wrapMode = TextureWrapMode.Clamp;
texture.filterMode = FilterMode.Bilinear;

if (importSettings.CompressTexture)
{
	if (texture.width % 4 == 0 && texture.height % 4 == 0)
	{
		texture.Compress(true);
	}
	else
	{
		Debug.LogWarning($"Could not compress texture `{texture.name}` because it is not divisible by 4");
	}
}

return texture;

                Regarding the sample project, unfortunately, I don't have the resources at the moment to work on this, if we reach a dead end in the conversation maybe this raises in priority and I get the resources

                I'll get back to you, thanks!

                  These are the texture import settings I'm creating in the code:

                  var uncompressedTextureImportSettings = new TextureImportSettings()
{
     CompressTexture = false,
     TextureFormat = TextureFormat.RGBA32,
     UseMipMaps = false
};

                  @kadak Unfortunately I can see nothing obviously wrong about your code. In general using streaming assets for textures is not recommended since Asset Bundles and Addressables have been introduced, but that's another topic.

                  Just a shot in the dark, but could it perhaps be that the asset in the build are not updated properly and a leftover asset is used? You could have a try replacing the problematic texture with something completely different, just to see if everything is updated properly.

                  kadak Regarding the sample project, unfortunately, I don't have the resources at the moment to work on this, if we reach a dead end in the conversation maybe this raises in priority and I get the resources

                  I'm afraid we won't get much further by discussion alone.

                    I'm a 100% sure the assets are correctly updated. Unfortunately using asset bundles or addressables is not an option in our case. I'll try playing around with values tomorrow probably, and then if that does not work I'll try to see if I can get you a sample project. I'll keep you posted, thank you!