Plenty of work

src/bib.bib

@@ -485,3 +485,42 @@
   author = {Stack Overflow},
   howpublished = {\url{https://insights.stackoverflow.com/survey/2019#technology-most-loved-dreaded-and-wanted}}
 }
+
+@inproceedings{urban-data-visualisation,
+    author = {Gaillard, J{\'e}r{\'e}my and Vienne, Alexandre and Baume, R{\'e}mi and Pedrinis, Fr{\'e}d{\'e}ric and Peytavie, Adrien and Gesqui\`{e}re, Gilles},
+    title = {Urban Data Visualisation in a Web Browser},
+    booktitle = {Proceedings of the 20th International Conference on 3D Web Technology},
+    series = {Web3D '15},
+    year = {2015},
+    isbn = {978-1-4503-3647-5},
+    address = {Heraklion, Crete, Greece},
+    pages = {81--88},
+    numpages = {8},
+    url = {http://doi.acm.org/10.1145/2775292.2775302},
+    doi = {10.1145/2775292.2775302},
+    acmid = {2775302},
+    publisher = {ACM},
+    keywords = {3D virtual city, WebGL, spatial information, standards},
+}
+
+@article{visibility-determination,
+    title={Quantitative analysis of visibility determinations for networked virtual environments},
+    author={Seo, Beomjoo and Zimmermann, Roger},
+    journal={Journal of Visual Communication and Image Representation},
+    volume={23},
+    number={5},
+    pages={705--718},
+    year={2012},
+    publisher={Elsevier}
+}
+
+@article{second-life,
+    title={Exploring {S}econd {L}ife},
+    author={Varvello, Matteo and Ferrari, Stefano and Biersack, Ernst and Diot, Christophe},
+    journal={IEEE/ACM Transactions on Networking (TON)},
+    volume={19},
+    number={1},
+    pages={80--91},
+    year={2011},
+}
+

src/commands.sty

@@ -1,3 +1,8 @@
+\newcommand{\minitoc}[1][Contents]{%
+  \etocsettocstyle{\addsec*{#1}}{}%
+  \localtableofcontents%
+}
+
 \newcommand{\written}[1]{{\noindent\color{Green}Things written in #1}}
 \newcommand{\unpublished}[1]{{\noindent\color{Green}Things written but not published in #1}}
 \newcommand{\missing}[1]{{\noindent\color{Red}Missing #1}}

src/conclusion/future-work.tex

@@ -1 +1,23 @@
+\fresh{}
 \section{Future work}
+
+After all this, there is still plenty of avenues for improving our streaming system.
+
+\subsection{Semantic information}
+In all of this work, no attention has been paid towards semantic.
+Our content preparation does not take anything like that into account, and our adaptation sets and segments surely will cut data that could be grouped semantically.
+Having semantic support can help us have a better structure for our content: we know that displaying half a building will lead to low quality of experience.
+Moreover, semantic data could also change the utilities we have been defining for our segments: some data can be marked as more important than other and this can be taken into account in our utilities.
+
+\subsection{Compression / multi resolution for geometry}
+In all of this work, no attention has been paid towards geometry compression or multi-resolution.
+Geometry data is transmitted as OBJ files which is the worst possible format for transmission, and compression could drastically increase the quality of experience.
+Being able to support multi resolution geometry would be even better, and even if performing multi resolution on a large and heterogeneous scene just like ours is difficult, we have no doubt that semantic information can help this task.
+
+\subsection{Performance optimization}
+Performance has already been discussed in Chapter~\ref{d3i}.
+However, in this work, we never tried to remove data from the media engine when it is no longer useful.
+This means that on a really large scene, performance is bound to become damaged due to the growing amount of data to render, and the saturation of memory.
+For our system to be able to support such scenes, it needs to unload data.
+The utility measures that we described in Section~\ref{d3:utility} seem to be a good candidate to determine what to unload.
+We could watch the performance of our system by measuring variables such as memory used or framerate and use those values to discard data with low enough utility.

src/config.sty

@@ -19,9 +19,8 @@ anchorcolor = blue]{hyperref}
 \usepackage{subcaption}
 \usepackage{todonotes}
 \usepackage{booktabs}
-\usepackage{minitoc}
+\usepackage{etoc, blindtext}
 
-\usepackage[chapter,nottoc]{tocbibind}
 \usepackage{setspace}
 \onehalfspacing{}
 

src/dash-3d-implementation/introduction.tex

@@ -93,6 +93,9 @@ All DASH clients are built from the same basic bricks, as shown in Figure~\ref{d
 
 We want to have two implementations of such a client:
 \begin{itemize}
-    \item \textbf{one in JavaScript}, so we can easily have demos and conduct user-studies with real users trying the real interface on different devices (desktop or mobile);
+    \item \textbf{one in JavaScript}, so we can easily have demos and conduct user-studies with real users trying the real interface on desktop or mobile devices (this implementation is detailed in Section~\ref{d3i:js-implementation});
-    \item \textbf{one in Rust}, so we can easily run simulations with maximum performance to be able to compare different setups or parameters with more precision.
+    \item \textbf{one in Rust}, so we can easily run simulations with maximum performance to be able to compare different setups or parameters with more precision (this implementation is detailed in Section~\ref{d3i:rust-implementation}).
 \end{itemize}
+
+Our implementation also contains the software that preprocess the model and structures it in a DASH manner.
+This piece of software was also implemented in Rust, and is detailed in Section~\ref{d3i:rust-exporter}.

src/dash-3d-implementation/js-implementation.tex

@@ -1,5 +1,5 @@
 \fresh{}
-\section{JavaScript implementation}
+\section{JavaScript client\label{d3i:js-implementation}}
 
 \subsection{Media engine}
 

src/dash-3d-implementation/main.tex

@@ -1,4 +1,4 @@
-\chapter{DASH-3D implementation}
+\chapter{DASH-3D implementation\label{d3i}}
 
 \minitoc{}
 \newpage
@@ -12,3 +12,5 @@
 \input{dash-3d-implementation/rust-implementation}
 \resetstyle{}
 
+\input{dash-3d-implementation/rust-exporter}
+\resetstyle{}

src/dash-3d-implementation/rust-exporter.tex

@@ -0,0 +1,14 @@
+\fresh{}
+
+\section{Preprocessing\label{d3i:rust-exporter}}
+
+The piece of software that does the preprocessing of the model mostly consists in file manipulation and is written is Rust as well.
+It successively preprocess the geometry and then the textures.
+The MPD is generated by a library named \href{https://github.com/netvl/xml-rs}{xml-rs}, and that works like a stack:
+\begin{itemize}
+    \item a structure is created on the root of the MPD file;
+    \item the \texttt{start\_element} method creates a new child in the XML file;
+    \item the \texttt{end\_element} method ends the current child and pops the stack.
+\end{itemize}
+This structure is passed along with our geometry and texture preprocessors that can add elements to the XML file as they are generating the corresponding files.
+The other details of the preprocessing is available in Section~\ref{d3:dash-3d}.

src/dash-3d-implementation/rust-implementation.tex

@@ -1,4 +1,5 @@
-\section{Rust implementation}
+\fresh{}
+\section{Rust client\label{d3i:rust-implementation}}
 
 In order to run our simulation, we want to have a native implementation of our DASH client that is performant and reliable.
 We chose to use Rust to accomplish this.

src/main.tex

@@ -30,7 +30,6 @@ Text that was freshly written will be in this color
 
 \makeflyleaf{}
 
-\dominitoc{}
 \tableofcontents
 
 \input{plan}

src/preliminary-work/conclusion.tex

@@ -1,6 +1,6 @@
 \fresh{}
 
-\section{Conclusion}
+\section{Conclusion\label{bi:conclusion}}
 
 In this chapter, we have described a basic interface that allows a user to navigate in a scene that is being streamed.
 It allowed us to understand the problems linked to the dynamicity of both the user behaviour and the 3D content:

src/preliminary-work/intro.tex

@@ -0,0 +1,44 @@
+\copied{}
+\section{Introduction}
+
+With the progress in data acquisition and modeling techniques, networked virtual environments, or NVE, are increasing in scale.
+For instance, Gaillard et al.~\cite{urban-data-visualisation} reported that the 3D scene for the city of Lyon takes more than 30 GB of data.
+It has become impractical to download the whole 3D scene before the user begins to navigate in the scene.
+A more common approach is to stream the required 3D content (models and textures) on demand, as the user moves around the scene.
+Downloading the required 3D content the moment the user demands it, however, leads to ``popping effect'' where 3D objects materialize suddenly in the view of the user, due to the latency between requesting for and receiving the 3D content from the server~\cite{visibility-determination}.
+Such latency can be quite high --- Varvello et al.\ reported a median of about 30 seconds for all 3D data in an avatar's surrounding to be loaded in high density Second Life regions under their experimental network conditions, due to a bottleneck at the server~\cite{second-life}.
+
+For a smoother user experience, NVE typically prefetch 3D content, so that a 3D object is readily available for rendering when the object falls into the view of the user.
+Efficient prefetching, however, requires the client or the server to predict where the user would navigate to in the future and retrieve the corresponding 3D content before the user reaches there.
+In a typical scenario, users navigate along a continuous path in a NVE, leading to a significant overlap between the 3D content visible from the user's known current position and possible next positions (i.e., \textit{spatial data locality}).
+Furthermore, there is a significant overlap between the 3D content visible from the current point in time to the next point in time (i.e., \textit{temporal data locality}).
+Both forms of locality lead to content overlaps, thus making a correct prediction easier and a wrong prediction less costly. 3D content overlaps are particularly common in a NVE with open space, such as a 3D archaeological site or a 3D city.
+
+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.
+The content provider of the NVE may want to highlight certain interesting features for the users to view and experience, such as a vantage point in a city, an excavation at an archaeological site, or an exhibit in a museum.
+To allow users to easily find these interesting locations within the NVE,  \textit{3D bookmarks} or \textit{bookmarks} for short, can be provided.
+A bookmark is simply a 3D virtual camera (with position and camera parameters) predefined by the content provider, and can be presented to users in different ways, including as a text link (URL), a thumbnail image, or a 3D object embedded within the NVE itself.
+
+When users click on a bookmark, NVEs commonly provide a ``fly-to'' animation to transit the camera from the current viewpoint to the destination~\cite{controlled-movement-virtual-3d,browsing-3d-bookmarks} to help orient the users within the 3D space.
+Clicking on a bookmark to fly to another viewpoint leads to reduced data locality.
+The 3D content at the  bookmarked destination viewpoint may overlap less with the current viewpoint.
+In the worst case, the 3D objects corresponding to the current and destination viewpoints can be completely disjoint.
+Such movement to a bookmark may lead to a \textit{discovery latency}~\cite{second-life}, in which users have to wait for the 3D content for the new viewpoint to be loaded and displayed.
+An analogy for this situation, in the context of video streaming, is seeking into a segment of video that has not been prefetched yet.
+
+In this paper, we explore the impact of bookmarks on NVE navigation and streaming, and make several contributions.
+First, we conducted a crowdsourcing experiment where 51 participants navigated in 3 virtual scenes to complete a task.
+This experiment serves two purposes: (i) it validates our intuition that bookmarks significantly reduce the number of interactions and navigation time (in average the time needed to complete the task
+for users with bookmarks is half the time for users without bookmarks); (ii) it produces a set of user interaction traces that we use for subsequent simulation experiments.
+Second, we quantified the effect of bookmarking on prefetching and visual quality in our experiments.
+We showed that, without prefetching, the number of correctly rendered pixels right after clicking on bookmarks can drop up to 10\% on average.
+If we prefetch the 3D content from the bookmarks according to the probability of access, we do not limit this drop by more than 5\%.
+Finally, we proposed a method to improve the visual quality after clicking on bookmarks, by exploiting the fact that the visible faces at the bookmark can be precomputed, and by fetching the visible faces only after a bookmark is clicked.
+We showed that, if the fetching is done during the 1 or 2 seconds of the ``fly-to'' camera movement from the current viewpoint to the bookmarked viewpoint, it suffices to increase the number of correctly rendered pixels to more than 20\%, without wasting bandwidth on prefetching.
+Our key message is that, \textit{in addition to easing navigation, bookmarking allows precomputation of visible faces and can significantly reduce interaction latency, without resorting to prefetching}, which may waste bandwidth by prefetching 3D data that will not be needed.
+
+The rest of the chapter consists of the following sections.
+Section~\ref{bi:3dnavigation} describes the 3D bookmarks that we use in our work, along with our experiments to validate the usefulness of bookmarking.
+Section~\ref{bi:system} describes the streaming and prefetching mechanisms that we used to simulate our experiments as well as our main findings.
+Finally, we conclude in Section~\ref{bi:conclusion}.

src/preliminary-work/main.tex

@@ -1,4 +1,4 @@
-\chapter{Preliminary work\label{bi}}
+\chapter{Analysis of the impact of UI on user navigation and streaming\label{bi}}
 
 \minitoc{}
 \newpage
@@ -7,6 +7,9 @@
 \newcommand{\Viewports}{\textsf{VP \xspace}}
 \newcommand{\Arrows}{\textsf{Ar \xspace}}
 
+\input{preliminary-work/intro}
+\resetstyle{}
+
 \input{preliminary-work/bookmarks-impact}
 \resetstyle{}