%%%%%%%%%%%%%%%%%%%%%%% file template.tex %%%%%%%%%%%%%%%%%%%%%%%%%
%
% This is a general template file for the LaTeX package SVJour3
% for Springer journals.          Springer Heidelberg 2010/09/16
%
% Copy it to a new file with a new name and use it as the basis
% for your article. Delete % signs as needed.
%
% This template includes a few options for different layouts and
% content for various journals. Please consult a previous issue of
% your journal as needed.
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% First comes an example EPS file -- just ignore it and
% proceed on the \documentclass line
% your LaTeX will extract the file if required
% \begin{filecontents*}{example.eps}
% %!PS-Adobe-3.0 EPSF-3.0
% %%BoundingBox: 19 19 221 221
% %%CreationDate: Mon Sep 29 1997
% %%Creator: programmed by hand (JK)
% %%EndComments
% gsave
% newpath
%   20 20 moveto
%   20 220 lineto
%   220 220 lineto
%   220 20 lineto
% closepath
% 2 setlinewidth
% gsave
%   .4 setgray fill
% grestore
% stroke
% grestore
% \end{filecontents*}
%
\RequirePackage{fix-cm}
%
% \documentclass{svjour3}                     % onecolumn (standard format)
% \documentclass[smallcondensed]{svjour3}     % onecolumn (ditto)
\documentclass[smallextended]{svjour3}       % onecolumn (second format)
%\documentclass[twocolumn]{svjour3}          % twocolumn
%
\smartqed  % flush right qed marks, e.g. at end of proof
%
\usepackage[lofdepth,lotdepth]{subfig}
\usepackage{graphicx}
%
\usepackage{mathptmx}      % use Times fonts if available on your TeX system
%
% insert here the call for the packages your document requires
\usepackage{latexsym}
\usepackage{amsmath}
\usepackage{pstricks,pst-plot,pst-node,pst-tree}
\usepackage[numbers,sort]{natbib}
% etc.
%
% please place your own definitions here and don't use \def but
% \newcommand{}{}
%
% Insert the name of "your journal" with
% \journalname{myjournal}
%
\begin{document}

\title{Improving 3D Navigation Techniques in Multiscale Environments: A Cubemap-based Approach%\thanks{Grants or other notes
%about the article that should go on the front page should be
%placed here. General acknowledgments should be placed at the end of the article.}
}
\subtitle{}

%\titlerunning{Short form of title}        % if too long for running head

\author{Daniel R. Trindade         \and
        Alberto B. Raposo %etc.
}

%\authorrunning{Short form of author list} % if too long for running head

\institute{Daniel R. Trindade \at
              Tecgraf / Department of Informatics \\
	      Pontifical Catholic University of Rio de Janeiro \\
              Tel.: +55-21-3527-1510\\
              Fax: +55-21-3527-1530\\
              \email{danielrt@tecgraf.puc-rio.br}           %  \\
%             \emph{Present address:} of F. Author  %  if needed
           \and
           Alberto B. Raposo \at
              Tecgraf / Department of Informatics \\
	      Pontifical Catholic University of Rio de Janeiro \\
              Tel.: +55-21-3527-1510\\
              Fax: +55-21-3527-1530\\
	      \email{abraposo@tecgraf.puc-rio.br}
}

\date{Received: date / Accepted: date}
% The correct dates will be entered by the editor


\maketitle

\begin{abstract}
Navigation in virtual 3D environments, especially those with multiscale
features, is still a problem for many users. In this regard, a good design of
the navigation interfaces is critical to ensure that the users navigate with the
best possible efficiency and comfort. In this paper, we present improvements
for two well-known interfaces: \emph{fly}, including support to collision
treatment and automatic navigation speed adjustment in relation to scale, and
\emph{examine}, with automatic pivot point. Such techniques are based on the
\emph{cubemap} structure, which provides information about the surrounding environment
at each instant. Usability tests with both beginner and advanced users revealed that the proposed
techniques created a significant improvement in the execution of navigation tasks and a
reduction in navigation errors.
\keywords{Navigation \and Multiscale environments \and Cubemap \and Interaction techniques}
% \PACS{PACS code1 \and PACS code2 \and more}
% \subclass{MSC code1 \and MSC code2 \and more}
\end{abstract}

\section{Introduction}
With the development of new technologies and the increasing processing power of
computers, larger and more detailed 3D virtual environments are
becoming more common. Accordingly, several
navigation tools were created to help users to explore these environments. However, despite the efforts of
researchers, navigation in virtual environments is still problematic for many
people.

%%%%% comentado em 28/10/10
% What in the real world is a natural procedure can lead
% to frustration in virtual ones.

There are a number of reasons for this. 
For example, when using a navigation tool, difficulty can arise from either a 
users' lack of knowledge about the tools' usage or function, or poor design
of the tool itself \cite{fitz08}. Another frequent problem is related to the type of
environment being explored. Multiscale virtual environments \cite{perlin93}, for
instance, often require methods to allow the users to navigate through the
different scales of the environment. Multiscale environments provide information 
in different levels of detail, ranging from a single screw to an oil field 
spanning dozens of miles.

Our goal is to propose techniques that help users, especially novice ones, navigate through multiscale
environments. The solutions proposed should satisfy two main
requirements: a) maximum automation, therefore demanding minimal intervention
by the user, and b) independence from the type of model being viewed, so
that new types of objects can be viewed in the future without the need to
develop new solutions. Moreover, the solutions are intended to work on desktop 
setups, using mouse and keyboard, as this setup is more common to most users 
\cite{santos09}.
%%% citacao sac

In this paper, we improve on two well known navigation
techniques. In the case of the \emph{fly} technique, we added collision support
and automatic speed adjustment in relation to the scale; in the
\emph{examine} technique we added a way to automatically determine the pivot
point. 
%%%%%%%%% comentado em 28/10/10 
% What these techniques have in common is that they are based on a
% structure called \emph{cubemap}, which has the purpose of creating an
% image-based representation of the environment in relation to the observer's
% position \cite{maccrae09}.

This paper is organized as follows. In Section 2 we present related work. The
cubemap concept is presented in Section 3. In Section 4, the navigation
techniques are described, and in Section 5 the results of usability
tests are presented. Section 6 concludes this article.

\section{Related Work}

Navigation in virtual environments has been studied by many
researchers. The main goal of most of these studies is to propose and analyze
techniques that facilitate the task of exploring such environments. As an
example, Ware and Osborne \cite{ware90} proposed three different navigation tools: \emph{eyeball
in hand}, \emph{scene in hand}, and \emph{flying vehicle control}. They
concluded that none of these three techniques by thenselves are able to fulfill all
user needs. The same conclusion was reached by Fitzmaurice et al. \cite{fitz08}, who analyzed the
behavior of some users of 3D applications and introduced techniques to
improve the interface of some tools.  Also seeking to propose new interaction
solutions, Mackinlay et al. \cite{mack90} introduced the \emph{point of interest (POI)}
technique, in which the user must first choose a destination point and then the
camera starts to move toward the chosen point, changing its speed in relation to
the remaining distance. Tan et al. \cite{desney01} proposed a hybrid solution in which the
\emph{fly} and \emph{examine} tools are combined into a single interaction
technique.

