Conversation
meir
force-pushed
the
main
branch
2 times, most recently
from
1ab2c2d to
c41b5f4
Compare
|
Tested, works in SteamVR now, however there is a bug where the DragReset puts you under the floor and away from the center for some reason, but that lies in the DragReset method |
|
If you want to look further into this, here's some info: Moving the playspace on SteamVR consists of moving the actual chaperone (the boundary thing that your draw during steamvr room calibration). When uncalibrated, the chaperone sits at the raw center of the playspace. (This is likely what it resets to as of now.) Upon room calibration, the chaperone is saved to a file somewhere, and SteamVR will use this calibration for the chaperone on next launch. Instead of resetting the chaperone by clearing its transform, we want to revert it to the pose that's in the calibration file. There's an OpenVR method that seems to do just what we need: IVRChaperoneSetup::ReloadFromDisk |
|
ahh alright, i'll see tomorrow if i can figure it out, might need to check my actual boundary in SteamVR aswell, i might have it improperly set since OVRAS sometimes broke it and i got sick of fixing it each time it happened |
|
couldn't really stop thinking about it, especially since ive recently started learning rust so got a bit too excited about it but looked into it and ReloadFromDisk wouldnt work since the CommitWorkingCopy would override the saved chaperone, this would technically mean that its overwritten entirely even between restarts, so i changed it out for the previewing the working data so that the saved chaperone stays in tact and does not get ruined However this does come with another bug, it's only visual and not breaking, but when the preview is showing, the chaperone bounds will just fly away, but the actual playspace goes in the correct position I'll look later into why this might be happening |
|
found the issue with the boundaries flying off, adding an offset to them was breaking it, apparently steamvr already sets the offset when previewing the working set. |
|
i'm not sure what the nix part is about, we're already included in: https://github.com/nix-community/nixpkgs-xr if it's needed then please make it into its own PR |
|
i added the nix flake for local development, the flake in nixpkgs-xr builds a specific git branch, the one i added is to run/build the local code using nix |
|
it is probably better to override the wlx package just like nixpkgs-xr does, im not sure if theres another option in nix to do local development using the nixpkgs-xr |
|
removed the nix flake and squashed down the commits into one i'll make a second pr later tonight with additions for a nix flake for local development on NixOS |
|
found another issue before this pr gets merged, when moving, any windows shift with you, when resetting they dont, i'll figure this out later today |
|
changed how the space drag moves the overlays, added an offset value to the overlay data instead which can in turn be easily reset instead. Tested in SteamVR, works exactly as expected |
Space reset ovr
|
Thanks, it's starting to look pretty good. Some ideas from me: Let's keep We should store the inverse offset so that from the effective transform, we can calculate the original transform (and offset) when needed. Since these offsets are only needed for SteamVR, let's store them in OpenVrOverlayData. ( |
…instead of applying it to the translation
Space reset ovr
…instead of applying it to the translation
|
alright, those changed are made, indeed its a better way of handling this. i'll have to test if this build works, i'll give an update when i have done so |
|
tested it out yesterday, everything seems to work like a dream |
|
just pushed a commit to main that will fix your checks |
src/backend/openvr/lines.rs
Outdated
| override_width: true, | ||
| image_view: Some(self.view.clone()), | ||
| image_dirty: true, | ||
| offset: Affine3A::IDENTITY, |
There was a problem hiding this comment.
Is this needed? Lines are only ever used for pointer lasers, and their transforms are recalculated every frame.
There was a problem hiding this comment.
no it is not, not sure why i added this, i'll fix this after testing the space rotate tonight so i can keep it in the same commit
| overlay.data.offset.translation = | ||
| overlay_transform.transform_point3a(overlay.state.transform.translation); |
There was a problem hiding this comment.
Have you had a chance to test the behavior of this with a space_rotate'd playspace?
I would wager you might run into issues when rotations are involved.
The equivalent matrix operation would be something along the lines of:
overlay.data.offset = overlay_transform * overlay.state.transform
There was a problem hiding this comment.
ah, i completely forgot about this, i never really use space rotate, i'll test this out tonight
There was a problem hiding this comment.
One of the things about space rotate is that the space actually rotates around the center of the playspace, but we make it seem as if it's rotating around the HMD.
This is done by counter-adjusting the offset position to keep the HMD in the same position. I believe this will mess stuff up.
At the very least, you'd need to also write the offset from the space_rotate logic.
There was a problem hiding this comment.
tested this out yesterday, 2 things to note
- the reset is indeed broken, so ill update this with some code to account for rotation
- the rotation of the overlays seems to be broken aswell, they do move, but dont rotate with the space rotate, so ill look into this aswell
2 participants
Tried to add the spacedrag bindings in SteamVR yesterday but found out the option for the space reset is missing.
This should add it in SteamVR.
Will have to test when i get back home, ill keep the PR in draft until ive managed to test it.