• Editor
  • Linked Mesh or Similar Effect with Slightly Differently Shaped Parts?

To achieve your goal of creating a character with interchangeable parts while minimizing repetitive work and maintaining performance, you can follow these steps:

  1. Linked Meshes for Similar Shapes: Use linked meshes for parts that have the same shape and size. This will allow you to reuse the same mesh and weights, saving time and ensuring consistency in animations. For example, if you have different weapons that are the same size and shape but have different designs, linked meshes are ideal.

  2. Duplicating Meshes for Different Shapes: For parts that have different shapes and sizes, you can duplicate the mesh and adjust the image path. This way, you can ensure that the vertices and weights match as closely as possible. This method is recommended when the shapes are not identical but still similar enough to share some vertex positions and weights.

  3. Wireframe Mode for Reference: When creating new meshes for parts with different shapes, use the wireframe mode to make the vertices of the original mesh visible. This will help you place the vertices of the new mesh in matching positions, ensuring that the overlapping parts deform similarly.

  4. Consistent Weights: Ensure that the vertices on the overlapping parts of different meshes have matching weights. This will help the parts deform consistently and look seamless when animated.

  5. Skin Constraints: If you have parts that need to be resized or repositioned slightly to match the character's proportions, consider using skin constraints. This can help you adjust the parts without creating entirely new meshes.

  6. Reuse Animations: If the animations are created using bones and weighted meshes, you can reuse the same animations across different skins. This will save you from having to recreate animations for each part.

By following these steps, you can reduce the workload and maintain performance while creating a character with interchangeable parts.

For more detailed information, you can refer to the following resources:

Related Discussions
...

Thanks bot, Is there a good way to keep different weapons in a similar shape? These weapons might be 90% similar (for example, all long-handled weapons), but there will always be some small differences in shape. If there's a good way to make them consistent, I think linked mesh would be the best solution.

