Spine (esotericsoftware) model detection + export - #10
Merged
Conversation
Detect Spine models embedded in Unity assets and export the raw Spine files — skeleton (.json/.skel), atlas (.atlas) and texture pages (.png) — into a per-model folder that re-imports into the Spine editor. - UnityRiftUtility/SpineExtractor: shared detector (atlas/skeleton format heuristics + atlas page parsing), collector (groups skeleton+atlas+textures, by explicit SkeletonDataAsset links when available, else by source assets file) and exporter (writes skeleton/atlas verbatim + PNG pages named exactly as the atlas references them). - CLI: new "-m spine" mode (loads TextAssets + Texture2Ds). - GUI: "Export > To Spine (skeleton + atlas + textures)" menu item, added in code (no Designer edits), mirroring the Godot export wiring. - Texture pages are matched by the atlas page name, so it also works when the skeleton/atlas and the texture pages live in different bundles. Tested on a real IL2CPP WebGL sample (samurai_oni): 1 model, 7 atlas pages, a valid Spine 4.3 skeleton + atlas + 7 PNGs. Co-Authored-By: Clue Opus 4.8 <noreply@anthropic.com>
Expose the new "-m spine" mode as an MCP tool (mirrors godot_export): detect and export Spine models (skeleton + atlas + texture pages) to a per-model folder. Notes that pages may live in a separate bundle, so pass a folder containing both. Co-Authored-By: Clue Opus 4.8 <noreply@anthropic.com>
Read spine-unity SkeletonDataAsset/AtlasAsset MonoBehaviours to recover the authoritative skeleton -> atlas grouping, following the Cubism ToType/PPtr pattern: skeletonJSON + atlasAssets[].atlasFile resolve to the skeleton and atlas TextAssets. Fields are read from the serialized type tree when present, else from loaded/generated assemblies; when neither is available (IL2CPP with stripped type trees and no assemblies) it returns nothing and the format heuristics take over. Both frontends now gather MonoBehaviours and pass the links to SpineCollector; the CLI spine mode loads MonoBehaviour too. Verified on the IL2CPP WebGL sample: the MonoBehaviour path can't read the stripped SkeletonDataAsset there, so it falls back to the heuristic with identical, correct output (skeleton + atlas + 7 pages). Co-Authored-By: Clue Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds detection and export of Spine 2D skeletal models embedded in Unity assets. Since Spine format can't be synthesized from arbitrary Unity data, "export" means reassembling the original embedded Spine files into a per-model folder that re-imports into the Spine editor:
<model>.jsonor<model>.skel— the skeleton<model>.atlas— the atlas (verbatim).pngper atlas page, named exactly as the atlas references itDetection (hybrid)
size:/filter:/format:page headers; JSON skeletons by the{"skeleton":…,"bones"/"slots"}shape; binary skeletons by.skel[.bytes]name. Texture pages are matched toTexture2Ds by the page name in the atlas.SkeletonDataAssetlinks when a frontend can supply them (the collector accepts them), and otherwise groups skeleton+atlas by source assets file. Because pages are matched by atlas page-name, it also works when the skeleton/atlas and the textures live in different bundles.Surfaces
-m spine(loads TextAssets + Texture2Ds), e.g.UnityRiftCLI <input> -m spine -o out.UnityRiftUtility/SpineExtractor(SpineDetector,SpineCollector,SpineExporter,SpineModel).Tested
Verified end-to-end on a real IL2CPP WebGL sample (
samurai_oni, itch.io 2D character customization). The skeleton/atlas were indata.unity3dand the 7 texture pages in a separate addressables bundle; loading both,-m spineproduced a valid Spine 4.3samurai_oni.json+samurai_oni.atlas+ 7 valid PNG pages, all resolved (no missing-texture warnings).net9 CLI + GUI build clean; CI validates net472/net8/net9.
Follow-up
The collector already accepts explicit
SkeletonDataAsset/AtlasAssetMonoBehaviour links, but the frontends currently feed only the heuristic path (the sample is IL2CPP with stripped MonoBehaviour typetrees, so those fields aren't readable there). Wiring the MonoBehaviour-field grouping for Mono games / loaded assemblies is a clean next step against a suitable sample.