• RuntimesUnity
  • Spine Atlas - Unity

Hello,
I have a question about how atlases work in Unity (I'm talking about the spine atlas of course).

To sum up:
Does SkeletonData read all the atlases in memory no matter how many it needs, or does it only read the atlases it needs?
(If 1 body atlas and 20 garment atlases, does it read 1 body atlas and 1 garment atlas, or all atlases?)

Does SkeletonData read the full atlas, even if he need only some part of the atlas ?
(The atlas use material, so does all materials are loaded, or only material with used piece inside)

And here's the full version, enjoy 🍻 :
And on an atlas, does it load all the images, or just the images it needs? (If it has 14 images, but the parts it needs are on images 1,2,4,7,8 and 9, does it load them all?)
I used to create atlases with the standard Spine exporter, creating a single atlas of more or less 30 MB. Having said that, I know that the weight of the image in the game is not the same as the weight on Windows. This created 12 images with a single .atlas.txt (because Unity uses .atlas too, so you changed it to .atlas.txt).

If my research is correct, during the Spine animation, all atlases were loaded into memory at the same time. Even if you were to use only part of images 1, 5 and 7, the whole atlas was loaded.

The problem is that the garments take up a lot of space and aren't all needed at the same time, so I started thinking "Maybe I should create an atlas for each garment".
This is a bit tedious to do, so I used "GDX Texture Packer" to do it and created 24 different atlases. 1 for the body, variation included (I could divide it into each body variation but I'm sure it's not worth it for the few different body parts...).

The thing is, I tried to see if there were any differences in my game using separate atlases or single atlases, but I couldn't see them.
At the moment I "only" have 20 different garments, but later I'll have more and more, and it's easier to add them to the atlas one by one than to wait until there are more than 80 garments to think "Maybe I should add an atlas".

  • Nate ответили на это сообщение.
    Related Discussions
    ...

    While doing some more research, I found out that putting a pack.json file in the folder would have be simplier than using another program. My bad. The result is not totally the same tough, as it create a single atlas with more picture, as he is separating things by their folder. So more picture, less atlas. But if the atlas read only picture he need it's better ? I'm lost 😭

    But the question stay mostly the same, it created separate picture for clothes under the same atlas, but is the atlas loading all materials in memory even those who are not used ?

    If not, does making separate atlas, used by the same SkeletonData, is better ?

    Pentacles Does SkeletonData read all the atlases in memory no matter how many it needs, or does it only read the atlases it needs?

    SkeletonData is decoupled from texture atlases. See the class diagram:
    https://esotericsoftware.com/spine-runtime-architecture#Class-diagram

    Don't be afraid to jump into the spine-csharp source code. It's pretty straightforward, being a generic runtime. spine-unity adds the rendering layer and Unity stuff, so is a little harder to follow along, but it's doable.

    Pentacles on an atlas, does it load all the images, or just the images it needs?

    An atlas doesn't know anything about skeleton data, so there is no notion of what is "needed". Besides, a single atlas could be used for multiple skeletons, or even for non-Spine rendering.

    An atlas has 1 or more images and by default all are loaded. You can customize this using a TextureLoader, see:
    https://esotericsoftware.com/spine-loading-skeleton-data#Texture-atlas
    You could write a TextureLoader that doesn't load the images, then later load them as needed.

    When SkeletonData is loaded, by default atlas regions are found in an atlas and set on region and mesh attachments. You can customize this using an AttachmentLoader, see:
    https://esotericsoftware.com/spine-loading-skeleton-data#JSON-and-binary-data

    The rendererObject on the atlas page and attachments is set to whatever will be rendering the skeleton expects. You could write an AttachmentLoader that does not set the rendererObject, then later (before rendering) set it only for the attachments actually in use (eg based on a character's equipped items).

    The problem is that the garments take up a lot of space and aren't all needed at the same time

    First I would question if it matters. Only if you cannot load all the images at once would I go for a more complex situation.

    I used "GDX Texture Packer" to do it and created 24 different atlases. 1 for the body, variation included

    That's one way to do it. It will use up more disk space if you are duplicating images on multiple atlases. You can also pack images at runtime, see here and the examples it mentions:
    http://esotericsoftware.com/spine-unity#Combining-Skins

    I tried to see if there were any differences in my game using separate atlases or single atlases, but I couldn't see them.

    Look at what images are loaded, or how much GPU memory is used. Also look at how many draw calls you are using. If you have many atlas page images, packing only the used regions into a single atlas can reduce draw calls, improving batching, and use less GPU memory, see:
    https://esotericsoftware.com/spine-metrics#Draw-calls

    I found out that putting a pack.json file in the folder would have be simplier than using another program.

    We are the authors/owners of libgdx and Spine is written using libgdx. Spine's packer is similar to the libgdx texture packer, it does everything the libgdx packer can do plus a few features, namely 1) polygon packing, and 2) knowledge of the meshes in a Spine project for whitespace stripping and polygon packing. Both support pack.json files. There's no reason to use the libgdx packer. When using the Spine packer from the CLI with meshes use -j / --project, see:
    http://esotericsoftware.com/spine-command-line-interface#Pack

    • Pentacles ответили на это сообщение.

      Nate
      I'm affraid that's just too much for me to look at.
      We are a team of two but I'm the one doing the animation and programming while she does the drawming, so we're a pretty short team.

      I'm not sure if I've understood everything clearly, this is clearly out of my comfort zone ^^', but seeing how it appear in the memory profiler, using multiple atlas doesn't change the fact that everything is loaded at once, even unneeded atlas.
      If I want to load only the required atlas and let the other out of memory, I've got to manage it "myself" by creating a TextureLoader ?
      Definitly not worth the bother for now, I just wanted to see if I could upgrade that aspect.
      I tried combining skins before but I failed to make it work but I'm gonna look at it a little more. But it cost to do a repack so I'll probably do it only for some scene that doesn't change a lot.

      Thank for the answers ! Didn't think you or anybody else would answer on week-end

      • Misaki ответили на это сообщение.

        Pentacles I just wanted to let you know that the implementation of delayed on-demand loading of atlas assets is already underway. Here is the issue ticket:
        EsotericSoftware/spine-runtimes1890

        7 дней спустя

        @Pentacles Sorry for the late reply, I have just returned from vacation. Please note that the implementation in the issue ticket is already available as experimental packages. See this ticket comment:
        EsotericSoftware/spine-runtimes1890

        So there is no need for you to implement your own loader if you just want to load (previously exported) atlas textures on demand at runtime.

        If you are encountering any problems using the experimental on-demand-loading packages, please don't hesitate to let us know. We're happy to improve the packages wherever possible.