Preserve the selected finish when opening the external AR viewer

Separate the visible state from its stored representation

List the scene changes offered before launch: a named material variant, a replaced texture or another supported runtime edit. For each, record whether the change exists in the original file, only in browser memory or in a separately generated delivery artifact. Use explicit asset revisions rather than “the current model,” because two files with the same display name can contain different finishes.

Create a route row for each receiver the experience actually offers. Include the original model URL, any explicitly supplied native-format file and the generation path where applicable. The purpose is to expose which representation crosses the boundary. Do not expand the matrix into a catalog of hypothetical devices that the team has neither committed to support nor tested.

Check the route’s documented transfer behavior

The model-viewer scene examples state that Scene Viewer downloads the original model URL, while WebXR stays in the browser. They distinguish auto-generated Quick Look USDZ from an explicit ios-src and document limits on some color-factor changes. These are route-specific behaviors, not a promise that every browser material edit survives conversion.

Use those distinctions to identify the risky rows. A separate native file can be correctly authored yet out of step with a changed browser scene. An automatically generated file still needs visual comparison for the particular edit. Ask the implementation owner what the receiver obtains, then verify that answer with the delivered experience. Do not infer successful transfer merely because the launch button remains available after the selection changes.

Compare deliberately different states across the boundary

Choose a small set of unmistakable fictional finishes for testing, such as contrasting colors with a distinct printed mark. Compare the default state, a changed state and a return to default. Record the browser appearance immediately before launch and the received appearance. Where the route uses a separate file, include its exact revision in the evidence so a mismatch can be traced to packaging rather than blamed on the viewer.

Test a repeated launch after a different selection and the return to the browser. Determine whether the visible browser state and the last received state remain understandable. Keep unrelated purchase controls out of this acceptance task. The relevant failure is that the scene crossing the boundary differs from the scene the reader was invited to preview, even when all product commerce data elsewhere is correct.

Resolve mismatches without silently changing the promise

Choose a correction matched to the route: deliver the appropriate supported asset, revise the conversion, clearly explain a limited preview or remove the misleading launch path for that state. Have the product and implementation owners approve the tradeoff. A generic note that “appearance may vary” should not excuse a predictable switch to a different finish.

Retest all affected route rows after repair, including the reset case. Preserve the scene-state map, receiver/version evidence and remaining unsupported edits with the delivery package. When either the browser manipulation or native asset changes, the handoff needs renewed review. Success means the tested receiver gets the intended representation or an explicit, honest alternative, not that every viewer has become equivalent.

Make the reasoning concrete.

A fictional lamp configurator changes its shade from blue to orange in the browser. Its native preview route still downloads a file whose default shade is blue. The team initially sees this as a minor color variation.

The team chooses the explicit route correction. It tests a changed selection and a reset rather than treating a single default-state launch as proof of state transfer.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. State

   Which changes are stored in the file and which exist only at runtime?

2. Route

   What exact asset or generated representation does each receiver obtain?

3. Evidence

   Which before-and-after views demonstrate the transferred state?

4. Mismatch

   Is the difference a packaging, conversion or documented route limitation?

5. Resolution

   What supported asset, explanation or restriction makes the handoff honest?

Watch for the wrong conclusion.

• Assuming a successful native launch preserves browser edits.
• Testing only the default finish.
• Using a display-variation disclaimer for a known wrong asset state.

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: Materials and Scene Examples →Primary viewer documentation · Supports: The scene examples describe original-URL reload, browser-resident WebXR, explicit versus generated USDZ and limited color-factor transfer. The acceptance matrix is original analysis.