VRAR Trends

Tendências e Técnicas em
Realidade Virtual e Aumentada

Av. Bento Gonçalves, 9500 - Setor 4 - Prédio 43.412 - Sala 219 - Bairro Agronomia
CEP 91.509-900 - Porto Alegre - RS - Tel. (51) 3308-6835 - Fax (51) 3308-7142
Home: www.sbc.org.br - E-mail: sbc@sbc.org.br
José Carlos Maldonado (ICMC-USP)
Presidente
Marcelo Walter (UFRGS)
Vice-Presidente
Luciano Paschoal Gaspary (UFRGS)
Diretor Administrativo
Paulo Cesar Masiero (ICMC-USP)
Diretor de Finanças
Lisandro Zambenedetti Granville (UFRGS)
Diretor de Eventos e Comissões Especiais
Mirella Moura Moro (UFMG)
Diretora de Educação
Karin Koogan Breitman (PUC-Rio)
Diretora de Publicações
Ana Carolina Brandão Salgado (UFPE)
Diretora de Planejamento e Programas Especiais
Thais Vasconcelos Batista (UFRN)
Diretora de Secretarias Regionais
Altigran Soares da Silva (UFAM)
Diretor de Divulgação e Marketing
Ricardo de Oliveira Anido (UNICAMP)
Diretor de Relações Profissionais
Carlos Eduardo Ferreira (USP)
Diretor de Eventos Especiais
Marcelo Walter (UFRGS)
Diretor de Cooperação com Sociedades Científicas

Publicação anual | Porto Alegre | v. 1, n. 1 | p. 1-158 | 2011
Tendências e Técnicas em
Realidade Virtual e Aumentada

TODOS OS DIREITOS RESERVADOS: Permitida a reprodução total ou parcial desde que citada a fonte (Tendências e
Técnicas em Realidade Virtual e Aumentada, Porto Alegre-RS, Brasil). Na ausência da indicação da fonte ou expressa
autorização da Instituição, é proibida a sua reprodução total ou parcial, por qualquer meio ou processo, especialmente por
sistemas gráficos, microfílmicos, fotográficos, reprográficos, fonográficos ou videográficos. Vedada a memorização e/ou
recuperação total ou parcial, bem como a inclusão de quaisquer partes desta obra em qualquer sistema de processamento
de dados. Essas proibições aplicam-se também às características da obra e à sua editoração. A violação dos direitos autorais
é punível como crime (art. 184 e §§, do Código Penal, cf. Lei no. 6.895, de 17-12-1980) com pena de prisão e multa, conjun-
tamente com busca e apreensão e indenizações diversas (arts. 122, 123, 124 e 126, da Lei no. 5.988 de 14-12-1973, Lei dos
Direitos Autorais).
Tendências e Técnicas em Realidade Virtual e Aumentada.
Sociedade Brasileira de Computação - SBC. -- n. 1 (2010) - .
Porto Alegra, RS: a Instituição, 2010- .
v.
Anual
ISSN
1. Realidade Virtual, Realidade Aumentada I. Siscoutto,
Robson. II. Brega, Jose Remo Ferreira.
CDD 006
Este periódico foi especialmente edi-
tado, em tiragem limitada, a partir
de conteúdos desenvolvidos para os
minicursos apresentado durante o
XIII Simpósio de Realidade Virtual
e Aumentada, realizado em Uber-
lândia – MG de 23 a 26 de Maio de
2011, promovido pela Sociedade
Brasileira de Computação e organi-
zado pela Universidade Federal de
Uberlândia - UFU.
Uberlândia - MG
2011
Índice para catálogo sistemático:
1. Realidade Virtual e Aumentada: Ciência da Computação 006
Dados Internacionais de Catalogação na Publicação (CIP)
EDITORES
Robson Augusto Siscoutto
José Remo Ferreira Brega
CONSELHO EDITORIAL
Alexandre Cardoso, UFU
Edgard Afonso Lamounier Júnior, UFU
José Remo Ferreira Brega, UNESP
Luciano Pereira Soares, PUC – RJ
Robson Augusto Siscouto, UNOESTE
Veronica Teichrieb, UFPE
PRODUÇÃO GRÁFICA
Canal 6 Projetos Editoriais - www.canal6.com.br
Este periódico será registro no IBICT.

5
Sumário
Prefácio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Developing Android Applications for AugmentedReality . . . . . . . . . . . . . 9
Philip Michel Duarte, Edson Alyppyo Gomes Coutinho
and Selan Rodrigues dos Santos
Prototipagem Rápida de Aplicações Interativas de Realidade
Aumentada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Claudio Kirner
Desenvolvendo um Ambiente Virtual em Realidade Aumentada
para Web com FLARToolKit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Robson Augusto Siscoutto e Levrangeles da Silva Filho
Jogos Educacionais Baseados em Realidade Aumentada e
Interfaces Tangíveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Rafael Roberto, João Marcelo Teixeira, João Paulo Lima, Manoela
Milena Oliveira da Silva, Eduardo Albuquerque, Daniel Alves, Veronica
Teichrieb e Judith Kelner
Desenvolvimento de Aplicações em Realidade Aumentada e
Diminuída para iPhone e iPad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Luciano Silva e Ismar Frango Silveira

7
Prefácio
O Symposium on Virtual and Augmented Reality (SVR) é um evento promovido
pela Sociedade Brasileira de Computação que integra pesquisadores e profissionais inte-
ressados em conhecer e atualizar conceitos relacionados à realidade virtual e aumentada
(RVA). Tradicionalmente, o evento oferece minicursos com o objetivo de apresentar ten-
dências e metodologias aplicadas visando promover habilidades e difusão de conheci-
mentos entre seus participantes.
Com o intuito de continuar a democratização e a disseminação do conhecimen-
to sobre RV e RA, neste ano de 2011, os minicursos do SVR2011 lançam mais uma
obra oferecendo uma visão conceitual e tecnológica destinada ao desenvolvimento de
aplicações de realidade aumentada – RA. Os cinco minicursos oferecidos, forma orga-
nizados em capítulos neste livro. No primeiro capítulo é apresentado uma visão geral
do processo de desenvolvimento de aplicações de Realidade Aumentada com AndAR,
uma biblioteca baseada em Java que implementa a ARToolKit na plataforma Android. O
segundo capítulo aborda o problema da autoria de aplicações de Realidade Aumentada,
relacionado com o desenvolvimento e uso das aplicações, em diversos níveis. É descrita
uma ferramenta de autoria e seu uso na prototipagem rápida de aplicações interativas
de Realidade Aumentada por não programadores. O terceiro capítulo apresentar o pro-
cesso de desenvolvimento de aplicações de Realidade Aumentada na web com FLAR-
ToolKit, explorando suas potencialidades quanto à integração de aplicações e suporte
na sua utilização em diferentes plataformas para acesso a ambientes de RA. O quarto
capítulo apresenta os conceitos básicos sobre Realidade Aumentada, interfaces tangíveis
e jogos para educação de modo que a integração destes possa melhorar a experiência de
alunos em sala de aula. O quinto e ultimo capítulo, detalha a organização funcional das
arquiteturas do iPhone e iPad, bem como seus ambientes e ferramentas de programa-

8
ção, detalhando algumas aplicações em Realidade Aumentada e Diminuída para ambas
as plataformas.
Esta obra foi o resultado do trabalho de 16 autores da comunidade brasileira de
RVA e constitui uma referência para atualizações tanto por profissionais quanto por
pesquisadores que queiram conhecer estas tendências e técnicas de RVA, além de ser
útil como porta de entrada para estudantes, iniciantes e profissionais de outras áreas do
conhecimento interessados em ingressar no fascinante mundo da tecnologia de realida-
de virtual e aumentada.
Agradecemos a todos que colaboraram com a realização dos minicursos e com a
edição deste livro. Desejamos a todos uma excelente leitura!
Os organizadores
Robson Augusto Siscoutto - robson.siscoutto@unoeste.br
José Remo Ferreira Brega - remo@fc.unesp.br

9
Developing Android Applications for
AugmentedReality
Philip Michel Duarte, Edson Alyppyo Gomes Coutinho
and Selan Rodrigues dos Santos
Departamento de Informática e Matemática Aplicada (DIMAp) Universidade
Federal do Rio Grande do Norte (UFRN) Natal – RN – Brazil
{philipmichelduarte,alyppyo}@gmail.com and selan@dimap.ufrn.br
Abstract
In this chapter we present an overview of the development process of an Augmented
Real¬ity (AR) application with AndAR, a Java based software library that implements
ARToolkit on the Android platform. This example application recognizes markers and su-
perimpose images over live video of the environment. To make this possible, ﬁrst we pres-
ent some basic concepts related to the development of mobile applications on the Android
platform, Augmented Reality, and the library AndAR. After that, we provide a detailed
step by step explanation about the application’s implementation.
1. Android
Android is an open platform for mobile development which was designed to abs-
tract the differences between platforms and to provide a uniform use experience. It was
acquired by Google in 2005 with the objective of being an alternative to mobile appli-
cation devel-opment. Since then Android has been growing fast and incorporating a
lot of different features such as multi-touch, multitasking and Virtual Private Network
(VPN) support.
JPG, PNG and GIF), SQLite, rich development environment, application fra-
mework, op¬timized graphics and another features that are hardware dependant. Figu-
re 1 illustrates the Android Architeture, its layers and its components.

10
Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011.
DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos.
Developing Android Applications for AugmentedReality
Figure 1. The Android’s Architeture. Source: developer.android.com.
Sometimes people may get confused when they try to deﬁne Android. Android
depends on the Linux kernel for core systems, but it is not considered embedded Li-
nux because the standard Linux utilities, such as X-Windows and GNU C libraries,
are not supported. We write Android applications in the Java language, but they will
not run within a Java ME virtual machine. Furthermore, Java-compiled classes and ex-
ecutables will not run natively in Android [Meier 2010], so we can not use standard Java
libraries like Swing. Android has its own libraries, optimized for usage in an embedded
environ¬ment.
Android is also not a Google’s answer to the iPhone. Android is an open-source
software stack produced by the Open Handset Alliance and designed to operate on any
device that meets the requirements, while the iPhone is a proprietary platform released
by Apple [Meier 2010].
1. Why choose Android?
According to oDesk’s online employment report for October 2010 [oDesk 2010],
the demand for Android developers has increased by 710% when compared with the
same month in last year. This means just one thing: a new market trend. In 2010, An-
droid based mobile phones sales has passed iPhone unit sales. All these facts are a
direct re-sult of a well designed platform that daily attracts an incresing number of
developers and users.

