Some updates
This commit is contained in:
parent
c1bb5662c7
commit
0f11fe5f45
|
@ -16,9 +16,9 @@ A screenshot of this interface is displayed in Figure~\ref{sb:desktop}.
|
|||
\copied{}
|
||||
Mobile interactions are more complex because the user does not have neither keyboard nor mouse to interact with.
|
||||
However, there are some other sensors on most mobile devices that can help interaction.
|
||||
The most useful sensor for 3D interaction on mobile devices is definitely the gyroscope.
|
||||
One useful sensor for 3D interaction on mobile devices is definitely the gyroscope.
|
||||
We use the gyroscope to enable a user to rotate his device to rotate the virtual camera.
|
||||
We also add the possibility to rotate the camera by drag and dropping the scene.
|
||||
We also add the possibility to rotate the camera by using touch controls.
|
||||
This way, the user is not forced to perform a real-world half-turn to be able to look behind or to keep its device pointing to the sky (which can quickly become tiring) to look up.
|
||||
These interactions, however, do not allow the user to move the camera: he can rotate it but not translate it.
|
||||
For this reason, we display a small joystick on the bottom left corner of the screen that mimics the first person video games interactions and allow the user translating the camera:
|
||||
|
@ -48,11 +48,11 @@ For these reasons, we changed the display to a vertical bar with a 2D sprite of
|
|||
This 2D sprite is always facing the camera to prevent it from being invisible when the camera would be on the side of it.
|
||||
Screenshots of user interfaces with bookmarks are available in Figures~\ref{sb:desktop} and~\ref{sb:mobile}.
|
||||
|
||||
The size of the sprite changes when time goes by following a sine function to help the user distinguish what is part of the scene and what is extra widgets.
|
||||
The size of the sprite changes over time following a sine function to help the user distinguish what is part of the scene and what is extra widgets.
|
||||
Since our scene is static, a user knows that a changing object is not part of the scene, but part of the UI\@.
|
||||
|
||||
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 bookmark.
|
||||
We also display a thumbnail of the bookmark's viewpoint when the mouse hovers over 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}.
|
||||
Note that since on mobile, there is no mouse and thus no pointer, thumbnails are never downloaded nor displayed.
|
||||
|
||||
|
@ -160,6 +160,7 @@ These renderings allow us to know what geometry segment and what texture corresp
|
|||
|
||||
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, and they show that, for the same amount of data downloaded, the optimized order reaches a higher PSNR than the greedy order, which means that its utility metric is more accurate.
|
||||
This curve is averaged on all the 9 bookmarks of the scene: we decided the locations of the bookmarks and each bookmark faces an interesting object in the scene.
|
||||
|
||||
\begin{figure}[th]
|
||||
\centering
|
||||
|
@ -190,8 +191,8 @@ Each curve represents the PSNR one can obtain by downloading a certain amount of
|
|||
|
||||
\copied{}
|
||||
|
||||
We now present how to include bookmarks information in the Media Presentation Description (MPD) file
|
||||
Bookmarks are fully defined by a position, a direction, and the additional content needed to properly render and use a bookmark in a system consists in three images: a thumbnail of the point of view at the bookmark, along with the JSON file giving the optimal segment order for this viewpoint.
|
||||
We now present how to include bookmarks information in the Media Presentation Description (MPD) file.
|
||||
Bookmarks are fully defined by a position, a direction, and the additional content needed to properly render and use a bookmark in a system consists in two files: a thumbnail of the point of view at the bookmark, along with the JSON file giving the optimal segment order for this viewpoint.
|
||||
For this reason, for each bookmark, we create a separate adaptation set in the MPD\@.
|
||||
The bookmarked viewpoint information is stored as a supplemental property.
|
||||
Bookmarks adaptation set only contain one representation, composed of two segments: the thumbnail used as a preview for the desktop interface and the JSON file.
|
||||
|
|
|
@ -2,16 +2,16 @@
|
|||
|
||||
\section{Introduction}
|
||||
|
||||
In Chapter~\ref{bi}, we described how it is possible to modify a user interface to ease user nagivation in a 3D scene, and how the system can exploit it.
|
||||
In Chapter~\ref{d3}, we presented a streaming system that does not take the interface or the user interaction into account at all.
|
||||
Hence, it seems natural to us to try to bring back the user interaction into DASH-3D.
|
||||
In order to do so, we have chosen two angles of attack:
|
||||
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 a streaming system that takes neither the interface nor the user interaction into account.
|
||||
Hence, it is natural study how the user interaction can impact performances of DASH-3D.
|
||||
In order to do so, followed these two steps:
|
||||
|
||||
\begin{itemize}
|
||||
\item we design an interface allowing to navigate in a 3D scene for both desktop and mobile devices;
|
||||
\item we design an interface allowing to navigate in a 3D scene on both desktop and mobile devices;
|
||||
\item we improve and adapt the bookmarks described in Chapter~\ref{bi} to the context of DASH-3D and to mobile interaction.
|
||||
\end{itemize}
|
||||
|
||||
In Section~\ref{sb:interaction}, we present the different choices we made for the interfaces, and we describe the new mobile interface.
|
||||
In Section~\ref{sb:bookmarks}, we describe how we embed the bookmarks into our DASH framework, and how we precompute data in order to improve the quality of experience of the user.
|
||||
In Section~\ref{sb:evaluation}, we describe the user study we conducted, the data we collected and we analyse this data.
|
||||
In Section~\ref{sb:bookmarks}, we describe how we embed the bookmarks into our DASH framework, and how we precompute data in order to improve the user quality of experience.
|
||||
In Section~\ref{sb:evaluation}, we describe the user study we conducted, the data we collected and we analyse the results.
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
\chapter{Mobile interaction and system bookmarks\label{sb}}
|
||||
\chapter{Bookmarks for DASH-3D on mobile devices\label{sb}}
|
||||
|
||||
\minitoc{}
|
||||
\newpage
|
||||
|
|
|
@ -11,16 +11,16 @@ Since we already conduct a user study on desktop devices, we decide to conduct t
|
|||
In this user study, we use two models.
|
||||
\begin{itemize}
|
||||
\item For the tutorial, we use a first model from a video game, representing a small scene, to maintain a good framerate and to prevent users from getting lost in the scene.
|
||||
\item For all the other parts of the experiment, we kept using the model used in the previous chapter.
|
||||
\item For all the other parts of the experiment, we used an extended version of the model used in the previous chapter.
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Experiment}
|
||||
|
||||
The experiment consists in 4 phases: a tutorial, a comparison between interfaces with and without bookmarks, a comparison between two streaming policies, and a final navigation where the user is looking for objects in the scene.
|
||||
The experiment consists in 4 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.
|
||||
|
||||
\paragraph{Tutorial}
|
||||
|
||||
The experiment starts with a tutorial, so the users can get accustomed to our interface.
|
||||
The experiment starts with a tutorial, to get the users accustomed to our interface.
|
||||
This tutorial shows the different types of interactions available and explains how to use them.
|
||||
It then presents bookmarks to the users.
|
||||
|
||||
|
@ -39,7 +39,8 @@ This part of the experiment also consists in two 1 minute long sessions that use
|
|||
One of those experiment has the default greedy policy described in~\ref{d3:dash-adaptation}, and the other one has the enhanced policy for bookmarks.
|
||||
The order of those two sessions is randomized to avoid biases.
|
||||
|
||||
Since we know that the difference between our streaming policies are subtle, we designed a task a little more complex in order to highlight the differences so that the user can see it.
|
||||
% Since we know that the difference between our streaming policies is subtle, we designed a task a little more complex in order to highlight the differences so that the user can see it.
|
||||
Since the behaviours of our streaming policy only differ when the user clicks a bookmark, we designed a task where the users have to perform a guided tour of the scene, where each bookmark is a step of the tour.
|
||||
The user starts in the scene, and one of the bookmarks is blinking.
|
||||
The user has to click the bookmark, and wait a little when he arrives at the destination.
|
||||
Once some data has been downloaded, and the user is satisfied with the data downloaded, they can look for the next blinking bookmarks.
|
||||
|
@ -50,8 +51,9 @@ The questionnaire also has a text field for users to explain their answer if the
|
|||
|
||||
The last part of the experiment is a free navigation.
|
||||
Diamonds are hidden in the scene, and are invisible until the user is close enough.
|
||||
The users have to find the diamonds, and they can navigate by using the controls and the bookmarks.
|
||||
The loading policy is the default greedy policy for half of the users, and the enhanced policy for bookmarks for the other half.
|
||||
The users have to find the diamonds, and they can navigate by using indifferently the controls and the bookmarks.
|
||||
The loading policy is the default greedy policy for half of the users, and the enhanced policy for bookmarks for the other half, and this order has been randomized.
|
||||
With this part of the experiment, we hope to see differences in terms of PSNR for the two policies, when users are not forced to click on bookmarks.
|
||||
|
||||
\subsubsection{Apparatus\todo{lol, i like this title but im not sure}}
|
||||
|
||||
|
@ -62,7 +64,8 @@ There is no artificial bandwidth limitation due to the fact that the bandwidth i
|
|||
|
||||
\subsection{Results}
|
||||
|
||||
18 users participated in this user-study.
|
||||
18 users participated in this user-study, 15 males and 3 females, average age is 20.7 and standard deviation is 0.53.
|
||||
We only proposed this user study to relatively young people to ensure they are used to mobile devices.
|
||||
|
||||
\subsubsection{Qualitative results --- Interaction}
|
||||
|
||||
|
|
Loading…
Reference in New Issue