bebete As Spinebot answered, you cannot specify the number of textures on each atlas page. Therefore, performing operations based on file names for skeletons whose textures are expected to be added later is not recommended.

If there are a large number of skins, you may want to consider setting them at runtime rather than setting them all in Spine. This eliminates the need to re-export the skeleton each time a skin is added. For details, see the following documentation:
https://esotericsoftware.com/spine-runtime-skins

bebete You can specify the atlas file name, but you cannot specify the page numbers or order. In other words, if you want to pack one page at a time, you can give each page a different name, but if you want to pack multiple pages in a single pack, you cannot specify which page will have the suffix _2 and which page will have the suffix _3.

If you pack each page individually, you will get separate .atlas.txt files for each page.

As you noticed, the format obtained from ChatGPT is invalid. The pack.json file does not have a setting for specifying the name of the atlas file.

Packing via the command line interface (CLI) is essentially the same as packing individually by running the texture packer in the Spine editor. When launching the texture packer individually, you can also specify the atlas name:

bebete If the images for each skeleton are not loaded properly from the atlas file created by launching the texture packer individually, check that the paths in the atlas file match the paths for each skeleton attachment. You may find the following thread helpful:
https://esotericsoftware.com/forum/d/28317-skeleton-data-turns-magenta-when-using-multiple-atlas-assets-in-unity/2

bebete Oh, I didn't realize that the thread I linked to was the one you created. Anyway, I'm glad your issue was resolved! If you have any questions or get stuck in the future, please feel free to ask us.

bebete No, there is no guarantee that the order of the folders will match the order in which the pages are created. Nate's response in the following thread may be a good reference for you:
https://esotericsoftware.com/forum/d/17000-single-image-per-page-atlas/5

bebete 텍스쳐 패커를 사용하여 아틀라스 이미지를 특정해 유니티에서 새로 조합하기 -> 비효율적이며 스파인 파일이 수정될때마다 계속해서 atlas.txt를 수동으로 수정해줘야함
Using TexturePacker to define the atlas image and reassemble it in Unity
→ Inefficient. Every time the Spine file is modified, I have to manually update the atlas.txt file.

I'm not sure I understand your question and use case correctly, but please note that especially if your project is large and complex, it's all the more important to have automated scripts export all your skeleton assets at once. Then copy them over to the respective Unity project directories. If you need any additional steps inside Unity to assign any asset references, this should also be automated via Unity Editor scripting. This should never be inefficient or require tiresome and error-prone manual export steps.

내보내기 -> 이미지 폴더로 출력하면 아틀라스 이미지들이 정확한 규칙에 따라 만들어지는 보장이 없이 생성되기 때문에 유니티에서 매번 스파인 파일을 수정할때마다 기존 이미지들을 특정할 수가 없어 수동으로 다시 재지정해줘야 함
Exporting to an image folder
→ Since there’s no guarantee the atlas images will be generated following a consistent rule, every time I modify the Spine file, Unity can’t identify the existing images, so I have to manually reassign everything.

They are generated with a consistent rule, but the page count and assignment of regions to individual pages of course may vary, unless you create enough subdirectories to ensure there is only one page per subdirectory. The main question is, why is that a problem?

Regarding the part "Unity can’t identify the existing images, so I have to manually reassign everything.": This should never be the case and sounds more like improper workflow setup. All atlas page textures are automatically assigned at materials and materials at AtlasAssets, according to the atlas.txt file. What exactly do you manually assign here?

텍스쳐 패커를 전부 사용한 후 스켈레톤 데이터에 atlas를 추가하여 텍스쳐 패커에서 나온 atlas 파일들을 넣어서 조합 -> 하나의 스켈레톤 데이터에서 계속해서 모든 atlas를 미리 로딩해야하기 때문에 최적화에서 불리함
Using TexturePacker entirely and adding the atlas to the skeleton data
→ This requires preloading all atlases for a single skeleton data file, which is disadvantageous in terms of optimization.

I'm not sure I understand this section. If you want to optimize download size and load times, you primarily have to optimize texture loading. The atlas asset and materials should be negligible in comparison. Delayed on-demand texture loading is provided via the spine-unity Addressables extension UPM package that you mentioned as well. Is there a reason you can't or don't want to use it?

자체제작 툴을 만들어 유니티에서 업로드된 스파인의 아틀라스 텍스쳐들의 이름과 atlas.txt를 자동으로 변환 -> 위에서 서술했듯이 스킨 폴더가 계속해서 추가되었을 때 자체제작 툴이 기존 아틀라스 이미지를 기억하지 못하기 때문에 매번마다 수동으로 재지정 해줘야하고 이는 효율적이지 못하며 라이브 서비스 시에 치명적인 실수로 동작할 수도 있음
Developing a custom tool to automatically convert the atlas texture names and atlas.txt in Unity
→ As mentioned above, if skin folders are continuously added, the tool can’t remember the previous atlas images. This means I have to manually reassign them every time, which is inefficient and can cause critical errors during live service.

I'm not sure I understand the above correctly, but your automation scripts should automatically work in all cases, when any output atlas subfolders to be packed are added, your scripts shall automatically cover that perfectly. If your scripts don't automatically convert and prepare all directories, you should modify your export scripts accordingly. Regarding a live service, it's even more crucial to prepare and upload everything automatically, there should be no manual steps involved, which will otherwise lead to potential errors.