11
Another appealing aspect of Android is its online store: the Android Market (mar-
ket.android.com). There are a lot of applications (or just “apps”) available to all kinds of
customer. The applications are divided by categories and can be found separated in free
or paid categories. On the website you can ﬁnd the most popular appli¬cations featured,
and the number of applications available are growing continuously. In fact, this number
has risen almost ﬁvefold in less than one year (see Figure 2).
Figure 2. Number of apps available on Android Market. Source: appbrain.com.
2. Augmented Reality
Augmented Reality (AR) is a growing area in Virtual Reality (VR) research. AR
sys¬tems generate composite views for the user, a combination of the real scene viewed
by the user and a virtual scene generated by the computer that augments this scene
with some additional information. The principal function of AR is to enhance the user’s
per¬formance and perception of the world [Vallino 1988]. The goal of AR is to create
the sensation that virtual objects are present in the real world. So, AR is most effective
when virtual elements are added in real time. Because of this it is generally used in digi-
tal video image. The simplest example of AR is overlaying a 2D image on a digital video
[Cawood and Fiala 2008]. However you may use 3D models as well, how we will show
you in the next sections.

12
When virtual objects are added to a scene, it is known as visual AR. AR elements
are not visible to the naked eye so we need some sort of display to see them. This display
can be a simple computer monitor or a television, or more sophisticated devices like a
head-mounted display (HMD). With the advance of the technology, new interfaces are
becoming available.
Figure 3. Examples of fiducial marker.
Figure 4. A model 3D renderized above a marker. Source: computerarts.co.uk.
However, one characteristic does not change: the necessity of an indication of the
place where you want to add information in a digital image. In general, we indicate it
with AR markers. The simplest form of marker is a unique pattern that is visible to the
AR camera and can be identified. This marker, as known as fiducial marker (see Figure
3), will be used like reference to the AR system software that will renderize the object as-
sociated to it. Fiducial means the markers are used as a trusted reference. Figure 4 shows
a model 3D renderized after the AR system had recognized the marker.
It is possible create AR effects without markers. This is known as markerless AR.
To substitute the markers, you can track the position of LEDs or another reflexive ob-
jects, like balls. You can also use natural features of the scene, like corners of a window
or energy switches instead of the markers. Another possibility is the use of textures
like markers.

13
2.1. Augmented Reality Application Domains
AR can be applied in a lot of different domains and the researchers have proposed
some ideas that will help the profissionals of many different areas. We will see some
examples of these ideas now.
The medical area can be considered the most important domain of AR applica¬tion.
With the facilities that the AR systems can bring doctors can not only increase their ac-
curacy in the diagnostic but can get it faster too. Pre-operative imaging studies of the
patient can provide the surgeon with the necessary of internal anatomy, how is illustra-
ted by Figure 5.
Figure 5. AR applied on medical field. Source: University of Rochester.
Military area also can be beneficiated. They have been using displays in cockpits
that presents information to the pilot on the windshield of the cockpit or the visor of
their flight helmet. AR can be applied in the training as well. The soldiers can visualize
many precise information about the place where they are and about the groups, choos-
ing the best strategy for the moment (Figure 6).

14
Figure 6. AR applied to military training. Source: augmented-reality.com.
We can use AR for architecture and urban planning as well. Figure 7 repre¬sents
the ARTHUR project from the University College London. In this project, people use
some special glasses to visualize and discuss models in design meetings. The virtual
models can be manipulated and the interface can develop a series of simulations
and visu¬alisations of aspects of building performance. This interface was especially
designed for interactive use and is a easy way to visualize the entire project in group
[Penn et al. 2004].
Figure 7. AR applied to architetural design. Source: UCL Bartlett School of Graduate Stu-
dies.
These are just some projects in AR area and you can easily ﬁnd a big variety of simi-
lar projects on the internet. The area is growing fast, and the tendency is to carry on this
way in the next years, which means that more ideas on the area will appear very soon.

15
2.2. ARToolKit
ARToolKit is a software library for building Augmented Reality (AR) applications
that involve the overlay of virtual imagery on the real world. We just have to use a mark-
er and one camera. When the user moves the marker in front of the camera, the virtual
character renderized moves with it and appears attached to the real object. One of the
key difﬁculties in developing Augmented Reality applications is the problem of tracking
the users viewpoint. In order to know from what viewpoint to draw the virtual imagery,
the application needs to know where the user is looking in the real world.
ARToolKit uses computer vision algorithms to solve this problem. The ARToolKit
video tracking libraries calculate the real camera position and orientation relative to
physi¬cal markers in real time. This enables the easy development of a wide range of
Augmented Reality applications. Some of the features of ARToolKit [ARToolKit 2011]
include:
Single camera position/orientation tracking;•
Tracking code that uses simple black squares;•
The ability to use any square marker patterns;•
Easy camera calibration code;•
Fast enough for real time AR applications;•
SGI IRIX, Linux, MacOS and Windows Operational System distributions;•
Distributed with complete source code.•
3. AndAR
AndAR is a library that empowers Android applications with Augmented Reality
features. The whole project is released under the GNU General Public License (GPL).
AndAR is, essentially, a ARToolKit port for Java under the Android platorm.
3.1. Preparing Our Development Environment
For Android development, we are going to need the Eclipse IDE, the ADT plugin,
the Android SDK and an Android Virtual Device. The Eclipse IDE can be downloaded
free of charge from http://www.eclipse.org/. Both the ADT plugin and the latest An-
droid SDK can be downloaded from the Android developer portal at http://developer.
android.com/in¬dex.html. The Android Virtual Device can be downloaded from the
Android SDK Man¬ager, which comes with the SDK itself. The source code of the An-

16
dAR project, along with the examples, can be downloaded directly from the SVN server,
as shown below:
svn checkout http://andar.googlecode.com/svn/trunk/ andar-read-only
3.2. Architecture of an AndAR Application
AndAR is an Augmented Reality Framework for Android. It offers a pure Java,
object-oriented API. The ﬁgure below shows a simpliﬁed class diagram of an application
that makes use of AndAR.
Figure 8. Class diagram of an AndAR application
Every Android application consists of one or more Activities. An Activity is a
vi¬sual user interface, targeted to a single purpose. Only one may be active at a time.
AndAR provides a special Activity class, AndARActivity, which takes care of Augmen-
ted Real¬ity related features such as opening the camera, detecting the markers and
displaying the video stream. One must extend AndARActivity in order to create an
Augmented Reality application. The AndARActivity class also offers a method that
allows the application to take screenshots.
On the diagram (see Figure 1.8), the extended AndARActivity class is called Cus-
tomActivity. It must implement the method onCreate and register the objects that
AndAR will process. The objects processed by AndAR are instances of classes which
extend ARObject.
The ARObject is an abstract class that represents an association between a marker
and a 3D object. It receives the name of the marker as an argument on it’s constructor

17
and must implement two methods: init and draw. The init method is used to ini-
tialize any members that may need a working OpenGL context. The draw is called by
AndAR whenever the object associated with a specific marker needs to be rendered.
Rendering with AndAR is provided through OpenGL ES 1.0.
In order to draw a custom object, the method draw has to be overridden. Before this
method is invoked a transformation matrix will already have been applied. This means
the object will be alligned to the marker, without any further steps. This method will not
be invoked, if the marker belonging to this object is not visible.
The class ARRenderer is reponsible for the rendering that is not associated with An-
dAR markers. If you want to mix augmented with non augmented 3D objects you may
provide a class implementing the OpenGLRenderer interface. There are three methods
defined by this interface. initGL being called only once, when the OpenGL surface is
initialized. Whereas setupEnv is called once before the augmented objects are drawn. It
can be used to issue OpenGL commands that shall effect all ARObjects, like initializing
the lighting. In the draw method you may draw any non augmented 3D objects. It will be
called once for every frame. Specifying such the described renderer is optional.
3.3. Using Our Own Markers
Using your own markers with AndAR is easy. Just as with ARToolKit, each marker
corre¬sponds to a file containing the necessary information for AndAR to identify the
markers. Each marker file must be placed inside the assets folder of the Eclipse project.
The file name corresponding to the marker must be passed as an argument in the AR-
Object con¬structor in order to associate a marker with an object. In order to generate
the marker files, one may proceed just as with ARToolKit, using the mk_patt program.
3.4. Programming in AndAR
In order to illustrate the concepts regarding the development of Augmented Reality
ap-plications in Android, we provide an in-depth walkthrough of a simple application
using AndAR called ObjViewer. The purpose of this application is showing the reader
how to develop a simple, yet fun AR application for Android with AndAR. The Ob-
jViewer al¬lows the user to visualize 3D models built with modelling packages such as
Blender or 3DS Max in an Augmented Reality context. One thing to be mentioned is
that this tutorial needs an actual Android device to be properly tested, since the current
Android Emulator does not feature camera support.

18
3.4.1. Step I -Planning Our App
Android applications are made up of activities. Each activity manages and exibits
a set of views and controls. As a rough idea, we may think of activities as realizations
of use-cases from the Unified Modelling Language (UML). For the ObjViewer, we will
need only one activity, which will be responsible for rendering the current frame as
captured by the camera and overlaying it with the AR objects.
LetuscreateanewandroidprojectfromtheEclipseinterfaceandnametheactiv¬ity
something you like. We will use through this tutorial the name ObjActivity. You will
end up with something like the source code in Figure 9.
public class ObjActivity extends Activity {
/ Called when the activity is first created . /
@Override public void onCreate ( Bundle savedInstanceState ){
super . onCreate ( savedInstanceState );
setContentView ( R . layout . main ); } }
Figure 9. Class ObjActivity.
Now we must prepare the project for AndAR. There are three ways of adding
An¬dAR to our project. The first and most cumbersome is adding each of the source
files to our project. The second is compiling the source yourself and generate a AndAR.
jar file, which is a better approach. What we are going to do is use an already provided
An-dAR.jar file, which can be found in the lib directory of the AndARModelViewer
example (included in AndAR).
Open up your favorite SVN client and download the source code of the An-
dAR project. Once the download is finished, we must add the AndAR.jar file to the
CLASS¬PATH of our project. Right-click on the project, select Properties. Go for Java
Build Path on the left menu, and pick the Libraries tab. Here, click on “Add External Jar”
and browse through the directories to the andar-read-only/AndARModelViewer/ lib/
AndAR.jar file. After this step, we are all set.
Now refer to code presented. Our app will need an Augmented Reality view, which
is what the AndAR provides. Thus, our activity needs to extend AndARActivity, and
not Activity. We must also call startPreview at the end of the onCreate method, in order
to start fetching frames from the camera. Once you change the superclass and correct
the imports, Eclipse will complain the method uncaughtException isn’t imple¬mented.
It is an abstract method from AndARActivity, called whenever AndAR detects a severe
exception on one of it’s threads. We must finish the application when we receive such
call (see Figure 10).

