Tendências e Técnicas em Realidade Virtual e …comissoes.sbc.org.br/ce-rv/livro2011.pdf · XIII Simpósio de Realidade Virtual ... bem como seus ambientes e ferramentas de programa-8

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: [email protected]

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 - [email protected]

José Remo Ferreira Brega - [email protected]

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 [email protected]

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, first 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.


Figure 1. Th e Android’s Architeture. Source: developer.android.com.

Sometimes people may get confused when they try to define 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 find the most popular appli¬cations featured,

and the number of applications available are growing continuously. In fact, this number

has risen almost fivefold 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 find 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 difficulties 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 figure below shows a simplified 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.

Let us create a new android project from the Eclipse interface and name the activ¬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 specific rendering events. Specifically, 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. Th e 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 file, 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

we restricted our .obj models to be totally triangulated. Drawing meshes with glDrawEle-

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 -Th e 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

[email protected]

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

Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 29-54, jan./dez. 2011.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 <SACRA\Wrl\reference>, na versão de distribui-

ção, tendo a aparência mostrada na Figura 6a.

Figura 6. Arquivos de confi guraçã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 <SACRA\position>, 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 <SACRA\animais>, 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.

55

Desenvolvendo um Ambiente Virtual em Realidade Aumentada para Web com FLARToolKit

Robson Augusto Siscoutto

Universidade do Oeste Paulista (Unoeste)

[email protected]

Levrangeles da Silva Filho

Universidade de Cuiabá (UNIC)

[email protected]

Abstract

This chapter aims to present the process of developing augmented reality applications on

the web with FLARToolkit, exploring the potential of integrating and supporting applications

used in different platforms to access AR environments. Moreover, the basic components will

be presented, and the process of installing and configuring the tool, followed by the develo-

pment of a basic design with FLARToolkit, will be presented in pratice, showing the tool’s

configuration files, as well as the Action Script language, to develop new capabilities, such

as behaviors, interactions, internal and external events, scripts, and so on. The main steps of

developing AR applications’ basic interactions are shown at the end of this chapter.

Resumo

Este capítulo tem como objetivo apresentar o processo de desenvolvimento de apli-

cações de Realidade Aumentada na web com FLARToolKit, explorando suas potenciali-

dades quanto à integração de aplicações e suporte na sua utilização em diferentes plata-

formas para acesso a ambientes de RA. Além disso, estão apresentados os componentes

básicos e, na prática, o processo de instalação e configuração da ferramenta, seguido de

um desenvolvimento de um projeto básico com o FLARToolKit, apresentando os arquivos

de configuração da ferramenta, bem como a linguagem Action Script para o desenvolvi-

mento de novas potencialidades, como comportamentos, interações, eventos internos e

externos, scripts, dentre outros. Ao final deste curso são mostrados os principais passos

para a inserção de interações básicas em aplicações de RA.

56

Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 55-90, jan./dez. 2011.SISCOUTTO, Robson Augusto; FILHO, Levrangeles da Silva.

Desenvolvendo um Ambiente Virtual em Realidade Aumentada para Web com FlarToolKit

1. Introdução

Uma biblioteca popular que contribuiu bastante para o desenvolvimento de aplica-

ções de Realidade Aumentada (RA) foi o ARToolKit. Por exigir um baixo custo do har-

dware para a sua implementação, se tornou o software mais popular na sua categoria.

Essa biblioteca utiliza o rastreamento óptico, uma técnica de visão computacional para

identificar e estimar em tempo real a posição e a orientação de um marcador fiducial em

relação ao dispositivo de captura de vídeo (Webcam). Assim, o cálculo da correlação en-

tre os dados estimados do marcador real e a sua imagem, possibilita posicionar objetos

virtuais alinhados à imagem do marcador [Kato, 2000].

O ARToolKit é uma biblioteca de programação multi-plataforma e utilizada para

o desenvolvimento de aplicações em ambientes Desktop. Devido a esta particularidade,

o desenvolvimento de aplicações de RA pode exigir configurações variadas durante a

instalação, sendo necessária a instalação da biblioteca em cada computador, gerando

complicações ou transtornos, tanto para o usuário quanto para o programador. Além

disso, não permite o desenvolvimento de aplicações de RA na Web [HITLab, 2010].

Como alternativa para o desenvolvimento de aplicações de RA na Web tem-se a

biblioteca FLARToolKit [Saqoosha, 2010] que será apresentada neste capítulo em de-

talhes. Portanto, este capítulo tem como objetivo apresentar a FLARToolKit (seção 2),

detalhando seus componentes (seção 3), instalação e configuração (seção 4), o desenvol-

vendo na prática um projeto (seção 5) e, por fim, a implementação de novas funciona-

lidades (seção 6).

2 FLARToolKit

O FLARToolKit [Koyama, 2010] é uma biblioteca desenvolvida na linguagem Ac-

tionScript [Adobe 2010]. Esta linguagem é executada nas maiorias dos browsers Web

que possuem suporte a tecnologia Adobe Flash Player. Logo, o desenvolvimento de apli-

cativos com o FLARToolKit possibilita executar aplicações para RA na Web, fornecendo

uma maior flexibilidade na questão do acesso às aplicações, pois o usuário poderá aces-

sar de qualquer lugar, seja de um computador pessoal ou até mesmo de um dispositivo

móvel, desde que a máquina utilizada tenha suporte ao Adobe Flash Player. Além disso,

o acesso aos aplicativos pode ser tanto em uma arquitetura Cliente/Servidor quanto

uma máquina local. O FLARToolKit apresenta algumas características que devem ser

levadas em consideração, como por exemplo:

57



Conhecer alguns pontos importantes sobre este assunto é essencial para que o •

desenvolvimento e execução de aplicações em RA com o FLARToolKit possam

ser mais eficientes;

O nível de iluminação do ambiente real que apresentará os marcadores ao •

FLARToolKit influencia na qualidade da imagem capturada pela câmera. Um

ambiente bem iluminado tende a resultar uma melhor qualidade da imagem

em relação a um ambiente menos iluminado, facilitando o trabalho do FLAR-

ToolKit no reconhecimento dos marcadores; e

Durante o desenvolvimento da aplicação, é importante trabalhar na ques-•

tão do nível de limiarização1 da imagem capturada. O reconhecimento de um

marcador depende muito da qualidade da imagem limiarizada. Logo, para um

reconhecimento mais eficiente do marcador, o nível de limiarização durante a

execução da aplicação deve ser variável, de acordo com o reconhecimento ou

não do marcador.

Aplicações de RA para Web com FLARToolKit consistem um conjunto de tecno-

logias diferentes, como linguagem de programação, ambientes para desenvolvimento,

bibliotecas externas e hardware, cada uma com suas características. É importante iden-

tificar as particularidades de cada tecnologia utilizada, visando desenvolver um projeto

de software mais robusto, tratando os possíveis impedimentos tanto durante o desen-

volvimento quanto na execução, obtendo melhores resultados e oferecendo um melhor

produto ao usuário final.

É de fundamental conhecer os passos do funcionamento de uma aplicação de Rea-

lidade Aumentada com o FLARToolKit para o sucesso da sua implementação. Segundo

Koyama (2010), os seis principais passos são:

1. Capturar a Imagem da Câmera: este é o início do ciclo. Nesta etapa, os parâme-

tros da câmera e marcadores já foram informados. A captura das imagens ou quadros é

realizada até o término da aplicação. A Figura 3.1 ilustra a imagem capturada.

1 Limiarização: Este processo consiste basicamente em separar os grupos de cinza de uma imagem. Em outras palavras, determina-se uma intensidade de cinza, chamada de limiar, que separa as partes da imagem, de forma que grupos de pixels com intensidades pareci-das sejam separados de outros [Rafael 2002].

58



Figura 1. Imagem capturada pela câmera [Koyama, 2010].

2. Criar o Mapa de Bits da Imagem limiarizada: criar um mapa de bits da imagem

capturada preparando para realizar a detecção de possíveis marcadores na cena. A Fi-

gura 2 mostra a imagem capturada de forma limiarizada.

Figura 2. Imagem limiarizada [Koyama, 2010].

59



3. Detectar os Marcadores: o rastreamento dos marcadores é iniciado. Na Figura 3 é

possível visualizar (bordas destacadas) que o FLARToolKit conseguiu encontrar quatro

possíveis marcadores.

Figura 3. Possíveis marcadores detectados na cena [Koyama, 2010].

Vale ressaltar que apenas 50% da área do marcador é utilizada para realizar a aná-

lise de identificação dos marcadores cadastrados na aplicação. A Figura 4 ilustra um

possível marcador detectado pelo FLARToolKit na cena e a sua área extraída para com-

paração com os marcadores cadastrados na aplicação.

Figura 4. Área de um marcador extraída para comparação [Koyama, 2010].

60



4. Identificar e Comparar os Marcadores: após a detecção dos marcadores, inicia-

se o processo de comparação com os marcadores registrados na aplicação. Neste ponto,

cada marcador registrado é comparado com cada marcador identificado, de forma que

a comparação se realize através da técnica de homografia, ou seja, na qual se faz uma

comparação a cada rotação de 90º do marcador registrado com um marcador identifi-

cado, gerando um resultado de 0 a 1. Quanto mais próximo de 1 a comparação se torna

mais precisa, ou seja, é mais provável que aquele marcador identificado seja o que foi

cadastrado. A Figura 5 apresenta um exemplo de comparação. Pode-se perceber que, na

segunda linha, há uma marcação em vermelho, mostrando que a imagem do marcador

registrado e a do marcador identificado são muito semelhantes pelo resultado obtido de

0.86 e que, aparentemente, ao olho nu, são iguais.

Figura 5. Comparação dos marcadores identifi cados com um marcador registrado

[Koyama, 2010].

Neste momento, o FLARToolKit já consegue decidir quem é o marcador registrado

no aplicativo. Na Figura 6 é possível visualizar que o resultado de todo o processamento

de identificação resultou em apenas um marcador registrado.

Figura 6. Marcador reconhecido pelo FLARToolKit [Koyama, 2010].

61



5. Calcular a Matriz de Transformação: com os marcadores identificados, chega o

momento para preparação do posicionamento dos objetos virtuais. A matriz de trans-

formação é calculada. A câmera possui um sistema de coordenadas. Um objeto virtual

pode ser posicionado em um ponto deste sistema de coordenadas, tornando possível a

visualização do mesmo, se o ponto em que está situado estiver em uma posição visível.

Existe uma matriz 3x4 denominada matriz transformação que o FLARToolKit utili-

za para realizar um cálculo com um ponto 3D no marcador identificado. O resultado

deste cálculo determina o ponto no sistema de coordenadas da câmera em que o objeto

virtual será situado [Kirner, 2007]. A Figura 7 apresenta este relacionamento entre as

coordenadas do marcador e as coordenadas da câmera, mostrando o ponto no sistema

de coordenadas da câmera onde um objeto virtual poderia ser alocado.

Figura 7 – Relacionamento entre as coordenadas do marcador e da câmera [Kato, 2010]

Segundo [Kirner, 2007], para corrigir distorções inerentes à câmera, o ARToolKit utiliza os parâmetros de câmera. Assim como o ARToolKit, o FLARToolKit também utiliza destes parâmetros. O arquivo câmera_ para.dat encontrado na biblioteca do FLARToolKit representa estes parâmetros, sendo considerado o cerne do FLARTo-olKit, que muito provavelmente não precisará ser alterado, a não ser em casos específi-cos e em projetos mais avançados [Cabana, 2010].

6. Renderizar os Objetos Virtuais: agora que já se sabe qual objeto foi selecionado e

onde o posicioná-lo, basta apenas utilizar de uma engine 3D para renderização dos ob-

jetos virtuais na cena. A Figura 8 apresenta um objeto virtual posicionado sobre a cena

real através do marcador identificado pelo processamento.

62



Figura 8. Objeto virtual posicionado sobre a cena real [Koyama, 2010].

Portanto, para cada quadro de imagem capturado, todo este processamento é reali-zado continuadamente, até que a aplicação seja encerrada.

3. Componentes do FLARToolKit

Conhecer os componentes do FLARToolKit é fundamental para o entendimento

de sua estrutura durante o desenvolvimento de um projeto de software. Diante disso,

as próximas seções apresentam os principais componentes, são eles: linguagem de pro-

gramação (seção 3.1), Ambiente de desenvolvimento – IDE (seção 3.2), bibliotecas e de-

pendências (seção 3.3), estrutura de diretórios (seção 3.4) e a criação de marcadores no

FLARToolKIT (seção 3.5).

3.1. Linguagem de Programação

O FLARToolKit utiliza a linguagem ActionScript 3 da Adobe, mas tem toda sua estrutura traduzida do NyARToolKit que é escrita em Java [ARToolworks, 2010]. Ac-tionScript é a linguagem de programação para os ambientes de execução Adobe Flash Player e Adobe AIR que roda sobre uma máquina virtual denominada ActionScript Vir-tual Machine (AVM). Para maiores detalhes sobre ActionScript 3 e a AVM vide Adobe (2010). Vale ressaltar que um conhecimento sobre orientação a objetos é essencial para um desenvolvimento básico de aplicações com o FLARToolKit, pois o ActionScript é orientado a objetos.

63



3.2. Ambiente de Desenvolvimento (IDE - Integrated Development Environment)

A escolha do IDE para o desenvolvimento de aplicações com FLARToolKit não ne-

cessita ser específica. Neste capítulo será utilizado o Flash Develop [FlashDevelop, 2011]

uma IDE de código aberto sob licença do MIT [MIT, 2011] que possui uma estrutura

voltada para o desenvolvimento de aplicações Flash. Entretanto, outras IDEs como Flex

Builder podem ser utilizados também [Adobe, 2011].

3.3. Bibliotecas e Dependências

O FlartoolKit apenas calcula a orientação dos marcadores, definindo a posição dos

objetos virtuais e outras ações como movimentação e escala, mas não renderiza os obje-

tos 3D da cena [Saqoosha, 2010]. Logo, para que isso ocorra existe a dependência de ou-

tras bibliotecas para tal. No pacote do FLARToolKit estão disponíveis algumas bibliote-

cas para renderização de objetos virtuais, como o Papervision3D e o Away3D. Sem estas

bibliotecas externas, não há como renderizar objetos 3D na cena, tornando a ferramenta

FLARToolKit impotente na criação de aplicativos para Realidade Aumentada.

Neste capitulo será utilizado o Papervision3D como renderizador dos modelos vir-

tuais [Papervision, 2010]. A Tabela 1 detalha as classes/formatos de arquivos dos mode-

los virtuais utilizados nas aplicações interpretados pelo PaperVision3D.

Tabela 1. Classes suportadas pelo Papervision3D.

CLASSE DESCRIÇÃO

Ase Permite carregar objetos exportados do 3DS Max

Collada Permite carregar cenas Collada

DAERepresenta um arquivo convertido para o formato COLLADA

1.4.1

KMZ Modelo para Google Earth

Max3DS Arquivo 3DS

MD2 Carrega um arquivo Quake 2 MD2 com animação

Sketchup Modelo do Google Sketchup

Sketchup Collada Modelo do Google Sketchup para Collada

64



3.4. Estrutura de Diretórios

Para a instalação do FLARToolKit deve-se, primeiramente, baixar a versão dese-

jada. O próximo passo é descompactar o arquivo no local de conveniência. Esse local

será referenciado abaixo como {FLARToolKit_ver_xx}. A Figura 9 mostra a estrutura de

diretórios da versão 2.5.4 do FLARToolKit, após descompactação.

Figura 9. Raiz da árvore de diretórios do FLARToolKit.

No diretório .settings estão contidas as configurações para o projeto na IDE Flex

Builder. O Flash Develop tem a capacidade de importar este tipo de projeto.

O diretório libs armazena todas as bibliotecas externas importadas no FLARTo-

olKit. Esta disponíveis as quatros engines 3D para renderização dos objetos virtuais 3D

- Away3D [Away3D 2010], Away3D Lite [Away3DLite 2010] e Papervision3D - e o NyAR-

ToolKitAS3, versão em código ActionScript 3 da biblioteca NyARToolKit [ARToolworks

2010] em Java, contendo a base do FLARToolKit.

O diretório resources contém as subpastas model e Data. A model é um repositório para os arquivos dos modelos tridimensionais e já está disponível um modelo de um ob-jeto tridimensional do planeta terra, sendo um arquivo no formato .dae com suas textu-ras (arquivo no formato Collada) e outro arquivo earth.blend no formato de um projeto de um programa open source para modelagem de objetos tridimensionais, o Blender. Pode-se utilizar do Blender ou outro programa para criação dos modelos 3D, desde que o formato do modelo seja aquele suportado pelo renderizador 3D escolhido. A Tabela 1 apresentou alguns formatos suportados pelo Papervision 3D, p.ex., para trabalhar com alguns tipos de modelos.

65



Já na Data, encontram-se dois exemplos de marcadores que podem ser utilizados no FLARToolKit, o hiro-marker.pdf e o flarlogo.pdf, bem como seus respectivos arqui-vos .pat utilizados no registro durante o desenvolvimento de uma aplicação. Na seção 3.5 serão apresentados maiores detalhes sobre os marcadores. Também nesta pasta en-contram-se dois arquivos referentes aos parâmetros da câmera que devem ser informa-dos à aplicação, o camera_ para.dat e o câmera_ para_16x9.dat, ambos para informar os parâmetros de câmera, sendo o ultimo para aplicações com visão widescreen.

Na pasta src estão os códigos-fonte do FLARToolKit. Dentro desta pasta existe a subpasta examples, contendo classes com vários exemplos de aplicações possíveis com o FLARToolKit, servindo como um meio de aprendizagem da ferramenta, bem como exploração de suas funcionalidades. A pasta org é a raiz para o código-fonte do FLARToolKit contendo as classes implementadas. Estas classes serão exploradas nas próximas seções.

Ainda na raiz da árvore de diretórios do FLARToolKit, encontram-se dois arqui-

vos, .actionScriptProperties e .project, representando uma configuração para um projeto

no ambiente de desenvolvimento FlexBuilder, possibilitando a compilação dos códigos-

fonte, bem como uma implementação com as configurações do projeto original.

3.5 – Criação de Marcadores no FLARToolKIT

A criação de novos marcadores para uso no FLARToolKit é possível por meio de uma aplicativo chamado MarkerGenerator que está disponível online em Marker

Generator Online (2010). Este realiza a detecção do marcador através de uma câmera e permite salvar em disco o arquivo referente ao marcador detectado. A Figura 10 apre-senta a detecção de um marcador através do MarkerGenerator. Uma borda vermelha é gerada ao redor, indicando que o marcador foi detectado, permitindo ao usuário salvar as configurações em disco clicando no botão Save Pattern.

Figura 10 – Marker Generator em funcionamento.

66



A criação da identificação no interior do marcador é um fator que influência no

momento da renderização de um objeto. Deve haver uma diferença aparente a cada ro-

tação de 90º no eixo z, facilitando o trabalho do FLARToolKit na orientação x, y e z do

marcador para o posicionamento de um objeto virtual [Cabana, 2010]. A Figura 11 apre-

senta um exemplo. O marcador da esquerda é perfeito, enquanto o da direita poderia

trazer problemas devido ao seu formato simétrico durante a rotação.

Figura 11. Exemplo de marcador que poderia confundir a aplicação: a) correto e b) possí-

vel problema [Cabana, 2010].

4. Instalação e Configuração do FLARToolKit

Esta seção apresenta o processo de instalação e configuração do FLARToolKit, tor-

nando possível criar um ambiente preparado para desenvolver aplicações. Inicialmente

serão apresentados os arquivos fundamentais necessários para o desenvolvimento (4.1),

depois será descrito como realizar a instalação dos arquivos (4.2) e a configuração da

IDE Flashdevelop (4.3).

4.1. Arquivos Fundamentais

Para que seja possível a compilação dos projetos com FLARToolKit é necessário

realizar o download de alguns arquivos. Além da biblioteca, é necessário baixar o Flex

SDK, um kit para desenvolvimento de aplicações Flash fornecido pela Adobe, essencial

para compilação dos projetos. O ambiente de desenvolvimento FlashDevelop, para ser

executado, depende de uma máquina virtual Java instalada no sistema, daí a necessi-

dade do Java Runtime 6. A Tabela 2 apresenta esses arquivos, o link para se realizar o

download e suas respectivas versões.

67



Tabela 2. Arquivos necessários para desenvolvimento com FLARToolKit.

NOME DESCRIÇÃO DOWNLOAD

FLARToolKit 2.5.4Biblioteca do

FLARToolKit

http://www.libspark.org/wiki/sa-

qoosha/FLARToolKit/downloadlist

Flex SDK 4.1