\emph{Multiscale environments} were first introduced in the literature by Perlin and Fox 
\cite{perlin93} and Bederson et al.\cite{bederson94_a}, through the creation of
the \emph{Pad} and \emph{Pad++} interfaces. These developments have been the focus of
many researchers \cite{zhang09,furnas95,furnas98}. To give users a sense of
scale of the environment, Glueck et al. \cite{Glueck09} provides a grid
reference. This is modified consistently with the camera position: as the camera
gets closer, the grid is subdivided in more pieces. As the scale of the grid is
known, it is possible to identify the scale of the objects by comparing these
with the grid. Besides the grid reference, they also provides position pegs,
which consist in projecting the object on the grid. Through the size of this
projection and a connection between this and the grid, it is possible to
identify the relative distance of objects. Although they provide information
that helps in identifying the scale, that is not used to modify parameters
related to navigation. Kopper et al. \cite{kopper06} 
presented a system
that allows the user to navigate through the different scales of an environment.
The hierarchy of the scene models is used to define the \emph{levels of scale}.
However, with this approach the user is forced to issue a command to change 
between scales. Moreover, the adjustment of navigation parameters is only made at 
 time of the command. Thus, one can say that the method proposed by Kopper et al. \cite{kopper06} 
is discrete in the sense that the different scale levels are
well defined regarding their form and their location in the hierarchy of the
scene. By contrast, the works presented by Ware and Fleet \cite{ware97} and 
McCrae et al.\cite{maccrae09} make continuous adjustments to the navigation 
parameters. Therefore the virtual
environments do not require a well defined hierarchy of levels of scale.
Ware and Fleet \cite{ware97} proposed adjusting the navigation speed of the \emph{fly} tool by
using the depth information present in the \emph{Z buffer}. To this effect, they
use the smallest value resulting from scanning 15 lines of the \emph{Z buffer}.
McCrae et al. \cite{maccrae09} constructed a representation of the environment called
\emph{cubemap}, which provides information that allows the adjustment of
parameters such as speed and clipping planes, as well as offering collision
support.

To deal with collisions, Baciu et al. \cite{baciu97,baciu98} presented image space based
techniques which consist of projecting the geometry onto an image using graphics
hardware and then checking for interference, usually by analyzing the \emph{Z
buffer}. Calomeni and Celes \cite{calomeni06} proposed the construction of 
a connectivity graph in
preprocessing time. Through this graph, they are able to move the camera in
order to avoid collisions with the environment. This concept was also explored
by Xiao and Hubbold \cite{xiao98}, who used force fields rather than a connectivity graph.
Nonetheless, a preprocessing stage is still required to compute the fields.
McCrae et al. \cite{maccrae09} proposed using a new structure, which they call a \emph{cubemap},
to help construct the force map with higher resolution while eliminating the
preprocessing stage altogether.

% Alguns do problemas relacionados �  determinação do ponto de pivot foram
% identificados por Fitzmaurice et al. \cite{fitz08}. Em seus estudos, o ponto de
% pivot é escolhido manualmente pelo usuário através de uma opção de menu. O ponto
% de pivot é pintado na tela, o que permite, segundo os autores, que os usuários
% tenham uma compreensão melhor do comportamento da ferramenta \emph{examine}.
% Khan et al. \cite{Khan05} desenvolveram a ferramenta de inspeção HoverCam.
% Quando longe do objeto inspecionado, essa ferramenta funciona como o
% \emph{examine}. Quando próxima, ela faz com que a câmera tenha o comportamento
% da ferramenta pan, movendo-se paralela a face do objeto. Isso é feito através da
% atualização contínua do ponto de pivot para o ponto mais próximo da cena. Dessa
% forma, diferente de Fitzmaurice et al. \cite{fitz08}, a escolha do ponto de
% pivot é automática. Ao iniciar o uso do HoverCam, a câmera é reorientada em
% direção o local onde está o ponto mais próximo. Essa escolha, entretanto pode
% entrar em conflito com a intenção do usuário. Por exemplo, em uma cena que
% contenha vários objetos próximos, a câmera pode ser reorientada para um objeto
% que estava a seu lado, fora do seu angulo de visão (pois esse se encontra mais
% próximo), quando na verdade a intenção do usuário era inspecionar outro objeto
% que, apesar de mais longe, já estava em seu ângulo de visão. Além disso, em sua
% primeira versão o HoverCam precisava de que uma estrutura de sphere-tree fosse
% precomputada para a cena, afim de se poder determinar qual o ponto mais próximo
% da câmera. Isso foi resolvido em uma segunda versão, quando McCrae et al.
% \cite{maccrae09} reimplementaram o HoverCam usando o \emph{cubemap} para
% determinar o ponto mais próximo.

Some of the problems related to the pivot point were identified by Fitzmaurice
et al. \cite{fitz08} . In their work, the pivot point is chosen manually by
the user via a menu option. The pivot point is also drawn on the screen, which
allows, according to the authors, the users to have a better understanding of
the behavior of the \emph{examine} tool. To inspect objects, they
use
a widget called \emph{ViewCube} \cite{Khan08}. This is a cube drawn on the corner
of the screen and the object is rotated by means of this cube. 
Khan et al. \cite{Khan05} developed
a new tool for object inspection called \emph{hovercam}. When far from the
object, this tool works like an \emph{examine}. When close, it has the behavior
of a pan operation, making the camera to move parallel to the faces of the
object. This is done by continuous updating the pivot point to the nearest
point of the scene. Unlike Fitzmaurice et al. \cite{fitz08}, the choice of
the pivot is automatic on \emph{hovercam}. When the use of hovercam begins, the
camera is reoriented toward the location of the nearest point. However, this may
conflict with the user intent of inspecting a specific object. For example, in a
scene containing several objects, the camera could be reoriented to an object
wich is not being visualized (because it is the closest one), when in fact the
user's intent was to inspect another object that, although further, was in its
angle of vision. Moreover, their first implemented of hovercam required the
pre-computation of a sphere-tree structure in order to determine the closest
point. This was resolved in a second version, when McCrae et al.
\cite{maccrae09} reimplemented the tool using the cubemap determine the
closest point.

The techniques introduced in the present paper are also based on the cubemap.
However, the approach taken to construct the cubemap and the navigation
techniques based on it had to be modified in order to fulfill the requirements
of our applications, as will be described in the following sections.

\section{The Cubemap}

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. This 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
estimate needs to be obtained.

The cubemap construction process we implemented differs from the one described
by McCrae et al. \cite{maccrae09} in two aspects: the orientation of the cubemap is the
same as that of the camera (McCrae et al. always used canonical directions);
and the \emph{RGB} channels of the images in the cubemap store a unit vector
pointing from the position of the generated fragment to the camera. The first
change was necessary to simplify the process of obtaining the distance from the viewer
to the center of the screen, which will be important for the automatic speed
adjustment techniques of \emph{fly} (Section 4.1) and for the automatic
definition of the pivot point in \emph{examine} (Section 4.3). The second change
simplifies the construction of the force map to detect collisions (Section 4.2).

\section{Navigation Techniques}

