• Editor
  • alternative attachments or more bones and meshes?

Hi everyone, I'm an indie game developer just starting to learn Spine, and I'm currently facing a problem and seeking help 🙂

In my game, there will be many NPCs (up to 40-50) moving in different directions on the screen, and they occasionally need to make some eye and mouth movements.

What I'm not clear about is, from a performance perspective, when the direction of these characters changes (e.g., from front to 3/4 front), should I bind more bones to achieve the perspective effect, or should I adjust the perspective effect in Photoshop and try to achieve the same effect by replacing attachments?

If there were only a few NPCs, I would definitely prefer to use more bones and meshes to handle it, but I'm not sure which approach would be more performance-efficient when there are a large number of characters. Thank you very much for your answers!

Related Discussions
...

When dealing with a large number of NPCs, performance efficiency is crucial. Based on the provided contexts, here are some insights:

  1. Attachments vs. Bones: Using more bones and meshes can be more performance-intensive due to the increased calculations required for each bone and vertex. If each character has many bones and vertices, the performance cost can be significant, especially with 40-50 NPCs on screen. On the other hand, using attachments to switch perspectives can be more efficient since only the active attachments are rendered, reducing the computational load.

  2. Inactive Bones Overhead: As mentioned in the context, having many inactive bones can lead to unnecessary overhead. If you use a single skeleton with many bones for different directions, you might end up updating bones that are not visible, which can degrade performance.

  3. Swapping Attachments: Swapping attachments for different perspectives can be a more efficient approach. This method allows you to pre-render different perspectives in Photoshop and switch them at runtime. This reduces the number of bones and vertices that need to be calculated, leading to better performance.

  4. Performance Metrics: It's essential to measure the performance on your target devices. Factors such as the number of vertices, bones, constraints, and draw calls per skeleton play a significant role in performance. You can refer to the Spine Metrics page for more detailed information on performance considerations.

In summary, for a large number of NPCs, using alternative attachments to handle perspective changes is likely to be more performance-efficient than adding more bones and meshes. This approach minimizes the computational load and avoids the overhead of updating inactive bones.

    Fewer bones requires slightly less effort, so it's typically better. However, if you use skin bones, bones that are inactive because they aren't in the current skin have no performance cost. Switching skins is abrupt, so activating such bones happens immediately and it may not be possible to create smooth transitions. If you are swapping attachment you probably also don't have smooth transitions.

    As always, be wary of using deform timelines and clipping attachments.

    Thank you Nate 🙂 if I simply switch attachments instead of using skins, will there be any additional performance costs?

    Additionally, if I need to mirror the character's limbs, should I directly duplicate and set the scale to -1 in Spine, or should I mirror a new image in Photoshop? Which approach has less performance overhead?

    Thanks again for your help!

      wpw1221 What Spine runtime are you using? If you have a large number of images for each skeleton and they don't fit on a single texture atlas page, spine-unity allows you to collect and repack only the images that are actually used at runtime. However, if you are using a different runtime, there is no easy way to do this.

      Additionally, if I need to mirror the character's limbs, should I directly duplicate and set the scale to -1 in Spine, or should I mirror a new image in Photoshop? Which approach has less performance overhead?

      I think it's better to export only one image that can be shared, then duplicate it and place it in the right position on Spine. In general, it is better to have as few images to load as possible.

      Thanks Misaki, I'm using spine-unity 😃 good news

        wpw1221 I see, so I recommend that you take a look at the sample scenes Spine Examples/Other Examples/Mix and Match Skins and Spine Examples/Other Examples/Mix and Match Equip.
        In these scenes you can see how to actually pack multiple textures into a single texture.

        See also the Runtime Repacking section of the spine-unity runtime documentation: https://esotericsoftware.com/spine-unity-main-components#Runtime-Repacking