The mobile browser has quietly become a serious 3D and AR runtime. WebGL and the WebXR Device API mean a buyer can tap a link and walk around a property model, or place furniture in their own living room, with no app store, no SDK, no install. This guide is the developer's map of that territory: the rendering stacks, project scaffolding, AR placement and tracking, interactivity, the performance engineering that keeps heavy architectural scenes running on phones, and the export paths when you need Unity or headset VR. It consolidates the individual developer answers from our knowledge base into one continuous reference.

Augmento ships browser-based AR for real estate developers, event brands and artists in production, so the recommendations below reflect what actually survives contact with mid-range Android devices, not just what works in a desktop demo.

The stack: WebXR, Three.js, Babylon.js, A-Frame

The foundation is the WebXR Device API, which enables AR experiences directly in mobile browsers without app installation. A web page can activate the user's camera, detect surfaces, and overlay 3D property models or furniture in augmented reality. That single capability is why WebAR is so effective for marketing: buyers tap a link and are inside the experience instantly. Our standalone answer on embedding an AR property tour directly on a webpage with WebXR covers the embed pattern in detail.

On top of WebXR you pick a rendering layer:

• Three.js: the de facto standard scene graph over WebGL. Mature loaders, controls and a huge ecosystem. Most of the recipes in this guide use it.
• Babylon.js: a batteries-included engine with strong tooling; a solid alternative if you prefer an integrated framework to a library.
• A-Frame: declarative, HTML-like scene markup on top of Three.js. Fastest path to a working prototype.

Do you need React or Vue on top? No. A performant 3D real estate viewer is entirely achievable with vanilla JavaScript and Three.js, and there is a real argument for it: without framework overhead the initial bundle stays small and rendering performance is maximized, which is critical for mobile devices viewing heavy 3D property scenes. Frameworks earn their keep in the surrounding UI, not in the render loop.

Scaffolding a project (npm create @iwsdk and alternatives)

The fastest way to a correctly configured WebXR project is the Immersive Web SDK generator. Run npm create @iwsdk@latest and the CLI walks you through selecting AR versus VR mode, choosing a rendering engine (Three.js or Babylon.js), and configuring build tools. The generated project includes hit testing, surface detection, and 3D model loading pre-configured, which removes most of the boilerplate that makes first WebXR projects painful. From there, the work is swapping in your property models and writing the interaction handlers specific to your use case.

If you prefer to scaffold by hand, the equivalent baseline is a bundler dev server, the Three.js (or Babylon.js) dependency, HTTPS for camera access, and a physical test device from day one. Emulators do not tell you the truth about tracking quality or thermal throttling; a real phone does.

Building a performant 3D viewer (models, controls, environments)

The canonical non-AR viewer, the "walk around the model in the browser" experience, has three moving parts in Three.js:

• Model loading: load GLTF/GLB models with GLTFLoader. GLTF/GLB is the recommended web format: lightweight, streamable and universally supported.
• Navigation: implement OrbitControls for orbit, pan and zoom around the model. It covers the property-viewer interaction pattern with almost no code.
• Lighting and materials: add environment maps for realistic material rendering. An environment map does more for perceived quality per kilobyte than almost any other asset.

On formats more broadly: GLTF/GLB for the web, USDZ for Apple's iOS Quick Look AR path, FBX and OBJ as import and interchange formats you convert from rather than ship. The full compatibility matrix is in which 3D file formats Augmento supports.

AR placement: hit testing, anchors and SLAM in the browser

Placing a 3D object on a real floor is the signature WebAR interaction, and the WebXR Hit Test API is the mechanism. The loop that powers every browser-based furniture placement experience:

• Request an XRHitTestSource from the active XR session.
• Perform hit tests each frame against the surfaces the device has detected.
• Visualize the candidate placement point with a reticle mesh so the user can see where the object will land.
• On user tap, create an anchor at the hit test result's pose and parent the furniture model to that anchor, so it holds its position as the user moves around the room.

What about SLAM (Simultaneous Localization and Mapping), the tracking technology underneath? The short answer: do not implement it yourself. In the browser, SLAM relies on WebXR's built-in tracking rather than a from-scratch implementation. Mobile browsers on ARKit and ARCore capable devices expose surface detection and spatial tracking through the WebXR API; your Three.js or A-Frame application accesses them by requesting an XRSession in immersive-ar mode, and the browser handles the heavy SLAM computation natively. Your code consumes poses and hit test results; the OS does the computer vision.