In this section we will present the three improved navigation techniques.

\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 for 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 this equation:

\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 extremes.

In face of the difficulty in determining a value for $k$ that suited all users,
we decided to let the users define it manually, using the scroll button of the
mouse. However, this led to other problems. When navigating very close to an
object, some users increased the $k$ value to move faster but forgot to readjust
it when the camera was distant from the geometry, falling into a situation where
$k$ is too high.

These examples revealed the disadvantage of using only $minDist$ as an
estimation to adjust the speed; when $minDist$ is too low, it works as a break
even when the user wishes to move faster. For instance, when navigating through
a corridor, the user may experience slow navigation due to the closeness of the
walls. %Similarly, a tangential approximation to any object causes the same
%effect. 
Thus, it is convenient to use some other type of estimation.

With that goal in mind, we attempted to use the distance to the central point of
the screen. This seemed reasonable since this point represents momentarily
the location the user wants to reach. Therefore, navigation speed started to be
adjusted using $centerDist$, the distance from the camera to the center of the
screen, rather than $minDist$.

However, the use of $centerDist$ resulted in a strange behavior. The motion of
the camera started to present peaks of speed, giving the
impression that it stopped or accelerated instantly. The reason for this can be
understood by observing the graph in Figure \ref{fig:minCenterCurve}. This graph
shows the behavior of the curves of the $minDist$ and $centerDist$ estimations
for one path followed by the camera in a time interval of around 6 seconds.

\begin{figure}[!h]
\centering
\input{minCenterCurve}
\caption{Graph representing the behavior of the $minDist$ and $centerDist$
curves.}
\label{fig:minCenterCurve}
\end{figure}

It can be seen that the $minDist$ curve is smooth while the $centerDist$
curve is noisier, displaying some peak values that are completely inconsistent
with the general behavior of the curve. This is related to the freedom the
\emph{fly} tool gives to the user, who can turn the camera to any direction at
any time. At a given moment, the central point of the screen may fall on an
object that is distant from the camera. The user then can turn the camera almost
instantly toward a close-by object, leading the value of $centerDist$ to drop
abruptly.  This is reflected in the speed adjustment, creating a steep 
deceleration. The opposite is also a problem. If, for example, the camera is
inside an object and the user unwillingly points the camera toward an external
point, the camera will be subject to a fast acceleration and will be thrown outside the
object. These effects do not happen when $minDist$ is used as estimation because
it is independent from the orientation of the camera.

To avoid the situations caused by the peak values of the $centerDist$ curve, we
applied an \emph{exponential moving average (EMA)}:

\begin{equation}\label{eq:mme}
 EMA_{i} = EMA_{i-1} + A \ ( centerDist_{i} - EMA_{i-1} )  
\end{equation}

In equation \ref{eq:mme}, $EMA_{i}$ is the smoothed value of $centerDist_{i}$ at
instant $i$, $EMA_{i-1}$ is the value smoothed at instant $i-1$, and $A$ is a
constant that influences how smooth the new curve will be and how quickly this
curve will converge to the $centerDist$ values. The smaller $A$ is, the smoother
the curve will be and the higher the time needed for such convergence to take
place. The maximum value of $A = 1$ is equivalent to the original curve. Figure
\ref{fig:mme} shows the results of smoothing an interval of the $centerDist$
curve (represented by the darker line) for three different values of $A$.

\begin{figure}[!h]
\centering
\input{mme}
\caption{Effect of applying the EMA to a curve.}
\label{fig:mme}
\end{figure}

By smoothing the $centerDist$ curve, we can use it to adjust the speed. 

But one last problem remained: when the camera is near to an object but 
points to a distant place, the navigation speed tends to quickly increase,
since $centerDist$ is far. This can lead to undesirable
situations, such as when the camera is inside an object and the user wants to 
view its exterior. In this case, the user needs to go outside of the object and
then point the camera toward the object again. When leaving the object, the
camera might point to a distant location for a period of time long
enough to increase the speed too much. As a result, the camera could move away
from the object before the user is able to adjust the movement. This is because
the scale perception provided by $minDist$ is no longer present. In such cases,
$minDist$ acts as a break, preventing the camera from moving far away too
quickly.

To address this final issue, values of $centerDist$ higher than $n~\times~minDist$ were discarded. 
This way, $minDist$ serves as a criterion to decide when a $centerDist$ value should or not be
considered inconsistent. We found that $n = 10$ worked well on ours tests.

This solution reflects a hybrid use of the $minDist$ and $centerDist$
estimations: while $centerDist$ ensures that speed adjustment is closer to what
the user intends, $minDist$ acts as a break in cases where the speed would be too
high. The result is increased comfort for the user when using this tool, as demonstrated by the usability tests.

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

Preventing the camera from cutting through objects in a virtual environment can
be crucial in some situations \cite{rocha08}. In immersive environments, for example, colliding
with an object can halt the immersion and leave the user disoriented. Another
problem occurs when a visualization involves a stereoscopy effect; in this case, a
collision with an object in the scene can cause physical discomfort to the
user's eyes.

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 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 avoided the objects in
its path. The behavior obtained is similar to the assisted navigation described
previously \cite{xiao98,calomeni06}, whereby the user can navigate through the
environment without worrying about choosing a collision-free path as the
system is in charge of this task. It is a different approach from that used
by McCrae et al. \cite{maccrae09}, who employed $F_{collision}$ combined with the POI technique,
a more restrictive solution which does not give the user total control over
the camera when navigation is being performed.

\subsection{Examine with Automatic Pivot Point}

The \emph{examine} tool allows any object or location in the scene to be
inspected. Basically, its function corresponds to rotating the camera around
a point, called the \emph{pivot point}. In our test application, drag movements
using the left mouse button made the camera rotate around the pivot  point,
which can be chosen by the user. Dragging vertically or horizontally with the
right mouse button caused the camera to zoom in or zoom out, respectively. When
the scroll mouse button is present, it can also be used for zoom operations. In
our implementation collision detection and treatment is not taken into account
when using the \emph{examine} tool, since it would prevent certain forms of
inspection to be performed. For example, zoom out operations can be used to
change the level of scale in which the camera is. If collision treatment is 
present, the camera can get stuck due to a surface located behind it.

The location of the pivot point is crucial for the proper functioning of the
\emph{examine} tool. If it is not specified correctly, the camera can display
behaviors which, from the user's point of view, would seem confusing. Figure
\ref{fig:centro_rotacao} illustrates two of these cases.

\begin{figure}[htb]
  \centering
  \includegraphics[scale=0.5]{examine}\\
  \caption{Problems related to the pivot point: (i) pivot point located outside
the field of vision; (ii) pivot point mapped beyond the object.
}
  \label{fig:centro_rotacao}
\end{figure}

In case (i), the pivot point (referred to as \emph{pivot} in the image) is
located outside the user's field of vision, too distant from the object to be
inspected. When the \emph{examine} tool is used, a mathematically correct 
rotation (from camera position 1 to 2) is made around the pivot. For the user, 
however, this operation
leads to a completely unexpected motion. This problem is worse when the pivot is
located at a great distance from the model: the greater the distance, the higher
the angular speed of the camera and, as a consequence, the bigger the
error as perceived by the user. Informal observations showed that this situation
occurred rather often in our test application. In the case of (ii), the pivot is
within the viewing angle of the camera but is located outside the object of
interest. As seen in the image, $pivot$ is beyond the model, and the
rotation around it has the effect of a pan operation.

