Eye Level Tracking not working in UE4.24
elitenas opened this issue · comments
Hi,
I am trying to use eye level tracking in SteamVR for seated mode but it seems to put the camera on the ground even after adding a scene component with the correct location and attaching motion controllers and camera to it. It works fine on console and oculus sdk. I can provide a reproducible bare bone project for this if needed.
@kisak-valve can you transfer this please to the unreal plugin repo, thanks!
@pixelcitystudio was your setup according to all the configuration as described in this ue4 documentation?
https://docs.unrealengine.com/en-US/Platforms/VR/SteamVR/HowTo/SeatedCamera/index.html
If so, yes, can you send us your test project?
Thanks,
Rune
Hi,
Please see the attached project. This is default project from epic with OculusVR plugin disabled. My camera is on the right level but my motion controllers attached mesh is in the air above me.
If you enable OculusVR plugin and test with that... it works fine.
Let me know if you have any questions or want to get on a quick call to discuss more. Thanks!
Ah this bug exists only in 4.24 and maybe versions before that. It is fixed in 4.25. Do you have the commit that fixed it? Please let me know.
@1runeberg 4.25 fixes the initial issue of base pose caching but one still cannot switch back and forth between eye level and floor level as seen in this logic below
@1runeberg fixed the issue https://github.com/EpicGames/UnrealEngine/pull/7059. Please review 😄
Hi @pixelcitystudio - sorry this got caught in the weekend.
Anyways, there doesn't appear to be any issues with 4.24.3 using the reccomended seated setup instructions from the official UE documentation.
If you're flipping between seated and standing as in your sample code, have you tried also resetting the RelativeLocation back to FVector(0)?
As for the PR - we don't have any control on Epic code, we do help maintain the Input portion of the plugin, but the hmd part, you need to followup directly with Epic whether they will accept these changes.
But I suggest trying out out simply zeroing your relative location if you're doing a flip/flop scenario like in your screenshot.
The PR fixed the issue... so I will close this issue. Perhaps someone else can try with SetRelativeLocation as well.
Just for clarity on anyone who comes along this issue in the future, flip flopping between seated and standing should be doable just in BP with no engine changes with either 4.24.3 or 4.25.1 (if using the setup from Epic games as per their documentation):
This doesn't really add any additional logic to the recommended Epic setup, just remembering to reset the relative location added during seated setup. Tracking universe from SteamVR side is unaffected.
@1runeberg With the above method, SetRelativeLocation will need to be manually set on beginplay for each character and would be a bit hacky in my opinion. Oculus and PSVR reset the offset when switching from eye level to floor. SteamVR is the only one not doing so.
Not sure what you mean @pixelcitystudio - its essentially the same bp you posted but just remembers to reset the relativelocation if you're flip-flopping as per your sample code.
the bug seems to be in the BP implementation, as forgetting to reset the relativelocation will have your camera stuck with the offset when flipping back to floor level from eye level.
everything else should be as designed. your PR seems to do the same thing which simply hard resets the location to 0, but doing it in-engine instead of in-project.
But Epic can decide if they want to incorporate and shift responsibility of a reset to in-engine instead of in-project - take note though the relativelocation was added in BP in the first place, not in-engine so not sure if resetting in-engine would be appropriate in this scenario and if it would impact titles that needs/needed this level of control on the project/bp side, but this isnt our call :)
a "proper" solution for this imo is to not require the additional offset at all somehow for the recommended setup, but unsure how many existing titles would then be impacted with the change.