Machine-readable: manifest · index · English Markdown
Draft translation: this English page is available for review and is not yet the production default.
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.
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
- Build the Spatial Map.
- Validate localization with production devices and lighting.
- Define the SLAM–VPS correction strategy.
- Define content types, permissions, and live synchronization.
- Test long routes, transitions, occlusion, low light, and network interruption.
