Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Livro2011

80 views

Published on

monografia realidade aumentada

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Livro2011

  1. 1. Tendências e Técnicas em Realidade Virtual e Aumentada
  2. 2. Av. Bento Gonçalves, 9500 - Setor 4 - Prédio 43.412 - Sala 219 - Bairro Agronomia CEP 91.509-900 - Porto Alegre - RS - Tel. (51) 3308-6835 - Fax (51) 3308-7142 Home: www.sbc.org.br - E-mail: sbc@sbc.org.br José Carlos Maldonado (ICMC-USP) Presidente Marcelo Walter (UFRGS) Vice-Presidente Luciano Paschoal Gaspary (UFRGS) Diretor Administrativo Paulo Cesar Masiero (ICMC-USP) Diretor de Finanças Lisandro Zambenedetti Granville (UFRGS) Diretor de Eventos e Comissões Especiais Mirella Moura Moro (UFMG) Diretora de Educação Karin Koogan Breitman (PUC-Rio) Diretora de Publicações Ana Carolina Brandão Salgado (UFPE) Diretora de Planejamento e Programas Especiais Thais Vasconcelos Batista (UFRN) Diretora de Secretarias Regionais Altigran Soares da Silva (UFAM) Diretor de Divulgação e Marketing Ricardo de Oliveira Anido (UNICAMP) Diretor de Relações Profissionais Carlos Eduardo Ferreira (USP) Diretor de Eventos Especiais Marcelo Walter (UFRGS) Diretor de Cooperação com Sociedades Científicas
  3. 3. Publicação anual | Porto Alegre | v. 1, n. 1 | p. 1-158 | 2011 Tendências e Técnicas em Realidade Virtual e Aumentada
  4. 4. 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. 5. 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
  6. 6. 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-
  7. 7. 8 ção, detalhando algumas aplicações em Realidade Aumentada e Diminuída para ambas as plataformas. Esta obra foi o resultado do trabalho de 16 autores da comunidade brasileira de RVA e constitui uma referência para atualizações tanto por profissionais quanto por pesquisadores que queiram conhecer estas tendências e técnicas de RVA, além de ser útil como porta de entrada para estudantes, iniciantes e profissionais de outras áreas do conhecimento interessados em ingressar no fascinante mundo da tecnologia de realida- de virtual e aumentada. Agradecemos a todos que colaboraram com a realização dos minicursos e com a edição deste livro. Desejamos a todos uma excelente leitura! Os organizadores Robson Augusto Siscoutto - robson.siscoutto@unoeste.br José Remo Ferreira Brega - remo@fc.unesp.br
  8. 8. 9 Developing Android Applications for AugmentedReality Philip Michel Duarte, Edson Alyppyo Gomes Coutinho and Selan Rodrigues dos Santos Departamento de Informática e Matemática Aplicada (DIMAp) Universidade Federal do Rio Grande do Norte (UFRN) Natal – RN – Brazil {philipmichelduarte,alyppyo}@gmail.com and selan@dimap.ufrn.br Abstract In this chapter we present an overview of the development process of an Augmented Real¬ity (AR) application with AndAR, a Java based software library that implements ARToolkit on the Android platform. This example application recognizes markers and su- perimpose images over live video of the environment. To make this possible, 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.
  9. 9. 10 Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011. DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos. Developing Android Applications for AugmentedReality Figure 1. The Android’s Architeture. Source: developer.android.com. Sometimes people may get confused when they try to 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.
  10. 10. 11 Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011. DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos. Developing Android Applications for AugmentedReality 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.
  11. 11. 12 Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011. DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos. Developing Android Applications for AugmentedReality 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.
  12. 12. 13 Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011. DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos. Developing Android Applications for AugmentedReality 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).
  13. 13. 14 Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011. DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos. Developing Android Applications for AugmentedReality Figure 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.
  14. 14. 15 Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011. DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos. Developing Android Applications for AugmentedReality 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-
  15. 15. 16 Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011. DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos. Developing Android Applications for AugmentedReality 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
  16. 16. 17 Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011. DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos. Developing Android Applications for AugmentedReality 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.
  17. 17. 18 Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011. DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos. Developing Android Applications for AugmentedReality 3.4.1. Step I -Planning Our App Android applications are made up of activities. Each activity manages and exibits a set of views and controls. As a rough idea, we may think of activities as realizations of use-cases from the Unified Modelling Language (UML). For the ObjViewer, we will need only one activity, which will be responsible for rendering the current frame as captured by the camera and overlaying it with the AR objects. LetuscreateanewandroidprojectfromtheEclipseinterfaceandnametheactiv¬ity something you like. We will use through this tutorial the name ObjActivity. You will end up with something like the source code in Figure 9. public class ObjActivity extends Activity { / Called when the activity is first created . / @Override public void onCreate ( Bundle savedInstanceState ){ super . onCreate ( savedInstanceState ); setContentView ( R . layout . main ); } } Figure 9. Class ObjActivity. Now we must prepare the project for AndAR. There are three ways of adding An¬dAR to our project. The first and most cumbersome is adding each of the source files to our project. The second is compiling the source yourself and generate a AndAR. jar file, which is a better approach. What we are going to do is use an already provided An-dAR.jar file, which can be found in the lib directory of the AndARModelViewer example (included in AndAR). Open up your favorite SVN client and download the source code of the An- dAR project. Once the download is finished, we must add the AndAR.jar file to the CLASS¬PATH of our project. Right-click on the project, select Properties. Go for Java Build Path on the left menu, and pick the Libraries tab. Here, click on “Add External Jar” and browse through the directories to the andar-read-only/AndARModelViewer/ lib/ AndAR.jar file. After this step, we are all set. Now refer to code presented. Our app will need an Augmented Reality view, which is what the AndAR provides. Thus, our activity needs to extend AndARActivity, and not Activity. We must also call startPreview at the end of the onCreate method, in order to start fetching frames from the camera. Once you change the superclass and correct the imports, Eclipse will complain the method uncaughtException isn’t imple¬mented. It is an abstract method from AndARActivity, called whenever AndAR detects a severe exception on one of it’s threads. We must finish the application when we receive such call (see Figure 10).
  18. 18. 19 Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011. DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos. Developing Android Applications for AugmentedReality 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.
  19. 19. 20 Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011. DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos. Developing Android Applications for AugmentedReality 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
  20. 20. 21 Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011. DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos. Developing Android Applications for AugmentedReality 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.
  21. 21. 22 Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011. DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos. Developing Android Applications for AugmentedReality 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.
  22. 22. 23 Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011. DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos. Developing Android Applications for AugmentedReality Line 13: this specifies whether we want smooth shading or not. The off option means no smooth shading. Line 15: this single line is the most important one, since it defines a face. On .obj files, meshes are made up of triangles or quads. a face line can represent either a tri- angle or a quad. The face line starts with an f identifier, then proceeds with three or four vertex configurations. Each configuration is composed of three one-based indices (as opposed to zero-based indices from Java and C/C++ arrays). The first refers to a vertex position; The second, to a texture coordinate; and the third, to a vertex normal. It is easy to see that the previous lines act as a “database” for further reference, and the face lines are the ones to actually define the mesh structure. Vertex configurations may also appear multiple times. We will need some sort of mechanism to detect when they reappear and not include them twice. It’s also worth noticing that vertex normals and texture coordinates may be absent on the .obj file. Thus, the following lines (see Figure 15) are also valid face descriptions, and respectively represent texture coordinates absence and vertex normals absence. f 1//1 2//1 3//1 f 1/3 2/1 3/3 Figure 15. Valid faces descriptions. That was brief for a mesh file description! Now, on to the parseOBJ method. We will make a few restrictions for the sake of simplicity. We will require the models to be composed entirely of triangle faces. Also, we will require that texture coordinates and vertex normals are always present. For the this method, we will need to declare a few more attributes (see Figure 16). private HashMap<String , Integer> vertMap = new HashMap<String , Integer >() ; private ArrayList<Float> vertices = new ArrayList<Float >() ; private ArrayList<Float> normals = new ArrayList<Float >() ; private ArrayList<Float> tcoords = new ArrayList<Float >() ; private ArrayList<Integer> indices = new ArrayList<Integer >() ; Figure 16. The new attributes declared. Understanding the purpose of these attributes is crucial. They are not intended to store the vertex positions, texture coordinates and normals as read from the file. They are used to represent faces of the mesh. Thus, for a given face index i, vertices[i] gives its position, normals[i] gives its normal and tcoords[i] gives its texture coordinates. The parseOBJ method opens up an bufferedReader from the InputStream and al¬locates three databases to store the vertices, normals and texcoords as read from the
  23. 23. 24 Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011. DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos. Developing Android Applications for AugmentedReality 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).
  24. 24. 25 Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011. DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos. Developing Android Applications for AugmentedReality @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
  25. 25. 26 Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011. DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos. Developing Android Applications for AugmentedReality sim¬plest part. This will be done in the draw method of the MeshObject class. For our draw¬ing method, the first step will actually be calling the draw of our super class (AR- Object) this will apply the ModelView matrix appropriate for the marker assigned to our object. After calling the draw method of the super class, it is time to do our magic. We are going to draw our mesh with vertex arrays, so we must first enable those vertex arrays! This can be done by calling glEnableClientState with the proper parameters. Since our models always have normals and texture coordinates, we turn on GL_NORMAL_AR- RAY and GL_TEXTURE_COORD_ARRAY besides the GL_VERTEX_ARRAY, which we would already turn on anyway. Then we must provite our buffers, so OpenGL actually has data to draw. This can be done with calls to glVertexPointer, glTexCoordPointer and glNormalPointer. That is why we needed those FloatBuffers back then! Finally, it is time to draw the mesh. Since we have done all the hard work already, drawing is as simple as calling glDrawElements. We are using GL_TRIANGLES, since werestrictedour.objmodelstobetotallytriangulated.DrawingmesheswithglDrawEle- ments is actually pretty smart. We provide buffers with vertex, normal and texture data, and OpenGL consults those buffers to draw our mesh based on an indices list that we also provide. This way, we do not need to include data twice in our buffers when we have a vertex shared by many faces on our mesh! We can just duplicate the indices, which cost much less memory and is more efficient. After drawing, it is also quite polite in OpenGL to disable the states we have enabled (see Figure 20). @Override public void draw ( GL10 gl ) { super . draw ( gl ); gl . glEnableClientState ( GL10 . GL_VERTEX_ARRAY ); gl . glEnableClientState ( GL10 . GL_NORMAL_ARRAY ); gl . glEnableClientState ( GL10 . GL_TEXTURE_COORD_ARRAY ); gl . glVertexPointer (3 , GL10 . GL_FLOAT , 0, vbuffer ); gl . glTexCoordPointer (2 , GL10 . GL_FLOAT , 0, tbuffer ); gl . glNormalPointer ( GL10 . GL_FLOAT , 0, nbuffer ); gl . glDrawElements ( GL10 . GL_TRIANGLES , indices . size () , GL10 . GL_UNSIGNED_SHORT , ibuffer ); gl . glDisableClientState ( GL10 . GL_VERTEX_ARRAY ); gl . glDisableClientState ( GL10 . GL_NORMAL_ARRAY ); gl . glDisableClientState ( GL10 . GL_TEXTURE_COORD_ARRAY ); } Figure 20. Method draw. This is it for this section. Next step we are going to finish our ObjActivity, and see how to register our mesh for rendering.
  26. 26. 27 Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011. DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos. Developing Android Applications for AugmentedReality 4.4. Step IV -Putting It All Together We have been through a lot in order to load and draw our meshes, but how do we actually put them to good use? Now that we have our MeshObject class, it is time to make use of it. Get a .obj model from any modelling package, and make sure it is triangulated and has normals and textures. Put it on the assets directory of your project. Now we want to open an Input- Stream from that file. That can be done with help of the AssetManager class, provided by the Android API. It has an overly complex method called open, which receives a string with the name of the asset as single paramenter and returns our InputStream. With the InputStream, we can create a new instance of our MeshObject class and get ready to rock. That is almost all there is to it! The only thing remaining is registering our object in ARToolKit. The ARToolKit instance can be obtained from the method getArtoolkit() from the super class AndARActivity, and can be used to register objects with the regis- terARObject method. The final Activity class looks like the code in Figure 21. public class ObjActivity extends AndARActivity { ARObject someObject ; ARTo- olkit artoolkit ; AssetManager am ; public class ObjActivity extends AndARActivity { ARObject someObject ; ARToolkit artoolkit ; AssetManager am ; @Override public void onCreate ( Bundle savedInstanceState ){ super . onCreate ( savedInstanceState ); am = getAssets () ; CustomRenderer renderer = new CustomRenderer () ; super . setNonARRenderer ( renderer ); try { artoolkit = super . getArtoolkit () ; someObject = new MeshObject ( am . open ("models/monkey.obj" ) , "monkyboy" , " android . patt " , 80.0 , new double []{0 ,0}) ; artoolkit . registerARObject ( someObject ); } catch ( Exception e ){ e . printStackTrace () ; } startPreview () ; } @Override public void uncaughtException ( Thread thread , Throwable ex ){ Log . e ( "AndAR EXCEPTION" , ex . getMessage () ) ; finish () ; Figure 21. Class ObjActivity -The final version. And with this, we finish. Now it is time to test and verify the program. In addi¬tion to this, you have to calibrate the application to recognize the marker that you have choosed.
  27. 27. 28 Tendências e Técnicas e Realidade Virtual e Aumentada, Porto Alegre, v. 2, n. 1, p. 9-28, jan./dez. 2011. DUARTE, Philip Michel; COUTINHO, Edson Alyppyo Gomes; SANTOS, Selan Rodrigues dos. Developing Android Applications for AugmentedReality 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.
  28. 28. 29 Prototipagem Rápida de Aplicações Interativas de Realidade Aumentada Claudio Kirner Universidade Federal de Itajubá – UNIFEI ckirner@unifei.edu.br Abstract Augmented reality applications are interesting, but they are difficult to develop and customize, mainly by non-expert people. However, there are authoring tools which make easy this development. This chapter focuses on the augmented reality authoring problem, related to the development and use of applications. It describes an authoring tool, showing how to use it on rapid prototyping of augmented reality interactive applications, without the need of programming skills. A developed example using this tool is described and the impact of this approach is discussed, considering different types of potential authors and applications. Resumo As aplicações de realidade aumentada são interessantes, mas difíceis de serem de- senvolvidas e personalizadas, principalmente por não especialistas em computação. No entanto, existem ferramentas de autoria que facilitam esse desenvolvimento. Este texto aborda o problema da autoria de aplicações de realidade aumentada, relacionado com o desenvolvimento e uso das aplicações, em diversos níveis. É descrita uma ferramenta de au- toria e seu uso na prototipagem rápida de aplicações interativas de realidade aumentada por não programadores. Também é mostrado um exemplo desenvolvido com esta técnica e as repercussões dessa abordagem são discutidas, levando em conta os diversos tipos de autores e aplicações em potencial.
  29. 29. 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.
  30. 30. 31 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. 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
  31. 31. 32 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. 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.
  32. 32. 33 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. 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
  33. 33. 34 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. “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].
  34. 34. 35 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. 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-
  35. 35. 36 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. 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
  36. 36. 37 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. 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.
  37. 37. 38 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. Esses arquivos contêm informações de autoria fornecidas pelo usuário, de forma a preparar o sistema para uso ou para configurações visuais complementares. Os arquivos de configuração editáveis são: a) Arquivo do Marcador de Referência (refi.dat), contendo: indicação da base virtual associada com o marcador;• posição, orientação e escala da base virtual;• indicação do som associado com a base virtual, se existir;• indicação da lista de pontos virtuais;• indicação do ponto virtual de ativação da lista.• Figura 5. Pastas e arquivos da versão de distribuição do SACRA Esse arquivo encontra-se na pasta <SACRAWrlreference>, na versão de distribui- ção, tendo a aparência mostrada na Figura 6a. Figura 6. Arquivos de configuração do SACRA
  38. 38. 39 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. b) Arquivo da Lista de Pontos de um Marcador de Referência (prefi.dat), contendo: posição e orientação do ponto que irá receber a lista de objetos virtuais e• sons; endereço da lista de objetos virtuais com seus sons.• Esse arquivo encontra-se na pasta <SACRAposition>, na versão de distribuição (Figuras 6b1 e 6b2). O arquivo da Figura 6b1 foi criado por meio de edição e mostra um ponto virtual com uma lista de objetos. O arquivo da Figura 6b2 mostra três pontos virtuais, cada um com uma lista di- ferente de objetos. Esses pontos virtuais foram criados por autoria visual, motivo pelo qual possuem parâmetros não exatos. c) Arquivo de uma Lista de Objetos Virtuais de um Ponto (ex. animais.dat), con- tendo: objeto virtual 1:• indicação do modelo 3D do objeto virtual 1;• posição, orientação e escala do objeto virtual 1;• indicação do som associado com o objeto virtual 1.• objeto virtual m;• informações similares no objeto virtual 1.• Um editor de texto simples, como o bloco de notas, pode ser usado para criar ou editar os arquivos de configuração. Esse arquivo encontra-se na posição <SACRAanimais>, na versão de distribuição (Figura 6c). Pastas As pastas mencionadas aqui são recursos preenchidos pelo desenvolvedor não pro- gramador, contendo informações úteis para a criação do ambiente de RA aumentada. Há quatro pastas no sistema SACRA, contendo: informações de configuração de posição de pontos (position); lista de objetos virtuais, contendo informações de configu- ração de posições dos objetos virtuais e sons e os próprios objetos virtuais (ex. animais); sons (audio); e texturas (textura), conforme a Figura 7.
  39. 39. 40 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. 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.
  40. 40. 41 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. 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
  41. 41. 42 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. 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
  42. 42. 43 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. 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-
  43. 43. 44 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. 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).
  44. 44. 45 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. 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.
  45. 45. 46 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. 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.
  46. 46. 47 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. 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).
  47. 47. 48 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. 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.
  48. 48. 49 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. 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
  49. 49. 50 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. 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.
  50. 50. 51 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. 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.
  51. 51. 52 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. 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
  52. 52. 53 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. 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.
  53. 53. 54 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. 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.

×