19
public class ObjActivity extends AndARActivity {
/ Called when the activity is first created . /
@Override
public void onCreate ( Bundle savedInstanceState ){ super .
onCreate ( savedInstanceState ); startPreview () ;
}
@Override public void uncaughtException ( Thread arg0 , Throwable arg1 ){ finish () ;
} }
Figure 10. Class ObjActivity modified.
This code should already compile and execute. After deploying the application into
an Android device, one should see the frames captured by the camera. No augmented
reality feature is displayed, however. That is due to the fact that we did not register
any objects to be detected by AndAR at all. On Step II we will go through the details
of setting up lights and render states in OpenGL, and on Step III we will learn how to
actually load, register and display 3D models.
3.4.2. Step II -Setting Up The Scene
It is time to set up the scene. Thus, what we want to do in this step is setup the
lighting of our scene. Granted, the 3D objects will be displayed in an augmented reality
context. But the same can not be said about the lights. AndAR will not detect light sour-
ces on the frames captured by the camera, and we must set those manually if we expect
to see our objects.
AndAR provides an interface, called OpenGLRenderer, which we can imple¬ment
in order to detect and react to speciﬁc rendering events. Speciﬁcally, it has 3 meth¬ods:
initGL, setupEnv and draw. The initGL method is called once the OpenGL surface is
created. The setupEnv method is called just before an AR object is rendered. The draw
method is called at the end of the rendering process.
We will use the OpenGLRenderer to setup our lighting. We will use the initGL me-
thod to setup a few OpenGL states that remain unchanged throughout the application,
such as face-culling, smooth shading and depth testing. The setupEnv will be mainly
used to setup the light. We also disable texturing on setupEnv, since we won’t be loading
any textures. We will leave the draw method empty, since we won’t be doing any non-AR
rendering this time.
The code listing in Figure 11 shows how we setup our scene. One thing to keep in
mind are the FloatBuffers. On regular OpenGL with C/C++, one need not deal with them.
They are allocated on native memory, and act as an optimization often made by Java ports
of OpenGL, preventing and intermediary copy from managed arrays to native memory.

20
public class CustomRenderer implements OpenGLRenderer {
// Light definitions
private float [] ambientlight1 = {.3 f , .3 f , .3 f ,1f }; private float [] diffuselight1
= {.7 f , .7 f , .7 f ,1f }; private float [] specularlight1 = {0.6 f , 0.6 f , 0.6 f ,1f };
private float [] lightposition1 = {20.0 f , 40.0f ,100.0 f ,1 f };
private FloatBuffer lightPositionBuffer1 = GraphicsUtil . makeFloatBuffer ( lightposition1 );
private FloatBuffer specularLightBuffer1 = GraphicsUtil . makeFloatBuffer ( specularlight1 );
private FloatBuffer diffuseLightBuffer1 = GraphicsUtil . makeFloatBuffer ( diffuselight1 ); private
FloatBuffer ambientLightBuffer1 = GraphicsUtil . makeFloatBuffer ( ambientlight1 );
// Do non Augmented Reality stuff here. Will be called once after all AR objects have // been drawn . The
transformation matrices may have to be reset .
public final void draw ( GL10 gl ){}
// Directly called before each object is drawn. Used to setup lighting and // other OpenGL specific
things .
public final void setupEnv ( GL10 gl ){ gl .
glEnable ( GL10 . GL_LIGHTING );
gl . glLightfv ( GL10 . GL_LIGHT1 , GL10 . GL_AMBIENT , ambientLightBuffer1 ); gl .
glLightfv ( GL10 . GL_LIGHT1 , GL10 . GL_DIFFUSE , diffuseLightBuffer1 ); gl . glLightfv (
GL10 . GL_LIGHT1 , GL10 . GL_SPECULAR , specularLightBuffer1 ); gl . glLightfv ( GL10 .
GL_LIGHT1 , GL10 . GL_POSITION , lightPositionBuffer1 ); gl . glEnable ( GL10 .
GL_LIGHT1 );
gl . glDisableClientState ( GL10 . GL_TEXTURE_COORD_ARRAY );
gl . glDisable ( GL10 . GL_TEXTURE_2D ); }
// Called once when the OpenGL Surface was created .
public final void initGL ( GL10 gl ){ gl . glDisable ( GL10 .
GL_COLOR_MATERIAL ); gl . glEnable ( GL10 .
GL_CULL_FACE ); gl . glShadeModel ( GL10 .
GL_SMOOTH ); gl . glDisable ( GL10 .
GL_COLOR_MATERIAL ); gl . glEnable ( GL10 .
GL_LIGHTING ); gl . glEnable ( GL10 . GL_CULL_FACE
); gl . glEnable ( GL10 . GL_DEPTH_TEST ); gl . glEnable
( GL10 . GL_NORMALIZE );
} }
Figure 11. Class CustomRenderer
Now that we already have our CustomRenderer implemented, it is time to make
use of it! Open up ObjActivity.java and locate the onCreate method. Here, instanciate a
CustomRenderer object and pass it as the sole argument of the method setNonARRen-
derer of the AndARActivity super class. You will end up with something like the code
in Figure 12.
public void onCreate ( Bundle savedInstanceState ){ super .
onCreate ( savedInstanceState );
CustomRenderer renderer = new CustomRenderer () ;
super . setNonARRenderer ( renderer );
startPreview () ; }
Figure 12. Method onCreate

21
On the next step, we will actually learn how to load, build and display 3D
Aug¬mented Reality objects.
3.4.3. Step III -Loading Obj Mesh Files
This is the principal part of our tutorial! We will learn how to load Wavefront (.obj)
mesh files into memory and how to render with AndAR.
AndAR provides a special class to deal with AR objects. Surprisingly enough, it’s
called ARObject. It has two abstract methods: init and draw. The init method is called
once, and may be used to load resources which need a working OpenGL context, such
as textures or vertex buffers. The draw method is called each frame, whenever the cor-
responding object needs rendering. One thing to notice is that the ModelView matrix is
already correctly applied when the draw method is called. One may scale or translate a
little bit, but generally the matrix set by AndAR already transforms the vertices to the
correct position.
Ok, so let us get started. The first thing we need to do is create a class called Me-
shObject (see Figure 13).
public class MeshObject extends ARObject {
public MeshObject ( InputStream stream , String name , String pattern , double width , double [] center )
throws IOException , Exception { super ( name , patternName , markerWidth , markerCenter ); parseOBJ (
model_stream );
}
@Override public void init ( GL10 arg0 ){}
private FloatBuffer vbuffer = null ; private
FloatBuffer tbuffer = null ; private FloatBuffer
nbuffer = null ; private ShortBuffer ibuffer =
null ;
@Override public void draw ( GL10 gl
){}
public void parseOBJ ( InputStream stream ){} }
Figure 13. Class MeshObject
The MeshObject class extends ARObject, as expected. On its constructor it receives
an InputStream refering to the mesh file which should be opened, a string with
the name of the object, the name of the pattern to associate with the model, the wi-
dth of the pattern and the center of the pattern. We also declare vbuffer, tbuffer, nbuffer
and ibuffer, which respectively store vertices, texture coordinates, normals and indices
and will be used when implementing the draw method. On the constructor, after calling
the constructor of the super calss, we call the parseOBJ method, which will read the
InputStream and allocate the previously refered buffers.

22
Since we will not really need any initialization code which refers to a GL10
in¬stance, we will leave the init method empty and jump to the parseOBJ method. The
parseOBJ method is responsible for reading the InputStream containing an .obj file and
converting its data to OpenGL format, suitable for rendering. Before attempting to read
an .obj file, however, it would be smart to know it’s structure!
The structure of a .obj mesh file is really simple. Data is written line by line, with an
identifier at the beginning of each line. Below we have a few examples of lines typically
found in .obj files (see Figure 14).
Figure 14. Examples of lines found in .obj files.
Line 1: this is a simple comment line, usually seen displaying info about the tool
that generated the file
Line 3: this line tells us to load a file named android.mtl, which will contain mate-
rial information such as diffuse, specular and ambient color, as well as the name of the
texture for that section of the mesh.
Line 5: this is a typical vertex position line. It refers to a position in model space
coordinates, which are always three-dimensional. Note that it does not refer to a
specific face.
Line 7: this line specifies a vertex normal, which are always three-dimensional.
Note that it also does not refer to a face.
Line 9: this line specifies texture coordinates, which are always two-dimensional.
Line 11: this line can be read like this: “from now on, render whatever appears with
the Material1 material”. It usually precedes a set of face lines.

23
Line 13: this specifies whether we want smooth shading or not. The off option
means no smooth shading.
Line 15: this single line is the most important one, since it defines a face. On .obj
files, meshes are made up of triangles or quads. a face line can represent either a tri-
angle or a quad.
The face line starts with an f identifier, then proceeds with three or four vertex
configurations. Each configuration is composed of three one-based indices (as opposed
to zero-based indices from Java and C/C++ arrays). The first refers to a vertex position;
The second, to a texture coordinate; and the third, to a vertex normal. It is easy to see
that the previous lines act as a “database” for further reference, and the face lines are
the ones to actually define the mesh structure. Vertex configurations may also appear
multiple times. We will need some sort of mechanism to detect when they reappear and
not include them twice.
It’s also worth noticing that vertex normals and texture coordinates may be absent
on the .obj file. Thus, the following lines (see Figure 15) are also valid face descriptions,
and respectively represent texture coordinates absence and vertex normals absence.
f 1//1 2//1 3//1 f 1/3
2/1 3/3
Figure 15. Valid faces descriptions.
That was brief for a mesh file description! Now, on to the parseOBJ method. We
will make a few restrictions for the sake of simplicity. We will require the models to be
composed entirely of triangle faces. Also, we will require that texture coordinates and
vertex normals are always present.
For the this method, we will need to declare a few more attributes (see Figure 16).
private HashMap<String , Integer> vertMap = new HashMap<String , Integer >() ; private
ArrayList<Float> vertices = new ArrayList<Float >() ; private ArrayList<Float> normals = new
ArrayList<Float >() ; private ArrayList<Float> tcoords = new ArrayList<Float >() ; private
ArrayList<Integer> indices = new ArrayList<Integer >() ;
Figure 16. The new attributes declared.
Understanding the purpose of these attributes is crucial. They are not intended to
store the vertex positions, texture coordinates and normals as read from the file. They
are used to represent faces of the mesh. Thus, for a given face index i, vertices[i] gives its
position, normals[i] gives its normal and tcoords[i] gives its texture coordinates.
The parseOBJ method opens up an bufferedReader from the InputStream and
al¬locates three databases to store the vertices, normals and texcoords as read from the

24
file. It then passes all these variables as arguments for the parseLoop method if the file
is ready to be read (see Figure 17).
private void parseOBJ ( InputStream in ) throws IOException , Exception
{ indices . clear () ; vertices .
clear () ; vertMap . clear () ;
InputStreamReader reader = new InputStreamReader ( in );
BufferedReader bf = new BufferedReader ( reader );
ArrayList<Float> db_pos = new ArrayList<Float >() ; ArrayList<Float>
db_tcoords= new ArrayList<Float >() ; ArrayList<Float> db_normals =
new ArrayList<Float >() ;
if ( reader . ready () )
{ parseLoop ( bf , db_pos , db_tcoords , db_normals ); bf .
close () ;
reader . close () ; in .
close () ; }
else
{ bf . close () ; reader .
close () ;
in . close () ; throw new Exception ("File not found!" ); } }
Figure 17. Method parseOBJ.
The parseLoop method reads the file line by line. Whenever it detects a vertex, nor-
mal or texcoord line, it stores it on the proper database by using the extract method. The
extract method simply converts a number of elements from the string array passed as an
argument into Floats and adds them to the array list passed as argument. When it finds
a face line, it retrieves the indices of each of the tree configurations presented on the
face line and add them to the indices buffer. The retrieval process is done through the
parseVertex method. After parsing the file, the method will allocate all the FloatBuffers
required for rendering and release the memory. The allocBuffers method hence converts
the data stored in the vertices, normals, texcoords and indices into FloatBuffers, suitable
for OpenGL calls (see Figure 18).

