45 lines
5.9 KiB
TeX
45 lines
5.9 KiB
TeX
\copied{}
|
|
\section{Introduction}
|
|
|
|
% With the progress in data acquisition and modeling techniques, networked virtual environments, or NVE, are increasing in scale.
|
|
% For instance, Gaillard et al.~\cite{urban-data-visualisation} reported that the 3D scene for the city of Lyon takes more than 30 GB of data.
|
|
% It has become impractical to download the whole 3D scene before the user begins to navigate in the scene.
|
|
% A more common approach is to stream the required 3D content (models and textures) on demand, as the user moves around the scene.
|
|
% Downloading the required 3D content the moment the user demands it, however, leads to ``popping effect'' where 3D objects materialize suddenly in the view of the user, due to the latency between requesting for and receiving the 3D content from the server~\cite{visibility-determination}.
|
|
% Such latency can be quite high --- Varvello et al.\ reported a median of about 30 seconds for all 3D data in an avatar's surrounding to be loaded in high density Second Life regions under their experimental network conditions, due to a bottleneck at the server~\cite{second-life}.
|
|
%
|
|
% For a smoother user experience, NVE typically prefetch 3D content, so that a 3D object is readily available for rendering when the object falls into the view of the user.
|
|
% Efficient prefetching, however, requires the client or the server to predict where the user would navigate to in the future and retrieve the corresponding 3D content before the user reaches there.
|
|
% In a typical scenario, users navigate along a continuous path in a NVE, leading to a significant overlap between the 3D content visible from the user's known current position and possible next positions (i.e., \textit{spatial data locality}).
|
|
% Furthermore, there is a significant overlap between the 3D content visible from the current point in time to the next point in time (i.e., \textit{temporal data locality}).
|
|
% Both forms of locality lead to content overlaps, thus making a correct prediction easier and a wrong prediction less costly. 3D content overlaps are particularly common in a NVE with open space, such as a 3D archaeological site or a 3D city.
|
|
|
|
Navigating in NVE with a large virtual space (most times through a 2D interface) is sometimes cumbersome.
|
|
In particular, a user may have difficulties reaching the right place to find information.
|
|
The content provider of the NVE may want to highlight certain interesting features for the users to view and experience, such as a vantage point in a city, an excavation at an archaeological site, or an exhibit in a museum.
|
|
To allow users to easily find these interesting locations within the NVE, \textit{3D bookmarks} or \textit{bookmarks} for short, can be provided.
|
|
A bookmark is simply a 3D virtual camera (with position and camera parameters) predefined by the content provider, and can be presented to users in different ways, including as a text link (URL), a thumbnail image, or a 3D object embedded within the NVE itself.
|
|
|
|
When users click on a bookmark, NVEs commonly provide a ``fly-to'' animation to transit the camera from the current viewpoint to the destination~\cite{controlled-movement-virtual-3d,browsing-3d-bookmarks} to help orient the users within the 3D space.
|
|
Clicking on a bookmark to fly to another viewpoint leads to reduced data locality.
|
|
The 3D content at the bookmarked destination viewpoint may overlap less with the current viewpoint.
|
|
In the worst case, the 3D objects corresponding to the current and destination viewpoints can be completely disjoint.
|
|
Such movement to a bookmark may lead to a \textit{discovery latency}~\cite{second-life}, in which users have to wait for the 3D content for the new viewpoint to be loaded and displayed.
|
|
An analogy for this situation, in the context of video streaming, is seeking into a segment of video that has not been prefetched yet.
|
|
|
|
In this chapter, we explore the impact of bookmarks on NVE navigation and streaming, and make several contributions.
|
|
First, we conducted a crowdsourcing experiment where 51 participants navigated in 3 virtual scenes to complete a task.
|
|
This experiment serves two purposes: (i) it validates our intuition that bookmarks significantly reduce the number of interactions and navigation time (in average the time needed to complete the task
|
|
for users with bookmarks is half the time for users without bookmarks); (ii) it produces a set of user interaction traces that we use for subsequent simulation experiments.
|
|
Second, we quantified the effect of bookmarking on prefetching and visual quality in our experiments.
|
|
We showed that, without prefetching, the number of correctly rendered pixels right after clicking on bookmarks can drop up to 10\% on average.
|
|
If we prefetch the 3D content from the bookmarks according to the probability of access, we do not limit this drop by more than 5\%.
|
|
Finally, we proposed a method to improve the visual quality after clicking on bookmarks, by exploiting the fact that the visible faces at the bookmark can be precomputed, and by fetching the visible faces only after a bookmark is clicked.
|
|
We showed that, if the fetching is done during the 1 or 2 seconds of the ``fly-to'' camera movement from the current viewpoint to the bookmarked viewpoint, it suffices to increase the number of correctly rendered pixels to more than 20\%, without wasting bandwidth on prefetching.
|
|
Our key message is that, \textit{in addition to easing navigation, bookmarking allows precomputation of visible faces and can significantly reduce interaction latency, without resorting to prefetching}, which may waste bandwidth by prefetching 3D data that will not be needed.
|
|
|
|
The rest of the chapter consists of the following sections.
|
|
Section~\ref{bi:3dnavigation} describes the 3D bookmarks that we use in our work, along with our experiments to validate the usefulness of bookmarking.
|
|
Section~\ref{bi:system} describes the streaming and prefetching mechanisms that we used to simulate our experiments as well as our main findings.
|
|
Finally, we conclude in Section~\ref{bi:conclusion}.
|