github djules75/OFXR-Bridge 0.2.11.1
OFXR Bridge v0.2.11.1 (V414) - VD Fix

latest releases: 0.2.14.3, 0.2.14.2, 0.2.14.1...
one month ago

If v0.2.1 felt smoother than recent versions on your Quest 3, this release
fixes it.
On Virtual Desktop, frames now go out as evenly as they did in
v0.2.1, and games hold the same frame rate, so it should feel at least as
smooth as v0.2.1.

Built on
tig3rmast3r's v0.2.1.
This release also stops a slow loss of frame rate on every runtime except
SteamVR.

Warning

Pimax headsets: use SteamVR, not Pimax OpenXR. Pimax Play's OpenXR
runtime keeps an extra copy in VRAM of every image it is handed, so OFXR
costs about 1.5 times more on it than on SteamVR, and the copies stay
until the game closes. We have reported it to Pimax so they can fix their
runtime; there is nothing OFXR can do about it in the meantime. Until it is
fixed, run your Pimax through SteamVR with
sboys3's native SteamVR driver
and make SteamVR the active OpenXR runtime (SteamVR → Settings → OpenXR).
This matters most in MSFS 2024, which is already close to the VRAM limit
at Pimax resolutions. Details in the
troubleshooting guide.

🛠️ Not working, or not feeling smoother?

➡️ Read the troubleshooting guide first

It checks in one step whether OFXR is running in your game, then lists the
usual causes and fixes: OpenVR games, running as administrator, the game's
frame rate, frame smoothing in your VR software, and running out of VRAM.

What's new

Smoother on Virtual Desktop

In some games, v0.2.10.1 sent frames to Virtual Desktop unevenly: at 90 Hz,
a generated frame and the real frame after it went out about 6 ms apart,
then nothing for 17 ms
, instead of evenly every 11 ms. The FPS counter
still read about 90, but motion looked choppy, and the game could fall a few
fps below half the headset's refresh rate.

It happened in games that need more than one display frame to render, which
are the heavy ones you would turn frame generation on for, and it is why
v0.2.1 could feel better: it did not have the problem.

OFXR now keeps its own steady clock on Virtual Desktop, as v0.2.1 did. In
the worst case reported, up to 90% of frames went out unevenly and the
game ran at 42 fps. In our tests on a Quest 3 through Virtual Desktop at
90 Hz, including two-minute sessions in MSFS 2024, v0.2.11.1 sent under
1%
unevenly, frames went out 11 ms apart, and games held 45 fps (half
of 90) from start to finish.

No more slow loss of frame rate

On Virtual Desktop, Pimax OpenXR and every runtime other than SteamVR,
v0.2.10.1 kept adjusting when the game was allowed to start its next frame,
and the adjustment only ever grew. In heavier games it could take a game
that held 45 fps at 90 Hz down to 39–41, and it could appear minutes into
a session. That adjustment is gone.

Nothing changes on SteamVR

Neither change touches SteamVR. Its pacing is the same as in v0.2.10.1.

Known issues

  • Your game has to reach half your headset's refresh rate (45 fps at
    90 Hz, 50 at 100 Hz) for every frame to come out evenly. Below that, some
    generated frames still have to wait for the game. If a game cannot get
    there, choose a lower refresh rate or lower its settings.
  • Check your real per-eye resolution. SteamVR's global resolution and a
    per-game resolution multiply: 200% global with 200% for the game gives
    four times the pixels, and OFXR's memory grows with them. The
    troubleshooting guide explains how to read the real value from a flight
    log.
  • SteamVR: turn off Motion Smoothing and "fixed frame rate at half" for
    the game
    in SteamVR's per-application video settings. They fight with
    OFXR's own pacing.
  • No FPS overlay in Vulkan games.

Installing

Unzip anywhere and run OFXRBridgeTray.exe. It arms the bridge by itself.
Keep OFXRBridgeTray.exe and the ofxr folder together; it holds the OpenXR
layer, its settings and the Vulkan layer. If an earlier version is armed,
disarm it and close its tray first.

Please report results, working or not, on this fork's
GitHub Issues, with an OFXR flight log where you can. To
record one, enable Bridge flight recorder in the tray, reproduce the
problem, then use Open bridge logs. Logs are written under
%LOCALAPPDATA%\OFXR Bridge\RuntimeLayer\v414\. Read the
troubleshooting guide first: most problems are
solved there in a few minutes.

Don't miss a new OFXR-Bridge release

NewReleases is sending notifications on new releases.