re-polish helps game teams optimize Spine JSON exports with predictable quality. This FAQ covers practical questions about file size reduction, curve cleanup, and physics baking in Spine 4.2.
Last updated: 2026-02-17
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 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.
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.
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.
