• Unity
  • Uneven pixel density and atlas optimizations.

Long one, grab some a drink of choice. Trying to figure out a best practice for artists that is not too complex and also does some basic amount of reasonable optimization for the atlas. Problem space:

Working art - PSD where the artist creates
Spine Source Art - PSD with flattened working art images ready for spine
Spine export - PNG atlas

We often have working art delivered as source art that are the original size (maybe 2x sometimes 4x the target size.) The spine animator has two options, option A) work at the original size and it happens to fit within the maximum spine canvas. Option B) scale the source art down 2 or 4x and animate at a smaller scale. Option C) ?

Now add in effect images like glows, sparkles, glints, shines to the mix. Those are often created at the original working size too, however they take up so much pixel room that could ideally be given to the actual art that is seen 90% of the time. A trick I'd like to use is scale the effect down by 50, 75, or even 90% in some cases since they aren't on the screen very long we can kinda "get away with it." This however is a bit of work on my part to rescale the attachment and or mesh back to the needed original desired size (but at a lower resolution) in the spine project after the animator has worked with it.

But if I do that (technical artist) and then later the art needs to update or a polish pass happens, they don't know how much I reduced their effect texture down by. If I told them, then they'd have this really tiny layer that doesn't do them much good in context of their working file but does give more pixel density to the best parts of their art and helps reduce atlas size overall.
When they reexport their new changes now the spin source art is back at the original working size and I need to go back through and resize the effects and less important art again.

I don't doubt I'm missing something simple here or over thinking it. It's almost as if I'd want to be able to set a scale per image in the spine texture export settings. Some manifest that lists all exporting textures and a scale value next to each one.

Should artists deliver their working art at it's working size for spine or reduce their work before hand to be more inline with the target resolution and reduce their effects even smaller still? Should a middle-person do this and deal with resizing churn? How does this all play in if we want to release 4k textures later, then all the mesh/attachment slots will need readjusting again.

Thanks for any insights anyone has.

Related Discussions
...

Hi,

If I understand correctly, when you first prepare the image resources, it may be helpful to export them using the [scale:number] tag available in PhotoshopToSpine.

[scale:number] Layers are scaled. Their attachments are scaled inversely, so they appear the same size in Spine.

https://github.com/EsotericSoftware/spine-scripts/tree/master/photoshop#tags

It's a lot of work to import an image at a large size and scale it in Spine editor.
By using [scale:number], the texture will be scaled down when exported from Photoshop, but it will be scaled up in Spine to keep the same look.

I hope this will help you.

Oh awesome! I think that's yet another good reason to get our artists using the spine photoshop export tool and tagging syntax.

Thank you for the suggestion Misaki!

I’m happy to hear that! Thanks for getting back to me 🙂

un año más tarde

Hello, may i ask whats the difference for using [scale:number] instead scaling down manually from psd ?

    Bebekkun Sometime you want to keep things the original size in the psd and have a reduced size when used in spine to keep the export small (like within 1024x1024). e.g. large shadow or light layers.

    Bebekkun The scale number will be stored in the exported JSON, so when it is imported into Spine, the scale of the image is automatically modified based on it. For example, an image exported with [scale:0.5] will have X/Y scale values of 2 after being imported into Spine.