Cody Bennett

A work-around would be to render each layer into a 2D render target and iteratively pipe it into a 3D data texture on the CPU. You can see the diff...

FWIW that option no longer has an effect with React 18 -- roots are effectively concurrent by default. A PR would be more than welcome here.

Is this still an issue with [v5.6.2](https://github.com/pmndrs/react-xr/releases/tag/v5.6.2)?

From Discord, looks like state is not being created correctly when `XR` remounts.

`setAnimationLoop` is what you'll need so three.js runs its internal pose and controllers sync in `WebXRManager`. R3F manages this since it's a bit more complicated when rendering can be interrupted...

Are you doing anything out of the ordinary in your rendering pipeline like post-processing or have texture use? Unless this is a trivial setup, I'd need to see an example....

Fixed how? Optional features shouldn't change behavior unless they're supported. Only required features will block a request.

I missed this and #219. Taking a look.

I'd look into projecting a [`VideoTexture`](https://threejs.org/docs/#api/en/textures/VideoTexture) onto a plane or adding support for that in https://github.com/pmndrs/drei/blob/master/src/core/Image.tsx if it doesn't already. It should be fine as long as it doesn't rely...

Your `WebXR` component itself relies on R3F hooks which can only be called within a component wrapped in `` since it relies on context for hooks. ```jsx import React, {...