HandColliderLeft/Right lags behind hand movement | SteamVR Unity

[mukobi]

I'm trying to build a seated space dogfighter game in Unity 2019.3 with the SteamVR Unity plugin where the ship is controlled by physically grabbing and touching controls in the cockpit.

I am using the SteamVR Player prefab from the Interaction System, but the trouble I'm running into is that when the Player GameObject is moving forward rapidly, the SteamVR HandColliderLeft and HandColliderRight GameObjects (instantiated by the HandPhysics.cs component on each hand) that are responsible for collision end up lagging behind the controller and render model positions, so although it looks like I'm touching the controls of the ship, the hand colliders are many meters back and nothing can accurately be grabbed.

To replicate, simply add the Player prefab to a new scene, enter play mode, and select the Player->HandColliderLeft/Right(Clone) GameObjects so their colliders show up in the scene view, then watch the colliders lag behind the hand model when the hand is moving. This is easiest to see when the Player prefab is moving at least around 20 meters per second, but you can also just shake your hand fast and the colliders won't always line up.

Does anyone know how to get around this issue? I simply can't find anything about HandPhysics.cs or HandCollider.cs online, and this issue is pretty critical to the game I'm building which makes development a bit frustrating. Could this issue be solved by editing some SteamVR code (maybe in Hand.cs, HandPhysics.cs, or HandCollider.cs) so that the HandColliderLeft/Right objects snap to the actual hand position?

If you're able to give any help, it would be much appreciated!

[xand7]

Hello there,

Relative beginner here twiddling about with VR. I've been having similar issues with the hand colliders. I've got it hooked up to VRTK to use VRTK climbing and have continunally had the hand lagging issue alongside various other issues integrating it with the climbing system whilst maintaining the hand physics.

Possibly what I've got to say might not be useful to you but I'll relay it anyway. In the HandCollider.cs within ExecuteFixedUpdate() there is an if/else depending on a collidersinradius boolean which for me was constantly true because the hands were collding with themselves. I set the collision mask properly via handcollider.cs so that the hands weren't colliding with themselves and then the boolean was false when away from an actual collision.

With this boolean as false the script here instead of instigating any physics just moves the hands to wherever they are supposed to be. From what I can gather it's checking to see if there is anything to collide with near and if there is turning on the hand physics.

Sorting out that collision mask mitigates the issue with the hand lagging somewhat by effectively turning off the hand physics until it is needed. It's weird to me that's what is in the Valve HandCollider.cs but I guess fair enough. Obviously this isn't really a great solution but I haven't found a better one yet. Please update this thread if you come across some sort of wholehearted resolution to this issue.

[ghostcat51]

I have the same problem and hope there is a solution

[mukobi]

In my limited testing, I haven't found a good way around this issue. It seems like there is something fundamentally weird with how the SteamVR hand colliders and programmed to work with Unity's physics update system. My best hope is that the Unity XR plugin that valve is supposedly working on will have improvements in that regard.

In the meantime, I have been dealing with it by not dealing with it. In my space dogfighter, instead of the player moving through space with a velocity v, everything else moves through space with velocity -v in addition to their normal velocities. Additionally, certain particle effects have to be passed in the player's velocity each frame to give the illusion of forward movement. It's all very hacky, and I don't recommend it for most VR games where a lot of your scene contents should be static, but it works for me for now.

Or you can use another plugin like the Oculus integration or VRTK.

[Monkis74]

I'm working on a racing game, and running into this same issue. If my hand is on the wheel (parented to the wheel) it behaves just fine, but if I let go it lags badly, and I cannot grab anything again until I stop the motion.

[tcwatson]

Beginner here, I'm also experiencing this issue, making a game where a player flies a ship. The ship has a rigidbody and is moved by adding forces to it, and the forces are controlled by physical objects like a throttle and steering wheel.

Once the ship starts moving, the hands start jittering quite a bit and lagging behind the actual tracked controllers, and I can't grab anything. Additionally, seemingly another symptom of the same problem, if the ship is rotated around, the circular drive that controls my steering wheel gets very buggy to try and grab, even when the ship isn't moving otherwise. This is difficult to explain, but after some rotation has been applied to the ship, grabbing the steering wheel and then moving my hand clockwise around the wheel results in the wheel rotating counterclockwise, and vice versa. Then after a short rotation, the hand stops "grabbing" the wheel, presumably because it's now too far away from its original grab point.

Is using the SteamVR plugin for Unity still the recommended approach with Unity XR on the horizon?

[mukobi]

Beginner here, I'm also experiencing this issue, making a game where a player flies a ship. The ship has a rigidbody and is moved by adding forces to it, and the forces are controlled by physical objects like a throttle and steering wheel.

Once the ship starts moving, the hands start jittering quite a bit and lagging behind the actual tracked controllers, and I can't grab anything. Additionally, seemingly another symptom of the same problem, if the ship is rotated around, the circular drive that controls my steering wheel gets very buggy to try and grab, even when the ship isn't moving otherwise. This is difficult to explain, but after some rotation has been applied to the ship, grabbing the steering wheel and then moving my hand clockwise around the wheel results in the wheel rotating counterclockwise, and vice versa. Then after a short rotation, the hand stops "grabbing" the wheel, presumably because it's now too far away from its original grab point.

Is using the SteamVR plugin for Unity still the recommended approach with Unity XR on the horizon?

IMO, the best away around this problem is to not built a VR game where the player is rapidly moving and they use their hands to grab things. Unfortunately, I've found no good way around it (as I said earlier, I implemented my system by having the player's position stationary and everything else moving relative to them, but that won't work well for most games). It seems like there are so many issues with this native SteamVR Unity plugin in combination with Unity's physics system that I'd recommend you avoid it for now.

If you check out the UnityXRPlugin branch, there's already a beta plugin for the new Unity XR system that you can try. I haven't tried it yet and since it's in beta it's not supposed to be used for production, but you could try and switch over to it (since Unity XR is the immediate future of SteamVR support in Unity). It seems like they just ported over this native OpenVR plugin to work within the Unity XR system, so I wouldn't expect the SteamVR input system to solve your problem here, but what you could try is using the beta SteamVR Unity XR plugin just to get the tracking and audiovisual input/output to your OpenVR headset but use the Unity XR Interaction Toolkit for things like hands, circular drives, etc.

[gregoryblood]

I think I found a solution. Edit the Maximum Allowed Timestep to the Fixed Timestep. You may also need to disable locking the Fixed Timestep to frame time inside of SteamVR Settings.