Seems the last time this was addressed was with the release of the Oculus Go. We seemed to settle on a VR cube face size of 1920px. Not sure oversampling is applicable right now since, as I understand it, WebXR doesn't support it.

Today the significantly higher-performing Quest 2 and other headsets dominating the market. Should we be looking at a different VR image resolution and/or other settings?

Has anyone done the testing for this already and is willing to share???

Since I didn't get any feedback on this I decided to run some tests. If you have a headset you can check it out yourself tdf360.com/test/vr_rez.

I tried three different resolutions per cube face: 1536 (the KRPano default for some time), 1920 (recommended in the thread mentioned previously), and 2400 (because... it's higher so why not). Change resolutions by clicking the arrow buttons. If you only have the gaze pointer look down about 45 degrees to bring up the floating navigation buttons.

BTW, I chose this scene because the edge between the sky and especially the red-ish rocks will show a color fringe (at least on the Quest 2) unless you have the headset optimally positioned, meaning you are getting the sharpest image possible.

First thing to do is look to the back where I have added a resolution test chart. Switch between resolutions and you will see a definite difference. More resolution shows more "detail." However, that detail gets messed up by a moire effect that I expect is due to the image resolution being close to but not the same as the screen or render resolution.

Now, look elsewhere in the scene and switch resolutions. Do you actually see a difference in detail? Would you know which resolution is which if you didn't check the number above the resolution chart? Would a normal user ever notice a difference?

More detail might be visible if the moire was gone. But I'm not sure what resolution would do that and if it were optimized for the Quest 2 what would happen on the newest HTC headsets or others?

Thoughts? What is your experience with the test?

Klause - what is your guidance?

I added the FPS monitor. On my Quest 2, it stays in the 80s with little or no difference between resolutions, even when moving quickly. It drops very briefly during pano transitions but, again, the resolution doesn't seem to matter.

I charged up my Go to see how all this worked there. You see more of the screen door effect, naturally. Moire shows up on the chart even in the 1536 version and the frame rate is in the low 20s at best. You really notice the stuttering motion when moving your head rapidly.

Sidenote: Seems to me I was getting significantly better than 20fps in the Oculus browser on the Go before the switch from WebGL to WebXR. Does anyone know if WebXR rendering actually is worse than WebGL?

I find it interesting that for clearly defined detail, such as the text on the resolution chart, there is a definite difference between1536 and 1920 and barely noticeable between 1920 and 2400. However, in organic image detail, they are all pretty much the same -- on the Quest 2, even more so on the Go.

Another test case, this time an interior with hard edges, text, etc to better see the difference at different resolutions: tdf360.com/test/vrrez2. As before, only the Mobile VR images change so check it out in a headset. On desktop, the pano image stays the same.

Especially look at the signs on the wall near the staircase. To my eyes there is a noticeable difference between 1536px and 1920px cube faces but no additional benefit from 2400px. The limiting factor may be because oversampling is limited to 1X by the WebXR API. WebGL allowed higher levels and really made a difference with aliasing and some with sharpness. My standard value was 2.

Klaus -- If you are listening, could you comment on whether oversampling >2 could make a difference if it were possible in WebXR rendering? Is there any possibility that the standards might be updated to make that possible? Curiously, oversampling > 1 is possible for WebXR audio.

Hi lastromantik,

I just converted the supplied fps.xml to one that used a hotspot instead of a layer. To lock the hotspot to the screen you set flying=1. That puts it dead center but you can position it where you want with offsets ox and oy. Below is the code:



You can get a more complete idea in the documentation. Be sure to click the advanced settings button.