Proof read dash3d

src/dash-3d/client.tex

@@ -9,7 +9,7 @@ A camera path generated by a particular user is a set of viewpoint $v(t_i)$ inde
 \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 requests and receiving responses;
+    \item the \emph{access client}, which is the module that deals with making HTTP requests and receiving responses;
     \item the \emph{segment parsers}, which decodes the data downloaded by the access client, whether it be materials, geometry or textures;
     \item the \emph{control engine}, which analyses the bandwidth to dynamically adapt to it;
     \item the \emph{media engine}, which renders the multimedia content and the user interface to the screen.
@@ -149,7 +149,7 @@ Having defined a utility on both geometry and texture segments, the client uses
 
 Along the camera path $C=\{v(t_i)\}$, viewpoints are indexed by a continuous time interval $t_i \in  [t_1,t_{end}]$.
 Contrastingly, the DASH adaptation logic proceeds sequentially along a discrete time line.
-The first request \texttt{(HTTP request)} made by the DASH client at time $t_1$ selects the most useful segment $s_1^*$ to download and will be followed by subsequent decisions at $t_2, t_3, \dots$.
+The first HTTP request made by the DASH client at time $t_1$ selects the most useful segment $s_1^*$ to download and will be followed by subsequent decisions at $t_2, t_3, \dots$.
 While selecting $s_i^*$, the i-th best segment to request, the adaptation logic compromises between geometry, texture, and the available \texttt{representations} given the current bandwidth, camera dynamics, and the previously described utility scores.
 The difference between $t_{i+1}$  and $t_{i}$ is the $s_i^*$ delivery delay.
 It varies with the segment size and network conditions.
@@ -473,7 +473,7 @@ This is why we also implemented a client in Rust, for simulation, so we can gath
 Our requirements are quite different that the ones we had to deal with in our JavaScript implementation.
 In this setup, we want to build a system that is the closest to our theoretical concepts.
 Therefore, we do not have a full client in Rust (meaning an application to which you would give the URL to an MPD file and that would allow you to navigate in the scene while it is being downloaded).
-In order to be able to run simulations, we develop the bricks of the DASH client separately: the access client and the media engine are totally separated:
+In order to be able to run simulations, we develop the bricks of the DASH client separately: the access client and the media engine are totally isolated:
 \begin{itemize}
     \item the \textbf{simulator} takes a user trace as a parameter, it then replays the trace using specific parameters of the access client and outputs a file containing the history of the simulation (which files have been downloaded, and when);
     \item the \textbf{renderer} takes the user trace as well as the history generated by the simulator as parameters, and renders images that correspond to what would have been seen.

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

@@ -36,7 +36,7 @@ We use a space partitioning tree to organize the faces into cells.
 A face belongs to a cell if its barycenter falls inside the corresponding bounding box.
 Each cell corresponds to an adaptation set.
 Thus, geometry information is spread on adaptation sets based on spatial coherence, allowing the client to download the relevant faces selectively.
-A cell is relevant if it intersects the frustum of the client's current viewpoint. Figure~\ref{d3:big-picture} shows the relevant cells in blue.
+A cell is relevant if it intersects the frustum of the client's current viewpoint. Figure~\ref{d3:big-picture} shows the relevant cells in green.
 As our 3D content, a virtual environment, is biased to spread the most along the horizontal plane, we alternate between splitting between the two horizontal directions.
 
 We create a separate adaptation set for large faces (e.g., the sky or ground) because they are essential to the 3D model and do not fit into cells.