Add renderer backend and reversedDepthBuffer properties, pass multiview option to WebGPURenderer#5847
Conversation
…ew to WebGPURenderer - multiviewStereo is now also passed as the multiview option used by WebGPURenderer (fixes aframevr#5749) - new reversedDepthBuffer property passed to both WebGLRenderer and WebGPURenderer - new backend property (webgpu or webgl) mapped to the forceWebGL option of WebGPURenderer; ignored by WebGLRenderer Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…derer config tests WebGPURenderer initializes its backend asynchronously via init(). Previously renderStarted was set and renderstart emitted while the backend was still initializing (three.js setAnimationLoop recovers by awaiting init internally, but anything reacting to renderstart could call renderer methods that throw before initialization). The render loop kickoff now awaits renderer.init() when it exists; WebGLRenderer has no init method and keeps the synchronous path. Extract getRendererConfig() from setupRenderer() so the renderer attribute parsing is unit-testable without creating a WebGL context, and add tests for multiviewStereo/multiview, reversedDepthBuffer, backend and the async init behavior. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
setPoseTarget is an A-Frame specific patch in super-three to the WebXRManager used by WebGLRenderer. An equivalent will need to be implemented in super-three for the XRManager used by WebGPURenderer when WebXR support for WebGPURenderer is added. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
I think it would be better to use the values For reference, quite a few WebGPU examples in Three.js require WebGPU support and show a simple error message "Your browser does not support WebGPU yet" when it's not supported. |
As suggested in PR review, the default value is auto (WebGPU when available, falling back to WebGL 2) since the WebGPU backend is not guaranteed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
yes, I changed webpgu to auto |
Fixes #5749
New renderer properties
multiviewStereois now also passed as themultiviewoption used byWebGPURenderer(WebGLRendererkeeps readingmultiviewStereo, each renderer ignores the other's key).reversedDepthBufferproperty, passed as-is to bothWebGLRendererandWebGPURenderer.backendproperty (webgpuorwebgl):backend: webglmaps to theforceWebGLoption ofWebGPURenderer. When unset, nothing is passed so the WebGPU build keeps its current behavior (try WebGPU, fall back to WebGL2). Ignored byWebGLRenderer.Wait for async renderer init before starting the render loop
WebGPURendererinitializes its backend asynchronously viainit(). PreviouslyrenderStartedwas set andrenderstartemitted while the backend was still initializing (three.jssetAnimationLooprecovers by awaiting init internally, but anything reacting torenderstartcalling e.g.renderer.render()orcompileAsync()would throw.render() called before the backend is initialized). The render loop kickoff now awaitsrenderer.init()when it exists;WebGLRendererhas noinitmethod and keeps the fully synchronous path.Tests
The renderer attribute parsing is extracted from
setupRenderer()intogetRendererConfig()so it is unit-testable without creating a WebGL context (setupRendereris stubbed on CI). Added tests formultiviewStereo/multiview,reversedDepthBuffer,backendand the async init behavior. There were no existing tests coveringmultiviewStereo.Also adds a code note that
setPoseTarget(A-Frame specific super-three patch toWebXRManager) will need an equivalent in theXRManagerused byWebGPURendererwhen WebXR support is added.Verified at runtime with both builds (
npm run devandnpm run start:webgpu) driving headless Chrome: options reach the renderer (backend.isWebGLBackend,reversedDepthBuffer,xr._useMultiviewIfPossible) andrenderer.initializedis nowtruewhenrenderstartfires. Actual multiview rendering in VR still needs a headset test withexamples/performance/multiview-extension.🤖 Generated with Claude Code