Kit de desenvol-

vimento para

compilação dos

aplicativos

http://www.adobe.com/cfusion/enti-

tlement/index.cfm?e=fl ex4sdk

FlashDevelop 3.3.1

IDE para desenvol-

vimento das apli-

cações

http://www.fl ashdevelop.org/down-

loads/releases/FlashDevelop-3.3.1-

RTM.exe

Java Runtime 6

Java Virtual Ma-

chine necessária

para execução do

FlashDevelop

http://www.java.com/pt_BR/down-

load/

4.2. Instalação dos Arquivos

Primeiramente, deverá ser extraídos para um diretório de preferência os arquivos

FLARToolKit 2.5.4 e o Flex SDK 4.1. O caminho deve ser o mais acessível de forma

que fique mais fácil para referenciar mais tarde durante o desenvolvimento. Neste caso,

ambos foram extraídos para C:\desenvolvimento\ra. A Figura 12 mostra a árvore de di-

retórios dos arquivos extraídos.

Figura 12. Diretório para Confi guração do Ambiente para Desenvolvimento com FLAR-

ToolKit.

68



O aplicativo FlashDevelop deve ser instalado neste mesmo local. Antes disso, é ne-

cessário instalar o Java Runtime para que seja possível a execução do FlashDevelop. Os

passos a seguir mostram os procedimentos para instalação do FlashDevelop:

Executar o arquivo FlashDevelop-3.3.1-RTM.exe e a Figura 13 será apresentada. Se

uma mensagem de alerta sobre a instalação do Flash Player 9 ou ActiveX for IE aparecer,

significa um alerta indicando que estes programas precisam ser instalados para a execu-

ção das aplicações. Depois de fechada a janela com o aviso, passe para o passo 2.

Figura 13 Primeiro passo para instalação do FlashDevelop.

Clicar em Next. Na próxima tela (Figura 14) desmarque a opção Install Flex SDK,

pois serve para instalar o SDK para desenvolvimento. Já que aqui será instalado manu-

almente, então não é necessário.

Figura 14 Segundo passo da instalação do FlashDevelop.

69



Clicar em Next. O próximo passo é escolher o local onde será instalado. Pode ser

qualquer um de preferência. Aqui foi criada uma pasta FlashDevelop no mesmo diretó-

rio do FLARToolKit e o Flex SDK, conforme a Figura 15.

Figura 15 Terceiro passo da instalação do FlashDevelop.

Clicar em Install para instalar o FlashDevelop. Após a instalação, será apresentada

a Figura 16 indicando uma opção para consulta de um guia online do FlashDevelop.

Apenas desmarcar a opção se não houver preferência no momento.

Figura 16 Último passo da instalação do Flash Develop

Agora os arquivos necessários já estão instalados, todos no mesmo diretório e pron-to para serem utilizados. Nas próximas seções, serão apresentadas as ferramentas que farão parte do desenvolvimento prático neste capítulo.

70



4.3. Configuração da IDE

Para configurar a IDE é preciso informar ao FlashDevelop sobre o local do Flex

SDK para compilação dos projetos. Para isso, siga os seguintes passos:

1. Abrir o menu Tools > Program Settings ou apertar a tecla F10. A Figura 17 será

apresentada.

Figura 17 Menu para tela de confi guração do Flex SDK.

2. Selecionar AS3Context nos plugins e encontre a opção Flex SDK Location no

grupo Language, conforme pode-se visualizar na Figura 18. Informe o caminho para

o Flex SDK.

Figura 18. Confi guração do Flex SDK no FlashDevelop.

71



Desse modo, qualquer projeto Action Script 3 criado, aberto ou importado estará pronto para ser compilado.

5. Desenvolvendo na Prática um Projeto de RA com FLARToolKit

Com base no tutorial “/Flash/Realidade Aumentada” [Cabana 2010], será desenvol-

vida uma aplicação simples, servindo de aprendizado para o entendimento do FLARTo-

olKit, mostrando, passo a passo, desde definição do projeto até o desenvolvimento do

código-fonte, sua compilação e teste.

Em termos de hardware, será utilizado uma webcam, um monitor LCD não imer-

sivo e mouse e teclado padrão. Para os softwares, o sistema operacional escolhido foi

a versão 64 bits do Windows 7 Professional, Google Chrome como navegador WEB e

FlashDevelop para IDE de desenvolvimento. O Papervision 3D será utilizado como a

engine 3D responsável pela renderização dos objetos virtuais.

Nas próximas seções serão apresentados o processo de criação e configuração de

um projeto (seção 5.1), a importação das bibliotecas necessárias (seção 5.2), a criação

e definição de uma classe e seus atributos fundamentais (seção 5.3), a implementação

de métodos e funcionalidades (seção 5.4) e, por fim, a compilação e o teste do projeto

(seção 5.5).

5.1. Criação e Configuração do Projeto

Inicialmente é necessário criar um novo projeto em qualquer diretório de preferên-

cia. Este projeto tem como objetivo apresentar uma estrutura de aplicação que propicie

um funcionamento básico de um ambiente de RA. Um projeto é apenas uma classe

Action Script, que possui algumas funcionalidades básicas e um código-fonte simplifi-

cado. Estes modelos podem ser obtidos na internet. Uma referência para este trabalho é

o Google Armazém 3D [Google 2011].

Conforme apresentado na seção 3.4 é preciso informar ao FlashDevelop sobre o local

do Flex SDK para compilação dos projetos. Logo após um projeto no FlashDevelop ser

criado para o desenvolvimento da aplicação. Os passos para criação de um projeto são:

Selecionar o item Project > New Project da barra de menus, conforme a Figura 19.

72



Figura 19. Menu para criar um projeto no FLashDevelop.

1. Na seção Installed Templates, selecionar a opção AS3 Project, dar um nome ao

projeto no campo de texto Name e informar o local onde o projeto será armazenado em

Location. Se o local informado não existir, marcar a opção Create directory for project

para criar o diretório.Veja a Figura 20.

Figura 20 – Defi nição das propriedades de um novo projeto no FlashDevelop.

Clicar no botão OK para confirmar a criação do novo projeto.

5.3. Importação das Bibliotecas

73



Para que seja possível criar aplicativos com Realidade Aumentada é necessário im-

portar algumas bibliotecas para o projeto. Para isto, deverá ser importado o renderiza-

dor, por exemplo, o Papervision3D, bem como o FLARToolKit e o NyARToolKitAS3. Os

passos a seguir descrevem como realizar a importação:

1. Criar um diretório para cada biblioteca na pasta lib do projeto, conforme Figura 21.

Figura 21 – Defi nição das pastas para as Bibliotecas no projeto no FlashDevelop.

2. Copiar o diretório src do FLARToolKit obtido para o diretório do FLARToolKit

do projeto, conforme a Figura 22.

Figura 22 – Copia src do FLARToolKit obtido para o diretório do FLARToolKit do projeto.

3. O FLARToolKit traz consigo em seu diretório libs o NyARToolKit e o Papervi-

sion3D. Para importar ambos para o projeto, basta apenas copiar seus respectivos src do

FLARToolKit em cada lugar correspondente no projeto, conforme a Figura 23.

74



Figura 23 – Copia de todos os src do FLARToolKit obtido para o diretório do FLARToolKit

do projeto.

Edite o classpath do projeto, pois é necessário informar ao FlashDevelop quais bi-

bliotecas importadas devem ser utilizadas durante a compilação. Os passos a seguir

mostram como editar o classpath do projeto:

Acessar o menu 1. Project > Properties da barra de menu;

Selecionar a aba 2. Classpaths;

Selecionar a opção 3. Add Classpath;

Informar, para cada biblioteca a ser referenciada, o diretório 4. src, conforme a

Figura 24.

Figura 24 – Bibliotecas referenciadas no classpath do projeto.

75



Após todo o projeto ser criado e configurado é possível implementar uma aplicação

em Realidade Aumentada. As pastas bin e src possuem alguns arquivos que podem ser

excluídos para que o trabalho funcione passo a passo com sucesso.

5.4. Criação e Definição de uma Classe e seus Atributos Fundamentais

Existem algumas classes que são base para realização de uma aplicação, algumas

são específicas da linguagem de programação, outras do FLARToolKit ou do Papervi-

sion3D. Cada uma destas classes será representada por atributos do projeto. A Tabela 3

apresenta as classes, o pacote que se originam e uma breve descrição de sua função.

Tabela 3 Classes Fundamentais para o Funcionamento da Aplicação Proposta.

PACOTE CLASSE DESCRIÇÃO

Flash URLLoader

Carrega dados binários ou texto através de uma URL informada. Utilizado para

carregar os parâmetros da câmera e marcador em uma aplicação de RA

Flash StagePalco de exibição principal de

conteúdo gráfi co

Flash Camera Webcam

Flash Bitmap Imagem capturada em mapa de bits

Flash Video Video para exibição do conteúdo

Flash Sprite Nó para exibição de gráfi cos/conteúdo 3D

FLARToolKitFLARRasterTh resholdAnalyzer_

SlidePTileAnalisa o nível de limiarização da

imagem

FLARToolKit FLARBaseNode Container para o modelo 3D

FLARToolKit FLARCode Marcador detectado

FLARToolKit FLARTransMatResult Matriz de transformação

FLARToolKit FLARSingleMarkerDetector Detector de um único marcador

FLARToolKit FLARParam Parâmetros da câmera

FLAToolkit FLARRgbRaster_BitmapDataRasterizador RGB - utilizado para trans-formar a imagem rgb para mapa de bits

Papervision3D Viewport3DContainer para todo o conteúdo (mo-

delo, marcador, camera3D)

Papervision3D Camera3D Câmera virtual

Papervision3D Scene3D Cena virtual

Papervision3D DAE Modelo virtual do tipo COLLADA 1.4.1

Papervision3D LazyRenderEngine Renderizador Papervision3D

76



Como exemplo básico, será criada uma classe de nome ProjetoSimplesPapervi-

sion3D. Esta classe, do mesmo nome do projeto, será nada mais que um Sprite para

conteúdo/visualização de cenas 3D. Serão implementados os métodos responsáveis pelo

carregamento dos parâmetros de câmera e do marcador, configuração da câmera, vídeo

e alguns componentes para execução, bem como o tratamento da detecção do marcador

e o que ser feito com a falha ou sucesso deste procedimento. Os métodos dessa classe

exemplo serão descrito na próxima seção.

5.5. Implementação de Métodos e Funcionalidades

Para um melhor entendimento, serão criados métodos que representam cada etapa

do funcionamento da aplicação, claramente identificados pelos seus respectivos nomes.

Esses métodos foram criados na classe ProjetoSimplesPapervision3D e serão apresenta-

dos nesta seção, com partes do código-fonte criados no projeto da aplicação juntamente

com comentários.

O método carregar é responsável por iniciar a aplicação. Este recebe três parâme-

tros: o primeiro é o arquivo referente aos parâmetros da câmera, o segundo referente ao

arquivo do marcador escolhido e o terceiro ao arquivo para o modelo virtual tridimen-

sional. A Figura 25 apresenta o método carregar.

Figura 25. Método Carregar responsável por iniciar a aplicação.

Inicialmente, as informações passadas por parâmetro são armazenadas nas vari-

áveis locais. Em seguida, são iniciados os valores para altura e largura da tela de apre-

sentação e largura do marcador, bem como a criação da instância de um objeto do tipo

77



URLLoader responsável por carregar os arquivos informados para câmera, marcador e

modelo. Após isso, o método carregarParametrosCamera é chamado.

Os parâmetros da câmera serão carregados pelo método carregarParametrosCa-

mera (vide Figura 26). Primeiramente, o carregador de URL é informado para carregar

os dados binários. Antes de carregar o arquivo da câmera, um evento é adicionado na

aplicação. Este evento serve para chamar o método onParametrosCameraCarregados

quando o carregamento do arquivo dos parâmetros de câmera for carregado.

O método onParametrosCameraCarregados inicia removendo o evento referente ao

término do carregamento dos parâmetros de câmera da aplicação, já que este evento

não será mais necessário, pois o arquivo já foi carregado. Uma instância de FLARParam

é criada. O método loadARParam desta instância é responsável por atribuir os valores

obtidos do arquivo da câmera carregando às suas propriedades. O método changeScre-

enSize informa à instância sobre o tamanho da tela apresentada ao usuário, informação

importante para o funcionamento. Em seguida, o método carregarMarcador é chamado.

A Figura 26 apresenta os métodos responsáveis pelos parâmetros da câmera.

Figura 26. Métodos Responsáveis pelos Parâmetros da Câmera.

O método carregarMarcador funciona da mesma forma que carregarParametros-Camera (vide Figura 27). A única diferença é que o formato de dados informado para o carregador de URL é do tipo texto e o método a ser chamado após o carregamento do marcador é onMarcadorCarregado.

O método onMarcadorCarregado também remove o evento referente ao término do carregamento do arquivo. Após isso, uma instância de FLARCode é criada, repre-sentando o marcador em questão, recebendo como parâmetros a quantidade de divisões em largura e altura para reconhecimento do símbolo interno do marcador. O método loadARPatt desta instância atribui os dados obtidos do arquivo do marcador para seus atributos. Neste ponto, o carregador de URL não é mais necessário. Após remover sua

78



instância da memória, o método iniciar é chamado. A Figura 27 apresenta os métodos responsáveis pelos parâmetros do marcador.

Figura 27. Métodos responsáveis pelos parâmetros do marcador.

O método iniciar chama os métodos de configuração da câmera, vídeo, Papervi-

sion3D e FLARToolKit, conforme a Figura 28. Estes métodos serão apresentados mais

adiante. Depois de configurados, é adicionado ao stage uma instância de capturaBitmap

da classe Bitmap e uma instância de viewport3D da classe Viewport3D. Mais detalhes

sobre as instâncias vide Tabela 3.

Por fim, um evento é adicionado na aplicação (addEventListener), conforme a Fi-

gura 28. Este evento tem como objetivo chamar o método onFrameCapturado para cada

frame apresentado na aplicação. Este método é o destaque desta aplicação e será expli-

cado mais adiante.

Figura 28. Método iniciar.

79



O método configurarWebcam apresentado na Figura 29, primeiramente tenta reco-

nhecer a câmera instalada através do método estático getCamera da classe Camera. Se a

câmera foi detectada, esta é configurada recebendo alguns parâmetros no método set-

Mode. Os dois primeiros são a largura e altura da tela e o ultimo é quantos frames serão

executados por segundo. Se a câmera não foi detectada, uma exceção é lançada.

Em seguida, o método configurarVideo é executado. Uma nova instância de Video

é criada a partir da largura e altura da tela. Logo após isso, a instância camera é passada

para vídeo, via o método attachCamera, visando mostrar as imagens da câmera na tela.

Figura 29 Método confi gurarWebcam.

A Figura 30 apresenta o método configurarPapervision3D, responsável por confi-

gurar o que está relacionado com o Papervision3D na aplicação. Primeiramente, são

instanciados os objetos cena3D, camera3D, viewport3D, baseModelo e renderizador.

Figura 30. Confi guração do Papervision3D.

80



Inicialmente, é instanciada um referencia para FLARBaseNode, a baseModelo, com

o objetivo de servir como base de apresentação do modelo virtual em cena. Logo depois,

é criada a instância cena3D para da classe Scene3D, representando a cena virtual do

ambiente. Depois uma instância camera3D recebe como parâmetro os parâmetros da

câmera, contendo as configurações referentes à câmera. A instância viewport3D recebe

como parâmetros informações sobre altura e largura que, no caso, será o mesmo da tela

apresentada. A instância renderizador de LazyRenderEngine recebe como parâmetros

cena3D, câmera3D e viewport3D respectivamente.

Após a criação das instâncias, é instanciado o modelo virtual no formato de ar-

quivo DAE. Por meio do método load é realizado a importação do arquivo referente

ao modelo. Após isso, o modelo é adicionado à baseModelo identificado por modelo e a

cena3D recebe esta baseModelo. A Figura 31 apresenta o diagrama que representa essas

associações.

Figura 31. Árvore de componentes na apresentação da cena.

A Figura 32 apresenta o método configurarFLARToolKit responsável por realizar

a configuração dos componentes relacionados com o FLARTollKit no aplicativo. É

instanciado o analisador de limiarização para tratamento do nível de limiarização do

ambiente (FLARRasterThresholdAnalyzer_SlidePTile). Em seguida, é criada a instância

para capturaBitmap das imagens da câmera, com algumas configurações específicas,

como largura e altura. Por fim, são instanciados os objetos para detecção de um único

marcador (FLARSingleMarkerDetector), um rasterizador de imagens RGB (FLARRg-

bRaster_BitmapData) e a matriz de transformação (FLARTransMatResult) (vídeo Ta-

bela 3 para detalhes sobre os métodos). Os demais parâmetros identificados como pa-

rametrosCamera, marcador, larguraMarcador, larguraTela e alturaTela foram definidas

no método carregar (Figura 25).

81



Figura 32. Confi guração do FLARToolKit.

A etapa final é tratar o que será feito com cada frame processado na aplicação. A Fi-

gura 33 apresenta o método onFrameCapturado. É importante ressaltar que cada código

escrito neste método será executado para cada frame processado.

Figura 33. Execução da aplicação para cada frame capturado.

A imagem capturada pela câmera é apresentada na tela do usuário pelo método

draw(video). Em seguida, uma variável isMarcadorDetectado tratará de informar à apli-

cação se o marcador foi detectado ou não, através do método detectMarkerLite do de-

tector de marcador, juntamente com uma análise se o valor obtido na comparação de

reconhecimento está maior que 0.5. A visibilidade ou não da base do marcador, conse-

qüentemente, do modelo virtual, depende da detecção do marcador. Se o marcador foi

detectado (isMarcadorDetectado), a matriz de transformação é calculada e passada para

a base do modelo virtual (get e setTransformMatrix). Se não, o tratamento do nível de

limiarização é feito e a variável limiarizacao recebe o novo valor calculado. Ao final de

toda esta execução, o renderizador realiza a renderização do ambiente virtual na tela

sob o marcador.

82



5.6. Compilação e Testes do Projeto

Uma vez pronto o projeto, basta realizar a compilação do mesmo, para que seja

possível realizar os testes. A compilação do projeto gera um arquivo swf no diretório bin.

Este swf pode ser executado em qualquer Flash Player disponível, como por exemplo, no

Firefox 4.0. SWF é o formato de arquivo suportado pelo Flash Player.

É importante saber que, para execução de um aplicativo em ActionScript, é preciso

que o projeto tenha uma classe que possua um método main. Será criada uma classe

Main contendo este método main, apresentada na Figura 34.

Figura 34. Método main para execução da aplicação

Nesta classe Main, uma instância da classe ProjetoSimplesPàpervision3D é criada. Seu

método carregar recebe os parâmetros de câmera, marcador e modelo, respectivamente.

Foram utilizados o marcador hiro.pat e o modelo earth.dae ambos presentes no FLARTo-

olKit. Por fim, para que seja possível visualizar a execução do projeto, basta apenas adicio-

nar esta instância ao palco de apresentação da aplicação. A Figura 35 mostra o ambiente

aumentado, com o marcador detectado e o modelo virtual posicionado em cena.

83



Figura 35. Projeto desenvolvido em execução.

6. Aplicando Novas Funcionalidades ao Projeto: Interações Básicas

Após ser conhecido toda estrutura e como criar um projeto de RA com FLARTo-

olKit, já é possível acrescentar novas funcionalidades, como algumas interações bási-

cas. Nesta seção, serão detalhadas as principais classes, métodos e arquivos necessário

para se implementar tais funções, logo em seguida, será demonstrado, na pratica, como

implementar e testar as interações criadas.

6.1. Classes e Métodos para Interações

Para se criar interações no ambiente virtual do FLARToolKit é necessário a cria-

ção de uma classe proprietária que extenda a classe Sprite responsável pela exibição de

gráficos ou modelos 3D utilizados na cena. Vamos chamar essa classe de interação de

InteracaoSimplesPaperVision3D, por exemplo.

A partir deste ponto, deve-se criar um método nesta classe, por exemplo, de nome

iniciar, que receba como parâmetro o FLARBaseNode que é um container para o

modelo 3D e o Stage de exibição principal de conteúdo gráfico. O FLARBaseNode

será setado em uma variável local para que se tenha acesso ao modelo visando aplicar

as interações. Ao Stage é adicionado um evento que será disparado toda vez que uma

ação for gerada por um dispositivo, como o teclado. Ao ser gerado o evento este deverá

estar associado a um método que irá tratar o evento. Pode-se criar vários eventos e

associá-los a métodos diferentes. A próxima seção ira apresentar com o implementar

essa classe e método.

84