And if I choose to duplicate meshes for different shapes, when I change the image path, I'm prompted to choose between stretch or keep size. I found that even if I select keep size, the image still gets somewhat stretched. The only way to fix it is by resetting, but that results in losing the existing mesh and weight 🙁

    wpw1221 When using linked meshes, the images must match in size or it will not work properly. In your case, all weapon images should be exported in a size that matches the largest weapon size.
    This can result in very large whitespaces on small weapon images, but this should not be a problem because Spine can strip the whitespace when outputting the texture atlas if you have checked Strip whitespace X/Y in the texture packer settings: https://esotericsoftware.com/spine-texture-packer#Regions

    Thanks Misaki! Does that mean I need to uncheck "trim whitespace" when importing from PSD to Spine? If so, this would make each image very large. Is there a good way to use the largest weapon as the base shape without including unnecessary whitespace?

      wpw1221 If you were using Photoshop, you could use a layer mask to make its borders the trim size of that layer. For example, add a layer mask for the parent group like this and include the [trim:mask] tag in the group name:

      The [trim] tag is taken into account even if the Trim whitespace option in the PSD import is checked. The result after import will look like this:

      If you are using software other than Photoshop, the layer mask itself may not be available in the first place, in which case another workaround may be necessary. If this applies to you, please let us know which image editor you are using.

        Misaki I'm using Photoshop, thank you very much Misaki! 😃
        I have another question: If my skeleton has a lot of images, considering performance during loading, should I avoid putting them all in one atlas when exporting, and then use the method https://esotericsoftware.com/spine-unity-main-components#Runtime-Repacking here to repack them as needed?
        Thank you again for your response!

          • تم التحرير

          wpw1221 I think there is a bit of confusion in your understanding, so let me clarify: If your concern is loading times, runtime repacking is not the direct solution. By default, the SkeletonDataAsset references the AtlasAsset, which references its atlas pages as Materials, where each Material references the atlas page texture. So if you exported all atlas pages normally as a single AtlasAsset, all pages will be loaded as soon as your skeleton's SkeletonDataAsset is loaded.
          If you want to load atlas texture pages on-demand, you need to make sure to not include direct references and instead use Unity means of delayed-loading, such as Addressables. You can use a build script to clear any direct references to the delayed-loaded resources and use a loader script to load and assign references at runtime when actually used.

          To make it easy, we provide convenient modules: Spine On Demand Loading and Spine Addressables. These are still experimental and are not yet explained in the spine-unity documentation, but you can find instructions on how to use them in the README.md here: EsotericSoftware/spine-runtimestree/4.2/spine-unity/Modules/com.esotericsoftware.spine.addressables/Documentation
          For installation instructions, please refer to the instructions in the Optional Extension UPM Packages - B-Add package from git URL section of the spine-unity runtime documentation.


          So what does runtime repacking do? It can help reduce the number of draw calls by combining texture atlas pages into a single page, thus improving performance at runtime. The benefits of reducing draw calls are explained in the official Unity manual: https://docs.unity3d.com/2022.3/Documentation/Manual/optimizing-draw-calls.html

          Optimizing draw calls and render-state changes has a number of benefits for your application. Mainly, it improves frame times, but it also:

          • Reduces the amount of electricity your application requires. For battery-powered devices, this reduces the rate at which batteries run out. It also reduces the amount of heat a device produces when running your application.
          • Improves maintainability of future development on your application. When you optimize draw calls and render-state changes earlier and maintain them at an optimized level, you can add more GameObjects to your scene without producing large performance overheads.

          If you have additional questions, you may want to create a new post to make it clear that they are spine-unity related.

            Misaki Thank you Misaki, I understand better now! As a beginner in game development, I still have a lot to learn. If there are any new questions, I will start a new post. Thanks again for your help! 😃

            Misaki I apologize for replying to this post again, but I feel this issue might be related to the current topic. Using the method you provided, I successfully placed different weapons and body parts under the same linked mesh and removed excess parts in the mask during the final export by using strip whitespace X and Y. However, I'm now facing a new issue with creating normal maps.

            I followed the process in this post https://esotericsoftware.com/forum/d/13453-use-premultiplied-alpha-when-texture-packing-normal-maps/4 to create normal maps for each weapon and part using SpriteIlluminator. But I found that if strip whitespace is checked on both normal and albedo maps, the sprite positions on the exported images do not align. Is there any way to force the positions in the texture packer to stay consistent while still using strip whitespace?

            Additionally, I have a minor question: if I place normal maps and albedo maps in the same folder, is it possible to export them separately based on file names or other identifiers? This would be more convenient for file management. However, this issue is not as important as the one above. Thank you very much! 😃

              wpw1221 Hmmm, that sounds strange. If you are following the method presented in that thread, I think you should be able to pack the textures in the same arrangement even if you check the StripwhitespaceX/Y checkbox. Did you use the texture packer to pack both albedo and normal maps? If either is packed at the same time as the JSON or binary export, the results may be different.

              If you have both packed with the texture packer, but the results are different, this may be a bug, and we would appreciate it if you could email us the image files that can reproduce the problem: contact@esotericsoftware.com
              (You can paint the images a random color or something so we can't see the specific images).


              Additionally, I have a minor question: if I place normal maps and albedo maps in the same folder, is it possible to export them separately based on file names or other identifiers? This would be more convenient for file management. However, this issue is not as important as the one above.

              It is impossible to separate packs if they are in the exact same folder. If the parent folder is the same and they are each in their own subdirectory, the texture packer will pack them as separate pages unless the Combine subdirectories checkbox is checked in the texture packer settings.
              For example, the folder hierarchy should look like this:

              <images folder>
                    ├── <albedo>
                    │ ├── body.png
                    │ ├── head.png
                    │ └──  ...
                    └── <normal>
                      ├── body.png
                      ├── head.png
                      └── ...

              In this way, two texture atlas pages can be obtained with a single texture packing.

              If you have both packed with the texture packer, but the results are different, this may be a bug, and we would appreciate it if you could email us the image files that can reproduce the problem:

              Sure! I have sent the content via email. 🙂

              It is impossible to separate packs if they are in the exact same folder. If the parent folder is the same and they are each in their own subdirectory, the texture packer will pack them as separate pages unless the Combine subdirectories checkbox is checked in the texture packer settings.

              To facilitate future skin replacements, I have organized the albedo folder based on the replaceable parts. However, I can try exporting the normal map images to a separate folder. Thank you again for your help!

                wpw1221 We have received your email, but it appears that the file was either not attached or was deleted during transmission. Could you please resend the file?

                  Misaki I'm sorry, I forgot to upload the files after packaging them. Please check again. Thank you!

                    wpw1221 Thank you for sending the file! I think I found the cause. You have Current project checked in the texture packer settings. I assume that you have the skeleton project open and then run the texture packer, which automatically packs the albedo map based on the information in the currently open project, so the pack result would be different from the normal map. As long as I did the pack with the same settings as yours (Strip whitespace X/Y checked) with a new Spine project open, the image alignment between the albedo map and the normal map matched perfectly. Could you try unchecking Current project and see if that solves the problem?

                      Misaki Thank you, Misaki. I used your method to pack them with a new Spine project. Most of the layouts are consistent now, but there are still some minor differences that prevent the normal map from working. I have emailed you.

                        wpw1221 Sorry for the wait to get back to you! It appears that you have checked Alias in the texture packer settings.
                        In the images for the albedo map, the following two have different shadow color shapes, but in the images for the normal map, they have exactly the same pixel:

                        • body/body_neck_skin_F_n.png
                        • body/body_neck_skin_S_n.png

                        When Alias is checked, two images that are pixel for pixel the same will only be packed once. The configure.jpg included in the .zip file you originally sent us had Alias unchecked, so it worked for me. Could you confirm that unchecking Alias produces the expected results?

                        Thank you, Misaki! I tried it and found that unchecking "Alias" does indeed allow them to have the same layout.

                        Additionally, I noticed that the folder structure for normal maps must match the folder structure for albedo maps. If the albedo folder has subdirectories (and you check "Combine subdirectories"), but you place all 57 normal images in one folder (without checking "Combine subdirectories"), this also causes their texture layouts to differ when packing.

                        Thanks again!

                          wpw1221 I’m glad to hear you've figured it out. Thank you for getting back to us! 🙂