WebXR デモ

WebXRの各仕様を、いま開いている端末でそのまま動かして確かめられます。

環境を確認中…

セッションモード

XR体験の入口です。体験を始めるときに navigator.xr.requestSession("モード名") で、この中から1つを選びます。

…
inlineinline
ヘッドセットをかぶらずに、ふつうのWebページの中で3Dシーンを動かして表示するモード
なぜ必要？
没入モードはユーザー操作がないと開始できず、始まるまで中身が見えない。inlineがあると、同じ3Dシーンを没入前にページ内で見せてから誘導でき、プレビュー用の別実装が要らなくなる
WebXR Device API
WebXR Samples
…
immersive-vrimmersive-vr
ヘッドセットをかぶって、視界全体をVRの世界に切り替えるモード
なぜ必要？
ふつうのウィンドウ描画では、左右の目それぞれの視点や頭の動きに追従した描画ができない。ヘッドセットへの直接描画と姿勢追跡をまとめて引き受けるのがこのモード
WebXR Device API
WebXR Samples Three.js PlayCanvas A-Frame Babylon.js 360 Stereo Photos Stereo Video
…
immersive-arimmersive-ar
デバイスのカメラで映した現実の風景に、3Dオブジェクトを重ねて表示するモード
なぜ必要？
VRと違って、現実の映像との合成や現実基準の座標の扱いが必要になる。その面倒な部分をブラウザ側が引き受けてくれる
WebXR Augmented Reality Module - Level 1
WebXR Samples Three.js PlayCanvas A-Frame Babylon.js

モジュール

体験に足せる機能です。使いたい機能のfeature名を requiredFeatures（必須）または optionalFeatures（任意）に入れて requestSession に渡すと有効になります。

…
Gamepads
コントローラーのボタンやスティックが、いまどう押されているかを読み取る
なぜ必要？
コントローラーのボタン配置は機種ごとにバラバラ。既存のGamepad APIと同じ形式に揃えることで、機種差を吸収して入力を読める
WebXR Gamepads Module - Level 1
WebXR Samples Three.js PlayCanvas A-Frame Babylon.js
…
Hand Inputhand-tracking
デバイスのカメラで手を認識して、指の関節の位置や動きを取得する。素手での選択やつかむ操作がつくれる
なぜ必要？
コントローラーを持たない・持てない場面（展示、教育など）でも操作手段が要る。手そのものを入力デバイスとして使えるようにする
WebXR Hand Input Module - Level 1
WebXR Samples Three.js PlayCanvas A-Frame
…
Hit Testhit-test
デバイスのカメラで現実の床や机を見つけて、3Dオブジェクトを置ける位置を教えてくれる
なぜ必要？
カメラ映像だけでは、アプリは「そこに面があるか」を知れない。端末の空間認識の結果を借りて、現実の面の位置を教えてもらう
WebXR Hit Test Module
WebXR Samples Three.js PlayCanvas Babylon.js
…
Anchorsanchors
現実の空間に目印を打ち込んで、置いたオブジェクトが時間が経ってもずれないように固定する
なぜ必要？
トラッキングは常に裏で補正されるため、固定の座標に置いた物は現実に対して少しずつ流れる。目印を端末側に追従させれば補正後もその場に留まる
WebXR Anchors Module
WebXR Samples PlayCanvas A-Frame Babylon.js
…
DOM Overlaysdom-overlay
XR中はふつうのHTMLが見えなくなるので、ボタンやメニューなどのHTMLをAR映像の上に重ねて表示する
なぜ必要？
XRの画面は毎フレームWebGLで描かれ、HTMLは一切表示されない。ボタン1つでもWebGLで自作するのは大変なので、HTMLをそのまま重ねる口が必要
WebXR DOM Overlays Module
WebXR Samples
…
Depth Sensingdepth-sensing
デバイスのカメラで現実の物までの距離を測って、3Dオブジェクトが現実の物の後ろに隠れる表現をつくる
なぜ必要？
距離情報が無いと、3Dオブジェクトは常に現実の手前に描かれてしまう。机の後ろに置いたはずの物が手前に浮いて見える、が防げる
WebXR Depth Sensing Module
WebXR Samples PlayCanvas Babylon.js
…
Mesh Detectionmesh-detection
デバイスが部屋をスキャンして作った、壁・床・家具の立体データを受け取る
なぜ必要？
現実の壁や家具の形が分からないと、ボールが壁で跳ね返るような現実と絡む表現がつくれない
WebXR Mesh Detection Module
WebXR Samples PlayCanvas A-Frame
…
Lighting Estimationlight-estimation
デバイスのカメラで部屋の明るさや光の向きを読み取って、3Dオブジェクトの影や色を現実の光に合わせる
なぜ必要？
現実は明るいのに3Dだけ暗い、影の向きが違う、といった「合成っぽさ」が出てしまう。現実の光を測って合わせると馴染む
WebXR Lighting Estimation API Level 1
Three.js Babylon.js
…
Layerslayers
動画や文字を専用のレイヤーに分けてヘッドセットに直接渡して、にじみを減らしてくっきり表示する
なぜ必要？
1枚のWebGLに全部を描くと、動画や文字は一度描いてから引き伸ばされてにじむ。ヘッドセットの合成器に直接渡せば劣化しない
WebXR Layers API Level 1
Quad Layer Cylinder Layer Media Layer Equirect Video Three.js A-Frame
…
WebGPU Bindingwebgpu
XRの映像をWebGPUでも描けるようにして、描画方法の選択肢を増やす
なぜ必要？
WebGPUにはコンピュートシェーダーなど、WebGLには無い描画のしくみがある。それらをXRの描画でも使えるようにする接続層
WebXR/WebGPU Binding
WebXR Samples Three.js
…
Body Trackingbody-tracking
ヘッドセットやトラッカーで体の動きを読み取って、全身のポーズを取得する。アバターを動かすのに使う
なぜ必要？
頭と手の位置だけでは腰や脚の動きが分からず、アバターの下半身は推測で動かすしかない。全身の関節が取れれば実際の動きを反映できる
WebXR Body Tracking（ベンダー拡張）
デモは近日公開

