When interface is launched and steam vr is NOT running, openvr can return bad HMD poses for a few frames.
To workaround this, filter out any hmd poses that are obviously bad, i.e. beneath the floor.
* Fixed bug with input devices that where added, removed then re-added.
The default mappings were being ignored on the second add.
* Fixed potential crash when hardware inputPlugin device poses were polled from the JavaScript thread
by taking the UserInputManager lock during pluginUpdate.
* Renamed Controller.Hardware.Vive.LB & RB to LeftGrip and RightGrip, to better match Oculus touch.
* Updated resource/controller/vive.json to reflect this new mapping.
* Exposed touch pad capacitive touch events to JavaScript as
Controller.Hardware.Vive.LSTouch and RSTouch.
* Added viveTouchpadTest.js script to test LSTouch and RSTouch events.
In the unlikely event you hit 90htz in non-threaded present mode, you will have perfect tracking and latency.
This verifies that there are no other sources of tracking or rendering latency, other then the ones we already know about.
This could occur if the GLEscrow queue has extra frames in it.
When new textures were fetched, before this fix, they were simply popped from the queue.
This commit introduces a loop, that will fetch from the queue until it is empty.
* Application::idle, physics and avatar processing are tracked
* Application::paintGL frameNumber payload is tracked
* OpenGLDisplayPlugin::present is profiled with corresponding frameNumber payload
* Added color and payload support to Nsight ProfileRange class.
Also, moved updateHeadPose so that the overlay and the main rendering use the same headPose.
Which should also be the same place the latencyMarker for the ovr_GetTrackingState is set.
Before this fix, a script could call into HMD.getHUDLookAtPosition2D() while the app was shutting down, which in turn would call
getHeadPose() on the currently active display plugin. This call could cause a crash within the openvr plugin, because the SDK was either shutdown, or in the process of shutting down on the main thread.
This fixes this by spliting the previous DisplayPlugin::getHeadPose(int) into two parts:
* updateHeadPose(int) which is only called once a frame and only by the main thread.
* getHeadPose() which is thread-safe and will return a cached copy of the hmd pose sampled by the last updateHeadPose.
The AvatarHoldAction now derives the body velocity by using data from the controller::Pose. Rather then trying to derive it based on previous positions. This results in more acurate motion of the held object when the hold is released.
OpenVR input plugin: pass the velocity and angularVelocity directly from the controller pose to the controller::Pose.
Before this PR the simulation rate was clamped to never exceed 60htz.
This had problems when waving the vive hand controllers in the world,
they would jitter. The simulation rate is now clamped to never exceed
120 htz. This has the effect of synchronizing the display and the
update rates to 90htz.
Also there are improvements to vive support if threaded present is
disabled.
Extrapolate the next set of poses for HMD and hand controllers.
Currently we predict 44ms into the future, this seems too high, however
it was discovered by inspection to be the best value.
Obviously there is a source of latency that we need to track down,
however even with this latency, it is a much improved experience.
Pass a InputCalibrationData to each inputPlugin and inputDevice.
This contains the most up sensorToWorldMatrix, avatarMat and hmdSensorMatrix.
Each input plugin can use this data to transform it's poses into Avatar space
before sending it up the chain.
This fixes a bug in the handControllerGrab.js script that relied on the hand controller
rotation/positions being in the avatar frame.
* Call vr::VR_Shutdown() when ref-count goes to zero. The ref-count
is ncessary because the vr::IVRSystem poitner is shared between the
the openvr input and display plugins.
* OpenVR plugins options will display in the menu if vr::VR_IsHmdPresent() is true.
This is faster then initializing all of openvr and less likely to conflict with the
oculus display plugin.