25
@Override public void draw ( GL10
gl ) {
super . draw ( gl );
gl . glEnableClientState ( GL10 . GL_VERTEX_ARRAY ); gl .
glEnableClientState ( GL10 . GL_NORMAL_ARRAY ); gl .
glEnableClientState ( GL10 . GL_TEXTURE_COORD_ARRAY );
gl . glVertexPointer (3 , GL10 . GL_FLOAT , 0, vbuffer ); gl .
glTexCoordPointer (2 , GL10 . GL_FLOAT , 0, tbuffer ); gl .
glNormalPointer ( GL10 . GL_FLOAT , 0, nbuffer );
gl . glDrawElements ( GL10 . GL_TRIANGLES , indices . size () , GL10 . GL_UNSIGNED_SHORT ,
ibuffer );
gl . glDisableClientState ( GL10 . GL_VERTEX_ARRAY ); gl .
glDisableClientState ( GL10 . GL_NORMAL_ARRAY ); gl .
glDisableClientState ( GL10 . GL_TEXTURE_COORD_ARRAY );
}
Figure 18. Method parseLoop.
Now we must review the parseVertex method. This method retrieves the index of
the current vertex. If the string representing the vertex of the face is already inserted in
the vertMap, we simply return its index. If it’s not, we insert each of the components in
the proper attribute list, and store its index on our vertMap (see Figure 19).
private int parseVertex ( String par , ArrayList<Float> pp , ArrayList<Float> nn , ArrayList
<Float> tt )
{ if ( vertMap . containsKey ( par ) ) return vertMap . get ( par );
int index =( vertices . size () /3);
vertMap . put ( par , index );
String [] aux = par . split ("/" ); Integer v = new
Integer ( aux [0]) 1; Integer t = new Integer (
aux [1]) 1; Integer n = new Integer ( aux [2])
1;
// Positions
vertices . add ( pp . get (3 v ) ); vertices .
add ( pp . get (1 +3 v ) ); vertices . add (
pp . get (2 +3 v ) );
/ / Normals
normals . add ( nn . get (3 n ) ); normals
. add ( nn . get (1 +3 n ) ); normals . add
( nn . get (2 +3 n ) );
/ / TCoords
tcoords . add ( tt . get (2 t ) );
tcoords . add ( tt . get (1 +2 t ) );
return index ; }
Figure 19. Method parseVertex.
Now that we know how to load the .obj mesh ﬁle, it is time to learn how to dis-
play them on the screen as Augmented Reality objects! Surprisingly enough, that is the

26
sim¬plest part. This will be done in the draw method of the MeshObject class. For our
draw¬ing method, the first step will actually be calling the draw of our super class (AR-
Object) this will apply the ModelView matrix appropriate for the marker assigned to
our object.
After calling the draw method of the super class, it is time to do our magic. We are
going to draw our mesh with vertex arrays, so we must first enable those vertex arrays!
This can be done by calling glEnableClientState with the proper parameters. Since our
models always have normals and texture coordinates, we turn on GL_NORMAL_AR-
RAY and GL_TEXTURE_COORD_ARRAY besides the GL_VERTEX_ARRAY, which
we would already turn on anyway.
Then we must provite our buffers, so OpenGL actually has data to draw. This can
be done with calls to glVertexPointer, glTexCoordPointer and glNormalPointer. That is
why we needed those FloatBuffers back then!
Finally, it is time to draw the mesh. Since we have done all the hard work already,
drawing is as simple as calling glDrawElements. We are using GL_TRIANGLES, since
werestrictedour.objmodelstobetotallytriangulated.DrawingmesheswithglDrawEle-
ments is actually pretty smart. We provide buffers with vertex, normal and texture data,
and OpenGL consults those buffers to draw our mesh based on an indices list that we
also provide. This way, we do not need to include data twice in our buffers when we have
a vertex shared by many faces on our mesh! We can just duplicate the indices, which cost
much less memory and is more efficient. After drawing, it is also quite polite in OpenGL
to disable the states we have enabled (see Figure 20).
@Override public void draw ( GL10
gl ) {
super . draw ( gl );
gl . glEnableClientState ( GL10 . GL_VERTEX_ARRAY ); gl .
glEnableClientState ( GL10 . GL_NORMAL_ARRAY ); gl .
glEnableClientState ( GL10 . GL_TEXTURE_COORD_ARRAY );
gl . glVertexPointer (3 , GL10 . GL_FLOAT , 0, vbuffer ); gl .
glTexCoordPointer (2 , GL10 . GL_FLOAT , 0, tbuffer ); gl .
glNormalPointer ( GL10 . GL_FLOAT , 0, nbuffer );
gl . glDrawElements ( GL10 . GL_TRIANGLES , indices . size () , GL10 . GL_UNSIGNED_SHORT ,
ibuffer );
gl . glDisableClientState ( GL10 . GL_VERTEX_ARRAY ); gl .
glDisableClientState ( GL10 . GL_NORMAL_ARRAY ); gl .
glDisableClientState ( GL10 . GL_TEXTURE_COORD_ARRAY );
}
Figure 20. Method draw.
This is it for this section. Next step we are going to finish our ObjActivity, and see
how to register our mesh for rendering.

