Removed fresh copied and resetstyle

src/dash-3d/client.tex

@@ -1,4 +1,3 @@
-\copied{}
 \section{Client\label{d3:dash-client}}
 
 In this section, we specify a DASH NVE client that exploits the preparation of the 3D content in an NVE for streaming.
@@ -6,7 +5,6 @@ In this section, we specify a DASH NVE client that exploits the preparation of t
 The generated MPD file describes the content organization so that the client gets all the necessary information to make educated decisions and query the 3D content it needs according to the available resources and current viewpoint.
 A camera path generated by a particular user is a set of viewpoint $v(t_i)$ indexed by a continuous time interval $t_i \in  [t_1,t_{end}]$.
 
-\fresh{}
 All DASH clients are built from the same basic bricks, as shown in Figure~\ref{d3:dash-scheme}:
 \begin{itemize}
     \item the \emph{access client}, which is the module that deals with making HTTP requests and receiving responses;
@@ -77,7 +75,6 @@ All DASH clients are built from the same basic bricks, as shown in Figure~\ref{d
     \caption{DASH client-server architecture\label{d3:dash-scheme}}
 \end{figure}
 
-\copied{}
 The DASH client first downloads the MPD file to get the material (.mtl) file containing information about all the geometry and textures available for the entire 3D model.
 At time instance $t_i$, the DASH client decides to download the appropriate segments containing the geometry and the texture to generate the viewpoint $v(t_{i+1})$ for the time instance $t_{i+1}$.
 
@@ -210,8 +207,6 @@ s^{\texttt{GREEDY}}_i= \argmax{s \in \mathcal{S} \backslash \mathcal{B}_i \cap \
 \label{d3:greedy}
 \end{equation}
 
-\fresh{}
-
 \subsection{JavaScript client\label{d3:js-implementation}}
 
 In order to be able to evaluate our system, we need to collect traces and perform analyses on them.

src/dash-3d/conclusion.tex

@@ -1,11 +1,9 @@
 \section{Conclusion\label{d3:conclusion}}
 
-\copied{}
 Our work in this chapter started with the question: can DASH be used for NVE\@?
 The answer is \emph{yes}.
 In answering this question, we contributed by showing how to organize a polygon soup and its textures into a DASH-compliant format that (i) includes a minimal amount of metadata that is useful for the client, (ii) organizes the data to allow the client to get the most useful content first.
 We further show that the data organisation and its description with metadata (precomputed offline) is sufficient to design and build a DASH client that is adaptive --- it selectively downloads segments within its view, makes intelligent decisions about what to download, balances between geometry and texture while adapting to network bandwidth.
-\fresh{}
 This way, our system addresses the open problems we mentioned in~\ref{i:challenges}.
 
 \begin{itemize}

src/dash-3d/content-preparation.tex

@@ -1,4 +1,3 @@
-\copied{}
 \section{Content preparation\label{d3:dash-3d}}
 
 In this section, we describe how we pre-process and store the 3D data of the NVE, consisting of a polygon soup, textures, and material information into a DASH-compliant Media Presentation Description (MPD) file.
@@ -14,7 +13,6 @@ This element does not apply to NVE, and we use a single \texttt{period} for the
 Each \texttt{period} element contains one or more adaptation sets, which describe the alternate versions, formats, and types of media.
 We utilize adaptation sets to organize a 3D scene's material, geometry, and texture.
 
-\fresh{}
 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 preprocesses the geometry and then the textures.
 The MPD is generated by a library named \href{https://github.com/netvl/xml-rs}{xml-rs} that works like a stack:
@@ -25,8 +23,6 @@ The MPD is generated by a library named \href{https://github.com/netvl/xml-rs}{x
 \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 data chunks.
 
-\copied{}
-
 \subsection{Adaptation Sets}
 When the user navigates freely within an NVE, the frustum at given time almost always contains a limited part of the 3D scene.
 Similar to how DASH for video streaming partitions a video clip into temporal chunks, we segment the polygons into spatial chunks, such that the DASH client can request only the relevant chunks.
@@ -114,6 +110,5 @@ For textures, each representation contains a single segment.
     ]{assets/dash-3d/geometry-as.xml}
 \end{figure}
 
-\fresh{}
 Now that 3D data is partitioned and that the MPD file is generated, we see in the next section how the client uses the MPD to request the appropriate data chunks
 

src/dash-3d/evaluation.tex

@@ -1,4 +1,3 @@
-\copied{}
 \section{Evaluation\label{d3:evaluation}}
 
 We now describe our setup and the data we use in our experiments. We present an evaluation of our system and a comparison of the impact of the design choices we introduced in the previous sections.

src/dash-3d/introduction.tex

@@ -1,4 +1,3 @@
-\fresh{}
 \section{Introduction}
 
 In this chapter, we take a little step back from interaction and propose a system with simple interactions that however, addresses most of the open problems mentioned in Section~\ref{i:challenges}.

src/dash-3d/main.tex

@@ -30,16 +30,8 @@ We finally evaluate these system parameters under different bandwidth setups and
 \newpage
 
 \input{dash-3d/introduction}
-\resetstyle{}
-
 \input{dash-3d/content-preparation}
-\resetstyle{}
-
 \input{dash-3d/client}
-\resetstyle{}
-
 \input{dash-3d/evaluation}
-\resetstyle{}
-
 \input{dash-3d/conclusion}
-\resetstyle{}
+