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.
