试图在unity中用sprite直接置换attachment图片的问题

Raindow00S

我直接使用了示例中MixAndMatch的代码，试图用sprite置换attachment的图片，但是出现了尺寸不对的问题。
如图，左边是我在spine中看见的正常尺寸，右边是我用于测试的，将头部attachment设为空的一个皮肤。我希望使用下方尺寸为256x256的头部sprite替换上去，它确实替换了，但看起来是先把透明像素全部删掉，然后把图片拉伸成256x256再换上去的…… :wounded:
官方示例中没有这种问题，我猜测是因为官方使用的sprite并没有在物体四周留出透明像素。但我希望留着以应对不同尺寸的配饰的变化。
请问有什么解决方法吗？非常感谢！

I directly used the MixAndMatch code in the example, and tried to replace the image of the attachment with sprite, but the size was wrong.

As shown in the figure, the left is the normal size I saw in spine, and the right is the one I used for testing. The head attachment is set as an empty skin. I wanted to use the 256x256 head sprite below to replace it. It did, but it looks like it deleted all the transparent pixels and then stretched the image to 256x256 before replacing it...

The official example doesn't have this problem, I guess because the official sprite doesn't have transparent pixels around the object. But I wanted to keep transparent pixels for the different sizes of accessories.

Is there any solution? Thank you very much!

Harald

通常，在替换附件（包括原始透明区域）时，重要的是原始附件大小（在 Spine 编辑器中使用）。导出骨架时，空白剥离（如果启用）将删除不必要的空白并将较小的区域打包到图集纹理。现在，当您想用另一个附件替换附件时，它需要适合原始附件大小，而不是剥离后的大小。

您的原始附件和替换精灵的大小是否相同，并且它们周围是否具有相同的空白区域？

请注意，替换附件的方法总是提供很多参数，其中许多参数保留为默认值。 Spine 示例场景中使用的 GetRemappedClone Mix and Match 例如提供了 useOriginalRegionSize、useOriginalRegionScale 等参数。

它也与您的附件类型有关：区域附件比网格附件（边界是固定的）支持更多的缩放和偏移选项。您的头部附件是区域附件还是网格附件？

In general it's the original attachment size (which was used in the Spine Editor) that matters when replacing attachments, including the original transparent area. When exporting the skeleton, whitespace stripping (if enabled) will remove unnecessary whitespace and pack the smaller region to the atlas texture. Now when you want to replace an attachment with another one, it needs to fit the original attachment size, not the stripped size.

Are both your original attachment and the replacement sprite of the same size, and do they have the same whitespace region around it?

Please note that the methods for replacing attachments always offer a lot of parameters, many of which are left at the default value. GetRemappedClone used in the Spine example scene Mix and Match for example provides useOriginalRegionSize, useOriginalRegionScale parameters amoung others.

It is also relevant of what type your attachment is: a Region Attachment supports more scaling and offset options than a Mesh Attachment (where the bounds are fixed). Is your head attachment a Region Attachment or Mesh Attachment?

Raindow00S

Harald đã viết
通常，在替换附件（包括原始透明区域）时，重要的是原始附件大小（在 Spine 编辑器中使用）。导出骨架时，空白剥离（如果启用）将删除不必要的空白并将较小的区域打包到图集纹理。现在，当您想用另一个附件替换附件时，它需要适合原始附件大小，而不是剥离后的大小。

您的原始附件和替换精灵的大小是否相同，并且它们周围是否具有相同的空白区域？

请注意，替换附件的方法总是提供很多参数，其中许多参数保留为默认值。 Spine 示例场景中使用的 GetRemappedClone Mix and Match 例如提供了 useOriginalRegionSize、useOriginalRegionScale 等参数。

它也与您的附件类型有关：区域附件比网格附件（边界是固定的）支持更多的缩放和偏移选项。您的头部附件是区域附件还是网格附件？

In general it's the original attachment size (which was used in the Spine Editor) that matters when replacing attachments, including the original transparent area. When exporting the skeleton, whitespace stripping (if enabled) will remove unnecessary whitespace and pack the smaller region to the atlas texture. Now when you want to replace an attachment with another one, it needs to fit the original attachment size, not the stripped size.

Are both your original attachment and the replacement sprite of the same size, and do they have the same whitespace region around it?

Please note that the methods for replacing attachments always offer a lot of parameters, many of which are left at the default value. GetRemappedClone used in the Spine example scene Mix and Match for example provides useOriginalRegionSize, useOriginalRegionScale parameters amoung others.

