Livro Do Pre Simposio X Symposium On Vir

Organizadores
Robson Siscoutto
Rosa Costa
Realidade Virtual e
Aumentada: Uma Abordagem
Tecnológica
Edição
Sociedade Brasileira de Computação – SBC
Promoção
Sociedade Brasileira de Computação – SBC
Laboratório de Tecnologias para o Ensino Virtual e Estatística (LabTEVE)
Livro do Pré-Simpósio
X Symposium on Virtual and Augmented Reality
João Pessoa – PB, 13 de Maio de 2008.
Apresentação
Somos uma comunidade jovem, multidisciplinar, criativa,

aberta a idéias e desafios, a qual atrai e acolhe novos talentos,
sejam eles estudantes ou profissionais migrando de outras áreas.
Foi pensando nesses novos e bem-vindos participantes do SVR que
criamos o Pré-Simpósio (PS), apresentado pela primeira vez em
São Paulo junto ao SVR 2004. O sucesso da iniciativa fez com que
a Comissão Especial de Realidade Virtual da SBC, responsável
pela organização e promoção do SVR, incluísse de forma definitiva
o PS na programação de atividades do evento.
O principal objetivo do Pré-Simpósio é oferecer um curso
rápido e abrangente sobre os principais conceitos e tecnologias das
áreas de RV e RA, de tal forma a estabelecer um repertório básico
que ajude o participante a melhor aproveitar tudo o que será
exibido e discutido ao longo dos três dias de atividades principais
do SVR. Criado, desenvolvido e apresentado por professores e
pesquisadores seniores da comunidade de RV e RA, o Pré-
Simpósio oferece aos participantes, além das 8 horas-aula, material
complementar na forma de um texto abrangente que cobre os
principais conceitos e tecnologias da área, cujo conteúdo vai muito
além do que é apresentado ao vivo. No SVR 2004, o PS deu
origem ao livro “Realidade Virtual: Conceitos e Tecnologia”.
Esse livro, já esgotado, tem sido usado como referência em cursos
técnicos e superiores, não só da área de computação e informática,
mas também de design, comunicação e artes.
Após um processo de reestruturação e revisão da publicação
do Pré-Simpósio do SVR 2004, bem como a ampliação e criação de
novos capítulos, foi publicado, no SVR 2006, o livro denominado
“Fundamentos e Tecnologia de Realidade Virtual e
Aumentada”. Esse livro foi fruto do trabalho colaborativo de
representantes de uma comunidade jovem e atuante, que está
crescendo em número e qualidade, podendo ser constatado em cada
nova edição do Symposium on Virtual and Augmented Reality
(SVR).
Com o intuito de continuar a democratização e a
disseminação do conhecimento sobre RV e RA, o PS do SVR
2007, foi lançado o livro denominado “Realidade Virtual e
Aumentada: Conceitos, Projeto e Aplicações” contribuindo para
a expansão desta comunidade. Este livro foi o resultado do
trabalho de 34 autores da comunidade brasileira de RV, que não
mediram esforços para produzir este texto didático e de qualidade,
e aos quais muito agradecemos.
Neste ano de 2008, o PS do SVR 2008 lança mais uma obra
intitulada “Realidade Virtual e Aumentada: Uma Abordagem
Tecnológica” oferecendo uma visão geral e abrangente dos
conceitos, tecnologias e aplicações. Esta obra foi o resultado do
trabalho de 14 autores da comunidade brasileira de RV constitui
uma referência para profissionais e pesquisadores, 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 realidade virtual e aumentada.
Boa Imersão!!!
Robson Siscoutto1 e Rosa Costa2

P P
EDITORES
1
P robson@unic.br
PTU
2
P P rcosta@ime.uerj.br
Copyright © 2008 by editors and authors
Todos os direitos reservados pelos respectivos detentores
Figuras e citações referenciadas: direitos reservados aos respectivos detentores
Coordenação de Produção e Editoração:

Robson Augusto Siscoutto - UNIC
Criação da Capa:
Alexandre Frigeri (Faculdade de Comunicação Social - UNIC)
Dados Internacionais de Catalogação na Publicação (CIP)

(Câmara Brasileira do Livro)
Realidade Virtual e Aumentada: Uma Abordagem Tecnológica
Robson Siscoutto e Rosa Costa - editores. – João
Pessoa - PB,
Editora SBC – Sociedade Brasileira de Computação,
Porto Alegre, 2008.
“Livro do pré-simpósio, X Symposium on Virtual and
Augmented Reality”
Bibliografia.
1. Realidade Virtual, Realidade Aumentada I. Siscoutto,
Robson II. Costa, Rosa.
I S B N 85-7669-185-X
Índice para catálogo sistemático:
1. Realidade Virtual e Aumentada: Ciência da Computação 006
Esta livro foi especialmente editada, a partir de conteúdos desenvolvidos para o
curso “Realidade Virtual e Aumentada: Uma Abordagem Tecnológica”
apresentado no pré-simpósio, em 13 de Maio de 2008, associado ao X
Symposium on Virtual and Augmented Reality, realizado em João Pessoal - PB
de 13 a 16 de Maio de 2008, promovido pela Sociedade Brasileira de
Computação e organizado pelo Laboratório de Tecnologias para o Ensino Virtual
e Estatística (LabTEVE).
João Pessoal - PB
2008
Sumário
Apresentação e Prefácio
Robson A. Siscoutto e Rosa M. E. M. Costa – Organizadores
Parte 1 – Conceitos
1. Fundamentos de Realidade Virtual e Realidade Aumentada ... 01

Robson A. Siscoutto (UNIC) e Cláudio Kirner (UNIMEP)
2. Dispositivos para Sistemas de Realidade Virtual ...................... 21

Liliane S. Machado (UFPB) e Alexandre Cardoso (UFU)
3. Técnicas de Interação para Ambientes de Realidade Virtual e

Aumentada .................................................................................... 46
Judith Kelner (UFPE) e Veronica Teichrieb (UFPE)
Parte 2 – Tecnologias de Desenvolvimento
4. VRML e X3D ............................................................................. 66

Alexandre Cardoso (UFU), Luciano Pereira Soares (USP) e
Marcelo K. Zuffo (USP)
5. JAVA 3D .................................................................................. 162

José Remo F. Brega (UNESP), Ildeberto A. Rodello (UNIVEM) e
Antonio C. Sementille (UNIVEM)
6. ARToolKit ................................................................................ 178

Cláudio Kirner (UNIMEP) e Rafael Santin (UNIMEP)
Parte 3 – Aplicações
7. Jogos e Entretenimento com Realidade Virtual e Realidade

Aumentada ...................................................................................277
Romero Tori (USP/SENAC), Ricardo Nakamura (USP), João Luiz
Bernardes Jr (USP), Roberto Cezar Bianchini (USP), Eduardo
Costa Jacober (USP), Daniel Calife (USP)e Alexandre
Nascimento Tomoyose (USP)
8. Aplicações Médicas com Realidade Virtual e Realidade
Aumentada .................................................................................. 309
Fátima L. S. Nunes (UNIVEM), Rosa M. E. M. Costa (UERJ), Ana
Cláudia M. T. G. Oliveira (UNIVEM), Sérgio R. Delfino (UNIVEM),
Larissa Pavarini (UNIVEM), Ildeberto A. Rodello (UNIVEM),
José Remo F. Brega (UNIVEM) e Antônio C. Sementille (UNIVEM)
9. Aplicações na Educação e Treinamento ................................. 343

Alexandre Cardoso (UFU) e Edgard Lamounier (UFU)
PARTE 1
CONCEITOS
Pré Simpósio –SVR2008
Capítulo
1
Fundamentos de Realidade Virtual
e Aumentada
Claudio Kirner1,2 e Robson Augusto Siscoutto3
1
Faculdade de Ciências Exatas e da Natureza – Universidade Metodista
de Piracicaba (UNIMEP)
Rodovia do Açúcar, Km 156 – 13400-911 – Piracicaba - SP – Brasil
2
Centro Universitário Adventista de São Paulo (UNASP)
Est. de Itapecerica, 5859 CEP 05858-001 - São Paulo-SP - Brasil
ckirner@unimep.br
3
Faculdade de Ciência e Tecnologia – Universidade de Cuiabá (UNIC)
Av. Beira Rio, 3100 – 78015-480 – Jardim Europa - Cuiabá - MT – Brasil
robson@unic.br
Abstract
Virtual reality and augmented reality are areas related to new user
interface generation, making easy and improving the user
interaction with computational applications. This chapter presents
the concepts of virtual and augmented reality, showing the aspects
of technology, design and application to be addressed in this book.
1
Resumo
Realidade Virtual e Realidade Aumentada são duas áreas

relacionadas com as novas gerações de interface do usuário,
facilitando e potencializando as interações do usuário com as
aplicações computacionais. Este capítulo apresenta os conceitos
de realidade virtual e aumentada, mostrando os aspectos de
tecnologia, projeto e aplicação a serem abordados neste livro.
1.1. Introdução
Antes do advento do computador eletrônico, com o
desenvolvimento do ENIAC em 1945, as pessoas utilizavam
interfaces naturais para interagir com o mundo no seu dia-a-dia,
usando seus sentidos. Em raras ocasiões, elas necessitavam
interagir com máquinas, apertando botões ou acionando alavancas.
O computador eletrônico trouxe um novo processo

sofisticado de interação com as aplicações, exigindo conhecimento
simbólico (abstrato) e necessidade de treinamento, uma vez que o
conhecimento do mundo real já não era suficiente.
Apesar dos benefícios da tecnologia, a sofisticação das

interfaces do usuário fez com que as pessoas tivessem que se
ajustar às máquinas, durante muitas décadas. Felizmente, os
pesquisadores, desde o início da era dos computadores, buscaram
maneiras de fazer com que as máquinas se ajustassem às pessoas, o
que foi se conseguindo com a evolução das tecnologias de
hardware, software e telecomunicações. Surgiram então interfaces
de voz, interfaces tangíveis, interfaces hápticas, etc, possibilitando,
aos usuários, acessarem aplicações como se estivessem atuando no
mundo real, falando, pegando, apertando, fazendo gestos, etc.
Há vários pontos importantes nessa evolução, envolvendo

invenções como: computador eletrônico à válvula, transistor,
2
circuito integrado, monitor de computador, computação gráfica,

rede, computador pessoal (PC), Internet, Web, software livre, além
de outros inventos tecnológicos, cuja integração permitiram o uso
transparente da tecnologia, por parte do usuário. O usuário já não
precisa perceber a presença da tecnologia, pois ela trabalha para ele
de forma invisível em qualquer lugar, dando origem aos termos:
ubíquo e pervasivo.
Nesse contexto, a realidade virtual [Burdea, 1994] e a

realidade aumentada [Azuma, 1997] têm um papel importante, pois
são interfaces computacionais avançadas, que ainda não foram
implantadas de forma expressiva na sociedade.
As primeiras interfaces computacionais, usadas nas décadas

de 40 e 50, eram baseadas em chaves e lâmpadas, que permitiam
uma comunicação com o computador baseada em linguagem de
máquina. Na década de 60, surgiram as consoles com vídeo, dando
início às interfaces gráficas rudimentares. Com a utilização de
microprocessadores, nas décadas de 70 e 80, os
microcomputadores se popularizaram, usando interface baseada em
comando, como o DOS. A evolução desta interface resultou no
Windows, que, explorando técnicas de multimídia, persiste até
hoje. Apesar de interessante e de ter bom potencial de uso, a
interface Windows fica restrita à limitação da tela do monitor e ao
uso de representações como menus e ícones.
A realidade virtual surge então como uma nova geração de

interface, na medida em que, usando representações
tridimensionais mais próximas da realidade do usuário, permite
romper a barreira da tela, além de possibilitar interações mais
naturais. A realidade virtual teve suas origens na década de 60, com
o desenvolvimento do ScketchPad por Ivan Sutherland [Sutherland,
1963], mas só ganhou força na década de 90, quando o avanço
tecnológico propiciou condições para a execução da computação
3
gráfica interativa em tempo real. Apesar das vantagens da

realidade virtual, ela necessitava de equipamentos especiais como
capacete, luva, óculos estereoscópicos, mouses 3D, etc, para fazer
com que o usuário fosse transportado para o espaço da aplicação,
onde realiza suas interações. Além disso, o “transporte” do usuário
para o ambiente virtual (desconhecido) causava um desconforto
inicial e dificuldades de interação, exigindo, muitas vezes,
treinamento. Esses problemas inibiram a popularização da
realidade virtual como uma nova interface do usuário.
Por outro lado, a evolução tecnológica também propiciou,

na década de 90, o aparecimento da realidade aumentada,
permitindo a sobreposição de objetos e ambientes virtuais com o
ambiente físico, através de algum dispositivo tecnológico. Essas
aplicações ficaram mais acessíveis somente no início dos anos
2000, com a convergência de técnicas de visão computacional,
software e dispositivos com melhor índice de custo-benefício.
Além disso, o fato dos objetos virtuais serem trazidos para o espaço
físico do usuário (por sobreposição) permitiu interações tangíveis
mais fáceis e naturais, sem o uso de equipamentos especiais. Por
isso, a realidade aumentada vem sendo considerada uma
possibilidade concreta de vir a ser a próxima geração de interface
popular, a ser usada nas mais variadas aplicações em espaços
internos e externos.
Enquanto a realidade virtual depende de equipamentos de

visualização, como monitor, projetor e capacete, normalmente
utilizados em ambientes fechados, a realidade aumentada não
apresenta esta restrição com dispositivos misturadores, podendo ser
usada em qualquer ambiente (fechado ou aberto), sendo, portanto
mais abrangente e universal. Por outro lado, tanto a realidade
virtual quanto a realidade aumentada podem ser usadas em
aplicações individuais e em aplicações coletivas locais ou remotas,
propiciando experiências colaborativas [Billinghurst, 1999]
4
[Benford, 1998; Kirner, 2004]. No entanto, a realidade aumentada

apresenta a vantagem de permitir o uso de ações tangíveis
[Kawashima, 2001] e de operações multimodais, envolvendo voz,
gestos, tato, etc, facilitando o trabalho do usuário sem a
necessidade de treinamento.
Assim, a convergência tecnológica e o desenvolvimento de

interfaces estão apontando para a nova geração de interfaces
computacionais baseadas em realidade aumentada para uso nas
mais variadas áreas, desde entretenimento, como jogos, até
experimentos científicos coletivos, constituindo verdadeiros
laboratórios de pesquisa.
1.2. Conceitos e Definições

Em função da abundância de termos e de interesses das áreas de
realidade virtual e aumentada, em função de sua
multidisciplinaridade, serão abordados em seguida alguns conceitos
e definições envolvidos com o assunto.
1.2.1. Multimídia
Multimídia consiste na integração, controlada por computador, de
textos gráficos, imagens, vídeo, animações, áudio e outras mídias,
que possam representar, armazenar, transmitir e processar
informações de forma digital [Marshal, 2001].
Aplicações multimídia são potentes e simples de usar, mas
restringem a visualização do usuário à tela do computador (2D).
Esta deficiência pode ser atenuada com o aproveitamento do
espaço da tela do monitor, através de múltiplas janelas sobrepostas
ou espalhadas.
5
1.2.2. Realidade Virtual

A Realidade Virtual (RV) é uma “interface avançada do usuário”
para acessar aplicações executadas no computador, propiciando a
visualização, movimentação e interação do usuário, em tempo real,
em ambientes tridimensionais gerados por computador. O sentido
da visão costuma ser preponderante em aplicações de realidade
virtual, mas os outros sentidos, como tato, audição, etc. também
podem ser usados para enriquecer a experiência do usuário.
A modelagem dos ambientes virtuais, usando linguagens
como VRML (Virtual Reality Modeling Language) [VRML97,
2007] e sua sucessora, X3D [Walsh, 2001; Web3d, 2007], além de
outras linguagens e ferramentas de autoria, permite, ao usuário,
visualizar ambientes tridimensionais, movimentar-se dentro deles e
manipular seus objetos virtuais. Os objetos virtuais podem ser
animados, apresentando comportamentos autônomos ou disparados
por eventos. A Figura 1.1 mostra um exemplo de ambiente virtual
visto no monitor.
Figura 1.1. Exemplo de aplicação de realidade virtual.

A interação do usuário com o ambiente virtual é um dos
aspectos importantes da interface e está relacionada com a
capacidade do computador detectar e reagir às ações do usuário,
promovendo alterações na aplicação [Bowman, 2005]. O usuário,
interagindo com um ambiente virtual tridimensional realista, em
6
tempo-real, vendo as cenas serem alteradas como resposta aos seus

comandos, como ocorre nos videogames atuais, torna a interação
mais rica e natural, gerando mais engajamento e eficiência.
Nos ambientes virtuais, a interação mais simples é a

navegação, decorrente da movimentação do usuário no espaço
tridimensional, através de algum dispositivo, como o mouse 3D,
comandos de voz ou de gestos detectados por algum dispositivo de
captura, resultando na visualização de novos pontos de vista do
cenário. Nesse caso, não há mudanças no ambiente virtual, mas
somente um passeio exploratório. Interações, propriamente ditas,
com alterações no ambiente virtual, ocorrem quando o usuário
entra no espaço virtual das aplicações e visualiza, explora,
manipula e aciona ou altera os objetos virtuais, usando seus
sentidos, incluindo os movimentos tridimensionais de translação e
rotação naturais do corpo humano.
A interface baseada em realidade virtual permite que

habilidades e conhecimento intuitivos do usuário possam ser
utilizados para a manipulação dos objetos virtuais. Esse tipo de
interação é realizado, através de dispositivos não convencionais,
como capacete de visualização ou luvas, o próprio corpo, como
gestos e comandos de voz, ou até mesmo dispositivos
convencionais como mouse, teclado e monitor de vídeo. O usuário
deve ter a impressão de estar atuando dentro do ambiente virtual,
apontando, pegando, manipulando e executando outras ações sobre
os objetos virtuais, em tempo-real. Normalmente, os atrasos
admissíveis para que o ser humano tenha a sensação de interação
em tempo-real estão em torno de 100 milisegundos, tanto para a
visão, quanto para as reações de tato, força e audição. Isto impõe
um compromisso do sistema (processadores, software, dispositivos,
complexidade do ambiente virtual, tipo de interação, etc) em
funcionar com taxas mínimas de 10 quadros por segundo na
renderização das imagens (sendo desejado algo em torno de 20
7
quadros por segundo para suportar melhor as cenas animadas) e de

100 milisegundos de atraso nas reações aos comandos do usuário.
Assim, a complexidade do mundo virtual, os dispositivos usados, o
software e a configuração do sistema devem ser ajustados para
funcionar com as taxas mínimas de renderização e reação.
Existem muitas definições de realidade virtual, envolvendo

diversos aspectos [Burdea, 1994; Vince, 1995, 2004; Kirner, 1996;
Sherman, 2003]. Uma definição, sintetizando as várias
considerando as discussões apresentadas até agora, é a seguinte:
“Realidade virtual é uma interface avançada para aplicações

computacionais, que permite ao usuário navegar e interagir, em
tempo real, com um ambiente tridimensional gerado por
computador, usando dispositivos multisensoriais”.
Apesar da realidade virtual também usar múltiplas mídias,

ela enfatiza a interação do usuário com o ambiente tridimensional e
a geração das imagens em tempo real. Para que isso ocorra, a
plataforma computacional deve ser apropriada para aplicações de
realidade virtual, apresentando boa capacidade de processamento
gráfico para a renderização de modelos tridimensionais em tempo
real, e suportando dispositivos não convencionais de interação para
atender à demanda multisensorial.
A comparação entre multimídia e realidade virtual pode ser

vista da seguinte maneira:
• Multimídia envolve imagens capturadas ou pré-

processadas; prioriza a qualidade das imagens; exige alta
capacidade de transmissão; usa técnicas de compressão de dados;
atua no espaço 2D; e funciona com dispositivos convencionais.
• Realidade virtual envolve imagens calculadas em tempo
real; prioriza a interação com o usuário; exige alta capacidade de
8
processamento; usa técnicas e recursos de renderização de modelos

tridimensionais e funciona com dispositivos especiais.
Tanto na multimídia, como na realidade virtual, o usuário
tem de ser transportado para o domínio da aplicação (ambiente
virtual), podendo causar-lhe desconforto frente ao desconhecido,
além da necessidade de adaptação e treinamento.
1.2.3. Realidade Aumentada

A realidade aumentada é definida de várias maneiras:
a) é o enriquecimento do ambiente real com objetos
virtuais, usando algum dispositivo tecnológico, funcionando em
tempo real;
b) é uma melhoria do mundo real com textos, imagens e
objetos virtuais, gerados por computador [Insley, 2003];
c) é a mistura de mundos reais e virtuais em algum ponto
da realidade/virtualidade contínua, que conecta ambientes
completamente reais a ambientes completamente virtuais [Milgran,
1994];
d) é um sistema que suplementa o mundo real com objetos
virtuais gerados por computador, parecendo coexistir no mesmo
espaço e apresentando as seguintes propriedades:
- combina objetos reais e virtuais no ambiente real;
- executa interativamente em tempo real;
- alinha objetos reais e virtuais entre si;
- aplica-se a todos os sentidos, incluindo audição,
tato e força e cheiro [Azuma, 2001].
A Figura 1.2 apresenta um exemplo de aplicação de
realidade aumentada com uma mesa real enriquecida com vaso e
carro virtuais.
9
Figura 1.2. Realidade aumentada com vaso e carro virtuais

sobre a mesa.
Essa tecnologia deverá ter grande impacto no
relacionamento das pessoas, através de novas maneiras de realizar
visualização, comunicação e interação com pessoas e informação.
A realidade aumentada e a realidade virtual [Bimber, 2004]

podem ser comparadas da seguinte forma:
- a realidade aumentada enriquece a cena do mundo real

com objetos virtuais, enquanto a realidade virtual é totalmente
gerada por computador;
- no ambiente de realidade aumentada, o usuário mantém o
sentido de presença no mundo real, enquanto que, na realidade
virtual, a sensação visual é controlada pelo sistema;
- a realidade aumentada precisa de um mecanismo para
combinar o real e o virtual, enquanto que a realidade virtual precisa
de um mecanismo para integrar o usuário ao mundo virtual.
1.2.4. Hiper-realidade
O próximo passo da evolução das interfaces é incrementar a
combinação do mundo real com o mundo virtual, através de novos
10
elementos e comportamentos para facilitar e potencializar a

interação do usuário com os recursos que ele necessita no dia a dia.
Nesse contexto, surge o conceito de hiper-realidade [Tiffin,
2001], cuja definição é a seguinte: “hiper-realidade é a capacidade
tecnológica de combinar realidade virtual, realidade física,
inteligência artificial e inteligência humana, integrando-as de forma
natural para acesso do usuário”.
Ambientes de hiper-realidade permitirão que habitantes

reais interajam com habitantes remotamente localizados, bem como
com objetos ou formas de vida imaginárias ou artificiais, gerados
por computador, em um mundo misturado. Esse mundo será
formado por pessoas, animais, insetos, plantas, terrenos,
construções e objetos virtuais inteligentes, todos integrados. Com
a visão do mundo misturado, cada usuário poderá enxergar o que
lhe interessa, de acordo com seu perfil ou sua necessidade, e
interagir com os objetos, de forma a ter suas necessidades
satisfeitas. Como exemplo, o usuário, ao caminhar ou dirigir seu
automóvel por uma cidade (usando um capacete de visão óptica
direta), poderá fazer solicitações por comandos de voz e ver
legendas virtuais nos prédios e ruas orientando-o ou mostrando
opções como: o melhor caminho para chegar a um destino;
restaurantes de determinados tipos ou padrões; entretenimentos
específicos; lojas; supermercados; hospitais; e assim por diante.
Muito do que se desenvolveu na Internet para facilitar a

vida do usuário, poderá ser transportado para o mundo misturado
de forma gráfica e seletiva. Assim, nesse mundo misturado com
hiper-realidade, as pessoas deverão satisfazer muitas de suas
necessidades, atuando num ambiente integrado inteligente, sendo
atendidas de forma explícita ou implícita.
11
1.2.5. Rastreamento
O rastreamento, em ambientes de realidade virtual e aumentada,
tem a função de identificar a posição da mão, da cabeça, do próprio
usuário ou de algo atrelado a ele, como uma placa. Com isto, o
sistema permite que o usuário exerça um controle de
posicionamento em ambientes virtuais ou aumentados, podendo,
por exemplo, movimentar-se e tocar, agarrar, mover e soltar
objetos virtuais.
Para uso em aplicações de realidade virtual, muitos
dispositivos de rastreamento foram desenvolvidos, usando
princípios mecânicos, magnéticos, de ultrasom, etc. Cada tipo
apresenta vantagens e desvantagens, mas em geral são caros.
Mais recentemente, com a popularização da webcam e com

o avanço das técnicas de visão computacional e do poder de
processamento dos microcomputadores, o rastreamento óptico
passou a ser uma realidade, em função da disponibilidade e do
baixo custo. A biblioteca ARToolKit [Lamb, 2007], usada em
aplicações de realidade aumentada, utiliza esse tipo de
rastreamento.
Assim, o capítulo 2 deste livro explora, em detalhes, os

conceitos, tecnologia e uso de rastreamento óptico para aplicações
de realidade virtual e aumentada.
1.2.6. Interação
A interação consiste na capacidade do usuário atuar em ambientes
virtuais e aumentados, promovendo alterações e reações às suas
ações. Esta é a principal característica dos jogos por computador,
sendo o fator determinante para o envolvimento do usuário e o
sucesso da aplicação.
12
Para que uma interação tenha efeito, é necessário um

controle de posicionamento do usuário (rastreamento) e outros
atributos do sistema como: apontamento e seleção de objetos,
ativação de ações, etc.
O capítulo 3 deste livro trata dos detalhes da interação em

ambientes e realidade virtual e aumentada, mostrando conceitos,
implementação e exemplos.
1.3. Tecnologia, Projeto e Aplicações

As áreas de realidade virtual e realidade aumentada, assim como
outras áreas, só se desenvolveram com a convergência de uma série
de fatores, incluindo as pesquisas, a tecnologia, a disponibilidade
de produtos e os custos acessíveis. Nesse sentido, tiveram papel
fundamental os pesquisadores que disseminaram essas áreas com o
desenvolvimento de recursos disponibilizados à sociedade
gratuitamente. A linguagem VRML - Virtual Reality Modeling
Language [VRML97, 2007] para uso em realidade virtual e a
biblioteca ARToolKit [Lamb, 2007] para realidade aumentada são
os exemplos mais marcantes de recursos gratuitos e livres, mas
existem vários outros disponibilizados por pesquisadores e, mais
recentemente, por empresas.
Em seguida, o leitor deverá ter uma visão geral sobre as
seções deste livro, envolvendo os aspectos de tecnologia, projeto e
aplicações.
1.3.1. Ambientes de Hardware e Software

O hardware de um computador é o núcleo de qualquer aplicação,
oferecendo os recursos a serem usados. Suas características,
ajustadas às necessidades da aplicação, são responsáveis pela
obtenção do melhor índice de custo-benefício.
13
O hardware envolve muitos elementos, consistindo de:

processador; placas especiais, como placas gráficas e sonoras;
periféricos, incluindo dispositivos especiais multisensoriais; e
infraestrutura de rede.
Para fazer o hardware funcionar adequadamente, são usados

ambientes de software, denominados núcleos ou sistemas
operacionais, que constituem máquinas virtuais poderosas
encarregadas de suportar as necessidades de aplicações específicas
de realidade virtual e aumentada.
O capítulo 4 deste livro aborda as questões de hardware e

software básicos, mostrando suas características, exemplos e
potencial de utilização.
1.3.2. Desenvolvimento e Avaliação de Sistemas

O processo de desenvolvimento de aplicações de realidade virtual e
aumentada requer a utilização de técnicas de engenharia de
software adaptadas ao contexto dessas áreas.
Além das técnicas de desenvolvimento, é importante usar
técnicas de avaliação das aplicações, no sentido de aferí-las sob
pontos de vista específicos.
O capítulo 5 deste livro trata desse assunto para a área de

realidade virtual, servindo como ponto de partida para o processo
de desenvolvimento e avaliação de aplicações de realidade
aumentada.
1.3.3. Ferramentas
O desenvolvimento de aplicações de realidade virtual e aumentada
pode ser facilitado, quando são usadas ferramentas apropriadas
para cada caso, como linguagens, bibliotecas, ambientes visuais de
14
desenvolvimento, etc, constituindo ferramentas de autoria das

aplicações.
A escolha certa das ferramentas depende de um bom
conhecimento do domínio da aplicação e da disponibilidade de
recursos de hardware e de software, além de recursos financeiros,
quando se tratar de ferramentas comerciais.
O capítulo 6 deste livro faz uma análise de ferramentas para

desenvolvimento de aplicações de realidade virtual e aumentada,
citando exemplos e potencialidades de uso.
1.3.4. Sistemas Distribuídos

Aplicações simples de realidade virtual e aumentada costumam ser
voltadas a um único usuário. No entanto, a demanda por trabalho
colaborativo, envolvendo vários usuários remotos, vem crescendo e
exigindo o desenvolvimento de aplicações sobre redes de
computadores ou constituindo sistemas distribuídos.
Em função dos requisitos específicos das aplicações de
realidade virtual e aumentada, é importante que os ambientes de
rede sejam apropriados para dar-lhes suporte, fornecendo o
comportamento esperado pelos usuários.
O capítulo 7 deste livro trata das questões de sistemas

distribuídos de realidade virtual e aumentada, considerando seus
requisitos e mostrando exemplos, aplicações e ferramentas.
1.3.5. Dispositivos Hápticos

Quando se trabalha com ambientes de realidade virtual e
aumentada, manipulando objetos virtuais, sente-se falta da
sensação de toque (háptica) que impõe mais realismo às aplicações.
Em alguns casos, a sensação háptica, envolvendo tato e força, pode
15
até ser dispensada, mas, em outros, ela é essencial, como ocorre em

situações de treinamento.
O treinamento médico é um exemplo típico, no qual o
cirurgião deve ter as mesmas sensações de toque nos tecidos
virtuais e nos tecidos reais. Para isto, são usados os dispositivos
hápticos e os modelos geométricos deformáveis para se ajustarem
às várias situações de pressão e ruptura.
O capítulo 8 deste livro discute os aspectos dos dispositivos

hápticos e sua utilização em aplicações de realidade virtual e
aumentada.
1.3.6. Ambientes Colaborativos

A evolução das tecnologias de informática e de telecomunicações
vem propiciando a computação ubíqua ou pervasiva, que faz com
que as aplicações computacionais estejam em vários lugares ao
mesmo tempo. Isto ocorre com telefones celulares, Internet e outras
aplicações.
Como resultado dessas facilidades, as aplicações
colaborativas estão tendo um grande desenvolvimento,
principalmente em educação, treinamento, projeto e
entretenimento, demandando ambientes mais realistas e
potencializados como ocorre com realidade virtual e aumentada.
O capítulo 9 deste livro aborda os conceitos, características,

exemplos e potencialidades de ambientes colaborativos de
realidade virtual e aumentada.
1.3.7. Jogos e Entretenimento

Jogos e entretenimento sempre tiveram um apelo muito grande nas
pessoas. Com o surgimento da realidade virtual e da realidade
aumentada, usando cenários e comportamentos mais realistas,
16
recursos dessas áreas passaram a ser usados para o

desenvolvimento de novas aplicações ou para a remodelagem de
aplicações já existentes.
O capítulo 10 deste livro trata do uso de realidade virtual e
aumentada em jogos e entretenimento, mostrando suas
características, exemplos e tendências.
1.3.8. Aplicações Médicas

A medicina é uma das áreas que mais demandaram o uso de
realidade virtual e aumentada em educação, treinamento,
diagnóstico, tratamento e simulação de cirurgia. Realidade virtual
e realidade aumentada, pelas suas características de visualização
3D e de interação em tempo real, permitem a realização de
aplicações médicas inovadoras, que antes não podiam ser
realizadas.
O capítulo 11 deste livro discute como a realidade virtual e
a realidade aumentada podem ser usadas em aplicações médicas,
mostrando exemplos e explorando os recurso de visualização e de
sensações multisensoriais em situações físicas e psicológicas.
1.3.9. Visualização
As imagens sempre foram usadas para melhorar as condições de
visualização de informação das pessoas, através de gráficos e
figuras.
Por outro lado, ambientes de realidade virtual e aumentada
amplificam as capacidades das pessoas em avaliarem informações
tridimensionais, na medida em que flexibilizam a atuação no
espaço 3D e permitem o uso de interações multimodais,
possibilitando maior riqueza de detalhes, melhores técnicas de
interação e mais desempenho.
17
O capítulo 12 deste livro aborda as questões de visualização

apoiada por realidade virtual e aumentada, mostrando exemplos e
tendências.
1.4. Conclusões
Realidade virtual e realidade aumentada são áreas recentes do
conhecimento que vêm dando, aos usuários, melhores condições de
interação com aplicações computacionais, propiciando a eles
interações naturais e potencialização de suas capacidades.
Para isso, muitos recursos são utilizados, envolvendo
hardware, software, periféricos, redes, tecnologias especiais,
técnicas de projeto e avaliação e o desenvolvimento de aplicações.
Este livro agrupa várias questões envolvidas com o uso de

realidade virtual e realidade aumentada para facilitar a vida das
pessoas, considerando os conceitos e tendências, assim como os
aspectos de tecnologia, projeto e aplicações.
Este capítulo teve como objetivo dar uma visão conceitual

de realidade virtual e aumentada, incluindo tendências, além de
apresentar um resumo do que o leitor irá encontrar na sequência de
leitura.
1.5. Referências Bibliográficas

Azuma, R. (1997) “A Survey of Augmented Reality", Presence:
Teleoperators and Virtual Environments, v .6, n.4, August, p.
355-385.
Azuma, R. et al. (2001) “Recent Advances in Augmented Reality.”
IEEE Computer Graphics and Applications, v .21, n.6, p. 34-47.
18
Benford, S. et. al. (1998) "Understanding and Constructing Shared

Spaces with Mixed Reality Boundaries". ACM ToCHI, v.5, N.3,
p. 185-223.
Billinghurst, M., Kato, H. (1999) "Collaborative Mixed Reality",
Proc. of the International Symposium on Mixed Reality,
ISMR'99, Springer -Verlag, p. 261-284.
Bimber, O., (2004) "Augmented Reality - Part 1 - Introduction and
Overview" <http://www.uni-weimar.de/~bimber/Pub/AR/>
Bowman, D., et al. (2005). “3D User Interfaces: Theory and
Practice”. Boston, MA: Addison-Wesley.
Burdea, G., Coiffet,P. (1994) “Virtual RealityTechnology", John
Wiley & Sons.
Insley, S. (2003) "Obstacles to General Purpose Augmented
Reality"
<http://islab.oregonstate.edu/koc/ece399/f03/final/insley2.pdf>
Kawashima, T. et. al. (2001) "Magic Paddle: A Tangible
Augmented Reality Interface for Object Manipulation", Proc. of
ISMR2001, p. 194-195.
Kirner, C., Pinho, M.S. (1996) “Introdução a Realidade Virtual”.
Mini-Curso, JAI/SBC, Recife, PE.
Kirner, C. (2004) “Mãos Colaborativas em Ambientes de
Realidade Misturada” Anais do 1o Workshop de Realidade
Aumentada, Piracicaba, SP, p. 1-4.
Lamb,P. (2007) “ArtoolKit” <www.hitl.washington.edu/artoolkit/>
Marshall, D. (2001) “What is Multimedia?”
http://www.cs.cf.ac.uk/Dave/Multimedia/node10.html
Milgram, P. et. al. (1994) “Augmented Reality: A Class of
Displays on the Reality-Virtuality Continuum”. Telemanipulator
and Telepresence Technologies, SPIE, V.2351, p. 282-292.
19
Sherman, W.R., Craig, A.B. (2003) “Understanding Virtual

Reality”, Morgan Kaufmann.
Sutherland, I. E. (1963) “SKETCHPAD: A MAN-MACHINE
GRAPHICAL COMMUNICATION SYSTEM” AFIPS
Conference Proceedings, Spring Joint Computer Conference,
Detroit <faculty.cs.tamu.edu/hammond/courses/SR/papers/
Sutherland/Sutherland1963Sketchpad.pdf>
Tiffin, J., Terashima, N. ed. (2001) “Hyper-reality: Paradigm for
the Third Millennium”. Routledge.
Vince, J. (1995) “Virtual Reality Systems”, Addison-Wesley.
Vince, J. (2004) “Introduction to Virtual Reality”, Springer-Verlag,
2nd edition.
VRML97 (2007). “The Virtual Reality Modeling Language”.
<http://www.web3d.org/x3d/specifications/vrml/ISO-IEC-
14772-VRML97/>
Walsh, A.E., Bourges-Sévenier, M. (2001), “Core WEB3D”,
Prentice Hall.
Web3D Consortium (2007) “X3D Documentation”.
<http://www.web3d.org/x3d/>
20
Capítulo
2
Dispositivos para Sistemas de
Realidade Virtual
Liliane dos Santos Machado1 e Alexandre Cardoso2
1
Departamento de Informática – Universidade Federal da Paraíba (UFPB)
Cidade Universitária s/n – 58052-900 – João Pessoa – PB – Brasil
liliane@di.ufpb.br
2
Programa de Pós Graduação em Engenharia Elétrica – Universidade
Federal de Uberlândia (UFU)
CEP – 38.400-902 – Uberlândia – MG – Brasil
alexandre@ufu.br
Abstract
This chapter presents devices used in virtual reality systems to

provide intuitive interaction and increase user immersion. The
devices were divided in two categories to explain their purpose and
their functionalities.
Resumo
Este capítulo apresenta alguns dos dispositivos mais utilizados em

sistemas de realidade virtual. O objetivo de tais dispositivos é
21

oferecer maneiras mais intuitivas de interação ou prover um maior

nível de imersão ao usuário. Estes dispositivos estão aqui
separados em duas categorias que apresentam sua finalidade e
suas funcionalidades.
2.1. Introdução
A utilização de dispositivos específicos para entrada e saída
de informações em um sistema de Realidade Virtual (RV) visa
aumentar os níveis de imersão do usuário com o sistema e prover
modos mais intuitivos de interação.
Pode-se dividir os dispositivos utilizados em um sistema de
RV em duas categorias: dispositivos de entrada e dispositivos de
saída, sendo eles responsáveis por toda comunicação usuário-
sistema. A Figura 2.1 apresenta um esquema com os elementos
chave de um sistema de RV, onde pode ser notada a importância
dos dispositivos de entrada e saída de dados.
Figura 2.1 - Elementos chave de sistemas de RV.

Além dos dispositivos específicos aqui apresentados,
22

grande parte dos sistemas de RV integram também dispositivos

convencionais, como mouse e teclado. Na maioria das vezes, estes
são utilizados para selecionar menus e objetos ou navegar pelo
ambiente.
2.2. Dispositivos de Entrada de Dados
Dispositivos de Entrada de Dados para sistemas de RV são

utilizados para enviar informações sobre ações do usuário para o
sistema. Basicamente, eles podem ser de dois tipos: de interação ou
de rastreamento. Em ambos os casos, as ações do usuário são
identificadas em um espaço tridimensional.
Os dispositivos de interação permitem ao usuário a

movimentação e manipulação de objetos no mundo virtual, de
forma direta ou indireta. Neste contexto, tais dispositivos conectam
ações do usuário com elementos de cena do ambiente virtual.
Os dispositivos de rastreamento, por sua vez, monitoram

movimentos de partes do corpo do usuário, para criar a sensação de
presença no mundo virtual. Assim, ao movimentar-se o usuário tem
seu deslocamento reconhecido pelo dispositivo e uma atualização
do ambiente virtual é efetuada.
É importante observar que objetos dos ambientes virtuais
geralmente podem mover-se com seis graus de liberdade (6DOF –
degrees of freedom), o que implica na possibilidade de três rotações
e três translações, como pode ser visto na Figura 2.2.
23

Figura 2.2 - Seis graus de liberdade dos elementos de Ambientes

Virtuais.
2.2.1. Dispositivos de Interação

Existem diferentes dispositivos de interação com diferentes
finalidades, sendo importante escolher o mais adequado para a
aplicação de RV em questão. A escolha do dispositivo de interação
leva em conta não apenas a finalidade do sistema, mas também os
pacotes computacionais utilizados, como linguagens e toolkits, pois
a eficiência do sistema vai depender da capacidade destes pacotes
de aproveitar as características do dispositivo.
A seguir são apresentados alguns dispositivos de interação
utilizados em sistemas de RV. Entretanto, com o avanço
tecnológico, novos dispositivos são constantemente desenvolvidos
com o objetivo de oferecer modos mais intuitivos de interação.
24

a) Dispositivos com 2DOF

Interagir com um mundo virtual nem sempre requer o uso
de um complicado e/ou caro dispositivo. Muitas tarefas podem ser
executadas com simples dispositivos com 2DOF, como um mouse
ou um joystick. Apesar de limitar as possibilidades de movimento,
estes dispositivos reduzem o tempo de resposta do sistema (seus
eventos são mais rapidamente processados) e são fáceis de serem
utilizados.
b) Dispositivos com 6DOF

Dispositivos de interação com 6DOF permitem uma
movimentação bastante ampla quando utilizados em sistemas de
RV, pois permitem a movimentação em todas as direções do
espaço 3D incluindo movimentos de rotação.
Algumas empresas procuram modificar o projeto do mouse
padrão para que este possa funcionar com sensores de trajetória de
6DOF ou 3DOF. Esses dispositivos passam então a utilizar
dispositivos de rastreamento ultrassônicos ou eletromagnéticos,
ficando sua eficiência dependente da qualidade do sistema de
rastreamento dos movimentos.
Já os dispositivos chamados isométricos, ou bolas

isométricas são fáceis de manipular e apresentam uma diferença
crucial em relação aos demais dispositivos 6DOF, pois são capazes
de medir a quantidade de força aplicada a eles. Costumam
constituir-se de uma bola sobre uma plataforma com botões
(normalmente um deles é utilizado para a reinicialização do
sistema) que são configurados via software.
c) Luvas de Dados
25

As luvas de dados são utilizadas em sistemas para

reconhecer e capturar os movimentos dos dedos da mão do usuário.
Na maioria dos equipamentos disponíveis são utilizados sensores
mecânicos ou de fibra ótica, sendo que as versões mais populares
de luvas de dados utilizam fibraótica. Seu uso consiste em um fio
de fibra ótica com junções. Quando a junta é movida o cabo dobra-
se reduzindo a passagem de luz por ele. Essas variações de luz são
resumidas e transmitidas para
o computador. Às luvas de dados também pode ser adicionado um
sensor de movimentos, neste caso um dispositivo de trajetória
permitirá a localização da mão do usuário no espaço através deste
sensor. O esquema básico deste tipo de luva pode ser visto na
Figura 2.3.
Figura 2.3 - Elementos de uma luva de dados.
26

Atualmente existem diversos modelos de luvas disponíveis

no mercado de RV, utilizados em sistemas de diferentes
finalidades.
d) Sensores de Entrada Biológicos

Sensores de entrada biológicos processam atividades
chamadas de indiretas, como comando de voz e sinais elétricos
musculares. Estudos sobre reconhecimento de voz existem há mais
de vinte anos, e em sistemas de RV o reconhecimento de comandos
de voz pode facilitar a execução de tarefas no mundo virtual,
principalmente quando as mãos estiverem ocupadas em outra tarefa
e não possam acessar o teclado.
Por outro lado, dispositivos que utilizam sinais elétricos
musculares utilizam eletrodos colocados sobre a pele para detectar
a atividade muscular, permitindo ao usuário movimentar-se pelo
mundo virtual através de simples movimentos, como o dos olhos,
por exemplo.
2.2.2. Dispositivos de Rastreamento

Dispositivos de interação podem estar associados a um
dispositivo responsável pela tarefa de detecção da trajetória,
conhecido como dispositivo de rastreamento. Dispositivos deste
tipo trabalham baseados na diferença de posição ou orientação em
relação a um ponto ou estado de referência. Basicamente existe
uma fonte que emite
o sinal (que pode estar localizada no dispositivo de interação), um
sensor que recebe este sinal e uma caixa controladora que processa
o sinal e faz a comunicação com o computador.
A maioria das aplicações que utiliza detecção de trajetória
27

faz uso de pequenos sensores colocados sobre as partes do corpo ou

sobre o objeto (se for o caso), técnica conhecida como tracking
ativo. Neste caso são utilizadas técnicas eletromagnéticas,
ultrassônicas, mecânicas ou óticas para fazer a medida dos
movimentos.
Como alternativa, o tracking passivo utiliza câmeras ou

sensores óticos ou de inércia para monitorar o objeto e determinar
sua posição e orientação. Diferente dos dispositivos que utilizam
tracking ativo, os dispositivos de tracking passivo utilizam apenas
um sensor para rastrear o objeto.
Algumas das principais características técnicas avaliadas
para a escolha e utilização de dispositivos de rastreamento são:
• número de medidas efetuadas por segundo;
• sensibilidade a interferências externas;
• grau de ruído;
• qualidade das medidas efetuadas (taxa de erro);
• presença ou não de fios;
• área de captura.
Como exemplo do uso de dispositivos de rastreamento,

pode-se citar três tecnologias utilizadas em luvas de dados para a
localização da mão no espaço e orientação da palma da mão. A
primeira baseia-se no uso de câmeras para monitorar a luva a uma
certa distância (tracking passivo), a segunda trabalha com a
radiação de pulsos magnéticos emitidos pela luva (tracking ativo),
e a terceira baseia-se na acústica (tracking ativo), onde dispositivos
ultrassônicos transmitem a posição da mão.
a) Dispositivos de Rastreamento Mecânicos
28

Dispositivos de rastreamento mecânicos consistem de uma

série de estruturas cinemáticas que, em paralelo, são capazes de
detectar alterações da posição dos elementos aos quais se
encontram conectados. Para tanto, usam sensores associados ao
corpo do usuário. Apresentam baixas latências e são imunes à
interferência de campos magnéticos.
Tais dispositivos, no entanto, são limitados pela liberdade
de movimento do usuário, podendo dificultar o movimento dos
usuários pela dureza do material da qual são constituídos.
b) Dispositivos de Rastreamento Magnéticos

Dispositivos de rastreamento magnéticos (Figura 2.4) são
capazes de efetuar medições do campo magnético produzido por
um transmissor estacionário para determinar, em tempo real, a
posição do receptor (que está em movimento). Suas principais
características são:
• usam baixa freqüência de campos magnéticos;
• os campos são produzidos por uma fonte fixa;
• tamanho da fonte está relacionado com o tamanho da área
de captura do dispositivo;
• o receptor está associado ao objeto que está sendo rastreado
e tem três antenas perpendiculares entre si; a distância é
inferida com base nas voltagens induzidas nas antenas e
para isto uma acurada calibração deve ser efetuada.
29

Figura 2.4 -Componentes de um dispositivo de trajetória magnético

[http://www.ascencion-tech.com].
c) Dispositivos de Rastreamento Ultrassônicos

Dispositivos de rastreamento ultrassônicos não entram em
contato com o usuário e usam um sinal ultrassônico produzido por
um transmissor estacionário para determinar a posição do objeto
em tempo real em função da mudança de posição do receptor. Suas
características principais são:
• usam sinais ultrassônicos de baixa freqüência para medir

posição;
• o som é produzido por fontes fixas, dispostas
triangularmente;
• o número de fontes é proporcional à área de atuação do
dispositivo;
• o receptor é triangular e permanece preso ao objeto que
30

está sendo rastreado;

• o objeto possui três microfones;
• a distância é inferida a partir do tempo de captura do som
pelo dispositivo fixo;
• alterações na temperatura do ar e ruídos ambientes
atrapalham a medida;
• requerem a ausência de barreiras entre a fonte e o
receptor;
Em geral, dispositivos de rastreamento ultrassônicos são

mais lentos que os dispositivos magnéticos. A Figura 2.5 apresenta
o esquema básico de um dispositivo de rastreamento ultrassônico.
d) Dispositivos de Rastreamento Ópticos

Os dispositivos de rastreamento ópticos são medidores que
não exigem contato com o usuário e que utilizam sensores ópticos,
como câmeras, para determinação de posição e orientação de um
31

dado objeto. A Figura 2.6 apresenta configurações possíveis para

tais tipos de equipamentos.
2.3. Dispositivos de Saída de Dados

Os dispositivos de saída de dados são responsáveis pelo envio das
informações ao(s) usuário(s). Uma vez que sistemas de RV buscam
a exploração dos cinco sentidos, os dispositivos de saída de dados
estimulam estes sentidos através de dispositivos de rastreamento
específicos. Atualmente os sentidos mais explorados são a visão, a
audição e o tato. No entanto, pesquisas recentes já apresentam
dispositivos para estímulo do olfato [Yanagida et al, 2004] e do
paladar [Iwata et al., 2004].
2.3.1. Dispositivos Visuais

Uma grande porção do cérebro é dedicada ao
processamento e organização dos estímulos visuais. Devido a isto,
os dispositivos visuais e o tipo de imagem gerada por um sistema
de RV são fatores muito importantes na obtenção e na
determinação do nível de imersão do sistema.
32

Conforme o tipo de dispositivo utilizado, podemos ter

sistemas de RV monoscópicos ou estereoscópicos. No caso de um
sistema monoscópico, a mesma imagem será exibida para os dois
olhos: apenas uma imagem passa pelo processo de renderização e é
exibida para os dois olhos. Já no sistema estereoscópico, cada olho
verá uma imagem ligeiramente diferente, sendo necessária a
construção de um par de imagens. Neste caso é importante ressaltar
que uma característica fundamental da visão humana é que, em
função da colocação dos olhos na frente da cabeça, o campo visual
não é de 360 graus como o das aves, mas, a visão é binocular. A
visão binocular (estereoscópica) caracteriza-se pelo
reconhecimento de duas imagens obtidas por pontos de vista
diferentes, que permite uma comparação capaz de originar a
sensação de profundidade .
Um outro fator importante quanto à parte visual da RV
refere-se ao número de quadros por segundo que aparecem no
vídeo, ou seja, a velocidade da simulação. Filmes projetados para o
cinema apresentam aproximadamente 24 quadros por segundo,
enquanto os projetados para TV apresentam aproximadamente 30
quadros por segundo. Em RV, busca-se uma taxa entre 15 e 22
quadros por segundo, mas esta taxa pode variar dependendo do tipo
de interação utilizado no sistema.
Pode-se separar os dispositivos de visualização em duas
categorias:
• de visualização individual;
• de visualização coletiva.
Na primeira categoria, enquadram-se os dispositivos do tipo

vídeo-capacete (HMD – head-mounted display) e os head-coupled
displays (dispositivos que utilizam braços mecânicos para
33

permanecer diante do usuário). Na segunda categoria, temos os

monitores de computador e os sistemas de projeção.
a) Vídeo-capacetes (HMDs)
O vídeo-capacete é um dispositivo de saída de dados que
isola o usuário do mundo real. Ele é constituído basicamente de
duas minúsculas telas de TV e um conjunto de lentes especiais. As
lentes ajudam a focalizar imagens que estão a alguns milímetros
dos olhos do usuário, ajudando também a estender o campo de
visão do vídeo. O vídeocapacete funciona também como um
dispositivo de entrada de dados quando contém sensores de
rastreamento que medem a posição e orientação da cabeça
transmitindo esses dados para o computador. Neste caso, o
computador gera uma seqüência de imagens correspondentes às
ações e perspectiva do usuário. A Figura 2.7 apresenta o esquema
de um HMD.
Figura 2.7. Esquema de um vídeocapacete.

34

Mais recentemente, foram desenvolvidos vídeo-capacetes

mais leves e fáceis de vestir e estes passaram a ser chamados de
face-mounted displays. Tais dispositivos apresentam as imagens
também em pequenos displays posicionados diante dos olhos do
usuário e podem integrar um sistema de rastreamento. Sua principal
vantagem é o pequeno peso e a forma de utilização semelhante à de
óculos convencionais (Figura 2.8).
b) Head-Coupled Display
Basicamente, os head-coupled displays constituiem-se de
um display montado sobre um braço mecânico com um contra-
peso, fazendo com que o display possua “peso zero”. Sensores
ligados ao braço mecânico mais os controles presentes próximos ao
display permitem movimentos com 6DOF.
O formato do head-coupled display permite uma transição
fácil entre a visualização do mundo virtual e a interação com
teclados, monitores e outros dispositivos que possam estar
controlando a simulação. Além disso, o fato deste dispositivo
35

utilizar sensores de posição mecânicos e não eletromagnéticos

diminui o tempo de latência das imagens.
c) Monitores e Sistemas de Projeção

Dispositivos visuais baseados em monitores e sistemas de
projeção não costumam oferecer um alto nível de imersão. Neste
caso, o usuário precisa estar constantemente olhando para a tela e
utilizar algum dispositivo de entrada para fazer sua movimentação
pelo mundo virtual. Mas isso não implica que as imagens não
possam ser vistas em estéreo. Há monitores que apresentam as
imagens associadas aos olhos esquerdo e direito simultaneamente e
que dispensam o uso de óculos especiais. Trata-se dos monitores
autoestereoscópicos (Figura 2.9).
Figura 2.9. Monitor auto-estereoscópico [http://www.dti3d.com].

Outra técnica para visualização estereoscópica utiliza
óculos para filtrar as duplas de imagens geradas pelo computador.
Para isso são utilizadas técnicas específicas para apresentar as
imagens direita e esquerda para o usuário. Os óculos podem
36

também integrar um dispositivo de rastreamento que permitirá ao

computador gerar as imagens de acordo com os movimento da
cabeça do usuário. Nestes casos, as imagens são apresentadas no
monitor ou projetadas utilizando filtros ou chaves de intermitência.
Um tipo de óculos para visualização estereoscópica é o que
utiliza filtros coloridos. Nesses óculos as lentes são vermelhas e
azuis, ou vermelhas e verdes, e as imagens do par estereoscópico
são apresentadas nas mesmas cores das lentes dos óculos, o que faz
com que cada um dos olhos veja apenas uma das imagens e o
usuário tenha a noção de profundidade da cena visualizada. Outro
tipo de óculos utiliza filtros polarizados em eixos ortogonais em
conjunto com uma projeção de cada imagem, também polarizada
com o auxílio de filtros polarizadores da luz, para separação das
imagens do par estereoscópico. Um terceiro tipo de óculos utiliza
obturadores de cristal líquido que, em conjunto com um emissor
ligado à placa de vídeo do computador, permite obstruir cada lente
dos óculos em sincronia com a alternância da imagem do par
estéreo apresentada. A Figura 2.10 apresenta o esquema básico
deste tipo de equipamento, onde pode também ser observada a
combinação de óculos com sistemas de rastreamento.
37

Uma vantagem dos óculos na visualização baseada em

monitores ou sistemas de projeção é que eles permitem que várias
pessoas participem da experiência de RV.
Em sistemas de projeção as imagens podem ser projetadas
ou exibidas em uma ou várias telas, nos chamados muros de
visualização e ambientes de visualização (ou sistemas tipo CAVE).
Os muros de visualização utilizam uma única tela ou um conjunto
destas dispostas lado a lado (Figura 2.11). Já os ambientes de
projeção possuem de duas a seis telas dispostas em ângulos de 90
graus entre si que envolvem o usuário no ambiente de RV (Figura
2.12). Ambos os sistemas permitem a visualização simultânea por
várias pessoas.
2.3.2 Dispositivos Auditivos

A característica básica de equipamentos para gerar sons em
sistemas de RV é a simulação do modelo humano de audição.
Neste modelo, os dois ouvidos captam ondas sonoras provenientes
38

de todas as direções. O formato de concha do ouvido externo

capacita-o para o trabalho de coletar ondas sonoras e direcioná-las
para os vários caminhos através do canal auditivo. O cérebro então
recebe e processa as características deste som para determinar ou
localizar o local exato da fonte sonora.
Figura 2.11 – Muro de visualização utilizando projeção por

polarização [Moraes et al, 2002].
39

Os sistemas de som 3D duplicam artificialmente os

ativadores naturais que auxiliam o cérebro a localizar o som, além
de recriar eletronicamente esses efeitos em tempo-real e não devem
ser confudidos com sons estéreo. A Figura
2.13 apresenta a diferença básica entre a geração do estéreo e de
sons para ambientes virtuais.
Para a geração de som 3D, a presença de placas específicas
é indispensável. Existem diversas placas de som projetadas para
trabalhar com conjuntos de ferramentas que constroem mundos em
RV. Algumas dessas placas permitem trabalhar com diversas fontes
de som simultâneas. O método mais popular para criar e controlar
sons é o MIDI (musical instrument digital interface).
Figura 2.13 – Comparação entre som 3D Virtual e som Estéreo.
40

2.3.3. Dispositivos Físicos

Os dispositivos físicos procuram estimular as sensações
relacionadas ao tato, tensão muscular e temperatura. Diferente dos
dispositivos de saída de visão e audição, os dispositivos físicos
requerem uma sofisticada interação eletromecânica com o corpo do
usuário.
A tecnologia dos dispositivos físicos existentes não é capaz
de estimular os sentidos do usuário com a mesma qualidade de
realismo que atinge os sentidos visuais e auditivos: o problema está
além da criação de dispositivos físicos, pois envolve também a
compreensão e simulação das forças apropriadas.
a) Dispositivos Hápticos
Dispositivos hápticos são aqueles que incorporam sensores
e atuadores, permitindo o monitoramento das ações do usuário
fornecendo-lhe sensação tátil e/ou de força. A sensação tátil está
associada à natureza do contato com o objeto, como textura ou
rugosidade, enquanto a sensação de força refere-se ao senso de
posição e movimentação junto com as forças associadas ao
movimento durante a interação com um objeto [Burdea e Coiffet,
2003].
Os dispositivos hápticos que fornecem sensação de força
podem ser divididos em duas categorias básicas: fixos (ground-
based) ou móveis (body-based). Os dispositivos hápticos fixos,
como os joysticks, são aqueles que estão fisicamente atrelados a
uma plataforma ou superfície estável que permite o envio de
reações de força ao usuário. Já os dispositivos hápticos móveis
utilizam um ponto de conexão do próprio dispositivo para fornecer
a reação de força e apresentam a vantagem de poderem ser
41

portáteis na maioria das vezes, como no caso das luvas e

exoesqueletos.
A Figura 2.14 apresenta o esquema de uma luva associada a
atuadores para prover resposta de força a movimentos do usuário.
Figura 2.14 -Luva associada a atuadores

[http://www.immersion.com].
Atualmente já existe uma série de dispositivos hápticos que

permitem manipulação com retorno tátil e/ou de força. Estes
dispositivos podem permitir movimentos com diferentes graus de
liberdade, suportam e reagem com diferentes valores de força,
oferecem manipulação em um espaço limitado e utilizam
tecnologias diversas. A Figura 2.14 apresenta um dispositivo
háptico que permite movimentos com 6DOF.
42

Figura 2.15 – Dispositivo Háptico 6DOF
b) Dispositivos de resposta térmica

Outro tipo de estímulo que também pode ser fornecido por
um sistema de RV é a resposta térmica. Este tipo de resposta
caracteriza-se pelo aquecimento ou resfriamento de parte do corpo
do usuário. Tal qual os dispositivos hápticos, este efeito é ativado
durante a interação do usuário com
o sistema.
A Figura 2.16 apresenta o esquema elétrico de um
dispositivo térmico, com destaque para a presença de
semicondutores, fonte DC, receptor e fonte de calor.
43

Figura 2.16 – Esquema de um sensor térmico.
c) Plataformas móveis
As plataformas móveis também são consideradas um
dispositivo de resposta física, pois fornecem a sensação de
movimento. Normalmente, elas são utilizadas em videogames,
simuladores de vôo e simuladores de movimento. Atualmente o
treinamento de pilotos da aviação civil é realizado em simuladores
de vôo que permitem a reprodução realista de todas as etapas de um
vôo e permitem simular situações de pouso e decolagem nos
principais aeroportos do mundo, bem como situações de
emergência.
Referências
Burdea, G. e Coiffet P., Virtual Reality Technology. Addison
Wesley, 2003.
44

Iwata, H.; Yano, H.; Uemura, T e Moriya, T. (2004) “Food

Simulator”, IEEE CG&A 24(1), Emerging Technologies CD-
ROM.
Moraes, R,; Machado, L. e Souza, A. (2003) “VirtWall: A Concept
of Low-Cost Virtual Wall for Immersion in Virtual Reality”.
Proc. SVR 2003, pp. 383-385.
Netto, A.V.; Machado, L.S. e Oliveira, M.C.F., Realidade Virtual.
Visual Books, 2002.
Yanagida, Y.; Kawato, S.; Noma, H.; Tomono, A. e Tetsutani, N.
(2004) “Projection-Based Olfactory Display with Nose
Tracking”. Proc, IEEE VR 2004, pp. 43-50.
45

Capítulo
3
Técnicas de Interação para
Ambientes de Realidade Virtual e
Aumentada
Judith Kelner e Veronica Teichrieb
Grupo de Pesquisa em Realidade Virtual e Multimídia, Centro de

Informática – Universidade Federal de Pernambuco (GRVM CIn UFPE)
Av. Prof. Moraes Rego, S/N – Prédio da Positiva – 1º Andar – Cidade
Universitária – 50670-901 – Recife – PE – Brasil
{jk,vt}@cin.ufpe.br
Abstract
Software usability is highly dependent on the supported interaction
at the interface level. A number of techniques have been described
in the literature, and some of those used in the context of virtual
and augmented realities together with implementation aspects are
presented in this chapter.
Resumo
A usabilidade de um software é dependente das técnicas de
interação disponíveis na sua interface. Várias dessas técnicas
encontram-se descritas na literatura, e algumas usadas nos
ambientes de Realidade Virtual e Aumentada, com uma breve
descrição sobre sua implementação, são descritas neste capítulo.
46
3.1. Introdução
A interação entre pessoas existe desde o surgimento das primeiras
civilizações humanas. Diferentes culturas utilizaram diversas
formas para a troca de informações, numa evolução contínua que
teve início com os primeiros desenhos rupestres nas cavernas,
passando pelos sinais de fumaça, os sons dos tambores, as pinturas
nas telas, a imprensa escrita e falada, o telefone, a televisão e,
finalmente, o computador e toda parafernália tecnológica existentes
atualmente.
No contexto de interface homem-máquina, interação é a
maneira com que o usuário se comunica com a aplicação, podendo
esta comunicação ocorrer através de dispositivos ou de forma
simbólica [Schneiderman e Plaisant, 2004].
De acordo com Bowman, “interação é um método que
permite a um usuário realizar uma tarefa através da interface do
usuário. Uma técnica de interação inclui tanto componentes de
hardware (dispositivos de entrada/saída) quanto de software. As
técnicas de interação utilizadas nos componentes de software são
responsáveis por mapear a informação de um dispositivo de entrada
em alguma ação dentro do sistema, e por mapear a saída do sistema
de forma que esta possa ser interpretada pelos dispositivos de
saída” [Bowman et al., 2004].
Existe um dito popular, que não se deve adquirir um livro
apenas pela aparência da sua capa. Isto pode ser válido no contexto
dos livros, mas considerando-se software, a experiência indica que
vários usuários deixam de usar um software sofisticado por causa
de uma interface mal projetada e das dificuldades de interagir
através da mesma.
No início da era computacional, não se deu muita
importância ao processo de interação homem-máquina (HCI). A
prioridade era obter um processamento preciso dos dados. Com a
47
evolução e disseminação dos computadores pessoais cresceu a

necessidade de serem adotadas metodologias específicas para a
HCI. Os usuários não estão dispostos a consumir seu tempo
precioso com aplicações que possuam interfaces que utilizam
técnicas primárias de interação. A busca por estratégias avançadas
de interação contempla, atualmente, grande parte do tempo dos
projetistas quando se inicia o processo de desenvolvimento de um
novo software ou de um novo dispositivo.
Inúmeros são os benefícios que um bom projeto de
interação pode agregar a um software. Entre estes, podem-se citar a
usabilidade do sistema, menor curva de aprendizagem, localização
e uso de todas as potencialidades da aplicação, otimização do
tempo do usuário na busca pela informação, entre outros.
Nas aplicações que exploram o espaço bidimensional (2D)
as técnicas de HCI já estão consolidadas e incluem as comumente
encontradas nas interfaces do tipo WIMP - Windows, Icons, Menus
and Pointing Device. Através desse tipo de interação os usuários
normalmente podem gerenciar os sistemas operacionais, armazenar
e gerenciar textos, apresentações, bitmaps, áudios, vídeos, entre
outros. A interação via dispositivo de apontamento, ou
simplesmente mouse, é bastante explorada na maioria das
interfaces projetadas para desktops 2D.
De acordo com Trevisan, um dos aspectos centrais na HCI
consiste em como combinar objetos reais e virtuais dentro de um
ambiente real, de tal forma que os usuários possam realizar as suas
tarefas e interagirem simultaneamente com os objetos reais e
virtuais [Trevisan et al., 2002]. Utilizando os métodos já
consolidados de projetos de interfaces em ambientes 2D, o usuário
será levado a interagir com dois ambientes, um real e outro virtual,
o que poderá acarretar numa quebra do seu fluxo natural de
interação, quando solicitado ora a interagir com o ambiente real ora
com o mundo virtual. Como conseqüência destas dificuldades, os
48
métodos tradicionais não são válidos para projetar e avaliar

interfaces em ambientes tridimensionais (3D).
Nas aplicações de Realidade Virtual (VR) técnicas especiais
de interação que lidam com o espaço 3D são demandadas. A
interação pode ocorrer tanto no sentido usuário-aplicação, quanto
no sentido aplicação-usuário. Como exemplos desta última,
cenários virtuais utilizados em VR podem dar retorno ao usuário
através de dispositivos chamados “hápticos”. Neste caso, o usuário
sente a reação do mundo virtual e pode reagir de forma diferente
dependendo dos estímulos providos pela VR.
Ainda considerando os ambientes de VR, deve ser avaliado
se a interação será não-imersiva, ou imersiva. Para os ambientes
imersivos as técnicas de interação introduzem novos paradigmas
para o usuário, estimulando outros sentidos que normalmente não
poderiam ser explorados em ambientes não-imersivos, como por
exemplo, a visão estereoscópica [Bowman et al., 2004].
Nos ambientes de Realidade Aumentada (AR) a mudança
ainda é mais drástica, principalmente do ponto de vista do usuário,
onde os computadores tradicionais com os seus dispositivos e
interfaces já bem definidas praticamente não são mais utilizados.
Com a introdução de alguns dispositivos especializados, tais como
trackers e luvas de dados, resolvem-se problemas específicos para
algumas aplicações, mas estes dispositivos não podem ser
reutilizados ou adaptados em outras áreas de aplicação
[Broll et al., 2005].
O design de técnicas de interação visa três objetivos
principais: desempenho, usabilidade e utilidade. Desempenho diz
respeito à quão bem as atividades estão sendo realizadas pelo
usuário e pelo sistema, em cooperação, além de eficiência, precisão
e produtividade. Usabilidade trata da facilidade em informar o
sistema sobre as intenções do usuário, bem como a facilidade de
uso e de aprendizado, além do conforto do usuário. Utilidade
49
mostra que a interação ajuda o usuário a atingir os seus objetivos,

podendo focalizar na tarefa.
A próxima seção descreve as principais técnicas de
interação para interfaces 3D, apresentadas utilizando a classificação
definida por Bowman (2004) para técnicas comumente adotadas
em ambientes de VR, além de uma breve discussão sobre a
adaptação destas técnicas para ambientes de AR.
3.2. Métodos e Técnicas de Interação

Interação 3D é crucial em sistemas de VR, assim como de AR.
Nesta seção são apresentadas algumas técnicas de interação 3D que
foram, originalmente, desenvolvidas para ambientes virtuais. É
importante ressaltar que a maioria destas técnicas pode ser
adequadamente utilizada em ambientes de AR e Virtualidade
Aumentada, com poucas ou sem adaptações.
As técnicas de interação para VR foram classificadas em
quatro categorias principais, de acordo com a tarefa realizada pelo
usuário: técnicas para seleção e manipulação, para controle do
sistema, para navegação e de entrada simbólica. Esta classificação
foi definida em Bowman (2004), e tem sido amplamente aplicada
pela comunidade de interface homem-máquina.
3.2.1. Manipulação 3D
A efetividade das técnicas de manipulação 3D depende das tarefas
de manipulação para as quais elas são aplicadas. A mesma técnica
pode ser intuitiva e fácil de usar em algumas condições, porém
inadequada em outras. É necessário que a interação seja realista, o
que significa que o usuário, por exemplo, agarra e move o objeto
virtual como manipularia esses objetos no mundo real.
A tarefa de manipulação trata de seleção, ou seja,
especificar um ou mais objetos a partir de um conjunto de objetos,
para algum propósito. Além disto, o usuário especifica
50
propriedades de um objeto, como posição, orientação, escala,

forma, textura e cor. Os objetivos da seleção são consultar um
objeto, navegar até este objeto, tornar o objeto ativo e definir a
manipulação a ser realizada. Por outro lado, os objetivos da
manipulação são posicionar objetos (design de objetos,
agrupamento de objetos, layout do ambiente virtual), navegar pelo
ambiente e realizar uma determinada ação.
Muitas das técnicas de manipulação podem ser usadas em
combinação com técnicas de interação para outras tarefas, não
diretamente relacionadas com manipulação. Algo a observar é que
técnicas de manipulação preservam a forma dos objetos.
As técnicas de interação para manipulação 3D são
Apontamento, Manipulação Direta, Mundo em Miniatura,
Agregação e Integração e Manipulação 3D para Desktop. Cada
uma destas categorias possui várias técnicas associadas. As
características destas técnicas são detalhadamente descritas em
Bastos (2006).
A Figura 3.1 apresenta a ferramenta DEMEditor, uma
aplicação que permite a visualização, manipulação e edição de
superfícies 2D/3D construídas a partir de dados de sensoriamento
remoto, coletados por radar [Teichrieb e Kelner, 2004]. Esta
ferramenta utiliza a técnica Widgets 3D (descrita em
[Bastos et al., 2006]) como forma de interação com um dos objetos
que compõe o cenário, um holofote, mostrado no canto inferior
direito da figura 3.1. Quando o holofote é selecionado, o widget se
torna visível, podendo ser transladado, e sua direção ou área de
iluminação pode ser modificada. A Figura 3.1a ilustra o holofote
apagado; a caixa branca ao seu redor da Figura 3.1b, c e d significa
que o usuário selecionou o holofote e o acendeu. Os retângulos
(Figura 3.1b), círculos (Figura 3.1c) e eixos (Figura 3.1d)
vermelhos indicam que o holofote foi selecionado no modo de
translação, rotação e escala, respectivamente, de forma que o
51
mesmo pode ser transladado para qualquer lugar no ambiente

virtual, ou rotacionado em alguma direção ou escalado.
a b C d
Figura 3.1. DemEditor: técnica Widgets 3D, para
manipulação 3D de objetos em aplicações desktop.
(Imagem cortesia © Grupo de Pesquisa em Realidade
Virtual e Multimídia da Universidade Federal de
Pernambuco, 2006)
3.2.1.1. Considerações sobre Implementação

Uma questão bastante importante quando da implementação de
52
técnicas de manipulação 3D é como indicar um evento de seleção

ou manipulação. A dificuldade aumenta quando o ambiente possui
interseções entre objetos. Por isso, é importante que o sistema
forneça algum tipo de retorno para o usuário, que pode ser gráfico,
auditivo ou tátil, de forma que o mesmo saiba quando um objeto
está selecionado e pronto para ser manipulado.
Exemplos clássicos de retorno visual são o avatar da mão
virtual e o avatar caneta, que representam a mão do usuário
manipulando objetos na cena, ou então uma caneta que pode ser
usada para apontar para o objeto em questão. Uma abordagem
bastante utilizada na implementação de técnicas para manipulação
é a que especifica que o sistema possui uma lista dos objetos
selecionáveis, o que impede a seleção de objetos que não podem
ser manipulados pelo usuário.
A integração da técnica de seleção com a de manipulação
também é uma questão de implementação importante. Para iniciar a
manipulação, a seleção deve ser desabilitada, e o estado da seleção
deve ser informado durante a manipulação. Um aspecto da
especificação da interface é definir claramente o que acontece no
sistema após a manipulação.
3.2.2. Controle do Sistema

Técnicas de interação para controle do sistema servem basicamente
para modificar o estado do sistema ou o modo de interação
utilizado pelo mesmo. Normalmente, estas ações são realizadas
através de comandos disponíveis na interface. Comandos de
controle do sistema muitas vezes são integrados com outras tarefas
de interação, quando modificam o estado do sistema, ou com todas
as outras atividades de interação disponíveis no sistema, quando o
usuário os utiliza para controlar o modo de interação a ser utilizado.
Um exemplo clássico são comandos acessíveis via menus, como
salvar um arquivo, entre outros.
53
As técnicas de interação para controle do sistema são

Menus Gráficos, Comandos de Voz, Comandos de Gestos e
Ferramentas. Estas categorias possuem várias técnicas associadas e
uma descrição mais detalhada das mesmas encontra-se em
Bastos (2006).
A Figura 3.2 ilustra a utilização de menus 2D adaptados
para um cenário 3D. Neste caso, o usuário pode utilizar o menu
como está habituado a fazê-lo em aplicações 2D, para diversas
tarefas de manipulação de arquivos em um cenário 3D. A figura 3.2
apresenta um dos menus da aplicação mivaDesk
[Teixeira et al., 2007].
Figura 3.2. mivaDesk: técnica Menus 2D Adaptados, para

controle de sistemas através de menus gráficos. (Imagem
cortesia © Grupo de Pesquisa em Realidade Virtual e
Multimídia da Universidade Federal de Pernambuco, 2006)
54

A implementação das técnicas de controle do sistema deve facilitar
o foco na tarefa a ser realizada pelo usuário, evitando que sua
atenção seja desviada do objetivo inicial. Além disto, é importante
usar uma referência espacial consistente, posicionando
corretamente os comandos no ambiente virtual.
Este tipo de técnica de interação é fortemente embasado em
entrada multimodal, permitindo o uso de voz, gestos, além dos
menus gráficos posicionados na cena. A utilização destas
modalidades variadas de entrada de dados deve ser cuidadosamente
avaliada, de acordo com o domínio da aplicação e o perfil do
usuário.
3.2.3. Navegação
É sabido que movimentação física tem uma influência positiva nos
níveis de presença relatados por usuários quando da interação em
ambientes virtuais. É neste contexto que são importantes as
técnicas de interação para navegação. O usuário, ao navegar pelo
ambiente virtual, pode realizar ações como viajar (explorar) pela
cena ou procurar um caminho específico.
Ao viajar (travel), o usuário se movimenta entre dois
lugares, pela definição da posição (e orientação) do seu ponto de
vista. Através desta ação o usuário pode realizar tarefas de
exploração do ambiente virtual, de busca por algum local
específico do ambiente, e de manobra. No caso da busca, a posição
do alvo pode ou não ser conhecida; quando a posição não é
conhecida, a busca é chamada ingênua (naive), e quando é
conhecida e o usuário quer encontrar novamente um local
específico diz-se que é uma busca privilegiada (primed). Esta tarefa
de navegação é amplamente realizada nas aplicações.
A ação conhecida como wayfinding, que permite procurar
um caminho específico, visa o uso e a aquisição por parte do
55
usuário de conhecimento espacial para definir um caminho no

ambiente. O auxílio de pistas e dicas disponíveis no ambiente
virtual facilita a realização desta tarefa. Usuários possuem
habilidades de orientação diferentes, o que deve ser levado em
consideração quando da utilização de técnicas para navegação.
As técnicas de interação para navegação são Locomoção
Física, Direcionamento, Planejamento de Rotas, Baseadas em
Alvo, Manipulação Manual, Travel-by-Scaling, Orientação do
Viewpoint, Especificação da Velocidade e Controles Integrados da
Câmera para Ambientes Desktop 3D. Em Bastos (2006) encontra-
se uma descrição detalhada de cada uma destas categorias com suas
técnicas associadas, bem como suas características.
A Figura 3.3 ilustra o uso da técnica Zoomback para
navegação por um cenário de planejamento de poços de petróleo,
gerado pela ferramenta Vis-Petro [Barros et al., 2006]. Esta
navegação é realizada escolhendo o ponto de vista desejado no
botão Sel da barra de ferramentas lateral, que levará o usuário
diretamente ao local definido por aquele ponto de vista. Esta
técnica permite explorar o cenário sob diversos ângulos de
visualização; na figura 3.3 o usuário tem uma visão em perspectiva
do cenário completo.
56
Figura 3.3. Vis-Petro: técnica Zoomback, para navegação

baseada em alvo. (Imagem cortesia © Grupo de Pesquisa
em Realidade Virtual e Multimídia da Universidade Federal
de Pernambuco, 2006).

Existe uma quantidade bastante variada de técnicas de interação
para navegação, disponíveis na literatura. Por isso, a simplicidade
do uso da técnica deve ser levada em consideração; por exemplo,
técnicas baseadas no alvo são simples para se movimentar até um
objeto específico, enquanto técnicas de direcionamento são mais
apropriadas quando se deseja realizar uma busca.
3.2.4. Entrada Simbólica

Existem diversas situações onde entrada simbólica em aplicações
57
seria útil, tais como deixar uma carta, uma anotação precisa para o
projetista em um passeio arquitetônico, entrar nomes de arquivos
para operações de abrir/salvar, adicionar nomes a objetos virtuais,
especificar propriedades numéricas (por exemplo, largura e
posição) e especificar parâmetros em uma visualização científica.
Estas aplicações podem ser generalizadas em cenários que
envolvem mundos virtuais imersivos ou mundos aumentados.
Nestes mundos uma técnica comum de entrada de texto/número é
demandada (entrada via teclado, por exemplo), e uma entrada de
voz somente não seria suficiente para o usuário interagir com o
mundo.
Técnicas de entrada simbólica para interfaces 3D são
diferentes de técnicas tradicionais (por exemplo, teclado) pelas
diferenças inerentes entre interfaces 3D (não desktop) e 2D.
Plataformas móveis usam entrada baseada em caneta, na qual o
usuário escreve caracteres, símbolos ou outros gestos com uma
caneta no dispositivo. Algumas dessas técnicas já foram usadas em
interfaces 3D, utilizando este tipo de dispositivo para interação.
As técnicas de interação para entrada simbólica são
Baseadas em Teclado, Baseadas em Caneta, Baseadas em Gestos e
Baseadas na Fala. Estas categorias e suas características são
detalhadamente descritas em Bastos (2006).
A Figura 3.4 ilustra um teclado virtual que aplica a técnica
de interação Teclado Soft para entrada de texto na aplicação
mivaDesk [Teixeira et al., 2007]. O usuário interage com o mesmo
simulando o toque nas teclas de um teclado convencional
colocando o cursor controlado por um tracker sobre a tecla virtual
desejada e fazendo uma postura de seleção com uma luva.
58
Figura 3.4. mivaDesk: técnica Teclado Soft, para entrada

simbólica baseada em teclado. (Imagem cortesia © Grupo
de Pesquisa em Realidade Virtual e Multimídia da
Universidade Federal de Pernambuco, 2006).
3.2.5. Técnicas de Interação Específicas para Realidade

Aumentada
Técnicas de interação específicas para interfaces de AR foram
concebidas, a fim de aproveitar características inerentes deste tipo
de interface, tais como a possibilidade de interação do usuário tanto
com objetos virtuais quanto reais durante a utilização da aplicação,
e a mobilidade.
Atualmente, ainda não existe um consenso, na literatura,
sobre como estas técnicas de interação devam ser adequadamente
classificadas. No entanto, alguns autores publicaram propostas de
classificações, tais como Trevisan (2002), Bowman (2004) e Broll
(2005).
59
Nesta seção serão ilustradas algumas técnicas de interação

amplamente empregadas em aplicações de AR, e será traçado um
paralelo com suas classificações correspondentes em VR.
3.2.5.1. Interfaces Tangíveis

Da mesma forma que as técnicas de interação para manipulação
utilizadas em VR permitem ao usuário selecionar e manipular
objetos virtuais, em AR tem-se as interfaces tangíveis. Esta técnica
permite a manipulação de objetos virtuais através da manipulação
de objetos reais.
Em interfaces tangíveis os usuários manipulam objetos
físicos, ferramentas, superfícies ou espaços para interagir com as
aplicações. A forma como os usuários manipulam os objetos reais é
natural e intuitiva. Em sistemas de AR, os objetos físicos são
mapeados usando-se uma função um-para-um com operações sobre
objetos virtuais.
Para ilustrar, pode-se assumir como exemplo uma aplicação
que disponibiliza um serviço de leilão virtual no qual o usuário
interage utilizando um cubo tangível [Teichrieb et al., 2007]. Em
leilões reais o arrematador provavelmente desejará ver o lote ou
alguns de seus itens antes de finalizar o processo de compra. Ele se
sentirá confortável se for possível tocar os objetos com as mãos e
observar todos os seus detalhes.
Dessa forma, o serviço de leilão virtual foi desenvolvido
permitindo ao usuário interagir com os itens do lote a ser leiloado,
visualizando os mesmos em 360°, além de ser possível escalar os
objetos para uma visualização mais detalhada, se for o caso.
Rotacionando um cubo de marcadores em sentido horário, o objeto
é escalado até o valor mais alto definido na aplicação, e para
reduzir seu tamanho o usuário gira em sentido anti-horário. A
Figura 3.5 ilustra o usuário manipulando um item do lote,
utilizando para isso um cubo tangível cujas faces são marcadores
60
fiduciais.
Figura 3.5. Interface tangível para manipulação de objetos.

(Imagem cortesia © Grupo de Pesquisa em Realidade
Virtual e Multimídia da Universidade Federal de
Pernambuco, 2007)
3.2.5.2. Interfaces Baseadas em Gestos

Este tipo de interface usa como entrada gesticulações espontâneas
do usuário, mímicas e gestos simbólicos. Um exemplo que ilustra
esta técnica, quando baseada em posturas (gestos estáticos), é uma
aplicação onde o usuário veste um wearable computer e uma luva
para interagir com a aplicação.
A interação ocorre realizando diferentes posturas pré-
definidas para desempenhar tarefas, tais como abrir e fechar a mão
(Figura 3.6). Gestos são identificados pelo uso de uma luva, que
detecta diferentes níveis de pressão para todos os dedos, e um
tracker. A combinação da ativação de sensores de um ou mais
61
dedos se configura num gesto, controlando algum aspecto da

aplicação.
Figura 3.6. Interface baseada em gestos para controle do

sistema. (Imagem cortesia © Grupo de Pesquisa em
Realidade Virtual e Multimídia da Universidade Federal de
Pernambuco, 2006).
3.2.5.3. Walking
A técnica Walking simplesmente prevê o andar físico através do
mundo 3D, sendo bastante natural para o usuário. Ela é classificada
como uma técnica de interação para navegação em ambientes de
VR, mas mostra-se muito adequada para aplicações móveis de AR.
Um aspecto importante a considerar é o fornecimento de
avisos que auxiliem no equilíbrio do usuário durante a caminhada,
de forma a promover entendimento espacial. O caminhar no mundo
real não é sempre prático ou factível, uma vez que é limitado por
obstáculos espaciais e tecnológicos. Além disto, a margem de
movimentação do usuário é diretamente dependente da tecnologia
de tracking utilizada.
Um exemplo que ilustra o uso desta técnica de interação é
uma aplicação de AR que permite ao usuário visitar a galeria de
arte de um museu virtual. Para isto, o usuário veste um wearable
computer (com um Head Mounted Display translúcido para
visualização e uma luva com tracker para interação) e caminha por
um espaço físico [Teixeira et al., 2007]. Uma vez tendo marcadores
fiduciais no seu campo de visão, a aplicação reconhece os mesmos
62
e exibe as obras de arte virtuais na cena. A Figura 3.7 ilustra o

usuário andando fisicamente pelo ambiente.
Figura 3.7. Técnica Walking para navegação. (Imagem

cortesia © Grupo de Pesquisa em Realidade Virtual e
Multimídia da Universidade Federal de Pernambuco, 2006).
3.2.5.4. Reconhecimento de Gestos Pen-Stroke

Esta técnica reconhece o movimento de uma caneta, por exemplo,
sobre a tela touch-screen de um handheld ou smartphone
(Figura 3.8). Com o uso crescente de dispositivos móveis em
aplicações de AR, esta técnica, classificada como técnica para
entrada simbólica em ambientes virtuais, tem sido amplamente
utilizada em AR.
63
Figura 3.8. Técnica Reconhecimento de Gestos Pen-Stroke

para entrada simbólica. (Imagem cortesia © Grupo de
Pesquisa em Realidade Virtual e Multimídia da
Universidade Federal de Pernambuco, 2006).
3.3. Considerações Finais

Este capítulo apresentou alguns conceitos relativos a técnicas de
interação para ambientes 3D, descrevendo questões relacionadas ao
design e implementação de técnicas utilizadas em VR e AR. O
intuito do que foi exposto é contribuir para uma difusão do
conhecimento em áreas onde a literatura ainda é escassa, e ilustrar
através de alguns cenários que é plenamente possível adaptar as
técnicas já utilizadas em VR para ambientes aumentados.
3.4 Referências Bibliográficas

Schneiderman, B. e Plaisant, C., Designing the User Interface:
Strategies for Effective Human-Computer Interaction, Addison-
Wesley Publishers, 2004.
64
Bowman, D. A., Kruijff, E., LaViola Jr, J. J. e Poupyrev, I., 3D

User Interfaces: Theory and Practice, Addison-Wesley, 2004.
Trevisan, D. G., Vanderdonckt, J. e Macq, B. (2002) “Analyzing
Interaction in Augmented Reality Systems”, ACM Multimedia
International Workshop on Immersive Telepresence, p. 56-53.
Broll, W., Lindt, I., Ohlenburg, J., Herbst, I., Wittkämper, M. e
Novotny, T. (2005) “An Infrastructure for Realizing Custom-
Tailored Augmented Reality User Interfaces”, IEEE
Transactions on Visualization and Computer Graphics, v. 11, n.
6, p. 722-733.
Bastos, N. C., Teichrieb, V. e Kelner, J., Interação com Realidade
Virtual e Aumentada, SBC, 2006.
Teichrieb, V. e Kelner, J. (2004) “DEMEditor: a Virtual Reality
System to Enhance the Precision of Digital Elevation Models”,
American Society for Photogrammetry & Remote Sensing,
Maryland, American Society for Photogrammetry & Remote
Sensing, p. 228-236.
Teixeira, J., Silva, D., Moura, G., Costa, L., Teichrieb, V. e Kelner,
J. (2007) “miva: Constructing a Wearable Platform Prototype”,
Symposium on Virtual and Augmented Reality.
Barros, P., Pessoa, D., Leite, P., Farias, R., Teichrieb, V. e Kelner,
J. (2006) “Three-Dimensional Oil Well Planning in Ultra-Deep
Water”, Symposium on Virtual Reality, Porto Alegre, Sociedade
Brasileira de Computação, p. 285-296.
Teichrieb, V., Gomes Neto, S., Farias, T., Teixeira, J., Lima, J.,
Almeida, G. e Kelner, J. (2007) “Augmented Ambient: an
Interactive Mobility Scenario”, HCI International.
65
PARTE 2
Tecnologias de
Desenvolvimento
Capítulo
4
VRML e X3D
Alexandre Cardoso1, Luciano Pereira Soares2 e Marcelo K. Zuffo2
1
alexandre@ufu.br
2
Universidade de São Paulo – USP
LSI – Laboratório de Sistemas Integraveis
lsoares@lsi.usp.br, mkzuffo@lsi.usp.br
4 RV suportada pelas tecnologias VMRL e X3D
4.1 Introdução
VRML tem uma história fundamentada na colaboração de
diversos pesquisadores e importantes empresas relacionadas com a
Computação Gráfica e Realidade Virtual.
O Scenario nasce a partir de um projeto, iniciado em 1989,
na Silicon Graphics Inc. por Rikk Carey e Paul Strass,
fundamentada em duas características básicas: capacidade de
66
criação de uma gama variada de aplicações 3D e a possibilidade de

usar este ambiente para construir uma nova interface para 3D.
Em 1992, baseado nas proposições do Scenario, surge o Iris
Inventor 3D, uma ferramenta fundamentada em C++ que,
posteriormente, fundamenta muito da semântica de VRML. A
revisão do Inventor realizada em 1994 origina o Open Inventor
caracterizada por sua portabilidade a uma grande variedade de
plataformas e baseada no Open GL da Silicon. O manual de
referência da mesma descrevia os objetos e formatos de arquivos
que, adequados por Gavin Bell, originariam a especificação da
primeira versão da Virtual Reality Modeling Language, VRML 1.0.
Em 1994, Mark Pesce e Tony Parisi construíram um
protótipo de um navegador 3D para a World Wide Web - WWW,
chamado Labyrinth. Um ano depois, Mark e Brian Behlendorf
criaram a lista de discussão do VRML e publicaram uma chamada
para propostas de uma especificação formal para 3D na WWW.
De discussões nesta lista, iniciadas por Gavin BellI, usando
como ponto de partida o manual do Inventor nasce a especificação
do VRML 1.0. Em 1995, o VRML 1.0 foi alvo de muitas correções
e novas discussões, de forma que nasce a proposta de uma segunda
especificação, a do VRML 1.1 (ou VRML 2.0).
Aprimorada e capaz de definir comportamentos (com mais
interação e animação) para elementos 3D, a nova proposição foi
67
submetida à lista em 1996. As propostas apresentadas pela Silicon

em colaboração com a Sony e com a Mitra receberam a grande
maioria dos votos e originaram o documento de definição de
VRML 2.0. Em agosto de 1996, esta versão foi publicada no
SIGGRAPH´96 em New Orleans.
A versão final deste texto, com correções e modificações
técnicas foi publicada em Abril de 1997, definida como VRML´97.
Suas principais características estão relacionadas com o
desenvolvimento de cenários mais realísticos, prototipação
(capacidade de encapsular novos recursos de forma a criar novos
nós), interação direta com o usuário através de sensores,
interpoladores e criação de animações usando scripts.
Desde então, VRML (Virtual Reality Modeling Language)
tem sido aplicada em diversos projetos para concepção de mundos
virtuais [ELLIS 1994, CHEN 1997, MATSUBA 1999, CARDOSO
et al. 1999] e é uma importante aliada no desenvolvimento de
mundos tridimensionais interativos na Web.
4.1.1 VRML97
Arquivos que simulam ambientes tridimensionais em
VRML, são na verdade uma descrição textual, na forma de textos
ASCii. Por meio de qualquer processador de textos, o
desenvolvedor pode conceber tais arquivos, salvá-los e visualizar
68
resultados no navegador de Internet associado a um plug-in

interpretador de VRML. Estes arquivos definem como estão as
formas geométricas, as cores, as associações, os movimentos,
enfim, todos os aspectos relacionados com a idéia do autor [AMES
1997]. Quando um dado navegador - browser - lê um arquivo com
a extensão .wrl, o mesmo constrói o cenário descrito, usando os
recursos do plug-in compatível.
De forma simplificada, um arquivo VRML se caracteriza
por quatro elementos principais:
• Header – obrigatório;
• Prototypes – usado para descrever classes de objetos que

podem ser usados na descrição do cenário;
• Shapes, Interpolators, Sensors, Scripts – usados para

descreverem o cenário que se deseja construir;
• Routes – rotas: essenciais na definição de comportamento

dos objetos que estão descritos no cenário.
Nem todos os arquivos contêm todos estes componentes. Na

verdade o único item obrigatório em qualquer arquivo VRML é o
cabeçalho (header). Porém, sem pelo menos uma figura, o
navegador não exibirá nada ao ler o arquivo. Outros componentes
que um arquivo VRML também pode conter:
69
• Comments;
• Nodes;
• Fields, field values;
• Defined node names;
• Used node names;
O cabeçalho (header) é composto pela instrução "#VRML

V2.0 utf8" e sua omissão impossibilita o plug-in do navegador de
ler o arquivo em questão. Os protótipos (proto) contém a definição
de novos nós que podem ser usados no arquivo em definição. A
seção de descrição de formas (shapes etc) apresenta a descrição das
formas que serão exibidas no navegador e a seção de rotas (routes)
contém a definição das trocas de mensagens entre os nós de
descrição de formas, interpoladores, sensores e scripts.
A concepção de cenários tridimensionais, usando VRML, se
baseia na elaboração de uma grafo direcionado acíclico, contendo
diferentes ramos - nós - que, associados de forma correta podem ser
agrupados ou estarem independentes uns dos outros. A grande
diversidade destes nós (54 pré-definidos), incluindo primitivas
geométricas, propriedades de aparência, sons (e propriedades) e
vários tipos de nós de agrupamentos, é uma das principais
características e qualidades da linguagem.
70
É permitida reutilização de código através da prototipação,

baseada na definição de novos nós (protos) que podem ser
utilizados por outros arquivos e ativados dentro de um arquivo
como um nó externo, sem duplicação de códigos. Ou senão, ser
reconhecido internamente pelo navegador utilizado.
A concepção de formas se dá através da associação de
elementos 3D geométricos pré-definidos, tais como Cones,
Cilindros, Esferas, Caixas, etc que possuem atributos variáveis e
que podem estar associados a texturas.
A modificação de fundos de ambiente está possibilitada
pelo uso de nós específicos - backgrounds, - que permitem simular
ambientes diferenciados que se assemelham a condições que
variam de um lindo dia de sol, um dia nublado ou com muita
neblina até a noites.
É possível o controle de aparência de elementos do cenário,
bem como a inserção de diferentes formas de fontes de luz
(pontuais, direcionais, ambiente), visando dar mais realismo ao
cenário concebido. Recursos de acrescentar sons e filmes também
estão disponíveis por utilização de nós específicos e são
compatíveis com os principais formatos de áudio e vídeo: .mpeg,
.mpg, .mid., .wav.
Podem ser elaborados scripts que facilitam as animações
utilizando-se Java ou JavaScript de forma a complementar a troca
71
de informações entre os elementos do mundo virtual. Esta

propriedade provê possibilidade de animações e de dinamismo às
formas concebidas e inseridas no cenário. O código em JavaScript
pode fazer parte do arquivo original.
4.1.2 X3D
O X3D é um padrão aberto para distribuir conteúdos de
realidade virtual em 3D, em especial pela Internet. Ele combina
tanto dados geométricos como descrições de comportamentos
instantâneos em um simples arquivo que tem inúmeros formatos de
transmissão, sendo que o padrão de codificação ideal é o XML
(Extensible Markup Language). O X3D é a próxima revisão da
especificação ISO VRML97, incorporando os avanços dos recursos
disponíveis nos últimos dispositivos gráficos comerciais tanto
quanto melhoras na sua arquitetura baseado nos anos de retorno da
comunidade de desenvolvimento do VRML97. Este padrão esta
sendo desenvolvido por um consórcio internacional, conhecido
como Web3D, que tem o objetivo de propor e manter o padrão, e
manter ele como um sistema aberto para a comunidade.
O X3D pode ser utilizado para Modelagem e animação,
interação, interoperabilidade com outras tecnologias da web,
treinamento, visualização científica, suporte a vendas, etc.
72
O XML foi adotado como sintaxe para o X3D para resolver

um grande número de problemas reais, A sintaxe do VRML 97 é
estranha para todos com exceção da comunidade do VRML. Ela é
similar a sintaxe do grafo de cena do Open Inventor, na qual foi
baseada e algumas notações de objetos. Todavia, a sintaxe
dominante na Web atualmente é o XML. Linguagens de marcações
têm provado ser a melhor solução para o problema de um longo
ciclo de vida de arquivamento de dados.
Integração baseada em páginas XML vai direto ao problema
de manter o sistema mais simples, assim mais pessoas podem
desenvolver páginas web, tanto em conteúdo como
implementações. Extensível suporte ao XML é esperado na última
versão do Mozilla e do Internet Explorer. O X3D, como um
formato que define informações visuais, é tipicamente o último
estágio em uma linha de produção. Usando um conjunto de
ferramentas disponíveis, como stylesheets, você pode trabalhar em
qualquer formato nativo XML que você queira, e ver que uma
representação 3D é tão trivial quanto um processo de
transformação.
Existe uma Document Type Definition (DTD) para X3D,
definida como parte do padrão. A URL do DTD é:
http://www.web3d.org/specifications/x3d-3.0.dtd. Também existe
um Schema para X3D aceito. Ele é definido como parte do padrão.
73
A URL do Schema é: http://www.web3d.org/specifications/x3d-

3.0.xsd.
O X3D é um padrão aberto que não tem royalties associados
com ele - você pode usar livremente aonde você quiser. Não existe
nenhuma política de limite de Propriedade Intelectual para a
tecnologia, além de existir um acordo com a ISO para publicar a
especificação para o público sem nenhum custo.
Existe um esforço para um programa de conformidade para
a especificação do X3D que tem o objetivo de prover consistência e
confiabilidade para as implementações que suportem X3D pelos
diversos vendedores das múltiplas plataformas, e para criar uma
definição objetiva de conformidade com o padrão X3D. Somente
produtos que passe pela conformidade poderá usar a marca
registrada X3D.
Profiles e components são as novas formas do X3D de
definir ambas, extensibilidade e o conjunto de serviços que o
conteúdo dos usuários necessita. Um componente (component)
define uma específica coleção de nós. Tipicamente esta coleção
tem em comum um conjunto de funcionalidades - por exemplo a
estruturas NURBS e as habilidades de texturização. Um
componente (component) consiste da definição dos nós e um
conjunto de níveis que prove um cada vez maior conjunto de
implementações. Um nível simples requer apenas poucos nós e
74
talvez uma seleção de campos a serem suportados, enquanto que

níveis maiores requerem todos os níveis mais simples, mais nós
mais complexos.
Por exemplo, o nível 1 de NURBS requer apenas linhas e
curvas 2D básicas, enquanto que o nível 4 requer, costura, junção e
superfícies de revolução. Um perfil (profile) é uma coleção de
componentes para um específico nível de suporte, conforme figura
4.1. Um perfil (profile) pode não conter outro perfil, porém ele
necessita todos os mesmos componentes (components) e níveis
como outro perfil (profile), e ainda mais. Todos os arquivos X3D
requerem a definição do perfil (profile) que está em uso, na qual
pode ser suprida com a requisição de componentes adicionais pelo
usuário - ou por níveis maiores que aqueles providos pelo perfil
(profile) ou que ainda não foram definidos no perfile (profile).
Empresas podem criar novos componentes com suporte para seus
produtos e submetê-los para a diretoria do X3D para sua
aprovação.
Quando um componente é submetido, este contém um
prefixo para a empresa que submete o componente similar como as
extensões OpenGL que têm o prefixo da empresa que criou a
extensão. Componentes vão sofrer os testes e revisões pela diretoria
do X3D, o Consórcio Web3D e a comunidade como um todo. Uma
vez que um componente seja aceito e implementado por mais de
75
uma empresa, o prefixo muda para EXT_. Se o componente é

classificado pela diretoria, ele então recebe o prefixo X3D_. A
diretoria pode julgar que certos componentes são tão largamente
adotados e importantes que deveriam ser incluídos em um conjunto
de modificações para a especificação ISO oficial. Uma vez que um
grupo de componentes (components) e/ou perfils (profiles) são
julgados importantes para a inclusão através das várias aplicações,
uma nova versão do X3D pode ser criada incluindo, por padrão, um
conjunto de perfis (profiles).
Uma nova versão implica mais funcionalidade que as
versões anteriores. Empresas podem criar navegadores,
ferramentas, importadores e exportadores X3D na qual suportam
diferentes versões, perfils (profiles) e componentes (components).
Por exemplo, um exportador para o 3DSMax que é usado nos
ambientes de produção de video-games pode suportar somente o
perfil Interchange, enquanto que um plug-in para navegador da
Internet pode suportar o perfil Immersive ou Full.
As empresas não precisam suportar todos os Profiles,
Components e Levels. Perfis e componentes existem para que as
empresas precisem somente suportar perfis e componentes para
suas necessidades. Por ter perfis, seus produtos podem ter certeza
que o conteúdo que eles lerem irá funcionar nas suas aplicações, e
que aquele conteúdo que eles criaram irá funcionar em outras
76
aplicações que suportem seus componentes ou perfis. Muitas

empresas não vão querer suportar uma especificação grande e
complexa como o VRML97. Porém a estrutura modular do X3D
significa que eles podem começar suportando perfis (profiles) e
componentes (components) simples, e gradualmente adicionar
perfis adicionais conforme eles se sentirem preparados. Por haver
empresas capazes de desenvolver componentes e submetê-los, o
X3D força os avanços da indústria a serem rápidos e eficientes. Isto
também garante que o X3D crescerá e florescerá, e não se tornará
tecnicamente obsoleto, como o padrão anterior se tornou.
Figura 4-1 – Diagrama de Profiles.
77
4.2 Grafo de Cena
4.2.1 Definições básicas

A concepção de ambientes 3D deve começar pela definição
de uma hierarquia e de seus componentes. Como exemplo, para a
construção de um avião, suas partes devem ser definidas e
agrupadas, hierarquicamente, através de um grafo de cena, como
pode ser visto na Figura 4-2.
Um nó é um componente construtivo do grafo de cena. No
caso da Figura 4-2, cada asa será um nó. Os nós podem ser outros
grafos de cena e, sucessivamente, definirem como cada instância
primitiva será usada para montar o cenário final.
Figura 4-2 - Grafo de Cena para uma aeronave simples
78
Assim, a construção dos grafos de cena requer a união,

usando a estrutura de árvores ou de grafos direcionados acíclicos –
DAG – de primitivas gráficas. Cada componente do cenário final
será uma associação de primitivas, que, no grafo de cena representa
um nó. Neste contexto, é muito importante o conhecimento das
primitivas disponibilizadas pela linguagem.
Cada primitiva Shape está associada a dois nós
(necessariamente):
- nó aparência: que descreve a aparência final da
forma;
- nó geometria: usado para definir a geometria da
forma.
Estruturalmente, a sintaxe dos nós em VRML e X3D que
permite acomodar a definição das primitivas tem, portanto, o
aspecto:
Forma Geométrica {
Definição da aparência {}
Definição da geometria{}
}
A seção seguinte apresenta alguns nós e suas definições.
79
4.2.2 Atributos
Os atributos declarados em cada nós podem conter um valor
simples ou múltiplos, isto é definido pelas duas primeiras letras.
Caso o tipo do atributo comece com SF (Single Field) somente
suportará um valor, caso seja MF (Multiple Fields), este suportara
vários valores. Estes também podém se referenciar outros nós com
o tipo abstrato básico SFNode and MFNode.
Dentre os tipos básicos de atributos temos:
Bool - para valores booleanos
Color - para a descrição de RGB de uma dada cor
ColorRGBA- para a descrição de RGBA de uma dada
cor
Double – para valores reais com altíssima precisão
Image – para imagem
Int32 - para valores inteiros
FLoat - para valores reais
Node - para a descrição de um nó
Rotation – para os valores de uma rotação
String – para um texto
Time – para um valor de tempo
Vec2d, Vec2f – para um vetor de 2 elementos de alta e
menor precisão
80
Vec3d, Vec3f – para um vetor de 3 elementos de alta e

menor precisão
4.2.3 Nós em VRML e X3D

• Geometrias
Box : X3DGeometryNode {
SFNode [in,out] metadata NULL [X3DMetadataObject]
SFVec3f [] size 2 2 2 (0,∞ )
SFBool [] solid TRUE
}
Figura 4-3 — Nó Caixa.
Cone : X3DGeometryNode {
SFBool [] bottom TRUE
SFFloat [] bottomRadius 1 (0,∞ )
SFFloat [] height 2 (0,∞ )
SFBool [] side TRUE
}
81
Figura 4-4 – Nó Cone

Cylinder : X3DGeometryNode {
SFBool [] bottom TRUE
SFFloat [] height 2 (0,∞ )
SFFloat [] radius 1 (0,∞ )
SFBool [] side TRUE
SFBool [] top TRUE
82
}
Figura 4-5 – Nó Cilindro
ElevationGrid : X3DGeometryNode {
MFFloat [in] set_height
SFNode [in,out] color NULL [X3DColorNode]
SFNode [in,out] normal NULL [X3DNormalNode]
SFNode [in,out] texCoord NULL [X3DTextureCoordinateNode]
SFBool [] ccw TRUE
SFBool [] colorPerVertex TRUE
SFFloat [] creaseAngle 0 [0,∞ )
MFFloat [] height [] (-∞ ,∞ )
SFBool [] normalPerVertex TRUE
SFInt32 [] xDimension 0 [0,∞ )
SFFloat [] xSpacing 1.0 (0,∞ )
SFInt32 [] zDimension 0 [0,∞ )
SFFloat [] zSpacing 1.0 (0,∞ )
83
}
Figura 4-6 – Nó ElevationGrid
Extrusion : X3DGeometryNode {
MFVec2f [in] set_crossSection
MFRotation [in] set_orientation
MFVec2f [in] set_scale
MFVec3f [in] set_spine
SFBool [] beginCap TRUE
SFBool [] ccw TRUE
SFBool [] convex TRUE
MFVec2f [] crossSection [1 1 1 -1 -1 -1 -1 1 1 1] (-∞ ,∞ )
SFBool [] endCap TRUE
MFRotation [] orientation 0 0 1 0 [-1,1] or (-∞ ,∞ )
MFVec2f [] scale 11 (0,∞ )
MFVec3f [] spine [0 0 0 0 1 0] (-∞ ,∞ )
}
IndexedFaceSet : X3DComposedGeometryNode {
MFInt32 [in] set_colorIndex
MFInt32 [in] set_coordIndex
MFInt32 [in] set_normalIndex
84
MFInt32 [in] set_texCoordIndex

SFNode [in,out] coord NULL [X3DCoordinateNode]
SFNode [in,out] normal NULL [X3DNormalNode]
SFNode [in,out] texCoord NULL [X3DTextureCoordinateNode]
SFBool [] ccw TRUE
MFInt32 [] colorIndex [] [0,∞ ) or -1
SFBool [] convex TRUE
MFInt32 [] coordIndex [] [0,∞ ) or -1
MFInt32 [] normalIndex [] [0,∞ ) or -1
SFBool [] normalPerVertex TRUE
MFInt32 [] texCoordIndex [] [-1,∞ )
}
Figure 4.7 — IndexedFaceSet texture default mapping
85
Figure 4.8 — ImageTexture for IndexedFaceSet in Figure 13.6
Sphere : X3DGeometryNode {
SFFloat [] radius 1 (0,∞ )
}
Figura 4-9 – Nó Esfera

IndexedLineSet : X3DGeometryNode {
MFInt32 [in] set_colorIndex
MFInt32 [in] set_coordIndex
MFInt32 [] colorIndex [] [0,∞ ) or -1
86
MFInt32 [] coordIndex [] [0,∞ ) or -1

}
PointSet : X3DGeometryNode {
}
Text : X3DGeometryNode {
SFNode [in,out] fontStyle NULL [X3FontSyleNode]
MFFloat [in,out] length [] [0,∞ )
SFFloat [in,out] maxExtent 0.0 [0,∞ )
MFString [in,out] string []
SFBool [] solid FALSE
}
Group : X3DGroupingNode {
MFNode [in] addChildren [X3DChildNode]
MFNode [in] removeChildren [X3DChildNode]
MFNode [in,out] children [] [X3DChildNode]
SFVec3f [] bboxCenter 000 (-∞ ,∞ )
SFVec3f [] bboxSize -1 -1 -1 [0,∞ ) or − 1 − 1 − 1
}
Transform : X3DGroupingNode {
SFVec3f [in,out] center 000 (-∞ ,∞ )
87
SFRotation [in,out] rotation 0 0 1 0 [-1,1] or (-∞ ,∞ )

SFVec3f [in,out] scale 111 (0,∞ )
SFRotation [in,out] scaleOrientation 0 0 1 0 [-1,1] or (-∞ ,∞ )
SFVec3f [in,out] translation 000 (-∞ ,∞ )
}
Shape : X3DShapeNode {
SFNode [in,out] appearance NULL [X3DAppearanceNode]
SFNode [in,out] geometry NULL [X3DGeometryNode]
SFVec3f [] bboxCenter 0 0 0 (-∞ ,∞ )
}
Appearance : X3DAppearanceNode {
SFNode [in,out] fillProperties NULL [FillProperties]
SFNode [in,out] lineProperties NULL [LineProperties]
SFNode [in,out] material NULL [X3DMaterialNode]
SFNode [in,out] texture NULL [X3DTextureNode]
SFNode [in,out] textureTransform NULL [X3DTextureTransformNode]
}
Material : X3DMaterialNode {
SFFloat [in,out] ambientIntensity 0.2 [0,1]
SFColor [in,out] diffuseColor 0.8 0.8 0.8 [0,1]
SFColor [in,out] emissiveColor 000 [0,1]
88
SFFloat [in,out] shininess 0.2 [0,1]

SFColor [in,out] specularColor 000 [0,1]
SFFloat [in,out] transparency 0 [0,1]
}
Inline : X3DChildNode, X3DBoundedObject, X3DUrlObject {

SFBool [in,out] load TRUE
MFString [in,out] url [] [url or urn]
SFVec3f [] bboxCenter 0 0 0 (-∞ ,∞ )
}
Background : X3DBackgroundNode {
SFBool [in] set_bind
MFFloat [in,out] groundAngle [] [0,π/2]
MFColor [in,out] groundColor [] [0,1]
MFString [in,out] backUrl [] [urn]
MFString [in,out] bottomUrl [] [urn]
MFString [in,out] frontUrl [] [urn]
MFString [in,out] leftUrl [] [urn]
MFString [in,out] rightUrl [] [urn]
MFString [in,out] topUrl [] [urn]
MFFloat [in,out] skyAngle [] [0,π]
MFColor [in,out] skyColor 0 0 0 [0,1]
SFTime [out] bindTime
SFBool [out] isBound
}
89
DirectionalLight : X3DLightNode {
SFFloat [in,out] ambientIntensity 0 [0,1]
SFColor [in,out] color 1 1 1 [0,1]
SFVec3f [in,out] direction 0 0 -1 (-∞ ,∞ )
SFFloat [in,out] intensity 1 [0,1]
SFBool [in,out] on TRUE
}
PointLight : X3DLightNode {
SFVec3f [in,out] attenuation 1 0 0 [0,∞ )
SFColor [in,out] color 1 1 1 [0,1]
SFVec3f [in,out] location 0 0 0 (-∞ ,∞ )
SFFloat [in,out] radius 100 [0,∞ )
}
SpotLight : X3DLightNode {
SFVec3f [in,out] attenuation 100 [0,∞ )
SFFloat [in,out] beamWidth π/2 (0,π/2]
SFColor [in,out] color 111 [0,1]
SFFloat [in,out] cutOffAngle π/4 (0,π/2]
SFVec3f [in,out] direction 0 0 -1 (-∞ ,∞ )
SFVec3f [in,out] location 000 (-∞ ,∞ )
90

SFFloat [in,out] radius 100 [0,∞ )
}
As definições se assemelham às da PointLight. Os demais elementos podem ser

vistos na Figura 4-10 - Elementos de SpotLight, onde apresenta-se, graficamente, os
elementos que compõem o nó em questão.
Figura 4-10 - Elementos de SpotLight
LOD : X3DGroupingNode {
SFVec3f [] center 000 (-∞ ,∞ )
MFFloat [] range [] [0,∞ ) or -1
}
AudioClip : X3DSoundSourceNode, X3DUrlObject {

SFString [in,out] description ""
SFBool [in,out] loop FALSE
91

SFTime [in,out] pauseTime 0 (-∞ ,∞ )
SFFloat [in,out] pitch 1.0 (0,∞ )
SFTime [in,out] resumeTime 0 (-∞ ,∞ )
SFTime [in,out] startTime 0 (-∞ ,∞ )
SFTime [in,out] stopTime 0 (-∞ ,∞ )
MFString [in,out] url [] [urn]
SFTime [out] duration_changed
SFTime [out] elapsedTime
SFBool [out] isActive
SFBool [out] isPaused
}
Sound : X3DSoundNode {
SFVec3f [in,out] direction 0 0 1 (-∞ ,∞ )
SFVec3f [in,out] location 0 0 0 (-∞ ,∞ )
SFFloat [in,out] maxBack 10 [0,∞ )
SFFloat [in,out] maxFront 10 [0,∞ )
SFFloat [in,out] minBack 1 [0,∞ )
SFFloat [in,out] minFront 1 [0,∞ )
SFFloat [in,out] priority 0 [0,1]
SFNode [in,out] source NULL [X3DSoundSourceNode]
SFBool [] spatialize TRUE
}
Os elementos do nó Sound podem ser vistos na Figura 4-11 - Elementos do nó
Sound.
92
Figura 4-11 - Elementos do nó Sound
ImageTexture : X3DTexture2DNode {
SFBool [] repeatS TRUE
SFBool [] repeatT TRUE
}
MovieTexture : X3DTexture2DNode, X3DSoundSourceNode, X3DUrlObject {

SFTime [in,out] resumeTime 0 (-∞ ,∞ )
SFFloat [in,out] speed 1.0 (-∞ ,∞ )
SFBool [] repeatS TRUE
SFBool [] repeatT TRUE
SFTime [out] duration_changed
93
TimeSensor : X3DTimeDependentNode, X3DSensorNode {

SFTime [in,out] cycleInterval 1 (0,∞ )
SFBool [in,out] enabled TRUE
SFTime [in,out] resumeTime 0
SFTime [out] cycleTime
SFFloat [out] fraction_changed
SFTime [out] time
}
A Figura 4-12 - Elementos do nó TimeSensor apresenta os elementos do nó
TimeSensor. É importante destacar que o tempo é sempre uma fração do valor máximo
(que é sempre 1.0). Assim, quando define-se que o intervalo de tempo (cycleInterval) será
de 10.0 s, em 2 s teremos o tempo relativo à fração 0.2.
Figura 4-12 - Elementos do nó TimeSensor
94
PositionInterpolator : X3DInterpolatorNode {
SFFloat [in] set_fraction (-∞ ,∞ )
MFFloat [in,out] key [] (-∞ ,∞ )
MFVec3f [in,out] keyValue [] (-∞ ,∞ )
SFVec3f [out] value_changed
}
OrientationInterpolator : X3DInterpolatorNode {
MFRotation [in,out] keyValue [] [-1,1] or (-∞ ,∞ )
SFRotation [out] value_changed
}
ScalarInterpolator : X3DInterpolatorNode {
MFFloat [in,out] keyValue [] (-∞ ,∞ )
SFFloat [out] value_changed
}
NavigationInfo : X3DBindableNode {
MFFloat [in,out] avatarSize [0.25 1.6 0.75] [0,∞ )
SFBool [in,out] headlight TRUE
SFFloat [in,out] speed 1.0 [0,∞ )
95
MFString [in,out] transitionType [LINEAR] ["TELEPORT" "LINEAR"

"ANIMATE"]
MFString [in,out] type ["EXAMINE" "ANY"]
SFFloat [in,out] visibilityLimit 0.0 [0,∞ )
}
Viewpoint : X3DBindableNode {
SFVec3f [in,out] centerOfRotation 0 0 0 (-∞ ,∞ )
SFFloat [in,out] fieldOfView π/4 (0,π)
SFBool [in,out] jump TRUE
SFRotation [in,out] orientation 0 0 1 0 [-1,1],(-∞ ,∞ )
SFVec3f [in,out] position 0 0 10 (-∞ ,∞ )
}
PlaneSensor : X3DDragSensorNode {
SFBool [in,out] autoOffset TRUE
SFVec2f [in,out] maxPosition -1 -1 (-∞ ,∞ )
SFVec2f [in,out] minPosition 0 0 (-∞ ,∞ )
SFVec3f [in,out] offset 0 0 0 (-∞ ,∞ )
96
SFBool [out] isOver

SFVec3f [out] trackPoint_changed
SFVec3f [out] translation_changed
}
SphereSensor : X3DDragSensorNode {
SFBool [in,out] autoOffset TRUE
SFRotation [in,out] offset 0 1 0 0 [-1,1],(-∞ ,∞ )
SFBool [out] isOver
SFRotation [out] rotation_changed
SFVec3f [out] trackPoint_changed
}
TouchSensor : X3DTouchSensorNode {
SFVec3f [out] hitNormal_changed
SFVec3f [out] hitPoint_changed
SFVec2f [out] hitTexCoord_changed
SFBool [out] isOver
SFTime [out] touchTime
}
VisibilitySensor : X3DEnvironmentalSensorNode {
97
SFVec3f [in,out] center 0 0 0 (-∞ ,∞ )

SFVec3f [in,out] size 0 0 0 [0,∞ )
SFTime [out] enterTime
SFTime [out] exitTime
}
ProximitySensor : X3DEnvironmentalSensorNode {
SFVec3f [in,out] center 0 0 0 (-∞ ,∞ )
SFVec3f [in,out] size 0 0 0 [0,∞ )
SFTime [out] enterTime
SFTime [out] exitTime
SFVec3f [out] centerOfRotation_changed
SFRotation [out] orientation_changed
SFVec3f [out] position_changed
}
Collision : X3DGroupingNode, X3DSensorNode {

SFBool [in,out] enabled
SFTime [out] collideTime
98

SFNode [] proxy NULL [X3DChildNode]
}
Anchor : X3DGroupingNode {
MFNode [in] addChildren
MFNode [in] removeChildren
MFString [in,out] parameter []
MFString [in,out] url [] [url or urn]
}
4.3 Codificação VRML97

Usando a idéia básica apresentada na seção anterior, serão
detalhados, nesta seção, o formato de codificação em VRML 97.
4.3.1 Formas Geométricas Básicas e primeiros

exemplos
Para começar a discutir as formas geométricas, será iniciada
a definição de um cone. Tal definição teria a descrição textual
abaixo como arquivo VRML:
Shape {
99
appearance Appearance {}
geometry Cone {
height 2.0
bottomRadius 1.0 }}
Observe que não foram feitas quaisquer definições de
aparência, levando a forma gerada, de acordo com o texto acima, a
ter aparência branca.
Para gerar o Cilindro, os elementos de geometria seriam os
apresentado na Figura 4-5.
A definição, em VRML, do nó Cylinder pode ser dada por:
Shape {
geometry Cylinder {
bottom TRUE
top TRUE
radius 2.0
height 3.0
}
}
Visando a construção da chaminé, temos de deslocar o
cone, de forma que sua base coincida com o topo do cilindro. Tal
deslocamento refere-se a uma translação da forma "Cone" no eixo
Y, do valor da metade da altura do cilindro (height/2) mais a
metade da altura do Cone (height_cone/2), uma vez que, conforme
ilustra a Figura 4-5, teríamos metade do cilindro acima e metade do
cilindro abaixo do eixo 'x' (o mesmo vale para o Cone).
100
4.3.2 Textos
É possível inserir textos nos ambientes 3D concebidos
através do nó Text, cuja sintaxe foi apresentada no grafo de cena.
A apresentação do texto pode ser formatada com uso do nó
FontStyle, que permite definir a fonte que será utilizada, seu
tamanho, espaçamento de caracteres, como o texto será justificado
etc.
O trecho de código abaixo, relativo à geometria, gera um
texto simples como exemplo.
geometry Text {
string ["SVR 04 - Curso de VRML e X3D"]
fontStyle FontStyle {
size 0.9
justify "MIDDLE"
spacing 0.3
style "BOLD"
family "SERIF"
}
}
Figura 4-13 - Exemplo de texto – linhas de código
Figura 4-14 - Exemplo de texto - Resultado
101
4.3.3 Transformações Geométricas

O nó VRML que permite que façamos transformações
geométricas (translação, rotação e escala) sobre as formas definidas
é o nó 'Transform'. 'Transform' é, de fato, um nó de agrupamento,
que, para todas as formas de seus filhos ('children') aplica as
transformações definidas nos campos 'scale', 'translation' e
'rotation':
- 'Scale': escala em X,Y,Z, respectivamente;
- 'Translation': translação nos eixos X,Y,Z respectivamente;
- 'rotation': rotação em X, Y, Z pelo argumento (em rad) do
quarto campo;
- 'children': lista dos elementos a qual devem ser aplicadas
as transformações.
Assim, o arquivo final para geração da chaminé deveria ter
um código semelhante às linhas abaixo:
Group{
children [
Transform {
scale 1.0 1.0 1.0
translation 0.0 3 0.0
rotation 0.0 0.0 0.0 0.0
children [
Shape {
geometry Cone {
height 3.0
bottomRadius 2.5 }
}
]
}
Shape {
102
geometry Cylinder {
bottom TRUE
top TRUE
radius 1.0
height 3.0
}
}
]
}
As linhas de código equivalem à uma árvore como a

apresentada na Figura 4-15 - Estrutura de árvore da Chaminé
Exemplo.
Figura 4-15 - Estrutura de árvore da Chaminé Exemplo

Observa-se que um código simples, iniciado por um
cabeçalho padrão (#VRML V2.0 utf8) e seguido por uma árvore
103
que contém a descrição de dois elementos geométricos, um cilindro

e um cone gera o efeito da construção de uma pequena chaminé. O
grafo que descreve a cena é dado por um nó principal Group que
contém dois nós como filhos - children:
¾ nó Transform, capaz de promover a translação de uma

dada forma, no caso, de um dado cone;
¾ nó Shape que é usado para definir uma outra forma, no

caso, um cilindro.
A facilidade de implementar formas geométricas é

facilmente observada através deste exemplo, que permite verificar
que um arquivo que tem menos de 1kb é capaz de produzir uma
forma geométrica 3D,que a partir dos recursos do navegador
VRML pode ser vista de diferentes ângulos, rotacionada para
verificação, aproximada ou afastada, girada, apontada etc, tornando
a navegação uma agradável experiência interativa com a forma.
Até meados do ano de 2000, a edição de textos que
descreviam formas em VRML não dispunha de um editor de textos
exclusivo para este fim. De olho neste nicho de mercado, a empresa
Parallel Graphics lançou o VrmlPad® [VRMLPAD 2000], que se
encontra na versão 2.0 e que facilita sobremaneira a edição de tais
textos.
104
4.3.4 Alterando Aparência - nó appearance

De maneira a acomodar a definição adequada da aparência
de uma forma, o nó appearance tem a seguinte sintaxe no VRML:
appearance Appearance {
material Material {
ambientIntensity 1.0
diffuseColor 1.0 0.0 0.0
emissiveColor 1.0 0.0 0.0
specularColor 1.0 0.0 0.0
transparency 0.3
shininess 0.4
}
texture ImageTexture {url ""}
}
}
As variáveis diffuseColor, emissiveColor e specularColor

referem-se à definição das cores do objeto relativas à iluminação
difusa, especular e a cor que o mesmo emite. A transparência do
mesmo é dada pelo campo 'transparency' e caso seja necessário,
podemos aplicar a textura relativa à uma imagem (JPEG, GIF etc)
ao objeto dando o endereço da mesma no campo ImageTexture.
Neste caso, as definições de cores feitas em 'Material' são perdidas.
Como exemplo, para alterar o cone já definido
anteriormente, dando-lhe uma aparência acinzentada, poderíamos
definir o nó appearance como:
material Material {
105
diffuseColor .8 0 .13
specularColor .77 .77 .77
emissiveColor .1 0 .02
ambientIntensity .0767
}
}
O resultado da alteração da forma do cone pode ser visto na

Figura 4-16.
Figura 4-16 - Cone colorido - uso de 'appearance'

Algumas vezes, no entanto, deseja-se aplicar uma textura a
uma dada forma, ao invés de definir propriedades de cor para a
mesma. Neste caso, imagens do tipo JPEG, GIF e PNG podem ser
aplicadas à forma desejada com uso do nó 'Material'. São campos
possíveis de serem utilizados: ImageTexture, PixelTexture e
MovieTexture.
Como exemplo, a aplicação de uma textura feita ao cone,
similar ao definido anteriormente, conforme o código abaixo pode
ser visto na Figura 4-17.
106
Transform {
scale 1.0 1.0 1.0
translation 0.0 3 0.0
rotation 0.0 0.0 0.0 0.0
children [
Shape {
material Material {
}
texture ImageTexture {
url "brick.jpg"}
}
geometry Cone {
height 3.0
bottomRadius 1.5 }
}]}
Figura 4-7 - Cone com aplicação de Textura

Há possibilidade de controlar o mapeamento de texturas
com utilização dos nós TextureCoordinate e TextureTransform. O
107
nó TextureTransform pode ser usado como um valor do campo de

valor no nó Appearance.
O trecho de código abaixo altera a aplicação de textura no
cone, por uma escala de 2.0 para as direções S e T,
respectivamente. A Figura 4-18 apresenta o plano de aplicação de
texturas S x T.
Figura 4-18 - Plano de aplicação de textura S x T
O resultado pode ser visto na Figura 4-19.

textureTransform TextureTransform
{scale 2.0 2.0 }
texture ImageTexture {url "brick.jpg"}
108
Figura 4-19 - Alterando Aplicação de Textura - textureTransform
4.3.5 Reutilizando Formas, Elementos e Definições

Quando se faz necessário reutilizar uma dada forma, são
usados os termos DEF e USE. DEF define o nome de um dado
elemento, forma ou definição. A reutilização deste nome a partir de
sua chamada por USE dispensa a redefinição.
Como exemplo, será definido um conjunto de colunas, a
partir da definição de uma única coluna. A coluna básica será
definida por "Coluna" e terá aparência definida por "White". Ao
longo da descrição do conjunto a reutilização se dará pela chamada
destes termos com USE, como pode ser visto no código abaixo:
Group {
children [
# Coluna da Esquerda
DEF ColEsquerda Transform {
translation -2.0 3.0 0.0
children DEF Coluna Shape {
appearance DEF White Appearance {
109
material Material { }
}
geometry Cylinder {
radius 0.3
height 6.0
}
}
},
# Coluna da Direita:
DEF ColDireita Transform {
translation 2.0 3.0 0.0
children USE Coluna
},
# Coluna Superior
DEF Superior Transform {
rotation 0.0 0.0 1.0 1.57
children Shape{
appearance USE White
geometry Cylinder {
radius 0.3
height 4.6
} }
}
]}
O resultado é mostrado na Figura 4-20, onde um elemento

foi reutlizado com uso de DEF e USE.
110
Figura 4-20 - Coluna com uso de DEF e USE

Podem ser inseridos elementos definidos em um dado
arquivo dentro de um cenário 3D, com uso do nó Inline. A sintaxe
de Inline é dada por:
Inline{
url []
bboxCenter -1.0 -1.0 -1.0
bboxSize 0.0 0.0 0.0
}
No exemplo abaixo, o grupo de colunas é combinado,

formando um conjunto de grupos de colunas, através da chamada
feita pelo Inline combinada com uso de "DEF" e "USE". O
resultado pode ser visto na Figura 4-21.
Group {
children [
Transform {
111
translation 0.0 -2.0 0.0

children DEF coluna Inline {url "colunas.wrl"} }
Transform {
translation 0.0 -2.0 -2.0
children USE coluna
}
Transform {
children USE coluna
}
Transform {
children USE coluna
}
]}
Figura 4-21 - Grupo de Colunas - uso de Inline
4.3.6 Compondo formas como conjunto de Faces

A utilização do nó IndexedFaceSet permite construir
conjuntos de faces interligadas, de forma que tal combinação gere
efeitos de formas complexas. Na descrição de um conjunto de
112
faces, uma lista de pontos coordenados deve ser explicitada, além

das conexões entre estes pontos. Supondo que se deseje a
construção de um cubo seriam necessárias as coordenadas da parte
superior do cubo e da parte inferior, além das descrições de
ligações entre estes pontos.
geometry IndexedFaceSet {
coord Coordinate {
point [
# Coordenadas da parte superior do cubo
-1.0 1.0 1.0,
1.0 1.0 1.0,
1.0 1.0 -1.0,
-1.0 1.0 -1.0,
# Coordenadas da parte inferior do cubo
-1.0 -1.0 1.0,
1.0 -1.0 1.0,
1.0 -1.0 -1.0,
-1.0 -1.0 -1.0
]
}
coordIndex [
# face superior
0, 1, 2, 3, -1,
# face de fundo
7, 6, 5, 4, -1,
# face de frente
0, 4, 5, 1, -1,
# face da direita
1, 5, 6, 2, -1,
# face de costas
2, 6, 7, 3, -1,
# face da esquerda
113
3, 7, 4, 0
]
}
}
E o resultado pode ser visto na Figura 4-7, onde um Cubo

foi construído a partir de suas faces.
Figura 4-7 - Cubo - uso de IndexedFaceSet
4.3.7 Fundos e Cenários

O nó Background permite criar fundos para os mundos
virtuais usando uma caixa de textura, elementos de piso e
elementos do céu. A sintaxe do nó Background foi mostrada no
grafo de cena.
O trecho de código a seguir, relativo à Figura 4-8, apresenta
um cenário com um céu azulado e o chão em tom marrom:
Background {
skyColor [
114
0.0 0.2 0.7

0.0 0.5 1.0
1.0 1.0 1.0
]
skyAngle [1.309 1.571]
groundColor[
0.1 0.1 0.1
0.4 0.25 0.2
0.6 0.6 0.6
]
groundAngle [1.309 1.571]
}
Figura 4-8 - Background aplicado

A definição de uma textura que é aplicada ao fundo pode
ser feita como apresentado no trecho de código abaixo:
Background {
skyColor [
0.0 0.2 0.7,
0.0 0.5 1.0,
1.0 1.0 1.0
]
skyAngle [ 1.309, 1.571 ]
groundColor [
115
0.1 0.10 0.0,

0.4 0.25 0.2,
0.6 0.60 0.6,
]
groundAngle [ 1.309, 1.571 ]
frontUrl "montanha.gif"
backUrl "montanha.gif"
leftUrl "montanha.gif"
rightUrl "montanha.gif"
}
E o resultado pode ser visto na Figura 4-, onde um elemento

de imagem auxilia na definição mais realística de um fundo.
Figura 4-22 - Background com elementos de imagem ".gif"
4.3.8 Iluminação
VRML provê diversos nós para uma iluminação adequada
de cenário. Todos estes nós apresentam os seguintes campos: color,
ambientIntensity e intensity. As funções dos nós podem ser:
116
- iluminação do tipo direcional, com os raios emanando

de forma radial em todas as direções: PointLight;
- iluminação do tipo direcional, com os raios pertencem a
um pincel de luz paralela: DirectionalLight;
- iluminação do tipo 'spot', com os raios em um pincel na
forma de cone, com a fonte de luz no ápice do cone:
SpotLight;
Em todos os casos, a contribuição de uma fonte de luz é
definida pelo campo intensityColor, enquanto que a contribuição da
luz ambiente é dade em função do valor do campo
ambientIntensity. Objetos com textura não são afetados pela fontes
de luz. Pode-se desligar a luz na cabeça do usuário (navegador)
através da definição a headlight FALSE no nó NavigationInfo, de
acordo com a sintaxe:
NavigationInfo {
headlight FALSE
}
4.3.8.1 DirectionalLight
A sintaxe do nó DirectionalLight é dada por:
DirectionalLight{
on TRUE
intensity 1.0
ambientIntensity 0.0
117
color 1.0 1.0 1.0

direction 0.0 0.0 -1.0
}
O pincel de luz paralelo tem a orientação dada pelo campo
direction, a cor definida no campo color e a intensidade definida
em intensity. A Figura 4-23 - uso de DirectionalLight, apresenta um
conjunto de esferas que foi iluminado com uma luz direcional, no
sentido do eixo x.
Figura 4-23 - uso de DirectionalLight
4.3.8.2 PointLight
A sintaxe do nó PointLight foi apresentada no grafo de
cena.
O pincel de luz puntiforme tem a localização no ambiente
3D dada pelo campo locaion, o raio da esfera de iluminação dado
pelo campos radius, a intensidade definida em intensity. Os
118
campos intensity e color combinam-se para definir o nível de cor

provida pela fonte de luz em definição. Assim, a equação que
define a cor da luz é:
lightColor = color X intensity.
A intensidade da luz ambiente é dada por:
lightAmbientColor = color X intensity X
ambientIntensity.
O apresentado em Figura 4-24 e Figura 4-25 refere-se a um
conjunto de esferas que foi iluminado com uma luz puntiforme, que
está definida no centro do eixo de coordenadas do sistema. Na
figura temos uma fonte de luz com grande intensidade e baixa
atenuação (caso 1) e na figura temos o mesmo conjunto de esferas
associado a uma fonte de luz com baixa intensidade e grande
atenuação (caso 2).
Figura 4-24 - uso de PointLight - caso 1
119
4.3.8.3 SpotLight
A sintaxe do nó SpotLight é dada por:
MOVI GRAFO CENAA Figura 4-25 apresenta o mesmo
conjunto de esferas iluminado por uma SpotLight
Figura 4-25 - uso de SpotLight
4.3.9 Controlando Detalhamento de Elementos - nó

LOD
A técnica de controlar o detalhamento de elementos aparece
na Computação Gráfica quando simuladores de vôo foram usados
para treinamento de pilotos. Em tais simuladores, ao apresentar o
cenário de um terreno, onde uma dada aeronave deveria pousar, o
realismo é muito importante.
120
Para dar mais realismo à tais cenas, os terrenos

necessitavam de grande detalhamento, associados à presença de
edificações, árvores, carros etc. Para melhorar o desempenho de
tais simuladores, observa-se que não é necessária a definição de
muitos detalhes quando o elemento está situado a grande distância
do observador e o inverso é válido para elementos muito próximos.
A técnica de controlar o detalhamento dos elementos está
associada à criação de diferentes versões do mesmo que serão
apresentadas ao navegante à partir de sua distância à forma em
questão. O nó LOD ativa a chamada de cada forma em função de
tais distâncias.
O valor de center especifica uma posição no espaço 3D para
o centro da forma construída com uso de LOD.
O campo level apresenta as diferentes ativações de formas
que serão efetuadas para diferentes distâncias do usuário à forma,
enquanto o campo range especifica as distâncias que definirão as
ativações dos elementos de range. O código abaixo apresenta uma
forma de controlar a apresentação de três formas - box, sphere e
cone à medida que o observador aproxima-se ou afasta-se do
conjunto.
LOD {
center 0.0 0.0 0.0
range [15,25]
level [
#primeiro nivel
121
Group{
children[
Shape { geometry Box{}}
Transform {
translation 3 0 0
children[
Shape { geometry Sphere { }}
Transform{
translation 3 0 0
children Shape { geometry Cone {}}}]}]}
# Segundo Nivel
Group {
children[
Shape { geometry Box {}}
Transform{
translation 3 0 0
children Shape { geometry Sphere{}}}]}
#Terceiro nível
Shape { geometry Box{}}
]
}
4.3.10 Animando as formas
4.3.10.1 Animações básicas

Para tornar o mundo mais dinâmico, podem ser animadas as
posições, orientações e escalas das formas que estão definidas.
Uma animação é uma mudança de algo em função de um intervalo
de tempo. Uma animação requer dois elementos:
- Um elemento de tempo (relógio) que controla a
animação;
122
- A descrição de como alguma coisa altera-se ao longo do

tempo da animação.
A animação de algum elemento deve ser feita imaginando
que o mesmo pode sofrer alterações de posição, orientação e escala
em função de um dado tempo (fração do tempo em questão). O nó
responsável pelo controle de tempos (e frações) é o nó TimeSensor.
O nó TimeSensor por si é incapaz de promover a animação.
A associação do mesmo com nós que controlam posição,
orientação e escala é essencial. O nó que controla a posição de uma
forma em função de uma fração de tempo é o nó
O nó PositionInterpolator necessita de receber uma
informação de tempo, enviada por um elemento de tempo
(geralmente um TimeSensor). Com tal informação, compatibiliza a
posição da forma (keyValue) com a fração de tempo (key). A
associação é sempre feita por uma rota que combina a saída de
tempo do TimeSensor com a entrada do nó PositionInterpolator.
Como exemplo, uma animação será aplicada à uma esfera
que deve mudar de posição o tempo todo (descrevendo um S), em
um loop, de forma que será desnecessária a intervenção do usuário
para disparar a animação. Devem ser definidas as posições inicial e
final do elemento, além das posições intermediárias (uma
interpolação define o percurso do mesmo no cenário 3D). O trecho
de código abaixo descreve esta animação:
123
DEF elemento Transform {

children[
DEF cont_tempo TimeSensor {
startTime 0.0
loop TRUE
cycleInterval 5.0
},
DEF cont_pos PositionInterpolator {
key [ 0.0 0.2 0.4 0.6 0.8 1.0]
keyValue [
0.0 0.0 0.0
1.0 0.0 0.0
1.0 1.0 0.0
0.0 1.0 0.0
0.0 2.0 0.0
1.0 2.0 0.0
]
}
DEF esfera Shape{
material Material {
diffuseColor .46 .37 .14
emissiveColor .14 .11 .04
ambientIntensity 0
shininess .04
}
}
geometry Sphere {
radius 0.3}
}
]
}
ROUTE cont_tempo.fraction_changed TO cont_pos.set_fraction
ROUTE cont_pos.value_changed TO elemento.set_translation
Há necessidade de inserir rotas, de forma que valores

obtidos em um nó sejam mapeados para outro nó, possibilitando a
animação. Neste caso, os valores de frações de tempo produzidos
124
pelo nó cont_tempo são enviados como entrada para o nó cont_pos.

Com a combinação de tais frações com os valores chave de tempo
descritos no campo key do nó cont_pos são associados com
posições chave (keyValue), que devem ser enviadas par o nó de
controle das tranformações geométricas (elemento), de forma que a
esfera seja animada.
Se, ao invés de controlar posições, fosse necessário
controlar a orientação, o nó adequado seria o nó
OrientationInterpolator, que permite que sejam aplicadas rotações
às formas desejadas.
Onde o campo key define as frações de intervalos de tempo
e o campo keyValue define as frações da animação (na forma de
rotação). O trecho de código abaixo promove a rotação de uma
caixa em torno do eixo 'x':
children[
startTime 0.0
loop TRUE
cycleInterval 5.0
},
DEF cont_or OrientationInterpolator {
key [ 0.0 0.25 0.5 0.75 1.0]
keyValue [
1.0 0.0 0.0 0.0
1.0 0.0 0.0 1.57
1.0 0.0 0.0 3.14159
1.0 0.0 0.0 4.7123
1.0 0.0 0.0 6.28
]
125
}
DEF forma Shape{
material Material {
shininess .19
}
}
geometry Box{
size 0.3 0.5 0.8}
}
]
}
ROUTE cont_tempo.fraction_changed TO cont_or.set_fraction
ROUTE cont_or.value_changed TO elemento.set_rotation
A definição da rotação está nos valores de keyValue, onde

define-se que será feita sobre o eixo 'x', que é o único dos três eixos
que está com valor diferente de '0.0' (como pode ser visto na linha
1 do campo keyValue. A rotação será de 0 a 2π e deve ser definida
com ângulos em radianos.
A última forma de animação relativa às transformações
geométricas é a mudança de escala. O nó que permite mudança de
escala é o nó PositionInterpolator (o mesmo que permite a
animação de posição). Neste caso, no entanto, devem ser colocados
valores de escala no campo keyValue e a rota de saída de valores
deve ser entrada para valores de escala ao invés de valores de
126
posição. Supondo a esfera apresentada anteriormente, a

modificação do nó de controle e das rotas seria dada por:
DEF cont_esc PositionInterpolator {
key [ 0.0 0.2 0.4 0.6 0.8 1.0]
keyValue [
1.0 1.0 1.0
1.5 1.5 1.5
2.0 2.0 2.0
2.5 2.5 2.5
1.5 1.5 1.5
1.0 1.0 1.0
]
}
DEF esfera Shape{
material Material {
ambientIntensity 0
shininess .04
}
}
geometry Sphere {
radius 0.5}
}
]
}
ROUTE cont_tempo.fraction_changed TO cont_esc.set_fraction
ROUTE cont_esc.value_changed TO elemento.set_scale
4.3.10.2 Controlando as animações

De maneira a controlar as animações, podem ser inseridos
nós sensores de ações dos usuários. Há três formas de ações que
podem ser percebidas:
127
Movimento (Move): sem pressionar o mouse, o usuário

move o cursor sobre um item qualquer;
Clique: quando o cursor está sobre um elemento, o
botão do mouse é pressionado e liberado, sem
movimento do mesmo;
Arraste (Drag): com o cursor sobre um item, o botão do
mouse é pressionado e, mantido pressionado, o mouse é
arrastado.
O nó capaz relativo à captura de toque é o nó TouchSensor.
A sintaxe do nó TouchSensor é:
TouchSensor {
enabled TRUE
}
O nó TouchSensor tem sensibilidade ao toque (campo
touchTime), ao cursor estar sobre uma forma (isOver) e
pressionado (isActive). Supondo que se desejasse disparar a
animação de uma esfera como mostrado anteriormente, ao toque na
esfera, a sintaxe poderia ser:
children[
cycleInterval 5.0
},
DEF cont_pos PositionInterpolator {
key [ 0.0 0.2 0.4 0.6 0.8 1.0]
keyValue [
0.0 0.0 0.0
1.0 0.0 0.0
1.0 1.0 0.0
128
0.0 1.0 0.0

0.0 2.0 0.0
1.0 2.0 0.0
]
}
DEF toque TouchSensor {}
DEF esfera Shape{
material Material {
ambientIntensity 0
shininess .04
}
}
geometry Sphere {
radius 0.3}
}
]
}
ROUTE toque.touchTime TO cont_tempo.startTime
ROUTE cont_tempo.fraction_changed TO cont_pos.set_fraction
ROUTE cont_pos.value_changed TO elemento.set_translation
Neste exemplo, quando o usuário toca na esfera, que está

definida no mesmo grupo do nó 'toque', um evento de disparo de
tempo é enviado para o nó de controle de tempo - 'cont_tempo'. Só
então, frações de tempo são recebidas pelo nó 'cont_pos',
disparando a animação (que acontece uma única vez).
De maneira a permitir que um dado elemento gráfico seja
manipulado pelos movimentos do usuário, existem três nós
distintos;
129
PlaneSensor: converte as ações do usuário em

movimentos em um plano 2D;
SphereSensor: converte as ações do usuário em
movimentos ao longo de uma esfera que envolve a
forma;
CylinderSensor: converte as ações do usuário em
movimentos ao longo de um cilindro definido sobre um
dos eixos.
Os campos maxPosition e minPosition definem os limites
da translação que será aplicada à forma. O trecho de código abaixo
permite que, com a movimentação do mouse, uma dada esfera sofra
mudança de posição ao longo do plano 'XY':
children[
DEF sensor_pos PlaneSensor {
enabled TRUE
autoOffset TRUE
offset 0.0 0.0 0.0
maxPosition -1.0 -1.0
minPosition 0.0 0.0
}
DEF esfera Shape{
material Material {
specularColor .5 0 .5
ambientIntensity 0
shininess .15
}
}
geometry Sphere {
130
radius 0.8}
}
]
}
ROUTE sensor_pos.translation_changed TO elemento.translation
O nó SphereSensor tem sintaxe dada por:

SphereSensor {
autoOffset TRUE
enabled TRUE
offset 0.0 1.0 0.0 0.0
}
O campo offset permite definir o eixo de rotação que será

usado. O trecho de código abaixo apresenta a utilização de
SphereSensor para rotacionar uma dada caixa (box):
children[
DEF sensor_esf SphereSensor {
autoOffset TRUE
enabled TRUE
offset 0.0 1.0 0.0 0.0
}
DEF esfera Shape{
material Material {
diffuseColor .6 .23 0
specularColor .5 .2 0
emissiveColor .3 .12 0
ambientIntensity 0
shininess .15
}
}
geometry Box {
size 2.0 3.0 5.0}
}
131
]
}
ROUTE sensor_esf.rotation_changed TO elemento.rotation
O nó CylinderSensor tem sintaxe dada por:

CylinderSensor {
autoOffset TRUE
enabled TRUE
diskAngle 0.262
offset 0.0
maxAngle -1.0
minAngle 0.0
}
O trecho de código abaixo apresenta a utilização de

CylinderSensor para movimentar uma dada caixa (box):
children[
DEF sensor_esf CylinderSensor {
autoOffset TRUE
enabled TRUE
diskAngle 0.262
offset 0.0
maxAngle -1.0
minAngle 0.0
}
DEF esfera Shape{
material Material {
specularColor .5 .2 0
132
ambientIntensity 0
shininess .15
}
}
geometry Box {
size 2.0 3.0 5.0}
}
]
}
ROUTE sensor_esf.rotation_changed TO elemento.rotation
4.3.11 Controlando o Ponto de Vista e a Navegação

A navegação pode ser controlada pelo nó NavigatonInfo.
A velocidade de movimentação do avatar é dada pelo
campo speed. Os tipos de navegação, relativos ao campo type são:
• "WALK": quando o usuário caminha no mundo e é afetado
pela gravidade;
• "FLY": quando o usuário pode se mover sem ser afetado
pela gravidade;
• "EXAMINE": quando o usuário fica estático, mas pode se
mover ao redor do mundo em diversos ângulos;
• "NONE", quando o usuário não pode controlar os
movimentos.
O campo headlight define se o avatar terá ou não uma fonte
de luz na sua cabeça. Se TRUE, uma fonte de luz estará ligada na
cabeça do avatar.
133
Um ponto de vista (Viewpoint) é uma posição pré-definida

com uma dada orientação no cenário. Podem ser alteradas as
formas de navegação do usuário e suas posições de visualização.
O campo orientation define um eixo de rotação e um ângulo
de rotação. O campo position define a posição de visualização do
avatar em relação ao cenário apresentado. O trecho de código
abaixo mostra como pode ser mudada a forma de navegação a
partir do toque em uma dada forma:
Group {
children [
DEF nav NavigationInfo {
type "NONE"
speed 2.0
headlight FALSE
avatarSize [0.5 1.6 0.5]}
DEF nav2 NavigationInfo {
type "WALK"}
DEF toque TouchSensor {},
Shape{
geometry Cone {}
}
]
}
ROUTE toque.isOver TO nav2.set_bind
4.3.12 Adicionando Sons e Filmes ao Cenário

De maneira a permitir que o cenário seja mais realístico,
podem ser adicionados sons, na forma de sons ambientes ou de
sons controlados por animações. Os nós relativos a adição de sons
são:
134
AudioClip: nó que suporta alguns tipos de sons digitais

(não é permitido o mp3): MIDI e WAV;
Sound: nó que cria um emissor de som que pode ser
ouvido dentro de uma região elipsoidal;
MovieTexture: permite a inserção de filmes (movie).
4.3.13 Sentindo a proximidade do usuário

Como visto, pode se usar o nó TouchSensor para detectar
quando o usuário toca uma forma do cenário. Há, no entanto, três
outros nós capazes de identificar ações do usuário, que podem ser
utilizados para controlar animações, da mesma forma que o nó
TouchSensor:
VisibilitySensor: usado para identificar a visibilidade de
um observador, através de uma região que tem o
formato de uma caixa (região de visibilidade);
ProximitySensor: nó que permite detectar quando o
observador entra e/ou se move em uma região fechada
(em formato de uma caixa);
Collision: permite detectar quando o usuário colide com
alguma forma, sendo também um nó de agrupamento
(como Group ou Transform). Este nó gera o tempo
absoluto em que o choque ocorreu ou alerta o navegador
o fato;
135
O trecho de código abaixo apresenta uma animação

controlada pelo nó ProximitySensor. Neste exemplo, quando o
usuário se aproxima de uma caixa de texto, um som intermitente é
emitido, como um som de alerta:
DEF SENSOR ProximitySensor {
size 8 8 8
}
Sound {
minFront 10
minBack 10
maxFront 50
maxBack 50
source DEF SOUND AudioClip {
loop TRUE
url "pop.wav"
startTime -1
}
}
Group {
children [
Shape {
material Material {
shininess .38
}
}
geometry Box { size 0.8 0.5 0.1}
}
Transform {
children
Shape {
136
material Material {
shininess .08
}
}
geometry Text {
string "Alerta"
size 0.27
justify "MIDDLE"
}
}
}
}
]}
ROUTE SENSOR.enterTime TO SOUND.startTime

ROUTE SENSOR.exitTime TO SOUND.stopTime
No exemplo anterior, se ao invés de utilizar o nó

ProximitySensor, fosse utilizado o nó Collision, o som só seria
emitido no caso de colisão com a forma.
4.3.14 Unindo Cenários Virtuais - Links

Usando VRML é possível simular que, ao toque em uma
porta, um novo cenário será carregado. Tal ativação pode carregar
um novo cenário 3D, uma página Web ou uma animação. O nó
adequado à tais simulações é o nó Anchor.
137
É importante destacar o campo url que conterá a informação

da página com a qual se deseja ativar ao tocar os elementos
descritos em children. O trecho de código abaixo apresenta um
exemplo de utilização de Anchor:
Anchor {
# inserção do link para onde se deseja ir:
url [ "http://www.sbc.org.br/svr"]
description "Página do SVR´03"
# nós que ativarão o link:
children [
Transform {
children [ Shape {
material Material {
ambientIntensity 0
shininess .15
}
}
geometry DEF Door Box {size 2.0 1.0 0.1}
}
Transform {
children Shape {
material Material {
ambientIntensity 0
shininess .14
}
}
# inserção de um texto para identificar o link:
geometry Text {
138
string "SVR 03"

size 0.4
justify "MIDDLE"}
}
}
}
]
}, ]}
Anchor {
# inserção do link para onde se deseja ir:
url [ "http://www.compgraf.ufu.br/alexandre"]
description "Homepage do Autor"
# nós que ativarão o link:
children [
Transform {
children [ Shape {
material Material {
shininess .03
}
}
geometry USE Door
}
Transform {
children Shape {
material Material {
ambientIntensity 0
shininess .14
}
139
}
# inserção de um texto para identificar o link:
geometry Text {
string "Autor"
size 0.4
justify "MIDDLE"}
}
}
}
]
}
]
}
4.3.15 Combinando VRML e JavaScript
4.3.15.1 Introdução
Os nós já apresentados para animação, tais como
TouchSensor, TimeSensor, PlaneSensor etc são muito limitados
quando se desejam animações mais complexas ou controle de
elementos de cena a partir de equações (matemáticas, físicas,
químicas etc). Em tais situações é imperativa a necessidade de uso
dos nós Script, que associam VRML com JavaScript ou Java.
Um nó Script pode ser entendido como uma forma
particular de controle ou de sensor. Como qualquer nó de controle
ou de sensor, este nó requer uma lista de campos (field) , eventos
de entrada (eventIns) e eventos de saída (eventOuts). A descrição
do nó deve complementar a definição destes campos, dando a eles
140
uma dada finalidade . Um nó Script deve ser entendido como um

nó que recebe informações de outros nós através dos eventos de
entrada, processa-as e envia informações na forma de eventos de
saída.
Logicamente, não serão encontrados nós Script
independentes da descrição de rotas, que mapeiam a troca de
informações entre nós externos e o nó Script. Uma exigência
importante é a necessidade de equivalência de tipos de elementos
entre os nós que trocam informações.
Característica básica de um Script:
Script {
# definição de campos, suas naturezas e valores iniciais:
field SFBool booleano1 TRUE
# definição de eventos de entrada e sua natureza:
eventIn SFBool entrada
# definição de eventos de saída e sua natureza:
eventOut SFBool saida
url "javascript:
function entrada(param){
// processamento e determinação da saída
saida = param;
"
}
141
4.3.15.2 Exemplos
Como exemplo, a função abaixo representa um Script capaz
de inserir um novo elemento, no caso, uma esfera em uma área de
um mundo virtual:
DEF Criador Script {
eventIn SFTime sphere_touchTime
field SFNode nopai USE TOP
field SFFloat x 0.0
eventOut MFNode new_child
url "javascript:
function sphere_touchTime(value,time) {
newVRML = 'Group {';
newVRML += ' children [';
newVRML += ' DEF SENSOR PlaneSensor {';
newVRML += ' maxPosition 0.45 0.45';
newVRML += ' minPosition -0.45 -0.45'
newVRML += ' }';
newVRML += ' DEF OBJECT Transform {';
newVRML += 'translation '
newVRML += x;
newVRML += ' 0.0 ';
newVRML += ' 0.0';
newVRML += ' children [';
newVRML += ' Shape {';
newVRML += ' appearance Appearance {';
newVRML += ' material Material {';
newVRML += ' diffuseColor 0 1 1';
newVRML += ' }';
newVRML += ' }';
newVRML += ' geometry Sphere {';
newVRML += ' radius 0.05';
142
newVRML += ' }';

newVRML += ' }';
newVRML += ' ]';
newVRML += ' }';
newVRML += ' ]';
newVRML += '}';
newVRML+=' ROUTE
SENSOR.translation_changed TO OBJECT.set_translation';
node =
Browser.createVrmlFromString(newVRML);
new_child = node;
nopai.addChildren = new_child;
}
"
}
ROUTE SPHERESENSOR.touchTime TO
Criador.sphere_touchTime
É possível alterar dinamicamente um texto, que funcione

como um contador de esferas adicionadas (continuação do exemplo
anterior), se um dado nó de texto for atualizado, a partir de um
campo que conte quantas esferas foram adicionadas. O trecho de
código abaixo refere-se à função sphere_touchTime atualizada, de
tal forma que a mesma é capaz de modificar o texto, enviando,
através de uma rota, o valor atual de esferas inseridas:
field SFFloat x2 0.0
field MFString str_sphere "0"
eventOut MFString str_sphere_out
function sphere_touchTime(value,time) {
143
x2 = x2 + 1.0;
str_sphere[0] = String(x2);
str_sphere_out[0] = str_sphere[0];
A rota combinada seria do tipo:
ROUTE Criador.str_sphere_out TO textoS.string
Onde textoS é um campo de texto pertencente a um nó
Shape.
4.4 Codificação X3D

Os dois padrões VRML97 e X3D são muito semelhantes o
X3D aproveita o trabalho desenvolvido pelo VRML97
solucionando diversos problemas e pontos em aberto. Dentre as
modificações temos a maior precisão com a iluminação e modelo
de eventos e a troca de certos nomes de campos para uma maior
consistência.
As maiores mudanças podem ser sumarizadas da seguinte
forma:
• Capacidades do grafo de cena expandidas
• Modelo de programação de aplicações revisado e unificado
• Multiplos formatos de codificação, descrevendo o mesmo

modelo abstrato, incluindo XML
144
• Arquitetura modular permitindo uma faixa de níveis para

serem adotados e suportados por diversos tipos de mercados
• Estrutura da especificação expandida
O grafo de cena X3D - o coração de uma aplicação X3D - é

quase idêntico a do grafo de cena VRML97. O projeto original da
estrutura e tipos de nós do grafo de cena VRML97 foi baseado no
OpenInventor. Modificações foram feitas no grafo de cena X3D,
primariamente em função de incorporar os avanços nos dispositivos
gráficos comerciais, via a introdução de novos nós e campos dos
dados. Adicionalmente mudanças menores foram feitas de forma a
esclarecer, como as de ser mais preciso no sistema de iluminação e
modelo de eventos, e prover acesso aos valores de transparência
nos campos de cores.
O X3D tem uma única interface de programação de
aplicações (API). Esta difere do VRML97 na qual tem uma API de
script interna mais uma API externa. A API unificada do X3D
esclarece e resolve diversos problemas que existiram no VRML97
resultando em uma implementação mais robusta e confiável.
Conexões por ECMAScript e Java são definidas e ECMAScript é
um requisito para a conformidade de uma aplicação. O
ECMAScript na verdade é um sistema Java interpretado porém
145
devido a restrições da Sun o nome Java não pode ser usado

livremente.
O X3D suporta múltiplas codificações de arquivos, a
própria VRML97 e adicionalmente Extensible Markup Language
(XML), além disso esta sendo estudada uma codificação binária,
que seria muito mais comprimida e eficiente para a leitura e
transferência de arquivos, contudo esta ainda não esta consolidada.
A codificação XML possui uma vantagem pois permite uma suave
integração com serviços de web (web services) e arquivos e
transferência de dados entre plataformas inter-aplicações ( cross-
platform inter-application). Cada codificação tem suas vantagens
para diferentes usos. Todas as codificações suportam todo o
conjunto de características do X3D.
O XML é um padrão definido para a troca de dados em
multiplataformas. Existe uma série de bibliografias que podem ser
estudadas [[[ REFFFFF ]]]. Basicamente o XML consistem em
uma série de nós que são organizados pelos sinais de menor e
maior ( “<” e “>” ) e também um sinal de barra ( “/” ) para
informar o final de um nós
Vamos apresentar aqui dois exemplos de arquivos, um no
formato clássico, que pode ser facilmente reconhecido pelos sinais
de chaves e colchetes. Percebam que ele tem a mesma estrutura do
VRML97, porém com diferenças no cabeçalho. Logo a seguir é
146
apresentado um na codificação XML, nele é possível verificar a

codificação XML, que é mais comum para usuários em geral, que
lidam com formatos de codificação.
• Exemplo de um arquivo em X3D Classico
#X3D V3.0 utf8
Profile Immersive
NavigationInfo {
type [ "ANY" ]
}
Transform {
children [
Shape {
material Material {
diffuseColor 1.0 1.0 1.0
}
}
geometry Sphere {}
}
]
}
• Exemplo de um arquivo em X3D codificado em XML

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE X3D PUBLIC
"http://www.web3d.org/specifications/x3d-3.0.dtd">
<X3D profile="Immersive">
<Scene>
<NavigationInfo type="ANY"/>
<Transform>
<Shape>
<Appearance>
<Material diffuseColor=”1.0
1.0 1.0”/>
</Appearance>
<Sphere/>
</Shape>
</Transform>
</Scene>
147
</X3D>
Estes arquivos deve produzir simplesmente uma esfera

branca – Figura 4-26.
Figura 4-26 – Imagem visualizada do exemplo

O X3D emprega uma arquitetura modular para prover uma
maior estensibilidade e flexibilidade. A maioria dos domínios de
aplicações não necessitam de todos os recursos do X3D, tão pouco
todas as plataforma suportam a gama de funcionalidades definidas
na especificação. Os recursos do X3D são agrupados em
componentes (components) que podem ser suportados pela
implementação em uma mistura de capacidades para atingir as
necessidades de um mercado ou plataforma em particular. O X3D
também introduz o conceito de perfis (profiles) - uma pré-definida
coleção de componentes comumente encontrados em certos
domínios de aplicações , plataformas, ou um cenário de uso, por
exemplo trocas de geometrias entre ferramentas de modelagem.
Diferente do VRML97, na qual requer um completo suporte de
148
suas funcionalidades para estar em conformidade, o X3D permite

vários graus de suporte do padrão para atingir uma variedade de
necessidades. O mecanismo de componentes do X3D também
permite desenvolvedores a implementar suas próprias extensões de
acordo com um rigoroso conjunto de regras, ajudando a evitar a
"torre de babel" das extensões dos desenvolvedores que surgiram
no VRML97 nos últimos anos.
Finalmente, a especificação do X3D por si mesma tem sido
reestruturada, permitindo um ciclo de vida mais flexível para
acomodar as evoluções dos padrões. O padrão X3D é divido em
três especificações separadas lidando com conceitos abstratos de
arquitetura, codificação de arquivo e acesso de linguagem de
programação. Este enfoque permite à especificação mudar durante
o tempo e facilita sua adoção através da ISO para especificar partes
da especificação conforme necessário.
4.5 Transição do VRML para o X3D

A mudança básica que deve ser efetuada caso para a
conversão entre VRML97 e o “X3D clássico” é mudar o cabeçalho
de:
#VRML V2.0 utf8
para
#X3D V3.0 utf8
149
Profile Immersive
Existe agora a necessidade de se definir o profile para que o
navegador saiba o grau de recursos a serem utilizados, uma outra
diferença é a forma de se chamar scripts no X3D. No VRML97 as
chamadas eram feitas com 'javascript' ou 'vrmlscript'. O X3D usar o
chamado 'ecmascript'. ECMAScript é a versão padronizada do
JavaScript.
Existem diversas ferramentas disponíveis que podem fazer a
conversão entre VRML97 e X3D. Se você tem um arquivo
relativamente simples que não contem scripts ou externprotos então
você pode editar manualmente o texto para trocar o cabeçalho e
inserir a nova declaração PROFILE que você estará com o
documento pronto. Qualquer coisa mais complexa vai requerer uma
ferramenta e idealmente um razoável trabalho de conhecimento
com a nova especificação (diversas áreas funcionais foram
mudadas para serem mais rigorosas ou apenas são simplesmente
diferentes).
Existem algumas ferramentas para a conversão de conteúdo,
uma delas é o X3D-Edit, porém é possível também a utilização de
algumas ferramentas por linha de código. Usualmente basta um
programa capaz de converter os nós de um formato de codificação
para outro.
150
Um cuidado que se deve tomar é que um arquivo VRML97

não é exatamente um arquivo X3D. Um navegador puramente X3D
poderá não será capaz de ler um arquivo VRML97 logo que
existem mudanças na sintaxe que levam os dois a
incompatibilidades. Entretanto, a maioria dos navegadores que
suportam o padrão X3D também suportam o padrão VRML97.
Provavelmente no futuro a maioria dos navegadores ira suportar
arquivos X3D, e alguns ainda suportarão o formato VRML97.
Existem mudanças entre o VRML97 e o X3D sutis e não
tão sutis. Algumas são:
• Os arquivos estão agora estruturados para definir as

capacidades necessárias como parte do cabeçalho. Isto necessita
que ao menos seja definido o perfil (profile) e qualquer
componente (component) extra.
• Externprotos agora são usados somente para definir conteúdo
externo ao arquivo X3D. Eles não podem ser usados para prover
mecanismos de extensão para o navegador. A forma de prover
extensões específicas para o navegador é através de componentes
(components) adaptados.
151
• Nomes de acesso para campos mudaram de eventIn,
eventOut, field e exposedField, para inputOnly, outputOnly,

initializeOnly e inputOutput, respectivamente.
• Scripts podem ter campos inputOutput (exposedFields)
definidos.
• Um nome DEF não pode ser multi definido mais.
• Todo conteúdo de leitura é desacoplado. Onde no VRML97
necessitaria que scripts fossem carregados antes da execução

começar, X3D remove esta necessidade e define que o arquivo
começa a executar primeiro e depois de certo tempo, recursos
(scripts, texturas, sons, inlines, externprotos) são carregados.
• O modelo de execução entre o conteúdo de um script e o
grafo de cena é rigorosamente definido e precisamente controlado.

Onde o VRML97 permite um script multi-threaded arbitrariamente
trocar o grafo de cena em qualquer ponto, o X3D define somente
certos ponto onde estas alterações podem ser feitas.
• A execução e modelo de programação para scripts é
consistente entre linguagens de programação e aonde quer que você

esteja, dentro ou fora do navegador - uma definição da API é regra
geral.
152
• Rigorosa definição de conjunto de definições de tipos
abstratos para nós.
Os arquivos X3D devem seguir as seguintes regras:
Codificação Extensão de Extensões

Tipo MIME
X3D arquivo Compactadas
.x3dvz,
Clássico VRML .x3dv model/x3d+vrml
.x3dv.gz
XML .x3d .x3dz, .x3d.gz model/x3d+xml
.x3dbz,
Binário .x3db model/x3d+binary
.x3db.gz
* os tipos MIME ainda estão sendo aprovados
4.6 Utilização de Ferramentas

Devido ao sistema de grafo de cena, a construção de
ambientes em VRML97 ou X3D pode ser feita diretamente em
qualquer editor de texto. Contudo a edição por texto é de grande
complexidade. Assim a utilização de ferramentas pode auxiliar em
muito. No caso do VRML97 temos o VRML-Pad. Já para o X3D
uma das possibilidades é o X3D-Edit. Este aplicativo em Java pode
editar arquivos X3D de uma forma muito simples e também
permite a abertura de arquivos no formato VRML97. Existe um
grande número de ferramentas úteis relacionadas com o X3D,
incluindo conversões stylesheet entre VRML97 e pacotes de edição
baseados em XML para arquivos X3D. Se você está trabalhando
153
neste nível, um bom entendimento de conceitos de computação

gráfica é necessário, e para efeitos visuais avançados, como o uso
de multitexturing, environment mapping, programmable shaders e
mais, um conhecimento prático de programação gráfica 3D (p.e.
OpenGL Direct3D etc) será uma vantagem.
Também existe uma série de aplicativo gerais, usualmente
conhecidos como modeladores que podem modelar objetos, animar
eles, e as vezes até inserir os comandos específicos do
VRML97/X3D. Isto cria uma grande facilidade para o
desenvolvimento dos mundos virtuais, e é algo que o
VRML97/X3D se destaca dos outros formatos de arquivo. É
esperado que ferramentas e conteúdo gerado automaticamente
prevalecerá sobre conteúdos editados a mão.
Finalmente abordaremos alguns dos navegadores utilizados
para ver o contudo do arquivos criados e navegar neles.
Usualmente eles estão conectados aos navegadores da Web como o
Netscape ou Internet Explorer, contudo outros são mais
independentes e usualmente apresentam mais funcionalidades.
• Editando os arquivos VRML97 e X3D
VRML-Pad
Editor simples de ser usado, desenvolvido pela Paralellgraphics
(www.paralellgraphics.com), o VRMLPad apresenta diversos
154
recursos, como a edição de extrusões, definição de cores e texturas

etc.
A Figura 4-27 apresenta a tela inicial do editor, onde podem ser
obervadas as áreas de janela de edição e auxiliar – que permite que
sejam verificados arquivos em uso, diretórios, grafo de cena e mapa
de rotas.
Figura 4-27 - Tela Principal do VRMLPad

X3D-Edit
155
Figura 4-28 – Exemplo de janela do X3D-Edit
• Editando os arquivos VRML97 e X3D de forma mais

avançada
Maya
O Maya é uma ferramenta muito utilizada para a criação de
filmes no ciname. Contudo ela possui um sistema avançado de
modelagem, e ativando o seu plug-in é possível salvar o arquivo no
formato VRML97. Alguns cuidados devem ser tomados, pois
poderão haver perdas de informação, pois infelizmente o conversor
do Maya não é completo o suficiente.
156
Figura 4-29 – Exemplo de modelagem com o Maya
3D-Studio
O 3D-Studio assim como o Maya apresenta uma série de
vantagens para a modelagem. E da mesma forma apresenta uma
ferramenta para exportar os dados para arquivos VRML97.
• Visualizando arquivos VRML97 e X3D
Cosmo
O Cosmo foi um dos primeiros navegadores desenvolvidos
para visualizar arquivos VRML, contudo não sofreu grandes
avanços desde então. Assim apresenta alguns limites.
157
Xj3D
Existe uma implementação código aberto (Open Source)
escrita em Java chamada de Xj3D. Uma aplicação funcional está
disponível hoje e tem sido testada sobre Linux, Solaris e Win32. O
Xj3D é baseado em Java3D, logo necessita o Java3D para rodar,
como o Java3D necessita o Java 2, uma grande quantidade de
dados deve ser instalado para a utilização do Xj3D. O navegador
Xj3Dé uma boas fonte para implementação.
JINX
O sistema JINX é um navegados estritamente X3D, que
pode ser utilizado em ambientes de aglomerados de computadores
e sistemas de projeções mais variados, desde simples monitores até
avançados sistema de projeção cúbica como Cavernas e Domos.
Este projeto ainda esta em desenvolvimento.
Figura 4-30 – Exemplo de aplicação básica rodando na JINX
158
4.7 Referências deste capítulo
AMES, L. A.; NADEAU, R.D.; MORELAND D. VRML

Sourcebook - Second Edition, John Wisley & Sons, Inc - USA,
1997.
CARDOSO, A.; LAMOUNIER E.; TORI R. Sistema de Criação de

Experiências de Física em Realidade Virtual para Educação a
Distância. In: II WORKSHOP BRASILEIRO DE REALIDADE
VIRTUAL, WRV´99, Marília, São Paulo, Brasil, 1999, p. 174-
181.
CARDOSO, A. Alexandre Cardoso - Página do Pesquisador.

Contém informações sobre aplicações de Realidade Virtual,
pesquisa e publicações do pesquisador, tutoriais sobre VRML e
artigos indicados para leitura. Disponível em:
<http://www.compgraf.ufu.br/alexandre/>. Acesso em Set./2003
CHEN, S.; MYERS, R.; PASSETO, R. The Out of Box Experience

- Lessons Learned Creating Compelling VRML 2.0 Content. In:
Proceedings of the Second Symposium on Virtual Reality
Modeling Language, p. 83-92, 1997.
EcmaScript Specification (JavaScript), disponível em

http://www.ecma.com, Search, EcmaScript, EC 262
159
ELLIS R. S. What are Virtual Environments. IEEE Computer

Graphics and Applications, p. 17-22, Jan. 1994.
LEMAY, MURDOCK, COUCH 3D Graphics and VRML 2

Sams.Net, Indiana - USA – 1996
Introducing X3D by Leonard Daly, Don Brutzman, Nicholas Polys,

Joseph D. Williams, SIGGRAPH 2002. Curso introdutório de
X3D, disponível em http://realism.com/Web3D/x3d/s2002,
acessado em Agosto 2004
MATSUBA, N.; STEPHEN; ROEHL, B. Bottom, Thou Art

Translated: The Making of VRML Dream. IEEE Computer
Graphics and Applications, v. 19, n. 2, p. 45-51, Mar./Apr.
1999.
Scenario Authoring and Visualization for Advanced Graphical

Environments (Savage) project at
http://web.nps.navy.mil/~brutzman/Savage/contents.html
Vapor Tutorial VRML - Tutorial de VRML com exemplos e

fontes. Disponível em http://web3d.vapourtech.com/. Acesso em
Set./2003
VRMLPAD. Parallellgraphis. O sítio disponibiliza diversos

programas computacionais de grande utilidade para
desenvolvimento de ambientes virtuais em VRML, inclusive o
160
programa VRMLPad. Disponível em:

<http://www.parallellgraphics.com>. Acesso em: 02 nov. 2000.
161
Capítulo
5
Java 3D
1,2 1,2
José Remo Ferreira Brega , Antônio Carlos Sementille , Ildeberto
1
Aparecido Rodello
1
UNIVEM Centro Universitário Eurípides de Marília Marília – SP
2
UNESP – Universidade Estadual Paulista – Campus de Bauru – SP
{remo, semente, rodello}@univem.edu.br
Abstract
This Chapter presents the API Java 3D, starts with the basic
structure of a program, until the more complex and elaborated
environment implementation. Its classes and methods are presented
for the creation of forms and support for diverse devices of
entrance and exit, illustrating the form of implementation by means
of examples.
Resumo
Este Capítulo apresenta a API Java 3D, discutindo desde a

estrutura básica de um programa, até a implementação de
ambientes mais complexos e elaborados. São apresentados e
discutidos as principais classes e métodos para a criação de
formas e suporte para diversos dispositivos de entrada e saída,
ilustrando a forma de implementação por meio de exemplos.
162

5.1. Introdução
Java 3D é um conjunto de classes desenvolvido pela Sun
Microsystems (SUN, 2002) com o objetivo de ser uma interface
para o desenvolvimento e apresentação de programas em Java com
conteúdo tridimensional, otimizando renderizações.
Java 3D segue o paradigma de escreva uma vez e rode em
qualquer lugar (Write once, run anywhere), fornecendo suporte
para várias plataformas, vários dispositivos de visualização e vários
dispositivos de entrada.
5.2. Vantagens e desvantagens

Como principais vantagens de Java 3D [SELMAN, 2002]:
Implementação somente em Java, oferecendo facilidades para a
portabilidade; Suporte para aplicações distribuídas, desde o uso de
Java RMI e para a Internet com Applets e Servlets desenvolvidas
facilmente em Java [SUN, 2006]; o emprego de grafo de cena;
Suporte para alguns dispositivos não convencionais A Descrição da
cena; e possuir mecanismos para otimização da renderização dos
grafos de cena.
Java 3D também oferece algumas desvantagens, dentre as
quais [SELMAN, 2002]: Não conseguir atender a todas as
características oferecidas por linguagens gráficas mais apuradas
como OpenGL; Não permitir aos desenvolvedores um controle
maior sobre o grafo de cena; A existência do coletor automático de
lixo de Java; e A dificuldade na distribuição das aplicações para os
usuários, pela necessidade da correta instalação da API Java 3D
associada com a aplicação.
5.3. Estrutura da API Java 3D
163

Um programa Java 3D cria instâncias de objetos, colocados em

uma estrutura hierárquica chamada de grafo de cena (scene graph).
Esta estrutura, segue um modelo que especifica o conteúdo de um
universo virtual e como este conteúdo será renderizado.
Em um grafo de cena são definidos a geometria, os sons, as
luzes, a localização, a orientação e a aparência dos objetos Java 3D,
os quais são organizados de acordo com o modelo pai-filhos de
relacionamento.
Como toda estrutura baseada em grafos, o grafo de cena é
composto por nós (nodes) e arcos (arcs). Um nó representa um
elemento e um arco representa o relacionamento entre os
elementos. A Figura 5.1 apresenta os nós e os arcos, presentes em
um grafo de cena Java 3D.
Os primeiros dois símbolos, Virtual Universe e Locale,
representam objetos de classes específicas. Os outros três símbolos,
Group, Leaf e Node Component, indicam subclasses de objetos
específicos. Por fim, o último símbolo é usado para representar um
objeto de qualquer outra classe.
As linhas em formato de setas indicam os relacionamentos
entre os objetos. As linhas contínuas representam um
relacionamento pai-filho entre dois objetos e as linhas pontilhadas,
por sua vez, indicam uma referência para um objeto.
Em cada grafo de cena existe um objeto VirtualUniverse,
que tem uma lista dos objetos Locale. Normalmente existe um
universo por aplicação. Ele é a base sobre a qual o grafo de cena é
montado.
Os objetos Locale, por sua vez, fornecem um ponto de
referência em termos de localização dos objetos no universo
virtual, ou seja, uma posição no universo na qual irão ser colocados
os grafos de cena. Normalmente existe um Locale por universo.
164

Um grafo de cena é construído de nós em relacionamentos

pai-filho, formando uma árvore, que possui um nó raiz. Outros nós
são acessíveis seguindo os arcos a partir da raiz. Um grafo de cena
é formado de árvores originadas em um objeto Locale e só existe
um caminho da raiz de uma árvore a cada uma de suas folhas.
Figura 5.1 – Componentes de Grafo de Cena.
Cada caminho especifica o estado e informações sobre

determinada folha, como local, orientação, e tamanho de um objeto
visual. Assim os atributos visuais de cada objeto dependem apenas
de seu caminho no grafo. Java 3D aproveita esta característica e
renderiza os nós na ordem que determinar ser mais eficiente. O
programador geralmente não tem controle sobre a ordem de
165

renderização dos objetos. Além disso, as representações gráficas de

um grafo de cena podem servir como documentação para
programas escritos em Java 3D.
A raiz de cada subgrafo do grafo de cena (ou branch graph)
é representado por um BranchGroup. Normalmente existem
diversos branch graphs por locale. Existem duas categorias de
subgrafo: view branch graph e content branch graph.
Normalmente existem vários branches por locale.
O content branch graph especifica o conteúdo do universo
virtual (geometria, aparência, comportamento, localização, som e
iluminação), enquanto o view branch graph especifica os
parâmetros de visualização tais como localização e direção.
A Figura 5.2 mostra um exemplo de um grafo de cena.
Neste grafo observa-se a presença de um virtual universe e um
locale. Abaixo do locale pode-se observar a presença de dois
subgrafos.
As principais vantagens na estruturação de ambiente em
grafo de cena são as facilidades de identificar e corrigir erros
antecipadamente e a possibilidade de buscar otimizações na
renderização da cena.
Os objetos discutidos até o momento fazem parte de uma
hierarquia de classes. Além dos itens já discutidos, destaca-se:
View: descreve os parâmetros e as políticas de visualização. Está
ligado a uma classe ViewPlatform, que define um ponto de visão
dentro de um locale. Em conjunto com um nó Transfom3D,o
ViewPlatform define um ponto de referência para o posicionamento
e orientação do usuário dentro do mundo virtual.
PhysicalBody: recebe parâmetros para ajuste do ponto de visão do
usuário como por exemplo, localização dos olhos.
166

PhysicalUniverse: descreve o ambiente do usuário. Esta descrição

serve de suporte para a classe View. Descreve dispositivos de
visualização (monitores, óculos), sensores de entrada, e
dispositivos de áudio, entre outros.
Screen3D: descreve o suporte para o dispositivo de visualização. É
sempre ligado a um Canvas 3D.
Figura 5.2 – Exemplo de um Grafo de Cena.
Canvas3D: é derivada da classe Canvas do Abstract Windowing

Toolkit (AWT), nativo do Java. Cria base para exibição do grafo de
167

cena, e pode ser entendido como o plano de imagem.

ObjectGraphObject: tem duas subclasses: Node e
NodeComponent que compõem o grafo de cena.
Node: é uma superclasse abstrata das classes Group e Leaf,
representando um item do grafo de cena
Group: é uma superclasse usada na especificação da localização e
orientação dos objetos visuais no universo virtual. Duas subclasses
da classe group são BranchGroup e Transform Group,
representados no grafo de cena por BG e TG, respectivamente.
Leaf: é uma superclasse usada para especificação da forma, som e
comportamento (behavior) dos objetos visuais no universo virtual.
Esses objetos não têm filhos.
NodeComponent: é uma superclasse usada para especificação de
geometria, aparência, textura e propriedades do material de um nó
shape3D, ou seja, um conjunto de atributos para os nodes. Os
NodeComponents não são parte do grafo de cena, sendo somente
referenciados.
Transform3D: os objetos dessa classe representam transformações
de geometria 3D, como translação, rotação e escala. Geralmente
estes objetos são usados em conjunto com um objeto
TransformGroup.
Alpha: objetos desta classe são usados para criar uma função
variante de tempo. Uma classe Alpha produz um valor entre zero e
um, dependente do tempo e parâmetros do objeto. São comumente
usados com objetos interpoladores, para fornecer animações de
objetos visuais.
Uma vez definidos e apresentados os principais
componentes, pode considerar que o desenvolvimento básico de
um programa em Java 3D consiste nos seguintes passos
168

(BOUVIER, 1999): a) criar um objeto Canvas 3D; b) criar um

objeto Virtual Universe; c) criar um objeto Locale e relacioná-lo ao
objeto Virtual Universe; d) construir um View branch graph; e)
criar um objeto View; f) criar um objeto ViewPlatform; g) criar um
objeto PhysicalBody; h) criar um objeto PhysicalEnvironment; i)
relacionar os objetos ViewPlatform, PhysicalBody,
PhysicalEnvironment ao objeto View; j) construir o(s) Content
Branch Graph(s); k) compilar o(s) Branch Graph(s); l) iInserir os
subgrafos em um objeto Locale.
5.5. Geração de Conteúdo

Existe em Java 3D um rico conjunto de características, que permite
a construção de conteúdos 3D complexos. Vale ressaltar que não
existe um formato próprio para conteúdo em Java 3D. Existem,
basicamente, duas formas para a geração desse conteúdo: usando
loaders para carregar um conteúdo previamente construído e a
construção do conteúdo dentro da própria aplicação Java, usando as
classes Java 3D para criação de geometrias.
Para o caso do uso de loaders, são necessárias classes File
loader que habilitam a leitura de conteúdos a partir de arquivos em
outros formatos, tais como: VRML (Virtual Reality Modeling
Language), OBJ (Alias/Wavefront object), LW3D (Lightwave 3D
scene) e ainda pode-se construir um File loader próprio para a
aplicação que se está desenvolvendo.
Já no caso da criação de conteúdo dentro da própria
aplicação, pode-se usar um nó leaf Shape3D que constrói um
objeto 3D baseado na geometria (Geometry) que se refere à forma
ou estrutura da forma e, na aparência (Appearance), que se refere à
coloração, transparência e sombreamento da forma.
Existem 14 diferentes tipos de geometria, agrupados em:
Simple geometry (PointArray , LineArray , TriangleArray e
169

QuadArray); Strip geometry (LineStripArray , TriangleStripArray e

TriangleFanArray); Indexed simple geometry (IndexedPointArray ,
IndexedLineArray , IndexedTriangleArray e IndexedQuadArray) ;
e Indexed stripped geometry (IndexedLineStripArray ,
IndexedTriangleStripArray e IndexedTriangleFanArray).
5.5. Manipulação de Capabilities

O grafo de cena construído por um programa Java 3D poderia ser
usado diretamente para renderização. Esta representação,
entretanto, não é muito eficiente. A flexibilidade construída em
cada objeto de um grafo de cena torna a representação do universo
virtual sub-otimizada. Portanto uma representação mais eficiente é
usada, para melhorar a performance de renderização.
Java 3D tem uma representação interna para um universo
virtual e métodos para fazer a conversão. Há dois modos para que o
sistema faça a conversão para a representação interna. Um deles é
compilar cada grafo. O outro é inserir o grafo em um universo
virtual para torná-lo vivo. A compilação de um branch graph
otimiza-o para uma renderização mais rápida.
Essa conversão, ocasiona alguns efeitos. Um deles é fixar o
valor das transformações e outros objetos no grafo. A menos que
especificado, o programa não tem a permissão para alterar os
valores dos objetos do grafo depois que foram tornados vivos.
Há casos quando um programa precisa alterar valores de um
objeto, depois que este se torna vivo, como por exemplo, para
alterar o valor de um objeto TransformGroup, quando tem-se
animações. Para isso acontecer, a transformação deve ser capaz de
mudar, depois que o objeto esteja vivo.
Para tanto, cada SceneGraphObject tem um conjunto de bits
de permissão (capabilities). Os valores desses bits determinam
170

quais as permissões existem para o objeto depois que este é

compilado ou se torna vivo. O conjunto de permissões varia por
classe.
Tais permissões controlam o acesso aos atributos de um nó
após já ter se tornado vivo ou sido compilado. É interessante
observar que quanto menor a quantidade de permissões, mais
otimizações poderão ser feitas.
Vale ressaltar ainda, que cada nó tem suas próprias
permissões para leitura e escrita, que podem ser herdadas de sua
classe pai
5.6. Interações
Em Java 3D, interações e animações são determinadas com
objetos da classe Behavior. A classe Behavior é uma classe
abstrata, que fornece mecanismos para mudar o grafo de cena.
O propósito de um objeto Behavior em um grafo de cena é
alterá-lo, ou alterar seus objetos, em resposta a alguns estímulos.
Um estímulo pode ser o pressionar de uma tecla, um movimento de
mouse, a colisão de objetos, a passagem do tempo, algum outro
evento, ou uma combinação de todos esses, entre outros. As
alterações produzidas podem ser: adição ou remoção de objetos ao
grafo de cena, mudança dos atributos desses objetos e rearranjo
deles. Estas possibilidades são limitadas apenas pelas permissões
dos objetos do grafo.
A Tabela 5.1 abrange algumas das possibilidades de
Behavior (um estímulo resulta em uma mudança).
Por meio de behaviors, Java 3D fornece suporte aos
dispositivos convencionais (mouse, teclado) e não convencionais
(joysticks, luvas). Java 3D provê acesso a teclado e mouse usando a
API padrão para suporte a esses dispositivos por meio dos
171

behaviors KeyNavigatorBehavior e MouseBehavior,

respectivamente.
Por meio de behaviors, Java 3D fornece suporte aos
dispositivos convencionais (mouse, teclado) e não convencionais
(joysticks, luvas). Java 3D provê acesso a teclado e mouse usando a
API padrão para suporte a esses dispositivos por meio dos
behaviors KeyNavigatorBehavior e MouseBehavior,
respectivamente.
Tabela 5.1 – Algumas possibilidades de Behavior.

Adicionalmente, Java 3D provê acesso a uma variedade de
dispositivos de entrada, como trackers e joysticks. Os dispositivos
possuem valores de entrada contínuos e bem definidos. Joysticks,
por exemplo, produzem dois valores contínuos entre –1.0 e 1.0 que
172

Java 3D armazena internamente como uma matriz de

transformação, com um dos valores como sendo a translação do
eixo X e outro como sendo a translação do eixo Y.
Uma classe behavior pode ser ainda personalizada. Para
tanto é necessário, no mínimo, a implementação dos métodos
initialization e processStimulus, da classe abstrata Behavior. Essa
classe personalizada, tem um construtor e pode ter outros métodos.
A classe behavior precisa de uma referência a seu objeto de
mudança para poder executar as mudanças. O construtor pode ser
usado para isso. Caso contrário, é necessário que outro método
guarde essa informação.
O método initialization é executado quando o grafo de cena
contendo a classe behavior se torna vivo. Ele é responsável por
ajustar o evento inicial e a condição inicial das variáveis que fazem
parte da classe.
O método processStimulus, por sua vez, é invocado quando
o evento de disparo especificado para o behavior ocorre. Ele é o
responsável a responder ao evento de disparo.
Outro método que pode ser implementado é o WakeupOn.
Ele é usado nos métodos initialize e processStimulus para ativar o
disparo para o behavior.
Vale ressaltar que os mecanismos de implementação de
uma classe Behavior são simples. Entretanto, deve-se saber que
uma classe implementada de forma errada pode degradar a
performance do sistema. Dois aspectos devem ser evitados:
consumo demasiado de memória e condições de disparo
desnecessárias.
5.7. Picking
É comum em ambientes virtuais, existir mais de um objeto visual
173

presente. Para podermos manipular esses objetos individualmente,

utiliza-se de uma técnica chamada Picking.
A classe Picking é implementada por um behavior
tipicamente disparado por eventos causados pelos botões do mouse.
Neste caso, o usuário posiciona o indicador do mouse em cima do
objeto visual de sua escolha e pressiona um botão, disparando a
"operação" picking.
Essa operação consiste no seguinte: um raio é projetado no
mundo virtual com origem na posição do ponteiro do mouse. A
intersecção desse raio com os objetos do mundo virtual é
computada. O objeto visual mais perto do plano de imagem que faz
intersecção com o raio será o escolhido para interação.
O teste de intersecção requer uma grande demanda de
processamento. A técnica de picking consome grande quantidade
de recursos, e depende da complexidade da cena.
5.8. Suporte para Dispositivos

As principais formas de interação com o AV são o mouse e a barra
de movimentação. Por meio delas o participante pode atuar na
molécula em seis graus de liberdade (6DOF -Degrees Of Freedom),
efetuando rotações e translações em qualquer sentido dos eixos X,
Y e Z.
A finalidade da barra de movimentação é mudar o ponto de
vista do participante em relação ao AV como um todo, enquanto o
mouse muda o ponto de vista do participante em relação ao objeto.
Além do mouse e da barra de movimentação, existe também
a possibilidade do usuário utilizar joystick ou luvas como
dispositivos de entrada. Para tanto, é necessária a implementação
das classes joystick e gloves com o respectivo suporte para o
dispositivo utilizado [RODELLO, 2003].
174

5.9. Exemplo
Para os mundos mais simples, e que não requerem o tratamento
com os valores de coordenadas, existe a possibilidade de utilização
da classe SimpleUniverse [PALMER, 2001]. Ela permite uma
construção mais simples e rápida com a fusão de alguns nós a
serem criados no caso do VirtualUniverse. Na Figura 5.3 a classe
ConeTest, e o resultado da sua interpretação na Figura 5.4.
Figura 5.3 – Exemplo de uma Classe ConeTest.
175

Figura 5.4 – Resultado obtido após execução da classe

ConeTest.
Referências
Bouvier, J. D. (2002), “Getting Started with the Java 3D™ API -A
Tutorial for Beginners”,
http://java.sun.com/products/java-media/3D/collateral/index.htm
l.
Palmer, I. (2001) “Essential Java 3D Fast: Developing 3D Graphics
Applications in Java”, Springer.
Rodello, I. A.; Brega, J. R. F.; Sementille, A. C. (2003) “Interação
com dispositivos de entrada não convencionais em ambientes
virtuais desenvolvidos com Java 3D”, Proccedings SVR 2003 –
VI Symposium on Virtual Reality. 15-18 October. Ribeirão
176

Preto, SP – Brasil.
Selman, D. (2002) “Java 3D Programming”, Manning Publications
Co..
Sun (2006) Sun Microsystems Inc. Disponível em
<http://www.sun.com.br> . Acesso em 13 de Maio de 2006.
177

Capítulo
6
ARToolkit: Conceitos e
Ferramenta de Autoria
Colaborativa
Rafael Santin1, Claudio Kirner2
1
Faculdade Anhanguera de Piracicaba
rasantin@gmail.com
2
Universidade Metodista de Piracicaba - UNIMEP
ckirner@gmail.com
Resumo
ARToolKit é um software bastante popular indicado para o desenvolvimento de

aplicações de Realidade Aumentada (RA). Ele constitui-se em uma biblioteca em
C/C++, gratuita e de código aberto, cujas funções são usadas em programas
aplicativos desenvolvidos pelo usuário. Além disso, é possível reconfigurar as
aplicações, através da edição de alguns arquivos e pastas, gerando novas
aplicações. No sentido de facilitar o desenvolvimento de aplicações de RA, foi
gerado um sistema de autoria com várias funcionalidades pré-programadas,
funcionando em rede e com capacidade de configuração em dois níveis. Essas
características permitem que usuários não programadores possam elaborar
aplicações de RA individuais e colaborativas. Este tutorial apresenta uma visão
do ARToolKit e descreve o Sistema de Autoria Colaborativa de Realidade
Aumentada para o Usuário Final.
178

6.1. Introdução
O ARToolKit (ARToolKit, 2007) é uma biblioteca de desenvolvimento de
aplicações de Realidade Aumentada (RA), bastante popular na
comunidade de RA. Isto acontece pelo fato da biblioteca fornecer
soluções de rastreamento 3D, em tempo real, com baixo custo
computacional (LEPETIT, 2005). Além disso, o ARToolKit é amplamente
utilizado por ser distribuído livremente para fins não comerciais,
incentivando a liberdade para os usuários executarem, estudarem e
modificarem os códigos disponíveis na biblioteca de acordo com as suas
necessidades.
O rastreamento óptico oferecido pelo ARToolkit possibilita extrair

de forma rápida a posição e orientação de padrões marcadores, apenas
com o uso de um computador e uma web câmera simples. Nesse caso, a
interação não sofre restrições de cabos utilizados nos diversos tipos de
dispositivos de rastreamento (HORNECKER, 2005). Por esses motivos e
o baixo custo do hardware necessário para a sua implementação, o
ARToolKit tem sido utilizado para o desenvolvimento de várias
aplicações de Realidade Aumentada, sendo o software mais popular na
sua categoria.
6.2. Artoolkit
O ARToolKit é uma biblioteca de programação multi-plataforma,
considerada um kit de ferramenta de RA, sendo bastante utilizada e
discutida por desenvolvedores e pesquisadores da comunidade de
Realidade Aumentada. O ARToolKit possui o seu código livre para
modificações e uso no desenvolvimento de aplicações não comerciais
sob licença GPL (GNU, 2007), enquanto que a versão proprietária para a
179

comercialização é oferecida pela incorporação ARToolworks

(ARToolworks, 2007).
6.2.1 Fundamentos do ARToolKit

A biblioteca ARToolKit implementada em C e C++ oferece suporte a
programadores para o desenvolvimento de aplicações de RA. Essa
biblioteca utiliza o rastreamento óptico, que implementa técnicas de
visão computacional para identificar e estimar em tempo real a posição e
a orientação de um marcador (moldura quadrada desenhada em papel)
em relação ao dispositivo de captura de vídeo. Assim, o cálculo da
correlação entre os dados estimados do marcador real e a sua imagem,
possibilita posicionar objetos virtuais alinhados à imagem do marcador
(KATO, 2000).
A saída de aplicações desenvolvidas com ARTooKit pode ser

visualizada através de dispositivos de visão indireta, não imersivos, ou
visão direta, imersivos. A diferença de imersão entre as duas formas de
visão, está relacionada à autenticidade impelida ao sentido visual do
usuário. Os dispositivos de visão indireta, como os monitores, não
imersivos, promovem a visualização conjugada das cenas virtual e real
fora do espaço alvo de atuação. Já a visualização direta, imersiva, pode
ser obtida por meio dos dispositivos como os HMDs, que fornecem a
visualização combinada das cenas diretamente no espaço alvo de
atuação da aplicação (KIRNER, 2006).
Os objetos virtuais visualizados em aplicações desenvolvidas com o

ARToolKit podem ser implementados com OPENGL ou com VRML. A
visualização dos objetos virtuais é realizada no momento da inserção de
seus respectivos marcadores no campo de captura da câmera de vídeo.
180

6.2.1.1 Marcadores
O rastreamento implementado no ARToolKit estima a posição de

marcadores, tornando possível desenvolver aplicações que necessitem
conhecer a posição e orientação de elementos ou ações reais, que são
representados na cena por marcadores. Por exemplo, as aplicações de
RA, que utilizam o marcador para posicionar e orientar elementos virtuais
na cena do mundo real, tornando um meio de interação do usuário com
essas aplicações.
Os marcadores reconhecidos pelo ARToolKit consistem em

figuras geométricas quadradas, que contém, no seu interior, símbolos
para identificá-los. A Figura 6.1 mostra um exemplo de marcador com
símbolos para a sua identificação.
Figura 6.1. Exemplo de marcador.
Como o ARToolKit extrai, da imagem de vídeo limiarizada (em

preto e branco), as bordas do quadrado em preto, utiliza-se uma moldura
em branco envolvendo esse quadrado para promover o contraste no
181

próprio marcador, viabilizando o seu reconhecimento sobre superfícies

de cores escuras. A Figura 6.2a demonstra dois marcadores dispostos
sobre uma superfície escura. A diferença entre os marcadores consiste
no fato do marcador com o símbolo RA não possuir a moldura em branco
e outro conter essa moldura. O marcador com o símbolo RA não pode
ser identificado sobre a superfície escura, pois não é possível extrair as
suas bordas na imagem limiarizada (Figura 6.2b).
(a) (b)
Figura 6.2. Utilidade da moldura branca do marcador.
O reconhecimento de padrões identifica os quatro vértices de

regiões quadradas, contidas na imagem de vídeo, e compara os
símbolos do seu interior com os gabaritos dos marcadores cadastrados
pelo usuário (CLAUS, 2005). Caso o retângulo extraído seja semelhante
com algum marcador cadastrado, o sistema passa a calcular a sua
orientação e posição.
6.2.1.2 Rastreamento
O rastreamento no ARToolKit é responsável pelo processamento da

imagem, que extrai algumas informações com relação a detecção, e pela
identificação de características dos marcadores, além de estimar sua
182

posição e orientação. Nesse caso, a obtenção da posição e orientação

do marcador é realizada através da análise da imagem de vídeo, que
estabelece o relacionamento entre as coordenadas do marcador e as
coordenadas da câmera, como demonstrado na Figura 6.3 (KATO,
1999).
Figura 6.3. Relacionamento entre os sistemas de coordenadas do marcador

e da câmera.
O relacionamento entre as coordenadas do marcador e as

coordenadas da câmera é realizado por intermédio de uma matriz 3x4,
denominada “matriz transformação”. A Figura 6.4 mostra a multiplicação
de uma matriz transformação "T" por um ponto 3D no marcador
(Xm,Ym,Zm), obtendo o ponto correspondente no sistema de
coordenadas da câmera (Xc,Yc,Zc) .
183

Figura 6.4. Multiplicação de matrizes
Para estimar a posição e orientação do marcador, através da

análise da imagem de câmera, torna-se necessário utilizar os parâmetros
de câmera, a fim de corrigir as distorções inerentes a câmera (LEPETIT,
2005). Assim, é possível estimar, com alguma precisão, o
relacionamento entre as coordenadas 3D do mundo e as coordenadas
2D da imagem (ABDULLAH, 2002). O ARToolKit utiliza esses
parâmetros de câmera no cálculo da matriz transformação (KATO,
1999).
As funções responsáveis pelo cálculo da matriz transformação

no ARToolKit, são “arGetTransMat” e “arGetTransMatCont”. A função
“arGetTransMat” é utilizada no momento em que o marcador é
detectado, enquanto a “arGetTransMatCont” deverá ser chamada
posteriormente, caso o marcador permaneça visível nos quadros de
vídeos subseqüentes, o que possibilita o uso de informações obtidas
anteriormente para agilizar o cálculo da matriz (KATO, 2002).
Estimada a matriz transformação, a API “OPENGL” é utilizada

para ajustar a câmera virtual, posicionar e desenhar o objeto virtual
alinhado na visualização do marcador real (PIEKARSKI, 2002).
184

6.2.1.3 Funcionamento do ARToolKit
A biblioteca de programação ARToolKit disponibiliza um conjunto de

funções que oferecem suporte ao desenvolvimento de aplicações de
Realidade Aumentada. Para implementar uma aplicação simples de RA,
o programador necessita conhecer as funcionalidades de algumas
funções dessa biblioteca e seguir os seguintes passos:
Iniciar a configuração do vídeo; ler o arquivo de cadastramento

dos marcadores; ler os parâmetros da câmera.
Capturar um quadro do vídeo.
Detectar e identificar os marcadores
Calcular a transformação do marcador relativa à câmera.
Desenhar o objeto virtual referente ao marcador.
Encerrar a captura de vídeo.
Usando a Tabela 6.1, os passos de número 2 a 5 são repetidos

continuamente até a aplicação ser finalizada, enquanto os passos 1 e 6
fazem respectivamente a inicialização e o término da aplicação (KATO,
2000).
O ARToolKit é distribuído com aplicações exemplos, que

implementam os passos citados anteriormente, servindo de modelo aos
programadores, tanto para o conhecimento de funções da biblioteca,
quanto para o auxílio no desenvolvimento de novas aplicações de RA. A
tabela 6.1 mostra os passos e as respectivas funções executadas na
aplicação "simple" disponibilizada nas distribuições do ARToolKit.
185

Tabela 6.1. Passos e as funções implementadas num exemplo de aplicação

distribuída com o ARToolKit .
Passos Função
1. Inicializa a aplicação Init
2.Captura do quadro de vídeo. ArVideoGetImage
3. Detecta os marcadores ArDetectMarker
4.Calcula a matriz transformação ArGetTransMat
5. Desenha o objeto virtual. Draw
6. Fecha a captura de vídeo Cleanup
O funcionamento de aplicações de RA, como alguns dos

exemplos inclusos na distribuição do ARToolKit, executa várias etapas
relacionadas às ilustrações da Figura 6.5. Na primeira etapa, a imagem
de vídeo capturada, conforme a Figura 6.5a, é convertida em uma
imagem binária (em preto e branco), de acordo com o valor do limiar ou
(threshold), resultando numa imagem como a da Figura 6.5b. Por
conseguinte, os quadriláteros, nessa imagem binária, são detectados e
comparados com gabaritos de marcadores cadastrados no sistema pelo
usuário. Caso haja a identidade entre supostos marcadores e os
marcadores conhecidos pelo sistema, a aplicação considera que
encontrou um marcador na imagem. A próxima etapa, então, consiste na
obtenção da posição e orientação de marcadores (KATO, 2000). Assim,
é possível desenhar o objeto virtual sobreposto a seu respectivo
marcador, como mostra a Figura 6.5c.
186

a) (b) (c)
Figura 6.5. Etapas envolvidas no funcionamento de uma aplicação de RA :
a) imagem da cena com o marcador, b) a imagem limiarizada e c) objeto
virtual sobrepondo o marcador.
A Figura 6.6 mostra um diagrama, detalhando as principais
etapas realizadas no funcionamento da aplicação.
Figura 6.6. Funcionamento de uma aplicação de RA.
187

6.2.2 Instalação e configuração do ARToolKit

O site do ARToolKit, no laboratório HITL da universidade de Washington
(ARToolKit, 2007), disponibiliza o ARToolKit, a sua documentação,
projetos e artigos relacionados à biblioteca. A área download desse site,
além de manter os links de versões mais antigas e algumas outras
contribuições, também disponibiliza um link para o site, onde estão
disponíveis as versões mais recentes.
6.2.2.1 Instalação
Para a instalação do ARToolKit deve-se, primeiramente, baixar a versão

desejada. O próximo passo é descompactar o arquivo no local de
conveniência. Esse local será referenciado abaixo como {ARToolKit} A
Figura 6.7 mostra a estrutura de diretórios da versão 2.72.1 do
ARToolKit, após descompactação.
Figura 6.7. Estrutura do diretório da versão 2.72.1 do ARToolKit após a

instalação.
6.2.2.2 Configurações na plataforma Windows
188

Realizada a descompactação, o próximo passo consiste em configurar o

sistema, instalando os pré-requisitos exigidos para a compilação do
ARToolKit. Os pré-requisitos necessários para a compilação no
Windows, Linux/SGI Irix e Mac OS X são descritos no arquivo
“README”, contido na pasta “ARToolKit”. Os pré-requisitos e passos
necessários para a compilação são demonstrados no anexo 1.
6.2.3 Aplicações Incluídas no ARToolKit

O ARToolKit é distribuído com diversas aplicações. A versão 2.72.1, por
exemplo, após a compilação, disponibiliza várias aplicações executáveis
na pasta “bin”. Essas aplicações possuem diferentes funcionalidades,
permitindo que os usuários as utilizem tanto na configuração, quanto no
auxílio no desenvolvimento de suas próprias aplicações. No total são
vinte e duas aplicações, das quais seis são denominadas aplicações
utilitárias e as demais são exemplos de aplicações de RA.
6.2.3.1 Aplicações utilitárias
As aplicações utilitárias são responsáveis pela configuração e teste do

sistema. Os utilitários de configuração são o “mkpatt, calib_camera2,
calib_cparam e calib_distortion”. Já os utilitários de teste do sistema são
o “graphicTest” e “videoTest”. Os códigos desses programas estão em
“{ARToolKit}\util”. O “mkpatt” é um programa usado na geração dos
arquivos bitmaps (mapa de bits), que relacionam os marcadores aos
objetos virtuais. Cada arquivo bitmap contém um conjunto de exemplos
de imagens de marcador. Esse conjunto é conhecido como treinamento
do marcador. Uma vez executado o “mkpatt”, será pedido para entrar
com o arquivo contendo os parâmetros de câmera. Nesse momento,
deve-se escrever o caminho para o arquivo, caso esse seja diferente da
189

configuração default (“Data/câmera_para”), senão tecla-se o “enter”. A

Figura 6.8 demonstra o início do programa.
Figura 6.8. Início da execução do mkpatt
O programa exibe uma janela com a imagem do vídeo. O

marcador deverá ser enquadrado nessa imagem, de modo a aparecer
um retângulo com lados vermelhos, à esquerda e acima, e verdes, à
direita e abaixo, nas bordas do marcador, como mostra Figura 6.9.
Figura 6.9. Marcador identificado pelo “mkpatt”
O botão esquerdo no mouse deverá ser apertado e

posteriormente será pedida a entrada de um nome para o arquivo.
Realizado esse passo, um arquivo será criado na pasta “bin”. Como os
190

arquivos, com dados de configurações das aplicações, geralmente estão

localizados na pasta “Data”, deve-se transferir o arquivo gerado para
esta pasta.
Os programas “calib_camera2, calib_cparam e calib_distortion”

são utilizados para a calibração de câmera. As etapas relacionadas à
calibração de câmera são detalhadas em (CONSULARO, 2004).
O utilitário “graphicTest” exibe uma janela com um objeto 3D

desenhado em seu interior, enquanto o “videoTest” mostra a uma janela
com a imagem capturada pela câmera. Os resultados dos testes que
esses programas realizam são as próprias execuções. Caso ocorra
algum erro durante a execução de um desses utilitários, provavelmente
ocorrerá o mesmo erro na execução dos outros programas fornecidos
pela biblioteca.
6.2.3.2 Exemplos de aplicações de RA
As aplicações de RA, fornecidas junto ao ARToolKit, são exemplos que

não só viabilizam o entendimento no funcionamento das funções do
ARToolKit, mas também servem como modelo para a produção de novas
aplicações.
Os exemplos executáveis, contidos na pasta “bin”, são: “collide,

exview, loadmultiple, modetest, multi, optical, paddle, paddledemo,
paddleinteraction, range, relation, simple, simple2, simplelite, simplevrml
e twoview”. Cada exemplo disponibiliza diferentes funções relacionadas
à interação da aplicação, servindo como base aos usuários que desejem
implementar novas funcionalidades em suas aplicações. Os códigos
desses programas estão localizados em “{ARToolKit}\examples”. A
próxima seção demonstrará algumas funcionalidades desses exemplos.
191

- Teste de Colisão
A aplicação “collideTest” possui, como característica principal, a

verificação de colisão entre dois marcadores. A função responsável em
verificar a colisão é denominada “checkCollisions”. Essa função recebe
as estruturas relacionadas às informações de cada um dos dois
marcadores, além de um número representante do fator de colisão. O
retorno dessa função é um número inteiro “1”, caso os marcadores esteja
em colisão e “0”, caso contrário. A Figura 6.10 mostra a aplicação em
execução, quando a distância entre os marcadores supera o limite do
fator de colisão, sendo desenhado um cubo sobre os marcadores,
conforme a Figura 6.10a. Quando a distância entre os marcadores for
inferior ao limite, será desenhada uma esfera sobre os marcadores,
conforme a Figura 6.10b.
(a) (b)
Figura 6.10. Execução da aplicação “collideTest”: a) cubos desenhados
sobre os marcadores distantes e b) esferas desenhadas sobre marcadores
próximos.
192

O exemplo “collide” utiliza os marcadores cadastrados no arquivo

“object_data2” contido em “{ARToolKit}\bin\Data”. Dessa forma, o usuário
pode associar os seus próprios marcadores, utilizando para isso o
“mk_patt” na geração do arquivo bitmaps (mapa de bits) dos
marcadores, os quais deverão substituir os marcadores configurados no
“object_data2”.
- Uso da Pá
O “paddleDemo” (uso da pá) é um dos exemplos que insere um

marcador com funcionalidades especializadas a técnicas tangíveis. Esse
marcador será denominado pá. A pá é utilizada para interagir com
objetos virtuais atrelados a um cartão, contendo vários marcadores,
denominado de cartão base. Essa aplicação disponibiliza técnicas que
permitem identificar a inclinação da pá, em relação ao cartão base e,
assim, atribuir algumas ações, como no caso de despejar uma esfera no
cartão base ou pegá-la. As funções que implementam essas técnicas
são a "check_incline" e a "check_pickup". Essas funções encontram-se
no arquivo "command_sub.c" em “{ARToolKit}\exemple\paddleDemo”. A
Figura 6.11 mostra a seqüência de execução do “paddleDemo”.
193

Figura 6.11. Execução do exemplo “paddleDemo”, mostrando a esfera

sobre a pá, a inclinação para despejar a esfera na base e a esfera fixada na
base.
O arquivo que relaciona a pá na aplicação é o “paddle_data”,

contido na pasta “Data” em “{ARToolKit}\bin\Data”. Já o cartão base,
configurado pelo arquivo “marker.dat”, está contido na pasta “multi”
localizada em “{ARToolKit}\bin\Data\multi”.
- simpleVRML
O “simpleVRML” é um programa que possibilita visualizar objetos

virtuais, escritos na linguagem VRML, sobrepostos aos marcadores.
Esse exemplo utiliza a biblioteca OpenVRML para a renderização dos
194

objetos VRML. A Figura 6.12 exibe o resultado da execução do

“simpleVRML”.
Figura 6.12. Resultado da execução do simpleVRML
Essa aplicação utiliza o arquivo de configuração

“object_data_vrml” para atrelar um marcador a um objeto virtual.
Localizado em “{ARToolKit}\bin\Data”, esse arquivo armazena o
relacionamento entre o arquivo bitmap do marcador, disposto no diretório
“Data”, e o arquivo de referência ao objeto VRML, localizado em
“{ARToolKit}\bin\wrl”. A Figura 6.13 mostra o arquivo “object_data_vrml”,
que contém dois marcadores cadastrados: o “patt.hiro” e o “patt.kanji”. O
marcador “patt.hiro” está associado a um arquivo de referência VRML,
denominado “bud_B.dat”, enquanto o marcador “patt.kanji” encontra-se
associado ao arquivo “snoman.dat”.
Em virtude dessa associação de arquivos, é possível adicionar

objetos virtuais de maneira muito simples,
195

bastando editar o arquivo “object_data_vrml”. Os demais exemplos

disponibilizados no ARToolKit possuem os objetos virtuais
implementados diretamente em seu código, de forma que, para adicionar
novos elementos virtuais, é necessário incluir o código do objeto virtual
em openGL na aplicação e a compilar novamente.
Figura 6.13. Referência de marcadores e objetos virtuais VRML
6.2.4 Software baseado no ARToolKit

Existe Software de Realidade Aumentada que estende o rastreamento
do ARToolKit a diferentes abordagens funcionais e estruturais.
Alguns exemplos desse software são: O ARToolKitPlus,

considerado uma biblioteca de RA otimizada para uso em dispositivos
portáteis como PDAs e alguns telefones celulares (WAGNER, 2003); o
jARToolKit, que possibilita escrever aplicações de RA em java,
acessando funções da biblioteca ARToolKit através da interface JNI
(GEIGER, 2002); o ARToolKit Phyton, um “bind” Python que encapsula
196

as funções do ARToolKit, permitindo a exploração das vantagens do

Python nas implementações, que podem ser feitas sem a compilação de
código (KIRNER, 2007); osgART framework baseado no ARToolKit, que
implementa a biblioteca gráfica OpenSceneGraph, apresentando alta
qualidade na renderização de objetos virtuais e possibilidade de importar
e exportar arquivos 3D gerados pelo 3D Studio Max e Maya (LOOSER,
2006). A Figura 6.14 mostra a execução de exemplos do osgART.
(a) (b)
Figura 6.14. Resultado da execução de exemplos do osgART: a) Exemplo
osgARTsimpleNPR e b) Exemplo osgARTvideoPlane.
6.3. Sistema de Autoria Colaborativa com Realidade

Aumentada – Sacra
As ferramentas de autoria são desenvolvidas para facilitar e agilizar o
trabalho de usuários de computadores, permitindo que usuários, sem
conhecimentos específicos em programação, encontrem a liberdade
para o desenvolvimento das suas próprias aplicações. Essas
ferramentas, geralmente, utilizam interfaces gráficas para associar
197

operações computacionais a elementos visuais, visto que os apelos

visuais são estimulantes e reforçam a percepção do usuário.
O uso da interface tangível de RA em autoria permite

potencializar o incremento da percepção dos usuários, visto que utilizam
a intuição natural para a manipulação de objetos virtuais, que povoam
próprio ambiente real onde estão acostumados a trabalhar.
Além das ferramentas de autoria que facilitam e agilizam os

trabalhos de seus usuários, existem as ferramentas colaborativas que
viabilizam o compartilhamento do trabalho entre seus usuários. As
ferramentas colaborativas oferecem técnicas de cooperação,
coordenação e comunicação para que participantes possam contribuir de
maneira responsável no desenvolvimento de um trabalho em comum.
Essa seção aborda a elaboração de um Sistema de Autoria

Colaborativa com Realidade Aumentada, que será referenciado no
transcorrer do capítulo como SACRA. O sistema desenvolvido oferece
autoria colaborativa para a construção de mundos virtuais, utilizando a
interface tangível de Realidade Aumentada.
6.3.1 Caracterização do ambiente.

O SACRA oferece um ambiente de RA tangível, para a autoria de
mundos virtuais, possibilitando a colaboração face a face e remota.
O seu desenvolvimento foi realizado com auxilio da biblioteca

ARToolKit, devido a características como facilidade de programação e
utilização de dispositivos de baixo custo, usando basicamente uma
webcam e um computador. Embora o Studierstube forneça suporte a
colaboração remota, recurso que o ARToolKit não disponibiliza, o
198

rastreamento oferecido com o custo mais acessível, dentre os vários

suportados pelo Opentracker, consiste no próprio rastreamento óptico do
ARToolKit. Assim, devido à facilidade de programação, o ARToolKit foi a
biblioteca adotada para o desenvolvimento do trabalho.
A interação do usuário no ambiente do SACRA é realizada

através do uso de marcadores, caracterizando a interface tangível de
RA. Por esse motivo, um ponto relevante adotado pelo sistema é a
manutenção da presença do usuário no ambiente de RA. Assim, buscou-
se minimizar a descontinuidade a sensação de presença no ambiente,
ocasionada pelas mudanças entre tipos de interfaces e dispositivos
utilizados.
O SACRA disponibiliza a seus usuários técnicas de interação, a

partir de operações envolvendo os propriedade dos marcadores como
visibilidade, posição e orientação. Essas operações permitem aos
usuários interagirem no ambiente, através do controle da presença,
mudança de características e manipulação dos objetos virtuais.
A autoria no SACRA oferece suporte a colaboração, permitindo

que outros usuários possam contribuir na construção de mundos virtuais.
A visualização do ambiente em modo de projeção, ou através de
monitores, possibilita explorar a colaboração face a face, enquanto a
autoria remota necessitou ser implementada.
O trabalho colaborativo remoto é viável no ambiente, através do

emprego de técnicas de cooperação, coordenação e comunicação.
As técnicas de cooperação permitem que múltiplos usuários

trabalhem na elaboração de mundos virtuais em comum. Dessa maneira,
é disponível um espaço compartilhado entre os usuários, para a
199

elaboração da autoria colaborativa. O espaço compartilhado emprega

técnicas de coordenação, que restringem as ações dos usuários sobre
determinados objetos virtuais, possibilitando controlar o desenvolvimento
das tarefas.
A troca de informações entre os participantes é fundamental para

a coordenação do trabalho colaborativo.
Dessa maneira, é necessário utilizar as tecnologias de

comunicação existentes na atualidade, como os chats ou sistemas
vídeo-conferência.
Com esses requisitos, o SACRA possibilita que os usuários

realizem as seguintes formas de interação: face a face, assíncrona,
síncrona distribuída e assíncrona distribuída.
A interação face a face ocorre no mesmo local e ao mesmo

tempo; é caso da colaboração face a face. A interação assíncrona é
realizada no mesmo local, mas em tempos diferentes; nesse caso
técnicas para salvar e recuperar os trabalhos foram desenvolvidas. Na
interação síncrona distribuída, usuários remotos realizam o trabalho
colaborativo em tempo real. Para ocorrer a interação assíncrona
distribuída, o usuário pode enviar ou receber por email o trabalho de
autoria desenvolvido, independentemente de tempo e local para a
elaboração do trabalho.
Assim, o SACRA possui variadas e concisas formas de interação

a seus usuários, a fim de oferecer suporte a diversas aplicações
educacionais, possibilitando a exploração do potencial da interface de
RA aliada aos benefícios do trabalho colaborativo.
200

6.3.2 Desenvolvimento
O SACRA foi desenvolvido com base na biblioteca ARToolKit, nas
versões 2.65 e 2.72.1 ambas com suporte a VRML, e nos módulos do
NetARToolKit, para a interação remota entre os usuários.
6.3.2.1 NetARToolKit
O NetARToolKit consiste numa modificação do ARToolKit 2.65 com

VRML, que disponibiliza serviços remotos de interação com o
renderizador, possibilitando a implementação de aplicações que
promovam modificações nas características das, pré-carregadas, cenas
escritas na linguagem VRML (OLIVEIRA, 2006).
Com o uso de funcionalidades da biblioteca LibVRML97, essa

aplicação permite alterar, características de determinada parte do objeto
virtual, sem a necessidade de se aplicar uma nova leitura dos objetos
VRML, como mostrado em (SANTIN, 2005). Isto é possível com a
atuação direta no renderizador, através da execução de comandos
específicos, que são recebidos remotamente. A Figura 6.15 demonstra a
interação entre as camadas do sistema.
201

Figura 6.15. Interação entre as camadas do sistema.
A arquitetura de rede implementada no NetARToolKit consiste no

modelo peer-to-peer, sendo, nesse caso, cada aplicação um cliente e
servidor ao mesmo tempo. Dessa maneira, os recursos oferecidos pela
aplicação geram as mensagens que são enviadas para todas as outras
aplicações interconectadas.
As mensagens, nesse caso, podem ser geradas tanto pela

aplicação de RA, como também por uma outra aplicação externa. A
criação da mensagem é realizada pela classe chamada ARNetEAI, ou
por outra aplicação que implemente a funcionalidade para gerar os
comandos e parâmetros necessários, interagindo, dessa maneira, com a
aplicação de realidade aumentada.
A classe ARNetEAI, além de gerar os comandos e passá-los

para a interface de rede, que no caso é representada pela classe
ARServer, também possui o papel fundamental de interpretar os
202

comandos provindos da rede e executá-los. A execução do comando

atua no grafo de cena, a partir das funções oferecidas pela biblioteca
OpenVRML. A seguir, a Tabela 6.2 mostra alguns comandos
implementados pelo sistema.
Tabela 6.2. Comandos implementados.
Comando Função sobre o “nodo”
set_translation Transladar
set_rotation Rotacionar
set_diffuseColor Alterar a cor
A Figura 6.16 mostra um ambiente, onde uma aplicação de

realidade aumentada recebe mensagens de um software desenvolvido
em Java, além de enviar mensagens a outras aplicações de RA.
203

Figura 6.16. Estrutura de Funcionamento do Ambiente.
A utilização do NetARToolkit facilitou o desenvolvimento do

protótipo da aplicação, além de expandir a interação com os objetos
virtuais, dada a possibilidade de modificação diretamente no seu grafo
de cena.
6.3.2.2 Implementação do SACRA
O desenvolvimento do sistema de autoria colaborativa com Realidade

Aumentada utilizou a linguagem C, envolvendo modificações no projeto
simpleVRML do ARToolKit2.65vrml, através da inserção de funções para
a autoria, acoplamento de módulos de rede e serviços do netARToolKit,
troca dos módulos de vídeo da versão 2.65 pelos módulos da versão
2.72.1 e alterações nas bibliotecas libarvrml.lib e libvrml97core.lib. A
Figura 6.17 demonstra a estrutura do sistema desenvolvido.
204

Figura 6.17. Estrutura do SACRA.
O módulo de autoria é responsável pela inicialização do

interpretador de comandos, além de adicionar as funcionalidades aos
marcadores no SACRA. No caso desse trabalho, o comportamento de
determinados marcadores é utilizado para realizar a interação com os
objetos virtuais.
O comportamento dos marcadores está associado aos possíveis

estados que o sistema de rastreamento permite identificar. Por exemplo,
205

é possível identificar: a presença do marcador na cena; a distância do

marcador, em relação a outros marcadores ou objetos virtuais; e a
orientação do marcador e o seu ângulo de rotação. Esses
comportamentos do marcador podem ser utilizados em conjunto para
expandir o tipo de interação, como aliar a detecção da distância e
rotação.
As variações e possivelmente a combinação dos estados

referentes ao comportamento dos marcadores possibilitaram a criação
de uma nova categoria de marcadores, que foram denominados
marcadores de ações. Os marcadores de ações viabilizam o acesso a
formas de interação dos objetos virtuais, pois são capazes de exercer
meios fundamentais para a execução das operações sobre os elementos
virtuais. Essas operações são conhecidas como seleção, ação e
liberação.
Um marcador pode ter a funcionalidade elaborada para explorar

as três operações em conjunto, ou essas operações podem ser
executadas por diferentes tipos de marcadores de ações, dependendo
da necessidade da sua atuação. Por exemplo, a cópia de um objeto
exibido na cena poderia ser realizada por um marcador que selecione,
copie e libere o objeto na cena. Outra forma seria a utilização de um
marcador para cada uma das três etapas, ou seja, um marcador seria
responsável pela seleção, outro pela cópia e o terceiro teria a função de
liberar o objeto.
seleção: Para realizar alguma interação com o objeto virtual,

primeiramente, o usuário necessita selecionar qual será o objeto alvo da
ação. Uma forma para selecionar o objeto virtual consiste na verificação
206

da proximidade entre o marcador de ação e os objetos disponíveis na

cena.
ação: A ação a ser efetuada sobre o objeto virtual é

desempenhada através dos marcadores de ação. A função desses
marcadores consiste em oferecer os recursos necessários para o usuário
realizar a tarefa desejada.
liberação: A liberação realiza as atividades inversas a seleção.

Esse mecanismo finaliza uma determinada atuação do usuário sobre o
objeto virtual, possibilitando que o usuário execute novas tarefas no
ambiente.
As funcionalidades dos marcadores de ações são definidas por

constantes de identificação implementadas no código fonte do módulo de
autoria. Os números de identificação estão relacionados à ordenação do
cadastramento dos marcadores no arquivo “Data/vrml_data.dat” do
ARToolKit. A Figura 6.18 demonstra a definição das funcionalidades dos
marcadores.
Figura 6.18. definição das funcionalidades dos marcadores
207

A cada iteração são realizadas comparações a fim de verificar se

o marcador, que está na cena, é de ação e caso seja executá-la. A
Figura 6.19 exemplifica a estrutura principal do módulo de autoria.
Figura 6.19. Estrutura principal da Autoria
208

No SACRA, os marcadores que não possuem ações definidas,

ou seja, os que foram cadastrados a partir do oitavo marcador podem
assumir o papel de marcador de referência, que será denominado no
texto como REF O REF permite que o usuário interaja com pontos no
espaço cadastrados no sistema. Cada REF pode ter diversos pontos,
que referenciam um ou mais objetos virtuais. A Figura 6.20 mostra a
estrutura das referências no SACRA.
Figura 6.20. Estrutura do marcador REF no SACRA.
O relacionamento entre as estrutura de dados do SACRA é

demonstrado na Figura 6.21. A estrutura Object é associada a todos os
marcadores cadastrados no sistema. Caso o marcador seja REF a
estrutura reference é atribuída a esse marcador. Os pontos associados a
cada REF são representados pela estrutura position. A classe
arVrml97Viewer possibilita o acesso dos atributos dos objetos WRLs
209

carregados no sistema, que no caso são referenciados por marcadores

ou pontos.
Figura 6.21. Relacionamento entre as estruturas de dados no SACRA.
Os marcadores são atribuídos como REF através de dois

parâmetros presentes nos arquivos de extensão dat contidos na pasta
“WRL” para a associação de objetos virtuais. Esses parâmetros indicam
se o marcador é REF e, caso seja, indicam o nome do arquivo que
contém os pontos associados a esse marcador. A Figura 6.22 mostra o
210

exemplo do arquivo responsável pela associação de objetos virtuais ao

marcador, contendo os atributos relacionados a esses objetos, como a
translação, rotação, escala e o áudio. A última linha indica se o marcador
referente a determinado objeto virtual é ou não REF, primeiro parâmetro,
e o nome do arquivo que contém os pontos atrelados a essa referência,
segundo parâmetro.
Figura 6.22. Arquivo de associação de objetos virtuais ao marcador.
No SACRA, o primeiro REF cadastrado obtém a funcionalidade

de referência remota. Esse marcador consiste na referência
compartilhada entre os usuários remotos. Toda a ação realizada nessa
REF será enviada para as REFs colaborativas dos usuários remotos.
Assim, os usuários passam a usufruir de uma área compartilha em
comum entre os integrantes do ambiente.
A implementação do REF permitiu estender a capacidade de

interação do sistema, visto que o referencial de objetos virtuais no
mundo real deixou de ser exclusivamente o marcador, passando a
mesclar com pontos cadastrados.
6.3.3 Funcionalidades do SACRA.
211

A seguir, serão demonstradas as principais funcionalidades

implementadas no SACRA.
6.3.3.1 Cadastramento de pontos
Os pontos cadastrados no SACRA são, basicamente, posições extraídas

das transformações relativas entre um determinado REF, visível na cena,
e o marcador de inspeção, denominado “INSPECTOR”.
A transformação relativa entre os marcadores é calculada pela

mudança de base da matriz transformação do marcador INSPECTOR no
sistema de coordenadas da câmera, para o sistema de coordenadas do
marcador REF. A equação 1 demonstra como é realizada a mudança do
sistema de coordenadas da câmera para o sistema de coordenadas do
marcador. Para isso, é realizada a multiplicação da matriz inversa da
transformação de REF pela matriz transformação do marcador
INSPECTOR, obtendo-se a matriz M4x3 ⋅ que representa a transformação
do marcador INSPECTOR no sistema de coordenadas do marcador
REF.
O cadastramento é responsável por armazenar em arquivo o

conteúdo na matriz M, mais especificamente a posição e orientação do
marcador INSPECTOR, em relação ao REF. Existem duas maneiras
para realizar o cadastro de pontos no SACRA. A primeira possibilidade é
posicionar o marcador INSPECTOR na posição desejada, em relação a
determinada REF, e clicar com o botão esquerdo do mouse. Nesse
momento, é pedido o nome do arquivo (.dat) que deverá ser associado
ao ponto cadastrado.
212

A segunda possibilidade consiste no próprio usuário editar o

arquivo que contém as posições associadas à referência, adicionando
valores de X, Y e Z em milímetros da distância do ponto desejado até o
REF e o nome do arquivo representante dos objetos virtuais, que serão
visualizados na posição. Os valores da orientação dos objetos virtuais, a
serem exibidos nesse ponto, assumem valores default, que podem ser
alterados com a modificação da orientação do objeto através do uso do
marcador de transporte.
Durante o cadastramento, todos os pontos cadastrados na REF

remota são enviados para as REFs remotas dos usuários remotos,
permitindo que esses usuários, geograficamente separados, visualizem
os mesmos objetos nas mesmas posições, desde que possuam os
determinados objetos virtuais com os mesmos.
3.3.2 Técnicas de interação
Os marcadores de ações são responsáveis pela interação do usuário no

ambiente do SACRA. A Figura 6.23 mostra um exemplo dos marcadores
de ação e um marcador de referência com seus respectivos pontos e
objetos virtuais associados.
213

Figura 6.23. Exemplo dos marcadores de ações e referência.
Os marcadores de ações atuam nos pontos associados às

referências, através de um ponto denominado ponto de colisão, que
pode ser configurado para coincidir com o centro do marcador, ou ser
deslocado, como os círculos em azul acima dos marcadores de ações na
Figura 6.23.
A atuação desses marcadores de ações é realizada por meio da

comparação da distância entre os pontos associados ao REF e os
pontos de colisão dos marcadores de ações. Para isso, foi estipulada a
distância de colisão, que pode ser alterada, durante a execução, para o
marcador de ação interagir com determinado ponto da REF. O exemplo
da Figura 6.24 mostra o uma ilustração das variações que o raio de
atuação da distância de colisão pode assumir. Nesse caso, o marcador
de ação atuaria em pontos nos interior da circunferência de raio r.
214

Figura 6.24. Distância para a atuação do marcador de ação.
3.3.3 Funcionalidades dos marcadores de ações
- Inspector
O marcador denominado INSPECTOR é responsável pela inspeção dos

pontos associados aos marcadores de referência, além de ser utilizado
para realizar o cadastramento de novos pontos.
A inspeção de pontos consiste no mecanismo de controle da

presença de objetos virtuais na cena, permitindo o usuário ativar ou
desativar a persistência dos objetos virtuais associados aos pontos.
Ao desativar a persistência dos objetos virtuais o usuário deixa

de visualizar o objeto, exigindo que ele memorize a posição daquele
215

determinado ponto, a fim de ativá-lo futuramente. Porém, uma grande

quantidade de objetos desativados pode dificultar o trabalho do usuário,
visto que necessitaria uma morosa inspeção no ambiente, para encontrar
o objeto desejado. Para isso, foi desenvolvido um mecanismo opcional
de suporte que, no momento de desativação da persistência do ponto, é
inserida uma referência visual em sua posição.
Essa referência visual pode ser um objeto VRML.
- Control
O CONTROL consiste no marcador que permite a troca dos

objetos virtuais, caso exista mais de um objeto associado a um ponto.
Esse marcador realiza a troca seqüencial dos objetos visualizados. A
troca é realizada, através da inserção do controle na cena, seguida da
colisão com o ponto que contém a lista de objetos. Ao chegar ao fim da
lista, a próxima interação retorna ao seu inicio, mostrando, novamente, o
primeiro objeto visualizado.
- Copy
O marcador COPY permite ao usuário copiar um objeto virtual

associado a determinada REF e replicá-lo na própria REF ou inserí-lo
numa outra REF.
Para o usuário copiar um objeto, é necessário selecionar

primeiramente a REF de destino, através da aproximação do COPY e,
por conseguinte, copiar o objeto virtual desejado, por meio de colisão
com o ponto representante do objeto. A fixação do objeto na posição
desejada é realizada pela oclusão do marcador de copia.
216

A seleção do marcador de destino é visualizada pela modificação

da cor do objeto virtual associado ao REF. Para alterar o estado de
selecionado do REF, o usuário deve realizar uma nova aproximação
entre esses marcadores.
A cópia de um objeto virtual para a REF remota promove o envio

dos dados referentes ao objeto a REF remota dos usuários remotos,
permitindo que todos visualizem o objeto copiado.
- Transport
O TRANSPORT é o marcador responsável pela re-orientação e

re-posicionamento de pontos. A colisão desse marcador com um ponto
promove o acoplamento do ponto ao TRANSPORT, possibilitando ao
usuário transportar o ponto para qualquer posição em relação a um
determinado REF.
Caso o marcador de referência seja remoto, o transporte enviará

para os usuários as atualizações da orientação e da posição dos pontos.
Para o usuário transportar um ponto atrelado a REF remota, é
necessário que ele tenha inserido o determinado ponto ou que esse
esteja desbloqueado.
O transporte remoto recebeu um filtro de envio de mensagens,

que realiza o envio de mensagens, somente quando a movimentação do
ponto supera uma distância estabelecida. Assim, o SACRA não onera a
rede com o envio e recebimento de um grande número de mensagens.
- Eraser
O marcador ERASER possibilita a exclusão dos pontos e a

desalocação dos respectivos objetos virtuais alocados na memória do
217

computador. Para a exclusão de determinado ponto, é necessário

realizar a colisão do ERASER com o ponto desejado.
Um determinado ponto, pertencente à REF remota, pode ser

excluído pelo usuário que o inseriu, ou por usuários remotos, caso o
ponto esteja desbloqueado.
- Status
O marcador STATUS mostra ao usuário as principais

informações do estado do sistema. As informações são apresentadas em
um painel desenvolvido em VRML, que mostra o valor das variáveis de
persistência, suporte, rastro, bloqueio, distância de atuação do ponto de
colisão e a distância do ponto de colisão do centro do marcador.
Como essas variáveis são alteradas, durante a execução do

sistema, foi necessário utilizar mecanismos para a modificação do objeto
virtual no tempo de execução. Para isso, foram implementadas funções
para atuar em determinado nó do grafo de cena do objeto virtual. A
Figura 6.25 demonstra a função changeString, que altera o valor das
Strings do nó text nos objetos virtuais.
218

Figura 6.25. Função utilizada para a modificação da string no nó Text do

painel de status.
- Path
Assim, conforme o usuário movimente o PATH, o percurso

realizado é marcado pelos objetos associados a esse marcador.
O rastro construído oferece os recursos de controle de presença

dos objetos virtuais, permitindo que o usuário ative e desative a sua
visualização no ambiente local, ou então apague-o completamente, tanto
localmente, quanto remotamente.
O rastro elaborado representa uma forma de comunicação no

ambiente colaborativo, visto que transmite o movimento realizado pelo
PATH aos usuários remotos.
219

- Lock
A técnica de coordenação do trabalho colaborativo no SACRA é

aplicada, através do marcador denominado LOCK. Esse marcador
permite ao usuário bloquear ou desbloquear as operações remotas sobre
os seus objetos na REF remota. A restrição sobre operações remotas
sobre determinado objeto é alterada somente pelo usuário que o inseriu.
O SACRA oferece as opções de envio do objeto bloqueado ou

desbloqueado às REFs remotas, pois os usuários que necessitassem do
bloqueio perderiam o controle de seus objetos, caso fosse necessário
realizar primeiro o envio e posteriormente o bloqueio. Os usuários
remotos poderiam realizar alguma modificação nesse intervalo de tempo.
O LOCK atua sobre os pontos da REF remota, através da

colisão de seu centro de colisão com o ponto determinado. Para
visualizar se o ponto está bloqueado ou desbloqueado, o usuário deve
utilizar o marcador STATUS, aproximando-o do ponto desejado.
6.3.4 Ambiente de autoria Colaborativa
O SACRA possibilita a configuração de ambientes virtuais, através do

uso das ferramentas para a interação com objetos virtuais, denominadas
marcadores de ações.
Os marcadores de ações atuam sobre pontos atrelados a outros

tipos de marcadores conhecidos como referência. Cada referência
representa um sistema de coordenadas, que orienta o posicionamento
de seus pontos. Um ponto pode ter um ou mais objetos virtuais
associados, sendo a visualização desses objetos controlada pelo
marcador de controle.
220

As referências podem ser de dois tipos: local ou remota. A

referência local permite a elaboração e visualização de um ambiente
virtual no ambiente local. Já a referência remota consiste numa área
comum entre os usuários remotos, possibilitando a configuração e
visualização de ambientes virtuais remotamente.
6.3.4.1 Referência Local
O SACRA possibilita o uso de múltiplas referências locais, viabilizando

diversos grupos de objetos virtuais representados por essas referências.
A REF local permite a colaboração face a face, visto a

possibilidade de mais pessoas estarem trabalhando na mesma aplicação
no mesmo local e ao mesmo tempo.
Os trabalhos realizados nas REFs locais são salvos em arquivos,

possibilitando também, tanto a colaboração assíncrona, quanto a
assíncrona distribuída.
A colaboração assíncrona é viável no SACRA, pois os arquivos

salvos das REF são sempre lidos na inicialização do sistema,
viabilizando o trabalho no mesmo local, mas em tempos diferentes.
A colaboração assíncrona e distribuída pode ser realizada,

através do envio dos arquivos por e-mail, realizando, dessa maneira, o
trabalho tanto em locais, quanto em tempos diferentes.
3.4.2 Referência Remota
A referência remota oferece uma área compartilhada entre os usuários

remotos, possibilitando o desenvolvimento do trabalho colaborativo
síncrono e distribuído.
221

A Figura 6.26 demonstra a esquematização do uso da referência

remota. No esquema, cada nó adiciona um objeto virtual, que é
distribuído para os outros nós participantes do trabalho colaborativo.
Figura 6.26. Esquematização do uso da referência remota para colaboração

síncrona.
O modelo de comunicação em rede, utilizado no SACRA,

consiste no modelo peer-to-peer, enviando e recebendo mensagens de
todos os nós cadastrados no arquivo “r_hosts”. O arquivo “r_hosts”
consiste num arquivo texto, contendo os endereços IPs dos hosts e as
portas requisitadas pelo sistema. A Figura 6.27 demonstra um exemplo
do arquivo “r_hosts”.
222

Figura 6.27. Exemplo do arquivo de hosts do SACRA.
A referência remota realiza o salvamento em arquivo do trabalho

elaborado. Assim, o trabalho colaborativo, referente a essa referência,
também pode ser o assíncrono e assíncrono distribuído, como na
referência local.
A diferença entre as referências remota e local está no fato da

referência remota promover o envio de mensagens aos usuários
remotos, através da execução de ações sobre os pontos associados a
esse marcador. As mensagens enviadas pelo SACRA são os comandos
a serem executados e os seus parâmetros. A Tabela 6.3 demonstra o
nome dos comandos a suas operações e as ações que o dispararam.
Tabela 6.3. Possíveis Comandos enviados aos usuários remotos
Comandos Operações Executor
add_object Adiciona um objeto Cadastramento de pontos

e Copy
remove_object Remove um objeto Eraser
update_object Atualiza a orientação e a posição Transport
223

do objeto
lock_object Bloqueio ou desbloqueia o objeto Lock
remove_path Remove o rastro Tecla ‘c’
O marcador de referência possibilita que o usuários enviem

trabalhos já elaborados nesse marcador, através de uma funcionalidade
oferecida pelo SACRA, denominada difusão. A difusão é executada ao
pressionar a tecla ‘d’ do teclado.
Outra funcionalidade oferecida pela referência remota consiste

no envio do rastro da trajetória do marcador Path em relação à
referência. O rastro consiste numa seqüência de objetos virtuais que
possibilitam oferecer uma indicação visual de um caminho aos usuários
remotos. A Figura 6.28 demonstra o exemplo da utilização do rastro
representado pelas esferas em azul. Uma esfera vermelha percorre a
trajetória, a fim de indicar a sua direção aos usuários.
Figura 6.28. Uso do rastro para indicar a trajetória.
224

A referência remota implementa as técnicas do trabalho

colaborativo: cooperação, coordenação e a comunicação. A cooperação
é possível pela área comum aos usuários remotos oferecida pela
referência remota. A coordenação das ações dos usuários sobre os
objetos virtuais é executada através do uso do marcador Lock, que
bloqueia e desbloqueia a atuação dos usuários remotos sobre
determinados objetos. A comunicação, nesse caso, pode ser realizada
por programas externos de chats e videoconferências, além do uso
rastro para indicar a trajetória que os usuários remotos devam realizar.
6.4. Gerando Aplicações de RA com Sacra
6.4.1 Introdução
O sistema de autoria colaborativa de realidade aumentada, SACRA,
permite a interação com objetos virtuais no espaço real do usuário,
utilizando técnicas específicas de interação com marcadores. Esse
sistema busca facilitar a construção de ambientes virtuais no ambiente
real, de forma colaborativa ou não, utilizando marcadores com funções
especializadas denominados marcadores de ação.
Os marcadores de ações são capazes de exercer mecanismos

fundamentais para a execução das operações sobre os objetos virtuais.
Além dos marcadores de ações existem outros marcadores responsáveis
por referenciar um conjunto de objetos virtuais no ambiente, esses
marcadores são denominados de marcadores de referência.
6.4.2 Preparação e execução da aplicação
225

Para a execução e configuração do SACRA será necessário

seguir os passos a seguir:
Baixe e descompacte o arquivo SACRA.zip, disponível em:

http://www.ckirner.com/sacra/SACRA.zip
Imprima e recorte os marcadores do Anexo3 deste Tutorial.
Imprima a folha que contêm o marcador e as guias de

posicionamento, no Anexo 4 deste Tutorial.
Cole os marcadores e o papel com as guias de posições em

um papelão, para facilitar o uso e o rastreamento.
Conecte a câmera.
Localize e execute a aplicação “SACRA.exe”.
6.4.3 Cadastramento
6.4.3.1 Cadastramento de Marcadores
O sistema é distribuído com os marcadores fornecidos já cadastrados e

configurados. Assim, o cadastramento de novos marcadores deverá ser
realizado para o cadastramento de novos marcadores no sistema.
O cadastramento dos marcadores deve ser feita no arquivo

“vrml_data” contido na pasta “Data”. A realização do cadastro de
marcadores é enfatizada no anexo 2. A Figura 6.29 demonstra a
estrutura de arquivos do SACRA.
226

Figura 6.29. Estrutura de arquivos do SACRA.
O funcionamento do SACRA necessita que esses marcadores

sejam devidamente cadastrados, seguindo uma ordem estabelecida
pelas ações dos marcadores. A Figura 6.30 demonstra a ordem de
cadastramento dos marcadores realizada no arquivo “vrml.dat”.
número Marcador
1 inspeção
2 controle
3 cópia
4 transporte
227

5 apagador
6 status
7 rastro
8 bloqueio
9 ref1_remota
10 ref_local
Figura 6.30. Ordem de cadastramento dos marcadores.
Após o cadastramento do oitavo marcador (bloqueio) os

marcadores de referência poderão ser cadastrados.
Nesse caso, a primeira referência (número 9) a ser cadastrada

assumirá o papel da referência remota. As referências após a referência
remota atuarão localmente. A Figura 6.31 demonstra um trecho do
arquivo “vrml_data”.
Figura 6.31. vrml_data: Arquivo responsável pelo cadastro dos Marcadores.
228

6.4.3.2 Cadastramento de marcadores de referência
O SACRA é oferecido com cinco marcadores de referência cadastrados,

sendo a primeira referência, REF1, o marcador de trabalho remoto. Os
quatros marcadores restantes são referências locais, sendo que, dois
deles, REF2 e REF5 possuem objetos virtuais cadastrados. A REF2, por
exemplo, possui objetos virtuais relacionados à mobília de uma casa, já
a REF5 possui objetos virtuais relacionados a animais, meios de
transporte e comunicação.
Assim, para cadastrar novos marcadores que assumirão o papel

de referência, as REFs, é necessário seguir as etapas descritas no
cadastramento de marcadores, porém com algumas etapas a mais.
Deve-se sinalizar que um marcador será referência criando e
configurando os arquivos “.dat”, que serão indicados pelo campo VRML
do arquivo “vrml_data”. Na Figura 6.31, por exemplo, foi necessário criar
o arquivo “ref5.dat” localizado em “Wrl/reference/”. A configuração desse
arquivo é demonstrada pelo retângulo amarelo da Figura 6.32. Para
indicar que o marcador será referência o primeiro parâmetro deverá ser 1
e o segundo (ponsition/pref5.txt) deverá indicar o caminho do arquivo
que armazenará os pontos que serão associados à referência.
229

Figura 6.32. Configuração do marcador de referência.
6.4.3.3 Cadastramento de pontos
A referência orienta um conjunto de pontos que são associados

por meio de um arquivo na pasta “position”, que informa todos os pontos
associados à determinada referência, além de associar os objetos que
aparecerão nos pontos cadastrados. Esse arquivo deve ser criado pelo
usuário na pasta “position” e deve possuir o mesmo nome do arquivo
indicado na pasta “reference”, como o arquivo “pref5.tx”t, mostrado na
Figura 6.33.
Figura 6.33. Pontos associados à referência.
230

Antes de inicializar o cadastro dos pontos é necessário

configurar o arquivo “.dat” correspondente ao objeto “Wrl”. Esse arquivo
“.dat” deve armazenar informações com relação ao caminho e nome de
um ou mais objetos virtuais e seus respectivos atributos, como
translação, rotação, escala o nome de um arquivo de áudio que será
associado ao objeto. A Figura 6.34 mostra o arquivo “animais.dat” que
possui três objetos virtuais associados (galinha.wrl, asno.wrl e porco.wrl).
Figura 6.34. Arquivo com informações dos objetos virtuais.
O cadastramento de pontos é responsável por extrair as

diferenças entre as informações do marcador de inspeção e o REF e
associar essas informações com o arquivo correspondente ao objeto
virtual. O cadastro de ponto a um REF pode ser realizado de duas
231

maneiras: automática ou manual. A seguir serão apresentadas as

maneiras para realizar o cadastramento de pontos.
- Cadastramento automático de pontos
Para realizar o cadastramento automático de ponto é necessário

posicionar o marcador de inspeção na posição desejada, em relação à
determinada REF, e clicar com o botão esquerdo do mouse. Nesse
momento, é pedido o nome do arquivo “.dat” que deverá ser associado
ao ponto cadastrado.
A seguir será demonstrado passo a passo o cadastro de pontos

numa REF:
1-) Cadastre o marcador impresso na folha com as guias de

posicionamento, disponível no Anexo 4, usando o procedimento descrito
na seção “Cadastramento de marcadores de referência”, e crie o arquivo
que receberá as informações dos objetos. A Figura 6.35 demonstra o
marcador devidamente cadastrado.
Figura 6.35. Folha com o marcador cadastrado.
232

2-) Posicione o marcador de inspeção dentro das linhas

visualizadas na folha, como a Figura 6.36.a. Os dois marcadores (REF e
Inspeção), que constam no Anexo 3, devem ser enquadrados pela
câmera, (Figura 6.36.b)
(a) (b)
Figura 6.36. Posicionamento do marcador de inspeção. a) Inserção do
marcador de inspeção sobre as linhas indicativas. b) Marcador de inspeção
posicionado na posição indicada na folha.
3-) Coloque o cursor sobre a janela da imagem da câmera e

pressione o botão esquerdo do mouse. Será pedido o nome do arquivo
que armazena as informações sobre os objetos virtuais, como mostra a
Figura 6.37.a.
Digite o caminho e o nome do arquivo, como mostra a Figura

6.37.b (wrl/animais/animais.dat). O conteúdo desse arquivo é mostrado
na Figura 6.34. A Figura 6.37.c mostra os objetos virtuais associados ao
ponto cadastrado.
233

Figura 6.37. Associação de pontos aos arquivos com dados sobre objetos
virtuais; a) mensagem para digitar o nome do arquivo, b) Inserção do
caminho e nome do arquivo, c) Confirmação da leitura dos objetos
referenciados no arquivo digitado e o salvamento das informações do
ponto.
4-) O objeto virtual será visualizado na posição cadastrada,

Figura 6.38.a. A Figura 6.38.b demonstra os objetos visualizados nos
pontos cadastrados.
234

Figura 6.38. Objetos virtuais visualizados no ponto cadastrado; a) Objeto

virtual visualizado no primeiro ponto cadastrado, b) Visualização dos
objetos virtuais correspondentes aos três pontos cadastrados.
- Cadastramento manual de pontos
A segunda possibilidade consiste no próprio usuário editar, com

um editor de texto comum, os arquivos localizados na pasta “position”.
Para isso, deve ser adicionados os valores de X, Y e Z em milímetros da
distância do ponto desejado até o REF e o nome do arquivo
representante dos objetos virtuais, que serão visualizados na posição.
Os valores da orientação dos objetos virtuais, a serem exibidos

nesse ponto, assumem valores default, que podem ser alterados com a
modificação da orientação do objeto por meio do marcador de transporte.
A Figura 39 demonstra um exemplo do arquivo de posições configurado
à mão. Nesse exemplo o objeto indicado por “chair_set.dat” aparecerá
na posição -20,10 e 20 em relação a REF.
235

Figura 6.39. Arquivo de posições configurado à mão.
6.4.4. Configuração da Referência Remota.

O SACRA possibilita que usuários remotos colaborem na construção de
ambientes virtuais. A interação remota é realizada por uma referência
que será comum a todos os usuários, a referência remota. Assim, tudo o
que ocorrer nessa REF será visualizado pelos outros usuários.
A seguir serão apresentados os passos para a configuração da

REF remota no SACRA:
a-) Primeiramente, os diferentes usuários deverão possuir os

mesmos objetos virtuais, pois o sistema não realiza a de troca objetos
virtuais entre os usuários remotos, mas trocam comandos, como inserir
ou apagar determinados objetos virtuais.
b-) O marcador que será a REF remota deve ser cadastrado,

como descrito na seção 6.4.1. O marcador que assume o papel de REF
remota é o primeiro marcador após os oitavo marcador de ação.
c-) Configure a REF remota da mesma maneira como é descrito

na seção 6.4.2.
d-) Configure o arquivo “r_host.txt” com o ip e a porta de acesso

dos usuários que utilizarão o sistema de
236

modo remoto. A Figura 6.40 mostra um exemplo do arquivo “r_host.txt”.
Figura 6.40. Arquivo com a lista de hosts.
Realizada essa seqüência de passos a configuração da REF

remota estará pronta para ser utilizada, como uma região comum entre
os usuários remotos. Assim, qualquer objeto inserido, apagado ou
movido em um dos sistemas provocará a mudança no mesmo objeto nos
outros sistemas.
Todos os marcadores podem atuam na REF remota. Nessas

condições dois marcadores operam somente nessa REF, como o
marcador de rastro e o de bloqueio.
O marcador de rastro permite ao usuário indicar um caminho

realizado com esse marcador. Para ativa ou desativar a construção do
rastro, o usuário necessita pressionar a tecla ‘r’ no teclado, já a tecla ‘c’
apaga o rastro existente.
O marcador de bloqueio possibilita ativar ou desativar as ações

de usuários remotos nos objetos virtuais. Assim, é possível bloquear as
237

ações dos usuários, como apagar e mover, sobre os objetos que foram
previamente bloqueados.
6.4.5 Associação do áudio

O SACRA permite associar um arquivo de áudio no formato wave a um
objeto virtual. Assim, o áudio associado será executado quando o
marcador de inspeção ativar a visualização do objeto ou o marcador de
controle alterar o objeto de um determinado ponto. Por convenção o
arquivo de áudio deve ser armazenado na pasta “áudio” e o seu nome
deve ser inserido no arquivo (.dat) que armazena as informações de
objetos virtuais. A Figura 6.41 demonstra a associação do arquivo
galinha (audio/galinha) ao objeto virtual galinha.wrl.
Figura 6.41. Associação do Arquivo de áudio ao objeto virtual.
6.4.6 Salvando o trabalho realizado.

O salvamento do trabalho desenvolvindo, na referência, pode ser
realizado posicionando as REF que se deseje salvar no campo de
captura da câmera e apertar a tecla ‘s’ do teclado. Caso as REF sofram
modicações e não sejam salvas, no momento da finalização do sistema
o usuário será informado se deseja salvar as modificações realizadas.
238

6.4.7 Usando os marcadores de ação.
6.4.7.1 Inspeção
O marcador de inspeção é responsável pela verificação dos pontos

associados aos marcadores de referência, além de ser utilizado para
realizar o cadastramento de novos pontos.
A inspeção de pontos consiste no mecanismo de controle da

presença de objetos virtuais na cena, permitindo o usuário ativar ou
desativar a persistência dos objetos virtuais associados aos pontos.
Ao desativar a persistência dos objetos virtuais o usuário deixa

de visualizar o objeto, exigindo que ele memorize a posição daquele
determinado ponto, a fim de ativá-lo futuramente. Porém, uma grande
quantidade de objetos desativados pode dificultar o trabalho do usuário,
visto que necessitaria uma morosa inspeção no ambiente, para encontrar
o objeto desejado. Para isso, foi desenvolvido um mecanismo opcional
de suporte que, no momento de desativação da persistência do ponto, é
inserida uma referência visual em sua posição.
Essa referência visual pode ser um objeto VRML. A Figura 6.42

demonstra o uso do marcador de inspeção.
239

Figura 6.42. Uso do marcador de inspeção: a) aproximação da esfera do

maçador de inspeção da esfera representante do ponto, b) ativação da
visualização do objeto e c) visualização dos objetos virtuais representados
pelos pontos.
6.4.7.2 Controle
O controle consiste no marcador que permite a troca dos objetos virtuais,

caso exista mais de um objeto associado a um ponto. Esse marcador
realiza a troca seqüencial dos objetos visualizados. A troca é realizada,
através da inserção do controle na cena, seguida da colisão com o ponto
que contém a lista de objetos. Ao chegar ao fim da lista, a próxima
240

interação retorna ao seu inicio, mostrando, novamente, o primeiro objeto

visualizado. A Figura 6.43 mostra o uso do marcador de controle.
Figura 6.43. Uso do marcador de controle para a troca de objetos virtuais:

a) televisão e b) tapete
6.4.7.3 Cópia
O marcador de cópia permite ao usuário copiar um objeto virtual

associado a determinada REF e replicá-lo na própria REF ou inserí-lo
numa outra REF.
Para o usuário copiar um objeto, é necessário selecionar

primeiramente a REF de destino. A seleção da referência de destino é
realizada com a aproximação do marcador de cópia do marcador de
referência, como mostra a Figura 6.44.
241

Figura 6.44. Seleção da referência de destino: a) aproximação da esfera do

marcador de cópia da referência e b) referência selecionada.
Selecionada a referência de destino, o usuário deve copiar o

objeto virtual com o próprio marcador de cópia e fixar o objeto copiado
na referência de destino, através da sua oclusão. A Figura 6.45 mostra
os passos para realizar a cópia do objeto virtual.
242

Figura 6.45. Cópia de objeto virtual: a) aproximação da esfera do marcador

de cópia do objeto, b) objeto copiado e c) fixação do objeto copiado no
marcador de destino.
6.4.7.4 Transporte
O transporte é o marcador responsável pela re-orientação e re-

posicionamento de pontos. A colisão desse marcador com um ponto
promove o acoplamento do ponto ao transporte, possibilitando ao
usuário transportar o ponto para qualquer posição em relação a um
determinado REF. A Figura 6.46 mostra um objeto virtual sendo
transportado.
243

Figura 6.46. Transporte do objeto virtual: a) aproximação da esfera do

marcador de transporte do objeto a ser copiado e b) objeto reposicionado e
reorientado através do marcador de transporte.
6.4.7.5 Apagamento
O marcador ERASER possibilita a exclusão (apagamento) dos pontos e

a desalocação dos respectivos objetos virtuais alocados na memória do
computador. Para a exclusão de determinado ponto, é necessário
realizar a colisão do ERASER com o ponto desejado. A Figura 6.47
demonstra o funcionamento desse marcador.
244

Figura 6.47. Remoção do objeto virtual: a) aproximação do marcador de

remoção do objeto virtual a ser removido e b) objeto virtual removido.
6.4.7.6 Status
O marcador de status mostra ao usuário as principais informações do

estado do sistema. As informações são apresentadas em um painel
desenvolvido em VRML, que mostra o valor das variáveis de
persistência, suporte, rastro, bloqueio, distância de atuação do ponto de
colisão e a distância do ponto de colisão do centro do marcador. A
Figura 6.48 mostra o marcador de Status.
245

Figura 6.48. Marcador de Status.
Como essas variáveis são alteradas, durante a execução do

sistema, foi necessário utilizar mecanismos para a modificação do objeto
virtual no tempo de execução. Para isso, foram implementadas funções
para atuar em determinado nó do grafo de cena do objeto virtual.
6.4.7.7 Rastro
O marcador de rastro possibilita ao usuário construir um rasto de objetos

virtuais, permitindo propagar a indicação de um percurso entre as REFs
remotas. Esse rastro consiste na fixação de objetos virtuais, durante a
manipulação do marcador. Assim, conforme o usuário movimente o
marcador o percurso realizado é indicado pela fixação de objetos virtuais
no caminho desenvolvido.
246

O rastro construído oferece os recursos de controle de presença

dos objetos virtuais, permitindo que ousuário ative e desative a sua
visualização no ambiente local, ou então apague-o completamente, tanto
localmente, quanto remotamente. O rastro elaborado representa uma
forma de comunicação no ambiente colaborativo, visto que transmite o
movimento realizado pelo PATH aos usuários remotos. A Figura 6.49
mostra um exemplo do rastro exibido na REF remota.
(a) (b)
Figura 6.49. Movimentação da peça orientada pelo rastro: a) visualização do
movimento pelo usuário1 e b) ponto de vista do usuário2.
6.4.7.8 Bloqueio
A técnica de coordenação do trabalho colaborativo no SACRA é

aplicada, através do marcador de bloqueio.
Esse marcador permite ao usuário bloquear ou desbloquear as

operações remotas sobre os seus objetos na REF remota. A restrição
sobre operações remotas sobre determinado objeto é alterada somente
pelo usuário que o inseriu.
247

O SACRA oferece as opções de envio do objeto bloqueado ou

desbloqueado às REFs remotas, pois os usuários que necessitassem do
bloqueio perderiam o controle de seus objetos, caso fosse necessário
realizar primeiro o envio e posteriormente o bloqueio. Os usuários
remotos poderiam realizar alguma modificação nesse intervalo de tempo.
O bloqueio atua sobre os pontos da REF remota, através da

colisão de seu centro de colisão com o ponto determinado. Para
visualizar se o ponto está bloqueado ou desbloqueado, o usuário deve
utilizar o marcador STATUS, aproximando-o do ponto desejado.
6.4.8 Usando o teclado para apoiar a autoria e

execução da aplicação
A Tabela 6.1 apresenta algumas funções associadas a determinadas
teclas do teclado.
Tabela 6.1. Funções associadas ao teclado.
Tecla Função
Ativa a visualização de todos os objetos

‘a’
virtuais
Desativa a visualização de todos os

‘A’
objetos virtuais
‘c’ Limpa o rastro
‘d’ Difusão
248

Desativa o envio de objetos bloqueados

‘l’
aos usuários remotos
Ativa o envio de objetos bloqueados aos

‘L’
usuários remotos
‘p’ Desativa ou ativa a persistência
‘r’ Ativa ou Desativa a criação do rastro
‘s’ Desativa a visualização do suporte
‘S’ Ativa a visualização do suporte
‘t’ Ativa visualização do rastro
‘T’ Desativa visualização do rastro
Diminui a distância do ponto de

‘x’ comparação em ao centro do
marcador relação
Aumenta a distância do ponto de

‘X’ comparação em ao centro do
marcador relação
Aumenta a o raio de atuação do ponto de

‘+’
colisão
249

Diminui o raio de atuação do ponto de

‘-‘
colisão
Com essas funções os desenvolvedores da aplicação ou os usuários

poderão ter mais recursos para desenvolver e usar suas aplicações,
conseguindo mais sofisticação nas suas atividades.
6.5. REFERÊNCIAS BIBLIOGRÁFICAS
ABDULLAH, J.; MARTINEZ, K. (2002) Camera Self-

Calibration for the ARToolkit. In Proceedings of First
International Augmented Reality Toolkit Workshop, pp. 84-88,

Darmstadt, Germany.
CLAUS, D.; FITZGIBBON, A. W. Reliable Automatic

Calibration of a Marker-Based Position Tracking System.
wacv-motion, pp. 300-305, Seventh IEEE Workshops on

Application of Computer Vision (WACV/MOTION'05) -
Volume 1, 2005.
CONSULARO, L.A.; CALONEGO JR, N.; DAINESE, C.A.;

GARBIN, T. R.; KIRNER, C.;TRINDADE, J.; FIOLHAIS,
C.(2004) ARToolKit: Aspectos Técnicos e Aplicações

Educacionais. In: CARDOSO, A.; LAMOUNIER JR, E.
250

editores. Realidade Virtual: Uma Abordagem Prática. Livro dos

Minicursos do SVR2004, SBC, São Paulo, 2004, p.
141-183.
GEIGER, C.; REIMANN, C.; STICKLEIN, J.; PAELKE, V.

(2002) JARToolKit- A Java binding for ARToolKit. In:
The First IEEE Augmented Reality ToolKit International

Workshop, p124, 2002.
GNU General Public License< http://www.gnu.org/licenses/gpl

.html #TOC1 >acesso em fev, 2007
HORNECKER, E.; PSIK, T. Using ARToolKit Markers to Build

Tangible Prototypes and Simulate Other
Technologies. Proc. of INTERACT 2005 Rome. 2005.
KATO, H.; BILLINGHURST, M.(1999). Marker Tracking and

HMD Calibration for a Videobased Augmented
Reality Conferencing System. In: Proceedings of the 2nd IEEE

and ACM Internationall Workshop on Augmented
Reality, San Francisco, CA,USA, p85-94, 1999.
KATO, H.; BILLINGHURST, M.; POUPYREV, I. (2000)

“ARToolKit Version 2.33”, Human Interface Lab,
Universidade de Washington.
251

KIRNER, C.; TORI, R. Fundamentos de Realidade Aumentada.

In: Claudio Kirner; Romero Tori; Robson Siscoutto.
(Ed.).Fundamentos e Tecnologia de Realidade Virtual e

Aumentada. Pré Simpósio SVR 2006, SBC, Belém, 2006, pp.
22-38.
KIRNER, C .(2007) Python-ARToolKit www.ckirner.com
LEPETIT, V.; FUA, P.(2005) Monocular Model-Based 3D

Tracking of Rigid Objects: A Survey. Foundations and
Trends in Computer Graphics and Vision, Vol.1, N.1, pp. 1-89, Out
2005.
LOOSER, J.; GRASSET, R.; SEICHTER, H.; BILLINGHURST,

M.(2006) OSGART - A pragmatic approach to MR.
Proceedings of the Fifth IEEE and ACM International Symposium

on Mixed and Augmented Reality (ISMAR06).
OLIVEIRA,L.A.; CALONEGO, N. J. Uma Aplicação Cliente-

Servidor Usando ARToolKit . In: Workshop de
Realidade Aumentada, 2006,Rio de Janeiro. Anais do 3º Workshop

de Realidade Aumentada. Rio de Janeiro: UERJ,
2006. v. 3. p. 31-34.
252

PIEKARSKI, W.; THOMAS, B. H.(2002) Using ARToolKit for

3D Hand Position Tracking in Mobile Outdoor
Environments. In 2nd International Augmented Reality Toolkit

Workshop, Darmstadt, Set, 2002.
SANTIN, R.; KIRNER, C. Alteração dinâmica de objetos

virtuais em Realidade Aumentada. In: Workshop de
Realidade Aumentada, 2005, Piracicaba. Anais do 2º Workshop de

Realidade Aumentada. Piracicaba : Unimep, 2005.
WAGNER, D.; SCHMALSTIEG, D.(2003) ARToolKit on the

PocketPC Platform. In:Proceedings of the 2nd
Augmented Reality Toolkit Workshop, p14-15, 2003.
6.6. ANEXOS
Anexo 6.6.1. Compilação do ARToolKit na

plataforma Windows
Para compilar as bibliotecas e aplicações da versão 2.72.1 do ARToolKit
no Windows, por exemplo, são pré-requisitos:
Microsoft Visual Studio .NET 2003 ou Visual Studio 6, ou Cygwin.
DSVideoLib-0.0.8b-win32
GLUT
OpenVRML-0.16.1-bin-win32 ou OpenVRML-0.14.3-win32 (opcional)
253

No caso dessa versão 2.72.1 na plataforma Windows, é necessário

seguir os seguintes passos para compilar os seus projetos:
1. Instalar um dos compiladores da Microsoft (Visual Studio .NET 2003

ou Visual Studio 6) ou o CygWin.
2. Baixar e descompactar a biblioteca “DSVideoLib-0.0.8b-win32”

(DSVideoLib, 2007) dentro do diretório raiz “{ARToolKit}”, certificando-se
que o diretório seja denominado “DSVL”. Copiar os arquivos “DSVL.dll” e
“DSVLd.dll” para a pasta “bin” do ARToolKit (“{ARToolKit}\bin”) .
3. Baixar o GLUT (GLUT, 2007), descompactar e copiar o arquivo

“glut32.dll” para pasta “system” do Windows, copiar o arquivo “glut32.lib”
para a pasta “lib” do ARToolkit (“{ARToolKit}\lib”) e criar uma pasta “GL”
no diretório “include” do ARToolKit (“{ARToolKit}\include \GL”), copiando
para essa nova pasta o arquivo “glut.h”.
4. Executar o script “Configure.win32.bat” que está em

“{ARToolKit}\Configure.win32.bat” para criar o arquivo
“{ARToolKit}\include\AR\conFigurah”.
5. Abrir o arquivo “ARToolKit.sln” no VisualStudio .NET ou o arquivo

“ARToolkit.dsw” no Visual Studio 6.
6. Compilar os projetos.
7. Executar as aplicações geradas em “{ARToolKit}\bin”
8. Caso o usuário deseje compilar a aplicação “SimpleVRML”, que

renderiza objetos virtuais implementados em VRML, deve-se :
9. Baixar a biblioteca “OpenVRML” (OpenVRML-0.16.1-bin-win32 ou

OpenVRML-0.14.3-win32 (OpenVRML, 2007) e descompactá-la no
diretório raiz do ARToolKit.
254

10. Copiar o arquivo “js32.dll” da pasta “{ARToolKit} \OpenVRML\bin”

para a pasta “{ARToolKit}\bin”.
11. Habilitar e compilar, no VisualStudio .NET, os projetos “libARvrml” e

“simpleVRML”. Já, no VisualStudio 6, é necessário criar um projeto para
compilar a biblioteca estática gerada pelo “libARvrml” e um projeto de
aplicação win32, com as devidas dependências ajustadas para gerar o
executável “simpleVRML.exe”.
No momento de execução das aplicações, podem surgir mensagens de

erro, acusando a falta de algumas dlls da Microsoft. Nesse caso, é
necessário baixá-las de sites na Internet e copiá-las para a pasta
“system32”, existente no diretório Windows.
- Referências do Anexo 6.6.1
DSVideoLib,<http://sourceforge.net/project/showfiles.php?group_id
=75107&package_id=75491> acesso em fev, 2007.
GLUT, The OpenGL Utility Toolkit.< http://www.xmission.com/ ~ nate/glut.html>

acesso em fev, 2007
OpenVRML< http://www.openvrml.org/> acesso em fev, 2007.
Anexo – 6.6.2. Instruções para instalação,

configuração e execução do ARToolKit - versão
2.65, usando a aplicação "simpleVRML"
255

6.6.2.1. Baixando, preparando e tentando executar o

ARToolKit
Inicialmente, entre no site oficial do ARToolKit em:
(http://www.hitl.washington.edu/artoolkit/download/) e baixe a
versão 2.65 com suporte VRML (ARToolKit 2.65 Software with VRML
support, zip format[9.4 mb]) para Windows.
Há também versões para outras plataformas e versões mais modernas

com suportes diferentes para objetos virtuais, se o usuário quiser baixar.
Faça a descompactação do arquivo baixado em uma pasta “ARToolKit”,

por exemplo.
Entre na pasta e veja seu conteúdo:
- na pasta “patterns”, o usuário encontrará as figuras das placas

(marcadores) já cadastradas no sistema imprima-as para poder usá-las.
É recomendável recortá-las e colá-las em um papelão um pouco maior,
para poder segurar cada placa pelas bordas, sem obstruir a moldura e
sem dobrar a figura.
Inicialmente, dependendo da configuração de seu computador, o usuário

poderá tentar executar os aplicativos executáveis, entrando na pasta
“bin”, como: “simple”, “simpleVRML” e “multiTest”. Com a webcam já
instalada, ao clicar nos aplicativos, deveria aparecer uma janela de vídeo
(invertida), mostrando a visão da webcam. Faça a inversão da imagem,
através dos parâmetros da webcam, ou a use invertida mesmo.
256

Se a imagem aparecer, procure colocar as placas, uma por vez, em

frente à webcam, de forma que a placa fique inteiramente no vídeo. Pode
ser que, em alguma dessas placas, apareça algum objeto virtual,
dependendo do fucionamento do software, das condições de iluminação,
etc. Feche a janela e tente outro aplicativo, daqueles mencionados,
localizados na pasta “bin”.
Na realidade, isto é só uma tentativa, pois, antes de fazer o ARToolKit

funcionar, ele deve ser instalado, de acordo com as orientações
constantes em:
http://www.hitl.washington.edu/artoolkit/documentation/usersetup.h
tm
Depois do ARToolKit ser instalado, o usuário, seguindo as instruções de:

http://www.hitl.washington.edu/artoolkit/documentation/userstartup
.htm poderá ver o resultado da primeira aplicação “simple”, mostrando
um cubo azul sobre a placa “Hiro”.
Ocorre que, para muitas pessoas, o processo de instação do ARToolKit,

é trabalhoso e complicado.
Para facilitar o teste e a configuração do ARToolkit, foram desenvolvidas,

com a ajuda de alunos que trabalharam com ARToolkit, algumas versões
pré-montadas e simplificadas, exigindo poucas ações do usuário para
seu funcionamento. Uma dessas versões é apresentada a seguir.
Recomendo que o usuário, depois de testar a versão pré-montada, volte

a tentar usar a versão oficial mais adequada para si.
257

6.6.2.2. Usando a versão simplificada pré-montada

do ARToolKit
Baixe o arquivo “ARTK-simplif.zip” em:
http://www.ckirner.com/download/arquivos/ARTK-simplif.zip
Faça a descompactação, vá para a pasta "bin" e localize a aplicação

"simpleVRML.exe", a aplicação "mk_patt.exe" e a pasta "Placas",
conforme a Figura A.1.
Pegue todos os arquivos DLL localizados pasta “bin” e os coloque em:

C:\WINDOWS\system32, ou espere o sistema reclamar, quando tentar
executar o ARToolKit, para colocar só as DLL solicitadas.
ATENÇÃO: Ao seguir as instruções, use sempre o conteúdo entre aspas,

sem as aspas.
Figura A.1. Conteúdo da pasta “bin”.
258

6.6.2.2.1. Preparação
Para a execução da aplicação "simpleVRML.exe", será necessário
realizar os seguintes passos:
a) Imprimir e recortar os marcadores do arquivo “placas-impressao.doc”,

contidos na pasta “Placas”, conforme a Figura A.2.
Figura A.2. Placas marcadoras iniciais (ce-placa e te-furado).
Colar cada placa em um quadrado de palelão, um pouco maior do que

ela. As placas que funcionam são aquelas com símbolos no interior da
moldura (ce-placa e te-furado). As outras molduras vazias poderão ser
usadas para ampliação do sistema. Para fazer o símbolo ele (L), a ser
usado mais tarde, edite o símbolo cê (C), retirando parte da barra
horizontal superior.
259

b) Conectar a câmera.
c) Executar a aplicação "simpleVRML.exe".
Obs: Caso surja a mensagem,“Please check if DsRenderer.as is

registered properly...”, execute o arquivo "register_filter.bat" (Figura1), ou
clique em "iniciar>executar (start>run) e execute: C:
\windows\system32\regsvr32.exe DsRenderer.ax. Volte a executar a
aplicação "simpleVRML.exe".
6.6.2.2.2. Funcionamento
Coloque uma placa no campo de visão da webcam, fazendo com que
apareça um objeto virtual sobre a placa.
Tome cuidado para não obstruir a placa ou parte dela, de forma que ela
apareça inteira no vídeo. A Figura A.3 mostra algumas visões da janela
de visualização e da janela de acompanhamento da execução.
260

Figura A.3. Aparecimento dos objetos virtuais sobre as placas.
Movimente e/ou incline a placa para ver se o objeto a acompanha.

Coloque duas placas separadas no campo de visão da webcam para ver
os dois objetos juntos. Se o usuário quiser alterar ou ampliar o sistema,
ele deverá executar os passos a seguir.
6.6.2.2.3. Cadastramento de novas placas e

configurando aplicações
Para o cadastramento de novas placas, será necessário seguir os
seguintes passos:
261

a) Crie os novos marcadores. Para isso abra o arquivo “placas-

impressao.doc”, contido na pasta “Placas”, e adicione um símbolo na
parte branca central posicionado de forma assimétrica, conforme a
Figura A.4. Faça uma letra “ele” (L), editando a letra “ce” (C), retirnado
parte da barra horizontal superior , imprimindo-a em seguida.
Figura A.4. Gerando nova placa (L), a partir da placa (C).
b) Executar o programa "mk_patt.exe", contido da pasta "bin". Será

pedido para que você entre com um nome de arquivo de parâmetros de
câmera. Entre com o nome do arquivo "camera_para.dat" ou
simplesmente tecle "enter". Este é o nome default para o arquivo de
parâmetros de câmera. Aparecerá, então, a tela mostrada na Figura a.5.
262

Figura A.5. Executando o programa de cadastramento de placa.
c) Enquadre a câmera de vídeo, apontando diretamente para a placa.

Surgirão, então, bordas vermelhas e verdes em torno da placa. Isto
indica que o software "mk_patt" encontrou o quadrado em torno da placa
que está sendo cadastrada. A placa deve ser movimentada até que os
lados vermelhos do quadrado estejam no topo e à esquerda do quadrado
na imagem de vídeo (a Figura A.6 mostra uma situação intermediária -
não é a situação final). Uma vez que o quadrado encontrado esteja
orientado corretamente, clique no botão esquerdo do mouse.
Será então pedido um nome de arquivo para a placa (Por exemplo:

simbolo1, ele-placa, etc).
263

Figura A.6. Cadastramento de uma placa.
Outras placas podem ser cadastradas, simplesmente enquadrando a

câmera para novos padrões e repetindo o processo, ou clicando no
botão direito do mouse para sair da aplicação.
264

d) Copie os novos arquivos de padrões da pasta “bin” para a pasta

“Data”, antes de usá-los, conforme a Figura A.7.
Figura A7 - Movendo os arquivos de padrões gerados no cadastramento de

placas.
e) Edite o arquivo "vrml_data", na pasta “Data”, conforme a Figura A.8,

para adequar a quantidade de marcadores e adicionar os parâmetros
referentes às novas placas, incluindo: o nome do arquivo criado pelo
"mkpatt", o nome do arquivo de referência aos objetos virtuais (.dat), o
tamanho da placa e a posição do centro da placa. Antes de editar o
arquivo, faça uma copia e renomeie. Depois da edição, clique em salvar
e renomeie, se for preciso – não mude o tipo de arquivo.
265

Figura A.8. Localização do arquivo “vrml_data”.
Cada um dos marcadores no arquivo "vrml_data" é especificado pela

seguinte estrutura:
#the number of patterns to be recognized
2 (número de marcadores que serão referenciados, neste caso, 2)
#pattern 1
VRML Wrl/simbolo1.dat (arquivo referente à placa cadstrada)
Data/arquivo de associação do objeto à placa1, na pasta “Wrl” (ex.

placa1-obj.dat)
80.0
0.0 0.0
#pattern 2
VRML Wrl/simbolo2.dat (arquivo referente aos objetos virtuais)
Data/arquivo de associação do objeto à placa2, na pasta “Wrl” (ex.

placa2-obj.dat)
80.0
0.0 0.0
266

A seguir, na Figura A.9, é ilustrado um exemplo com 3 placas

(marcadores).
Figura A.9 – Exemplo de estrutura do arquivo “vrml_data”.
f) Criar um arquivo com a extensão ".dat", na pasta “Wrl”, que fará a

associação da placa com o objeto virtual. Esse arquivo possuirá os
nomes e parâmetros de translação rotação e escala dos objetos virtuais
associados à placa. Para isso, abra um editor de texto como o Notepad
267

(Bloco de Notas) e copie a estrutura abaixo, colocando o nome do

arquivo do objeto virtual desejado, conforme a Figura A.10.
wrl/Nome do objeto.wrl # objeto virtual associado à placa
0.0 0.0 0.0 # Translation - x,y,z from center of tracking

pattern
90.0 1.0 0.0 0.0 # Rotation angle + axis, eg 90.0 1.0 0.0 0.0
111 #escala
Figura A.10. Construindo o arquivo “*.dat”, associando a placa ao objeto

virtual. Salve o arquivo, de acordo com o nome associado na linha
VRML do passo “e”, nesse caso:
Figura A.11. Conteúdo da pasta “Wrl”, incluindo o objeto “angfish.wrl”.
268

g) Certifique-se que o objeto virtual associado esteja na pasta "Wrl" –

angfish.wrl, conforme a Figura A.11.
h) Executar a aplicação "simpleVrml.exe", na pasta “bin” .
Agora, você está pronto para criar novas placas e associá-las com outros
objetos virtuais, dispondo-os no seu espaço físico, em frente à webcam.
6.6.3. Outras Aplicações

Para desenvolver outras aplicações, pode-se partir de uma versão fonte
do programa "simpleVRML", promovendo as alterações e inserções
desejadas com programação C, compilando o programa quando estiver
pronto.
Está sendo preparada uma versão do ARToolKit com Python , que é

uma linguagem interpretada, com a participação de Rafael Santin,
Celso Providelo e Claudio Kirner, de forma a permitir o
desenvolvimento da aplicação "simpleVRML" em Python. Desta maneira,
a alteração do programa não precisará ser compilada, facilitando o
trabalho de teste de novos programas.
Oportunamente, essa versão de ARToolKit com Python será

disponibilizada no site de RV em:
http://www.realidadevirtual.com.br
Anexo – 6.6.3. Marcadores Pré-cadastrados no

SACRA
269

270

271

272

273

274

Anexo – 6.6.4. Marcador com guias
275

276

PARTE 3
APLICAÇÕES
Capítulo
7
Jogos e Entretenimento com
Realidade Virtual e Aumentada
Romero Tori, Ricardo Nakamura, João Luiz Bernardes Jr, Roberto
Cezar Bianchini, Eduardo Costa Jacober, Daniel Calife e Alexandre
Nascimento Tomoyose
Laboratório de Tecnologias Interativas (Interlab) – Departamento de

Engenharia de Computação e Sistemas Digitais – Escola Politécnica da
Universidade de São Paulo (USP)
{romero.tori, ricardo.nakamura, joão.bernardes, roberto.bianchini,

eduardo.jacober, daniel.calife, alexandre.tomoyose}@poli.usp.br
Abstract
In this chapter the evolution of computer games and its industry,

the major related concepts, and the relationship among videogame,
Virtual Reality and Augmented Reality technologies will be
discussed. Game engines, their use in computer game and virtual
environments development, and the use of tangible user interfaces
are among other important novel technologies that will be
analyzed here.
Resumo
Este capítulo discute evolução e mercado dos jogos de computador
e principais conceitos envolvidos, relacionando essa tecnologia
277
com as de realidade virtual e aumentada. Serão destacados os

motores de jogos (game engines) e sua utilização no
desenvolvimento de jogo e ambientes virtuais, bem como as
interfaces tangíveis, importantes em sistemas de realidade virtual e
aumentada .
7.1. Introdução
Jogos Eletrônicos (JE) e Realidade Virtual (RV) são áreas que têm
sua origem no início da década de 1960, e que acabaram se
desenvolvendo de forma independente. Algum tempo após o
surgimento desses dois campos, a área de Realidade Aumentada
(RA) também se juntou às outras duas e às muitas outras que
estudam a forma como se pode representar e simular situações e
ambientes em computadores. A Computação Gráfica (CG) é a
principal tecnologia por trás de JE, RV e RA. Dessa forma a
evolução da CG impacta as outras três áreas, assim como demandas
provenientes de cada uma delas influenciam a indústria e pesquisas
de CG. Devido ao grande avanço ocorrido no hardware gráfico e
na diminuição do seu custo, pesquisas que englobam JE, RV e RA
tendem a produzir resultados cada vez mais interessantes que
aumentam o grau de interatividade homem-computador. A
gigantesca indústria de jogos impulsiona a criação de ferramentas,
dispositivos de interação e game engines que podem ser
aproveitados também para o desenvolvimento de protótipos e/ou
aplicações finais de RV e RA. Dessa forma, conhecer a tecnologia
de desenvolvimento de jogos é interessante para profissionais,
estudantes e pesquisadores da área de RV e RA, mesmo que esses
só pretendam desenvolver aplicações “sérias”.
Este capítulo apresenta conceitos e tecnologia de JE e

analisa algumas de suas relações com RV e RA.
278
7.2. Conceitos
Esta seção trata da conceituação e discussão sobre a aplicação das
tecnologias de JE, RV e RA no entretenimento digital, com maior
ênfase na realidade aumentada, por se tratar de tecnologia mais
recente e ainda pouco explorada pela indústria do entretenimento.
Serão também discutidas semelhanças e diferenças entre técnicas e
tecnologias de RV e JE.
7.2.1. Jogos Eletrônicos

Definir jogos eletrônicos é simples, ou seja, são jogos que utilizam
dispositivos eletrônicos (como computadores, consoles de
videogame, - inclusive os portáteis – e celulares ou PDAs) como
seu meio, ou seja, para permitir a interação com ele, mostrar seu
estado, armazenar suas regras etc.
Já a definição de jogo é mais problemática. Embora

reconhecer intuitivamente se determinada atividade é ou não um
jogo pareça tarefa simples, diversos autores vêm tentando fornecer
definições que consideram adequadas, muitas vezes conflitantes
entre si, sem que a comunidade de desenvolvimento e pesquisa de
jogos tenha chegado a um consenso. No livro publicado dois anos
após sua morte, o filósofo Ludwig Wittgenstein (1953) argumenta
que uma única definição, baseada em seus elementos, não é
suficiente para determinar o conceito de jogo, que deveria ser
representado por um conjunto de definições. Uma das principais
dificuldades está na diferenciação entre jogo, brincadeira,
competição, entretenimento e atividades artísticas. Outra se refere
às diferenças culturais e lingüísticas que tratam tais conceitos de
forma diferente em diferentes sociedades. Por exemplo, em
português “jogo” engloba três diferentes palavras da língua inglesa
( “play”, “game” e “gambling” ). Por outro lado “play” possui um
sentido mais amplo que o nosso “jogar”. Para evitar dúvidas,
279
quando nos referirmos a “jogo” neste texto estaremos tratando

desse sentido mais estrito, equivalente ao “game” da língua inglesa.
Atualmente há também correntes que preferem excluir da
classificação de jogos os programas de simulação (como o “The
Sims”) e de histórias interativas. Do ponto de vista tecnológico, no
entanto, há muitas similaridades entre essas aplicações e jogos
eletrônicos, de forma que sob esse ponto de vista as tecnologias
discutidas neste capítulo também se aplicam a esse tipo de produto
de entretenimento.
A maioria dos autores concorda com alguns elementos que

devem estar presentes em uma atividade para que seja considerada
um jogo: interatividade, regras bem definidas, um ou mais
objetivos a serem alcançados, obstáculos para alcançá-los e o
entretenimento do jogador. Walther (2003) define jogo como
transgressões que levam da realidade a um "modo de jogo",
basicamente em função de limites sobre local, tempo e objetos e da
existência de regras e estrutura não-convencionais.
Mesmo esses elementos são fonte de discordância. Os

objetivos de um jogo, por exemplo, nem sempre são explícitos e
fechados (close-ended), mas podem ser implícitos ou abertos
(open-ended), ou seja, estão de alguma forma previstos nas regras
mas são escolhidos pelo jogador conforme seu desejo. Por contar
somente com objetivos open-ended, escolhidos pelo usuário e não
impostos pelo jogo, muitos jogos não foram classificados como tal
no passado. Os produtos da série "Sim" e boa parte dos MMOs
contam principalmente com objetivos desse tipo. Chris Crawford
(2003), em sua definição baseada em dicotomias, tenta separar jogo
de quebra-cabeça e competição com base na natureza dos
obstáculos apresentados ao jogador, mas atinge uma definição
muito restrita para jogo que constantemente desafia a intuição. A
finalidade da atividade é outro aspecto que gera dúvidas, já que
280
atualmente é bastante comum o uso de jogos com objetivos além

do entretenimento, dentre eles destacando-se o treinamento de
profissionais. Mesmo quando o entretenimento não é a principal
finalidade de um jogo, aquele componente deve existir para
caracterizá-lo como tal. É difícil concordar com Roger Caillois
(1957) que inclui a não-produtividade como elemento de sua
definição de jogo.
Se é complexo classificar atividades como jogo ou não,

classificar os jogos eletrônicos em si também não é unanimidade.
Uma classificação comum (mas nem sempre consistente) do
mercado:
• First Person Shooter (FPS): jogos de ação em que o

jogador tem visão em primeira pessoa e tem como objetivo
eliminar adversários (controlados pelo computador ou por outros
jogadores) utilizando diversos tipos de armas ou golpes. Não existe
evolução do personagem controlado pelo jogador, exceto através da
posse de itens que coleta ao longo do jogo;
• Estratégia: o jogador controla (mais ou menos

diretamente) diversos personagens (normalmente chamados de
unidades) e estruturas (usadas para criar ou melhorar unidades ou
para defesa) que são criados dentro do jogo a partir de recursos
limitados. A estratégia está no gerenciamento desses recursos, na
escolha do que criar e no uso das unidades;
• RPG: A principal característica desses jogos é a

possibilidade de evolução do personagem controlado pelo jogador
(é menos comum que o jogador controle mais de um personagem,
mas existem jogos em que controla grupos pequenos), cujas
capacidades melhoram conforme se alcança algum objetivo. Essas
capacidades normalmente são representadas numericamente por
281
estatísticas como atributos físicos, sociais ou mentais, habilidades,

"níveis" etc. É comum, mas não necessário, que a forma como essa
evolução acontece, desde a criação do personagem, também esteja
sob controle do jogador, permitindo a sua customização (a forma
como os personagens interagem com o jogo pode ser bem diferente
dependendo de quais estatísticas foram privilegiadas). Parte da
evolução normalmente é também a aquisição e uso de
"equipamentos" melhores para o personagem, cuja disponibilidade
normalmente é limitada pelo estágio de evolução dos mesmos;
• Simulação: jogos que simulam alguma atividade real,

como o crescimento e gerenciamento de uma cidade ou a vida de
um indivíduo. Alguns tipos específicos de simulação são tão
populares que podem ser considerados como categorias separadas:
• Esportes (normalmente esportes populares de equipe

e esportes radicais como skate e snowboard);
• Simuladores de vôo;
• Corrida (quase sempre refere-se a corrida de

automóveis e não é classificado como jogo de esporte).
• Ação: Jogos eletrônicos em que ação intensa

(normalmente violenta) é o principal componente, sem grande
preocupação com elementos como gerenciamento de recursos ou
evolução do personagem, mas com mais obstáculos a vencer que os
FPS (a mera locomoção no jogo e a aquisição de equipamentos
podem ter obstáculos complexos, puzzles são comuns fazendo com
que muitos desses jogos sejam classificados como action-
adventure);
• Aventura: Jogos eletrônicos em que o principal obstáculo

são puzzles e onde o elemento de ação é quase inexistente.
282
Normalmente o desenrolar do jogo conta uma história (e essa

história costuma ser um dos maiores atrativos desses jogos)
bastante linear;
É interessante notar que um dos principais fatores para essa

classificação parece ser o tipo de desafio ou obstáculo que o
jogador deve enfrentar. São comuns classificações que são
combinações dessas, como Action-RPG ou o já mencionado
Action-Adventure. Outras classificações são feitas com relação à
plataforma do jogo (computador, consoles específicos, jogos para
celular...) ou à sua finalidade (jogos para treinamento, jogos
educativos, advergames para divulgação de produtos ou conceitos
etc.).
Outro conceito relacionado, e que raramente é tratado com

rigor é o da “jogabilidade”. Para o escopo deste texto, considera-se
como sendo o análogo da usabilidade, no contexto dos jogos. Ou
seja, como a usabilidade é a capacidade de um sistema
computacional de atender às metas dos seus usuários, a
jogabilidade é a capacidade do jogo eletrônico de atender às metas
(normalmente de entretenimento) dos seus jogadores.
7.2.2. Game Engines

Em diferentes áreas da Computação, o termo “engine” é utilizado
para denominar o núcleo de um sistema de software responsável
por uma tarefa específica. Desta forma, existem engines de busca
para bancos de dados, engines de inferência relacionados à
inteligência artificial, entre outros. Na área de JE, existem
divergências sobre o que define o que é um “game engine”, ou seja
um engine para jogos eletrônicos. Por exemplo, a abordagem de
Eberly (2000) é limitada às técnicas de geração de imagens e
gerenciamento de cenas. Para McShaffry (2003), existem diferentes
tipos de game engines, tais como engines de renderização 3D e
283
engines de simulação física. Lewis e Jacobson (2002) definem

engine como uma coleção de módulos de código de simulação que
não especificam diretamente o comportamento ou o ambiente do
jogo. A definição adotada neste texto é um pouco mais abrangente:
um conjunto de sistemas de software parametrizáveis, integráveis e
reutilizáveis, que fornecem serviços utilizados em um jogo
eletrônico.
A principal motivação para o surgimento e proliferação dos
game engines é a reutilização de código. A evolução dos
computadores leva a um aumento na complexidade dos softwares
desenvolvidos e isto também se aplica aos jogos eletrônicos. Como
resultado, hoje em dia projetos de JE podem durar vários anos,
consumindo milhões de dólares e envolvendo dezenas de pessoas.
Neste contexto, os game engines surgem como ferramenta para
reduzir o tempo de desenvolvimento e os riscos de projeto, ao
fornecerem serviços fundamentais necessários para os jogos
eletrônicos. Como ilustrado na figura 7.1, o game engine
implementa os seus serviços sobre a plataforma computacional na
qual o JE será executado. Sobre o game engine fica o JE que o
utiliza, responsável por controlar a execução de seus serviços e
fornecer os dados necessários, tais como modelos 3D e sons. É
interessante observar que em geral, os game engines não abstraem
muitos detalhes das plataformas de hardware em que são
executados. Isso leva a um maior acoplamento entre o game engine
e o hardware, mas é feito para não comprometer o desempenho do
JE.
284
Figura 7.1. Estrutura de desenvolvimento de um jogo

eletrônico que utiliza um engine.
A maioria dos game engines implementa algum tipo de
geração de imagens, normalmente renderização de elementos
tridimensionais. Isto se deve, principalmente, ao fato de que a
maioria dos jogos eletrônicos atuais depende predominantemente
da saída visual para interagir com o jogador. Uma conseqüência
desta abordagem é que, em muitos game engines, a representação
de entidades lógicas e visuais se confunde, sendo implementada de
maneira fortemente acoplada.
Apesar da ênfase que se observa na capacidade de geração

de imagens pelos game engines, existem muitos outros serviços
que podem ser fornecidos por eles, tais como: geração de áudio,
comunicação em rede, inteligência artificial, colisão e simulação
física e tratamento de dispositivos de entrada.
Ao se utilizar game engines em aplicações de Realidade

Virtual ou Aumentada, é preciso ter em mente o fato de que,
285
mesmo sendo flexíveis, esses sistemas de software são produzidos

e otimizados para JE. Isto traz conseqüências como:
• Muitos game engines geram imagens adequadas para

visualização em monitores convencionais. No caso de se utilizar
dispositivos diferentes, tais como HMDs e CAVEs, é preciso
avaliar a compatibilidade do game engine;
• A representação de objetos 3D e renderização é

freqüentemente otimizada para determinados tipos de ambientes
virtuais (cenários fechados ou terrenos amplos, por exemplo) e sua
utilização em outros casos pode ser difícil ou mesmo inviável;
• Muitos game engines utilizam formatos próprios para

modelos 3D, efeitos sonoros etc. e disponibilizam ferramentas de
conversão entre formatos. No entanto, é preciso avaliar se os
formatos suportados por tais ferramentas são adequados para o
ambiente de produção específico (questões de licenciamento de
software, tempo de processamento, conversões incompletas, etc);
• A tolerância à latência nos jogos eletrônicos tende a ser

maior do que em ambientes virtuais multi-usuários, e os sistemas
de comunicação em redes dos game engines são feitos de acordo
com este fato. Portanto, pode ser necessário avaliar o desempenho
do game engine caso seja utilizado para este tipo de aplicação;
• Os sistemas de colisão e simulação física utilizados nos

game engines buscam gerar resultados “visualmente corretos”. Ao
se utilizar tais sistemas em aplicações de RV e RA envolvendo
simulação, deve-se avaliar se os resultados são adequados (fatores
como confiabilidade e precisão).
Em resumo, os game engines possuem algumas

características que os tornam semelhantes aos “toolkits” para
286
aplicações de Realidade Virtual. No entanto, sua implementação é

direcionada para o desenvolvimento de JE e portanto seu uso em
aplicações de RV e RA requer uma avaliação cuidadosa das
características do game engine.
7.2.3. Interfaces Tangíveis

Influenciados pelo surgimento de duas novas tecnologias
promissoras, a Realidade Aumentada e a Computação Ubíqua, Ishii
e Ullmer (1997) definiram um novo tipo de interface homem-
máquina muito mais ligada ao mundo físico (assim como RA e
Computação Ubíqua): a Interface Tangível (TUI, Tangible User
Interface). Esta interface se baseia no princípio da utilização de
interações físicas para manipulação direta do mundo virtual, desta
forma um objeto físico real e um objeto virtual são associados,
quando ocorre alguma mudança em um deles (normalmente no
objeto físico) o outro é afetado da mesma maneira, permitindo que
o usuário manipule um objeto virtual em um ambiente 3D através
da manipulação de um objeto real, de uma maneira muito mais
intuitiva.
Através das interfaces tangíveis, a manipulação de

conteúdos digitais se torna muito mais natural, como por exemplo
rotacionar um cubo real e obter as mesmas transformações em um
cubo virtual em um ambiente tridimensional. Um exemplo de
aplicação da interface tangível é apresentado por Underkoffler e
Ishii (1999), em uma aplicação chamada “Illumination Light”,
nesta aplicação os usuários podem manipular objetos físicos que
representam componentes ópticos (espelhos, lasers, lentes, etc) em
uma “superfície aumentada”. Quando o usuário posiciona o objeto
que representa o laser nesta superfície, é projetado um raio
luminoso que parece sair deste objeto, caso seja posicionado o
287
objeto que representa o espelho, este raio será refletido de acordo

com sua posição.
A colaboração entre os usuários é permitida e até mesmo

incentivada com o uso das interfaces tangíveis, isto ocorre devido
ao fato de as interações e movimentos terem menos limitadores,
por exemplo, as interações com os marcadores físicos podem ser
realizadas com as duas mãos e até mesmo com o corpo [Brave et al,
1998].
Para que o uso das interfaces tangíveis seja intuitivo e

natural, sem a necessidade de um treinamento específico para sua
utilização, é necessária a escolha de objetos físicos e metáforas
comuns aos usuários que irão utilizá-las, assim os usuários podem
basear-se nas suas habilidades e experiências desenvolvidas
durante o curso de sua vida [Billinghurst et al, 2005].
Existem muitas aplicações e pesquisas de interfaces

tangíveis aplicadas a JE [Bernardes et al, 2005; Paiva et al, 2003;
Tangible Media Group, 2007]. Alguns jogos eletrônicos comerciais
fazem uso deste tipo de interface, como o uso de pistolas, pedais,
volantes, manches e até baquetas de bateria. Nem todas as
aplicações de controles não-convencionais caracterizam-se como
interface tangível, pelo simples fato de que nem sempre o controle
é mapeado diretamente e unicamente com o elemento virtual
correspondente. Assim, um controle na forma de cabo de raquete
usado em um jogo de tênis virtual da mesma forma que um jogador
desse esporte movimentaria uma raquete real é uma interface
tangível. Já esse mesmo bastão usado para movimentar o curso na
tela não seria uma interface tangível.
O console de videogame recentemente lançado “Wii”

[Nintendo Wii, 2007], com seu controle sem fio com sensores de
movimentos, pode atuar em alguns jogos eletrônicos como uma
288
interface tangível, como por exemplo no jogo eletrônico “Wii

Sports”, onde o controle pode ser utilizado como uma raquete de
tênis ou como um taco de baseball.
7.2.4. Agentes Inteligentes e Vida Artificial

As aplicações em JE e RV são povoadas não apenas por seres
humanos mas também por agentes artificiais, conhecidos em JE
como Non-Player Characters, ou apenas NPCs. Estes agentes são
objetos autônomos no ambiente, isto é possuem comportamento
que não depende apenas da interação com os outros objetos para se
manifestar, possuem a mesma representação no ambiente que os
habitantes humanos (por avatares), mas seu comportamento é
controlado por técnicas de Inteligência Artificial (IA). Dado a
complexidade na geração das imagens gráficas em taxas de quadros
por segundos adequadas, acima de 30 quadros por segundo, em JE
e RV, durante muito tempo os algoritmos de IA utilizados foram
muito simples, gerando comportamentos muito previsíveis e
superficiais, não obstante pudessem ser divertidos em JE. Com o
aumento no realismo gráfico, os usuários tanto de JE quanto de RV
tendem a ter também uma expectativa alta em relação aos demais
elementos que podem interagir no ambiente. Comportamentos
muito artificiais e pobres para os agentes em JE e RV estão
começando a quebrar o sentido de imersão dos usuários [Bianchini,
2005].
Além das técnicas sofisticadas para os comportamentos dos

agentes, certas situações em JE e RV exigem comportamentos
consistentes, que não quebrem a imersão, mas que são aplicados
não a um, mas a um grupo de agentes. O importante não é o
comportamento individual de cada agente, mas o seu
comportamento global como um grupo. Neste sentido, técnicas de
Vida Artificial (VA) trazem realismo para simulação de grupos,
289
como um grupo de animais ou uma multidão de pessoas. Técnicas

de VA também podem ser utilizadas na evolução do
comportamento dos agentes. Resultados muito interessantes destas
técnicas podem surgir devido ao seu caráter emergente: situações
não previstas explicitamente inicialmente pelos desenvolvedores
podem emergir da interação dos diversos agentes entre si e com o
meio, levando a experiências mais ricas e dinâmicas nestes
ambientes.
7.3. Jogos e Realidade Virtual

Está cada vez mais freqüente o uso de JE como ferramentas ou
objetos de pesquisa no meio científico [Rosenbloom, 2003].
Devido à grande popularização e demanda por poder de
processamento visual, os jogos eletrônicos se tornaram o norteador
do desenvolvimento de microcomputadores com alta capacidade
gráfica.
Por serem explorados como produto de massa, os jogos

eletrônicos ainda se limitam a plataformas computacionais de
baixo custo. Por influência desta condição, os computadores
pessoais que custam alguns milhares de dólares são capazes de
renderizar cenas altamente complexas, custando dezenas, até
mesmo centenas de vezes menos que uma estação gráfica utilizada
em renderizações mais elaboradas, como em animações pra o
cinema ou visualização científica de dados (Swartout and van Lent,
2003). As grandes empresas que produzem hardware gráfico visam
primeiro antecipar e atender os requisitos dos estúdios
desenvolvedores de JE, enquanto se contentam em atender às
necessidades de visualização científica como um efeito colateral
[Rhyne, 2002].
290
Uma vez tendo ajudado a popularizar o acesso a recursos

gráficos em sistemas computacionais, a indústria de JE está
influenciando o ambiente científico, sendo utilizados sistemas
oriundos dos jogos eletrônicos (como os game engines) nas mais
diversas aplicações, passando por propósitos militares [Kumagi,
2001], educativos e teatrais [Jacobson and Hwang, 2002]. Olanda
descreve um sistema feito em RV com objetivos de entretenimento
que simula a exploração da superfície do planeta Marte [Olanda,
2006]. Em muitos casos game engines comerciais criados para JE
servem de plataforma para a visualização de dados e simulações
físicas.
Um outro uso resultante da melhoria gráfica dos jogos

eletrônicos é a criação de novas formas de visualização de arte.
Jacobson e Hwang (2002) adaptaram um game engine comercial
para ser utilizado em uma CAVE ao invés de um monitor. Com o
auxílio deste sistema é possível a exibição de mostras de arte de
forma panorâmica, isto é, com um grande campo de visão.
Aplicações na área médica também são comuns. Slater et al

(2001) descreve o uso de JE e RV no tratamento de fobias e
traumas. Neste sistema, o paciente é exposto a um ambiente virtual,
no qual são realizadas simulações de forma a auxiliar o paciente a
superar o problema. A grande vantagem é que o paciente não está
exposto à situação real, que poderia causar algum tipo de dano
físico ou psicológico maior. Losh (2006) descreve um sistema de
simulação em RV chamado Virtual Iraq que tenta diminuir os
efeitos de estresse pós-traumático de soldados americanos após a
invasão do Iraque por forças lideradas pelo EUA em 2003.
291
7.4. Jogos e Realidade Aumentada

Em sua primeira importante review sobre Realidade Aumentada,
Azuma (1997) não mencionava jogos eletrônicos. Citava
entretenimento como uma das aplicações dessa tecnologia, mas
referindo-se principalmente à produção de filmes para o cinema. Já
em 2002, jogos eletrônicos são citados por ele como uma
importante aplicação, com diversos exemplos [Azuma, 2002]: uma
mudança causada principalmente pelo barateamento do hardware
usado em aplicações de RA, tornando-as apropriadas para o
entretenimento doméstico. Treinamento também é uma importante
aplicação de RA citada por Azuma e muitos jogos têm sido usados
para esse fim. Atualmente, até mesmo a indústria mainstream de
jogos eletrônicos investe em RA, como evidenciado pelo “EyeToy”
para Playstation2.
Uma preocupação constante da indústria de jogos

atualmente, no entanto, como obter jogabilidade original em seus
produtos [BusinessWeek, 2006], o que se torna cada vez mais
difícil conforme os paradigmas com sucesso de jogos e interação
são explorados incessantemente. Novas formas de interação, como
o uso do controle do “Wii” como interface tangível e o já citado
uso de RA com o “EyeToy”, são soluções interessantes para esse
problema, que exemplificam as vantagens que a RA pode trazer ao
universo dos jogos eletrônicos. Outra vantagem é a possibilidade
de combinar as características de jogos e brincadeiras clássicos
(que não usam o meio eletrônico, como por exemplo jogos de
cartas ou tabuleiro), como seu forte componente de socialização,
com as dos jogos eletrônicos (gráficos e sons dinâmicos e atraentes,
IA, comunicação em rede, manutenção das regras) através da
combinação de elementos reais e virtuais [Magerkurth et al., 2004].
Por outro lado, jogos são uma aplicação bastante adequada

para testar novas formas e dispositivos de interface, como RA
292
[Starner et al., 2000]. Devido ao caráter lúdico e metáforas bem

conhecidas em JE, os usuários se dispõem com mais facilidade a
lidar com metáforas e tecnologias de interface mesmo quando
ainda em estágio de protótipo e certamente com problemas. Além
disso, a popularidade dos jogos auxilia na divulgação da nova
tecnologia.
A principal classificação de jogos em realidade aumentada

proposta nesse trabalho refere-se à área de jogo, separando os que
fazem uso de grandes áreas, os que precisam de áreas limitadas e
preparadas e os que se aproveitam da mobilidade de dispositivos
como celulares ou PDAs. As características, principalmente o
tamanho, da área em que se passa um jogo em realidade aumentada
têm grande influência não só em sua jogabilidade como na
tecnologia usada em sua implementação.
Jogos projetados para áreas relativamente grandes (muitas

vezes chamados “jogos outdoor"), como um campus universitário,
ou um grande edifício, dependem de computadores “vestíveis”
(normalmente carregados nas costas dos jogadores, em uma
montagem especial similar a uma mochila). A saída gráfica é
normalmente realizada através de HMDs , portáteis e mais viáveis
do que distribuir monitores ou projetores em grandes áreas. Além
disso, esses HMDs normalmente são do tipo semi-transparente, por
razões de segurança. Um dos problemas mais complexos em
realidade aumentada, o registro, torna-se ainda mais desafiador em
grandes áreas e normalmente é necessária a combinação de várias
técnicas de registro para tratá-lo. Um conhecimento prévio do
ambiente, seja na forma de um modelo 3D ou planta em 2D, bem
como o uso de GPS são constantes na implementação desses jogos
eletrônicos, normalmente auxiliadas por técnicas de visão
computacional ou sensores de movimento e orientação.
293
Em relação à jogabilidade, a metáfora física prevalece nos

jogos para grandes áreas. Uma das maiores motivações para esses
jogos é justamente trazer um jogo eletrônico para o mundo real e
interagir de acordo. Sendo assim, para deslocar-se ou mudar seu
ponto de vista em um desses jogos, o jogador anda, corre, pula ou
vira a cabeça na realidade e assim por diante.
Já os jogos projetados para áreas menores e delimitadas

podem fazer uso de diversas opções de tecnologia para sua
implementação. Enquanto HMDs são comuns, a composição das
imagens real e virtual por vídeo é tão comum quanto a ótica, ao
contrário dos jogos para grandes áreas, e monitores e projetores em
diversas configurações também são largamente utilizados.
Raramente há a necessidade de se usar computadores portáteis ou
vestíveis, e a tarefa de registro pode ser feita de forma mais
simples, utilizando-se uma única técnica isoladamente
(normalmente visão computacional, muitas vezes com câmeras em
posições fixas e conhecidas, mas sensores de posição e outras
técnicas também são usados). Além disso, o jogo normalmente faz
uso de algum elemento do ambiente, como uma mesa, caixas sobre
uma grade desenhada no chão, uma parede de cor uniforme, um
cenário etc.
Um terceiro tipo de jogo envolve dispositivos móveis e não

depende do local onde esteja sendo jogado. Essa independência é
que caracteriza esse tipo de jogo, e não somente o uso de
dispositivos móveis, visto que os mesmos também podem ser
usados em jogos eletrônicos em pequenas áreas. A principal
dificuldade para esse tipo de aplicação é a capacidade de
processamento consideravelmente mais baixa, atualmente, dos
dispositivos portáteis.
294
Os principais jogos em RA para grandes áreas são o

“NetAttack” [Fraunhofer, 2007], o “Human Pacman” [Cheok et al.,
2004] e o “ARQuake” [Thomas et al., 2002]. Todos utilizam HMDs
semi-transparentes, computadores vestíveis, GPS e comunicação
por rede sem fio. O “NetAttack” e o “Human Pacman” utilizam
mapas 2D do ambiente real, enquanto o “ARQuake” necessita de
um modelo 3D. O “Human Pacman” é o único que não utiliza
visão computacional e marcadores fiduciais para auxiliar no
registro, utilizando sensores ativos. Cada um dos jogos tem
peculiaridades interessantes, como o uso de uma "arma" com force
feedback como dispositivo de entrada no “ARQuake”, de interfaces
tangíveis no “Human Pacman” e de colaboração com jogadores
utilizando interfaces convencionais nele e no “Net Attack”.
Parte da equipe responsável pelo desenvolvimento do

“ARQuake”, em conjunto com a iniciativa privada, está
desenvolvendo um hardware e um game engine em "Realidade
Aumentada" [A_RAGE, 2007]. A expressão está entre aspas pois,
embora o “A_RAGE” combine elementos reais e virtuais através
de um HMD semi-transparente e tenha interação em tempo real
através de um gamepad, não há registro 3D entre os objetos reais e
virtuais, não satisfazendo a definição de RA de Azuma (1996).
Jogos de RA em áreas limitadas, além de normalmente

terem uma implementação mais simples e de menor custo,
permitem uma maior variedade de metáforas. Talvez devido a esses
fatores são bem mais numerosos que os para grandes áreas e serão
apresentados de forma resumida na Tabela 7.1.
É muito comum que jogos sejam apresentados como sendo

de RA, inclusive em trabalhos científicos, mesmo quando não
combinam elementos reais e virtuais ou quando não fazem o
295
registro 3D desses elementos, meramente por usarem HMDs ou

marcadores fiduciais. Tais projetos não foram considerados aqui.
Nome/ Visualização/
Registro Interação
referência composição
Metáfora de Jogos de Tabuleiro
KnightMage,
CandyLand, Monitores Visão computacional
Tangível (peças
Monopoly/ (Presentation (limitada), RFID,
com RFID), PDA
Magerkurth Manager)/vídeo sensores magnéticos
et al. (2004)
Projeção simples,
Herding Sheep/ Visão computacional
monitor (laptop, Tangível, apontar e
MacWilliams (ferramenta DTrack
PDA), HMD voz, laptop, PDA
et al. (2003) da ART)
/vídeo e ótica
Tangível
Monkey Bridge
Visão computacional (marcadores
/Barakonyi et HMD/ótica
ou sensor magnético fiduciais ou "puck"
al. (2005)
magnético)
False prophets/ Tangível (peças
Projeção Diodos e sensores
Mandryk et al. com diodo
simples/ótica infravermelho
(2002) infravermelho)
AR Mahjong/ Personal interaction
Szalavári et al. HMD/ótica sensores magnéticos panel (Szalavári e
(1998) Gervautz, 1997)
Ulbricht e Tangível
Schmalstieg HMD/ótica Visão computacional (marcadores
(2003) fiduciais)
Jumanji
Tangível (cubos
Singapore/
HMD/vídeo Visão computacional com marcas
Zhou et al.
fiduciais)
(2004)
Kanji Learning
Tangível
/Wagner e Monitor
Visão computacional (marcadores
Barakonyi (PDA)/vídeo
fiduciais)
(2003)
296
TARBoard/Lee Tangível (cartas,

Monitor/Vídeo Visão computacional
et al. (2005) tabuleiro)
Perceptive
MIND-Warping Projeção simples
Workbench (visão e Tangível (peças) ou
/ Starner et al. no tabuleiro ou
infravermelho) ou gestos e voz
(2000) HMD/ótica
rádio
Metáfora de Esportes
Rastreamento
AR2Hockey/
magnético da cabeça
Ohshima et al. HMD/ótica Tangível (mallets)
e visão
(1998)
computacional
Golf Simulator/
Govil et al. HMD/vídeo Visão computacional Tangível (taco, bola)
(2000)
Visão
AR Bowling/
computacional,
Matysczok et HMD/vídeo Não-tangível (bola)
dataglove e sensor
al. (2004)
magnético
AR Billiards/
Visão computacional Tangível (o próprio
Jebara et al. HMD/vídeo
(cor) jogo de bilhar)
(1997)
Ping Pong
Projeção Tangível (o próprio
Plus/ Ishii et al. Som
simples/ótica jogo de ping-pong)
(1999)
CamBall/
Woodward et Monitor/vídeo Visão computacional Tangível (raquete)
al. (2004)
Metáfora Física
RV Border
Guards, Sensores magnéticos
AcquaGauntlet HMD/ótica e modelo 3D do Gestos
/ Ohshima et ambiente
al. (1999)
Bladeships/ Sensores magnéticos
Não-tangível (os
Takemura et HMD/ótica (mão, cabeça) e
bladeships)
al. (2004) modelo 3D do
297
ambiente
Kick Ass Kung
Projeção Não-tangível
Fu/Hamalainen Visão computacional
simples/vídeo (oponente)
et al. (2005)
Sensores magnéticos
Touch Space/ e visão Gamepad, posição e
Cheok et al. HMD/vídeo computacional co-localização,
(2002) (marcadores tangível (caixas)
fiduciais)
AR PushPush/ Visão computacional
Kim et al. HMD/vídeo (marcadores Gestos
(2005) fiduciais)
Outros
ARHockey/
Projeção Sensores
Vieira et al. Tangível (batedores)
simples/ótica infravermelhos
(2006)
Câmera
Gestos (posição
Kombat/ Paula Monitor/vídeo Visão computacional
corporal)
et al. (2006)
Invisible Train/ Visão computacional
Monitor
Wagner et al. (marcadores Touchscreen
(PDA)/vídeo
(2005) fiduciais)
Glass
Xylophone Projeção Visão computacional
Tangível (baquetas)
/Kim et al simples/vídeo (infravermelho)
(2004)
Interactive
Projeção Gestos, não-tangível
Storytelling/ Visão computacional
simples/vídeo e interpretação de
Charles et al. (features)
(cromaqui) linguagem natural
(2004)
Tabela 7.1 - Jogos em Áreas Limitadas
O “SymBall” [Hakkarainen e Woodward, 2005], uma

versão móvel do “CamBall” [Woodward et al., 2004], e o “chute a
gol mobile" [Paelke et al., 2004] são os principais representantes
298
dos jogos independentes de local. Ambos utilizam a câmera do

portátil como dispositivo de entrada, através de técnicas de visão
computacional, e a sua tela como saída gráfica.
7.5. Tendências
Uma tendência tanto para JE quanto RV é o aparecimento de
ambientes virtuais tridimensionais genéricos, acessíveis por
microcomputadores padrão pela internet, como o “Second Life”
[Second Life, 2006]. Tais ambientes genéricos não têm um objetivo
específico, fica a cargo de seus inúmeros partipantes (“habitantes”)
decidir se utilizarão sua infra-estrutura para fins de comunicação
(como pontos de encontro, propaganda, etc), fins de entretenimento
(como jogos, exibições, etc), comerciais (venda de conteúdo ou
serviços dentro do ambiente) ou de aprendizado (museus virtuais,
ensino a distância, etc). Assim como os game engines, podem ser
adotados como base para as aplicações científicas de RV e, da
mesma forma, essa prática deve ser analisada com cautela, devido
às suas características e restrições.
No campo dos game engines, novas oportunidades

aparecem com relação à democratização ao acesso à plataforma de
consoles, através de SDKs públicos (como o “XNA Game Studio
Express” da Microsoft) e o formato de distribuição por digital
downloads. Ao mesmo tempo, os novos consoles “Nintendo DS” e
“Wii”, bem como a série “EyeToy” da Sony, criam uma ampla base
instalada de dispositivos anteriormente não-convencionais de
interface, como telas sensíveis ao toque, microfones, sensores de
posição e movimento, force-feedback, conexão sem-fio, captura de
imagens e visão computacional. Ou seja, tais dispositivos podem
facilitar tanto seu uso em projetos de pesquisa de RV, quanto
diminuir o distanciamento do grande público a esses novos estilos
interativos.
299
Alguns exemplos foram citados, anteriormente neste texto,

da atividade batizada como “serious games”, ou seja, a utilização
das ferramentas e métodos característicos do desenvolvimento de
jogos para aplicações diferentes do entretenimento. De modo geral,
essa tendência se apresenta cada vez mais forte e mostrando ainda
um grande potencial de crescimento, exemplificado por resultados
favoráveis em um número crescente de aplicações e áreas do
conhecimento.
Peters e Itti (2006) apresentam pesquisas voltadas a prever

o comportamento do usuário e a possibilitar a criação de agentes
com um comportamento mais humano. Este é um exemplo de
evolução conjunta que pode ser aplicada tanto aos jogos eletrônicos
como em aplicações científicas. Neste aspecto, a tendência atual é
aumentar a complexidade dos comportamentos fazendo uso de
técnicas de aprendizagem, para que os agentes possam se adaptar
melhor às diversas situações que surgem nestes ambientes; incluir
conceitos de computação afetiva tanto no processo de inferência
quanto na representação externa que os usuários têm acesso;
técnicas que permitam aos agentes apresentar comportamentos
mais voltados a objetivos, como no modelo Belief Desire Intention
de agentes; técnicas de Sistemas Multi Agentes para a cooperação
entre os agentes na solução de problemas.
7.6. Conclusão
Este capítulo apresentou os principais conceitos relacionados à
tecnologia de jogos eletrônicos, com destaque para game engines e
interfaces tangíveis. Foi analisada a interação entre as áreas de RV
e RA com a de jogos eletrônicos, tendo-se apresentado o estado da
arte dos jogos baseados em tecnologia de RA. Finalmente foram
discutidas algumas das principais tendências da indústria e
pesquisa de jogos eletrônicos e suas relações com RV e RA. Para o
300
leitor interessado em se aprofundar no assunto é apresentada a

seguir uma vasta bibliografia, utilizada como referência para a
elaboração deste texto.
7.7. Referências Bibliográficas

A_RAGE “A_RAGE: Augmented Reality Gaming Engine” [sítio
web]. Disponível em: <http://www.a-rage.com>. Acesso em:
março de 2007.
Azuma, R. “A Survey of Augmented Reality”. In: Presence:
Teleoperators and Virtual Environments, n. 6, p. 355-385, 1997.
Azuma, R.; Baillot, Y.; Behringer, R.; Feiner, S.; Julier, S.
Macintyre, B. “Recent Advances in Augmented Reality”. In:
IEEE Computer Graphics and Applications, v. 21, n. 6, p. 34-47,
2001.
Barakonyi, I.; Markus W.; Thomas P.; Schmalstieg D.
“MonkeyBridge: Autonomous Agents in Augmented Reality
Games”. In: ACM SIGCHI INTERNATIONAL
CONFERENCE ON ADVANCES IN COMPUTER
ENTERTAINMENT TECHNOLOGY, 2005. Anais... ACM,
2005.
Bernardes Jr., J. L.; Dias, J. S.; Tori, R. (2005). “Exploring Mixed
Reality User Interfaces for Eletronic Games”, In: Proceedings of
WJOGOS 2005, 353-358.
Bianchini, R.C. “Uma Arquitetura Bdi para Comportamentos
Interativos de Agentes em Jogos Computacionais”, [tese de
doutorado], 2005.
Bianchini, R. C.; Bernardes Jr., J. L.; Cuzziol, M.; Jacober, E,;
Nakamura, R.; Tori, R. (2006) “Jogos Eletrônicos e Realidade
Virtual”, Fundamentos e Tecnologia de Realidade Virtual e
Aumentada, R. Tori e C. Kirner (org.), Porto Alegre, SBC, p.
199-219. disponível em www.interlab.pcs.poli.usp.br
301
Billinghurst, M.; Grasset, R.; Looser, J. (2005). “Designing

augmented reality interfaces”, ACM SIGGRAPH Computer
Graphics, 39, 1, 17-22.
Brave, S.; Ishii, H.; Dahley, A. (1998). “Tangible interfaces for
remote collaboration and communication”, In: Proceedings of
the 1998 ACM conference on Computer supported cooperative
work, 169-178.
Businessweek. “Electronic Arts: A Radical New Game Plan”.
Disponível em:
<http://www.businessweek.com/magazine/content/06_12/b3976
086.htm>. Acesso em: março de 2006.
Caillois, R. “Les jeux et les homes”. Gallimard, 1957.
Charles, F.; Cavazza, M.; Mead, S.; Martin, O.; Nandi, A.;
Marichal, X. “Compelling Experiences in Mixed Reality
Interactive Storytelling”. In: ACM SIGCHI ADVANCES IN
COMPUTER ENTERTAINMENT, 2004. Anais... ACM, 2004.
p. 32-41.
Cheok, A. et al. “Human Pacman: a Sensing-Based Mobile
Entertainment System with Ubiquitous Computing and Tangible
Interaction”. In: WORKSHOP ON NETWORK AND SYSTEM
SUPPORT FOR GAMES, 2, 2003. Anais... 2003. p. 106-117
Crawford, C. “Chris Crawford on Game Design”. New Riders,
2003.
Eberly, D. H., “3D Game Engine Design: A Practical Approach to
Real-Time Computer Graphics”, Morgan-Kaufmann, 2000.
Fraunhofer F. “NetAttack Homepage”. [sítio web] Disponível em:
<http://www.fit.fraunhofer.de/projekte/netattack/index_en.xml?
aspect=ar-gaming>. Acesso em: abril de 2006.
Govil, A.; You, S.; Neumann, U. “A Video-Based Augmented
Reality Golf Simulator”. In: ACM INTERNATIONAL
302
CONFERENCE ON MULTIMEDIA, 8, 2000. Anais... ACM,

2000.
Hakkarainen, M.; Woodward, C. “SymBall: Camera Driven Table
Tennis for Mobile Phones”. In: ACM SIGCHI
INTERNATIONAL CONFERENCE ON ADVANCES IN
COMPUTER ENTERTAINMENT TECHNOLOGY, 2005.
Anais... 2005.
Hamalainen, P.; Ilmonen, T.; Hoysniemi, J.; Lindholm, M.;
Nykanen, A. “Martial Arts in Artificial Reality”. In:
INTERNATIONAL CONFERENCE FOR HUMAN-
COMPUTER INTERACTION, 2005. Anais... 2005.
Hause, K. “What to Play Next: Gaming Forecast 1999-2003”. In:
CONFERENCE ON HUMAN FACTORS IN COMPUTING
SYSTEMS, 2003. Anais... 2003. p. 894-895.
Ishii, H.; Ullmer, B. (1997). “Tangible bits: towards seamless
interfaces between people, bits and atoms”, In: Proceedings of
the SIGCHI conference on Human factors in computing
systems, 234-241.
Ishii, H. Et Al. “PingPongPlus: Design of an Athletic-Tangible
Interface for Computer-Supported Cooperative Play”. In: ACM
CONFERENCE ON HUMAN FACTORS IN COMPUTING
SYSTEMS, 1999. Anais... 1999.
Jacobson, J. and Hwang, Z. “UnrealTournament for Immersive
Interactive Theater”. In: Communicatins of the ACM, 45(1):39–
42, 2002.
Jebara, T.; Eyster, C.; Weaver, J.; Starner, T.; Pentland, A.
“Stochasticks: Augmenting the Billiards Experience with
Probabilistic Vision and Wearable Computers”. In:
INTERNATIONAL SYMPOSIUM ON WEARABLE
COMPUTERS, 1, 1997. Anais... IEEE, 1997. p. 138-145.
303
Kim, I.; Lee, H.; Kim, H. “Magic Mirror: A new VR platform

design and its applications”. In: ACM SIGCHI ADVANCES IN
p. 343-348.
Kim, K. et al. “ARPushPush: Augmented Reality Game in Indoor
Environment”. In: INTERNATIONAL WORKSHOP ON
PERVASIVE GAMING APPLICATIONS, 2005. Anais... 2005.
Kumagi, J. “Fighting in the streets”. In: IEEE Spectrum, 38(2):68–
71, 2001.
Lee, W.; Woo, W.; Lee, J. “TARBoard: Tangible Augmented
Reality System for Table-top Game Environment”. In:
INTERNATIONAL WORKSHOP ON PERVASIVE GAMING
APPLICATIONS, 2005. Anais... 2005.
Lewis, M., Jacobson, J. (2002), “Game Engines in Scientific
Research”, In: Communications of the ACM, Vol. 45, No. 1, p.
27-31.
Losh, E. “Making Things Public: Democracy and Government
Funded Videogames and Virtual Reality Simulations”, In:
Sandbox Symposium July 29-30, 2006,
Macwilliams, A.; Sandor, C.; Wagner, M.; Bauer, M.; Klinker, G.;
Bruegge, B. “Herding Sheep: Live System Development for
Distributed Augmented Reality”. In: IEEE AND ACM
INTERNATIONAL SYMPOSIUM ON MIXED AND
AUGMENTED REALITY, 2, 2003. Anais... ACM, 2003.
Magerkurth, C.; Engelke, T.; Memisoglu, M. “Augmenting the
Virtual Domain with Physical and Social Elements”. In: ACM
SIGCHI ADVANCES IN COMPUTER ENTERTAINMENT,
2004. Anais... ACM, 2004. p. 163-172.
Mandryk, R.; Maranan, D.; Inkpen, K. “False Prophets: Exploring
Hybrid Board/Video Games”. In: CONFERENCE OF HUMAN
304
FACTORS IN COMPUTING SYSTEMS, 2002. Anais... 2002.

p. 640-641.
Matysczok, C.; Radkowski, R.; Berssenbruegge, J. “AR-Bowling:
Immersive and Realistic Game Play in Real Environments
Using Augmented Reality”. In: ACM SIGCHI ADVANCES IN
p. 269-274.
McShaffry, M., “Game Coding Complete”, Paraglyph Press, 2003.
Nintendo “Wii.Nintendo.com”. [sítio web] Disponível em:
<http://wii.nintendo.com/home.html>, acessado em Fevereiro de
2007.
Olanda, R.; Pérez, M.; Morillo, P. et al. “Entertainment Virtual
Reality System for Simulation of Spaceflights Over the Surface
of the Planet Mars”, In, VRST 06, November 1-3, 2006.
Ohshima, T. et al. “AR2Hockey: A Case Study of Collaborative
Augmented Reality”. In: VIRTUAL REALITY ANNUAL
INTERNATIONAL SYMPOSIUM, 1998. Anais... IEEE, 1998.
p. 268-275.
Ohshima, T.; Satoh, K.; Yamamoto, H.; Tamura, H. “RV-Border
Guards: A Multi-player Entertainment in Mixed Reality Space”.
In: IEEE AND ACM INTERNATIONAL WORKSHOP ON
AUGMENTED REALITY, 2, 1999. Anais... ACM, 1999.
Paelke, V.; Reimann, C.; Stichling, D. “Foot-based mobile
Interaction with Games”. In: ACM SIGCHI ADVANCES IN
p. 321-324.
Paiva, A.; Chaves, R.; Vala, M.; Bullock, A.; Andersson, G.; Hook,
K. “Towards Tangibility in Gameplay: Building a Tangible
Affective Interface for a Computer Game”, In: Proceedings of
International Conference on Multimodal Interfaces ICMI’03,
60-67. 2003.
305
Paula, L.; Bonini, R.; Miranda, F. “Camera Kombat – Interação

Livre para Jogos”, In: Anais SBGames 2006.
Peters, R. J.; Itti, L. “Computational mechanisms for gaze direction
in interactive visual environments”. In: ACM:27-29, Março
2006
Rhyne, T. “Computer Games and Scientific Visualization”. In:
Communications of the ACM, 45(7):40–44, 2002.
Rosenbloom, A. “A Game Expirience in Everyday Application”.
In: Communications of the ACM, 46(7):28–31, 2003.
Second Life “Second Life: Your World. Your Imagination”. [sítio
web] Disponível em: http://secondlife.com Acessado em
Fevereiro, 2007.
Slater, M., Pertaub, D. P. and Baker, C. “Medicine Meets Virtual
Reality 2001: Outer Space, Inner Space, Virtual Space, volume
Studies in Health Technology Studies” In: IOS Press,
Amsterdam, Netherlands, 2001.
Starner, T. et al. “Mind-Warping: Towards Creating a Compelling
Collaborative Augmented Reality Game”. In:
INTERNATIONAL CONFERENCE ON INTELLIGENT
USER INTERFACES, 5, 2000. Anais... ACM, 2000. p. 256-
259.
Swartout, W.; van Lent, M. “Making Game of a System Design”.
In: Communications of the ACM, 46(7):32–39, 2003.
Szalavári, Z.; Eckstein, E.; Gervautz, M. “Collaborative Gaming in
Augmented Reality”. In: ACM SYMPOSIUM ON VIRTUAL
REALITY SOFTWARE AND TECHNOLOGY, 1998. Anais...
1998. p. 195-204.
Takemura, M.; Haraguchi, S. ; Ohta, Y. “An Interactive Attraction
in Mixed Reality: Bladeships”. In: INTERNATIONAL
CONFERENCE ON VIRTUAL SYSTEMS AND
MULTIMEDIA, 10, 2004. Anais... 2004.
306
Thomas, B.; Close, B.; Donoghue, J.; Squires, J.; De Bondi, P.;
Piekarski, W. “First Person Indoor/Outdoor Augmented Reality
Application: ARQuake”. In: Personal and Ubiquitous
Computing, n. 6, p. 75-86, 2002.
TMG “MIT Media Lab - Tangible Media Group”. [sítio web]
Disponível em: <http://tangible.media.mit.edu/>, acessado em
Fevereiro de 2007.
Ulbricht, C.; Schmalstieg, D. “Tangible Augmented Reality for
Computer Games”. In: THE IASTED INTERNATIONAL
CONFERENCE ON VISUALIZATION, IMAGING AND
IMAGE PROCESSING, 2003. Anais... IASTED, 2003. p. 950-
954.
Underkoffler, J.; Ishii, H. (1998). “Illuminating light: an optical
design tool with a luminous-tangible interface”, In: Proceedings
of the SIGCHI conference on Human factors in computing
systems, 542-549.
Vieira, B.; Theodoro, C.; Trias, L.; Miranda, F.; Tori, R.
“ARHockey: Um jogo de Realidade Aumentada Baseada em
Projetores”, In: Anais SBGames 2006.
Wagner, D.; Barakonyi, I. “Augmented Reality Kanji Learning”.
In: IEEE AND ACM INTERNATIONAL SYMPOSIUM ON
MIXED AND AUGMENTED REALITY, 2, 2003. Anais...
ACM, 2003.
Wagner, D.; Pintaric, T.; Ledermann, F. ; Schmalstieg, D. Towards
“Massively Multi-User Augmented Reality on Handheld
Devices”. In: INTERNATIONAL CONFERENCE ON
PERVASIVE COMPUTING, 3, 2005. Anais 2005.
Walther, B. K.; “Playing and Gaming: Reflections and
Classifications”. In: GAME STUDIES – THE
INTERNATIONAL JOURNAL OF COMPUTER GAME
RESEARCH, vol. 3, issue 1, May 2003. Disponível em:
307
<http://www.gamestudies.org/0301/walther>. Acesso em
Março, 2007.
Woodward, C.; Honkamaa, P.; Jäppinen, J.; Pyökkimies, E.
“CamBall – Augmented Networked Table Tennis Played with
Real Rackets”. In: ACM SIGCHI ADVANCES IN
p. 275-276.
Wittgenstein, L. “Philosophical Investigations”. 1953.
Zhou, Z.; Cheok, A.D.; Chan, T.; Li, Y. “Jumanji Singapore: An
Interactive 3D Board Game Turning Hollywood Fantasy into
Reality”. In: ACM SIGCHI ADVANCES IN COMPUTER
ENTERTAINMENT, 2004. Anais ACM, 2004. p. 362-363.
308
Capítulo
8
Aplicações Médicas usando
Realidade Virtual e Realidade
Aumentada
1 2
Fátima L. S. Nunes , Rosa M. E. M. Costa , Ana Cláudia M. T. G.
1 1 1 1
Oliveira , Sérgio R. Delfino , Larissa Pavarini , Ildeberto A. Rodello ,
1 1
José Remo F. Brega , Antônio C. Sementille
1
Programa de PósGraduação em Ciência da Computação
Centro Universitário Eurípides de Marília (UNIVEM)
Avenida Hygino Muzzi Filho, 529 CEP 17525901, Marília –
SP, Brasil
2
Universidade do Estado do Rio de Janeiro
IME – Dept de Informática e Ciência da Computação Rua São Francisco
o
Xavier 5246 Bl. B, CEP 20550013 Rio de Janeiro RJ Brasil
{fatima,lpavarini,rodello,remo,semente}@univem.edu.br,
rcosta@ime.uerj.br, {anatiessi, srdelfino}@gmail.com
Abstract
Virtual Reality (VR) and Augmented Reality (AR) application for

309

health area are developed with the most different purposes.

Independent of the application objectives, requirements for its
building can exceed that ones requested for application in other
areas. This chapter presents a practical vision of the important
requirements to building VR and AR applications for health area,
motivating a reflection and offering subsidies for planning tools for
those people who desire start develop or are already developing
application in this knowledge area.
Resumo
As aplicações de Realidade Virtual (RV) e Realidade Aumentada

(RA) para a área de saúde são desenvolvidas para as mais diversas
finalidades. Independente da finalidade da aplicação, os requisitos
para construí-la muitas vezes podem ir além daqueles exigidos
para aplicações destinadas a outras áreas. Este capítulo
apresenta uma visão prática dos requisitos importantes para
construir aplicações de RV e RA para a área de saúde, motivando
uma reflexão e oferecendo subsídios para o planejamento de
ferramentas daqueles que desejam adentrar ou estão
desenvolvendo aplicações neste campo de conhecimento.
8.1. Introdução
Os computadores e tecnologias de comunicação vêm sendo
utilizados de maneira crescente em diferentes áreas do
conhecimento, sendo que, na última década estes equipamentos se
disseminaram fortemente na área médica.
A tecnologia de Realidade Virtual (RV) vem despertando grande
interesse neste domínio, pois amplia as possibilidades de estudo e
prática de variadas técnicas e procedimentos médicos. Por outro
lado, a difusão das redes favorece as aplicações de telemedicina,
310

onde gráficos de alta resolução, imagens e áudio podem ser

transmitidos e integrados em diferentes tipos de sistemas.
A conjunção destes avanços impulsiona o crescimento do número
de experimentos e pesquisas que, por sua vez, exploram
sofisticadas técnicas de visualização, incorporando equipamentos
específicos capazes de gerar nos seus usuários sensações
semelhantes às do mundo real.
Este capítulo discute a utilização dos computadores na área médica,
aponta a exploração da Realidade Virtual e Realidade Aumentada
(RA) como tendências para esta área, descreve requisitos e
equipamentos necessários para o desenvolvimento dos trabalhos
neste domínio e destaca várias aplicações. Como as questões éticas
associadas às novas tecnologias extrapolam as fronteiras da
tecnologia e atingem a sociedade de maneira direta, este capítulo
apresenta, ainda, os valores éticos envolvidos no uso das novas
tecnologias na área medica.
8.2. Aplicações – características, requisitos e exemplos

As aplicações desenvolvidas para a área médica estão inseridas em
um contexto que exige ambientes virtuais realísticos e respostas a
ações que permitam ao usuário ter a sensação de estar vivenciando
uma situação ou procedimento como se fosse, de fato, real. Logo,
um dos aspectos fundamentais para a utilização de ambientes
virtuais neste domínio é a necessidade de geração de sensações
próximas às reais, ou seja, gerar presença em seus usuários.
A presença ou telepresença pode ser definida como a sensação que
a pessoa tem de realmente estar dentro do Ambiente Virtual, ou
seja, estar em um local diferente do que fisicamente se encontra
[Baños 2000]. A presença pode ser obtida através do estímulo dos
sentidos humanos (tato, visão e audição).
311

O senso de presença é dependente não somente das qualidades

físicas (resolução, realismo, interatividade, tempo de resposta), mas
também o que o usuário traz como bagagem psicológica. Cada
pessoa reage de maneira diferente quando expostas a mesma
situação real ou virtual [Baños 2000].
Neste sentido, North et al. (1998) observam que a concentração nas
atividades realizadas no ambiente virtual está diretamente
relacionada com o nível de interação e a adequação dos
equipamentos de entrada e saída. A seguir, são apresentados alguns
dos equipamentos mais utilizados em aplicações de RV e RA na
área médica.
8.2.1. Equipamentos de Entrada e Saída

8.2.1.1. Equipamentos de Entrada
Em geral, os rastreadores são equipamentos muito utilizados em
aplicações médicas, pois fornecem posicionamento em tempo-real
e orientação de movimento de objetos ou pessoas, explorando
diferentes tecnologias.
Eles podem ser do tipo mecânico, que fica preso à cabeça do
usuário dando-lhe pouca mobilidade; ultra-sônicos, que trabalham
por meio da emissão de ondas sonoras para determinar a posição do
usuário e dando-lhe liberdade de movimentos, mas tendo pouca
precisão; luminosos, que capturam, com o uso de câmeras,
pequenas luzes acopladas ao corpo do usuário, sendo de uso
confortável, mas consumindo muito tempo de processamento dos
sinais; óticos, que trabalham de forma contrária aos rastreadores
luminosos, com a câmera ficando presa à cabeça do usuário e as
luzes em pontos estratégicos do ambiente físico; entre outros.
Estes rastreadores podem estar acoplados a instrumentos de
manipulação cirúrgica [Aras 2007], permitindo ao usuário ter
312

precisão no controle dos seus movimentos e do mesmo tempo,

gerando resistência. Estes equipamentos são classificados no grupo
de interfaces hápticas e são essenciais na geração de sensações
próximas das obtidas em uma simulação real. O Capítulo 9
apresenta os equipamentos hápticos de forma detalhada.
As luvas também têm sido utilizadas em experimentos onde é
necessária a manipulação de objetos [Haluck 2007]. Capturam os
movimentos das mãos e dos dedos, fazendo com que as respostas
do ambiente sejam compatíveis com estes movimentos. Existem
vários tipos de luvas funcionando com diferentes mecanismos de
captura dos movimentos: tinta condutiva, esqueletos externos e
medidores de luminosidade.
8.2.1.2. Equipamentos de Saída
Para a geração de telepresença, os ambientes virtuais necessitam de
visão estereoscópica, que possibilitam a visualização de imagens
com um mais alto grau de realismo, fornecendo sensação de
profundidade ao observar o AV.
Um dos equipamentos que geram visão estereoscópica mais
utilizados na área médica é o HMD (Head-mounted display),
também conhecido como capacete. Permite isolar o usuário do
mundo real e projetar imagens que geram um alto grau de presença.
Entretanto, está no grupo de equipamentos de saída que gera mais
problemas de saúde em seus usuários, tais como náuseas e tonturas.
Os HMDs são utilizados em variados tipos de aplicações médicas,
desde tratamentos de fobias e problemas neuropsiquiátricos [Costa
2004] até a visualização de imagens para procedimentos cirúrgicos,
por meio de técnicas de RA [Reitinger 2006].
As Mesas de Projeção integram duas telas verticais em formato de
“L”. Os usuários têm possibilidades de visualização estereoscópica
e de interação com os objetos da cena [Barco 2007].
313

A Caverna ou Cave é uma pequena sala onde imagens são

projetadas sobre paredes translúcidas. Existem sensores de posição
que capturam os movimentos dos usuários e atualizam as imagens
projetadas. Em geral, possuem som 3D, gerando sensações bastante
reais. Sua grande vantagem é permitir que várias pessoas
compartilhem a mesma experiência [Diffusion 2007].
8.3. Criação de objetos tridimensionais

Em aplicações médicas, objetos tridimensionais (3D) são usados
para representar pacientes, equipamentos, ambientes (consultórios,
salas de cirurgia) e órgãos humanos.
Ferramentas para modelagens 3D oferecem inúmeros recursos para
a construção desses objetos sintéticos. No entanto, é necessária
uma certa dose de arte para construí-los, tarefa nem sempre trivial
para profissionais de Computação. Além disso, algumas aplicações,
como treinamento de procedimentos, podem exigir precisão em
tempo real. Nesses casos, o ideal é que os objetos 3D sejam
modelados a partir de dados provenientes de imagens médicas
reais. Uma solução para implementar objetos realísticos é a
utilização de imagens geradas por meio de equipamentos médicos.
A seguir é apresentada uma conceituação sobre algumas
modalidades médicas que podem gerar imagens para a criação de
um Ambiente Virtual (AV). Exemplos de métodos de utilização
dessas imagens são apresentados na seção 8.9.
As modalidades de diagnóstico por imagens se estabeleceram há
algum tempo, valendo-se de uma variedade de equipamentos de
aquisição como Tomografia Computadorizada (TC), Ressonância
Magnética Nuclear (RMN) e Ultra-Som (US).
Na TC a imagem deriva do tratamento informatizado dos dados
obtidos numa série de projeções angulares de raios-X. De maneira
simplificada, traduz uma secção transversal (uma "fatia") do corpo
314

do indivíduo (Figura 8.1a) [Wagner 2002].

A Ressonância Magnética Nuclear (RMN) é uma técnica que
permite determinar propriedades de uma substância por meio do
co-relacionamento da energia absorvida com a freqüência, na faixa
de megahertz (MHz) do espectro eletromagnético. Usa
propriedades dos núcleos dos átomos ou íons para mapear os
tecidos, sob a influência de um campo magnético, produzindo
imagens de alta qualidade (Figura 8.1b) [Hennel 1993].
A ultra-sonografia é um método diagnóstico que aproveita o eco
produzido pelo som para ver, em tempo, real as sombras
produzidas pelas estruturas e órgãos do organismo. As ondas
sonoras, ao encontrarem um anteparo, batem e são refletidas,
retornando ao seu ponto de origem. Se for medido o tempo
dispendido desde a emissão até a recepção do sinal de retorno,
pode-se determinar com boa precisão a distância que ele percorreu,
sendo possível a tradução em uma escala de cinza, que formará a
imagem dos órgãos internos (Figura 8.1c) [Handolin 2007].
Figura 8.1 – Imagens de CT, RMN e US: a) cérebro

obtido por CT; b) cérebro obtido por RMN; c) cérebro
de feto obtido por US (Sayeg, 2007).
As modalidades que geram seções transversais (RMN, CT, entre

315

outras) permitem um mapeamento direto para objetos virtuais 3D,

por meio de técnicas de reconstrução de imagens. Para aquelas que
geram apenas algumas visões, como US bidimensional (2D) e
mamografia, é possível aplicar técnicas de simulação dos objetos
3D a partir de medidas extraídas das imagens 2D, como será visto
na seção 8.9.
8.4. Detecção de colisão

Em aplicações médicas, precisão, tempo de resposta, conhecimento
do local de impacto e verificação de interpenetração entre os
objetos são fundamentais para a simulação de procedimentos de
forma realística. Por isso, a detecção de colisão torna-se um fator
extremamente relevante nesta classe de aplicações.
Lau et al. (2002) classificam este fator em dois grandes grupos:

detecção em objetos rígidos, que envolve o teste de penetração de
um objeto em outro e detecção em objetos deformáveis (superfícies
flexíveis), que trata, além da interação entre os objetos, das
deformações causadas por esta interação.
Na detecção de colisão em objetos rígidos, podem ser utilizadas
três aproximações: subdivisão hierárquica do espaço, subdivisão
hierárquica do objeto e cálculo incremental da distância [Lau
2002].
Os métodos de colisão em objetos deformáveis, por sua vez, são
baseados na subdivisão hierárquica do objeto, a qual pode ser de
dois tipos: objetos representados por polígonos encadeados e por
superfícies paramétricas (mapeamentos de algum subconjunto do
plano ao espaço). No primeiro caso, os objetos são deformados
alterando-se as posições dos vértices dos polígonos. Já os
representados por superfícies paramétricas são, geralmente,
deformados pela alteração do controle de pontos da superfície.
316

8.5. Deformação
Um AV pode ser composto de objetos estáticos, os quais mantêm a
mesma forma durante toda sua existência e dinâmicos, que mudam
de posição, forma ou aparência devido a alguma interação ocorrida.
Para que um AV seja realístico, é necessário planejá-lo da forma
mais próxima ao cotidiano, definindo suas ações e reações. A
deformação é uma das reações a serem analisadas, sendo que o
comportamento dos objetos deformados é representado por uma
simulação geométrica, física ou híbrida.
Choi et al. (2002) definem a simulação geométrica como aquela
baseada em manipulações de dados geométricos como vértices e
pontos. Usa artifícios matemáticos para obter resultados
visualmente convincentes que permitem mudança na estrutura do
objeto.
A simulação física utiliza a dinâmica, ramo da física que estuda as

relações entre as forças e os movimentos que são produzidos por
estas, ou seja, se preocupa com a causa e a conseqüência dos
estímulos causados [Ramalho 1993].
Na literatura três técnicas são as mais citadas para se obter
deformação de objetos em aplicações de RV: Free Form
Deformation (FFD) [Gibson 1997], Mass Spring (MS),
popularmente conhecido como Massa-Mola [Zill 2003] e
Elementos Finitos [Gladilin 2003].
Free Form Deformation (FFD) é uma técnica geométrica que provê
um alto nível de ajuste e controle individual dos pontos do objeto.
O objeto é envolvido por uma grade que sofre deformação (Figura
8.2). Mesmo sendo versátil, Choi et al. (2002) afirmam que neste
método é difícil limitar as deformações para pequenas regiões,
dificultando a obtenção de realismo na cena quando empregado em
um treinamento cirúrgico.
317

O Método dos Elementos Finitos originou-se da necessidade de

resolver elasticidade complexa e análise de estruturas. Sua
característica principal é a discretização da malha de um domínio
contínuo em um conjunto de subdomínios discretos. A
discretização do domínio é o primeiro passo em qualquer análise de
elementos finitos, pois a maneira na qual o domínio é discretizado
afetará as exigências de armazenamento no computador, o tempo
de processamento e a precisão dos resultados numéricos [Hirota et
al. 1999].
A teoria da elasticidade afirma que a deformação de um corpo é
proporcional à tensão aplicada desde que o limite elástico do
material não seja excedido [Zill 2003]. A análise de qualquer tipo
de estrutura pode ser feita pela integração das equações da teoria da
elasticidade. As dificuldades para realizar essa integração levam,
porém, à formulação de modelos matemáticos aproximados. Os
passos básicos para implementar este método podem ser obtidos
em [Hirota et al. 1999].
Figura 8.2 – Exemplo de objeto deformado utilizando o método

FFD (Hirota et. al., 1999).
O método Massa-Mola é uma técnica baseada na física que permite

a remodelagem de objetos deformados através de nós de massa
conectados por molas, como mostra a Figura 8.3 [Gibson 1997].
Envolve formulação de matrizes e sistemas de equações
318

diferenciais governadas por modelos dinâmicos para prevenir a

instabilidade numérica. A mola pode ser considerada como uma
estrutura que possui elasticidade e permite a deformação quando
uma pressão é exercida nela. A força de uma mola é normalmente
linear, baseada na lei de Hooke [Zill 2003], mas molas não lineares
podem ser usadas para simularem tecidos como pele humana, que
exibem um comportamento não elástico.
Figura 8.3 – Molas conectadas a um ponto de massa que

exercem forças nos pontos vizinhos quando a massa é deslocada
do resto das posições (Gibson, 1997).
8.6. Estereoscopia
Nas aplicações de RV e RA para proporcionar a sensação,

denominada imersão, são empregados conceitos de estereoscopia.
A visão estéreo é um dos principais mecanismos que permite ao ser
humano perceber a noção de profundidade. O olho esquerdo e o
olho direito sempre vêem imagens diferentes (apesar de muito
319

parecidas). Santos (2000) lembra que o cérebro usa esta diferença

para montar a imagem. O princípio de funcionamento da maioria
dos dispositivos estereoscópicos é a projeção de imagens distintas
aos olhos esquerdo e direito do observador, proporcionando
sensação de profundidade.
Há vários métodos para obter esta sensação. Johanson (2001)
apresenta a técnica de vídeo estereoscópico, no qual posicionam-se
câmeras separadas uma da outra que geram imagens distintas. O
método de polarização da luz baseia-se na utilização de filtros,
fazendo com que as imagens de um par estereoscópico sejam
polarizadas em planos verticais e horizontais [Machado 2003].
Óculos obturadores com lentes de cristal líquido são dispositivos
especiais, cujas lentes ficam instantaneamente transparentes ou
opacas de acordo com um sistema de controle prévio, sincronizados
com a imagem projetada. Existe também a visualização do par
estéreo [Lipton 1982], na qual são apresentadas duas imagens, lado
a lado, de forma com que cada imagem seja posicionada levando
em conta a distância entre os olhos do observador.
Ao método de estereoscopia que utiliza cores e diferentes
profundidades codificadas, dá-se o nome de Disparidade
Cromática. Esta técnica baseia-se na utilização de lentes especiais
denominadas ChromaDepth, as quais realizam a codificação das
profundidades através de suas cores. As lentes mudam a trajetória
da luz que as atravessa de acordo com a cor do objeto, gerando o
efeito estéreo.
O uso de anaglifos é apresentado por Schwartz (2004), explicando
que os objetos são obtidos por uma combinação finita (azul-
vermelho ou verde-vermelho) de cores, gerando uma sensação de
profundidade e imersão no ambiente. Cada um dos olhos utiliza um
filtro diferente de cor, dependendo da cor das lentes dos óculos
estereoscópicos feito de papel celofane ou semelhante, para a
320

visualização do par estéreo.
8.7. Precisão e tempo de resposta

Para que os simuladores sejam realísticos, é necessário que a
resposta ocorra em tempo real e que os métodos implementados
forneçam precisão.
Na Ciência da Computação, a expressão tempo real, em geral,
refere-se à interação simultânea entre sistemas ou pessoas, com
intervalos muito curtos ou com implicações sérias ao nível do
atraso. É, portanto, uma operação em que o par ação/reação deve
demorar menos tempo que o atraso máximo permitido pelo sistema
[Shaw 2003]. Essa conceituação de tempo real é importante em
sistemas de treinamento médico que utilizam RV e RA, visto que
tais aplicações devem atender ao requisito de fornecer uma resposta
dentro de um tempo máximo a fim de que usuário tenha a sensação
de que a reação do sistema é imediata à ação que executou no AV.
Este fator não é obtido trivialmente, visto que modelagem e
manipulação de objetos 3D, a interação por meio de dispositivos
convencionais e não convencionais e o uso de bibliotecas gráficas
contribuem para a inserção de atrasos ao sistema.
O fator precisão é outro requisito que merece destaque. Ao
contrário de outros campos de aplicações, como indústria e
entretenimento, a área médica, muitas vezes, trabalha com partes
do corpo humano de tamanho diminuto. Em uma aplicação de
telecirurgia, por exemplo, erros na ordem de milímetros são
inadmissíveis. A necessidade de realismo exige que muitos
sistemas, principalmente aqueles que simulam procedimentos,
forneçam precisão em relação à modelagem e manipulação de
objetos. E este requisito pode vir de encontro à necessidade de
tempo real, citada nesta seção. Desta forma, tempo e precisão são
dois fatores quase que conflitantes. Planejamentos adequados de
321

aplicações devem prever uma relação coerente entre eles a fim de

que a utilização dos sistemas desenvolvidos torne-se viável.
8.8. Exemplos de Aplicações

Inúmeros projetos de RV e RA estão sendo desenvolvidos com
tecnologias e finalidades diversas, como pode ser verificado nos
trabalhos destacados a seguir.
8.8.1. Educação e treinamento médico
Atualmente, a educação médica encara diversos desafios, seja no
campo das ciências biológicas ou na área tecnológica e estão
relacionados tanto à formação de futuros médicos, quanto à
atualização de profissionais já formados.
A conjunção do rápido aumento dos novos resultados na área
biomédica e da constante evolução das tecnologias associadas aos
procedimentos clínicos, demanda uma constante atualização por
parte dos profissionais da saúde. Para que o conhecimento
adquirido não se torne rapidamente obsoleto, é imprescindível
expandir e reforçar formas de educação permanente.
Por outro lado, o ensino da prática clínica requer contato direto
entre estudantes de medicina e pacientes, com a supervisão de
médicos e professores. Entretanto, os riscos de erros médicos
envolvidos nesta prática são bastante significativos, podendo
ocasionar problemas de saúde para os pacientes e problemas éticos
e judiciais para os profissionais médicos.
Apesar da pouca difusão da educação apoiada em computadores
nas escolas médicas, existem várias experiências sendo
desenvolvidas. Estes sistemas podem simular casos clínicos em
diferentes especialidades, diminuindo a necessidade de contatos
reais entre médico e pacientes em fases iniciais do aprendizado
médico.
322

Segundo Moline (1997) os ambientes virtuais provêem ferramentas

educacionais que cobrem os aspectos experimentais através de uma
abordagem didática, que explora principalmente, a visualização 3D
de partes do corpo humano.
O estudo da anatomia em módulos virtuais diminui a necessidade
do uso de cadáveres e oferece imagens com cores e
comportamentos mais reais. Em um humano virtual é possível
observar os órgãos em pleno funcionamento, diminuir os riscos de
erros de secção e os efeitos psicológicos adversos gerados pelo
contato com cadáveres reais.
Em geral, os Atlas para estudos da anatomia apresentam desenhos e
fotos que não permitem uma visão mais integrada de órgãos e
sistemas. Os Atlas digitais vêm suprindo algumas carências
observadas nos Atlas em papel, entretanto, não é possível a
visualização estereoscópica, nem possibilidades de observação
cooperativas.
O AnotomI [Monteiro 2006] é um Atlas digital de uso livre e
permite, de forma interativa, a manipulação e o estudo de estruturas
tridimensionais do corpo humano com descritivos contendo
informações textuais sobre cada estrutura. Este Atlas como
recursos de RV e estereoscopia, imersão simultânea de várias
pessoas, baixo custo de desenvolvimento e processamento e
aplicação de transparências, entre outras. Permite, ainda, a consulta
cooperativa que favorece o estudo e a discussão das estruturas
estudadas.
O Visible Human Project [Visible 2007] disponibiliza uma
representação tridimensional de um corpo feminino e outro
masculino, obtidas a partir da secção milimétrica de corpos
humanos.
Ramos et al (2005) desenvolveram um Atlas virtual da mama para

323

estudo da anatomia mamária e fisiopatologia do câncer de mama,

através da visualização de estruturas, antes só disponíveis em
imagens de livros ou estudo em cadáveres.
A RV aplicada à cirurgia abrange uma série de situações que vão
desde o planejamento de um procedimento até o treinamento de
técnicas e assistência para a sua realização. Neste sentido, o
primeiro simulador cirúrgico desenvolvido no Brasil [Machado
2003] visa a coleta de medula óssea. O sistema possui visualização
esteroscópica e manipulação tridimensional de um modelo do osso
ilíaco, dotado de camadas que possuem propriedades
físico-elásticas, que são percebidas pelo usuário através da
manipulação de dispositivos hápticos.
Na área de simulação de procedimentos merecem destaque a
simulação de ortopedia de Sourin et al. (2000) e diagnóstico de
câncer de próstrata de Burdea et al. (1999). Recentemente,
Balanuik et al. (2006) desenvolveram uma ferramenta de
visualização de cirurgias plásticas dos seios, voltada para a
educação do paciente e o planejamento cirúrgico.
8.8.2. Telecirurgia
A telecirurgia exige equipamentos sofisticados que possibilitam
comunicação rápida e manipulação cirúrgica segura. Isto envolve o
uso tanto de equipamentos de visualização 3D quanto de
manipulação do campo cirúrgico, que disponibilizem ao cirurgião
recursos para a realização dos procedimentos adequados, mesmo
estando distante do paciente. No local aonde a cirurgia é realizada,
é necessário um conjunto de itens que realizem a cirurgia no
paciente. Neste caso os robôs são imprescindíveis, assim como uma
rede que permita o envio e a recepção dos comandos de maneira
rápida e segura [Current 2007].
324

Estas tecnologias abrem novas possibilidades de tratamento para

pessoas que se encontram distantes de grandes centros urbanos ou
em situações de guerras.
Algumas dessas cirurgias podem utilizar os recursos da RA, que
superimpõe imagens geradas a partir de exames de RMN ou TC em
imagens reais.
8.8.3. Suporte a deficiências
Um outro tipo de aplicação médica da RA ajuda pessoas que
possuem degenerações na retina (que geram manchas negras sobre
as cenas) e requerem a integração de câmeras aos HMDs,
permitindo que o usuário visualize imagens reais alteradas para
suprir essa deficiência visual.
A Figura 8.4 apresenta um exemplo de aplicação onde as imagens
reais (a) estão sofrendo um deslocamento em direção às bordas de
uma área cega(b), permitindo que o usuário “enxergue” as imagens
que estariam localizadas dentro dessa área (mancha negra) [Farago
2005].
(a) (b)
Figura 8.4 - Imagem original (a) e imagem transformada (b).
8.8.4. Reabilitação
A RV também tem sido explorada para apoiar o tratamento de
diferentes seqüelas motoras e cognitivas, derivadas de distúrbios ou
325

danos cerebrais. Em geral, os ambientes virtuais possibilitam uma

variedade de associações não possíveis com outras interfaces
homem-máquina, devido às qualidades multisensoriais e espaciais
destes ambientes, contribuindo para o enriquecimento das
aplicações na área de reabilitação.
Se uma pessoa sofre algum dano cerebral, uma ou várias funções
motoras ou cognitivas podem se tornar deficientes. Para recuperá-
las é preciso empreender estratégias terapêuticas específicas para
cada tipo de deficiência detectada.
As pessoas que sofreram um Acidente Vascular Cerebral (AVC),
em geral, sofrem de seqüelas motoras que são facilmente
observadas, mas também, funções cognitivas podem ser
danificadas. Neste sentido, Holden et al. (2006) propõem um
sistema voltado para a telereabilitação. O ambiente permite ao
terapeuta conduzir sessões interativas para o tratamento de pessoas
com problemas motores nas mãos e que estão em suas casas. Um
grupo de pesquisadores da UFRJ e UERJ vêm desenvolvendo
experimentos com ambientes virtuais 3D para estimular a
realização de atividades de vida diária de pessoas com seqüelas de
atenção e percepção causadas por AVC. Os pacientes têm aceitado
com muito entusiasmo o trabalho nos ambientes virtuais e os
resultados obtidos têm apresentado uma significativa recuperação
dos níveis de atenção e concentração nas atividades cotidianas
[Cardoso 2006].
Costa e Carvalho (2004) apresentam os resultados da aplicação de
um programa de reabilitação cognitiva para pacientes com
esquizofrenia e insuficiência mental. As atividades propostas
contemplam tarefas que estimulam a atenção e a memória. No
experimento, verificou-se que os pacientes tiveram uma boa
aceitação do trabalho com o computador e demonstraram um bom
nível de motivação para usar a máquina.
326

8.9. Reconstrução de modelos a partir de imagens reais
Reconstruir um objeto significa recuperar suas informações

geométricas e topológicas e seus atributos a partir do conjunto de
amostras que o representa. Esta reconstrução é feita por meio de
algum tipo de interpolação sobre as amostras.
Existem vários métodos de reconstrução e visualização de objetos
tridimensionais. Os principais deles podem ser classificados em
duas categorias: baseados em volume e baseados em superfície. Em
aplicações de RV e RA para a área médica, a fonte de dados são as
imagens provenientes de modalidades, como as citadas na seção
8.3.
Os métodos baseados em volume percorrem o conjunto de dados,

gerando uma imagem a partir de alguns parâmetros como
densidade, opacidade, textura e campos de vetores normais. Tais
parâmetros indicam como os dados internos do volume são
combinados e processados para gerar a imagem final, através da
interação com a luz. Um exemplo pode ser visualizado na Figura
8.5. Uma das principais vantagens da reconstrução de volumes é a
qualidade das imagens geradas. Um dos grandes problemas desta
categoria de reconstrução é a grande quantidade de dados a
processar [Peixoto 2000].
A reconstrução da borda ou superfície que delimita um objeto

sólido, a partir de uma série de seções planares paralelas, tem
recebido bastante atenção nas últimas duas décadas [Peixoto 2000].
A Figura 8.5 mostra um exemplo de contornos paralelos
distribuídos em três fatias e a superfície reconstruída. Através de
tecnologias como TC e RMN são obtidas informações sobre órgãos
e tecidos humanos, armazenadas em fatias. As informações das
327

fatias são utilizadas para definir o conjunto de contornos que, por

sua vez, podem ser interpolados para gerar superfícies. Estas
superfícies seriam as bordas dos órgãos ou tecidos humanos que,
desta forma, podem ser exibidos e utilizados em aplicações
gráficas. Na reconstrução por superfície dá-se importância somente
às fronteiras que delimitam o objeto volumétrico. A partir de
atributos como a função de densidade, é feita uma busca nas fatias
do volume, a fim de definir o conjunto de contornos que
delimitarão a superfície (exemplo na Figura 8.6). As técnicas desta
categoria são utilizadas principalmente para reconstruir superfícies
de objetos morfologicamente bem definidos. Uma das grandes
vantagens dos métodos de reconstrução de superfícies em relação
aos métodos de reconstrução volumétrica é a menor quantidade de
informações armazenadas. Uma vez construída a superfície,
pode-se aplicar técnicas de renderização conhecidas para visualizar
o objeto.
Figura 8.5 – Reconstrução Volumétrica a partir de imagens de

cérebro geradas por RMN (Neuroimage, 2006).
328

Figura 8.6 – Reconstrução de uma superfície a partir de

contornos (Peixoto, 2000)
8.10. Detecção de colisão
Como introduzido na seção 8.4, a detecção de colisão com precisão
é um fator relevante para proporcionar realismo em aplicações para
a área médica. A seguir são citadas algumas soluções para alcançar
este requisito.
O uso de hierarquias, juntamente com o conceito de volumes
limites, é freqüentemente empregado para uma rápida detecção de
colisão. Um volume limite representa a extensão espacial máxima
de um objeto, podendo ser representada por um cubo ou esfera
[Sense8 2006]. Esta abordagem consiste em criar aproximações
geométricas para objetos complexos, permitindo eliminar áreas dos
objetos que não estão em contato.
Figura 8.7 – Reconstrução por superfície a partir de imagens

mamográficas: (a) e (b) imagens originais; (c) objeto com
textura e (d) objeto wireframe (Delfino, 2006)
O’Sullivan et al. (2001) apresentam as técnicas mais comuns: (a)
Octrees: hierarquias criadas recursivamente subdividindo o volume
que contém um objeto em oito octantes (cubos ou esferas) e
retendo somente aqueles octantes que contêm alguma parte do
329

objeto original; (b) Sphere-trees: parecida com Octrees, esta

técnica envolve os objetos por esferas, tendo como vantagem a
rotação invariável; (c) OBB-trees: consistem no uso de volumes
limites orientados com o objeto (Oriented Bounding Boxes) tendo
como vantagem a proximidade com a forma do objeto e (d)
AABB-trees: volumes limites alinhados aos eixos (Axis Aligned
Bounding Boxes), consistindo em hierarquias mais simples de criar
e realizar testes de sobreposição.
Especificamente na área médica, vários projetos encontrados na

literatura buscam uma detecção de colisão precisa e com o menor
custo computacional possível a partir de refinamentos ou
combinação de métodos e algoritmos já existentes.
Em Garcia-Alonso et al. (1994) foram utilizados três métodos para
determinar uma colisão entre dois objetos: Minimax,Voxels e
Faces. Ponamgi et al. (1995) combinaram um algoritmo baseado no
uso de volumes limites com aproximações incrementais de suas
características (lados, bordas e vértices) para detecção de colisão
entre sólidos em ambientes dinâmicos.
Burdea et al. (1999) utilizaram o cálculo de distância entre vértices
para a detecção de colisão entre a superfície de uma próstata virtual
e um dedo virtual. Em [Machado 2003], a opção adotada foi o
refinamento das rotinas de detecção de colisão contidas na
biblioteca háptica GHOST.
Riquelme (2005) realizou um estudo comparativo dos métodos
oferecidos pelas bibliotecas Java3D e WorldToolkit [Sense8 2006]
para detecção de colisão. Observou-se que os métodos fornecidos
por essas tecnologias não eram suficientes para uma detecção de
colisão com precisão e rapidez e, por isso, propôs uma nova técnica
que utiliza a equação do plano para refinar os métodos fornecidos.
330

8.11. Deformação
Como mencionado na seção 8.5, há métodos clássicos na literatura
para simular deformação em tecidos flexíveis. O grande desafio
continua sendo a relação precisão versus tempo de resposta.
Em aplicações médicas, o conceito de Elementos Finitos foi
utilizado em Shi e Yan (2001), que desenvolveram técnicas para
deformação de objetos e cortes em aplicações de cirurgia virtual,
Costa e Balaniuk (2002), que se concentraram em métodos para
deformar objetos em tempo real e Dimaio e Salcudean (2002), que
apresentaram uma simulação de inserção de agulha virtual em
tecidos flexíveis. Exemplos de utilização do método Massa-Mola
são Delingette et al. (1999), que apresentam aplicações de
simulações de cirurgias crânio-faciais e Oliveira et al. (2006), que
implementaram um sistema em Java para simular a deformação em
exames de biópsia de mama.
8.12. Estereoscopia
Em aplicações médicas, muitas vezes a implementação de
estereoscopia esbarra no custo de equipamentos sofisticados que
podem fornecer sensação de imersão mais adequada. A seguir são
apresentadas algumas soluções para proporcionar esta sensação.
Meneses et al. (2002) desenvolveram um estudo para comparar as
técnicas anaglífica e de polarização quanto à nitidez e realismo de
um segmento neuroanatômico, concluindo que a melhor técnica em
percentagem de eficácia foi a de polarização, apresentando melhor
efeito de profundidade e maior nitidez. Óculos estereoscópicos
obturadores foram usados para simular o treinamento de cirurgias
ortopédicas [Sourin 2000] e coleta de medula óssea [Machado
2003].
Montanha e Nunes (2005) optaram por uma abordagem de baixo
331

custo, desenvolvendo o método de anaglifos em Java, aplicado em

um Atlas Virtual. Apesar de constituir uma solução barata, os
autores observaram que métodos mais adequados devem ser
aplicados em sistemas da área médica, pois os anaglifos causam
distorção nas cores das imagens, prejudicando a sensação de
realismo tão desejada neste tipo de sistema.
8.8. Construção de frameworks

Um framework é definido como um conjunto de classes abstratas e
concretas usadas para o desenvolvimento de uma aplicação com
domínio específico. Framework orientado a objetos representa uma
categoria de artefatos de software potencialmente capazes de
promover reúso de alta granularidade [Johnson 1988]. Têm sido
pesquisados devido a sua capacidade de alterabilidade,
extensibilidade e, em longo prazo, rapidez no desenvolvimento de
novas aplicações, diminuição de erros e aumento de qualidade do
produto final.
Alguns frameworks na área de RV e RA aparecem na literatura,
mas poucos deles são direcionados especificamente à construção de
aplicações na área médica. Bastos et al. (2005) afirmam que esses
frameworks permitem que o usuário se concentre no
desenvolvimento da aplicação, pois não é necessário se preocupar
com a gerência do sistema de RV. Tais frameworks podem oferecer
abstração de dispositivos e sistemas de projeção, grafos de cena
especializados, interação com o AV, suporte a sistemas distribuídos
e renderização distribuída. Dentre os frameworks direcionados à
construção de aplicações genéricas de RV, é interessante destacar o
Avango [Tramberend 2001], o IVORY [Sprenger 1998] e o ViRAL
[Bastos 2005].
Especificamente para a área médica, é interessante citar o VPat
(Virtual Patients), apresentado por Freitas et al. (2003) e
332

desenvolvido com o propósito de suportar aplicações de

computação gráfica na área médica e o ViMeT (Virtual Medical
Training), descrito por Oliveira et al. (2006), cujo conjunto de
classes permite criar e manipular um ambiente de RV com o
objetivo de simular exames de biópsia. O ViMeT tem como
principal motivação a possibilidade de reúso de código que pode
facilitar a construção de aplicações de RV para treinamento médico
a partir do ViMeT. Também faz parte do projeto uma ferramenta de
instanciação automática [Oliveira et al. 2006].
8.14. A ética no uso da RV na área médica

O avanço dos preceitos de bioética tem gerado impactos em vários
domínios das ciências médicas e perpassa, de maneira incisiva, o
uso das novas tecnologias nesta área. Neste sentido, a utilização e a
construção de artefatos tecnológicos devem receber especial
atenção de maneira a não colocar em risco a saúde de seus
usuários.
Várias dimensões devem ser consideradas na construção e uso
destes artefatos e englobam aspectos tecnológicos e humanos. As
questões tecnológicas estão centradas nos aspectos técnicos
relacionados, principalmente, ao desempenho do programa que
controla procedimentos médicos, à definição e implementação dos
meios de armazenamento de dados, aos meios de comunicação
utilizados, à estrutura lógica, metodologias e padrões de qualidade
do processo de desenvolvimento. As questões humanas tratam dos
impactos dos programas nos seus usuários, verificam se o programa
está resolvendo o problema almejado pelos usuários e se o está
resolvendo de maneira correta, ou ainda, se está expondo o usuário
a algum tipo de risco ou desconforto, dentre outros. O uso de
ambientes virtuais 3D na área de saúde pressupõe o respeito aos
pacientes, considerando estes fatores éticos.
333

No caso da tecnologia de RV, vários trabalhos focam nas questões

envolvidas na imersão [Lewis 1997]. Existem variados fatores que
podem influenciar a geração de problemas, sendo que alguns são
associados a aspectos técnicos do equipamento e construção do
ambiente, enquanto outros, são inerentes ao próprio usuário.
Pessoas de idade mais avançada podem ter problemas ao usar um
capacete de projeção estereoscópica. A limitação do campo de
visão gerada por estes equipamentos também pode contribuir para a
ocorrência de sensações desagradáveis nos usuários. Logo,
precauções especiais devem ser tomadas para assegurar a segurança
e o bem-estar de pacientes em ambiente virtuais 3D. Neste sentido,
antes de expor os pacientes a estes ambientes virtuais, é
fundamental que sejam verificadas suas características individuais,
assegurando que eles não estejam sofrendo de infecções ou gripes;
alcoolizados; sob o efeito de medicamentos que afetem as funções
visuais ou perceptivas; sob o efeito de drogas; com histórico de
desordens de equilíbrio ou com deficiências visuais.
8.15. Comentários Finais

Este capítulo apresentou uma visão da RV e da RA aplicadas à área
da saúde, destacando os requisitos fundamentais para a construção
e utilização de ambientes virtuais cada vez mais realísticos,
exemplos de sistemas voltados para o apoio da educação médica,
das telecirurgias e de tratamentos específicos, dentre outros.
A partir do que foi exposto, percebe-se o potencial da RV e RA
para impulsionar o crescimento do número e da qualidade dos
procedimentos médicos apoiados nestas novas tecnologias. Cabe
destacar a necessidade de um trabalho cada vez mais
interdisciplinar, integrando os diferentes especialistas envolvidos
na concepção e uso destes produtos.
Desafios como custo da tecnologia de hardware e software,
334

capacidade de processamento das máquinas, manipulação de

grande volume de dados e familiarização dos usuários com as
novas tecnologias ainda devem ser vencidos. Logo, uma vasta área
de pesquisa se descortina, trazendo desafios tanto tecnológicos,
quanto médicos e educacionais.
Referências Bibliográficas
ARAS -Augmented Reality Aided Surgery, em:
http://www.vrvis.at/vr/aras/, visitado em janeiro de 2007.

Balaniuk, R.; Costa, I.; Melo, J.; (2006), “Cosmetic Breast Surgery
Simulation”, VIII Symposium on Virtual Reality, pp. 387-396.

Baños, R. M., Botella, C., Garcia-Palacios, A., Villa, H., Perpiña,
C., Alcañiz, M. (2000), “Presence and Reality Judgment in

Virtual Environments: A Unitary Construct?”, CyberPsychology
& Behaviour vol. 3, n. 3, pp. 327-335.
BARCO, Em: http://www.barco.com/VirtualReality/en/products/

product.asp?element=313, visitado em janeiro de 2007.
Bastos, T. A., Raposo, A. B., Gattas M. (2005), “Um Framework

para o Desenvolvimento de Aplicações de Realidade Virtual
Baseados em Componentes Gráficos”, Anais do XXV Congresso
da Sociedade Brasileira de Computação, pp. 213-223.
Burdea, G., Patounakis, G., Popescu, V., Weiss, R. E. (1999)

“Virtual Reality-Based Training for Diagnosis of Prostate
Cancer”, IEEE Transactions on Biomedical Engineering, v. 46,
n. 10, pp. 1253-1260.
335

Cardoso, L.; Costa, R. M.; Piovesana, A.; Costa, M.; Penna, L.,
(2006), “Using Virtual Environments for Stroke Rehabilitation”.
IEEE-5th International Workshop on Virtual Rehabilitation,
New York, pp. 1-5.
Choi, K.S et al. (2002), “Scalable Force Propagation Approach for

Web – Based Deformable Simulation of Soft Tissues”,
Web3D’02, Arizona, ACM Proceedings, pp.185-193.
Costa, I. F., Balaniuk, R. (2001), “LEM -An Approach for Real

Time Physically based Soft Tissue Simulation”, International
Conference in Automation and robotics, Seul–Korea do Sul.
Costa, R. M.; Carvalho, L., (2006), “The Acceptance of Virtual

Reality Devices for Cognitive Rehabilitation: a report of
positive results with schizophrenia”, Computer Methods and
Programs in Biomedicine, v. 73, n. 3, pp. 173-182.
Current Status of Telesurgery, em:

http://www2.telemedtoday.com/articles/telesurgery.shtml,
visitado em janeiro de 2007.
Delingette, H., Cotim, S., Ayache, N. (1999). “A Hibrid elastic

model allowingreal-time cutting, deformations and
force-feedback for surgery training and simulation”, In:
Computer Animation 1999. Anais IEEE Computer Society,
p.70-81.
Diffusion Tensor MRI Brain Visualization, em:

http://www.nature.com/neuro/journal/v5/n11s/full/nn948.html,
visitado em janeiro de 2007.
Dimaio, S.P., Salcudean, S.E. (2002), “Needle Insertion Modelling

336

and Simulation”, Proceedings of The IEEE International

Conference on Robotics and Automation, pp.2098-2105.
DirectX, Site Oficial (2006), http://www.microsoft.com/

windows/directx/default.mspx, visitado em novembro de 2006.
Farago, P.; Barros, L.; Landau, L.; Cunha, G.; Costa, R. M. (2005),
“ATDV: An Image Transforming System”. Lecture Notes in
Computer Science, v. 3414, pp. 727-734.
Freitas, C. M. D. S., Manssour, I. H., Nedel, L. P., Gavião, J.

K.,Paim, T. C., Maciel, Ânderson (2003) “Framework para
Construção de Pacientes Virtuais: Uma aplicação em
Laparoscopia Virtual”, Symposium On Virtual Reality-2003,
Ribeirão Preto. v. 6, pp. 283-294.
Garcia-Alonso, A., Serrano, N., Flaquer, J. (1994), “Solving the

Collision Detection Problem”, IEEE Computer Graphics and
Applications, v.14, n.3, pp. 36-43.
Gibson, S.F.F., Mirtch, B. (1997), “A Survey of Deformable

Modeling in Computer Graphics”, Mitsubishi Electric
Information Technology Center America, pp.1-22.
Gladilin, E. (2003) “A Biomechanical Modeling of Soft Tissue and

Facial Expressions for Craniofacial Surgery Planning”, Tese de
Doutorado, FUBerlin.
Haluck R., Webster R., Wang W., LeFever A., Mohler B., (2007)
“Tracking Laparoscopic Surgical Motions Using the 5DT
DataGlove”, em:
http://cs.millersville.edu/~webster/haptics/handproject/handproj
ect.html, visitado em janeiro de 2007.
337

Handolin, L., Partio, E. K. , Arnala, I., Pajarinen, J., Pätiälä, H.,

Rokkanen, P. (2007), “The effect of low-intensity pulsed
ultrasound on bone healing in SR-PLLA rod fixed experimental
distal femur osteotomy in rat”, J Mater Sci Mater Med,
February.
Hennel, J. W., Klinowski J. (1993), Fundamentals of Nuclear

Magnetic Resonance, Longman Scientific & Technical, Essex -
England.
Hirota, G., Maheshwari R., Lin M.C. (1999), “Fast

Volume-Preserving Free Form Deformation Using Multi-Level
Optimization”, SIGGRAPH: ACM Special Interest Group on
Computer Graphics and Interactive Techniques, Michigan,
pp.234 – 245.
Johanson, M. (2005), “Stereoscopic Video Transmission over the

Internet”, Proceedings of WIAPP'01, San Jose, Julho.
Johnson, R. E., Foote, B. (1988), “Designing reusable classes”,

Journal of Object Oriented Programming, v.1, n.2, pp.22-35.
Lau, R.W.H., Chan, O., Luk, M., Li, F. W. B. (2002), “A collision

detection framework for deformable objects”, ACM VRST’02,
pp.113-120.
Lewis, C.; Griffin, M., (1997), “Human Factors Consideration in

Clinical Applications of Virtual Reality”, Virtual Reality in
Neuro-Psycho-Physiology; Ed. Giuseppe Riva, IOS Press.
Lipton, L. (2005), “Foundations of the Stereoscopic Cinema”, Van

Nostrand Reinhold Co. pp.77-79.
Machado, L. S. (2003), “A Realidade Virtual no modelamento e

338

Simulação de Procedimentos Invasivos em Oncologia

Pediátrica: Um estudo de caso no Transplante de Medula
Óssea”, Tese de Doutorado, Escola Politécnica de São Paulo,
São Paulo.
Meneses, M.S. et al. (2002), “Estereoscopia aplicada à

Neuroanatomia: estudo comparativo entre técnicas de filtro de
cores e de polarização”, Directory of Open Access Journals,
vol.60, pp.769-774.
Moline, J., (1997), “Virtual Reality for Health Care: a Survey”;

Virtual Reality in Neuro-Psycho-Physiology; Ed. Giuseppe
Riva, IOS Press, Holanda.
Montanha, F., Nunes, F. L. S. (2005), “Construção de Atlas de

Anatomia e Fisiopatologia do Câncer de Mama utilizando
Realidade Virtual”, XVIII Sibgrapi - IV WTDCGPI.
Monteiro, B.; Valdek, M.; Cunha, I.; Moraes, R.; Machado, L.;
(2006), “AnotomI 3D: Um Atlas digital baseado em realidade
Virtual para o ensino de medicina”, VIII Symposium on Virtual
Reality, pp 3-14.
Neuroimage, (2006), “Ressonância magnética de crânio

convencional”, Em: www.neuroimaging.com, Visitado em
dezembro de 2006.
North, M.M., North, S. M., Coble, J. R. (1998), “Virtual Reality

Therapy: an effective treatment for phobias”. Virtual
Environments in Clinical Psychology and Neuroscience, Ios
Press, Amsterdam.
O´Sullivan, C., Dingliana, J., Ganovelli, F., Bradshaw, G. (2001),

339

“Collision Handling for Virtual Environments”, Eurographics

Tutorial.
Oliveira, A. C. M. T. G., Pavarini, L., Nunes, F. L. S., Botega, L.

C., Justo, D. R., Bezerra, A. (2006), “Virtual Reality Framework
for Medical Training: Implementation of a deformation class
using Java”, ACM SIGGRAPH International Conference on
Virtual-Reality Continuum and its Applications in Industry.
Hong Kong –China.
Peixoto, A., Gattass, M. (2000) “Reconstrução de Superfícies a

partir de Seções Bidimensionais”, Dissertação de Mestrado,
Pontifícia Universidade Católica do Rio de Janeiro, Rio de
Janeiro.
Ponamgi, M., Manocha, D., Lin, M.C. (1995) “Incremental

Algorithms for Collision Detection Between Solid Models”.
ACM Siggraph, Utah.
Ramalho Jr., F., Ferraro, N. G., Soares, P. A. T. (1993), Os

fundamentos da Física, Editora Moderna.
Ramos, F.; Nunes, F.; Botega, L.; Damasceno, E.; Pavarini, L.;
(2005), “Atlas Virtual da Mama e Fisiopatologia do Câncer de
Mama utilizando Java3D”. Workshop de Aplicações de
Realidade Virtual, Uberlândia.
Reitinger B., Bornik A., Beichel R., Schmalstieg D., (2006), “Liver
Surgery Planning Using Virtual Reality”, IEEE Computer
Graphics and Applications, Vol 26, n. 6, pp 36-47.
Riquelme, F. (2005), “Estudo comparativo de soluções para

detecção de colisão em tecnologias de Realidade Virtual para o
desenvolvimento de ferramentas para treinamento médico”
340

Dissertação de Mestrado, Centro Universitário Eurípides de

Marília, Marília.
Santos, E.T. (2000), “Uma Proposta para uso de Sistemas

Estereoscópicos Modernos no Ensino de Geometria Descritiva e
Desenho Técnico”, Graphica 2000, Ouro Preto, pp. 1-8.
Sayeg, N. (2007), “Avaliação Morfofuncional”, em:

www.alzheimermed.com.br/m3.asp?cod_pagina=1058, visitado
em janeiro de 2007.
Schwartz, J. (2004), “Special topics in CS: intro to Bioinformatics”

2004. http://www.settheory.com/bioinformatics_syllabus/
bioinformatics_syllabus.html>,Julho.
Sense8 (2006), “WorldToolKit”, em:

http://www.inition.co.uk/inition/product.php?URL_=product_soft
ware_sense8_worldtoolkit&SubCatID_=54>, visitado em
dezembro de 2006.
Shi, J.Y, Yan, L.X. (2001), “Deformation and Cutting in Virtual

Surgery”, Proceedings of the Intern. Workshop on Medical
Imaging and Augmented Reality, IEEE Computer Society.
Sourin, A. et al. (2000), “Virtual Orthopedic Surgery Training”,

IEEE Computer Graphics and Applications, vol.20, n.3, pp.6-9.
Sprenger, T. C., Gross, M., Bielser, D., Strasser, T., (1998),

“IVORY -An Object-Oriented Framework for Physics-Based
Information Visualization in Java”, Proceedings of the IEEE
Symposium on Information Visualization, IEEE CS Press, pp.
79-86.
The Visible Human Project, em: http://www.nlm.nih.gov/research/

341

visible/visible_human.html, visitado em janeiro de 2007.
Tramberend, H. (2001), “Avango: A Distributed Virtual Reality
Framework“. Proceedings of Afrigraph '01, ACM.
Wagner, J. M., Noo, F., Clackdoyle, R., Bal, G, Christian, P.

(2002), “Attenuation Correction for Rotating Slant-Hole (RSH)
SPECT using Exact Rebinning”, IEEE Transactions on Nuclear
Science.
Zill, D.G. (2003), Equações Diferenciais com aplicações em

Modelagem, Thomson.
342

Capítulo
9
Aplicações na Educação e
Treinamento
Alexandre Cardoso e Edgard Lamounier Jr.

alexandre@ufu.br, lamounier@ufu.br
Resumo
A Educação pode ser vista como um processo de descoberta,
exploração e de observação. Tais elementos são de fundamental
importância para a construção do conhecimento. Neste contexto, a
possibilidade de simular situações e experimentos que de maneira
real não seriam possíveis ou inviáveis, propicia grande avanço no
processo educacional. Este capítulo visa apresentar e discutir
Realidade Virtual como uma significativa ferramenta de suporte ao
ensino-aprendizagem. É avaliado como a mesma possibilita a
realização de experiências com o conhecimento, de forma mais
intuitiva e interativa, suportando a exploração de ambientes,
processos ou objetos, de uma forma totalmente inovadora, quando
comparada com métodos tradicionais (quadro-negro, livros, filmes
etc.).
343

9.1. Introdução
A discussão da utilização da Informática na educação e treinamento
deve considerar muitos fatores, sob pena de falsas soluções serem
apontadas como efetivas. A simples utilização de uma tecnologia
não é a solução para os problemas, logo, informatizar o material
tradicional (anteriormente aplicado em educação/treinamento
presencial), sem uma adequada alteração das técnicas de ensino,
não é solução por si só [Robles et al., 1997]. O risco declarado
consiste em confundir a entrega de informação com aprendizado,
alijando elementos essenciais, tais como resolução de problemas,
criatividade e imaginação dos instrutores e dos alunos [Bork;
Britton, 1998]. Neste contexto, tecnologias como a Realidade
Virtual (RV) vêm apresentando diferenciais importantes.
A Realidade Virtual (RV) é uma tecnologia que consiste
em uma combinação de programas computacionais, computadores
de alto desempenho e periféricos especializados, que permitem
criar um ambiente gráfico de aparência realística, no qual o usuário
pode se locomover em três dimensões, onde objetos gráficos
podem ser sentidos e manipulados.
Assim, a Realidade Virtual permite a criação de uma
interface homem-máquina mais natural e poderosa, possibilitando
ao usuário interação, navegação e imersão num ambiente
tridimensional sintético, gerado pelo computador através de canais
multisensoriais de visão, audição, tato, olfato ou paladar.
Ressalta-se que um grande benefício oferecido por esta
interface é que o conhecimento intuitivo do usuário a respeito do
mundo físico pode ser utilizado para manipular
o ambiente virtual, possibilitando ao usuário a manipulação de
informações através de experiências próximas do real. Isso porque,
no ambiente virtual, é possível criar a ilusão de mundo que na
344

realidade não existe, através da representação tridimensional para o

usuário.
Dessa forma, a RV tem potencial para propiciar uma
educação como processo de exploração, descoberta, observação e
construção de uma nova visão do conhecimento, oferecendo ao
aprendiz a oportunidade de melhor compreensão do objeto de
estudo. Essa tecnologia, portanto, tem potencial de colaborar no
processo cognitivo do aprendiz, proporcionando não apenas a
teoria, mas também a experimentação prática do conteúdo em
questão.
9.2. Justificativas para o Uso de RV na Educação e
Treinamento
A utilização de RV com fins educativos tem merecido destaque e
tem sido avaliada de forma intensiva nos últimos anos [Pantelidis,
1996]. Os resultados destas avaliações mostram ganhos, em termos
de aprendizagem superiores a diversas outras formas de interação
visando educação mediada por computador. Alguns relatos são
destacados a seguir.
Byrne (1996) demonstrou que, estudantes do Ensino Médio
utilizando aplicativos baseados em Realidade Virtual para análise
de experiências de Química (relacionadas com visualização e
manuseio de moléculas) apresentaram uma retenção de
informações (após três meses) muito superior a estudantes que
obtiveram tais informações através de outros meios, tais como
sistemas audiovisuais, demonstrando que um dos principais fatores
envolvidos com a aprendizagem é a interatividade proporcionada
pelo ambiente. Este aspecto é apontado por Costa (2000),
confirmando que a interação é a característica chave que distingue
uma experiência em RV de uma experiência de, por exemplo,
assistir a um filme.
345

Pausch et al. (1997) destaca que usuários de RV são muito

melhores nas buscas sistemáticas da informação porque têm
lembranças melhores daquilo que olharam na cena que os envolve.
Pinho (2000) apresenta o consenso de que a mesma pode
influenciar positivamente o processo de aprendizado, sendo que
uma das principais justificativas, à esta influência, está na forma de
aprendizado, que pode ser baseada em experiências de 1ª pessoa.
Experiências de 1ª pessoa são aquelas na qual o indivíduo
conhece o mundo através de sua interação com ele, sendo
caracterizado como um conhecimento direto, subjetivo e
freqüentemente inconsciente (o aprendiz não tem a clara definição
que está aprendendo). Tais experiências são naturais e, geralmente,
privadas.
Por outro lado, experiências de 3ª pessoa são aquelas na
qual o aprendiz ouve o relato de uma experiência ou aprende a
partir da descrição feita por outra pessoa. Esta forma de
aprendizado é objetiva, consciente e implícita. Como RV permite a
imersão e a exploração individual, o aprendiz vive experiências de
1ª pessoa e explora a informação como uma experiência diária.
Conclusivamente, Bell; Foglerl (1995), Pinho (2000) e
Meiguins (1999) apontam como principais vantagens da utilização
de técnicas de RV para fins educacionais, os seguintes itens:
(a) motivação de estudantes e usuários de forma geral,
baseada na experiência de 1ª pessoa vivenciada pelos mesmos;
(b) grande poderio de ilustrar características e processos,
em relação a outros meios multimídia;
(c) permite visualizações de detalhes de objetos;
(d) permite visualizações de objetos que estão a grandes
distâncias, como um planeta ou um satélite;
(e) permite experimentos virtuais, na falta de recursos, ou
346

para fins de educação virtual interativa;

(f) permite ao aprendiz refazer experimentos de forma
atemporal, fora do âmbito de uma aula clássica;
(g) porque requer interação, exige que cada participante se
torne ativo dentro de um processo de visualização;
(h) encoraja a criatividade, catalisando a experimentação;
(i) provê igual oportunidade de comunicação para
estudantes de culturas diferentes, a partir de representações;
(j) ensina habilidades computacionais e de domínio de
periféricos.
Experiências de utilização de sistemas que utilizam técnicas
de Realidade Virtual têm sido desenvolvidas e aplicadas nos mais
diversos campos de ensino, desde Medicina, indústria e aplicativos
para matemática básica, experimentos virtuais de Óptica
Geométrica e até simulações de circuitos integrados. A próxima
seção relata algumas destas experiências.
9.3. Aplicações de Realidade Virtual
9.3.1. Medicina
A Medicina e áreas de saúde relacionadas têm, substancialmente,
se beneficiado dos avanços tecnológicos apresentados pela
Realidade Virtual, nos últimos anos. Pesquisadores acreditam que
RV providencia um recurso ímpar para o ensino e treinamento em
estruturas anatômicas. Um dos principais problemas para a
educação em Medicina, em geral, é como providenciar um senso
realístico da inter-relação entre estruturas anatômicas no espaço
3D. Com RV, o aprendiz pode repetidamente explorar as estruturas
de interesse, separando-as ou agrupando-as com as mais diferentes
formas de vizualização, imersão e exploração. Isto seria,
obviamente, impossível com um paciente vivo e é economicamente
347

inviável manter com cadáveres em escolas de Medicina.

Projetos estão sendo desenvolvidos para suportar a cirurgia
à distância. Os profissionais da Medicina podem, através de um
ambiente virtual, controlar os braços de um robô para desenvolver
uma cirurgia em um soldado, em um campo de batalha, como
ilustrado na Figura 9.1, onde o robô da imagem à esquerda,
controlado por um cirurgião à distância usando técnicas de RV,
pode gerenciar a cirurgia da imagem à direita.
Figura 9.1 – Controle de cirurgia/robô com técnicas de RV.
Realidade Virtual também tem sido utilizada para suportar

localmente o treinamento de vários tipos de cirurgia como cirurgias
endoscópicas, artoscopias (Figura 9.2) e cirurgias de medula. É
importante destacar, que estes aparelhos baseados em RV não só
reduzem o custo de treinamento de cirurgões, mas também
reduzem os riscos cirúrgicos dos pacientes.
348

Figura 9.2. Treinamento virtual de uma artroscopia.
Tratamento de fobias, têm também se beneficiado com o

uso de técnicas de RV. Existem sistemas, atualmente, que simulam
situações de pânico e risco, tais como viagens aéreas, elevadores e
medo de animais. Por exemplo, o sistema, SPIDERWORLD
(Figura 9.3) é um sistema baseado em Realidade Virtual projetado
para auxiliar pacientes em sua luta contra fobia de aranhas. A
paciente usa um HMD que projeta uma aranha virtual. Através de
uma aranha de brinquedo, o sistema rastreia a mão da paciente,
permitindo que a mesma toque a criatura virtual.
349

Figura 9.3. Sistema RV para fobia de aracnídeos.
Uma outra área de merecido destaque em Medicina,

recentemente, é a Realidade Aumentada. Com a facilidade de
integrar imagens reais com aquelas geradas e controladas por
técnicas de Realidade Virtual, este área de aplicação tem atraído
vários pesquisadores e profissionais de Medicina, devido a
proximidade que a mesma proporciona de casos reais. Como
exemplo, pode-se citar o sistema de neuro-cirurgias (JHU/KRDL
Skull-base Surgery Simulator – Figura 9.4), onde os cirurgiões
podem planejar, treinar e simular toda a cirurgia, antes de
efetivamente executá-la sobre o paciente.
350

Figura 9.4 – Neurocirurgias Baseadas em Realidade

Aumentada
9.3.2. Indústria
Analogamente à Medicina, várias são as áreas de aplicações de
Realidade Virtual nos vários ramos da indústria. Dentro estas
diversas áreas podem-se destacar a área de petróleo e gás. As
pessoas que trabalham na indústria petrolífera, como os geólogos,
geofísicos e engenheiros de reservatórios, gostam de trabalhar com
modelos em 3D dos reservatórios em estudo. Esses modelos,
normalmente grandes e complexos, são construídos utilizando
informações de muitas fontes diferentes: dados sísmicos, que
revelam as características estruturais, como falhas ou horizontes em
uma escala de dezenas de milhares de metros e registros do poço,
que produzem informações locais em torno do poço sobre a
porosidade, permeabilidade e outras propriedades da rocha.
Por meio da utilização de poderosas estações de trabalho
gráficas em conjunto com técnicas de RV, um geólogo pode
manipular, interrogar e investigar mais facilmente o modelo de um
grande reservatório contendo todos esses tipos diferentes de dados.
351

A RV também acelera o ritmo de descobertas, melhora a

comunicação, reduz o risco de erros e torna o processo de tomada
de decisões mais eficiente.
Figura 9.5. Realidade Virtual na exploração e busca de petróleo.
É na sede da Petrobrás, empresa brasileira que possui 13

centros de realidade virtual espalhados por suas unidades, que está
o mais moderno na área de exploração e produção de petróleo. É
por meio dessa tecnologia que os geólogos e geofísicos analisam as
propriedades do fundo do oceano, reconhecendo com precisão os
pontos onde se deverá perfurar para chegar ao petróleo.
Identificados os reservatórios, a realidade virtual também ajuda a
aproveitar ao máximo a extração de cada um deles, o que ajuda a
economizar tempo e dinheiro. "Um levantamento realizado em um
campo de trabalho da Petrobras, antes da utilização dessa
tecnologia, indicou que eram necessários perfurar 65 poços, ao
custo de 15 milhões de dólares cada, para a extração do petróleo.
352

Com o uso da realidade virtual, esse número diminuiu para 51",

compara Paulo Ricardo da Silva dos Santos, gerente setorial de
Exploração e Produção da Petrobras (extraído da revista
Galileu-Editora Globo, Edição 158, Setembro de 2004).
A Embraer, empresa brasileira na área de contrução e
manutenção de aviões, que, a exemplo de suas concorrentes, se
beneficia das facilidades do mundo virtual para o desenvolvimento
de seus aviões e treinamento de pilotos, desde 2001. É em uma
sala, equipada com uma enorme tela e sistemas de visualização,
que profissionais de diversas áreas da engenheira trabalham no
desenvolvimento/treinamento virtual de algumas aeronaves.
Figura 9.6. Uso de Realidade Virtual na construção e simulação de

aeronaves.
9.3.3. Ciências e Matemática

As vantagens para o ensino e treinamento proporcionadas pela
Realidade Virtual e apresentadas nas seções anteriores, também são
profundamente exploradas, como era de se esperar, para auxiliar
estudantes nos estudos e avaliações das mais diversas área da
Ciência e Matemática. Inúmeros são os sistemas de Realidade
353

Virtual desenvolvidos nos últimos anos que auxiliam os alunos a

explorar novos conhecimentos, através da Realidade Virtual. Esta
seção apresenta apenas alguns destaques.
O projeto ScienceSpace (www.virtual.gmu.ed/vrhome.htm)
apresenta uma coleção de ambientes virtuais que visa auxiliar
estudantes e professores na compreensão de conceitos científicos,
principalmente relativos à Química e Física. Atualmente, o sistema
é composto de três ambientes: Newton World (cinemática e
dinâmica), Maxwell World (eletrostática e leis de Gauss) e Pauling
World (estudo de estruturas moleculares), como mostram as
imagens na Figura 9.7, respectivamente.
Figura 9.7 – Ambientes Virtuais do Sistema ScienceSpace.
A disciplina de Matemática tem, igualmente, usufruído dos

inúmeros benefícios advindos da Realidade Virtual,
particularmente a área de Geometria. Isto porque um dos problemas
tradicionalmente apresentado na literatura é o fato de os livros
serem em 2-D, o que dificulta ao aluno a sensação tridimensional
de imersão e profundidade. Tais itens são largamente explorados
por sistemas atuais que utilizam técnicas de RV no ensino de
Geometria.
O sistema Construct3D (www.ims.tuwien.ac.at), por
exemplo, é uma ferramenta de construção de geometria
tridimensional, projetado especificamente para o ensino de
Matemática e Geometria. Baseado em técnicas de Realidade
Aumentada [Azuma 1997], o sistema foi projetado para
354

proporcionar um ambiente natural de colaboração entre professores

e estudantes, como mostrado na Figura 9.8. A principal vantagem
de usar RA, neste caso, é que e os estudantes podem de fato
visualizar e interagir com objetos tridimensionais os quais eles
tinham que calcular e construir utilizando, na maioria das vezes,
procedimentos rudimentares (baseados em papel e caneta). Assim,
por trabalhar diretamente com o espaço 3D, problemas e relações
espaciais complexas podem ser compreendidas de forma mais
rápida e com mais qualidade do que métodos tradicionais.
Figura 9.8 – Experimentos de Realidade Aumentada e

Geometria.
9.4. Considerações Finais

Baseado nos experimentos e aplicações apresentados nas seções
anteriores, é de imediata a conclusão de que a Realidade Virtual
executa um importante papel no processo de educação e
treinamento de seus usuários.
Entretanto, é importante destacar que a RV também
apresenta seus próprios problemas. Primeiramente, ela é muito cara
de se produzir e usar, principalmente para a RB (Realidade
Brasileira!!!). Em segundo lugar, aparentemente, não existe um
currículo padrão para o ensino e desenvolvimento de sistemas de
355

RV sendo aplicado uniformemente em nossas universidades e

empresas. Finalmente, é muito difícil produzir simulações
altamente realísticas, de tal maneira que possa aproximar, com
grande precisão, o real do virtual. Assim, parece que para o
momento, a Realidade Virtual na educação e treinamento tem se
apresentado mais como um remédio do que a cura.
Porém, à medida que a tecnologia evolui e os educadores
aprenderem mais sobre como as pessoas aprendem através da
interação com ambientes virtuais, a RV será vista com mais
freqüência em nossas escolas e universidades. É improvável que
venhamos a assistir a construção de ambientes virtuais com a
máxima fidelidade em nosso tempo. Mas, pesquisadores estão
trabalhando para criar ambientes virtuais que suportem toque,
cheiro e sabor com mais precisão. A qualidade de dispositivos
visuais está cada vez mais aumentando em contraste com seu
tamanho e peso. Portanto, como educadores possuem uma
habilidade ímpar de trabalhar com novas tecnologias, a Realidade
Virtual na educação e no treinamento não será, no futuro, uma
exceção.
9.5. Referências
Azuma, R. (1997) “A Survey of Augmented Reality, PRESENCE:
Teleoperators and Virtual Environments, Vol. 6, No. 4, pp.
355-385”.
Bell, J.; Foglerl H. S. (1995) “The Investigation and Application of
Virtual Reality as an
Educational Tool” Proceedings of the american society for
engineering education annual
conference, Anheim, CA..
Bork, L. A. and BRITTON, R. D, (1998) “The Web is Not Yet
356

Suitable for Learning”, IEEE Transactions on Computer, USA.

pp. 115-119.
Byrne, C.(1996) “Water on Tap: The Use of Virtual Reality as an
Educational Tool”. Washington, Tese de Doutorado - University
of Washington.
Costa, E. M. R. M. (2000) “Ambientes Virtuais na Reabilitação
Cognitiva”. Rio de Janeiro, Tese de Doutorado. Engenharia de
Sistemas e Computação - COPPE/UFRJ.
Meiguins, S. B.; Behrens, H. F. (1999) “Laboratório Virtual para
Experiências de Eletrônica” Anais do II Workshop Brasileiro de
Realidade Virtual, WRV´99, Marília, pp. 56-67.
Pantelidis V. Vesamontex. (1999) “Projeto e descrição detalhada
das atividades e resultados
da implementação de uma solução de VR aplicada a Educação”.
http://users.hub.ofthe.net/~mtalkmit/veshtml2.html, November.
Pausch, R.; Proffit, D.; Williams, G. (1997) “Quantifying
Immersion in Virtual Reality”
Proceedings of the 1997 -ACM Siggraph annual conference on
Computer Graphics, pp.
13-18.
Pinho, M. (2000) “Interação em Ambientes Tridimensionais”.
rd
Tutorial do 3 Workshop on
Virtual Reality - WRV´2000, Gramado, RS, Outubro.
Robles, T. et al. (1997) “Using Multimedia Communication

Technologies in Distance Learning”, ACM Proceedings of the
Conference on Integrating Technology into Computer Science
Education, ITiCSE´97, USA, 1997, pp. 06-07
357

Livro Do Pre Simposio X Symposium On Vir

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Livro Do Pre Simposio X Symposium On Vir

Enviado por

Direitos autorais:

Formatos disponíveis

Organizadores

Somos uma comunidade jovem, multidisciplinar, criativa,

Robson Siscoutto1 e Rosa Costa2

Coordenação de Produção e Editoração:

Dados Internacionais de Catalogação na Publicação (CIP)

1. Fundamentos de Realidade Virtual e Realidade Aumentada ... 01

2. Dispositivos para Sistemas de Realidade Virtual ...................... 21

3. Técnicas de Interação para Ambientes de Realidade Virtual e

Parte 2 – Tecnologias de Desenvolvimento

4. VRML e X3D ............................................................................. 66

5. JAVA 3D .................................................................................. 162

6. ARToolKit ................................................................................ 178

7. Jogos e Entretenimento com Realidade Virtual e Realidade

9. Aplicações na Educação e Treinamento ................................. 343

Realidade Virtual e Realidade Aumentada são duas áreas

O computador eletrônico trouxe um novo processo

Apesar dos benefícios da tecnologia, a sofisticação das

Há vários pontos importantes nessa evolução, envolvendo

circuito integrado, monitor de computador, computação gráfica,

Nesse contexto, a realidade virtual [Burdea, 1994] e a

As primeiras interfaces computacionais, usadas nas décadas

A realidade virtual surge então como uma nova geração de

gráfica interativa em tempo real. Apesar das vantagens da

Por outro lado, a evolução tecnológica também propiciou,

Enquanto a realidade virtual depende de equipamentos de

[Benford, 1998; Kirner, 2004]. No entanto, a realidade aumentada

Assim, a convergência tecnológica e o desenvolvimento de

1.2. Conceitos e Definições

1.2.2. Realidade Virtual

Figura 1.1. Exemplo de aplicação de realidade virtual.

tempo-real, vendo as cenas serem alteradas como resposta aos seus

Nos ambientes virtuais, a interação mais simples é a

A interface baseada em realidade virtual permite que

quadros por segundo para suportar melhor as cenas animadas) e de

Existem muitas definições de realidade virtual, envolvendo

“Realidade virtual é uma interface avançada para aplicações

Apesar da realidade virtual também usar múltiplas mídias,

A comparação entre multimídia e realidade virtual pode ser

• Multimídia envolve imagens capturadas ou pré-

processamento; usa técnicas e recursos de renderização de modelos

1.2.3. Realidade Aumentada

Figura 1.2. Realidade aumentada com vaso e carro virtuais

A realidade aumentada e a realidade virtual [Bimber, 2004]

- a realidade aumentada enriquece a cena do mundo real

elementos e comportamentos para facilitar e potencializar a

Ambientes de hiper-realidade permitirão que habitantes

Muito do que se desenvolveu na Internet para facilitar a

Mais recentemente, com a popularização da webcam e com

Assim, o capítulo 2 deste livro explora, em detalhes, os

Para que uma interação tenha efeito, é necessário um

O capítulo 3 deste livro trata dos detalhes da interação em

1.3. Tecnologia, Projeto e Aplicações

1.3.1. Ambientes de Hardware e Software

O hardware envolve muitos elementos, consistindo de:

Para fazer o hardware funcionar adequadamente, são usados

O capítulo 4 deste livro aborda as questões de hardware e

1.3.2. Desenvolvimento e Avaliação de Sistemas

O capítulo 5 deste livro trata desse assunto para a área de

desenvolvimento, etc, constituindo ferramentas de autoria das

O capítulo 6 deste livro faz uma análise de ferramentas para

1.3.4. Sistemas Distribuídos

O capítulo 7 deste livro trata das questões de sistemas

1.3.5. Dispositivos Hápticos