27
4.4. Step IV -Putting It All Together
We have been through a lot in order to load and draw our meshes, but how do we
actually put them to good use?
Now that we have our MeshObject class, it is time to make use of it. Get a .obj model
from any modelling package, and make sure it is triangulated and has normals and
textures. Put it on the assets directory of your project. Now we want to open an Input-
Stream from that file. That can be done with help of the AssetManager class, provided
by the Android API. It has an overly complex method called open, which receives a
string with the name of the asset as single paramenter and returns our InputStream.
With the InputStream, we can create a new instance of our MeshObject class and get
ready to rock.
That is almost all there is to it! The only thing remaining is registering our object
in ARToolKit. The ARToolKit instance can be obtained from the method getArtoolkit()
from the super class AndARActivity, and can be used to register objects with the regis-
terARObject method. The final Activity class looks like the code in Figure 21.
public class ObjActivity extends AndARActivity { ARObject someObject ; ARTo-
olkit artoolkit ; AssetManager am ;
public class ObjActivity extends AndARActivity { ARObject
someObject ; ARToolkit artoolkit ; AssetManager am ;
@Override public void onCreate ( Bundle savedInstanceState ){
super . onCreate ( savedInstanceState );
am = getAssets () ;
CustomRenderer renderer = new CustomRenderer () ; super .
setNonARRenderer ( renderer ); try {
artoolkit = super . getArtoolkit () ; someObject = new MeshObject ( am . open ("models/monkey.obj" ) ,
"monkyboy" , " android . patt " , 80.0 , new double []{0 ,0}) ; artoolkit . registerARObject ( someObject ); }
catch ( Exception e ){
e . printStackTrace () ; }
startPreview () ;
}
@Override
public void uncaughtException ( Thread thread , Throwable ex ){ Log . e (
"AndAR EXCEPTION" , ex . getMessage () ) ; finish () ;
Figure 21. Class ObjActivity -The final version.
And with this, we finish. Now it is time to test and verify the program. In addi¬tion to
this, you have to calibrate the application to recognize the marker that you have choosed.

28
5. Conclusion
In this chapter we teach how to make an application in the Android platform for
Aug-mented Reality using AndAR, a software library for building Augmented Reality
appli-cations. First we present Android and discuss a little about its functionalities and
ad-vantages. After this we talked about Augmented Reality and present some projects in
the area, including the ARToolKit. Finally, we see the details of the development of this
application in the walkthrough.
It is necessary to clarify that this is a basic application. If you liked of the ideas pre-
sented here, you have to research and go more deep on this topic. The application also is
very simple but can be used like example of the use of AndAR.
6. References
ARToolKit (2011). Artoolkit home page. Retrieved from www.hitl.washington.edu/
artoolkit/.
Cawood, S. and Fiala, M. (2008). Augmented Reality: A Practical Guide. Pragmatic
Bookshelf, 1st edition.
Meier, R. (2010). Professional Android 2 Application Development. Programmer to
Programmer. Wiley Publishing.

29
Prototipagem Rápida de Aplicações Interativas de
Realidade Aumentada
Claudio Kirner
Universidade Federal de Itajubá – UNIFEI
ckirner@unifei.edu.br
Abstract
Augmented reality applications are interesting, but they are difficult to develop and
customize, mainly by non-expert people. However, there are authoring tools which make
easy this development. This chapter focuses on the augmented reality authoring problem,
related to the development and use of applications. It describes an authoring tool, showing
how to use it on rapid prototyping of augmented reality interactive applications, without
the need of programming skills. A developed example using this tool is described and the
impact of this approach is discussed, considering different types of potential authors and
applications.
Resumo
As aplicações de realidade aumentada são interessantes, mas difíceis de serem de-
senvolvidas e personalizadas, principalmente por não especialistas em computação. No
entanto, existem ferramentas de autoria que facilitam esse desenvolvimento. Este texto
aborda o problema da autoria de aplicações de realidade aumentada, relacionado com o
desenvolvimento e uso das aplicações, em diversos níveis. É descrita uma ferramenta de au-
toria e seu uso na prototipagem rápida de aplicações interativas de realidade aumentada
por não programadores. Também é mostrado um exemplo desenvolvido com esta técnica
e as repercussões dessa abordagem são discutidas, levando em conta os diversos tipos de
autores e aplicações em potencial.

30
KIRNER, Claudio. Prototipagem Rápida de Aplicações Interativas de Realidade Aumentada.
1. Introdução
As aplicações espaciais mediadas por computador, incluindo navegação, busca de
pontos de interesse, jogos tridimensionais, ferramentas educacionais tridimensionais,
etc., estão aumentando com o uso de realidade aumentada.
Atualmente, a convergência tecnológica permite o desenvolvimento de aplicações
que envolvem diferentes recursos funcionando juntos, como: GPS, acelerômetros, câ-
meras, telefones celulares, notebooks, ipads, etc. A criação dessas aplicações depende
fortemente de programadores e técnicos.
Entretanto, há muitas pessoas sem conhecimento de programação, interessadas em
desenvolver aplicações de realidade aumentada. Para contornar esse problema, algumas
ferramentas de autoria de aplicações estão fornecendo recursos para não programado-
res, a fim de que eles possam criar suas próprias aplicações [Seitchter, Looser e Billin-
ghurst 2008]. É importante mencionar que essas aplicações devem ser independentes
de compiladores, usando, no entanto, edição de texto, procedimentos de configuração,
interface visual e ações tangíveis.
Portanto, a principal questão deste trabalho é: como não programadores poderiam
desenvolver suas próprias aplicações de realidade aumentada, usando recursos de edi-
ção e configuração de parâmetros textuais e manipulação de elementos espaciais? Para
responder essa questão, será feita, inicialmente, uma contextualização dos conceitos en-
volvidos, levando em conta o estado da arte da tecnologia. Depois, será realizada uma
análise das ferramentas de autoria de aplicações de realidade aumentada, enfatizando
suas características relacionadas com independência de programação e/ou conhecimen-
tos técnicos. Em seguida, a ferramenta “Sistema de Autoria Colaborativa com Realida-
de Aumentada” (SACRA) será descrita e discutida, sob o ponto de vista da geração de
aplicações. Os recursos de suporte à ferramenta SACRA serão analisados e descritos e
um exemplo de aplicação será detalhado. Finalmente, serão apresentadas as tendências
da área de realidade aumentada e suas aplicações, procurando destacar características
como custo, disponibilidade, adaptação, customização e personalização.
2. Conceitos de Realidade Virtual e Aumentada
Realidade virtual (RV) e a realidade aumentada (RA) tiveram seus conceitos origi-
nados na década de 1960, com os trabalhos de Ivan Sutherland [Sutherland 1963, 1965,
1968]. De lá para cá, muita coisa mudou e a tecnologia evoluiu, exigindo, em certos
casos, uma atualização dos conceitos.

31
2.1. Realidade Virtual
A RV surgiu como uma primeira opção de interface tridimensional, propiciando ao
usuário interações naturais, com o uso das mãos, em ambientes virtuais renderizados na
tela do monitor, em projeções em tela, ou em projeções nos olhos, através de capacetes
de RV (Head Mounted Display – HMD). Para a interação com os elementos virtuais, são
necessários dispositivos especiais multisensoriais, como luvas com sensores e rastreado-
res, dispositivos de tato e força, mouses 3D, óculos estereoscópicos, emissores de sons
espaciais, etc.
Uma definição de RV é: “realidade virtual é uma interface computacional avançada
que envolve simulação em tempo real e interações, através de canais multisensoriais”
[Burdea e Coiffet 2003].
Outra definição é: realidade virtual é uma interface computacional que permite ao
usuário interagir, em tempo real, em um espaço tridimensional gerado por computador,
usando seus sentidos, através de dispositivos especiais.
O usuário pode perceber o mundo virtual, através de uma janela constituída pela
tela do monitor ou pela tela de projeção, ou ser inserido no mundo virtual, através de
HDM ou de salas com multiprojeção (cavernas) e dispositivos de interação.
Quando o usuário é transportado totalmente para mundo virtual, através de dispo-
sitivos multisensoriais como HDM e salas de multiprojeção, a realidade virtual é deno-
minada “Imersiva” (Figura 1a). Quando o usuário é transportado parcialmente, perce-
bendo o mundo virtual através de uma janela, como a tela do monitor ou equivalente, a
realidade virtual é denominada “Não Imersiva” (Figura 1b).
Figura 1. Realidade virtual imersiva e não imersiva

32
2.2. Realidade Aumentada
A definição de RA tem sido atualizada, em função da evolução tecnológica. Ini-
cialmente, o aumento do ambiente real ocorria através de elementos visuais; mas, com o
desenvolvimento de interações sonoras e hápticas associadas a posições espaciais, ocor-
rendo em tempo real, houve uma expansão no conceito.
Neste contexto, uma definição mais abrangente é que realidade aumentada consiste
no enriquecimento do mundo físico com objetos virtuais devidamente posicionados em
tempo real, através de algum dispositivo tecnológico. A Figura 2 ilustra o resultado do
enriquecimento do mundo físico com elementos virtuais.
Figura 2. Ambiente de realidade aumentada
Uma definição mais atualizada é: realidade aumentada é uma interface baseada
na sobreposição de informações virtuais geradas por computador (envolvendo imagens
estáticas e dinâmicas, sons espaciais e sensações hápticas) com o ambiente físico do
usuário, percebida através de dispositivos tecnológicos e usando as interações naturais
do usuário, no mundo físico.
Uma maneira de trazer as informações virtuais para o espaço físico do usuário
é usando uma webcam, que captura dinamicamente as imagens do ambiente físico e
rastreia determinadas posições, permitindo que o computador introduza ou acione in-
formações virtuais associadas com as posições. O resultado pode ser visto, ouvido e
sentido em monitores, projeções, capacetes e dispositivos hápticos, dando sensação de
realismo ao ambiente híbrido.
3. Trabalhos Relacionados
Durante os últimos dez anos, surgiram várias ferramentas de autoria de aplicações
de realidade aumentada, voltadas para o desenvolvimento de aplicações especiais me-
diadas por computador.

33
Essas ferramentas podem ser classificadas, de acordo com suas características de
programação e de projeto de conteúdo em baixo nível e alto nível, apresentando di-
ferentes abstrações de conceito e complexidade de interface [Hampshire et al. 2006],
[Seitchter, Looser e Billinghurst 2008].
Programação é, geralmente, mais complexa, apresentando mais flexibilidade e pos-
suindo menor nível de abstração de conceito do que projeto de conteúdo. Projeto de
conteúdo tende a ser menos complexo e flexível, apresentando maior nível de abstração
de conceito. Portanto, conforme a abstração de conceito aumenta, a interface fica mais
simples e menos flexível.
Ferramentas de programação são baseadas em APIs básicas ou avançadas, con-
tendo bibliotecas, envolvendo tarefas como: visão computacional, ajustes de imagem,
renderização tridimensional, sons, entrada e saída e outras funções. ARToolKit [Kato e
Billinghurst 1999], MR [Uchiyama et al. 2002] em MX [Dias et al. 2003] são exemplos
de ferramentas de programação de baixo nível, enquanto que Studierstube [Schmalstieg
et al. 2002], OrgArt [Looser 2006] e DWARF [Bauer et al. 2001] são ferramentas de pro-
gramação de alto nível.
ARToolKit é uma das primeiras ferramentas de realidade aumentada que usam mar-
cadores e visão computacional. Para utilizá-la criar aplicações de realidade aumentada,
os desenvolvedores precisam ter habilidades com programação em C/C++.
Ferramentas de projeto de conteúdo eliminam a dependência da linguagem de pro-
gramação, substituindo-a pela descrição dos objetos virtuais e de seus relacionamentos
com o ambiente real.
APRIL [Ledermann e Schmalstieg 2005] é um exemplo de baixo nível desse tipo de
ferramenta, que requer descrições em XML. Ferramentas de projeto de conteúdo de alto
nível usam interfaces gráficas de usuários (GUI) para representar as descrições e inte-
rações, como ocorre com: DART [MacIntyre et al. 2004], AMIRE [Grimm 2002], ECT
[Hampshire et al, 2006], ComposAR [Seitchter, Looser e Billinghurst 2008] e ARSFG
[Di Wu e Liu 2009].
DART é uma ferramenta implementada sobre o Macromedia Director, usando um
modelo de autoria visual do tipo “pegar-arrastar-soltar” e uma linguagem de script (des-
crições textuais) interpretada.
AMIRE baseia-se em uma estrutura que usa a tecnologia orientada a componentes,
apresentando: um conjunto mínimo de componentes para demonstração, uma coleção
de recursos reusáveis e uma ferramenta de autoria visual.
ECT é uma ferramenta de software orientada a componentes, com uma interface de
programação visual projetada para facilitar o desenvolvimento de aplicações de realidade
aumentada, por usuários com pouca ou nenhuma experiência em programação.
ComposAR é uma ferramenta extensível, para autoria de aplicações de realida-
de aumentada por usuários não programadores. Ela suporta script e interface do tipo

34
“pegar-arrastar-soltar”, além de entrada interpretada em tempo real e funcionalidades
adicionadas por usuários.
ARSFG é uma ferramenta de software para prototipagem rápida de aplicações de
realidade aumentada, baseada em grafos de cena, que permite colaboração remota atra-
vés de protocolo baseado em XML.
Um projeto de conteúdo em alto nível deve ser mais intuitivo e adequado para não
programadores. Por isso, exige que suas ferramentas suportem script e/ou interface visual,
novas funcionalidades adicionadas pelos usuários e interpretação em tempo real.
A ferramenta SACRA, enfocada nesse trabalho, difere das demais aqui indicadas,
uma vez que possui as seguintes características:
A ferramenta foi implementada sobre o ARToolKit;•
A autoria de aplicações depende da edição de arquivos de configuração e/ou•
de operações tangíveis;
Há diferentes níveis de autoria, que podem ser usados, dependendo das habili-•
dades dos desenvolvedores, que não precisam ser programadores;
Há um suporte colaborativo que permite múltiplos usuários remotos atuando•
no ambiente compartilhado de realidade aumentada, usando ações tangíveis.
O desenvolvedor das aplicações pode usar ações tangíveis, edição de arquivos•
de configuração, e mouse e teclado, mas o usuário final poderá interagir com a
aplicação de realidade aumentada, usando somente um ou dois marcadores.
4. Descrição da Ferramenta SACRA
O desenvolvimento de aplicações de realidade aumentada depende de: estrutura
de dados e pastas que suportam a ferramenta de autoria; interface de autoria, incluindo
tarefas de configuração e comandos; e procedimentos de utilização que permitem ao
usuário final navegar ambiente aumentado e interagir com ele.
Para facilitar o desenvolvimento de aplicações de realidade aumentada, foi criada
a ferramenta de autoria SACRA - Sistema de Autoria Colaborativa com Realidade Au-
mentada [Kirner e Santin 2009]. Essa ferramenta apresenta características próprias de
autoria e de uso, além de possibilitar a colaboração remota compartilhada.
A ferramenta SACRA foi construída sobre o ARToolKit, incluindo também fun-
cionalidades adicionais programadas em C/C++. Manuais e exemplos de aplicação do
SACRA são distribuídas livremente pelos autores [Kirner 2011].

35
4.1. Estrutura do Ambiente de Realidade Aumentada
RA envolve muito mais do que sobrepor objetos virtuais com o mundo físico. Neste
trabalho, o ambiente aumentado (Figura 3a) contém: objetos reais; objetos virtuais in-
terativos, que são alterados em certas situações; objetos virtuais animados, que podem
ser ativados ou desativados; objetos virtuais visíveis ou invisíveis, que desaparecem e
aparecem em certos casos; pontos virtuais visíveis ou invisíveis, que podem ser ativa-
dos ou desativados; sons associados aos objetos; e pontos, que podem ser acionados ou
desacionados, etc.
Além disso, o ambiente de realidade aumentada pode ser modificado, depois de ser
elaborado, usando criação, alteração e eliminação de pontos virtuais, objetos virtuais e
sons associados.
Figura 3. Organização do ambiente de RA
4.2. Estrutura de Dados e Pastas
A estrutura de dados do ambiente de RA (Figura 3b) a ser elaborado, tem como raiz
os marcadores de referência. Um marcador de referência possui uma base virtual asso-
ciada, contendo pontos virtuais, objetos virtuais e sons que aparecem ou são adiciona-
dos na base, de acordo com a Figura 3a. Esses elementos devem ser colocados em pastas
(Figura 3c), que o desenvolvedor deverá manipular para criar o ambiente de RA.
A ferramenta tem cinco tipos de pastas, configuráveis pelo desenvolvedor, sendo
que algumas delas podem conter arquivos também configuráveis. Essas pastas referem-
se a: posição dos pontos virtuais; posição dos objetos virtuais; objetos virtuais; texturas
e sons. Os sons podem ser associados aos objetos virtuais ou, na falta deles, às posições
dos pontos virtuais (Figura 3c). Dependendo do tipo de aplicação e do nível de autoria,
o desenvolvedor poderá manipular um conjunto menor de pastas, envolvendo somente
texturas e sons, por exemplo. Neste caso, a autoria fica extremamente simplificada, em-

36
bora restrita, permitindo que pessoas com pouco conhecimento de informática possam
ser autores de ambientes de realidade aumentada.
Nas seções seguintes, serão apresentados exemplos desse tipo de autoria, que é mui-
to útil para a área educacional, permitindo que professores do ensino fundamental e
médio, com poucos recursos e conhecimento na área de informática, possam desenvol-
ver aplicações educacionais específicas.
4.3. Interfaces de Autoria
Na fase de autoria, a aplicação de RA pode ser desenvolvida por meio de edição
de pastas e arquivos e/ou ações tangíveis realizadas no campo de visão da webcam. Os
recursos necessários para criar pontos virtuais, associando a eles objetos virtuais e sons,
são: marcadores de ações; botões do teclado; botões do mouse; e pastas e arquivos de
configurações.
Marcadores de Ações
Marcadores de ações permitem a execução de ações tangíveis capazes de manipular
pontos e objetos virtuais associados à base virtual, conforme a Figura 4.
Figura 4. Ambiente de RA e seus marcadores
Nesse ambiente, pontos e objetos virtuais, ligados a um marcador de referência,
possuem pequenas esferas virtuais visíveis ou invisíveis com eles associadas. Cada mar-
cador de ação também tem uma pequena esfera, virtual que pode ser manipulada pelo
usuário, visando colidí-la com alguma esfera associada ao marcador de referência.
Quando o marcador de ação é movimentado no ambiente de realidade aumentada,
sua esfera virtual serve como um ponteiro capaz de tocar as esferas virtuais associadas ao
marcador de referência, executando ações nos pontos ou objetos virtuais correspondentes.
As colisões, que selecionam os pontos ou objetos virtuais, dependem de certas situações do
marcador de ação, para que as ações sejam executadas. No SACRA, a colisão mantida por

37
alguns milissegundos é que seleciona o objeto, mas gestos como inclinação ou oclusão do
marcador também podem ser usados em certas situações.
Os marcadores de ações usados no SACRA são:
Inspeção: mostra o objeto virtual associado ao ponto virtual;•
Controle: mostra o próximo objeto virtual de uma lista de objetos associados•
ao ponto virtual;
Transporte: leva um objeto virtual de uma posição para outra;•
Apagamento: apaga um ponto virtual e seu objeto ou lista de objetos;•
Status: mostra uma placa virtual com informações sobre o sistema;•
Trava: trava ou destrava ações remotas em objetos associados a um ponto vir-•
tual;
Cópia: replica o objeto virtual a ser colocado em outra posição de outro mar-•
cador de referência;
Trajetória: permite criação e visualização de uma trajetória visual feita de uma•
posição a outra.
Teclado e Mouse
Algumas teclas do teclado e botões do mouse podem ativar ações complementares no
ambiente de RA, atuando sozinhos ou em conjunto com os marcadores de ações.
Essas teclas e botões podem ativar ou desativar: visualização de pontos e objetos
virtuais; operações remotas; criação de trajetórias; visualização de status; persistência de
objetos virtuais; etc. Eles também podem controlar a posição e o raio das esferas virtuais
associadas com os marcadores, para melhorar a precisão e desempenho no processo de
seleção de pontos e objetos virtuais. Quanto menor for o raio das esferas virtuais, maior
será a dificuldade de seleção, mas, em alguns casos, quando houver pontos próximos,
será necessário obter melhor precisão, para ser bem sucedido na operação.
O botão do mouse, atuando conjuntamente com o marcador de inspeção, permitirá a
criação visual de pontos virtuais no ambiente de realidade aumentada, possibilitando uma
reconfiguração posterior através da edição de arquivos de configuração.
A lista de teclas e ações do mouse que são considerados no SACRA pode ser obtida
no site da ferramenta [Kirner 2011].
Arquivos de Configuração
Os arquivos de configuração do SACRA podem ser criados pelo usuário ou edi-
tados, a partir dos arquivos contidos na versão de distribuição (Figura 5). Além disso,
também é possível editar os arquivos gerados no processo de criação visual de pontos
virtuais.

38
Esses arquivos contêm informações de autoria fornecidas pelo usuário, de forma a
preparar o sistema para uso ou para configurações visuais complementares.
Os arquivos de configuração editáveis são:
a) Arquivo do Marcador de Referência (refi.dat), contendo:
indicação da base virtual associada com o marcador;•
posição, orientação e escala da base virtual;•
indicação do som associado com a base virtual, se existir;•
indicação da lista de pontos virtuais;•
indicação do ponto virtual de ativação da lista.•
Figura 5. Pastas e arquivos da versão de distribuição do SACRA
Esse arquivo encontra-se na pasta <SACRAWrlreference>, na versão de distribui-
ção, tendo a aparência mostrada na Figura 6a.
Figura 6. Arquivos de configuração do SACRA

39
b) Arquivo da Lista de Pontos de um Marcador de Referência (prefi.dat), contendo:
posição e orientação do ponto que irá receber a lista de objetos virtuais e•
sons;
endereço da lista de objetos virtuais com seus sons.•
Esse arquivo encontra-se na pasta <SACRAposition>, na versão de distribuição
(Figuras 6b1 e 6b2).
O arquivo da Figura 6b1 foi criado por meio de edição e mostra um ponto virtual
com uma lista de objetos.
O arquivo da Figura 6b2 mostra três pontos virtuais, cada um com uma lista di-
ferente de objetos. Esses pontos virtuais foram criados por autoria visual, motivo pelo
qual possuem parâmetros não exatos.
c) Arquivo de uma Lista de Objetos Virtuais de um Ponto (ex. animais.dat), con-
tendo:
objeto virtual 1:•
indicação do modelo 3D do objeto virtual 1;•
posição, orientação e escala do objeto virtual 1;•
indicação do som associado com o objeto virtual 1.•
objeto virtual m;•
informações similares no objeto virtual 1.•
Um editor de texto simples, como o bloco de notas, pode ser usado para criar ou
editar os arquivos de configuração.
Esse arquivo encontra-se na posição <SACRAanimais>, na versão de distribuição
(Figura 6c).
Pastas
As pastas mencionadas aqui são recursos preenchidos pelo desenvolvedor não pro-
gramador, contendo informações úteis para a criação do ambiente de RA aumentada.
Há quatro pastas no sistema SACRA, contendo: informações de configuração de
posição de pontos (position); lista de objetos virtuais, contendo informações de configu-
ração de posições dos objetos virtuais e sons e os próprios objetos virtuais (ex. animais);
sons (audio); e texturas (textura), conforme a Figura 7.

