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.
