An unofficial build on
tig3rmast3r's v0.2.1.
A follow-up to 0.2.3_beta4 — one fix, nothing else changed.
Short version
If a game stopped starting on SteamVR since 0.2.3_beta3, take this build.
Cyberpunk 2077 through Luke Ross's R.E.A.L. VR mod was the reported case: with
the bridge armed before launch it never reached the menu.
If your games were starting fine, this changes nothing you can see. Frame
delivery, pacing, the overlay and every setting behave exactly as in
0.2.3_beta4.
If you had been working around this by arming the bridge after launching the
game, you no longer need to. Arm it before launch as usual.
What was wrong
0.2.3_beta3 fixed a crash in Assetto Corsa. The fix was to stop closing the
background connection the bridge opens to SteamVR to read the compositor's
delivered-frame counters — closing it is what killed the next VR session, so
since beta3 the connection is opened once and left open for as long as the game
runs. That part is correct and has not changed.
What it did not account for is that some VR mods start VR twice.
R.E.A.L. VR builds a short throwaway VR session at launch purely to ask the
headset what it is — field of view, resolution, which runtime is active — then
shuts the whole thing down and starts VR again for real. It does this on every
launch, on every runtime.
That throwaway session renders a single frame, and one frame was enough to make
the bridge open its connection to SteamVR. Because the connection is
deliberately never closed, it was still open when the mod started VR the second
time — and that second start never finished. The game was left waiting inside
SteamVR, with nothing to show for it.
It is also why arming the bridge after launching worked: that let the
throwaway session run with no bridge present, so nothing was left open when the
real session started.
The fix
The bridge now waits for the runtime to confirm that a session is actually being
displayed before it opens its connection. A throwaway session used only for
measurement never gets that far, so it never opens one, and the real start that
follows is unobstructed.
The Assetto Corsa fix is untouched — the connection still opens once and is
still never closed. It just no longer opens underneath a session that was only
ever going to be discarded.
Who this affected
SteamVR only, and only games or mods that shut VR down and start it again.
On VDXR, Oculus, PimaxXR and Virtual Desktop the bridge never opens this kind of
connection at all, so the fault could not occur there, and nothing about those
runtimes changes in this build.
If you use a R.E.A.L. VR mod — Cyberpunk 2077 and the other Luke Ross titles —
on SteamVR, this is the build you want. The same is true of anything else with
an in-game "restart VR" control.
Known issues
Unchanged from 0.2.3_beta4, which has the full list. The ones
most worth knowing:
- Dips are usually a resolution ceiling, not the bridge. Disarm the bridge
and play the same scene: if the dips are still there, your machine is past its
comfortable per-eye resolution. Dropping to about 0.92× removed nearly all of
them on the reporting machine. If you are reporting a dip, please say whether
it survives disarming and at what per-eye resolution — that one line saves the
most time. - Very high per-eye resolutions remain the hard limit. Above roughly 9
megapixels per eye the generated frame cannot be finished early enough to be
shown, and the bridge cannot tell that this is happening. - A very high headset refresh rate can outrun what generation can produce.
Generation doubles your game's frame rate; if double is still short of the
refresh rate the bridge fills the difference with repeats and it judders. Pick
a refresh rate close to double your game's frame rate. - If SteamVR is restarted while a game is running, the delivery counters may
stop being meaningful until the game is restarted. - Selecting the NVIDIA backend without an NVIDIA card silently does nothing.
On AMD or Intel leave the backend on FidelityFX, the shipped default.
Everything else is unchanged from 0.2.3_beta4
The SteamVR pacing work, the overlay's frame counter, the Assetto Corsa crash
fix, the D3D11 fix, the NVIDIA backend recommendation and every game-facing
setting behave exactly as described in the
0.2.3_beta4 notes.
Installing
Unzip anywhere and run OFXRBridgeTray.exe, then Arm bridge. Keep
OFXRBridgeTray.exe and the ofxr folder together. If you have an earlier
version armed, disarm it first.
Tested
- Cyberpunk 2077 through R.E.A.L. VR on SteamVR — the reported failure
to start, now fixed and confirmed by the reporter
on SteamVR with a Pimax Crystal Super OLED, on the NVIDIA OFA backend.
This is a targeted hotfix: one change, on the SteamVR-only path described above,
gated so that it cannot affect a session that reaches the headset. The rest of
the suite that ships with the source passes unchanged. The other titles listed
in the 0.2.3_beta4 notes were not re-run against this build.
This is an experimental beta and compatibility is not universal. Please report
results — working and not — on this fork's GitHub Issues, with
an OFXR flight log where you can. Enable one by setting logging_enabled=1
under [diagnostics] in ofxr_bridge.ini; logs are written next to the armed
layer under %LOCALAPPDATA%\OFXR Bridge\RuntimeLayer\v278\.