Analyzing these situations, it can be concluded that they are basically caused
by one reason: the pivot point is not located at a point that adequately corresponds to the 
object to be examined. %The correct functioning of the \emph{examine} tool depends 
%on not allowing this situation to happen, therefore it is important to identify 
%when it takes place.

Usually, 3D visualization applications that make use of the \emph{examine} tool
include a button (or any other interface item) that, when selected, allows a new
pivot point to be chosen. We observed that some people, even more
experienced users, at some point forgot to select an adequate pivot point before
starting to rotate around the object of interest.%This happens because, after a
%certain time using the application, users stop focusing on details of the
%interface and, naturally, transfer all of their attention to the virtual
%environment. 

This occurred especially frequently when some users switched from the
\emph{fly} to the \emph{examine} tool, as they attempted to rotate the camera
around the object located in front of them before readjusting the pivot point.
And, even when the users did not forget to perform this last operation, they
reported feeling upset with the fact that they had to do it explicitly.

The solution we found for this was to automatically determine a pivot point at
the moment the \emph{examine} tool is activated. As mentioned before, the
solution proposed by Khan et al. of doing this by setting the pivot point to
$minDist$ and reorienting the camera could conflict with the user intent. We 
propose to use the point corresponding to the center of the screen as the new
$pivot$. Doing this, it is possible to establish a behavior that seems natural
from the user's point of view. There is no reorientation of the camera and all
the user needs to do is point the camera to the object of interest and then
select the \emph{examine} tool. It is reasonable to expect this feature, as in
most cases the users only decide to inspect an object once it is in front of
them. However, the object might not necessarily be located exactly in the
direction of the center of the screen; in fact, the pivot point could be mapped
to an object behind the one the user wishes to examine. In this case, the user
would experience the effect of a pan operation, as shown in (ii) in Figure
\ref{fig:centro_rotacao}. Another possibility is that the central point of the
screen does not correspond to any valid point in the geometry, and thus
determining $pivot$ is impossible. 

To avoid these problems, the smallest distance present on the front face of the
distance cube, $minFront$, is used. When the central point is not valid, $pivot$
is adjusted to the point that is $minFront$ away from the camera. This way, the
angular speed of the rotation of the \emph{examine} tool will be coherent with
the scale in which the camera is located, preventing it from making excessively
quick movements.

The $minFront$ estimation is also used when the pivot point is automatic mapped
to a distant point located behind the object. This may occurs when the object to
be inspected is not located exactly in the center, but this contains valid
geometry that is far away from the object of interesting. If the pivot point is
mapped to this point, the situation presented on (ii) in Figure
\ref{fig:centro_rotacao} should happen. To avoid this, we do not allow $pivot$
to be adjusted to a point whose distance is greater than $k \times minFront$.
We found that $k = 5$ worked well on our tests. This solution does not solve the
problem definitively, but reduces its occurence adequately.

\section{User Tests}

The techniques presented in the previous section attempt to assist 
the users in the task of exploring virtual environments. From the
user's point of view, this should result in a more comfortable navigation
experience and fewer errors.

To verify this, usability tests were carried out with groups of users in order to  
gather information about the solutions developed. 
These tests were planned and conducted based on the orientations provided by 
T. Tullis and W. Albert \cite{tullis08}, and were divided in two types, according with the procedures 
adopted and the information gathered:

\begin{itemize}
\item \emph{Qualitative Tests}: to collect feedback from users, such as 
how they felt while using the software, what bothered them, and what could be 
improved. The time was not taken into account and users had more freedom to 
explore the environment and make certain decisions.
\item \emph{Quantitative Tests}: to collect quantitative information  
on how users interact with the scene, like how often a collision occurs or how many times the 
user got disoriented. The time was tracked and users had to follow a 
pre-determined set of steps, without the freedom of changing them.
\end{itemize}

\subsection{Test Environment}

The tests were performed using the SiVIEP viewer, a project under development
by Tecgraf/PUC-Rio in cooperation with Petrobras (Brazilian Oil \& Gas Company). 
SiVIEP supports a comprehensive
visualization of several types of models comprising an oil exploration and
production enterprise. For example, it is possible to load enviroments ranging 
from oil platforms to wells and reservoirs in a single scene (Figure 
\ref{fig:cenario_teste}). The main characteristic of the virtual environments 
resulting from this integration is that they are multiscale.

\begin{figure*}[ht]
  \centering
  \includegraphics[width=11.5cm,height=3cm]{siviep1}
  \caption{SiVIEP: visualization of an oil enterprise. In the first image, a
complete oil field can be seen. Then the camera reaches the scale of a platform.
Finally, the interior of the platform can be navigated.}
  \label{fig:cenario_teste}
\end{figure*}

Two different versions of SiVIEP were used in the tests:

\begin{itemize}
 \item \emph{Automated}: this version supports the solutions discussed in the
preceding sections. The user does not have to worry about speed adjustment,
collisions are prevented automatically, and the explicit use of the pivot-point
tool is not necessary.
 \item \emph{Manual}: this version does not include any of the improved
techniques previously mentioned. The speed in the \emph{fly} tool must be
adjusted manually with the mouse scroll button, the user must be careful to
not collide with the models, and the pivot-point tool has to be used always
before beginning to inspect an object with the \emph{examine} tool.
\end{itemize}

The scenario used consisted of two oil extraction platforms, A and B, 
located at a certain distance apart from each other. The camera was initially 
placed in a position where both platforms could be seen (Figure 
\ref{fig:cenario_teste1}).

\begin{figure*}[ht]
  \centering
  \includegraphics[scale=0.35]{cenario_teste_user}
  \caption{Scenario used in the tests.}
  \label{fig:cenario_teste1}
\end{figure*}

\subsection{User Profiles}

Nineteen people were selected to carry out the tests. They were divided in two
groups: \emph{advanced users}, with experience in the use of 3D visualization
and 3D modeling applications who use this type of software at least once in a
month; and \emph{non-advanced users}, with little experience in 3D
visualization applications, except for some electronic games, and who do not use
3D visualization applications frequently.

From the 19 individuals, 7 were allocated in the first group (advanced users) 
and 12 in the second group (non-advanced users). 
All of them had the following characteristics in common: they were
between 20 and 35 years old and did not have any previous contact
with the application used in the tests. The individuals in the advanced group of 
users are herein called PA1 to PA7, while the test users in the
non-advanced group are identified as PN1 to PN12. Also, advanced users and 
non-advanced users from PN1 to PN5 performed only the qualitative tests, while users 
PN6 to PN12 performed the quantitative tests. All users were male, except one of 
the non-advanced group that performed the quantitative tests.

\subsection{Qualitative Tests}

\subsubsection{Procedures Adopted}

Each person was first asked to read and sign a consent agreement to confirm
their commitment to taking the test. They were then given an overview of
SiVIEP to introduce them to the application and its functions. The
test consisted of asking the subjects to use the two versions 
of SiVIEP.

