Struggling with Runtime Hot-Updates for Spine Skins in Unity

javadrah

This is AI generated question:
I'm currently optimizing a Unity project that needs to render a large number of Spine characters (testing with 150-500), and I've hit a solid wall trying to implement a hot-update system for character skins at runtime. I'm hoping someone here can point me in the right direction or correct my approach.

What I've Achieved (for context):

Optimized rendering significantly. By using SpineCharacterRandomizer and calling OptimizeSkin(), I can render each character with exactly 1 draw call, regardless of texture complexity. The massive FPS boost is great.

I've also gained ₁₅-20 FPS by aggressively reducing bones/vertices/keyframes in the editor and enabling USE_FAST_SIN_COS_ATAN2_APPROXIMATIONS in MathUtils.cs.

The Core Obstacle: Runtime Hot-Updating
The project requires downloading new skins (textures/SkeletonData) from a server post-launch without rebuilding the app. I've tried two approaches, both of which failed. I need to understand why these fail fundamentally, and what the correct architecture is.

Attempt 1: Raw Texture Load & Material Swap
My idea was simple: load a raw texture at runtime, create a new Material, and inject it into an existing skin's attachment.

Exported a base character (skeleton + animations) from the Spine Editor.

At runtime, loaded a new .png texture from disk/server.

Created a material with the Spine/Skeleton shader and the new texture.

Attempted to find the correct slot/attachment (e.g., RegionAttachment) and set its renderer to the new material/texture.

Result: Failed. The mesh didn't update correctly, or the new texture was placed in the wrong position. It felt like I was missing a crucial step in rebuilding or re-mapping the attachment's UV coordinates or mesh bounds. Is this approach even viable, or is the entire Skeleton/Skin structure too baked-in for this?

Attempt 2: Two-Export Base & Skin Swap (Based on an AI's Suggestion)
This was suggested as a workaround, which I tested but couldn't get working:

Export A: A base character (no skin textures, just skeleton + animations).

Export B: A separate export containing only the skin attachments (no animation).

At runtime, load both. Apply the Skin from Export B onto the Skeleton from Export A using something like skeleton.SetSkin().

Result: This failed. The skeleton and animations worked, but the skin from the second file never correctly attached. My assumption is that the internal indices for slots/attachments between the two exports didn't match, causing the skin to silently fail. Is there a correct procedure for "grafting" a skin from one export onto a fresh skeleton from another? Can this be done at runtime without merging them in the editor?

The Central Question:
With my current experience, am I missing a fundamental rule about the Spine-Unity runtime? Is there a proven, documented workflow for loading a complete new character structure (skeleton + skin) or just a skin sheet from an AssetBundle or raw files at runtime? Any code snippets, high-level architecture advice, or a definitive "stop, you're doing it wrong" would be incredibly valuable.

Thank you for your time and expertise. I'm happy to share my current code implementation of the failed attempts if it helps diagnose the issue.

Nate

Harald can give better spine-unity advice and point you to the right examples (we have examples, don't miss them!), but at a high level:

You can make this as complex or as simple as needed. Go through the examples. Decide what functionality you actually need and look at how much complexity various solutions have.

Don't try to split up skeleton data, it's not large enough to matter. Texture atlas/images are completely separate from skeleton data.

It's simpler if you don't try to update your skeleton dynamically. If you don't need to add animations, etc and just want to add attachments, it's easier. Using different images with the same skeleton data is simpler.

One approach is to treat the skeleton like a doll. You attachment template images in the Spine editor, each using the largest image size that any of the replacement images will be. That allows you to position the art anywhere within that size, so you don't need to reposition each individual image, you just need to replace the image. At runtime you replace all those images to change the look. This allows you to keep the skeleton data the same and use any amount of new art (eg downloaded as needed).

Harald

@javadrah For performance gains, it's highly recommended to switch to spine-unity 4.3-beta (which will soon be out of beta) and use it's threaded animation and mesh generation features.

Regarding downloading textures or skins at runtime:
The recommended workflow is using the provided On-Demand loading UPM package, which provides support for Addressables out of the box. See the documentation here:
https://esotericsoftware.com/spine-unity-on-demand-loading
It allows you to easily replace any material textures with low-res placeholders and downloads and hooks-up the high-res textures at runtime on demand.

Now if your requirement is that the atlas and materials are also not known when building your executable, you could still use Adressables or Asset Bundles. You could then export multiple atlas assets from the same Spine project and download only what you need at runtime. Typically you would then export your atlas assets packed by folder structure and pack via export scripts and the Spine Command Line Interface.

Regarding your failed approaches: In general you can do a lot of things and get it working, but it's hard to debug your issue if you just share prose text describing your code. It would be much better if you would at least share code of the respective sections, or better send us a minimal Unity project which shows your failed attempt in full (but please no AI created code or workarounds). You can send us a zip file to contact@esotericsoftware.com, briefly mentioning this forum thread.

And please note that AI will unlikley write useful code for you in this regard, it will likely create more broken code.

In general please be sure you've read the documentation before attempting more complex things than what is shown in the Spine Example scenes:
https://esotericsoftware.com/spine-unity-main-components#Setting-Skins
https://esotericsoftware.com/spine-unity-rendering#Rendering