Thierry's fix

This commit is contained in:
2019-10-11 11:06:22 +02:00
parent beee676839
commit bd7bc84eee
19 changed files with 36 additions and 38 deletions

View File

@@ -220,7 +220,7 @@ Since our scene is large, and since the system we are describing allows navigati
\subsubsection{Media engine}
Of course, in this work, we are concerned about performance of our system, and we will not be able to use the normal geometries described in Section~\ref{f:geometries}.
However, the way our system works, the way changes happen to the 3D content is always the same: we only add faces and textures to the model.
However, in our system, the way changes happen to the 3D content is always the same: we only add faces and textures to the model.
Therefore, we made a class that derives BufferGeometry, and that makes it more convenient for us.
\begin{itemize}
\item It has a constructor that takes as parameter the number of faces: it allocates all the memory needed for our buffers so we do not have to reallocate it which would be inefficient.
@@ -230,8 +230,8 @@ Therefore, we made a class that derives BufferGeometry, and that makes it more c
\end{itemize}
\paragraph{Our 3D model class.\label{d3:model-class}}
As said in the previous subsections, a geometry and a material a bound together in a mesh.
This means that we are forced to have has many meshes as there are materials in our model.
As said in the previous subsections, a geometry and a material are bound together in a mesh.
This means that we are forced to have as many meshes as there are materials in our model.
To make this easy to manage, we made a \textbf{Model} class, that holds everything we need.
We can add vertices, faces, and materials to this model, and it will internally deal with the right geometries, materials and meshes.
In order to avoid having many models that have the same material which would harm performance, it automatically merges faces that share the same material in the same buffer geometry, as shown in Figure~\ref{d3:render-structure}.
@@ -473,7 +473,7 @@ In this setup, we want to build a system that is the closest to our theoretical
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:
\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 (what files have been downloaded, and when);
\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.
\end{itemize}
When simulating experiments, we will run the simulator on many traces that we collected during user-studies, and we will then run the renderer program on it to generate images corresponding to the simulation.

View File

@@ -17,7 +17,7 @@ We utilize adaptation sets to organize a 3D scene's material, geometry, and text
\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 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:
The MPD is generated by a library named \href{https://github.com/netvl/xml-rs}{xml-rs} 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;

View File

@@ -7,10 +7,8 @@
\centering
\includegraphics[width=\textwidth]{assets/dash-3d/bigpicture.png}
\caption{%
A subdivided 3D scene with a viewport, with regions delimited with
red edges. In white, the regions that are outside the field of view
of the camera; in green, the regions inside the field of view of the
camera.\label{d3:big-picture}
A subdivided 3D scene with a viewport and regions delimited with red edges.
In white, the regions that are outside the field of view of the camera; in green, the regions inside the field of view of the camera.\label{d3:big-picture}
}
\end{figure}