Spine Mesh Jumps to the Origin After a Skin Change? Check Skin Bones

A mesh stretches toward the origin or disappears after switching to one skin. Before repainting it, preserve the export and ask whether its required bones are active for that skin. A visible image file and a valid runtime dependency chain are different pieces of evidence.

Establish whether this asset uses skin bones

The official Spine Skins guide describes bones and constraints assigned to skins so they are active only under the relevant visible skin conditions. This supports skin-specific structures; it does not imply every template uses them.

Ask the rig or integration owner for the actual skin name, affected mesh, weighted bones and skin memberships. Without those details, record the dependency as unconfirmed. A screenshot alone cannot establish that skin bones caused the fault.

A weight reference is not proof of an active bone

The guide's attachment warnings explain that vertices weighted to an inactive bone can become invalid and end up at world 0,0. If every vertex is invalid, the mesh may not be visible. Confirm the actual weights and activation state rather than concluding that an existing PNG must render correctly.

Other problems can also produce an origin-like collapse. No exported data or target runtime was tested for this article. Use the documented mechanism as a branch to verify, not a diagnosis inferred from the shape of an artifact.

Keep three dependency layers in the handoff

• Parents: are the required parent bones active under the same skin conditions?
• Attachments: are skin bones used by the weighted mesh available for that attachment's skin?
• Constraints: do target and constrained-bone activation conditions match the constraint's skin membership?
• Warnings: which actual objects are marked in the source project, and what does the warning say?

Have the owner inspect these dependencies in a source-project copy. Adding every bone to every skin is not a universal repair: it can defeat structures intentionally enabled only for particular skins.

Do not confuse a diagnostic viewport with the export contract

The official guide notes that a viewport option can activate all bones regardless of visible skins, concealing some dependency problems that would matter at runtime. Include the observation settings with a screenshot instead of treating that view as proof that the selected skin works independently.

Resolve confirmed warnings under the intended skin conditions, then export a matched data, atlas and texture batch. Retain the original package for comparison. Do not improvise edits to production JSON references to hide a source-rig problem.

Choose artwork repair only when the evidence points there

Use Spine Workbench with its public guide to check the resource, exported skin and intended motion. Part calibration or rework is appropriate when the pose matches but the image contour does not.

Route confirmed bone, weight or constraint dependencies to the rig owner. The tutorial does not establish a general skin-bone editor in the workbench. Retest the original skin, target skin, both switching directions and the required animations; one static pose is not complete acceptance.