Para que este método iniciar() seja executado, é necessário criar uma instância da

classe de interação que chamamos de InteracaoSimplesPaperVision3D e adicioná-la a

classe do projeto criado (por exemplo: ProjetoSimplesPapervision3D). Como se pode

visualizar na Figura 36, foi acrescido a chamada ao método configurarInteracoes() no

método iniciar da classe ProjetoSimplesPapervision3D que irá criar a instância da classe

de interação. Além disso, é onde será realizada a chamada ao método iniciar() visando

passar como parâmetro para a classe de interação a baseModelo e o stage.

Figura 36 – Alteração no Método Iniciar da classe ProjetoSimplesPapervision3D para

adicionar a classe de interações - InteracaoSimplesPaperVision3D.

Concluída a fase de criação da classe e associação das interações já é possível acres-

centar as interações propriamente ditas. Como mencionado, isso pode ser feito via cria-

ção de métodos associados a eventos. Na próxima seção será apresentado como isso

pode ser implementado e testado.

6.2. Implementação e Testes Práticos

Visando demonstrar como é realizado o processo de implementação de interações

diretas com a cena via algum evento gerado por um dispositivo, como teclado, mouse ou

luvas de dados, esta seção irá apresentar como criar interações básicas do tipo translação,

rotação e escala dos objetos virtuais para os eixos x, y e z. Para isso a classe KeyboardE-

vent será utilizada durante a captura destes comandos e no auxílio do reconhecimento

sobre o que foi digitado, através da disponibilização de algumas propriedades estáticas,

nas quais representam algumas teclas de um teclado padrão, como Keyboard.ESCAPE

para a tecla ESC ou Keyboard.UP para a seta direcional ao norte, dentre outros.

85



Inicialmente, deve-se criar uma classe básica que estende a classe sprite (responsá-

vel por permitir a visualização de conteúdo 3D), como por exemplo, a classe Interacao-

SimplesPapervision3D na Figura 37.

Figura 37. Classe para interações simples e seu método iniciar.

O método iniciar tem como objetivo receber os parâmetros referentes ao nó base do

modelo virtual (este parâmetro será setado em uma variável interna da classe para que

ter acesso ao modelo e aplicar as interações) e o stage, utilizado pela aplicação. A partir

desse ponto, os eventos de teclado são capturados a cada tecla pressionada pelo usuário

e o método verificarAcoes é chamado (passado como parâmetro na chamada do método

stage.addEventListener) (Figura 37).

O método verificarAcoes é responsável por analisar cada tecla acionada pelo usu-

ário (Figura 38). Como se pode notar, dentro do método verificarAcoes é realizado um

teste para se determinar qual evento de teclado foi realizado. A partir da captura do

comando, é realizada uma comparação visando determinar qual tecla foi pressionada:

Escape, Left, Up, Rigth, Down, Numpad_Add (+), Numpad_Subtract (-), Insert, Delete,

Home, End, Page_Up ou Page_Down.

Figura 38. Método verifi carAcoes checando evento de teclado para interação.

Se tecla Escape for pressionada, os atributos do objeto virtual serão reinicia-dos com os valores originais recebidos no início da aplicação, como, por exemplo, o retorno do objeto virtual para sua posição, escala e rotação de origem. Como se pode notar na Figura 39, por meio de uma instância de baseModelo e usando o método ge-tChildByName é possível ter acesso ao modelo virtual e aos eixos x, y e z bem como escala e rotações. O método getChildByName realiza uma busca de um nó filho a partir do nome, neste caso, o nome é modelo.

86



Figura 39. Caso de interação para reiniciar os atributos do modelo virtual.

As operações de interação estão associadas às teclas UP,

LEFT, RIGHT e DOWN para os eixos x e y, CTRL + UP e CTRL +

DOWN para o eixo z. Para cada movimento, o modelo virtual realiza tal ação adicio-

nando ou subtraindo o valor de sua posição atual em relação a um eixo. Se o usuário

quiser, por exemplo, realizar uma translação para a esquerda (case Keyboard.LEFT),

este deve, como uma observação de um plano cartesiano, subtrair o valor de sua posição

em relação ao eixo x. A Figura 40 apresenta cada evento para cada tecla pressionada pelo

usuário e a ação realizada em resposta.

Figura 40. Casos de interação para movimentação

Para realizar uma operação de escala, são utilizadas as teclas NUMPAD_+ e NUM-

PAD_-, aumentando ou diminuindo seu valor, respectivamente. A Figura 41 detalha

87



as operações de escala. Se a tecla NUMPAD_ADD for pressionada é acrescido em 1 a

escala do modelo virtual, mas se for NUMPAD_SUBTRACT é subtraído em 1.

Figura 41. Casos de interação para escala.

Por fim, as interações de rotação nos eixos x, y e z estão associadas às teclas HOME

e END (rotação no eixo X), PAGE_DOWN e DELETE (rotação no eixo Z), PAGE_UP e

INSERT (rotação no eixo Y). A Figura 42 detalha a implementação dos métodos.

Figura 42. Casos de interação para rotação

A classe de interações está concluída. Para testar seu funcionamento, basta compi-

lar e abrir, no browser, o arquivo swf gerado no diretório bin. Depois coloque o marca-

dor definido no projeto na frente da câmera.

Como se pode notar, o processo de inclusão de novas interações é feita de forma

relativamente simples. Entretanto, para se criar interações mais avançadas utilizando

luvas ou outros dispositivos especiais para RV ou RA é necessário um estudo mais apro-

fundado, não sendo alvo deste trabalho.

88



7. Conclusões

Este trabalho apresentou o desenvolvimento de aplicações de Realidade Aumenta-

da utilizado a biblioteca FLARToolKit. Foi explorado os componentes básicos, o proces-

so de instalação e configuração da ferramenta, seguido de um desenvolvimento de um

projeto básico com o FLARToolKit.

O desenvolvimento de aplicações de RA, principalmente com a biblioteca

apresentada neste capitulo, ainda exige o conhecimento de uma linguagem de progra-

mação, o que restringe a divulgação e o uso maciço de aplicações de RA nas diversas

áreas do conhecimento, bem como na educação a distância.

Visando facilitar o desenvolvimento de aplicações de RA na Web usando FLAR-

ToolKit, os autores estão desenvolvendo um projeto de código aberto denominado Web

Augmented Reality Generator (WARGen), disponível em Silva Filho e Siscoutto (2011).

Este projeto tem como finalidade disponibilizar um gerador de aplicações em Realidade

Aumentada para web, de maneira com que o usuário possa realizar algumas configura-

ções, enviar arquivos de modelos virutais e de marcadores, além de realizar associações

de modelos virtuais, marcadores e interações de maneira simples e intuitiva via web.

Diante disso, espera-se contribuir com a popularização das aplicações de RA facili-

tando o seu desenvolvimento e simplificando a maneira do como aprender.

Referências

Adobe (2010) “Learning ACTIONSCRIPT 3.0”, Disponível em: http://help.adobe.com/

en_US/as3/learn/as3_learning.pdf, October. Acessado em 04/04/2010.

Adobe (2011) “Recursos do Flex Builder 3”, Disponível em: http://www.adobe.com/br/

products/flex/features/flex_builder/, April, Acessado em 29/03/2011.

ARToolworks (2010) “NyARToolKit”, Disponível em: http://www.artoolworks.com/

products/stand-alone/nyartoolkit/, October. Acessado em 04/04/2010

Away3D (2010) “Away3D”, Disponível em: http://away3d.com/, October. Acessado em

04/04/2010

Away3DLite (2010) “Away3D Lite v1.0: fastest and smallest 3d engine in Flash”, http://

away3d.com/away3d-lite-v1-0-fastest-and-smallest-3d-engine-in-flash, Octo-

ber. Acessado em 04/04/2010

Blender (2010) “Blender”, Disponível em: http://www.blender.org/, October. Acessado

em 04/04/2010

89



Cabana, P. (2010) “/Flash/Realidade Aumentada” http://www.cabanacriacao.com/

tutorialW/Tutorial_ra_w.pdf, October, Acessado em 14/10/2010

Google (2011) “Google Armazém 3D”, Disponível em: http://sketchup.google.

com/3dwarehouse/, April, Acessado em 31/03/2011

FlashDevelop (2011) “FlashDevelop:About”, Diponível em: http://www.flashdeve-

lop.org/wikidocs/index.php?title=FlashDevelop:About, March, Acessado em

29/03/2011

HITLab (2010) “ARToolKit”, Disponível em: http://www.hitl.washington.edu/arto-

olkit/, October. Acessado em 14/10/2010

Kato, H.; Billinghurst, M.; Poupyrev, I. (2000) “ARToolKit Version 2.33”, Human Inter-

face Lab;

Kirner, C. (2007) “Tecnologias para o Desenvolvimento de Sistemas de Realidade Vir-tual e Aumentada”, Recife.

Koyama, T. (2010) “Introduction to FLARToolKit”, Disponível em: http://saqoosha.

net/lab/FLARToolKit/Introduction-to-FLARToolKit.pdf, April. Acessado em

04/04/2010

Filho, L. S.; Siscoutto, R. A. (2011) “Web Augmented Reality Generator - WARGen”;

Disponivel em http://wargen.googlecode.com.

MIT (2011) “About MIT”, Disponível em: http://web.mit.edu/aboutmit/, March,

Acessado em 29/03/2011

Papervision3D (2010) “Papervision3D”, Disponível em: http://blog.papervision3d.

org/, October. Acessado em 22/10/2010

Rafael, C; Gonzales; Richard, E. W. (2002), “Digital Image Processing”, Prentice Hall ,

2nd edition, January.

Saqoosha (2010) “FLARToolKit”, Disponível em: http://saqoo.sh/a/en/flartoolkit/

start-up-guide, October. Acessado em 22/10/2010

Marker Generator Online (2010); Disponível em http://flash.tarotaro.org/ar/Ma-

rkerGeneratorOnline.swf. Acessado em 05/08/2010.

91

Jogos Educacionais Baseados em Realidade Aumentada e Interfaces Tangíveis

Rafael Roberto1, João Marcelo Teixeira1, João Paulo Lima1, Manoela Milena Olivei-

ra da Silva1, Eduardo Albuquerque2, Daniel Alves2, Veronica Teichrieb1 e Judith Kelner1

1Universidade Federal de Pernambuco (UFPE)2Universidade Federal de Goiás (UFG)

{rar3,jmxnt,jpsml}@cin.ufpe.br, [email protected], [email protected], danf-

[email protected], {vt,jk}@cin.ufpe.br

Abstract

This tutorial aims to present the basic concepts of augmented reality, tangible user

interfaces and educational games so that their integration can improve the experience of

students in the classroom. For this, this tutorial shows how educational games influence on

the children learning, especially for those up to eight years, and how it is possible to use aug-

mented reality to create tangible user interfaces. By the end of this course is also shown the

main steps in developing a tool involving all subjects cited above, thus sharpening the crea-

tivity and critical sense of the audience so that it can also create their own applications.

Resumo

Este tutorial tem como principal objetivo apresentar os conceitos básicos sobre Re-

alidade 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. Para isto, o texto

mostra como os jogos educativos influenciam no aprendizado de crianças, em especial

aquelas de até oito anos, e como é possível utilizar Realidade Aumentada na criação de

interfaces tangíveis. Ao final do minicurso são mostrados os principais passos do de-

senvolvimento de uma ferramenta envolvendo todos os temas supracitados, aguçando

assim a criatividade e o senso crítico da plateia de modo que ela também possa criar suas

próprias aplicações.

92

Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 91-128, jan./dez. 2011.ROBERTO, R.; TEIXEIRA, J. M.; LIMA, J. P.; SILVA, M.M. O. da; ALBUQUERQUE E.; ALVES, D.; TEICHRIEB, V.;

KELNER, J.. Jogos Educacionais Baseados em Realidade Aumentada e Interfaces Tangíveis.

1. Introdução

Os jogos, de maneira geral, desempenham um papel importante no desenvolvimento

da inteligência das crianças [Piaget, 1971]. Elas, por sua vez, apresentam uma evolução que

perpassa pela exercitação, no período sensório-motor; jogos simbólicos, com predominân-

cia na fase escolar e com forte caracterização da imitação, jogos com regras, pressupondo a

existência de parceiros e um conjunto de obrigações, conferindo-lhes um caráter social favo-

recendo avanços do pensamento e a preparação, a análise e o estabelecimento de relações.

Além da contribuição para os aspectos motores, atividades colaborativas são rele-

vantes para que as crianças compreendam que o seu sucesso não depende da derrota ou

da depreciação de outra pessoa.

Neste contexto, este tutorial propõe a utilização de jogos como recurso pedagó-

gico, de forma que eles sejam aproveitados em atividades de leitura ou escrita em alfa-

betização e outros conteúdos. Sendo usados no momento oportuno, espera-se ajudar

no desenvolvimento do raciocínio infantil e na construção do conhecimento de forma

criativa. Para atingir esse objetivo, os autores fazem uso de Realidade Aumentada, ou

simplesmente RA, uma tecnologia que possui suas raízes nas áreas de Visão Computa-

cional e Computação Gráfica. Através da RA, é possível rastrear o mundo real e inserir

nele elementos virtuais, acrescendo o mundo que conhecemos de informações úteis à

realização de uma tarefa específica.

A ligação entre a criança, usuária da aplicação a ser desenvolvida, e a aplicação em si,

se dará por meio de interfaces tangíveis. Através da integração desses três elementos (jogos,

RA e interfaces tangíveis), espera-se melhorar a experiência de alunos em sala de aula.

Este tutorial está organizado conforme descrito a seguir. Inicialmente, os conceitos

básicos sobre RA, interfaces tangíveis e jogos para educação serão apresentados. Ao longo

do texto, o leitor poderá perceber como os jogos educativos influenciam no aprendizado de

crianças, em especial aquelas de até oito anos, e como é possível utilizar RA na criação de

interfaces tangíveis. Em seguida, como forma de consolidação do conhecimento apresenta-

do, um estudo de caso exemplifica os principais passos do desenvolvimento de uma ferra-

menta envolvendo todos os temas citados anteriormente, aguçando assim a criatividade e o

senso crítico do leitor, de modo que ele/ela também possa criar suas próprias aplicações.

2. Educação Lúdica

Nesse contexto, os alunos eram considerados passivos, sendo responsáveis apenas

pela memorização dos conteúdos transmitidos pelo professor. Atualmente, porém, essas

teorias foram derrubadas no sentido de que não há ensino sem aprendizagem e de que o

conhecimento é encarado como um processo de construção.

93



Essa ideia de um ensino despertado pelo interesse do aluno acabou transformando

o sentido do que se entende por material pedagógico. Nesse contexto, os jogos entram

em cena, por serem bons facilitadores da aprendizagem. Apesar de existirem a muito

tempo, os jogos em grupo tornaram-se bastante relevantes no contexto educacional se

consideradas as ideias Piagetianas. Sob a perspectiva de Piaget, constatamos o quan-

to os jogos contribuem para o desenvolvimento infantil. Não somente Piaget, mas, “a

maioria dos filósofos, sociólogos, etólogos e antropólogos concordam em compreen-

der o jogo como uma atividade que contém em si mesmo o objetivo de decifrar os

enigmas da vida e de construir um momento de entusiasmo e alegria na aridez da

caminhada”[Antunes, 2008].

A valorização do jogo se dá, pois, a partir do momento em que a aquisição de estra-

tégias por parte dos pequenos é focada. “O ato de jogar faz com que atitudes fundamen-

tais e procedimentos importantes sejam aprendidos e adotados em diferentes situações,

sem que haja uma formalidade, um treinamento ou um exercício repetitivo”[Antunes,

2008]. Assim, os jogos proporcionam as crianças participarem efetivamente na constru-

ção de seu saber, pois a partir dos jogos, o aprendiz estabelece uma relação positiva com

o conhecimento, já que este passa a ser percebido como uma real possibilidade. Esse

aspecto torna-se bastante relevante se forem consideradas crianças com dificuldades de

aprendizagem, que, em geral, possuem uma imagem negativa cristalizada em relação

ao conhecimento. Em segundo lugar, através dos jogos, as crianças são incentivadas a

desenvolver seu raciocínio, observar, questionar, discutir, interpretar, solucionar e ana-

lisar, já que estas são habilidades necessárias para se jogar bem.

Vale ressaltar, inclusive, que os jogos e brincadeiras estão presentes na vida das crian-

ças fora dos muros da escola. Esse fato corrobora com a ideia de que a inserção do elemento

lúdico em sala de aula somente contribui para o aumento do interesse e participação do

aluno no processo de aprendizagem. Nesse sentido, já em 1999, as Diretrizes Curricula-

res Nacionais para a educação infantil ao estabelecer os fundamentos que devem nortear

as propostas pedagógicas das creches e pré-escolas mencionou à ludicidade como um dos

princípios estéticos que devem balizar a educação infantil[Antunes, 2007].Por um longo período de tempo, confundiu-se ensino com transmissão de co-

nhecimentos.

Ancoradas em princípios construtivistas, as orientações acima explicitadas reco-

nhecem a participação construtiva do aluno na produção de seu conhecimento. Nessa

perspectiva, o jogo apresenta-se o melhor caminho de iniciação ao prazer estético, à

descoberta da individualidade e à meditação individual. Ao lado dessa função, os jogos

também se prestam à multidisciplinaridade e, dessa forma, viabilizam a exploração sig-

nificativa dos conteúdos por parte dos aprendizes.

Outra forma de se apreciar a importância dos jogos no desenvolvimento infantil é

através das teorias psicanalíticas trabalhadas por autores como: Winnicott, 1975; Lajon-

94



quière, 1992; Mrech, 1999; Santa Roza, 1999, entre outros (apud [Schartz, 2004]). Esses

teóricos comparam o brincar com os sonhos. Consideram, assim, que o brincar possui

conteúdos manifestos e ocultos que devemos nos dispor a escutar, caso desejemos pro-

piciar uma educação que alie a maior liberdade possível, a menor repressão (BACHA,

1999 apud [Schartz, 2004]).

Observa-se, portanto, a partir do exposto, que embora com diferentes ênfases, to-

das as teorias do jogo e da brincadeira, desde as clássicas até as mais recentes apontam

para a importância do lúdico como meio privilegiado de expressão e de aprendizagem

infantil, reconhecendo não haver nada significativo na estruturação e no desenvolvi-

mento de uma criança que não passe pelo brincar [Rodulfo, 1990].

2.1. Jogos Colaborativos

Sendo a competição e a cooperação valores e atitudes socioculturais,conclui-se que

esses comportamentos são passíveis de ser ensinados e aprendidos através das diversas

formas de interação humana, notadamente, pela educação. Esta seção teráseu focono

uso de jogos colaborativos como ferramenta pedagógica a serviço da aprendizagem de

valores como cooperação e autoconhecimento.

Muitos teóricos têm discutido a importância dos jogos colaborativos. Um teórico

de grande relevância foi[Piaget, 1971], que em sua teoria do desenvolvimento infantil,

propõe a existência de três estágios evolutivos, a saber: o estágio pré-operatório, o ope-

ratório concreto e o operatório formal. Nestes, o jogo emerge sob diferentes formas de

manifestação desses processos, perpassando pelo pensamento infantil no decorrer dos

diferentes estágios de desenvolvimento.

O estágio pré-operatório caracteriza-se, dentre outros aspectos, pelo egocentrismo,

ou seja, a incapacidade de ver os problemas a partir de outros pontos de vista. Durante

esse primeiro estágio, o jogo dá evidência de um pensamento que explica o mundo pela

intuição e não pela lógica; de símbolos mentais construídos para representar objetos

reais. O jogar e o brincar não estão atrelados, nessa fase, a resultados, já que esses valores

ainda não se instalaram no repertório infantil. A criança joga apenas pelo prazer, não

percebendo o elemento competitivo. A criança joga, na verdade, contra ela mesma.

Num segundo momento, quando a criança evolui para o pensamento operatório

concreto, o jogo com características egocêntricas vai cedendo espaço para jogos de natu-

reza social, com a inserção de outros participantes. Assim, os jogos ideais para essa fase

passam a requisitar cooperação, esforço, regras bem definidas e espírito competitivo,

já que nessa fase, a criança torna-se capaz de estabelecer sequências lógicas, conservar

e reverter atributos e operações, classificar agrupamentos e melhorar seu desempenho

linguístico, aproximando-se da fala do adulto.

95



Por fim, no estágio das operações formais, a criança ganha uma importante ca-

pacidade, a da abstração. Dessa forma, ela se torna capaz de refletir sobre seu próprio

pensamento. Nessa fase, as crianças já são capazes, portanto, de utilizar a linguagem

como veículo de reflexão e exteriorizam, inclusive nas atividades lúdicas, conceitos bem

