Stuff
This commit is contained in:
parent
df630c630b
commit
d4f2672470
17
src/bib.bib
17
src/bib.bib
|
@ -96,3 +96,20 @@
|
|||
year={2008},
|
||||
organization={ACM}
|
||||
}
|
||||
|
||||
|
||||
@article{gltf,
|
||||
title={Gltf---The Runtime Asset Format for WebGL},
|
||||
author={Robinet, Fabrice and Cozzi, P},
|
||||
journal={OpenGL ES, and OpenGL},
|
||||
year={2013}
|
||||
}
|
||||
|
||||
@inproceedings{progressive-meshes,
|
||||
title={Progressive meshes},
|
||||
author={Hoppe, Hugues},
|
||||
booktitle={Proceedings of the 23rd annual conference on Computer graphics and interactive techniques},
|
||||
pages={99--108},
|
||||
year={1996},
|
||||
organization={ACM}
|
||||
}
|
||||
|
|
|
@ -0,0 +1,81 @@
|
|||
\newpage
|
||||
|
||||
\section{3D Streaming}
|
||||
|
||||
\subsection{Progressive meshes}
|
||||
|
||||
It is not possible to speak about 3D streaming without speaking about progressive meshes.
|
||||
Progressive meshes were introduced by Hughes Hoppe in 1996~\cite{progressive-meshes} and allow transmitting a mesh by send first a low resolution mesh, 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}).
|
||||
Each time two vertices are merged, vertices and faces are removed from the original mesh, and the resolution of the model decreases a little.
|
||||
When the model is light enough, it is encoded as is, and the operations needed to recover the initial resolution of the model are encoded as well.
|
||||
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.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\begin{tikzpicture}[scale=2]
|
||||
\node (Top1) at (0.5, 1) {};
|
||||
\node (A) at (0, 0.8) {};
|
||||
\node (B) at (1, 0.9) {};
|
||||
\node (C) at (1.2, 0) {};
|
||||
\node (D) at (0.9, -0.8) {};
|
||||
\node (E) at (0.2, -0.9) {};
|
||||
\node (F) at (-0.2, 0) {};
|
||||
\node (G) at (0.5, 0.5) {};
|
||||
\node (H) at (0.6, -0.5) {};
|
||||
\node (Bottom1) at (0.5, -1) {};
|
||||
|
||||
\node (Top2) at (3.5, 1) {};
|
||||
\node (A2) at (3, 0.8) {};
|
||||
\node (B2) at (4, 0.9) {};
|
||||
\node (C2) at (4.2, 0) {};
|
||||
\node (D2) at (3.9, -0.8) {};
|
||||
\node (E2) at (3.2, -0.9) {};
|
||||
\node (F2) at (2.8, 0) {};
|
||||
\node (G2) at (3.55, 0) {};
|
||||
\node (Bottom2) at (3.5, -1) {};
|
||||
|
||||
\draw (A.center) -- (B.center) -- (C.center) -- (D.center) -- (E.center) -- (F.center) -- (A.center);
|
||||
\draw (A.center) -- (G.center);
|
||||
\draw (B.center) -- (G.center);
|
||||
\draw (C.center) -- (G.center);
|
||||
\draw (F.center) -- (G.center);
|
||||
\draw (C.center) -- (H.center);
|
||||
\draw (F.center) -- (H.center);
|
||||
\draw (E.center) -- (H.center);
|
||||
\draw (D.center) -- (H.center);
|
||||
\draw[color=red, line width=1mm] (G.center) -- (H.center);
|
||||
|
||||
\draw (A2.center) -- (B2.center) -- (C2.center) -- (D2.center) -- (E2.center) -- (F2.center) -- (A2.center);
|
||||
\draw (A2.center) -- (G2.center);
|
||||
\draw (B2.center) -- (G2.center);
|
||||
\draw (C2.center) -- (G2.center);
|
||||
\draw (F2.center) -- (G2.center);
|
||||
\draw (E2.center) -- (G2.center);
|
||||
\draw (D2.center) -- (G2.center);
|
||||
\node at (G2) [circle,fill=red,inner sep=2pt]{};
|
||||
|
||||
\draw[-{Latex[length=3mm]}] (Top1) to [out=30, in=150] (Top2);
|
||||
\draw[-{Latex[length=3mm]}] (Bottom2) to [out=-150, in=-30] (Bottom1);
|
||||
|
||||
\node at (2, 1.75) {Edge collapse};
|
||||
\node at (2, -1.75) {Vertex split};
|
||||
|
||||
|
||||
\end{tikzpicture}
|
||||
\caption{Vertex split and edge collapse\label{sote:progressive-scheme}}
|
||||
\end{figure}
|
||||
|
||||
\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
|
||||
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.
|
||||
|
||||
However, glTF in itself does not address the problem of view-dependent 3D 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\@.
|
|
@ -2,3 +2,6 @@
|
|||
|
||||
\input{state-of-the-art/video}
|
||||
\resetstyle{}
|
||||
|
||||
\input{state-of-the-art/3d}
|
||||
\resetstyle{}
|
||||
|
|
Loading…
Reference in New Issue