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

- conclusion future work proofread

This commit is contained in:
acarlier 2019-10-20 15:51:21 +02:00
parent 5e8d7dd4c2
commit 1872a8791b
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
src/conclusion/future-work.tex
View File

@ -1,31 +1,31 @@
\fresh{} \fresh{}
\section{Future work} \section{Future work}
Successfully using the DASH framework for 3D content is a significant step that naturally opens many exciting perspectives. Successfully adapting the DASH framework to 3D content is a significant step that naturally opens many exciting perspectives.
In this section, we shall detail three major perspectives for future work. In this section, we shall detail three major perspectives for future work.
\subsection{Semantic information} \subsection{Semantic information}
In this thesis, no attention has been given to semantic. In this thesis, no attention has been given to semantic.
Our content preparation considers only spatial information both for 3D content and clients so our adaptation sets and segments may separate data that could be grouped semantically. Our content preparation considers only spatial information both for 3D content and clients so our adaptation sets and segments may separate data that could be grouped semantically.
Having semantic information could help us derive a better structure for our content: we know that displaying half a building will lead to low quality of experience. Having semantic information could help us derive a better structure for our content: we know for example that displaying half a building will lead to low quality of experience.
In order to account for semantic besides partitioning, we could also adapt the utilities we have been defining for our segments: some semantically significant data can be considered as more important than other by taking it into account in our utilities. In order to account for semantic besides partitioning, we could also adapt the utilities we have been defining for our segments: some semantically significant data can be considered as more important than other by taking it into account in our utilities.
\subsection{Compression / multi resolution for geometry} \subsection{Compression / multi resolution for geometry}
In this thesis, we considered different resolutions for textures, but for geometry, neither compression nor multi-resolution. In this thesis, we considered different resolutions for textures, but we have not investigated geometry compression nor multi-resolution.
Geometry data is transmitted as OBJ files which mostly consist in ASCII encoded numbers, which is terrible for transmission, and compression could reduce size, thus increase the quality of experience. Geometry data is transmitted as OBJ files (mostly consisting in ASCII encoded numbers), which is terrible for transmission. Compression would reduce the size of the geometry files, thus increasing the quality of experience.
Being able to support multi resolution geometry would be even better, and even if performing multi resolution on a large and heterogeneous scene just like ours is difficult. Supporting multi resolution geometry would improve it even more, even if performing multi-resolution on a large and heterogeneous scene is difficult.
Moreover, only few work have considered multi-resolution for textured geometry~\citep{maglo20153d}, and only for objects. To this day, only a few work have considered multi-resolution for textured geometry~\citep{maglo20153d}, and their focus has been on 3D objects.
There, using semantic information would also benefit compression. Once again, semantic information could be a great help in this regard.
% we have no doubt that semantic information can help this task. % we have no doubt that semantic information can help this task.
\subsection{Performance optimization} \subsection{Performance optimization}
Performance has already been discussed in Chapter~\ref{d3}. Performance has already been discussed in Chapter~\ref{d3}.
However, in this work, we never tried to remove data from the media engine when it is no longer useful. However in this thesis, we have for example never discussed removing data from the media engine when it is no longer useful.
This means that on a really large scene, performance is bound to become damaged due to the growing amount of data to render, and the saturation of GPU memory. This means that on a really large scene, performance is bound to become damaged due to the growing amount of data to render, and the saturation of GPU memory.
For our system, in order for a client (even more for a mobile client), to be able to support such scenes, it needs to unload data. In order for a client (even more a mobile client) to be able to support such scenes, it is necessary to implement a mechanism to periodically free the memory.
The utility measures that we described in Section~\ref{d3:utility} is a good candidate to determine what to unload. The utility measures that we described in Section~\ref{d3:utility} are good candidates to determine what to unload.
We could estimate the performance of our system by measuring variables such as memory used or framerate and use those values to discard data with low enough utility. We could estimate the performance of our system by measuring variables such as memory used or framerate and use those values to discard data with low enough utility.
Finally, this thesis has proposed a first, but ambitious, complete development of a DASH-3D framework, providing a scalable, efficient, streaming for textured meshes. Finally, this thesis has proposed a first, but ambitious, complete development of a DASH-3D framework, providing a scalable, efficient, streaming for textured meshes.