Massive cleaning

preliminary-work/bookmarks-impact.typ

@@ -1,10 +1,10 @@
-= Impact of 3D bookmarks on navigation
+== Impact of 3D bookmarks on navigation
 
 We now describe an experiment that we conducted on 51 participants, with two goals in mind.
 First, we want to measure the impact of 3D bookmarks on navigation within an NVE\@.
 Second, we want to collect traces from the users so that we can replay them for reproducible experiments for comparing streaming strategies in Section~\ref{bi:system}.
 
-== Our NVE
+=== Our NVE
 To ease the deployment of our experiments to users in distributed locations on a crowdsourcing platform, we implement a simple web-based NVE client using THREE.js// \footnote{http://threejs.org}.
 The NVE server is implemented with node.js. // \footnote{http://nodejs.org}.
 The NVE server streams a 3D scene to the client; the client renders the scene as the 3D content is received.
@@ -19,7 +19,7 @@ The mouse movement controls the camera rotation.
 The user can always choose to lock the pointer, or unlock it using the escape key.
 The interface also includes a button to reset the camera back to the starting position in the scene.
 
-== 3D bookmarks
+=== 3D bookmarks
 Our NVE supports 3D bookmarks.
 A 3D bookmark, or bookmark for short, is simply a fixed camera location (in 3D space), a view direction, and a focal.
 Bookmarks visible from the user's current viewpoint are shown as 3D objects in the scene.
@@ -40,22 +40,22 @@ Since bookmarks are part of the scene, they are visible only when not hidden by
 We chose size and colors that are salient enough to be easily seen, but not too large to limit the occlusion of regions within the scene.
 When reaching the bookmark, the corresponding arrow or viewport is not visible anymore, and subsequently will appear in a different color, to indicate that it has been clicked (similar to web links).
 
-== User study
+=== User study
 
 We now describe in details our experimental setup and the user study that we conducted on 3D navigation.
 
-#heading(level: 3, numbering: none)[Models]
+#heading(level: 4, numbering: none)[Models]
 We use four 3D scenes (one for the tutorial and three for the actual experiments) which represent recreated scenes from a famous video game.
 Those models are light (a few thousand of triangles per model) and are sent before the experiment starts.
 We keep the models small so that users can perform the task with acceptable latency from any country using a decent internet connection.
 Our NVE does not stream the 3D content for these experiments, in order to avoid unreliable conditions caused by the network bandwidth variation, which might affect how the users interact.
 
-#heading(level: 3, numbering: none)[Task design]
+#heading(level: 4, numbering: none)[Task design]
 Since we are interested in studying how efficiently users navigate in the 3D scene, we ask our participants to complete a task which forces them to visit, at least partially, various regions in the scene.
 To this end, we hide a set of 8 coins on the scene: participants are asked to collect the coins by clicking on them.
 In order to avoid any bias due to the coins position, we predefined 50 possible coin locations per scene, and randomly select 8 out of these 50 positions each time a new participant starts the experiment.
 
-#heading(level: 3, numbering: none)[Experiment]
+#heading(level: 4, numbering: none)[Experiment]
 Participants are first presented with an initial screen to collect some preliminary information: age, gender, the last time they played 3D video games, and self-rated 3D gaming skills. We ask those questions because we believe that someone who is used to playing 3D video games should browse the scene more easily, and thus, may not need to use our bookmarks.
 
 Then, the participants go through a tutorial to learn how the UI works, and how to complete the task.
@@ -94,15 +94,15 @@ After completing the three tasks, the participants have to answer a set of quest
   caption: [List of questions in the questionnaire and summary of answers. Questions 1 and 2 have a 99% confidence interval.],
 )<bi:questions>
 
-#heading(level: 3, numbering: none)[Participants]
+#heading(level: 4, numbering: none)[Participants]
 The participants were recruited on microworkers.com, a crowdsourcing website.
 There were 51 participants (36 men and 15 women), who are in average 30.44 years old.
 
-== Experimental results
+=== Experimental results
 
 We now present the results from our user study, focusing on whether bookmarks help users navigating the 3D scene.
 
-#heading(level: 3, numbering: none)[Questionnaire]
+#heading(level: 4, numbering: none)[Questionnaire]
 We had 51 responses to the questionnaire.
 The answers are summarized in Table~\ref{bi:questions}.
 Note that not all questions were answered by all participants.
@@ -116,7 +116,7 @@ This is slightly in contradiction with our setup; even if coins may appear in so
 The strongest result is that almost all users (49 out of 51) find bookmarks to be helpful.
 In addition, users seem to have a preference for \Arrows{} against \Viewports{} (32 against 7).
 