体験スペース

体験の基準になる座標系です。セッション開始後に session.requestReferenceSpace("名前") で選びます。bounded-floor などは optionalFeatures への指定も必要です。

…
viewerviewer
座標の原点が頭（視点）そのものになる。どこを向いてもオブジェクトが視界の同じ位置に居続けるので、メニューや照準の固定に使う
なぜ必要？
HUDや照準を普通のワールド座標に置くと、頭を動かした瞬間に視界からズレてしまう。視点に張り付く座標系が別に必要
WebXR Device API（Reference Spaces）
デモは近日公開
…
locallocal
体験を始めた瞬間の頭の位置が原点になる。床の高さは分からないので、椅子に座ったまま・立ち止まったままの体験に向く
なぜ必要？
トラッキングの原点は端末任せで、何も指定しないと開始位置すら保証されない。「開始時の頭の位置」という分かりやすい基準を保証してくれる
WebXR Device API（Reference Spaces）
デモは近日公開
…
local-floorlocal-floor
原点が足元の床（y=0）になり、床の高さが現実と一致する。地面にものを置いたり、立って見下ろすコンテンツがつくれる
なぜ必要？
localでは床の高さが分からないため、地面に置いたはずのオブジェクトが浮いたり埋まったりする。床基準の原点があればy=0に置くだけで済む
WebXR Device API（Reference Spaces）
デモは近日公開
…
bounded-floorbounded-floor
原点は床のままで、さらにヘッドセットに設定した「安全に歩ける範囲」の境界線が取れる。境界の中を実際に歩き回る前提のコンテンツに使う
なぜ必要？
歩き回る体験で、安全に動ける範囲をコンテンツ側が知らないと、壁や家具に向かわせる配置をしてしまう。境界線が取れれば範囲内に収まる設計ができる
WebXR Device API（Reference Spaces）
WebXR Samples
…
unboundedunbounded
どこまで移動してもトラッキングが破綻しないように座標を調整し続ける空間。建物や屋外など、広い場所を歩き回るARに使う
なぜ必要？
local系の空間は原点から離れるほどトラッキング誤差が積み重なる。長距離を歩くARでは、原点自体を調整し続ける仕組みが必要になる
WebXR Device API（Reference Spaces）
デモは近日公開

スターターコードを組み立てる

モード・機能・体験スペースを選ぶと、WebXRを開始するコードがその場で組み上がります。未対応の端末でも、実装の形をそのまま確認できます。

モード

機能（optionalFeatures）

体験スペース

starter.js

1// 1. この端末でモードが使えるか確認2const supported = await navigator.xr.isSessionSupported("immersive-vr");3 4// 2. セッションを開始（使いたい機能はここで要求）5const session = await navigator.xr.requestSession("immersive-vr", {6  requiredFeatures: ["local-floor"],7});8 9// 3. 体験の基準になる座標系を取得10const refSpace = await session.requestReferenceSpace("local-floor");

体験を開始すると、VRでは安定性を優先した暗背景、ARではパススルーを背景に、hit-test（面マーカー）・anchors（選択操作で固定キューブを設置）・hand-tracking（関節の点表示）・bounded-floor（境界線）・mesh-detection（部屋メッシュの点群）・depth-sensing（視線の先の実測距離マーカー）・light-estimation（主光源の方向線）・body-tracking（全身関節の点表示）がセッションの中で確認できます。Layersなど「可視化なし」の機能は、体験開始時のセッション要求には入れません。

対応表示はブラウザのAPI実装有無に基づく簡易チェックです。各行のコードは、requestSession のモード名または requiredFeatures / optionalFeatures に渡す機能名です。最終的な動作は各デモページでご確認ください。

解説つきデモ記事