Forum Discussion
Aliasing video texture in WebXR in Quest headsets
I have a strange report I can't replicate anywhere including on my Rift headset. Of aliasing on the actual video texture even with antialias configured and anisotropy set on the texture. I am unable to attain a Quest headset to check yet sadly.
I've repurposed the basic three stereo video example and made it render for top down stereo.
It's a top down stereo video texture. I dont have power of 2 sizing on the video element but do in the actual implementation. It may be quite noticeable to be a worry as in blocky pixels but there is no edges on the video texture. The title text in the video looks sharp to me at the start in my headset.
They weren't able to give me another screenshot. At one stage their render looked like Quest was trying to force a native stereo projection mode when three does that in Webxr so had a second distorted texture up the top.
They weren't able to give me another screenshot. At one stage their render looked like Quest was trying to force a native stereo projection mode when three does that in Webxr so had a second distorted texture up the top.
I was wondering if anyone with a headset might be able to check or know if its a bug with the oculus software or a solution for it. The dimensions of the video is quite large and its h265. I don't know where the problem is.
5 Replies
Replies have been turned off for this discussion
I believe this is related and is because the resolution on Quest is forced to be low even with a large video texture resolution.
the suggested solution is to set framebufferScaleFactor to 2. Which kills performance I believe. So at default ALL textures like this are low resolution and therefore pixelated.
https://communityforums.atmeta.com/t5/Quest-Development/Browser-WebXR-resolution-dropped-since-version-50/td-p/1043442WebXR renders at the recommended resolution of your headset (like pretty much any other app).
Multisampling only helps when you render geometry so it has no effect on yout video texture.
What you are seeing are artifacts of double sampling. We introduced WebXR layers to specifically work around that issue. (This is also what is used by native video players)
If you use three.js, you can take a look at https://github.com/mrdoob/three.js/blob/dev/examples/webgpu_xr_native_layers.html. The new three renderer has native support for layers. You should create a quad or cylinder layer and then blit the video in there. (You could even blit at the video frame rate which will help with performance).
For more detailed help, you can visit the WebXR discord.
How are you rik. I saw those layer examples. So multiview isn't needed ? From my tests frame buffer upscaling was needed as Quest renders at lower resolutions but causes performance problems. I already had a method to render at the video frame rate for non webxr but renders at the headset rate in xr. It may still need to stay that frame rate.
I'm not sure how to integrate that to make it universal for non webxr and webxr. And it seems each mesh / group added to the scene needs its own layer and camera ? Its just basic top bottom video in a sphere geometry with a custom video controls that needs to render in webxr and controlled by controllers. So for the video it can use this. The controls has many planes, circle goemetries and the SDF text is a buffer geoemtry. It seems that api only supports plane and cylinder geometries. So may not work for 360 video with custom controls.
Im presuming I need to add this somehow for video.
https://github.com/immersive-web/webxr-samples/blob/main/layers-samples/eqrt-video.htmlyes, support for equirect should be added to three. It's fairly simple since you could mimic the code for quad/cylinder layers.
Actually, equirect is simpler than quad/cylinder since you don't need to "hole punching". Instead, it renders behind the content of your three.js scene
