re-polish helps game teams optimize Spine skeleton exports in JSON and binary .skel formats with predictable quality. This FAQ covers size reduction, curve cleanup, conversion, atlas and texture workflows.
Last updated: 2026-04-18
Reduce redundant keys, simplify curves with an error tolerance, and remove unused entities before release exports. This keeps visual motion stable while lowering payload size for runtime loading. JSON / .skel
JSON is human-readable and stores verbose text structures, so it is usually heavier than binary .skel. The tradeoff is easier inspection, diffing, and pipeline automation.
Dense key distributions, complex curve data, and oversized bone/slot structures are common drivers. Quick wins usually come from cleaning extra keys and removing unused entities before final builds.
Yes. Smaller payloads usually mean faster transfer, parse time, and lower memory pressure. This is most noticeable on mobile and web scenes with many skeletons.
Yes. It accepts Spine JSON and binary .skel skeleton exports and keeps the source format available through Auto export.
Yes. Auto output preserves the format of each source item; explicit JSON or SKEL output selects a target format.
Yes. The conversion workflow supports JSON to binary .skel and binary .skel to JSON when the selected Spine version is supported.
Yes. Project workflows can process skeleton files together with .atlas and texture assets such as .png and .jpg/.jpeg.
The supported Spine versions are 3.7, 3.8, 4.0, 4.1, and 4.2.
JSON is text and binary .skel is serialized differently, so size changes are measured on the actual output artifact and can differ.
Safety depends on thresholds and track type. Typical transforms are usually safe with correct tolerances, while sharp accents, VFX, and stylized motion need conservative settings and selective exclusions.
Avoid aggressive simplification for micro-motion, handcrafted style cues, and strict sync with audio or gameplay triggers. In those tracks, use softer thresholds or disable optimization.
After baking, animation often contains noisy step-like keys. Cleanup reconstructs smoother compact curves within tolerance, which reduces file size and keeps data easier to maintain.
Compare before/after on control clips: fast turns, extremes, loop seams, and VFX-heavy segments. Use a checklist for key poses, seam smoothness, jitter absence, and trigger timing.
Baking converts simulation output into deterministic keys. This improves playback predictability, helps stable loops, and reduces dependence on runtime physics-constraint support.
Baking may produce very dense key sequences. A second pass (key cleanup plus curve approximation) is needed to recover compact size while preserving visual behavior.
In most cases yes, if final JSON contains standard animation keys without runtime-specific physics data. Always verify critical clips in your target runtime version before release.
Align start/end poses and control the transition window around the seam. Post-bake smoothing near the boundary helps remove spikes while keeping event timing stable.
Yes. Use the upgrade → bake → downgrade pipeline: the Set Spine Version node upgrades your JSON to 4.2, the Add Physics Constraints node attaches physics to selected bones, the Bake Physics node converts simulations into standard keyframes, and a final Set Spine Version pass downgrades back to your target version. The result is a regular animation file with no physics dependencies, compatible with older runtimes. This lets you leverage Spine 4.2 physics as a fast motion-authoring tool even if your project ships on an earlier runtime.
Manual cleanup gives maximum control but does not scale well. Automation provides consistency, repeatability, and speed, with manual review reserved for sensitive cinematic tracks.
Track JSON size, parse time, peak memory at load, and visual diffs on control clips. These metrics provide practical evidence for both technical and production stakeholders.
For full-project workflows, use Project Input, Project Viewer, and Deduplicator together. This pipeline helps you load the entire project, quickly find bottlenecks, and remove duplicate assets.
Project Input loads a full project folder or archive into the graph instead of a single file. That gives downstream nodes access to JSON, atlas data, textures, and project structure in one batch-ready context.
Project Viewer helps you inspect the project before making changes and spot the heaviest JSON files, atlas pages, and texture assets. This makes it easier to focus optimization work on real bottlenecks instead of guessing.
Deduplicator finds identical or near-identical sprites across the project, keeps a canonical unique version, and remaps references to it. This reduces duplicate atlas content, lowers asset waste, and simplifies downstream export or repack steps.
Static Bake turns selected animation frames into generated PNG sprites and static symbols. This is useful in iGaming pipelines where teams need stable, predictable, runtime-light assets for reels, UI elements, and promo scenes.
It gives teams one repeatable workflow for loading, analyzing, and cleaning whole projects instead of processing files one by one. That saves time, reduces the chance of missing heavy or duplicated assets, and makes release preparation more predictable.
The core risk is over-compression on style-critical tracks. Keep conservative defaults, maintain per-track overrides, and run targeted QA checks on scenes with strict timing.
