Hidden in the Spine Editor, Visible in the Game? Check the Hiding Mechanism

The AI-generated cover illustrates character looks. It is not a visibility control, an export comparison or a recorded game test.

You hide an ornament with a slot's visibility dot in the Spine editor. It disappears from the viewport, then reappears when the exported skeleton runs in the game. First identify whether you changed a temporary editor view or the actual attachment state. An empty area in the editor does not establish the behavior of exported data.

Define where the part must disappear

• Only in the editor, to reduce visual clutter while working.
• From an exported image or video.
• From a particular state in a game that loads skeleton data.

These requests can produce similar previews but require different delivery criteria. Name the output in the handoff: image, video or runtime data package. “Hide after export” is too ambiguous without that object.

The visibility dot is an editor control

The official Spine Slots documentation explains that hiding a slot with its tree visibility dot removes its attachments from the viewport and image or video exports. Those attachments still appear in data exports, and this temporary hiding cannot be keyed.

A preview without the ornament therefore does not prove that the runtime package excludes it. This describes the Spine editor. It does not imply that Tooliva has the same dot or that a particular Tooliva export is faulty.

Runtime behavior needs attachment-state evidence

If the ornament should disappear during part of an animation in the game, ask the data owner to confirm the actual slot, attachment selection and any required attachment keys. A slot may have no attachment selected; that is different from hiding the editor view. Check the actual skeleton project and receiving runtime rather than relying on a screenshot.

Do not interpret this as an instruction to delete a shared PNG or atlas region. Other skins or animations may still need it. A display-state decision and physical resource removal require separate dependency checks.

Zero alpha does not establish zero rendering work

Spine also cautions that setting slot alpha to zero is not an efficient way to hide an attachment: many game toolkits still perform drawing work. Alpha can serve a fade, but “invisible” and “rendering cost removed” are different findings.

No engine-specific cost is promised here, and this is not a reason to rewrite a playback system. Establish the required visual state first. If performance matters, inspect the actual rendering path in the target project.

Make the handoff reproducible

1. Record the export batch, skin, animation and observation time.
2. Record the editor preview and runtime result separately.
3. Name the mechanism: temporary visibility dot, slot attachment state or alpha.
4. Reload this package in the receiving project and check both the hidden interval and the intended return to visibility.

These are proposed acceptance steps, not engine tests performed for this article. If an old attachment remains specifically after a skin change, see skin changes and attachment state rather than attributing that separate issue to editor visibility.

In the Spine workbench, use the illustrated guide to check the current resource, animation and multi-skin export scope. Hand off skeleton hiding logic separately; do not assume the workbench offers arbitrary attachment-key editing.