
%
\documentclass[10pt, conference, compsocconf]{IEEEtran}
% Add the compsocconf option for Computer Society conferences.
%


\usepackage{amsmath}
\usepackage{graphicx}
\usepackage{pstricks,pst-plot,pst-node,pst-tree}



% *** GRAPHICS RELATED PACKAGES ***
%
\ifCLASSINFOpdf
  % \usepackage[pdftex]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../pdf/}{../jpeg/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
\else
  % or other class option (dvipsone, dvipdf, if not using dvips). graphicx
  % will default to the driver specified in the system graphics.cfg if no
  % driver is specified.
  % \usepackage[dvips]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../eps/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.eps}
\fi
% graphicx was written by David Carlisle and Sebastian Rahtz. It is

% correct bad hyphenation here
\hyphenation{op-tical net-works semi-conduc-tor}


\begin{document}
%
% paper title
% can use linebreaks \\ within to get better formatting as desired
\title{Dynamic Adjustment of Stereo Parameters for Virtual Reality Tools}


% author names and affiliations
% use a multiple column layout for up to two different
% affiliations

% \author{\IEEEauthorblockN{Authors Name/s per 1st Affiliation (Author)}
% \IEEEauthorblockA{line 1 (of Affiliation): dept. name of organization\\
% line 2: name of organization, acronyms acceptable\\
% line 3: City, Country\\
% line 4: Email: name@xyz.com}
% \and
% \IEEEauthorblockN{Authors Name/s per 2nd Affiliation (Author)}
% \IEEEauthorblockA{line 1 (of Affiliation): dept. name of organization\\
% line 2: name of organization, acronyms acceptable\\
% line 3: City, Country\\
% line 4: Email: name@xyz.com}
% }

% conference papers do not typically use \thanks and this command
% is locked out in conference mode. If really needed, such as for
% the acknowledgment of grants, issue a \IEEEoverridecommandlockouts
% after \documentclass

% for over three affiliations, or if they all won't fit within the width
% of the page, use this alternative format:
% 

\author{
\IEEEauthorblockN{Felipe Carvalho, Daniel R. Trindade, Peter F. Dam, Alberto Raposo}
\IEEEauthorblockA{Tecgraf / Department of Informatics \\ 
Pontifical Catholic University of Rio de Janeiro \\
Email: \{kamel, danielrt, peter, abraposo\}@tecgraf.puc-rio.br}
\and
\IEEEauthorblockN{Ismael H. F. dos Santos}
\IEEEauthorblockA{CEMPES Petrobras, Rio de Janeiro, RJ - Brasil\\
Email: ismaelh@petrobras.com.br}
}




%\author{
%\IEEEauthorblockN{
%Felipe G. Carvalho\IEEEauthorrefmark{1},
%Daniel R. Trindade\IEEEauthorrefmark{1},
%Peter F. Dam\IEEEauthorrefmark{1}, 
%Alberto B. Raposo\IEEEauthorrefmark{1} and
%Ismael H. F. dos Santos\IEEEauthorrefmark{2}
%}

%\IEEEauthorblockA{
%\IEEEauthorrefmark{1}Tecgraf / Department of Informatics \\ 
%Pontifical Catholic University of Rio de Janeiro \\ 
%Email: \{kamel, danielrt, peter, abraposo\}@tecgraf.puc-rio.br}

% \IEEEauthorblockA{
% \IEEEauthorrefmark{2}Tecgraf / Department of Informatics \\ 
% Pontifical Catholic University of Rio de Janeiro \\ 
% Email: danielrt@tecgraf.puc-rio.br}
% 
% \IEEEauthorblockA{\IEEEauthorrefmark{3}Tecgraf / Department of Informatics \\ 
% Pontifical Catholic University of Rio de Janeiro \\ 
% Email: peter@tecgraf.puc-rio.br}
% 
% \IEEEauthorblockA{\IEEEauthorrefmark{4}Tecgraf / Department of Informatics \\ 
% Pontifical Catholic University of Rio de Janeiro \\ 
% Email: abraposo@tecgraf.puc-rio.br}

%\IEEEauthorblockA{\IEEEauthorrefmark{2}CEMPES Petrobras, Rio de Janeiro, RJ - Brasil\\
%Email: ismaelh@petrobras.com.br}}




% use for special paper notices
%\IEEEspecialpapernotice{(Invited Paper)}




% make the title area
\maketitle


\begin{abstract}

%O surgimento de tecnologias novas e mais acessiveis est� tornando mais comum o 
% aparecimento de aplica��es 3D interativas (por exemplo,jogos e realidade virtual) 
% com suporte a visualiza��o estereoscopica. Entretanto, este fato n�o resolve alguns 
% problemas (enjoos e dores de cabe�a) se cuidados n�o forem levados em conta 
% durante a gera��o do conteudo para este tipo de visualiza��o. Entre estes 
% cuidados est�o a converg�ncia/acomoda��o dos olhos assim como o aparecimento 
% de objetos recortados na paralaxe negativa. Este trabalho apresenta uma t�cnica 
% baseada numa estrutura de cubemap para ajustar dinamicamente parametros de 
% estereoscopia em cen�rios multi-escala.

Due to emerging new technologies in the development of interactive 3D applications (eg games and virtual reality), 
stereoscopic visualization is becoming a common feature. However, this fact does not solve some problems 
(nausea and headaches - cybersickness) related with the generation of this type of visualization. Some parameters have 
to be carefully chosen to create a comfortable stereo view, for example, eye distance, zero parallax plane distance, 
and the treatment of partially clipped objects in negative parallax. This paper presents a technique based on a CubeMap structure to dynamically 
adjust stereo parameters during the usage of two virtual reality tools in multi-scale 3D scenarios.

\end{abstract}

\begin{IEEEkeywords}
virtual reality; interaction; 3D techniques; stereoscopy;

\end{IEEEkeywords}


% For peer review papers, you can put extra information on the cover
% page as needed:
% \ifCLASSOPTIONpeerreview
% \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
% \fi
%
% For peerreview papers, this IEEEtran command inserts a page break and
% creates the second title. It will be ignored for other modes.
\IEEEpeerreviewmaketitle



\section{Introduction}
% no \IEEEPARstart

Currently new stereoscopic technologies are increasingly 
present in our lives. What was once just fun colored 
glasses, today are modern solutions that allow you to view 3D 
graphics without loss of visual characteristics such as brightness or color.

Besides cinema's entertainment, stereoscopic visualization reached new areas, among 
them are games and virtual reality. These two areas share the use of interactive 3D graphics, 
which enables users to change the virtual scenes at any time.

