Spatial product production workshop / 6 MIN READ
Keep an interactive annotation attached to the part it describes
A label can remain readable while pointing to the wrong moving component.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-07
Interactive annotations join language to a location on a three-dimensional object. Accept both sides of that relationship: the statement must describe the intended feature, and its anchor must remain meaningful as the camera or product moves. Readability alone does not establish a correct attachment.
What you will leave with: A feature-to-anchor map with movement, visibility and alternative-information checks for every consequential label.
Use this when
- A model uses hotspots to explain features or dimensions.
- A label drifts away from a component during animation or remains misleading when hidden behind the model.
This is geometry-bound annotation acceptance, not a static diagram review or a blanket accessibility claim. Browser annotations should not be assumed to transfer to native viewers. Use fictional content and authorized test environments. Source checked on 7 November 2026.
Name the feature before choosing its coordinate
For each annotation, record the exact physical feature and the statement it supports. Distinguish a point on a component from an area, a dimension endpoint or a general note about the whole product. A label for a removable insert should not be anchored to the case beside it merely because that position is convenient in the initial view.
Link the label to a stable feature reference in the production handoff and include a view that establishes the intended attachment. Record whether the component moves, changes visibility or exists only in some supported model states. This prevents an implementation owner from treating every label as a fixed point while the artist assumes it follows a moving part.
Choose an anchor behavior that matches the feature
The model-viewer annotation examples distinguish position-based hotspots from surface-following animated hotspots. Their visibility event indicates whether the hotspot faces the camera; it is not proof that another surface does not obscure the target. The examples also describe screen overlays that draw above the model without scene occlusion.
Ask the implementation owner to document the selected binding and visibility behavior for each label. State what should happen when the target turns away, moves behind another component or leaves the useful view. Possible decisions include hiding the annotation, changing its presentation or keeping a clearly separate explanatory note. The choice must preserve meaning rather than pretending all forms of visibility are the same technical signal.
Inspect camera movement and component movement together
Test each annotation from the useful inspection views, then repeat while its component moves through supported states. Watch the anchor, connector line, label text and target as one unit. Record when a connector crosses another feature in a way that changes the apparent reference. A label that stays perfectly stationary can still become incorrect when the component beneath it moves.
Include a view where the target faces the camera but is behind another surface, if that relationship can occur. This exposes confusion between facing direction and actual obstruction. Also test a view where the target remains visible but several labels compete for space. Resolve the explanatory problem without relocating the anchor to an unrelated feature. Keep the same information available through a plain-text or other appropriate route that does not depend on locating a tiny hotspot.
Retest attachments after asset changes
When geometry, animation or model variants change, revisit the anchor map even if the annotation code has not changed. A coordinate or surface reference that was correct for the earlier asset may no longer identify the intended part. Compare the accepted feature view with the new delivery and retain the revision relationship in the handoff.
Close the review with the tested states, receiver, visibility policy and unresolved limitations. Do not claim that a browser overlay is present in a native experience unless that separate route has been verified. If the annotation cannot remain truthful through a state, narrow its availability or offer the explanation outside the interactive scene. The goal is a dependable reference, not the maximum possible number of labels on screen.
Make the reasoning concrete.
A fictional desk-lamp model labels the hinge on its adjustable arm. During the arm animation, the label stays at its original coordinate and appears to point to the shade. A separate rear view shows the hinge label through the body.
Move the label for the hero pose
Opening: Reposition it until the starting screenshot looks clear.
Hypothesis: The first view becomes easier to read.
Risk: The attachment still fails during movement, and the obstruction behavior remains unexplained.
Review binding and visibility separately
Opening: Bind the explanation to the intended moving feature and choose a truthful policy for obscured views.
Hypothesis: The label can preserve its referent across the supported interaction.
Risk: Some views may need a separate text explanation rather than an always-visible overlay.
The team chooses the second approach and retests the animation and rear view. It treats legibility, attachment and visibility as related but distinct acceptance questions.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Referent
Which exact feature does the annotation describe?
Binding
Should the anchor remain fixed or follow a changing surface?
Visibility
What happens when the feature faces away or is obscured?
Sequence
Which camera and component movements can make the reference misleading?
Continuity
What alternative explanation and revision check preserve the information?
Watch for the wrong conclusion.
- Choosing coordinates before identifying the feature.
- Equating camera-facing visibility with true occlusion.
- Keeping annotation positions unchanged after a geometry revision.
Your next action
Test one moving-feature label through its full supported motion and one obstructed view, checking attachment and visibility separately.
Sources & scope
Workflows, worksheets and fictional examples are original editorial analysis. Sources support only specifically attributed principles. Platform guidance can change; legal requirements depend on jurisdiction and context. No measured results or named human reviewer are claimed.
- model-viewer: Annotations →Primary viewer documentation · Supports: The examples describe position and surface binding, camera-facing visibility and overlay occlusion limits. The feature map and acceptance workflow are original analysis.