Build an AR Placement Test for a Commercial Pitch—and Check Its Scale
Build an AR Placement Test for a Commercial Pitch—and Check Its Scale
The smallest useful AR test for a pitch is one page, one approved model, one number, one phone you can actually hold, a reference object you measured with a tape, and a second copy of the model scaled wrong on purpose. The number is the part people skip.
Here is the whole job in a sentence: put a model you are allowed to use on a real surface, at its true physical size, next to an ordinary object whose size you measured with a tape, and write down what you saw. If the object claims to be 0.30 m tall, the test is whether a 0.30 m object is what ends up on the table.
It is also a much smaller test than the one you will be tempted to show. A model that loads in a browser tab and opens into a camera view has proven that a session started. It has not proven the object is the size you said, that the same thing happens on a phone that isn't yours, or that anything resembling the finished spot exists. Those are three different claims, and only the first one comes free.
Everything below is a plan rather than a report. No page was built for this piece, no model was exported, and no device session was run. The example's numbers are stipulated so the checks have something to check against.
Establish the physical question and the asset
Start with the decision, not the technology. "Can we do AR" is not a decision. "At true size, does this object sit on a kitchen counter the way the pitch implies, or does it crowd the mug beside it" is a decision. That question tells you what you need: one object, one surface type, one size.
Get a model you are permitted to use, and get the size from somewhere other than the file. For the exercise here, an approved stand-in is declared to be 0.30 m tall. That number comes from the approved specification. Whatever the model file happens to contain is a separate fact, and the two are allowed to disagree.
They disagree more often than you would think. glTF — the format a browser viewer will most likely load — measures in metres. An object that should be 0.30 m tall should be roughly 0.30 units tall in the geometry. A designer working in millimetres exports a 300 mm object, the exporter writes 300, and the metre-based format reads back 300 m. Nothing warns you. The model-viewer scenegraph example uses this exact case in its materials section, which is why it's worth checking before anything else.
Before you fix the size, fix two things that imitate size problems. Orientation: which way is up in the file, and does the viewer agree. Contact: where the object's underside sits relative to the file's origin. An origin at the object's centre will bury half the model in the table, which looks like a scale error and is not one. Decide the contact point — the base, the back face, the mounting bracket — and make the file match it.
Do not trust the preview. A previewing camera frames whatever it is given, so a 300-metre copy and a 0.30-metre copy produce the same tidy image with the same tidy turntable. The preview tells you the shape is intact. It cannot tell you the size, because it has no ruler.
Finally, keep the correction traceable. Note the original asset, the number you changed, the number you changed it to, and who approved it. Do not scale the object to fit the shelf, the frame, or the room. A wrong size that composes nicely in a screenshot is still wrong, and uniform scaling is not the only way to distort a product — squeeze it to fit a surface and you have quietly altered its proportions.
Construct one minimal placement route
The page needs four parts: the model, one control that starts placement, an ordinary 3D view for anyone who can't place it, and a line of text that states the dimension. That last one is not decoration. It is the fallback.
Choose the AR routes deliberately and write down the viewer library version you used. The model-viewer AR examples document the mode, scale and placement settings this test depends on; that is page text, not a device result, and the version you ship matters more than the version in a screenshot. The snippet below pins a version rather than floating on whatever is latest — replace the placeholder with the exact build you tested, because an unpinned URL changes under a reviewer who opens the page a month later.
You need a secure context. WebXR — the browser session that lets the page itself render the object into the camera feed — will not run over plain HTTP, and a page opened straight from disk will not work either. The camera and spatial-tracking permission is a user action, so it can be denied, and a previously denied permission often fails silently. If the reviewer meets the test inside an embedded frame, the frame needs to be allowed to request spatial tracking; otherwise the button does nothing and looks broken.
Now the distinction that shapes the whole build. There are three plausible routes, and they are not the same product:
- WebXR, where the browser tab keeps rendering and your page still owns the interaction.
- Scene Viewer, on Android, where the page hands off to a separate application.
- Quick Look, on iOS, which consumes a USDZ file rather than a GLB and has its own controls.
The model-viewer documentation is explicit that in-page content and controls do not automatically travel into the native viewers. The moment you hand off, your button, your label, your alt text and your fixed-scale setting are back in the browser. The native viewer brings its own interface and its own affordances, possibly including a resize gesture you did not plan for.
A page shaped like this is enough:
<script type="module"
src="https://unpkg.com/@google/model-viewer@<version>/dist/model-viewer.min.js"></script>
<model-viewer
src="stand-in-0.30m.glb"
ios-src="stand-in-0.30m.usdz"
alt="Approved stand-in, 0.30 metres tall"
ar
ar-modes="webxr scene-viewer quick-look"
ar-placement="floor"
ar-scale="fixed"
camera-controls>
<button slot="ar-button">Show it at full size</button>
</model-viewer>
<p>Approved stand-in, 0.30 m tall. Shown at true size in a supported AR viewer.</p>
Read that button label again. "Show it at full size" is a promise about the asset, not about the button. If the file is wrong, the interface is lying to a reviewer on your behalf.
Separate scale correction from scale locking
ar-scale="fixed" stops casual pinch-resizing during the session where the route supports it. It does not inspect the model, and it does not certify that the file was ever the right size. It is a route setting. Locking the door does not tell you what is behind it.
Which routes honour that setting, and how, is worth verifying in the version you ship rather than assuming. Treat it as an interaction decision — do I want the reviewer to be able to resize the object — and not as a calibration step.
So the calibration happens earlier, and it happens to the file. Prepare two copies of the same stand-in, identical in shape:
- The corrected copy, exported so the geometry is about 0.30 units, which the metre-based format reads as 0.30 m.
- The deliberately mis-scaled copy, authored in millimetres and exported with no conversion, so the file carries 300 units and reads as 300 m — roughly a thousand times the intended height.
The wrong copy is not evidence that any platform is broken. It is a test of your review process. Will anyone catch it before it reaches a reviewer, or does the process have no numeric gate at all? A thousand-fold error is, honestly, the easy version: expect the oversized copy to refuse to place in an ordinary room, or to engulf you rather than sit in front of you, and record whatever it actually does. If your process catches that, the harder question is the 10 per cent error, and you may want a third copy at 0.27 m in a later round to see whether a human eye does what a build step should.
Then trace what each route actually receives, which is where in-page fixes quietly fail. The scenegraph example's model-transformations section is a useful reminder that a transformation applied by the page lives in the page. Scale the node at runtime and the browser route may look perfect while a native viewer opening the original asset gets the untouched original. Correct the asset and every route inherits the correction. If a vendor delivers the model and you cannot re-export it, runtime scaling may be your only option — but then the report has to say plainly that the native routes receive uncorrected geometry.
And do not announce support for every phone. Test the path you chose, and describe it by name.
Check the result beside a measured reference
Take the one supported phone you can actually hold, go somewhere quiet, and place the object on a surface. Then put the reference beside it: an ordinary object you measured with a tape to 0.30 m. Measure it; do not trust a nominal size printed on the side of a box, because the number you compare against should be the number you actually observed.
Look at three things and keep them apart in your notes.
Apparent height. Does the placed object match the marked reference, fall short, or overshoot? Compare a camera angle that shows both at once rather than two separate impressions.
Contact. Is the base sitting on the surface, hovering above it, or sunk into it? This is where the origin decision from the first section comes back. Hovering or sinking is a contact error, not a size error, and conflating them in the write-up will send someone hunting for the wrong bug.
Stability. Move the phone. Does the object stay where it was placed, or creep? Drift is a tracking symptom. An object of the wrong size beside a correct reference is a scale symptom. Two different findings, two different sentences.
Write down the conditions with the result: date, device and OS version, browser or viewer name and version, route taken, the asset filename and its stated height, the reference object and its measured height, what you observed, and what you could not determine. Take a photograph if the space is yours and contains nobody else — the room you film is a room you have to have permission to film, and nobody's data belongs in this exercise.
If the device on hand can't run a session, that is still a result. It goes in the report with the fallback: the ordinary non-AR view, with the 0.30 m dimension written out in text and marked on a labelled diagram. A labelled diagram is a diagram, and it should say so. Neither a composited image nor a plain 3D preview is evidence that a placement test ran, and putting one next to a result paragraph would make the whole page less trustworthy than the software inside it.
The sentence you are trying to be able to write
The finished test produces one sentence: on this device, in this route, with this asset version, the corrected 0.30 m stand-in placed on a table surface and matched a reference measured at 0.30 m, and the mis-scaled copy did whatever it did. Beside it: the fallback view, and the list of things this run did not test — the other route, the other phone, native-app behaviour, the finished campaign.
Until that sentence exists with real values in it, the whole construction is a test plan, and saying so is not modesty. It is the difference between a director showing a reviewer how an object would occupy their space, and a director showing a reviewer a nice picture of an object. The second one is much easier and proves much less.
Frequently asked questions
Why can't I judge the model's true size from the preview?
A previewing camera frames whatever it is given, so a 300-metre copy and a 0.30-metre copy produce the same tidy image with the same tidy turntable. The preview tells you the shape is intact; it cannot tell you the size, because it has no ruler. Size has to come from the approved specification and be checked against a measured reference.
How does a metre-based format end up with a model a thousand times too tall?
glTF measures in metres. A designer working in millimetres exports a 300 mm object, the exporter writes 300, and the metre-based format reads back 300 m. Nothing warns you. The model-viewer scenegraph example uses this exact case in its materials section, which is why it's worth checking before anything else.
Does setting the AR scale to fixed guarantee the object is the right size?
No. A fixed scale setting stops casual pinch-resizing during the session where the route supports it. It does not inspect the model, and it does not certify that the file was ever the right size. Treat it as an interaction decision — do I want the reviewer to be able to resize this — and not as a calibration step. Calibration happens earlier, to the file: two copies, one corrected and one deliberately mis-scaled, to see whether your review process has a numeric gate at all.
What's the difference between the AR routes, and what should I be careful about?
WebXR keeps rendering in the browser tab with your page still owning the interaction; Scene Viewer on Android hands off to a separate application; Quick Look on iOS consumes a USDZ rather than a GLB and brings its own controls. In-page content and controls don't automatically travel into native viewers, so your button, label, alt text and fixed-scale setting stay behind — and a native viewer may offer a resize gesture you didn't plan for. WebXR also needs a secure context and won't run from a page opened off disk; camera and spatial-tracking permission is a user action that can be denied, often silently, and an embedded frame has to be allowed to request spatial tracking.
What belongs in the report when no device on hand can run a session, or when the mis-scaled copy misbehaves?
A device that can't run a session is still a result; record it with the fallback: the ordinary non-AR view, the 0.30 m dimension written out in text and marked on a labelled diagram that says plainly it is a diagram. Write down the conditions with whatever you observed — date, device and OS, browser or viewer and version, route, asset filename and stated height, the reference object and its measured height, and what you could not determine. Keep apparent height, contact (sitting, hovering, sunk) and stability (does it creep when the phone moves) as separate findings, because drift is a tracking symptom and a mis-sized object beside a correct reference is a scale symptom. Then list what the run did not test: the other route, the other phone, native-app behaviour, the finished campaign.