40
Figura 7. Hierarquia de recursos do SACRA
A pasta de informações de posição de pontos (position) contém arquivos de confi-
guração relativos aos marcadores de referência, indicando seus pontos e listas de objetos
virtuais. A pasta com uma lista de objetos virtuais (ex. animais) contém o arquivo de
configuração dos objetos da lista, indicando suas posições e os sons associados, e os
próprios objetos virtuais. A pasta de sons contém todos os sons usados no sistema, in-
cluindo as narrações. A pasta de texturas (textura) contém imagens usadas nos objetos
virtuais para dar mais realismo ou passar informações.
Os conteúdos das pastas devem ser ali colocados antes de serem usados, mas alguns
deles podem ser modificados durante a fase de utilização, principalmente os arquivos
de configuração.
O SACRA também tem comandos para salvar e restaurar o ambiente de RA, de
forma que a autoria possa ser interrompida e continuada depois.
Procedimentos de Utilização
Na fase de utilização, o usuário final deverá manipular o ambiente de realidade
aumentada, usando ações tangíveis com marcadores específicos.

41
Os marcadores mais usados são os de Inspeção e Controle, que permitem a exploração
do ambiente, mostrando os objetos virtuais e os sons associados em cada ponto.
Entretanto, visando deixar o sistema mais potente, é possível reconfigurar o ambien-
te durante a fase de utilização, alterando o ambiente de RA inicialmente projetado. Esse
procedimento permite uma personalização do ambiente. O usuário, poderá então mudar
a visibilidade dos pontos e objetos virtuais, trocar alguns objetos virtuais por outros,
fazer cópia e movimentar objetos virtuais, eliminar pontos e objetos virtuais, etc. Essas
ações são simples e requerem menor esforço, em comparação com a autoria inicial.
Assim, a reconfiguração estática do ambiente de realidade aumentada, obtida através
de edição de arquivos de configuração, juntamente com a reconfiguração dinâmica, obtida
por meio de alteração de elementos do ambiente e de ações tangíveis importantes para a
personalização da aplicação, são muito úteis em jogos e em aplicações educacionais.
Além disso, o sistema tem um marcador de referência especial (Ref1), que permite
interligar vários usuários em rede, atuando sobre o mesmo ambiente de Ra e proporcio-
nando trabalhos colaborativos remotos. Quando o usuário coloca o marcador de refe-
rência colaborativo (Ref1), ele é conectado à rede e passa a interagir em um ambiente
compartilhado de RA, explorando e alterando os elementos local e remotamente. Esta
característica é muito útil em jogos e aplicações educacionais, permitindo o trabalho em
grupo de usuários remotos.
5. Recursos para o Desenvolvimento de Aplicações de RA
Além da ferramenta de autoria SACRA, o desenvolvedor precisará conhecer e usar
alguns softwares para ter sucesso na elaboração do ambiente de RA. Ele deverá ser capaz
de capturar, produzir e editar imagens, sons e objetos virtuais estáticos e animados.
5.1. Preparação de Imagens
As imagens, no ambiente de realidade aumentada, são utilizadas como texturas
para os objetos virtuais, visando fornecer maior realismo ou renderizar informações
(figuras e anotações) para os usuários.
Essas texturas podem ser feitas à mão e escaneadas, capturadas de bibliotecas em
repositórios multimídia ou produzidas com o uso de editores de texto e de imagens.
Qualquer editor de texto ou de texto e imagem, como Bloco de Notas, Word, Power-
Point ou recursos do OpenOffice, pode ser útil na elaboração da textura.
Para capturar texturas da tela do computador, no formato jpg, usa-se algum captu-
rador de imagem como o Free Screen Hunter [Wisdom Software 2011]. Deve-se ter um
cuidado especial para que os arquivos das texturas capturadas, produzidas ou editadas

