Work

src/dash-3d/client.tex

@@ -131,5 +131,68 @@ s^{\texttt{GREEDY}}_i= \argmax{s \in \mathcal{S} \backslash \mathcal{B}_i \cap \
 \label{d3:greedy}
 \end{equation}
 
+\fresh{}
+\subsection{Performance}
 
+Another important aspect of our client is performance.
+To sum up the bottlenecks of performance described in Section~\ref{i:rendering}, we need to keep the least amount of objects possible, to do the least amount of \texttt{glDrawArray}, but we want to have separated objects so that frustum culling is efficient.
+In our NVE, there are more than a thousand materials and they are reused all over the scene.
+Creating local objects to benefit from frustum culling is not an option in our case, so we merge all faces that share material and draw them in a single \texttt{glDrawArray} call.
 
+In order to do so, the content that was previously structured in a way to optimize streaming is restructured live on the client to optimize rendering, as show in Figure~\ref{d3:render-structure}.
+That way, when geometry is downloaded for a new material, we know how much space we should allocate for the buffers, and when geometry is downloaded for a material already allocated, we just edit the buffer and transmit it to the GPU\@.
+
+\begin{figure}[ht]
+    \centering
+
+    \begin{tikzpicture}
+
+        \node[align=center] at(1.5, -1) {DASH-3D\\Structure};
+
+        \node at(-1.5, -3) {\texttt{seg0.obj}};
+        \draw[fill=LightCoral] (0, -2) rectangle (3, -3);
+        \node at(1.5, -2.5) {Material 1};
+        \draw[fill=LightGreen] (0, -3) rectangle (3, -4);
+        \node at(1.5, -3.5) {Material 2};
+
+        \node at(-1.5, -6) {\texttt{seg1.obj}};
+        \draw[fill=LightCoral] (0, -5) rectangle (3, -7);
+        \node at(1.5, -6) {Material 1};
+
+        \node at(-1.5, -9) {\texttt{seg2.obj}};
+        \draw[fill=LightGreen] (0, -8) rectangle (3, -9);
+        \node at(1.5, -8.5) {Material 2};
+        \draw[fill=Lavender] (0, -9) rectangle (3, -10);
+        \node at(1.5, -9.5) {Material 3};
+
+        \node[align=center] at (7.5, -1) {Renderer\\Structure};
+
+        \node at(10.5, -3.5) {Object 1};
+        \draw[fill=LightCoral] (6, -2) rectangle (9, -5);
+        \node at(7.5, -3.5) {Material 1};
+
+        \node at(10.5, -7) {Object 2};
+        \draw[fill=LightGreen] (6, -6) rectangle (9, -8);
+        \node at(7.5, -7) {Material 2};
+
+        \node at(10.5, -9.5) {Object 3};
+        \draw[fill=Lavender] (6, -9) rectangle (9, -10);
+        \node at(7.5, -9.5) {Material 3};
+
+        \node[minimum width=3cm,minimum height=2cm] (O1) at (7.5, -3.5) {};
+        \draw[-{Latex[length=3mm]}, color=FireBrick] (3, -2.5) -- (O1);
+        \draw[-{Latex[length=3mm]}, color=FireBrick] (3, -6) -- (O1);
+
+        \node[minimum width=3cm,minimum height=2cm] (O2) at (7.5, -7) {};
+        \draw[-{Latex[length=3mm]}, color=DarkGreen] (3, -3.5) -- (O2);
+        \draw[-{Latex[length=3mm]}, color=DarkGreen] (3, -8.5) -- (O2);
+
+        \node[minimum width=3cm,minimum height=2cm] (O3) at (7.5, -9.5) {};
+        \draw[-{Latex[length=3mm]}, color=RoyalBlue] (3, -9.5) -- (O3);
+
+        \node at (1.5, -10.75) {$\vdots$};
+        \node at (7.5, -10.75) {$\vdots$};
+    \end{tikzpicture}
+
+    \caption{Restructuration of the content on the renderer\label{d3:render-structure}}
+\end{figure}

src/dash-3d/conclusion.tex

@@ -12,7 +12,7 @@ Exploiting DASH's concepts to design 3D streaming systems allow us to tackle som
     \item \textbf{It has built-in support for materials and textures}: we use a DASH adaptation set for the materials, and the average color of textures are given in the MPD, meaning that a client is not forced to render everything in white while not having the texture for the materials.
     \item \textbf{It doesn't require any computation on the server side}: the only computation required is preprocessing the model and creating metadata to allow a client make smart decisions, once those precomputations are done, the artifacts can be deployed to a static server like Apache or nginx and all the computation lod is deported to the client, making this solution scalable.
     \item \textbf{It has support for multi-resolution}: in our implementation, we use multi-resolution textures, and even though multi-resolution geometry is not implemented yet, the challenge here lies more on the compression side than on the streaming side. Once a portion of geometry is encoded into different levels of details, we just have to create representations and segments for those levels and define their corresponding utility.
-    \item \todo{we didn't talk about performance, even though we have a few things to say about this in the client and right here}
+    \item \textbf{Performance has been taken into consideration}, and even though the many textures and the heterogeneity of our model prevents us from reaching optimal performances, we still manage to restructure the content on the client side to have a decent framerate.
 \end{itemize}
 
 However, the work described in this chapter does not take any quality of experience aspects into account.