immersive-web
Hint for VR in AR WebXR sessions.
/facetoface This came up in today's call (4/3/25). There have been experiences in the wild want to run almost entirely in VR then occasionally use the AR pass through features. Currently this results in large power and performance requirements as the AR systems are active but not being utilised. Should we have a new session type or an API to quickly allow switching between AR and VR?
The proposal is to have a switch to disable calculation of the AR passthrough so sessions can seamlessly switch between VR and AR.
What would this look like in code, Something like the below? I would think we would want a promise as operation to enable/disable could take a while.
session.toggleAR().then((enabled) => {
console.log('enabled?', enabled)
})
What would this look like in code, Something like the below? I would think we would want a promise as operation to enable/disable could take a while.
session.toggleAR().then((enabled) => { console.log('enabled?', enabled) })
It could be something in the renderstate. That way it's easy to read and write and it's well defined when it's applied.
This is a valuable direction,....enabling dynamic AR/VR toggling could significantly improve power efficiency and broaden use case flexibility for mixed-mode experiences. I agree with the idea that exposing this as part of renderState makes it cleanly declarative and consistent with existing WebXR patterns.
One small question: Would toggling AR passthrough affect camera access or environment blend modes mid-session? If so, it might help to clarify the expected state transitions and whether developers need to handle reinitialization events (e.g., frame loop adjustments, pipeline changes).
Either way, excited to see this evolve, especially for battery-sensitive mobile XR apps that don’t need full AR context persistently. Let me know if a PR draft or spec sketch would be helpful!