42
sejam leves e com boa qualidade de imagem, para que a aplicação, envolvendo um gran-
de número de texturas, não dificulte o processo de distribuição pela Internet.
5.2. Preparação de Sons e Narrações
Os sons, acionados quando os objetos virtuais são ativados, podem ser ruídos ou
narrações. Eles podem ser obtidos de repositórios ou gravados. No caso de narrações,
a gravação é mais apropriada, uma vez que dificilmente será encontrada uma narração
específica.
Qualquer software de gravação de som pode ser usado, desde que o arquivo resul-
tante seja leve e do tipo wav, pelos mesmos motivos já explicados para imagens.
Um software de gravação de sons interessante é o Free Sound Recorder [FreeAu-
dioVideo 2011], que é bem intuitivo e permite selecionar a qualidade do som. Assim,
narrações com qualidade baixa podem ser usadas, pois o interesse está na informação.
5.3. Preparação de Objetos 3D e Animações
Como o SACRA é baseado em objetos virtuais do tipo VRML, é necessário que a
captura, produção e edição desses objetos tenha capacidade para tratar esse formato.
A captura de objetos 3D de repositórios VRML está ficando difícil, uma vez que
esse formato é um pouco antigo. No entanto, é possível usar editores de modelos 3D que
convertem outros formatos para VRML, utilizando-se assim outros repositórios mais
recentes, como o Armazém 3D do Google.
Outra maneira de se obter os objetos virtuais VRML é produzí-los diretamente,
usando textos, ou visualmente usando ferramentas como Vivaty, Blender, SketchUp,
3DS Max, etc., que possuem recursos para exportação dos modelos em VRML.
Além do modelo estático, é muito útil dispor-se de modelos animados. Os softwa-
res de modelagem já citados fazem bem essa tarefa, com destaque para o Vivaty, pela sua
leveza e simplicidade.
Da mesma maneira que as imagens e sons, recomenda-se produzir arquivos leves
para o bom desempenho do SACRA, bem como para facilitar a distribuição da aplicação
de RA.
5.4. Outras considerações
Embora o uso de vídeo e de gif animado seja interessante no ambiente de realidade
aumentada, o SACRA não permite esse tipo de recurso. No entanto, novas versões do
SACRA, como a que estamos desenvolvendo com FlartoolKit [Saquoosha 2011], deverão

43
permitir formatos de objetos 3D mais modernos, como COLLADA, e o uso de vídeo e
gif animado, aplicados como texturas.
6. Prototipagem Rápida de uma Aplicação de Multimídia Espacial com RA
Embora o SACRA e outras ferramentas de autoria de aplicações de RA sejam po-
tentes, muitas vezes usa-se muito pouco de suas potencialidades para desenvolvimento
de aplicações mais simples. É o caso de aplicações de multimídia espacial com realidade
aumentada, que permite o acionamento de pontos no espaço para mostrar informa-
ções interativas visuais e sonoras. Embora simples, essas aplicações atendem a maioria
das necessidades dos usuários em certos campos do conhecimento, além de serem mais
acessíveis e fáceis de serem personalizadas, por possuírem interfaces mais simples e
amigáveis. Por outro lado, essas aplicações não exploram todo potencial da renderização
tridimensional, mas este é o preço da simplicidade de elaboração e de uso da aplicação
de RA, usando multimídia espacial.
Para ilustrar o processo de prototipagem rápida de aplicações multimídia com RA,
será utilizado o desenvolvimento do jogo de perguntas e respostas P&R-RA (ou Q&A-
AR, em inglês).
O desenvolvimento do jogo pode ocorrer em dois níveis: 1º) desenvolvimento da
estrutura do jogo; 2º) desenvolvimento do conteúdo do jogo (Figura 8).
Figura 8. Diagrama de camadas de uma aplicação de RA com SACRA
Esses dois níveis de desenvolvimento podem ser obtidos por prototipagem rápida,
sendo que o primeiro, usando o SACRA, exige algum conhecimento de modelagem 3D e
posicionamento espacial, além de um certo domínio da linguagem VRML e de suas fer-

44
ramentas. O segundo nível limita-se ao desenvolvimento de conteúdo (texturas e sons),
permitindo que usuários sem conhecimento de programação e com o mínimo conhe-
cimento de informática, possam produzir suas próprias aplicações com pouco esforço
e rapidez. Essa situação encaixa-se perfeitamente no perfil dos professores de ensino
fundamental e médio, interessados em produzir aplicações personalizadas para as suas
salas de aula.
6.1. Descrição do Jogo Educacional de Perguntas e Respostas
O jogo educacional de perguntas e respostas suportado por RA foi elaborado como
um artefato formado por dois planos perpendiculares, contendo um plano vertical para
mostrar de perguntas e respostas e um plano horizontal para interação e complementa-
ção de informações (Figura 9a).
Figura 9. Estrutura física e virtual do jogo
O jogo é baseado em uma corrida de carros, em que o sistema faz perguntas e os
usuários respondem e verificam se as respostas estão certas ou erradas. Se um usuário
acertar, ele ganhará pontos e receberá instruções para mover seu carro para frente, no
trajeto. Se errar, ele não ganhará pontos e receberá instruções para recuar seu carro no
trajeto. O conjunto de perguntas e respostas deverá ser focado em um determinado tema
ou poderá ser de conhecimentos gerais.
O jogo tem uma série de pontos físicos coloridos nos planos e sobre os carros, além
de pontos virtuais coincidentes com os pontos físicos (Figura 9b). Um ponteiro físico
com um marcador associado será o responsável pelas interações, de forma que a ponta
do marcador tenha um ponto virtual que fará colisão com os pontos virtuais dos planos
e dos carros (Figura 10a).

45
Figura 10. Recursos físicos e virtuais do jogo
O ponto virtual de um carro só será ativável, quando o carro estiver sobre uma
célula da trajetória (Figura 10b), fazendo com que seu ponto físico coincida com o ponto
espacial da célula do trajeto.
Figura 11. Ambiente de RA e detalhes da interação
Para o jogo funcionar, o artefato deverá ser colocado no campo de visão da webcam
e seu aplicativo deverá ser executado. A visualização ocorrerá na tela do monitor e o
computador emitirá sons em resposta às interações (Figura 11a).
No primeiro toque no ponto da célula sobre o carro (Figura 12), o sistema apre-
sentará a pergunta ilustrada no plano vertical com as opções de resposta e informações
complementares no plano horizontal.

46
Figura 12. Ativação da pergunta
Além disso, o usuário deverá marcar, no plano horizontal, a opção que ele acredita
estar correta (Figura 13). Para isto ele deverá aproximar o ponteiro com o marcador
de Controle (C) do botão impresso, correspondente à opção que ele julga estar correta,
ativando-o, de forma a ficar na cor azul. Se o usuário decidir mudar a opção, ele poderá
desativar o botão ativado, usando novamente o ponteiro e ativar outro botão de sua
preferência.
Figura 13. Ativação da opção correta
O segundo toque no mesmo local (Figura 14) mostrará a resposta no plano vertical
e marcará a opção correta no plano horizontal. Se a opção marcada pelo sistema coinci-
dir ou não com a opção do usuário, ele identificará seu acerto ou erro e verá as instru-
ções sobre o que fazer, avançando ou recuando seu carro e anotando seus pontos.

47
Figura 14. Ativação da resposta
Finalmente, o usuário desativará os pontos ativos, preparando o jogo para o pró-
ximo usuário, e moverá o seu carro para a nova posição, de acordo com as instruções
(Figura 15).
Figura 15. Desativando os pontos e movendo o carro
6.2. Implementação da Estrutura do Jogo
A estrutura física do jogo educacional foi construída com dois planos perpendi-
culares feitos de isopor, mas poderiam ter sido usados outros materiais como madeira,
plástico, etc. O marcador, os pontos físicos (botões) e a trajetória com as células do jogo
foram impressos e colados. Os acessórios, como ponteiros com marcadores, dados e
carros, também foram construídos com isopor (Figura 9a).

48
A estrutura virtual foi constituída de planos e botões virtuais coincidentes com
seus equivalentes físicos (Figura 9b), para permitir a colocação de informações e intera-
ção eficiente baseados nos elementos físicos. Ao interagir com elementos físicos, os ele-
mentos virtuais serão acionados mostrando imagens e emitindo sons (Figuras 12 a 14).
O SACRA foi usado para o estabelecimento das posições dos pontos, objetos virtu-
ais e sons. O Vivaty foi usado para a modelagem dos objetos virtuais (VRML) e vincu-
lação com as texturas, contendo informações (perguntas, respostas e instruções) para
o usuário.
Os formatos do arquivo de posicionamento dos pontos, referente à estrutura (pref2.
txt), e dos arquivos com as listas de objetos virtuais de um ponto (path1.dat) podem
ser vistos na Figura 16. O jogo educacional poderá ser baixado para uso ou alteração, a
partir do site da ferramenta SACRA [Kirner 2011 ].
Figura 16. Arquivos da estrutura do jogo (pref2 e path1)
6.3. Desenvolvimento de Conteúdo e Personalização
Para permitir o desenvolvimento rápido de conteúdo, o jogo foi baseado em texturas
e sons (Figura 17) que podem ser preparados por usuários com poucos conhecimentos
de informática. Embora haja outras pastas de texturas (imagens que irão aparecer no
artefato), o desenvolvedor de conteúdo precisará acessar somente as pastas de perguntas
e respostas, utilizando os nomes dos arquivos, conforme a definição dada pelo sistema
como (qv1-1, qv1-2, qv1-n), (av1-1, av1-2, av1-n), (qh1-1, qh1-2, qh1-n) e (ah1-1, ah1-2, ah1-
n), para n perguntas no ponto 1, e assim por diante para os outros pontos da trajetória,
podendo variar o número de perguntas em cada ponto.

49
Figura 17. Conteúdo do jogo (texturas e sons) para uma pergunta e resposta
Essas texturas podem ser preparadas manualmente e escaneadas por usuários com
pouco conhecimento de informática, de forma a viabilizar o uso do artefato por todos os
interessados, mesmo que não possuam experiência no uso de recursos computacionais.
A Figura 18 mostra um conjunto de perguntas preparado por professores do ensino de
ciências do ensino fundamental e médio, simulando o trabalho de usuário leigo em in-
formática. Esse conteúdo foi preparado com escrita manual e colagem de figuras e, em
seguida, escaneado para uso no artefato.
Figura 18. Conteúdo feito à mão