definidos como amor, ódio, velocidade e tempo.

A partir do exposto, percebe-se a importância dos jogos colaborativos, pois através

destes, a criança tem a necessidade de cooperar e, trabalhar com regras. O cumpri-

mento de regras envolve o fato de se relacionar com outras pessoas que pensam, agem

e criam estratégias de maneiras diferentes. Através dos jogos, mesmo que derrotada,

a criança tem a oportunidade de conhecer-se, estabelecer os seus próprios limites e

competências como jogadoras,além de avaliar o que pode ser trabalhado para evitar a

derrota nas próximas vezes.

Nos jogos colaborativos, os jogadores não necessitam escolher um lado, mas, sobre-

tudo, devem estar juntos. O conteúdo e a dinâmica do jogo determinam não somente a

relação da criança com o objeto, mas desta com as demais. Dessa forma, jogos colabora-

tivos promovem o desenvolvimento das relações sociais da criança. Durante o processo

de socialização, a criança ouve o colega e discute, identificando perspectivas e se justifi-

cando. Ao se justificar, argumenta e reflete sobre os seus próprios procedimentos.

Através dos jogos cooperativos, o participante pode, ainda, trabalhar habilidades

como interação, percepção, relacionar-se com empatia, apresentar autoestima e autoco-

nhecimento e ser ético. Essas habilidades fazem parte do que Gardner (1994, 1995, 2000

apud [Schartz, 2004]) denomina inteligências pessoais – referentes às capacidades de

autoconhecimento e compreensão do outro.

Assim, os autores concordam com [Broto, 1999] ao afirmar que um bom jogo

em grupo deve possibilitar à criança avaliar os resultados de suas ações. Se o adulto

impõe a avaliação como uma verdade, a criança se tornará muito dependente e inse-

gura da sua própria habilidade de tomar decisões. Percebe-se, portanto, que além da

colaboração, os jogos colaborativos proporcionam a ref lexão sobre as próprias ações

e o autoconhecimento.

Outras características das situações cooperativas em relação às situações de com-

petição de acordo com [Broto, 1999] são: percepção de que o atingimento dos objetivos

é, em parte, consequência da ação dos outros membros, sensibilidade às solicitações

alheias, frequência maior de ajuda mútua, maior homogeneidade na quantidade de con-

tribuições e participações, maior produtividade em termos qualitativos e maior especia-

lização de atividades.

Assim sendo, são enfatizados os benefícios dos jogos colaborativos como ferra-

menta pedagógica viável para o incentivo ao desenvolvimento mental dos estudantes.

Através de atividades lúdicas, mais especificamente, de jogos colaborativos, podemos

fomentar valores não somente para as salas de aula, mas para a vida.

96



3. Interação e Interfaces Tangíveis

De acordo com o Aurélio [Ferreira, 2010], a definição de tangível é:

Adjetivo de dois gêneros.

Que pode ser tangido, tocado ou apalpado; palpável, sensível.1.

P. ext. Que os sentidos podem apreender; perceptível, sensível, visível (fig.): 2.

um sinal tangível.

Econ. Diz-se de bens econômicos, ativos, etc., que têm existência física. [Opõe-3.

se, nesta acepç., a intangível (3).]

Portanto, no contexto deste trabalho, por “tangível” consideramos a tecnologia ba-

seada no conceito de aparelhos digitais “palpáveis”, ou “tocáveis”. Por interface tangível

consideramos aquela em que o usuário interage com o ambiente digital com o uso de dis-

positivos físicos. Estes dispositivos garantem uma interação muito mais realista entre o ho-

mem e o computador. Inicialmente, as interfaces tangíveis foram denominadas interfaces

“pegáveis”(em inglês, graspable user interfaces), mas este termo deixou de ser utilizado.

Os dispositivos tangíveis provêm três facilidades básicas:

Interatividade:1. um contato físico no equipamento é mapeado em resultados

em tempo real no meio digital;

Praticidade:2. o usuário fará a interação como se estivesse utilizando o equipa-

mento real. Por exemplo, no caso de uso de uma raquete em um jogo eletrô-

nico de tênis;

Colaboração:3. mais de um usuário poderá trabalhar com um equipamento, de

forma colaborativa, como se o tivessem fisicamente na mão. Por exemplo, a

utilização de um instrumento musical.

Para prover as facilidades, nas interfaces tangíveis temos de acordo com [Ullmer,

2000; Ishii, 2001]:

As representações físicas são acopladas computacionalmente às informações •

digitais, ou seja, ao modelo. Exemplos desses acoplamentos podem ser a li-

gação entre representações geométricas gráficas e os objetos reais, ou ainda,

simulações dinâmicas acopladas a objetos reais. Como exemplo, podemos ter

um simulador de vento acoplado a um simulador de fluxo de fluidos que pode

ser usado em uma ferramenta de planejamento urbano onde as construções

são objetos tangíveis, como visto na Figura 1;

97



Figura 1: Ferramenta de simulação de planejamento urbano.

As linhas indicam direção de vento [Ishii, 2008].

As representações físicas incorporam mecanismos para controle interativo. A •

movimentação física, deslocamento, rotação, ligação ou outras manipulações

entre objetos são as formas básicas de controle da interface;

As representações físicas são conceitualmente acopladas a representações digi-•

tais ativamente mediadas. As interfaces tangíveis dependem de um equilíbrio

entre representações digitais e físicas, ao mesmo tempo em que elementos fí-

sicos possuem um papel central, definindo papeis na representação e controle

da interface, as representações digitais, em particular áudio e gráfico, frequen-

temente apresentam parte significativa da informação dinâmica processada

pelo sistema de computação subjacente;

O estado físico dos objetos tangíveis incorpora parcialmente o estado digital •

do sistema: interfaces tangíveis são geralmente construídas a partir de sistemas

com artefatos físicos. Em conjunto, esses objetos possuem diversas proprieda-

des importantes. Como são compostas por elementos físicos, as interfaces tan-

gíveis são persistentes. Ao contrário de uma interface gráfica, elas não podem

ser duplicadas (ou destruídas) com uma simples ativação de um botão. Além

disso, frequentemente os artefatos tangíveis podem ser lidos tanto por pessoas

como por computadores através do seu estado físico, cujas configurações físi-

cas são fortemente acopladas ao estado digital dos sistemas que representam.

Um exemplo de sucesso das interfaces tangíveis é a oferecida pelo console Wii da

Nintendo. Os controles existentes no console permitem, por exemplo, que o usuário “di-

rija” um carro como se estivesse com um volante real na mão, ou que dê raquetadas em

um jogo de tênis, como se realmente estivesse em quadra. Uma raquetada mal orientada

fará com que a bola seja jogada para fora da quadra.

As próximas seções apresentam um histórico do desenvolvimento das interfaces

tangíveis, tipos de interfaces, aplicações e, finalmente, casos de aplicações em educação.

98



3.1. História

As interfaces gráficas de usuário (GUI), assim como seus dispositivos de interação

principais (mouse e teclado), se tornaram padrões e parte do cotidiano dos usuários.

Entretanto, como apontado por [Ishii, 2008], tais dispositivos não permitem que o usu-

ário utilize toda sua destreza e técnica de criação da mesma forma que o faz enquanto

manipulando objetos físicos reais.

Assim, há cerca de 28 anos, pesquisadores estudam sobre interfaces tangíveis de

usuário como um meio de melhorar o conceito de RA e permitir uma melhor interação

entre o usuário e o computador, aumentando sua produtividade [Blackwell et al., 2007].

Em meados de 1990, o grupo responsável pelos estudos de mídias tangíveis, Tangi-

ble Media Group, presente no Laboratório de mídia do MIT, trocou as interfaces gráficas

pelas interfaces tangíveis. A mudança ocorreu na tentativa de dar forma à visão de com-

putação ubíqua definida por Mark Weiser, cientista chefe na Xerox PARC, que prega a

utilização de objetos físicos em um ambiente físico, transparentemente integrados com

dispositivos computacionais [Ishii, 2008].

Em 1995, [Fitzmaurice, G. et al., 1995] apresentam o conceito de interfaces “pegá-

veis” de usuário. A ideia se baseava na utilização de alguns artefatos físicos chamados

de Bricks, que desempenhavam o papel de dispositivo de entrada. Tais artefatos po-

diam estar fortemente acoplados a objetos virtuais para a manipulação ou expressão

de ações.

Após a grande contribuição de Fitzmaurice e Ishii, em 1997, Ishii e Ulmer esten-

dem essas ideias e propõem o termo “interfaces de usuário tangíveis”, em inglês, “tan-

gible user interfaces”[Ishii e Ullmer, 1997]. Esses descrevem que sua inspiração veio da

história, elegendo o ábaco como um exemplo de protótipo para esse conceito. O ábaco

não é um dispositivo eletrônico, portanto não existe distinção entre entrada e saída.

Tudo que ele faz é permitir a sua manipulação de forma física, simultaneamente fazen-

do com que seus artefatos, componentes internos, representem controles físicos.

Diferentemente das GUI que fazem uma distinçãoentre representação e contro-

le, as interfaces de usuário tangíveis exploram o espaço aberto pela eliminação dessa

distinção[Ullmer, 2000].

Em 1999, surgem as interfaces tangíveis de primeira geração, sendo a URP –

Urban Planning Workbench – desenvolvida pelo Tangible Media Group, mostrada

na Figura 2, o exemplo mais conhecido. Esse sistema utilizava modelos físicos para

configurar e controlar simulações de sombras, f luxo de ventos, ref lexão de luzes e

congestionamento de tráfego. Adicionalmente, existem objetos para controlar fisi-

camente parâmetros da simulação urbana, como velocidade e direção do vento e

posição do sol.

99



Figura 2: URP com os objetos e sombras projetadas [Ishii, 2008].

No URP sombras digitais são projetadas na superfície da mesa onde os modelos fí-

sicos se encontram, seguindo os parâmetros de configuração especificados. Além disso,

todos os objetos e modelos de construção são representações digitais tangíveis, que po-

dem ser manipuladas diretamente para mudá-las de posição e inclinação, por exemplo.

Embora o URP permita uma facilidade muito grande de utilização e siga em suma

a definição de uma interface tangível, esse possui uma limitação quanto ao que pode

ser manipulado, pois as formas dos objetos não podem ser alteradas. Todos os objetos e

formas nesse sistema devem ser fixos e pré-definidos, somente permitindo a alteração

entre a interação dos objetos, disposição, dentre outros.

Assim, o Tangible Media Group inicia a definição do que seria a segunda geração da

tecnologia, conhecida como interfaces tangíveis “orgânicas”.

Em 2002, surge um novo tipo de interface tangível, Illuminating Clay, observado

na Figura 3, que permite o uso de diversos objetos incluindo a própria mão do usuário,

pedaços de papel, papelão, espuma, plásticoetc. para modelar objetos de uma paisagem

ou terreno, por exemplo. Tal sistema resultou da necessidade de engenheiros e designers

envolvidos em projetos de paisagem, arquitetura e indústria que continuavam a por

ênfase na utilização de modelos físicos, que muitas vezes, seriam posteriormente digita-

lizados de alguma forma [Piper et al., 2002].

Figura 3: Illuminating Clay - Manipulação do modelo físico e feedback na

visualização[Piper et al., 2002].

100



Em 2004, outra interface tangível orgânica foi criada, com base no Illuminating

Clay, sendo conhecida como Sandscape[Ratti et al., 2004].Sandscape era uma solução

mais barata que, cuja diferença básica estava nos sensores utilizados para capturar o

modelo sendo manipulado. O Sandscape, visto na Figura 5, onde analisava raios infra-

vermelhos capturados por uma câmera, enquanto o Illuminating Clay utilizava uma

variação de lasers para capturá-lo, o que é mais eficiente que a primeira solução, como

ilustrado na Figura 4.

Figura 4: Illuminating Clay

Laser Scanner[Ratti et al., 2004].

Figura 5: Sandscape

Optical Scanner[Ratti et al., 2004].

Atualmente, vários autores estão propondo mistos entre RA e interfaces tangíveis,

como uma possível alternativa mais portátil e mais barata do que os sistemas anteriores.

3.2. Aplicações Mistas

A seguir são descritas brevemente soluções de interfaces tangíveis que fazem uso de

outras tecnologias tais como RA e robótica.

3.2.1. Misto com Realidade Aumentada

Numa tentativa de se criar interfaces tangíveis de forma mais prática e fácil, [Dias

et al., 2004] propõem um misto entre interfaces tangíveis e RA.

A ideia básica é permitir a manipulação de objetos tangíveis virtualmente, tentando

promover a mesma sensação de uma interface tangível pura, mas num ambiente de RA.

Para isso, são utilizados marcadores nas mãos do usuário para que os gestos pos-

sam ser capturados e transmitidos ao ambiente virtual, permitindo a manipulação dire-

ta do objeto no mundo virtual, de forma similar a objetos físicos.

101



3.2.2. Misto com Robótica

O controle Wiimote do Nintendo Wii também está sendo pesquisado como uma

alternativa de alto desempenho para a captura de gestos e como ferramenta auxiliar na

construção de aplicações mistas, ou mesmo físicas.

Em 2008, [Guo e Sharlin, 2008] apresentaram um trabalho no qual exploram a

utilização de interfaces tangíveis através douso do Wiimote para o controle de robôs.

Em tal simulação, eles apresentam como tal Interface Tangível pode ser utilizada como

um meio para que um mediador humano possa controlar ações de um robô, utilizando

gestos, permitindo um controle natural do artefato robótico.

3.3. Interfaces Tangíveis na Educação

Na educação, interfaces tangíveis também são objetos de pesquisa como um meio para

melhorar a aprendizagem, além de permitir uma melhor absorção do conhecimento e enga-

jamento do aluno. Para o estudo de matemática, manipulativos são “objetos projetados que

representam conceitos matemáticos abstratos de forma concreta” [Falcão e Gomes, 2006]. Tais

objetos são comuns em salas de aula e possuem cores e formas que são atrativas às crianças,

além de poderem ser manipulados diretamente. Exemplos de tais objetos são: geoplano, blo-

cos dienes, sólidos geométricos e jogos de encaixe, ilustrado na Figura 6.

Figura 6: Crianças brincando com blocos lógicos (Blocos Dienes).

Entretanto, a utilização de interfaces tangíveis na educação, através do uso de

objetos, os manipulativos, não é recente e precede o uso dos computadores. Entre os

primeiros pensadores e projetistas destacam-se Friedrich Froebel e Maria Montessori

[Africano et al., 2004]. Froebel, que foi o inventor do jardim de infância, projetou os

“Presentes de Froebel” para o seu jardim de infância. Os Presentes de Froebel são ob-

jetos para brincadeiras que acompanham o desenvolvimento cognitivo das crianças.

Apesar do tempo em que foram projetados, ainda são comercializados [Froebelgifts,

102



2010]. Maria Montessori estendeu as ideias de Froebel para que os objetos fossem uti-

lizados por crianças mais velhas. Suas ideias, que visavam auxiliar o desenvolvimento

das capacidades sensoriais das crianças, foram implementadas em diversas escolas no

mundo, incluindo o Brasil.

Segundo [Zuckerman et al., 2005], as vantagens de se utilizar interfaces tangíveis

nesse contexto são:

Engajamento sensorial – • é basicamente o modo como as crianças aprendem,

em sua forma natural, utilizando vários sentidos (tato, visão, audição) em um

processo construtivo.

Acessibilidade – • poisaumenta a acessibilidade para crianças mais novas, prin-

cipalmente quando essas possuem dificuldades de aprendizado.

Aprendizado em grupo –• permite que várias mãos sejam utilizadas, isto é, que

várias crianças trabalhem de colaboradores na criação, facilitando a interação

e promovendo discussões em grupo.

Outro exemplo de uma interface tangível para o ensino de matemática, que pode ou

não fazer uso de computadores, é uma espécie de régua denominada BEAM, acrônimo

em inglês de Balancing Equations by Adapting Manipulatives [Leong e Horn, 2010]. O

BEAM, que segue as ideias de Montessori, tem funcionamento similar às antigas balan-

ças de braço e peso. Um exemplo de seu uso é mostrado na Figura 7. No modo offline

o BEAM permite verificar igualdades entre equações (há o equilíbrio da régua), e desi-

gualdades quando a régua pende para o maior lado. No modo online o BEAM é conecta-

do a um computador através de uma porta USB. O computador é capaz de ler as posições

dos pesos na régua e é capaz de apresentar as equações algébricas em tempo real.

Figura 7: Ilustração da solução da equação (3x2) + (4x5) = (7x3) +(2x2) usando o

BEAM[Leong e Horn, 2010].

Os blocos de LEGO, de grande sucesso comercial, são objetos tangíveis que podem

ser utilizados como ferramentas educacionais seguindo as ideias de Froebel [Fitzmau-

rice, G. W. et al., 1995].

Pesquisas mais recentes têm focado no uso intensivo de computadores com in-

terfaces tangíveis especialmente em atividades pedagógicas envolvendo crianças. Este

desenvolvimento é natural tendo em vista a redução do custo dos computadores, espe-

cialmente os portáteis, e sua disponibilidade para faixas etárias cada vez mais baixas.

103



As facilidades de comunicação proporcionadas pelos computadores também têm levado

a uma mudança de seu uso em educação. O primeiro uso dos computadores em educa-

ção era voltado para o estudo/aprendizagem individual. No entanto, crianças aprendem

através das brincadeiras e atividades sociais em grupo. Um exemplo do desenvolvimen-

to de uma interface tangível, educacional, com foco na colaboração é apresentado em

[Africano et al., 2004].

O trabalho apresenta um sistema para aprendizagem e brincadeiras. Para ilustrar

a viabilidade da proposta, foi desenvolvido um sistema, centrado em um boneco, Ely o

Explorador, visto na Figura 8. O sistema possui também uma unidade de acesso mul-

tiusuário e robusta, algumas ferramentas tangíveis e um software projetado para o am-

biente escolar. De acordo com os resultados apresentados, as crianças se envolveram

na brincadeira e a proposta se mostrou adequada como uma ferramenta auxiliar no

ambiente escolar.

Figura 8: Componentes de Ely o Explorador, que encontra-se à direita. À esquerda, a uni-

dade de acesso multiusuário. No centro, a sua tela de toque, contendo uma área comum e

três individuais, botões e leitor de RFID.

As interfaces tangíveis também têm sido utilizadas no ensino de conceitos abs-

tratos, como os matemáticos. Um trabalho atual nessa área é apresentado em [Falcão,

2007]. No trabalho, a autora, além de apresentar uma profunda revisão do uso de inter-

faces tangíveis no ensino, projeta uma interface tangível para auxiliar a aprendizagem

de frações no Ensino Fundamental brasileiro.

Os trabalhos desenvolvidos por [Resnick, 2005] fazem uso dos computadores. Os

autores desenvolveram blocos construtivos com poder computacional que chamaram

de MiMs Digitais (de Montessori – inspired Manipulatives, ou manipulativos inspirados

por Montessori). São desenvolvidos blocos de fluxo (FlowBlocks) e de sistema (System-

Blocks) que permitem a construção de sistemas interativos modulares físicos para com-

portamento dinâmico. Os resultados apresentados mostram que os MiMs, ilustrados na

Figura 9, são acessíveis mesmo para crianças pequenas.

104



Figura 9: MiMs de fl uxo, à esquerda, e de controle, na direita[Resnick, 2005].

4. Realidade Aumentada

O ser humano vive numa época onde a demanda por informação é enorme. Não

basta apenas ver um objeto ou ouvir seu som para identificá-lo, é preciso ter todas as

informações possíveis sobre ele. Em determinados meios, como numa sala de cirurgia

ou numa cabine de avião, esse conteúdo adicionalpode servital na hora de tomar uma

decisão crítica. Existem diversas formas de obter estes dados adicionais. Um piloto de

avião, por exemplo, tem o auxílio dos instrumentos de bordo e dos controladores de

voo. Como nem sempre essas informações estão diretamente em seu campo de visão,

o acesso a elas pode proporcionar um momento de distração preciosoem um instante

crítico. Por isso, formas mais diretas de exibir dados têm sido estudadas e a Realidade

Aumentada vem mostrando ser bastante promissorapara atender esta demanda.

Realidade Aumentada é umaárea da ciência da computaçãocapaz de interagir ele-

mentos virtuais com reais, criando um ambiente misto em tempo real. No caso do pilo-

to, já existem aviões capazes de exibir as informações mais críticas durante o voo numa

tela translúcida, de modo que o comandante seja capaz de visualizar esses dados sem

a necessidade de abaixar sua cabeça e procurar por ela num painel repleto de informa-