When someone looks at an object in the real world, the eyes focus on 
the object and also converge (turning an eye toward the other) on 
it. After the process of focusing and convergence of the eyes, 
the brain fuses the two images (from the left and right eyes) into one, allowing 
viewing stereoscopic or depth. In Figure \ref{fig:stereo} there are the basic elements to understand the 
stereoscopic configuration process inside a 3D interactive application. Often an application 
needs to set two parameters: eye distance and fusion distance. The first 
parameter is used as an offset to create two different virtual view points, 
one for the right eye and other for the left. 

\begin{figure}[htb]
  \centering
  \includegraphics[scale=0.4]{figs/stereo}\\
  \caption{Stereoscopic elements.}
  \label{fig:stereo}
\end{figure}

Since the parallax is the distance between the corresponding points from the 
images of the right and left eyes, three important elements are identified 
based on the value of this distance: zero parallax plane, positive parallax region 
and negative parallax region. These different parallaxes indicate different distances 
from the viewer and the second parameter refers to it. The fusion distance is the position
of the zero parallax plane. A virtual object near this plane appears to be in plane of the screen,
objects inside the positive parallax appear to be behind the screen, and those which appear to be in 
front of the screens belong to the negative parallax region.

Objects with high parallax values (positive or negative) cause discomfort because the eyes have a hard time converging
on them. Very often this is treated using the clipping planes, i.e., near plane is used to decrease the negative parallax 
region while the far plane is used to decrease the positive parallax region.

The benefits of stereo are well known \cite{Holliman04,Lipton97,McAllister93}, 
but the development of applications 
of this nature must take care to avoid problems that could cause 
discomfort to users \cite{Matthias95, Yeh90, Woods93}, such as nausea, 
headaches, etc. One of the causes of these efects is the convergence / 
accommodation problem \cite{Ware98dynamicadjustment,Noro93}. When someone looks at a screen or monitor, the eyes are 
accommodated on the plane of the screen, but are converged using the 
parallax between the left and right images. For some people, this is 
perceived as discomfort. To minimize the negative effects of this 
problem, convergence plane must be positioned on the screen or monitor, 
and one should carefully choose the distance between the eyes to 
avoid a high disparity in the projected images.

Another important problem is the conflicts between the clipped objects 
and parallax depth  \cite{Valyrus66}. If an object has a negative parallax 
and is being blocked (partially clipped) by the borders of the screen, 
the sensation of stereoscopic depth is seriously impaired. 
This problem occurs because of the conflict between the resulting three-dimensional depth 
of the negative parallax interposed between the scene objects and 
the screen. One solution to this problem is to place the near plane on 
the zero parallax plane position, but this approach cancels any visualization in the negative parallax region.

In virtual reality applications, often these problems are found in tasks 
such as navigation or object manipulation. For instance, 
while navigating in a 3D scene, composed by objects of different scales 
(multi-scale environment \cite{furnas95}), if the eye distance is maintained constant 
throughout the scenario it will cause problems of convergence. This is 
explained by the fact that an eye distance X used in a virtual room, 
can become unreasonably large if the user navigates into places smaller than this room.
In these others places, the unmodified eye distance becomes too separated and resulted parallax becomes larger.

The objective of this work is to propose a solution capable of dynamically
adjusting the stereo parameters in virtual reality applications. The
techniques presented here are based on a data structure called cubemap,
initially proposed by \cite{maccrae09}. Also some virtual reality
navigation techniques are discussed, since these have a large influence
in the stereo adjustment we propose.

This paper is structured in the following manner: section \ref{sec:related_work} 
presents related work. Section \ref{sec:cubmap} briefly describes the cubemap 
structure. Section \ref{sec:navigation_tec} describes improvements made to 
some navigation techniques that are important for the stereo parameter's dynamic 
adjustment, which is presented in section \ref{sec:dynamic_stereo}. Finally, 
section \ref{sec:conclusion} concludes the paper.

\section{Related Work} \label{sec:related_work}

% A tentativa de se estabelecer automaticamente os parametros de estereo foi objeto de 
% estudo de v�rios autores. Em sua maioria, esses trabalhos fazem uso da informa��o de 
% profundidade da cena para estabelecer a separa��o dos olhos e a distancia ao plano 
% de parallax zero.
% 
% Jones et al \cite{Jones01} criou um metodo que leva em consideracao a geometria do mundo 
% real na determinacao dos parametros de estereo. Baseados em estudos anteriores, eles 
% estabeleceram o intervalo maximo de profundidade para um determinado display em que a maioria 
% das pessoas seria capaz de fundir duas imagens. Com esses dados em m�os, assim como a 
% distancia entre os olhos de uma pessoa real e sua distancia para a tela, eles s�o capazes 
% de calcular qual a separa��o virtual dos olhos. A ideia deles e mapear a cena do mundo 
% virtual para o mundo real, de forma que a rela��o entre as disparidades do objeto mais 
% perto e mais longe da camera se mantenha o mais proxima possivel da rela��o existente no 
% mundo real.
% 
% Em seu trabalho, Holliman \cite{Holliman04} usa o mesmo conceito de \cite{Jones01}, mas 
% introduz a ideia de regi�o de interesse. Ao inv�s de mapear linearmente a cena para o 
% intervalo de profundidade que pode ser percebido, Holliman cria 3 regioes: a primeira, mais 
% proxima do plano de corte near; a segunda, contendo o plano de parallax zero; e a terceira, 
% mais proxima do plano de corte far. A sedunda regiao e a maior, e concentra os objetos de 
% interesse da cena. Com isso, Holliman tem como vantagem diminuir a distor��o que � causada 
% pelo metodo de \cite{Jones01}, que faz o mapeamento linear. Entretanto, na duas regioes 
% restantes, ainda h� a distor��o. Al�m disso, esse metodo � dependente do tipo de display e 
% ambiente que est� sendo usado.
% 
% Ware et al \cite{Ware98} conduziram experimentos afim de tentar identificar de que forma os usu�rios 
% ajustam os parametros de estereoscopia e como essas pessoas reagiriam ao ajuste dinamico 
% desses valores. Primeiramente, foram realizados testes com usu�rios para saber qual a 
% taxa maxima de mudanca no estereo que uma pessoa pode suportar. Em seguida, foi pedido aos 
% usu�rios que ajustassem manualmente os parametros do estereo, at� que a visualizacao 
% ficasse confortavel. De posse desses dados, Ware et al criaram um algoritmo de 2 estagios para 
% ajustar apropriadamente a separa��o virtual dos olhos e distancia ao plano de parallax. O metodo 
% de Ware et al leva em consideracao os dados diretos do usuarios que participaram dos testes e, 
% dessa forma, n�o garante o funcionamento para todos os tipos de pessoas.

The attempt to automatically adjust stereo parameters was an object of study for
several authors. In their majority these works use the scene's depth information to
establish the eye separation and the zero parallax plane.