50
Para os usuários com conhecimentos de informática suficientes para manipular
editores de textos e imagens, a montagem das perguntas e respostas fica mais simples
rápida, usando os recursos computacionais (Figura 19). Algum capturador de imagem
da tela do computador, como o Free Screen Hunter, será útil para a preparação das ima-
gens que serão usadas como texturas.
Figura 19. Conteúdo preparado com editores
Os sons (ruídos, músicas, narrações) poderão ser capturados de repositórios ou
gravados com algum software, como o Free Sound Recorder.
Assim, o conteúdo do jogo pode ser criado, editado ou reformulado, através da mon-
tagem de texturas e gravação ou captura de sons. Essa facilidade permite a personaliza-
ção do jogo educacional para uso em turmas ou grupos de pessoas ou alunos.
Para personalizar o jogo educacional, o professor ou supervisor deverá executar os
seguintes procedimentos:
a) Verificar as pastas de texturas relativas a perguntas e respostas para ver quan-
tas texturas existem em cada uma.
b) Preparar o mesmo número de perguntas ilustradas (para o plano vertical), per-
guntas textuais (para o plano horizontal), respostas ilustradas (para o plano
vertical) e ações de resposta (para o plano horizontal), usando um editor de
textos e os gabaritos (templates) para cada caso;
c) Capturar as partes das telas das questões, respostas e ações como arquivos de
imagem do tipo JPG, por exemplo, renomeando-os com os mesmos nomes dos
arquivos equivalentes existentes em cada pasta.
d) Substituir as texturas antigas pelas novas.
e) Gravar novos sons e/ou narrações associados com cada pergunta e resposta,
mantendo os mesmos nomes de arquivos correspondentes aos anteriores.
f) Substituir os sons e/ou narrações antigos pelos novos.

51
Se o professor/supervisor quiser aumentar a quantidade de perguntas e respostas
associadas com um ponto específico da trajetória, ele precisará: preparar novas textu-
ras e novos sons e/ou narrações, colocá-los nas respectivas pastas e editar o arquivo de
configuração de objetos no ponto (path(i).dat contido na pasta wrl). Além disso, novas
estruturas de perguntas e respostas (modelos VRML) deverão ser criadas por replicação
e editadas para ajustar os endereços das respectivas texturas.
No caso de diminuir a quantidade de perguntas e respostas, será necessário editar o
arquivo de configuração path(i).dat, eliminando as referências aos blocos das perguntas
e respostas a serem descartadas.
Com esse processo, o professor/supervisor poderá personalizar o jogo educacional
de forma a explorar temas específicos e diferentes quantidades de perguntas, respostas
e ações, melhorando a qualidade do jogo.
Se o desenvolvedor quiser ilustrar as perguntas e respostas com modelo 3D está-
ticos ou animados, ele poderá criar um ponto no espaço para a renderização do objeto
virtual e um ponto em algum lugar de um dos planos para servir como ativador. Para
isto, basta replicar um dos pontos da trajetória e editá-lo para exibir o objeto virtual,
além de inserí-lo no arquivo de pontos do marcador de referência.
7. Conclusões
Este trabalho discutiu a autoria de aplicações de realidade aumentada e mostrou
como a ferramenta SACRA pode ser usada para facilitar o trabalho de desenvolvimento.
Além disso, foi mostrado que, mediante certas estratégias, pode-se acelerar o desenvol-
vimento de aplicações obtendo-se um processo de prototipagem rápida.
Apesar da ferramenta SACRA ser baseada no ARToolKit e em VRML, esses recur-
sos ficam confinados e transparentes, quando se faz desenvolvimento de conteúdo, de
forma que, para o desenvolvedor final ou usuário, não interessa o que está por baixo da
aplicação, mas sim seu funcionamento e desempenho.
Mesmo assim, encontra-se em desenvolvimento uma ferramenta com o potencial
do SACRA, usando FlarToolKit, para atualizar o software e superar as restrições relacio-
nadas com o uso de vídeo. Além disso, serão incorporados módulos de inteligência, que
poderão ser associados aos objetos virtuais, visando fazer com que a nova ferramenta
seja um sistema de autoria de aplicações de hiper-realidade.
O desenvolvimento do conteúdo do jogo educacional, para ajustar-se aos temas de
interesse do professor/supervisor, mostrou-se bastante simples e rápido. Espera-se que
este seja um dos vários artefatos interativos com realidade aumentada a serem disponi-
bilizados para professores, visando elevar o nível do ensino e aprendizagem, principal-
mente na educação básica.

52
Com isto, espera-se contribuir para que a alta tecnologia possa ser usada por todos
os cidadãos, incluindo aqueles de classes menos favorecidas, através de aplicações com
realidade aumentada gratuitas, simples de aprender e de usar, com alta disponibilidade
e personalizável.
Agradecimentos
Agradeço ao Rafael Santin, que desenvolveu o software SACRA como trabalho de
mestrado, sob minha orientação; aos alunos Eduardo Shiwaku Okawa e Hipólito Dou-
glas Moreira, que me ajudaram na digitação; às professoras Gisele Maria P. Garcia e
Marília L. Paiva e Silva, pelas amostras de perguntas feitas à mão; e ao CNPq e FAPE-
MIG pelo financiamento a projetos, em cujo contexto foram realizados experimentos de
artefatos interativos com realidade aumentada.
Referências
Bauer, M., Bruegge, B., Klinker, G., MacWilliams, A., Reicher, T., Riss, S., Sandor, C. e
Wagner, M. (2001) “Design of a Component-based Augmented Reality Framework” In
ISAR’01, IEEE and ACM International Symposium on Augmented Reality, New York,
USA, pp. 45-54.
Burdea, G.C. e Coiffet,P., Virtual Reality Technology, Wiley-Interscience, 2nd edition,
2003.
Di Wu, Y.Y. e Liu, Y. (2009) “Collaborative Education UI in Augmented Reality” In
ETCS’09, First International Workshop on Education Technology and Computer
Science, Wuhan, China, pp. 670-673.
Dias, J.M.S. Santos, P., Bastos, R., Monteiro, L. e Silvestre, R. (2003) “Developing and
Authoring Mixed Reality with MX Toolkit”, In ART 2003, 2nd IEEE International
Augmented Reality Toolkit Workshop, Tokyo, Japan, pp. 18-26.
FreeAudioVideo (2011) “Free Sound Recorder”, http://www.freesoundrecorder.net/,
abril.
Grimm, P., Haller, M., Paelke, V., Reinhold, S., Reimann, C. e Zauner, J. (2002) “Amire
- Authoring Mixed Reality”, In The First IEEE International Workshop on Augmented
Reality Toolkit, Darmstadt, Germany, 2 pp.
Hampshire A., Seitcher, H., Grasset, R. e Billinghurst, M. (2006) “Augmented Reality
Authoring: Generic Context from Programmer to Designer”, In OzCHI’06, 18th

53
Australia conference on Computer-Human Interaction: Design: Activities, Artefacts
and Environments, Sydney, Australia, pp. 409-412.
Irawati, S., Green, S., Billinghurst, M., Duenser, A. e Ko, H. (2006) “An Evaluation of
an Augmented Reality Multimodal Interface Using Speech and Paddle Gestures”, In
Lecture Notes in Computer Science, 4282, pp. 272-283.
Kato, H. e Billinghurst, M. (1999) “Marker Tracking and HMD Calibration for a Video-
based Augmented Reality Conferencing System”, In IWAR’99, The 2nd Int. Workshop
on Augmented Reality, San Francisco, USA, pp. 85–94.
Kaufmann, H. e Dunser, A. (2007) “Summary of Usability Evaluations of an Educational
Augmented Reality Application”, In Lecture Notes in Computer Science, 4563, pp. 660-
669.
Kirner, C. e Santin, R. (2009) “Interaction, Collaboration and Authoring in Augmented
Reality Environments” In SVR’09. XI Symposium on Virtual and Augmented Reality,
Porto Alegre, Brazil, 2009, pp. 210-220.
Kirner, C. e Kirner, T.G. (2010) “Authoring Spatial Applications by non-Programmers
with an Augmented Reality Tool” In Web3DW 2010, IADIS Web Virtual Reality and
Three-Dimensional Worlds Conference, Freiburg, Germany, pp. 293-300.
Kirner, C. (2011) “ARAS-NP: Augmented Reality Authoring System for Non-
programmers”, http://www.ckirner.com/sacra/, abril.
Kirner, C., (2011) “Q&A-AR: augmented reality racing game based on questions and
answers”, http://www.ckirner.com/educa/, abril.
Ledermann, F. e Schmalstieg, D. (2005) “APRIL: A High-level Framework for Creating
Augmented Reality Presentations”, In VR’05, IEEE Virtual Reality 2005, Bonn,
Germany, pp. 187–194.
Looser, L., Grasset, R., Seichter, H. e Billinghurst, M. (2006) “OSGART – A Pragmatic
Approach to MR”, In ISMAR’06, 5th IEEE and ACM International Symposium on
Mixed and Augmented Reality, Santa Barbara, USA, 2 pp.
MacIntyre, B., Gandy, M., Dow, S. e Bolter, J.D. (2004) “DART: A Toolkit for Rapid
Design Exploration of Augmented Reality Experiences”, In UIST’04, 17th Annual ACM
Symposium on User Interface Software and Technology, Santa Fe, USA, pp. 197–206.
Saquoosha, T.K.A. (2011) “FlarToolKit”, http://saqoosha.net/en/flartoolkit/start-up-
guide/, março.

54
Schmalstieg, D., Fuhrmann, A., Hesina, G., Szalavari, Z., Encarnação, L.M., Gervautz,
M. e Purgathofer, W. (2002) “The Studierstube Augmented Reality Project”, Presence:
Teleoperators and Virtual Environments, 11(1), 33–54.
Seitchter, H., Looser, J. e Billinghurst, M. (2008) “ComposAR: An Intuitive Tool for
Authoring AR Applications”, In ISMAR’08, 7th IEEE and ACM International Symp. on
Mixed and Augmented Reality, Cambridge, UK, pp. 177-178.
Sutherland, I.E. Sketchpad: A Man-Machine Graphical Communication System, PhD
Thesis, MIT, January, Technical Report No. 574, University of Cambridge, UCAM-CL-
TR-574, 1963.
Sutherland, I.E. (1965) “The ultimate display”, In Proceedings of IFIPS Congress, New
York City, NY, vol. 2, May, pp. 506-508.
Sutherland, I.E. (1968) “A Head-mounted Three-dimensional Display,” In 1968 Fall
Joint Computer Conference, AFIPS Conference Proceedings, vol. 33, pp. 757-764.
Uchiyama, S., Takemoto, K., Satoh, K., Yamamoto, H. e Tamura, H. (2002) “MR
Platform: A Basic Body on which Mixed Reality Applications are Built”, In ISMAR’02,
The First IEEE and ACM International Symposium on Mixed and Augmented Reality,
Darmstadt, Germany, pp. 246.
Wisdom Software (2011) “ScreenHunter 5”, http://www.wisdom-soft.com/downloads/
setupscreenhunterfree.msi, abril.

VRAR Trends

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (9)

Similaire à VRAR Trends

Similaire à VRAR Trends (20)

VRAR Trends