Oculus Frame Rate Reporting

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:
Oculus frame rates & check
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 :slight_smile:

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:

  • A worm hole
  • A first person interpretation of long distance teleporting

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.