bebete Before I answer your question, I would like to tell you this: please feel free to post in your native language on this forum. In particular, the "한국어" tag you chose is for posting in Korean, so you don't need to post in English. 🙂


Regarding your problem, perhaps the image paths described in the atlas file do not match the paths for each attachment that the skeleton data has. If you pack with the folder specified in the image path of the skeleton, the image path will generally match, but if you pack with a folder lower down in the hierarchy than that as the input folder, it will be described in the atlas file, as you can see in the screenshot below The paths described in the atlas file will change, as you can see in the screenshot below:

The atlas file on the left was exported by specifying the folder specified in the skeleton image path, and here the path boy/arm-front is described, but if the boy folder is specified as the input folder and packed, that folder name is not described in the atlas file, so the path is arm-front. In this case, the paths do not match, and the images will be out of reference when imported into Unity.

To optimize performance, I duplicated the atlas file as many times as the number of images.

If performance is a concern, it is better to implement on-demand texture loading using the Spine Addressables Extensions rather than splitting the atlas file. For more information, see the following documentation:
EsotericSoftware/spine-runtimestree/4.2/spine-unity/Modules/com.esotericsoftware.spine.addressables/Documentation

    Related Discussions
    ...
    • 已编辑

    Misaki 친절하고 답변 고마워 해당 기능은 한번 살펴볼게 그리고 모국어로 편하게 질문하도록 할게!

    내가 원하는 것은 수십가지의 코스튬 파츠가 있는 캐릭터에서의 효과적인 이미지 관리야, 복잡하게 움직이는 캐릭터의 코스튬들이 수십가지가 생긴다면 하나의 스켈레톤데이터에서 2048x2048의 이미지가 20장 넘게 들어가야 할 일이 생겨버리는거지. 그러면 유니티에 좋지 않을거야.
    하지만 이 이미지들을 전부 각각의 스파인 파일로 분할 출력한 후 유니티에서 합쳐버리는것도 좋은 선택은 아닌거같아. 왜냐하면 각 스파인끼리 교차되어서 나타나는 이미지들이 있을 수도 있는데 그럼 모든 파츠들을 전부 나눠서 올려야 해서 이미지들끼리의 드로우오더 순서가 복잡해지니까, 그럼 스파인 파일은 100개 이상이 필요할거야. 그걸 컨트롤 하는것도 어려운일이지.
    슬롯을 끄고 키는 기능 또한 머리카락만 40개가 넘는 슬롯이 있는데 코스튬별로 슬롯을 따로 관리해야해서 이렇게 되면 관리해야 하는 슬롯의 갯수는 수천개가 되어버리지.

    우리팀의 기술자가 가장 이상적으로 원하는건 하나의 스켈레톤 데이터로 슬롯과 움직임의 모든것을 관리하되 아틀라스들을 나눠서 필요할때만 아틀라스를 불러오고 안불러오고 할 수 있는 최적화를 원해. 하지만 하나의 스켈레톤 데이터에서 하나의 아틀라스 파일을 불러오는데 거기에는 모든 이미지들과 머태리얼의 데이터가 집합되어 있어서 분리할 수가 없지. 이것을 분리해서 최적화를 구현하는 방법을 찾고있어.
    그 노력의 일환중에 하나가 내 첫번째 게시물에서 보이는 작업들이지 그리고 너의 친절한 답변에 아틀라스 텍스트를 수정하여 마젠타로 깨지는 부분은 해결했어. 하지만 결국 스켈레톤 데이터에서 여러개의 아틀라스 에셋을 넣었다 뻈다 할때는 오류가 발생하더라구 좋은 방법이 없을까?

    아니면 나의 접근법이 처음부터 틀린걸까? Spine_boy_unity 예제나 foot_soilder예제를 보니까 교체하는 필요 파츠가 아예 다른 폴더로 빠져있던데 그런 방식이 좋은건지 그건 어떻게 하는건지 어떤 방식으로 관리해야 좋을지 알려줘!

      bebete I am glad to hear that you have resolved the issue with the broken texture reference!

      우리팀의 기술자가 가장 이상적으로 원하는건 하나의 스켈레톤 데이터로 슬롯과 움직임의 모든것을 관리하되 아틀라스들을 나눠서 필요할때만 아틀라스를 불러오고 안불러오고 할 수 있는 최적화를 원해. 하지만 하나의 스켈레톤 데이터에서 하나의 아틀라스 파일을 불러오는데 거기에는 모든 이미지들과 머태리얼의 데이터가 집합되어 있어서 분리할 수가 없지. 이것을 분리해서 최적화를 구현하는 방법을 찾고있어.

      The Spine Addressables Extensions exist for just such cases. Using them will still load all textures, but you can improve the loading time by loading a lightweight dummy image instead of the production image, and loading higher resolution textures as needed.

      Questions about effective asset management for characters with dozens of costume parts are very common, so please take a look at the following threads:
      https://esotericsoftware.com/forum/d/28180-reducing-batches--draw-calls-multiple-textures-materials

      The thread above answers the basic ideas, but below are threads that our Unity expart, Harald, has answered for users who have responded to various things they have tried to optimize their complex skeletons. They are all very long, but I think you will find the information helpful.
      https://esotericsoftware.com/forum/d/28191-how-to-export-skins-in-their-own-skeletons
      https://esotericsoftware.com/forum/d/26782-feature-request-better-spriteatlas-support

      Also, since you mentioned the possibility of skeletons intersecting each other, I would like to point you to the following thread on SkeletonRenderSeparator:
      https://esotericsoftware.com/forum/d/28232-how-to-properly-attach-sprites-with-skeletonpartsrenderer

      @Misaki In addition to what Misaki said, you could also use runtime repacking to pack multiple atlas page textures to a single one.

      In general if you have lots of large atlas textures, the Spine Addressables Extension UPM package is recommended.
      See the following issue ticket comment here for the Add package via Git URL path (and replace 4.1 with 4.2 accordingly):
      EsotericSoftware/spine-runtimes1890

      Misaki와 Harald의 헌신과 노력은 늘 저를 기쁘게 합니다 친절한 답변에 너무 감사드립니다 이후는 팀 엔지니어의 추가적인 질문입니다. 이 질문에 대한 답변이 달린 후 우리팀의 문제가 해결되기를 진심으로 기원합니다

      [Question] Is it possible to change AtlasAssets dynamically in SkeletonAnimation?

      Hi, I have a question about dynamically changing the AtlasAssets in SkeletonAnimation.

      My current setup**

      • I have a character's main SkeletonAnimation created in Unity.
      • The AtlasAssets contains costume parts (Materials & Textures).
      • Each costume part has its own animation data inside the main SkeletonData.

      My Goal**

      • I want to remove and add specific SpriteAtlasAssets dynamically from AtlasAssets at runtime.
      • For example:
        1. The character currently displays Hair 1 (from AtlasAssets A).
        2. I want to replace Hair 1 with Hair 2 (from AtlasAssets B).
        3. The new Hair 2 should be properly rendered and play animations from the main SkeletonData.

      My Questions**

      1. Is it possible to dynamically add/remove AtlasAssets in SkeletonAnimation at runtime?

        • If I modify skeletonDataAsset.atlasAssets, will calling SkeletonAnimation.Initialize() apply the changes?
      2. If I change AtlasAssets, will the character's animations update properly?

        • Will the attachments from the new Atlas automatically map to the existing bones?
        • Will the character correctly display the new costume part with animations?
      3. Would you recommend a different approach?

        • Would using SetAttachment() or SetSkin() be a better solution instead of modifying AtlasAssets?

      I would appreciate any guidance on this. Thank you!

        bebete That is exactly what can be achieved with runtime repacking introduced by Harald! Please see Spine Examples/Other Examples/Mix and Match and Spine Examples/Other Examples/Mix and Match Equip and the used MixAndMatch.cs example script for further insights.

        These example scenes are briefly introduced in the following video at 18:21-18:56, so it may be easier to see where to look for them:

        Misaki가 말한 예제는 이미 나에게 오래전부터 많은 가르침을 준 예제입니다! 보여지는 형식으로는 해당 예제와 쓰고자 하는 기능은 완벽히 같지만 Export 파일 관리 단계에서 우리는 이 예제와는 다른 문제에 봉착해있습니다.

        차이점에 대하여 : 영상 18:21-18:56 에 있는 예제는 아틀라스 텍스쳐의 사이즈가 작습니다! 한장의 아틀라스 텍스쳐로 기능하는 동작이며 추가로 파츠가 수십개가 늘어난다고 해도 엔진에 큰 부하가 없습니다. 하지만 우리의 프로젝트는 하나의 코스튬 파츠가 2048수준으로 커질 가능성이 높습니다.

        우리의 궁극적 목표는 언제나 한가지입니다. 하나의 스파인 파일에서 이미지 폴더 기능을 사용하여 2048x2048사이즈의 아틀라스 텍스쳐 수십장을 출력합니다. 그 후 엔진에서 하나의 스켈레톤 데이터에서 예시와 같이 Mix and Match기능을 사용하여 코스튬을 자유롭게 변경합니다.(코스튬은 이미지폴더 기능으로 코스튬 파츠별로 한장의 아틀라스 텍스쳐로 묶여있습니다) 이럴때 코스튬 파츠를 교환할 시 아틀라스 텍스쳐 수십장을 지속적으로 한번에 전부 불러오지 않고 필요할 때만 하나씩 꺼내 쓸 수 있게 최적화를 원합니다.

        팀의 엔지니어는 이 경우에 런타임 리패킹이나 Spine Addressables Extension UPM 패키지를 사용해도 결국 스켈레톤 데이터에서 수십장의 아틀라스 텍스쳐를 모두 다 불러온 다음 하나로 리패킹해야 하는 방식이라 최적화가 어렵다고 말합니다. 내가 공부가 모자라 어떤말이 맞는지 혼동스럽습니다. 런타임 리패킹과 Spine Addressables Extension UPM 패키지가 해결책입니까? 아니면 수십장의 2048x2048 사이즈의 아틀라스 텍스쳐를 관리하는 방법은 근본적으로 없는걸까요?

          bebete I forgot to mention that anyone can create an account and post on this forum. Ideally, it's best if the person with the question posts it themselves whenever possible.

          Even if you have dozens of atlas textures, Spine Addressables Extensions helps reduce loading issues by first loading low-resolution placeholder images. When dealing with multiple atlas textures, file size can quickly add up—for example, if each texture is 1 MB, 100 textures would total 100 MB. With Spine Addressables Extensions, the original 1 MB images are replaced with low-resolution versions, significantly reducing their size (e.g., 16 KB per image), so 100 images would be less than 1.6 MB. It's easy to test, so feel free to give it a try!

          혼선을 줘서 미안합니다 답변을 주는 당신들의 끈기와 노력에 진심으로 감사를 표합니다. 말씀해주신 방법들로 여러 방면으로 다시 시도해서 성공적인 프로젝트가 될 수 있도록 노력해보겠습니다! Misaki와 Harald는 신이야!

          Thanks for your kind words, glad it helped!