gg modifs
This commit is contained in:
parent
937eb3816d
commit
acf7cb6030
|
@ -12,7 +12,7 @@ A screenshot of this interface is displayed in Figure~\ref{sb:desktop}.
|
||||||
\begin{figure}[ht]
|
\begin{figure}[ht]
|
||||||
\centering
|
\centering
|
||||||
\includegraphics[width=\textwidth]{assets/system-bookmarks/screenshots/desktop.png}
|
\includegraphics[width=\textwidth]{assets/system-bookmarks/screenshots/desktop.png}
|
||||||
\caption{Screenshot of the desktop version, with a bookmark and its thumbnail on the bottom left corner\label{sb:desktop}}
|
\caption{Screenshot of the desktop version, with a bookmark and its thumbnail on the bottom left corner and three bookmarks\label{sb:desktop}}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
\subsection{Mobile interaction}
|
\subsection{Mobile interaction}
|
||||||
|
@ -62,7 +62,7 @@ Since our scene is static, a user knows that a changing object is not part of th
|
||||||
The other bookmark parameters remain unchanged since Chapter~\ref{bi}: in order to avoid users to lose context, clicking on a bookmark triggers an automatic, smooth, camera displacement that ends up at the bookmarked camera position.
|
The other bookmark parameters remain unchanged since Chapter~\ref{bi}: in order to avoid users to lose context, clicking on a bookmark triggers an automatic, smooth, camera displacement that ends up at the bookmarked camera position.
|
||||||
We also display a thumbnail of the bookmark's viewpoint when the mouse hovers a bookmark.
|
We also display a thumbnail of the bookmark's viewpoint when the mouse hovers a bookmark.
|
||||||
Such thumbnail is displayed in Figure~\ref{sb:desktop}.
|
Such thumbnail is displayed in Figure~\ref{sb:desktop}.
|
||||||
Note that since on mobile, there is no mouse and thus no pointer, thumbnails are never downloaded nor displayed.
|
Note that since on mobile, there is no mouse and thus no pointer, thus thumbnails not used in the mobile setting.
|
||||||
|
|
||||||
|
|
||||||
\begin{algorithm}[th]
|
\begin{algorithm}[th]
|
||||||
|
@ -156,7 +156,9 @@ These renderings allow us to know which geometry segment and which texture corre
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
Figure~\ref{sb:precomputation} shows how this precomputation improves the quality of rendering.
|
Figure~\ref{sb:precomputation} shows how this precomputation improves the quality of rendering.
|
||||||
Each curve represents the PSNR one can obtain by downloading a certain amount of data following the greedy policy introduced in Section~\ref{d3:dash-adaptation}. The blue curve, labelled "Default order", is obtained by optimizing the utilities as defined in Section~\ref{d3:utility}, whereas the green curve labelled "Proposed order" uses the sorting computed in Algorithm~\ref{sb:algo-optimal-order}. We can observe that for the same amount of data downloaded, the optimized order reaches a higher PSNR which means that its utility metric is more accurate.
|
Each curve represents the PSNR one can obtain by downloading a certain amount of data following a streaming policy.
|
||||||
|
The blue curve, labelled ``Default order'', is obtained by optimizing the utilities as defined in Section~\ref{d3:utility}, whereas the green curve labelled ``Proposed order'' uses the sorting computed in Algorithm~\ref{sb:algo-optimal-order}.
|
||||||
|
We can observe that for the same amount of data downloaded, the optimized order reaches a higher PSNR which means that its utility metric is more accurate.
|
||||||
Note that this curve is averaged over all the 9 bookmarks of the scene. These bookmarks are chosen to cover the widest area in the scene, and each one faces a particular object-of-interest.
|
Note that this curve is averaged over all the 9 bookmarks of the scene. These bookmarks are chosen to cover the widest area in the scene, and each one faces a particular object-of-interest.
|
||||||
|
|
||||||
\begin{figure}[th]
|
\begin{figure}[th]
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
In this chapter, our objective was to propose a mobile interface for DASH-3D and to integrate back the interaction aspects that we developed in Chapter~\ref{bi}.
|
In this chapter, our objective was to propose a mobile interface for DASH-3D and to integrate back the interaction aspects that we developed in Chapter~\ref{bi}.
|
||||||
%We have seen that doing so is not trivial, and many improvements have been made.
|
%We have seen that doing so is not trivial, and many improvements have been made.
|
||||||
For aesthetics and performance reasons, the UI of the bookmarks has changed, and new interactions were proposed for free navigation in the 3D scene.
|
For aesthetics and performance reasons, the UI of the bookmarks has changed, and new interactions were proposed for free navigation in the 3D scene.
|
||||||
We developed an algorithm that computes offline a better order of segments from a certain viewpoint than what a greedy policy would do.
|
We developed an algorithm that computes offline a better order of segments for bookmarks than what a greedy policy would do.
|
||||||
We encoded this optimal order in a JSON file and we modified our MPD in order to give metadata about bookmarks to the client, as well as modified our client implementation to benefit from this.
|
We encoded this optimal order in a JSON file and we modified our MPD in order to give metadata about bookmarks to the client, as well as modified our client implementation to benefit from this.
|
||||||
We then conducted a user study on 18 participants where users had to navigate in scenes with bookmarks and using various streaming policies.
|
We then conducted a user study on 18 participants where users had to navigate in scenes with bookmarks and using various streaming policies.
|
||||||
The results indicate that users prefer the optimized version of the policy, which is coherent with the PSNR values that we computed. The results also show that users who enjoy an optimized policy tend to use the bookmarks more.
|
The results indicate that users prefer the optimized version of the client streaming policy, which is coherent with the PSNR values that we computed. The results also show that users who enjoy an optimized policy tend to use the bookmarks more.
|
||||||
|
|
|
@ -3,7 +3,7 @@
|
||||||
In Chapter~\ref{bi}, we described how it is possible to modify a user interface to ease user navigation in a 3D scene, and how the system can benefit from it.
|
In Chapter~\ref{bi}, we described how it is possible to modify a user interface to ease user navigation in a 3D scene, and how the system can benefit from it.
|
||||||
In Chapter~\ref{d3}, we presented the DASH-3D streaming system, which does not depend on the interface nor on the user interaction.
|
In Chapter~\ref{d3}, we presented the DASH-3D streaming system, which does not depend on the interface nor on the user interaction.
|
||||||
In this chapter, we will analyze how the user interaction can impact performances of DASH-3D.
|
In this chapter, we will analyze how the user interaction can impact performances of DASH-3D.
|
||||||
In order to do so, we followed these two steps:
|
In order to do so, we follow these two steps based on our DASH framework:
|
||||||
|
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item we design an interface allowing to navigate in a 3D scene on both desktop and mobile devices;
|
\item we design an interface allowing to navigate in a 3D scene on both desktop and mobile devices;
|
||||||
|
|
|
@ -13,8 +13,8 @@ For these reasons, using DASH to stream 3D on mobile devices requires specific a
|
||||||
We add some widgets on the screen to support touch interactions: a virtual joystick is displayed on the screen and the user can touch it to translate the camera, instead of using the W, A, S and D keys on a computer keyboard.
|
We add some widgets on the screen to support touch interactions: a virtual joystick is displayed on the screen and the user can touch it to translate the camera, instead of using the W, A, S and D keys on a computer keyboard.
|
||||||
Since most mobile devices embed a gyroscope, we allow users to rotate the camera by physically rotating the device.
|
Since most mobile devices embed a gyroscope, we allow users to rotate the camera by physically rotating the device.
|
||||||
This interaction is more precise and intuitive to the user, but it is also more tiring, this is why we also added a touch interaction to rotate the screen: a user can also ``touch and drag'' at any point on the screen that does not correspond to the joystick to rotate the camera.
|
This interaction is more precise and intuitive to the user, but it is also more tiring, this is why we also added a touch interaction to rotate the screen: a user can also ``touch and drag'' at any point on the screen that does not correspond to the joystick to rotate the camera.
|
||||||
In order to ease navigation, we integrate bookmarks back, and we include an enhanced version of the precomputations explained in Chapter~\ref{sb} in the DASH Media Presentation Description.
|
In order to ease navigation, we integrate bookmarks back, and we propose an enhanced version of the precomputations explained in Chapter~\ref{sb} that we encode in the DASH Media Presentation Description.
|
||||||
We then present a user study on 18 participants, that evaluate how users perceive the visual quality of the scene, and how their interactions affect it.
|
We then present a user study on 18 participants, that evaluates how users perceive the visual quality of the scene, and how their interactions affect it.
|
||||||
|
|
||||||
\newpage
|
\newpage
|
||||||
|
|
||||||
|
|
|
@ -1,4 +1,6 @@
|
||||||
\section{Evaluation}\label{sb:evaluation}
|
\section{Evaluation}\label{sb:evaluation}
|
||||||
|
We now describe our setup and the data we use in our experiments.
|
||||||
|
We then present a user study where users try our new interface with different streaming policies and we compare the impact of the design choices we introduced in the previous sections.
|
||||||
|
|
||||||
\subsection{Preliminary user study}
|
\subsection{Preliminary user study}
|
||||||
|
|
||||||
|
@ -17,7 +19,7 @@ For these reasons, we decided to setup a new experiment, with a less complex tas
|
||||||
In this user study, we display two successive 3D models to the users:
|
In this user study, we display two successive 3D models to the users:
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item For the tutorial phase, we use a model derived from a video game, representing a small scene, in order to prevent users from getting lost in the scene.
|
\item For the tutorial phase, we use a model derived from a video game, representing a small scene, in order to prevent users from getting lost in the scene.
|
||||||
\item For all the other parts of the experiment, we use a larger version of the Singaporean district 3D model, that include neighbouring districts such as Central Business District.
|
\item For all the other parts of the experiment, we use a larger version of the Singaporean district 3D model, that include neighbouring districts such as Central Business District. A screenshot of the extended model is given in Figure~\ref{sb:models} and statistics about sizes are given in Table~\ref{sb:size}.
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
\begin{figure}[ht]
|
\begin{figure}[ht]
|
||||||
|
@ -29,9 +31,23 @@ In this user study, we display two successive 3D models to the users:
|
||||||
\includegraphics[width=\textwidth]{assets/system-bookmarks/models/after.png}
|
\includegraphics[width=\textwidth]{assets/system-bookmarks/models/after.png}
|
||||||
\caption{Extended model}
|
\caption{Extended model}
|
||||||
\end{subfigure}
|
\end{subfigure}
|
||||||
\caption{Models used in our user studies}
|
\caption{Models used in our user studies\label{sb:models}}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
|
\begin{table}[th]
|
||||||
|
\centering
|
||||||
|
\begin{tabular}{lll}
|
||||||
|
\toprule
|
||||||
|
\textbf{Files} & \textbf{Previous model} & \textbf{Extended model} \\ \midrule
|
||||||
|
OBJ file & 62 MB & 116 MB \\
|
||||||
|
MTL file & 0.27MB & 0.52 MB \\
|
||||||
|
Textures (high res) & 167 MB & 487 MB\\
|
||||||
|
Textures (low res) & 11 MB & 30 MB \\
|
||||||
|
\bottomrule
|
||||||
|
\end{tabular}
|
||||||
|
\caption{Sizes of the different files of the model\label{sb:size}}
|
||||||
|
\end{table}
|
||||||
|
|
||||||
\subsubsection{Experiment}
|
\subsubsection{Experiment}
|
||||||
|
|
||||||
The experiment is articulated into four phases: a tutorial, a comparison between interfaces with and without bookmarks, a comparison between two streaming policies, and a final navigation during which the user is looking for objects in the scene.
|
The experiment is articulated into four phases: a tutorial, a comparison between interfaces with and without bookmarks, a comparison between two streaming policies, and a final navigation during which the user is looking for objects in the scene.
|
||||||
|
@ -152,7 +168,7 @@ We also observe that the gyrocope-based interaction to rotate the camera tends t
|
||||||
\subsubsection{Quantitative results}
|
\subsubsection{Quantitative results}
|
||||||
|
|
||||||
Among the 18 participants of this user study, the answers given by users at the end of the \textbf{streaming} part of the experiment were as follows: 10 indicated that they preferred the optimized policy, 4 preferred the greedy policy, and 4 did not perceive the difference.
|
Among the 18 participants of this user study, the answers given by users at the end of the \textbf{streaming} part of the experiment were as follows: 10 indicated that they preferred the optimized policy, 4 preferred the greedy policy, and 4 did not perceive the difference.
|
||||||
One should note that the difference between the two policies can be described in the following terms. The greedy policy tends to favor the largest geometry segments and as a result, the scene structure tends to appear a little bit faster with this method. On the other hand, because it explicitly uses PSNR as an objective function, the optimized policy may result in downloading important textures (that appear large on the screen) before some mid-size geometry segments (that, for example, are typically far from the camera). Some of the users managed to precisely describe these differences.
|
One should note that the difference between the two policies can be described in the following terms. The greedy policy tends to favor the largest geometry segments and as a result, the scene structure tends to appear a little bit faster with this method. On the other hand, because it explicitly uses PSNR as an objective function, the optimized policy may result in downloading important textures (that appear large on the screen) before some mid-size geometry segments (that, for example, are typically far from the camera). Some users managed to precisely describe these differences.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue