phd/src/introduction/challenges.tex

52 lines
3.4 KiB
TeX
Raw Normal View History

2019-09-18 17:43:45 +02:00
\fresh{}
2019-09-24 11:08:42 +02:00
\section{Open problems}
2019-09-18 17:43:45 +02:00
The objective of our work is to design a system that allows a user to access remote 3D content that guarantees good quality of service and quality of experience.
A 3D streaming client has lots of tasks to accomplish:
\begin{itemize}
\item render a scene;
\item find out what to download and download it;
\item parse the result of the download;
\item add the parsed result to the scene;
\item manage the interaction with the user.
\end{itemize}
To add to the challenge, we hope to have a client that would be portable between devices, and that would work easily on both desktop and mobile setups.
2019-09-24 11:08:42 +02:00
We have to setup a client-server architecture while respecting constraints required for performant software:
2019-09-18 17:43:45 +02:00
\begin{itemize}
2019-09-24 11:08:42 +02:00
\item \textbf{for the server}, since a server must serve many clients, and a solution that requires even low computation on the server will scale difficultly;
\item \textbf{for the client}, since the end user will use his own device, whether it be an old computer or a mobile device, and has many other things to do than simply downloading content.
2019-09-18 17:43:45 +02:00
\end{itemize}
2019-09-24 11:08:42 +02:00
This opens multiple problems that we need to take care of.
\subsection{Content preparation}
Any preprocessing that can be done on our 3D data gives us an advantage since it consists in computations that will not be needed live, neither for the server nor for the client.
Furthermore, for streaming, data needs to be split into chunks that are requested separately, so perparing those chunks in advance also gives us an advantage during the streaming.
2019-09-18 17:43:45 +02:00
2019-09-24 11:08:42 +02:00
\subsection{Chunk utility}
Once our content is prepared and split in chunks, we need to be able to rate those chunks depending to the user position.
A chunk that contains data in the field of view of the user must have a higher score that a chunk outside of it; a chunk that is close to the camera must have a higher score that a chunk far away from the camera, etc\ldots
2019-09-18 17:43:45 +02:00
2019-09-24 11:08:42 +02:00
\subsection{Streaming policies}
Rating the chunks is not enough, there are other parameters that need to be taken into account.
For example, the time needed to download a chunk is important: when two segments have the same score, a smart client would rather download the once that arrives earlier.
The user interaction can also be taken into account: if we are able to perdict the user movement in the scene, we can get a more precise information about what chunks should be downloaded.
This is why we need to define streaming policies that rely on chunk utilities to determine the optimal segments to download.
2019-09-18 17:43:45 +02:00
2019-09-24 11:08:42 +02:00
\subsection{Evaluation}
All the problems mentionned earlier yield many ideas and solutions that have different parameters.
We need to compare the different options we have for each of the previous problems, and evaluate their impact in terms of Quality of Service and Quality of Exeperience.
2019-09-18 17:43:45 +02:00
2019-09-24 11:08:42 +02:00
\subsection{Implementation}
Implementation is a key problem for our system.
We need to write software that answers the problems mentionned earlier (content preparation, chunk utility, streaming policies) as well as developing a client that performs 3D rendering in an efficient manner in order to leave resources to the other tasks that are needed.
Furthermore, since we want to be able to evaluate our systems, user studies are required and using web technologies are what make this possible.
Therefore, part of our software needs to be runnable from a web browser.
2019-09-18 17:43:45 +02:00