Before each person started to use one of the versions, some instructions were
given about the functioning of the navigation tools in that version. In the
manual version, for instance, the users were asked to avoid crossing through the
models in the scene and instructed on how to make manual speed adjustments and
to operate the pivot-point tool. In the case of the automated version, the
users were informed that they did not have to worry about these aspects.

The users were asked to navigate to platform A using the \emph{fly} tool. Once
there, they had to explore the internal area of the platform to select three 
objects inspection with the \emph{examine} tool. Finally, the
users were asked to navigate from platform A to platform B.

After using each version, the users were asked to answer a questionnaire aimed at 
gathering their impressions about the tools used. This questionary
consisted of the following statements, here identified as S1, S2, S3, S4 and S5:

\begin{itemize}
 \item S1: \emph{I did not have any difficulty with the speed adjustment of the
fly tool.}
 \item S2: \emph{I was able to perform the tasks without colliding with the
environment.}
 \item S3: \emph{I did not have any difficulty with the pivot-point tool.}
 \item S4: \emph{I did not feel disoriented at any moment when navigating
in the virtual environment.}
 \item S5: \emph{I felt comfortable using the navigation tools.}
\end{itemize}

Below each of these statements there was a scale of ten numbers, from 1 to 10, 1
meaning that the user disagrees completely with the statement and 10 meaning
that the user fully agrees with it. At the end of the form there was a blank
space where the users could describe their general impressions and
justify the grades given.

After both versions had been tested, the users were asked to fill out a final
survey consisting of two written questions, identified as Q1 and Q2:

\begin{itemize}
 \item Q1: \emph{Which of the two approaches did you prefer: the automated
navigation techniques or the manual techniques? Why?}
 \item Q2: \emph{With regard to the approach you preferred, in your opinion
could something be improved? If affirmative, what is it and why would it need to
be improved?}
\end{itemize}

%Question Q1 was considered one of the most important in the test due to its
%conclusive nature. In this question, the person was encouraged to think about
%both versions and establish a mental comparison between the two experiences. 

Lastly, the order in which the versions were presented to each user was different 
from test to test. The first person to take the test used the manual version first, and then
the automated version second. The second took the test in the opposite order. This pattern
was followed until the last user. This measure was taken with the purpose of
minimizing the learning effect of using the first version over the second.

\subsubsection{Non-Advanced Group Results}

Tables \ref{tab:results3} and \ref{tab:results4} show the results obtained 
after testing the group of non-advanced users. They include
the responses to the 5 statements presented in the
previous section. Table \ref{tab:results3} provides the grades referring to the
use of the manual version, while Table \ref{tab:results4} contains the grades
given to the automated version. The final column in each table shows the average
grade for each statement. For a better view of the general results, these
averages are presented side by side in Figure \ref{fig:teste_usuario1}. The
confidence interval used in the generation of this graph was 90 \%.

\begin{table}[!htb]
\centering
\begin{tabular}[c]{|c|c c c c c|c|}
\hline
        & PN1  & PN2  & PN3  & PN4  & PN5  & Avg \\
\hline
 S1     &  7   &  8   &  10  &  9   &  5   &  7.8 \\
\hline
 S2     &  6   &  5   &  7   &  7   &  2   &  5.4 \\
\hline
 S3     &  6   &  9   &  8   &  7   &  3   &  6.6 \\
\hline
 S4     &  4   &  8   &  7   &  9   &  1   &  5.8 \\
\hline
 S5     &  5   &  8   &  9   &  10  &  4   &  7.2 \\
\hline
\end{tabular}
\caption{Results of the usability test for the manual version (group of
non-advanced users).}
\label{tab:results3}
\end{table}

\begin{table}[!htb]
\centering
\begin{tabular}[c]{|c|c c c c c|c|}
\hline
        &  PN1 &  PN2 &  PN3 &  PN4 &  PN5 &  Avg \\
\hline
 S1     &  9   &  10  &  10  &  10  &  9   &  9.6 \\
\hline
 S2     &  10  &  10  &  10  &  10  &  10  &  10.0  \\
\hline
 S3     &  10  &  8   &  10  &  10  &  10  &  9.6 \\
\hline
 S4     &  10  &  10  &  9   &  10  &  10  &  9.8 \\
\hline
 S5     &  10  &  9   &  10  &  10  &  10  &  9.8 \\
\hline
\end{tabular}
\caption{Results of the usability test for the automated version (group of
non-advanced users).}
\label{tab:results4}
\end{table}

\begin{figure}[htb!]
  \centering
  \includegraphics[scale=0.4]{teste_usuario_iniciante}
  \caption{Comparative results between the manual and the automated version
(group of non-advanced users.)}
  \label{fig:teste_usuario1}
\end{figure}

We applied a two-tailed paired t-test to compare the average of the results for
both versions. We obtained $t(4) = -6.43, p = 0.001$, which affirms
that this group preferred the automated version of the navigation. When using
the manual version, users complained especially about the difficulty of controlling 
camera speed in order not to collide with the environment. One of the users,
for instance, reported that ``the program is somewhat abrupt, which makes its
use difficult for someone who is not used to or does not have enough dexterity
for 3D games and software''. The lack of collision treatment created situations
in which some people felt lost. When these situations occurred, 2 of the 5 users
mentioned that they would like to quit the task.

The written answers confirm the statistic results. For question $Q1$,
all users
in this group replied that they preferred the automated version rather than the
manual one. In the justifications, most users mentioned that the techniques
provided by the automated version made navigation simpler, less prone to errors,
and easier to control. As for question $Q2$, none of these users considered that
any improvement was necessary to their preferred version.

\subsubsection{Advanced Group Results}

Tables \ref{tab:results5} and \ref{tab:results6} show the results obtained after
the application of the tests to the group of advanced users. The results are
presented in the same format as those in the previous section. Figure
\ref{fig:teste_usuario2} also shows a comparison between the grades given to the
manual version and those given to the automated version. The confidence interval
was 90 \%.

\begin{table}[!htb]
\centering
\begin{tabular}[c]{|c|c c c c c c c|c|}
\hline
             &  PA1 &  PA2 &  PA3 &  PA4 &  PA5 &  PA6 &  PA7 &  Avg \\
\hline
 S1          &  10  &  9   &  7   &  7   &  10  &  9   &  9   &  8.7 \\
\hline
 S2          &  3   &  7   &  7   &  7   &  10  &  8   &  7   &  7.0 \\
\hline
 S3          &  7   &  8   &  10  &  3   &  5   &  5   &  7   &  6.4 \\
\hline
 S4          &  3   &  9   &  6   &  5   &  10  &  6   &  8   &  6.7 \\
\hline
 S5          &  6   &  8   &  8   &  8   &  10  &  8   &  7   &  7.8 \\
\hline
\end{tabular}
\caption{Results of the usability test for the manual version (group of advanced
users).}
\label{tab:results5}
\end{table}

\begin{table}[!htb]
\centering
\begin{tabular}[c]{|c|c c c c c c c|c|}
\hline
             &  PA1 &  PA2 &  PA3 &  PA4 &  PA5 &  PA6 &  PA7 &  Avg \\
