ads:
MINISTÉRIO DA DEFESA
EXÉRCITO BRASILEIRO
SECRETARIA DA CIÊNCIA E TECNOLOGIA
INSTITUTO MILITAR DE ENGENHARIA
CURSO DE MESTRADO EM SISTEMAS E COMPUTAÇÃO
Ten EDUARDO DE ALMEIDA CADORIN
ACAmPE : AMBIENTE VIRTUAL COLABORATIVO
PARA A ÁREA DE PETRÓLEO
Rio de Janeiro
2005
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
INSTITUTO MILITAR DE ENGENHARIA
Ten EDUARDO DE ALMEIDA CADORIN
ACAmPE : AMBIENTE VIRTUAL COLABORATIVO PARA A ÁREA
DE PETRÓLEO
Dissertação de Mestrado apresentada ao Curso de
Mestrado em Sistemas e Computação do Instituto Militar
de Engenharia, como requisito parcial para a obtenção do
título de Mestre em Ciências em Sistemas e Computação.
Orientador: Jauvane Cavalcante de Oliveira – Ph.D.
Co-Orientador : TC. Edison Ishikawa – D. Sc.
Rio de Janeiro
2005
ads:
2
C2005
INSTITUTO MILITAR DE ENGENHARIA
Praça General Tibúrcio, 80 – Praia Vermelha
Rio de Janeiro - RJ CEP: 22290-270
Este exemplar é de propriedade do Instituto Militar de Engenharia, que poderá incluí-lo
em base de dados, armazenar em computador, microfilmar ou adotar qualquer forma de
arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão deste trabalho entre
bibliotecas, sem modificação de seu texto, em qualquer meio que esteja ou venha a ser fixado,
para pesquisa acadêmica, comentários e citações, desde que sem finalidade comercial e que
seja feita a referência bibliográfica completa.
Os conceitos expressos neste trabalho são de responsabilidade do autor e dos
orientadores.
C125b Cadorin, Eduardo de Almeida
ACAmPE : Ambiente Virtual Colaborativo para a Área de
Petróleo/Eduardo de Almeida Cadorin. - Rio de Janeiro :
Instituto Militar de Engenharia, 2005.
85 p. : il.
Dissertação: (mestrado) - Instituto Militar de Engenharia –
Rio de Janeiro, 2005.
1. Sistemas Multimídia – Petróleo. 2. Interação homem-
computador. I. Instituto Militar de
Engenharia. II. Título
CDD 006.78
3
INSTITUTO MILITAR DE ENGENHARIA
Ten EDUARDO DE ALMEIDA CADORIN
ACAmPE : AMBIENTE VIRTUAL COLABORATIVO PARA A ÁREA DO
PETRÓLEO
Dissertação de Mestrado apresentada no Curso de Mestrado em Sistemas e Computação
do Instituto Militar de Engenharia, como requisito parcial para a obtenção do título de Mestre
em Ciências em Sistemas e Computação.
Orientador : Jauvane Cavalcante de Oliveira – Ph.D.
Co-Orientador : TC. Edison Ishikawa – D.Sc.
Aprovada em 14 de julho de 2005 pela seguinte Banca Examinadora:
___________________________________________________________________________
Prof. Jauvane Cavalcante de Oliveira – Ph.D. do LNCC - Presidente
___________________________________________________________________________
Prof. TC. Edison Ishikawa – D.Sc. do IME
___________________________________________________________________________
Prof. Paulo Fernando Ferreira Rosa – Ph.D. do IME
___________________________________________________________________________
Prof. Artur Ziviani – Docteur do LNCC
Rio de Janeiro
2005
4
À minha querida esposa Michele, às minhas filhas
Giovana e Giulia e a meus pais, pelo amor, apoio e
compreensão neste e em todos os momentos da minha
vida.
5
AGRADECIMENTOS
Aos meus pais, Severino e Helena Cadorin, por despertar em mim o prazer em aprender.
À minha amada e querida esposa Michele, pelo seu amor, carinho, atenção e
compreensão nos inúmeros momentos em que tive que priorizar este trabalho.
Às minhas maravilhosas filhas, Giovana e Giulia, que tornaram meus momentos de
descanso muito mais alegres e divertidos e meus momentos de trabalho bem mais agitados.
Aos meus sogros, Wagner e Iza Baroni, pelo carinho e apoio.
Ao Jauvane C. Oliveira, orientador e amigo, pela atenção, dedicação, apoio, incentivo e
amizade. Sua orientação foi vital na execução deste trabalho.
Ao colega Carlos Silva, do LNCC, pela amizade e dedicação na modelagem dos objetos
tridimensionais, artisticamente criados para este trabalho.
Aos membros da banca examindora, TC. Edison Ishikawa, professores Paulo Rosa e
Artur Ziviani, por aceitarem o convite para compor a banca e nos honrar com suas presenças,
sugestões e correções.
Aos colegas do laboratório ACiMA do LNCC, por seu companheirismo e apoio.
À Fábrica de Materiais de Comunicação e Eletrônica da Indústria de Material Bélico do
Brasil, pelo apoio e confiança.
Ao Instituto Militar de Engenharia, pela excelência do ensino.
Ao Laboratório Nacional de Computação Científica, pelo apoio ao trabalho realizado.
Ao laboratório DISCOVER, da Universidade de Ottawa, no Canadá, por ceder o código
do programa COVET, que foi utilizado como ponto de partida deste trabalho.
A todos que, de alguma forma, contribuíram para a concretização desta dissertação.
6
“Existem mais pessoas que desistem do que pessoas
que fracassam”.
HENRY FORD
7
SUMÁRIO
LISTA DE ILUSTRAÇÕES.....................................................................................................10
LISTA DE TABELAS..............................................................................................................13
LISTA DE SIGLAS..................................................................................................................14
1 INTRODUÇÃO................................................................................................................17
2 COMPONENTES DE UM AMBIENTE VIRTUAL COLABORATIVO..................20
2.1 Modelagem Geométrica..............................................................................................20
2.1.1 Padrão 3DS.................................................................................................................20
2.1.2 Padrão VRML.............................................................................................................21
2.1.2.1 Histórico......................................................................................................................21
2.1.2.2 Características.............................................................................................................22
2.1.3 Padrão X3D.................................................................................................................24
2.2 Renderização 3D.........................................................................................................24
2.2.1 OpenGL.......................................................................................................................25
2.2.2 DirectX........................................................................................................................26
2.2.3 VR Juggler..................................................................................................................27
2.2.4 SmallVR......................................................................................................................28
2.2.5 Java 3D........................................................................................................................29
2.3 Arquitetura de Distribuição da Informação................................................................32
2.3.1 Arquitetura de Comunicação......................................................................................33
2.3.1.1 Arquitetura Cliente/Servidor.......................................................................................33
2.3.1.2 Arquitetura Peer-to-Peer............................................................................................33
2.3.2 Modelos de Comunicação...........................................................................................34
2.3.2.1 Unicast........................................................................................................................35
2.3.2.2 Broadcast.....................................................................................................................35
2.3.2.3 Multicast......................................................................................................................36
2.3.2.4 Anycast........................................................................................................................38
2.4 Conceitos Principais de Realidade Virtual..................................................................38
8
2.4.1 Imersão........................................................................................................................39
2.4.2 Interação......................................................................................................................40
2.4.3 Envolvimento..............................................................................................................40
2.5 Dispositivos de Entrada e Saída..................................................................................41
2.5.1 Luva de Dados............................................................................................................41
2.5.2 Braço Mecânico..........................................................................................................42
2.5.3 Capacete de Visualização e Óculos 3D.......................................................................43
2.5.4 Sistemas de Posicionamento.......................................................................................44
2.5.5 Joystics........................................................................................................................44
2.6 Tecnologia de Integração............................................................................................45
2.6.1 Java..............................................................................................................................45
3 TRABALHOS RELACIONADOS .................................................................................47
3.1 Desktop Virtual Reality Miner Training Simulator....................................................47
3.2 Virtual TrainingPit......................................................................................................49
3.3 Firefighter Command Training Virtual Environment.................................................50
3.4 omVR – A Safety Training System For A Virtual Refinary..….........………………..51
3.5 Walkinside.…………………………………………..............…................................54
3.6 COVET.......................................................................................................................55
3.7 O Sistema Ideal...........................................................................................................56
3.8 O Sistema Proposto: ACAmPE...................................................................................57
3.9 Quadro Comparativo...................................................................................................58
4 ACAmPE............................................................................................................................59
5 CONCLUSÃO...................................................................................................................74
5.1 Avaliação do trabalho.................................................................................................74
5.2 Características.............................................................................................................75
5.3 Trabalhos futuros........................................................................................................76
5.3.1 Sistema de leitura e remoção das seções.....................................................................76
5.3.2 Locales com grupos multicast.....................................................................................77
9
5.3.3 Sistemas externos de detecção de colisão...................................................................77
5.3.4 Arquivos externos com os treinamentos.....................................................................78
5.3.5 Possibilidade de escolha do avatar..............................................................................78
5.3.6 Uso de mensagens de inicialização.............................................................................79
5.3.7 Criação de novos comportamentos para os avatares...................................................79
6 REFERÊNCIAS BIBLIOGRÁFICAS............................................................................80
10
LISTA DE ILUSTRAÇÕES
FIG. 2.1 Comunicação entre um applet Java e um mundo VRML..........................................23
FIG. 2.2 Arquitetura da API OpenGL.......................................................................................26
FIG. 2.3 Relação entre as várias camadas de software no contexto Java 3D...........................29
FIG. 2.4 Grafos de visão e de conteúdo....................................................................................30
FIG. 2.5 Modelo unicast: uma mensagem enviada para cada usuário......................................35
FIG. 2.6 Modelo Broadcast: uma mensagem enviada, todos recebem.....................................36
FIG. 2.7 Modelo Multicast: somente usuários do grupo recebem a mensagem.......................37
FIG. 2.8 Agrupamento de usuários utilizando multicast..........................................................38
FIG. 2.9 Luvas de dados (gloves).............................................................................................42
FIG. 2.10 Braço mecânico (phantom) ......................................................................................42
FIG. 2.11 Capacete de visualização e óculos 3D......................................................................43
FIG. 2.12 Joystick com o recurso “force feedback” ................................................................44
FIG. 2.13 Independência de plataforma ou código compilado.................................................46
FIG. 3.1 Telas do programa………………………………………………….........................47
FIG. 3.2 Twilight3Ds Graphical Engine……………………………………………...……..48
11
FIG. 3.3 Modelo 3D do cockpit virtual e os dispositivos de RV utilizados............................49
FIG. 3.4 Informações de feedback mostradas aos pilotos pelo sistema...................................49
FIG. 3.5 Cenas do ambiente de treinamento de bombeiros.....................................................50
FIG. 3.6 Esquema completo do sistema omVR.......................................................................51
FIG. 3.7 Módulo do treinador no servidor NT.........................................................................52
FIG. 3.8 Modelo da refinaria...................................................................................................52
FIG. 3.9 Sala de ferramentas e área de operação.....................................................................53
FIG. 3.10 Direções distintas de observação e de deslocamento..............................................53
FIG. 3.11 Ambiente virtual de uma plataforma de petróleo do Walkinside............................54
FIG. 3.12 Avatar efetuando o reparo.......................................................................................55
FIG. 3.13 Tela do COVET.......................................................................................................55
FIG. 4.1 Objetos VRML do avatar e 3DS da plataforma........................................................59
FIG. 4.2 Interface do sistema ACAmPE..................................................................................60
FIG. 4.3 Sistema de treinamento..............................................................................................61
FIG. 4.4 Modelos dos avatares masculino e feminino..............................................................61
FIG. 4.5 Câmeras: a) superior; b) lateral; c) frontal; d) God eyes; e) frontal eyes; f) rat
eyes.............................................................................................................................64
12
FIG. 4.6 Visão frontal com o avatar olhando para o lado........................................................65
FIG. 4.7 Código da thread de controle do cronômetro...........................................................65
FIG. 4.8 Divisão da plataforma em 42 seções..........................................................................66
FIG. 4.9 Posicionamento das seções........................................................................................66
FIG. 4.10 Sistema de seções....................................................................................................67
FIG. 4.11 Sequência com a câmera superior: leitura e remoção das seções.............................67
FIG. 4.12 Tipos de superfícies de colisão do Java3D..............................................................70
FIG. 4.13 Código da classe CollisionDetector........................................................................70
FIG. 4.14 Cilindro sensor do sistema de colisão.......................................................................71
FIG. 4.15 Trecho do código do controle de movimentação.....................................................71
FIG. 4.16 Código da Thread gravidade...................................................................................72
FIG. 4.17 Esfera sensora do sistema de gravidade...................................................................72
FIG. 4.18 Trecho do código da função cai ()...........................................................................73
13
LISTA DE TABELAS
TAB. 3.1 Quadro comparativo entre os sistemas.....................................................................58
TAB. 4.1 Teclas de controle do avatar e suas descrições.........................................................62
TAB. 4.2 Descrição dos nomes e tipos de câmeras disponíveis..............................................63
14
LISTA DE SIGLAS
ACAmPE Ambiente virtual Colaborativo para a Área de PEtróleo
API Application Programming Interface
ASCII American Standart Caracter II
AV Ambiente Virtual
AVC Ambiente Virtual Colaborativo
BG BranchGroup
CAVE Cave Automatic Virtual Environment
CRT Catode Ray Tube
HMD Head Mounted Display
HTML HiperText Marked Language
IP Internet Protocol
IPv4 Internet Protocol – versão 4
IPv6 Internet Protocol – versão 6
LCD Liquid Cristal Display
LRV Laboratório de Realidade Virtual
RNP Rede Nacional de Ensino e Pesquisa
TG TransformGroup
X3D Extensible 3D
VRML Virtual Reality Modeling Language
15
RESUMO
A realidade virtual está cada vez mais presente e, em certas atividades, está se tornando
essencial. O uso de ambientes virtuais, para se efetuar treinamentos, vem aumentando
consideravelmente e está se tornando uma peça chave neste processo. Permitir que situações
de risco e de emergência sejam treinadas, unir funcionários geograficamente distantes
permitindo que eles interajam no mundo virtual, são apenas algumas das novas facilidades
que esta tecnologia oferece.
Nesta dissertação é apresentado um ambiente virtual colaborativo, para uso em
treinamentos na área de petróleo. O protótipo apresentado neste trabalho visa oferecer um
ambiente de treinamento para funcionários que, trabalham ou vão trabalhar, em uma
plataforma de petróleo. O mundo virtual tratado é um modelo, em escala, de uma plataforma
de petróleo real, obtendo-se assim um alto nível de detalhamento e realismo.
É apresentado um estudo sobre ambientes virtuais colaborativos, voltados para
treinamentos, bem como uma análise comparativa entre eles e o protótipo deste trabalho.
16
ABSTRACT
Virtual reality is increasingly present and in certain activities is becoming essential. The
usage of virtual environments for training has been increasing steadily. Collaborative Virtual
Environments (CVE) can be used to allow workers to practice security procedures in various
cases of emergencies or risky procedures. It allows users to interact amongst themselves as
well as with the environment, even if those users are geographically spread..
This thesis introduces a CVE for training in the oil industry, more precisely training of
workers who are to be aboard offshore oil platforms with regard to security procedures and
reaction in critical situations. The CVE consists of a realistic 3d model of an offshore
platform where users interact and need to react correctly according to each emergency they
are exposed to.
17
1 INTRODUÇÃO
Um Ambiente Virtual Colaborativo (AVC) consiste em uma simulação de um mundo
sintético controlado por computador, através do qual um grupo de usuários colaboram entre
si. Em um AVC os usuários ficam imersos no mundo virtual e podem interagir em tempo
real, compartilhar informações e manipular objetos do ambiente. A idéia de colaboração vem
do fato que os usuários juntos podem, num esforço coordenado, resolver um problema ou
simplesmente interagir no meio, como se estivessem fisicamente presentes no mesmo
ambiente real.
Os métodos tradicionais de treinamento, como documentos impressos e apresentação de
“slides”, já não são suficientes o bastante para abranger toda a complexidade de certas
atividades (BLUEMEL et al, 2003). Os AVCs surgem, então, como uma nova possibilidade
no treinamento, onde o usuário pode se deparar com o problema real sem que corra riscos e
sem ter que se locomover fisicamente para o local onde o treinamento real poderia ser
realizado.
Para a criação do AVC, alguns pontos são fundamentais como: a qualidade na exibição
das imagens, a sensação real de imersão e, principalmente, uma perfeita interação do usuário
com o ambiente e com os demais usuários.
No ambiente virtual os usuários podem se comunicar com os demais, tomar decisões
juntos e discutir assuntos, desde que, dentro do mundo virtual, estejam próximos,
independentemente de suas distâncias geográficas no mundo real. Com isso, podemos ter
vários funcionários sendo treinados juntos, dentro do mesmo mundo virtual, mas
geograficamente distribuídos.
Ao entrar no mundo virtual, os usuários são representados tridimensionalmente por
“avatares” (avatar é uma palavra originária da Índia e significa encarnação da divindade, que
acontece quando um indivíduo se une a um espírito e retorna à Terra). O significado de avatar
para a área tecnológica foi trazido pela série de televisão “Snowcrash”, escrita por Neal
Stephenon: os avatares são aqueles que atuam no ambiente virtual sob o controle do usuário
(PINHO, 2002).
O treinamento exigido pelas indústrias de petróleo para que um novo funcionário
embarque em uma plataforma é muito severo, e é necessário que o mesmo passe por uma
série de testes até estar totalmente apto. O uso de AVCs neste tipo de treinamento auxilia o
18
futuro funcionário a se ambientar com a plataforma e também a executar os treinamentos
exigidos.
Treinamentos podem, por muitas vezes, colocar em risco a vida dos funcionários,
principalmente a dos que ainda estão se adaptando à plataforma. Nestes casos, o uso de AVCs
para os treinamentos é muito indicado, pois o mesmo treinamento pode ser repetido diversas
vezes, sem que haja risco à vida do funcionário.
Alguns treinamentos, por sua vez, exigem que certas partes da plataforma sejam
danificadas para que os mesmos possam ser executados. É o caso de focos de incêncio,
explosões, quebra de canalizações e de estruturas. Em março de 2001, um acidente desta
natureza ocorreu na P36 da Petrobras, causando a morte de 11 operários. Ao todo foram três
explosões que ocorreram num intervalo de 15 minutos. A primeira ocorreu 20 minutos depois
da meia-noite. A segunda, apenas quatro minutos depois da primeira, foi a mais grave e a que
causou os maiores estragos. Quando a terceira explosão aconteceu, o fogo já havia tomado a
plataforma P36.
Este tipo de problema pode ser evitado com simulações em um AVC. No ambiente
virtual é possível “danificar” qualquer parte da plataforma, de diversas formas, quantas vezes
forem necessárias, de forma a se obter o melhor resultado no treinamento.
Há casos, também, em que o treinamento real se torna praticamente impossível, como em
acidentes envolvendo helicópteros. Na Bacia de Campos um helicóptero da empresa BHS,
resultou na morte de cinco pessoas. A aeronave caiu quando o rotor da cauda chocou-se
contra o mastro do navio Toisa Mariner, ao tentar pousar no heliponto da embarcação, a 60
quilômetros da costa.
Há muito risco envolvido no momento da operação real mas, muitas vidas podem ser
salvas se o treinamento for feito corretamente. Para que o treinamento seja completo, deve-se
poder modificar as variáveis envolvidas no acidente, sendo o uso de AVCs mais do que
indicado, essencial.
Com base nestes fatos, e visando atender a estas necessidades, nasceu a idéia de se
desenvolver um AVC que pudesse servir para estes e outros treinamentos relacionados à área
de petróleo, surgindo assim o ACAmPE : Ambiente virtual C
olaborativo para a Área de
PEtróleo.
O ACAmPE é um sistema de realidade virtual desenvolvido para o treinamento de
técnicas de segurança e ambientação em plataformas de petróleo, o qual pode ser extendido
19
facilmente para diversos outros tipos de treinamentos. Neste tipo de ambiente o usuário está
imerso no ambiente virtual tornando o treinamento muito mais próximo do real.
No ACAmPE o mundo virtual é dividido em diversas seções, permitindo que sejam
utilizados ambientes de dimensões ilimitadas. Vários usuários podem entrar ao mesmo tempo
no ambiente e juntos interagirem entre si e com o ambiente. Todos os usuários podem se
movimentar livremente pela plataforma, tendo ainda um conjunto de câmeras que
acompanham cada usuário, possibilitando uma visão completa do usuário e do ambiente ao
seu redor.
Esta dissertação está estruturada em 5 capítulos de tal forma que :
• No capítulo 2 serão apresentados os componentes envolvidos num Ambiente Virtual
Colaborativo: comunicação e controle; renderização; modelagem de conteúdo;
dispositivos de entrada e saída;
• No capítulo 3 serão analisados os trabalhos que foram estudados e utilizados como
parâmetros para o desenvolvimento do ACAmPE;
• No capítulo 4 será apresentado o ACAmPE – ambiente proposto neste trabalho;
• No capítulo 5 serão apresentadas as conclusões para o trabalho, bem como as
perspectivas de trabalhos futuros para sua continuidade.
20
2 COMPONENTES DE UM AMBIENTE VIRTUAL COLABORATIVO
Para a confecção de um ambiente virtual colaborativo alguns componentes fundamentais
devem ser analisados para que seja efetuada a escolha mais adequada dentre todas as
possibilidades. Neste capitulo serão abordados os seguintes componentes :
• Modelagem geométria : construção e representação dos objetos do mundo virtual;
• Renderização 3D : apresentação ao usuário dos objetos modelados;
• Arquiteturas de distribuição : arquiteturas e modelos de comunicação entre
computadores;
• Conceitos principais de realidade virtual : imersão, interação e envolvimento;
• Dispositivos de entrada e saída : luva de dados, braço mecânico, capacete de
visualização, óculos 3D, sistemas de posicionamento, joysticks;
• Tecnologias de integração : plataformas que permitem todas as tecnologias
trabalharem em conjunto.
2.1 MODELAGEM GEOMÉTRICA
A modelagem geométrica consiste na construção e representação dos objetos do mundo
virtual. Os padrões de modelagem são aqueles nos quais os objetos podem ser exportados,
cada qual com características próprias, com suas vantagens e desvantagens.
Serão abordados nesta seção os padrões 3DS (3DSMAX,2005), VRML - Virtual Reality
Modeling Language (VRML,2005) e X3D (X3D,2005).
2.1.1 PADRÃO 3DS
O 3D Studio MAX™ é um software profissional de modelagem, animação e
renderização. Possibilita a criação fácil e intuitiva de modelos tridimensionais complexos, a
21
obtenção de modelos com qualidade foto-realista e a criação de animações de elevada
qualidade.
Além de salvar os objetos em seu formato nativo atual – MAX – ele permite que o
objetos sejam exportados para outros formatos, dentre eles o 3DS, seu antigo formato nativo,
e o VRML.
A utilização de uma arquitetura orientada a objetos permite reter, com cada objeto, o seu
histórico, o que significa que praticamente todas as suas propriedades podem ser modificadas
a qualquer momento. O programa foi construído de forma que aplicações externas (plug-ins)
podem ser facilmente inseridas, expandindo consideravelmente as suas capacidades.
O 3D Studio MAX™ possui uma grande comunidade de desenvolvimento de plugins e
modelos tridimensionais.
2.1.2 PADRÃO VRML
VRML – Virtual Reality Modeling Language - é uma linguagem para criação de mundos
virtuais onde os usuários podem navegar e interagir com os objetos do mundo (FIG 2.1). A
descrição do mundo é feita através de elementos geométricos, já possuindo objetos pré-
definidos como cubo, cone, cilindro e esfera. Algumas transformações são suportadas como
rotação, translação e ajuste de escala; aplicação de texturas, luz e sombreamento; e nível de
detalhe (LOD, level of detail) que permite ajustar a complexidade dos objetos, de acordo com
a distância do observador.
2.1.2.1 HISTÓRICO
Com o objetivo de desenvolver uma infra-estrutura para aplicações gráficas
tridimensionais a SGI, em 1989, iniciou um projeto chamado Scenario. Como resultado deste
projeto, em 1992, foi criada uma biblioteca gráfica chamada Inventor 3D, para permitir que os
programadores desenvolvessem, com rapidez, programas gráficos 3D interativos, utilizando
conceitos de cena e descrição de objetos (RODRIGUES, OLIVEIRA & PEIXOTO, 2004).
22
Na 1
a
Conferência da World Wide Web, em 1994, o grupo de discussão de realidade
virtual decidiu desenvolver uma linguagem de descrição de cena para que fosse utilizada na
Web. Naquele mesmo ano, em outubro, na 2
a
Conferência da World Wide Web, foi decidida a
utilização de um formato baseado no metafile do Open Inventor (OPENINVENTOR, 2005),
com modificações que permitissem sua utilização em rede.
Em 1995, foi especificada a versão 1.0 da VRML que permitia a criação de cenas
estáticas e, em 1996, foi lançada a versão 1.0c, a qual corrigia alguns problemas. Ainda em
1995, foi formado o VRML Architecture Group (VAG) que, em 1996, decidiu aceitar a
proposta de inserir na linguagem suporte a animações e interações, sendo este o ponto de
partida para a especificação do VRML 2.0 (VRML20, 2005), anunciada no Siggraph’96. Em
1997, alguns pontos foram revistos e a especificação foi reescrita e chamada de
VRML97(VRML97, 2005).
2.1.2.2 CARACTERÍSTICAS
VRML é uma linguagem para descrição de geometria e comportamento, independente de
plataforma, a qual permite a criação de objetos tridimensionais.
Os arquivos VRML têm formato ASCII e extensão .wrl, podendo ser escritos em
qualquer editor de textos. A linguagem apenas descreve como os ambientes devem ser
representados e está para o tridimensional assim como o HTML (HyperText Markup
Language) está para o bidimensional. O VRML é interpretado, da mesma forma que o HTML,
e seus objetos podem ser visualizados em qualquer navegador de internet (browser) com o
auxílio de um plug-in apropriado, como o blaxxun Contact (BLAXXUN, 2005). O browser
carrega o arquivo texto, monta o ambiente, carrega as texturas e, a partir de então, o usuário
pode navegar livremente pelo ambiente, mudando a visão para qualquer ângulo ou posição.
Na versão VRML 2.0, os objetos podem se mover e responder a eventos baseados no
tempo ou em eventos do próprio usuário, além de permitir a inserção de elementos multimídia
como sons e filmes (RODRIGUES & OLIVEIRA & PEIXOTO, 2004).
Um arquivo VRML se caracteriza por quatro elementos principais: o cabeçalho, que é
obrigatório; os protótipos; as formas, interpoladores, sensores, scripts; e as rotas. Com
exceção do cabeçalho, um arquivo VRML não necessita de todos os componentes, contudo,
23
sem possuir pelo menos uma figura, o navegador não exibirá nada ao ler o arquivo. Além
destes, outros componentes que um arquivo VRML também pode conter são comentários,
nós, campos de valores e definição dos nomes dos nós usados (CARDOSO, 2003).
O cabeçalho é composto pela instrução “#VRML V2.0 utf8” e sua omissão impossibilita
que o navegador abra o arquivo; os protótipos contêm a definição de novos nós que podem ser
usados no arquivo; a seção de descrição das formas define como elas serão apresentadas no
navegador; as rotas contêm a definição das trocas de mensagens entre os nós de descrição de
formas, interpoladores, sensores e scripts.
Os cenários tridimensionais VRML baseiam-se na elaboração de um grafo direcionado
acíclico, contendo diferentes nós, que podem estar agrupados ou independentes uns dos
outros. São ao todo 54 tipos de nós pré-definidos, incluindo primitivas geométricas,
propriedades de aparência, sons e vários tipos de nós de agrupamentos, demonstrando a
grande diversidade de nós existentes, uma das qualidades desta linguagem.
Podem ser inseridos scripts que facilitam as animações utilizando-se Javascript,
complementando a troca de informações entre os elementos do mundo virtual. O código em
Javascript pode fazer parte do arquivo original.
Um mundo VRML pode ser controlado também, utilizando-se uma interface do Java
denominada External Authoring Interface – EAI. Esta interface possibilita que uma aplicação
ou applet Java controle uma cena VRML, como controla qualquer outro elemento da matriz
multimídia: áudio, vídeo e etc. Da mesma forma que, quando se pressiona um botão, pode se
associar a execução de um vídeo, pode-se também enviar um evento para uma cena VRML,
de forma a alterar algum parâmetro, como uma posição ou cor de um objeto.
Este API tem um conjunto de classes e métodos que possibilitam a um applet acionar
funcionalidades de um navegador VRML e também de se comunicar com os objetos da cena.
É um processo de, basicamente, enviar e receber eventos de uma cena VRML
A FIG.2.1 apresenta como é possível esta comunicação, sendo o EAI uma ponte de
ligação que permite a comunicação entre o applet Java e o mundo VRML.
FIG. 2.1 – Comunicação entre um applet Java e um mundo VRML.
Arquivo
HTML
applet
JAVA
EAI
External
Authoring
Interface
Mundo
VRML
24
2.1.3 PADRÃO X3D
O X3D é um padrão aberto de distribuição de conteúdo 3D. Ele combina geometria e
descrições de comportamentos instantâneos em um único arquivo. Existem inúmeros
formatos de arquivos disponíveis, incluindo o Extensible Markup Language (XML). É a
revisão seguinte da especificação ISO VRML97, incorporando os avanços dos recursos
disponíveis nos dispositivos gráficos comerciais, via a introdução de novos nós e campos dos
dados, tanto quanto melhorias na sua arquitetura. Adicionalmente mudanças menores foram
feitas de forma a 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 grafo de cena X3D, que é o coração das aplicações X3D, é praticamente o mesmo do
grafo de cena VRML97.
As principais mudanças podem ser resumidas 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;
• Arquitetura em modulos, permitindo uma faixa de níveis que podem ser adotados
e suportados por diversos tipos de mercados;
• Estrutura da especificação expandida;
2.2 RENDERIZAÇÃO 3D
Chamamos de renderização a apresentação ao usuário dos objetos modelados. Existem
algumas bibliotecas responsáveis por acessar diretamente a placa de vídeo, as quais podem ser
utilizadas por outras linguagens. De acordo com as necessidades e requisições do sistema a
ser desenvolvido, este conjunto linguagem/biblioteca pode ser escolhido do modo mais
satisfatório.
Nesta seção serão analisadas as bibliotecas OpenGL e Directx e as linguagens Java3D,
VR Juggler e SmallVR.
25
2.2.1 OPENGL
OpenGL é uma biblioteca de rotinas gráficas e de modelagem, bi (2D) e tridimensional
(3D), portável e rápida. Usando OpenGL é possível criar gráficos 3D com uma alta qualidade
visual.
Alguns critérios devem ser satisfeitos pela interface destinada a aplicações gráficas como
ser implementável em plataformas com capacidades distintas sem comprometer o
desempenho gráfico do hardware e sem sacrificar o controle sobre as operações de hardware.
O padrão IRIS GL, desenvolvido pela SGI, foi o antecessor do OpenGL, sendo uma
interface gráfica independente do hardware. A maioria das funcionalidades da IRIS GL foi
removida ou reescrita na OpenGL, tendo suas rotinas e símbolos renomeados para evitar
conflitos. Formou-se, então, o consórcio OpenGL Architecture Review Board, composto
pelas seguintes companhias: 3DLabs, Compaq, Evans & Sutherland, Hewlett-Packard, IBM,
Intel, Intergraph, NVIDIA, Microsoft, e SGI.
A interface OpenGL disponibiliza um controle direto sobre uma gama de funções
gráficas, as quais são agrupadas nas seguintes categorias: Accumulation buffer; Alpha
blending; Anti-aliasing; Automatic rescaling of vertex normals; BGRA pixel formats and
packed pixel formats; Color-index mode; Display list; Double buffering; Feedback; Gouraud
shading; Immediate mode; Level of detail control; Materials lighting and shading; Pixel
operations; Polynomial evaluators; Geometric Primitives; Raster primitives; RGBA mode;
Selection and picking; Specular Highlights; Stencil planes; Texture coordinate edge
clamping; Texture mapping; Three Dimensional Texturing; Transformation; Vertex array
enhancements; Zbuffering, o que permite ao programador especificar os objetos e as
operações necessárias para a produção de imagens gráficas de alta qualidade.
O OpenGL é um padrão destinado apenas para a renderização podendo ser utilizada em
diversos sistemas de janelas como, por exemplo, XWindow System, Motif ou MSWindows,
aproveitando-se dos recursos disponibilizados pelo hardware gráfico existente.
A portabilidade do OpenGL vem do fato dele possuir implementadas funções tanto para
os sistemas baseados em Unix (GLX), quanto para os MSWindows (WGL). Os programas
podem se utilizar das funções comuns presentes na GLU para se comunicar com qualquer
sistema de janelas, ou se utilizar de funções específicas para cada sistema, através da GLX
(unix) ou da WGL (mswindows), como pode ser visto na FIG 2.2.
26
FIG.2.2 – Arquitetura da API OpenGL
A idéia central, na utilização de aplicações baseadas na biblioteca OpenGL, é que
algumas operações complexas podem ser aplicadas em um hardware específico, em vez do
processador principal que não é otimizado para tais operações, como a transformada de
cossenos, útil na renderização de imagens e na texturização de objetos tridimensionais. Este
aumento no desempenho permite que estações de baixo custo executem aplicações com alta
complexidade gráfica.
No XWindows, ela é integrada através da GLX (OpenGL Extension for XWindows), um
conjunto de rotinas para criar e gerenciar um contexto de renderização do OpenGL no
XWindows. Além da GLX, existem outras bibliotecas alternativas para interfaceamento no
XWindows, tais como GLU (OpenGL Utility Toolkit) e GTK. Estas bibliotecas têm um
conjunto de ferramentas que facilita a construção de programas utilizando o OpenGL.
Podemos citar, por exemplo, funções para gerenciamento de janelas, rotinas para geração de
vários objetos gráficos 3D ou dispositivos de entrada de dados.
Uma vantagem em se utilizar a GLU é que esta biblioteca é compatível com praticamente
todas as implementações OpenGL em Windows e X. Em aplicações que requerem uma maior
utilização dos recursos do X, pode-se utilizar a GLU juntamente com a GLX.
2.2.2 DIRECTX
O equivalente da Microsoft
TM
para o OpenGL é chamado de Direct3D que é uma API
integrante do DirectX SDK. Direct3D é uma biblioteca gráfica de alto desempenho rica em
recursos, contudo é mais complexa de se utilizar que o OpenGL e o seu uso é restrito à
plataforma Windows
TM
.
UNIX
WINDOWS
27
Microsoft DirectX® (DIRECTX, 2005)é um conjunto de APIs desenvolvido para que os
computadores que utilizam Microsoft Windows possam executar aplicações ricas em
elementos multimídia como vídeos, animações 3D e som surround. DirectX é parte integrante
da família Windows, exceto o Windows 95, no qual o DirectX deve ser instalado como pacote
opcional.
A definição nas palavras da própria Microsoft
TM
:
“DirectX é um pacote avançado de APIs multimídia, desenvolvido para o sistema
operacional Microsoft Windows. DirectX fornece uma plataforma de desenvolvimeno para
computadores Windows, permitindo aos desenvolvedores de software acessarem
características específicas do hardware sem ter que escrever um código específico para o
hardware. Esta tecnologia foi introduzida em 1995 e é reconhecida como um padrão para o
desenvolvimento de aplicações multimidia em plataformas Windows.” (ELMQVIST, 2005)
2.2.3 VR JUGGLER
VR Juggler é um projeto de pesquisa ativo coordenado pela Profa. Carolina Cruz-Neira e
uma equipe de estudantes do Centro de Aplicações de Realidade Virtual (Virtual Reality
Applications Center) da Universidade Estadual de Iowa, dos Estados Unidos da América
(EUA). Esta pesquisa produziu uma plataforma de desenvolvimento de aplicações de
realidade virtual (BIERBAUM et al., 2001).
Seguindo a mesma filosofia da linguagem Java, VR Juggler também utiliza-se do jargão
“Programe uma vez, experimente em qualquer lugar”, ressaltando sua característica de ser
multiplataforma.
VR Juggler é uma coleção de tecnologias, as quais fornecem as ferramentas necessárias
para o desenvolvimento de aplicações em realidade virtual, permitindo ao usuário executar as
aplicações em sistemas de realidade virtual. Uma aplicação escrita em VR Juggler é,
essencialmente, independente de dispositivo, plataforma e sistema de realidade virtual. VR
Juggler pode rodar com qualquer combinação de tecnologias imersivas e hardware
computacional.
VR Juggler é escalável desde um sistema simples, como um computador PC, até
complexos sistemas com múltiplos monitores sendo executados em clusters ou
28
supercomputadores. Esta flexibilidade permite que as aplicações sejam executadas em
diversas configurações e a portabilidade do código possibilita que vários sistemas
operacionais sejam usados.
2.2.4 SMALLVR
A SmallVR (SMALLVR, 2005) surgiu da necessidade de se ter uma ferramenta de
desenvolvimento para aplicações de realidade virtual, sendo utilizada nas disciplinas de
realidade virtual ministradas na Pontifícia Universidade Católica do Rio Grande do Sul –
PUCRS. Esta ferramenta deveria ser de fácil aprendizado, aproveitando conhecimentos
prévios em OpenGL, para que a concentração do esforço fosse dedicado à programação da
solução dos problemas propostos e não em questões acessórias como controle de dispositivos
gráficos e rotinas de leitura de objetos.
Além do desenvolvimento de projetos em disciplinas, esta ferramenta tem sido utilizada
no desenvolvimento de projetos de pesquisa, bem como em escolas técnicas do SENAI-RS,
sem custo e sem a necessidade de um longo tempo de aprendizagem.
A ferramenta SmallVR é baseada nas bibliotecas OpenGL e GLUT o que permite que o
usuário possa continuar usando a estrutura básica de um programa com a GLUT e apenas
adicionar os objetos e comandos necessários à aplicação sem perder o controle da execução
da aplicação.
A SmallVR tem sido utilizada com sucesso por alunos e pesquisadores e ainda está em
evolução. A forma como a biblioteca está organizada tem se mostrado interessante pela
facilidade de se incluir novas funcionalidades e pelo reduzido tempo necessário para sua
aprendizagem.
2.2.5 JAVA3D
A API JAVA3D (JAVA3D, 2005) é composta por um conjunto de classes que serve
como interface para o desenvolvimento de sistemas gráficos tridimensionais. É baseada em
29
bibliotecas gráficas de mais baixo nível, como OpenGL e Direct3D, conforme FIG 2.3.
Através de construtores de alto nível, pode-se criar, manipular e visualizar objetos
geométricos especificados num universo virtual, sendo os detalhes da visualização
gerenciados automaticamente.
FIG.2.3 – Relação entre as várias camadas de software no contexto Java 3D
Desta forma é possível para os programadores de aplicações explorarem, agora no âmbito
das aplicações tridimensionais, o conjunto de facilidades e vantagens da plataforma Java,
como orientação a objetos, segurança e independência de plataforma.
Esta tecnologia gráfica vem ainda de encontro com a crescente demanda por operações
requisitadas hoje pela internet. Neste sentido, Java 3D se apresenta como uma solução viável,
considerando que a mesma disponibiliza uma interface robusta para a internet.
Uma aplicação Java 3D é projetada a partir de um grafo de cena contendo objetos
gráficos, luz, som, objetos de interação, entre outros, que possibilitam ao programador criar
mundos virtuais com personagens que interagem entre si e/ou com o usuário.
O desenvolvimento de um programa Java3D se resume na criação de objetos e no seu
posicionamento num grafo de cena, que se combinam numa estrutura de árvore. Grafo de
cena é um arranjo de objetos 3D em uma estrutura de árvore que especifica o conteúdo de um
Universo Virtual e indica como este será renderizado. Nele é possível definir som, luz,
orientação, geometria, localização e aparência visual dos objetos.
Descrever uma cena usando um grafo de cena é uma tarefa mais simples do que construir
a cena utilizando linhas de comando que especificam primitivas gráficas, tais como as do
30
OpenGL. Esta abordagem de mais alto nível facilita em muito a tarefa dos programadores
com pouca experiência 3D.
Cada objeto é um nó e pode se relacionar por referência, que simplesmente associa o
objeto ao grafo de cena, ou por herança, podendo ser o nó do tipo grupo com um ou mais
filhos, mas somente um pai ou do tipo folha, sem filhos (MANSSOURL, 2003).
A árvore que representa uma cena gráfica tem como raíz o Universo Virtual (UV), do
qual se tem um ou mais Locales, que são componentes responsáveis pelas coordenadas do
ambiente.
Do Locale derivam-se 2 grafos de cena, como pode ser visto na FIG 2.4:
• Grafo de Visão (View Branch Graph) : especifica os parâmetros de controle de
visualização da cena, tal como a direção de observação;
• Grafo de Conteúdo (Content Branch Graph) : descreve a cena gráfica.
FIG. 2.4 – Grafos de visão e de conteúdo
Os grafos de cena (branch graphs) são classificados em duas categorias: de conteúdo e de
visão. Os grafos de conteúdo descrevem os objetos que serão renderizados, ou seja,
especificam a geometria, textura, som, objetos de interação, luz e, ainda, como estes serão
localizados no espaço (ramo esquerdo na FIG. 2.4).
Os grafos de visão especificam as atividades e os parâmetros relacionados com o controle
da vista da cena, tais como orientação e localização do usuário (ramo direito na FIG 2.4).
31
Os grafos de cena não determinam a ordem em que os objetos serão renderizados, mas
sim o que será renderizado.
Alguns objetos/nós Java3D, em particular, são importantes para a compreensão deste
trabalho, assim segue suas definições :
• VirtualUniverse: um objeto desta classe é sempre o nó inicial ou raíz do grafo de
cena;
• Locale: fornece um sistema de coordenadas ao mundo virtual. Um objeto desta classe
está sempre conectado como único filho de uma instância de VirtualUniverse;
• Canvas3D: fornece uma área de desenho (canvas), onde é realizada a visualização 3D;
• BranchGroup: serve como raíz do sub-grafo de cena. É o único objeto que pode ser
inserido (filho) em um Locale;
• Transform3D: especifica as transformações geométricas de escala, rotação e
translação. Representa uma matriz 4x4 de números reais (float);
• TransformGroup: especifica uma transformação, através de um objeto Transform3D,
que será aplicada a todos os seus filhos;
• Light: esta é a classe abstrata que define uma fonte de luz no Java 3D. Suas subclasses
correspondem aos tipos de fonte de luz normalmente encontrados em computação
gráfica;
• Shape3D: esta classe é utilizada para representar objetos geométricos no mundo
virtual.
Um ponto de partida para a criação de um programa Java3D, segundo a própria Sun
Microsystem é :
• Criar um objeto Canvas3D;
• Criar um objeto VirtualUniverse;
• Criar um objeto Locale e anexá-lo ao VirtualUniverse;
• Construir um grafo view branch
• Criar um objeto View;
• Criar um objeto ViewPlatform;
• Criar um objeto PhysicalBody;
• Criar um objeto PhysicalEnvironment;
• Anexar os objetos criados em (b), (c) e (d) ao objeto View;
• Construir um ou mais grafos content branch;
32
• Compilar o(s) branch graph(s);
• Inserir os subgrafos ao nó Locale;
Programadores Java podem rapidamente definir programas gráficos tridimensionais
utilizando as classes gráficas da API Java3D.
2.3 ARQUITETURA DE DISTRIBUIÇÃO DA INFORMAÇÃO
Para se configurar um sistema colaborativo é necessário que mais de um usuário entre no
ambiente virtual, cada qual em sua própria estação. Cada estação, portanto, precisa se
comunicar com as demais para trocar informações e atualizar o ambiente com suas
modificações e para isto elas precisam estar conectadas entre si por uma rede de
computadores.
Existem três tipos de rede de computadores :
• LANs (Local Area Networks, redes locais) : são as redes restritas a um pequeno
local e que permitem que todos os computadores conectados compartilhem seus
recursos e troquem informações entre si;
• MANs (Metropolitan Area Networks, redes metropolitanas) : são aquelas que
estão compreendidas numa área metropolitana, como as diferentes regiões de toda
uma cidade;
• WANs (Wide Area Networks, redes de longa distância) : basicamente podem ser
consideradas como grandes LANs.
A internet, a maior rede mundial, é um conjunto que engloba LANs e MANs, formando
uma WAN, possuindo milhares de máquinas que uma vez conectadas podem se comunicar
segundo arquiteturas de distribuição de informações, algumas das quais descrevemos nesta
seção.
33
2.3.1 ARQUITETURAS DE COMUNICAÇÃO
Existem algumas arquiteturas para interligar computadores em rede. Nesta seção
ilustraremos a arquitetura cliente/servidor e a arquitetura peer-to-peer.
2.3.1.1 ARQUITETURA CLIENTE/SERVIDOR
A arquitetura cliente/servidor descreve a relação entre dois programas de computador. O
primeiro, o cliente, solicita serviços ou arquivos ao segundo, o servidor, que atende ao pedido.
Boa parte das aplicações na internet é baseada na arquitetura cliente/servidor. O navegador de
internet, por exemplo, é um cliente que solicita os arquivos (HMTL, figuras, etc.) às maquinas
que atuam como servidores.
Este tipo de funcionamento é bastante interessante por não necessitar manter uma
conexão permanente entre os envolvidos, sendo bastante útil, também, na internet.
A arquitetura cliente/servidor veio substituir a antiga arquitetura de comunicação
centralizada, em que mainframes atendiam a uma série de terminais ditos “ burros”, pois
limitavam-se a exibir os dados. Na arquitetura cliente/servidor os computadores que rodam os
programas clientes podem participar do processamento dos dados não se limitando à mera
exibição destes.
2.3.1.2 ARQUITETURA PEER-TO-PEER
A principal diferença entre a arquitetura peer-to-peer e a arquitetura cliente/servidor é o
conceito de entidades (SILVA, 2003). Na arquitetura cliente/servidor existe uma entidade que
faz o papel de servidor e outras entidades que fazem o papel de clientes. Na arquitetura peer-
to-peer (P2P), todas as entidades podem atuar como cliente e servidor ao mesmo tempo.
Chamamos de peer qualquer nó da arquitetura P2P. Pode ser um simples computador; um
dispositivo móvel, como um celular; ou uma aplicação distribuída em vários computadores.
34
P2P tem a capacidade de disponibilizar recursos por um baixo custo, maximizando o uso
dos recursos de todos os peers conectados na rede. As soluções cliente/servidor necessitam de
equipamentos de rede e instalações diferenciadas para que sejam robustas, enquanto que
soluções P2P oferecem o mesmo nível de robustez distribuindo as necessidades por toda a
rede.
A forma distribuída dos canais da rede P2P resulta em pedidos de serviços de natureza
não-determinística. Por exemplo, clientes que requisitam um mesmo arquivo da rede P2P
podem se conectar em máquinas distintas, por diferentes rotas de comunicação e com
resultados diferentes. Os pedidos enviados podem não ter resultados imediatos e, em muitos
casos, não resultar em qualquer resposta.
Alguns recursos podem desaparecer, não ficando mais disponíveis. Nestes casos, a
própria rede P2P tem a capacidade de replicar os recursos mais acessados em outros peers da
rede, promovendo, assim, acesso redundante a estes recursos. Quanto maior o número de
peers que possuem os recursos replicados, menor será a probabilidade de se receber um
pedido sem resposta. Ou seja, a mesma estrutura que pode causar problemas também pode ser
a solução para resolvê-los.
2.3.2 MODELOS DE COMUNICAÇÃO
O tráfego de mensagens, de uma maneira simples, pode ser dividido em três tipos:
• Unicast é o tráfego direcionado para um endereço definido, ou seja, com um único
destinatário;
• Broadcast é o tráfego dirigido para todos os destinos conhecidos;
• Multicast é o tráfego direcionado para um grupo de computadores, os quais estão
configurados e inscritos para receber o tráfego multicast;
• Anycast é o tráfego entre um único emissor e o mais próximo de diversos receptores
em um grupo.
35
2.3.2.1 UNICAST
Unicast é uma conexão ponto-a-ponto entre o servidor e o cliente. Uma conexão ponto-a-
ponto significa que cada cliente pode receber uma mídia distinta do servidor, isto é, o servidor
administra cada conexão com cada cliente.
Este modelo de comunicação não se torna muito apropriado quando o tráfego em questão
consome grande quantidade de banda – dados multimídia – pois, sendo necessário replicá-los
para um número grande de usuários, provocaria uma queda abrupta no desempenho da rede.
A FIG 2.5 exemplifica um modelo de transmissão unicast.
FIG.2.5 – Modelo unicast: uma mensagem enviada para cada usuário.
2.3.2.2 BROADCAST
Broadcast é utilizado quando se deseja enviar um pacote para todos os computadores da
rede. Quando é utilizado o endereço de broadcast, todos os computadores da rede recebem o
pacote e processam o pacote. O broadcast é utilizado por uma série de serviços, como por
exemplo o WINS, para fazer verificações periódicas de nomes, para enviar uma mensagem
para todos os computadores da rede, para obter informações de todos os computadores e
assim por diante.
36
Um detalhe interessante é que, por padrão, a maioria dos roteadores bloqueia o tráfego de
broadcast, para evitar congestionamentos nos links de WAN.
Para o uso em ambientes virtuais colaborativos, ou seja, com mais de um usuário, o
modelo broadcast seria uma solução viável para o envio das mensagens entre os participantes,
pois, ao invés de se enviar uma mensagem para cada usuário no ambiente, bastaria uma única
mensagem para que todos recebessem. O problema, entretanto, ocorre por que todas as
pessoas conectadas na mesma rede receberiam as mensagens e, por vezes, nem todas estariam
participando do ambiente virtual, causando um tráfego desnecessário, ou mesmo poderiam
estar participando de outro ambiente virtual, embaralhando as mensagens entre os dois
ambientes.
A FIG 2.6 exemplifica um modelo de transmissão broadcast.
FIG.2.6 – Modelo Broadcast: uma mensagem enviada, todos recebem.
2.3.2.3 MULTICAST
Multicast é um modelo de comunicação em que um computador emissor envia uma
mensagem a um grupo de computadores destino. Muito embora isso possa ser feito
mandando-se diferentes mensagens do tipo unicast (um-para-um), existem várias razões pelas
quais a comunicação multicast é desejável.
A primeira vantagem é que o endereçamento multicast diminui a carga de tráfego na rede,
já que o transmissor envia somente um pacote da mensagem, sendo que o pacote é replicado
37
apenas se necessário, não consumindo largura de banda da rede com pacotes replicados para
participantes de uma mesma sub-rede.
Um exemplo prático de utilização do multicast é para uma transmissão de vídeo através
da rede. Vamos supor que de uma rede de 1000 computadores, apenas 30 devem receber um
determinado arquivo de vídeo. Se for usado tráfego unicast, serão transmitidas 30 cópias do
arquivo de vídeo (o qual já é um arquivo grande), uma cópia para cada destinatário. Se for
usado o broadcast todos os 1000 computadores receberiam os pacotes do vídeo. Com o uso
do multicast, uma única cópia é transmitida através do link de WAN e o tráfego multicast
entrega uma cópia do arquivo apenas para os 30 computadores devidamente configurados
para receber o tráfego multicast.
A FIG 2.7 exemplifica um modelo de transmissão multicast.
FIG.2.7 – Modelo Multicast: somente usuários do grupo recebem a mensagem.
Os diferentes canais a que os usuários de um ambiente virtual estariam associados
poderiam ser definidos com o uso e um endereço IP classe D, correpondente aos endereços de
224.0.0.0 até 239.255.255.255. Dessa forma, um usuário poderia escolher entrar ou sair de um
grupo multicast informando sua opção ao roteador que o conecta à internet. Nessa mesma
rede, poderíamos ter diversos grupos multicast distintos e esse roteador somente iria repassar
mensagens aos grupos que têm algum usuário cadastrado.
38
FIG.2.8 – Agrupamento de usuários utilizando multicast.
2.3.2.4 ANYCAST
Anycast é utilizado no IPv6 – IPv6 é a nova versão do protocolo de internet, a qual deverá
substituir progressivamente o protocolo atual da Internet, o IPv4, aumentando o espaço de
endereçamento corrente para 128 bits – como uma forma de se atualizar as tabelas de
roteamento. Um host inicia a atualização da tabela para um grupo de hosts enviando dados
para o host mais próximo. O IPv6 pode determinar qual gateway está mais próximo e assim
enviar os pacotes para o host como numa comunicação unicast. Por sua vez, este host também
envia mensagens para o host mais próximo, sucessivamente, até que toda a tabela do grupo
esteja atualizada.
2.4 CONCEITOS PRINCIPAIS DE REALIDADE VIRTUAL
Existe uma discussão entre os pesquisadores da área de computação sobre se o termo
“realidade virtual” é apropriado ou não para tal, devido ao fato de que, na verdade, não se cria
uma nova realidade e sim um novo ambiente onde o usuário tem a sensação de imersão. Desta
forma, o termo “mundos virtuais” teria mais sentido e vem sendo defendido por alguns
39
acadêmicos como uma alternativa mais coerente. Independente de tudo isso, uma definição
para realidade virtual seria “uma técnica avançada de interfaceamento, onde o usuário pode
realizar imersão, navegação e interação em um ambiente sintético tridimentional gerado por
computador, utilizando canais multi-sensoriais” (KIRNER, 2005).
Em termos mais simples, podemos dizer que o usuário consegue, utilizando um conjunto
de dispositivos especiais, que trabalham os sentidos humanos – visão, audição, tato, paladar e
olfato – manipular informações em um ambiente tridimensional criado por computador. Esses
dispositivos permitem ao usuário um conjunto de ações de tal forma que ele terá a sensação
de estar fisicamente dentro do ambiente.
A realidade virtual trabalha com três conceitos principais: imersão, interação e
envolvimento do usuário com o meio. Nesta seção estudaremos estes conceitos.
2.4.1 IMERSÃO
A idéia de imersão está relacionada com a sensação de estar dentro do ambiente virtual.
Além dos fatores visuais, os outros sentidos também são importantes como a audição, o
posicionamento automático da pessoa e dos movimentos da cabeça, controles reativos e etc.
Para se conseguir imersão, é necessário, primeiramente, criar um mundo virtual
tridimensional. Para isso precisa-se ter alguns conhecimentos de computação gráfica como
modelagem de objetos, renderização, visão estereoscópica, etc.
Além da necessidade do usuário ver imagens fotorrealistas do ambiente virtual, é
necessário também que ele seja capaz de perceber esse mundo de um modo interativo, ou seja,
segundo seus próprios movimentos. Um sistema de realidade virtual imersiva precisa
trabalhar a atualização das imagens que são apresentadas em tempo real.
Outras características precisam ser adicionadas ao sistema, além do sentido da visão,
para aumentar a imersão, como a audição e o tato. Imaginemos uma avenida onde os carros
estejam passando em alta velocidade: é de se supor que o barulho dos carros mais próximos
seja mais nitidamente percebido do que o daqueles mais distantes. Imaginemos também que,
com o uso de uma luva de dados (seção 2.5.1), o usuário esteja pegando uma bola virtual. É
natural supor que se ele tentar apertar esta bola ele “sinta” uma certa resistência ao fazê-lo,
dependendo do tipo da bola: borracha, metal, etc.
40
A imersão é a capacidade de o usuário estar convencido de que aquele ambiente virtual
realmente “existe”, haja visto que se pode definir qualquer coisa que existe no mundo real
como sendo aquilo que se é capaz de perceber com os sentidos.
2.4.2 INTERAÇÃO
A idéia de interação está ligada com a capacidade do computador detectar as entradas do
usuário e modificar instantaneamente o mundo virtual e as ações sobre ele – as cenas mudam
em resposta aos comandos do usuário. Esta é a característica mais marcante nos jogos.
Para aumentar a sensação de que o mundo virtual realmente existe é importante permitir a
interação do usuário imerso no ambiente. Para que se possa trabalhar a interação do usuário
com o ambiente também é necessário que o sistema seja capaz de simular as colisões entre os
objetos (se o usuário movimentar um objeto para cima de uma mesa é de se esperar que este
fique sobre a mesa e não “flutue” no ar ou “atravesse” a mesa). Em simulações que exigem
realismo, algumas questões precisam ser consideradas no processo, como a gravidade, o atrito
e vários outros fenômenos da física.
2.4.3 ENVOLVIMENTO
A idéia de envolvimento tem correlação com o grau de motivação para o engajamento de
uma pessoa com determinada atividade. Este envolvimento pode ser passivo, como ler um
livro, ou pode ser ativo, como participar de um jogo com um parceiro. Com realidade virtual é
possível ambos os tipos de envolvimento ao permitir a exploração do ambiente virtual e ao
proporcionar a interação do usuário com o mundo.
Para uma melhor compreensão do conceito de envolvimento, deve-se entender que,
quando o usuário estiver imerso no mundo virtual, ele pode ou não ter a sua disposição os
mecanismos físicos para produzir interação; ou mesmo o próprio ambiente pode permitir ou
não ações do usuário de forma que ele possa interferir no resultado esperado pela aplicação
(envolvimento passivo ou ativo). Imaginemos, por exemplo, um estudante de medicina
41
usando um sistema de realidade virtual para ensino de anatomia. Ele poderia navegar pelos
diferentes órgãos do corpo humano como se ele fosse microscópico. Neste caso ele vê o
mundo, mas não interfere nele (passivo). Se o estudante for praticar uma cirurgia virtual, ele
seria capaz de operar um paciente e, neste caso, seria um agente ativo e modificador do
sistema.
2.5 DISPOSITIVOS DE ENTRADA E SAÍDA
Desde o surgimento de estudos sobre realidade virtual, um dos objetivos das pesquisas é a
criação de dispositivos de entrada e saída que possibilitem ao usuário o máximo de imersão,
interação e envolvimento.
Os dispositivos de entrada podem ser divididos em dois tipos:
• de posicionamento, que lêem a posição de pontos específicos sobre o corpo do
usuário;
• de deslocamento, que lêem o movimento de partes do corpo (rotação da cabeça,
torções do braço, etc.).
Nesta seção estaremos vendo alguns dos dispositivos já desenvolvidos.
2.5.1 LUVA DE DADOS
As luvas de dados (gloves) consistem em uma luva convencional associada a sensores de
posição da mão e dos dedos (FIG 2.9). O princípio de funcionamento é basicamente detectar o
deslocamento de pontos conhecidos na mão e nos dedos.
Alguns modelos possuem um conjunto de micro-motores que geram uma força contrária
sobre os dedos (force feedback) permitindo que o participante tenha diferentes sensações
táteis como, por exemplo, sentir diferentes texturas, densidade e resistência dos objetos.
42
FIG.2.9 – Luvas de dados (gloves)
2.5.2 BRAÇO MECÂNICO
O braço mecânico (phantom) é o meio mais simples e mais conhecido de se obter um
dispositivo de entrada com o sistema de força de retorno (force feedback), que seria uma força
aplicada pelo dispositivo sobre o usuário (FIG 2.10). Esta força aplicada não fornece, no caso
do phantom, uma sensação tátil e sim a possibilidade de explorar o mundo tridimensional,
tendo o senso de limites e densidade dos objetos. Em sistemas médicos aplicados à cirurgia, o
phantom pode, por exemplo, ser utilizado para controlar um bisturi no mundo virtual. O
usuário ao movimentar o braço do aparelho estaria movimentando o bisturi no ambiente
virtual, e teria a resistência de movimento característica ao encostar no corpo do paciente
virtual, aumentando a sensação de imersão.
FIG.2.10 – Braço mecânico (phantom)
43
2.5.3 CAPACETE DE VISUALIZAÇÃO E ÓCULOS 3D
Um capacete de visualização (HMD – Head Mounted Display) consiste em dois
pequenos monitores (CRT ou LCD) e um sistema de lentes ajustáveis. Os HMDs são os
primeiros sistemas de projeção que foram desenvolvidos especificamente para visualização de
ambientes virtuais e, hoje, são amplamente utilizados militarmente e em aplicações médicas.
Eles podem projetar imagens deslocadas e sobrepostas, em cada olho, reproduzindo o efeito
natural da visão, causado pela distância entre os olhos (imagens estereoscópicas).
Os HMDs têm algumas vantagens como: seu uso proporciona ao usuário a sensação física
de imersão; possuem tamanho e peso reduzidos, sendo mais confortáveis que dispositivos
mais antigos; permitem fácil integração com sensores de posicionamento da cabeça; tornam
intuitivo o movimento do ponto de visão do participante.
Por outro lado, o dispositivo apresenta algumas limitações como: o campo de visão que é
limitado; a resolução das imagens projetadas é baixa (1024x768, ou menos); a interação fica
prejudicada pelo fato de que o participante não conseguir visualizar seus braços e mãos.
Os óculos 3D podem se utilizar de uma técnica de polarização para separar o sinal
luminoso relativo ao olho esquerdo e direito, ou podem alternar sequencialmente a projeção
para cada olho de forma transparente ao usuário.
Na FIG 2.11 vemos um HMD a esquerda e os óculos 3D a direita.
FIG.2.11 – Capacete de visualização e óculos 3D
44
2.5.4 SISTEMAS DE POSICIONAMENTO
A correta informação sobre o real posicionamento do usuário é essencial para a sensação
de presença e o sucesso da interação com objetos e outros usuários no mundo virtual. São
utilizados dispositivos de reconhecimento de posição (trackers) na cabeça do usuário para
identificar a posição do mesmo. Para haver a interação ou o dispositivo de interação ou a mão
do usuário deve possuir um tracker.
É importante que o sistema de posicionamento seja capaz de obter todos os 6 graus de
liberdade – rotação nos 3 eixos e translação nos 3 eixos – com alta precisão.
Com a informação do posicionamento da cabeça o sistema é capaz de gerar a visão
coerente do ambiente, que será exibida ao usuário e, cada vez que o usuário movimentar a
cabeça o sistema atualiza a informação que está sendo visualizada pelo usuário.
2.5.5 JOYSTICKS
Joysticks com o recurso de force feedback (FIG. 2.12) foram desenvolvidos para o uso
em sistemas simuladores de vôo e, recentemente, para a indústria de jogos. O recurso de force
feedback, que é a atuação reversa do joystick sobre a mão do usuário, fornece uma sensação
táctil e real quando utilizado. Aliado ao seu baixo custo e à facilidade de configuração e de
integração, este dispositivo passou a ser utilizado com frequência em sistemas de realidade
virtual.
FIG.2.12 – Joystick com o recurso “force feedback”
45
2.6 TECNOLOGIA DE INTEGRAÇÃO
Para que todas as tecnologias vistas nas seções anteriores possam trabalhar em conjunto é
necessário uma plataforma que as integre, permitindo que todas as suas funcionalidades sejam
utilizadas. A plataforma adotada neste trabalho foi a linguagem de programação JAVA, a qual
será analisada na seção 2.6.1.
2.6.1 JAVA
A comunicação entre os ambientes pela rede e o controle de seus componentes, que
mantêm a consistência do sistema, foram desenvolvidos utilizando-se a linguagem de
programação Java.
Java é uma linguagem de programação introduzida ao mercado em 1995 pela Sun
Microsystems (SUN, 2005) e pode ser considerada mais do que uma simples linguagem de
programação, mas todo um ambiente de desenvolvimento e execução de programas.
Java originou-se da linguagem C++ e, como esta, possui todas as facilidades da
programação orientada a objetos e a portabilidade de código, além de características próprias
como a segurança e a facilidade de integração com outros ambientes, como a internet.
O programa Java pode ser escrito em qualquer editor de texto simples e o compilador
Java (javac.exe) gera um código para uma plataforma neutra chamado de bytecode. Esse
código gerado - bytecode - não contém qualquer instrução de um hardware específico, mas
sim de uma máquina virtual.
A Máquina Virtual Java (JVM, Java Virtual Machine) é a implementação de tal máquina
virtual e é específica para cada conjunto hardware/sistema operacional. É a responsável por
interpretar os bytecodes para execução na máquina local.
Além da possibilidade dos bytecodes serem interpretados pela JVM, eles também podem
ser compilados temporariamente para o código nativo em tempo de execução. Antes de iniciar
a execução de um programa a JVM verifica a existência do compilador JIT (Just In Time) e,
caso existam, os bytecodes, ao invés de serem interpretados pela JVM, estes são compilados
46
pelo compilador JIT (FIG. 2.13). O compilador JIT troca maior tempo gasto no carregamento
do programa por desempenho e velocidade na execução.
Existem também compiladores independentes Java que geram um arquivo executável a
partir do código-fonte Java, mas perde-se, neste caso, a portabilidade do programa.
FIG. 2.13 – Independência de plataforma ou código compilado
Os programas Java podem executar diversas rotinas (threads) internas concorrentemente.
Todas as aplicações possuem pelo menos uma thread que representa o canal de execução
principal do programa.
O interpretador verifica todos os acessos de sistema efetuados dentro de um programa e,
assim, os programas Java não conseguem derrubar o sistema. Quando ocorre algum problema,
é gerada uma exceção que pode ser tratada pelo próprio programa.
O sistema Java verifica todos os acessos à memória e garante que nenhum vírus se utilize
de um programa Java em execução. Pelo fato de ponteiros não serem suportados pela
linguagem, os programas não conseguem ter acesso a áreas de memória a que eles não têm
direito.
Java não suporta aritmética de ponteiros, conversão implícita de tipos de dados, estruturas
e uniões, sobrecarga de operadores, gabaritos ou modelos ou ainda herança múltipla.
47
3 TRABALHOS RELACIONADOS
Neste capítulo serão apresentados alguns exemplos de ambientes virtuais utilizados para
treinamentos em diversas áreas. São eles :
• “Desktop virtual reality miner training simulator” : Ambiente virtual colaborativo
desenvolvido para a indústria de mineração;
• “Virtual TrainingPit” : Ambiente virtual desenvolvido para treinamento de pilotos
de avião;
• “Firefighter Command Training Virtual Environment” : Ambiente virtual
colaborativo desenvolvido para treinamento de bombeiros;
• “omVR – A Safety Training System for a Virtual Refinery” : Ambiente virtual
desenvolvido para o treinamento da operação de checagem diária de emissão de
H
2
S em uma refinaria;
• “Walkinside” : Ambiente virtual colaborativo, comercial, desenvolvido para o
treinamento de operários de uma plataforma de petróleo;
• COVET : Ambiente virtual colaborativo para treinamento industrial.
3.1 DESKTOP VIRTUAL REALITY MINER TRAINING SIMULATOR
FIG.3.1 – Telas do programa
48
Este ambiente virtual foi desenvolvido para a indústria de mineração (TIMOTHY,
MARC & TODD) visando ajudar a reduzir o número de acidentes e mortes de mineradores. O
intuito dos pesquisadores foi usar a tecnologia para desenvolver uma mina virtual com
flexibilidade de treinamentos, desde o trabalho subterrâneo na mina até os procedimentos de
evacuação. O ambiente permite colaboração entre os participantes, que podem interagir nos
trabalhos, nos acidentes e nas situações de emergência.
Inicialmente foi utilizada a estrutura do jogo “Quake II” para criar um ambiente 3D de
teste, e para a versão final foi comprada a engine gráfica “Twilight3D’s 3D Graphics
Engine”(TWILIGHT3D, 2005), desenvolvida para a criação de jogos. Esta engine consiste de
3 partes:
• Twilight ALIBI (Advanced LIBrary Interface): contém as classes para interfaces
de entrada e saída para os gráficos 2D, “joysticks”, “wheels”, áudio e etc. Também
permite ler e salvar na maioria dos formatos populares de imagem;
• Twilight 3DEG: módulo principal de renderização 3D;
• Twilight 3DEG Plus Plugins: coleção de plugins, incluindo importadores de
modelos 3DS, ray-intersection, spline e etc.
A Twilight 3DEG suporta Visual C++ Win32 e Watcom C++ Dos32, manipula arquivos
Bitmap, tem um eficiente sistema de mouse e teclado, suporta os padrões mais tradicionais de
arquivos de imagem (JPG, BMP, PNG, TGA, PCX, CEL, PPM, LBM, IFF e XBM),
compacta e criptografa as bibliotecas de dados, é orientada a objetos (C++), dentre outros
recursos. Esta engine é, portanto, bastante flexível permitindo que sejam criados ambientes
realísticos, com alto nível de interação e envolvimento por parte do usuário.
FIG.3.2 – Twilight3Ds Graphical Engine
49
3.2 VIRTUAL TRAININGPIT
FIG.3.3 – Modelo 3D do cockpit virtual e os dispositivos de RV utilizados
Um ambiente virtual desenvolvido na Universidade Federal de Santa Catarina - UFSC, o
Virtual TrainingPit (GARCIA et al., 2002), é um sistema virtual de treinamento de pilotos de
aeronaves. Os “trainingpits” são cabines, em escala ou não, que simulam as diversas funções e
panes de uma aeronave.
Foi desenvolvido, então, um simulador em realidade virtual imersiva, que utiliza-se de
dispositivos de realidade virtual, como capacetes de visualisação (HMD) e luvas, para
transmitir ao aluno-piloto a sensação de uma cabine de uma aeronave e assim realizar seu
treinamento (FIG.3.3). O simulador é utilizado para que os pilotos e co-pilotos se
familiarizem e aprendam o funcionamento dos equipamentos do cockpit e dos sistemas da
aeronave, não funcionando como um simulador de vôo.
FIG.3.4 – Informações de feedback mostradas aos pilotos pelo sistema
50
Utilizando softwares específicos, HMD e luvas, o usuário pode visualizar os sistemas
internos da aeronave (elétricos e/ou hidráulicos) (FIG.3.4) e o toque em um botão, ou o
acionamento de uma alavanca, por exemplo, implicará em resposta do sistema.
No Laboratório de Realidade Virtual da UFSC (LVR, 2005) foram criados dois grupos
distintos que trabalharam em plataformas diferentes. Uma equipe utilizou Unix, C++ e
OpenGL numa Silicon Graphics Octane. A segunda equipe utilizou Windows, Delphi e
VRML num Pentium 4 com 512MB de memória RAM e uma placa gráfica GeForce 4 TI
64MB. Estas duas equipes trabalharam em paralelo de forma complementar, tornando o
sistema compatível com as 2 plataformas utilizadas (Windows e Unix), além de flexibilixar o
modo de criação dos objetos (OpenGL ou VRML).
3.3 FIREFIGHTER COMMAND TRAINING VIRTUAL ENVIRONMENT
Um treinamento real contra incêndio pode pôr em risco a vida do bombeiro que está
sendo treinado, bem como há a necessidade de se criar novos focos de incêndio a cada
treinamento, o que gera um impacto em termos de poluição do ar, custo dos materiais, e uma
manutenção de segurança. Para ajudar a resolver estes problemas, foi desenvolvido um
ambiente virtual - Firefighter Command Training Virtual Environment (TAZAMA & CHRIS,
2003) - para auxiliar bombeiros em seus treinamentos. O ambiente permite a colaboração
entre seus participantes, que podem interagir de diversas formas entre si e com os objetos do
ambiente. Os bombeiros em treinamento podem utilizar ferramentas como pás e serras e
carregar e usar escadas para subir em telhados (FIG.3.5).
FIG.3.5 – Cenas do ambiente de treinamento de bombeiros.
51
O sistema utiliza-se de um algoritmo para descobrir o melhor caminho para os bombeiros
em treinamento – A* pathfinding (RUSSELL & NORVIG, 1995) – assim, ao iniciarem o
treinamento, eles já conhecem o caminho a percorrer e podem navegar com sucesso
contornando paredes e outros obstáculos.
Os objetos, a casa e as animações foram modelados no software 3D Studio Max
(3DSMAX, 2005) e o ambiente foi desenvolvido baseado na “Simple Virtual Environment
(SVE)” (KESSLER, BOWMAN & HODGES, 2000), uma biblioteca para a construção de
ambientes virtuais. A SVE foi desenvolvida para auxiliar o desenvolvimento experimental de
ambientes virtuais. Suas bibliotecas fornecem, sem nenhuma programação, uma aplicação
tipo fly-through, bem como um ambiente de trabalho para o desenvolvimento independente de
diferentes mecanismos para renderizar partes da cena, para responder a eventos e mudanças
no modelo do ambiente, para prover comportamentos dinâmicos para partes do ambiente e
para interfacear com novos dispositivos de entrada e saída.
3.4 omVR – A SAFETY TRAINING SYSTEM FOR A VIRTUAL REFINERY
O sistema omVR (HALLERet al, 1999) é um ambiente imersivo de treinamento da
operação de checagem diária de emissão de H
2
S numa refinaria. É possível simular aspectos
ambientais da refinaria (nível de emissão de H
2
S) para se treinar questões específicas e
situações que não seriam factíveis no mundo real devido a falta de recursos, de tempo, e ao
alto risco.
FIG.3.6 – Esquema completo do sistema omVR.
52
Para maior realismo do treinamento é utilizado um capacete de visualização (HMD –
Head Monted Display) e um dispositivo de tracking para o posicionamento das mãos
(FIG.3.6).
O servidor gráfico é um SGI e consta também de um servidor Windows NT que permite
ao treinador controlar a cena da refinaria através de um módulo de treinamento (FIG 3.7).
FIG.3.7 – Módulo do treinador no servidor NT.
FIG. 3.8 – Modelo da refinaria.
53
O modelo da refinaria foi dividido em dois : uma área operacional (refinaria) e uma sala
de ferramentas (tool-rom), onde ficam guardados os equipamentos (FIG 3.8). No início do
treinamento o usuário começa na sala de ferramentas (FIG 3.9), e deve escolher quais os
equipamentos que vai utilizar.
FIG.3.9 – Sala de ferramentas e área de operação.
Uma funcionalidade interessante que foi inserida neste trabalho é a possibilidade de
caminhar em uma direção estando olhando em outra direção (FIG 3.10).
FIG.3.10 – Direções distintas de observação e de deslocamento.
54
3.5 “WALKINSIDE”
FIG.3.11 - Ambiente virtual de uma plataforma de petróleo do Walkinside
O sistema comercial Walkinside (WALKINSIDE, 2004) é uma ferramenta de
visualização e simulação tridimensional de situações de alto risco em tempo real. Possui uma
tecnologia própria de detecção de colisões e de simulação de gravidade que oferece um nível
elevado de realismo, facilitando os treinamentos, além de ajudar os funcionários em
treinamento a se familiarizarem com a plataforma.
O Walkinside é útil para acompanhar projetos, para realizar simulações, para auxiliar
programas de manutenção e para treinamentos de segurança, todos acontecendo em tempo
real, multi-usuários, numa rede local (LAN) ou internet.
Apesar das facilidades apresentadas pelo sistema Walkinside, o programa é um sistema
comercial não aberto e as adaptações de código, necessárias a cada aplicação, podem se tornar
extensas e complexas.
55
3.6 COVET
O COVET (COVET, 2005) é um projeto patrocinado pela Newbridge Networks Co, hoje
parte da Alcatel, e criado pelo DISCOVER Laboratory, da Universidade de Ottawa, Canadá.
O programa foi desenvolvido para ser utilizado em treinamentos industriais em que os
usuários aprendem a efetuar a troca de uma placa defeituosa em um switch ATM. Os
movimentos executados pelo avatar no mundo virtual são os mesmos que devem ser
executados pelo usuário no mundo real para efetuar o reparo, conforme pode ser visto na FIG
3.12.
FIG. 3.12 – Avatar efetuando o reparo.
O programa utiliza uma câmera para capturar os movimentos da cabeça do usuário e
assim efetuar a rotação correspondente na cabeça do avatar . Utilizando um menu de opções é
possível interagir com o ambiente e através do chat o usuário pode conversar com os outros
usuários (FIG.3.13).
FIG. 3.13 – Tela do COVET.
56
Os comandos para movimentar o avatar, ou mesmo para mudar o ponto de visão, podem
ser dados também utilizando-se um sistema de reconhecimento de voz (Microsoft Speech
API). Os comandos são falados num microfone comum e o sistema responde de acordo.
O sistema utiliza a comunicação multicast como meio de troca de mensagens entre os
usuários, sendo o primeiro usuário, chamado de master, o responsável por criar o grupo
multicast no roteador e os demais participantes apenas assinantes do grupo. Cada usuário
envia suas mensagens para o IP do grupo e a rede multicast fica responsável pela distribuição
por todos os participantes do grupo. Existe também outra versão do sistema que utiliza-se da
comunicação unicast para IPv4 e IPv6.
3.7 O SISTEMA IDEAL
Realidade virtual pode ser considerada a junção de três conceitos básicos, que são a
imersão, a interação e o envolvimento. A idéia de imersão está ligada com o sentimento de se
estar dentro do ambiente; a idéia de interação está ligada com a capacidade do computador
detectar as ações do usuário e modificar instantaneamente o mundo virtual e as ações sobre
ele; a idéia de envolvimento, por sua vez, está ligada com o grau de motivação para o
engajamento de uma pessoa com determinada atividade. (KIRNER, 2005)
Uma aplicação de realidade virtual, direcionada para treinamento, além de estar focada
nos conceitos acima, deve observar outros fatores práticos, como exemplo a linguagem de
desenvolvimento, a plataforma utilizada e a modelagem dos objetos.
Para que um sistema se torne realmente eficiente e produza resultados práticos
satisfatórios é necessário que seja observado um conjunto de características. Dentre elas,
podemos destacar :
• Usar uma linguagem aberta que permite a portabilidade do programa gerado entre
diferentes sistemas operacionais, como a linguagem Java/Java3D, que foi utilizada
no COVET;
• Ser multi-usuário com colaboração, como no “Desktop virtual reality miner
training simulator”, “Firefighter command training virtual environment”,
“Walkinside” e no COVET;
57
• Ter funções adicionais que permitam maior nível de realismo, como um sistema de
detecção e tratamento de colisões e um simulador de efeito gravitacional, como os
presentes no sistema “Walkinside”;
• Suportar a utilização de mundos virtuais de dimensões ilimitadas;
• Ter liberdade de movimentação do avatar por todo o mundo virtual, como nos
sistemas “Walkinside”, “Desktop virtual reality miner training simulator”,
3.8 O SISTEMA PROPOSTO : ACAmPE
O ACAmPE é um ambiente virtual colaborativo desenvolvido para o treinamento de
técnicas de segurança em plataformas de petróleo. No ambiente, o usuário será representado
por um avatar, sendo permitido diversos usuários ingressarem juntos na plataforma virtual e
interagirem entre si e na plataforma, caracterizando um sistema multi-usuário com
colaboração. No desenvolvimento, foi utilizada a linguagem Java, juntamente com a API
Java3D, tornando o sistema portável para qualquer sistema operacional que possua a máquina
virtual Java instalada. Foram desenvolvidos sistemas de detecção e tratamento de colisões e
de simulação dos efeitos da gravidade, fazendo com que os usuários não consigam atravessar
as paredes, os objetos ou outros avatares e com que ele realmente caia, se por algum motivo
não estiver com os pés sobre o chão. O avatar pode se deslocar livremente por todo o mundo
virtual, que pode possuir dimensões ilimitadas, uma vez que o mesmo é composto de seções
de área quadrada, as quais são lidas/removidas automaticamente pelo programa.
O ACAmPE, que será detalhado no capítulo seguinte, foi desenvolvido baseado no
programa COVET e deste foram mantidos, os avatares, a estrutura do grafo de cena e o
sistema de comunicação.
58
3.9 QUADRO COMPARATIVO
TAB 3.1 - Quadro comparativo entre os sistemas.
SISTEMA LINGUAGEM OBJETOS MULTI-USUÁRIOS
SISTEMAS
DISPONÍVEIS
MUNDO
VIRTUAL
ACAmPE
JAVA / JAVA3D VRML e 3DS Sim, com colaboração Colisão, gravidade
Dividido
seções
contínuas
Miner
Training
Twilight3D´s Graphics
Engine
3DS Sim, com colaboração Não informado
1 sala de
ferramentas e a
mina
Virtual
TrainingPit
Delphi / C++ VRML/Open GL Sim HMD, luvas
Cabine do
avião
Firefighter
Simple Virtual
Environment
Não disponível Sim, com colaboração Pathfinding Cenário único
OmVR
Não disponível Não disponível Não HMD, luvas, tracking
1 sala de
ferramentas e a
plataforma
Walkinside
Não disponível Não disponível Sim, com colaboração Colisão, gravidade Cenário único
COVET
Java/Java3D VRML Sim, com colaboração
HMD, luvas, head-
tracking, reconhecimento
de voz
1 sala de
treinamento
com
equipamentos
59
4 ACAmPE : Ambiente virtual C
olaborativo para a Área de PEtróleo
O ACAmPE é um sistema de realidade virtual desenvolvido para o treinamento de
técnicas de segurança e ambientação em plataformas de petróleo, podendo ser estendido
facilmente para diversos outros tipos de treinamentos.
Os funcionários têm uma visão tridimensional da plataforma, podendo observar outros
funcionários, máquinas, e demais objetos. A configuração do sistema permite ao usuário
sentir-se como se estivesse dentro da plataforma real, o que lhe proporciona um maior
envolvimento e uma melhor ambientação.
Para o desenvolvimento do ambiente utilizou-se ferramentas que oferecem recursos
avançados, tais como interatividade, animações, simulações e mundos virtuais. Para a criação
do ambiente virtual utilizou-se Java e Java3D. Para modelar a plataforma utilizou-se o padrão
3DS, do software 3D Studio Max (3DS, 2005) e para descrever a geometria e o
comportamento dos avatares (FIG.4.1) utilizou-se a linguagem VRML - Virtual Reality
Modeling Language (VRML, 2005).
FIG.4.1 – Objetos VRML do avatar e 3DS da plataforma.
A descrição do mundo virtual e seus objetos tridimensionais, como a plataforma de
petróleo, criados com base no padrão 3DS, foram importados no Java3D como um grupo tipo
BranchGroup. Os avatares, por sua vez, foram exportados utilizando-se a linguagem VRML,
que é uma linguagem textual, independente da plataforma, e seus objetos podem ser
visualizados diretamente num navegador de internet com a utilização de um plug-in
apropriado, como o blaxxun Contact (BLAXXUN, 2005).
60
As classes especiais do Java3D que tornam possível importar tais objetos para o mundo
virtual são chamadas de loaders. Cada objeto VRML ou 3DS lido em Java3D é agrupado em
um BranchGroup, o qual pode ser inserido ou removido do mundo virtual.
Como já foi dito, o ACAmPE é um ambiente virtual colaborativo para treinamento de
técnicas de segurança e ambientação, a fim de otimizar as ações de funcionários nas situações
críticas reais (focos de incêndio, quebra de canalizações e de estruturas). Neste ambiente,
virtual o funcionário em treinamento será representado por um avatar, o qual responderá aos
seus comandos. É permitido a diversos usuários ingressarem juntos na plataforma virtual e
interagirem entre si e com a plataforma. Está a disposição dos usuários um sistema com
diversas câmeras que permite uma melhor navegação, um menu onde poderão ser escolhidos
os diversos tipos de treinamentos, cada qual com um tempo correspondente, e uma caixa de
diálogo – chat – para permitir a comunicação entre os participantes.
Na FIG.4.2, é apresentada a interface do sistema ACAmPE. Na lateral esquerda, estão o
cronômetro e seu botão de início, o menu, o painel de informações, e a caixa de mensagens.
Na direita, é posicionada a área de construção da cena 3D (canvas), onde será exibida a cena
gráfica 3D.
FIG.4.2 – Interface do sistema ACAmPE.
A FIG.4.3 mostra em detalhes o posicionamento de cada componente do sistema de
treinamento, entre eles o cronômetro, o menu com a opção “Treinamentos”, e o painel onde é
mostrada a descrição, os objetivos e o tempo associado ao treinamento escolhido.
CANVAS 3D
Cronômetro
Menu
Painel de
informações
Caixa de
mensagens
61
FIG.4.3 – Sistema de treinamento
.
O ACAmPE foi desenvolvido com base no programa COVET, da Universidade de
Ottawa (COVET, 2005), e deste foram mantidos os avatares, a estrutura do grafo de cena e o
sistema de comunicação.
O primeiro usuário a entrar no sistema é chamado de master e cria o grupo multicast na
rede e cada novo usuário que entra no sistema, apenas se inscreve no grupo. Neste momento,
ele também passa a enviar e receber mensagens e comandos para todo o grupo.
O usuário master é associado com o modelo masculino do avatar e, os demais usuários
slave são associados ao modelo feminino do avatar, como pode ser visto na FIG.4.4.
FIG.4.4 – Modelos dos avatares masculino e feminino.
Cada usuário tem em uma cópia do ambiente, não havendo um servidor que centralize e
distribua o ambiente para os clientes. A atualização do ambiente, então, é feita diretamente
entre os usuários, os quais enviam mensagens de texto com os comandos na rede multicast.
PAINEL COM A
DESCRIÇÃO E OS
OBJETIVOS DO
TREINAMENTO
MENU
TREINAMENTOS
CRONÔMETRO
62
As modificações ocorridas em cada plataforma virtual são enviadas para o grupo
multicast e, cada usuário, atualiza seu ambiente com as informações recebidas pela rede.
Desta forma, mantém-se a consistência entre os todos.
O envio de mensagens de texto com os comandos, ao invés de toda a cena gráfica, faz
com que o tráfego de dados na rede seja reduzido, permitindo o funcionamento mesmo em
redes sem garantias de: velocidade; transmissão; largura de banda, como a internet. Devido ao
tráfego baixo, a consistência do sistema também é beneficiada, fazendo com que todos os
participantes permaneçam com seus ambientes coerentes e atualizados, em tempo real, salvo
atrasos normais da rede.
Cada movimento que se deseje que o avatar execute deve ser feito através do envio do
comando equivalente para a rede multicast, de forma a se manter a consistência entre todos os
participantes. O envio é feito utilizando-se a classe csharing, uma thread responsável por
encaminhar os comandos para a rede e por “escutar” a rede para receber os comandos
enviados. Para cada movimento do avatar há um comando associado, o que padroniza os
movimentos e a comunicação.
TAB. 4.1 - Teclas de controle do avatar e suas descrições.
O sistema original de controle dos avatares foi reformulado e aprimorado para dar um
maior grau de liberdade de movimentos e com isso aumentar o realismo dos treinamentos. O
sistema original do programa COVET permite que o avatar se movimente apenas entre pontos
sensíveis pré-configurados, acionados pelo mouse do computador. Esta forma de controle
deixa a movimentação muito limitada, não permitindo que o usuário explore livremente o
ambiente. No sistema novo desenvolvido para o ACAmPE, o avatar se desloca por todo
63
mundo virtual, sem limitações ou restrições. A tabela TAB.4.1 relaciona as teclas de controle
do avatar e suas descrições.
Duas variáveis do tipo boolean controlam se as teclas “Caps-Lock” e “Shift” foram
pressionadas, mantendo o estado até que sejam pressionadas novamente.
Como pôde ser visto, o usuário consegue movimentar o avatar como se estivesse
presente na plataforma, conferindo um grande realismo ao ambiente.
Paralelamente ao sistema de controle pelo teclado, foi desenvolvido um servidor
multitarefa de comandos. O servidor se inscreve no grupo multicast, utilizando a mesma
identificação do avatar que irá controlar, ao mesmo tempo que aguarda conexão em uma porta
pré-configurada. Os programas-cliente ao se conectarem no servidor, podem enviar números,
os quais serão associados aos comandos de controle do avatar no servidor, sendo estes
enviados na rede multicast, de forma idêntica ao que acontece com o uso do teclado. Quando
o servidor recebe do cliente uma mensagem que não confere com nenhum dos seus comandos
conhecidos, ele simplesmente repassa a mensagem para o grupo.
O servidor de comandos permite que sejam criados programas de interface para diversos
dispositivos de hardware, como luvas de dados (Dataglove), joystick ou um phantom,
descritos no capítulo 2. Basta que o programa-cliente capture os movimentos destes
dispositivos e os converta para os códigos equivalentes. Torna-se possível, também, o uso de
mais de um dispositivo de hardware controlando o avatar, cada um comandando uma função
do mesmo. Teríamos, por exemplo, um joystick controlando a movimentação do avatar e um
phantom controlando especificamente a mão do avatar.
TAB.4.2 - Descrição dos nomes e tipos de câmeras disponíveis.
Associado ao novo sistema de movimentação, o sistema de câmeras e visualização do
ambiente foi modificado e adaptado à nova realidade de locomoção do avatar. No atual
sistema existe apenas uma câmera fixa – câmera superior – que dá uma visão de topo da
64
plataforma. As demais câmeras estão todas relacionadas e interligadas com o avatar,
acompanhando-o.
Na tabela TAB.4.2 segue uma descrição dos nomes e tipos de câmeras disponíveis e, na
FIG.4.5, a visão de cada câmera.
FIG.4.5 – Câmeras: a) superior; b) lateral; c) frontal; d) God eyes; e) frontal eyes; f) rat eyes
.
Com este conjunto de câmeras é possível ter uma visão ampla da região em volta do
avatar, facilitando o treinamento e a ambientação do usuário.
Todas as câmeras citadas estão associadas com o avatar, mais precisamente com a cabeça
do avatar, assim elas se movimentam juntamente com o avatar e se movimentam de acordo
com sua cabeça. Foi desenvolvido, então, um sistema de teclas para o controle lateral da
cabeça do avatar, e consequentemente, das câmeras. Através das teclas “<” e “>” é possível
movimentar a cabeça do avatar juntamente com a câmera escolhida, para esquerda e para
direita, respectivamente. É permitido girar para cada lado no máximo 90
o
, quando é enviada
uma mensagem ao usuário informando o limite alcançado. A tecla “/” executa o retorno
instantâneo da cabeça para frente.
A inserção destes controles permitiu que o avatar olhe ao redor de si, sem ter que virar
todo o corpo, e sem mudar sua direção de locomoção, sendo, então, possível caminhar numa
direção enquanto se olha para outra, um diferencial presente em poucos sistemas de
treinamentos (FIG.4.6).
65
FIG.4.6 – Visão frontal com o avatar olhando para o lado.
No menu do programa pode-se escolher qual treinamento se deseja executar, e ao ser
escolhido, aparece num painel a descrição do treinamento e seu objetivo. Cada treinamento
pode ter uma posição inicial diferente para cada avatar, e um tempo de execução associado.
Este tempo é marcado em um cronômetro situado na parte superior esquerda do programa, e é
controlado por uma thread, chamada clock, sendo executado, portanto, em paralelo com o
programa principal.
Na FIG.4.7, temos o código da thread clock.
FIG.4.7 – Código da thread de controle do cronômetro.
A fim de tornar o código aplicável a ambientes de qualquer tamanho, mesmo os de
dimensões muito grandes, o modelo da plataforma foi dividido em seções com bases
quadradas de lado igual a 13 metros, formando um total de 42 seções (FIG.4.8).
class clock extends JPanel implements Runnable {
public void run() {
Thread antiga = Thread.currentThread();
Thread atual = Thread.currentThread();
while (antiga == atual) {
try {
if (contagem) {
antiga.sleep(1000);
if (relogio>0) relogio -= 1;
mostratempo();
} }
catch (InterruptedException e){} } } }
66
FIG.4.8 – Divisão da plataforma em 42 seções.
As seções foram orientadas e posicionadas segundo o plano XZ, conforme a FIG 4.9.
Apenas o conjunto das nove seções em torno do avatar, incluindo a que ele se encontra,
são lidas e exibidas ao usuário ao mesmo tempo, como visto na FIG.4.10. Foi desenvolvido
um sistema que controla a leitura/remoção das seções, baseado nas coordenadas do avatar, de
forma a inserir/remover seções, em tempo de execução, da cena ativa e compilada. De acordo
com a movimentação do usuário, quando este muda de seção, novas seções são lidas e
exibidas enquanto que outras são removidas, como pode ser visto na FIG.4.11.
Em Java3D apenas nós do tipo BranchGoup podem ser inseridos ou removidos de uma
cena gráfica compilada e ativa. Para a remoção do nó do grafo de cena é necessário ainda
configurar tal capacidade do nó, o que é feito usando-se a função
setCapability(BranchGroup.ALLOW_DETACH).
FIG.4.9 – Posicionamento das seções
67
FIG.4.10 – Sistema de seções.
Foi criada, então, uma nova classe chamada de LeSecao, responsável por verificar a
posição do avatar e inserir e remover as seções da cena gráfica de acordo com o seu
movimento. Para cada seção lida é criado um novo BranchGroup, com suas características
inicializadas no momento de sua criação, sendo, posteriormente, inserido na cena gráfica. Este
processo de criação é dinâmico e ocorre em tempo de execução.
FIG.11 – Sequência com a câmera superior: leitura e remoção das seções.
O processo de leitura em disco das seções acabava por atrapalhar o processamento
principal do programa causando interrupções na renderização da cena e comprometendo o
desempenho de toda a aplicação. Como a seção em que o avatar está e mais as 8 seções em
torno dele já estão lidas, não há problema em haver um pequeno atraso na exibição das novas
seções, contudo não pode haver nenhum tipo de retardo na movimentação do avatar, a fim de
se manter a sensação de imersão do usuário. Para resolver este problema, as funções de leitura
e remoção das seções foram inseridas numa thread, que a cada 300ms obtém o
posicionamento do avatar e calcula quais seções devem ser lidas e removidas. O
processamento é feito em paralelo com o programa principal, sem que haja queda no
desempenho da renderização.
(1) (2)
(3)
(4)
68
No código da função que remove as seções, utiliza-se uma variável tipo boolean para
verificar se o cubo em questão já foi lido ou não, antes de removê-lo.
As seções foram obtidas seccionando o objeto 3DS da plataforma inteira, assim, as seções
criadas carregam consigo seu posicionamento relacional. Desta forma, ao se carregar as
seções, elas automaticamente retornam ao seu posicionamento original remontando a
plataforma.
Inicialmente havia duas possibilidades de se desenvolver o sistema de leitura/remoção
das seções: a que foi adotada no projeto que se utiliza das coordenadas do avatar para saber se
houve mudança de seção; a que foi rejeitada utilizaria sensores invisíveis tipo “caixa” que
envolveriam cada seção e neles estariam associados eventos de detecção de colisão, de forma
que, quando o avatar passasse por uma parede da “caixa”, seria gerada uma interrupção
informando a colisão a qual poderia ser devidamente tratada. Como cada seção teria sua
própria “caixa”, quando o avatar saísse de uma seção e entrasse numa seção vizinha, teríamos
duas interrupções sendo geradas – a de saída e a de entrada – e assim seria possível saber para
qual seção o avatar se moveu e quais cubos devem ser lidos e removidos. Este sistema,
aparentemente, seria bem mais simples e mais genérico, pois a caixa sensora seria lida
juntamente com a seção e teria um tamanho fixo – o tamanho das seções – e seria necessário
apenas desenvolver uma única rotina de tratamento das colisões contudo, um pequeno mas
complexo problema impediu que esta opção fosse escolhida. Como foi dito, cada seção teria
sua caixa sensora envolvendo toda a seção, e esta caixa seria sensível a colisões, colisões estas
que são de quaisquer espécies, não necessariamente apenas com os avatares. Deste modo,
estando as caixas sensoras entrando em colisão constante com as seções vizinhas, impediriam,
assim, que outras colisões, inclusive com os avatares, fossem corretamente reportadas,
deixando o sistema de inserção/remoção de seções inoperante. Para impedir que as seções
fossem objetos que pudessem colidir com a caixa sensora era necessário informar ao Java3D
que estes objetos – as seções – não são passíveis de colisão através do comando
.setCollidable(false). Isto foi feito e deu resultado positivo, no que diz respeito ao sistema de
mudança de cubos, pois com este comando desabilitamos qualquer tipo de colisão com as
seções, desligando também o funcionamento do sistema de tratamento de colisão do avatar
com a seção que impede o avatar de “atravessar” as paredes e objetos da seção, como será
visto à frente. Desta forma, não foi encontrada nenhuma solução viável para se utilizar os
sensores de colisão no sistema de mudança de seções, motivo pelo qual esta opção foi
descartada.
69
Este tipo de sistema com seções torna o código aplicável a ambientes de quaisquer
dimensões, mesmo os muito grandes, pois o programa sempre trata apenas um conjunto de até
nove seções a cada instante de tempo. Um cenário composto, por exemplo, de uma cidade
inteira dividida em seções resultaria em execução normal do sistema, sem necessidade de
nenhum tipo de mudança, tampouco haveria uma queda de desempenho de processamento, de
leitura de disco ou de congestionamento na rede, já que as mesmas nove seções seriam
tratadas a cada instante.
Para um maior realismo e imersão do usuário foi desenvolvido um código próprio para o
tratamento de colisões, utilizando-se o sistema inerente do Java3D de detecção de colisão.
Java3D assinala apenas que houve algum tipo de colisão, mas não há nenhuma opção interna
para o tratamento da colisão. Sem o devido tratamento, não há nada que impeça o avatar de
atravessar os objetos, as paredes e até mesmo outros avatares. É necessário, portanto, que o
sistema possua rotinas de tratamento de colisões.
A classe que executa a detecção de colisão estende a classe behavior e é inserido no grafo
de cena por referência. Para se criar uma subclasse de Behavior deve-se :
1. Implementar, pelo menos, um construtor para a subclasse que armazene uma
referência para o objeto que será alterado;
2. Sobreescrever o método inicialization () especificando um critério para começar a
interação;
3. Sobreescrever o método processStimulus (), responsável pela execução da ação.
Neste nosso caso, devemos especificar como critério aqueles relacionados com colisão e,
no método que é executado, quando os critérios são satisfeitos, devemos alterar o estado de
uma variável do tipo boolean, chamada inCollision, associada ao estado da colisão. Após a
execução do método é necessário reinicializar os critérios de colisão. Esta variável será
utilizada pelo programa como um sinalizador de colisão. Por se tratar de uma variável do tipo
Private construímos uma função do tipo public boolean, chamada getInColl(), que retorna o
estado de inCollision, e que pode ser acessada pelas outras classes do programa. Para que se
possa saber com exatidão quando o avatar entra e quando ele sai da colisão, são utilizados
dois critérios de detecção: quando entra em colisão, usa-se o WakeupOnCollisionEntry;
quando sai, usa-se o WakeupOnCollisionExit.
Definidos os critérios iniciais, é necessário definir também como Java3D enxergará o
objeto para detectar a colisão. Java3D pode utilizar a própria geometria do objeto para checar
70
se houve colisão, como pode utilizar apenas a envoltória – bounds – dos objetos, conforme a
FIG.4.12.
Se definirmos o uso da envoltória – USE_BOUNDS – Java3D irá considerar como
superfície de colisão um paralelepípedo que envolve todo o objeto, tornando o processamento
mais simples e rápido porém a colisão se torna muito imprecisa. Utilizando a própria
geometria do objeto – USE_GEOMETRY – Java3D irá verificar, inicialmente, a envoltória do
objeto, e se esta estiver em colisão, testará todos os polígonos do objeto para verificar se
algum deles está colidindo.
FIG.4.12 – Tipos de superfícies de colisão do Java3D.
Como se pode notar, este processo é mais completo e complexo que o anterior,
reportando com muito mais precisão as colisões, porém exigindo muito mais processamento.
No nosso sistema, necessitamos de precisão, pois os avatares se deslocam por toda a
plataforma e podem colidir entre si, com as paredes e com os objetos.
Na FIG.4.13 é mostrado o código da classe que detecta a colisão.
:
FIG.4.13 – Código da classe CollisionDetector.
Seção
USE_BOUNDS
USE_GEOMETRY
public class CollisionDetector extends Behavior {
private boolean inCollision;
private Node no;
private String avatar;
private WakeupOnCollisionEntry wEnter;
private WakeupOnCollisionExit wExit;
private int speedHint = wEnter.USE_GEOMETRY;
private int speedHintExit = wExit.USE_GEOMETRY;
public CollisionDetector(Node s, String avat) {
no = s;
avatar = avat;
inCollision = false; }
public void initialize() {
wEnter = new WakeupOnCollisionEntry(no, speedHint);
wExit = new WakeupOnCollisionExit(no, speedHintExit);
wakeupOn(wEnter); }
public boolean getInColl(){
return inCollision; }
public void processStimulus(Enumeration criteria) {
inCollision = !inCollision;
if (inCollision) {
System.out.println ("Support Entrando em Colisao!");
wakeupOn(wExit);
} else {
System.out.println ("Support Saindo da Colisao!");
wakeupOn(wEnter);
} }}
71
A propriedade de colidir fica relacionada apenas com os objetos que se movem, com os
avatares, pois são eles que podem provocar as colisões. A plataforma e demais objetos
estáticos são ditos passíveis de sofrer colisões – setCollidable(true) – e serão analisados
segundo sua geometria – USE_GEOMETRY.
FIG.4.14 – Cilindro sensor do sistema de colisão.
A propriedade de colisão – Behavior – pode estar associada apenas a elementos gráficos
primitivos do Java3D, como Box, Sphere, Cylinder, ou a qualquer outro do tipo Shape3D,
sendo então necessário envolver os avatares com pelo menos um destes objetos a fim de
torná-los sensores de colisão. No ACAmPE foi utilizado um único cilindro transparente
(FIG.4.14) que envolve o corpo do avatar. Quando algum outro objeto, de qualquer tipo, toca
este cilindro a rotina de colisão é acionada, alterando a variável inCollision. A partir daí, o
sistema que controla a movimentação dos avatares utiliza a função getInColl() para obter o
estado da colisão, e assim não mais permitir movimentação naquela direção, até a saída do
estado da colisão. Na FIG.4.15, vemos o trecho do código do sistema de controle de
movimentação dos avatares que checa a colisão.
FIG.4.15 – Trecho do código do controle de movimentação.
public void keyPressed(KeyEvent e) {
int keycode = e.getKeyCode();
if (!(makescene.getinColl())) {
if (keycode== ....
72
A fim de tornar o ambiente mais real, foi desenvolvido um sistema que emula os efeitos
da gravidade, utilizando os mesmos princípios do sistema de tratamento de colisão. Com a
gravidade, o usuário precisa se preocupar para não cair dos andares da plataforma, bem como
cair da plataforma no mar.
FIG. 4.17 – Esfera sensora do sistema de gravidade
O sistema foi desenvolvido utilizando um sensor esférico transparente – Sphere – na
altura dos pés do avatar, e uma rotina de colisão foi associada a ele, de forma que é reportada
a colisão deste sensor com o chão. Através de uma rotina – thread – no programa principal
chamada gravidade, ficamos checando a cada 100ms se o sensor dos pés do avatar continua
em colisão. Em caso afirmativo nada é feito, pois significa que o avatar está com os pés no
class gravidade implements Runnable {
createSceneGraph makescene;
cSharing share;
gravidade (createSceneGraph makescene, cSharing share) {
this.makescene = makescene;
this.share = share; }
public void run() {
Thread antiga = Thread.currentThread();
Thread atual = Thread.currentThread();
while (antiga == atual) {
try {
if (!(makescene.getCollChao())) share.sendmainviewcommand("Cai");
antiga.sleep (100); }
catch (InterruptedException e){} }}}
FIG. 4.16. – Código da Thread gravidade.
73
chão, caso contrário é enviado o comando para o avatar cair. Na FIG.4.16, temos o código da
Thread gravidade e na FIG.4.17 vemos em destaque o sensor do sistema de gravidade.
O envio do comando “cai” seguirá para todos os participantes e fará com que o respectivo
avatar caia, ou seja, tenha o valor da coordenada Y diminuído até que o sensor dos pés entre
novamente em colisão, indicando que o avatar está novamente em contato com o chão ou que
caiu na água.
Temos na FIG.4.18 o trecho do código da função cai().
FIG.4.18 – Trecho do código da função cai ().
public void cai () {
if (fcd!=-100000.0f) {
System.out.println ("Caindo..." + pontoa);
pontoa.y = pontoa.y - 0.009f;
gotopos (0,"");
}
}
74
5 CONCLUSÃO
5.1 AVALIAÇÃO DO TRABALHO
Neste trabalho, foi apresentado um protótipo de um ambiente virtual colaborativo
chamado ACAmPE – Ambiente virtual Colaborativo para a Área de PEtróleo. É o primeiro
trabalho da área de Realidade Virtual e Ambientes Virtuais Colaborativos do Instituto Militar
de Engenharia desenvolvido para treinamento de técnicas de segurança, em especial para a
área de petróleo.
Para o desenvolvimento deste protótipo, foram estudados diversos tipos de ambientes
virtuais, sendo que nem todos especificamente para treinamento ou relacionados a área de
petróleo.
Como base, foi adotado o progama COVET (COVET, 2005), desenvolvido na
universidade de Ottawa. A partir deste programa, pôde-se desenvolver todos os
procedimentos relacionados à área de petróleo, bem como uma série de novas
funcionalidades, relacionados no ítem 5.2.
O foco dado a este trabalho foi o desenvolvimento de um ambiente o mais realístico
possível, de forma a aumentar ao máximo a sensação de imersão do usuário. Num sistema de
treinamento de técnicas de segurança – ao contrário de outros ambientes virtuais como os
voltados para o entretenimento, para o comércio eletrônico ou para a educação – o nível de
imersão deve ser o mais alto possível, a fim de facilitar a ambientação do usuário e aumentar
a precisão dos seus movimentos nas situações de emergência que, no caso real podem, muitas
vezes, colocar a vida do usuário em risco.
5.2 CARACTERÍSTICAS
O ACAmPE é um sistema de realidade virtual com a finalidade de se efetuar
treinamentos de segurança, o qual pode ser estendido facilmente para diversos outros tipos de
75
treinamentos. Neste tipo de ambiente, o usuário está imerso no ambiente virtual tornando o
treinamento muito mais próximo do real.
Algumas novas tecnologias foram implementadas no ACAmPE tornando-o um ambiente
virtual bastante complexo, com alto nível de interação e imersão.
O ACAmPE foi desenvolvido dividindo-se a plataforma (mundo virtual) em seções de
base quadrada, tornando assim o sistema independente do tamanho do mundo virtual. Esta é
uma forma de generalização importante do ACAmPE que permite que o sistema possa ser
utilizado com mundos virtuais de dimensões ilimitadas e, para que não haja ônus no
desempenho, a leitura e remoção dos cubos são feitas em uma thread específica para isso.
No ACAmPE, os avatares podem se movimentar livremente com o uso do teclado por
toda a plataforma. Eles podem andar, andar lateralmente, correr, correr lateralmente, subir e
descer escadas, pular pra cima, pular pra frente, rotacionar a cabeça e observar o ambiente,
bem como se deslocar em uma direção, tendo a visão em outra direção.
Foi desenvolvido um sistema de tratamento de colisões, o que permite aos avatares se
movimentarem sem atravessar os objetos, as paredes e os outros avatares, aumentando o nível
de realismo e a sensação de imersão, fundamentais neste tipo de aplicação.
Um sistema particular de tratamento de colisão foi desenvolvido para simular o efeito da
gravidade, utilizando-se um sensor nos pés dos avatares. A possibilidade de se ter gravidade
num ambiente virtual traz novas perspectivas, permitindo um nível de realismo cada vez
maior.
Associado à liberdade de movimentação e ao realismo proporcionado pelos sistemas de
tratamento de colisão foi desenvolvido um conjunto de câmeras que envolve o avatar,
permitindo diversos tipos diferentes de visão do ambiente no qual está interagindo.
Existem um total de cinco câmeras distribuídas em torno do avatar e estas se deslocam
juntamente com ele. Adicionalmente, existe uma câmera superior que mostra do alto todas as
seções lidas que, juntas, possibilitam uma visão completa do ambiente, e do avatar imerso
nele. Há também um controle pelo teclado independente para as câmeras, o que permite
rotacionar a câmera, fazendo o avatar olhar para os lados, mesmo enquanto caminha em outra
direção.
Os resultados obtidos ao longo do trabalho foram apresentados e publicados no
Symposium on Virtual Reality – SVR2004 – Workshop de Teses e Dissertações, bem como
servem de base para estudo no desenvolvimento de um projeto comercial pela empresa IESA
76
- Projetos, Equipamentos e Montagens S/A, e serão apresentados como artigo completo em
eventos futuros.
5.3 TRABALHOS FUTUROS
É possível, em implementações futuras do ACAmPE, disponibilizar novos recursos,
visando: o melhor desempenho do sistema; maior nível de realismo e imersão do usuário; uma
maior aproximação com os treinamentos reais de uma plataforma de petróleo.
Uma versão imersiva, em um CAVE (CRUZ-NEIRA et al, 2005), também poderá ser
implementada.
A seguir, serão analisadas as perspectivas imediatas para novas implementações.
5.3.1 SISTEMA DE LEITURA E REMOÇÃO DAS SEÇÕES
O sistema atual de remoção das seções foi desenvolvido voltado para o projeto GIGA, da
Rede Nacional de Pesquisa – RNP (GIGA-RNP, 2005), onde é requerido um fluxo intenso de
dados na rede a fim de testá-la. Desta forma, as seções descartadas, além de retiradas da cena
gráfica, são desconsideradas para futuras leituras, necessitando serem carregadas novamente
de um servidor. Este tipo de implementação não é o mais adequado quando estamos
trabalhando numa rede sem garantias de: velocidade; transmissão; largura de banda, como a
internet. Sendo assim, é necessário adaptar o sistema para apenas remover a seção da cena,
sem necessariamente retirá-la da memória, permitindo que, caso a seção precise novamente
ser exibida ao usuário, baste apenas inserí-la novamente na cena gráfica. Na prática, seria
necessário o uso de um buffer que guardaria apenas os últimos cubos lidos, e o seu tamanho
seria definido pela relação entre a quantidade de memória total da máquina e a quantidade de
memória livre necessária para o bom desempenho do sistema. Teríamos com isso uma
considerável diminuição do fluxo de dados na rede, principalmente se o avatar se movimentar
repetidamente nas mesmas seções.
77
5.3.2 LOCALES COM GRUPOS MULTICAST
No sistema atual, temos apenas um grupo multicast para toda a plataforma, que é
utilizado por todos os participantes e, desta forma, não há como filtrar as mensagens
recebidas. O que se deseja implementar é um sistema com Locales (BARRUS, WATERS &
ANDERSON, 1996). Cada seção, por exemplo, tem um IP multicast próprio, de forma que
cada usuário receberia apenas as mensagens de atualização do seu próprio locale, e dos
locales vizinhos disponíveis e já apresentados, pois apenas estas seriam mensagens
importantes para aquele usuário. Quando o avatar mudar de locale, ele recebe um pacote de
mensagens para atualizar sua cena gráfica com a situação do ambiente, o posicionamento dos
demais avatares e objetos, mantendo a consistência do sistema. Este tipo de implementação
sobrecarrega menos a rede, que teria um fluxo de dados reduzido, e a estação do usuário, que
passa a processar menos mensagens, permitindo assim um melhor aproveitamento da rede e
do processamento da máquina.
5.3.3 SISTEMAS EXTERNOS DE DETECÇÃO DE COLISÃO
Devido ao fato do sistema de detecção de colisão do java3D ainda ser muito simples, ele
é impreciso e com alto custo de processamento. Uma solução para isso é utilizar bibliotecas
C++ (UNC, 2005) externas ao java3d para sistema de detecção de colisão. Com os algoritmos
destas bibliotecas, consegue-se melhor desempenho, mesmo quando se utilizam objetos de
grandes dimensões, ou objetos com alto nível de detalhe.
Será necessário um estudo preliminar para se determinar a relação custo/benefício e se
verificar a real necessidade e viabilidade desta proposta.
78
5.3.4 ARQUIVOS EXTERNOS COM OS TREINAMENTOS
No sistema atual, os treinamentos disponíveis foram inseridos junto ao código, antes da
compilação, ficando o sistema limitado apenas a eles. Para tornar o sistema mais dinâmico e
de atualização mais fácil, as configurações dos treinamentos deverão estar em um arquivo
externo, o qual será lido em tempo de execução. Novos treinamentos poderão ser incluídos
apenas inserindo seus dados neste arquivo. Ajustes ou alterações nos treinamentos poderão ser
feitos apenas editando o arquivo de configuração, ou através de uma ferramenta de autoria.
5.3.5 POSSIBILIDADE DE ESCOLHA DO AVATAR
Da mesma forma que, ao entrar no sistema, dizemos se estaremos atuando como o master
ou como um slave, é interessante termos a possibilidade de passar como parâmetro o tipo de
avatar que nos representará no mundo virtual. Este tipo de escolha permite tornar claro no
ambiente virtual a função de cada usuário no sistema. Por exemplo, o usuário bombeiro
deverá ser representado por uma avatar bombeiro, um operário como um avatar operário, o
engenheiro como um avatar engenheiro e assim sucessivamente. Isso torna o sistema mais
real, contribuindo bastante para o treinamento dos usuários.
Esta escolha do tipo do avatar seria passada como um parâmetro tipo String para todos os
usuários que, ao inserir o novo membro, fariam a devida associação.
5.3.6 USO DE MENSAGENS DE INICIALIZAÇÃO
O sistema atual não realiza nenhuma troca de mensagem de inicialização quando um novo
usuário entra. Assim, qualquer ação no mundo virtual só deve ser efetuada quando todos
entrarem no sistema, a fim de evitar um erro de consistência. Essa limitação torna o sistema
pouco prático, restrigindo seu uso.
79
A fim de contornar este problema, cada usuário, ao entrar no sistema, deverá receber um
pacote de mensagens com as informações pertinentes ao estado do ambiente naquele
momento, de forma semelhante, como já foi explicado anteriormente, ao que acontece quando
o avatar troca de locale. A partir deste ponto, ele começa a receber e a enviar as mensagens de
atualização normalmente como os demais usuários já presentes no ambiente.
5.3.7 CRIAÇÃO DE NOVOS COMPORTAMENTOS PARA OS AVATARES
Um dos fatores que fazem com que o sistema se torne mais real é uma perfeita
movimentação dos avatares, e para isso é necessário que sejam criados para eles novos
comportamentos (behaviors).
Todas as ações desempenhadas pelos avatares necessitam de um comportamento
associado. Assim, para que o avatar possa correr, sentar, pegar objetos, etc, é necessário que
sejam criados arquivos VRML com estes comportamentos.
80
REFERÊNCIAS BIBLIOGRÁFICAS
3DS - 3D Studio Max. Disponível: http://www4.discreet.com/3dsmax/ [capturado em 22 de
mar. de 2005].
BARRUS, J.W., WATERS, R.C., ANDERSON, D.B.. Locales and beacons: efficient and
precise support for large multi-user virtual environments. Mitsubishi Electric
Research Laboratory: 1996.
BIERBAUM, A., JUST, C., HARTLING, P., MEINERT, K., BAKER, A., CRUZ-NEIRA,
C.. VR Juggler: a virtual platform for virtual reality application development. IEEE
VR 2001 Proceedings. Yokohama. Japan: 2001.
BLAXXUN Contact. Disponível: http://www.blaxxun.com/en/products/contact/index.html
[capturado em 07 de maio de 2005]
BLUEMEL, E., HINTZE, A., SCHULZ, T., SCHUMANN, M., STUERING, S.. Virtual
environments for the training of maintenance and service tasks. Proceedings of the
2003 Winter Simulation Conference: 2003.
BRUTZMAN, D.. The virtual reality modeling language and Java. Communication of the
ACM. v.41. n.6. jun. 1998.
CADORIN, E.A., OLIVEIRA, J. C.. ACAmPE – um ambiente virtual colaborativo para a
área de petróleo. Symposium on Virtual Reality 2004. São Paulo. SP. Brasil. 2004.
CARDOSO, A.. VRML – A web em 3D. Symposium on Virtual Reality 2003. Porto Alegre.
SC. Brasil. 2003.
COUCH J.. Collision detection system. Disponível:
http://www.j3d.org/implementation/collision.html [capturado em 22 de maio de 2005]
COVET – Collaborative virtual environment - Disponível:
http://woodworm.cs.uml.edu/~rprice/ep/hosseini-demo/ [capturado em 05 de maio de
2005].
CRUZ-NEIRA, C.. Computational humanities: the new challenge for VR. Universidade
do Estado de Iowa. IEEE Computer Society. maio/jun. 2003.
81
CRUZ-NEIRA, C., SANDIN, D.J., DEFANTI, T.A.. Surround-screen projection-based
virtual reality: the design and implementation of the CAVE. Eletronic Visualization
Laboratory (EVL). The University of Illinois at Chicago. Siggraph: 1993. Disponível :
http://www.cs.utah.edu/~thompson/vissim-seminar/on-line/CruzNeiraSig93.pdf
[capturado em 18 de mar. de 2005]
CRUZ-NEIRA, C., SANDIN, D.J., DEFANTI, T.A., KEYON, R.V., HART, J.C.. The
CAVE audio visual experience automatic virtual environment. Sigggraph.
Communication of the ACM. v.35. n.6. jun. 1992.
DIRECTX - Microsoft DirectX. Disponível: http://www.microsoft.com/directx/ [capturado
em 09 de maio de 2005]
EDUARDO, V.. Protótipo de um ambiente virtual distribuído multiusuário. 2001. 121 f.
Trabalho de conclusão de curso submetido à Universidade Regional de Blumenau para
obtenção dos créditos na disciplina com nome equivalente no curso de ciências da
computação – Bacharelado.
ELMQVIST, N.. Practicalities of Game Development. Disponível:
http://www.cs.chalmers.se/Cs/Grundutb/iss/kurser/simul/doc/lecture-2.pdf [capturado
em 24 de jul. de 2005].
FORNEY, G.P., MADRZYKOWSKI, D., McGRATTAN, K.B.. Understanding Fire and
Smoke Flow Through Modeling and Visualization. National Institute of Standards
and Technology. IEEE Computer Society. jul./ago. 2003.
GARAU, M., SLATER, M., VINAYAGAMOORTHY, V., BROGNI, A., STEED, A.,
SASSE M. A.. The impact of avatar realism and eye gaza control on perceived
quality of communication in a shared immersive virtual environment. Department
of Computer Science. University College London (UCL). Gower St.. Londres. 2003.
GARCIA, F.L.S.,CAMARGO, F.D.,LORENZATO, L.M.,VASCONCELOS, M.. Virtual
TrainingPit: um sistema de treinamento virtual de pilotos de aeronaves. 5th SBC
Symposium on Virtual Reality. Fortaleza, Brasil. 2002.
GIGA-RNP - Projeto Rede Giga. Rede Nacional de Pesquisa. Disponível:
http://www.rnp.br/editais/giga200302.html [capturado em 18 de mar. de 2005].
82
GOUVEIA, L.B.. Ambientes virtuais colaborativos: a procura de formas alternativas de
interacção. Revista Politécnica. n.2: 2000. Edições da Cooperativa de Ensino
Politécnico. Porto. Portugal. ISSN 0874-8799.
HALLER M., KURKA G., VOLKERT J., WAGNER R.. omVR: a safety training system
for a virtual refinery. ISMCR 99. Topical Workshop on Virtual Reality and Advanced
Human-Robot Systems. Vol.X. Tokio. Japão. pp. 291-298: 1999.
IMPLEMENTING Collision Avoidance in Java 3D. J3D.ORG. Disponível:
http://www.j3d.org/tutorials/collision/collision.html [capturado em 22 de maio de 2005]
IMPLEMENTING Terrain Following. J3D.ORG. Disponível:
http://www.j3d.org/tutorials/collision/setup.html [capturado em 22 de maio de 2005]
Introdução ao mundo Java. Fundão da Computação. Disponível:
http://www2.fundao.pro.br/articles.asp?cod=58 [capturado em 27 de jul. de 2005].
JAVA3D – API JAVA3D. Disponível: https://java3d.dev.java.net [capturado em 24 de jul. de
2005].
JÚNIOR, P. J.. Introdução ao Java. Núcleo de Educação à Distância. Universidade de São
Francisco: 1999.
KESSLER D., BOWMAN D., HODGES L.. The simple virtual environment library: an
extensible framework for building VE applications. Presence: Teleoperators and
Virtual Environments: 2000. pp. 187-208.
KIRNER, C.. Sistemas de realidade virtual. Grupo de Pesquisa em Realidade Virtual.
Departamento de Computação. Universidade Federal de São Carlos(UFSCar).
Disponível: http://www.dc.ufscar.br/~grv/tutrv/tutrv.htm [capturado 23 de mar. de 2005]
LIN M. C.. Efficient collision detection for animation and robotics. Department of
Electrical Engineering and Computer Science. University of California. Berkeley.
Berkeley. CA. 1993.
LVR - Laboratório de realidade virtual da Universidade Federal de Santa Catarina
(UFSC). Disponível : http://www.lrv.ufsc.br [capturado em 21 de mar. de 2005].
83
MANSSOURL, I.H.. Introdução ao Java3D. Faculdade de Informática. Pontifícia
Universidade Católica do Rio Grande do Sul (PUCRS). Porto Alegre. RS. 2003.
MENGE, F.. Curso de Java – Módulo II: Swing. Centro de Computação. Unicamp.
Campinas. São Paulo. 2002.
OLIVEIRA J.C., HOSSEINI, M., SHIRMOHAMMADI S.. Java multimedia
telecollaboration. IEEE Computer Society. jul./set. 2003.
OLIVEIRA, J.C., SHEN, X., GEORGANAS, N.. Collaborative virtual environment for
industrial training and e-commerce. Multimedia Communications Research
Laboratory. School of Information Technology and Engineering. University of Ottawa.
Canadá.
OLIVEIRA J.C., SHIRMOHAMMADI S., GEORGANAS, N.. Collaborative virtual
environment standards: a performance evaluation. Multimedia Communications
Research Laboratory. School of Information Technology and Engineering. University of
Ottawa. Canadá.
OPENGL architecture review board. Disponível: http://www.opengl.org [capturado 09 de
maio de 2005].
OPENINVENTOR – Open inventor. Disponível: http://oss.sgi.com/projects/inventor/
[capturado 17 de maio de 2005].
PAIR, J., NEUMANN, U., PIEPOL, D., SWARTOUT, D.. FlatWorld: combining
hollywood set-design techniques with VR. University of Southern California. IEEE
Computer Society. jan./fev. 2003.
PEREIRA, A. T. C., TISSIANI, G., BOCIANOSKI, I.. Design de interfaces para ambientes
virtuais: como obter Usabilidade em 3D. In: IV CONGRESSO IBERO-AMERICANO
DE GRÁFICA DIGITAL, 2000, RIO DE JANEIRO. CONSTRUINDO O ESPAÇO
DIGITAL. Rio de Janeiro. José Ripper Kós, Adriana Simeone Barbosa, Rodrigo Cury
Paraizo, 2000. v. 1. p. cd-cd.
PESCE, M.. VRML and Java: a marriage made in heaven. Disponível:
http://developer.netscape.com/viewsource/pesce_vrml2/pesce_vrml2.html [capturado 10
de maio de 2004]
84
PINHO, M. S.. Manipulação simultânea de objetos em ambientes virtuais imersivos.
2002. Tese (Doutorado em Ciência da Computação) – Universidade Federal do Rio
Grande do Sul, Instituto de Informática.
RMAV - Endereçamento multicast e aplicações multimídia distribuídas na RMAV-FLN.
Boletim bimestral sobre tecnologia de redes produzido e publicado pela RNP – Rede
Nacional de Ensino e Pesquisa. v.4, n.4, jul. 2000.
RODRIGUES S. G.. ADVICE – Ambiente virtual colaborativo para o ensino a distância.
2004. 137 p. Dissertação (Mestrado em Ciência da Computação) – Instituto Militar de
Engenharia, Departamento de Engenharia de Sistemas. Rio de Janeiro. 2004.
RUSSELL J. S., NORVIG P.. Artificial intelligence: a modern approach. Pretience Hall.
New York. 1995.
SELMAN, D.. Java3D programming. Edição Reimpressa. Manning Publication. 2002.
400p. ISBN 1930110359.
SMALLVR – A Simple toolkit for VR application development. Disponível:
http://grv.inf.pucrs.br/Pagina/SmallVR/Tutorial/CursoRV.html [capturado em 18 de
maio de 2005]
SOWIZRAL, H.A., DEERING, M.F.. The Java 3D API and virtual reality. Sun
Microsystems. IEEE Computer Society. maio/jun. 1999.
SUN Microsystems. Disponível: http://www.java.sun.com [capturado em 14 de jan. de
2005].
TAZAMA U. St. J, CHRIS D. S.. Firefighter command training virtual environment.
TAPLA: 2003.
TIMOTHY, J.O., MARC, T.F., TODD, M.R.. Desktop virtual reality miner training
simulator. NIOSH, Spokane Research Laboratory, Spokane, WA, USA. Disponível:
http://www.cdc.gov/niosh/mining/pubs/pdfs/dvrmt.pdf [capturado em 24 de jul. de 2005]
TWILIGHT3D´s 3D graphics engine. Disponível:
http://www.twilight3d.com/modules.php?op=modload&name=News&file=article&sid=1
&mode=thread&order=0 [capturado em 21 de mar. de 2005]
85
UNC collide research group. Collision Detection – Proximity Query Packages. Disponível :
http://www.cs.unc.edu/~geom/collide/packages.shtml [capturado em 18 de mar. de
2005].
VRML - International standard ISO/IED. Disponível:
http://www.web3d.org/x3d/specifications/vrml/ [capturado em 16 de fev. de 2005].
X3D. Disponível: http://www.web3d.org/x3d/ [capturado em 24 de jul. de 2005]
WALKINSIDE. Disponível em : http://www.walkinside.com [capturado em 08 de dez. de
2004].
WEY, J.D.R. InterFace: um sistema de animação interativa de rostos humanos.
Dissertação (Mestrado) – Escola Politécnica da Universidade de São Paulo.
Departamento de Engenharia Eletrônica. São Paulo. 1999.
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
