Why does native AR show a different product color or animation from my web 3D preview?

Separate the source model from webpage runtime changes

A merchant may display a lamp in several finishes using webpage material controls. The customer selects a dark housing, but native Android AR opens with the original light-colored finish.

Model-viewer's Scene Viewer route downloads the original model again from its URL. It does not automatically inherit every material change made to the browser's current scene.

WebXR differs because it remains within the browser environment and can work with runtime material changes.

Before changing product files, identify the original model, the selected webpage state, and the asset used by the target AR viewer.

Do not assume a successful color change on the webpage means the underlying model file was rewritten.

Treat Quick Look as a separate delivery path

For iOS Quick Look, model-viewer can generate a USDZ from the current scene when a separate ios-src is not supplied. Some transformations, textures, and material properties can carry into that generated asset.

However, the official examples identify limitations. Certain base-color changes multiplied into textures may not appear as expected, and the demonstrated automatic USDZ path has animation limitations.

If an explicit ios-src is supplied, it identifies a separate iOS model asset. Changing the webpage material state does not establish that this independent file has been updated.

These conditions do not mean every USDZ file or every iOS AR implementation lacks animation. The limitation concerns the documented automatic-generation behavior.

For each intended product finish or motion, determine whether the target runtime receives the appropriate approved asset.

Illustrative exercise: lamp colors and box animation

Illustrative exercise — fictional merchant scenarios. No 3D model was generated, no webpage was modified, and no AR device was tested.

Input A is a lamp with two approved housing colors. The webpage switches to the dark finish, but the merchant expects Scene Viewer to show the same selected color.

The team should inspect the original model URL and the intended AR asset rather than assuming the webpage's runtime material state was transferred.

Input B is a packaging box with an opening animation visible in the web preview. The merchant plans to use automatically generated USDZ for iPhone AR.

The team should review the documented animation limitation and decide whether a separately prepared and approved iOS asset is required.

Neither case proves that a particular device will reproduce the intended material or animation.

Build a runtime-specific asset map

Record the approved source model, webpage material state, Android AR source, and iOS AR asset. Include the intended product finish and whether animation is required.

For color changes, inspect whether the chosen AR route loads the original asset or a derived model representing the selected finish.

For animations, distinguish web playback from the actual capabilities of the iOS delivery asset. Adding or changing an asset reference is not proof that its contents are correct.

Stop when the target AR mode cannot be matched to an approved model state. Resolve the asset mapping before treating the experience as ready.

The objective is consistent asset responsibility across runtimes, not guaranteed material accuracy, physical product validation, or successful device playback.

These tasks require separately prepared 3D assets and storefront integration. Itemlume images and videos are not validated interactive model exports.

Illustrative exercise — Web 3D and native AR asset-state handoff

These are illustrative exercise rows. Save a copy and record your own observations; the example is not an executed acceptance test.

Download review worksheet (CSV)