dash-3d-tmp
/
phd
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Listing -> Snippet

This commit is contained in:
Thomas Forgione 2020-02-06 11:41:44 +01:00
parent 4b461b7a8d
commit b5ffd3408e
6 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
src/dash-3d/client.tex
View File

@ -98,7 +98,7 @@ Note that the texture segments have similar information, but computed at \textit
The second information stored in the MPD for all segments, geometry, and texture, is the size of the segment (in kB). The second information stored in the MPD for all segments, geometry, and texture, is the size of the segment (in kB).
Finally, for each texture segment $s^{T}$, the MPD stores the \textit{MSE} (mean square error) of the image and resolution, relative to the highest resolution (by default, triangles are filled with its average color). Finally, for each texture segment $s^{T}$, the MPD stores the \textit{MSE} (mean square error) of the image and resolution, relative to the highest resolution (by default, triangles are filled with its average color).
Offline parameters are stored in the MPD as shown in Listing~\ref{d3:mpd}. Offline parameters are stored in the MPD as shown in Snippet~\ref{d3:mpd}.
\subsubsection{Online parameters} \subsubsection{Online parameters}
In addition to the offline parameters stored in the MPD file for each segment, view-dependent parameters are computed at navigation time. In addition to the offline parameters stored in the MPD file for each segment, view-dependent parameters are computed at navigation time.

2
src/dash-3d/content-preparation.tex
View File

@ -40,7 +40,7 @@ We consider a face to be large if its area in 3D is more than $a+3\sigma$, where
In our example, it selects the 5 largest faces that represent $15\%$ of the total face area. In our example, it selects the 5 largest faces that represent $15\%$ of the total face area.
We thus obtain a decomposition of the NVE into adaptation sets that partitions the geometry of the scene into a small adaptation set containing the larger faces of the model, and smaller adaptation sets containing the remaining faces. We thus obtain a decomposition of the NVE into adaptation sets that partitions the geometry of the scene into a small adaptation set containing the larger faces of the model, and smaller adaptation sets containing the remaining faces.
We store the spatial location of each adaptation set, characterized by the coordinates of its bounding box, in the MPD file as the supplementary property of the adaptation set in the form of ``\textit{$x_{\min}$, width, $y_{\min}$, height, $z_{\min}$, depth}'' (as shown in Listing~\ref{d3:mpd}). We store the spatial location of each adaptation set, characterized by the coordinates of its bounding box, in the MPD file as the supplementary property of the adaptation set in the form of ``\textit{$x_{\min}$, width, $y_{\min}$, height, $z_{\min}$, depth}'' (as shown in Snippet~\ref{d3:mpd}).
This information is used by the client to implement a view-dependent streaming (Section~\ref{d3:dash-client}). This information is used by the client to implement a view-dependent streaming (Section~\ref{d3:dash-client}).
\subsubsection{Texture management} \subsubsection{Texture management}

4
src/foreword/3d-model.tex
View File

@ -24,7 +24,7 @@ A 3D model encoded in the OBJ format typically consists in two files: the materi
The materials file declares all the materials that the object file will reference. The materials file declares all the materials that the object file will reference.
A material consists in name, and other photometric properties such as ambient, diffuse and specular colors, as well as texture maps, which are images that are painted on faces. A material consists in name, and other photometric properties such as ambient, diffuse and specular colors, as well as texture maps, which are images that are painted on faces.
Each face corresponds to a material. Each face corresponds to a material.
A simple material file is visible on Listing~\ref{i:mtl}. A simple material file is visible on Snippet~\ref{i:mtl}.
\paragraph{} \paragraph{}
The object file declares the 3D content of the objects. The object file declares the 3D content of the objects.
@ -42,7 +42,7 @@ Faces are declared by using the indices of these elements. A face is a polygon w
An object file can include materials from a material file (\texttt{mtllib path.mtl}) and apply the materials that it declares to faces. An object file can include materials from a material file (\texttt{mtllib path.mtl}) and apply the materials that it declares to faces.
A material is applied by using the \texttt{usemtl} keyword, followed by the name of the material to use. A material is applied by using the \texttt{usemtl} keyword, followed by the name of the material to use.
The faces declared after a \texttt{usemtl} are painted using the material in question. The faces declared after a \texttt{usemtl} are painted using the material in question.
An example of object file is visible on Listing~\ref{i:obj}. An example of object file is visible on Snippet~\ref{i:obj}.
\begin{figure}[th] \begin{figure}[th]
\centering \centering

