50 lines
5.1 KiB
TeX
50 lines
5.1 KiB
TeX
\documentclass[10pt,twocolumn]{article}
|
|
\usepackage[utf8]{inputenc}
|
|
\usepackage{graphicx}
|
|
\usepackage{lipsum}
|
|
|
|
\title{Performance Optimisations for Rendering Portals in Virtual Reality}
|
|
\author{Milan van Zanten\\\normalsize{University of Basel}\\\normalsize{milan.vanzanten@unibas.ch}}
|
|
|
|
\begin{document}
|
|
|
|
\maketitle
|
|
|
|
% \begin{center}
|
|
% \textbf{Abstract}
|
|
|
|
% WIP
|
|
% \end{center}
|
|
|
|
\section{Introduction}
|
|
There are several uses for portals in computer graphics including determining the visibility of parts of a 3D scene\cite{lowe:2005}, dividing a scene up into separate areas, rendering a mirror surface, or as traversable portals that can be seen and moved through. These uses can be broadly categorised as either an optimisation technique or a rendering trick. The former two of the mentioned applications are used to determine geometry that can be ignored when rendering a scene and speed up the process. Mirror surfaces and traversable portals though are effects purposefully implemented in an application to benefit the experience.
|
|
|
|
There are already many implementations of traversable portals in media like video games or architectural visualisations\cite{aliaga:1997}. In this paper we will focus on an application of traversable portals concerning the space limitations in a virtual reality (VR) experience.
|
|
|
|
One of the main challenges when implementing VR applications is immersion, since errors in tracking and latency are noticed particularly strong\cite{abrash:2013}. In an effort to maximise immersion, most of VR has moved from seated experiences with movement limited to three degrees of freedom (just rotation) to ``room-scale'' tracking. Here, in addition to the rotation of the VR headset, the user's position is tracked either via external devices with fixed positions or by cameras that analyse the surroundings and use computer vision algorithms to determine the position. With the added positional tracking, the six degrees of freedom allow the user to move around the room freely. Thus, the only limitation now is the available space. To move around virtual worlds larger than the available space, several different methods have been developed\cite{boletsis:2017}. Examples include head-directed locomotion, point \& teleport and more. Indisputably though, the technique that preserves immersion the most is actual walking inside the real space.
|
|
|
|
A recent method to circumvent the space limitations of walking inside a real space is the concept of impossible spaces. Overlapping rooms are connected through portals into a single space many times larger than the initial rooms themselves. If such an arrangement is made while factoring in the real available space, the whole virtual space can be accessed by passing through the portals. An example layout can be seen in Figure \ref{fig1}.
|
|
|
|
\begin{figure}
|
|
\includegraphics[width=\linewidth]{assets/impossible-spaces.png}
|
|
\caption{Four rooms with portals (in red) can all be accessed without leaving the smaller real space\cite{lochner:2021}.}
|
|
\label{fig1}
|
|
\end{figure}
|
|
|
|
To allow for such impossible spaces to exist, the aforementioned portals are necessary. When viewed, they show what the user would be seeing through the portal in the other room, and if a user crosses the plane of a portal, they are transported to the connecting one. In virtual reality, implementing such a portal system poses some extra challenges.
|
|
|
|
Each portal requires rendering an additional viewpoint. When rendering the portals in VR, where each eye is rendered by its own camera, there are now two additional viewpoints to render from. In the naive case where each viewpoint is rendered the same, we produce quadruple the amount of work compared to a basic non-VR scene without portals. We will present two optimisations that can reduce the rendering time and analyse their impact. The first optimisation --- using the stencil buffer to only render what is seen through the portal --- is concerned with improving the rendering time of portals in general. In contrast, the second optimisation improves the overall performance of rendering VR by not pushing the whole scene to the GPU twice and rendering a texture for each eye, but rather rendering both eyes onto a single texture.
|
|
|
|
The way a VR scene is rendered also raises the question of how to handle the teleportation of the user. For example, consider the centre point between the eyes that could be used to decide when the portal plane has been crossed. If the user view the portal from an angle, they could clip through the portal with one eye when they enter it\ref{fig2}. This could be solved by transporting each eye separately whenever it passes through the portal, but that idea conflicts with one of the performance optimisations we will discuss in the first part.
|
|
|
|
\begin{figure}
|
|
\includegraphics[width=\linewidth]{assets/head-clipping.png}
|
|
\caption{What should the right-eye camera render if it is inside the portal wall (in grey), but the centre of the head (in red) has not crossed the portal plane? If nothing is done, the blue part of the user's field of view would not render the next room, but whatever is inside or behind the portal wall.}
|
|
\label{fig2}
|
|
\end{figure}
|
|
|
|
\bibliographystyle{plain}
|
|
\bibliography{refs}
|
|
|
|
\end{document}
|