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

Proof paper 1

This commit is contained in:
Thomas Forgione 2019-10-19 23:33:50 +02:00
parent a18f259fa2
commit 9178fed55f
No known key found for this signature in database
GPG Key ID: BFD17A2D71B3B5E7
3 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
src/preliminary-work/conclusion.tex
View File

@ -3,7 +3,7 @@
\section{Conclusion\label{bi:conclusion}}
In this chapter, we have described an interface that allows a user to navigate in a scene that is being streamed.
We identified and addressed the problems linked to the dynamics of both the user behaviour and the 3D content:
We identified and addressed the problems linked to the dynamics of both the user behaviour and the 3D content.
\begin{itemize}
\item Navigating in a 3D scene can be complex, due to the many degrees of freedom, and tweaking the interface can increase the user's Quality of Experience.
@ -14,7 +14,7 @@ We identified and addressed the problems linked to the dynamics of both the user
However, the system described in this chapter has some drawbacks and fails to answer the problems we mentioned in Section~\ref{i:challenges}, and all these problems come from the fact that \textbf{the content preparation is inexistent}.
The server knows all the data and simply determines what the client needs, it prepares the content and builds chunks on the go.
Thus, he server has to keep track of what the client already has (which will eat memory) and has to compute what should be sent next (which will eat CPU). The scalability of such a server is therefore not possible.
Thus, the server has to keep track of what the client already has (which will eat memory) and has to compute what should be sent next (which will eat CPU). The scalability of such a server is therefore inexistent.
Furthermore, we only considered geometry streaming: materials and textures are downloaded before the streaming starts, which causes great latency at the start of the streaming and harms the quality of experience.
After learning these lessons, we describe, in the next chapter, what is possible to do in order to alleviate these issues.

4
src/preliminary-work/main.tex
View File

@ -18,7 +18,7 @@
\begin{subfigure}[b]{0.45\textwidth}
\includegraphics[width=\textwidth]{assets/preliminary-work/bookmarks/arrow-bookmark-with-preview.png}
\caption{A preview is shown when the mouse hovers over a bookmark}
\caption{A preview is shown when the mouse hovers a bookmark}
\end{subfigure}
\begin{subfigure}[b]{0.45\textwidth}
\includegraphics[width=\textwidth]{assets/preliminary-work/bookmarks/arrow-bookmark.png}
@ -32,7 +32,7 @@ In this chapter, we present our first contribution: an analysis of the impact of
We implement a 3D navigation interface where the keyboard translates the camera and the mouse rotates it.
We augment this interface with 3D bookmarks.
When the user's cursor hovers over a bookmark, a preview of the point of view is displayed to the user, and when the user clicks on a bookmark, the camera smoothly moves from its current position to the bookmarked point of view.
When the user's cursor hovers a bookmark, a preview of the point of view is displayed to the user, and when the user clicks on a bookmark, the camera smoothly moves from its current position to the bookmarked point of view.
We conduct a within-subject user-study on 51 participants, where each user starts with a tutorial to get used to the 3D navigation controls, and then tries successively to perform a task with and without bookmarks.
We show that not only the presence of bookmarks causes a faster task completion, but also that it allows users to see a larger part of the scene during the same time span.

8
src/preliminary-work/streaming.tex
View File

@ -88,7 +88,7 @@ It is not scalable to compute this for every viewpoint requested by the client.
However, we can pre-render the bookmarked viewpoints, since the number of bookmarks is limited, their viewpoints are known in advance, and they are likely to be accessed.
For each bookmark, we render offline the scene using a single color per triangle.
Once rendered, we scan the output image to find the visible triangles (based on the color) and sort them by decreasing projected area.
This technique is also used by~\cite{view-dependent-progressive-mesh}.
This technique is also used by~\citep{view-dependent-progressive-mesh}.
Thus, when the user clicks on a 3D bookmark, this pre-computed list of faces is used by the server, and only visible faces are sent in decreasing order of contributions to the rendered image.
For the three scenes that we used in the experiment, we can reduce the number of triangles sent by 60\% (over all bookmarks).
@ -126,7 +126,7 @@ In what follows, we will refer to this streaming policy as \textsf{visible}.
\end{axis}
\end{tikzpicture}
\caption{Comparison of rendered image quality (average on all bookmarks and starting position): the triangles are sorted offline (dotted curve), or sorted online by distance to the viewpoint (solid curve).}\label{bi:sorted-tri}
\caption{Comparison of rendered image quality (average on all bookmarks and starting position): the triangles are sorted offline (green curve), or sorted online by distance to the viewpoint (blue curve).}\label{bi:sorted-tri}
\end{figure}
\subsubsection{Prefetching by Predicting the Next Bookmark Clicked}
@ -234,10 +234,10 @@ The first point we are interested in is which streaming policy leads to the lowe
\caption{Average percentage of the image pixels that are correctly rendered against time, for all users with bookmarks, and using a bandwidth (BW) of 1 Mbps. The origin, $t=0$, is the time of the first click on a bookmark. Each curve corresponds to a streaming policy.\label{bi:click-1250}}
\end{figure}
Figure~\ref{bi:click-1250} compares the quality of the view of a user after his/her first click on a bookmark.
Figure~\ref{bi:click-1250} compares the quality of the view of a user after their first click on a bookmark.
The ratio of pixels correctly displayed is computed in the client algorithm, see also algorithm~\ref{bi:streaming-algorithm-client}.
In this figure we use a bandwidth of 1 Mbps.
The solid curve corresponds to the \textsf{culling} policy.
The blue curve corresponds to the \textsf{culling} policy.
Clicking on a bookmark generates a user path with less spatial locality, causing a large drop in visual quality that is only compensated after 4 seconds.
During the first second, the camera moves from the current viewport to the bookmarked viewport.