• Runtimes

  • SkeletonAnimation and 2K2D Sprite Collection not batching

    англійська
Related Discussions
...

I'm just not sure if I already know what there is to know to solve this problem, but there's just too many scaling factors involved here.

We've been working on our project for quite a while now, so this is what we had:

  • huge PNG files on which the spine bone setups and animations are based on
  • texture atlases, one per animation (didn't get how to combine PNGs of different animations into one atlas)
  • spine unity to handle the skeletondata

what we have now:

  • 2D Toolkit Sprite Collections (4 in total), holding all PNGs "as PNGs" for 30+ animations.
  • spine tk2d to handle the skeletondata so it corresponds with the sprite collections.

Now the actual scaling problem:
Since we went from spine atlases to tk2d sprite collections we scaled all PNGs down to fit. Looks horrible in the spine editor, but we figured that it didn't matter in Unity anymore. Since there were a lot of PNGs with different relative scales to each other, several bones in the animations are differently scaled to account for that.

In short:
(Unity)

  • the game objects all have a scale of 1
  • the skeleton datas have scales that fit their former "overscale" due to the oversized pngs
  • there's a total of 4 materials renderering all animations with tk2ds BlendedVertexColor Shader
    (spine)
    -the animations have different scales, bone and texture wise
  • the PNGs are shrunk to a pixel perfect version for the final game build

Which part is it that renders the animations un-batchable? Does every spine animation need to have a scale of 1 throughout it's setup?

If this was somehow practically solvable, it would be the perfect setup, but for any advice on mistakes that should be avoided in the future I'm also I greatly appreciate.

Additional Test: I deactivated everything in the scene and activated the gameobjects one by one. Up to game object 5 they were perfectly batching (1 call, 4 batch). with object 6 activated (referenced another atlas) I had 3 draw calls with 4 batches instead of the expected 2 draw calls with 5 batches.
How can I loose batches? There's only 2 materials involved.
Or is that a Unity problem? Or 2D Toolkit?

  • Nate

  • Допис #3
  • Цей допис на англійська

Lots of questions here. 🙂

alex.seeck написав

texture atlases, one per animation (didn't get how to combine PNGs of different animations into one atlas)

http://esotericsoftware.com/spine-textu ... er#Packing

Generally, scaling doesn't affect batching. The number of textures you draw from does, as well as using additive blending. If you draw a skeleton from multiple textures, batching gets wrecked. Moving to TK2D atlases doesn't solve any batching problems, it only enables use of a TK2D atlas and other TK2D features, eg for the camera.

The size you use in Spine does not have to be the size you use at runtime:
http://esotericsoftware.com/spine-using ... s/#Scaling

Unity does have some weird rules to obey if you want dynamic batching to work.
I don't know enough about TK2D to tell what part of it might be breaking batching, but your setup does sound ok.

I think it does boil down to you having four materials/four sprite collections. Unless TK2D has some sorcery behind it that allows this to be batched, it seems like it inherently can't be batched.

The "scaling problem" seems like a separate issue.
Skeleton JSONs aren't supposed to care what resolution the atlases are. It should just work as long as the atlas data correctly describes how the images were scaled (I think?). But I have seen UV-mapping and FFD stuff break before from scaling, not sure if it was on the skeleton side or the atlas side.
But I think that was fixed at some point, and then broke again at some point then got fixed again. I'm not sure where it is now.

But the ideal is that you can export a json, then swap around different resolution atlases and it should work just fine. I actually tried this before and it worked. Again, I'm not sure how the atlasing works on the TK2D side so whatever adjustments have to be made are probably related to how the TK2D atlasing/runtime works.

Kinda unrelated info that might be helpful:
Scaling the Transforms of GameObjects was definitely was an issue, but they made uniform scaling of SpriteRenderers not break batching. They hinted at doing the same for MeshRenderers (which Spine-Unity relies on) but I actually don't know if they've managed to do that already.

Scaling the assets should have no effect on batching though. That's an import operation and not something that's calculated at runtime. Batching will break if you're pulling from different textures.

Additive blending thankfully doesn't break batching with Spine-Unity as long as you're using the Spine\Skeleton shader or any premultiplied alpha shader.

Thank you all for your time and extensive explanations. I just wanted to let you know that I found the problem. Our scene makes extensive use of the layering system (didn't think about that yesterday). Animations and backgrounds alternate quite a lot. So every time something needs to be drawn in between draws of a different atlas, a new draw call gets issued.
This means I need to resort everything back to front and pack things as close to their sorting order as possible.

Thanks guys.