Hotspots, pop-ups and interactivity

A property model becomes a sales tool when it can answer questions: tap the kitchen island for the spec sheet, tap the window for the view video. In Three.js the pattern is:

• Markers: create hotspot markers as sprite meshes, or as HTML overlay elements positioned in 3D space using CSS2DRenderer. Sprites live inside the WebGL scene; CSS2D overlays give you ordinary HTML styling for labels and buttons.
• Picking: use raycasting via THREE.Raycaster to detect mouse and touch intersections with hotspot objects.
• Actions: on click, trigger pop-up overlays containing images, video, text or links.
• VR mode: where there is no pointer, implement gaze-based interaction: hovering the reticle on a hotspot for a threshold duration triggers the same action.

Keep the hotspot data (positions, content, media URLs) separate from the scene code. It is the part of the experience that marketing will want to change weekly, and it should not require a rebuild.

Performance engineering: Gaussian splats, LOD, mesh and texture budgets

Performance is the difference between a WebAR experience that converts and one that gets closed after four seconds of loading. Two workloads dominate real estate: photoreal capture (increasingly Gaussian splats) and CAD-derived architectural meshes.

Gaussian splat models

Gaussian splatting produces photoreal scenes, and enormous files. The optimization playbook for mobile browsers:

• Decimate: reduce splat count while preserving visual quality.
• Stream by level of detail: implement LOD streaming that loads nearby detail first.
• Compress: quantize the point cloud data.
• Load progressively: show a coarse preview within seconds while full detail streams in the background.

Three.js plus custom WebGL shaders are the primary tools for browser-based splat rendering today. The dedicated walkthrough is in optimizing a large Gaussian splat model for mobile browsers.

Mesh and texture budgets

For polygonal scenes, the discipline is the same on every target: bake lighting into textures instead of computing it in real time, reduce polygon counts with LOD techniques, compress textures, and load lazily so users only download what they actually view. As a reference point, the budgets we discuss for real-time VR below (a full scene under 500K polygons, 2K-4K texture atlases) are a sane ceiling for high-end mobile web as well; most scenes should aim lower.

On the Augmento platform this pipeline is automated: 3D model compression and LOD generation, adaptive quality scaling based on device GPU capabilities, lazy asset loading, edge-cached CDN delivery for sub-100ms asset loading, and frame rate monitoring with automatic quality fallbacks. We target 60fps on mid-range devices from the last 3 years, and that target shapes every budget above. More in how Augmento keeps AR performant across devices.

Beyond the browser: Unity and VR export settings

Some deliverables outgrow the browser: headset VR presentations, sales-suite installations, or Unity apps. The export settings that make an architectural model behave in real-time VR:

• Polygon budget: target under 500K polygons for the full scene.
• Format: use FBX for best Unity compatibility (GLTF/GLB remains the choice for web-based VR).
• Detail: bake high-poly detail into normal maps rather than shipping dense geometry.
• Textures: limit texture atlases to 2K-4K resolution, with proper UV unwrapping.
• Scale: set import scale to Unity's convention of 1 unit = 1 meter.
• Culling: for large properties, implement occlusion culling and LOD groups so only visible geometry renders each frame.

For heavy architectural renderings headed to a client walkthrough, two further rules matter. First, bake lighting into textures; real-time global illumination is where VR frame rates go to die. Second, design comfort in: implement teleportation-based navigation rather than smooth locomotion, which causes motion sickness, and hold a consistent 72+ FPS for comfortable viewing. A beautiful walkthrough at 40 FPS is a nauseating one.

Shipping faster with Augmento's WebAR platform and API

Everything above is buildable from scratch. The question is whether your team should spend its time on splat compression pipelines or on the product. Augmento's platform packages the undifferentiated heavy lifting: the ingestion pipeline accepts GLTF/GLB, USDZ, FBX and OBJ and automatically optimizes models for mobile (texture compression, polygon reduction, LOD generation), the runtime handles device-adaptive quality and 60fps rendering, and delivery rides an edge-cached CDN.

For developers, the platform is programmable: a RESTful API and webhooks let you manage AR experiences, trigger content updates, pull analytics data, and integrate with your existing stack, with SDKs for JavaScript, Python and Swift. Rate limits and access levels depend on plan, and dedicated support is available for complex integrations. Details in Augmento's API and custom integrations.

If you are evaluating build versus buy, look at the case studies to see what the platform ships in production, or talk to our engineering team about your use case.