Repository navigation
Research: XR Support #677
Description
Activity
- addedfeature requestNew feature requestNew feature requestand removedfeature requestNew feature requestNew feature request
on Feb 17, 2025 vanruesc commented
on Jun 19, 2025 on Jun 19, 2025 · Hidden as off-topicAuthorshow commentMore actionsLet me explain:
1 - I'm using V6, so I'm talking about it right now.
I'm using both "setAnimationLoop" and "requestAnimationFrame" with "postprocessing" in a desktop web app, and both them work.
That's why I had idea that there should be no issue on it for XR, if "setAnimationLoop" is mandatory, and that's why I suspect that the problem is about the xr camera.
2 - By now, my suggestion would be to use another canvas, with another renderer, to suverimpose the "postprocessing" render onto the top of the underliying scene, so to be able to use a standard camera for rendering, instead of the xr camera.
A bit tricky, but I did a test and it work.
Next step is to sync the standard camera with the xr camera, but it's not so hard.
Maybe I'm wrong, or maybe it can give you some idea.
Btw many thanks!!!I'm using V6, so I'm talking about it right now.
I see. This ticket is about v7 and there are no plans to add XR support to v6. Sorry for the confusion - I've added the v7 milestone now.
that's why I suspect that the problem is about the xr camera
Well, yes, no question about that. Postprocessing needs to be aware of the array camera and XR state.
my suggestion would be to use another canvas, with another renderer [...]
Next step is to sync the standard camera with the xr camera, but it's not so hard.There is no need for an additional renderer. Postprocessing can use the same renderer since it uses its own internal render targets and doesn't actually use a camera to render the effects. (The fullscreenCamera is just a dummy.)
to superimpose the "postprocessing" render onto the top of the underliying scene, so to be able to use a standard camera for rendering, instead of the xr camera.
With XR, the scene is rendered twice - once for each eye, with slightly different camera settings and the results are rendered into the left half and the right half of a framebuffer respectively. Postprocessing must again be aware of this and also render the effects for the left eye and the right eye while respecting the different camera settings. Blending the result with the XR output frame is not the problem.
I appreciate your input and I hope this clears things up a bit.
Reacted by issimissimoYes, I see. Many thanks for your nice and detailed reply.
Description
Related: #676 #452
This is a research ticket for gathering information on how to implement XR support in
postprocessing.The rendering workflow in v7 consists of using a
RenderPipelinethat uses aWebGLRenderer/WebGPURendererto render individual passes. Three's WebXR support requires the use ofWebGLRenderer.setAnimationLoopand it uses a special XR camera for the active XR session. So some parts definitely need to be changed but the actual scope of the changes needs to be specified before VR can be implemented.Implementation Details
Relevant sources
Additional sources