report first version

6 files changed, 84 insertions, 0 deletions

diff --git a/report/2iv55-report.tex b/report/2iv55-report.tex
new file mode 100644
index 0000000..9f0f238
--- /dev/null
+++ b/report/2iv55-report.tex
@@ -0,0 +1,21 @@
+\documentclass[10pt,a4paper]{article}

+\usepackage{graphicx}

+

+\begin{document}

+

+  % Title page

+  \title{MatchBlox (2IV55)\\Group 7}

+  \author{Dennis Peeten (0571361)\\Oliver Schinagl (0580852)\\Maik Teurlings (0591600)\\Wilrik De Loose (0601583)}

+  %\date{7 February 2006}

+  \maketitle

+

+%no paragraph indentation

+\parindent=0in

+

+\include{toc}

+\include{chapter1}

+\include{chapter2}

+\include{chapter3}

+\include{chapter4}

+

+\end{document}

diff --git a/report/chapter1.tex b/report/chapter1.tex
new file mode 100644
index 0000000..2cad507
--- /dev/null
+++ b/report/chapter1.tex
@@ -0,0 +1,11 @@
+\section{Introduction}
+
+For the master course Interactive Virtual Environments (2IV55), group 7 decided to create an application that can be used in an experimental setup. The application uses different techniques from computer graphics to create some kind of virtual environment. The goal of this program was to draw some conclusions whether or not these techniques contribute to the accuracy of the user when utilizing a "3D mouse" with 3DOF\footnote{Degrees of freedom: The amount of motion supported in a robotics or virtual reality system. 3DOF provides X, Y and Z (horizontal, vertical and depth) while 6DOF provides X, Y and Z and pitch, yaw and roll}. \\
+
+And thus, the "MatchBlox" project was born. It would challenge the user to take a wooden block in 3D and put it in the correct position. These small experiments could then be repeated with the assistance of head tracking or stereo vision. The exact goals of the project and the problems encountered are discussed in chapter 2 of this report. \\
+ 
+Head tracking is a relatively old technique in the field of virtual environments. It basically keeps track of the head's position and/or rotation. Using the information about the head's position, the virtual world can be rendered according to these values. This turns an ordinary computer screen into a virtual window which the user can look trough from different angles. \\
+
+Stereo vision is another well-known technique mainly because it's very easy to apply. By rendering the virtual world twice and merging the two images one can accomplish the illusion of depth. The stereo vision and the head tracking techniques are explained in more detail in chapter 3. \\
+
+Finally, in chapter 4, a conclusion is drawn from the execution of the project.
\ No newline at end of file
diff --git a/report/chapter2.tex b/report/chapter2.tex
new file mode 100644
index 0000000..95c6c7b
--- /dev/null
+++ b/report/chapter2.tex
@@ -0,0 +1,43 @@
+\section{Project definition}

+

+This chapter gives an insight in the MatchBlox project. First of all, the goals of the project and how they changed during the execution of the project are listed and explained. Then, in the next paragraph, the problems that were encountered are discussed. This chapter concludes with a short project evaluation.

+

+\subsection{Goals}

+

+In the proposal for this course, the MatchBlox project was defined as an experiment for which "the results should give an insight in the usability of a 3D input device". The usability could be tested with and without some key factors, namely:

+

+\begin{itemize}

+  \item Head tracking

+  \item Stereo glasses red/blue

+  \item Depth of the field

+  \item Shadow projection

+\end{itemize}

+

+The first two factors, head tracking and stereo vision, were researched before implementation started. From these two small research assignments two demo applications were created. These two demo programs respectively showed a possible implementation for head tracking and for stereo vision. Both will be explained in detail in the next chapter. \\

+

+The depth of the field was implemented by altering the size of the box in which the user puts the blocks. Three different sizes were supported; small (2x2), medium (3x3) and large (4x4). \\

+

+As for the shadow projection, the idea was dropped because the number of test cases would grow to large. Without the addition of shadow projection the number of test cases were already $ 2 \times 2 \times 3 = 12 $. The implementation of the current application as well as the supporting database does support the addition of an extra factor such as shadow projection.

+

+\subsection{Problems}

+

+The number of test cases to implement was the first small problem the group had encountered. However, it was not the only one. The main problem was due to the chosen input device; the Wiimote\footnote[1]{Wiimote is a nickname for the Wii remote which is the primary controller (6DOF) used with the Nintendo Wii.}. As the Wiimote supports 6DOF only 3DOF were used in the project. This was enough to be able to place a block inside the correct hole.

+

+\subsubsection{Lag in library}

+

+In order to support a Wiimote in a program like MatchBlox, a number of development libraries are available on the web. The library that was initially used for the application suffered a lot of lag. It took some time to determine the error and switch to another library.

+

+\subsubsection{Depleted batteries}

+

+A second Wiimote is used to track the head using the infrared camera in front of the Wiimote. The user places two infrared LED's which the Wiimote can keep track of. A wireless Wii sensorbar\footnote[1]{The Wiimote senses IR light from the sensor bar. The light emitted from each end of the sensor bar is focused onto the image sensor which sees the light as two bright dots separated by a distance "mi" on the image sensor. The second distance "m" between the two clusters of light emitters in the Sensor Bar is a fixed distance. From these two distances m and mi, the distance between the Wiimote and the sensor bar can be calculated.} was used for this. This has as great advantages that it's wireless (as opposed the the wired variant shipped with the Wii console) and no home made infrared LED's need to be used. \\

+

+A great disadvantage however, is that it need batteries and it's not visible when the batteries are almost depleted. When the batteries are running low, it is harder for the Wiimote to detect the IR dots. With the use of a camera from a mobile phone, the infrared LED's can be seen. This is a good way to check if the sensor bar is still emitting IR light.

+

+\subsubsection{Cross talk}

+

+Cross talk is a common problem in all implementations of stereo vision. It occurs when left images reach the right eye and right images reach the left eye. In other words, you see things with an eye you're only supposed to see with the other eye. In the case of red and blue stereo vision it means that the colors are not properly filtered out. \\

+

+There exist a technique that reduces this effect. What it basically does is subtract the leakage from the displayed intensity. This technique was not applied to the MatchBlox application. Instead, a more detailed and moving background is used. This makes the crosstalk less visible.

+

+\subsection{Evaluation}

+

diff --git a/report/chapter3.tex b/report/chapter3.tex
new file mode 100644
index 0000000..0baa9c5
--- /dev/null
+++ b/report/chapter3.tex
@@ -0,0 +1,6 @@
+\section{Techniques}

+

+\subsection{Head tracking}

+

+\subsection{Stereo vision}

+

diff --git a/report/chapter4.tex b/report/chapter4.tex
new file mode 100644
index 0000000..1883b5f
--- /dev/null
+++ b/report/chapter4.tex
@@ -0,0 +1,2 @@
+\section{Conclusions}

+

diff --git a/report/toc.tex b/report/toc.tex
new file mode 100644
index 0000000..f39cb6c
--- /dev/null
+++ b/report/toc.tex
@@ -0,0 +1 @@
+\tableofcontents