[VIVE] Motion Controllers in the wrong place

[Multox]

Hi, I'm new to Unreal VR development and having some trouble with motion controller positions. It was working for me in Unreal 4.24.1 but today when I upgraded to 4.24.2 the motion controllers are in the wrong place with respect to the HMD. They are consistently several feet behind and above the HMD's position. If I ResetSeatedPosition, the controllers again move to above and behind the HMD's new orientation.

Both motion controllers are attached to the VROrigin.

I tried calling SetRelativeLocationAndRotation, ResetRelativeTransform, ResetOrientationAndPosition on each of the motion controllers, but none of these have any effect.

Any suggestions or ideas?

[Starkium]

I have this same issue too.

[Noviak]

Getting the same issue.

I have a setup similar to this: https://www.youtube.com/watch?v=EKR8ogonD68 which works in 4.22, in 4.24 the position of the hands is behind and above the HMD.

Currently trying different methods of calculating any possible offsets in regards to the HMD/ VR origin that may be causing the issue, but haven't had tremendous results yet getting the controller's world position to correctly correlate with the HMD world position. Help/ insights would be appreciated.

[TrueJelly]

I had a similar issue after updating from 4.22 to 4.24. Where when using steamVR there was a noticable offset between the motion controllers' real and in-game position. Curiously, the issue was present only in editor. In builds there was no offset. What helped me was setting base rotation and position to zero with those functions: FSteamVRHMD::SetBasePosition, SteamVRHMD::SetBaseRotation

[DreyMo]

I have the same issue, VIVE motion controllers are working perfectly in 4.24.1 but in 4.24.3 they are offset above the head and not in the correct position. The same issue persists within the editor and packaged build. Anyone found a solution or is this a bug?

Edit: Did some more tests on a clean scene with the VR template, the controllers get displaced over the head as soon as the Reset Orientation and Position function is called.

[aldermark]

I have the same issue and desperately need a solution we cannot go back a version.

[aldermark]

I had a similar issue after updating from 4.22 to 4.24. Where when using steamVR there was a noticable offset between the motion controllers' real and in-game position. Curiously, the issue was present only in editor. In builds there was no offset. What helped me was setting base rotation and position to zero with those functions: FSteamVRHMD::SetBasePosition, SteamVRHMD::SetBaseRotation

TrueJelly - Did you find a workaround? what were the steps? can this be done in blueprints?

Thanks

[Tim_Flinn]

I have been working this same issue out also. The best way I can find to do it is to make another scene component on the same level as the VROrigin and place the motion controllers to the new scene component. This allowed me to have the "scene origin" for the motion controllers to be able to move independently from the VROrigin. One of the things that is weird though is the second scene component "MCOrigin" in my case seems to do some weird 45-degree camera offset for the VROrigin even though they are independent of each other.

Not saying this is the fix but another idea on the approach.

[aldermark]

Tim_Flinn thanks for posting - Interesting - when my pawn is first appeared its about 150 units above where it should be , using reset origin moves you to 0 but puts the hands in the old place and is useless. When I manually offset the pawn down using a set relative position both do move , but because its offset things like widgets are all incorrect and if your pawn is then moved onto another object - in my case a flying animal the position gets skewed because of the offset. Its the SteamVR plugin doing this - the oculus is perfect like before. looks like months before epic can fix it and we have a live game so need to figure out a workaround... if your pawn is not flying around my fix may work for you..

I'm going to try to play with spring arms and see if that helps.

[Tain]

Unfortunately I'm running into this as well. Wondering if I might have to roll back to 4.24.1 for now.

[yomunecominami]

I have fixed the following code in my local engine.
The absence of "return" was obviously unnatural.

void FSteamVRInputDevice::Tick(float DeltaTime)
{

    ...

    else if(SteamVRHMDModule && SteamVRHMDModule->GetVRSystem())
    {
        // Cache the controller transform to ensure ResetOrientationAndPosition gets the correct values (Valid for UE4.18 upwards)
        // https://github.com/ValveSoftware/steamvr_unreal_plugin/issues/2
        if (GEngine->XRSystem.IsValid() && SteamVRHMDModule && SteamVRHMDModule->GetVRSystem())
        {
            CachedBaseOrientation = GEngine->XRSystem->GetBaseOrientation();
            CachedBasePosition = GEngine->XRSystem->GetBasePosition();

            //@third party code - BEGIN Fix SteamVR MotionController Transform Bug.
            return;
            //@third party code - END Fix SteamVR MotionController Transform Bug.
        }
    }

    CachedBaseOrientation = FQuat::Identity;
    CachedBasePosition = FVector::ZeroVector;
}

[Tain]

I have fixed the following code in my local engine.
The absence of "return" was obviously unnatural.

void FSteamVRInputDevice::Tick(float DeltaTime)
{

...

else if(SteamVRHMDModule && SteamVRHMDModule->GetVRSystem())
{
// Cache the controller transform to ensure ResetOrientationAndPosition gets the correct values (Valid for UE4.18 upwards)
// https://github.com/ValveSoftware/steamvr_unreal_plugin/issues/2
if (GEngine->XRSystem.IsValid() && SteamVRHMDModule && SteamVRHMDModule->GetVRSystem())
{
CachedBaseOrientation = GEngine->XRSystem->GetBaseOrientation();
CachedBasePosition = GEngine->XRSystem->GetBasePosition();

//@third party code - BEGIN Fix SteamVR MotionController Transform Bug.
return;
//@third party code - END Fix SteamVR MotionController Transform Bug.
}
}

CachedBaseOrientation = FQuat::Identity;
CachedBasePosition = FVector::ZeroVector;
}

Thank you! I'll have to give this a shot later.

[aldermark]

This is the official latest from Epic:
We've found a fix for the bug that you should be able to cherry-pick onto a source build of the engine:

Open the source file Engine\Plugins\Runtime\Steam\SteamVR\Source\SteamVRInputDevice\Private\SteamVRInputDevice.cpp

In the function FSteamVRInputDevice::Tick look for the following two lines at the end of the function:

1. CachedBaseOrientation = FQuat::Identity;
2. CachedBasePosition = FVector::ZeroVector;

Change those lines to:

1. else
2. {
3. CachedBaseOrientation = FQuat::Identity;
4. CachedBasePosition = FVector::ZeroVector;
5. }

That should resolve the issue.
-------
You will need to use a source version of the engine from github.

-----
My Issue now less about the reset but rather that each hand Rotation is different for Vive, index and Rift - Anyone else seen that? I'm going to have to write some code to rotate each mesh differently for each HMD (and also get users to identify their setup as there seems to be no sure way of doing it). Has Anyone seen this? Searches come up empty.

[bmahlbrand]

Has this issue been confirmed to be solved in 4.25.4?