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

Some stuff

This commit is contained in:
Thomas Forgione 2019-10-10 16:03:18 +02:00
parent fb4091d3d9
commit 5a38450ff0
No known key found for this signature in database
GPG Key ID: 203DAEA747F48F41
4 changed files with 60 additions and 44 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
src/bib.bib
View File

@ -524,3 +524,20 @@
year={2011},
}
@inproceedings{3d-tiles,
author = {Schilling, Arne and Bolling, Jannes and Nagel, Claus},
title = {Using glTF for Streaming CityGML 3D City Models},
booktitle = {Proceedings of the 21st International Conference on Web3D Technology},
series = {Web3D '16},
year = {2016},
isbn = {978-1-4503-4428-9},
location = {Anaheim, California},
pages = {109--116},
numpages = {8},
url = {http://doi.acm.org/10.1145/2945292.2945312},
doi = {10.1145/2945292.2945312},
acmid = {2945312},
publisher = {ACM},
address = {New York, NY, USA},
keywords = {3D city models, CityGML, WebGL, browser integration, geographic information system, web streaming},
}

25
src/state-of-the-art/3d-interaction.tex
View File

@ -3,32 +3,33 @@
\section{3D Bookmarks and Navigation Aids}
Devising an ergonomic technique for browsing 3D environments through a 2D interface is difficult.
Controlling the viewpoint in 3D (6 DOFs) with 2D devices is not only inherently challenging but also strongly task-dependent. In their recent review~\cite{interaction-3d-environment}, Jankowski and Hachet distinguish between several types of camera movements: general movements for exploration (e.g., navigation with no explicit target), targeted movements (e.g., searching and/or examining a model in detail), specified trajectory (e.g., a cinematographic camera path), etc.
Controlling the viewpoint in 3D (6 DOFs) with 2D devices is not only inherently challenging but also strongly task-dependent. In their recent review,~\cite{interaction-3d-environment} distinguish between several types of camera movements: general movements for exploration (e.g., navigation with no explicit target), targeted movements (e.g., searching and/or examining a model in detail), specified trajectory (e.g., a cinematographic camera path), etc.
For each type of movement, specialized 3D interaction techniques can be designed.
In most cases, rotating, panning, and zooming movements are required, and users are consequently forced to switch back and forth among several navigation modes, leading to interactions that are too complicated overall for a layperson.
Navigation aids and smart widgets are required and subject to research efforts both in 3D companies (see \url{sketchfab.com}, \url{cl3ver.com} among others) and in academia, as reported below.
Translating and rotating the camera can be simply specified by a \textit{lookat} point. This is often known as point-of-interest movement (or \textit{go-to}, \textit{fly-to} interactions)~\cite{controlled-movement-virtual-3d}.
Translating and rotating the camera can be simply specified by a \textit{lookat} point.
This is often known as point-of-interest movement (or \textit{go-to}, \textit{fly-to} interactions)~\cite{controlled-movement-virtual-3d}.
Given such a point, the camera automatically animates from its current position to a new position that looks at the specified point.
One key issue of these techniques is to correctly orient the camera at destination.
In Unicam~\cite{two-pointer-input}, the so-called click-to-focus strategy automatically chooses the destination viewpoint depending on 3D orientations around the contact point.
The recent Drag'n Go interaction~\cite{drag-n-go} also hits a destination point while offering control on speed and position along the camera path.
In Unicam (\cite{two-pointer-input}), the so-called click-to-focus strategy automatically chooses the destination viewpoint depending on 3D orientations around the contact point.
The recent Drag'n Go interaction (\cite{drag-n-go}) also hits a destination point while offering control on speed and position along the camera path.
This 3D interaction is designed in the screen space (it is typically a mouse-based camera control), where cursor's movements are mapped to camera movements following the same direction as the on-screen optical-flow.
Some 3D browsers provide a viewpoint menu offering a choice of viewpoints~\cite{visual-perception-3d},~\cite{showmotion}.
Some 3D browsers provide a viewpoint menu offering a choice of viewpoints (\cite{visual-perception-3d},~\cite{showmotion}).
Authors of 3D scenes can place several viewpoints (typically for each POI) in order to allow easy navigation for users, who can then easily navigate from viewpoint to viewpoint just by selecting a menu item.
Such viewpoints can be either static, or dynamically adapted: the authors from~\cite{dual-mode-ui} report that users clearly prefer navigating in 3D using a menu with animated viewpoints than with static ones.
Such viewpoints can be either static, or dynamically adapted:~\cite{dual-mode-ui} report that users clearly prefer navigating in 3D using a menu with animated viewpoints than with static ones.
Early 3D VRML environments~\cite{browsing-3d-bookmarks} offer 3D bookmarks with animated transitions between bookmarked views.
Early 3D VRML environments (\cite{browsing-3d-bookmarks}) offer 3D bookmarks with animated transitions between bookmarked views.
These transitions prevent disorientation since users see how they got there.
Hyperlinks can also ease rapid movements between distant viewpoints and naturally support non-linear and non-continuous access to 3D content.
Navigating with 3D hyperlinks is potentially faster, but is likely to cause disorientation, as shown by the work of Ruddle et al.~\cite{ve-hyperlinks}.
Eno et al.~\cite{linking-behavior-ve} examine explicit landmark links as well as implicit avatar-chosen links in Second Life.
Navigating with 3D hyperlinks is potentially faster, but is likely to cause disorientation, as shown by the work of~\cite{ve-hyperlinks}.
\cite{linking-behavior-ve} examine explicit landmark links as well as implicit avatar-chosen links in Second Life.
These authors point out that linking is appreciated by users and that easing linking would likely result in a richer user experience.
In~\cite{dual-mode-ui}, the Dual-Mode User Interface (DMUI) coordinates and links hypertext to 3D graphics in order to access information in a 3D space.
\cite{dual-mode-ui} developed the Dual-Mode User Interface (DMUI) that coordinates and links hypertext to 3D graphics in order to access information in a 3D space.
Our results are consistent with the results on 3D hyperlinks, as we showed that in our NVE 3D bookmarks also improve users performance.
The use of in-scene 3D navigation widgets can also facilitate 3D navigation tasks.
Chittaro and Venkataraman~\cite{navigation-aid-multi-floor} propose and evaluate 2D and 3D maps as navigation aids for complex virtual buildings and find that the 2D navigation aid outperforms the 3D one for searching tasks.
The ViewCube widget~\cite{viewcube} serves as a proxy for the 3D scene and offers viewpoint switching between 26 views while clearly indicating associated 3D orientations.
\cite{navigation-aid-multi-floor} propose and evaluate 2D and 3D maps as navigation aids for complex virtual buildings and find that the 2D navigation aid outperforms the 3D one for searching tasks.
The ViewCube widget (\cite{viewcube}) serves as a proxy for the 3D scene and offers viewpoint switching between 26 views while clearly indicating associated 3D orientations.
Interactive 3D arrows that point to objects of interest have also been proposed as navigation aids by Chittaro and Burigat~\cite{location-pointing-navigation-aid,location-pointing-effect}: when clicked, the arrows transfer the viewpoint to the destination through a simulated walk or a faster flight.

31
src/state-of-the-art/3d-streaming.tex
View File

@ -1,10 +1,9 @@
\fresh{}
\section{3D Streaming}
\subsection{Progressive meshes}
\subsection{Compression and structuring}
It is not possible to speak about 3D streaming without speaking about progressive meshes.
Progressive meshes were introduced by~\citet{progressive-meshes} and allow transmitting a mesh by sending a low resolution mesh first, called \emph{base mesh}, and then transmitting detail information that a client can use to increase the resolution.
The most popular compression model for 3D is progressive meshes: they were introduced by~\citet{progressive-meshes} and allow transmitting a mesh by sending a low resolution mesh first, called \emph{base mesh}, and then transmitting detail information that a client can use to increase the resolution.
To do so, an algorithm, called \emph{decimation algorithm} removes vertices and faces by merging vertices (Figure~\ref{sote:progressive-scheme}).
\begin{figure}[ht]
@ -67,17 +66,14 @@ When the model is light enough, it is encoded as is, and the operations needed t
Thus, a client can start by downloading the low resolution model, display it to the user, and keep downloading and displaying details as time goes by.
This process reduces the time a user has to wait before seeing something, and increases the quality of experience.
\subsection{glTF}
In a recent standardization effort, the Khronos group has proposed a generic format called glTF (GL Transmission Format~\cite{gltf}) to handle all types of 3D content representations: point clouds, meshes, animated model, etc\ldots
More recently, to answer the need for a standard format for 3D data, the Khronos group has proposed a generic format called glTF (GL Transmission Format,~\cite{gltf}) to handle all types of 3D content representations: point clouds, meshes, animated model, etc\ldots
glTF is based on a JSON file, which encodes the structure of a scene of 3D objects.
It can contain a scene tree with cameras, meshes, buffers, materials, textures, animations an skinning information.
Although relevant for compression, transmission and in particular streaming, this standard does not yet consider view-dependent streaming which is required for large scene remote visualisation.
\subsection{3D Tiles}
3D Tiles is a specification for visualizing massive 3D geospatial data developped by Cesium and built on glTF\@.
\todo{add stuff here}
3D Tiles (\cite{3d-tiles}) is a specification for visualizing massive 3D geospatial data developed by Cesium and built on glTF\@.
Their main goal is to display 3D objects on top of regular maps, and the data they use is quite different from ours: while they have nice and regular polygons with all the semantic they need, we only work on a polygon soup with textures.
Their use case is also different from ours, while their interface allows a user to have a top vision of a city, we want our users to move inside a city.
\copied{}
\subsection{Prefetching in NVE}
@ -90,18 +86,19 @@ Once the set of objects that are likely to be accessed by the user is determined
A simple approach is to retrieve the objects based on distance: the spatial distance from the user's virtual location and rotational distance from the user's view.
Other approaches consider the movement of the user and attempt to predict where the user will move to in the future.
Chan et al.~\cite{motion-prediction} and Li et al.~\cite{walkthrough-ve} predict the direction of movement from the user's mouse input pattern.
\cite{motion-prediction} and~\cite{walkthrough-ve} predict the direction of movement from the user's mouse input pattern.
The predicted mouse movement direction is then mapped to the navigation path in the NVE\@.
Objects that fall in the predicted path are then prefetched.
CyberWalk~\cite{cyberwalk} uses an exponentially weighted moving average of past movement vectors, adjusted with the residual of prediction, to predict the next location of the user.
Hung et al.~\cite{prefetching-walkthrough-latency} cluster the navigation paths of users and use them to predict the future navigation paths.
Objects that fall within the predicted navigation path are prefetched. All these approaches work well for a navigation path that is continuous --- once the user clicks on a bookmark and jumps to a new location, the path is no longer continuous and the prediction becomes wrong.
\cite{prefetching-walkthrough-latency} cluster the navigation paths of users and use them to predict the future navigation paths.
Objects that fall within the predicted navigation path are prefetched.
All these approaches work well for a navigation path that is continuous --- once the user clicks on a bookmark and jumps to a new location, the path is no longer continuous and the prediction becomes wrong.
Moving beyond ordering objects to prefetch based on distance only, Park et al.~\cite{caching-prefetching-dve} propose to predict the user's interest in an object as well.
Moving beyond ordering objects to prefetch based on distance only,~\cite{caching-prefetching-dve} propose to predict the user's interest in an object as well.
Objects within AoI are then retrieved in decreasing order of predicted interest value to the user.
In~\cite{learning-user-access-patterns} investigates how to render large-scale 3-D scenes on a thin client.
\cite{learning-user-access-patterns} investigates how to render large-scale 3-D scenes on a thin client.
Efficient scene prefetching to provide timely data with a limited cache is one of the most critical issues for remote 3-D data scheduling in networked virtual environment applications.
Existing prefetching schemes predict the future positions of each individual user based on user traces.
In this paper, we investigate scene content sequences accessed by various users instead of user viewpoint traces and propose a user access pattern-based 3-D scene prefetching scheme.
@ -109,7 +106,7 @@ We make a relationship graph-based clustering to partition history user access s
Then, these user access patterns are prioritized by their popularity and users' personal preference.
Based on these access patterns, the proposed prefetching scheme predicts the scene contents that will most likely be visited in the future and delivers them to the client in advance.
In~\cite{remote-rendering-streaming} Lazem et al.\ investigate remote image-based rendering (IBR) as the most suitable solution for rendering complex 3D scenes on mobile devices, where the server renders the 3D scene and streams the rendered images to the client.
\cite{remote-rendering-streaming} investigate remote image-based rendering (IBR) as the most suitable solution for rendering complex 3D scenes on mobile devices, where the server renders the 3D scene and streams the rendered images to the client.
However, sending a large number of images is inefficient due to the possible limitations of wireless connections.
They propose a prefetching scheme at the server side that predicts client movements and hence prefetches the corresponding images.
@ -117,7 +114,7 @@ Prefetching techniques easing 3D data streaming and real-time rendering for remo
Culling methods, that don't possess frame to frame coherence, can successfully be combined with remote scene databases, if the prefetching algorithm is adapted accordingly.
We present a quantitative transmission policy, that takes the limited bandwidth of the network and the limited memory available at the client computer into account.
Also in the context remote visualization, Sisneros et al.~\cite{cache-remote-visualization} study caching and prefetching and optimize configurations of remote visualization architectures.
Also in the context remote visualization,~\cite{cache-remote-visualization} study caching and prefetching and optimize configurations of remote visualization architectures.
They aim at minimizing the fetch time in a remote visualization system and defend a practical infrastructure software to adaptively optimize the caching architecture of such systems under varying conditions (e.g.\ when network ressources vary).

29
src/state-of-the-art/video.tex
View File

@ -12,38 +12,39 @@ DASH is based on a clever way of structuring the content that allows a great ada
\subsubsection{DASH structure}
All the content structure is described in a Media Persentation Description (MPD) file, written in the XML format.
All the content structure is described in a Media Presentation Description (MPD) file, written in the XML format.
This file has 4 layers: the periods, the adaptation sets, the representations and the segments.
A MPD behaves like a tree-structure, meaning that each period can have many adaptation sets, each adaptation set can have many representation, and each representation can have many segments.
A MPD has a tree-structure, meaning that it has many periods, each period can have many adaptation sets, each adaptation set can have many representation, and each representation can have many segments.
\paragraph{Periods.}
Periods are used to delimit content depending on the time.
Periods are used to delimit content depending on time.
It can be used to delimit chapters, or to add advertisements that occur at the beginning, during or at the end of a video.
\paragraph{Adaptation sets.}
Adaptation sets are used to delimit content depending of the format.
Adaptation sets are used to delimit content depending on format.
Each adaptation set has a mime-type, and all the representations and segments that it contains share this mime-type.
In videos, most of the time, each period has at least one adaptation set containing the images, and one adaptation set containing the sound.
It may also have an adaptation set for subtitles.
\paragraph{Representations.}
The representation level is the level DASH uses to offer the same content at different levels of resolution.
For example, a adaptation set containing images have a representation for each available resolution (it might be 480p, 720p, 1080p, etc\ldots).
For example, an adaptation set containing images has a representation for each available resolution (it might be 480p, 720p, 1080p, etc\ldots).
This allows a user to choose its representation and change it during the video, but most importantly, since the software is able to estimate its downloading speed based on the time it took to download data in the past, it is able to find the optimal resolution, being the highest resolution that the client can request without stalling.
\paragraph{Segments.}
Until this level in the MPD, content has been divided but it is still far from being sufficiently divided to be streamed efficiently.
In fact, a representation of the images of a chapter of a movie is still a long video, and keeping such a big file is not possible since downloading heavy files is not suitable for streaming.
In fact, heavy files prevent the dynamicity of streaming: if the user requests to change the level of resolution of a video, the system would either have to wait until the file is totally downloaded, or cancel the request, making all the progress done unusable.
In fact, a representation of the images of a chapter of a movie is still a long video, and keeping such a big file is not possible since heavy files prevent the dynamic of streaming: if the user requests to change the level of resolution of a video, the system would either have to wait until the file is totally downloaded, or cancel the request, making all the progress done unusable.
Segments are used to prevent this behaviour.
They typically encode files that last approximately one second of video, and give the software a great ability to dynamically adapt to the system.
Segments are used to prevent this issue.
They typically encode files that contain approximately one second of video, and give the software a great ability to dynamically adapt to the system.
If a user wants to seek somewhere else in the video, only one second of data can be lost, and only one second of data has to be downloaded for the playback to resume.
\subsubsection{Client side computation}
Once a video is encoded in DASH format, all the files have been structured and the MPD has been generated, all this data can simply be put on a static HTTP server that does no computation other than serving files when it receives requests.
Once a video is encoded in DASH format, all the files have been structured and the MPD has been generated, all this data can simply be hosted on a static HTTP server that does no computation other than serving files when it receives requests.
All the intelligence and the decision making is moved to the client side.
A client typically starts by downloading the MPD file, and then proceeds on downloading segments of the different adaptation sets that he needs, estimating itself its downloading speed and choosing itself whether it needs to change representation or not.
This is one of the strengths of DASH\@: no powerful server is required, and since static HTTP server are studied since the beginning of the internet, they are optimized well and all DASH clients can benefit from it.
\subsection{DASH-SRD}
@ -57,7 +58,7 @@ That way, a client can choose to download either the low resolution of the whole
\caption{DASH-SRD~\cite{dash-srd}\label{sota:srd-png}}
\end{figure}
For each tile of the video, an adaptation set is declared in the MPD, and a supplemental property is defined in order to give the client information about the file.
For each tile of the video, an adaptation set is declared in the MPD, and a supplemental property is defined in order to give the client information about the tile.
This supplemental property contains many elements, but the most important ones are the position ($x$ and $y$) and the size (width and height) of the tile describing the position of the tile in relation to the full video.
An example of such a property is given in Listing~\ref{sota:srd-xml}.
@ -91,7 +92,7 @@ This is especially interesting in the context of 3D streaming since we have this
We briefly survey other research on prefetching that focuses on non-continuous interaction in other types of media.
In the context of navigating in a video, a recent work by carlier et al.~\cite{video-bookmarks} prefetches video chunks located after bookmarks along the video timeline.
In the context of navigating in a video, a recent work by~\cite{video-bookmarks} prefetches video chunks located after bookmarks along the video timeline.
Their work, however, focuses on changing the user behavior to improve the prefetching hit rate, by depicting the state of the prefetched buffer to the user.
Carlier et al.\ also consider prefetching in the context of zoomable videos in an earlier work~\cite{zoomable-video}, and showed that predicting which region of videos the user will zoom into or pan to by analyzing interaction traces from users is difficult.
@ -99,10 +100,10 @@ Prefetching for navigation through a sequence of short online videos is consider
Each switch from the current video to the next can be treated as a non-continuous interaction.
The authors proposed recommendation-aware prefetching --- to prefetch the prefix of videos from the search result list and related video list, as these videos are likely to be of interest to the user and other users from the same community.
Grigoras et al.~\cite{video-navigation-mpd} consider the problem of prefetching in the context of a hypervideo; non-continuous interaction happens when users click on a hyperlink in the video.
\cite{video-navigation-mpd} consider the problem of prefetching in the context of a hypervideo; non-continuous interaction happens when users click on a hyperlink in the video.
They propose a formal framework that captures the click probability, the bandwidth, and the bit rate of videos as a markov decision problem, and derive an optimal prefetching policy.
Zhao and Ooi~\cite{joserlin} propose joserlin, a generic framework for prefetching that applies to any non-continuous media, but focuses on peer-to-peer streaming applications.
\cite{joserlin} propose Joserlin, a generic framework for prefetching that applies to any non-continuous media, but focuses on peer-to-peer streaming applications.
They do not predict which item to prefetch, but rather focus on how to schedule the prefetch request and response.
There is a huge body of work on prefetching web objects in the context of the world wide web. Interested readers can refer to numerous surveys written on this topic (e.g.,~\cite{survey-caching-prefetching}).