PlayerStart is unstable _ Oculus Quest2 App Dev

Development Platform & Builds XR Development
, ,
1

Hi all,

I’m doing a spatial perception experiment with UE5 and oculus quest2.
I generated a room environment and set the PlayerStart actor with a fixed position and direction. The UE5 project is built for an android setting and I checked to start the player same as a playerstart actor location. However, when I relaunched the app saved in oculus, the starting location and direction are changed and different every time. It is not a huge change but I need to provide the same conditions to all participants, it’s bit of a problem. My guess is that the oculus is trying to set the playerstart actor to the center of the gardian area, but when an actual person is not in the center of the gardian area it seems like providing offset initial location, but have no idea about the direction. Is there anyone why it happens or how to fix this?

2

Hi Haheehong,

The first thing to try would be resetting the Oculus position/rotation. Do this by standing in the same spot as your player start + facing the correct direction, then press and hold the Oculus button to reset the player.

Hope that helps, welcome to the Forums!

1 Like
3

The Player Start Actor defines where the Pawn is spawned, not the Camera’s relative location. You’d have to move the pawn on Begin Play so that the Relative location and rotation of the Camera is = Player Start Actor. You can use the same logic that’s used for the VR Pawn’s Teleport, but feed the location and rotation of the Player Start Actor instead of where the teleport trace hits.

1 Like
4

I am having the same problem as the OP, but on quest 3 with any version of UE5.
(Right now using 5.5.3, but the last couple of versions, including the fork from Meta had the same results), hence the necro post, rather than making a new thread.
(Incidentally, many others are also still having these issues, with similar postings on the Meta forums)
So if we are all doing the same thing wrong, we need to identify it and get the right education out there.
At this point, I would be delighted to be told I’m an idiot and pointed to a ‘correct’ way of doing things. :smile:

I understand that there is the difference between the player’s position in terms of the root of the player pawn, and potentially the current position of the players HMD relative to that root.

However, on Beginplay, I am resetting EVERTHING to 0 (relative positions and rotations)
(I do this after a brief timer callback, just to give everything time to settle, in case that matters)
I am also calling UHeadMountedDisplayFunctionLibrary::ResetOrientationAndPosition();

Nothing seems to work though. What I (and most other similar comments I saw) want when we start a level is to have the player start at the player start, not offset from it based on where they are in their physical room. (That only makes any sense in AR)

I’m not using (and i didnt even enable) spatial anchors, or any of that funky AR jazz.

This to me doesnt feel like its a UE problem, it feels like its a Meta Quest issue.

Based on the last comment @VictorLerp; do I really need to write some ugly code in my VRCharacter’s beginplay to go find the PlayerStart actor, and then manually teleport back to it again?
I mean, if I must then I must, but it feels kinda wrong. The quest should just start me at the player start - not add some offset to it.
If I had walked in the real world AFTER starting the game, sure, I want that.

5

This has been a pretty annoying issue across platforms. Guessing there is a race condition where it can take a while before the camera gets the correct HMD position, and anything that happens before will mess up the position.

I’m not a big fan of the player pawn being centered around the play area center. In most cases it makes more sense for it to be centered on the players actual location instead. I’d probably implement it in the player pawn directly, rather than use ResetOrientationAndPosition(). It also gives you more options on dealing with things like locomotion and collisions. You’d implement it by, every frame, taking the players HMD location on the horizontal plane, moving the pawn to it, and moving the VR Origin back the same amount.

6

What you suggest is basically what we are already doing. :+1:

Our VR player base class has a function which gets called on Tick(), and repositions both the Actor’s world offset, and its ‘VROrigin’ component. This means physical world movement works in VR, and controller movement works also, but it stops players attempting to walk through VR obstacles, by simply walking in the real world.

That lot all works great.

It was the initial position which was being a pain.

I’ve solved it now, so I will describe what I did, along with what I think is a small Unreal Editor bug which really messed me up.

As mentioned above, we have code to correct position in a function called UpdateVrPosition() which gets called on Tick(). This works fine when everything is up and running, but at the beginning it may be possible that the Tick gets called before the Beginplay function has completely finished. Especially in our case as we have a timer in the BeginPlay to allow the HMD to ‘sort its life out’ before telling it to ResetOrientationAndPosition(). There are a number of ways you can fix that, such as bAllowTickBeforeBeginPlay =false.
However, we chose to allow tick, but start with it disabled, using:

	PrimaryActorTick.bCanEverTick          = true;
	PrimaryActorTick.bStartWithTickEnabled = false;

And then turn it on once we have finished doing whatever setup we wanted in our timer callback.
In addition to ResetOrientationAndPosition(), we also reset the VROrigin and VRCameraComponent relative positions/rotations. That might not be required anymore since disabling the Tick(), but… belt and braces.
Gotta say I am NOT happy about using a timer function in this way, its the kinda cludgey hack you would expect in Javascript, not Unreal C++, but whatever, it works.

Now, lets mention the BUG which ate up a lot of my time…

As anyone who has done a bit of testing in VR knows, sometimes you put the headset on, and sometimes you leave it on the desk. It depends what you are testing.
If you were testing something like the PlayerStart not working as you wanted, you probably leave it on the desk after the 1000th time of trying to fix the code.

So, I suddenly noticed that when I wore the headset my position was WRONG, but when I left it on the desk it was CORRECT.
Instantly I assumed it was something to do with the headset sensor, and I pulled the visor apart, removed the silicon interface, cleaned the sensor, etc, etc.
Lets just skip to the TLDR;

  • When NOT wearing the headset, I generally start the preview by pressing the little green ‘VR Preview’ button in the toolbar.
  • When wearing the headset, I generally press a button on my streamdeck which does the shortcut keys for the same thing.

It turns out the shortcut, while running the game, IGNORES YOUR GameMode, so none of your code in the playercharacter, or playercontroller even runs.
Call me an idiot if you like, but I literally had to set up breakpoints to eventually discover that.

Anyhow, hope maybe it helps someone
(Or gives them a laugh at my expense) :wink:

2 Likes