ções, ao mesmo tempo em que enxerga o ambiente real externo à aeronave.

RA tem se mostrado muito promissora por ser capaz de tornar a interação com o

usuário mais natural. Assim, ao invés de olhar apenas para um monitor e usar um ou

dois dispositivos para manipular as informações desejadas, o usuário pode interagir

com o ambiente inteiro ao seu redor através de gestos naturais em suas atividades co-

tidianas. Graças a esta enorme aplicabilidade, ela vem sendo bastante estudada, tanto

no meio acadêmico como em laboratórios de pesquisa e por isso já existem algumas

subáreas e linhas de atuação importantes, como será visto nesta seção.

105



4.1. Realidade Aumentada com Marcadores

A utilização de padrões visuais, também conhecidos como marcadores, tem como

objetivo amenizar a demanda de processamento gerada pelos algoritmos de visão com-

putacional e com isso tornar possível que as aplicações sejam executadas em tempo real.

Essa “simplificação” do rastreamento do mundo real faz com que hardware de baixo

custo possa ser utilizado, como processadores mais restritos e câmeras de menor reso-

lução e taxa de captura.

Os marcadores são elementos muito importantes em RA, pois são usados numa

etapa crucial neste tipo de aplicação: o registro. É neste passo que as informações do

mundo real e da câmera utilizada para capturá-las são alinhadas com os dados virtuais

gerados pelo computador, de forma que estes possam ser exibidos de maneira coerente.

Anteriormente o registro era realizado utilizando sensores 3D, sejam eles magnéti-

cos, ultrassônicos ou a laser. Entretanto, esses são caros e muitas vezes as suas dimensões

e estrutura não permitem o registro das cenas. Outras técnicas, baseadas apenas nas in-

formações capturadas pela câmera, como arestas ou textura, foram desenvolvidas [Stri-

cker e Kettenbach, 2001], mas apenas recentemente elas conseguiram adquirir maturida-

de suficiente para serem usadas com precisão em uma aplicação [Comport et al., 2006].

A alternativa encontrada para o registro foi a utilização do marcador. Este elemento

revolucionou a RA por conseguir ser um instrumento visual que auxilia na obtenção

dos dados necessários nesta etapa. Além disso, por serem de baixo custo e possuírem

uma grande variedade de códigos possíveis, pode-se inserir na cena tantos quantos fo-

rem necessários.

4.1.1 Tipos de Marcadores

Por ser uma abordagem bastante difundida, existem várias aplicações de RA base-

adas em marcadores e, consequentemente, diversos tipos deles foram propostos. Dentre

os mais comuns estão o fiducial, o idBased, o DataMatrix, o split e o frame.

Marcadores Fiduciais

Um dos primeiros padrões a ser utilizado por esse tipo de aplicação consistia em

um quadrado com bordas pretas. Em seu centro, localiza-se um padrão (template) espe-

cífico que o torna único e distinguível de outros marcadores. Nele, qualquer informação

pode estar gravada, como letra, número, nome ou imagem e seu rastreamento é realiza-

do comparando trechos da imagem obtida com um banco de dados de marcadores até

que um deles seja similar o suficiente à região central capturada pela câmera.

Por fazer várias comparações durante o rastreamento, este tipo de marcador não

é muito escalável, pois quanto mais deles estiverem na região de captura da câmera,

106



mais lento se torna o rastreamento, tanto que o ARToolKit [Kato e Billinghurst, 1999],

biblioteca de RA que utiliza marcadores fiduciais, limita a quantidade de marcadores

rastreados para um máximo de 20 simultâneos.

idBased Markers

Estes marcadores foram desenvolvidos para resolver o problema de escalabilidade

dos marcadores fiduciais. O princípio deles é que o código, que antes poderia ser qual-

quer imagem, agora é representado por uma matriz de quadrados pretos e brancos. Com

isso, o rastreamento deixa de ser feito por similaridade de imagens e passa a ser realiza-

do através da leitura direta de cada elemento da matriz, de onde o código é extraído.

Graças à diminuição da carga de processamento, o número de marcadores rastrea-

do simultaneamente aumentou bastante. O ARTag [Fiala, 2005], outra biblioteca de RA,

mas que utiliza marcadores baseados em id, possui exemplos onde mais de 100 deles são

rastreados ao mesmo tempo.

DataMatrix Markers

Os DataMatrix markers são bastante semelhantes aos descritos na subseção ante-

rior; a diferença se encontra na codificação [Aim, 2010]. Enquanto neles qualquer infor-

mação pode ser usada como representante de um determinado código, os marcadores

baseados em DataMatrix seguem um padrão comum aos códigos de barra 2D, determi-

nados pela ISO. Outra diferença é na quantidade de código possível para um conjunto

de marcadores, pois os DataMatrix markers têm um número fixo de 2235 códigos, en-

quanto os baseados em id dependem do tamanho da matriz utilizada.

Split Markers

Também são marcadores baseados em id, porém o código localiza-se em duas de

suas bordas, deixando a área entre eles livre para a inserção de qualquer informação.

Este tipo de marcador foi desenvolvido primeiramente pela Sony para o jogo “Eye of

Judgment” [Nishino, 2009], de modo que as informações dos personagens pudessem ser

impressas no cartão juntamente com o código usado para seu rastreamento.

FrameMarker

Outro marcador baseado em id, o Frame marker é semelhante ao Split marker, dife-

renciado deste pelo fato do código estar em todas as bordas e não apenas em duas [Sch-

malstieg, 2009]. Desta forma, o marcador ganha maior robustez e simplicidade de ras-

treamento sem perder a área livre para inserção de informação. Nele pode ser vista uma

borda fina e contínua que delimita o marcador. Internamente a esta borda está o código,

uma sequência de quadrados, ou bits, em cada lateral. O código é o mesmo para ambas

as bordas, mudando apenas o primeiro e o último bits, que são usados para indicar a

107



orientação do marcador. O número máximo de marcadores distintos que podem ser

criados com essa abordagem é proporcional ao número de bits utilizado nas laterais.

A Figura 10 ilustra os tipos de marcadores descritos nesta seção.

Figura 10: Da esquerda para a direita, os marcadores fi ducial;idBased, DataMatrix;

SplitMarker; e FrameMarker.

4.1.2 Bibliotecas

O suporte ao uso de marcadores em RA tem evoluído bastante ao longo dos anos. É

possível encontrar uma série de ferramentas (toolkits) de desenvolvimento de aplicações,

muitas delas open-source, capazes de fornecer informação sobre o posicionamento cor-

reto dos marcadores em uma cena e a posterior renderização de informação em posição

relativa aos mesmos. Uma breve descrição é mostrada em sequência.

ARToolKit

O ARToolKit foi originalmente desenvolvido para servir de apoio na concepção de

interfaces colaborativas por Hirokazu Kato [Kato e Billinghurst, 1999], na Universidade

de Osaka. Desde então, tem sido mantido pelo Human Interface Technology Laboratory

(HIT Lab) da Universidade de Washington e pelo HIT Lab NZ da Universidade de Can-

terbury, em Christchurch.

O ARToolKit é uma biblioteca de software open-source, escrita na linguagem C,

para concepção de aplicações em RA. Um exemplo de uma possível aplicação pode ser

um personagem virtual 3D que aparecerá em cima de um marcador, que é um cartão

com um padrão impresso correspondente a uma imagem específica. Esta imagem pode

ser visualizada através de um display utilizado pelo usuário e, à medida que o mar-

cador é movimentado a imagem também é transladada, dando a impressão de estar

colada ao marcador.

Uma das grandes dificuldades ao se desenvolver aplicações em RA é o problema em

calcular o viewpoint do usuário em tempo real, de modo que as imagens virtuais estejam

exatamente alinhadas com os objetos reais, ou seja, o problema é saber para onde o usuá-

rio estará olhando em um determinado momento de modo que a imagem seja posiciona-

da no lugar correto. O ARToolKit se propõe a resolver este problema usando uma técnica

108



que calcula a posição real da câmera presa ao display e a orientação relativa a marcadores,

permitindo então que o programador possa sobrepor objetos virtuais nestes.

As principais características do ARToolKitsão:

Tracking para posicionamento e orientação de uma única câmera;•

Código que usa como padrão um quadrado de bordas pretas;•

Possibilidade de uso de qualquer marcador, desde que o mesmo obedeça ao pa-•

drão;

Código simples para calibração da câmera;•

Rápido o suficiente para possibilitar aplicações de RA em tempo real;•

Distribuição multi- plataforma, como por exemplo, SGI IRIX, Linux, MacOS e •

Windows, e distribuição do código fonte completo.

O funcionamento do ARToolKit é muito simples. Primeiramente, a câmera posi-

cionada no display do usuário captura as imagens do mundo real e as envia para um

computador, que procurará nas imagens frames que contenham o padrão do quadrado

de bordas pretas, ou seja, um marcador. Se algum for encontrado, o computador efetu-

ará uma série de cálculos matemáticos para saber qual a posição da câmera relativa ao

marcador visualizado. Uma vez que a posição da câmera é conhecida um modelo com-

putacional gráfico, que é o objeto virtual, será desenhado na mesma posição. A saída,

portanto, nada mais é do que esta imagem virtual “grudada” em cima do marcador, que

o usuário poderá visualizar através de qualquer display que esteja usando.

ARToolKitPlus

O ARToolKitPlus foi desenvolvido na Graz University Technology dentro do pro-

jeto Studierstube, e é uma biblioteca open-source de RA baseada no ARToolKit, embora

a primeira se preocupe exclusivamente com a questão da detecção de marcadores, não

oferecendo funções para captura de vídeo ou renderização de objetos 3D [Wagner e

Schmalstieg, 2003; Wagner, 2006].

Seu código fonte conta com várias otimizações, tais como a utilização de mate-

mática de ponto fixo com o intuito de gerar aplicações eficientes para os dispositivos

móveis, como por exemplo os PDAs e smartphones. Os marcadores utilizados por esta

biblioteca são semelhantes aos do ARToolKit, com a diferença que o desenho no interior

do quadrado de bordas pretas consiste em uma codificação do identificador do marca-

dor. Tal codificação permite que o usuário possa utilizar até 512 diferentes marcadores,

diminuindo a ocorrência da confusão entre marcadores diferentes.

O ARToolKitPlus utiliza a técnica de limiar adaptativo, que consiste em perceber

alterações de iluminação no ambiente capturado pela câmera, de forma que a detecção

dos marcadores não seja prejudicada. Esta biblioteca também oferece suporte ao usuário

de utilizar marcadores com borda de largura variável, desta forma pode- se diminuir a

109



largura da borda para melhor aproveitar o espaço para codificação, fazendo com que

marcadores menores possam ser detectados. Outra característica consiste na capacidade

de realizar uma compensação sobre imagens de câmeras que geram uma queda radial

de luminância. Este fato ocorre em algumas câmeras onde a imagem capturada por elas

se apresenta mais escura nos cantos, fazendo com que os marcadores situados nessas

regiões não sejam detectados.

ARTag

O ARTag foi desenvolvido pelo National Research Council of Canada e inspirado

no ARToolKit. O ARTag, tal como o ARToolKit, também consiste em uma biblioteca

de padrões, mas diferentemente do segundo, que compara imagens, o ARTag verifica

códigos digitais compostos de 0’s e 1’s. O marcador do ARTag também vem a ser um

quadrado de bordas pretas, mas seu interior é preenchido com uma malha 6 x 6 de qua-

drados pretos e brancos que representam os códigos digitais.

O ARTag foi concebido para não conter alguns dos problemas que o ARToolKit

possui. Entre esses problemas pode- se destacar três que são mais comuns, e que no

ARTag foram corrigidos:

Falso positivo: acontece quando a presença de um marcador é reportada, mas •

não existe nenhum no ambiente;

Inter- marker confusion: acontece quando a presença de um marcador é repor-•

tada, mas com o ID errado;

Falso negativo: acontece quando existe um marcador no ambiente, mas sua •

presença não é reportada.

Além de solucionar esses problemas presentes no ARToolKit, o ARTag ainda tem

a vantagem de possuir 2002 marcadores. Dentre esses 1001 têm o mesmo padrão do

ARToolKit, um quadrado de bordas pretas e interior branco, enquanto que os restan-

tes 1001 têm o padrão inverso, um quadrado de bordas brancas e interior preto [Fiala,

2005]. Outra vantagem sobre o ARToolKit é que ao contrário deste, no ARTag não é ne-

cessário que um arquivo contendo todos os padrões seja previamente carregado. Além

do que os marcadores do ARTag podem ser reconhecidos mesmo que uma parte deles

esteja oculta, o que não acontece com os marcadores do ARToolKit.

O processo para o reconhecimento de um marcador no ARTag começa basicamente

do mesmo modo que no ARToolKit; primeiramente deve ser localizado o contorno da

borda do quadrado. Após isso, a região interna que contém a malha é retirada e são

determinados os códigos de 0’s e 1’s contidos. Todo o processamento subsequente de

identificar e verificar o marcador é feito digitalmente. Quatro sequências binárias de

36 bits são obtidas do array de códigos binários originários da malha, uma para cada

uma das quatro possíveis posições rotacionadas, e dentre estas apenas uma será validada

110



pelo processo de decodificação. A sequência binária codificada no marcador encapsula

um ID de 10 bits usando métodos digitais; os 26 bits extras provêem redundância para

reduzir as chances de detecção e identificação falsas e também para prover unicamente

uma das quatro possíveis rotações [Fiala, 2005].

StudierstubeTracker

O Studierstube Tracker é uma biblioteca de visão computacional para detecção e

estimativa de pose de marcadores fiduciais 2D [Schmalstieg, 2009]. É considerado um

sucessor da biblioteca ARToolKitPlus e assemelha-se tanto dela como ao ARToolKit e

ARTag, porém sua implementação base é completamente diferente. O projeto do Stu-

dierstube Tracker foi montado com foco em alto desempenho tanto para PCs, quanto

para celulares.

O desenvolvimento do Studierstube Tracker deu início quatro anos após o surgi-

mento do ARToolKitPlus. Esse rastreador apresenta requisitos de memória bastantes

baixos, na ordem de 100KB, o que representa de 5 a 10% do consumo de memória do

ARToolKitPlus, além do processamento ser cerca de duas vezes mais rápido do que a

mesma biblioteca em celulares, e aproximadamente 1 ms por frame em um PC. Enquan-

to o ARToolKitPlus segue uma abordagem monolítica, necessitando ser configurado

em tempo de compilação, o Studierstube Tracker é altamente modular: desenvolvedores

podem estender o rastreador de várias formas, criando novas funcionalidades para o

mesmo. Ao contrário do ARToolKitPlus, o Studierstube Tracker não é open-source.

Vários tipos de marcador são suportados: template (similar aos do ARToolKit), id-

Based, DataMatrix, Frame markers, Split markers e Grid markers.

Flare

O Flare (FlashAugmentedRealityEngine*Tracker) é uma biblioteca de visão com-

putacional para detecção e estimativa de pose de códigos de barra 2D [Imagination,

2010]. Ele se assemelha bastante ao ARToolKit, ARToolKitPlus e ARTag, porém apre-

sentando uma implementação completamente distinta.

As principais características do Flare são:

Suporte a variados tipos de marcadores (• idBased, DataMatrix e Frame ma-

rkers), os quais podem ser usados concorrentemente;

Apresenta um bom desempenho ao ser executado nos • browsers;

É considerada a solução mais rápida de rastreamento para web;•

Baixo consumo de memória;•

Feito em ActionScript e suportado a partir da versão 10.0 do Adobe Flash, é •

uma solução fechada, com licença paga.

111



FlartoolKit

O FlartoolKit é uma versão do ARToolKit portada para ActionScript 3 [Flartoolkit,

2010]. Atualmente, o FlartoolKit baseia-se no NyARToolKit, uma versão do ARToolKit

em Java. A biblioteca se encarrega do reconhecimento do marcador na imagem de en-

trada e calcula sua posição 3D e orientação. Porém, o suporte à renderização não é for-

necido.

O FlartoolKit é livre para ser usado em aplicações não comerciais sob a licença GPL,

ou seja, o código-fonte da aplicação que utiliza a biblioteca deve ser disponibilizado.

AndAR

O AndAR é um projeto que possibilita a execução de aplicações de RA na platafor-

ma Android [Andar, 2010]. O projeto por completo é disponibilizado sob a licença GPL.

A empresa ARToolworks oferece licença comercial para uso do ARToolKit.

SLARToolKit

O SLARToolKit é uma biblioteca de RA para a plataforma Silverlight com o objeti-

vo de permitir o desenvolvimento de aplicações em tempo real de forma simplificada e

rápida [Slartoolkit]. Pode ser utilizado com a Webcam API, que foi introduzida no Sil-

verlight 4, ou com qualquer outro CaptureSource ou um WriteableBitmap. A biblioteca

baseia-se tanto no NyARToolKit como no ARToolKit. Um modelo duplo de licença pode

ser utilizado com a biblioteca, o que permite que ela seja usada tanto para aplicações

abertas como fechadas, de acordo com algumas restrições.

NyARToolKit

O [Nyala] é uma derivação do conhecido ARToolKit. Ao contrário de seu predeces-

sor, ele foi portado para várias plataformas distintas, como Java, C# e Flash, e durante

o processo tornou-se orientado a objetos, diferentemente da abordagem procedural do

ARToolKit.

A biblioteca consiste em uma versão do ARToolKit implementada inteiramente em

Java. A versão do ARToolKit que deu origem à biblioteca foi a 2.72.1. Nenhum códi-

go nativo é utilizado. Essa característica torna a execução mais lenta do que a origi-

nal, porém completamente independente de arquitetura. Assim como seu predecessor,

o NyARToolKit é uma biblioteca de funções que permite interpretação visual da cena

capturada e integração de elementos virtuais em ambientes reais.

Apesar de ser nativa em Java, a biblioteca funciona em C# e no sistema operacional

Android de forma satisfatória. Existem inúmeros outros portes para outras plataformas

que foram baseados no NyARToolKit.

A empresa que comercializa o ARToolKit, ARToolworks, detém a licença comercial

do NyARToolKit, apesar de não fazer parte do desenvolvimento da biblioteca. Por este

112



motivo, a biblioteca é distribuída como sendo de código aberto, porém como produto

não comercial.

A seguir estão listadas algumas características da biblioteca:•

Permite a criação de aplicações de RA em tempo real;•

Sobrepõe objetos 3D virtuais em marcadores reais;•

Suporta diferentes entradas de vídeo (USB, • firewire, placa de captura) e dife-

rentes formatos (RGB/YUV420P, YUV);

Provê rastreamento de marcadores rápido e de baixo custo computacional (detec-

ção planar em tempo real);

Suporta VRML e telefones rodando Android nativamente.

4.1.3 Aplicações

Atualmente, RA com marcadores é utilizada nas mais diversas áreas. Desde entre-

tenimento e propaganda ao uso na educação e indústria. A seguir alguns exemplos nas

áreas de jogos e educação serão listados.

Invisible Train

O Invisible Train [Wagner et al., 2005] é uma aplicação que mistura entretenimento

e dispositivos móveis. Esse jogo foidesenvolvido primeiramente para crianças de nível

primário, e é um jogo multiplayer no qual os participantes guiam um trem virtual atra-

vés de um trilho real construído em miniatura. Este trem só é visível para osjogadores

através de PDAs, e para esses usuários são permitidas duas ações: operar as junções en-

tre ostrilhos ou mudar a velocidade do trem, tudo isto através das telas sensíveis a toque

dos próprios PDAs. Vide a Figura 11.

Figura 11: Dois PDAs rodando o Invisible Train[Wagner et al., 2005].

113



Magic Cubes

O projeto MagicCubes [Zhou et al., 2005]foi desenvolvido para promover intera-

ções físicas e sociais dentro das famílias. Ele consiste basicamente em marcadores em

formato de cubo que contam histórias, como se fossem umlivro de histórias infantis,

servindo também para “brincar de casinha”, montando a mobília para quartos e salas, e

por fim ainda servem para jogos de tabuleiro, conforme ilustrado na Figura 12.

Figura 12: Magic Cubes usada como contador de história[Zhou et al., 2005].

Magic Table

Por fim tem-se o Magic Table [Berard, 2003], que vem a ser um quadro branco onde

se escreve, desenha e apaga.A diferença entre um quadro branco comum e o Magic

Tableconsiste em scanners que capturam o que éescrito no quadro e colocamo conteúdo

em retângulos,chamados de patches, que são manipulados atravésde pequenos círculos,

ostokens, sobre o quadro, vide Figura 13.

Figura 13: Magic Table em uso[Berard, 2003].

114



4.2. Realidade Aumentada Projetiva

Uma das formas mais comuns de se conseguir que o usuário visualize elementos

