# Aligning In-Game Room with Chaperone Bounds/Play Area

Hi All,

Fresh to game development here, so please forgive my following question for what might be a very simple problem. I’m trying to build a room that fits the size of my play area/softbounds, however I am lost in trying to align the chaperone bounds with the walls of the room. My searches aren’t coming up with anything my simple mind is able to put together at this point. I’m hoping I can get past this issue so I can have a solid test room for further VR learning. How best can I achieve alignment between my in game room and my chaperone bounds?

At the least, I’m looking to achieve parity between the world rotation and the chaperone rotation (thus aligning the in game walls with my own real world walls). At best, (or maybe further down the line) I am looking to blueprint a scalable room that can align itself and scale to the users softbounds/available play area.

Any guidance would be greatly appreciated. Like I said, I’m very new to blueprints and development in general so I’ll take anything I can get. THANK YOU!

SteamVR gives everyone a square play space (the by m thing box in the room setup).

To access that in unreal, add a chaperone component.
I’ve explained a bunch of it in my video tutorial here / starting template here.

I need the same thing as the parent post. Basically I have a rectangle play space in game and need to position the pawn such that the in-game rectangle fits within the chaperone bounds.

Since the pawn origin can be anywhere in the chaperone bounds and facing any direction depending on how the user configured it, I’m thinking something like figure out the right rotation to make the rectangles aligned, then take the average of the in-game points (giving the center) and the average of the Chaperone points (center of the chaperone area).

I’ll try to remember to post another reply here if I get it all worked out.

Can you just position the spawn point in the center of that space?

If you need to scale that zone, you can average the locations of the vectors and move things in accordingly.

There’s also hard bounds and soft bound enter / return nodes for calling when the player moves beyond the safe zone.

~~No, because the player may have calibrated their playspace to have a center that is way off from the real center (when chaperone setup tells you to stand in the center of your room and point to the monitor). E.g. if my game requires 2.5mx2.5m, and the player has that much space, but didn’t stand in the exact center when they calibrated, then centering the pawn in the in-game sapce will get them out of alignment and they won’t be able to reach some things in the game play space, even though they actually have enough space.

At least that’s my understanding of how the pawn center is determined (faces opposite of monitor and is offset to where they were standing when they pointed at the monitor). If it actually already uses the center of the four chaperone points instead, then it will be simpler.~~

I’m starting to work on this now. Another requirement I have is that the orientation try and match up with the pawn rotation as much as possible to keep the cord behind the player for some portions of my game.

(edit: I looked into it more, apparently it is based on center of bounds and not center where you were standing when you pointed at the monitor, and I think the direction is simpler too, see code snippit, so you are right, you can pretty much just center up the pawn. Only thing left is in my case if the bounds are a wide rectangle and not a square I want to orient things such that the wider bounds are to the player’s sides)

``````

/** HIGH LEVEL TRACKING SPACE ASSUMPTIONS:
* 0,0,0 is the preferred standing area center.
* 0Y is the floor height.
* -Z is the preferred forward facing direction. */

class IVRChaperone
{

``````

Chaperone bounds seem to be broken in 4.11. I created an AnswerHub post (linked below).

I’ve got it working with some changes to the source; I’ll try and post a small patch soon, will probably link it on the AnswerHub:

Great news. Thank you sir!

Here’s the patch; it changes ChaperoneComponent->GetBounds to return a boolean that says whether the bounds were valid. http://pastebin.com/NDAiNkXj

I think if players start the game with their headset and controllers untracked it will be invalid until they get initially tracked, so you can call it repeatedly in a delay loop until it returns valid bounds.

I have no idea on any of the thread safety of it, etc.