I really dislike '@'ing, but @RaananW, I saw those WebXR wrapper functions in session manager, so I just tried them. When moving scene, it might be helpful to slow down the rate on the old scene, and go into a scene.freezeActiveMeshes() to free up cycles.
Anyway, here is what I got. Is this to be expected?
I did a test right after getting the info, which makes me think that there is a bug that Oculus current rate is not initialized correctly. Here is the code
session.onXRSessionInit.add(()=> {
this.currentFrameRate = session.currentFrameRate;
this.supportedFrameRates = session.supportedFrameRates;
console.log('current rate:', session.currentFrameRate, '\nsupported rates:', session.supportedFrameRates);
// test changing to see what happens / is reported
session.updateTargetFrameRate(80).then(() => {
console.log('double check', session.currentFrameRate);
})
});
You now get this:
After the target rate is updated current rate is reported at 80. Also, starting to think that the supported rates are for each eye.
EDIT: I found an on device mechanism in settings to report problems. I used it. Kind of interested to see if anything happens. This is a good issue to use. If the thing is not initialized, l can just pretend it is something that I always set.
Other problems you cannot just ignore, so finding out if this is a feasible way to go with this, before.
I am not sure I follow 
We don’t officially support moving a scene when in XR (not until we take the scene out of every XR-related object), and you can change the rate whenever needed using the API provided. Or have I misunderstood your question?
Sorry, in my example I cut and pasted. I had function, which covered updateTargetFrameRate, adding a check that the frame rate was returned from the supported list, which I did not show.
Here is a PG, https://playground.babylonjs.com/#0A28NK#20, which shows the same thing.
As far as the question is concerned, do you think returning 0 from session.currentFrameRate is a Oculus issue?
We only proxy the session’s framerate:
So yes, I would assume it is oculus return 0 instead of the right rate
Thanks, you of course know that from the earliest version of the 2nd post, that I strong suspected it a WebXR level problem. Getting the person who wrote BJS XR implementation to say “they are only reporting what they got” builds a better case.
I am just spent getting my entire code base / architecture to work with multiple scenes & this re-worked pipeline. Need to play a while with the transition stuff. Here is just the Blender screenshot of what I have in mind.
Not sure what to call it:
The animation is going to be material based (in addition to the camera flying 1000 meters through it), & really cheap, if you know how to set it up. I going for a cross between jaw dropping & pants crapping.