Jones et al \cite{Jones01} created a method that takes into account the geometry of the
real world to determinate the stereo parameters. Based on previous studies, they
established the maximum depth interval for a given display in which the majority of
people would be capable of merging two images. With this data in hands, along with
the distance between the eyes of a real person and their distance to the screen, they
are capable of calculating the virtual eye separation. Their idea is to map the virtual
world scene to the real world, in a way that the relationship between the disparities of
the objects closest and furthest to the camera stays as close as possible to the
relationship existing in the real world.

In his work Holliman \cite{Holliman04} uses the same concept as \cite{Jones01}, but
introduces the idea of an interest region. Instead of linearly mapping the scene to
the noticeable depth interval, Holliman creates three regions: the first, closer to
the near clipping plane; the second, containing the zero parallax plane; and the third,
closer to the far clipping plane. The second region is the largest, and concentrates the
objects of interest in the scene. With this, Holliman has the advantage of reducing the
distortion caused by the method presented in \cite{Jones01}, which uses linear mapping.
However in the two other regions there still is distortion. Furthermore, this method
depends on the display type and environment that is being used.

Ware et al \cite{Ware98} conducted experiments to identify how users adjust stereoscopy
parameters and how those users would react to the dynamic adjustment of those values.
First, tests were performed with users to know what the maximum rate of changes in stereo
that a person could support. Next, the users were asked to manually adjust the stereo
parameters until the visualization was comfortable. With this data, Ware et al created a
two pass algorithm to appropriately adjust the virtual eye separation and zero parallax plane
distance. This method takes into account the direct input from users who participated in the
tests and, because of this, does not guarantee appropriate behavior for all people.

\section{The Cubemap} \label{sec:cubmap}

The purpose of the cubemap, as proposed by McCrae et al. \cite{maccrae09}, is to provide information about the virtual
environment at a given moment. Given a camera position, this structure is constructed from 6
rendering passes, each in a different direction in order to cover the whole
environment. The FOV of the camera is $90^0$, therefore the combination of the 6
resulting frustums yields a cube. At each pass, a shader is used to calculate
the distance from the fragment generated to the camera. The computed distance
values are normalized in relation to the \emph{near} and \emph{far} values, and
stored in the \emph{alpha} channel of the positions related to the fragments.
Rendering is made in 32-bit float images. Such procedure is performed at each frame, or each time the camera position
changes. The image resolution used for rendering does not have to be high, since only an
estimation needs to be obtained.

In our implementation of the cubemap, we also use the \emph{RGB} channels of the 
images to store a unit vector pointing from the position of the generated 
fragment to the camera. This simplifies the construction of the force map we 
use to avoid collisions (section \ref{sec:colision_detection}).

\section{Navigation Techniques} \label{sec:navigation_tec}

In this section we will present three navigation techniques. Althouth they are 
not directly connected to stereoscopy, they are important to avoid some problems 
in this sense. These techniques were first proposed by Maccrae et al 
\cite{maccrae09} and were evaluated by \cite{daniel11}.

\subsection{Fly with Automatic Speed Adjustment} \label{sec:ajuste_vel}

Navigation speed is related to the scale of the environments to be explored.
Larger environments require faster speeds, while the opposite is more convenient
on smaller scales.For instance, the camera speed is expected to be higher when
navigating from one planet to another, but much lower when navigating from a 
city to another.

In several applications, the scale of the virtual world does not change much and
is well known, allowing a fixed navigation speed to be used. This is
the case of many games, for instance. Multiscale environments,
however, require a way to estimate the current scale in
order to adjust the navigation speed accordingly.

McCrae et al. \cite{maccrae09} use $minDist$, the minimum distance in the cubemap, as an 
estimation to determine the current scale
the camera is at. Based on that, first we developed a \emph{fly} tool which
could be controlled by the user by pressing the arrow keys of the keyboard to
move the camera while guiding the direction of the motion with the mouse
movements. Navigation speed was adjusted automatically according to equation
\ref{eq:vel_nav}.
\begin{equation} \label{eq:vel_nav}
 V_{nav} = k \ minDist
\end{equation}
where $V_{nav}$ is the adjusted navigation speed and $k$ is a parameter of unit 1/s that
causes an increase or reduction in the acceleration applied to the camera. We
noticed that two situations caused discomfort and disorientation for some users. 
The first situation is when $k$ is too high. In this situation, when users move away 
from the geometry, the camera accelerates too quickly, producing an effect similar to 
teleporting and making users lose their location. The second situation happens for low $k$ 
values, which can considerably increase the time required to reach the intended destination, 
making the navigation tedious. Thus, the value of $k$ should be selected in a way that it 
balances these extreme situations.

\subsection{Collision Detection and Treatment} \label{sec:colision_detection}

Not allowing the camera to cut through objects in a virtual environment can
be crucial in some situations. In immersive environments, for example, colliding
with an object can halt the immersion and leave the user disoriented. When stereoscopy 
also exist, the collisions could break the stereo effect.

McCrae et al. \cite{maccrae09} used information from the distance cube to obtain a collision
factor that causes the camera to smoothly dodge the
closest objects. The idea is that each point in the cubemap located at a
distance smaller than a given radius $r$ produces a repulsion factor given by:
\begin{equation}\label{eq:colision_force}
 F(x,y,i) = w(dist(x,y,i)) \ norm(pos(x,y,i) - camPos)
\end{equation}
\begin{equation}\label{eq:penal_factor}
 w(d) = e^{\frac{(r - d)^2}{\sigma^2}}
\end{equation}
where $F(x,y,i)$ is the repulsion factor produced by point $p$ referring to
position $(x,y)$ of image $i$ of the cubemap. Value $dist(x,y,i)$ is the
distance from $p$ to the camera. The term $pos(x,y,i)$ is the position of $p$ in
world space, and $camPos$ is the camera position. Function $norm(v)$ indicates
the normalized vector of $v$. In equation \ref{eq:penal_factor}, $\sigma$ is a
parameter that indicates the smoothness of the collision factor. The higher
$\sigma$ is, the smoother will be the calculated factor. Considering a spherical
region with radius $r$ and centered on the camera position, equation
\ref{eq:penal_factor} results in determining a collision penalty that grows
exponentially from the moment when point $p$ enters this region.

The repulsion factors referring to equation \ref{eq:colision_force} are computed
for each position in the cubemap where $d < r$ and then are combined into a single
factor: 
% if the distance stored in the
% current position is smaller than $r$, then the corresponding point is inside the
% collision region, and a penalty is calculated for it according to equations
% \ref{eq:colision_force} and \ref{eq:penal_factor}. After doing this for all
% points, the results are combined into a single factor, given by the following
% equation:
\begin{equation}\label{eq:f_colisao}
 F_{collision} = \dfrac{1}{6 \ cubeRes^2} \sum_{x,y,i} F(x,y,i)
\end{equation}
where $cubeRes$ is the resolution of the distance cube.