Spine Addressables Extensions을 사용하여 최적화에 큰 도움을 줄 수 있음 하지만 지금 내가 원하는 근본적인 해결책은 아님.
Using Spine Addressables Extensions
→ This can help significantly with optimization, but it’s not the fundamental solution I’m looking for.

The question is what fundamental problem are you trying to solve? And why does on-demand loading of larger assets not help you with that?

결국 내가 원하는것은 출력된 아틀라스 이미지의 이름이 완전히 특정될 수 있는 상황이며 이는 텍스쳐 패커 기능으로 해결되는 듯 했으나 결국 유니티에서 조립할때는 다시 일일히 수동으로 할당해줘야 한다는 결말이 나옵니다.
What I ultimately want is for the output atlas image names to be completely predictable. It seemed like this could be solved using the TexturePacker feature, but in the end, when assembling things in Unity, it still requires manual assignment every time.

There should never be any manual assignment of these assets necessary. If it is required, something is wrong with your setup. Even if you have several separate .atlas.txt files with unknown and varying count, your export scripts and Unity Editor import scripts should be written in a way that they add all AtlasAssets to the SkeletonDataAsset list.

스파인에서 이미지폴더로 출력시에 images폴더 안에 있는 폴더의 이름 순서대로 아틀라스 이미지가 묶여서 출력되는것이 확실할 때 이 모든 문제가 매우 간단하게 해결될 것 같습니다.
If it were guaranteed that when exporting to an image folder, the atlas images would be grouped and exported in the order of the folder names inside the images folder, this entire issue could be resolved very simply.

What do you want to be grouped here, what do you want to rely on here? Why is it important for you and why would the setup not work if it were different each time?

If it's all for automatically loading an AtlasAsset in your game when a skin is assigned, with all associated materials and atlas page textures, you should automatically update your Unity project and automatically update and upload all affected addressable packages. There should be no manual steps involved where you could forget anything or cause subsequent errors.

In generalt however I would recommend just optimizing texture downloading, e.g. via the spine-unity Addressables UPM package, and loading all "empty" AtlasAssets up front, which should not pose any performance issues as such.

@bebete If you have just a single atlas asset and just want to download atlas texture pages on-demand, you should likely be using the Spine Addressables extension UPM package, which does exactly that for you. If you need some database indirection, you could write your own on-demand loading module based on the spine-unity Addressables UPM package, with modifications where necessary.

문제는 스파인에 코스튬을 추가할 때에 스파인 데이터를 작업한 걸 유니티로 옮기면 기존에 여름 복장의 헤어 코스튬의 텍스쳐가 기존의 LB_01.png 라는 보장이 없다는 겁니다.
The problem is:
When new costumes are added to Spine and the data is imported into Unity, there’s no guarantee that the texture for the summer hair costume will still be named LB_01.png.

You could use subfolders with pack.json files and automatically detect when more than a single atlas page is generated (and then issue an error to be fixed by a developer) to ensure it always ends up with the same predictable name. Nevertheless, it's not the best solution and more of a misuse and turning the atlas packing concept on its head.

The clean solution would be to automatically use export scripts and Unity Editor import scripts (and data-base setup and update scripts) which update all your mappings in all places. See the on-demand-loading UPM packages, which manage just that: resolving the required textures when the attachments are needed. You should (1) never have to rely on certain attachments being located in certain atlas pages and (2) analyse and setup attachment-to-atlas-page-texture mappings for downloading automatically via Unity Editor scripts or other automation scripts. That's what I was suggesting in my above reply. If you manually setup any mapping like "this attachment or skin requires that atlas page", you're using an error-prone workflow. Then instead you should be using automated systems which create the mapping correctly for you every time and make sure all assets are in the right places.

@bebete Glad it's helpful. Your summary was almost correct:

대신 자동화된 매핑 시스템을 사용하라.
Instead, use an automated mapping system

Yes, this is correct.

Spine Addressables UPM 패키지로 온디맨드 텍스처 로딩.
Use the Spine Addressables UPM package for on-demand texture loading.

This is recommended, yes. If there is nothing preventing you from using it, it will do everything for you and you don't need any custom solution. So you should not need to analyze anything via scripts. The analysis would only be necessary if you can't use the Spine Addressables UPM package as-is.

Unity Editor 스크립트로 .atlas.txt 분석 → 어태치먼트와 텍스처 매핑 자동화.
Use a Unity Editor script to analyze .atlas.txt → automate attachment-to-texture mapping.

Sorry if this was not clear. I did not mean to directly analyze the .atlas.txt file, instead it should be easier to analyze the result after automatic import. So you can analyze the Atlas object returned from AtlasAssetBase.GetAtlas(). You can access all Atlas objects of a SkeletonDataAsset (usually just one) e.g. via SkeletonDataAsset.atlasAssets. The Atlas object then provides Atlas.Regions.

텍스처 파일 이름이나 순서에 의존하지 않고, 어태치먼트 이름 기준으로 매핑 구조를 구성하라는 조언.
The advice is to build the mapping system based on attachment names, without relying on texture file names or ordering.

If you need a mapping, and for some reason can't use just the Spine Addressables UPM package without additional indirection layers, yes, this is correct.

We're very glad it helped, thanks for your kind words! Have a great day, too!