It is also relevant of what type your attachment is: a Region Attachment supports more scaling and offset options than a Mesh Attachment (where the bounds are fixed). Is your head attachment a Region Attachment or Mesh Attachment?

啊，我在导出资源时勾选了去除空白区 :scared:
我取消勾选，再次导出资源，现在图集中看起来有透明区域了，但通过代码替换的图片依然尺寸不对。
这是我想要替换上去的图片：
这是我再次导出的图集：
这是运行代码的结果：
看起来unity还是很热心地帮我把空白区裁剪掉了，因为我看到这个：
另外，如果我勾选脚本中的Repack，会产生这样的报错：
我对texture之类的方面不是很懂……所以一筹莫展…… 🙁
我用的是区域附件

=====

Oh, I enabled whitespace stripping when I exported the skeleton!

This time I disabled it and exported again. Now I have transparent areas in the atlas, but the sprite replaced through the code was still the wrong size.

Here's the sprite I want to replace on:

Here's the altas I exported this time:

Here is the result of the code:

Looks like unity still kindheartedly helped me strip the white space, because I see this:

Also, if I check the Repack in the script, I get this error

I don't know much about texture and stuff... So at a loss...

I use region attachments, by the way

Harald

感谢您提供详细的后续信息。请将 Sprite 的 MeshType 从 Tight 更改为 Full Rect，否则这将删除 Unity Sprite 中的空白。

请注意，您可以在导出骨架时启用“Strip whitespace”，尤其是在仅替换区域附件时。原始尺寸将用于替换尺寸计算。

更换网状附件时，您的设置也不应该遇到问题。当用另一个在空白剥离后更小的网格附件替换网格附件时，这将成为问题，由于未修改的固定网格边界，这会使周围的纹理区域可见。

Thanks for the detailed follow up information. Please change your Sprite's MeshType from Tight to Full Rect, otherwise this will remove the whitespace from your Unity Sprite.

Please note that you can keep Strip whitespace enabled when exporting your skeleton, especially when only replacing region attachments. The original size will be used for replacement size computations.

When replacing mesh attachments, you should not run into problems with your setup either. It will just become problematic when replacing a mesh attachment with another one which is smaller after whitespace stripping, which leaves the surrounding texture area visible due to the unmodified fixed mesh boundaries.

Raindow00S

Harald đã viết
感谢您提供详细的后续信息。请将 Sprite 的 MeshType 从 Tight 更改为 Full Rect，否则这将删除 Unity Sprite 中的空白。

请注意，您可以在导出骨架时启用“Strip whitespace”，尤其是在仅替换区域附件时。原始尺寸将用于替换尺寸计算。

更换网状附件时，您的设置也不应该遇到问题。当用另一个在空白剥离后更小的网格附件替换网格附件时，这将成为问题，由于未修改的固定网格边界，这会使周围的纹理区域可见。

Thanks for the detailed follow up information. Please change your Sprite's MeshType from Tight to Full Rect, otherwise this will remove the whitespace from your Unity Sprite.

Please note that you can keep Strip whitespace enabled when exporting your skeleton, especially when only replacing region attachments. The original size will be used for replacement size computations.

When replacing mesh attachments, you should not run into problems with your setup either. It will just become problematic when replacing a mesh attachment with another one which is smaller after whitespace stripping, which leaves the surrounding texture area visible due to the unmodified fixed mesh boundaries.

原来如此！我等会就去试试，非常感谢！😃
还想再请教一个问题，如果我有很多配件，比如上百件衣服和上百件帽子，而且我希望它们能够自由组合，使用sprite来替换附件是否是最好的方式？因为我觉得如果使用skin的话，一个spine文件可能会包含太多东西。
另外，我还想为角色添加武器，但是武器的尺寸差异太大了，我觉得比起添加透明区域以统一它们的尺寸，它们更适合单独存放于一个spine文件中，并指明它们被持握的位置。
这种方法是否可行呢？

=====

I get it! I'll try it later. Thank you very much! 😃

I also want to ask another question. If I have many accessories, such as hundreds of clothes and hundreds of hats, and I want them to be able to combine freely, is it the best way to use sprite to replace the attachments? Because I think a spine file might contain too many things if using skin to change clothes.

Besides, I want to add weapons to the character, but the size of the weapons was so different that I felt that rather than adding transparent areas to unify their sizes, they would be better placed in a single spine file that indicated where they are held (slot).

