m-vz/scientific-writing-paper
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

introduction review suggestions

Browse Source
This commit is contained in:
milan
2022-11-01 13:02:56 +01:00
parent 6f91c4fc8e
commit db35ba89ac
5 changed files with 23 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
paper.aux
View File

@@ -15,6 +15,6 @@
\bibcite{boletsis:2017}{3}
\bibcite{lochner:2021}{4}
\bibcite{lowe:2005}{5}
\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces What should the right-eye camera render if it is inside the portal wall (in gray), but the center 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.}}{2}{}\protected@file@percent }
\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces 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.}}{2}{}\protected@file@percent }
\newlabel{fig2}{{2}{2}}
\gdef \@abspage@last{2}

36
paper.log
View File

@@ -1,9 +1,9 @@
This is pdfTeX, Version 3.141592653-2.6-1.40.24 (TeX Live 2022) (preloaded format=pdflatex 2022.10.11) 1 NOV 2022 12:15
This is pdfTeX, Version 3.141592653-2.6-1.40.24 (TeX Live 2022) (preloaded format=pdflatex 2022.10.11) 1 NOV 2022 13:00
entering extended mode
restricted \write18 enabled.
%&-line parsing enabled.
**"D:/wolke7/-Uni/Scientific Writing/paper/paper.tex"
(d:/wolke7/-Uni/Scientific Writing/paper/paper.tex
**"D:/git/uni/scientific writing paper/paper.tex"
(d:/git/uni/scientific writing paper/paper.tex
LaTeX2e <2022-06-01> patch level 5
L3 programming layer <2022-09-28> (d:/Program Files/texlive/2022/texmf-dist/tex
/latex/base/article.cls
@@ -64,7 +64,7 @@ Package: lipsum 2021-09-20 v2.7 150 paragraphs of Lorem Ipsum dummy text
\l__lipsum_a_int=\count195
\l__lipsum_b_int=\count196
(d:/Program Files/texlive/2022/texmf-dist/tex/latex/lipsum/lipsum.ltd.tex)) (D:
\wolke7\-Uni\Scientific Writing\paper/paper.aux)
\git\uni\scientific writing paper/paper.aux)
\openout1 = `paper.aux'.
LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 9.
@@ -128,36 +128,36 @@ Underfull \vbox (badness 1681) has occurred while \output is active []
[1{d:/Program Files/texlive/2022/texmf-var/fonts/map/pdftex/updmap/pdftex.map}
<D:\wolke7\-Uni\Scientific Writing\paper/assets/impossible-spaces.png>]
<D:\git\uni\scientific writing paper/assets/impossible-spaces.png>]
<assets/head-clipping.png, id=11, 548.0475pt x 399.4925pt>
File: assets/head-clipping.png Graphic file (type png)
<use assets/head-clipping.png>
Package pdftex.def Info: assets/head-clipping.png used on input line 41.
(pdftex.def) Requested size: 229.5pt x 167.29195pt.
(D:\wolke7\-Uni\Scientific Writing\paper/paper.bbl
(D:\git\uni\scientific writing paper/paper.bbl
Underfull \hbox (badness 3514) in paragraph at lines 9--13
\OT1/cmr/m/n/10 In \OT1/cmr/m/it/10 Pro-ceed-ings. Vi-su-al-iza-tion '97 (Cat.
No.
[]
) [2 <D:\wolke7\-Uni\Scientific Writing\paper/assets/head-clipping.png>] (D:\wo
lke7\-Uni\Scientific Writing\paper/paper.aux) )
) [2 <D:\git\uni\scientific writing paper/assets/head-clipping.png>] (D:\git\un
i\scientific writing paper/paper.aux) )
Here is how much of TeX's memory you used:
1805 strings out of 475071
34586 string characters out of 5775887
34534 string characters out of 5775887
466594 words of memory out of 5000000
23217 multiletter control sequences out of 15000+600000
473245 words of font info for 41 fonts, out of 8000000 for 9000
1141 hyphenation exceptions out of 8191
72i,9n,77p,1123b,263s stack positions out of 10000i,1000n,20000p,200000b,200000s
<d:/Program Files/texlive/2022/t
exmf-dist/fonts/type1/public/amsfonts/cm/cmbx12.pfb><d:/Program Files/texlive/2
022/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb><d:/Program Files/texli
ve/2022/texmf-dist/fonts/type1/public/amsfonts/cm/cmr12.pfb><d:/Program Files/t
exlive/2022/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb><d:/Program Fil
es/texlive/2022/texmf-dist/fonts/type1/public/amsfonts/cm/cmti10.pfb>
Output written on "D:\wolke7\-Uni\Scientific Writing\paper/paper.pdf" (2 pages,
191515 bytes).
72i,9n,77p,1120b,263s stack positions out of 10000i,1000n,20000p,200000b,200000s
<d:/Program Files/texlive/2022/texmf-dis
t/fonts/type1/public/amsfonts/cm/cmbx12.pfb><d:/Program Files/texlive/2022/texm
f-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb><d:/Program Files/texlive/2022/
texmf-dist/fonts/type1/public/amsfonts/cm/cmr12.pfb><d:/Program Files/texlive/2
022/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb><d:/Program Files/texli
ve/2022/texmf-dist/fonts/type1/public/amsfonts/cm/cmti10.pfb>
Output written on "D:\git\uni\scientific writing paper/paper.pdf" (2 pages, 192
001 bytes).
PDF statistics:
40 PDF objects out of 1000 (max. 8388607)
22 compressed objects within 1 object stream

BIN
paper.pdf
View File

Binary file not shown.

BIN
paper.synctex.gz
View File

Binary file not shown.

8
paper.tex
View File

@@ -21,7 +21,7 @@ There are several uses for portals in computer graphics including determining th
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 virual 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.
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}.
@@ -33,13 +33,13 @@ A recent method to circumvent the space limitations of walking inside a real spa
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.
Firstly, 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 certain optimisations, some specific to rendering portals, others more general, that can reduce the rendering time and analyse their impact.
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 center 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 seperately whenever it passes through the portal, but that idea conflicts with one of the performance optimisations we will discuss in the first part.
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 gray), but the center 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.}
\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}