When we applied the factor given by equation \ref{eq:f_colisao} to the camera,
the \emph{fly} tool behaved as described in the previous section: as the camera
moves, $F_{collision}$ ensured that it smoothly deviate the objects that crossed
its path. The user then can navigate through the
environment without worrying about choosing a collision-free path as the
system is in charge of this task.

\subsection{Automatic adjustment of clipping planes}

% A má configuração dos planos de clipping pode levar a problemas que vão 
% desde o corte indevido de objetos até o aparecimento de artefatos em objetos 
% distantes da câmera. Quando em estéreo, esses problemas se tornam piores ainda, 
% ficando ainda mais evidentes para os usuários. Portanto, o ajuste correto dos 
% planos de clipping é um requisito importante para a criação de um efeito de estéreo 
% correto.
% 
% \cite{maccrae09} desenvolveram uma técnica de ajuste automático para os planos 
% de corte. Essa consiste em utilizar a informação $minDist$ presente no cubemap 
% a fim de selecionar valores ótimos para os parâmetros \emph{near} e 
% \emph{far}. A ideia deles é manter a geometria vísivel sempre no intervalo entre 
% \emph{near} e \emph{far}. A cada quadro, verifica-se a necessidade de se atualizar 
% os planos de corte de acordo com as seguintes equações:
% 
% \begin{equation} \label{eq:ajuste_planos0}
% n = \left\{ \begin{array}{ll}
%  \alpha n & \textrm{se $minDist < An$}\\
%  \beta n & \textrm{se $minDist > Bn$}\\
%  n & \textrm{caso contrário}\\
%   \end{array} \right.
% \end{equation}
% 
% \begin{equation} \label{eq:ajuste_planos1}
%  f = Cn
% \end{equation}
% 
% \begin{figure}[htb]
%   \centering
%   \includegraphics[scale=0.25]{figs/ajuste_planos}\\
%   \caption{Automatic adjustment of clipping planes [19]}
%   \label{fig:ajuste_planos}
% \end{figure}
% 
% 
% Na equações \ref{eq:ajuste_planos0} e \ref{eq:ajuste_planos1}, $n$ é o valor de 
% \emph{near}, $f$ o valor de \emph{far}, $minDist$ é a menor distância (não 
% normalizada) armazenada no cubo de distâncias, $\alpha$, $\beta$, $A$, $B$ são 
% constantes que indicam quando e como os planos de corte devem ser atualizados. 
% Na implementação de \cite{maccrae09}, assim como em nossas aplicações de teste, os 
% valores  $\alpha = 0.75$, $\beta = 1.5$, $A = 2$, $B = 10$ produziram resultados 
% satisfatórios. Por último, $C$ expressa a razão entre os valores de $n$ e $f$. 
% O valor de $C$ deve ser escolhido de forma que não ocorram cortes em objetos 
% localizados próximos do plano \emph{far}. Ao mesmo tempo, $C$ não pode assumir 
% valores muito altos pois isso provocaria perda de precisão no \emph{depth 
% buffer}. Em nossas aplicações, $C$ foi fixado em 10000.
% 
% A Figura \ref{fig:ajuste_planos}, retirada de \cite{maccrae09}, ilustra o modo 
% como as equações \ref{eq:ajuste_planos0} e \ref{eq:ajuste_planos1} agem sobre os 
% valores dos planos de corte. No caso \emph{(a)}, o ponto mais próximo da cena, 
% representada por uma estrela, está localizado no intervalo $[An, Bn]$ e dessa 
% forma não é necessária nenhuma modificação dos planos de corte. Esse é o caso 
% ideal. No caso \emph{(b)}, $minDist$ se tornou menor do que $An$, ou seja, está mais 
% próximo do plano \emph{near}. Os planos de corte são então ajustados para valores 
% menores, de forma a garantir, com certa margem de segurança, que a geometria da 
% cena fique dentro do frustum de visão. Da mesma forma, no caso \emph{(c)} os 
% planos de corte são ajustados para valores maiores, uma vez que $minDist$ está 
% mais distante da câmera ( $minDist > Bn$ ).

The non-configuration of the clipping planes can lead to problems ranging from
the undue clipping of objects to appearance of artifacts on objects distant
from the camera. When in stereo, these problems become even worse, becoming
more evident to the users. Therefore the correct adjustment of the clipping
planes is an important requirement to create a correct stereo effect.

Maccrae et al \cite{maccrae09} developed a technique of automatic adjustment of the clipping
planes. It consists in using the $minDist$ information available in the CubeMap
to select optimal values for the \emph{near} and \emph{far} parameters. Their
idea is to maintain the visible geometry always between \emph{near} and \emph{far}.
At each frame the need to update the clipping plane is checked based on the
following equations:

\begin{equation} \label{eq:ajuste_planos0}
n = \left\{ \begin{array}{ll}
 \alpha n & \textrm{if $minDist < An$}\\
 \beta n & \textrm{if $minDist > Bn$}\\
 n & \textrm{otherwise}\\
  \end{array} \right.
\end{equation}

\begin{equation} \label{eq:ajuste_planos1}
 f = Cn
\end{equation}

\begin{figure}[htb]
  \centering
  \includegraphics[scale=0.25]{figs/ajuste_planos}\\
  \caption{Automatic adjustment of clipping planes [11]}
  \label{fig:ajuste_planos}
\end{figure}

In the \ref{eq:ajuste_planos0} and \ref{eq:ajuste_planos1} equations, $n$ is the
\emph{near} value, $f$ is the \emph{far} value, $minDist$ is the minimum distance
(not normalized) stored in the distance cube, $\alpha$, $\beta$, $A$, $B$ are
constants that indicate when and how the clipping planes should be adjusted. In
the implementation present in \cite{maccrae09}, as well as in our test applications,
the values $\alpha = 0.75$, $\beta = 1.5$, $A = 2$, $B = 10$ yielded satisfactory
results. Finally, $C$ expresses the ratio between $n$ and $f$. $C$ should be chosen
so that objects near \emph{far} plane will not be clipped. At the same time $C$
should not be too high or else that would cause a loss of precision in the
\emph{depth buffer}. In our applications, $C$ was fixed at 10000.

The figure \ref{fig:ajuste_planos}, taken from \cite{maccrae09}, illustrates how
the equations \ref{eq:ajuste_planos0} and \ref{eq:ajuste_planos1} act on the values
of the clipping planes. In case \emph{(a)}, the closest point in the scene,
represented by a star, is located in the $[An, Bn]$ interval, which doesn't require
any modification to the clipping planes. This is the ideal case. In case \emph{(b)},
$minDist$ has become smaller than $An$, in other words, it is closer to the \emph{near}
plane. The clipping planes are then adjusted to lower values to ensure, with some
safety margin, that the scene's geometry stays inside the view frustum. Similarly in
case \emph{(c)} the clipping planes are adjusted to larger values, since $minDist$ is
further away from the camera ( $minDist > Bn$ ).

\section{Dynamic adjustment of stereo parameters} \label{sec:dynamic_stereo}

In our applications, we have primarily two ways that the user can interact with 
the scene: one is using the \emph{fly} navigation tool and the other is using the 
\emph{examine} manipulator. As each on of these techniques has its own characteristics, 
we developed two types of dynamic adjustment of stereo parameters. 

\subsection{Stereo Adjustment for Fly}

% Como visto nas secoes anteriores, boa parte dos parametros de navegacao sao 
% ajustados com base no menor valor presente no CubeMap em um determinado momento. 
% Nossa abordagem e usar tambem este valor para ajustar dinamicamente os 
% paramentros de estereo:
% 
% \begin{equation}\label{eq:paralax}
% Dist_{pzero} = minDist
% \end{equation}
% \begin{equation}\label{eq:eye}
% Eye_{sep} = k * minDist
% \end{equation}
% 
% Onde $Dist_{pzero}$ e a distancia da camera ate o plano de paralax zero, 
% ${minDist}$ e o menor valor presente no cubemap, $Eye_{sep}$ e a distancia 
% virtual entre os olhos e $k$ e uma constante. O ajuste acima e feito 
% dinamicamente sempre que a ferramenta de navegacao fly esta ativada.
% 
% A equacao \ref{eq:paralax} cria um efeito de stereo onde os objetos da cena 
% estao localizados a maior parte do tempo na paralax positiva. Esse comportamento 
% e parecido com aquele mostrado em \cite{Ware98}, e tem como principio 
% fornecer uma sensacao de profundidade confortavel para o usuario.
% 
% A abordagem adotada aqui e diferente daquela em \cite{Ware98}, uma vez que 
% esse ultimo utiliza o ponto mais proximo com base na varredura do Depth buffer 
% da camera principal. Nos usamos $minDist$, que representa o ponto mais proximo 
% da camera considerando-se uma visao de $360^{o}$. Isso implica que $minDist$ 
% pode ser referente a um ponto que nao esta localizado no campo de visao do 
% usuario. Aparentemente, o uso de $minDist$ pode nao fazer sentido, uma vez que 
% os parametros de estereo deveriam ser ajustados com base naquilo que o usuario 
% esta observando. Entretanto, o modo como a ferramenta fly funciona pode criar 
% alguns problemas que somente a informacao de profundidade da camera frontal nao 
% e capaz de resolver.
% 
% Como ja descrito em secoes anterioes, a ferramenta fly permite que o usuario 
% rotacione em $360^{o}$ a camera em relacao ao seu proprio eixo. Como resultado, 
% um objeto que antes nao estava no campo de visao da camera pode aparecer 
% bruscamente caso essa seja rotacionada muito rapido.
% 
% Em seu trabalho, \cite{Ware98} realizaram testes que mostram que existe uma 
% taxa maxima na qual os parametros de estereo podem ser ajustados sem que essa 
% operacao seja notada. Para respeitar tal restricao eles fizeram uma interpolacao 
% para suavisar os consecutivos ajustes de modo que o usuario não os perceba. Essa 
% suavizacao, entretanto, entrou em conflito com a situacao descrita anteriormente: 
% quando um objeto aparecia bruscamente no campo de visao, o usuario podia perceber 
% a existencia de duas imagens em separado durante o periodo em que a interpolacao 
% estava sendo feita. Por conta disso, \cite{Ware98} abandonaram a interpolacao.
% 
% Quando $minDist$ e usado, os problemas descritos anteriormente nao acontecem. 
% Como $minDist$ representa um minimo global para uma determinada posicao da 
% camera, a rotacao da camera nao provoca uma mudanca brusca dos parametros do 
% estereo, uma vez que $minDist$ nao e alterado. Alem disso, a entrada de 
% objetos no frustum da camera principal nao provoca quebra no estereo pois os 
% parametros ja foram ajustados levando-se em consideracao a possivel entrada de tais 
% objetos. Em outras palavras, usar $minDist$ como base para o ajuste dinamico do 
% estereo corresponde a antecipar acoes que o usuario pode vir a tomar no futuro. 
% Essa caracteristica representa uma vantagem quando levamos em consideracao que 
% aplicacoes de realidade virtual sao dinamicas no sentido de prover ferramentas 
% de navegacao e manipulacao para os usuarios. Esse nao e o caso, por exemplo, da 
% producao de estereoscopia em outras aplicacoes como, por exemplo, cinema, onde 
% os parametros podem ser ajustados com base naquilo que o diretor do filme quer 
% que as pessoas vejam.
% 
% Devido a restricao com relacao a taxa maxima de atualizacao dos parametros de 
% estereo, nos decidimos realizar os ajustes somente no momento em que os planos de 
% corte tambem sao ajustados. Dessa forma, toda vez que a camera chega em um ponto 
% da cena onde os planos de corte precisam ser reajustados, o estereo tambem e 
% reajustado e todos os objetos da cena sao colocados na regiao de paralax 
% positiva. Como nesse momento a distancia de paralax zero e ajustada para 
% $minDist$, alguns objetos podem entrar na regiao de paralax negativa caso a 
% camera continue se movendo na direcao do ponto referente a $minDist$. A 
% ocorrencia dessa situacao pode levar ao problema de cancelamento de frames. Nos 
% consideramos esse problema sem importancia no nosso caso, uma vez que nossas 
% aplicacoes devem rodar em ambientes imersivos como caves e teloes. Devido ao 
% tamanho desses ambientes, a sensacao de estereo nas bordas da tela pode ser 
% desprezada uma vez que essas estao quase sempre fora do campo de visao do 
% usuario.
% 
% A separacao entre os olhos e ajustada de acordo com a equacao \ref{eq:eye}. A 
% constante $k$ e definida empiricamente, de modo a criar uma sensacao de 
% profundidade confortavel para o usuario. Em nossos testes, chegamos a conclusao 
% de que $k = 0.01$ fornece um efeito satisfatorio para nossas cenas.
% 
% Por ultimo, e importante falar sobre a relacao do ajuste automatico de 
% velocidade e do tratamento de colisao descritos nas secoes \ref{sec:ajuste_vel} 
% e \ref{sec:colision_detection} com o ajuste dinamico de estereo mostrado aqui. 
% 
% Um dos requisitos para o funcionamento desse ajuste e que a variacao dos valores 
% presentes no cubemap entre quadros sucessivos não deve ser alta, de forma a 
% garantir suavidade para os valores de $minDist$. Isso so e conseguido gracas ao 
% ajuste continuo da velocidade de navegacao, que evita com que a camera de 
% "pulos". A figura \ref{fig:minCenterCurve} mostra a curva que e formada pelos valores 
% sucessivos de $minDist$ para um dado caminho de camera, quando o ajuste de 
% velocidade esta em funcionamento. Pode-se observar que a curva e suave e nao 
% apresenta picos. Isso tambem contribui para o funcionamento correto do ajuste 
% dos planos de corte e do tratamento de colisao. 
% 
% \begin{figure}[!h]
% \centering
% \input{figs/minCurve}
% \caption{Graph representing the behavior of the $minDist$ curve.}
% \label{fig:minCenterCurve}
% \end{figure}
% 
% O tratamento de colisao tambem e essencial para a corretude do estereo. Sem tal 
% tratamento, a camera seria capaz de ultrapassar objetos. Isso provocaria o 
% corte de objetos no plano near, ocasionando a quebra do estereo e causando 
% desconforto ao usuario. O tratamento de colisao descrito na secao 
% \ref{sec:colision_detection} impede que isso acontece, fazendo com que a 
% camera desvie suavemente dos objetos que estao em seu caminho.

As seen in previous sections, a large part of the navigation parameters are
adjusted based on the lowest value of the CubeMap at a certain moment.
Our approach is to use this value to dynamically adjust the stereo parameters
as well:

\begin{equation}\label{eq:paralax}
Dist_{pzero} = minDist
\end{equation}
\begin{equation}\label{eq:eye}
Eye_{sep} = k * minDist
\end{equation}

Where $Dist_{pzero}$ is the distance from the camera to the parallax zero
plane, ${minDist}$ is the lowest value in the CubeMap, $Eye_{sep}$ is the
virtual distance between the eyes and $k$ is a constant. This adjustment
is dynamically made when fly navigation tool is active.

The \ref{eq:paralax} equation creates a stereoscopy effect where the scene's
objects are in positive parallax most of the time. This behavior is similar
to the one observed in \cite{Ware98} and is based on providing a comfortable
depth sensation to the user.

The approach used here is different from the one in \cite{Ware98} since the
latter uses the nearest point based on a scan in the main camera's depth
buffer. We use $minDist$, which represents the nearest point to the camera
taking into consideration a $360^{o}$ view. This implies that $minDist$ could
refer to a point that is not localized in the user's field of view. The use of
$minDist$ may not seem to make sense, since the stereo parameters would be 
adjusted based on what the user can see. However, the way the fly tool works
may create some problems that cannot be solved with only the front camera's
depth information.

As described previously, the fly tool allows the user to rotate the
camera by $360^{o}$ on it's own axis. Because of that an object that previously
wasn't in the camera's field of view may abruptly appear in case the rotation is
fast.

In his work, \cite{Ware98} performed tests that show that there is a maximum rate
at which the stereo parameters may be adjusted without being noticeable. To
respect this restriction they interpolated the parameters to smoothen the
consecutive adjustments so the user would not notice it. This smoothening,
however, conflicts with the previous note: when an object abruptly appeared in
the field of view the user could see two separate images during the time that
the parameters were being interpolated. For this reason, \cite{Ware98} abandoned
the interpolation.

When $minDist$ is used, the previously described problems do not occur. Because
$minDist$ represents a global minimum distance to a certain camera position, the
camera's rotation does not cause an abrupt change to the stereo parameters, due
to $minDist$ not being changed. Furthermore, the appearing of objects in the
camera's frustum does not break the stereoscopy because the parameters have already
been adjusted taking into consideration the possibility of that object entering
the frustum. In other words, using $minDist$ as a base for the stereoscopy's
dynamic adjustment corresponds to anticipating actions the user may take. This
feature is an advantage when we take into account that virtual reality applications
are dynamic in the sense of providing the user with tools for navigation and
manipulation. This is not the case, for example, of stereoscopy in other applications,
such as cinema, where the parameters may be adjusted according to what
the movie's director wants people to see.

Due to the stereo parameters maximum update rate restriction we decided to perform
adjustments only when the clipping planes are adjusted. This way every time the
camera reaches a point where the clipping planes need to be adjusted, the stereo
is also adjusted and all objects in the scene are placed in positive parallax.
From this moment some objects may enter in the negative parallax region if the 
camera moves closer to the position that yielded
$minDist$. This may lead to objects in negative parallax being clipped by screen
borders. We consider this problem irrelevant, however, since they occurs for a 
briefly. Also, our applications are built for immersive systems such as caves and 
large screens. Dueto the size of these environments, this effect can be ignored 
since these areas are almost always out of the user's field of view.

The eye separation is adjusted according to the \ref{eq:eye} equation. The idea 
of this is to consider the current scale to set $Eye_{sep}$. For example, 
if the camera is in a room scale, it might be reasonable 
that $Eye_{sep}$ have a value that is in accordance to the eye separation of a 
real person. But if the camera is viewing an entire planet, then $Eye_{sep}$ 
should be reconfigured to larger value. With the adjustment provided with 
equation \ref{eq:eye}, $Eye_{sep}$ is appropriately updated as the camera moves 
in the scene. The $k$ constant is choosed to provide the user with a comfortable 
depth sensation. In our tests we discovered that $k = 0.01$ provides a 
satisfactory effect.

Finally, it is important to mention the relation between the automatic navigation
velocity adjustment and the collision detection described in sections \ref{sec:ajuste_vel}
and \ref{sec:colision_detection} with the dynamic stereo adjustment described here.

One of the requirements for this adjustment to work is that the variation of values in
the cubemap throughout successive frames should not be high, so we can guarantee that
values of $minDist$ will have a smooth variation. This is only achieved thanks to the
continued adjusting of the navigation velocity, which avoids the camera stuttering. The
figure \ref{fig:minCenterCurve} shows the curve generated by the successive values of
$minDist$ for a given camera path when the velocity adjustment is activated. It is
possible to observe that the curve is smooth and shows no peaks. This also contributes
to the proper functioning of the clipping planes and collision detection.

\begin{figure}[!h]
\centering
\includegraphics[scale=0.2]{figs/minCurve.eps}
\caption{Graph representing the behavior of the $minDist$ curve.}
\label{fig:minCenterCurve}
\end{figure}

The collision detection is also fundamental to the stereo's correctness. Without
this the camera would be able to pass through objects. This would cause
objects to be clipped by the near plane, causing a break in the stereo and,
consequently, discomfort to the user. The collision detection described in
\ref{sec:colision_detection} avoids that this happens, causing the camera to
smoothly swerve around objects in it's path.


% Uma implementa��o da ferramenta fly com o ajuste autom�tico foi realizada no 
% framework Unity3D. Na Figura \ref{fig:fly_unity01} h� um screenshot da aplica��o 
% desenvolvida mostrando um objeto (torre do castelo) parcialmente na paralaxe 
% negativa. Outro screnshot foi obtido para visualizar o posicionamento da paralaxe 
% de acordo com o minimo global, neste caso, posicionando-a antes do castelo 
% (Figura  \ref{fig:fly_unity02}).

An implementation of the fly tool with automatic adjustment was done in
Unity3D \cite{unity3d}. In the figure \ref{fig:fly_unity01} there is a screenshot of the
developed application showing an object (castle tower) partially in
negative parallax. Another screenshot was taken to view the parallax in
relation to the global minimum, in this case, placing it before the castle
(Figure \ref{fig:fly_unity02}).

\begin{figure}[htb]
  \centering
  \includegraphics[scale=0.4]{figs/fly_unity01.eps}\\
  \caption{Fly tool on Unity3D.}
  \label{fig:fly_unity01}
\end{figure}

\begin{figure}[htb]
  \centering
  \includegraphics[scale=0.4]{figs/fly_unity02.eps}\\
  \caption{Fly tool on Unity3D.}
  \label{fig:fly_unity02}
\end{figure}

% 
% 
% A situacao nao ocorre no trabalho apresentado por \cite{art_prin}, uma vez que os parametros de 
% estereo sao constantemente ajustados e, dessa forma, a cena sempre esta na 
% regiao de paralax positiva.
% poderia acarretar  Apos esse momento, podem haver casos em que alguns objetos entrem na 
% regiao de paralax negativa. Isso 
% 
%  
% 

%  e que, portanto, n�o 
% necessariamente est� localizado na regi�o para a qual a camera esta apontanto.
% 
% O uso de minDist traz algumas vantagens em rela��o ao uso de outros tipos de estimativas. 
% 
% 
% 
% 
% Isso dará fundamentação 
% para o que está sendo feito. Com relação ao fato de o ponto mais próximo ser global e 
% não somente da face inteira, nós podemos dizer que isso garante a segurança de que os 
% parâmentros de estereo sempre estarão corretos mesmo que o usuário vire bruscamente a 
% camera. Seria algo similar a usar um fov maior para identificar os objetos que podem 
% aparecer. Usando o min global, nos sempre garantimos que não havera quebra do stereo 
% pelo fato de um objeto aparecer devido a uma rotacao da camera. Ainda, como a 
% velocidade da camera é ajustada automaticamente atraves de minDist, isso produz um 
% movimento suave na camera, evitanto pulos (Essa e a motivacao de se colocar uma secao 
% falando sobre o ajuste dinamico de velocidade).
% 
% 
% 
%  Isso garante também uma curva suave de minDist, 
% o que por sua vez garante um ajuste suave dos parametros de stereo. Por ultimo, nos 
% so ajustaremos os parametros de estereo no momento em que os planos de corte forem também 
% ajustados. Isso garante que os planos de corte não sejam continuamente ajustudados a todo 
% quadro, o que seria ruim uma vez que (Dynamic Adjustment of Stereo Display Parameters) mostrou 
% que esses parametros nao podem ser ajustados em uma frequencia muito alta. Procedendo dessa forma, 
% ainda assim ha chance de um objeto no stereo negativo ser clipado pelos lados da tela. Nos 
% iremos dizer que isso e um problema menor, uma vez que nossas aplicacoes rodam em ambientes 
% imersivos como cave ou telas muito grandes. Nesse tipo de ambiente, as laterais da tela estao quase
% sempre fora do campo de visao do usuario e, portanto, um objeto em stereo negativo ser clipado nao 
% tem tanta importancia. 0
% 
% 
%  Por ultimo, falar que 
% o tratamento de colisão impede que os objetos sejam atravessados, garantindo assim o stereo 
% correto.

\subsection{Stereo Adjustment for Examine}

%A ferramenta examine basea-se em rota��es em torno de um ponto (pivo), ou seja, ela permite inspecionar um objeto de diferentes pontos de vista. Os autores acreditam que para este fim seria necess�rio indicar explicitamente um objeto e, desta forma, ficaria mais direto adaptar os parametros da estereoscopia atrav�s dos atributos como posi��o a caixa envolvente do objeto escolhido.

%Nesta abordagem optamos por posicionar o plano da paralaxe zero no centro do objeto. Isto cria um efeito onde metade dele est� para dentro da tela e a outra para o lado de fora. Al�m disso, a distancia dos olhos � determinada assumindo uma constante vezes o valor da caixa envolvente do objeto escolhido. Para nossos testes utilizamos o valor de 0.18 para constante.

%Na figura \ref{fig:examine_environ} est�o algumas imagens retiradas do software Environ aonde foi implementada esta abordagem. Um representa��o do cone de vis�o foi criada dentro do cen�rio 3D, e esta representa��o � escalonada de acordo com o objeto escolhido durante a intera��o. Juntamente com este ajuste de escala h� o posicionamento do plano da paralaxe. O uso de uma interpola��o linear suaviza a transi��o dos parametros de estereoscopia de um objeto escolhido para outro. Isto se mostrou ness�rio dado aos diferentes tamanhos dos objetos dentro do cenario.


The examine tool is based on rotating around a target object, 
an object in which one is interested in visually inspecting. 
The authors of this work believe that for this it is necessary 
to explicitly indicate an object, which makes it easier to adapt 
the stereoscopy parameters using object attributes such as 
position and bounding box.

In this approach we decided to position the zero parallax plane 
on the object's center. This creates an effect where half of 
it is coming out of the screen and half is going into it. Besides 
that, the interaxial eye distance is determined assuming a 
certain constant multiplied by the chosen object's bounding 
box. For our tests we used a value of 0,18 for the constant.

In figure \ref{fig:examine_environ} are some images taken from 
Environ software \cite{environ} where this approach has been implemented. A 
representation of the viewing cone has been created inside the 
3D scenario, and this representation is scaled according to the 
chosen object. Along with this scale adjustment there is the 
repositioning of the parallax plane. The use of a linear 
interpolation softens the transition of the stereoscopy parameters 
from one chosen object to another. This was proven necessary due to 
the different size of objects in the same scene.


\begin{figure}[htb]
  \centering
  \includegraphics[scale=0.45]{figs/examine_environ.eps}\\
  \caption{Examine tool on Environ.}
  \label{fig:examine_environ}
\end{figure}

\section{Conclusion} \label{sec:conclusion}

% Desenvolver aplica��es com suporte a estereoscopia requer cuidados importantes, 
% pois sem eles problemas fisiol�gicos como nauseas e dores de cabe�a podem surgir 
% nos usu�rios. Dependendo do conteudo 3D que ser� exibido, faz-se necessario um 
% ajuste dinamico dos parametros da estereoscopia para que a visualiza��o fique 
% confortavel em todos os espa�os do cen�rio 3D, por exemplo, nos ambientes 
% multi-escalas.
% 
% Este trabalhou apresentou algumas abordagens de ajuste da estereoscopia em duas 
% ferramentas utilizadas em aplica��es de realidade virtual: fly e examine. As 
% duas comtemplam respectivamente as tarefas de navega��o e manipula��o 3D. Para 
% a ferramenta fly foi utilizada uma estrutura CubeMap para para ajustar 
% automaticamente os parametros da estereoscopia dinamicamente. Basicamente, a 
% estrutura fornecia uma distancia minima global a camera do usu�rio, e esta 
% distancia era utilizada como base para posicionar o plano da paralaxe zero 
% assim como a distancia entre os olhos. Esta abordagem foi implementada em um 
% software chamado Siviep e em uma aplica��o desenvolvida utilizando o framework 
% Unity3D.
% 
% Para ferramenta examine, descrevemos como obter uma escala confortavel para 
% expandir a distancia entre os olhos e a distancia da paralaxe zero. Foi 
% assumido neste caso que o usu�rio deveria escolher um objeto, a partir deste 
% dado, utlizando o tamanho da bounding box e como valor de referencia � 
% determinado a distancia entre os olhos, e para finalizar o objeto escolhido e 
% posicionado no plano da paralaxe zero. 

Development of applications with stereoscopy support requires important care, or else
physiological problems may be caused to the users such as nausea and headaches.
Depending on the 3D content that will be shown, dynamic adjustment of stereoscopy
parameters may be necessary so that the visualization remains comfortable in all
points of the 3D scene, for example, in multi-scale environments.

This work presented some approaches of stereoscopy adjustment in two tools used
in virtual reality applications: fly and examine. Both respectively contemplate
the navigation and 3D manipulation tasks. For the fly tool a CubeMap structure was
used to automatically adjust the stereoscopy parameters. Basically, the structure
supplied a global minimum distance for the user's camera, and this distance is used
as basis to position the zero parallax plane, and likewise the eye distance. This
approach was implemented in an application developed
using Unity3D.

For the examine tool we described how to obtain a comfortable scale to expand the
eye distance and zero parallax distance. It was assumed, in this case, that the user
would choose an object and then, based on that, the bounding box size was used as
reference to determine the eye distance. Finally the zero parallax plane is placed
in the same position as the chosen object.

We believe that our approach produces a comfortable stereo effect and helps users in the 
sense that they do not need to configure the parameters. In our primary tests we found that
the graphical results were well received by users. As future work, we are planning to conduct
more accurate usability tests to evaluate our solution.

\section*{Acknowledgements}

Tecgraf is a laboratory mainly supported by Petrobras. Alberto Raposo receives an individual grant by FAPERJ.


% An example of a floating figure using the graphicx package.
% Note that \label must occur AFTER (or within) \caption.
% For figures, \caption should occur after the \includegraphics.
% Note that IEEEtran v1.7 and later has special internal code that
% is designed to preserve the operation of \label within \caption
% even when the captionsoff option is in effect. However, because
% of issues like this, it may be the safest practice to put all your
% \label just after \caption rather than within \caption{}.
%
% Reminder: the "draftcls" or "draftclsnofoot", not "draft", class
% option should be used if it is desired that the figures are to be
% displayed while in draft mode.
%
%\begin{figure}[!t]
%\centering
%\includegraphics[width=2.5in]{myfigure}
% where an .eps filename suffix will be assumed under latex, 
% and a .pdf suffix will be assumed for pdflatex; or what has been declared
% via \DeclareGraphicsExtensions.
%\caption{Simulation Results}
%\label{fig_sim}
%\end{figure}

% Note that IEEE typically puts floats only at the top, even when this
% results in a large percentage of a column being occupied by floats.


% An example of a double column floating figure using two subfigures.
% (The subfig.sty package must be loaded for this to work.)
% The subfigure \label commands are set within each subfloat command, the
% \label for the overall figure must come after \caption.
% \hfil must be used as a separator to get equal spacing.
% The subfigure.sty package works much the same way, except \subfigure is
% used instead of \subfloat.
%
%\begin{figure*}[!t]
%\centerline{\subfloat[Case I]\includegraphics[width=2.5in]{subfigcase1}%
%\label{fig_first_case}}
%\hfil
%\subfloat[Case II]{\includegraphics[width=2.5in]{subfigcase2}%
%\label{fig_second_case}}}
%\caption{Simulation results}
%\label{fig_sim}
%\end{figure*}
%
% Note that often IEEE papers with subfigures do not employ subfigure
% captions (using the optional argument to \subfloat), but instead will
% reference/describe all of them (a), (b), etc., within the main caption.


% An example of a floating table. Note that, for IEEE style tables, the 
% \caption command should come BEFORE the table. Table text will default to
% \footnotesize as IEEE normally uses this smaller font for tables.
% The \label must come after \caption as always.
%
%\begin{table}[!t]
%% increase table row spacing, adjust to taste
%\renewcommand{\arraystretch}{1.3}
% if using array.sty, it might be a good idea to tweak the value of
% \extrarowheight as needed to properly center the text within the cells
%\caption{An Example of a Table}
%\label{table_example}
%\centering
%% Some packages, such as MDW tools, offer better commands for making tables
%% than the plain LaTeX2e tabular which is used here.
%\begin{tabular}{|c||c|}
%\hline
%One & Two\\
%\hline
%Three & Four\\
%\hline
%\end{tabular}
%\end{table}


% Note that IEEE does not put floats in the very first column - or typically
% anywhere on the first page for that matter. Also, in-text middle ("here")
% positioning is not used. Most IEEE journals/conferences use top floats
% exclusively. Note that, LaTeX2e, unlike IEEE journals/conferences, places
% footnotes above bottom floats. This can be corrected via the \fnbelowfloat
% command of the stfloats package.

% conference papers do not normally have an appendix


% use section* for acknowledgement
% \section*{Acknowledgment}
% 
% 
% The authors would like to thank...
% more thanks here


% trigger a \newpage just before the given reference
% number - used to balance the columns on the last page
% adjust value as needed - may need to be readjusted if
% the document is modified later
%\IEEEtriggeratref{8}
% The "triggered" command can be changed if desired:
%\IEEEtriggercmd{\enlargethispage{-5in}}

% references section

% can use a bibliography generated by BibTeX as a .bbl file
% BibTeX documentation can be easily obtained at:
% http://www.ctan.org/tex-archive/biblio/bibtex/contrib/doc/
% The IEEEtran BibTeX style support page is at:
% http://www.michaelshell.org/tex/ieeetran/bibtex/
%\bibliographystyle{IEEEtran}
% argument is your BibTeX string definitions and bibliography database(s)
%\bibliography{IEEEabrv,../bib/paper}
%
% <OR> manually copy in the resultant .bbl file
% set second argument of \begin to the number of references
% (used to reserve space for the reference number labels box)

\bibliographystyle{IEEEtran}
\bibliography{IEEEabrv,svr2011}


%\begin{thebibliography}{1}

%\bibitem{IEEEhowto:kopka}
%H.~Kopka and P.~W. Daly, \emph{A Guide to \LaTeX}, 3rd~ed.\hskip 1em plus
%  0.5em minus 0.4em\relax Harlow, England: Addison-Wesley, 1999.

%\end{thebibliography}




% that's all folks
\end{document}