Is it feasible and practical?

Harald

如果你有这么多配件，创建一个带有多个皮肤的单一骨架可能仍然是一种可行的方法（每个服装项目一个皮肤，比如蓝色牛仔裤覆盖多个附件的一个皮肤），那么你可以更轻松地替换需要的项目多个附件，并更轻松地在 Spine 编辑器中预览任何组合。

通常，您可以使用延迟加载机制（如 Adressables、Asset Bundles 等）来一次不加载所有图集纹理，而是添加一种机制来仅加载已使用附件的纹理（以减少内存使用）。

如果您不想为所有服装项目使用具有多个皮肤的单个骨架，您可以通过两种主要方式替换附件：

通过使用Sprites，正如你已经提到的。
使用其他单独创建的Spine图集资源（按文件夹打包），如spine-unity示例场景Spine Examples/Other [/*][/list] Examples/AtlasRegionAttacher所示。

第二种方式，创建单独的 Spine 地图集资产，具有更多好处，例如更可靠的大小行为。您通常会通过命令行界面而不是与骨架导出一起打包单独的图集纹理来执行此操作，如下所述：
Texture packing - Spine User Guide: Folder structure
Command line interface - Spine User Guide

关于武器：这完全取决于您的用例。如果您的武器需要动画移动部件，它们可以是一个单独的 Spine 骨架项目（或多个项目，每个武器一个）。如果您只有单手武器，我认为不需要特殊的插槽或骨骼来标记它们的持有位置，您可以相应地移动（偏移）武器的附件，以便手与本地 (0,0) 位置匹配.使用 Unity Sprite 时，您可以相应地将枢轴设置在手柄位置。

如果您需要两个锚点，例如对于用两只手握住武器，您可以将武器的偏移设置为右手位置，并为左手添加位置骨骼。然后，您可以将武器连接到角色骨架的右手，并让左手 IK 目标骨骼将手定位在枪的前轴或重剑的手柄上。一种更简单的方法可能是只使用一些预先编写的固定动画，例如两臂持枪，两臂持剑。通常，您不需要精确调整手柄位置以使每种武器都不同。这只是我作为程序员的想法，艺术家和动画师可能会想到不同的用例和解决方案。 🙂

If you have so many accessories, it might still be a feasible way to create a single skeleton with many skins (one skin for each clothing item, like one skin for blue jeans covering multiple attachments), then you can more easily replace items that require multiple attachments, and more easily preview any combination in the Spine Editor.

In general, you could use delayed loading mechanisms like Adressables, Asset Bundles, etc to not load all atlas textures at once, but add a mechanism to load only textures of used attachments (to reduce memory usage).

If you don't want to use a single skeleton with multiple skins for all clothing items, you can replace attachments in basically two main ways:
1. By using Sprites, as you already mentioned.
2. By using other separately created Spine atlas assets (packaged by folder), as shown in the spine-unity example scene Spine Examples/Other Examples/AtlasRegionAttacher.
The second way, creating separate Spine atlas assets, comes with a few more benefits like more reliable size behaviour. You would typically do this by packing the separate atlas textures via the command line interface instead of alongside skeleton export, as described here:
Texture packing - Spine User Guide: Folder structure
Command line interface - Spine User Guide

Regarding weapons: it totally depends on your use case. If your weapons require animated moving parts, they could be a separate Spine skeleton project (or multiple projects, one for each weapon). If you have one-handed weapons only, I see no need for special slots or bones to mark where they are held, you could just move (offset) the attachments of your weapon accordingly so that hand matches the local (0,0) position. When using a Unity Sprite, you could setup the pivot accordingly to be at the handle position.

If you need two anchor points, e.g. for holding a weapon with two hands, you could have the offset of the weapon for the right-hand position and add a position bone for the left hand. Then you could attach the weapon to the right hand of your character skeleton and have a left-hand IK target bone position the hand at either a gun's front shaft, or at a heavy sword's handle. An easier way would perhaps be to just have a few pre-authored fixed animations for e.g. holding a gun with two arms and for holding a sword with two arms. Normally you won't need precisely adjusted handle positions to be different for each weapon. That's just my thoughts as a programmer though, artists and animators might think of different use-cases and solutions 🙂.

Raindow00S

Harald đã viết
如果你有这么多配件，创建一个带有多个皮肤的单一骨架可能仍然是一种可行的方法（每个服装项目一个皮肤，比如蓝色牛仔裤覆盖多个附件的一个皮肤），那么你可以更轻松地替换需要的项目多个附件，并更轻松地在 Spine 编辑器中预览任何组合。

通常，您可以使用延迟加载机制（如 Adressables、Asset Bundles 等）来一次不加载所有图集纹理，而是添加一种机制来仅加载已使用附件的纹理（以减少内存使用）。

如果您不想为所有服装项目使用具有多个皮肤的单个骨架，您可以通过两种主要方式替换附件：

通过使用Sprites，正如你已经提到的。

使用其他单独创建的Spine图集资源（按文件夹打包），如spine-unity示例场景Spine Examples/Other [/*][/list] Examples/AtlasRegionAttacher所示。

第二种方式，创建单独的 Spine 地图集资产，具有更多好处，例如更可靠的大小行为。您通常会通过命令行界面而不是与骨架导出一起打包单独的图集纹理来执行此操作，如下所述：
Texture packing - Spine User Guide: Folder structure
Command line interface - Spine User Guide

关于武器：这完全取决于您的用例。如果您的武器需要动画移动部件，它们可以是一个单独的 Spine 骨架项目（或多个项目，每个武器一个）。如果您只有单手武器，我认为不需要特殊的插槽或骨骼来标记它们的持有位置，您可以相应地移动（偏移）武器的附件，以便手与本地 (0,0) 位置匹配.使用 Unity Sprite 时，您可以相应地将枢轴设置在手柄位置。

如果您需要两个锚点，例如对于用两只手握住武器，您可以将武器的偏移设置为右手位置，并为左手添加位置骨骼。然后，您可以将武器连接到角色骨架的右手，并让左手 IK 目标骨骼将手定位在枪的前轴或重剑的手柄上。一种更简单的方法可能是只使用一些预先编写的固定动画，例如两臂持枪，两臂持剑。通常，您不需要精确调整手柄位置以使每种武器都不同。这只是我作为程序员的想法，艺术家和动画师可能会想到不同的用例和解决方案。 🙂

If you have so many accessories, it might still be a feasible way to create a single skeleton with many skins (one skin for each clothing item, like one skin for blue jeans covering multiple attachments), then you can more easily replace items that require multiple attachments, and more easily preview any combination in the Spine Editor.

In general, you could use delayed loading mechanisms like Adressables, Asset Bundles, etc to not load all atlas textures at once, but add a mechanism to load only textures of used attachments (to reduce memory usage).

If you don't want to use a single skeleton with multiple skins for all clothing items, you can replace attachments in basically two main ways:

By using Sprites, as you already mentioned.

By using other separately created Spine atlas assets (packaged by folder), as shown in the spine-unity example scene Spine Examples/Other Examples/AtlasRegionAttacher.

The second way, creating separate Spine atlas assets, comes with a few more benefits like more reliable size behaviour. You would typically do this by packing the separate atlas textures via the command line interface instead of alongside skeleton export, as described here:
Texture packing - Spine User Guide: Folder structure
Command line interface - Spine User Guide

Regarding weapons: it totally depends on your use case. If your weapons require animated moving parts, they could be a separate Spine skeleton project (or multiple projects, one for each weapon). If you have one-handed weapons only, I see no need for special slots or bones to mark where they are held, you could just move (offset) the attachments of your weapon accordingly so that hand matches the local (0,0) position. When using a Unity Sprite, you could setup the pivot accordingly to be at the handle position.

If you need two anchor points, e.g. for holding a weapon with two hands, you could have the offset of the weapon for the right-hand position and add a position bone for the left hand. Then you could attach the weapon to the right hand of your character skeleton and have a left-hand IK target bone position the hand at either a gun's front shaft, or at a heavy sword's handle. An easier way would perhaps be to just have a few pre-authored fixed animations for e.g. holding a gun with two arms and for holding a sword with two arms. Normally you won't need precisely adjusted handle positions to be different for each weapon. That's just my thoughts as a programmer though, artists and animators might think of different use-cases and solutions 🙂.

非常感谢你提供了这么多指导和资源！还有这么多东西要学！
你提到了可以通过sprite的pivot来标记偏移量，我的理解是：
1.我在手部有一个插槽用于武器附件；
2.我在武器sprite上通过pivot标记它被持握的位置；
3.当我替换武器sprite时，我通过pivot计算它的偏移量，以使pivot的位置和插槽重叠。
但我不知道具体该怎么做？ :o 是有什么函数提供了这个功能吗，还是说我要自己写一个？
我又想到，如果这种方案可行的话，是否也可以用同样的方式对衣服、帽子等进行替换（考虑到有些奇特的帽子会非常大，但我不想为了统一所有帽子图片的尺寸，而给其他所有小帽子留下大量的空白区域）？例如我可以在头顶加一个插槽来标记帽子的位置，然后也在帽子sprite上通过pivot标记它被戴在脑袋上的位置。假如我只使用区域附件。

=====

Thank you so much for providing so much guidance and resources! There's so much to learn!

You mentioned that hold position can be marked by the pivot of the sprite. I think that means:

I have a slot on my hand for weapon attachments;
In the weapon sprite, I used pivot to mark where it will be held;
When I replace the weapon sprite, I calculate its offset with the pivot to overlap the pivot and slot.

But I don't know exactly how to do that. :o Is there any function that support this or I have to write it by myself?

Then I thought, if this works, would it be possible to do the same for clothes, hats, etc. (given that some fancy hats can be very large, but I don't want to leave lots of whitespace for all the other small hats just to unify the size of all the hat sprites)? For example, I could add a slot on the top of the head to mark the position of the hat, and then also mark hat sprite with the pivot. Suppose I only use area attachments.

Harald

这么晚才回复很抱歉！

你提到了可以通过sprite的pivot来标记偏移量，我的理解是：
1.我在手部有一个插槽用于武器附件；
2.我在武器sprite上通过pivot标记它被持握的位置；
3.当我替换武器sprite时，我通过pivot计算它的偏移量，以使pivot的位置和插槽重叠。

我的意思是，如果您用 Sprite 替换附件，您可以简单地更改 Sprite 的枢轴（正常使用 Unity 的 Sprite 编辑器），这将相应地调整位置偏移。无需计算任何东西。

您可以使用“Mix and Match”示例场景进行尝试，只需调整“googles-tactical”Sprite 的轴心，以查看在播放模式下更换遮阳板时的位置变化。

Sorry for the late reply!

You mentioned that hold position can be marked by the pivot of the sprite. I think that means:

I have a slot on my hand for weapon attachments;

In the weapon sprite, I used pivot to mark where it will be held;

When I replace the weapon sprite, I calculate its offset with the pivot to overlap the pivot and slot.

I meant that if you replace an attachment with a Sprite, you can simply change the Sprite's pivot (using Unity's Sprite Editor as normal), this will adjust the position offset accordingly. There is no need to calculate anything.

You can try that out with the Mix and Match example scene, just adjust the pivot of the googles-tactical Sprite to see the visor change it's position when it is replaced in play mode.

Raindow00S

Harald đã viết
这么晚才回复很抱歉！

你提到了可以通过sprite的pivot来标记偏移量，我的理解是：
1.我在手部有一个插槽用于武器附件；
2.我在武器sprite上通过pivot标记它被持握的位置；
3.当我替换武器sprite时，我通过pivot计算它的偏移量，以使pivot的位置和插槽重叠。

我的意思是，如果您用 Sprite 替换附件，您可以简单地更改 Sprite 的枢轴（正常使用 Unity 的 Sprite 编辑器），这将相应地调整位置偏移。无需计算任何东西。

您可以使用“Mix and Match”示例场景进行尝试，只需调整“googles-tactical”Sprite 的轴心，以查看在播放模式下更换遮阳板时的位置变化。

Sorry for the late reply!

You mentioned that hold position can be marked by the pivot of the sprite. I think that means:

I have a slot on my hand for weapon attachments;

In the weapon sprite, I used pivot to mark where it will be held;

When I replace the weapon sprite, I calculate its offset with the pivot to overlap the pivot and slot.

I meant that if you replace an attachment with a Sprite, you can simply change the Sprite's pivot (using Unity's Sprite Editor as normal), this will adjust the position offset accordingly. There is no need to calculate anything.

You can try that out with the Mix and Match example scene, just adjust the pivot of the googles-tactical Sprite to see the visor change it's position when it is replaced in play mode.

感谢您耐心细致的回答！对我的帮助非常大！?我会再尝试一下。
真的太感谢了！祝您工作顺利，生活愉快！

=====

Thank you for your patient and meticulous answer! It helps me a lot! ? I'll give it a try.
Thank you so much! Hope you have a great day!

Harald

感谢您的客气话，很高兴它有所帮助！ 🙂
也有美好的一天！

Thanks for your kind words, glad it helped! 🙂
Have a great day, too!