14
src/foreword/implementation.tex
View File

@ -26,7 +26,7 @@ It provides classes to deal with everything we need:
\item the \textbf{Material} class is the class that holds the properties used to render geometry (the most important information being the texture), there are many classes derived from Material, and the developer can choose what material they want for its objects; \item the \textbf{Material} class is the class that holds the properties used to render geometry (the most important information being the texture), there are many classes derived from Material, and the developer can choose what material they want for its objects;
\item the \textbf{Mesh} class is the class that links the geometry and the material, it derives the Object class and can thus be added to a scene and rendered. \item the \textbf{Mesh} class is the class that links the geometry and the material, it derives the Object class and can thus be added to a scene and rendered.
\end{itemize} \end{itemize}
A snippet of the basic usage of these classes is given in Listing~\ref{f:three-hello-world}. A snippet of the basic usage of these classes is given in Snippet~\ref{f:three-hello-world}.
\begin{figure}[th] \begin{figure}[th]
\lstinputlisting[% \lstinputlisting[%
@ -61,7 +61,7 @@ There are two types of borrow, the immutable borrow and the mutable borrow (roug
The compiler comes with the \emph{borrow checker} which makes sure you only use variables that you are allowed to use. The compiler comes with the \emph{borrow checker} which makes sure you only use variables that you are allowed to use.
For example, the owner can only use the value if it is not being borrowed, and it is only possible to either borrow mutably a value once, or immutably borrow a value many times. For example, the owner can only use the value if it is not being borrowed, and it is only possible to either borrow mutably a value once, or immutably borrow a value many times.
At first, the borrow checker seems particularly efficient to detect bugs in concurrent software, but in fact, it is also decisive in non concurrent code. At first, the borrow checker seems particularly efficient to detect bugs in concurrent software, but in fact, it is also decisive in non concurrent code.
Consider the piece of C++ code in Listings~\ref{f:undefined-behaviour-cpp} and~\ref{f:undefined-behaviour-cpp-it}. Consider the piece of C++ code in Snippets~\ref{f:undefined-behaviour-cpp} and~\ref{f:undefined-behaviour-cpp-it}.
\begin{figure}[ht] \begin{figure}[ht]
\centering \centering
@ -81,14 +81,14 @@ Consider the piece of C++ code in Listings~\ref{f:undefined-behaviour-cpp} and~\
This loop should go endlessly because the vector grows in size as we add elements in the loop. This loop should go endlessly because the vector grows in size as we add elements in the loop.
But the most important thing here is that since we add elements to the vector, it will eventually need to be reallocated, and that reallocation will invalidate the iterator, meaning that the following iterator will provoke an undefined behaviour. But the most important thing here is that since we add elements to the vector, it will eventually need to be reallocated, and that reallocation will invalidate the iterator, meaning that the following iterator will provoke an undefined behaviour.
The equivalent code in Rust is in Listings~\ref{f:undefined-behaviour-rs} and~\ref{f:undefined-behaviour-rs-it}. The equivalent code in Rust is in Snippets~\ref{f:undefined-behaviour-rs} and~\ref{f:undefined-behaviour-rs-it}.
\begin{figure}[ht] \begin{figure}[ht]
\centering \centering
\begin{minipage}[c]{0.45\textwidth} \begin{minipage}[c]{0.45\textwidth}
\lstinputlisting[ \lstinputlisting[
language=rust, language=rust,
caption={Rust version of Listing~\rawref{f:undefined-behaviour-cpp}}, caption={Rust version of Snippet~\rawref{f:undefined-behaviour-cpp}},
label={f:undefined-behaviour-rs} label={f:undefined-behaviour-rs}
]{assets/dash-3d-implementation/undefined-behaviour.rs} ]{assets/dash-3d-implementation/undefined-behaviour.rs}
\end{minipage} \end{minipage}
@ -96,19 +96,19 @@ The equivalent code in Rust is in Listings~\ref{f:undefined-behaviour-rs} and~\r
\begin{minipage}[c]{0.45\textwidth} \begin{minipage}[c]{0.45\textwidth}
\lstinputlisting[ \lstinputlisting[
language=rust, language=rust,
caption={Rust version of Listing~\rawref{f:undefined-behaviour-cpp-it}}, caption={Rust version of Snippet~\rawref{f:undefined-behaviour-cpp-it}},
label={f:undefined-behaviour-rs-it} label={f:undefined-behaviour-rs-it}
]{assets/dash-3d-implementation/undefined-behaviour-it.rs} ]{assets/dash-3d-implementation/undefined-behaviour-it.rs}
\end{minipage} \end{minipage}
\end{figure} \end{figure}
What happens is that the iterator needs to borrow the vector. What happens is that the iterator needs to borrow the vector.
Since it is borrowed, it can no longer be borrowed as mutable since mutating it could invalidate the other borrowers. Since it is borrowed, it can no longer be borrowed as mutable since mutating it could invalidate the other borrowers.
And effectively, the borrow checker will crash the compiler with the error in Listing~\ref{f:undefined-behaviour-rs-error}. And effectively, the borrow checker will crash the compiler with the error in Snippet~\ref{f:undefined-behaviour-rs-error}.
\begin{figure}[ht] \begin{figure}[ht]
\lstinputlisting[ \lstinputlisting[
language=XML, language=XML,
caption={Error given by the compiler on Listing~\ref{f:undefined-behaviour-rs}}, caption={Error given by the compiler on Snippet~\ref{f:undefined-behaviour-rs}},
label={f:undefined-behaviour-rs-error} label={f:undefined-behaviour-rs-error}
]{assets/dash-3d-implementation/undefined-behaviour-error.txt} ]{assets/dash-3d-implementation/undefined-behaviour-error.txt}
\end{figure} \end{figure}

2
src/state-of-the-art/video.tex
View File

@ -74,7 +74,7 @@ That way, a client can choose to download either the low resolution of the whole
For each tile of the video, an adaptation set is declared in the MPD, and a supplemental property is defined in order to give the client information about the tile. For each tile of the video, an adaptation set is declared in the MPD, and a supplemental property is defined in order to give the client information about the tile.
This supplemental property contains many elements, but the most important ones are the position ($x$ and $y$) and the size (width and height) of the tile describing the position of the tile in relation to the full video. This supplemental property contains many elements, but the most important ones are the position ($x$ and $y$) and the size (width and height) of the tile describing the position of the tile in relation to the full video.
An example of such a property is given in Listing~\ref{sota:srd-xml}. An example of such a property is given in Snippet~\ref{sota:srd-xml}.
\begin{figure}[th] \begin{figure}[th]
\lstinputlisting[% \lstinputlisting[%

4
src/system-bookmarks/bookmark.tex
View File

@ -216,13 +216,13 @@ Bookmarks adaptation set only contain one representation, composed of two segmen
]{assets/system-bookmarks/bookmark-as.xml} ]{assets/system-bookmarks/bookmark-as.xml}
\end{figure} \end{figure}
An example of a bookmark adaptation set is depicted on Listing~\ref{sb:bookmark-as}. An example of a bookmark adaptation set is depicted on Snippet~\ref{sb:bookmark-as}.
The three first values in the supplemental property are the camera position coordinates, and the three last values are the target point coordinates. The three first values in the supplemental property are the camera position coordinates, and the three last values are the target point coordinates.
\subsection{Loader modifications} \subsection{Loader modifications}
We build on the loader introduced in Algorithm~\ref{d3:next-segment} to implement a client adaptation logic. We build on the loader introduced in Algorithm~\ref{d3:next-segment} to implement a client adaptation logic.
We include a bookmark adaptation logic such that (i) when a bookmark is hovered for the first time, the corresponding thumbnail image as well as the JSON file containing the optimal order of the segments (see Listing~\ref{sb:bookmark-as}) are downloaded, and (ii) when a bookmark is clicked, we switch from utility $\mathcal{U}$ to optimized utility $\mathcal{U}^*$ to determine which segments to download next. We include a bookmark adaptation logic such that (i) when a bookmark is hovered for the first time, the corresponding thumbnail image as well as the JSON file containing the optimal order of the segments (see Snippet~\ref{sb:bookmark-as}) are downloaded, and (ii) when a bookmark is clicked, we switch from utility $\mathcal{U}$ to optimized utility $\mathcal{U}^*$ to determine which segments to download next.
\begin{algorithm}[th] \begin{algorithm}[th]
\SetKwInOut{Input}{input} \SetKwInOut{Input}{input}