ads:
Laborat´orio Nacional de Computa¸c˜ao Cient´ıfica
Programa de P´os Gradua¸c˜ao em Modelagem Computacional
Ambiente de Realidade Virtual Autom´atico para
Visualiza¸c˜ao de Dados Biol´ogicos
Por
Paulo Roberto Trenhago
PETR
´
OPOLIS, RJ - BRASIL
NOVEMBRO DE 2009
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
AMBIENTE DE REALIDADE VIRTUAL AUTOM
´
ATICO PARA
VISUALIZA¸C
˜
AO DE DADOS BIOL
´
OGICOS
Paulo Roberto Trenhago
DISSERTA¸C
˜
AO SUBMETIDA AO CORPO DOCENTE DO LABORAT
´
ORIO
NACIONAL DE COMPUTA¸C
˜
AO CIENT
´
IFICA COMO PARTE DOS REQUI-
SITOS NECESS
´
ARIOS PARA A OBTEN ¸C
˜
AO DO GRAU DE MESTRE EM
CI
ˆ
ENCIAS EM MODELAGEM COMPUTACIONAL
Aprovada por:
Prof. Jauvane Cavalcante de Oliveira, Ph.D
(Presidente)
Prof. Gilson Antˆonio Giraldi, D.Sc
Prof. Ana Tereza Ribeiro Vasconcelos, D.Sc
Prof. Selan Rodrigues dos Santos, Ph.D
Prof. Luciano Pereira Soares, Ph.D
PETR
´
OPOLIS, RJ - BRASIL
NOVEMBRO DE 2009
ads:
Trenhago, Paulo Roberto
T794a Ambiente de realidade virtual autom´atico para visualiza¸c˜ao de dados
biol´ogicos / Paulo Roberto Trenhago. Petrop´olis, RJ. : Laborat´orio Nacional
de Computa¸c˜ao Cient´ıfica, 2009.
xix, 111 p. : il.; 29 cm
Orientador: Jauvane Cavalcante de Oliveira
Disserta¸c˜ao (M.Sc.) – Laborat´orio Nacional de Computa¸c˜ao Cient´ıfica,
2009.
1. Programa¸c˜ao visual (Computa¸c˜ao). 2. Bioinform´atica. 3. X3D (Ex-
tensible 3D Graphics). I. Oliveira, Jauvane Cavalcante de. II. LNCC/MCT.
III. T´ıtulo.
CDD 005.118
e.p´ı.gra.fe
Visualiza¸c˜ao Cient´ıfica ´e um modo de
comunica¸c˜ao entre humanos e sistemas que
transcende as aplica¸c˜oes e os limites
tecnol´ogicos.
(Fonte: Visualization in Scientific Computing, 1987.)
iv
Dedicat´oria
aos meus pais Cla´udio Trenhago e Claudia
Trenhago e a meus irm˜aos Daniel J.
Trenhago e Carlos A. Trenhago
v
Agradecimentos
Agrade¸co aos meus pais e irm˜ao que mesmo distantes contribu´ıram de todas
as maneiras necess´arias para a realiza¸c˜ao deste trabalho e do meu treinamento
cient´ıfico.
Ao amigo e orientador Jauvane C. de Oliveira por sua confian¸ca e disposi¸c˜ao
em me orientar pelos caminhos necess´arios ao desenvolvimento deste trabalho, pela
ajuda sempre presente quando necess´aria a tantas outras quest˜oes mais ou menos
importantes.
`
A prof. Ana Tereza Vasconcelos, chefe do Labinfo que tamb´em acreditou e
me acolheu no curso de p´os gradua¸c˜ao do LNCC.
Ao prof. Gilson A. Giraldi por seus ensinamentos em matem´atica que me
levaram a um olhar mais detalhado sobre os fenˆomenos gerais, relevantes ou n˜ao
ao meu trabalho.
`
A Ellen S. Correa pela agrad´avel companhia e pelo carinho especial que tens
demostrado.
Ao amigo Rodrigo Danieli pela sua inestim´avel ajuda e conselhos que me
auxilaram nesta conquista.
E finalmente aos amigos, Daniel, Daniel e Daiane, Jonas, Cris, Eduardo,
Johannes, Madalena, Douglas, Antˆonio, Cecilia, Priscila, Gilmar, Elen, Murilo,
Arthur, Silvano, Luciane, ao prof. Selan, e outros que fizeram parte da minha vida
neste per´ıodo.
Aos funcion´arios da secret´aria de p´os-gradua¸c˜ao Ana Neri e Ana Paula e do
labinfo M´arcia, e de toda a comunidade do LNCC. Agrade¸co tamb´em `a CAPES,
`a RNP e LNCC pelo financiamento da minha forma¸c˜ao e do material necess´ario
vi
para o trabalho.
vii
Resumo da Disserta¸c˜ao apresentada ao LNCC/MCT como parte dos requisitos
necess´arios para a obten¸c˜ao do grau de Mestre em Ciˆencias (M.Sc.)
AMBIENTE DE REALIDADE VIRTUAL AUTOM
´
ATICO PARA
VISUALIZA¸C
˜
AO DE DADOS BIOL
´
OGICOS
Paulo Roberto Trenhago
Novembro , 2009
Orientador: Jauvane Cavalcante de Oliveira, Ph.D
Este Trabalho descreve o desenvolvimento de uma estrutura l´ogica de soft-
ware para o controle do CAVE do LNCC e sua utiliza¸c˜ao na visualiza¸c˜ao de dados
biol´ogicos. Configuramos e adaptamos o framework InstantReality para fazer fun-
cionar todos os componentes singulares do CAVE do LNCC ( uma parede n˜ao
ortogonal, duas paredes com cinco lados, projetores convencionais, entre outros)
por meio de uma tecnologia emergente, o X3D, usado para distribuir conte´udo 3D
multim´ıdia pela Internet.
Propomos um processo para o r´apido desenvolvimento, recorrendo ou n˜ao a
uma linguagem de programa¸c˜ao, de aplica¸c˜oes para visualiza¸c˜ao de dados biol´ogi-
cos, tais como: descri¸c˜ao geom´etrica de parte do sistema cardiovascular humano,
de parte de uma larva, visualiza¸c˜ao de modelos de prote´ınas e caps´ıdios de v´ırus.
Apresentamos quest˜oes importantes na visualiza¸c˜ao de superf´ıcies complexas, como
a importˆancia do modelo de ilumina¸c˜ao utilizado e descrevemos a implementa¸c˜ao
de um modelos de ilumina¸c˜ao em GPU. Adicionalmente, justificamos o emprego da
Realidade Virtual como ferramenta valiosa para a visualiza¸c˜ao em bioinform´atica,
e mesmo na biologia.
Finalmente, avaliamos a eficiˆencia geral do CAVE e de cada componente,
atrav´es dos resultados obtidos na visualiza¸c˜ao de cen´arios tem´aticos de interesse
biol´ogico. Identificamos poss´ıveis problemas e sugerimos op¸c˜oes para uma melhoria
viii
geral do desempenho.
ix
Abstract of Dissertation presented to LNCC/MCT as a partial fulfillment of the
requirements for the degree of Master of Sciences (M.Sc.)
T
´
ITULO EM INGL
ˆ
ES DA TESE OU DISSERTA ¸C
˜
AO
Paulo Roberto Trenhago
November, 2009
Advisor: Jauvane Cavalcante de Oliveira, Ph.D
This work describes the development of a software structure that currently
controls the CAVE at LNCC, as well as its use for biological data visualiza-
tion. This work also includes the adaptation and configuration of the InstantRe-
ality framework considering all particularities of the CAVE built at LNCC, which
amongst other things does not have square walls all around (two walls have a par-
ticular shape). In order to accompish this task we make use of the emerging X3D
technology.
This work also proposes a process for fast development of biological data vi-
sualization. Such process has been used to develop a series of sample applications,
which included geometric description of parts of the human cardiovascular system
as well as other structures such as parts of worms and other creatures, visualization
of proteine models and virus envelops both relying or not on some programming
language. This work also introduces important aspects of complex surface visu-
alization and describes the implementation of a GPU based ilumination model.
Additionally, some justifications are presented regarding the use of Virtual Reality
as a tool for bioinformatics visuzalization or biologic applications.
Finally, this work evaluates the CAVE prototype, considering each of its
components, in the light of the results achieved in the biologic visualization ap-
plications developed. Problems are identified and further improvements are pro-
posed.
x
Sum´ario
1 Introdu¸c˜ao 1
1.1 Contribui¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Organiza¸c˜ao do Conte´udo . . . . . . . . . . . . . . . . . . . . . . . 2
2 No¸c˜oes Preliminares 4
2.1 Realidade Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Mundos Virtuais . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Imers˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 Navegabilidade e Intera¸c˜ao em Tempo Real . . . . . . . . . 5
2.1.4 Cave Automatic Virtual Environment . . . . . . . . . . . . . 6
2.1.5 Vis˜ao Estereosc´opica . . . . . . . . . . . . . . . . . . . . . . 7
2.1.6 Polariza¸c˜ao Circular da Luz . . . . . . . . . . . . . . . . . . 9
2.2 X3D: Extensible 3D Graphics . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 X3D: Elementos Geom´etricos Vis´ıveis . . . . . . . . . . . . . 12
2.2.2 X3D: Eventos e Anima¸c˜oes . . . . . . . . . . . . . . . . . . . 15
2.2.3 X3D: Acesso aos Processadores Gr´aficos Program´aveis . . . 17
2.2.4 X3D: Interface Externa Autorizada . . . . . . . . . . . . . . 20
2.3 InstantReality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.1 Componentes X3D estendidos . . . . . . . . . . . . . . . . . 24
2.3.2 Escalabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.3 Interoperabilidade . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.4 Independˆencia de Dispositivos de Entrada e Sa´ıda . . . . . . 25
xi
2.3.5 Conformidade com Padr˜oes . . . . . . . . . . . . . . . . . . 25
2.4 Introdu¸c˜ao `a Visualiza¸c˜ao Cient´ıfica . . . . . . . . . . . . . . . . . . 26
2.4.1 Visualiza¸c˜ao de Estrutura de Prote´ınas . . . . . . . . . . . . 27
3 Estrutura F´ısica 29
3.1 Telas de proje¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Projetores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Filtros para Polariza¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Espelhos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5 Infraestrutura Computacional . . . . . . . . . . . . . . . . . . . . . 34
3.6 Rastreador de Posi¸c˜ao e Orienta¸c˜ao . . . . . . . . . . . . . . . . . . 37
3.7 Alinhamento f´ısico . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4 Elementos de Software 41
4.1 Vis˜ao Geral dos Elementos . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 O Subgrafo Scene . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 O Subgrafo Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.1 O sistema de proje¸c˜ao distribu´ıdo . . . . . . . . . . . . . . . 46
4.3.2 Alinhamento das ´areas de imagens . . . . . . . . . . . . . . 47
4.3.3 Modelo de cˆameras . . . . . . . . . . . . . . . . . . . . . . . 50
4.4 Integrando o NestOfBirds . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.1 Controle do NestOfBirds em Java . . . . . . . . . . . . . . . 54
4.4.2 Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.5 Suporte ao Desenvolvimento de Aplica¸c˜oes . . . . . . . . . . . . . . 57
5 Resultados e discuss˜ao 58
5.1 Resultados Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1.1 Resolu¸c˜ao M´axima
´
Util por Projetor . . . . . . . . . . . . . 59
5.1.2 Diferen¸cas de Brilho entre Telas . . . . . . . . . . . . . . . . 61
5.1.3 Diferen¸cas na resposta ao espectro de cores entre telas . . . 63
5.1.4 Sincronismo espacial . . . . . . . . . . . . . . . . . . . . . . 64
xii
5.1.5 Sincronismo Temporal . . . . . . . . . . . . . . . . . . . . . 65
5.1.6 Rastreamento da posi¸c˜ao da cabe¸ca do usu´ario e transfor-
ma¸c˜oes nas imagens . . . . . . . . . . . . . . . . . . . . . . . 65
5.2 Resultados Espec´ıficos em Bioinform´atica . . . . . . . . . . . . . . . 66
5.2.1 Visualiza¸c˜ao de morfologia de larvas . . . . . . . . . . . . . 66
5.2.2 Visualiza¸c˜ao Sistema Cardiovascular humano . . . . . . . . . 68
5.2.3 Visualiza¸c˜ao de modelos de prote´ınas e de v´ırus . . . . . . . 70
5.2.4 Visualiza¸c˜ao 3D de um gel bidimensional . . . . . . . . . . . 72
6 Conclus˜ao e Trabalhos Futuros 76
6.1 Conclus˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.2 Sugest˜oes de Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . 78
6.2.1 Melhorias na Estrutura F´ısica do CAVE . . . . . . . . . . . 78
6.2.2 Melhorias no Software de Controle do CAVE . . . . . . . . . 78
6.2.3 Desenvolvimento de Aplicativos para Visualiza¸c˜ao Cient´ıficas 79
Referˆencias Bibliogr´aficas 81
Apˆendice
A Software de Controle do CAVE 87
A.1 Parte em X3D do controle do CAVE . . . . . . . . . . . . . . . . . 87
A.2 Parte em Java para controle do NestOfBirds . . . . . . . . . . . . . 91
A.3 C´odigo em C para o NestOfBirds . . . . . . . . . . . . . . . . . . . 94
A.4 Comandos para compilar e executar . . . . . . . . . . . . . . . . . . 100
A.4.1 Um passo a passo para compilar . . . . . . . . . . . . . . . . 100
A.4.2 Como executar . . . . . . . . . . . . . . . . . . . . . . . . . 101
B Exemplo de uma aplica¸c˜ao 102
B.1 Descri¸c˜ao parcial da estrutura 3D de uma larva em VRML . . . . . 102
B.2 C´odigo fonte das outras aplica¸c˜oes . . . . . . . . . . . . . . . . . . . 111
xiii
Lista de Figuras
Figura
2.1 Representa¸c˜ao art´ıstica de um CAVE: Um usu´ario esta vendo um
mundo sint´etico sendo projetado ao seu redor e sua vis˜ao esta iso-
lada do mundo real. Note alguns dos componentes importantes
como paredes, espelhos, projetores. Fonte: Center for Innovative
Computer Applications. . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Tipos de paralaxe: (a) Paralaxe zero; (b) Paralaxe negativa; (c) par-
alaxe positiva. Fonte: Livro do Pr´e-Simp´osio SVR 2004, (Siscoutto
et al., 2004) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Luz polarizada: (a) vetor campo el´etrico
E e campo magn´etico
B;
(b) dois componentes el´etricos
E
1
e
E
2
; (c) dois componentes el´etri-
cos
E
1
e
E
2
de mesma amplitude e deslocados de 1/4 λ. Adaptado
de (HyperPhysics) . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Sa´ıda gr´afica dos elementos definidos no C´odigo 2.1. . . . . . . . . . 14
2.5 Ajuste de cor e ilumina¸c˜ao no processador de v´ertices: (a) imagem
renderizada utilizando modelo de ilumina¸c˜ao difusa e especular; (b)
imagem correspondente `a renderiza¸c˜ao sem ilumina¸c˜ao. . . . . . . . 20
3.1 Planta baixa do CAVE do LNCC: Disposi¸c˜ao dos componentes como
telas de proje¸c˜ao, espelhos, usu´ario, projetores, emissor do tracker
e computadores PCs. . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Arranjo espacial das quatro telas de proje¸c˜ao do CAVE. . . . . . . 30
xiv
3.3 Suporte dos projetores das telas do centro, da esquerda e da direita.
Distˆancias em mm. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Suporte dos projetores da tela do piso, fixado no teto. . . . . . . . . 32
3.5 Fotos dos suportes para os projetores: (a) suporte dos projetores
para tela do piso, fixado no teto; (b) suporte referente as telas da
esquerda, centro e direita. . . . . . . . . . . . . . . . . . . . . . . . 33
3.6 Filtros ´oticos de polariza¸c˜ao circular: (a) filtro polariza¸c˜ao circular
sentido hor´ario; (b) filtro polariza¸c˜ao circular sentido anti-hor´ario;
(c) ´oculos confeccionados com filtros de polariza¸c˜ao. . . . . . . . . . 33
3.7 Distˆancia adequada entre projetores e telas corrigidas com a uti-
liza¸c˜ao de espelhos, E1, E2, E3 e E4. P1 representa a posi¸c˜ao onde
deveria estar posicionado o par de projetores caso n˜ao fosse utilizado
o espelho E1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.8 Estrutura computacional com m´ultiplos projetores para o CAVE do
LNCC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.9 Transforma¸c˜oes na imagem provocada pelo deslocamento do obser-
vador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.10 Alinhamento f´ısico das proje¸c˜oes: (a) proje¸c˜oes n˜ao alinhadas; (b)
eixos horizontais e verticais perpendiculares, alinhamento parcial;
(c) condi¸c˜ao final para o alinhamento f´ısico. . . . . . . . . . . . . . 40
4.1 Componentes do software de controle para o CAVE do LNCC, as
linhas finas representam os ROUTEs. . . . . . . . . . . . . . . . . . 43
4.2 Interface de Rede do InstantPlayer: Web Interface Device Manage-
ment. O Exemplo ilustra o dispositivo joyStick. . . . . . . . . . . . 44
4.3 Arranjo das ´areas de telas dos servidores, determinado pelos valores
dos campos hserver="4" e vServer="1" do n´o ClusterWindow. Na
figura temos um resolu¸c˜ao total de 8192x768. . . . . . . . . . . . . . 47
xv
4.4 Alinhamento das ´areas de imagens: (a) alinhamento e dimension-
amento das ´areas de imagens no espa¸co de tela dos servidores; (b)
imagens projetadas nas paredes do CAVE, j´a com as posi¸c˜oes indi-
viduais (esquerda e direita) para cada parede alinhadas. . . . . . . . 49
4.5 Frustum: volume de visualiza¸c˜ao no espa¸co virtual. . . . . . . . . . 51
4.6 Frustum 4 ajustado para a tela do piso. . . . . . . . . . . . . . . . . 52
4.7 Configura¸c˜ao do Frustum 1 para a tela de proje¸c˜ao frontal. . . . . . 53
4.8 UML das Classes em Java para controle do tracker NestOfBirds. . . 55
5.1 Sincronismo espacial, emendas das imagens nas bordas das telas: (a)
linhas brancas de largura um pixel; (b) qualidade da renderiza¸c˜ao
de um objeto com imagens para olho esquerdo e direito. . . . . . . . 61
5.2 Diferen¸cas de brilho e de cor nas quatro telas de proje¸c˜ao: (a) parede
da esquerda apresenta um n´ıvel de brilho relativamente baixo; (b)
tela do piso responde melhor a faixa do espectro correspondente ao
vermelho. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3 Ilustra¸c˜ao das duas Leis de ilumina¸c˜ao. . . . . . . . . . . . . . . . . 63
5.4 jun¸c˜oes das imagens nas quatro telas, emendas das imagens nas bor-
das das telas: (a) emendas das imagens referentes ao olho esquerdo;
(b) emendas das imagens referentes ao olho direito. . . . . . . . . . 64
5.5 Sequˆencia de imagens que ilustra as transforma¸c˜oes nas proje¸c˜oes
em resposta ao movimento da cabe¸ca do usu´ario: (a),(b),(c),(d),(e)
e (f) s˜ao seis instantes de tempo distintos. . . . . . . . . . . . . . . 66
5.6 Modelo geom´etrico parcial do crˆanio da larva Leptobrachella mjobergi
carregado no ambiente CAVE, sem tratamento. . . . . . . . . . . . 67
5.7 Captura de tela da Aplica¸c˜ao para visualiza¸c˜ao da estrutura mor-
fol´ogica do crˆanio de uma larva. . . . . . . . . . . . . . . . . . . . . 68
5.8 Um cen´ario virtual descrito pelo modelo de art´erias e veias de um
humano: (a) vis˜ao frontal geral; (b) detalhe do t´orax; (c) uma im-
agem de dentro do crˆanio. . . . . . . . . . . . . . . . . . . . . . . . 69
xvi
5.9 Exemplo de uma aplica¸c˜ao para visualiza¸c˜ao de modelos de prote´ı-
nas com menu de intera¸c˜ao com o usu´ario: (a) menu de intera¸c˜ao;
(b) modelo de esferas e astes; (c) modelo no estilo ribbon; (d) esferas
e astes + superf´ıcie; (e) e (f) modelo da superf´ıcie. . . . . . . . . . . 70
5.10 Visualiza¸c˜ao de modelos multi escala de v´ırus: (a) um v´ırus da
familia Reoviridae resolu¸c˜ao 3,60 A; (b) um Togaviridae; (c) repre-
senta¸c˜ao 3D de um Totiviridae de 3,50 A. . . . . . . . . . . . . . . 71
5.11 Visualiza¸c˜ao de dados eletroforese bi-dimensional: (a) foto tipica de
um resultado de eletroforese 2D; (b) um fragmento da figura; (c)
um modelo 3D gerado a partir do fragmento 5.11-b. . . . . . . . . 73
5.12 Transforma¸c˜ao da Figura 5.11-b para um modelo geom´etrico 3D
equivalente: (a) representa¸c˜ao 3D da imagem sem tratamento; (b)
imagem tratada com um filtro de convolu¸c˜ao gaussiano. . . . . . . . 74
5.13 Duas representa¸c˜ao 3D do fragmento de imagem da Figura 5.11-b:
(a) renderiza¸c˜ao simples sem utiliza¸c˜ao de um modelo para ilumi-
na¸c˜ao do objeto; (b) com um modelo de ilumina¸c˜ao difusa e espec-
ular Phong shading em gpu. . . . . . . . . . . . . . . . . . . . . . . 74
5.14 Visualiza¸c˜ao no CAVE da representa¸c˜ao 3D do gel 2D, com suaviza-
¸c˜ao e ilumina¸c˜ao pelo modelo de Phong: (a) Note as imagens dos
pequenos picos na tela do piso; (b) imagem de picos maior da tela
do piso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
xvii
Lista de Tabelas
Tabela
4.1 Dados das coordenas, levantados pelo processo de alinhamento. . . 48
5.1 Densidade de pontos de imagem nas telas. . . . . . . . . . . . . . . 60
xviii
Lista de Siglas e Abreviaturas
• 2hba: estrutura do cristal do dom´ınio N-terminal da Prot´eina Ribossomal L9, obtido
do PDB
• 1ej6: modelo do caps´ıdio de um v´ırus da fam´ılia Reoviridae, obtido do VIPERdb
• GPU: Unidade de Processamento Gr´afico, processadores das placas de v´ıdeo
• 3D: Tridimensional
• VRML: Linguagem de modelagem para Realidade Virtual
•
˚
A: Angstroms
• GLSL: OpenGL Shading, uma API para acessar recursos das GPUs
• X3D: Um formato XML pa Gr´aficos 3D extens´ıveis
• NIH: National Institutes of Health
• ACiMA: Laborat´orio de Ambientes Colaborativos e Multim´ıdia Aplicada
• CAVE: Ambiente de Realidade Virtual Autom´atico
• DLP: Processamento digital de Luz
• VIPERdb: VIrus Particle ExploreR data base.
• DNA (ou ADN):
´
Acido Desoxirribonucl´eico
• PDB: Protein Data Bank
• RMN: Ressonˆancia Magn´etica Nuclear
• Rx: Raios-X
• SLI: Scalable Link Interface
• DVI: Digital Visual Interface
xix
Cap´ıtulo 1
Introdu¸c˜ao
A proposta prim´aria desta disserta¸c˜ao ´e o desenvolvimento de componentes
l´ogicos para tornar operacional o Ambiente de Realidade Virtual Autom´atico (Cave
Automatic Virtual Environment) CAVE (Cruz-Neira et al., 1992), montado no
Laborat´orio ACiMA, e apresentar uma solu¸c˜ao para visualiza¸c˜ao de dados biol´ogi-
cos estruturais incluindo modelos relacionados a morfologia, modelos de prote´ınas
e modelos de part´ıculas virais. Prote´ınas e v´ırus n˜ao podem ser visualizados dire-
tamente porque seus tamanhos est˜ao entre a escala nanom´etrica e microm´etrica,
portanto est˜ao fora do alcance da vis˜ao humana natural. Estes sistemas biol´ogicos
possuem conforma¸c˜oes tridimensionais complexas no espa¸co al´em de uma dinˆamica
espec´ıfica no tempo. Os dados referente `as posi¸c˜oes de cada ´atomo de uma pro-
te´ına podem ser determinados mediante t´ecnicas de cristalografia de prote´ınas e
difra¸c˜ao de raio-X discutidas no Cap´ıtulo 2 desta disserta¸c˜ao. Estes detalhes da
estrutura tridimensional de uma prote´ına podem ser exploradas como alvos para
encaixe com outras mol´eculas que podem controlar sua atividade biol´ogica, e assim
desenvolver novos medicamentos.
O ambiente CAVE/LNCC ´e constitu´ıdo de 4 paredes de proje¸c˜ao: es-
querda, frontal e direita com dimens˜oes de 1,85 x 2,45 metros e piso com 1.38 x
1,85 metros, 8 projetores DLP, filtros de polariza¸c˜ao circular da luz, 4 espelhos, 5
computadores, 1 switch gigabit ethernet e um sistema para rastreamento de movi-
mentos da cabe¸ca e da m˜ao do usu´ario Ascension Nest of Birds (Corporation).
1
Este ambiente permite aos pesquisadores e estudantes de biologia a visualiza¸c˜ao
tridimensional e estereosc´opica, de modelos de sistemas biol´ogicos, al´em de permi-
tir a imers˜ao total do usu´ario na realidade virtual descrita pelos dados biol´ogicos.
A visualiza¸c˜ao de dados com recurso para estereoscopia podem ser implementados
utilizando-se monitores convencionais com alta taxa de atualiza¸c˜ao mas o grau de
imers˜ao visual proporcionado ao usu´ario ´e comparativamente menor do que o sis-
tema descrito neste trabalho, pois o tamanho das imagens de um ou dois monitores
n˜ao preenche todo o campo de vis˜ao humano.
1.1 Contribui¸c˜oes
A principal contribui¸c˜ao desta disserta¸c˜ao ´e a constru¸c˜ao de elementos l´ogicos
de software para o controle de um CAVE de custo relativamente baixo, possibili-
tando a populariza¸c˜ao desta tecnologia no Brasil e motivando o desenvolvimento de
novas aplica¸c˜oes para pesquisas em Bioinform´atica na ´area de Visualiza¸c˜ao Cien-
tifica. Adicionalmente, discutimos quest˜oes de um caso particular de sincronismo
de brilho entre as paredes de proje¸c˜ao e uma altera¸c˜ao na geometria do ambiente de
imers˜ao, devido a configura¸c˜ao da parede de proje¸c˜ao localizada na parte de baixo
(o piso). Tamb´em descrevemos e testamos a capacidade para o desenvolvimento
r´apido de aplica¸c˜oes de Visualiza¸c˜ao Cient´ıfica para Bioinform´atica baseadas nos
padr˜oes Virtual Reality Modeling Language (VRML) (Ames et al., 1996) e Exten-
sible 3D Graphics (X3D) (Brutzman e Daly, 2007).
1.2 Organiza¸c˜ao do Conte´udo
O conte´udo desta disserta¸c˜ao ´e organizado em 3 partes. Na Parte 1 (Cap´ı-
tulos 2, 3 e 4), discutimos o projeto e constru¸c˜ao dos componentes f´ısicos e l´ogicos
deste ambiente CAVE de baixo custo, incluindo conceitos preliminares com revis˜ao
bibliogr´afica sobre o sistema visual humano, polariza¸c˜ao circular da luz, realidade
virtual, CAVEs, descri¸c˜ao do projeto, detalhes da constru¸c˜ao dos componentes
f´ısicos e do softwares de controle.
2
Na Parte 2 (Cap´ıtulo 5), apresentamos os resultados alcan¸cados tanto da
funcionalidade geral do sistema como na execu¸c˜ao de aplica¸c˜oes para visualiza¸c˜ao.
Mostramos como desenvolver rapidamente aplica¸c˜oes para este ambiente com base
nas tecnologias X3D, VRML e Java para visualizar modelos tridimensionais que
descrevem morfologias anatˆomicas de animais e humanos, bem como visualiza¸c˜ao
de modelos que representam estruturas de prote´ınas e part´ıculas virais, com dados
provenientes da internet dos bancos de dados p´ublicos Protein Data Bank (PDB)
(RCSB) e do VIrus Particle ExploreR (VIPER) (TSRI).
A Parte 3 (Cap´ıtulo 6), cont´em a discuss˜ao dos resultados e conclus˜oes, e uma
proposta para trabalhos futuros (Cap´ıtulo 7), referˆencias bibliogr´aficas e apˆendices
contendo partes relevantes do c´odigo fonte das Partes 1 e 2 desta disserta¸c˜ao. Na
conclus˜ao discutimos os resultados esperados e os obtidos. Material adicional deste
trabalho ser´a distribu´ıdo em meio digital CDROM dispon´ıvel tamb´em na p´agina
do laborat´orio ACiMA, http://acima.lncc.br/cave.
3
Cap´ıtulo 2
No¸c˜oes Preliminares
Este Cap´ıtulo descreve sucintamente alguns conhecimentos chaves para o
entendimento deste trabalho. Os especialistas na ´area de realidade virtual e vi-
sualiza¸c˜ao cientifica podem avan¸car para o pr´oximo cap´ıtulo. Entretanto para os
profissionais da a´erea de bioinform´atica a leitura deste capitulo ´e recomendado.
2.1 Realidade Virtual
A Realidade Virtual (RV) ´e um tipo de interface avan¸cada entre hu-
manos e computadores. Tamb´em pode ser definida como o modo de intera¸c˜ao
entre usu´arios (humanos) e as aplica¸c˜oes executadas em sistemas computacionais.
Sistemas RV s˜ao caracterizados por trˆes ou quatro elementos b´asicos (Scherman
e Craig, 2003): mundo virtual, imers˜ao, navegabilidade e interatividade, al´em do
requisito de execu¸c˜ao em tempo real. O sentido humano mais explorado atual-
mente ´e a vis˜ao, mas os outros sentidos, como tato, audi¸c˜ao, paladar e olfato est˜ao
sendo explorados em aplica¸c˜oes mais avan¸cadas.
2.1.1 Mundos Virtuais
Mundo virtual ´e um espa¸co imagin´ario que se manifesta por algum meio de
um sistema de proje¸c˜ao controlado por computador. Estes mundos, quando em
um contexto computacional, podem ser definidos atrav´es da Linguagem para Mod-
elagem de Realidade Virtual, Virtual Reality Modeling Language (VRML), ou por
4
sua sucessora Gr´aficos 3D extens´ıveis, Extensible 3D Graphics (X3D). Atrav´es de-
las podemos definir objetos geom´etricos, atribuir propriedades de cor e transparˆen-
cia, descrever a ilumina¸c˜ao, definir comportamentos autˆonomos ou disparados por
eventos aos objetos. Mundos Virtuais podem ter ou n˜ao correspondˆencia com o
nosso mundo real. Na se¸c˜ao X.X ´e apresentado ao leitor uma introdu¸c˜ao ao X3D.
2.1.2 Imers˜ao
Imers˜ao ´e a sensa¸c˜ao de estar dentro de um ambiente virtual; pode ser um
estado puramente mental, Imers˜ao Mental, ou o indiv´ıduo pode estar acoplado
fisicamente atrav´es de sensores e atuadores eletromecˆanicos ao meio que manifesta
o mundo virtual, ´e o que chamamos de Imers˜ao F´ısica. A leitura de um livro
pode produzir imers˜ao mental, o leitor se torna um observador do cen´ario e dos
acontecimentos descrito pelo autor. Para termos imers˜ao f´ısica ´e fundamental a
participa¸c˜ao corporal atrav´es da percep¸c˜ao de uma ou mais sensa¸c˜oes produzidas
por est´ımulos sint´eticos via o uso de tecnologias espec´ıficas. Sentidos como vis˜ao,
audi¸c˜ao e tato s˜ao tipicamente exploradas.
2.1.3 Navegabilidade e Intera¸c˜ao em Tempo Real
O aspecto mais importante da RV est´a relacionado com a capacidade do
computador detectar e reagir `as a¸c˜oes do usu´ario (Bowman et al., 2005). A
intera¸c˜ao do usu´ario com um ambiente virtual tridimensional realista, em tempo-
real, atrav´es de altera¸c˜oes nas cenas em resposta aos movimentos ou comandos do
usu´ario promove um grau maior de eficiˆencia para imers˜ao. Esta caracter´ıstica de
permitir ao usu´ario o controle da navega¸c˜ao para que ele explore mundos virtuais,
juntamente com a possibilidade de intera¸c˜ao com objetos destes mundos torna o
usu´ario um elemento ativo neste processo o que n˜ao acontece ao lermos livros ou
quando assistimos a filmes.
5
2.1.4 Cave Automatic Virtual Environment
Em 1992, na Universidades de Illinois em Chicago um CAVE foi apresentado
tendo rapidamente se tornado um sistema altamente popular (Cruz-Neira et al.,
1992) que prove com eficiˆencia a sensa¸c˜ao de imers˜ao e sensa¸c˜ao de vis˜ao 3D. Um
CAVE ´e constitu´ıdo a partir de um sistema de proje¸c˜ao, variando de 2 a 6 telas de
proje¸c˜ao distribu´ıdas em uma estrutura em forma de cubo, nas quais s˜ao projetadas
duas imagens de uma mesma cena, uma endere¸cada ao olho esquerdo e outra ao
olho direito. Um sistema de filtros de luz, ou obturadores, garantem a percep¸c˜ao
exclusiva da imagem de cada olho. Dentro do CAVE a posi¸c˜ao da cabe¸ca do
usu´ario ´e constantemente monitorada por um dispositivo de rastreio que informa
ao sistema de renderiza¸c˜ao o deslocamento dos olhos do usu´ario dentro do ambiente,
e com base nestes dados transforma¸c˜oes geom´etricas s˜ao executadas nas imagens
para manter o realismo. O grau de imers˜ao visual ´e muito alto, e geralmente o
espa¸co interno do CAVE ´e relativamente grande permitindo que mais do que um
observador compartilhe a experiˆencia, contudo somente um usu´ario ´e rastreado.
A Figura 2.1 mostra a disposi¸c˜ao dos componentes para um CAVE de 4
lados. Para reduzir a demanda de espa¸co f´ısico do sistema, espelhos s˜ao utilizados
para diminuir a distˆancia entre as telas de proje¸c˜ao e os projetores. O tamanho
t´ıpico de um CAVE ´e de uma estrutura em formato de cubo com 3 metros de
arestas, mas evidentemente o tamanho pode variar. Um bom n´ıvel de imers˜ao
pode ser conseguido com trˆes paredes, mas para imers˜ao total ´e necess´ario ainda
usar o teto ou assoalho ou ambos.
Rastreadores de posi¸c˜ao e orienta¸c˜ao de sensores baseados em sistemas mag-
n´eticos, ´oticos ou ac´usticos s˜ao usados para monitorar principalmente a posi¸c˜ao
da cabe¸ca do usu´ario em CAVEs ou ambientes virtuais. Al´em do monitoramento
da cabe¸ca, que ´e indispens´avel, ´e comum a utiliza¸c˜ao de sensores para determi-
nar a posi¸c˜ao e orienta¸c˜ao das m˜aos do usu´ario para prover sofisticados meios de
intera¸c˜ao entre o observador e o cen´ario virtual.
6
Figura 2.1: Representa¸c˜ao art´ıstica de um CAVE: Um usu´ario esta vendo um
mundo sint´etico sendo projetado ao seu redor e sua vis˜ao esta isolada do mundo
real. Note alguns dos componentes importantes como paredes, espelhos, projetores.
Fonte: Center for Innovative Computer Applications.
2.1.5 Vis˜ao Estereosc´opica
A maioria das formas de vida animal possuem um par de olhos. Esta configu-
ra¸c˜ao permite aumento do campo de vis˜ao e auxilia na percep¸c˜ao da profundidade
(Valberg, 2005). Enquanto duas imagens s˜ao tomadas de duas posi¸c˜oes diferentes
no espa¸co, o c´erebro combina as diferen¸cas para criar uma ´unica representa¸c˜ao que
cont´em as informa¸c˜oes de profundidade. Isto define o termo “vis˜ao estereosc´opica”.
Obviamente nosso pr´oprio sistema de vis˜ao ´e estereosc´opico. N´os depende-
mos dele para realizar tarefas complicadas como por fios em agulhas, encaixar uma
porca em um parafuso, ou estimar a distˆancia de um carro em aproxima¸c˜ao.
A vis˜ao estereosc´opica pode ser implementada em um sistema de Realidade
Virtual (Vince, 2004) e (Rogers e Adams, 1989), atrav´es da produ¸c˜ao de duas
vis˜oes distintas do mundo virtual, uma endere¸cada ao olho esquerdo e outra ao
7
olho direito. Na gera¸c˜ao destas duas imagens ´e preciso ajustar a distˆancia entre
os dois centros de proje¸c˜ao perspectiva para uma distˆancia sempre menor ou igual
a distˆancia entre os olhos do usu´ario, entretanto esta distˆancia muda de indiv´ıduo
para indiv´ıduo, mas um valor tipico de 6,5 cm costuma ser suficiente, (Vince,
2004). A distˆancia horizontal entre as imagens geradas pelo computador para o
olho esquerdo e para o olho direito ´e conhecida como paralaxe. Convergˆencia ´e o
termo usado para designar o ˆangulo formado entre os eixos ´oticos dos olhos e com
aux´ılio desta medi¸c˜ao que o c´erebro estima a distˆancia de um objeto.
Para que um observador tenha a impress˜ao de que um ponto esteja localizado
no plano de proje¸c˜ao, basta renderizar os pontos na mesma posi¸c˜ao (distˆancia
nula) e o termo t´ecnico empregado para designar este tipo de proje¸c˜ao ´e paralaxe
zero, Figura 2.2-a. Na paralaxe negativa ocorre o cruzamento dos eixos ´oticos
provocando a sensa¸c˜ao de que o ponto est´a localizado entre o observador e a tela
de proje¸c˜ao, Figura 2.2-b. Quando a distˆancia horizontal entre as imagens for
inferior `a distˆancia que separa os olhos do usu´ario, teremos a impress˜ao de que
o ponto esta localizado atr´as do plano de proje¸c˜ao, paralaxe positiva (Siscoutto
et al., 2004) Figura 2.2.
Figura 2.2: Tipos de paralaxe: (a) Paralaxe zero; (b) Paralaxe negativa; (c) par-
alaxe positiva. Fonte: Livro do Pr´e-Simp´osio SVR 2004, (Siscoutto et al., 2004)
A eficiˆencia do efeito estereosc´opico esta diretamente relacionado ao controle
da paralaxe e com o encaminhamento distinto de cada imagem gerada ao olho
8
correspondente sem que ocorra uma sobreposi¸c˜ao. Exitem basicamente dois modos
de conseguir este efeito: mecanismos passivos, baseados nas propriedades da luz
como a frequˆencia e a polariza¸c˜ao, e os mecanismos ativos como ´oculos dotados
de obturadores sincronizados com o sistema de renderiza¸c˜ao. Os sistemas ativos
s˜ao mais eficientes entretanto ´e necess´ario gerar o dobro de imagens por unidade
de tempo se comprado com o sistema passivo. Uma outra maneira de garantir a
separa¸c˜ao entre as imagens ´e montar pequenas telas pr´oximas a cada um dos olhos
isoladamente, Scherman e Craig (2003). Um dispositivo que implementa est´a ideia
´e conhecido como capacete para realidade virtual (HMDs head-mounted displays).
2.1.6 Polariza¸c˜ao Circular da Luz
Para entendermos como ´e poss´ıvel separar duas imagens projetadas em uma
mesma tela, uma para cada olho, precisamos entender algumas caracter´ısticas da
radia¸c˜ao eletromagn´etica. A luz vis´ıvel ´e um tipo particular de radia¸c˜ao eletro-
magn´etica com comprimento de onda relativo a sensibilidade do olho humano,
aproximadamente entre 400nm e 700nm, (Born e Wolf, 1999) e (Hecht, 2002).
A radia¸c˜ao eletromagn´etica ´e composta de um campo el´etrico e um campo mag-
n´etico, que oscilam perpendicularmente um ao outro e `a dire¸c˜ao da propaga¸c˜ao
(Reitz et al., 1992) e (Jackson, 1998). Na Figura 2.3-a temos em cinza claro a
representa¸c˜ao do campo el´etrico, descrito pelo vetor
E oscilando confinado num
´unico plano de propaga¸c˜ao e em padr˜ao pontilhado o campo magn´etico, vetor
B.
A luz ´e uma onda eletromagn´etica transversal e a polariza¸c˜ao ´e uma descri¸c˜ao da
orienta¸c˜ao do vetor campo el´etrico ao longo do tempo. Entretanto, a luz natu-
ral ´e geralmente n˜ao polarizada e todos os planos de propaga¸c˜ao s˜ao igualmente
prov´aveis, (Brosseau, 1998).
Um caso particular da polariza¸c˜ao linear da luz ´e ilustrado na firgura 2.3-b.
Note que duas componentes el´etricas ortogonais
E
1
e
E
2
(componente magn´etico
omitido) est˜ao em fase e o vetor resultante da soma ´e sempre um segmento de reta
no plano E
1
− E
2
. Na polariza¸c˜ao linear, a dire¸c˜ao da reta suporte para o vetor
9
resultante vai depender da amplitude relativa entre as componentes e o ˆangulo de
inclina¸c˜ao dos respectivos planos. N˜ao ´e necess´ario, portanto, que as componentes
sejam ortogonais.
Na polariza¸c˜ao circular de ondas eletromagn´eticas, o vetor que descreve o
campo el´etrico tem tamanho constante e descreve um movimento circular no plano
E
1
− E
2
. Este fenˆomeno ocorre quando duas componentes el´etricas possuem a
mesma intensidade e um deslocamento de fase de 90 graus. O sentido de rota¸c˜ao
´e determinado pela rela¸c˜ao entre as fases de E
1
e E
2
.
A polariza¸c˜ao circular pode ser realizada em sentido hor´ario ou anti-hor´ario,
dependendo do sentido de rota¸c˜ao do vetor que descreve o campo el´etrico. Entre-
tanto, historicamente duas conven¸c˜oes contradit´orias existem sobre o sentido de
rota¸c˜ao. Em f´ısica, astronomia e ´otica, a polariza¸c˜ao ´e definida pelo referencial do
receptor (Born e Wolf, 1999) e em engenharia el´etrica o referencial ´e o transmissor
(1037C, 2002), figura 2.3-c.
Figura 2.3: Luz polarizada: (a) vetor campo el´etrico
E e campo magn´etico
B;
(b) dois componentes el´etricos
E
1
e
E
2
; (c) dois componentes el´etricos
E
1
e
E
2
de
mesma amplitude e deslocados de 1/4 λ. Adaptado de (HyperPhysics)
Para produzir luz polarizada circular podemos utilizar uma placa de um
material cristalino birrefringente com espessura de 1/4 do comprimento da onda
quarter-wave plate (Paschotta, 2008). Quando um onda de luz polarizada linear-
10
mente incide a 45 graus em rela¸c˜ao ao eixo ´optico desta placa a luz ´e dividida em
dois componentes el´etricos iguais. Um destes ´e retardado por um quarto do com-
primento de onda pela placa. Incidindo uma luz polarizada circular nesta placa
produz uma luz polarizada linearmente. A combina¸c˜ao destas placas com filtros
lineares resultam em filtros para luz polarizada circular.
2.2 X3D: Extensible 3D Graphics
Esta se¸c˜ao descreve de uma maneira informal uma introdu¸c˜ao ao X3D, jus-
tificada pelo leitor da ´area de biologia interessado em desenvolver aplica¸c˜oes de
visualiza¸c˜ao para biologia e tamb´em ao leitor leigo em X3D/VRML. Aos que j´a
possuem conhecimento deste t´opico podem avan¸car `a pr´oxima se¸c˜ao.
X3D (eXtensible 3D Graphics ou Gr´aficos 3D Extens´ıveis) ´e uma revis˜ao do
padr˜ao VRML (Virtual Reality Modeling Language) estruturado, entre outros for-
matos, em XML (eXtensible Markup Language). O X3D ´e um padr˜ao industrial
aberto para distribui¸c˜ao de conte´udo 3D, definido pelas especifica¸c˜oes ISO/IEC
19775:2008, ISO/IEC 19976:2005 e ISO/IEC 19777:2005, ele combina, num sim-
ples arquivo texto a descri¸c˜ao da geometria e do comportamento dos elementos de
um cen´ario virtual 3D. O X3D surgiu de uma revis˜ao da especifica¸c˜ao ISO/IEC
14772-1:1997 do VRML 2.0 para incorporar melhorias ao n´ucleo (anima¸c˜ao de
humanoides, B-splines, GeoVRML) e acrescentar recursos dispon´ıveis nos moder-
nos dispositivos gr´aficos comerciais, entre eles, o acesso aos processadores gr´aficos
program´aveis GPUs (Graphics Processing Unit) das placas de v´ıdeo modernas.
A cria¸c˜ao de mundos virtuais 3D ´e simples e intuitiva no X3D (Brutzman e
Daly, 2007). N˜ao ´e necess´ario experiˆencia previa em programa¸c˜ao nem em XML,
´e ideal para o desenvolvimento de aplica¸c˜ao cient´ıficas, mantendo assim o desen-
volvedor concentrado na defini¸c˜ao da geometria e no comportamento dos elementos
para as cenas sem grandes preocupa¸c˜oes com detalhes intr´ınsecos das linguagens
de programa¸c˜ao e suas APIs gr´aficas. Entretanto, para o desenvolvimento de apli-
ca¸c˜oes complexas ´e aconselh´avel treinamento em XML (Holzner, 2001), VRML
11
(Ames et al., 1996) e na linguagens de programa¸c˜ao Java (Deitel e Deitel, 2005).
Uma introdu¸c˜ao ao X3D atrav´es de exemplos completos encontra-se a seguir.
Nesta introdu¸c˜ao apresentamos o X3D atrav´es de alguns exemplos: um exemplo
com defini¸c˜oes de elementos geom´etricos simples, um outro exemplo de como uti-
lizar recursos dos processadores gr´aficos das placas de v´ıdeo e finalmente como
controlar um pequeno cen´ario atrav´es de um programa em Java.
2.2.1 X3D: Elementos Geom´etricos Vis´ıveis
O C´odigo 2.1 ilustra um arquivo completo em X3D formatado em XML e
a Figura 2.4 representa a sa´ıda gr´afica correspondente quando executado por um
visualizador ou player de X3D. Um arquivo X3D inicia com a declara¸c˜ao <?xml?>,
linha 1, que ´e uma exigˆencia geral para qualquer arquivo XML. Portanto todas as
cenas no formato X3D devem ser, a priori, um arquivo XML v´alido. A linha 2 ´e
opcional mas recomendada, e inclui uma referˆencia para um documento ou esquema
de valida¸c˜ao do arquivo X3D. O n´umero de vers˜ao ´e um campo obrigat´ario na
declara¸c˜ao raiz, linha 3. Todo o conte´udo referente ao grafo de cenas encontra-se
entre <Scene>...</Scene>, linhas 4 e 58, que define o n´o raiz do grafo de cenas.
Grafos de cenas s˜ao ferramentas conceituais para representa¸c˜ao de ambientes
virtuais.
´
E uma forma de organizar cole¸c˜oes de objetos, seus relacionamentos, e a
forma em que o observador vˆe esses objetos na cena, (Wernecke, 1994).
1 <?xml version=” 1 . 0 ” en coding=”UTF−8”?>
2 < !DOCTYPE X3D PUBLIC ”ISO //Web3D//DTD X3D 3 . 0 / /EN” ” h t t p : //www. web3d . org /
s p e c i f i c a t i o n s /x3d − 3.0 . dtd ”>
3 <X3D p r o f i l e= ’ Immersive ’ version=’ 3 . 0 ’>
4 <Scene>
5 <Background s kyC olo r= ’ 1 1 1 ’ />
6 <Transform t r a n s l a t i o n= ’−5 0 0 ’>
7 <Shape>
8 <Box s i z e= ’ 2 2 2 ’ />
9 <Ap pearance>
10 <Material d i f f u s e C o l o r= ’ 1 0 .2 0 . 2 ’ />
11 </Appearance>
12 </Shape>
13 </Transform>
12
14 <Transform t r a n s l a t i o n= ’ −2.5 0 0 ’>
15 <Shape>
16 <Cone bottom=’ t r u e ’ bottomRadius= ’ 1 ’ h e i g h t= ’ 2 ’ s i d e= ’ t r u e ’ />
17 <Ap pearance>
18 <Material d i f f u s e C o l o r= ’ 0 . 2 1 0. 2 ’ />
19 </Appearance>
20 </Shape>
21 </Transform>
22 <Transform t r a n s l a t i o n= ’ 0 0 0 ’>
23 <Shape>
24 <Cylinder bottom=’ t r u e ’ h e i g h t= ’ 2 ’ r a d i u s= ’ 1 ’ s i d e= ’ t r u e ’ top=’
t r u e ’ />
25 <Ap pearance>
26 <Material d i f f u s e C o l o r= ’ 0 . 2 0 . 2 1 ’ />
27 </Appearance>
28 </Shape>
29 </Transform>
30 <Transform t r a n s l a t i o n= ’ 2.5 0 0 ’>
31 <Shape>
32 <Sphere r a d i u s= ’ 1 ’ />
33 <Ap pearance>
34 <Material d i f f u s e C o l o r= ’ 1 1 0 . 2 ’ />
35 </Appearance>
36 </Shape>
37 </Transform>
38 <Transform t r a n s l a t i o n= ’ 5 0 0 ’>
39 <Shape>
40 <IndexedFaceSet c oo r dI nde x=”0 1 3 −1 1 2 3 −1 2 0 3 −1 2 1 0 ”>
41 <Coordinate po i n t=”−1 −1 −0.87 0 −1 0 . 8 7 1 −1 −0.87 0 0 . 7 3 0 ”/
>
42 </Ind exedFaceSet>
43 <Ap pearance>
44 <Material d i f f u s e C o l o r=”1 0 1 ”/>
45 </Appearance>
46 </Shape>
47 </Transform>
48 <Transform t r a n s l a t i o n= ’ 6.5 0 0 ’>
49 <Shape>
50 <Text s t r i n g= ’ ”LNCC” ”X3D! ” ’>
51 <FontStyle />
52 </Text>
53 <Ap pearance>
54 <Material d i f f u s e C o l o r=”0 0 0 ”/>
55 </Appearance>
13
56 </Shape>
57 </Transform>
58 </Scene>
59 </X3D>
C´odigo 2.1: Primitivas geom´etricas descritas em X3D, codifica¸c˜ao XML.
Figura 2.4: Sa´ıda gr´afica dos elementos definidos no C´odigo 2.1.
A linha 5 ajusta a cor de fundo do cen´ario para branco skyColor=’r g b’,
Background ´e um n´o e skyColor um campo ou atributo do tipo SFVec3f, um
vetor de trˆes floats. A linha 6 abre um elemento de transforma¸c˜ao geom´etrica e
a linha 13 o fecha, o campo translation=’-5 0 0’ define uma transforma¸c˜ao do
tipo transla¸c˜ao para as coordenadas x = −5 y = 0 z = 0 unidades em metros. O
nodo <Transform></Transform> tamb´em opera como um elemento para agrupar
n´os.
A linha 7 abre uma defini¸c˜ao de um componente vis´ıvel, Shape, para associar
a geometria (linha 8) com suas propriedades visuais (linha 10), a linha 12 indica o
termino da descri¸c˜ao do marcador Shape XML do elemento em quest˜ao. A linha 8
cria um cubo Box com largura, altura e profundidade de 2 metros, size =
x y z
, e a
linha 10 atribui uma cor, baseado no modelo de ilumina¸c˜ao luz difusa, representado
no sistema de cores (RGB) r = 100% g = 20% b = 20%, veja na Figura 2.4 o cubo
`a esquerda. Ao definir um Shape ´e necess´ario definir tanto uma geometria quanto
uma aparˆencia.
As linhas 16, 24 e 32 representam as defini¸c˜ao para cone, cilindro e esfera
respectivamente. A linha 40 define um tetraedro cujos v´ertices s˜ao listados na
linha 41. A representa¸c˜ao dos pontos que determinam os v´ertices segue o esquema
14
geral point = ”p
0
x p
0
y p
0
z p
1
x p
1
y p
1
z ... p
n
x p
n
y p
n
z” e as faces s˜ao definidas
por uma sequencia de pontos terminada pelo indicador −1, a ordem com que os
v´ertices s˜ao listados determina a dire¸c˜ao do vetor normal da face. A linha 50
define um componente gr´afico capaz de representar textos, o campo string ´e do
tipo MFString que contem m´ultiplos strings, string individuais s˜ao delimitadas
por ”aspas duplas”que podem ser agrupadas por ’aspas simples’, cada string ser´a
renderizada numa posi¸c˜ao vertical distinta, ordenada de cima para baixo no espa¸co
de renderiza¸c˜ao.
2.2.2 X3D: Eventos e Anima¸c˜oes
Alguns n´os possuem campos que produzem eventos, e s˜ao conectados ent˜ao
atrav´es de uma ROUTE aos campos em n´os alvos. Cada campo de entrada de um
n´o VRML/X3D possui um nome (name), um tipo de dados (type), propriedades
de acesso (accessType), um valor padr˜ao e uma faixa de valores validos (range).
Consequentemente, um comportamento pode ser definido como o ato de mudar
um ou mais valores de campos do n´os no grafo de cenas para animar um X3D.
O princ´ıpio da anima¸c˜ao em X3D ´e simples: valores em campos podem ser
modificados em tempo de execu¸c˜ao. A troca de valores de campos dos n´os ´e
chamado evento, um evento consiste de um carimbo de tempo (time stamp) e um
valor de atualiza¸c˜ao.
1 <?xml version=” 1 . 0 ” en coding=”UTF−8”?>
2 < !DOCTYPE X3D PUBLIC ”ISO//Web3D//DTD X3D 3.1//EN” ” h t t p : //www. web3d . or g /
s p e c i f i c a t i o n s /x3d − 3.1 . dtd ”>
3 <X3D p r o f i l e= ’ Immersive ’ version=’ 3 . 1 ’>
4 <Scene>
5 <Transform DEF= ’CUBO’>
6 <Shape>
7 <Box s i ze= ’ 0.2 0 . 2 0 . 2 ’ />
8 </Shape>
9 </Transform>
10
11 <TimeSensor DEF= ’RELOGIO ’ c ycl eI nte rva l= ’ 2 . 0 ’ enabled=’ true ’ loop=’ t r u e ’ />
12 <OrientationInterpolator DEF= ’INTER ’ key= ’ 0. 0 0 . 5 1 . 0 ’ keyValue= ’ 0 . 0 1 .0 0 . 0 0 . 0
0 . 0 1 . 0 0 . 0 3 . 1 4 0 . 0 1 . 0 0 . 0 6 . 2 8 ’ />
15
13
14 <ROUTE fromNode= ’RELOGIO ’ fromField= ’ f r a c t i o n c h a n g e d ’ toNode= ’INTER ’ toFi eld= ’
s e t f r a c t i o n ’ />
15 <ROUTE fromNode= ’INTER ’ fromField=’ val u e cha n ged ’ toNode= ’CUBO’ t oFi eld= ’
r o t a t i o n ’ />
16 </S cene>
17 </X3D>
C´odigo 2.2: C´odigo X3D para um cubo animado.
Na linha 5, 11 e 12, o campo DEF permite atribuir um nome para um n´o
X3D. Neste exemplo atribu´ımos o nome CUBO a um n´o de transforma¸c˜ao que
cont´em um filho cubo (Box), a aparˆencia n˜ao foi definida, ent˜ao o player usar´a
valores padr˜ao. O n´o Transform possui um campo rotation, que aceita eventos
de leitura e grava¸c˜ao, o tipo de dado aceito ´e SFRotation que ´e um vetor com
quatro valores de ponto flutuante (float), os trˆes primeiros valores especificam um
vetor normalizado que representa o eixo de rota¸c˜ao e o quarto valor espec´ıfica o
ˆangulo de rota¸c˜ao em radianos.
O n´o TimeSensor nomeado de RELOGIO, linha 11, ´e um gerador de eventos
baseado em tempo. Quando este nodo esta ativo ele produz um evento de sa´ıda
fraction-changed, do tipo SFFloat dentro da faixa [0,1] e n˜ao aceita eventos de
entrada. O campo cycleInterval controla o tempo de dura¸c˜ao de um ciclo, no
nosso exemplo o tempo total para o cubo girar uma volta completa ´e de dois segun-
dos, cycleInterval=’2.0’. Os valores gerados pelo campo fraction-changed
s˜ao conectados atrav´es de uma rota ao n´o OrientationInterpolator (linha 12)
que produz atrav´es do tipo SFFloat valores adequados do tipo SFRotation.
OrientationInterpolation, linha 12, interpola entre uma lista de valores
de rota¸c˜ao especificados no campo keyValue para produzir um evento value-
changed do tipo SFRotation controlado pelo campo key. Estas rota¸c˜oes s˜ao ab-
solutas no espa¸co do objeto. KeyValue e key devem conter exatamente a mesma
quantidade de objetos.
ROUTE, linhas 14 e 15, n˜ao ´e um n´o VRML/X3D e sim uma via para modificar
campos de objetos. Cada declara¸c˜ao ROUTE conecta dois objetos, por meio de
16
campos de acesso. No C´odigo 2.2 conectamos os n´os RELOGIO e INTER, linha 14,
toda vez que o campo key do n´o RELOGIO recebe um novo valor do tipo SFFloat o
n´o INTER gera um evento de sa´ıda do tipo SFRotation pelo campo value-changed,
que ent˜ao ´e conectado ao nodo CUBO que executa a transforma¸c˜ao adequada que
faz girar o objeto Box.
2.2.3 X3D: Acesso aos Processadores Gr´aficos Program´aveis
A evolu¸c˜ao das placas de v´ıdeo segue a tendˆencia atual do mercado de dispos-
itivos eletrˆonicos, substituir unidades funcionais fixas por unidades program´aveis.
Exemplos para as novas placas de v´ıdeo s˜ao as unidades program´aveis para pro-
cessamento de v´ertices vertex processor e processamento de fragmentos fragment
processor. O processador de v´ertices ´e usualmente respons´avel pelas fun¸c˜oes de
transforma¸c˜oes de v´ertices, normaliza¸c˜oes e transforma¸c˜oes em normais, gera¸c˜ao de
coordenadas para texturas, transforma¸c˜oes em coordenas de texturas e ilumina¸c˜ao.
A unidade de processamento de fragmentos ´e usada geralmente para interpola¸c˜ao
de valores, acesso a texturas, aplica¸c˜ao de texturas, n´evoa (fog) e soma de cores.
No C´odigo 2.3 demonstramos uma forma de integrar a linguagem GLSL,
(Rost, 2006), uma das linguagens para os processadores de placas de v´ıdeo, no
c´odigo em X3D. N˜ao pretendemos aqui introduzir ou explicar o GLSL, queremos
apenas mostrar como ´e poss´ıvel integrar c´odigo para processadores gr´aficos em ce-
nas formatadas em X3D. Recomendamos aos interessados em aplica¸c˜oes das carac-
ter´ısticas de unidades gr´aficas program´aveis em bioinform´atica, a tese de doutorado
do pesquisador Liu (2005) desenvolvida na Universidade do Estado da Ge´orgia nos
Estados Unidos da Am´erica. Sendo assim, o c´odigo abaixo ilustra a implementa¸c˜ao
de um modelo de ilumina¸c˜ao difusa e especular C = C
dif
+ C
esp
(Rogers, 1997),
(Richard S Wright et al., 2007) utilizando o processador de v´ertices.
1 <?xml version=” 1 . 0 ” en coding=”UTF−8”?>
2 < !DOCTYPE X3D PUBLIC ”ISO//Web3D//DTD X3D 3.1//EN” ” h t t p : //www. web3d . or g /
s p e c i f i c a t i o n s /x3d − 3.1 . dtd ”>
3 <X3D p r o f i l e= ’ Immersive ’ version=” 3 . 1 ”>
4 <Scene>
17
5 <Viewp oint p o s i t i o n= ’ 4 . 5 4 . 0 1 5 . 0 ’ o r i e n t a t i o n= ’ 1 . 0 0 . 0 0 . 0 −0.2 ’ />
6 <Shape>
7 <ElevationGrid xDimension= ’ 9 ’ zDimension= ’ 9 ’ h e i g h t= ’ 0. 0 0 . 0 0 . 5 1 . 0 0 . 5
0 . 0 0 . 0 0 . 0 0 . 0 0 . 0 0 . 0 0 . 0 0 . 0 2 . 5 0 . 5 0 . 0 0 . 0 0 . 0 0 . 0 0 . 0 0 . 5 0 . 5
3 . 0 1 . 0 0 . 5 0 . 0 1 . 0 0 . 0 0 . 0 0 . 5 2 . 0 4 . 5 2 . 5 1 . 0 1 . 5 0 . 5 1 . 0 2 . 5 3 . 0
4 . 5 5 . 5 3 . 5 3 . 0 1 . 0 0 . 0 0 . 5 2 . 0 2 . 0 2 . 5 3 . 5 4 . 0 2 . 0 0 . 5 0 . 0 0 . 0 0 . 0
0 . 5 1 . 5 1 . 0 2 . 0 3 . 0 1 . 5 0 . 0 0 . 0 0 . 0 0 . 0 0 . 0 0 . 0 0 . 0 2 . 0 1 . 5 0 . 5 0 . 0
0 . 0 0 . 0 0 . 0 0 . 0 0 . 0 0 . 5 0 . 0 0 . 0 ’ />
8 <Ap pearance>
9 <ComposedShader>
10 <f i e l d acc es sType= ’ i n i t i a l i z e O n l y ’ name= ’ l i g h t P o s ’ type= ’ SFVec3f ’
valu e= ’ −0.1 −1.0 0 . 0 ’ />
11 <ShaderPart type= ’VERTEX’>
12 <! [CDATA[
13 un if orm ve c3 l i g h t P o s ;
14
15 voi d main ( voi d ) {
16 g l P o s i t i o n=gl M odel V iewP r ojec t ionM a trix ∗ g l V e r t e x ;
17
18 f l o a t ypos = clamp ( gl V e r t e x . y , 0 . 0 , 1 . 0 ) ;
19
20 vec3 N = n o r m a l ize ( gl N or ma lM at rix ∗ gl N or ma l ) ;
21 vec4 V = g l ModelViewM atrix ∗ gl V e r t e x ;
22 vec3 L = n o r m a l ize ( l i g h t P o s − V. xyz ) ;
23 vec3 H = n o r m a l ize (L + vec3 ( 0 . 0 , 0 . 0 , 1 . 0 ) ) ;
24 c o n s t f l o a t spe cul arE xp = 1 2 8 . 0 ;
25
26 // c a l c u l o da l u z d i f u s a
27 f l o a t NdotL = max ( 0 . 0 , dot (N, L) ) ;
28 vec4 d i f f u s e=vec4 ( ypos , 1 . 0 , ypos , 1 . 0 ) ∗ vec4 ( NdotL ) ;
29
30 // c a l c u l o da l u z e s p e c u l a r
31 f l o a t NdotH = max ( 0 . 0 , dot (N, H) ) ;
32 vec4 s p e c u l a r = ve c4 ( 0 . 0 ) ;
33 i f ( NdotL > 0 . 0 )
34 s p e c u l a r = ve c4 ( pow ( NdotH , spe cul arE xp ) ) ;
35
36 // soma dos componentes d i f u s o e e s p e c u l a r
37 g l F r o n t Col o r = d i f f u s e + s p e c u l a r ;
38 }
39 ] ]>
40 </ShaderPart>
41 </ComposedShader>
42 </Appearance>
18
43 </Shape>
44 </Scene>
45 </X3D>
C´odigo 2.3: Uma cena em X3D com c´odigo GLSL integrado.
A linha 7 define um terreno atrav´es do n´o X3D ElevantionGrid com dimen-
s˜ao de 9 x 9 metros. O resultando ´e uma malha de 81 elementos 9 x 9, quando
o espa¸camento ´e omitido o Player de X3D assume o valor padr˜ao, que ´e de 1 m
tanto para o eixo X como para o eixo Z. O campo height cont´em os valor das
alturas correspondente a cada um dos v´ertice da malha.
As linha 8 e 42 abrem e fecham uma defini¸c˜ao para controlar a aparˆencia
declarado pelo elemento Appearance. Entre estas linhas declaramos um compo-
nente ComposedShader que indica ao player do X3D a existˆencia de c´odigo fonte
compat´ıvel com as unidades de processamento gr´afico. Dentro deste n´o podemos
definir c´odigos diretamente, ou indicar um arquivo externo em formato compat´ıvel.
A linha 10 declara e inicializa um objeto do tipo SFVec3f referenciado por
lightPos que cont´em um vetor representando a dire¸c˜ao da luz, esta informa¸c˜ao ´e
utilizada para o c´alculo de ilumina¸c˜ao especular e ilustra como podemos acessar
uma vari´avel externa ao c´odigo escrito em GLSL.
As linhas 11 e 40 definem um objeto simples ShaderPart atrav´es do campo
type = "VERTEX" que informa ao player de X3D para compilar e injetar o c´odigo
no processador de v´ertices da placa de v´ıdeo atrav´es do driver para OpenGL su-
portado pelo hardware.
A linha 12 informa ao player de X3D para n˜ao interpretar o que estiver entre
<![CDATA[ e ]]> e a linha 13 faz o acesso a vari´avel lightPos declarada na linha
10, ainda no formato XML para o X3D.
O resultado gr´afico gerado pelo C´odigo 2.3 esta representado pela Figura 2.5-
a e a Figura 2.5-b ´e uma sa´ıda gr´afica de outro c´odigo no qual a cor ´e atribu´ıda
diretamente, ao mesmo objeto, sem computar e aplicar qualquer modelo de ilumi-
na¸c˜ao. Entretanto poder´ıamos ter configurado a cor e o modelo de ilumina¸c˜ao por
outros caminhos no pr´oprio X3D, com a defini¸c˜ao de um n´o do tipo Color entre as
19
defini¸c˜oes de ElevationGrid com seu campo ColorPerVertex ajustado para true,
mas as solu¸c˜oes baseadas em GLSL, em geral, apresentam melhor desempenho. A
utiliza¸c˜ao de modelos de ilumina¸c˜ao complexos podem facilitar a nossa percep¸c˜ao
a detalhes em objetos com geometria complexa.
(a) (b)
Figura 2.5: Ajuste de cor e ilumina¸c˜ao no processador de v´ertices: (a) imagem
renderizada utilizando modelo de ilumina¸c˜ao difusa e especular; (b) imagem cor-
respondente `a renderiza¸c˜ao sem ilumina¸c˜ao.
2.2.4 X3D: Interface Externa Autorizada
X3D n˜ao ´e um arquivo no formato XML que apenas descreve a geometria
de objetos virtuais e seus comportamentos. Ele ´e um formato que pode ser esten-
dido para conter qualquer tipo de informa¸c˜ao, por exemplo c´odigo para unidades
gr´aficas program´aveis, detalhado anteriormente, ou scripts para criar e controlar a
dinˆamica de cen´arios. N´os do tipo Scripts permitem aos desenvolvedores criarem
recursos customizados atrav´es das linguagens ECMAScript e Java, coberto pela
especifica¸c˜ao ISO/IEC FDIS 19777:2005. Mesmo com toda esta flexibilidade que o
X3D possui, um c´odigo X3D puro pode n˜ao ser o suficiente para escrever algumas
aplica¸c˜oes complexas.
Existem basicamente dois meios para controlar uma cena 3D atrav´es de com-
ponentes de softwares externo. Uma mais antiga, External Authoring Interface
20
(EAI) ou Interface Externa de Autoria, definida pela norma ISO/IEC 14772-2:1997
para o VRML, e outra mais recente, Scene Access Interface (SAI) ou Interface para
Aceso a Cenas, definida pela norma ISO/IEC CD 19775-2.2:2008 para o X3D. Am-
bas permitem que programas externos controlem completamente o grafo de cena:
adicionando, modificando, removendo n´os ou emitindo e recebendo eventos. O
player de X3D utilizado no desenvolvimento deste trabalho suporta apenas o pro-
tocolo EAI, a implementa¸c˜ao do SAI est´a na fase inicial.
O exemplo a seguir ´e composto de duas listagem de c´odigo fonte: um arquivo
X3D contendo uma cena simples, um cubo vermelho; e um arquivo em c´odigo fonte
java que, que ap´os compilado e executado, estabelece uma conex˜ao EAI com o
player para X3D, atrav´es do protocolo de rede TCP/IP, e obt´em uma referencia
ao n´o Material da cenas definido pelo nome COR e efetua a troca da cor do cubo
de vermelha para a verde.
1 <?xml version=” 1 . 0 ” en coding=”UTF−8”?>
2 <X3D p r o f i l e= ’ Immersive ’ version=’ 3 . 0 ’>
3 <Scene>
4 <Background s kyC olo r= ’ 1 1 1 ’ />
5 <Shape>
6 <Ap pearance>
7 <Material DEF= ’COR’ d i f f u s e C o l o r= ’ 1 . 0 0 .0 0 . 0 ’ />
8 </Appearance>
9 <Box/>
10 </Shape>
11 </Scene>
12 </X3D>
C´odigo 2.4: Um cen´ario simples em X3D, um cubo vermelho.
A linha 7 do C´odigo 2.4 define um n´o X3D Material referenciado pelo nome
COR atrav´es de um campo DEF. O campo diffuseColor pode ser acessado tanto
para a escrita como leitura de dados do tipo SFColor, um vetor de trˆes floats com
valor entre 0 e 1. Este nome COR servir´a de referˆencia para o player localizar
aquele n´o espec´ıfico dentro do grafo de cenas.
1 /∗
2 ∗ Programa : Cubo Vermelho , Cubo Verde
3 ∗ M odi fic a a cor de um cubo usando EAI
21
4 ∗ /
5 import vrml . e a i . f i e l d . EventInSFColor ;
6 import vrml . e a i . Node ;
7 import vrml . e a i . Br owserFactor y ;
8 import vrml . e a i . Browser ;
9 import j a va . net . Ine t A ddre s s ;
10
11 public c l a s s BoxEai {
12 public s t a t i c void main ( S t r i n g [ ] a r g s ) {
13 // d e c l a r a ¸c˜a o dos o b j e t o s
14 Browser browse r = nu ll ;
15 Node m a t er i a l = null ;
16 EventInSFColor corDoCubo = nu ll ;
17
18 // Conecta com ao Navegador VRML/X3D
19 try {
20 Inet A d dre s s e n d ere c o = Ine t A ddre s s . getByName ( ” l o c a l h o s t ”) ;
21 browse r = Br owserFact or y . ge tBrow se r ( en derec o , 484 8) ;
22 } catch ( Throwable tudo ) {}
23
24 // Pega uma r e f e r e n c i a ao campo d i f f u s e C o l o r do nodo m a t e r ial
25 m a t e r i a l = brows er . getNode ( ”COR”) ;
26 corDoCubo = ( EventInSFColor ) m a t e r i a l . g et Eve ntI n ( ” d i f f u s e C o l o r ”) ;
27
28 f l o a t [ ] novaCor = {0.0 f , 1 . 0 f , 0 . 0 f } ;
29 corDoCubo . s e t V alue ( novaCor ) ;
30
31 bro ws er . d i s p o s e ( ) ;
32 }
33 }
C´odigo 2.5: Acesso ao player de X3D e aos elementos do cen´ario em tempo de
execu¸c˜ao atrav´es do protocolo EAI.
As linhas 5 a 8 (C´odigo 2.5) s˜ao dependentes do player VRML/X3D uti-
lizado, atrav´es destas linhas inclu´ımos classes em java que permitem acessar o
cen´ario que o player estiver executando. Mais informa¸c˜oes podem ser conseguidas
na documenta¸c˜ao do player, para o InstantReality (nstantlabs).
A linha 14 declara um objeto do tipo browser que conter´a uma referˆencia
para acessarmos o player de X3D, a linha 15 declara um n´o gen´erico com o nome
material e a linha 16 declara um evento de entrada que recebe um SFColor. N´os
22
VRML/X3D podem emitir e receber eventos de determinados tipos.
A linha 21 tenta conectar ao player usando o m´etodo est´atico getBrowser
da classe BrowserFactory usando um endere¸co TCP/IP v´alido e a porta 4848, em
caso de sucesso ´e retornado uma referˆencia a um objeto do tipo browser.
Queremos agora ter acesso ao n´o COR que ´e do tipo Material e a seu campo
diffuseColor que aceita um evento de entrada do tipo EventInSFColor. A
linha 25 recupera a referˆencia ao n´o nomeado de COR por meio do m´etodo getN-
ode("COR") do objeto browser e atrav´es dela podemos conseguir uma referˆencia
ao evento de entrada do campo diffuseColor, linha 26.
A linha 28 define um vetor de trˆes floats com o conte´udo [0.0, 1.0, 0.0] que
nas coordenadas para RGB significa cor verde pura. A linha 29 gera o evento de
entrada referenciado por corDoCubo, com os dados do vetor da linha anterior. A
linha 31 tem a fun¸c˜ao de desconectar o programa do player.
2.3 InstantReality
O InstantReality ´e um player para X3D com recursos para computa¸c˜ao dis-
tribu´ıda e controle de dispositivos de entrada e sa´ıda espec´ıficos para RV, (instant-
labs, 2008). Ele ´e tamb´em um framework de alto desempenho para realidade mista
(RM) desenvolvido pelo Institut Graphische Datenverarbeitung (IGD) de Fraun-
hofer e Zentrum f
¨
ur Graphische Datenverarbeitung (ZGDV), ambos da Alemanha.
A proposta do InstantReality ´e fornecer aos desenvolvedores de Realidade Virtual
(RV) e Realidade Aumentada (RA) uma interface simples e consistente para desen-
volvimento r´apido de solu¸c˜oes de qualidade atrav´es de um conjunto de ferramentas
amig´aveis. As metas do InstantLabs, o grupo que desenvolve o InstantReality s˜ao:
renderiza¸c˜ao com alt´ıssimo realismo, intera¸c˜ao com o usu´ario e suporte a tecnolo-
gia de imers˜ao visual total. A caracter´ıstica mais importantes do InstantReality
para os desenvolvedores de solu¸c˜oes para RV ´e permitir que cenas sejam criadas
por modelagem e n˜ao apenas por programa¸c˜ao utilizando o VRML ou X3D.
23
2.3.1 Componentes X3D estendidos
Pela pr´opria defini¸c˜ao do X3D deduzimos que ele ´e um formato para grafos de
cenas que pode ser estendido. A especifica¸c˜ao ISO/IEC FDIS 19775-1:2008 define
um conjunto m´ınimo de 33 componentes funcionais: Core, Time, Networking,
Grouping, Rendering, Shape , Geometry3D, Geometry2D, Text, Sound, Light-
ing, Interpolation, Pointing, KeyDeviceSensor, PointingSeviceSensor,
EnvironmentalSensor, Navigation, EnvironmentalEffects, Geospatial, Hu-
manoidAnimation (H-Anim), NURBS, DistributedInteractiveSimulation (DIS),
Scripting, EventUtilities, Shader, CADgeometry, EnvironmentalTextur-
ing, Layering, Layout, RigidBodyPhysics, PickingSensor, Followers e Par-
ticleSystems.
O InstanReality estende este conjunto com os componentes, (instantlabs):
CollisionSensor (1), Combiner (3), DirectSensor (41), Engine (33), Mor-
phing (2), Operator (4), Physics (9), Simulator (5), Snapping (2), Steer-
ing (9), TreeSensor (3) e VolumeRendering (18). Entre parenteses est´a a
quantidade de tipos de n´os X3D.
Engine ´e um conjunto de componentes que fornece um grafo completamente
separado do grafo de cenas. Atrav´es deste grafo ´e poss´ıvel gerenciar a configu-
ra¸c˜ao dos componentes inclusive aqueles relacionados com a interface humana, os
aglomerados de computadores e sistemas multi-telas.
2.3.2 Escalabilidade
A estrutura do InstanReality inclui m´etodos para explorar todos os recursos
dispon´ıveis do hardware afim de otimizar a execu¸c˜ao da aplica¸c˜ao em tempo real:
• Multithread e auto-paralelismo: O sistema utiliza um m´etodo patenteado
para detectar em grafos os sub-grafos independentes, e ent˜ao executa-los
em paralelo.
• Cluster: Um algoritmo different sort-first/sort-last, (Roth et al., 2006),
distribui, em tempo real, a carga de renderiza¸c˜ao ao conjunto de n´os pre-
24
sentes. O m´etodo escala quase linearmente. O algoritmo permite aumentar
o desempenho total do sistema pela adi¸c˜ao de novos n´os de renderiza¸c˜ao.
• Multi-Resolu¸c˜ao: o framework possui recursos para criar e gerenciar es-
truturas de dados para multi-resolu¸c˜ao de pontos, malhas e volumes. Isto
permite aumentar o desempenho no controle da renderiza¸c˜ao e alcan¸car
objetivos globais da aplica¸c˜ao, mantendo uma boa taxa de atualiza¸c˜ao de
40 a 60 imagens por segundos (FPS).
2.3.3 Interoperabilidade
Os recursos computacionais para sistemas distribu´ıdos do framework fornecem
interfaces de rede s´ıncrona e ass´ıncrona, de alto desempenho, para transferˆencia de
dados para a aplica¸c˜ao em tempo real. O InstantReality permite muitas maneiras
de se controlar e manipular a aplica¸c˜ao em execu¸c˜ao. Al´em dos protocolos como
SOAP e HTTP, um protocolo EAI podem ser utilizados para o desenvolvimento
de avan¸cadas interfaces com o usu´ario, o protocolo SAI encontra-se em fase inicial
de implanta¸c˜ao.
2.3.4 Independˆencia de Dispositivos de Entrada e Sa´ıda
O sistema InstantReality fornece v´arios n´ıveis de abstra¸c˜ao para o controle de
dispositivos de entrada e sa´ıda. As classe espec´ıficas para dispositivos permitem
tanto o acesso ao fluxo de dados (data streams) de baixo n´ıvel dos dispositivos
como recursos de alto n´ıvel independente do dispositivo f´ısico.
2.3.5 Conformidade com Padr˜oes
O projeto do InstantReality inclui v´arios padr˜oes industriais para facilitar o
processo de desenvolvimento das aplica¸c˜oes:
OpenGL 2.0 (Khronos Group)
GLSL (Khronos Group)
CG (NVIDIA Corporation)
25
X3D (ISO/IEC 19775:2004)
ECMAScript (ISO/IEC 16262:2002)
JAVA (Sun Corporation)
SOAP (W3D SOAP V1.2)
ZEROCONF (IETF Zeroconf WG)
2.4 Introdu¸c˜ao `a Visualiza¸c˜ao Cient´ıfica
A primeira defini¸c˜ao de Visualiza¸c˜ao Cient´ıfica surgiu em 1987 no relat´orio
”Visualization in Scientific Computing”, (McCormick et al., 1987). A visualiza¸c˜ao
´e uma ´area de pesquisa que evoluiu a partir da Computa¸c˜ao Gr´afica, e estuda
estrat´egias e algoritmos para mapear informa¸c˜oes num´ericas em representa¸c˜oes
gr´aficas (Rosenblum et al., 1994). Recentemente alguns aplicativos destinados a
visualiza¸c˜ao cient´ıfica passaram a incorporar recursos e t´ecnicas de Realidade Vir-
tual tornando poss´ıvel a imers˜ao, a navegabilidade avan¸cada entre os dados, a
descri¸c˜ao de dados atrav´es de imagens em multi-resolu¸c˜ao e a gera¸c˜ao de ima-
gens em tempo real. Tecnologias desenvolvidas em RV permitem a constru¸c˜ao de
interfaces sofisticadas entre pesquisadores e aplica¸c˜oes destinadas `a visualiza¸c˜ao
cient´ıfica.
O objeto de estudo da Biologia ´e multiescala no espa¸co e no tempo, altamente
diverso, complexo, dinˆamico e ainda n˜ao totalmente entendido. Grandes descober-
tas em ciˆencias biol´ogicas deram-se atrav´es do desenvolvimento de equipamentos
e t´ecnicas que expandiram nossa capacidade de vis˜ao, entre eles a inven¸c˜ao do
microsc´opico ´otico que revelaram aos biologistas um desconhecido mundo povoado
de seres antes invis´ıveis. Outros equipamentos permitiram alcan¸car escalas ainda
menores, 0,1 nm, como o Microsc´opio de For¸ca Atˆomica (MFA), (Cohen e Light-
body, 1999). Entretanto, os dados coletados precisam passar por tratamento
matem´atico e atrav´es deles o computador cria uma representa¸c˜ao virtual do ob-
jeto. As t´ecnicas de cristalografia e difra¸c˜ao de raio-X (Kendrew et al., 1958)
possibilitam determinar precisamente, por m´etodos matem´aticos, a posi¸c˜ao espa-
26
cial de cada ´atomo de uma prote´ına. Mas para a visualiza¸c˜ao destas estruturas ´e
necess´ario recorrer a um sistema de visualiza¸c˜ao cient´ıfica.
N˜ao ´e apenas na escala microsc´opica ou nanosc´opica que a visualiza¸c˜ao ci-
entifica ´e ´util `a Biologia. Imagens de sat´elites criadas a partir de sensores para
luz vis´ıvel ou infravermelho, (Davis e Monteiro, 2006), permitem aos cientistas
monitorar as condi¸c˜oes bi´oticas e abi´oticas do planeta Terra como a dinˆamica das
florestas provocada, em sua maioria, pela dispers˜ao humana. Outros exemplos do
emprego de t´ecnicas de visualiza¸c˜ao cient´ıfica s˜ao os softwares para as m´aquinas
de tomografia computadorizadas (TC) (Webb, 2003a), e ressonˆancia nuclear mag-
n´etica (RNM) (Webb, 2003b), capazes de criar imagens do interior de organismos
vivos sem danific´a-los. Temos ainda as ferramentas de software para visualiza¸c˜ao de
sequˆencias de caracteres que representa os ´acidos desoxirribonucleicos (DNAs) de
um indiv´ıduo: o genoma ou parte dele e suas respectivas informa¸c˜oes de anota¸c˜ao
que descreve a fun¸c˜ao de um fragmento de c´odigo (Stein, 2003).
2.4.1 Visualiza¸c˜ao de Estrutura de Prote´ınas
Visualiza¸c˜ao de estruturas tridimensionais de prote´ınas ´e um caso cl´assico
de utiliza¸c˜ao das t´ecnicas de Visualiza¸c˜ao Cient´ıfica em Biologia. Em 1971 foi
fundado pelos Dr. Edgar Meyer e Walter Hamilton o Protein Data Bank (PDB),
um reposit´orio para dados de estruturas 3D de prote´ınas e ´acidos nucleicos. Estes
dados s˜ao tipicamente obtidos por cristalografia de Raio-X ou por espectroscopia
de NMR (Wuthrich, 1990) e submetidos por bi´ologos e bioqu´ımicos de todas as
partes do mundo. Os dados, de dom´ınio p´ublico, podiam ser acessados sem custo,
disponibilizados inclusive por uma conex˜ao via linha telefˆonica e modem com taxa
m´axima de 4.000 bits/s.
O conte´udo de um arquivo PDB descreve, al´em de outras informa¸c˜oes rel-
evantes, as coordenadas tridimensionais dos ´atomos que comp˜oem uma prote´ına
(pdb, 2008). Existe uma s´erie de softwares que renderizam um modelo que rep-
resenta a prote´ına atrav´es dos dados contidos em um arquivo *.pdb, sendo jmol
27
(Community) e chimera (UCSF) dois exemplos. O software UCSF CHIMERA
possui recursos para acessar diversas bases de dados na Internet, renderizar ce-
nas descritas pelos dados baixados em diferentes estilos configur´aveis e exportar
estas cenas no formato X3D ou VRML atrav´es de um passo adicional de conver-
s˜ao. Jmol (Community) ´e escrito inteiramente em Java e pode ser incorporado
a qualquer aplicativo Java ou at´e mesmo a uma p´agina em HTML. Entretanto,
o recurso para exportar cenas em VRML ´e limitado, pois esta em fase inicial de
desenvolvimento.
A visualiza¸c˜ao de modelos de prote´ınas em CAVEs pode tornar o trabalho
de cientistas envolvidos no desenvolvimento de novos medicamentos mais eficiente,
devido ao maior grau de imers˜ao visual do pesquisador no modelo, fixando sua
concentra¸c˜ao apenas naquele mundo virtual. Desenvolver um software totalmente
novo capaz de transformar um arquivo PDB em uma descri¸c˜ao VRML ou X3D com
capacidades similares ao do Jmol ou Chimera est´a fora do escopo deste trabalho,
mas um relativa integra¸c˜ao entre o software Chimera e uma aplica¸c˜ao ´e plaus´ıvel
e ser´a descrita no Capitulo 5.
28
Cap´ıtulo 3
Estrutura F´ısica
O sistema CAVE do LNCC foi projetado pelo engenheiro Fran¸cois Maltric
e a constru¸c˜ao foi executada com aux´ılio da equipe do ACiMA. A disposi¸c˜ao dos
principais componentes ao final da montagem esta na Figura 3.1. Os n´umeros 1 a
8 referem-se ao projetores e os n´umeros 9 a 12 aos espelhos.
Figura 3.1: Planta baixa do CAVE do LNCC: Disposi¸c˜ao dos componentes como
telas de proje¸c˜ao, espelhos, usu´ario, projetores, emissor do tracker e computadores
PCs.
29
3.1 Telas de proje¸c˜ao
Empregamos trˆes telas do tipo Stewart Disney Black para proje¸c˜ao por tr´as
nas paredes, com 2,46 m de altura por 1,85 m de largura e uma tela Silver Screen
para proje¸c˜ao direta, no piso, de 1,85 m de largura por 1,38 m de altura. A carac-
ter´ıstica principal destas telas ´e a preserva¸c˜ao da polariza¸c˜ao da luz que permite a
separa¸c˜ao das imagens do olho esquerdo daquelas do olho direito, mediante o uso
adequado de filtros ´oticos. O arranjo dos planos de proje¸c˜ao formados pelas telas
esta ilustrado na Figura 3.2
Figura 3.2: Arranjo espacial das quatro telas de proje¸c˜ao do CAVE.
Para a fixa¸c˜ao das telas constru´ımos uma estrutura com tubos PVC rosque´aveis
de uso comum em instala¸c˜oes hidr´aulicas residenciais, al´em de uma base de madeira.
Materiais ferrosos foram evitados para permitir o emprego de sensores de campo
magn´etico para determinar posi¸c˜oes e orienta¸c˜oes do usu´ario dentro do ambiente
delimitado pelas telas de proje¸c˜ao.
30
3.2 Projetores
Utilizamos oito projetores de DLP NEC LT245 (NEC, a) com resolu¸c˜ao
nativa 1024x768 pixels, freq
¨
uˆencia vertical m´axima de 120Hz e brilho 2200 Lumens,
n´ıvel de contraste ajust´avel 2000:1 montados em suportes de alum´ınio e providos
de filtros ´oticos polarizadores. Este modelo de projetor foi escolhido durante o
projeto do CAVE, devido `a abertura do feixe de luz o qual ´e suficiente para cobrir
o espa¸co de tela de proje¸c˜ao. Para permitir um ajuste fino dos feixes de luz dos
projetores nas telas foram desenhados dois conjuntos de suportes.
Quatro suportes em alum´ınio foram confeccionados para acomodar dois pro-
jetores e dois filtros ´oticos cada. Os suportes para os projetores referentes `as telas
da direita, centro e esquerda possuem a estrutura ilustrada na Figura 3.3. Para
a proje¸c˜ao na tela do piso os projetores foram fixados no teto como mostra a
Figura 3.4. Trˆes conjuntos de projetores tiveram que ser montados na posi¸c˜ao
vertical para melhor aproveitar a ´area ´util dispon´ıvel.
A Figura 3.5 ilustra as fotos das estruturas completamente montadas. Na
Figura 3.5-a a estrutura ´e fixada no teto da sala que aloja o CAVE o sinal luminoso
´e refletido por um espelho, descrito na pr´oxima se¸c˜ao, e atinge a tela do piso
formando a imagem na superf´ıcie da mesma. Os outros suportes s˜ao apoiados no
piso, Figura 3.5-b e suas localiza¸c˜oes podem ser vistas na Figura 3.1.
3.3 Filtros para Polariza¸c˜ao
A utiliza¸c˜ao de dois projetores por tela de proje¸c˜ao requer o uso de filtros
´oticos para prover um mecanismo de separa¸c˜ao entre as imagens. Para cada parede
de proje¸c˜ao s˜ao sintetizadas, pelo sistema de renderiza¸c˜ao, duas imagens e proje-
tadas ao mesmo tempo, uma destinada ao olho esquerdo e outra destinada ao olho
direito; a imagem correspondente ao olho esquerdo dever´a sensibilizar com boa
intensidade o olho esquerdo e ser completamente atenuada para o olho direito. A
mesma regra se aplica a imagem gerada para o olho direito, que sensibilizar´a ape-
nas o olho direito. O emprego de filtros ´oticos de polariza¸c˜ao circular garantem o
31
Figura 3.3: Suporte dos projetores das telas do centro, da esquerda e da direita.
Distˆancias em mm.
Figura 3.4: Suporte dos projetores da tela do piso, fixado no teto.
correto endere¸camento das imagens aos olhos e permite ao usu´ario a liberdade de
32
Figura 3.5: Fotos dos suportes para os projetores: (a) suporte dos projetores para
tela do piso, fixado no teto; (b) suporte referente as telas da esquerda, centro e
direita.
Figura 3.6: Filtros ´oticos de polariza¸c˜ao circular: (a) filtro polariza¸c˜ao circular
sentido hor´ario; (b) filtro polariza¸c˜ao circular sentido anti-hor´ario; (c) ´oculos con-
feccionados com filtros de polariza¸c˜ao.
inclinar a cabe¸ca sem preju´ızo `as filtragens. Um filtro ´e montado junto ao proje-
tor, e seu conjugado, no formato de um ´oculos, ´e posicionado pr´oximo ao olho do
usu´ario (Figura 3.6). Se empreg´assemos filtros ´oticos para polariza¸c˜ao linear um
simples movimento de inclina¸c˜ao da cabe¸ca do usu´ario desalinharia o eixo ´otico
33
do filtro ao plano de propaga¸c˜ao da luz e ter´ıamos a perda imediata das filtragens
e consequentemente da vis˜ao est´ereo. Na polariza¸c˜ao circular o plano de propa-
ga¸c˜ao tem um componente rotacional, e assim movimentos da cabe¸ca do usu´ario
n˜ao acarretam em perda de sensa¸c˜ao visual 3D.
3.4 Espelhos
O espa¸co destinado `a montagem do CAVE n˜ao permitia o posicionamento
dos projetores a uma distˆancia adequada das telas, obrigando-nos a utilizar espel-
hos. Para preservar a polariza¸c˜ao circular da luz foi necess´ario empregar espelhos
planos de metal polido montados tamb´em em suportes ajust´aveis confeccionados
em alum´ınio. Na Figura 3.7 a posi¸c˜ao indicada por P 1 mostra a posi¸c˜ao onde
deveria estar posicionado o par de projetores caso n˜ao empreg´assemos o espelho
E1.
A luz polarizada circular, ao ser refletida, sofre invers˜ao no sentido de rota¸c˜ao
do vetor que descreve o campo el´etrico. Entretanto este fenˆomeno n˜ao apresenta
um problema e para a corre¸c˜ao simplesmente utilizamos pares de filtros conjugados,
isto ´e, para recuperar a imagem produzida por um filtro de polariza¸c˜ao circular
direita usamos um filtro para polariza¸c˜ao esquerda. A Figura 3.7 tamb´em ilustra
a posi¸c˜ao de cada espelho, indicados por E1, E2, E3 e E4.
3.5 Infraestrutura Computacional
Para alcan¸car o desempenho desejado optamos pela montagem de um cluster
de cinco computadores interconectados por uma rede gigabit. Todos os computa-
dores possuem as seguintes configura¸c˜oes: processadores Intel Core 2 Quad de
3Ghz, 4 Gbytes de memoria RAM, placa de rede Gigabit Ethernet e duas placas
gr´aficas NVIDIA 9800 GTX+ ligadas em SLI, Figura 3.8.
Quatro computadores foram utilizados para a conex˜ao aos oito projetores.
As placas de v´ıdeo NVIDIA 9800 GTX+ possuem duas sa´ıdas DVI que s˜ao conec-
tadas a um par de projetores. Para cada computador foi ajustado uma ´area total
34
Figura 3.7: Distˆancia adequada entre projetores e telas corrigidas com a utiliza-
¸c˜ao de espelhos, E1, E2, E3 e E4. P1 representa a posi¸c˜ao onde deveria estar
posicionado o par de projetores caso n˜ao fosse utilizado o espelho E1.
de imagem de 2048x768 pixels, resultado do alinhamento horizontal das duas sa´ıdas
de 1024x768 pixels. Ent˜ao, cada projetor do par correspondente possui uma ´area
de imagem de 1024x768 pixels e o posicionamento de janelas neste espa¸co pode
ser feito da seguinte maneira. Um dos projetores do par gera a imagem correspon-
dente as coordenadas de tela entre [0, 0; 1023, 769] e o outro entre as coordenadas
[1024, 0; 2047, 769]. A utiliza¸c˜ao de quatro computadores conectados permitem ex-
pandir a ´area de imagem para 8192x768 pixels. Detalhes est˜ao no Cap´ıtulo 4,
Figura 4.4-a.
35
Figura 3.8: Estrutura computacional com m´ultiplos projetores para o CAVE do
LNCC.
A utiliza¸c˜ao de aglomerados de computadores para aumentar a resolu¸c˜ao da
´area de renderiza¸c˜ao exige o emprego de redes de comunica¸c˜ao com velocidades de
transferˆencias de dados compat´ıveis. Por exemplo, para transferir os dados sem
compress˜ao referente a uma imagem de 512x768 pixels, 24 bits de cores e taxa de
atualiza¸c˜ao de 60 vezes por segundo precisar´ıamos de uma banda passante efetiva
de 567Mbits/seg. Em geral a eficiˆencia m´axima de uma rede ´e da ordem de 70 %
e numa rede de 100Mbits/s a imagem acima s´o poderia ser atualizada 8 vezes por
segundo o que comprometeria a sensa¸c˜ao de imers˜ao. Para atingir um desempenho
aceit´avel seria necess´ario empregar uma rede Gigabit Ethernet ou melhor.
O quinto computador foi empregado para controlar os dispositivos para nave-
ga¸c˜ao e rastreamento do usu´ario dentro do ambiente. Para controlar a navega¸c˜ao
empregamos inicialmente um joystick, entretanto o emprego de um mouse 3D sem
fio seria desej´avel. O computador de controle tamb´em ´e respons´avel pelo acesso
aos dados do rastreador magn´etico, discutido a seguir, e pelo controle das trans-
36
forma¸c˜oes geom´etricas de todas as imagens devido ao deslocamento do usu´ario
dentro do ambiente, al´em de coordenar a distribui¸c˜ao da carga de renderiza¸c˜ao aos
servidores.
3.6 Rastreador de Posi¸c˜ao e Orienta¸c˜ao
Rastreadores de posi¸c˜oes e orienta¸c˜oes Trackers permitem monitorar a posi¸c˜ao
e orienta¸c˜ao de sensores colocados em partes selecionadas do corpo de um usu´ario.
Trackers tamb´em s˜ao chamados de dispositivos com 6-graus-de-liberdade, 6-degree-
of-freedom (6-DOF) porque s˜ao capazes de informar a posi¸c˜ao referentes as coor-
denadas x, y, z, bem como a inclina¸c˜ao referente a cada um dos eixos x, y, z em
rela¸c˜ao a um referencial fixo.
Trackers podem ser constru´ıdos baseados em dispositivos mecˆanicos, ´oticos,
eletromagn´eticos, ac´usticos, dentre outros (Burdea e Coiffet, 1994). No ambiente
CAVE discutido neste documento foi empregado um tracker eletromagn´etico da
Ascension Technology Corporation (technology Corporation) modelo NestOfBirds
RS232 com alcance estendido para 2,44 m capaz de monitorar at´e 4 sensores simul-
taneamente. Os sensores s˜ao formados por trˆes bobinas dispostas em posi¸c˜oes per-
pendiculares montadas em pequenas unidades que s˜ao presas ao corpo do usu´ario.
O transmissor emite um campo magn´etico e a rela¸c˜ao entre as correntes el´etricas
geradas nas bobinas do sensor ´e determinada pela distˆancia e orienta¸c˜ao em re-
la¸c˜ao ao transmissor. Este sistema tem como inconveniente uma baixa tolerˆancia
a interferˆencias, que pode ser reduzida com o uso de materiais n˜ao ferrosos sendo
o alum´ınio uma boa op¸c˜ao, se desconsiderarmos o custo.
Na Figura 3.9 ilustramos o processo de corre¸c˜ao que deve ocorrer quando o
observador se desloca lateralmente no ambiente. Quando o usu´ario esta na posi¸c˜ao
P
1
a imagem correspondente a renderiza¸c˜ao do objeto arvore O ´e I
1
e quando o
observador se encontra na posi¸c˜ao P
2
a imagem deve estar na posi¸c˜ao I
2
.
A necessidade de utiliza¸c˜ao de tracker est´a relacionada com dois fatores im-
portantes. O primeiro e mais importante ´e que a distˆancia do observador `a tela
37
afeta o efeito de estereoscopia. Quanto maior a distˆancia `a tela, maior ser´a o
efeito estereosc´opico, tanto em paralaxe positiva quanto em negativa, e o deslo-
camento lateral provoca no usu´ario a sensa¸c˜ao de que o objeto tamb´em se move.
Para minimizar este efeito, as imagens precisam sofrer uma transforma¸c˜ao antes
de serem projetadas, esta transforma¸c˜ao ´e calculada com base na posi¸c˜ao dos olhos
do usu´ario dentro do ambiente.
Outro fator que justifica a utiliza¸c˜ao do tracker ´e seu uso para intera¸c˜ao com
o usu´ario. Ao saber onde se encontram as m˜aos do usu´ario o ambiente sint´etico
poderia reagir em resposta a gestos executados, desta forma permitindo o desen-
volvimento de sistemas de intera¸c˜ao mais naturais ao usu´ario. Um exemplo seria
o observador deslocar uma cadeira no mundo virtual usando as pr´oprias m˜aos.
Figura 3.9: Transforma¸c˜oes na imagem provocada pelo deslocamento do obser-
vador.
38
3.7 Alinhamento f´ısico
Para alinhar os feixes de luz dos projetores `as telas correspondentes, dois de-
talhes b´asicos precisam ser respeitados. Alinhar de modo a preencher totalmente
as telas com as imagens e ajustar os eixos verticais e horizontais paralelamente.
A utiliza¸c˜ao do recurso de keystone que permite posicionar o projetor em ˆangulo
sobre a superf´ıcie de proje¸c˜ao por meio da compress˜ao em parte da imagem. en-
tretanto, este recurso provoca distor¸c˜ao nas imagens e, devido ao deslocamento no
posicionamento entre os projetores de cada tela. A solu¸c˜ao encontrada foi posi-
cionar as proje¸c˜oes conforme a Figura 3.10-c. Este arranjo provoca perda de res-
olu¸c˜ao, mas evita deforma¸c˜ao nas imagens, apenas a interse¸c˜ao entre as proje¸c˜oes
´e utiliz´avel.
39
Figura 3.10: Alinhamento f´ısico das proje¸c˜oes: (a) proje¸c˜oes n˜ao alinhadas; (b)
eixos horizontais e verticais perpendiculares, alinhamento parcial; (c) condi¸c˜ao
final para o alinhamento f´ısico.
40
Cap´ıtulo 4
Elementos de Software
Desenvolver um software que controle os aspectos necess´arios para opera¸c˜ao
de um CAVE ´e uma tarefa complexa. Existe uma s´erie de APIs que podem auxil-
iar na escrita de um motor de controle, mas CAVE ACiMA possui caracter´ısticas
particularidades que exigiram um tratamento espec´ıfico, rejeitando assim op¸c˜oes
tradicionais de implementa¸c˜ao. Os elementos principais a serem tratados foram:
o emprego de um sistema distribu´ıdo para renderiza¸c˜ao de imagens, trˆes pares de
projetores dispostos em posi¸c˜ao vertical, uma tela de proje¸c˜ao n˜ao ortogonal `as
demais, resolu¸c˜ao distintas entre telas e o alinhamento horizontal da linha m´e-
dia dos projetores n˜ao era correspondente em todas as telas. Outra preocupa¸c˜ao
era facilitar o desenvolvimento de aplica¸c˜oes finais por programadores iniciantes
ocultando toda a complexidade do ambiente.
Neste cap´ıtulo discutiremos quais s˜ao os elementos essenciais para o CAVE
ACiMA e como implement´a-los usando o X3D. O c´odigo fonte completo em X3D
discutido aqui est´a no Anexo 1. O anexo 2 cont´em c´odigo em Java e em lin-
guagem C parcial. Entretanto, todos estes componentes de softwares poderiam
ter sido implementados totalmente em linguagem C/C++ com auxilio da API
gr´afica OpenGL e de uma API para acesso a recursos de redes, mais tal op¸c˜ao
foi descartada devido ao limite de tempo dispon´ıvel para o desenvolvimento deste
trabalho.
41
4.1 Vis˜ao Geral dos Elementos
A Figura 4.1 ilustra os elementos l´ogicos e suas rela¸c˜oes para o CAVE
ACiMA. Os elementos est˜ao organizados em uma estrutura de dados do tipo grafo,
dividido em dois subgrafos com fun¸c˜oes distintas Engine e Scene. Engine cont´em os
elementos l´ogicos que controlam a renderiza¸c˜ao das imagens de modo coerente nas
quatro telas, gerando imagens do mundo virtual de quatro perspectivas distintas,
al´em do controle da comunica¸c˜ao e o balanceamento de carga de processamento
entre as m´aquinas, e do monitoramento da posi¸c˜ao do usu´ario dentro do ambiente.
Todos os elementos constituintes do bloco Engine precisam completar suas respec-
tivas tarefas a cada atualiza¸c˜ao da imagem nas telas. O subgrafo Scene cont´em
todos os elementos que n˜ao s˜ao necess´arios para o controle de renderiza¸c˜ao e o
player de X3D cria um processo separado para seu processamento.
A raiz do grafo X3D define um arquivo XML do tipo X3D que contem dois
grupos Engine e Scene. O grupo engine cont´em n´os exclusivos para o player
InstantPlayer e o carregamento deste arquivo em um player diferente resultar´a
apenas na execu¸c˜ao do subgrafo Scene, ou poder´a causar um erro de execu¸c˜ao.
4.2 O Subgrafo Scene
Inline ´e um componente de rede do X3D que permite incluir cenas VRM-
L/X3D, na cena corrente, provenientes da World Wide Web ou de uma m´aquina
local. Todas as cenas carregadas pelo n´o Inline s˜ao renderizadas adequadamente
pelo motor Engine que renderiza quatro imagens distintas em est´ereo e distribui
aos computadores conectados aos projetores, n˜ao sendo necess´ario que o desen-
volvedor ajuste o c´odigo de arquivo X3D ou VRML para que este seja visualizado
no CAVE do LNCC. No IntantPlayer ´e poss´ıvel carregar tamb´em arquivos do tipo
.OBJ, nativo do software de modelagem Maya.
Cen´arios externo podem ser criados para permitir a intera¸c˜ao do usu´ario
de dentro do CAVE. Estes cen´arios formados por elementos gr´aficos de interfaces
como menus, caixas de textos e bot˜oes permitiriam carregar modelos de objetos
42
Figura 4.1: Componentes do software de controle para o CAVE do LNCC, as linhas
finas representam os ROUTEs.
e controlar aspectos de ilumina¸c˜ao ou transparˆencia. No Cap´ıtulo 5 daremos um
exemplo simples de uma aplica¸c˜ao de controle deste tipo.
IOSensor ´e o n´o pelo qual podemos acessar os dados de qualquer dispositivo
de entrada e/ou sa´ıda suportado pelo InstantReality. Um recurso do InstantReality
o InstantIO Web Interface, fornece os nomes e os tipos de dados vinculados a cada
recurso de um dispositivo de IO, Figura 4.2.
43
Figura 4.2: Interface de Rede do InstantPlayer: Web Interface Device Manage-
ment. O Exemplo ilustra o dispositivo joyStick.
Alguns destes OutSlots s˜ao conectados atrav´es de ROUTE aos InSlots dos
nodos NavigationInfo e Viewpoint que controlam a navega¸c˜ao e o ponto de visu-
aliza¸c˜ao respectivamente.
NavigationInfo e Viewpoint s˜ao preferencialmente componentes dos cen´arios
externos, pois os modos de navega¸c˜ao s˜ao particulares ao mundo virtual descrito.
Por exemplo, o evento humano de caminhar requer paramentros de velocidades e
acelera¸c˜ao distintos a uma navega¸c˜ao por meio de um veiculo a´ereo. O C´odigo 4.1
ilustra esta id´eia.
1 . . .
2 <Scene>
3 <IOSensor DEF=” i o s ” type=” j o y S t i c k ”>
44
4 <f i e l d acc essTy pe= ’ outputOnly ’ name= ’ ∗ x∗ a x i s ’ ty pe=’ SFFloat ’ />
5 <f i e l d acc essTy pe= ’ outputOnly ’ name= ’ ∗ y∗ a x i s ’ ty pe=’ SFFloat ’ />
6 <f i e l d acc essTy pe= ’ outputOnly ’ name= ’ ∗ z ∗ a x i s ’ type= ’ SFFloat ’ />
7 <f i e l d acc essTy pe= ’ outputOnly ’ name= ’ ∗ z ∗ r o t ∗ ’ t yp e= ’ SFFloat ’ />
8 <f i e l d acc essTy pe= ’ outputOnly ’ name= ’ ∗ button ∗ 7 ’ ty pe=’ SFBool ’ />
9 </IOSensor>
10
11 <NavigationInfo type= ’ ”walk ” ”any ” ’>
12 <SteerNavigator DEF= ’ nav ’ inputRange= ’ 0 1 ’ z e r o D e f l e ct i o n T r a n s=’ 0 . 5 0 . 5
0 . 5 ’ z e r o D e f l e c t i on R o t= ’ 0 . 5 0 . 5 0 . 5 ’ r o t a t i o n S p e e d= ’ −0.2 −0.2 −0.2 ’
t r a n s l a t i o n S p e e d= ’ 1 . 0 1 . 0 1 .0 ’ />
13 </NavigationInfo>
14
15 <ROUTE fromNode=’ i o s ’ f r o mFie l d= ’ ∗ y∗ a x i s ’ toNode= ’ nav ’ t o F i e l d= ’
s e t x R o t a ti o n ’ />
16 <ROUTE fromNode=’ i o s ’ f r o mFie l d= ’ ∗ x∗ a x i s ’ toNode= ’ nav ’ t o F i e l d= ’
s e t y R o t a ti o n ’ />
17 <ROUTE fromNode=’ i o s ’ f r o mFie l d= ’ ∗ z ∗ a x i s ’ toNode=’ nav ’ t o F i e l d= ’
s e t x T r a n s l a t i o n ’ />
18 <ROUTE fromNode=’ i o s ’ f r o mFie l d= ’ ∗ z ∗ r o t ∗ ’ toNode=’ nav ’ t o F i e l d= ’
s e t z T r a n s l a t i o n ’ />
19
20 <ROUTE fromNode=’ i o s ’ f r o mFie l d= ’ ∗ butt on ∗ 7 ’ toNode=’ nav ’ t o F i e l d= ’
updat eRo tat ionCe nte r ’ />
21 . . .
22 </Scene>
23 . . .
C´odigo 4.1: C´odigo parcial dos elementos do subgrafo Scene. Neste exemplo temos
o mapeamento da entrada do joystick para opera¸c˜ao de navega¸c˜ao (deslocamento
de Viewpoint)
4.3 O Subgrafo Engine
O princ´ıpio de funcionamento de um CAVE est´a baseado na correspondˆencia
de parˆametros do modelo de cˆamera no espa¸co virtual com a posi¸c˜ao relativa
dos olhos do observador em rela¸c˜ao aos v´ertices das telas de proje¸c˜ao no espa¸co
do usu´ario. O deslocamento do usu´ario dentro do ambiente requer um sistema
dinˆamico para o controle das proje¸c˜oes. Num primeiro momento trˆes componentes
s˜ao necess´arios para que o CAVE ACiMA funcione, s˜ao eles: ajuste do sistema
45
distribu´ıdo, alinhamento de oito viewports, e calibra¸c˜ao das oito cˆameras. Todos
estes elementos relacionados s˜ao ajustados por meio de um ´unico arquivo X3D que
chamaremos ECAVE.X3D sua listagem completa esta no Anexo 1.
4.3.1 O sistema de proje¸c˜ao distribu´ıdo
O sistema de proje¸c˜ao ´e formado por quatro servidores de telas com resolu¸c˜ao
de 2048x768 pixel cada e um cliente o qual controla todas as opera¸c˜oes dos servi-
dores. Toda a arquitetura ´e baseada no recurso de Clustering do InstantPlayer
atrav´es do n´o X3D ClusterWindow que permite estender a resolu¸c˜ao e balancear a
carga de renderiza¸c˜ao quando necess´ario. A configura¸c˜ao deste recurso ´e facilitada
devido `a conformidade do InstantReality com o padr˜ao industrial IETF Zeroconf
WG, bastando apenas indicar qual a resolu¸c˜ao final da tela, os nomes dos servi-
dores, a disposi¸c˜ao ou alinhamento dos dispositivos de tela e habilitar ou n˜ao a
distribui¸c˜ao de carga de renderiza¸c˜ao no computador cliente, C´odigo 4.2.
1 . . .
2 <ClusterWindow serv er s=’ ”ca ve 1 ” ”cave2 ” ”c av e3 ” ”cave4 ” ’ hServers=”4 ” vServers=”1 ”
s i ze=”8192 768 ” balance=” t r u e ” showBal ancing=” f a l s e ”>
3 . . .
4 </ClusterWindow>
5 . . .
C´odigo 4.2: Ajuste do aglomerado de computadores.
Sistemas distribu´ıdos para renderiza¸c˜ao em m´ultiplos projetores s˜ao comuns
em aplica¸c˜oes para computa¸c˜ao gr´afica. A vantagem desta t´ecnica ´e a obten¸c˜ao de
uma alta resolu¸c˜ao a um custo modesto, porem como cada computador ´e respon-
s´avel por uma ´area exclusiva da imagem a eficiˆencia esta limitada ao computador
com a maior carga de renderiza¸c˜ao. Para contornar este problema podemos dis-
tribuir a carga quase que igualmente a todos os computadores atrav´es do recurso
de balanceamento de carga do InstantReality que utiliza um algoritmo Different
sort-first/sort-last, veja o campo balance, linha 2, no c´odigo 4.2. Se habilitarmos a
op¸c˜ao showBalancing o sistema vai informar como a carga esta sendo distribu´ıda.
46
A desvantagem desta configura¸c˜ao ´e a elevada carga de rede provocada pela
intensa troca de dados de imagens entre os servidores. Uma estimativa superficial
da carga pode ser feita analisando-se um caso particular. Supondo uma carga de
renderiza¸c˜ao dividida igualmente entre dois computadores, um deles esta acoplado
a uma tela com resolu¸c˜ao 1024x768 px e profundidade de cor de 24bits, cada
computador ´e respons´avel por renderizar metade da imagem 512 x 768 px x 24
bits resultando em 9.437.184 bits. O computador que n˜ao esta acoplado a tela ter´a
de enviar cerca de 10Mbits para o computador conectado a tela, isto a cada nova
atualiza¸c˜ao da imagem (frame). Em uma rede de 100Mbits/s temos uma taxa
efetiva de no m´aximo 70MBits/s e consequentemente 7,42 frames por segundo
(fps), em uma rede gigabit poder´ıamos ter 74,2 fps.
Na linha 2 do C´odigo 4.2 o n´o ClusterWindow informa ao InstantPlayer que
o sistema de janelas est´a estendido entre as m´aquinas declaradas no campo servers.
cave1, cave2, cave3 e cave4 devem estar executando obrigatoriamente o software
InstantCluster. Os campos hServers e vServers determina a disposi¸c˜ao espacial
relativa das ´areas de telas dos servidores conforme a Figura 4.3. A resolu¸c˜ao
alcan¸cada com esta configura¸c˜ao ´e a soma das resolu¸c˜oes de cada servidor, campo
size, totalizando ent˜ao 8192x768 pixels.
Figura 4.3: Arranjo das ´areas de telas dos servidores, determinado pelos valores
dos campos hserver="4" e vServer="1" do n´o ClusterWindow. Na figura temos
um resolu¸c˜ao total de 8192x768.
4.3.2 Alinhamento das ´areas de imagens
Uma condi¸c˜ao para que a estereoscopia funcione adequadamente ´e a corre-
spondˆencia, pixel a pixel, dos pontos das duas imagem em cada tela de proje¸c˜ao.
Para executar este alinhamento foi desenvolvido um programa em Java que per-
47
mite deslocar e redimensionar imagens padr˜ao para alinhamento. Foram utilizadas
duas imagens, uma vermelha e outra verde, ambas com detalhes de linhas em preto,
vide Figura 4.4-c. Quando estas duas imagens encontravam-se alinhadas formava-
se uma imagem de cor amarela com os detalhes apenas em preto. Segmentos de
imagens vermelhas ou verdes indicavam divergˆencias entre os alinhamentos do par
de projetores correspondente a uma parede do CAVE.
A Figura 4.4-a ilustra os oito monitores, M1 a M8, conectados aos quatro
computadores. Para cada monitor existe um projetor correspondente, P1 a P8.
Na Figura 4.4-b as imagens s˜ao sobrepostas duas a duas e projetadas nas quatro
paredes do CAVE, para permitir a visualiza¸c˜ao simultˆanea nas telas de proje¸c˜ao
do CAVE e nos monitores foi empregado um dispositivo eletrˆonico video splitter
que permite dividir em dois os sinais el´etricos das placas de v´ıdeo para permitir
visualiza¸c˜ao simultˆanea nos monitores e nas telas.
Os dados coletados do alinhamento podem ser vistos na Tabela 4.1. Na tabela
a coluna Posi¸c˜ao corresponde `as coordenadas de tela x : y em pixels, as colunas
Altura e Largura referente ao espa¸co de tela tamb´em em pixels. A coluna Perda
expressa a perda de pontos de imagens provocado pelo alinhamento de sobreposi¸c˜ao
das imagens.
Tabela 4.1: Dados das coordenas, levantados pelo processo de alinhamento.
Alinhamento (em pixels)
Projetor Parede/Olho Posi¸c˜ao x:y Largura Altura Perda
1 frente esquerdo 140 : 5 836 705 25%
2 frente direito 1167 : 59 835 709 24,7%
3 esquerda direito 2077 : 4 855 649 29,4%
4 esquerda esquerdo 3116 : 43 856 651 29,1%
5 direita esquerdo 4153 : 6 884 665 25,2%
6 direita direito 5170 : 98 885 669 24,7%
7 baixo direito 6141 : 150 1002 609 22,4%
8 baixo esquerdo 7168 : 2 1002 677 13,7%
O n´o X3D Viewarea do conjunto de componentes Engine do InstantReality
foi declarado com base nos dados de posi¸c˜ao, largura e altura da Tabela 4.1. Ex-
48
Figura 4.4: Alinhamento das ´areas de imagens: (a) alinhamento e dimensiona-
mento das ´areas de imagens no espa¸co de tela dos servidores; (b) imagens proje-
tadas nas paredes do CAVE, j´a com as posi¸c˜oes individuais (esquerda e direita)
para cada parede alinhadas.
emplos para os projetores P1 e P2, podem ser vistos no C´odigo 4.3 e no c´odigo
completo, em X3D, Anexo 1.
1 . . .
2 <!−− P r o j e t o r 1 : p ar ed e f r o n t a l o l h o e squ e rdo −−>
3 <Viewarea containerField= ’ v ie w s ’ lowerLeft=’ 140 5 ’ upperRight= ’ 976 710 ’ />
4
5 <!−− P r o j e t o r 2 : p ar ed e f r o n t a l o l h o d i r e i t o −−>
6 <Viewarea containerField= ’ v ie w s ’ lowerLeft=’ 1167 59 ’ upperRi ght= ’ 2002 767 ’ />
7 . . .
C´odigo 4.3: Exemplo de declara¸c˜ao dos n´os ´areas de imagens.
Viewarea ´e um componente que declara uma ´area retangular para o desenho
de imagens. Dois pontos no espa¸co de tela v´alido para o ClusterWindow s˜ao re-
queridos, lowerLeft e upperRight e s˜ao usados para indicar as coordenadas do canto
inferior esquerdo e superior direito, respectivamente, da ´area de desenho v´alida. O
49
campo containerField ´e necess´ario para manter um correto relacionamento entre
os n´os do grafo, (Brutzman e Daly, 2007).
4.3.3 Modelo de cˆameras
Uma defini¸c˜ao cl´assica de cˆamera,(Collin, 2001), ´e ”Dispositivo que trans-
forma uma cena em sinais el´etricos que podem ser exibidos em uma televis˜ao”ou
projetores. Entretanto, a cˆamera aqui descrita ´e um elemento l´ogico de software
que transfere parte de uma cena 3D do mundo virtual em uma representa¸c˜ao 2D
que pode ser exibida em telas de computadores ou paredes de um CAVE. No con-
texto de um sistema CAVE, o elemento l´ogico cˆamera possui uma importˆancia
maior. Precisamos usar simultaneamente diversas cˆameras e o sincronismo entre
elas ´e que garante um bom n´ıvel de imers˜ao visual para o usu´ario.
Para entendermos melhor o modelo de cˆamera usado devemos deixar claro
a existˆencia de dois espa¸cos: o espa¸co natural ou real onde o usu´ario e os compo-
nentes f´ısicos do CAVE est˜ao presentes; o espa¸co virtual ´e uma entidade abstrata
armazenada no computador onde est˜ao presentes objetos virtuais como um cubo,
uma esfera e elementos n˜ao vis´ıveis, como por exemplo as cˆameras. O volume de
visualiza¸c˜ao, o plano de proje¸c˜ao e o centro de proje¸c˜ao s˜ao elementos do mundo
virtual definidos no modelo de cˆamera, Figura 4.5, e possuem elementos correspon-
dente no espa¸co real, por exemplo:o plano de proje¸c˜ao corresponde a tela e o centro
de proje¸c˜ao ao centro dos olhos.
O realismo da percep¸c˜ao do mundo virtual pelo usu´ario depende fundamen-
talmente de dois parˆametros para todas as cˆameras. As posi¸c˜oes das cˆameras em
rela¸c˜ao aos respectivos planos de proje¸c˜ao no espa¸co virtual devem corresponder
`as posi¸c˜ao relativas dos olhos em rela¸c˜ao `as telas de proje¸c˜ao no mundo real. A
Figura 4.6 ilustra a configura¸c˜ao do frustum para a tela do piso. O centro de pro-
je¸c˜ao (CDP) esta localizado na posi¸c˜ao de origem [0; 0; 0] atribu´ıda para o espa¸co
real que corresponde `a posi¸c˜ao mediana dos olhos do usu´ario posicionado num
ponto de referˆencia dentro do ambiente. O plano de proje¸c˜ao ´e definido por quatro
50
Figura 4.5: Frustum: volume de visualiza¸c˜ao no espa¸co virtual.
pontos relativos ao ponto de referˆencia e determinados pelo v´ertices da tela de
proje¸c˜ao, portanto a tela de proje¸c˜ao e o plano de proje¸c˜ao do modelo da cˆamera
possuem as mesmas ou propor¸c˜oes.
Para termos um sistema esteresc´opico, devemos configurar duas cˆameras para
a tela de proje¸c˜ao do piso. As coordenadas referentes ao plano de proje¸c˜ao de
ambas as cˆameras permanecem inalterados. Para a cˆamera correspondente ao olho
esquerdo, deslocamos o CDP para a posi¸c˜ao [x = −0.04; y = 0; z = 0] e para a
cˆamera respectiva ao olho direito o CDP ´e deslocado para [x = 0.04; y = 0; z = 0].
A configura¸c˜ao das cˆameras para as outras telas ´e an´alogo. Definimos sempre
a posi¸c˜ao do CDP para [x = 0; y = 0; z = 0], os planos de proje¸c˜ao s˜ao determi-
nados pelas posi¸c˜oes relativas dos v´ertices das telas correspondentes ao ponto de
referˆencia exceto para a tela de proje¸c˜ao frontal. A Figura 4.7 ilustra o frustum
para a tela frontal. N˜ao h´a sobreposi¸c˜ao entre os frustum 1 e 4. Entretanto, entre
as telas do piso esquerda e piso direita h´a uma sobreposi¸c˜ao dos volumes de visu-
aliza¸c˜ao mas apenas um dos volumes ´e percebido pelo usu´ario devido ao arranjo
inclinado da tela do piso. Esta sobreposi¸c˜ao intencional daqueles frusta tamb´em
resolveu os problemas do plano inclinado e da geometria n˜ao retangular das telas
51
Figura 4.6: Frustum 4 ajustado para a tela do piso.
da esquerda e direita.
Para ajustar as caracter´ısticas necess´arias ao modelo de cˆamera definimos
altera¸c˜oes no padr˜ao dos oito frusta pr´e-configurados no InstantReality. Os n´os
X3D Viewarea discutidos anteriormente permitem o acr´escimo de um n´o filho
ProjectionViewModifier, o qual imp˜oe uma transforma¸c˜ao controlada ao volume
de visualiza¸c˜ao. Este n´o ProjectionViewModifier requer apenas dois campos,
um referentes `a descri¸c˜ao de uma superf´ıcie de proje¸c˜ao no espa¸co da cena, e para
qual dos olhos a imagem ser´a encaminhada, al´em da distˆancia que separa os olhos
do observador, veja o c´odigo 4.4. Para o centro de proje¸c˜ao de cada frustrum ´e
assumido a origem acrescida do deslocamento do olho correspondente.
1 . . .
2 <!−− P r o j e t o r 1 : p ar ed e f r o n t a l o l h o e squ e rdo −−>
3 <Viewarea containerField= ’ v ie w s ’ lowerLeft=’ 140 5 ’ upperRight= ’ 976 710 ’>
52
Figura 4.7: Configura¸c˜ao do Frustum 1 para a tela de proje¸c˜ao frontal.
4 <ProjectionViewModifier DEF= ’ p r o j e t o r 1 ’ surf ac e=’ 0 .9275 −1.4 −1.5 , 0 .9275 0 . 8
−1.5 , 0 . 9275 0 . 8 −1.5 , −0.9275 −1.4 −1.5 ’ leftEye=’TRUE ’ rightEye= ’FALSE ’
eyeSeparation=’ 0 . 0 8 ’ />
5 </Viewarea>
6
7 <!−− P r o j e t o r 2 : p ar ed e f r o n t a l o l h o d i r e i t o −−>
8 <Viewarea containerField= ’ v ie w s ’ lowerLeft=’ 1167 59 ’ upperRi ght= ’ 2002 767 ’>
9 <ProjectionViewModifier DEF= ’ p r o j e t o r 2 ’ surf ac e=’ 0 .9275 −1.4 −1.5 , 0 .9275 0 . 8
−1.5 , 0 . 9275 0 . 8 −1.5 , −0.9275 −1.4 −1.5 ’ leftEye=’FALSE ’ rightEye= ’TRUE’
eyeSeparation=’ 0 . 0 8 ’ />
10 </Viewarea>
11 . . .
C´odigo 4.4: Ajuste dos volumes de visualiza¸c˜ao para a tela frontal
ProjectionViewModifier responde a um evento do tipo SFMatrix4f, pelo
campo set eyeTransform, com uma modifica¸c˜ao no CDP do frustum, mas man-
tendo as coordenadas do plano de visualiza¸c˜ao. SFMatrix4f ´e semelhante a Vrml-
Matrix que ´e uma matriz 4x4 de floats.
53
set eyeT ransform =
X
x
Y
x
Z
x
T
x
X
y
Y
y
Z
y
T
y
X
z
Y
z
Z
z
T
z
0 0 0 1
.
As trˆes primeiras colunas de elementos definem a dire¸c˜ao do vetor que rep-
resenta a orienta¸c˜ao dos eixos X, Y e Z. A quarta coluna T representa o deslo-
camento em rela¸c˜ao a origem do espa¸co. Este ´e um formato de dados comum,
retornados por diversos rastreadores de posi¸c˜oes quando devidamente configura-
dos.
4.4 Integrando o NestOfBirds
A vers˜ao do InstantReality utilizada neste trabalho suporta apenas um mod-
elo de tracker, o miniBird, (technology Corporation). Uma solu¸c˜ao tempor´aria,
mas funcional, foi desenvolver um programa em Java que gerasse um evento de
sa´ıda, a cada frame, para alterar o campo set eyeTransform mediante dados de
um sensor posicionado na cabe¸ca do observador e monitorado pelo dispositivo de
rastreio NestOfBirds. Entretanto, a Ascension Technology Corporation, fabricante
do dispositivo de rastreio NestOfBirds, fornece apenas uma API para a linguagem
C/C++ e para contornar este problemas desenvolvemos uma classe java com m´eto-
dos nativos em linguagem C atrav´es do recurso do Java Native Interface (JNI),
(Liang, 1999).
4.4.1 Controle do NestOfBirds em Java
Duas classes em java foram escritas para controlar as opera¸c˜oes do NestOf-
Birds e repass´a-las, por EAI, ao n´o Script do subgrafo Engine em ECAVE.X3D
que controla os aspectos da renderiza¸c˜ao. A classe NestOfBirds cont´em todas as
opera¸c˜oes necess´arias para intera¸c˜ao com o dispositivo de rastreio e a classe Con-
trolX3DTracking ´e a ponte de conex˜ao entre a cena ECAVE.X3D quando executado
54
pelo InstantPlayer e os recursos do tracker acessados atrav´es de m´etodos nativos
implementados na classe NestOfBirds. Figura 4.8.
Figura 4.8: UML das Classes em Java para controle do tracker NestOfBirds.
Os m´etodos da classe NestOfBirds n˜ao s˜ao implementados em Java, sendo
simples referˆencia a fun¸c˜oes constru´ıdas em linguagem C e carregadas adequada-
mente pela M´aquina Virtual Java (Liang, 1999). A utiliza¸c˜ao da interface JNI pode
parecer confusa e n˜ao ´e nosso objetivo discut´ı-la neste trabalho. Mesmo assim, o
Anexo A.2 cont´em o c´odigo completo da parte em Java desta classe, um fragmento
da implementa¸c˜ao em C e os comando para compilar.
No desenvolvimento da classe NestOfBirds tivemos cuidado para manter os
tempos de respostas dos m´etodos os menores poss´ıveis. O m´etodo nativo public
native float[] getPosition(int birds) devolve, ao objeto que a chamou, os dados cor-
rentes da quantidade de sensores indicado pelo parˆametro birds no formato de um
vetor de n´umeros do tipo float. Se o parˆametro birds for igual a 1, ser´a retornado
uma referˆencia a um vetor de tamanho trˆes, com os dados das posi¸c˜oes [x; y; z] rel-
ativos ao primeiro sensor do NestOfBirds. Quando o parˆametro birds for igual a 2,
uma referˆencia a um vetor de tamanho seis ser´a retornado [x
S1
; y
1
; z
S1
; x
S2
; y
S2
; z
S2
]
com os dados do sensor 1 (S1) e do sensor 2 (S2). Este mecanismo diminui a
55
quantidade de chamadas aos m´etodos nativos, por exemplo, podemos obter as in-
forma¸c˜oes de posi¸c˜ao e orienta¸c˜ao de 4 sensores em uma ´unica chamada ao m´etodo
public native float[] getPositionAngles(int birds) se birds for igual a 4.
A classe ControlX3DTracking ´e respons´avel por integrar a cena ECAVE.X3D
com a classe NestOfBirds que controla o tracker. ControlX3DTracking implementa
trˆes m´etodos est´aticos: O m´etodo onBrowserChanged monitora o estado e os even-
tos do player de X3D. Quando o player ´e fechado este m´etodo garante o desliga-
mento adequado do hardware do NestOfBirds e o t´ermino dos c´odigos relacionados.
O m´etodo onChangedPosition emite um evento EventInMFFloat ao n´o Script de
ECAVE.X3D atrav´es de EAI, com os valores dos sensores retornados pelo objeto
nob. O m´etodo main, ponto de partida para a M´aquina Virtual Java, executa a
inicializa¸c˜ao do hardware do NestOfBirds, abre uma conex˜ao EAI com o player
de X3D, adquire uma referencia ao n´o Script do arquivo X3D em execu¸c˜ao pelo
InstantPlayer e atualiza constantemente os valores dos sensores.
4.4.2 Script
A conex˜ao direta deste campo de entrada ao NestOfBirds n˜ao ´e poss´ıvel
nem mesmo atrav´es de EAI pois a API do InstantReality n˜ao implementa a classe
SFMatrix4f nem VrmlMatrix. Ent˜ao a sa´ıda para o problema foi desenvolver um
n´o Script chamado Matriz que convertesse um evento EventInMFFloat em outro
evento do tipo SFMatrix4f.
A especifica¸c˜ao ISO/IEC FDIS 19775-1:2008 define o tipo de dados SFMa-
trix4f como nativo ao X3D mas o InstantReality utilizado neste trabalho tem como
base uma especifica¸c˜ao anterior que n˜ao definia este tipo de dados. Tal problema
foi contornado atrav´es da declara¸c˜ao de um campo de sa´ıda do tipo SFMatrix4f
no Script Matriz e da atribui¸c˜ao deste campo de sa´ıda a uma referˆencia a um
objeto do tipo VrmlMatrix, veja o fragmento de C´odigo 4.5. Tal t´ecnica funciona
perfeitamente, pois os dois tipos s˜ao equivalentes, (uma estrutura de 16 floats).
1 . . .
2 < !−− De fin e um NODO X3D SFMatrix4f com os v a l o r r e t ornad o s p e l o t r a c k i n g −−>
56
3 <S c r i p t DEF=”Matriz ”>
4 <f i e l d acc es sType=”inpu tOnly ” name=” s e t m a t r i x 4 f ” type=”MFFloat ”/>
5 <f i e l d acc es sType=”outputOnly ” name=” get e yeT r ansf orm ” t ype=”SFMatrix4f ”/>
6 <! [CDATA[
7 e c m a s c r i p t :
8 f u n c t i o n s e t m a t r i x 4 f ( v e t o r ) {
9 g e t e y eTr a nsf o rm = new VrmlMatrix ( 1 , 0 , 0 , v e t o r [ 0 ] , 0 , 1 , 0 , v e t o r [ 2
] , 0 , 0 , 1 , vet o r [ 1 ] , 0 , 0 , 0 , 1) ;
10 }
11 ] ]>
12 </ S c r i p t>
13 . . .
C´odigo 4.5: Script
O campo de sa´ıda do Script get eyeTransform ´e conectado ao campo de
entrada set eyeTransform dos oito n´os ProjectionViewModifier, veja Figura 4.1
e Anexo 1. O programa de controle do NestOfBirds escrito em Java manipula
adequadamente o campo de entrada set matrix4f do Script gerando um evento de
atualiza¸c˜ao em intervalos de tempo de 33 ms.
4.5 Suporte ao Desenvolvimento de Aplica¸c˜oes
O objetivo principal de todo este trabalho foi construir um ambiente de con-
trole do CAVE do LNCC para renderizar adequadamente qualquer cena descrita
em X3D ou VRML. Para a visualiza¸c˜ao de cenas est´aticas ou animadas sem a
necessidade de recursos avan¸cados de navega¸c˜ao ´e necess´ario apenas informar qual
a localiza¸c˜ao do arquivo VRML, X3D ou OBJ no n´o Inline e carregar no Instant-
Player do computador cliente o arquivo do ECAVE.X3D, e executando o programa
em Java de controle do NestOfBirds em paralelo.
No pr´oximo cap´ıtulo descreveremos como se pode desenvolver pequenas apli-
ca¸c˜ao em VRML, X3D e Java que permitem acessar arquivos contendo dados bi-
ol´ogicos tanto em m´aquinas locais como na Internet, criando modelos e renderizando-
os dentro do ambiente CAVE. Apresentaremos tamb´em alguns programas de ter-
ceiros capazes de converter dados biol´ogicos estruturais organizados em formatos
de uso espec´ıficos em biologia para os formatos VRML e X3D.
57
Cap´ıtulo 5
Resultados e discuss˜ao
Os resultados est˜ao separados em dois grupos: gerais e espec´ıficos. Na se¸c˜ao
de resultados gerais apresentamos os resultados referentes ao desempenho dos com-
ponentes do CAVE, que de algum modo afetam a qualidade da sensa¸c˜ao de imers˜ao:
densidade de pontos de imagem nas telas, sincronismo espacial e temporal, difer-
en¸cas de brilho e eficiˆencia de resposta as cores. Na se¸c˜ao de resultados espec´ıficos
apresentaremos o processo de desenvolvimento de algumas aplica¸c˜oes de interesse
para Bioinform´atica que utilizam o ambiente CAVE. Al´em de apresentar estes re-
sultados vamos tamb´em discutir algumas modifica¸c˜oes tanto na estrutura f´ısica
quanto na infraestrutura de software para melhorar o desempenho em uma vers˜ao
futura.
Descrever efetivamente todos os aspectos relativos aos resultados de um sis-
tema que prove a imers˜ao f´ısica e mental de um humano em um mundo virtual
baseado em texto e imagens ´e uma tarefa desafiadora e complexa. At´e mesmo a
utiliza¸c˜ao de v´ıdeos n˜ao se mostra adequado a esta tarefa. O que podemos apre-
sentar aqui s˜ao parˆametros t´ecnicos e caracter´ısticas visuais que podem prejudicar
a qualidade da sensa¸c˜ao de imers˜ao do usu´ario, exemplos seriam: a resolu¸c˜ao das
imagens nas telas e diferen¸cas de brilho. Estes aspectos t´ecnicos podem ser aferidos
subjetivamente por fotos das proje¸c˜oes nas telas, as quais constituem grande parte
dos resultados aqui expostos.
A descri¸c˜ao dos resultados espec´ıficos em Bioinform´atica tamb´em ´e particu-
58
lar. N˜ao vamos apresentar aqui uma aplica¸c˜ao para Bioinform´atica de uso amig´avel
com uma infinidade de recursos altamente configur´aveis ao gosto do usu´ario. O
que vamos descrever ´e a capacidade que este sistema possui de permitir um de-
senvolvimento r´apido de aplica¸c˜oes de visualiza¸c˜ao de dados biol´ogicos que podem
ser descritos geometricamente em 3D/4D por meio de linguagens de descri¸c˜ao de
mundos virtuais, mesmo por programadores com pouca experiˆencia.
5.1 Resultados Gerais
Nesta se¸c˜ao vamos apresentar e discutir parˆametros t´ecnicos referente aos el-
ementos f´ısicos utilizados na montagem e nos componentes de software do CAVE.
Todos os elementos l´ogicos empregados est˜ao intimamente relacionados aos com-
ponentes f´ısicos e o desempenho final de todo o sistema esta intrinsecamente rela-
cionado inclusive a disponibilidade de espa¸co e ao isolamento luminoso da sala que
acomoda todo o aparato do CAVE ACiMA. Tamb´em neste trabalho, n˜ao temos
a inten¸c˜ao de descrever comparativos de desempenho entre o prot´otipo do CAVE
do LNCC e outros CAVEs no Brasil ou exterior, pois durante este trabalho n˜ao
tivemos acesso a CAVEs de terceiros.
5.1.1 Resolu¸c˜ao M´axima
´
Util por Projetor
A resolu¸c˜ao nativa dos projetores empregados ´e de 1024 pixels horizontais
por 768 pixels vertical, 1024x768 pixels. Para melhor aproveitar a resolu¸c˜ao, seis
projetores foram dispostos na posi¸c˜ao vertical, devido `as dimens˜oes das telas de
proje¸c˜ao com altura maior que a largura (veja Figura 3.2). Logo a resolu¸c˜ao passou
para 768x1024 pixels n˜ao considerando as perdas decorrentes do alinhamento. Pela
Tabela 5.1 o menor ponto de imagem poss´ıvel nas telas ´e da ordem de 3mm nas
imagens geradas pelos projetores 1 a 6 e de 1,8 mm para os projetores 7 e 8.
Na coluna Projetor temos o n´umero que identifica o projetor. A coluna
Parede/Olho indica qual a parede tela de proje¸c˜ao os dados se referem. Den. Hor-
izontal especifica qual a densidade de pontos de imagem por polegada no sentido
59
Tabela 5.1: Densidade de pontos de imagem nas telas.
Densidade pixels/polegada (px/in)
Projetor Parede/Olho Den. Horizontal Den. Vertical Perda
1 frente/esquerdo 9,679 8,632 25,0%
2 frente/direito 9,734 8,622 24,7%
3 esquerda/direito 8,911 8,828 29,4%
4 esquerda/esquerdo 8,938 8,838 29,1%
5 direita/esquerdo 9,130 9,127 25,2%
6 direita/direito 9,185 9,127 24,7%
7 baixo/direito 13,757 11,89 22,4%
8 baixo/esquerdo 13,757 12,327 13,7%
horizontal, referente `a orienta¸c˜ao do usu´ario e Den. Vertical `a densidade no sen-
tido vertical. A coluna Perda expressa a perda de resolu¸c˜ao, em percentagem,
tomando-se por base a resolu¸c˜ao m´axima dos projetores empregados e ´e idˆentica `a
coluna Perda da Tabela 4.1.
As perdas de resolu¸c˜ao s˜ao devidas a dois fatores principais: os projetores
n˜ao tem o recursos de shift image, isto ´e, capacidade de deslocamento da imagem
pelo menos no sentido vertical, sem provocar distor¸c˜oes e ao alinhamento f´ısico
dos projetores em rela¸c˜ao as telas e entre eles. O Alinhamento l´ogico corrige
o alinhamento f´ısico entretanto provoca perdas, veja Figura 4.4-a. O reduzido
espa¸co da sala que acomoda o prot´otipo do CAVE ´e que exige as perdas relatadas.
Uma significante melhora na resolu¸c˜ao do sistema pode ser alcan¸cada com
as seguintes medidas. Remontar o CAVE em uma sala maior afim de permitir
acomodar melhor os suportes de projetores e espelhos. Substituir os projetores
NEC LT245 pelos NEC XT5100/SX6000 (NEC, b) ou por outros com recursos
similares. Estes projetores suportam resolu¸c˜ao da ordem de 1600x1200 pixels,
possuem deslocamento horizontal e vertical da imagem por meio de motores que
podem ser controlados via software, o que tornariam o processo de alinhamento dos
projetores mais preciso e elevando a resolu¸c˜ao para 18 px/in nas telas da esquerda,
frontal e direita.
De qualquer modo, o resultado obtido de mais de 9 px/in ´e aceit´avel se
60
comparado ao custo de um CAVE com maior resolu¸c˜ao. Vale aqui mencionar que
a resolu¸c˜ao do CAVE do Centro de Pesquisas em Bioinformatica de Calgary for
VISUAL GENOMICS, 4DBioinformatics possui uma densidade horizontal de 13,47
px/in e na vertical de 10,77 px/in uniforme nas quatro paredes.
(a) (b)
Figura 5.1: Sincronismo espacial, emendas das imagens nas bordas das telas: (a)
linhas brancas de largura um pixel; (b) qualidade da renderiza¸c˜ao de um objeto
com imagens para olho esquerdo e direito.
5.1.2 Diferen¸cas de Brilho entre Telas
A qualidade da sensa¸c˜ao de imers˜ao depende tamb´em de um baixo desvio
na intensidade do brilho entre as telas. Diferen¸cas de luminosidade nos planos de
proje¸c˜ao confundem nossa vis˜ao e ajudam o c´erebro a perceber rapidamente que a
proje¸c˜ao n˜ao ´e real. Um correto ajuste de brilho entre telas nem sempre ´e poss´ıvel
e ´e um problema comum no desenvolvimento de sistemas deste tipo. Na Figura
5.2-a temos o resultado final do melhor ajuste de brilho para o CAVE do LNCC.
O resultado mostrado na Figura 5.2-a deixa evidente que o brilho da tela
da direita ´e baixo quando comprado ao brilho das demais telas. No momento do
61
(a) (b)
Figura 5.2: Diferen¸cas de brilho e de cor nas quatro telas de proje¸c˜ao: (a) parede
da esquerda apresenta um n´ıvel de brilho relativamente baixo; (b) tela do piso
responde melhor a faixa do espectro correspondente ao vermelho.
projeto do CAVE n˜ao consideramos as Leis f´ısicas de ilumina¸c˜ao e espalhamento
de luz e as propriedades fotˆonicas das telas empregadas. Entretanto este resultado
levou-nos a obter um entendimento melhor dos fatores que afetam a resposta ao
brilho das imagens formadas nas telas de proje¸c˜ao. Uma primeira aproxima¸c˜ao de
um modelo para a resposta ao brilho nas telas pode ser feito atrav´es de duas leis de
ilumina¸c˜ao bem conhecidas por profissionais de Realidade Virtual: Lei do Cosseno
do
ˆ
Angulo de Incidˆencia, Equa¸c˜ao 5.1, e pela Lei de Lambert, Equa¸c˜ao 5.2, (Slater
et al., 2002).
L
h
=
I
γ
h
2
cos
3
γ (5.1)
A Lei do Cosseno do
ˆ
Angulo de Incidˆencia considera a ilumina¸c˜ao ou lu-
minˆancia no plano num ponto na dire¸c˜ao γ inversamente proporcional ao quadrado
da distˆancia h da fonte luminosa, diretamente proporcional `a intensidade luminosa
emitida nesta dire¸c˜ao e varia com o cos
3
do ˆangulo de incidˆencia. Em resumo, o
62
ˆangulo de incidˆencia da luz dos projetores nas telas afeta o n´ıvel do brilho delas.
I
α
= I
0
cosα (5.2)
A Lei de Lambert determina que a intensidade luminosa percebida I
α
depende
do ˆangulo entre o eixo ´otico do olho do observador e o eixo de emiss˜ao do feixes
de luz do projetor I
0
. Veja a Figura 5.3.
Figura 5.3: Ilustra¸c˜ao das duas Leis de ilumina¸c˜ao.
Constatamos assim que o ˆangulo de incidˆencia dos feixes de luz do projetor
em rela¸c˜ao as telas e o angulo do eixo ´otico do usu´ario em rela¸c˜ao a tela afeta a sen-
sa¸c˜ao de brilho do observador. O reposicionamento dos projetores poderiam, ent˜ao,
diminuir a diferen¸ca de brilho, principalmente na tela da direita. Infelizmente o
espa¸co dispon´ıvel na sala do prot´otipo n˜ao ´e suficiente para este ajuste. Sendo
assim, uma remontagem do CAVE em uma sala maior esta sendo providenciada.
5.1.3 Diferen¸cas na resposta ao espectro de cores entre telas
A Figura 5.2-b deixa evidente que existe uma diferen¸ca na tonalidade das
cores na tela do piso. Este resultado ´e devido `a natureza do material da tela do piso,
que ´e diferente das demais. A distor¸c˜ao de cor poderia ser reduzida baixando-se o
brilho e alterando-se as configura¸c˜oes de cores de todos os projetores. Entretanto
estes dois projetores est˜ao relativamente mais pr´oximos a esta tela o que tem
63
prejudicado o ajuste de cor. Na Figura 5.4, n˜ao efetuamos nenhum tipo de ajuste
de cor de modo que esta situa¸c˜ao ´e a extrema para o nosso sistema. Um ajuste
adequado de brilho e cor nos projetores pode minimizar tal diferen¸ca, veja Figura
5.4, as cores na tela do piso e na da frente s˜ao muito similares nesta ´ultima figura.
5.1.4 Sincronismo espacial
Quando imagens de um mesmo objeto se distribuem por mais de uma tela de
proje¸c˜ao formam-se jun¸c˜oes de imagens. O alinhamento das imagens destas jun¸c˜oes
´e crucial para a qualidade da sensa¸c˜ao de imers˜ao. Usamos o termo sincronismo
espacial n˜ao apenas para nos referirmos as emendas das jun¸c˜ao de imagens mas
tamb´em ao controle da paralaxe das jun¸c˜ao de duas imagens. A Figura 5.4-
a mostra um resultado para emendas de cinco jun¸c˜oes de imagens para o olho
esquerdo, e a Figura 5.4-b as cinco jun¸c˜oes para o olho direito. Tamb´em podemos
ver estas emendas nas Figuras 5.2-a e 5.2-b.
(a) (b)
Figura 5.4: jun¸c˜oes das imagens nas quatro telas, emendas das imagens nas bordas
das telas: (a) emendas das imagens referentes ao olho esquerdo; (b) emendas das
imagens referentes ao olho direito.
64
5.1.5 Sincronismo Temporal
As dez jun¸c˜oes de imagens nas 4 telas s˜ao dinˆamicas no tempo. Estas jun¸c˜oes
de encaixe sofrem rearranjos quando o objeto ´e deslocado em rela¸c˜ao ao usu´ario.
O sincronismo temporal mantem a coerˆencia quando as imagens de um objeto
deslocam-se de uma parede a outra, isto significa que a cada frame, se uma parte
de um objeto est´a em uma parede e o restante estiver em outra estas tem de estar
alinhadas espacialmente. No pr´oximo frame um pequeno deslocamento ocorre, uma
nova jun¸c˜ao se forma e o alinhamento espacial deve ser mantido. Encolhimento
ou alongamento em qualquer dire¸c˜ao s˜ao os tipos de deforma¸c˜oes mais comuns
durante o movimento do objeto entre telas. A taxa de quadros dever ser igual ou
superior a 30 Hz, valores abaixo podem causar n´auseas ao observador, (Pausch
et al., 1996).
Uma avaliza¸c˜ao mais detalhada deste resultado pode ser feita analisando-se
um dos v´ıdeo no CD-ROM que acompanha esta disserta¸c˜ao ou na pagina Web do
Laborat´orio de Ambientes Colaborativos e Multim´ıdia Aplicada ACiMA do LNCC
em http://acima.lncc.br/cave.
5.1.6 Rastreamento da posi¸c˜ao da cabe¸ca do usu´ario e transfor-
ma¸c˜oes nas imagens
No Cap´ıtulo 3, Se¸c˜ao 3.6 deixamos clara a necessidade de alterar as imagens
caso o usu´ario se desloque dentro do ambiente CAVE. Sem este recurso o usu´ario
tem uma sensa¸c˜ao estranha de que os objetos se movem quando deveriam per-
manecer im´oveis. A sequˆencia de imagens da figuras 5.5 ilustra as transforma¸c˜oes
que ocorrem nas imagem para o olho esquerdo. Para uma melhor avalia¸c˜ao da efi-
ciˆencia deste recurso veja o v´ıdeo tracker.mov no CDROM que acompanha esta
disserta¸c˜ao.
65
(a) (b) (c)
(d) (e) (f)
Figura 5.5: Sequˆencia de imagens que ilustra as transforma¸c˜oes nas proje¸c˜oes
em resposta ao movimento da cabe¸ca do usu´ario: (a),(b),(c),(d),(e) e (f) s˜ao seis
instantes de tempo distintos.
5.2 Resultados Espec´ıficos em Bioinform´atica
Nesta se¸c˜ao vamos apresentamos e discutimos alguns resultados da utiliza¸c˜ao
do CAVE do LNCC para visualiza¸c˜ao de dados biol´ogicos. Vamos aqui mostrar
alguns processos para o desenvolvimento de pequenas aplica¸c˜oes que podem ser
estendidas, observando a simplicidade e tempo restrito de desenvolvimento.
5.2.1 Visualiza¸c˜ao de morfologia de larvas
Leptobrachella mjobergi ´e uma esp´ecie de anf´ıbio da fam´ılia Megophryidae
encontrada na Indon´esia, Mal´asia e Brunei. A sua larva tem uma estranha forma
vermiforme, s˜ao fossoriais e habitam o cascalho de pequenos c´orregos. Uma equipe
de cientistas chefiados por Alexander Haas da Universidade de Hamburgo, Ale-
manha, reconstru´ıram a geometria 3D do crˆanio desta larva a partir de uma s´erie
de cortes histol´ogicos transversais utilizando um m´etodo manual de segmenta¸c˜ao
de imagens (Hass et al., 2006).
A reconstru¸c˜ao da geometria 3D do modelo da larva foi executado por um
66
m´etodo semi-autom´atico com auxilio do software Maya desenvolvido pela Autodesk
(Autodesk). O resultado foi a obten¸c˜ao de uma descri¸c˜ao geom´etrica das superf´ıcies
de quatro objetos designados por Chondrocranium, Hyobranchium, Notochord e
Musculature no formato .OBJ. Em um primeiro momento carregamos este arquivo,
no formato OBJ, atrav´es do n´o Inline do programa de controle do ambiente CAVE,
c´odigo A.1 linha 103, e o resultado esta ilustrado na Figura 5.6.
Figura 5.6: Modelo geom´etrico parcial do crˆanio da larva Leptobrachella mjobergi
carregado no ambiente CAVE, sem tratamento.
Para produzirmos um cen´ario que possibilitasse alguma intera¸c˜ao do usu´ario
com o modelo da larva, como alterar transparˆencia dos componentes e melhorar
a navega¸c˜ao convertemos este arquivo .OBJ para VRML com aux´ılio do software
3ds Max (Autodesk). Este arquivo, em formato VRML contendo ent˜ao apenas a
descri¸c˜ao da geometria de quatro objetos atrav´es de n´os VRML do tipo Indexed-
FaceSet foi editado manualmente. Adicionamos os n´os IOSensor, NavigationInfo,
ScreenTextOverlay, Script e um novo n´o HUD foi desenvolvido para mostrar um
67
painel com informa¸c˜oes sobre a larva diante do observador independente de sua
localiza¸c˜ao no mundo virtual.
Toda a intera¸c˜ao entre usu´ario e cen´ario ´e feita atrav´es de um JoyStick sem
fio. Os bot˜oes 8 e 6 aumentam e diminuem o n´ıvel de transparˆencia do objeto
selecionado pelos botoes 1 a 4, este valor de transparˆencia pode ser ajustado entre
0 e 100%. O bot˜ao 5 exibe um painel de informa¸c˜oes quando pressionado. Bot˜oes
7, 9 e 10 n˜ao possuem fun¸c˜ao e os bot˜oes anal´ogicos permitem o deslocamento do
observador no eixos x, y e z e rota¸c˜ao nos eixos x e y. Algumas fotos da aplica¸c˜ao
rodando no CAVE aparece na Figura 5.7.
Figura 5.7: Captura de tela da Aplica¸c˜ao para visualiza¸c˜ao da estrutura morfol´og-
ica do crˆanio de uma larva.
Em rela¸c˜ao ao tempo para desenvolvimento desta aplica¸c˜ao, o ambiente de-
scrito no cap´ıtulo anterior alcan¸cou o objetivo. O seu desenvolvimento exigiu
apenas experiˆencia em VRML, n˜ao sendo necess´ario utilizar linguagem de pro-
grama¸c˜ao. Esta aplica¸c˜ao poderia ter sido escrita em X3D, bastando converter o
arquivo VRML exportado pelo 3DMax para X3D manualmente ou por meio de um
utilit´ario espec´ıfico Vrml97ToX3DNist, (Wang, 2004), e ent˜ao proceder a edi¸c˜ao
para acrescentar os recursos necess´arios.
5.2.2 Visualiza¸c˜ao Sistema Cardiovascular humano
A descri¸c˜ao geom´etrica do modelo do sistema cardiovascular humano ´e com-
plexa, sendo ideal para executar um teste de eficiˆencia da sensa¸c˜ao de imers˜ao,
resolu¸c˜ao e sincronismo espacial/temporal.
68
(a) (b) (c)
Figura 5.8: Um cen´ario virtual descrito pelo modelo de art´erias e veias de um
humano: (a) vis˜ao frontal geral; (b) detalhe do t´orax; (c) uma imagem de dentro
do crˆanio.
Um modelo completo do corpo humano (http://www.anatomium.com/) e foi
editado para conter uma descri¸c˜ao geom´etrica simplificada das principais art´erias
e veias. Para este teste adicionamos ao arquivo VRML, exportado pelo software
3DMax, apenas os recursos para navega¸c˜ao e a op¸c˜oes para controlar o n´ıvel de
transparˆencia, Figura 5.8.
Esta aplica¸c˜ao apresentou como resultado bom n´ıvel de imers˜ao visual. A
diversidade de planos contendo art´erias e veias e a complexidade geom´etrica do
modelo aliados a capacidade de proje¸c˜ao estereosc´opica do sistema, tamanho das
telas de proje¸c˜ao e o isolamento do observador do mundo real impressionou os
visitantes do laborat´orio submetidos a tal experiˆencia.
Um cen´ario mais complexo poder´a ser constru´ıdo para visualiza¸c˜ao de out-
ros componentes do corpo humano. O desenvolvimento de recursos para navega¸c˜ao
avan¸cada como controle de velocidade, transla¸c˜ao e rota¸c˜ao nos trˆes eixos, um menu
em VRML/X3D que permita ao usu´ario a capacidade de adicionar e remover com-
ponentes, um recurso para marcar locais, e ainda mostrar pain´eis com informa¸c˜oes
baseadas em texto sobre a anatomia humana tornariam o sistema um aplica¸c˜ao
completa de visualiza¸c˜ao do corpo humano em ambiente CAVE.
69
5.2.3 Visualiza¸c˜ao de modelos de prote´ınas e de v´ırus
Softwares de visualiza¸c˜ao de prote´ınas s˜ao bem familiares aos bi´ologos, o
que antecede a pr´opria Bioinform´atica. A visualiza¸c˜ao de prote´ınas ´e uma tarefa
importante em pesquisa biol´ogica, e j´a ´e efetuada em CAVEs h´a algum tempo
(Stromer et al., 2005), (C. et al., 1996), (Huˇs´ak et al., 2003). Conseguimos o
c´odigo fonte do software desenvolvido pelo grupo (Stromer et al., 2005) mas n˜ao
foi poss´ıvel adapt´a-lo para funcionar no CAVE do LNCC. Propomos, ent˜ao, uma
vers˜ao n˜ao finalizada de um programa que recupera o arquivo que descreve as
posi¸c˜oes dos ´atomos de uma prote´ınas, um arquivo PDB cl´assico, converte mediante
um componente de terceiros (UCSF) em uma descri¸c˜ao geom´etrica 3D no formato
VRML e apresenta o resultado dentro do CAVE.
Na Figura 5.9-a temos a visualiza¸c˜ao do menu, onde o usu´ario escolhe na base
de dados do PDB a proteina Ribosomal L9 (NTL9) K12M, c´odigo PDB 2hba e as
demais figuras 5.9-b,c,d,e,f representam modelos em v´arios estilos desta prote´ına.
(a) (b) (c)
(d) (e) (f)
Figura 5.9: Exemplo de uma aplica¸c˜ao para visualiza¸c˜ao de modelos de prote´ınas
com menu de intera¸c˜ao com o usu´ario: (a) menu de intera¸c˜ao; (b) modelo de esferas
e astes; (c) modelo no estilo ribbon; (d) esferas e astes + superf´ıcie; (e) e (f) modelo
da superf´ıcie.
Este mesmo programa ainda em uma vers˜ao alfa pode recuperar e renderizar
70
modelos geom´etricos de caps´ıdios de v´ırus postados no banco de dados p´ublico
VIPERbd. O procedimento ´e o mesmo, o usu´ario escolhe um v´ırus e o sistema
recupera da base de dados p´ublica e renderiza um modelo correspondente aos
dados. As Figuras 5.10-a, 5.10-b e 5.10-c representam os cen´arios VRML descritos
por um conjunto de dados, um v´ıdeo correspondente esta no CDROM.
Figura 5.10: Visualiza¸c˜ao de modelos multi escala de v´ırus: (a) um v´ırus da familia
Reoviridae resolu¸c˜ao 3,60 A; (b) um Togaviridae; (c) representa¸c˜ao 3D de um
Totiviridae de 3,50 A.
O sistema para este aplicativo ´e bastante complexo e levou mais de uma
semana para ser desenvolvido, n˜ao estando finalizado. Ele possui um m´odulo em
X3D que ´e o controle do sistema de renderiza¸c˜ao do CAVE e um m´odulo complexo
em Java que interage com o software Chimera (UCSF) desenvolvido no Centro
de Pesquisas para Biocomputa¸c˜ao, Visualiza¸c˜ao e Inform´atica, fundado pelo NIH.
Esta integra¸c˜ao se deu atrav´es de gera¸c˜ao e execu¸c˜ao de scripts tanto pelo m´odulo
em Java quanto pelo m´odulos do Chimera.
Uma modifica¸c˜ao numa pr´oxima vers˜ao ser´a integrar partes da API do Jmol
(Community) e descontinuar a integra¸c˜ao do Chimera. Existem dois bons motivos
para tal atitude: primeiro, o Chimera ´e desenvolvido em Python e C++ e possui
um algoritmo propriet´ario MSMS (Sanner et al., 1995) para c´alculo de superf´ıcie
de prote´ınas o que impede sua recompila¸c˜ao com este recurso al´em de ser dif´ıcil de
integr´a-lo a um programa em Java; segundo, o Jmol ´e de c´odigo aberto de dom´ınio
publico totalmente escrito em Java o que torna a integra¸c˜ao mais simples e natural.
N´os optamos pelo uso do UCSF Chimera no desenvolvimento deste tra-
71
balho porque o m´odulo de convers˜ao PDB para VRML do Jmol estava em um
est´agio inicial de desenvolvimento, n˜ao possuindo as funcionalidade para expor-
tar cen´arios de superf´ıcie de prote´ınas. J´a o UCSF Chimera possu´ıa um mod-
ulo de exporta¸c˜ao de cenas em X3D de boa qualidade e totalmente funcional.
Para qualquer visualiza¸c˜ao feita com o Chimera ´e poss´ıvel gerar um cen´ario X3D
manualmente e carreg´a-lo no CAVE, sem qualquer modifica¸c˜ao, inclusive cen´arios
animados, o que torna o CAVE do LNCC ´util para a tarefa de visualiza¸c˜ao de
prote´ınas e estruturas virais. O UCSF Chimera pode acessar dados diretamente
da Internet provenientes dos seguintes banco de dados p´ublicos: NDB, PDB,
PDB(mmCIF), SCOP, PubChem, CASTp, EDS(2fo-fc), EDS(fo-fc), PQS, Mod-
Base e VIPERdb, para maiores informa¸c˜oes consulte o Manual do Usu´ario do
Chimera em http://www.cgl.ucsf.edu/chimera/current/docs/index.html.
5.2.4 Visualiza¸c˜ao 3D de um gel bidimensional
Eletroforese bidimensional em gel ´e um t´ecnica comum em laborat´orios de
Biologia Molecular para separar prote´ınas. As prote´ınas s˜ao separadas na primeira
dimens˜ao por suas diferen¸cas el´etricas e na segunda por diferen¸cas de massa molec-
ular (Berth et al., 2007). O resultado desta t´ecnica ´e uma foto como aquela da
Figura 5.11. No horizontal a separa¸c˜ao ´e por diferen¸cas el´etricas, ponto isoel´etrico,
na vertical pela massa atˆomica em KD ( 1000 Daltons ).
A Figura 5.11-c foi gerada pelo software ImageJ (NIH, 1997). Note que cada
ponto na imagem 5.11-b representa o volume de um prote´ına ou uma mistura delas.
Rela¸c˜oes entre volumes s˜ao melhores visualizados em descri¸c˜oes tri-dimensionais.
A transforma¸c˜ao T : R
2
→ R
3
´e feita avaliando-se o valor num´erico de cada pixel
para determinar a altura dos picos, quanto mais baixo o valor do pixel maior ´e
a altura, a informa¸c˜ao de cor no R
3
´e proveniente de uma tabela indexada pela
altura.
Para a gera¸c˜ao de uma estrutura 3D correspondente ´e necess´ario eliminar
o ru´ıdo mediante uma t´ecnica de suaviza¸c˜ao. Empregamos uma convolu¸c˜ao da
72
Figura 5.11: Visualiza¸c˜ao de dados eletroforese bi-dimensional: (a) foto tipica de
um resultado de eletroforese 2D; (b) um fragmento da figura; (c) um modelo 3D
gerado a partir do fragmento 5.11-b.
imagem com uma matriz gaussiana (Jain, 1989). A matriz de suaviza¸c˜ao foi criada
a partir da Equa¸c˜ao 5.3 e a convolu¸c˜ao entre a matriz da imagem i do gel com
a matriz gaussiana g ´e descrita pela Equa¸c˜ao 5.4. O efeito visual desta t´ecnica
pode ser visto na Figura 5.12, em a com ru´ıdo e em b suavizado.
g(x, y) = e
(
x
2
+y
2
2σ
2
)
x, y = 0...12 (5.3)
I(x, y) =
∞
x
=−∞
∞
y
=−∞
i(x
, y
)g(x − x
, y − y
). (5.4)
Modelos 3D que s˜ao representados por superf´ıcies irregulares precisam ser
renderizadas mediante modelos de ilumina¸c˜ao adequados, (ver Cap´ıtulo 2), se¸c˜ao
2.3.3, para tornar os detalhes evidentes. A imagem da Figura 5.13-a foi renderizada
apenas com a aplica¸c˜ao de uma cor em determinado ponto, j´a na figura 5.13-b
utilizamos o modelo de ilumina¸c˜ao Phong, (Slater et al., 2002). A implementa¸c˜ao
cl´assica deste modelo de ilumina¸c˜ao consome muito tempo de processamento que
o torna desaconselh´avel para objetos em grande escala, entretanto implementamos
os c´alculos em GPU segundo a id´eia apresentada no Capitulo 2, Se¸c˜ao 2.3.3.
73
(a) (b)
Figura 5.12: Transforma¸c˜ao da Figura 5.11-b para um modelo geom´etrico 3D
equivalente: (a) representa¸c˜ao 3D da imagem sem tratamento; (b) imagem tratada
com um filtro de convolu¸c˜ao gaussiano.
(a) (b)
Figura 5.13: Duas representa¸c˜ao 3D do fragmento de imagem da Figura 5.11-b:
(a) renderiza¸c˜ao simples sem utiliza¸c˜ao de um modelo para ilumina¸c˜ao do objeto;
(b) com um modelo de ilumina¸c˜ao difusa e especular Phong shading em gpu.
Na Figura 5.14 temos o resultado da renderiza¸c˜ao de uma foto de um gel 2D
completa dentro do ambiente do CAVE com o modelo adequado de ilumina¸c˜ao. A
utilidade desta aplica¸c˜ao pode ser pouco relevante do ponto de vista de um software
para analisar dados de imagens de gel 2D, pois existem t´ecnicas complementares
para determinar a quantidade de cada prote´ına no gel, mesmo que cada marca seja
uma mistura de in´umeras prote´ınas.
Nosso objetivo com esta aplica¸c˜ao foi mostrar a capacidade do sistema para
transformar e renderizar objetos com superf´ıcies muito irregulares, como peles de
74
(a) (b)
Figura 5.14: Visualiza¸c˜ao no CAVE da representa¸c˜ao 3D do gel 2D, com suaviza¸c˜ao
e ilumina¸c˜ao pelo modelo de Phong: (a) Note as imagens dos pequenos picos na
tela do piso; (b) imagem de picos maior da tela do piso.
animais ou imagens de Microsc´opio de For¸ca Atˆomica (AFM), al´em do que vimos
acima. Tamb´em ´e vi´avel a utiliza¸c˜ao da t´ecnica aqui descrita para analisar imagens
de terrenos com alvos de interesse biol´ogicos como florestas e lagos. Amplia¸c˜oes
desta t´ecnica poderia permitir a constru¸c˜ao de simula¸c˜oes de inunda¸c˜oes em um
determinado terreno no qual o usu´ario estaria imerso, de maneira virtual ´e claro,
podendo mensurar melhor os impactos biol´ogicos decorrentes de chuvas intensas.
Obviamente o desenvolvimento de uma aplica¸c˜ao em X3D para esta finalidade
necessitaria de uma boa equipe de desenvolvedores incluindo ge´ologos e bi´ologos.
Dentro do contexo de processamento de imagens m´edicas, modelos de ilumi-
na¸c˜ao adequados poderiam ser usados para uma melhor avalia¸c˜ao visual da eficiˆen-
cia de filtros para imagens devido a facilidade de percep¸c˜ao de pequenos detalhes.
Desenvolver aplica¸c˜oes para esta finalidade pode ser realizado em poucos horas por
um ´unico programador experiente em X3D e Java.
75
Cap´ıtulo 6
Conclus˜ao e Trabalhos Futuros
6.1 Conclus˜ao
O conte´udo desta disserta¸c˜ao pode ser sumarizado em trˆes partes, a saber.
Descrevemos o projeto e a montagem da estrutura f´ısica do CAVE de baixo custo do
laborat´orio ACiMA no LNCC pelo engenheiro Fran¸cois Malric e pelo pesquisador
Jauvane C. de Oliveira. Preparamos o leitor com no¸c˜oes preliminares e princ´ıpios
f´ısicos com o objetivo de melhorar sua compreens˜ao sobre os componentes e as
partes constituintes do sistema CAVE do Lab. ACiMA. Cada componente f´ısico
foi detalhado com textos, ilustra¸c˜oes e fotos justificando sua utiliza¸c˜ao quando
necess´aria no contexto singular deste projeto. Na se¸c˜ao de resultados gerais ap-
resentamos parˆametros t´ecnicos alcan¸cados pela estrutura descrita, explicamos
porque certos resultados ocorreram e discutimos meios para melhorarias no desem-
penho alcan¸cado, mediante altera¸c˜ao de componentes ou a modificando de parte
da estrutura do sistema. Ainda assim, o prot´otipo apresentou um desempenho
surpreendente e contribuiu significativamente para melhorar nosso conhecimento
cient´ıfico sobre ambientes imersivos de grande escala.
Na segunda parte apresentamos minunciosamente o desenvolvimento de um
software de controle para o CAVE do Laborat´orio ACiMA. Utilizando uma re-
cente tecnologia para produ¸c˜ao de aplicativos baseados em Realidade Virtual o
X3D, por meio de um framework de alto desempenho para Realidade Mista, ainda
em vers˜ao beta, em desenvolvimento no Fraunhofer Institute for Computer Graph-
76
ics. Estendemos o InstantReality, por meio de sua interface EAI, para suportar o
rastreador de posi¸c˜oes e orienta¸c˜ao NestOfBirds. Ajustamos o modelo de cˆamera
do framework para renderizar eficientemente as imagens que representam um vis˜ao
est´ereo nas quatro paredes adaptadas `a geometria particular das telas de proje¸c˜ao
do CAVE do LNCC. Corrigimos, por meio de c´odigo, as diferen¸cas de alinhamento
dos projetores, tamb´em singular a este projeto. Esta corre¸c˜ao teve como efeito
colateral uma redu¸c˜ao em 24% no buffer de renderiza¸c˜ao, ou seja, uma redu¸c˜ao da
densidade de pontos de imagem nas telas de proje¸c˜ao. A utiliza¸c˜ao do InstantRe-
ality evitou apenas o trabalho de desenvolver um sistema de janelas distribu´ıdo e
um loader para VRML/X3D com suporte a EAI.
A terceira parte tamb´em trabalhamos no desenvolvimento de aplica¸c˜oes para
visualiza¸c˜ao de dados biol´ogicos. Exploramos t´ecnicas de convers˜ao autom´aticas e
semiautom´aticas de dados biol´ogicos dispon´ıveis atrav´es da Internet em descri¸c˜oes
geom´etricas no formato VRML e X3D para permitir a visualiza¸c˜ao deles no am-
biente CAVE. Inicialmente convertemos alguns arquivos com descri¸c˜ao geom´etrica
3D no formato (.OBJ) para VRML, com auxilio de um software de terceiros, e car-
regamos no ambiente larvas e o sistema cardiovascular humano. Adicionalmente
editamos estes arquivos para permitir alguma intera¸c˜ao do usu´ario com o objeto
virtual descrito. Desenvolvemos uma interface de intera¸c˜ao com o usu´ario vis´ıvel e
control´avel de dentro do ambiente virtual permitindo ao pesquisador escolher qual
base de dados p´ublica, PDB ou VIPERdb, e qual ID do objeto a ser baixado e
convertido em uma descri¸c˜ao geom´etrica apropriada para permitir sua visualiza-
¸c˜ao no ambiente de imers˜ao virtual. Finalmente, apresentamos um m´etodo para
converter imagens em superf´ıcies aplicando um modelo adequado de ilumina¸c˜ao
para real¸car detalhes, utilizando para isso uma outra tecnologia recente, GPUs
com processadores program´aveis. Assim sendo, o desenvolvimento de novas tec-
nologias para visualiza¸c˜ao de dados cient´ıficos, no contexto de dados biol´ogicos,
podem auxiliar no avan¸co do nosso entendimento sobre os processos que regem os
organismos vivos, o qual foi o objetivo deste trabalho.
77
6.2 Sugest˜oes de Trabalhos Futuros
6.2.1 Melhorias na Estrutura F´ısica do CAVE
A primeira medida a ser executada ´e a montagem do CAVE em uma sala
maior que permita um correto posicionamento dos projetores em rela¸c˜ao as telas
de proje¸c˜ao. Os projetores devem estar alinhados de tal forma que o eixo do
feixe de luz esteja perpendicular `as telas de proje¸c˜ao correspondentes, este cuidado
no alinhamento vai minimizar as diferen¸cas de intensidade de brilho entre telas de
mesma natureza. Para reduzir e at´e eliminar as perdas de pontos de imagens devem
ser utilizados projetores com recurso de shift image, pelo menos no eixo vertical.
Para eliminar totalmente estas perdas seria necess´ario o emprego de projetores
com shift image na vertical e horizontal motorizados e controlados por software,
assim o ajuste seria mediante o deslocamento do feixes de luz e n˜ao no arranjo da
viewport. Modificar a tela do piso, deixando ela disposta ortogonal `as demais numa
base firme que suporte o deslocamento do usu´arios dentro do ambiente, esta medida
aumentaria ainda mais o n´ıvel da sensa¸c˜ao de imers˜ao do usu´ario. Posicionar o
centro de controle em frente ao CAVE para facilitar as opera¸c˜oes pertinentes para
acionar e controlar o ambiente.
6.2.2 Melhorias no Software de Controle do CAVE
O desenvolvimento de componentes l´ogicos reutiliz´aveis para intera¸c˜ao do
usu´ario com cen´arios virtuais seria outra medida a ser tomada para acelerar o
tempo de desenvolvimento de aplica¸c˜oes. Menus de carga de cen´arios, suporte a
rastreamento das m˜aos do usu´ario e utiliza¸c˜ao de um navegador 3D sem fios com
seis graus de liberdade no lugar do joystick que possui quatro graus de liberdade
melhoraria tanto a maneira de navegar por um ambiente virtual quanto a intera¸c˜ao
com o mesmo, a¸c˜oes de carregamento e descarte de cen´arios poderiam ser realizadas
rapidamente pelo pr´oprio usu´ario dentro do CAVE. Al´em disso, o InstantReality
evoluiu e recursos das vers˜oes mais recentes podem ser testados. Em nosso trabalho
usamos a vers˜ao beta 4. e no momento da escrita deste texto foi disponibilizado a
78
vers˜ao beta 5.
Um novo software de controle poderia ser escrito usando APIs como OpenSG,
CAVELib, VRjuggler, Syzygy, CaveUT e CoVE. O desenvolvimento utilizando a
API OpenGL e uma API para rede, ´e desaconselh´avel como trabalho de mestrado.
Entretanto, ´e poss´ıvel de ser executado por uma equipe pequena de programadores
em alguns anos mas sem garantias de alcan¸car um desempenho maior do que as
APIs existentes. O InstantReality ´e baseado em OpenSG EX e no Avango e tem
aproximadamente cinco anos de desenvolvimento, al´em de possuir m´etodos paten-
teados para particionamento de carga e renderiza¸c˜ao em sistemas distribu´ıdos. O
desenvolvimento de uma API para CAVE de boa qualidade para visualiza¸c˜ao cien-
t´ıfica teria mercado, mesmo se baseado em outras APIs. Um ponto de partida
poderia ser o OpenSG o qual j´a possui recursos para renderiza¸c˜ao em cluster-
ing e outro poderia ser a utiliza¸c˜ao do Open Inventor da SGI junntamente com
GLX OpenGL Extension to the X Window System suportado, inclusive pelas mais
recentes placas gr´aficas da NVIDIA. Explorar as APIs existentes para CAVEs,
tamb´em seria uma boa ideia para forma¸c˜ao de recursos humanos na ´area.
6.2.3 Desenvolvimento de Aplicativos para Visualiza¸c˜ao Cient´ıficas
N˜ao apenas na ´area de Bioinform´atica mas em todo o ˆambito da Modelagem
Computacional a visualiza¸c˜ao de grande quantidade de dados, seja proveniente de
sensores ou de simula¸c˜oes num´ericas ´e um grande desafio. Arquivos da ordem de
GBytes a TBytes, de altas dimens˜oes precisam ser visualizados na sua totalidade
sem perdas relevantes de informa¸c˜oes por humanos acostumados a ver em trˆes di-
mens˜oes e com um campo de vis˜ao limitado. Existem tamb´em problemas mais
trat´aveis como a visualiza¸c˜ao do dobramento de prote´ınas, que pode perfeitamente
ser implementado usando X3D no CAVE descrito neste trabalho o qual seria muito
´util para os desenhistas de f´armacos. O desenvolvimento de um browser que inte-
graria a visualiza¸c˜ao de informa¸c˜oes de genomas, com transcriptomas e regula¸c˜ao
por prote´ınas e co-fatores de um organismo completo, como uma bact´eria ou lev-
79
edura podendo no futuro ser expandido para organismos mais complexos como
plantas e animais. CAVEs s˜ao ´uteis na visualiza¸c˜ao de grandes quantidades de
informa¸c˜oes de uma maneira mais natural, diversos pain´eis de textos e anima¸c˜oes
podem ser usados para apresenta¸c˜ao de dados cient´ıficos.
80
Referˆencias Bibliogr´aficas
Atomic coordinate entry format description. wwPDB, 2008.
http://www.wwpdb.org/documentation/Format v32 A4.pdf (acessado em
21/10/2008).
Federal Standard 1037C. polarization. Telecommunications: Glossary of
Telecommunication Terms, 2002. http://www.its.bldrdoc.gov/fs-1037/dir-028/-
4059.htm (Acessado em 22/11/2008).
Andrea L Ames, David R Nadeau, e John L Moreland. VRML 2.0 Sourcebook.
Wiley, 2 edition edi¸c˜ao, December 1996.
Autodesk. Autodesk 3ds max. http://usa.autodesk.com/adsk/servlet/index?id=5659302&siteID=123112
(acessado em 28/11/2008).
Matthias Berth, Frank Michael Moser, Markus Kolbe, e J
¨
org Bernhardt. The state
of the art in the analysis of two-dimensional gel electrophoresis images. Applied
Microbiology and Biotechnology, 76(6):1432–0614, October 2007.
Max Born e Emil Wolf. Principles of Optics. Cambridge University, 1999.
Doug A. Bowman, ERnst Kruijff, Joseph J. LaViola, e Ivan Poupyrev. 3D User
Interfaces: Theory and Practice. Addison-Weskey, August 2005.
Christian Brosseau. Fundamentals of Polarized Light: A Statistical Optics
Approach. Wiley-Interscience, 1998.
Don Brutzman e Leonardo Daly. X3D EXTENSIBLE 3D GRAPHICS FOR
WEB AUTHORS. Morgan Kaufmann, April 2007.
81
Grigore C. Burdea e Philippe Coiffet. Virtual Reality Technology. Wiley-
Interscience, 1994.
Cruz-Neira C., Langley R., e Bash P.A. Vibe: a virtual biomolecular environment
for interactive molecular modeling. Applied Mathematics and Computa-
tion, 20:469–477, 1996.
Samuel H. Cohen e Marcia L. Lightbody. Atomic Force Microscopy/Scanning
Tunneling Microscopy 3. Springer, 1999.
S. M. H. Collin. Dicion´ario de Inform´atica, Multim´ıdia e Realidade Vir-
tual. Melhoramentos, 2001.
Jmol Community. Jmol: an open-source java viewer for chemical structures in 3d.
http://jmol.sourceforge.net/ (Acessado em 24/11/2008).
Ascension Techology Corporation. http://www.ascension-
tech.com/realtime/RTnestofBirds.php (acessado em 20/06/2009).
Carolina Cruz-Neira, Daniel J. Sandin, Thomas A. DeFanti, Robert V. Kenyon, e
John C. Hart. The cave: audio visual experience automatic virtual environment.
Commun. ACM, 35(6):64–72, 1992.
Clodoveu A.D. Jr. Davis e Antonio M.V.M. Monteiro. Advances in geoinformatics:
Viii brazilian symposium on geoinformatics. In: GEOINFO 2006, 2006.
Harvey Deitel e Paulo Deitel. Java: como programar. Person Prentice Hall, 6
ed. edi¸c˜ao, 2005.
SUN CENTER OF EXCELLENCE for VISUAL GENOMICS. Cave technical
highlights. http://www.visualgenomics.ca/index.php?option=com content&task=view&id=120&Itemid=207
(acessado em 02/03/2009).
Alexander Hass, Stefan Hertwig, e Indraneil Das. Extreme tadpoles: The mor-
phology of the fossorial megophryid larva, Leptobrachella mjobergi. Zoology,
109:26–42, 2006.
82
Eugene Hecht. Optics. Addison Wesley, 4th edition edi¸c˜ao, 2002.
Steven Holzner. Desvendando XML. Campus, 2001.
Michal Huˇs´ak, Christoph Anthes, e Paul Heinzlreiter. MCE–CAVE: program for
interactive visualization of electron density maps within the cave virtual-reality
environment. Journal of Applied Crystallography, 36(6):1484–1485, Dec
2003. URL http://dx.doi.org/10.1107/S0021889803021046.
HyperPhysics. http://hyperphysics.phy-astr.gsu.edu/hbase/phyopt/polclas.html
(acessado em 20/06/2009).
instantlabs. Componentes x3d para instantreality.
http://www.instantreality.de/documentation/nodetype/standards=X3D2.0,X3D3.0,X3D3.1,X3D3.2/
(Acessado em 24/11/2008).
instantlabs. instantreality, 2008. http://www.instantreality.de/home/ (acessado
em 24/11/2008).
John David Jackson. Classical Electrodynamics. Wiley, 1998.
Anil K. Jain. Fundamentals of Digital Image Processing. Cap´ıtulo Two-
Dimensional Systems and Mathematical Preliminaries, p´aginas 11 – 48, Prentice
Hall, 1989.
J. C. Kendrew, G. Bodo, H. M. Dintzis, R. G. Parrish, H. Wyckoff, e D. C. Phillips.
A three-dimensional model of the myoglobin molecule obtained by x-ray analysis.
Nature, 181:662–666, 1958.
Sheng Liang. Java(TM) Native Interface: Programmer’s Guide and Spec-
ification. Prentice Hall PTR, 1999.
Feng Liu. PLATFORM INDEPENDENT REAL-TIME X3D SHADERS
AND THEIR APPLICATIONS IN BIOINFORMATICS VISUAL-
IZATION. Tese de Doutorado, Georgia State University, 2005.
83
Bruce H. McCormick, Thomas A. DeFanti, e Maxine D. Brown. Visualization
in Scientific Computing. ACM Press, 1987.
NEC. Nec portable projectors lt245 and lt265, a.
http://www.necvisualsystems.com/cms/documents/ColorBrochures/NEC090450.pdf
(Acessado em 25/11/2008).
NEC. Xt5100 and sx6000, b. http://www.media-
vision.de/international/pdf/datasheets/nec/event xt5100.pdf (acessado
02/03/2009).
NIH. Imagej image processing and analysis in java, 1997.
http://rsb.info.nih.gov/ij/ (acessado em 02/03/2009).
nstantlabs. Java eai api documentation for instantreality.
http://www.instantreality.de/media/apidocs/java/index.html (acessado em
18/10/2008).
R
¨
udiger Paschotta. Encyclopedia of Laser Physics and Technology. Wiley-
VCH, 2008.
Pausch, Randy, Jon Snoddy, Robert Taylor, Scott Watson, e Eric Haseltine. Dis-
ney’s aladdin: First steps toward storytelling in virtual reality. In: Computer
Graphics (Proceedings of SIGGRAPH 96, Annual Conference Series),
p´aginas 193–203, 1996.
RCSB. Protein data bank - an information portal to biological macromolecular
structures. http://www.pdb.org/ (acessado em 11/02/2009).
John R. Reitz, Frederick J. Milford, e Robert W. Christy. Foundations of Elec-
tromagnetic Theory. Addison Wesley, 1992.
Jr. Richard S Wright, Benjamin LIpchak, e Nicholas Haemel. OpenGL Super-
Bible. Addison-Weskey, fourth edition edi¸c˜ao, 2007.
84
David F. Rogers. Procedural Elements of Computer Graphics. McGraw-Hill,
2nd edition edi¸c˜ao, 1997.
David F. Rogers e J. Alan Adams. Mathematical Elements for Computer
Graphics. McGraw-Hill, 2nd edition edi¸c˜ao, 1989.
L. Rosenblum, R. A. Earnshaw, J. Encarnacao, H. Hagen, A. Kaufman, S. Kli-
menko, G. Nielson, F. Post, e D. Thalmann. Scientific Visualization Ad-
vances and Challenges. Academic Press, 1994.
Randi J. Rost. OpenGL Shading Language. Addison-Wesley Professional,
second edition edi¸c˜ao, February 2006.
Marcus Roth, Patrick Riess, e Dirk Reiners. Load balancing on cluster-based multi
projector display suystems. In: WSCG’2006, 2006.
Michel F. Sanner, Arthur J. Olson, e Jean-Claude Spehner. Fast and robust com-
putation of molecular surfaces. Proc. 11th ACM Symp. Comp. Geom.,
C6-C7, 1995, 1995.
William R Scherman e Alan B Craig. Understanding Virtual Reality. Morgan
Kaufmann Plublishers, 2003.
Robson Augusto Siscoutto, Fl´avio Szenberg, Romero Tori, Alberto B. Raposo,
Waldemar Celes, e Marcelos Gattas. Realidade Virtual: Conceitos e
Tendˆencias. Cap´ıtulo 11, p´aginas 179–201, Editora Mania de Livro, 2004.
Mel Slater, Anthony Steed, e Yiorgos Chrysanthou. Computer Graphics and
Virtual Environments. Cap´ıtulo 6, p´aginas 133–154, Addison Welsley, 2002.
Lincoln Stein. Generic genome browser, June 2003.
http://iubio.bio.indiana.edu/gmod/gbrowse/ (Acessado em 24/11/2008).
Julie N. Stromer, Gerald T. Quon, Paulo M.K. Gordon, Adrei L. Turinsky, e
Christoph W. Sensen. Jabiru: harnessing java 3d behaviors for device and display
85
portability. Computer Graphics and Applications, IEEE, 25(2):70–80,
March-April 2005.
Ascension technology Corporation. minibird brochure. http://www.ascension-
tech.com/docs/minibird brochure8 02.pdf (acessado em 27/11/2008).
TSRI. Virus particle explorer. http://viperdb.scripps.edu/ (acessado em
19/06/2009).
UCSF. Ucsf chimera : an extensible molecular modeling system.
http://www.cgl.ucsf.edu/chimera/ (Acessado 24/11/2008).
Arne Valberg. Light Vision Color. Wiley, 2005.
John Vince. Introduction to Virtual Reality. Springer, 2004.
Qiming Wang. Package for translating between vrml97 and x3d files, 2004.
http://ovrt.nist.gov/v2 x3d.html (acessado em 28/11/2008).
Andrew Webb. Introduction to Biomedical Image. Cap´ıtulo 1, p´aginas 1–56,
John Wiley AND Sons, Inc, 2003a.
Andrew Webb. Introduction to Biomedical Image. Cap´ıtulo 4, p´aginas 157–
219, John Wiley AND Sons, Inc, 2003b.
Josie Wernecke. The Inventor Mentor: Programming Object-Oriented
3D Graphics with Open Inventor. Number ISBN0-201-62495-8. Addison-
Wesley, release 2 edi¸c˜ao, 1994.
K. Wuthrich. Protein structure determination in solution by nmr spectroscopy. J.
Biol. Chem, 265(36):22059–22062, 1990.
86
Apˆendice A
Software de Controle do CAVE
A.1 Parte em X3D do controle do CAVE
1 <?xml version=” 1 . 0 ” en coding=”UTF−8”?>
2 < !DOCTYPE X3D PUBLIC ”ISO//Web3D//DTD X3D 3.1//EN” ” h t t p : //www. web3d . or g /
s p e c i f i c a t i o n s /x3d − 3.1 . dtd ”>
3 <X3D p r o f i l e= ’ Immersive ’ version=’ 3 . 1 ’ x mln s:x sd= ’ ht t p : //www. w3 . org /2001/XMLSchema
−i n s t a n c e ’ xsd:noNamespaceSchemaLocation= ’ h t t p : //www. web3d . org / s p e c i f i c a t i o n s /
x3d −3 . 1. xsd ’>
4 <Engine>
5 <RenderJob>
6 <WindowGroup>
7 <LocalWindow enabled=”FALSE”/>
8 <ClusterWindow containerField= ’ windows ’ se rv ers= ’ ”c av e1 ” ”cave2 ” ”
ca ve3 ” ”cave 4 ” ’ hServers=”4 ” vServers=”1 ” s i ze=”8192 768 ”
balance=” f a l s e ” showBalancing=” f a l s e ”>
9 <!−− Parede da Frente , ´a rea de imagem para olho e sq ue rd o ,
CAVE1 −−>
10 <Viewarea containerField= ’ v ie w s ’ lowerLeft=’ 140 5 ’
upperRight= ’ 976 710 ’>
11 <!−− Mo dif ic aca o dos param etros da camera −−>
12 <ProjectionViewModifier DEF= ’ pF renteOes querdo ’ surf ace= ’
0.927 5 −1.4000 −1.5000 , 0 . 9 275 0 . 8 000 −1.5000 , 0 .9275
0.800 0 −1.5000 , −0.9275 −1.4000 −1.5000 ’ lef tE ye= ’TRUE
’ rightEye=’FALSE ’ eyeSeparation=’ 0. 0 8 ’ />
13 </Viewarea>
14 <!−− Parede da Frente , are a de imagem para o l h o d i r e i t o ,
CAVE1 −−>
15 <Viewarea containerField= ’ v ie w s ’ lowerLeft=’ 1166 58 ’
upperRight= ’ 2001 767 ’>
16 <ProjectionViewModifier DEF= ’ p F r e n t e O d i r e i t o ’ surfa ce= ’
0.927 5 −1.4000 −1.5000 , 0 . 9 275 0 . 8 000 −1.5000 , −0.9275
87
0.800 0 −1.5000 , −0.9275 −1.4000 −1.5000 ’ lef tE ye= ’
FALSE ’ rightEye= ’TRUE’ eyeSeparation=’ 0 . 0 8 ’ />
17 </Viewarea>
18 <!−− Parede da Esquerda , ´a rea de imagem para o l h o d i r e i t o ,
CAVE2 −−>
19 <Viewarea containerField= ’ v ie w s ’ lowerLeft=’ 2082 4 ’
upperRight= ’ 2937 654 ’>
20 <ProjectionViewModifier DEF= ’ p E squ e rda O dir e ito ’ sur fa ce= ’
−0.9275 −1.6000 −1.5000 , −0.9275 0 . 8 0 0 0 −1.5000 ,
−0.9275 0 . 8 0 00 0 . 35 5 0 , −0.9275 −1.6000 0 . 3 5 5 0 ’ l eftEye
= ’FALSE ’ rightEye= ’TRUE’ eyeSeparation=’ 0 . 0 8 ’ />
21 </Viewarea>
22 <!−− Parede da Esquerda , ´a rea de imagem para o l h o es qu er do ,
CAVE2 −−>
23 <Viewarea containerField= ’ v ie w s ’ lowerLeft=’ 3116 43 ’
upperRight= ’ 3972 694 ’>
24 <ProjectionViewModifier DEF= ’ pEsquerdaOesquerdo ’ sur fa ce= ’
−0.9275 −1.6000 −1.5000 , −0.9275 0 . 8 0 0 0 −1.5000 ,
−0.9275 0 . 8 0 00 0 . 35 5 0 , −0.9275 −1.6000 0 . 3 5 5 0 ’ l eftEye
= ’TRUE’ rightEye= ’FALSE ’ eyeSeparation=’ 0 . 0 8 ’ />
25 </Viewarea>
26 <!−− Parede da Direi t a , ´area de imagem para o l h o es qu erdo ,
CAVE3 −−>
27 <Viewarea containerField= ’ v ie w s ’ lowerLeft=’ 4153 56 ’
upperRight= ’ 5037 721 ’>
28 <ProjectionViewModifier DEF= ’ p D i rei t aOe s q uer d o ’ s urfac e=’
0.927 5 −1.6000 0 . 35 5 0 , 0 . 9275 0 .8000 0 . 3 5 50 , 0.92 7 5
0.800 0 −1.5000 , 0 .9275 −1.6000 −1.5000 ’ left Eye=’TRUE ’
rightEye=’FALSE ’ eyeSeparation=’ 0. 0 8 ’ />
29 </Viewarea>
30 <!−− Parede da Direi t a , ´area de imagem para o l h o d i r e i t o ,
CAVE3 −−>
31 <Viewarea containerField= ’ v ie w s ’ lowerLeft=’ 5170 98 ’
upperRight= ’ 6055 767 ’>
32 <ProjectionViewModifier DEF= ’ p D i r e i t a O d i r e i t o ’ surf ace= ’
0.927 5 −1.6000 0 . 35 5 0 , 0 . 9275 0 .8000 0 . 3 5 50 , 0.92 7 5
0.800 0 −1.5000 , 0 .9275 −1.6000 −1.5000 ’ left Eye=’FALSE
’ rightEye=’TRUE ’ eyeSeparation=’ 0.08 ’ />
33 </Viewarea>
34 <!−− Parede de Baixo , ´area de imagem para o l h o d i r e i t o ,
CAVE4 −−>
35 <Viewarea containerField= ’ v ie w s ’ lowerLeft=’ 6144 79 ’
upperRight= ’ 7118 725 ’>
88
36 <ProjectionViewModifier DEF= ’ pBai x o Odir e i to ’ s ur face= ’
−0.9275 −1.5830 −0.2260 , 0 . 9 2 75 −1.5830 −0.2260 ,
0.927 5 −1.4000 −1.5000 , −0.9275 −1.4000 −1.5000 ’
leftE ye= ’FALSE ’ rightEye=’TRUE ’ eyeSeparation=’ 0.08 ’ /
>
37 </Viewarea>
38 <!−− Parede da Baixo , ´area de imagem para o l h o esquerdo ,
CAVE4 −−>
39 <Viewarea containerField= ’ v ie w s ’ lowerLeft=’ 7168 2 ’
upperRight= ’ 8170 679 ’>
40 <ProjectionViewModifier DEF= ’ pBaixoOesquerdo ’ s urfac e=’
−0.9275 −1.5830 −0.2660 , 0 . 9 2 75 −1.5830 −0.2660 ,
0.927 5 −1.4000 −1.5000 , −0.9275 −1.4000 −1.5000 ’
leftE ye= ’TRUE ’ rightEye= ’FALSE ’ eyeSeparation=’ 0 . 0 8 ’ /
>
41 </Viewarea>
42 </ClusterWindow>
43 </WindowGroup>
44 </RenderJob>
45
46 <!−− I n i c i o da p a r t e do c odig o para c o n t r o l e do t r a c k i n g que f i c a a cardo do
p l a ye r de X3D −−>
47
48 <!−− De fi ne um NODO X3D SFMatr ix4f com os v a l o r ret o r n a d o s p e l o t r a c k i n g −−>
49 <Script DEF=”Matriz ”>
50 <f i e l d accessType=”inputOnly ” name=” s e t m a t r i x 4 f ” type=”MFFloat ”/>
51 <f i e l d accessType=”outputOnly ” name=” get e yeT r ans f orm ” type=”SFMatrix4f ”
/>
52 <! [CDATA[
53 e c m a s c r i p t :
54 // Ma tr iz normal de t r a nsfo r m a¸c˜a o
55 // | r 11 r12 r13 tX |
56 // M = | r21 r22 r23 tY |
57 // | r 31 r32 r33 tZ |
58 // | 0 0 0 1 |
59 // M = new VrmlMatrix ( r11 , r12 , r13 , tX , r21 , r22 , r23 , tY , r31 ,
r32 , r33 , tZ , 0 , 0 , 0 , 1 ) ;
60 f u n c t i o n s e t m a t r i x 4 f ( v e t o r ) {
61 get e yeT r ans f orm = new VrmlMatrix ( 1 , 0 , 0 , vet o r [ 0 ] , 0 , 1 ,
0 , v e t o r [ 2 ] , 0 , 0 , 1 , v e t o r [ 1 ] , 0 , 0 , 0 , 1) ;
62 }
63 ] ]>
64 </ Script>
65
89
66 <!−− Apl i c a as t ran s form a coes nas are a s de v i s u a l i z a c a o −−>
67 <ROUTE fromNode= ’ Matriz ’ fromField=’ ge t e yeT r ans f orm ’ toNode= ’
pFrenteOesquerdo ’ toField= ’ set e y e T r ansf o r m ’ />
68 <ROUTE fromNode= ’ Matriz ’ fromField=’ ge t e yeT r ans f orm ’ toNode= ’
p F r e n t e O d i r e i t o ’ toFiel d=’ se t e y e Tran s f o r m ’ />
69 <ROUTE fromNode= ’ Matriz ’ fromField=’ ge t e yeT r ans f orm ’ toNode= ’
pEsquerdaOesquerdo ’ toFiel d=’ se t e y e Tran s f o r m ’ />
70 <ROUTE fromNode= ’ Matriz ’ fromField=’ ge t e yeT r ans f orm ’ toNode= ’
pEs q uer d aOd i rei t o ’ toF ield= ’ s e t e y e T r ansf o r m ’ />
71 <ROUTE fromNode= ’ Matriz ’ fromField=’ ge t e yeT r ans f orm ’ toNode= ’
pDi r eita O esq u erdo ’ toFiel d=’ se t e y e Tran s f o r m ’ />
72 <ROUTE fromNode= ’ Matriz ’ fromField=’ ge t e yeT r ans f orm ’ toNode= ’
p D i r e i t a O d i r e i t o ’ toFie ld= ’ s et e y e T r ansfo r m ’ />
73 <ROUTE fromNode= ’ Matriz ’ fromField=’ ge t e yeT r ans f orm ’ toNode= ’
pBaixoOesquerdo ’ toField= ’ s et e y e T r ansfo r m ’ />
74 <ROUTE fromNode= ’ Matriz ’ fromField=’ ge t e yeT r ans f orm ’ toNode= ’ p B a ixoO d i reit o
’ toFie ld= ’ s et e y e T r ansf o r m ’ />
75
76 <!−− Fim da p a r t e do c o g i g o para o c o n t r o l e do de t r a c k i n g−−>
77
78 </Engin e>
79 <Scene>
80 <!−− I n i c i o do cod i g o para c o n t r o l e do j o y s t i c k −−>
81 <IOSensor DEF=” i o s ” type=” j o y S t i c k ”>
82 <f i e l d accessType= ’ outputOnly ’ name= ’ ∗ x∗ a x i s ’ type= ’ SFFloat ’ />
83 <f i e l d accessType= ’ outputOnly ’ name= ’ ∗ y∗ a x i s ’ type= ’ SFFloat ’ />
84 <f i e l d accessType= ’ outputOnly ’ name= ’ ∗ z ∗ a x i s ’ type= ’ SFFloat ’ />
85 <f i e l d accessType= ’ outputOnly ’ name= ’ ∗ z ∗ r o t ∗ ’ type= ’ SFFloat ’ />
86 <f i e l d accessType= ’ outputOnly ’ name= ’ ∗ bu tton ∗ 7 ’ type= ’ SFBool ’ />
87 </IOSensor>
88
89 <NavigationInfo type= ’ ”examine ” ”any ” ’>
90 <SteerNavigator DEF= ’ nav ’ inputRange= ’ 0 1 ’ z e r oD e f l e c t i o n T r an s= ’ 0 . 5 0 . 5
0 . 5 ’ z e r o D e f l e c t i on R o t= ’ 0 . 5 0 . 5 0 . 5 ’ r o t a t i o n S p e e d= ’ −0.2 −0.2 −0.2 ’
t r a n s l a t i o n S p e e d= ’ 1 . 0 1 . 0 1 .0 ’ />
91 </NavigationInfo>
92
93 <ROUTE fromNode= ’ i o s ’ fromField=’ ∗ y∗ a x i s ’ toNode= ’ nav ’ toFi eld= ’
s e t x R o t a ti o n ’ />
94 <ROUTE fromNode= ’ i o s ’ fromField=’ ∗ x∗ a x i s ’ toNode= ’ nav ’ toFi eld= ’
s e t y R o t a ti o n ’ />
95 <ROUTE fromNode= ’ i o s ’ fromField=’ ∗ z ∗ a x i s ’ toNode= ’ nav ’ toFi eld= ’
s e t x T r a n s l a t i o n ’ />
90
96 <ROUTE fromNode= ’ i o s ’ fromField=’ ∗ z ∗ r o t ∗ ’ toNode= ’ nav ’ toField= ’
s e t z T r a n s l a t i o n ’ />
97
98 <ROUTE fromNode= ’ i o s ’ fromField=’ ∗ button ∗ 7 ’ toNode= ’ nav ’ toField= ’
updat eRo tat ionCe nte r ’ />
99 <!−− Fim do c odig o para j o y s t i c k−−>
100 <Viewp oint pos iti on=”0 . 0 −0.15 −1.3 ”/>
101 <Transform t r a n s l a t i o n= ’ 0.0 0 . 0 0 . 0 ’>
102 <!−− carr e g a cen a r i o s extern o −−>
103 <In l in e ur l= ’ . . \ modelosVRMLeX3D\ f a c e . wr l ’ />
104 </Transform>
105 </Scene>
106 </X3D>
C´odigo A.1: C´odigo completo em X3D para o CAVE do LNCC.
A.2 Parte em Java para controle do NestOfBirds
1 /∗
2 ∗ To change t h i s tem pla t e , ch oose To ols | Templates
3 ∗ and open t h e t e mplate in t h e e d i t o r .
4 ∗ /
5
6 /∗ ∗
7 ∗
8 ∗ @author tre n hag o
9 ∗ /
10 import vrml . e a i . Browser ;
11 import vrml . e a i . e ve n t . BrowserEvent ;
12 import vrml . e a i . Br owserFactor y ;
13 import vrml . e a i . e ve n t . Browser L i s t e n e r ;
14 import vrml . e a i . Node ;
15 import vrml . e a i . f i e l d . EventInMFFloat ;
16
17 import j a va . net . Ine t A ddre s s ;
18
19 public c l a s s ControlX3DTracking {
20 private s t a t i c EventInMFFloat s e t m a t r i x 4 f ;
21 public s t a t i c boolean ca ptu ra = true ;
22 /∗ ∗
23 ∗ @param args t h e command l i n e arguments
24 ∗ /
25 public s t a t i c void main ( S t r i n g [ ] a r g s ) {
26 f i n a l NestOfBird nob = new Ne stOfBird () ;
27 nob . i n i t i a l i z e ( ) ;
91
28 nob . setDataFormat ( 1 ) ;
29
30 // Espera o t r a c k i n g i n i c i a l i z a r
31 nob . bir dS ta rt Fr am eS tr ea m ( ) ;
32
33 Browser browse r = nu ll ;
34 try {
35 // I n i c i a l i z a a conexao
36 Inet A d dre s s addres s = I n etAd d r ess . getByName ( ” l o c a l h o s t ”) ;
37 browse r = Br owserFact or y . ge tBrow se r ( add res s , 48 48) ;
38
39
40 // tr ata men to de e v e n t o s do brow se r I n s t a n tP l a y er
41 browse r . ad dBr o wser L ist e ner (
42 new Browse r L i s t e n e r ( ) {
43 public void browserChanged ( BrowserEvent ev ent ) {
44 switch ( e ve n t . g etID ( ) ) {
45 case BrowserEvent . INITIALIZED :
46 b reak ;
47 case BrowserEvent .SHUTDOWN:
48 case BrowserEvent .URL ERROR:
49 case BrowserEvent .CONNECTION ERROR:
50 d efau lt :
51 ControlX3DTracking . ca ptu ra = f a l s e ;
52 f or ( long n = 0 ; n < 10 000 0 000; n++) ; // apenas
um t e s t e
53 nob . birdStopFrameStream ( ) ;
54 nob . shutDown ( ) ; // d e s l i g a o t r a c k i n g
cor ret ame nte
55 System . out . p r i n t l n ( ”Ne st OfBirds d e s l i g a d o . . . . ”
) ;
56 System . e x i t ( 0) ;
57 }
58 }
59 }
60 ) ;
61
62 Node ma tri z = b rowser . getNode ( ”e n g i n e : : Matriz ”) ;
63 s e t m a t r i x 4 f = ( EventInMFFloat ) m a tri z . ge tEv en tIn ( ” s e t m a t r i x 4 f ”) ;
64
65 // Executa para sempre
66 while ( ControlX3DTracking . cap t ura ) {
67 // T racking d e v o l v e as p o s i co e s em p o l e g a d a s . . . .
68 s e t m a t r i x 4 f . s e t Value ( nob . g e t P o s i t i o n ( ) ) ;
92
69 Thread . s l e e p ( 1 5 ) ;
70 }
71
72 } catch ( Throwable a l l ) {
73 a l l . p r intStac k T r a c e ( ) ;
74 } f i n a l l y {
75 // Shutdown
76 System . out . p r i n t l n ( ”N es tO fBird s d e s l i g a d o . . . ”) ;
77 i f ( br owser != null ) {
78 br ow ser . d i s p o s e ( ) ;
79 }
80 }
81 }
82
83 }
C´odigo A.2: Modulo intermedi´ario, integra o InstantReality ao NestOfBirds
1 /∗
2 ∗ To change t h i s tem pla t e , ch oose To ols | Templates
3 ∗ and open t h e t e mplate in t h e e d i t o r .
4 ∗ /
5
6 /∗ ∗
7 ∗
8 ∗ @author tre n hag o
9 ∗ /
10 public c l a s s NestOfBird {
11 /∗ ∗ o parametro b i r d s i n d i ca de qua nto s s e n s o res sao r e tor n ado os dados .
12 ∗ Retorna uma m atr i z 2D com coordenadas de p o s i c a o em metr os e
13 ∗ an g u los em r adi a n os . Veja o manual do Nest o f Bir ds para mais d e t a l h e s . ∗ /
14 public native f l o a t [ ] g e t P o s i t i o n ( ) ;
15 public native f l o a t [ ] [ ] get A n gles ( in t b i r d s ) ;
16 public native f l o a t [ ] [ ] g etM atr ix ( i nt b i r d s ) ;
17 public native f l o a t [ ] [ ] g e tQu ate r nio n ( in t b i r d s ) ;
18 public native f l o a t [ ] [ ] g e tP o s i ti o n A ng l e s ( i nt b i r d s ) ;
19 public native f l o a t [ ] [ ] g e t P o si t i o n M a t ri x ( i nt b i r d s ) ;
20 public native f l o a t [ ] [ ] g e t P o s i t i o nQuat e r n i o n ( in t b i r d s ) ;
21
22 /∗ ∗ re t o r n a um t e x t o informando q u a l f o i o ulti m o e r r o r . ∗ /
23 public native S t r i n g get E rr o rMe ssa ge ( ) ;
24
25 /∗ ∗ d e s l i g a o Nest Of Bir ds corretamente , retor n a 0 s e s u c e s s o . ∗ /
26 public native i nt shutDown ( ) ;
27
93
28 /∗ ∗ l i g a o Nest Of Birds , a t i v a t o d o s os s e n s o r e s e o trans m i s s o r .
29 ∗ Retorna o numero de s e n s o r e s de ras tre ame nto c o nect a dos e a t i v a d o s . ∗ /
30 public native i nt i n i t i a l i z e ( ) ;
31
32 /∗ ∗ a j u s t a o forma to de dados t r a n s m i t i d o s .
33 ∗ Formatos v a l i d o s :
34 ∗ BDF NOBIRDDATA 0 no dat a (NOTE: RS232 and ISA modes have no
way of s p e c i f y i n g t h i s fo rmat )
35 ∗ BDF POSITION 1 p o s i t i o n on l y
36 ∗ BDF ANGLES 2 a n g l e s o n ly
37 ∗ BDF MATRIX 3 matri x o nly
38 ∗ BDF POSITIONANGLES 4 p o s i t i o n and a n g l e s
39 ∗ BDF POSITIONMATRIX 5 p o s i t i o n and ma tr ix
40 ∗ BDF QUATERNION 7 q uater n i o n o n ly
41 ∗ BDF POSITIONQUATERNION 8 p o s i t i o n and q uater n i o n
42 ∗ ==========================================================================
43 ∗ r e t o rna 0 , s e s u c e s s o . . . ∗ /
44 public native i nt setDataFormat ( i nt birdsDataFormat ) ;
45
46 /∗ ∗ a j u s t a a p o s i c ao de origem para t o d os os s ens o res , v a l o r e s em c e n t i m e t r o s .
∗ /
47 public native void setHome ( double x , double y , double z ) ;
48
49 /∗ ∗ i n i c i a o proce s s o de a q u i s i c a o de dados dos s e n s o r e s ∗ /
50 public native void bir dS ta rt Fr am eS tr ea m ( ) ;
51
52 /∗ ∗ te rmina o p r o c e sso de a q u i si c a o de dados dos s e n s o r e s ∗ /
53 public native void birdStopFrameStream ( ) ;
54
55 /∗ ∗ ca r r ega a DLL Ne st Of Birds . d l l ∗ /
56 s t a t i c {
57 System . loadLi b r a r y ( ”NestO fBird ”) ;
58 }
59 }
C´odigo A.3: Classe com m´etodos nativos para controlar o NestOfBirds
A.3 C´odigo em C para o NestOfBirds
1 #include <windows . h>
2 #include <s t d i o . h>
3 #include <wincon . h>
4 #include <s t r i n g . h>
5 #include <b ird . h>
6 #include < j n i . h>
94
7 #include ”NestOfBir d . h”
8
9 // The o b j e c t i v e o f t h i s program i s to d em onstr at e t h e b a s i c s t e p s n ecc e sary
10 // to c o n f i g u r e and run t h e Nest o f Bi rds . This program w i l l onl y us e t h e
11 // commands a v a i l a b l e i n t h e Bird Windows Dr i ver .
12
13 #def in e GROUP ID 1 // a r b i t r a r y d e s i g n a t i o n f o r group
14 #def in e MAX DEVICE COUNT 5 // maximum p o s s i b l e number of b i r d s in
n e s t
15 #def in e READ TIMEOUT 2000 // 2000 mSec (2 sec ond s )
16 #def in e WRITE TIMEOUT 2000 // 2000 mSec (2 se con ds )
17 #def in e BAUD RATE 115200 // 115. 2K baud
18 #def in e ANY XMTR 0x0F // BFS ERT3 | BFS ERT2 | BFS ERT1 |
BFS ERT0
19 #def in e XMTR 0 x01
20 #def in e MAX XMTRS 5
21
22 // Glo b a l v a r i a b l e s
23 BOOL s t a t u s = 0 ; // r e t u rn s t a t u s o f b i r d c a l l s
24 BOOL valid COM port = FALSE ; // Flag i n d i c a t i n g t h e use r h as i n p u t a
25 // v a l i d COM p o r t
26
27 WORD COM port [ 6 ] = { 0 , 3 , 0 , 0 , 0 , 0 } ; // se e birdRS232WakeUp
28 // d e s c r i p t i o n f o r d e t a i l s
29 WORD xmtrIndex =0;
30 WORD r c v r I n d e x =0;
31 unsigned char xm tr cf g cmd [MAX XMTRS ] ;
32 unsigned char xmt r t ype [MAX XMTRS] ;
33 unsigned char srtCount = 0 ;
34 unsigned char ertCount = 0 ;
35
36 BIRDSYSTEMCONFIG s y s c o n f i g ;
37 BIRDDEVICECONFIG d e vc o n f i g [MAX DEVICE COUNT ] ;
38
39 i nt i , j ;
40 i nt n u mbe r ofd e vic e s = 0 ; // a c t u a l number o f d e v i c e s found
41 unsigned char bird cmd [ 2 0 ] ;
42 s t a t i c char mError [ 1 0 0 0 ] ; // u ltim a mensagem de e r ro
43 double measur em en t rate = 8 5 . 0 ; // v a ores v a l i d o s 20 − 120
44
45 // V a r i a v e i s para birdGetMostRecentFrame
46 BIRDFRAME frame ;
47 j f l o a t pos [ 3 ] ;
48 BIRDREADING ∗ b i rd d a t a ;
95
49
50 JNIEXPORT j i n t JNICALL
51 J a v a N e s t O f B i r d i n i t i a l i z e ( JNIEnv ∗ env , j o b j e c t obj ) {
52 COM port [ 1 ] = 1 ; // d e f i n e a po r t a COM
53 s t a t u s = birdRS232WakeUp (GROUP ID, FALSE, MAX DEVICE COUNT, COM port ,
54 BAUD RATE, READ TIMEOUT, WRITE TIMEOUT) ;
55 i f ( ! s t a t u s ) {
56 s t r c p y ( mError , ”Couldn ’ t wake up n e s t . \ n ”
57 ”Make s u r e t he Nest i s powered on and the \n ”
58 ” s e r i a l c a bl e i s a t tac h e d to the s p e c i f i e d por t . \n\n ”) ;
59 return 0 ;
60 }
61 s t a t u s = b ir dG etSystemCon fi g (GROUP ID, &s y s c o n f i g ) ;
62 i f ( ! s t a t u s ) {
63 s t r c p y ( mError , ”Couldn ’ t g e t system c o n f i g u r a t i o n . \ n\n ” ) ;
64 return 0 ;
65 }
66 // Count up how many de v i c e s ar e o ut t h e r e
67 f or ( i =1; i<=MAX DEVICE COUNT; i ++) {
68 i f ( ( s y s c o n f i g . by F loc kSt a tus [ i ] & BFS FBBACCESSIBLE) == BFS FBBACCESSIBLE)
{
69 // fo und a d ev i c e we can t a l k to , incremen t d e vi c e c ount
70 num b ero f dev i ces ++;
71 } // end i f ( s y s c o n f i g . . .
72 } // end f o r ( i = 1 ; . . .
73 birdShutDown (GROUP ID) ;
74 s t a t u s = birdRS232WakeUp (GROUP ID, FALSE, n umb erofd evi ce s , COM port ,
75 BAUD RATE, READ TIMEOUT, WRITE TIMEOUT) ;
76 i f ( ! s t a t u s ) {
77 s t r c p y ( mError , ”Couldn ’ t wake up n e s t . \ n ”
78 ”Make s u r e t he Nest i s powered on and the \n ”
79 ” s e r i a l c a bl e i s a t tac h e d to the s p e c i f i e d por t . \n\n ”) ;
80 return 0 ;
81 }
82 s t a t u s = b ir dG etSystemCon fi g (GROUP ID, &s y s c o n f i g ) ;
83 i f ( ! s t a t u s ) {
84 s t r c p y ( mError , ”Couldn ’ t g e t system c o n f i g u r a t i o n . \ n\n ” ) ;
85 return 0 ;
86 }
87 s y s c o n f i g . dMeasurementRate = measure me nt rat e ; // measurement r at e i n
h e r t z
88 s t a t u s = bird S etS y ste m Conf i g (GROUP ID, &s y s c o n f i g ) ;
89
90 f or ( i =1; i<=n umb e rof d evi c es ; i ++) {
96
91 unsigned char temp ;
92
93 i f ( ( s y s c o n f i g . by F loc kSt a tus [ i ] & BFS FBBACCESSIBLE) != BFS FBBACCESSIBLE)
{
94 s p r i n t f ( mError , ”B ird %1u not r e spon d i n g . \ n ” , i ) ;
95 } el s e {
96 s t a t u s = bi rdGe t Dev i c eCo n fig (GROUP ID, i , &d e v c o n fi g [ i − 1]) ;
97 i f ( ! s t a t u s ) {
98 s p r i n t f ( mError , ”Couldn ’ t get d e v i c e %1u c o n f i g u r a t i o n . \ n ” , i ) ;
99 }
100
101 i f ( ( s y s c o n f i g . b yFl o ckS tat u s [ i ] & BFS RECEIVERPRESENT) ==
BFS RECEIVERPRESENT) {
102 r c v r I n d e x ++;
103 } // end i f ( ( s y s c o n f i g . b y F l ock S t a t u s [ i ] & BFS RECEIVERPRESENT) . . .
104 i f ( s y s c o n f i g . b yFl o ckS t atu s [ i ] & ANY XMTR) {
105 i f ( ( s y s c o n f i g . b yFl o ckS tat u s [ i ] & BFS ERC) == BFS ERC) {
106 temp = s y s c o n f i g . by F loc k Sta tus [ i ] & ANY XMTR;
107 fo r ( j =0; j <4; j++) {
108 i f ( ( temp & XMTR) == XMTR) { // i s the t r a n s m i t t e r he re ?
109 x mtr cf g cmd [ xmtrIndex ] = ( i << 4) + j ; // i i s t h e
f b b add r e s s of t h e d e vi c e
110 xmtr type [ xmtrIndex ] = BTT ERT ;
111 xmtrIndex++;
112 e rtCount++;
113 }
114 // t h a t wasn ’ t i t , t r y t h e ne x t b i t
115 temp = temp >> 1 ;
116 }
117 } e l s e {
118 xmtr cfg cmd [ xmtrIndex ] = ( i << 4 ) + 0 ; // i i s t h e f b b
addre s s o f the d ev i c e
119 xmt r t yp e [ xmtrIndex ] = BTT SRT ;
120 xmtrIndex++;
121 srtC ou nt ++;
122 } // end i f ( ( s y s c o n f i g . b y F loc k S t a t u s [ i ] & BFS ERC) . . .
123 } // end i f ( s y s c o n f i g . b y F l o ckS t a t u s [ i ] & ANY XMTR)
124 } // end i f ( s y s c o n f i g . b y F l o ckS t a t u s [ i ] & BFS FBBACCESSIBLE) . . .
125 } // end f o r ( i = 1 ; . . .
126
127 i f ( srtCount && e rtCount ) {
128 s p r i n t f ( mError , ”More than one t ype o f t r a n s m i t t e r c onn ect ed a t th e same
time . \ n ”
97
129 ”Power down t he system and make sure onl y one type (SRT
or ERT) \n ”
130 ” o f t he t r a n s m i t t e r i s con nec ted . \ n\n ” ) ;
131 return 0 ;
132
133 } // end i f ( x mtrIn dex > 1)
134 i f ( xm tr type [ 0 ] == BTT SRT) {
135 bird cmd [ 0 ] = 0 x50 ; // change v a lue
136 bird cmd [ 1 ] = 0 x12 ; // t r a n s m i t t e r mode
137 bird cmd [ 2 ] = 0 x02 ; // ”co o l down ” mode
138
139 s t a t u s = birdRS232SendCommand (GROUP ID,
140 1 , // b i r d command i s meant f o r
141 bird cmd ,
142 3) ; // number o f b y t e s i n command
143 } // end i f ( x mtr t y p e [ 0 ] == BTT SRT)
144
145 // s p e c i f y t h e b i r d wit h the t r a n s m i t t e r
146 bi rd cmd [ 0 ] = 0 x30 ; // n e xt t r a n s m i t t e r
147 bi rd cmd [ 1 ] = x mtr cf g cmd [ 0 ] ;
148
149 s t a t u s = birdRS232SendCommand (GROUP ID,
150 1 , // b i r d command i s meant f o r
151 bird cmd ,
152 2) ; // number o f b y t e s i n command
153
154 // Informa a quan tid ad e , t i p o e t a xa de a t u a l i z a c a o dos s ensore s . . . .
155 return r c v r I n dex ;
156 }
157
158 JNIEXPORT j i n t JNICALL
159 Java NestOfBird s et Da ta Fo rm at ( JNIEnv ∗ env , j o b j e c t obj , j i n t dataFormat ) {
160 // S e t t h e s e n s o r s t o t h e d e s i r e P&O outp u t form at
161 j i n t e r r o = 0 ;
162 char tmpError [ 2 0 0 ] ;
163 mError [ 0 ] = ’ \0 ’ ;
164 f or ( i =1; i<=n umb e rof d evi c es ; i ++) {
165 // no need t o s e t i t i f i t ’ s a l r e a d y t h e r e
166 i f ( de vc o n f i g [ i − 1 ]. byDataFormat != ( char ) dataFormat ) {
167 d e v co n f i g [ i − 1]. byDataFormat = ( char ) dataFormat ;
168
169 s t a t u s = birdS e t D e v i c e C o n f i g (GROUP ID, i , &d ev c o n f i g [ i −1]) ;
170 i f ( ! s t a t u s ) {
171 s p r i n t f ( tmpError , ”Couldn ’ t s e t d ev i c e %1u c o n f i g u r a t i o n . \ n ” , i ) ;
98
172 s t r c a t ( mError , tmpError ) ;
173 e r r o++;
174 } // end i f ( ! s t a t u s )
175 } // end i f ( d e v c o n f i g [ i − 1]. byDataFormat != . . .
176 } // end f o r ( i =1; i<=n umb e r ofd e vic e s ; i++)
177 return e r r o ;
178 }
179
180 // d e f i n i c a o da funcao que d e s l i g a o Nest Of Bird s
181 JNIEXPORT j i n t JNICALL
182 Java NestOfBird shutDown ( JNIEnv ∗ env , j o b j e c t ob j ) {
183 bi rd cmd [ 0 ] = 0 x47 ; // s l e e p ( t h e shut down command doesn ’ t do t h i s )
184
185 s t a t u s = birdRS232SendCommand (GROUP ID,
186 1 , // b i r d command i s meant f o r
187 bird cmd ,
188 1) ; // number o f b y t e s i n command
189 birdShutDown (GROUP ID) ;
190
191 s p r i n t f ( mError , ”Nest o f B irds d e s l i g a d o . . . ”) ;
192 return 0 ;
193 }
194
195 // d e f i n i c a o da funcao que rec upe r a mensagens de e r ro
196 JNIEXPORT j s t r i n g JNICALL
197 Jav a N est O fBi r d g etEr rorM essa ge ( JNIEnv ∗ env , j o b j e c t obj ) {
198 return (∗ env )−>NewStringUTF ( env , mError ) ;
199 }
200
201 // d e f i n i c a o da funcao que i n i c i a a c o l e t a dos dados dos s e n s o r e s
202 JNIEXPORT void JNICALL
203 Ja va Nes tO fBi rd b ird Sta rtFra meS tre am ( JNIEnv ∗ env , j o b j e c t o bj ) {
204 b ir dS ta rt Fr ameStream (GROUP ID) ;
205 }
206
207 // d e f i n i c a o da funcao que term ina a c o l e t a de dados dos s e nsore s
208 JNIEXPORT void JNICALL
209 J av a N estOfBird birdSt op Fr ameStream ( JNIEnv ∗ env , j o b j e c t obj ) {
210 birdStopFrameStream (GROUP ID) ;
211 }
212
213 // d e f i n i c a o da funcao que r e t orna uma m atr i z c onten do as coordenadas em metros
214 JNIEXPORT j f l o a t A r r a y JNICALL
215 J a v a N e s t O f B i r d g e t P o s i t i o n ( JNIEnv ∗ env , j o b j e c t obj ) {
99
216 j f l o a t A r r a y f a r r = ( ∗ env )−>NewFloatArray ( env , 3 ) ; // a l t o c u s to em termos de
tempo
217 i f ( f a r r == NULL)
218 return NULL;
219 birdGetMostRecentFrame ( GROUP ID, &frame ) ; // a l t o c u s t o em termos de
tempo ,
220 // c o n s u l t e o manual do Nest
Of Bir ds
221 b ir d da t a = &frame . r e a d i n g [ 1 ] ;
222 pos [ 0 ] = ( f l o a t ) ( ( ( bird da t a −>p o s i t i o n . nX / 227 . 548 6 111 ) −27.9 ) / −39.37) ;
223 pos [ 1 ] = ( f l o a t ) ( ( ( bird da t a −>p o s i t i o n . nY / 227 . 548 6 111 ) −26.9 ) / −39.37) ;
224 pos [ 2 ] = ( f l o a t ) ( ( ( bird da t a −>p o s i t i o n . nZ / 2 2 7.5 4 861 1 1 ) +6.3) / −39.37) ;
225
226 ( ∗ env )−>S et F lo a tA rra yRe gio n ( env , f a r r , 0 , 3 , pos ) ;
227 // (∗ env )−>D e l e teLo c a l R ef ( env , f a r r ) ;
228 return f a r r ;
229 }
C´odigo A.4: C´odigo em C completo para controle do NestOfBirds
A.4 Comandos para compilar e executar
A.4.1 Um passo a passo para compilar
Para o desenvolvimento deste trabalho utilizamos o Sistema Operacional
Windows XP SP2, compilador C/C++ do pacote Microsoft Visual Studio .NET
2003 Enterprise Architect e Java SDK vers˜ao 1.6.0 04, X3D-Edit e InstantPlayer
vers˜ao Instant Player-Win32 NT-5.1-i686-2.0.0beta4-b10249.2522.
Copie o arquivo localizado no CDROM, pasta drivers, Bird.dll para a pasta
C:/Windows/system, o arquivo Bird.h e Bird.lib para as pastas C:/Arquivos de
Programas/Microsoft Visual Studio .NET 2003/Vc7/include e C:/Arquivos de Pro-
gramas/Microsoft Visual Studio .NET 2003/Vc7/lib respectivamente.
Compile primeiro o arquivo NestOfBird.java, com o comando:
javac NestOfBirds.java
a seguir ´e preciso criar um arquivo de cabe¸calho no estilo JNI, para isso execute o
seguinte comando,
javah -jni NestOfBird
para maiores informa¸c˜oes consulte o livro xxxx, c´apitulo 2. de posse do arquivo
100
NestOfBird.c na mesma pasta o digite o comando para compilar,
cl -I”C:/Arquivos de programas/Java/jdk1.6.0 04/include” -I”C:/Arquivos
de programas/Java/jdk1.6.0 04/include/win32” /c NestOfBird.c
e para linkar
link NestOfBird.obj /OUT:NestOfBird.dll /DLL /RELEASE /NODE-
FAULTLIB:msvcrt.lib Bird.lib
Todos os comandos acima devem ser executados no prompt de comandos do
Visual Studio .NET 2003.
A.4.2 Como executar
Instale o InstatPlayer em todas as m´aquinas, durante a instala¸c˜ao permita
o carregamento autom´atico do InstantCluster, verifique no Listing A.1, linha 8
os nomes dos servidores e o nomes das maquinas s˜ao correspondentes, se existir
modifique-os adequadamente.
Dˆe dois clicks sobre o arquivo X3D respons´avel pelo controle do CAVE e ex-
ecute o programa ControlX3DTracking.class caso n˜ao funcione adicione o caminho
C:/Aquivos de programas/Instant Player/bin a variavel de sistema CLASSPATH.
Para usar o sistema sem o tracker basta executar o arquivo X3D de controle.
101
Apˆendice B
Exemplo de uma aplica¸c˜ao
B.1 Descri¸c˜ao parcial da estrutura 3D de uma larva em VRML
O arquivo abaixo foi editado para adi¸c˜ao de recursos para controlar a transparˆen-
cia de seus componentes, adicionar recursos para navega¸c˜ao e um painel com in-
forma¸c˜oes sobre as estruturas anatˆomicas inscritas em uma imagem.
1 #VRML V2 . 0 u t f 8
2 PROFILE F u l l
3 # Produced by 3D S tud i o MAX VRML97 e x p orte r , V ers i on 8 , R e v i s i o n 0 ,92
4 # MAX F i l e : l e p t o b r a c h e l l a . max , Date : Wed Jun 25 1 6 : 0 5 : 5 5 2008
5 # Editado manualmente por : Paulo Trenhago
6
7 #I n i c i o da e d i c ao da p r i meir a p a r t e
8 DEF i o s IOSensor {
9 type ” j o y S t i c k ”
10 eve ntOut S FFloat ∗ x∗ a x i s
11 eve ntOut S FFloat ∗ y∗ a x i s
12 eve ntOut S FFloat ∗ z ∗ a x i s
13 eve ntOut S FFloat ∗ z ∗ r o t ∗
14 eve ntOut S FFloat ∗ Hat∗ x∗ a x i s
15 eve ntOut S FFloat ∗ Hat∗ y∗ a x i s
16 eve ntOut SFBool ∗ but ton ∗ 1
17 eve ntOut SFBool ∗ but ton ∗ 2
18 eve ntOut SFBool ∗ but ton ∗ 3
19 eve ntOut SFBool ∗ but ton ∗ 4
20 eve ntOut SFBool ∗ but ton ∗ 5
21 eve ntOut SFBool ∗ but ton ∗ 6
22 eve ntOut SFBool ∗ but ton ∗ 7
23 eve ntOut SFBool ∗ but ton ∗ 8
24 }
102
25
26 NavigationInfo {
27 type [ ”examine ” , ”any ” ]
28 navigator [
29 DEF nav SteerNavigator {
30 inputRange [ 0 1 ]
31 z e r oD e f l e c t i o n T r a n s 0 . 5 0 . 5 0 . 5
32 z e r oD e f l e c t i o n R o t 0 . 5 0 . 5 0 . 5
33 rot a t i o n S p e e d −0.2 −0.2 −0.2
34 t r a n s l a t i o n S p e e d 10 . 0 10. 0 10. 0
35 }
36 ]
37 }
38
39 ROUTE i o s . ∗ y∗ a x i s TO nav . s et x Ro t a t i on
40 ROUTE i o s . ∗ x∗ a x i s TO nav . s et y Ro t a t i on
41 ROUTE i o s . ∗ z ∗ a x i s TO nav . s e t x T r a n s l a t i o n
42 ROUTE i o s . ∗ z ∗ r o t ∗ TO nav . s e t z T r a n s l a t i o n
43 ROUTE i o s . ∗ Hat∗ y∗ a x i s TO nav . s e t y T r a n s l a t i o n
44
45 ROUTE i o s . ∗ bu tton ∗ 7 TO nav . upd ate Ro tat ion Cen te r
46
47 Foregro und {
48 overlays [
49 DEF textO v e r l a y ScreenTe xtO ver lay {
50 t e x t [ ”Chondrocranium [ 0% ] ” , ”Hyobranchium [ 0% ] ” , ”Notochord [ 0% ] ” , ”
Mu sc ul at ure [ 0% ] ” ]
51 bgColor 1 , 0 , 0 , 0 .4
52 }
53 ]
54 }
55
56 DEF c o n t r o l e Script {
57 eventIn SFBool butto n1
58 eventIn SFBool butto n2
59 eventIn SFBool butto n3
60 eventIn SFBool butto n4
61 eventIn SFBool butto n5
62 eventIn SFBool butto n6
63 eventIn SFBool butto n8
64 eve ntOut SFVec3f hudd
65 eve ntOut S FFloat mChond
66 eve ntOut S FFloat mHyob
67 eve ntOut S FFloat mNoto
103
68 eve ntOut S FFloat mMusc
69 f i e l d MFFloat e s c a l a [ 0 . 0 , 0 . 1 , 0 . 0 , 0 . 2 , 0 . 0 , 0 . 3 , 0 . 0 , 0 . 4 , 0 . 0 , 0 . 5 , 0 . 0 ,
0 . 6 , 0 . 0 , 0 . 7 , 0 . 0 , 0 . 8 , 0 . 0 , 0 . 9 , 0 . 0 , 1 . 0 ]
70 f i e l d SFNode text O v e r l ay USE t e x t O v erla y
71 url [ ” j a v a s c r i p t :
72 va r i n d i c e = 0 , c ont ado r1 = 0 , c on t ad o r2 = 0 , c ont ado r3 = 0 , c on t ad o r4 = 0 ;
73 f u n c t i o n butt on1 ( v a lor , t s ) {
74 i f ( v a l o r )
75 i n d i c e = 1 ;
76 }
77
78 f u n c t i o n butt on2 ( v a lor , t s ) {
79 i f ( v a l o r )
80 i n d i c e = 2 ;
81 }
82
83 f u n c t i o n butt on3 ( v a lor , t s ) {
84 i f ( v a l o r )
85 i n d i c e = 3 ;
86 }
87
88 f u n c t i o n butt on4 ( v a lor , t s ) {
89 i f ( v a l o r )
90 i n d i c e = 4 ;
91 }
92
93 f u n c t i o n butt on5 ( v a l o r , t s ) {
94 i f ( v a l o r )
95 hudd = new SFVec3f ( 0 . 0 , 0 . 0 , −1) ;
96 e l s e
97 hudd = new SFVec3f ( 0 . 0 , 0 . 0 , 2 . 0 ) ;
98 }
99
100 f u n c t i o n butt on6 ( v a lor , t s ) {
101 i f ( v a l o r ) {
102 i f ( i n d i c e == 1 ) {
103 mChond = e s c a l a [ −−c ont ado r1 ] ;
104 t e xtOve r l a y . t e xt [ 0 ] = ( ’ Chondrocranium [ ’ + ( mChond . t oFi xed (2) ∗ 10 0) +
’% ] ’ ) ;
105 }
106 i f ( i n d i c e == 2 ) {
107 mHyob = e s c a l a [ −−co nta dor 2 ] ;
108 t e x t O verla y . t e x t [ 1 ] = ( ’ Hyobranchium [ ’ +( mHyob . to F ix e d ( 2) ∗ 100 ) + ’%
] ’ ) ;
104
109 }
110 i f ( i n d i c e == 3 ) {
111 mNoto = e s c a l a [ −−c ont ado r3 ] ;
112 t e x t O verla y . t e x t [ 2 ] = ( ’ Notochord [ ’ +( mNoto . to Fix ed ( 2 ) ∗ 100 ) + ’% ] ’
) ;
113 }
114 i f ( i n d i c e == 4 ) {
115 mMusc = e s c a l a [ −−c ont ado r4 ] ;
116 t e x t O verla y . t e x t [ 3 ] = ( ’ Musculat ur e [ ’ +( mMusc. toFi xed (2 ) ∗ 100 ) + ’%
] ’ ) ;
117 }
118 }
119 }
120
121 f u n c t i o n butt on8 ( v a lor , t s ) {
122 i f ( v a l o r ) {
123 i f ( i n d i c e == 1 ) {
124 mChond = e s c a l a [ ++co nta dor 1 ] ;
125 t e xtOve r l a y . t e xt [ 0 ] = ( ’ Chondrocranium [ ’ +( mChond . toF ixe d ( 2 ) ∗ 100 ) +
’% ] ’ ) ;
126 }
127 i f ( i n d i c e == 2 ) {
128 mHyob = e s c a l a [ ++con tad or2 ] ;
129 t e xtOve r l a y . t e xt [ 1 ] = ( ’ Hyobranchium [ ’ +( mHyob . to F ix e d ( 2) ∗ 100 ) + ’%
] ’ ) ;
130 }
131 i f ( i n d i c e == 3 ) {
132 mNoto = e s c a l a [ ++co nta dor 3 ] ;
133 t e x t O verla y . t e x t [ 2 ] = ( ’ Notochord [ ’ +( mNoto . to Fix ed ( 2 ) ∗ 100 ) + ’% ] ’
) ;
134 }
135 i f ( i n d i c e == 4 ) {
136 mMusc = e s c a l a [ ++c ont ado r4 ] ;
137 t e xtOve r l a y . t e xt [ 3 ] = ( ’ Musculature [ ’ +( mMusc . to Fix ed ( 2 ) ∗ 100 ) + ’%
] ’ ) ;
138 }
139 }
140 }
141 ”
142 ]
143 }
144
145 ROUTE i o s . ∗ bu tton ∗ 1 TO c o n t r o l e . butto n1
146 ROUTE i o s . ∗ bu tton ∗ 2 TO c o n t r o l e . butto n2
105
147 ROUTE i o s . ∗ bu tton ∗ 3 TO c o n t r o l e . butto n3
148 ROUTE i o s . ∗ bu tton ∗ 4 TO c o n t r o l e . butto n4
149 ROUTE i o s . ∗ bu tton ∗ 5 TO c o n t r o l e . butto n5
150 ROUTE i o s . ∗ bu tton ∗ 6 TO c o n t r o l e . butto n6
151 ROUTE i o s . ∗ bu tton ∗ 8 TO c o n t r o l e . butto n8
152
153 PROTO HUD [
154 exposedField SFVec3f scr eenOf fs et 0 0 0
155 exposedField MFNode hudGeometry [ ]
156 # i n i t i a l i z a t i o n nodes ( i f any ) go h e r e
157
158 eve ntOut SFVec3f p os i t i o n c h a n g e d
159 eve ntOut SFRot ation o r i e n t a t i o n c h a n g e d
160 ] {
161 Group {
162 children [
163 DEF HudContainer Transform {
164 children [
165 Transform {
166 t ra ns la tio n IS scre enOff se t
167 chil dre n [
168 Group {
169 children IS hudGeometry
170 }
171
172 ]
173 }
174 ]
175 }
176 DEF HereIAm ProximitySensor {
177 s i ze 1000 1000 1000
178 p o si t i o n c h a ng e d IS p o s i t i o n ch a n g e d
179 o r i e n t a t i o n c h a n g e d IS o r i e n t a t i o n ch a n g e d
180 }
181 ]
182 ROUTE HereIAm . o r i e n t a t i o n c h a n g e d TO HudContainer . r o t a t i o n
183 ROUTE HereIAm . p o s i t i o n c h a n g e d TO HudContainer . tr an slati on
184 }
185 }
186
187
188
189 # P roto D e cla r e i s th e ” c o o k i e c u t t e r ” te mp late , P r o t o I n s t a nce c r e a t e s an a c t u a l
o c c u r r e n ce
106
190 DEF Hud HUD {
191 scre en Offse t 0 0 2
192 hudGeometry Shape {
193 geometry Box {
194 si z e 0.743 0 . 4 3 3 . 1
195 }
196 appea ra nc e Appearance {
197 t e x t u r e ImageTexture {
198 url [ ” f i g 4 a . png ” ]
199 }
200 }
201 }
202 }
203
204 ROUTE c o n t r o l e . hudd TO Hud. s creen Of fset
205 #t er mino da e d i c a o da p r i m e ira p a r t e
206
207 DEF objChondrocranium Transform {
208 tr ans la ti on 0 0 0
209 child ren [
210 Shape {
211 appea ra nc e Appearance {
212 m a t e r i a l DEF mChondrocranium M a t e r i a l {
213 d i f f u s e C o l o r 1 1 1
214 a m b i e ntI n t e n s i t y 1 . 0
215 s p e c u l a r C o l or 0 0 0
216 s h i n i n e s s 9 5 . 0 5
217 t r anspare n c y 0
218 }
219 }
220 geometry DEF objChondrocranium−FACES IndexedFaceSet {
221 ccw TRUE
222 s o l i d TRUE
223 colorPerVertex FALSE
224 c o l o r C ol or { c o l o r [
225 1 1 1 , 0 . 2 706 0 . 4039 0 .9804 ] }
226 coo rd DEF objChondrocranium−COORD Coo rdi nat e { p o i n t [
227 0 . 1 47 −0.04149 1 . 2 9 8 , 0.1 3 3 1 −0.01971 1 . 2 78 , 0 . 1029 −0.01601 1 . 2 9 5 ,
228 . . .
229 0.151 6 0.08 0 7 1 −0.382 , 0 .1491 0 .0824 −0.3714 , 0 . 1 5 4 1 0 . 0 8134 −0 .3 928]
230 }
231 normal Normal { v ec t o r [
232 0.352 8 0 .0223 0 . 9 3 54 , −0.8536 0 .4086 −0.3229 , 0 .3046 0 .9428 0 . 1 348 ,
233 . . .
107
234 0.866 4 0 . 3 8 −0.3237 , 0 .123 5 0 .2662 0 . 9 5 59 , 0.144 0 . 4 035 −0.9035 ,
235 −0.789 −0.6005 −0.1294 , ] }
236 normalPerVertex TRUE
237 c oor dIn dex [
238 1 , 0 , 2 , −1, 2 , 0 , 3 , −1, 5 , 4 , 6 , −1, 6 , 4 , 7 , −1, 9 , 8 , 1 0 , −1,
239 . . .
240 2 6099 , 2 54 11 , 2 64 00 , −1, 25 411 , 26 397 , 26 398 , −1, 2541 1 , 2 63 98 , 264 00 ,
−1,
241 2 5410 , 2 63 97 , 2 54 11 , −1]
242 c o l o r I n d e x [
243 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 ,
244 . . .
245 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 ,
246 1 , 1 , 1 , 1 , 1 , 1 ]
247 normalIn dex [
248 4 718 , 16 651 , 20 166 , −1, 2016 6 , 1 66 51 , 104 83 , −1, 11 42 7 ,
249 . . .
250 −1, 6 80 9 , 12 488 , 23 893 , −1, 9328 , 21302 , 680 9 , −1,
251 ]
252 }
253 }
254 ]
255 }
256 DEF objHyobranchium Transfor m {
257 tr ans la ti on 0 0 0
258 child ren [
259 Shape {
260 appea ra nc e Appearance {
261 m a t e r i a l DEF mHyobranchium Material {
262 d i f f u s e C o l o r 1 1 1
263 a m b i e ntI n t e n s i t y 1 . 0
264 s p e c u l a r C o l or 0 0 0
265 s h i n i n e s s 9 5 . 0 5
266 t r anspare n c y 0
267 }
268 }
269 geometry DEF objHyobranchium−FACES IndexedFaceSet {
270 ccw TRUE
271 s o l i d TRUE
272 colorPerVertex FALSE
273 c o l o r C ol or { c o l o r [
274 1 1 1 , 0 .070 5 9 0.8 3 1 4 0. 0 3 1 37 ] }
275 coo rd DEF objHyobranchium−COORD Coo rd i na te { p o i n t [
276 −0.3444 0 . 2 091 0 . 8 97 9 , −0.3392 0 . 2 057 0 . 9 , −0.3472 0 . 2 055 0 . 9 08 4 ,
108
277 . . .
278 0.018 4 0 .9358 0 . 3 5 18 , 0.3 7 4 9 0.91 5 6 0 . 1 4 4 6 , 0.1 8 3 8 −0.7021 −0.6878 ,
279 ] }
280 normalPerVertex TRUE
281 c oor dIn dex [
282 0 , 1 , 2 , −1, 0 , 2 , 3 , −1, 4 , 5 , 2 , −1, 4 , 2 , 1 , −1, 6 , 7 , 2 , −1,
283 . . .
284 2 721 , 27 00 , 2 71 4 , −1, 2 700 , 62 , 6 1 , −1, 2 700 , 61 , 2 714 , −1]
285 c o l o r I n d e x [
286 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 ,
287 . . .
288 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 ]
289 normalIn dex [
290 4 162 , 10 227 , 6219 , −1, 41 62 , 621 9 , 5 315 , −1, 4131 , 1751 ,
291 . . .
292 5 860 , 75 86 , 9 80 3 , −1, 7 586 , 663 , 9345 , −1, 758 6 , 9 345 ,
293 9 803 , −1, ]
294 }
295 }
296 ]
297 }
298 DEF ob jNotochor d Transform {
299 tr ans la ti on 0 0 0
300 child ren [
301 Shape {
302 appea ra nc e Appearance {
303 m a t e r i a l DEF mNotochord M a t e r i a l {
304 d i f f u s e C o l o r 0 .9647 1 0
305 a m b i e ntI n t e n s i t y 1 . 0
306 s p e c u l a r C o l or 0 0 0
307 s h i n i n e s s 0 . 0 5
308 t r anspare n c y 0
309 }
310 }
311 geometry DEF objNot ochord−FACES IndexedFaceSet {
312 ccw TRUE
313 s o l i d TRUE
314 coo rd DEF objNotochord−COORD C oor din ate { poi n t [
315 −0.0388 0 . 0649 4 1 . 6 3 8 , −0.04333 0.05 5 4 7 1 . 6 3 9 , −0.02677 0.03 3 0 7 1 . 6 4 1 ,
316 . . .
317 −0.07331 0 . 0 1 427 1 . 4 0 4 , −0.06072 0 . 0779 2 1 . 6 3 8 ]
318 }
319 normal Normal { v ec t o r [
320 −0.8191 0 . 1 094 −0.5629 , 0 .9636 −0.1063 −0.2452 , −0.6196 0 . 4 0 9 2 0. 6 6 9 7 ,
109
321 . . .
322 0.993 7 0 .0438 −0.1023 , ] }
323 normalPerVertex TRUE
324 c oor dIn dex [
325 0 , 1 , 2 , −1, 0 , 2 , 3 , −1, 1 , 4 , 5 , −1, 1 , 5 , 2 , −1, 4 , 6 , 7 , −1,
326 . . .
327 2 6 , 24 , 9 1 , −1, 2 8 , 26 , 9 1 , −1, 0 , 2 8 , 91 , −1]
328 normalIn dex [
329 3 8 , 19 , 6 3 , −1, 3 8 , 63 , 3 3 , −1, 1 9 , 19 , 5 9 , −1, 1 9 , 59 ,
330 . . .
331 −1, 1 9 , 19 , 1 9 , −1, 3 8 , 19 , 1 9 , −1, ]
332 }
333 }
334 ]
335 }
336 DEF o bjM usc ula tur e Transform {
337 tr ans la ti on 0 0 0
338 child ren [
339 Shape {
340 appea ra nc e Appearance {
341 m a t e r i a l DEF mMusculature M a t e r i a l {
342 d i f f u s e C o l o r 1 1 1
343 a m b i e ntI n t e n s i t y 1 . 0
344 s p e c u l a r C o l or 0 0 0
345 s h i n i n e s s 9 5 . 0 5
346 t r anspare n c y 0
347 }
348 }
349 geometry DEF obj Mu sc ulature −FACES IndexedFaceSet {
350 ccw TRUE
351 s o l i d TRUE
352 colorPerVertex FALSE
353 c o l o r C ol or { c o l o r [
354 1 1 1 , 0 . 9 882 0 . 7 0 2 0 . 5 8 8 2 ] }
355 coo rd DEF obj Mu sculatu re −COORD C oo rdi nat e { p o i n t [
356 −0.141 0 . 1 7 5 6 0 . 6 1 , −0.1544 0 . 1 7 1 2 0 .6 3 1 5 , −0.1637 0 . 1 7 16 0 . 63 2 8 ,
357 . . .
358 −0.218 0 . 1 1 8 9 0 .96 8 6 , −0.7882 0 . 0 682 −0.6116 , −0.8352 0 . 5402 −0.1027 ,
359 ] }
360 normalPerVertex TRUE
361 c oor dIn dex [
362 0 , 1 , 2 , −1, 0 , 2 , 3 , −1, 4 , 5 , 6 , −1, 4 , 6 , 7 , −1, 8 , 9 , 1 0 , −1,
363 . . .
110
364 2 1678 , 2 17 04 , 2 16 79 , −1, 21 662 , 21 661 , 21 716 , −1, 2166 2 , 2 17 16 , 216 65 ,
−1,
365 2 1660 , 2 16 59 , 2 16 68 , −1, 21 660 , 21 668 , 21 687 , −1]
366 c o l o r I n d e x [
367 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 ,
368 . . .
369 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 ]
370 normalIn dex [
371 1 4218 , 4 22 1 , 87 12 , −1, 14 218 , 8712 , 185 84 , −1, 69 71 ,
372 . . .
373 1 1026 , −1, 4 26 4 , 1 102 6 , 5 81 3 , −1, 1 4508 , 194 30 , 178 84 ,
374 −1, 1 45 08 , 1 78 84 , 2 19 5 , −1, ]
375 }
376 }
377 ]
378 }
379
380 #i n i c i o da e d i c a o da segunda p a r t e
381 ROUTE c o n t r o l e . mChond TO mChondrocranium . t r a n s p a r e ncy
382 ROUTE c o n t r o l e . mHyob TO mHyobranchium . t r a n s p arency
383 ROUTE c o n t r o l e . mNoto TO mNotochord . t r a n s p a rency
384 ROUTE c o n t r o l e . mMusc TO mMusculature . t r a n s p a r e n cy
385 #t er mino da e d i c a o da segunda parte
C´odigo B.1: Um cen´ario VRML descrito pela geometria 3D do crˆanio de uma larva.
B.2 C´odigo fonte das outras aplica¸c˜oes
Consulte o CDROM pasta aplica¸c˜oes ela contem o c´odigo das aplica¸c˜oes:
larva, arteriasEveias, proteinasEvirus e gel2d.
111
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
