# For AR developers

## Start with project scale

AR projects span table-scale, room-scale, building-scale, campus-scale, and city-scale environments. Device SLAM can track motion at 30–60 FPS and is usually sufficient for table- and room-scale experiences. Over longer routes, small frame-to-frame errors accumulate into visible drift, so building- and campus-scale projects need VPS.

VPS does not replace SLAM. SLAM provides smooth, low-latency local tracking; VPS periodically or eventfully corrects that local trajectory against a persistent Spatial Map.

[![A person follows a solid yellow ground path; dashed yellow camera frusta preserve the same proportions while becoming uniformly smaller and more densely spaced toward the roadway vanishing point](/media/docs/ar-slam-vps-collaboration-v22.png)](/media/docs/ar-slam-vps-collaboration-v22.png)

## Design for changing light

Mapping and localization are easiest under similar light, but production venues change. Museums can be dark, outdoor sites vary with weather and time, and commercial venues change lighting by schedule. 01Spatial is optimized for robust cross-light localization, but acceptance testing should still cover every important device, area, direction, and lighting condition.

## Build an operable AR product

Use the localization API, WebXR, App Clip, WeChat Mini Program, or Unity template for the client. In Space Studio, operators can inspect maps, add primitive objects or imported GLB / glTF models, and publish content updates without rebuilding the map or shipping a new app for every campaign.

## Recommended sequence

1. Build the Spatial Map.
2. Validate localization with production devices and lighting.
3. Define the SLAM–VPS correction strategy.
4. Define content types, permissions, and live synchronization.
5. Test long routes, transitions, occlusion, low light, and network interruption.