- Uređeno
Workflow: Should I be animating with high res source art?
I've been Spine on my project for well over a year now, and I think I've been using a workflow that "works", but is not necessarily the best thing I should be doing. In the past this has been the workflow:
1) Create high resolution art in photoshop using layers
2) Export game/low resolution .PNG files of all layers
3) Animate using game/low resolution .png files
4) Export animation data and packed texture
5) Adjust scale of character in Unity runtime via the Spine "Skeleton" component "Scale" field (same component that lets you set mix times etc) to be correct for the game.
However, I just discovered the "Scale" settings in the Spine Editor for the packed texture ... and you can even export multiple scales at the same time. So really, since I have high resolution artwork ... I should always animate using the high res artwork incase I ever need to export larger than my normal game/low resolution images such as for a website, promo video, or even decide to up-res the game?
Besides any performance considerations of having to animate using high resolution art ... is there a reason to not animate using the high resolution art since I have it?
nope, its what we do. We have export scales of up to 0.009
I work with images which are the highest determined possible resolution for target devices. For example, one of our target devices might be the newest or upcoming iPad. It will handle high resolution assets. But most of our target devices are mid-end. For those we scale down the atlases with Texture Packer.
Our producer is big on high resolution, so the assets I work with are big enough to make the Spine editor occasionally lag. For example, an image can be as large as 800800. Which at full scale for mobile devices is, I think, overkill. But some, the ones I try to make, might be really small. But not smaller than 44 px, because when downsized 4 times for lower-end devices the pixels will disappear.
When I think about it, I wouldn't want to work in Spine with actual image sizes. When I tried to do that when doing animation for a video, the computer and Spine lagged horrendously. Doesn't it lag for you?
And how well do small scales as 0.009 work out in these optimisation cases: say an image of a building is cut diagonally and rotated in Spine. They are placed so that the pixels are touching and not overlapping. If I scale down 0.009, might it start showing a tear in that spot? Well, probably one could simply overlap images... Example below:
Spine should not lag from large or many images. If it does, likely your graphics hardware is lacking.
There's no reason to work in Spine at a particular size. The Spine animation data can be applied to images of any size, smaller or larger. Use the size of images in Spine that is easy for you. It is often convenient to use one of the image sizes you will actually use in your game, but this is not a requirement.
colinday wroteHowever, I just discovered the "Scale" settings in the Spine Editor for the packed texture ... and you can even export multiple scales at the same time. So really, since I have high resolution artwork ... I should always animate using the high res artwork incase I ever need to export larger than my normal game/low resolution images such as for a website, promo video, or even decide to up-res the game?
The Spine animation data is separate from the images that are used. At runtime you can scale the data for use with larger or smaller images than were used in Spine. If you want to use higher resolution images than you used in Spine, run the texture packer separately from the animation data export to create an atlas that has larger images. The animation data export has a Create atlas
checkbox, but this is only for convenience, since it is very common. You can also run the texture packer on any images you want. Eg, you can work in Spine at 25% resolution, export the animation data, then run the texture packer on your largest, 100% size images and have it export them as atlases at 100%, 75%, 50%, 25%, and 10% size. At runtime you scale the data based on which atlas you are using. Eg, when using the 75% atlas you would use a scale of atlasScale / spineScale = runtimeScale
which is 75 / 25 = 3
. For the 10% atlas you'd use 10 / 25 = 0.4
.