Skip to content

Implement poses functions with "seconds from now" - #245

Open
xytovl wants to merge 2 commits into
Supreeeme:mainfrom
xytovl:GetPoseActionDataRelativeToNow
Open

Implement poses functions with "seconds from now"#245
xytovl wants to merge 2 commits into
Supreeeme:mainfrom
xytovl:GetPoseActionDataRelativeToNow

Conversation

@xytovl

@xytovl xytovl commented Dec 5, 2025

Copy link
Copy Markdown
Contributor

OpenXR doesn't natively have a concept of "now", but has extensions to convert OS time to XrTime so that we can implement relative time ourselves.

GetPoseActionDataRelativeToNow is used for instance in The Lab, the change does however not fix the hand movement which is still not smooth.

@xytovl
xytovl force-pushed the GetPoseActionDataRelativeToNow branch from f5063f4 to 549cd76 Compare December 5, 2025 07:25
@xytovl xytovl changed the title Implement GetPoseActionDataRelativeToNow Implement poses functions with "seconds from now" Dec 5, 2025
@xytovl

xytovl commented Dec 5, 2025

Copy link
Copy Markdown
Contributor Author

I could test GetPoseActionDataRelativeToNow in The Lab, which doesn't make any visible change.
I don't know of games that use GetDeviceToAbsoluteTrackingPose, so I'm not sure how to test that change.

@xytovl
xytovl force-pushed the GetPoseActionDataRelativeToNow branch 2 times, most recently from 8caf88e to 2a30a5c Compare December 5, 2025 08:21

@Supreeeme Supreeeme left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could use a test if you're up to writing one, if not I'll write it myself.

Comment thread src/input.rs Outdated
Comment thread src/input/devices.rs
session_data: &SessionData,
origin: vr::ETrackingUniverseOrigin,
) -> Option<vr::TrackedDevicePose_t> {
let nanos = xr_time.as_nanos();

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not have the pose cache be Mutex<HashMap<xr::Time, TrackedDevicePose>>?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It complained that xr::Time was not hashable:

   Compiling xrizer v0.3.0 (/home/xytovl/projects/xrizer)
error[E0599]: the method `get` exists for struct `std::sync::MutexGuard<'_, HashMap<openxr::Time, TrackedDevicePose_t>>`, but its trait bounds were not satisfied
  --> src/input/devices.rs:91:40
   |
91 |         if let Some(pose) = pose_cache.get(xr_time) {
   |                                        ^^^ method cannot be called due to unsatisfied trait bounds
   |
  ::: /home/xytovl/.cargo/git/checkouts/openxrs-419b52284129469d/d0afdd3/sys/src/lib.rs:46:1
   |
46 | pub struct Time(i64);
   | --------------- doesn't satisfy `openxr::Time: Hash`
   |
   = note: the following trait bounds were not satisfied:
           `openxr::Time: Hash`

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah. In this case I'd prefer if a type like this was defined:

#[derive(PartialEq, Eq, derive_more::From, Copy, Clone)]
struct Time(xr::Time);

impl Hash for Time {
    fn hash<H: Hasher>(&self, state: &mut H) {
        self.0.as_nanos().hash(state);
    }
}

Then you should be able to use it like:

pose_cache.get(&Time(xr_time))
pose_cache.insert(Time(xr_time))
// etc

Comment thread src/input/devices.rs Outdated
Comment thread src/system.rs Outdated
@xytovl
xytovl force-pushed the GetPoseActionDataRelativeToNow branch from 2a30a5c to ad68355 Compare December 6, 2025 21:13
@xytovl

xytovl commented Dec 6, 2025

Copy link
Copy Markdown
Contributor Author

This could use a test if you're up to writing one, if not I'll write it myself.

What would you test? The cache mechanism, relative time, fallback if openxr now is not available?
I am not familiar with rust yet, so I'm not sure how to mock the instance method.

@Supreeeme Supreeeme closed this Dec 7, 2025
@Supreeeme Supreeeme reopened this Dec 7, 2025
@Supreeeme

Copy link
Copy Markdown
Owner

What would you test?

Relative time. Check that the poses returned from GetPoseActionDataRelativeToNow( and GetPoseActionDataForNextFrame actually differ, and that it returns the right pose basically.

The way xrizer handles tests is primarily unit testing each interface with a mocked OpenXR runtime, this fake runtime lives in the fakexr directory. If you look at the code in there you can see it's just implementing all of the relevant OpenXR functions from the runtime side. So you can add whatever helpers you need and just call the OpenVR functions like an application would. The input tests specifically live in src/input/tests.rs, they should be insightful at least.

@Supreeeme Supreeeme closed this Dec 7, 2025
@Supreeeme Supreeeme reopened this Dec 7, 2025
@Supreeeme

Copy link
Copy Markdown
Owner

Sorry I keep accidentally closing it lol

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants