Repository navigation
Conversation
The headset decides the real field of view while the game keeps believing its own. A game that draws its first person geometry through a separate field of view has to be told the real one, otherwise that geometry is distorted and drifts against the world. This is what the weapon looks wrong in VR problem comes down to in The Outer Worlds 2, where the pawn has its own WeaponFOV. get_ue_projection_matrix already carries the information, but recovering angles from it means knowing how the matrix is laid out, so the conversion is done here once rather than in every script that needs it. Returns a flat table with left, right, up and down as signed angles plus the horizontal and vertical totals. The halves are kept separate because asymmetric projections are normal in VR: on a Quest 3 one eye reads left -54 and right 40, and averaging that away loses the part a script needs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds
vr.get_projection_fov(eye). Returns a flat table:left,right,up,downassigned angles, plus
horizontalandverticaltotals.What it is for
The headset decides the real field of view, the game keeps believing its own. That is fine
until the game draws its first person geometry through a separate field of view, which is
common: the weapon in view is often rendered with its own FOV so it does not distort at wide
camera angles. That value stays at whatever the flat game picked, so in VR the weapon does not
match the world, and it drifts against it when you move.
In The Outer Worlds 2 the pawn has a
WeaponFOVfunction, and feeding it the headset's realhorizontal FOV is what fixes the weapon. My script does:
A hardcoded number does not work here. The advertised figure for a headset is binocular, the
union of both eyes, while each eye gets an asymmetric cone rotated outward. On my Quest 3 the
left eye reads
left -54,right 40, so one view gets 94 horizontal, and 94 is the number thegame needs. It also changes when the user touches the projection settings in the UEVR menu, so
a script has to re-read it rather than cache it once.
Why not just read the matrix
get_ue_projection_matrixalready carries this. But getting angles out of it means knowing howthe matrix is laid out:
with
landbnegative, which inverts tor = (1 - m[2][0]) / m[0][0]andl = (-1 - m[2][0]) / m[0][0], same shape vertically. That is fine to do once, less fine torepeat in every script that wants an angle. So it is done here, and the halves are kept
separate rather than averaged, because asymmetric projections are the normal case in VR.
Returns nil if
m[0][0]orm[1][1]is zero, so a script does not get a bogus angle out of anuninitialised projection.
Tested
Release build, The Outer Worlds 2 on a Quest 3 over OpenXR. Straight from my log:
Feeding
horizontalintoWeaponFOVlines the weapon up with the world.