• Editor
  • Different output scale for each skeleton when exporting with single atlas

I have many different spine skeletons for a game. All of them are exported into their own atlases with power of two dimensions. This results in the atlas having some empty spaces. And each of these skeletons are exported with a different output scale since each of their source images come in varied sizes. Let's say I want to optimize the game and reduce total atlas area and size. I would need to merge all of these skeletons into a single spine file and export all the skeletons together with a single atlas. In this case I would have to choose a single output scale in the current export settings. I want to be able to have the option to assign a different output scale per each skeleton when exporting multiple skeletons into a single atlas. Is it possible to add this into export settings?

Related Discussions
...

You are not required to export the atlas and skeletons at the same time. To do what you want, export them separately:
http://esotericsoftware.com/spine-texture-packer

I couldn't find in the link you sent any explanation about merging the atlases of multiple skeletons while maintining each of their own output scale multiplier , nor did I find any settings about this in the texture packer.

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

    bogacoydemir Sorry for the confusion. When running the texture packer separately, input is a folder. So if you have separate image folders for each skeleton, you can run the texture packer separately to pack the textures for each image folder at a specific scale setting.

    However, the atlas format does not anticipate the case where images packed at different scales are mixed in the same atlas, so it should not be possible to fully achieve what you want to do with only the texture packer. If you want to change the texture image scale for each skeleton, it would be ideal to be able to adjust it at the time of exporting from an image editor such as Photoshop.

    Ah, sorry I gave a kneejerk reaction. The number of times people need to be told that... 🫣

    It's somewhat unusual to want to pack images for multiple skeletons and scale the images differently. Often when an atlas contains images for multiple skeletons, the skeletons share some of the images.

    The texture packer only scales the entire atlas. I suggest normalizing the scale of your images across all your skeletons. You can do this by exporting to JSON (check Nonessential), then importing that back into Spine and specifying a scale:
    http://esotericsoftware.com/spine-import#Scale

    If you must, you can combine the .atlas files by simply concatenating the files (via a command line or copy/paste). This will give you an atlas with all the pages, but won't mix the images within the pages. The only way to do that is to have your images with the same scale.

    Thank you both for your responses. In my case, I've been working on a game project for almost 2 years and I have created a lot of spine animations for a lot of game assets. And the source images of these assets are always created in a much higher resolution than how big they are supposed to be seen on the screen. So I work with large images inside Spine, and scale these images to sizes close to how big they are supposed to be in game by entering a multiplier number in the texture packer settings for each asset. And the resolutions of the created assets are usually disproportionate with each other. So the assets come in to correct resolution during the export json process. So currently there are dozens of spine skeletons in the project with atlases created with various different output scale multipliers. If I want to import, let's say 5 of the spine skeletons into 1 spine file and export all 5 skeletons with a single atlas, output scale of all 5 skeletons' source images will be multiplied by a single number, and the images in the atlas that belong to different skeletons are going to be disproportionate with each other. Now, I can manually resize all the source images of all the assets in the game to the point where they are all proportionate with each other as you suggested. But this would take so much time and effort. That's why I thought it would be great if, when importing a project into another spine file, Spine could also import the output scale value of the imported project. So, when exporting multiple skeletons with a single atlas, we could use the imported output scale multiplier for each skeleton, or have the option to assign a different value for each skeleton's output scale multiplier. A simple automated calculation made by Spine could save hours of manual work. Thank you for reading 😃

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

      bogacoydemir the source images of these assets are always created in a much higher resolution than how big they are supposed to be seen on the screen. So I work with large images inside Spine

      You can work in Spine using images at a size different from what will be used at runtime (smaller or larger). You don't have to work using the 100% size of the art. It can be uncomfortable to work with extremely large images in Spine, though the Bone scale setting helps a little. When packing the images for use at runtime into the same atlas, that is when you need the images to have the same relative scale across skeletons.

      If I want to import, let's say 5 of the spine skeletons into 1 spine file

      Note while you can have multiple skeletons in one Spine project file, you don't have to. They can be in separate files and still share an atlas at runtime.

      bogacoydemir I can manually resize all the source images of all the assets in the game to the point where they are all proportionate with each other as you suggested. But this would take so much time and effort.

      Have you been using the PhotoshopToSpine script the entire time? If so you can run the script for each project, setting the different scale for each. This gives you the images at the correct size across all skeletons. Next you could pack them without changing your Spine projects, specifying the different scales when you load the skeleton data at runtime. Otherwise you'd need to export your projects to JSON and import them again to normalize the scale across your projects. You can do that from the command line:
      http://esotericsoftware.com/spine-command-line-interface#Import

      Doing that would take some effort, but it might not be as bad as it seems if done carefully and at least it's a one-time pain.

      bogacoydemir That's why I thought it would be great if, when importing a project into another spine file, Spine could also import the output scale value of the imported project.

      It's the Spine texture packer that would need a way to specify scale differently for various groups of images. Images are grouped using folders and per folder settings are specified using a pack.json file. I hesitate to add scale to the pack.json settings for a few reasons:

      • Foremost, this isn't a desirable organization approach because skeletons using the same atlas can't reasonably share images that have different scales. It would be better to do the work to normalize your image sizes across Spine projects.
      • Scale has always been intended to be used for the whole atlas, typically to provide the same images at different resolutions, depending on the user's screen resolution. Making scale per folder probably has some ramifications for how the texture packer performs it's work. It is unlikely to be the simple change it may seem.
      • Lastly, the scale is output in the data for each atlas page, but this would no longer make sense if images in the same atlas page can have different scale.

      To avoid normalizing your image scale across skeletons, maybe you could continue to use separate atlases? Are you having an actual problem with draw calls or GPU memory that combining images on the same atlas pages would solve? Blank space in image files contributes very little to the image file size because the image format is compressed. At runtime the image files are often loaded into memory uncompressed and that uses more GPU memory. Do you have a real need to use power of two textures? If not, that could save some GPU memory.