- Düzenlendi
Unity + multiple texture atlases messed up
Hi,
I'm a noob starting with Spine and Unity so bear with me 
I have a Spine project with multiple skeletons with multiple skins and with multiple animations per skeleton (some FFD). I'm trying to export from Spine (which seems to be working correctly) and importing into Unity (which is not working correctly). I'm using the runtime that is supposed to support FFD found here (https://github.com/pharan/spine-runtimes/tree/unity-ffd).
Here is what the character looks like in Spine:
https://www.dropbox.com/s/32g0pz66qsqia ... -spine.png
The workflow I followed was one I found in a youtube video.
1) I used the "Texture Packer..." option in Spine in order to export the atlases with 1 .atlas file
2) I import the texture files as textures and the .atlas file as a text file.
3) Create materials for each of the 3 texture files and set the shader to Spine/Skeleton
4) Create a Spine Atlas, add the .atlas file and add the 3 materials
5) Create a Spine SkeletonData and bind the atlas asset and skeleton json to it.
6) Add a few animation state data mixes (all animations are visible here)
7) Add a Spine SkeletonAnimation to my scene and set the SkeletonDataAsset.
The Mesh Renderer ends up with 9 materials for some reason (the same 3 for each texture atlas is repeated 3 times).
And here is what it looks like after importing into Unity:
https://www.dropbox.com/s/grmfj2n8mn5jt ... -unity.png
As you can see, it seems to be accessing the wrong parts of the atlas and getting the wrong size somehow. This is what I need help with because I'm at a loss as to why this is happening. When I only have 1 texture atlas, everything seems to work fine.
Help!
/Mark
- Düzenlendi
That runtime is unofficial and it was tested with mutliple atlases but not too thoroughly with a wide variety of situations. Sorry!
But the mesh renderer will always end up with multiple copies of the same material based on the draw order of the images you used and which atlases they pull from.
That's just how it needed to work in Unity because it's a 2D stacking of parts mapped to flat meshes instead of a more traditionally solid, textured 3D mesh that uses depth maps to prevent occluded objects from being drawn when they're drawn later.
If for instance, the draw order causes images to be pulled from atlases in this order:
atlas1, atlas2, atlas1, atlas3, atlas1, atlas1, atlas1, atlas2, atlas3, atlas2, atlas1, atlas2
It'll have 9 materials. 1,2,1,3,1,2,3,2,1,2
An extra copy for each time it swaps.
This also translates to 9 draw calls 'cause they inevitably can't be batched.
Unity docs say you should start worrying if your draw call reaches a few hundred on mobile, or a few thousand on desktop.
But otherwise, it shouldn't be your main concern.
It looks like the parts are quite a bit smaller than what it's supposed to be, too. Are your atlas sizes bigger than 1024x1024? (Unity's default maximum)
Note that if Unity resizes the pngs on import, it'll cause the atlases to incorrectly read the region positions. You should check and see if Unity's not actually resizing your pngs.
Unofficial runtime bugs aside, this info is mentioned here and can be seen in the examples that come with the official runtime:
https://github.com/EsotericSoftware/spi ... nity#notes
Thank you! That was it! I was exporting atlases at 2048x2048 and Unity was resizing them to 1024x1024. I checked the override switch in Unity and everything looked great.
A few hundred draw calls on mobile is ok you say. So then I don't need to worry about that.
But what about the number of textures?
If I now resize them in the Spine export to 1024x1024 to match Unity defaults, how many of those 1024x1024 texture atlases can I have in memory at once?
At the moment I have 3x2048x2048 atlases.
I think 2048x2048 is fine nowadays.
The limit of the number of textures is a function of VRAM and it depends on your target device and how light you want your game to be (eg, do you want your game to run while the user has 5 other heavy apps running?)
Considering sprites need to be uncompressed in memory to look correct, here's the rudimentary calculation:
each pixel holds RGBA.
each channel is 1 byte (holds a value from 0 to 255)
so an RGBA pixel is 4 bytes
(1024 X 1024) pixels X 4 bytes per pixel
4194304 bytes
4.194304 MB
plus some overhead, probably. And it's probably insignificant.
And consider most phones and tablets nowadays have 1GB of shared RAM (most ARM mobile devices have shared memory between CPU and GPU. I have no idea how much goes to system and other apps at any given time. You should probably google that.)
You can probably do the research from here on.
A few hundred draw calls on mobile is ok you say. So then I don't need to worry about that.
That's according to Unity Documentation anyway.
But really, long before 100 draw calls can happen, you can easily be bogging down your game's performance in other areas, like in GPU fillrate and just sheer CPU cycles.
OK - thanks very much for the info! I really appreciate it :-)