reais junto aos virtuais em aplicações de RA é utilizando os famosos Head-Mounted

Displays, sejam eles Optical See-Through, quando a informação do mundo real é vis-

ta diretamente pelo olho e é acrescida dos elementos virtuais, ou Video See-Through,

onde a imagem do mundo real é capturada por uma câmera no dispositivo e composta

com a informação virtual para ser exibida ao usuário. Porém, estes dispositivos ainda

apresentam alguns problemas que dificultam o seu uso, sendo a ergonomia e o preço

os principais entraves. Outra forma de atingir o objetivo de exibir informações virtuais

e reais que vem ganhando bastante espaço é a RA Espacial, onde o ambiente em que o

usuário se encontra inserido é aumentado com imagens integradas diretamente ao lugar

e não apenas ao campo visual do observador [Raskar et al., 1998]. Esta inserção pode ser

feita através de simples telas anexadas ao ambiente ou por meios mais complexos, como

o uso de espelhos semi-translúcidos para criar o efeito de hologramas.

A forma de integração mais comum, porém, é dada por projeções diretamente na

superfície, tanto que já existe uma subdivisão da RA Espacial que trata apenas da inser-

ção de objetos virtuais no ambiente real utilizando projetores, chamada de RA Projeti-

va. A Figura 14 ilustra este conceito.

Figura 14: Àesquerdatem-se a maquete de um palácio sem textura alguma, totalmente

branca. Utilizando projetores, a textura juntamente com a posição do sol é simulada, à

direita[Raskar et al., 1998].

ARA possui um grande potencial de aplicabilidade por conseguir adicionar infor-

mações ao mundo real e melhorar significativamente a forma como o usuário interage

tanto com os elementos reais, como virtuais. Já a RAProjetiva vem mostrando também

ter um grande potencial de aplicações. Já existem diversas iniciativas de seu uso no meio

comercial, comoem vitrines de lojas interativas. Nelas, os produtos são projetados na

vitrine e o cliente interage com as ofertas. Ele pode desde ver como as roupas ficam nele,

até finalizar a compra, entrando na loja apenas para receber o produto[Ivista, 2011].A

115



área médica também já faz uso deste tipo de aplicação, na qual os médicos possuem um

dispositivo que projeta sobre o paciente suas veias e artérias, facilitando assim o encon-

tro destas para o uso em procedimentos. Uma das áreas que mais faz uso de projeções

é a publicidade. Há muitas iniciativas voltadas para a divulgação de marcas, produtos e

conteúdo, como os pisos e paredes interativos [Streitz et al.], projeções de animações em

produtos e exposição de museus. A Figura 15 mostra algumas dessas ações.

Figura 15: A imagem ilustra algumas aplicações de RA Projetiva. Acima e à esquerda te-

mos o exemplo de um museu onde o expectador interage com a exposição e à direita uma

vitrine interativa[Ivista, 2011]. Abaixo, uma parede interativa[Streitz et al.].

A RA Projetiva possui algumas características peculiares, a começar pelo registro do

ambiente real. Na RA “tradicional”, a imagem virtual é anexada a porções do ambiente

que compreendem apenas o ponto de vista do usuário, diferentemente da RA Projetiva

onde a informação é atribuída ao ambiente inteiro. Assim, é feito o registro apenas do

espaço e de todos os objetos que o compõem e, independente da movimentação da pes-

soa e de como ela observa, as informações virtuais serão sempre as mesmas. Entretanto,

para algumas aplicações é importante que a projeção mude à medida que o observador se

movimenta, o que pode ser útil para prover uma noção de profundidade ou sensibilidade

a contexto. Para isto, é necessário que não só o ambiente esteja registrado, mas também

que haja um rastreamento da cabeça do usuário, que pode ser feito utilizando sensores

presos à cabeça do mesmo. A Figura 16 mostra um exemplo. Outra forma de obter pro-

fundidade para o observador é utilizando projeções estéreo e óculos polarizados, como

em muitas salas de cinema hoje em dia. Contudo, esta abordagem não elimina a neces-

sidade do rastreamento da cabeça do usuário. Ao contrário, ela se torna imprescindível,

pois as projeções estéreo dependem justamente do ponto de vista do usuário.

116



Figura 16: Exemplo de aplicação de RA Projetiva onde há o rastreamento de acordo com o

ponto de vista do observador [Bimber et al., 2005].

Outra peculiaridade se dá em relação à oclusão, pois na RA Projetiva os elementos vir-

tuais podem sempre ser ocludidos, porém nunca se sobrepõem totalmente ao mundo real,

ao contrário da RA “convencional” onde ocludir os elementos virtuaisé bastante complexo,

mas estes se justapõem muito facilmente sobre os objetos reais. Também é preciso tomar

cuidado com as cores dos objetos virtuais, pois esta característica pode ser modificada no

momento da projeção dependendo das cores da superfície onde ocorre a exibição.

O fato de o ambiente real interagir diretamente com os objetos virtuais influencia

bastante na forma como o usuário interatua com a aplicação. As características da RA

Projetiva praticamente impõem uma interação mais natural. Assim, é muito comum

o uso de interfaces tangíveis e o rastreamento de partes do corpo do usuário, como as

mãos, de modo que estes são usados para fornecer a entrada para o sistema.

Assim, um dos grandes benefícios da RA Projetiva é a capacidade de prover a inte-

ração dos elementos virtuais com os reais de forma imersiva para o usuário sem a neces-

sidade de Head-Mounted Displays. Outra vantagem é ser possível controlar o ambiente

de forma relativamente simples para se conseguir uma boa qualidade na projeção. O fato

de o objeto virtual ser inserido em geral próximo ao real e da imagem não incidir direta-

mente no olho do usuário, e sim através de uma reflexão vinda de uma superfície pouco

reflexiva, como uma parede, torna esta abordagem muito agradável ao olho humano.

Em contrapartida a RA Projetiva é bastante dependente da superfície de projeção e

do ambiente. Caso o local de projeção não seja difuso, possua uma cor clara e uniforme,

a qualidade da imagem se torna bastante comprometida. A nitidez das cores também

está diretamente relacionada à luminosidade do ambiente. Assim, quanto mais escuro,

melhor será a qualidade das cores, eliminando a necessidade de projetores muito poten-

tes. Um problema a ser tratado também é o das sombras, que pode ser resolvido basica-

mente de duas formas: a mais simples é posicionar muito bem os projetores; a outra, um

pouco mais complexa, é utilizando múltiplos projetores, que precisam estar alinhados

para que o conteúdo seja uniformemente visualizado.

117



5. Estudo de Caso

O estudo de caso descrito nesta seção pretende integrar todos os conceitos vistos

nas seções anteriores, de modo a desenvolver o conceito de um produto fechado que uti-

liza RA para criar um jogo educacional possuindo uma interface tangível, e explorando

assim os benefícios das atividades lúdicas para a educação.

Existem várias possibilidades de aplicações que integram esses conceitos. Para este

minicurso, os autores criaram um jogo baseado em blocos para auxiliar na alfabetização

de crianças.

5.1. Definição

Como foi mostrado anteriormente, quando as crianças estão brincando com jogos

de blocos, na realidade elas estão aprendendo a pensar e resolver problemas a partir do

momento em que manipulam espacialmente os objetos e os classificam unindo os ele-

mentos comuns. Este tipo de atividade influencia diretamente no modo como eles veem

e compreendem o mundo ao seu redor.

Deste modo, os jogos baseados em blocos são muito utilizados como brinquedos

educativos, pois servem como instrumento para o aprendizado, especialmente para

crianças de até oito anos. Dependendo dos blocos, o professor pode usá-los para criar

atividades que desenvolvam o raciocíniológico e matemático das crianças, assim como

o vocabulário e até a criatividade.Entretanto, como os blocos tradicionais possuem suas

faces estáticas, é necessário praticamente um jogo diferente para cada uma das ativida-

des que o tutor queira executar, limitando as possibilidades do mesmo. Desta forma,

existem diversosbrinquedos baseados em blocos com um único propósito.

O estudo de caso proposto visa solucionar esta limitação a partir do desenvolvi-

mento de blocos dinâmicos, onde qualquer informação desejada possa ser gravada em

suas faces durante a atividade, desde uma simples letra ou número, até uma animação.

Dessa forma, as possibilidades do professor aumentam substancialmente e ele pode usar

sua criatividade para criar praticamente qualquer atividade, desde as mais tradicionais

já citadas, até outras mais complexas de se trabalhar com blocos convencionais, como

o ensino de música.

Para tornar estes blocos dinâmicos possíveis, utiliza-se RA Projetiva para criar um

sistema computacional manipulado por uma interface tangível, que seriam os blocos

físicos. Cada bloco possui um marcador em suas faces para diferenciá-lo dos demais,

que será rastreado por uma câmera. De posse das posições e orientações de cada cubo,

o conteúdo de cada um deles será projetado apenas na face do respectivo bloco, assim

ele funciona ao mesmo tempo como um display, pois irá exibir a informação para o

usuário, e um dispositivo de entrada, já que a sua manipulação influenciará no jogo e no

118



que será mostrado. Por se tratar de um bloco físico, todos os benefícios já mencionados

associados aos brinquedos tradicionais são preservados, mas por se tratar de um siste-

ma computacional, outros pontos positivos são acrescidos, como, além dos já citados, a

possibilidade de retorno sonoro. A Figura 17 ilustra o conceito proposto.

Figura 17: Estrutura proposta para uma aplicação de RA Projetiva envolvendo 3 blocos,

possuindo um Frame Marker cada e a projeção do conteúdo ocorre apenas no interior

dos marcadores. Para isso, tanto câmera como projetor precisam estar alinhados.

5.2. Concepção

Por se tratar de um sistema a ser usado por educadores como instrumento para

aumentar a capacidade de aprendizado e o desenvolvimento das crianças, é necessário

que todo o desenvolvimento do jogo seja acompanhado de perto por professores, de

modo que estes possam transmitir toda a sua experiência e vivência em sala de aula para

acrescentar ao projeto ideias úteis para o mesmo.

Existem várias metodologias, princípios e técnicas de design para o desenvolvimen-

to de jogos educacionais, porém nenhuma delas será detalhadaneste tutorial, sendo aqui

descrito apenas como se deu a concepção do estudo de caso citado na subseção anterior,

o que já serve como uma boa base para o design de diversos outros sistemas que sigam

essas mesmas características.

O ponto de partida foi a definição de um objetivo claro para o projeto, pois é

ele quem vaideterminar as pesquisas,que por sua vez irão guiar o desenvolvimento.

Como este estudo de caso visa criar uma atividade para educação que utilize blocos

dinâmicos,pode-se dizer que o principal objetivo é o de desenvolver um jogo baseado

em blocos dinâmicos que possa ser inserido como ferramenta de apoio na alfabetização

119



infantil e que seja capaz de contribuir com o estímulo à criatividade e ao desenvolvimento

de crianças na faixa etária de 5 a 8 anos.

Este objetivo deixa claro que o jogo deve auxiliar o professor, contribuindo para o

processo de aprendizagem o mais naturalmente possível, sem retirar o foco dos alunos

do objetivo principal que é aprender de forma lúdica. Para que esta meta seja alcançada,

é importante compreender o domínio de sala de aula, o que levanta algumas questões

que precisam ser respondidas. Dentre elas estão:

Como é a alfabetização de crianças atualmente?

Como a alfabetização de crianças pode se tornar mais atrativa para os pequenos e

os professoresutilizando interfaces tangíveis?

O que as interfaces tangíveis atuais podem prover em relação à interação e ao en-

sino de crianças?

A respostadestas questões veio atravésde uma pesquisa dividida em duas fases:

Análise de competidores: uma pesquisa detalhada acerca do que já foi e está sendo

desenvolvido, tanto na educação como temos hoje, como nas interfaces tangíveis e no

seu uso no contexto de jogos. Praticamente todos os resultados desta fase vieram de uma

forte pesquisa bibliográfica em ambas as áreas. Dela foi possível concluir que os jogos

baseados em blocos dinâmicos se encaixam na categoria das interfaces tangíveis conhe-

cidas como manipulativos digitais equeo desenvolvimento tecnológico destas interfaces

já caminhou bastante, porém ainda é visível a falta de aplicativos interessantes capazes

de suprir as necessidades de ensino para crianças[Falcão e Gomes, 2006].

Compreensão do contexto: nesta fase foi realizada uma observação com o objetivo

de se compreender o funcionamento, dinâmica, regras, rotina e dificuldades da sala de

aula, além de uma entrevistasemi-estruturada com os professores para a obtenção de

informações e contribuições valiosas, assim como os requisitos genéricos do produto.

Os resultados obtidos mostraram que a alfabetização tradicionalnãofaz uso dos mani-

pulativos, porém os professores procuram utilizar recursos multimídia como forma de

chamar a atenção das crianças, que gostam quando são expostas a situações onde vários

de seus sentidos são estimulados, em especial a visão e audição. Os livros atuais também

seguem esta tendência, pois utilizam vários elementos gráficos. Também foi possível

observar a forma como os professores ministram suas atividades e avaliam seus alunos,

algo de fundamental importância na elaboração da dinâmica de um jogo educativo.

Com o resultado da pesquisa foi iniciada a fase de criação do jogo, que consistiu

em duas sessões de prototipação, a primeira em papel e a segunda em isopor, no mesmo

formato dos blocos, como visto na Figura 18. A partir dessas duas fases de prototipagem

foi possível refinar com os professores a ideia inicial do jogo de modo que ele pudesse

melhor atender às necessidades de uma sala de aula.

120



5.3. Desenvolvimento do produto

O desenvolvimento do produtopassa por duas etapas. A primeira é a do sistema

computacional em si, utilizando RA Projetiva e interface tangível; a segunda é a do jogo,

cuidadosamente concebido como mostrado na subseção anterior, que será executado

sobre o sistema.

Figura 18: Imagens dos protótiposemisoporutilizados nasegundafase de prototipação.

A primeiraquestão a ser tratada no desenvolvimentode um sistema de RA é o modo

como o rastreamento será realizado. No estudo de caso elaborado, este assunto requer

uma atenção um pouco maior, pois, por se tratar de uma interface tangível utilizando

RA Projetiva, o rastreamento, a exibição da informação e o dispositivo de entrada en-

volvem o mesmo objeto.

Como os blocos serão a superfície de projeção, estes não podem ser texturizados,

devendo ser lisos e na cor branca para que o mínimo de interferência ocorra na exibição

das cores. Entretanto, não é possível rastrear uma superfície com essas características. Se

todos os blocos são uniformemente brancos, não há como sequer distinguir um do ou-

tro. Para resolver este entrave, a primeira solução pensada foi a de adicionar uma borda

colorida nos blocos. Entretanto, esta resolução possui algumas falhas, sendo a principal

delas uma limitação no número máximo de marcadores rastreados simultaneamente,

que seria de apenas quinze. Isto se deve ao fato de que o valor das cores é muito sensível

à iluminação ambiente e para que se tenha uma margem de segurançaé necessária uma

paleta com cores mais distantes umas das outras, como a CGA [Ibm, 1981], que possui

apenas dezesseis.Porém, uma destas dezesseis cores não pode ser utilizada já que a cor

branca é a mesma do bloco, não sendo possível assim uma borda com esta tonalidade.

A solução final adotada foi a utilização de um Frame Marker, com o qual é possível

ter todos os benefícios de um marcador comum e ainda conseguir que uma grande re-

gião do bloco não possua nenhuma informação, ficando totalmente branca para receber

a projeção. Até onde os autores conhecem, não existe nenhuma biblioteca gratuita de

RA que dê suporte a este tipo de marcador, e por isso foi criado tanto um marcador

específico como um rastreador capaz de suprir as necessidades do projeto.

121



O marcador, mostrado na Figura 19, possui uma borda fina e contínua que o deli-

mita. Interno a ela está o código, umasequência de 10 quadrados, ou bits, para cada lado.

O código é o mesmo para ambas as bordas para que a redundância dê mais robustez à

identificação; o que muda é apenas o primeiro e último bit, que servem para indicar a

orientação do marcador.Entre essespequenos quadrados das extremidades estãoos ou-

tros oito que formarão o código em si. Este número permite a confecção de até 256

marcadores diferentes, que é uma quantidade suficiente para a maioria das aplicações.

Caso haja a necessidade de mais marcadores, pode-se adicionar mais um bit ao código.

Porém, deve-se tomar cuidado, pois quanto mais bits, menor o tamanho dos quadrados,

tornando o rastreamento mais suscetível a erros.

Figura 19: Frame Marker criado para o projeto.

O processamento realizado pelo rastreador que foi desenvolvido para este mar-

cador possui quatro etapas. Na primeira a imagem é convertida para tons de cinza e

em seguida é segmentada usando um limiar de valor 120, determinado de forma ex-

perimental. No passo seguinte, é utilizado o detector de borda de Canny[Canny, 1986]

para determinar todas as arestas. Em seguida, são selecionados todos os contornos que

possuem quatro vértices e uma área entre dois limiares que contém entre eles o tamanho

mais provável de um marcador. Por fim, a leitura do código é realizada e aqueles que

possuírem um identificador válido são classificados como marcadores rastreados com

sucesso. Esta operação é feita em todos os frames do vídeo capturado pela webcam. AFi-

gura 20 mostra uma sequência de imagens com o resultado de cada uma dessas etapas.

Figura 20: Sequência de imagens com resultados das etapas do rastreamento. Na imagem

da esquerda a segmentação da imagem extraída pela webcam, no centro o resultado da

segmentação utilizando Canny e à direita a identifi cação de três marcadores diferentes.

122



Solucionado o problema do rastreamento, o passo seguinte é o de desenvolver um

sistema que projete as informações desejadas apenas na área interna ao marcador. Esta

etapa está em desenvolvimento a partir da adaptação de umatécnica proposta por Jo-

hnny Lee [Lee et al.], a qual calculauma transformaçãoque modifica o dado a ser exibido

de acordo com as dimensões e orientação do bloco rastreado.

Porém, apenas aplicar uma transformação que leve os dados para a orientação e

posição dos blocos não é suficiente para uma projeção correta sobre os mesmos, pois

a câmera e oprojetor possuem sistemas de coordenadas diferentes. Assim, é necessário

alinhar o sistema câmera-projetor de modo a descobrir a correspondência entreo sis-

tema de coordenadas do projetor e o da câmera. Por se tratar de uma etapa futura do

desenvolvimento, os autores ainda não chegaram a uma solução definitiva para o ali-

nhamento, possuindo apenas uma noção preliminar de como ela será realizada. Como

a câmera e o projetor permanecerão imóveis, os autores pensam em utilizar uma etapa

de calibração no instante da inicialização. Assim, as quatro extremidades da área de

projeção seriam indicadas, dando assim a correspondência com os vértices da câmera.

Possuindo quatro pares é possível aplicar uma homografia entre todos os pontos de

ambos os dispositivos.

Ao término do processo, todo o arcabouço tecnológico está pronto, e o sistema

computacional utilizando blocos como interface tangível e RA Projetiva para exibir a

informação foi finalizado. Em seguida, a etapa de desenvolvimento do jogo pode ser

iniciada. Por se tratar de um desenvolvimento de software utilizando a plataforma apre-

sentada, não pertence ao escopo deste tutorial descrever detalhes desta etapa. A Figura

21 e a Figura 22 ilustram dois exemplos de aplicações que podem ser montadas a partir

da ferramenta descrita neste tutorial.

Figura 21: Exemplo de aplicação onde as crianças precisam formar a palavra correspondente à

imagem projetada em um dos marcadores. A ação deve ser realizada de forma colaborativa.

123



6. Considerações Finais

Este tutorial apresentou os principais conceitos envolvendo a utilização de interfaces

tangíveis para aplicações de RA, focando na integração destas duas áreas para aprimorar

a experiência de alunos e educadores, possibilitando um aprendizado mais interativo.

Para isto, foi mostrado como os jogos educacionais representam um importante

instrumento a ser utilizado por educadores das mais diversas áreas. Os autores também

expuseram como as interfaces tangíveis são capazes de possibilitar uma interação na-

tural com sistemas computacionais a partir da utilização de objetos reais, que podem

ser associados pelo usuário com objetos do cotidiano. Também foram vistas várias ca-

racterísticas e bibliotecas de RA, fornecendo ao leitor uma boa noção para que ele possa

escolher a forma mais adequada de se usar RA em diversos tipos de aplicações, incluin-

do aquelas que utilizem as interfaces mencionadas acima, melhorando assim o nível de

experiência do usuário.

Figura 22: Nesta outra aplicação, a criança deve associar o marcador com a imagem à

palavra correspondente, a partir da união dos blocos relacionados.

