[Feature Request] Better SpriteAtlas support

GamerXP

I'm looking for ability for Spine to use Unity's regular sprites internally for drawing.
Purpose: memory and draw calls optimization.

We're making a mobile game with isometric view, and it got a huge ton of sprites sorted by camera distance. Each Spine object break batching, adding +2 draw calls. Considering there are quite a lot of such objects - performance hit is quite noticeable.
To optimize it, I thought it may be good to swap spine objects with regular sprites when object is idle. Issue is it will require Spine to use actual Unity's sprites internally. They way SpriteAtlas support currenly is:

Packing ALL spine sprites together with regular sprites into a single SpriteAtlas doesn't seem doable
Packing to SpriteAtlas seems to be generating a new texture out of it instead of actually using the SpriteAtlas. This results source sprites to reference a different texture when drawing with SpriteRenderers, creating a duplicate textures as a result. When using addressables, it can get even worse
Whole SpriteAtlas workflow is very hard to use to begin with.

Having Spine use actual Unity Sprites will simplify a lot of things:

Can just pack them in SpriteAtlases together with other sprites automatically
Better addressables support. Spine won't require to handle addressables manually - can just use normal Unity's workflow for SpriteAtlas late binding. This is possible because referencing a sprite does not force sprite's texture to be include in the build, so you can load it later and bind to the sprite.
Potentially, can attempt to make Spine batch with normal sprites and each other. It will be a huge performance boost in general. Have to look into 2D Animations package - they also got freeform deformations, but batch with regular sprites. Considering package is plain C# - can study it and try making Spine use similar workflow instead of meshes. I considered making a converted from Spine to 2D Animations, but 2D Animations does not support direct vertex animations - only bones.

Original issue on GitHub:
EsotericSoftware/spine-runtimes2589

Harald

GamerXP Each Spine object break batching, adding +2 draw calls. Considering there are quite a lot of such objects - performance hit is quite noticeable.

Is it not possible that the attachments fit on a single Spine atlas texture page in your case? This way everything could be batched properly without adding draw calls per skeleton.

GamerXP Packing ALL spine sprites together with regular sprites into a single SpriteAtlas doesn't seem doable

You could pack your Unity Sprites together with your Spine attachments by using Spine's atlas packer. Or is there any reason why you can't do that?

GamerXP Packing to SpriteAtlas seems to be generating a new texture out of it instead of actually using the SpriteAtlas. This results source sprites to reference a different texture when drawing with SpriteRenderers, creating a duplicate textures as a result. When using addressables, it can get even worse

Yes, that due to Unity's API restrictions, the atlas texture can't be accessed really (at least at the time of initially writing the SpriteAtlas support implementation). If SpriteAtlas would offer a better API, we would happily use it.

GamerXP Whole SpriteAtlas workflow is very hard to use to begin with.

Yes, that's why it's also not recommended at all, and should be the last resort if normal Spine atlas workflow is not possible for some reason.

GamerXP Having Spine use actual Unity Sprites will simplify a lot of things:

Sorry, this won't ever be supported. Anyway, Unity Sprites are nothing more than regions in one or more atlas textures, unfortunately managed by Unity behind the scenes with bad access via their scripting API.

Spinebot

To address your concerns about optimizing memory and draw calls by using Unity's regular sprites internally for drawing in Spine, here are some insights and potential solutions based on the current capabilities and limitations of Spine and Unity integration:

Repacking Atlases: You can repack atlases at runtime to combine multiple textures into a single atlas, which can help reduce draw calls. This is demonstrated in the Spine Examples/Other Examples/Mix and Match and Mix and Match Equip example scenes. This approach can help in reducing the number of draw calls by ensuring that all images are packed into a single shared atlas.
Using Unity's SpriteAtlas: While Spine does support using Unity's SpriteAtlas as an atlas provider, it is generally recommended to use Spine's own texture packing for better performance and fewer issues. However, if you need to use Unity's SpriteAtlas, you can follow the steps outlined in the spine-unity documentation to set it up. Note that this might still result in some performance overhead due to the way Unity handles SpriteAtlases.
Custom AttachmentLoader: If you need more control over how sprites are loaded and used, you can write your own AttachmentLoader and pass it to the SkeletonJson or SkeletonBinary constructors. This allows you to import from any atlas format and potentially integrate more closely with Unity's sprite handling.
Batching and Draw Calls: To improve batching and reduce draw calls, ensure that all your sprites are packed into a single atlas and that dynamic batching requirements are met. This includes keeping the vertex count low and ensuring that materials and textures are shared across sprites.
Addressables and Late Binding: Using Unity's Addressables system can help manage memory and loading times, especially for large projects. By referencing sprites without forcing their textures to be included in the build, you can load and bind them later, which can help optimize memory usage.
Performance Considerations: For mobile games, it's crucial to optimize both memory usage and draw calls. Using a single larger atlas texture shared between multiple skeletons can help. Additionally, consider runtime repacking to combine skins or attachments from multiple atlas textures into a single texture.

For more detailed steps and examples, you can refer to the following resources:

By leveraging these techniques, you can optimize your game's performance while using Spine for animations.

GamerXP

Sorry for later reply. I was sent to other tasks, and back to optimizations only now.

I've tried looking into a way to use SpriteAtlas in more convenient way. Wrote my own atlas class that hold references to sprites themselves, then generate Atlas and materials based on the data of those sprites. It works surprisingly well, but there are few issues:

If sprite is rotated in the original Spine texture - I don't know it from the sprite itself. Have to access original atlas text file to that. Not such a bit issue at least.
Late binding can't be done properly. Disabling DomainReload also makes cache persist, which is an issue since atlases are disabled in editor mode (at least SpriteAtlasV1 we still use).

If texture is null - I can't generate materials and get uvs. I need some way to force reset cache of all users of current atlas asset to regenerate their skeletons after textures are loaded, or make skeleton somehow wait till atlas is ready.
Can it be somehow done without rewriting sources?

Uploaded the experimental atlas class.

spinespriteatlasassetnew.txt

5kB

Harald

GamerXP I've tried looking into a way to use SpriteAtlas in more convenient way. Wrote my own atlas class that hold references to sprites themselves, then generate Atlas and materials based on the data of those sprites. It works surprisingly well, but there are few issues:

Great, glad to hear. Thanks for sharing your code, much appreciated.

GamerXP If texture is null - I can't generate materials and get uvs. I need some way to force reset cache of all users of current atlas asset to regenerate their skeletons after textures are loaded, or make skeleton somehow wait till atlas is ready.
Can it be somehow done without rewriting sources?

I'm not sure I understand what you mean by that. Could you please describe the above in more detail, how and which texture becomes null, and what you want the skeleton to wait for?

GamerXP

Harald
When sprite atlas is marked as addressable - it won't load automatically. You can have direct references to sprites, but they won't have texture and uv data till sprite atlas is loaded and bound.
It's done with SpriteAtlasManager's static events. I've attached one of my scripts that uses them (it won't compile because of some of our internal classes references, but those parts can be safely removed)

sceneatlasloader.txt

11kB

So, I plan on subscribing to SpriteAtlasManager.atlasRegistered method and, when all required sprites have their textures assigned, make spine reload the atlas.