\hline
 S1          &  7   &  5   &  10  &  5   &  9   &  9   &  9   &  7.7 \\
\hline
 S2          &  10  &  9   &  9   &  10  &  10  &  9   &  10  &  9.6 \\
\hline
 S3          &  10  &  6   &  6   &  10  &  10  &  9   &  10  &  8.7 \\
\hline
 S4          &  6   &  9   &  7   &  10  &  10  &  8   &  9   &  8.4 \\
\hline
 S5          &  10  &  6   &  9   &  9   &  10  &  9   &  9   &  8.9 \\
\hline
\end{tabular}
\caption{Results of the usability test for the automated version (group of
advanced users).}
\label{tab:results6}
\end{table}

\begin{figure}[htb!]
  \centering
  \includegraphics[scale=0.4]{teste_usuario_avancados}\\
  \caption{Comparative results between the manual and the automated version
(group of advanced users.)}
  \label{fig:teste_usuario2}
\end{figure}

We applied a two-tailed paired t-test to compare the average of the results for
both versions. We obtained $t(4) = -2.1, p = 0.09$, which does not allow us to
affirm that this group preferred the automated version of the navigation.
Nevertheless, as can be observed, the automated version received higher grades
in all statements with the exception of S1, which sought to evaluate the
automatic speed adjustment of the \emph{fly} tool. Analyzing the justifications
for the grades and the general comments made by the users revealed some
interesting points.

Almost all advanced users who gave a lower grade to the automatic speed
adjustment reported that, when getting very close to an object, the camera would
become too slow and it would take a while until they were able to move away from
the object again. These users felt impatient, and this
feeling was made worse by the fact that no control option was provided to allow
them to \emph{momentarily} increase the speed. Nonetheless, the same users noted
that the automatic adjustment was good because it allowed them to be less
concerned with the controls and helped them avoid some errors, which is in
agreement with the general comments made by the non-advanced users. In summary,
the advanced users wished they were offered some sort of control which allowed
them to make a more ``customized'' adjustment at certain moments, while at the
same time including automatic speed adjustment.

Another factor that contributed to the preference for the manual version
in S1 was the manner in which the tests were conducted. Before the users began
the manual version test, they were asked to avoid cutting through
(colliding with) objects in the scene. This led them to be very cautious in
relation to speed adjustment, thus avoiding possible difficulties they could
face when using the manual version. This caution may have contributed to the 
higher grades that resulted. However, this had a negative impact on the 
comfort experienced by the
users: in order to avoid colliding with the models, they were forced to stop
often and readjust the navigation speed.

The greatest contributions of the automated version were related to statements
S2 and S3, which aimed at evaluating the efficacy of collision treatment and
automatic pivot point, respectively. %These two techniques were the ones that
%received most positive remarks in the general comments. 
The users could easily
notice the effects provided by these techniques and were very satisfied with
their results. Some users expressly stated that, thanks to these techniques, they
did not make certain errors and were able to focus less on interface issues.
Finally, the grades given by the users in the advanced group to statements S4
and S5 demonstrated that they felt more comfortable and experienced fewer moments
of disorientation while using the automated version. This was also true for the 
non-advanced users.

Regarding the final survey question, 6 out of the 7 advanced users
stated in Q1 that they preferred the automated version rather than the manual
one. Only user PA2 preferred the latter. In the justification, this user
mentioned the problem with the automatic speed adjustment and the lack of
feedback to the user about the location of the pivot point when using automatic
adjustment. As a result of PA2 suggestions, we now draw the pivot point in the
screen on recent versions of ours systens. Like Fitzmaurice et al.
\cite{fitz08}, we found that this also caused a improvement on the usage of the
tools related to the pivot point.

Finally, in question Q2, which asks for suggestions about what could be improved
in the preferred version, all of them asked for some kind of control that allows
them to momentarily increase the speed. This leads us to assume that advanced
users have a greater tendency to prefer solutions that make the tools simple to
use but that are not completely automated. The opposite might be said of
non-advanced users: due to their lack of experience, they prefer approaches that
minimize the need to adjust the parameters of the navigation tools.

\subsection{Quantitative Tests}

\subsubsection{Procedures Adopted}

% Assim como ocorreu nos testes qualitativos descritos anteriormente, foi pedido 
% que cada usuário assinasse um termo de consentimento para a realização dos testes. 
% Inicialmente foram também apresentadas as funcionalidades do SiVIEP, assim como 
% todos os aspectos necessários �  utilização do software.
% 
As in the qualitative tests described above, each user was asked to sign an agreement 
to confirm their commitment to taking the test. Then, the features and controls of 
SiVIEP were presented.

% Cada usuário deveria seguir um roteiro pré-determinado que, assim como nos testes 
% qualitativos, consistia em navegar até a plataforma A usando a ferramenta Fly, 
% inspecionar três objetos diferentes usando a ferramenta Examine e por fim ir até 
% a plataforma B usando  a ferramenta Fly . A diferença é que nesse caso não foi 
% dada ao usuário a liberdade de escolher quais objetos deveriam ser examinados. 
% Para cada versão, o usuário deveria encontrar e inspecionar três objetos 
% pré-determinados. Para minimizar os efeitos da aprendizagem, os objetos a serem 
% examinados na versão manual foram diferentes daqueles da versão automática. 
% Dessa forma, a dificuldade em achar os objetos ao usar o software pela segunda 
% vez deveria ser a mesma. Pela mesma razão, o procedimento de alterar a ordem 
% em que as versoes são apresentadas ao usuário também foi usado aqui. Foi pedido 
% também que os usuários evitassem colidir com os objetos da cena quando estivessem 
% usando a ferramenta Fly.

Each user had to follow a pre-determined set of steps, consisting of navigating 
to the platform A using the \emph{fly} tool, finding three different 
objects to inspect using the \emph{examine} tool and travelling to
platform B using again the \emph{fly} tool. A key diference between this quantitative 
test and the previously described qualitative test is that in the quantitative test users 
were not given the freedom to choose which objects they should examine, rather, the 
objects were assigned. To minimize learning effects, the objects to be examined in the manual version 
were different from those of the automatic version. Thus, the difficulty in finding 
objects using the software for the second time should be the same. For the same 
reason, the procedure for changing the order in which the versions were presented to a user
was also used. The users were also asked to avoid collisions when using the 
\emph{fly} tool.

% Na realização desses testes não foi necessário que os usuários respondessem a um 
% questionário após a execução de cada versão. Os testes foram filmados, e os videos 
% resultantes foram analisados posteriormente afim de se obter o número de vezes em 
% que cada um dos eventos abaixo ocorreu:
% 
There was no written questionnaire issued after the test of each version. The tests 
were filmed, and the videos obtained were analyzed in order to determine the number of times
that each of the following events occurred:

% \begin{itemize}
%  \item A - Colisão.
%  \item B - Ajuste incorreto do centro de rotaçao.
%  \item C - Desorientação do usuário.
%  \item D - Uso do botão de reset.
% \end{itemize}
% 
\begin{itemize}
 \item A - Collision.
 \item B - Incorrect adjustment of the pivot point.
 \item C - Disorientation.
 \item D - Usage of the reset button.