Também foi conduzida uma sequência de atividades para a construção de uma apli-

cação que faça uso das duas tecnologias mostradas para ser utilizada em sala de aula como

um jogo baseado em blocos para o auxílio da alfabetização infantil. É importante ressaltar

a importância de cada uma dessas atividades, desde a fase de concepção e estudo do usu-

ário, pois é nela onde é possível descobrir os reais desejos de quem vai utilizar a aplicação,

até a do desenvolvimento propriamente dito, onde o jogo toma a sua forma final.

124



Referências

Africano, D., S. Berg, K. Lindbergh, P. Lundholm, F. Nilbrink e A. Persson. Designing

tangible interfaces for children’s collaboration. CHI ‘04 extended abstracts on Human

factors in computing systems. Vienna, Austria: ACM 2004.

Aim. Bar Code Technology: Matrix 2D Symbologies 2010.

Andar. andAR - Android Argumented Reality Lib 2010.

Antunes, C. Educação infantil: prioridade imprescindível: Vozes. 2007

______. Jogos para a estimulação das múltiplas inteligências: Vozes. 2008

Berard, F. The Magic Table: Computer Vision Based Augmentation of a Whiteboard for

Creative Meetings 2003.

Bimber, O., G. Wetzstein, A. Emmerling e C. Nitschke. Enabling View-Dependent

Stereoscopic Projection in Real Environments. ISMAR ‘05: Proceedings of the 4th IEEE/

ACM International Symposium on Mixed and Augmented Reality: IEEE Computer

Society. 2005, 2005. Paginas p.

Blackwell, A. F., G. Fitzmaurice, L. E. Holmquist, H. Ishii e B. Ullmer. Tangible user

interfaces in context and theory. CHI ‘07 extended abstracts on Human factors in

computing systems. San Jose, CA, USA: ACM: 2817-2820 p. 2007.

Broto, F. O. Jogos cooperativos: o jogo e o esporte como um exercício de convivência.

1999

Canny, J. A computational approach to edge detection. IEEE Trans. Pattern Anal. Mach.

Intell., v.8, n.6, p.679-698. 1986.

Comport, A. I., Marchand, E.,e Chaumette, F. Real-Time Markerless Tracking for

Augmented Reality: The Virtual Visual Servoing Framework. IEEE Transactions on

Visualization and Computer Graphics, v.12, p.625-628. 2006.

Dias, J., N. Barata, P. Santos, A. Correia, P. Nande e R. Bastos. In your hand computing:

tangible interfaces for mixed reality: IEEE, 2004. Paginas p.

Falcão, T. e A. Gomes. Design de interfaces tangíveis educacionais: uma metodologia

baseada em contexto: ACM, 2006. Paginas p.

Falcão, T. P. D. R. Design de interfaces tangíveis para aprendizagem de conceitos

matemáticos no Ensino Fundamental. Centro de Informática, Universidade Federal de

Pernambuco, Recife, 2007. 225 p.

125



Ferreira, A. B. de H. Novo Dicionário da Língua Portuguesa. 5. ed. Rio de Janeiro:

Editora Positivo, 2010.

Fiala, M. ARTag, a Fiducial Marker System Using Digital Techniques. CVPR ‘05:

Proceedings of the 2005 IEEE Computer Society Conference on Computer Vision

and Pattern Recognition (CVPR’05) - Volume 2: IEEE Computer Society. 2005, 2005.

Paginas p.

Fitzmaurice, G., H. Ishii e W. Buxton. Bricks: laying the foundations for graspable user

interfaces: ACM Press/Addison-Wesley Publishing Co., 1995. Paginas p.

Fitzmaurice, G. W., H. Ishii e W. A. S. Buxton. Bricks: laying the foundations for

graspable user interfaces. Proceedings of the SIGCHI conference on Human factors

in computing systems. Denver, Colorado, United States: ACM Press/Addison-Wesley

Publishing Co. 1995.

Flartoolkit. FLARToolKit 2010.

Froebelgifts. Froebel Gifts Child Development Toys 2010.

Guo, C. e E. Sharlin. Exploring the use of tangible user interfaces for human-robot

interaction: a comparative study: ACM, 2008. Paginas p.

Harald, W. Adaptive Line Tracking with Multiple Hypotheses for Augmented Reality,

2005. Paginas p.

Holzer, S., S. Hinterstoisser, S. Ilic e N. Navab. Distance Transform Templates for Object

Detection and Pose Estimation. 2009.

Ibm. Color/Graphics Adapter. 1981

Imagination. Flare Tracker 2010.

Ishii, B. U. A. H. Emerging Frameworks for Tangible User Interfaces. In: J. M. Carroll

(Ed.): Addison-Wesley, 2001. Emerging Frameworks for Tangible User Interfaces, p.579-

601. (Human-Computer Interaction in the New Millenium)

Ishii, H. The tangible user interface and its evolution. Commun. ACM, v.51, n.6, p.32-

36. 2008.

Ishii, H. e B. Ullmer. Tangible bits: towards seamless interfaces between people, bits and

atoms: ACM, 1997. Paginas p.

Ivista, M. invista soluciones. 2011

Jurie, F. e M. Dhome. A simple and efficient template matching algorithm. 2001, 2001.

Paginas p.

126



Kato, H. e M. Billinghurst. Marker Tracking and HMD Calibration for a Video-Based

Augmented Reality Conferencing System. IWAR ‘99: Proceedings of the 2nd IEEE and

ACM International Workshop on Augmented Reality: IEEE Computer Society. 1999,

1999. Paginas p.

Klein, G. e D. Murray. Parallel Tracking and Mapping for Small AR Workspaces. Proc.

Sixth IEEE and ACM International Symposium on Mixed and Augmented Reality

(ISMAR’07). 2007/november, 2007. Paginas p.

Lee, J. C., P. H. Dietz, D. Maynes-Aminzade, R. Raskar e S. E. Hudson. Automatic

projector calibration with embedded light sensors. UIST ‘04: Proceedings of the 17th

annual ACM symposium on User interface software and technology: ACM. 2004.

Paginas p.

Leong, Z. A. e M. S. Horn. The BEAM: a digitally enhanced balance beam for mathematics

education. Proceedings of the 9th International Conference on Interaction Design and

Children. Barcelona, Spain: ACM 2010.

Newcombe, R. A. e J. Andrew. Live Dense Reconstruction with a Single Moving Camera

Davison, CVPR 2010. CVPR. 2010.

Nishino, H. A split-marker tracking method based on topological region adjacency

& geometrical information for interactive card games. SIGGRAPH ASIA ‘09: ACM

SIGGRAPH ASIA 2009 Posters: ACM. 2009, 2009. Paginas p.

Nyala. FrontPage.en - NyARToolkit.

Piaget, J. A formação do símbolo na criança: imitação, jogo e sonho, imagem e

representação: J. Zahar. 1971

Piper, B., C. Ratti e H. Ishii. Illuminating clay: a 3-D tangible interface for landscape

analysis: ACM, 2002. Paginas p.

Raskar, R., G. Welch e H. Fuchs. Spatially Augmented Reality. Methods, n.919, p.1-7.

1998.

Ratti, C., Y. Wang, H. Ishii, B. Piper e D. Frenchman. Tangible User Interfaces (TUIs): a

novel paradigm for GIS. Transactions in GIS, v.8, n.4, p.407-421. 2004.

Resnick, O. Z. A. S. A. A. M. Extending tangible interfaces for education: digital

montessori-inspired manipulatives. Proceedings of the SIGCHI conference on Human

factors in computing systems. Portland, Oregon, USA: ACM: 859-868 p. 2005.

Rodulfo, R. O Brincar e o Significante: um estudo psicanalítico sobre a constituição

precoce. Porto Alegre: ArtMed. 1990

127



Schartz, G. M. Dinâmica lúdica: novos olhares: Manole. 2004

Schmalstieg, D. W. A. D. Making Augmented Reality Practical on Mobile Phones, Part

1. IEEE Computer Graphics and Applications, v.29, n.3, p.12-15. 2009.

Skrypnyk, I. e D. G. Lowe. Scene modelling, recognition and tracking with invariant

image features. 2004/nov., 2004. Paginas p.

Slartoolkit. SLARToolkit ‚ Silverlight Augmented Reality Toolkit.

Streitz, N. A., G. Jã¶Rg, T. Holmer, S. I. Konomi, C. Mã¼Ller-Tomfelde, W. Reischl,

P. Rexroth, P. Seitz e R. Steinmetz. i-LAND: an interactive landscape for creativity

and innovation. CHI ‘99: Proceedings of the SIGCHI conference on Human factors in

computing systems: ACM. 1999. Paginas p.

Stricker, D. e T. Kettenbach. Real-Time and Markerless Vision-Based Tracking for

Outdoor Augmented Reality Applications. ISAR ‘01: Proceedings of the IEEE and ACM

International Symposium on Augmented Reality (ISAR’01): IEEE Computer Society.

2001, 2001. Paginas p.

Teichrieb, V., J. P. S. Do Monte Lima, E. L. Apolinário, T. S. M. C. De Farias, M.

A. S. Bueno, J. Kelner e I. H. F. Santos. Experiences on the Implementation of a 3D

Reconstruction Pipeline. International Journal of Modeling and Simulation for the

Petroleum Industry, v.1. 2007.

Ullmer, B. A. I., H. Emerging frameworks for tangible user interfaces. IBM Systems

Journal, v.39, n.3.4, p.915-931. 2000.

Vacchetti, L., V. Lepetit e P. Fua. Stable real-time 3d tracking using online and offline

information. IEEE Transactions on Pattern Analysis and Machine Intelligence, v.26,

p.1385-1391. 2004.

Wagner, D. Augmented Reality on Truly Mobile Devices. 2006.

Wagner, D., T. Pintaric, F. Ledermann e D. Schmalstieg. Towards massively multi-user

augmented reality on handheld devices. In Third International Conference on Pervasive

Computing. 2005, 2005. Paginas p.

Wagner, D. e D. Schmalstieg. ARToolKit on the PocketPC platform. Proceedings of the

Second IEEE International Augmented Reality Toolkit Workshop, 2003. Paginas p.

Wiedemann, C., M. Ulrich e C. Steger. Recognition and Tracking of 3D Objects.

Proceedings of the 30th DAGM symposium on Pattern Recognition: Springer-Verlag.

2008, 2008. Paginas p.

Xalingo. Brincando de Engenheiro 200 peças 2010.

128



Zhou, Z., A. D. Cheok, Y. Li e H. Kato. Magic cubes for social and physical family

entertainment. CHI ‘05: CHI ‘05 extended abstracts on Human factors in computing

systems: ACM. 2005, 2005. Paginas p.

Zuckerman, O., S. Arida e M. Resnick. Extending tangible interfaces for education:

digital montessori-inspired manipulatives: ACM, 2005. Paginas p.

129

Desenvolvimento de Aplicações em Realidade Aumentada e Diminuída para iPhone e iPad

Luciano Silva e Ismar Frango Silveira

Laboratório de Processamento Gráfico e Mídias Digitais

Faculdade de Computação e Informática, Universidade Presbiteriana Mackenzie

[email protected] e [email protected]

Abstract

The increasing of general processing and graphical capabilities of mobile devices like

iPhone and iPad , as well as the availability of sensors and actuators, have shown new fe-

asible directions in both Augmented and Diminished Application development. Further-

more, languages like Objective-C and specific SDKs for iPhone and iPad provide a suitable

environment for agile prototyping of applications. This chapter presents the functional

organization of these two architectures, programming environments and tools, as well as

detailing of some Augmented and Diminished based applications for both platforms.

Resumo

Dispositivos móveis como iPhone e Ipad têm se revelado como plataformas viáveis

para desenvolvimento de aplicações tanto em Realidade Aumentada como Diminuída,

devido ao aumento de suas capacidades de processamento geral e gráfica, assim como

pela disponibilidade de sensores e atuadores. Além disto, linguagens como Objective-C e

SDKs específicos para iPhone e iPad disponibilizam um ambiente muito adequado para

prototipação ágil de aplicações. Este capítulo apresenta a organização funcional destas

duas arquiteturas, ambientes e ferramentas de programação, bem como detalhamento de

algumas aplicações em Realidade Aumentada e Diminuída para ambas as plataformas.

130

Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 129-156, jan./dez. 2011.SILVA, Luciano; SILVEIRA, Ismar Frango.

Desenvolvimento de Aplicaçnoes em Reralidade Aumentada e Diminuída para iPhone e iPad

1. Introdução

Com o aumento do poder de processamento dos dispositivos móveis, já é possível o

desenvolvimento de aplicações complexas de Realidade Aumentada (RA) e Diminuída

(RD) nestas plataformas. Em particular, as plataformas iPhone e iPad representam uma

alternativa bastante viável para prototipação e testes de aplicações de RA e RD, dadas

as facilidades de implementação e disponibilidade de diversos sensores e atuadores pre-

sentes nestes equipamentos.

O objetivo deste capítulo é introduzir a arquitetura funcional destas duas plata-

formas, os ambientes de desenvolvimento de aplicações e a exibição de algumas possi-

bilidades para desenvolvimento tanto em RA quanto RV. O texto está organizado da

seguinte forma: as duas seções iniciais descrevem os componentes funcionais tanto do

iPhone quando iPad, com foco nos componentes passíveis de uso em RA e RD; a seção

seguinte trata dos ambientes de programação, assim como da linguagem Objective-C

e dos SDKs para as duas plataformas; finalmente, as seções finais apresentam algumas

aplicações em RA e RD. Dadas as limitações de espaço do capítulo, alguns tópicos

não poderão ser discutidos em profundidade. Para complementar a discussão destes

tópicos, recomenda-se a consulta às referências ALAN (2011), BACKLIN (2010) e TEI-

XEIRA et al. (2009).

2. Organização Funcional de Hardware do iPhone

Segundo Morissey (2010), a estrutura computacional, tando do iPhone quando do

iPad, está concentrada em um único módulo (placa-mãe ou PCB-Phone Control Board).

Os componentes principais de organização funcional do iPhone, para a versão 3GS tra-

tada neste capítulo, estão mostrados na Figura 1:

131



Figura 1: Organização funcional básica de um iPhone 3GS.

Fonte: www.apple.com

O Módulo de Câmera é formado por uma câmera digital de 3 megapixels, fabricada

pela empresa OmniVision, com auto-foco, auto-balanceamento de branco e auto-macro,

capaz de capturar vídeo HD em 720p (30 fps), mas que foi limitado em 480p pela Apple.

A Placa-mãe (PCB) integra circuitos de diversos fabricantes. A Figura 2 ilustra a

parte frontal desta placa, com fabricantes dos circuitos, modelos e funções:

Figura 2: Arquitetura da parte frontal da PCB de um iPhone 3GS.


132



O módulo central de processamento desta arquitetura é um Samsung APL0298C05,

integrado na forma SoC e que contém um processador ARM Cortex-A8, underclocked

de 833 Mhz para 600Mhz, com uma GPU integrada PowerVR SGX, que suporta progra-

mação shaders de pixel, de vértices e geométricos, segundo as especificações OpenGL

2.0 e Direct X 10.1 Shader Model 4.1. Este SoC conta com uma memória eDRAM dedi-

cada de 256MB. Além do processador e da GPU, os circuitos abaixo também podem ser

acessados por aplicações em Realidade Aumentada e Diminuída:

Controlador de Touchscreen

Interface para o Display

Módulo de Áudio

Módulo de GPS

Módulos de Rede (Wi-Fi, Blutooth e 3G)

A parte posterior da PCB contém a memória principal do iPhone e o controlador de

Bluetooth, conforme mostrado na Figura 3:

Figura 3: Arquitetura da parte posterior da PCB de um iPhone 3GS.


As aplicações, normalmente, são armazenadas nesta memória (versões para 8GB,

16GB e 32GB). Esta memória não pode ser expandida. Porém, é possível o armazena-

mento de aplicações diretamente dentro do cartão SIM da operadora do celular.

133



3. Organização Funcional de Hardware do iPad

A organização funcional do iPad é similar em vários aspectos com a organização

do iPhone (Morissey, 2010). A Figura 4 mostra os principais componentes da arquitetu-

ra do iPad Versão 1:

Figura 4: Visão funcional dos componentes do iPad Versão 1.


No iPad, ainda se tem o módulo computacional organizado em uma placa chamada

Placa de Lógica Principal (MLB-Main Logic Board), onde se encontram um processador

A4, os módulos de memória e demais componentes. Um diferenciador importante pode

ser notado nas antenas de Bluetooth e Wi-Fi localizados na mesma placa que contém o

conector do iPad a cabos e docks, além das duas células de baterias, que confere maior

autonomia enérgetica do iPad em relação ao iPhone.

Somente a versão 2 do iPad conta com câmeras frontal e posterior. É possível, tam-

bém, encontrar ambas as versões (1 e 2) com suporte a 3G. A Figura 5 mostra os princi-

pais componentes da MLB do iPad Versão 1, com as partes frontal e posterior da placa:

134



Figura 5: Componentes da MLB do iPad Versão 1.

Fonte: www.applei.ph

O processador da MLB é um Apple A4, baseado na arquitetura ARM. No iPad

Versão 1, este processador funciona a 1GHz e é formado por um core ARM Cortex-A8 e

uma GPU PowerVR SGX 535, que também suporta pixel shaders, vertex shaders e geo-

metric shaders. Este mesmo processador também é utilizado no iPhone 4, iPod Touch e

Apple TV, mas as frequências de operação não são divulgadas. No iPad Versão 2, utiliza-

se um processador Apple A5, dual core, com frequência de operação de 1GHz.

4. Processo de Desenvolvimento de Aplicações para iPhone/iPad

Nesta seção, será apresentado o processo de desenvolvimento tradicional de desen-

volvimento na plataforma Apple, que se baseia em XCode, assim como tratar de alterna-

tivas para outras plataformas. Uma breve visão da linguagem Objective-C (Apple, 2010)

será também oferecida.

4.1. Ambientes de programação e compilação

O XCode (anteriormente denominado Project Builder) é um ambiente para desen-

volvimento de aplicações em iPhone/iPad mantido pela Apple, que é incluído no pacote

135



Developer Tools. Pode ser categorizado como uma suíte de ferramentas para o desenvol-

vimento de software para Mac OS X e iOS, como mostra a Figura 6 a seguir.

Figura 6: O ambiente Xcode.

Fonte: http://www.blogiversity.org/images/devtools_simulator.jpg e http://gdcmac.source-

forge.net/xcode-d-project.png

136



A principal aplicação da suíte é seu ambiente de desenvolvimento integrado (IDE),

igualmente chamado Xcode. Entre as funcionalidades da suíte Xcode encontra-se uma

tecnologia para distribuir a construção de código-fonte em vários computadores. Eclip-

se, NetBeans, Geany, Aptana, Code::Blocks, KDevelop e Anjuta são alternativas popu-

lares para o Xcode no Linux, utilizando-se do gcc. Para Windows, pode-se usar o com-

