Impossible Rooms: Making a physical space larger than it is with VR

From the 9th to the 12th of February 2021 I was at the International XR Workshop. Over those 4 days we had a number of speakers talk about various uses of XR (Extended Reality) and what research is being done in the field. We also formed groups to work on projects over those days, to be shown off at the end. My team, consisting of Dominik Lange (University of Auckland), Sam Thompson (University of Auckland), Nick Heyworth (Victoria University), and myself started with the idea of creating a maze. After viewing the various physical areas we had to show off the project in we realised that it would be difficult to fit a maze into that area. The entire reason we wanted to create a maze was to enable the testing of navigation tasks in the controlled environment of VR. Additionally we wanted to make it easier for people who don’t have experience with VR to participate in the test. This lead us to thinking about ways other than simple teleportation or directional locomotion. In an earlier post on this blog I have gone in more detail into the various forms of locomotion in VR, and we realised that using the same space (via doubling back in the real world although changing your location in the virtual world) would allow us to make a large maze in a relatively small area. After confirming that we where all on the same page by looking at a game that did this (Tea for God) we decided to start planning the maze and get onto coding. I primarily coded the “portal” so I’ll speak the most about that, although I will also touch on our method of stopping people from going through walls and the actual design of the maze.

The Portal System

At first we thought we should make a portal system that used render textures, basically a textured cube that looks like whatever another camera is looking at. After doing some research I found that doing it this way required the system to run multiple rendering passes, which may cause issues on the quest (especially for people without knowledge of how to optimize for VR. As we where meaning this project for others to use as well, this was something we didn’t want). After spending a bit of time puzzling through this particular issue I remembered an explanation¹ on how Antichamber does a similar trick. By tricking you into thinking that you are just walking down one corridor when, in fact, half way down the corridor, you are moved to an identical position in an identical looking corridor. We used this same method, and found success. We worked on multiple “corridor” configurations that allow for movement from room to room.

Stopping Real Movement Through Virtual Walls

As we where making a maze, an important question was “what happens if someone walks through a wall? We looked at some other methods that people used to stop this in VR. Some faded to black, although we noted that it was occasionally difficult to figure out where you came from. Another method we found was moving the environment away from you, so you can move freely but the virtual environment moves to keep you from intersecting with virtual objects. The second wouldn’t work with our method, as we wanted 1-1 movement. In order to counteract the loss of directional sense we placed a marker (a pillar of light) where they where just before they entered a location that the virtual environment would stop them from entering, and placed text in front of them instructing them to turn back to that spot (along with fading the world to black).

Designing the Maze

Designing the maze took surprisingly little time for creating a maze that used the same space as previously. How little time you ask? About 2 hours. We came up with a method to map the maze, then did some puzzle solving to create the corridor layouts, then chose and designed each room to appear different.

We initially created this map via drawing out the node-map to the right. This gave us the paths between rooms and how many portals each room had to have. Then we drew out the 11 room grids (based on a 0.75m grid just due to how we had been building things so far). The next step was to set up all the portals, where they are in each room and what room they led to. Finally we fleshed out each room with details so that it would be recognisable to someone walking through the maze. Once we had done that, we just had to build the rooms in unity and do some testing to make sure it all worked correctly.

Presenting

I am a design student, and I’d like to think that that was at least part of why I pushed my team to work on the actual presentation of the showcase (and feedback sessions), and would like to think that doing that is at least part of why we ended up winning first place. Each day (other than the first and last) we had a feedback session, these where meant to take about 30 minutes in which each team would do a 1 minute presentation of what they’ve done so far, then get some feedback. We, as design students, have had the importance of good feedback drilled into us, so I tried to make our presentations as smooth as possible. We would record a quick video of the current state of our project, then would run the video while talking about it. This meant that our sessions didn’t overrun due to technical difficulties (as is common in attempting a live demonstration) yet still gave a visual indication of our project. It also was personally helpful in relieving stress while presenting the feedback session. If anyone who plans to join the next XR workshop or something like it, I would definitely recommend trying to do something like it. As for the actual showcase, we created a slideshow to place behind the area in which people could try it out that would show a description of our project, future uses, and a video of the final work. We also did some other minor touch-ups to the space such as clearing our workstations and setting up one of the whiteboards with the projects name and “logo”.

If you want to get your hands on it, go check out the project page.