\end{itemize}

% A ocorrência de qualquer um dos eventos acima indica um erro cometido pelo usuário ou 
% ainda uma experiencia ruim de uso do sistema de navegação e interação do softawre.
% 
An occurrence of these events indicates an error or a bad user experience.

% O botão de reset faz com a que a câmera volte a sua posição inicial. Foi dado ao
% usuário como uma alternativa de se orientar novamente quando este entrava em uma 
% situação de desorientação a qual não conseguia resolver facilmente. Quando um usuário 
% usava esse botão, não era necessário que ele refizesse todos os passos que já haviam sido 
% completados. Ele podia se dirigir diretamente para a posição onde estava antes da desorientação 
% e seguir o teste desse ponto.
% 
The reset button sends the camera back to its original position. It was given to
users as an option to orient themselves again when a event of disorientation ocurred. 
When a user clicks this button, brought the user directly to the place where the 
camera was before the disorientation event occurred.

% Foram também obtidos os tempos que cada usuário levou para completar o roteiro 
% de teste em cada versão. Isso faz sentido aqui uma vez que não há mais a 
% liberdade de escolha de quais objetos deverão ser examinados.
% 
% Apesar de não ter sido pedido que os usuários respondessem a um questionário sobre suas 
% impressões do uso do softawre, esses foram incentivados a falar o máximo possível 
% durante o teste sobre a experiência de uso com o software. Esperou-se com isso obter 
% também informações subjetivas que pudessem justificar a ocorrência dos eventos 
% listados acima.
% 
The duration of the tests were also recorded. This was done as the users no longer 
had the freedom to choose which objects should be 
examined. Also, users were encouraged to relay their impressions verbally while 
performing the tests. This way, we could obtain extra information that could 
help explain the occurrence of events listed above.

\subsubsection{Results}

% As tabelas \ref{tab:results7} e \ref{tab:results8} mostram os resultados dos testes 
% quantitativos em relação a ocorrência dos eventos A, B, C e D. Cada linha representa 
% um usuário, enquanto as colunas o número de 
% vezes que os eventos A, B, C e D ocorreram. A última coluna contém o total de eventos 
% para um determinado usuário. A tabela \ref{tab:results7} refere-se aos 
% resultados da versão manual. A tabela \ref{tab:results8} refere-se �  versão automática.
% O gráfico da figura \ref{fig:teste_usuario3} mostra os valores totais para as 
% versões manual e automática para cada usuário e facilita a comparação entre seus 
% resultados.
% 
Tables \ref{tab:results7} and \ref{tab:results8} show the results of the 
quantitative tests for the occurrence of events A, B, C and D. Each row represents
a different user, while the columns labeled A, B, C and D represent the number of times that the 
respective event happened. The last column contains the total number of events
for a given user. Table \ref{tab:results7} refers to results of the manual version. 
Table \ref{tab:results8} refers to the automatic version. Figure \ref{fig:teste_usuario3} 
shows the total number of errors for manual and automatic versions for each user and facilitates the 
comparison between then.

\begin{table}[!htb]
\centering
\begin{tabular}[c]{|c|c c c c |c|}
\hline
       &  A  &  B  &  C  &  D  &  TOTAL \\
\hline
 PN6   &  5  &  1  &  3  &  0  &  9     \\
\hline
 PN7   &  1  &  0  &  1  &  0  &  2     \\
\hline
 PN8   &  2  &  0  &  0  &  0  &  2     \\
\hline
 PN9   &  3  &  4  &  4  &  3  &  14    \\
\hline
 PN10  &  3  &  5  &  6  &  0  &  14    \\
\hline
 PN11  &  7  &  2  &  4  &  1  &  15    \\
\hline
 PN12  &  5  &  1  &  1  &  0  &  7     \\
\hline
\end{tabular}
\caption{Number of events A, B, C and D for the manual version.}
\label{tab:results7}
\end{table}

\begin{table}[!htb]
\centering
\begin{tabular}[c]{|c|c c c c |c|}
\hline
       &  A  &  B  &  C  &  D  &  TOTAL \\
\hline
 PN6   &  0  &  3  &  1  &  0  &  4     \\
\hline
 PN7   &  0  &  0  &  1  &  1  &  2     \\
\hline
 PN8   &  0  &  0  &  0  &  0  &  0     \\
\hline
 PN9   &  0  &  0  &  1  &  0  &  1    \\
\hline
 PN10  &  0  &  0  &  1  &  0  &  1    \\
\hline
 PN11  &  0  &  0  &  1  &  0  &  1    \\
\hline
 PN12  &  0  &  0  &  0  &  0  &  0     \\
\hline
\end{tabular}
\caption{Number of events A, B, C and D for the automatic version.}
\label{tab:results8}
\end{table}

\begin{figure}[htb!]
  \centering
  \includegraphics[scale=0.4]{teste_quant}
  \caption{Comparative results between the manual and the automated version.}
  \label{fig:teste_usuario3}
\end{figure}

% Como pode ser visto, o número de eventos ocorridos na versão manual foi maior que os 
% ocorridos na versão automática para a maioria dos usuários. Isso indica que a versão 
% automática foi menos propensa a erros e provocou menos situações desconfortáveis aos 
% usuários. As excessões ficam por conta dos usuários PN7 e PN8, e serão discutidas mais 
% adiante. 
% 
The number of events in the manual version was greater than in the 
automatic version for most users. This indicates that the automatic version was less 
prone to errors and caused fewer uncomfortable situations. The exceptions are users PN8 and PN7, 
which will be discussed later.

% Como era esperado, não houve registro de colisões (evento A) para a versão automática uma vez que 
% o sistema impede que elas ocorram. Na versão manual, foi possível perceber que a 
% ocorrência de colisões estava relacionada �  dificuldade de se controlar a 
% velocidade da câmera. Essas colisões por vezes provocaram situações de desorientação.
% 
As expected, there were no collisions (event A) for the automatic version since
the system prevents them from occurring. In the manual version, it was observed that the
collisions were related to the difficulty of controlling the camera speed. These collisions 
often led to disorientation.

% O ajuste incorreto do centro de rotaçao foi outro fator responsável por causar 
% desorientação. Novamente, a maior incidência desse erro ocorreu na versão manual. A 
% excessão foi o usuário PN6: ele teve dificuldades em orientar a câmera de forma que 
% o objeto a ser examinado ficasse no centro da tela. Por conta disso, o ajuste 
% automático do centro de rotação não funcionou da forma que ele esperava. O resultado 
% disso é que esse usuário relatou durante os testes que preferiu usar explicitamente 
% a ferramenta de alterar centro de rotação.
% 
The incorrect adjustment of the pivot point was another factor responsible for 
disorientation. Again, the highest incidence of this error occurred in the manual 
version. The exception was user PN6: he had difficulty in orienting the camera so that
the object to be examined could be located in the center of the screen. Because of 
this, the automatic adjustment of the pivot point did not work the way expected. The result
is that this user reported that he preferred to use the tool to manually set the pivot point.

