WebXR Input Source: linear velocity #3060
Conversation
|
How about returning a zero vector if it is not available? This would match the behavior we get when trying to read the velocity of a kinematic or static rigidbody in physics. |
There are input sources that have no such concept as position, for example: touch in AR session, or voice commands input source, or gaze style input source. So we should not provide linear velocity for such types, just like we don't provide position and rotation data for such input sources. So it stays consistent for XR input source concepts. |
…rowser implementation
src/xr/xr-input-source.js
Outdated
| * @description Get the linear velocity (units per second) of input source if it is handheld ({@link XrInputSource#grip} is true). Otherwise it will return null. | ||
| * @returns {Vec3|null} The world space linear velocity of handheld input source. | ||
| */ | ||
| getLinearVelocity() { |
There was a problem hiding this comment.
We already have RigidBodyComponent#linearVelocity. Should this be a property too?
There was a problem hiding this comment.
Fair enough, but whole XR APIs uses function notation. Also it is only a get function, there is no way to set linear velocity as it is sourced from underlying APIs.
There was a problem hiding this comment.
Then it would just be a getter property. No requirement to have a setter. Functions are fine for getPosition/setPosition etc to mirror the function on GraphNode but generally, we should use properties where it makes sense.
There was a problem hiding this comment.
If we want to use properties, then all other methods would need to be changed for consistency reasons. Preferring a consistent design for WebXR APIs.
There was a problem hiding this comment.
The WebXR APIs shouldn't define their own API style. There should be an engine-wide style. If the WebXR APIs don't adhere to that, we can gradually migrate and alias to something that is consistent with the overall engine. Especially while the WebXR spec is in flux.
There was a problem hiding this comment.
I've used get* style which is in line with Entity and other APIs. And as mentioned before, this is not settable property like in rigidbody's case.
This particular method can be changed to match very specific case of rigidbody.
Then should we change: getOrigin and getDirection of XrInputSource to be similar to Ray, but again mentioning: origin and direction of input source cannot be set by developer, and provided by an API. Also they do call a function inside to update transform, just like GraphNode.getPosition does.
And regarding getPosition and getRotation, should we change them to simply: position and rotation?
To be honest, it is already not consistent within engine, but it is very clear that if it is a property - then it can be set. In XR case, those methods cannot be set, they only provide data.
There was a problem hiding this comment.
There are a large number of gettable but not settable properties in the API. Just check out GraphNode for example:
https://developer.playcanvas.com/en/api/pc.GraphNode.html#children
Read-only properties are 100% OK.
getPosition and getRotation could be aliased to position and rotation maybe. I think it's a little complicated and needs some serious thought.
TBH, we should probably improve Ray and have the XrInputSource provide a Ray instead of separate origin and direction.
There was a problem hiding this comment.
We can definitely start a discussion and do WebXR-wide refactor, with such changes. Some companies already using WebXR for development, and soon we need to consider backwards compatibility.
Development for Oculus Quest is already a commercially viable path.
Also developing for Chrome Android only - is commercially viable too.
mvaligursky
removed
the
release: next minor
|
Would love to get a second look at this PR, so it can be merged/resolved. |
Linear Velocity has been added for handheld devices in WebXR specs: https://pr-preview.s3.amazonaws.com/cabanier/webxr/pull/1182.html#dom-xrpose-linearvelocity
This also been implemented in the latest Oculus Browser: https://twitter.com/rcabanier/status/1377459759876505606
This PR implements input source linear velocity and also emulates it with the same logic if it is not available/supported.
So if the input source has a grip space - we guarantee to provide linear velocity.
It can be used for reliable throwing and distant grabbing mechanics as well as using for physics to simulate insertion/weight.
New APIs:
I confirm I have signed the Contributor License Agreement.