Work in (static) standing universe instead of raw. #24
Conversation
|
Current status of pull request (summarizing discussion that was previously only on Discord): This PR doesn't actually produce "true" standing universe according to applications using openvr, primarily because of OVRAS' playspace mover. There may be other exceptions. However, this actually ends up being somewhat beneficial, since SlimeVR has multiple (potential) features that benefit from floor level actually being at y=0, so I think we're likely to move ahead with the current implementation. The blocking problem comes back to it not actually being standing universe, which means that the feeder app would become incompatible until updated. I've started working on an update to the feeder app to fix this, but I'm having... weird issues with parsing the JSON file. I need to get back to that. Worst case, I can do exactly what I'm doing here in the driver, trawling the filesystem, but that shouldn't be necessary. That said, I suppose it is technically ready for review/merge, since feeder app is still technically optional. As much as I want feeder app to also be ready before this goes in, I'm not sure that it makes sense to block it.
|
| // TODO: set this once, somewhere? | ||
| pose.vecWorldFromDriverTranslation[0] = -trans.translation.v[0]; | ||
| pose.vecWorldFromDriverTranslation[1] = -trans.translation.v[1]; | ||
| pose.vecWorldFromDriverTranslation[2] = -trans.translation.v[2]; | ||
|
|
||
| pose.qWorldFromDriverRotation.w = cos(trans.yaw / 2); | ||
| pose.qWorldFromDriverRotation.x = 0; | ||
| pose.qWorldFromDriverRotation.y = sin(trans.yaw / 2); | ||
| pose.qWorldFromDriverRotation.z = 0; |
There was a problem hiding this comment.
This is something that doesn't actually need to be checked/set every single time we send the pose, we could just do something to update it every time we detect a change instead.
| // TODO: Test on OSX/Linux, because our build system is probably not outputting the macros that this wants for them. | ||
| // I already had to change WIN32 to _WIN32 for the initial include of windows.h |
There was a problem hiding this comment.
I believe this is technically a regression in cross-platform compatibility (which is somewhat important because i know of at least two efforts to provide an alternative to windows specific named pipes for other platforms), but I don't think it should be too difficult to either update the build system or find the correct defines to use with #ifdef when the time comes.
| // TODO: This is licensed under BSD 3-Clause which is compatible with MIT, | ||
| // but we should probably do something to ensure we comply with clause 2. |
There was a problem hiding this comment.
Clause 1 is already fulfilled because of the notice i left in source under this comment, but we may want to add a file to the driver containing license information if not already present to fulfill clause 2, or add something to the server UI mentioning libraries used by various components.
I think something similar also applies to the simdjson library I'm using here. It's Apache 2, which should also be compatible, but similarly requires a license notice.
|
A sketch for testing guidelines, since I don't feel like re-typing everything out again: Users should use the current version of the feeder app, with the Users should also test against a broad variety of headsets, given a driver-level difference we already found with the oculus quest. So far, the valve index appears to work, as does the oculus quest (tested with both AirLink and Virtual Desktop, though i should note that Virtual Desktop appears to provide raw space as standing space, meaning there is no difference). On my/our end, we need to setup a list of headsets that have been tested/have yet to be tested, as well as provide a driver build to put on said list for users to download. We need to add (or link to) instructions on how to replace the driver with the testing version. |
|
TBH, with feeder and driver using (almost) the same logic to derive standing space, it feels less critical that we test many headsets for mismatches between standing space and our static-standing space. that may just be my desire to not run a testing program speaking, though. |
e2f83f1
to
d6435df
Compare
This isn't quite there yet. I think the rotation is still subtly incorrect, which means there's a slight rotation leftover somewhere.
in the end i was trying to rotate by half the angle i was supposed to, D'oh!
Either I never actually tested current driver state on my current state or feeder app is pulling in a different version of simdjson that is more strict.
c9ee80e
to
eed1aa2
Compare
|
Have been testing this in practice and it works well, I never had many problems but this PR doesn't cause any, would really love to see it merged |
|
ok lesgo |
This reverts commit 25f0417. Since SlimeVR/SlimeVR-OpenVR-Driver#24 has been merged, match the universe introduced there. Will create release once a driver release has happened.
|
Ping me when a release of the driver comes out and I'll post a release of the feeder app to update its defaults to match. |
Fixes #20.
This seems to work on my machine, but I'd like some additional testing from other people with other headsets, like oculus ones, and on beta/non-beta, etc., before merging, as well as properly making sure that taking input is happening correctly, how well it interacts with OVRAS (works fine on my end, idk if there's something that will cause it to break though)