% A tabela \ref{tab:results9} contem os tempos de duração em segundos dos testes das 
% versões automática e manual para cada usuário. A última coluna indica a relação 
% entre os tempos das versões manual e automática. Para a maioria dos usuários, o 
% tempo necessário para finalizar o teste foi maior na versão manual. Como motivo
% principal para isso observou-se que os usuários gastaram uma parte razoável do tempo 
% tentando ajustar corretamente a velocidade de navegação. Além disso, as situações 
% de desorientação também contribuiram para que esse tempo fosse maior.
% 
Table \ref{tab:results9} contains the duration in seconds of the tests for each user. 
The last column indicates the relationship between the times spent on manual and 
automatic versions. For most users, the time required to complete the test was higher 
in the manual version. The main reason of this was that users spent a significant amount of 
time trying to correctly adjust the navigation speed. Moreover, the disorientation situations
also contributed to the increase in time.

\begin{table}[!htb]
\centering
\begin{tabular}[c]{|c| c c |c|}
\hline
       &  Manual  &  Automatic  &  Manual / Automatic \\
\hline
 PN6   &  540     &  240        &  2.25  \\
\hline
 PN7   &  215     &  380        &  0.56  \\
\hline
 PN8   &  180     &  213        &  0.84  \\
\hline
 PN9   &  535     &  230        &  2.32  \\
\hline
 PN10  &  895     &  400        &  2.23  \\
\hline
 PN11  &  720     &  480        &  1.5   \\
\hline
 PN12  &  320     &  250        &  1.28  \\
\hline
\end{tabular}
\caption{Time spent to perform the tests.}
\label{tab:results9}
\end{table}

\begin{figure}[htb!]
  \centering
  \includegraphics[scale=0.35]{teste_quant_tempo}
  \caption{Comparative results between the times spent on manual and automatic versions.}
  \label{fig:teste_usuario4}
\end{figure}

% A excessão novamente fica por conta dos usuários PN7 e PN8. Durante os testes, 
% descobriu-se que o perfil desses usuários não se encaixava exatamente no grupo de 
% não-avançados. O usuário PN8 informou que jogava jogos eletrônicos 3D com frequência. 
% Por conta disso, ele não teve maiores dificuldades em controlar manualmente a 
% navegação e colidiu levemente com os objetos apenas duas vezes. O tempo gasto na versão 
% automática foi um pouco maior do o gasto na versão manual, uma vez que a habilidade 
% desse usuário permitiu que ele se deslocasse mais rápido pela cena usando o ajuste 
% manual de velocidade. Assim como alguns integrantes do grupo de usuários avançados, 
% o usuário PN8 reclamou de não poder aumentar a velocidade na versão automática.
% 
The exceptions again were users PN7 and PN8. During the tests, it was 
found that these users had previous experiences that affected their navigation 
performances. User PN8 reported that he plays 3D games very often.
Hence, he had no difficulty in manually controlling the camera on both versions 
and collided lightly with the objects only twice. The time spent in the automatic version 
was slightly greater than the time spent on the manual version, since the ability
of user PN8 allowed him to move faster through the scene using the manual adjustment
of speed. Similarly to some members of the advanced group of users, user PN8 complained of 
not being able to adjust the speed in the automatic version.

% Sobre o usuário PN7, descobriu durante os testes que o mesmo já havia usado no passado 
% ouro softawre de visualização cientifica. A primeira versão do SiVIEP usada por ele 
% foi a automática, e boa parte do tempo gasto nessa versão foi na tentativa de aplicar 
% no SiVIEP a forma de se navegar do sistema que ele havia usado anteriormente. Somente 
% depois de algum tempo, o usuário PN7 se acostumou com as formas de navegação do SiVIEP. 
% Isso contribuiu para que o tempo gasto na versão automática fosse quase o dobro em 
% relação �  manual. Esse acontecimento nos sugere outra maneira de melhorar a 
% usabilidade de nosso sistema: a investigação da experiência de uso com outros softwares.
% Uma vez de posse dessas informações, seria possível identificar em outros sistemas 
% possíveis melhorias a serem agregadas em nossas ferramentas de navegação.
% 
With user PN7, it was discovered during the test that he had already used 
other scientific visualization software in the past. The automatic version was tested 
first, and he spent a significant amount of time trying to use the navigation
tools in SiVIEP the same way he used tools on the other software. Only
after some time did the user become better acquainted with the tools of SiVIEP.
This contributed to the result of the user requiring almost twice as much time in 
the automatic version versus the manual version. This event suggests another way to improve
usability on our system: the investigation of the user's experience with other software.
With such information, we could identify possible improvements to be 
incorporated in our navigation tools.

% Por fim, ao final do uso das duas versões foi perguntado aos usuários qual delas haviam 
% preferido. Somente os usuários PN7 e PN8 preferiram a versão manual. Novamente, o 
% fator que motivou essa escolha foi a falta de controle de velocidade na versão 
% automática, o que está de acordo com os testes qualitativos com o grupo de usuários 
% avançados.
% 
Finally, at the end of the tests users were asked about which version they had
preferred. Only users PN7 and PN8 chose the manual version. Again, the
factor that motivated this choice was the lack of speed control in the automatic version. This 
is consistent with the results reported in qualitative tests with the group of advanced 
users.

\section{Conclusions}

This work presented techniques to assist and facilitate navigation in 
3D virtual environments. They were based on the construction and
maintenance of a data structure called \emph{cubemap} 
\cite{maccrae09}. Improvements were proposed for the \emph{examine} tool, with
the development of a system to automatically determine the pivot point, and for the
\emph{fly} tool, in which collision support and automatic speed adjustment in
relation to the scale were implemented.

To verify the efficacy of the solutions proposed, usability tests were
performed. The results allow us to conclude that the techniques presented
here improve the navigation experience of the users. From the 19 subjects of the
usability tests, 16 preferred the version of the application that included the
techniques proposed. In particular, the automatic adjustment of the pivot point
in the \emph{examine} tool and the collision support implemented in the
\emph{fly} tool had a significant positive impact in user experience.

Navigation in 3D environments still presents issues and provides plenty of challenges.
Multiscale environments, which are becoming more common, identify several further
navigation-related problems to be solved in the future. We believe the 
techniques demonstrated in this
work contribute to providing solutions to some of the problems identified
regarding navigation in these environments. 


\begin{acknowledgements}
The authors thank Petrobras for this research support and for the software
used in this research (SiVIEP). D. Trindade thanks CAPES and A. Raposo, 
FAPERJ and CNPq for the individual support granted to this research.
\end{acknowledgements}

% BibTeX users please use one of
\bibliographystyle{spbasic}      % basic style, author-year citations
%\bibliographystyle{spmpsci}      % mathematics and physical sciences
%\bibliographystyle{spphys}       % APS-like style for physics
\bibliography{mtap}   % name your BibTeX data base

% Non-BibTeX users please use
% \begin{thebibliography}{}
%
% and use \bibitem to create references. Consult the Instructions
% for authors for reference list style.
%
% \bibitem{RefJ}
% Format for Journal Reference
% Author, Article title, Journal, Volume, page numbers (year)
% Format for books
% \bibitem{RefB}
% Author, Book title, page numbers. Publisher, place (year)
% etc
% \end{thebibliography}

\end{document}
% end of file template.tex