pilador Objective-C que acompanha o sistema MinGW (http://www.mingw.org). Em

ambos os casos, é possível executar o Xcode através de uma máquina virtual.

4.2. Linguagem Objective-C

A linguagem Objective-C foi criada por Brad Cox e Tom Love em sua empresa

Stepstone nos anos 1980. Quando Steve Jobs temporariamente deixou a Apple, o mesmo

fundou a companhia NeXT e licenciou a linguagem, lançando seu próprio compilador,

sobre o qual a interface NeXTstep seria criada – a mesma virou base para o projeto

GNU, que se baseou no padrão OpenStep. Ao adquirir a NeXT, a Apple incorporou a

linguagem Objective-C e usou OpenStep em seu sistema operacional, de maneira que

boa parte dos objetos da API Cocoa da Apple é baseada nos objetos da OpenStep.

Em moldes similares a C++, agrega os conceitos advindos do Paradigma Orientado

a Objetos à linguagem C. Entretanto, diferente de C++, o faz com uma sintaxe inspirada

claramente em Smalltalk. A Figura 7 a seguir mostra um exemplo de código escrito em

Objective-C – o material de referência para a linguagem encontra-se em (Apple, 2010):

137



Figura 7: Exemplo de código em Objective-C.

5. Aplicações para Realidade Aumentada

A maioria das aplicações para Realidade Aumentada para iPhone e iPad disponí-

veis na loja iTunes ainda estão vinculadas a jogos. A seguir, serão descritos alguns destes

jogos com base em ABRANTES (2010).

AR EASTER EGG HUNT

AR Easter Egg Hunt (APPLE INC.; 2010a) é um jogo gratuito em Realidade Au-

mentada desenvolvido para iPhone 3GS, com o intuito de relembrar o usuário de sua

infância e de como se divertia procurando ovos de Páscoa escondidos.

O jogo é baseado em um costume muito tradicional em diversos países do mundo,

que consiste em colher ovos escondidos na época da Páscoa. Com gráficos típicos do

tema, o jogo faz uso de diversas funcionalidades do iPhone 3GS. A Figura 8 mostra a

tela principal do jogo:

138



Figura 8: Tela principal do jogo AR Easter Egg Hunt.

Fonte: http://a1.phobos.apple.com/us/r1000/037/Purple/8d/a4/e5/

mzl.momhkhqn.320x480-75.jpg

No menu ‘Radar’ da tela principal, o jogador pode transformar o dispositivo em um

radar de ovos, permitindo a localização de ovos ao redor do mundo inteiro, por meio do

GPS. A Figura 9 mostra essa funcionalidade:

139



Figura 9: Radar do AR Easter Egg Hunt exibindo a localização dos ovos de Páscoa.

Fonte: http://a1.phobos.apple.com/us/r1000/056/Purple/21/dd/0d/

mzl.hoyuolgv.320x480-75.jpg

Para coletar os ovos de Páscoa, o jogador precisa mudar o modo de visualização

para a visualização em Realidade Aumentada que exibirá os ovos coloridos ao seu redor.

A Figura 10 mostra o jogador selecionando um ovo próximo à Torre Eiffel, em Paris:

Figura 10: Ovo encontrado próximo à Torre Eiff el no jogo AR Easter Egg Hunt.

140



O objetivo do jogo é coletar a maior quantidade de ovos possível, variando de ovos

comuns para muito raros, de modo a maximizar a pontuação online e completar um

conjunto de objetivos, tais como coletar todos os ovos comuns. O usuário pode seguir

seu progresso navegando nas salas de prêmios, por meio do menu ‘Awards’ da tela prin-

cipal, e compartilhar suas realizações com seus amigos no facebook. A Figura 11 mostra

a pontuação global do usuário:

Figura 11: Pontuação global do usuário no jogo AR Easter Egg Hunt.

Fonte: http://a1.phobos.apple.com/us/r1000/010/Purple/84/1f/91/

mzl.vcmfrvyf.320x480-75.jpg

AR Easter Egg Hunt é um jogo em Realidade Aumentada impressionante, que cria

uma experiência semi-imersiva rica e muito divertida. Atualmente, o jogo é suportado

apenas em iPhone 3GS com a versão 3.1.3 do iPhoneOS.

ARCADE REALITY

Invasores de videogame do espaço sideral estão atacando o mundo real. Apenas o

jogador pode ver e atacá-los com o iPhone. No Arcade Reality (APPLE INC., 2010b), in-

141



vasores alienígenas voam ao redor do corpo do jogador em tempo real, atacando-o com

feixes de laser e mísseis por todos os lados.

A Figura 12 mostra uma sessão de jogo do Arcade Reality:

Figura 12: Sessão de jogo do Arcade Reality.

Fonte: http://a1.phobos.apple.com/us/r1000/008/Purple/09/17/13/

mzl.vmfedtoy.320x480-75.jpg

O jogo comporta múltiplos modos de jogo e níveis bônus, incluindo:

Infinite Shooter:• se atira em tudo que se move, muito simples e fácil. O jogo

termina quando dez alienígenas atravessam o “portal triangular”, portanto o

jogador deve matá-los antes que eles o façam.

Arcade Reality:• o jogador tem três minutos para o jogo inteiro. Em cada nível

regular perde-se algum tempo pelo jogo, mas se ganha alguns segundos de

bônus. Mantendo-se o saldo positivo, pode-se jogar por um bom tempo antes

que o prazo se esgote. A cada cinco níveis há um nível bônus em que se pode

ganhar power-ups ou tempo extra ao completar uma missão especial.

142



Asteroid Mode:• o jogador pilota uma pequena espaçonave lutando contra as-

teróides e alienígenas.

Há vários tipos de alienígenas com inúmeros ataques e movimentos. Os chefes são

mais fortes que os alienígenas e aparecem ao final de cada nível. A Figura 13 mostra a

tela principal do jogo:

Figura 13: Tela principal do jogo Arcade Reality.

Fonte: http://a1.phobos.apple.com/us/r1000/033/Purple/c8/48/62/

mzl.isyzodsb.320x480-75.jpg

O jogador pode ainda visitar e postar sua pontuação no Hall da Fama e ver como se

compara com os melhores jogadores ao redor do mundo. O jogo faz intenso uso da câ-

mera, acelerômetro e bússola para o registro das posições e por isso requer a utilização

de um iPhone 3GS.

CAPTURE THE FLAG

Capture the Flag (APPLE INC., 2010c) é um jogo multiplayer baseado na rede 3G.

Para jogá-lo é necessário que o Bluetooth esteja ligado, o adaptador Wifi desligado e que

143



haja uma boa recepção de sinal de GPS, que geralmente requer que o jogador esteja em

um ambiente exterior. Em um jogo de duas pessoas, o segundo jogador também precisa

ser um líder de time.

Naturalmente, as bases precisam estar posicionadas a uma distância razoável para

prevenir que as bandeiras sejam capturadas instantaneamente. A Figura 14 mostra o

menu principal do jogo:

Figura 14: Tela principal do jogo Capture the Flag.

Fonte: http://a1.phobos.apple.com/us/r1000/051/Purple/4b/00/07

/mzl.ioeyjfxb.320x480-75.jpg

Capture the Flag tem uma longa história entre jogadores jovens. Eles adoram estar

ao ar livre, são fisicamente ativos e mentalmente envolvidos. A Figura 15 mostra uma

sessão do jogo, com as localizações de ambas as bandeiras pelo GPS:

144



Figura 15: Sessão do jogo Capture the Flag mostrando as localizações das bandeiras.

Fonte: http://a1.phobos.apple.com/us/r1000/024/Purple/c8/ab/16/

mzl.xhvndgzw.320x480-75.jpg

Atualizado para uma jogabilidade moderna, a versão da Situware relata aos jo-

gadores e seus times as localizações de ativos, em tempo real, em uma visão aérea de

um mapa. Os jogadores são providos com ativos virtuais como armas, kits médicos

e bandeiras. Os jogos e times são estabelecidos ad hoc, as bandeiras são posicionadas

assim que as equipes vêem encaixes. Os jogadores são monitorados usando o GPS, ace-

lerômetro, bússola e suas interações com a tela de toque do iPhone. As informações

disponibilizadas são reforçadas com sons e vibrações geradas pelo jogo, aumentando o

senso do jogador em relação ao mundo. A Figura 16 mostra algumas das informações

disponibilizadas aos jogadores:

145



Figura 16: Informações disponibilizadas aos jogadores de Capture the Flag.

Fonte: http://a1.phobos.apple.com/us/r1000/042/Purple/db/87/c7

/mzl.cuocfqeq.320x480-75.jpg

O jogo é jogado ao ar livre, direcionado para jogadores casuais procurando por

uma experiência física e cognitiva. O objetivo é localizar a bandeira e capturar a bandei-

ra do time oposto ao passo que não se pode perder a da própria equipe.

FIREFIGHTER 360

Firefighter 360 (APPLE INC., 2010e) é um jogo de bombeiros especificamente de-

senvolvido para iPhone auxiliado por uma engine de Realidade Aumentada. Nesse jogo

o jogador atua como um bombeiro, que, ao invés de matar os inimigos, tem de dar fim

a chamas que se espalham rapidamente no ambiente real. Conforme o jogador gira com

o iPhone, ele tem uma visão do que há ao seu redor.

A Figura 17 mostra os controles e informações do jogo:

146



Figura 17: Controles e informações disponibilizadas aos jogadores de Firefi ghter 360.

Fonte: http://a1.phobos.apple.com/us/r1000/048/Purple/d2/64/50/

mzl.bzrufb zi.320x480-75.jpg

O jogador pode andar para frente e para trás por meio de um botão e atirar água

pressionando a tela. O fogo propriamente dito não é apenas um inimigo estático com o

qual o jogador tem de lidar. As chamas vão se propagando e se o jogador não as apagar

completamente, o fogo é capaz de causar-lhe dano. A Figura 18 mostra uma cena em que

a situação saiu de controle e o jogador está sofrendo dano por conta disso:

Figura 18: Chamas causando danos no jogador de Firefi ghter 360.

Fonte: http://a1.phobos.apple.com/us/r1000/049/Purple/8d/66/56/

mzl.bophjqpk.320x480-75.jpg

147



Para reencher a coluna de água automaticamente é preciso estar perto do caminhão

de bombeiros. O jogador pode salvar as pessoas do fogo tocando nelas quando estiverem

próximas. Cada pessoa salva vale 25 pontos e cada fogo apagado vale 10. A Figura 19

mostra o jogador salvando uma pessoa:

Figura 19: Jogador salvando uma pessoa em Firefi ghter 360.

Fonte: http://a1.phobos.apple.com/us/r1000/058/Purple/b3/73/3b/

mzl.hmhoxlew.320x480-75.jpg

Para marcar mais pontos o jogador deve tomar cuidado com o fogo, girando 360

graus para verificar toda a área de jogo e salvar a maior quantidade possível de pessoas.

FIREPOWER

Firepower (APPLE INC., 2010f) é um simulador de metralhadora em que o joga-

dor pode mirar em qualquer objeto visto na câmera e atirar. É possível armazenar as

fotos dos objetos tomando tiros. A Figura 20 mostra a tela com os principais botões

utilizados no jogo:

148



Figura 20: Tela com principais botões do jogo Firepower.

Fonte: http://a1.phobos.apple.com/us/r1000/017/Purple/49/d5/b7/mzl.

cocofj bt.320x480-75.jpg

Na tela de configurações é possível customizar os efeitos dos tiros, habilitar fuma-

ça, gravidade realística e se o iPhone vibrará durante os tiros ou não, conforme mostra

a Figura 21:

Figura 21: Tela de confi gurações do jogo Firepower.

Fonte: http://a1.phobos.apple.com/us/r1000/033/Purple/7d/e9/d4/

mzl.xszrxfgy.320x480-75.jpg

O jogo não tem um objetivo claro, seu propósito é meramente a diversão de se atirar

em qualquer coisa. Há ainda uma opção de customizar os tiros por meio de uma aplica-

ção chamada Particle Toy e importá-los no Firepower.

149



iPEW

iPew (APPLE INC., 2010g) é outro jogo com o simples propósito de se atirar no que

é projetado na câmera do iPhone, como mostra a Figura 22:

Figura 22: Jogador atirando em uma pessoa no jogo iPew.

Fonte: http://a1.phobos.apple.com/us/r1000/059/Purple/9e/d4/0b/

mzl.qqwrztrh.320x480-75.jpg

Há quatro opções de armas para serem usadas: raio laser, metralhadora, mísseis e

atirador de chamas.

SKY SEIGE

Sky Seige (APPLE INC., 2010i) é um jogo, cujo campo de visão do jogador é de

360 graus em todas as direções, o que o torna mais real e imersivo. O jogador deve se

defender dos helicópteros espalhados por todos os lados atirando neles. Para isso, ele

deve girar seu iPhone ao seu redor para localizá-los e tocar na tela para atirar. A Figura

23 mostra a interface do jogo:

150



Figura 23: Interface do jogo Sky Seige.

Fonte: http://a1.phobos.apple.com/us/r1000/012/Purple/c6/6f/51/

mzl.zwwohqcm.320x480-75.jpg

O jogador tem várias opções de armas e para trocá-las ele deve usar o botão locali-

zado no canto esquerdo inferior da tela. Para recarregar suas armas o jogador deve olhar

para o chão, onde estão localizadas as caixas com munição. É possível aproximar a mira

da arma apertando o botão próximo ao que troca as armas. O jogo dispõe de dois mo-

dos, um de Realidade Virtual e outro de Realidade Aumentada. No modo de Realidade

Virtual, o jogador é colocado em uma torre, no meio de um campo de batalha e tem de

derrubar os helicópteros inimigos que o rodeiam, conforme mostra a Figura 24:

Figura 24: Modo de Realidade Virtual do jogo Sky Seige.

Fonte: http://a1.phobos.apple.com/us/r1000/055/Purple/99/ee/87/

mzl.pwowslwb.320x480-75.jpg

151



No modo de Realidade Aumentada, diferentemente do modo em Realidade Vir-

tual, os helicópteros inimigos são inseridos no mesmo ambiente em que o jogador está

localizado, conforme mostra a Figura 25:

Figura 25: Modo de Realidade Aumentada do jogo Sky Seige.

Fonte: http://a1.phobos.apple.com/us/r1000/033/Purple/d0/4b/a0/

mzl.qgmmfzhc.320x480-75.jpg

O jogo dispõe de 32 fases, com diferentes níveis de dificuldade. Para jogar Sky Sei-

ge o jogador necessita de um iPhone 3GS, pois, além de utilizar acelerômetro, o jogo

também utiliza a bússola digital. Para melhores resultados é importante que não haja

interferência magnética.

TURN YOUR FRIENDS INTO A CYBORG

Segundo Kirner e Kirner (2008), para que uma aplicação seja considerada de Reali-

dade Aumentada, é necessário que os objetos reais e virtuais sejam misturados em tem-

po real. Apesar de Turn Your Friend into a Cyborg (APPLE INC., 2010j) não se encaixar

nesse quesito e, portanto, não ser classificado como uma aplicação de Realidade Au-

mentada dentro do escopo deste trabalho, ele foi incluído nessa seção por apresentar um

aspecto interessante ao desenvolvimento de aplicações de Realidade Aumentada. Ele é

capaz de detectar rostos humanos usando técnicas de visão computacional e alinhá-los

com a face de um robô virtual, conforme mostra a Figura 26:

152



Figura 26: Exemplo da detecção de rostos da aplicação Turn Your Friends into a Cyborg.

Fonte: http://a1.phobos.apple.com/us/r1000/022/Purple/52/18/53/

mzl.biwyaxkb.320x480-75.jpg

A detecção de padrões por meio da visão computacional é um requisito importante

para se produzir bons jogos em Realidade Aumentada, que normalmente utilizam mar-

cadores fiduciais para orientar o alinhamento dos objetos reais e virtuais.

6. Desenvolvimento de Aplicações para Realidade Diminuída

Ao contrário da Realidade Aumentada, a Realidade Diminuída tem como objetivo remover detalhes de uma cena, conforme mostrado na Figura 27:

153



Figura 27: Remoção de detalhes em imagens via Realidade Diminuída.

Fonte: http://3.bp.blogspot.com/_Hj8jCz2g8iI/TO7RT-NvLNI/AAAAAAAAAhE/

C1Vqh42nZ7Y/s1600/diminished-reality.jpg

O procedimento para remoção de detalhes nas imagens pode utilizar os mesmos

frameworks mostrados anteriormente. Porém, a carga de processamento devido à apli-

cação de filtros para remoção de detalhes é muito mais intensa quando comparada à

implementação de algoritmos para Realidade Aumentada.

Outro obstáculo bastante importante refere-se à limitação no uso de múltiplas câ-

meras para Realidade Diminuída. Por exemplo, técnicas como ENOMOTO e SAITO

(2007) não podem ser facilmente implementadas, mesmo no contexto de compartilha-

mento de câmeras entre iPhones e iPads (somente versão 2).

Assim, a área de Realidade Diminuída nestes dois dispositivos ainda apresenta di-

versos desafios para desenvolvimento de novas bibliotecas e frameworks sob um am-

biente com número reduzido de câmeras.

154



7. Conclusões

Realidade Aumentada e Diminuída em dispositivos móveis oferece várias opor-tunidades de pesquisa, tanto teóricas como aplicadas. As plataformas iPhone e iPad representam alternativas viáveis para prototipação de aplicações nessas áreas, cujas ca-racterísticas principais envolvem alto desempenho de CPU e GPU, ambientes de desen-volvimento gratuitos e boa documentação.

Este capítulo apresentou os fundamentos da arquitetura dessas duas plataformas, com ênfase em aspectos de componentes para Realidade Aumentada e Dimunída. Além disto, foram apresentados os princípios da linguagem Objective-C, base para implemen-tação de aplicações no ambiente Apple. Finalmente, foram apresentados diversos exem-plos de aplicações tanto para iPhone quanto iPad.

Dado o caráter introdutório do texto, diversos detalhes sobre bibliotecas e fra-meworks não puderam ser discutidos. Neste contexto, estimula-se o leitor a consultar as referências indicadas durante e no final deste texto para suprir estas lacunas. Além disto, reforça-se o fato que o desenvolvimento de novas técnicas, bibliotecas e frameworks para desenvolvimento de aplicações de Realidade Aumentada e Diminuída é de grande interesse tanto acadêmico quanto comercial.

Referências

ABRANTES, C.A.B.P. Jogos em Realidade Aumentada para iPhone. Trabalho de

Conclusão de Curso. Orientador: Luciano Silva. Bacharelado em Ciência da Computação,

Universidade Presbiteriana Mackenzie, São Paulo, 2010.

ALLAN, A. iOS 4 Sensor Programming: Augmented reality and Location Enabled

iPhone and iPad Apps. New York: O’Reilly, 2011.

ALTENBERG, B., CLARKE, A. e MOUGIN, P. Become an Xcoder – Start

programming the Mac using Objective-C. Disponível em: http://www.cocoalab.

com/BecomeAnXcoder.pdf Acesso em 28 de Março de 2011.

BACKLIN, G. Professional iPhone and iPad Application Development. New York:

Wrox, 2010.

APPLE INC (a). AR Easter Egg Hunt. Apple. Disponivel em: <http://itunes.apple.com/

us/app/ar-easter-egg-hunt-augmented/id363450700?mt=8>. Acesso em: 20 Maio 2010.

___________(b). Arcade Reality. Apple. Disponivel em: <http://itunes.apple.com/us/

app/arcade-reality-iphone-3gs/id328981829?mt=8#>. Acesso em: 20 Maio 2010.

155



___________(c). Capture the Flag. Apple. Disponivel em: <http://itunes.apple.com/us/

app/capture-flag-augmented-reality/id362289823?mt=8>. Acesso em: 20 Maio 2010.

___________(d). Developer Tools Overview. Apple Developer. Disponivel em: <http://

developer.apple.com/technologies/tools/>. Acesso em: 20 Outubro 2010.

___________(e). Firefighter 360. Apple. Disponivel em: <http://itunes.apple.com/us/

app/firefighter-360/id338041092?mt=8>. Acesso em: 20 Maio 2010.

_____________(f). Firepower. Apple. Disponivel em: <http://itunes.apple.com/us/

app/firepower/id317465162?mt=8>. Acesso em: 20 Maio 2010.

____________(g). iPew. Apple. Disponivel em: <http://itunes.apple.com/us/app/ipew/

id333769147?mt=8>. Acesso em: 20 Maio 2010.

____________(h). Model-View-Controller. Cocoa Core Competencies. Disponivel

em: <http://developer.apple.com/library/ios/#documentation/General/Conceptual/

DevPedia-CocoaCore/MVC.html#//apple_ref/doc/uid/TP40008195-CH32-SW1>.

Acesso em: 4 Novembro 2010.

____________(i). Sky Siege. Apple. Disponivel em: <http://itunes.apple.com/us/app/

sky-siege/id349892759?mt=8>. Acesso em: 20 Maio 2010.

__________ (j). Turn Your Friend into a Cyborg. Apple. Disponivel em: <http://itunes.

apple.com/us/app/turn-your-friend-into-a-cyborg/id357418260?mt=8>. Acesso em: 20

Maio 2010.

___________ (k). The Objective-C Proramming Language. Apple. Disponível

em: <http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/

ObjectiveC/ObjC.pdf>. 8 Dezembro 2010, acesso em: 2 Abril 2011.

ENOMOTO, A., SAITO, H. Diminished Reality using Multiple Handheld Cameras. In:

Proceedings of ACCV’07 Workshop on Multi-dimensional and Multi-view Image

Processing, pp.130-135, 2007.

KIRNER, C.; KIRNER, T. G. Virtual Reality and Augmented Reality Applied to

Simulation Visualization. In: EL SHEIKH, A.; AL AJEELI, A. T.; ABU TAIEH, E.

Simulation and Modeling: Current Technologies and Applications. Hershey: Idea

Group Reference, 2008. p. 391-419.

TEIXEIRA, J.M., TEICHRIEB, V., KELNER, J. Embedded Augmented Reality: Finding an adequate escape pod to real time augmented reality applications. New York: LAP Lambert Academic Publishing, 2009.

Documents

Tendências e Técnicas em Realidade Virtual e …comissoes.sbc.org.br/ce-rv/livro2011.pdf · XIII Simpósio de Realidade Virtual ... bem como seus ambientes e ferramentas de programa-8