-#heading(level: 3, numbering: none)[Analysis of interactions]
+#heading(level: 4, numbering: none)[Analysis of interactions]
 
 #figure(
   table(
@@ -159,7 +159,7 @@ Although users tend to spend less time on the tasks when they do not have bookma
 As a consequence, they visit the scene faster in average with bookmarks, than without bookmarks.
 The table shows that this higher speed is due to the bookmarks, as more than 60\% of the distance traveled by users with bookmarks happens when users click on bookmarks and fly to the destination.
 
-#heading(level: 3, numbering: none)[Discussion]
+#heading(level: 4, numbering: none)[Discussion]
 
 In the previous paragraphs, we have shown how bookmarks are well perceived by users (looking at the questionnaire answers).
 We also showed that users tend to be more efficient in completing the task when they have bookmarks than when they do not.

preliminary-work/intro.typ

@@ -1,4 +1,4 @@
-= Introduction
+== Introduction
 
 Navigating in NVE with a large virtual space (most times through a 2D interface) is sometimes cumbersome.
 In particular, a user may have difficulties reaching the right place to find information.

preliminary-work/main.typ

@@ -1,6 +1,4 @@
-#import "../chapter.typ"
-
-#chapter.chapter[Bookmarks, navigation and streaming]
+= Bookmarks, navigation and streaming
 
 #figure(
   grid(

preliminary-work/streaming.typ

@@ -1,6 +1,6 @@
-= Impact of 3D bookmarks on streaming
+== Impact of 3D bookmarks on streaming
 
-== 3D model streaming
+=== 3D model streaming
 
 In this section, we describe our implementation of a 3D model streaming policy in our simulation.
 A summary of the streaming policies we designed is given in Table X.
@@ -66,12 +66,12 @@ Note that the server may send faces that are occluded and not visible to the cli
 
 In the following, we shall denote this streaming policy \textsf{culling}; in Figures~\ref{bi:click-1250} and~\ref{bi:click-625} streaming using \textsf{culling} only is denoted \textsf{C-only}.
 
-== 3D bookmarks
+=== 3D bookmarks
 
 We have seen (Figure~\ref{bi:triangles-curve}) that navigation with bookmarks is more demanding on the bandwidth.
 We want to exploit bookmarks to improve the user's quality of experience. For this purpose, we propose two streaming policies based on offline computation of the relevance of 3D content to bookmarked viewpoints.
 
-#heading(level: 3, numbering: none)[Visibility determination for 3D bookmarks]
+#heading(level: 4, numbering: none)[Visibility determination for 3D bookmarks]
 
 A bookmarked viewpoint is more likely to be accessed, compared to other arbitrary viewpoint in the 3D scene.
 We exploit this fact to perform some precomputation on the 3D content visible from the bookmarked viewpoint.
@@ -126,7 +126,7 @@ In what follows, we will refer to this streaming policy as \textsf{visible}.
 //     \caption{Comparison of rendered image quality (average on all bookmarks and starting position): the triangles are sorted offline (green curve), or sorted online by distance to the viewpoint (blue curve).}\label{bi:sorted-tri}
 // \end{figure}
 
-#heading(level: 3, numbering: none)[Prefetching by predicting the next bookmark clicked]
+#heading(level: 4, numbering: none)[Prefetching by predicting the next bookmark clicked]
 
 We can now use the precomputed, visibility-based streaming of 3D content for the bookmarks to reduce the amount of traffic needed.
 Next, we propose to prefetch the 3D content from the bookmarks.
@@ -183,7 +183,7 @@ We denote this combination as \textsf{V-PP}, for Prefetching based on Prediction
 //     \caption{Example of how a chunk can be divided into fetching what is needed to display the current viewport (culling), and prefetching three recommendations according to their probability of being visited next.\label{bi:prefetched-chunk}}
 // \end{figure}
 
-#heading(level: 3, numbering: none)[Fetching destination bookmark]
+#heading(level: 4, numbering: none)[Fetching destination bookmark]
 
 An alternate method to benefit from the precomputing visible triangles at the bookmark, is to fetch 3D content during the "fly-to" transition to reach the destination.
 Indeed, as specified in Section~\ref{bi:3dnavigation}, moving to a bookmarked viewpoint is not instantaneous, but rather takes a small amount of time to smoothly move the user camera from its initial position towards the bookmark.
@@ -209,7 +209,7 @@ We call this method \textsf{V-FD}, since we are Fetching the 3D data from the De
 //     \caption{Summary of the streaming policies\label{bi:streaming-policies}}
 // \end{table}
 
-== Comparing streaming policies
+=== Comparing streaming policies
 
 In order to determine which policy to use, we replay the traces from the user study while simulating different streaming policies.
 The first point we are interested in is which streaming policy leads to the lower discovery latency and better image