- conclusion contributions proofread
This commit is contained in:
parent
8a8e03f9d0
commit
5e8d7dd4c2
|
@ -3,32 +3,32 @@
|
|||
In this thesis, we have presented three main contributions.
|
||||
|
||||
\paragraph{}
|
||||
First, we set up a basic system allowing 3D navigation and 3D content streaming in the context of streaming online 3D content consisting in textured meshes.
|
||||
First, we set up a basic system allowing navigation in a 3D scene (represented as a textured mesh) with the content being streamed through the network from a remote server.
|
||||
We developed a navigation aid in the form of \textbf{3D bookmarks}, and we conducted a user study to analyse its impact on navigation and streaming.
|
||||
On one hand, consistently with the state of the art, we observed that navigation aid \textbf{helps people navigating in a scene}, since they perform tasks faster and more easily.
|
||||
On the other hand, we showed that benefiting from bookmarks in 3D navigation comes at the cost of a negative impact for the quality of service (QoS): since users navigate faster, they require more data during the same time span.
|
||||
However, we also showed that this cost is not a fatality: using prior knowledge we have about bookmarks, we are able to \textbf{precompute data ordering offline} so that when users click on bookmark, their QoS improves.
|
||||
On the other hand, we showed that benefiting from bookmarks in 3D navigation comes at the cost of a negative impact on the quality of service (QoS): since users navigate faster, they require more data during the same time span.
|
||||
However, we also showed that this cost is not a fatality: using prior knowledge we have about bookmarks, we are able to \textbf{precompute an optimal data ordering offline} so that the QoS increases when users click on bookmarks.
|
||||
Simulations on the traces we collected during the user study quantify how these precomputations \textbf{improve the QoS}.
|
||||
This work has been published at the conference MMSys in 2016~\citep{bookmarks-impact}.
|
||||
This work has been published at the ACM MMSys conference in 2016~\citep{bookmarks-impact}.
|
||||
|
||||
\paragraph{}
|
||||
Then, we focus on the streaming aspect of the system.
|
||||
The objective of this contribution is to introduce a system able to perform \textbf{scalable, view-dependent 3D streaming}.
|
||||
This new framework proposes many improvements upon the basic system described in our first contribution: support for texture, moving computation from the server to the clients, support for multi-resolution textures, rendering performances considerations.
|
||||
We took massive inspiration from the DASH technology, a standard for video streaming thanks to its scalability and its adaptability.
|
||||
After studying the interactive aspect of 3D navigation, we proposed a contribution focusing on the streaming aspect of such a system.
|
||||
The objective of this contribution wass to introduce a system able to perform \textbf{scalable, view-dependent 3D streaming}.
|
||||
This new framework brings many improvements upon the basic system described in our first contribution: support for texture, externaliration of necessary computations from the server to the clients, support for multi-resolution textures, rendering performances considerations.
|
||||
We drew massive inspiration from the DASH technology, a standard for video streaming used for its scalability and its adaptability.
|
||||
We exploit the fact that DASH is made to be content agnostic to fit 3D content into its structure.
|
||||
We used DASH-SRD extension to partition our 3D content tree and profit from this partition to perform view-dependant streaming, without having any computation to run on the server side.
|
||||
For the clients, we implement loading policies based on a utility metric that gives a score for both geometry and texture portion of the model.
|
||||
We throughly tested our solutions for different values of parameters, as well as for our different loading policies by running simulations, to propose an efficient framework that we name DASH-3D.
|
||||
Following the path set by DASH-SRD, we propose to tile 3D content using a tree and encode this partition into a description file (MPD) to allow view-dependent streaming, without the need for computation on the server side.
|
||||
On the client side, we implement loading policies that optimize a utility metric estimating how much geometry and texture segments contribute to the visual rendering of the scene at a particular viewpoint.
|
||||
We thoroughly tested our solutions by running simulations with different parameter values, as well as different loading policies, to propose an efficient framework that we name DASH-3D.
|
||||
This work has been published as a full paper at the conference ACMMM in 2018~\citep{dash-3d}.
|
||||
A demo paper on the DASH-3D implementation was also published~\citep{dash-3d-demo}.
|
||||
A demonstration paper on the DASH-3D implementation was also published~\citep{dash-3d-demo}.
|
||||
|
||||
\paragraph{}
|
||||
Finally, we brought back the \textbf{3D navigation bookmark within DASH-3D}.
|
||||
Finally, we brought back the \textbf{3D navigation bookmark within our DASH-3D framework}.
|
||||
We developed interfaces that allow navigating in 3D scenes for both \textbf{desktop and mobile devices} and we reintroduced bookmarks in these interfaces.
|
||||
The setup of our first contribution considered only geometry, triangle by triangle, which made precomputations and ordering straightforward.
|
||||
Moreover, the server knows exactly the client needs, and thus create chunks adapted to the client's requirements.
|
||||
Moreover, as the server knew exactly the client needs, it could create chunks adapted to the client's requirements.
|
||||
In DASH-3D, the data is structured a priori (offline), so that chunks are grouped independently of a client's need.
|
||||
However, this does not mean that all hope is lost: we are still able to precompute an optimal order for chunks from each bookmark, and, using the policies from our first contribution, switch to this optimal order when a user clicks a bookmark.
|
||||
We therefore focus on precomputing an optimal order for chunks from each bookmark, and, alter the streaming policies from our second contribution to switch to this optimal order when a user clicks a bookmark.
|
||||
Simulations show that the QoS is positively impacted by those policies.
|
||||
A demo paper was published at the conference ACMMM in 2019~\citep{dash-3d-bookmarks-demo} showing the interfaces for desktop and mobile clients with bookmarks, but without the streaming aspect.
|
||||
A demo paper was published at the conference ACMMM in 2019~\citep{dash-3d-bookmarks-demo} showing the interfaces for desktop and mobile clients with bookmarks, but without the streaming aspect. A journal paper will be submitted shortly to value this third contribution.
|
||||
|
|
12
src/plan.tex
12
src/plan.tex
|
@ -1,23 +1,23 @@
|
|||
\frontmatter{}
|
||||
|
||||
\input{introduction/main}
|
||||
%\input{introduction/main}
|
||||
\resetstyle{}
|
||||
|
||||
\mainmatter{}
|
||||
|
||||
\input{foreword/main}
|
||||
%\input{foreword/main}
|
||||
\resetstyle{}
|
||||
|
||||
\input{state-of-the-art/main}
|
||||
%\input{state-of-the-art/main}
|
||||
\resetstyle{}
|
||||
|
||||
\input{preliminary-work/main}
|
||||
%\input{preliminary-work/main}
|
||||
\resetstyle{}
|
||||
|
||||
\input{dash-3d/main}
|
||||
%\input{dash-3d/main}
|
||||
\resetstyle{}
|
||||
|
||||
\input{system-bookmarks/main}
|
||||
%\input{system-bookmarks/main}
|
||||
\resetstyle{}
|
||||
|
||||
\backmatter{}
|
||||
|
|
Loading…
Reference in New Issue