ads:
Universidade Federal do Maranh˜ao
Centro de Ciˆencias Exatas e Tecnologia
Curso de P´os-Gradua¸c˜ao em Engenharia de Eletricidade
RONALD SILVA SERR
˜
AO
ALGORITMO DE OTIMIZAC¸
˜
AO
PARA VISUALIZAC¸
˜
AO DE
MODELOS URBANOS COM BANCO
DE DADOS GEOGR
´
AFICOS
S˜ao Lu´ıs
2008
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
RONALD SILVA SERR
˜
AO
ALGORITMO DE OTIMIZAC¸
˜
AO
PARA VISUALIZAC¸
˜
AO DE
MODELOS URBANOS COM BANCO
DE DADOS GEOGR
´
AFICOS
Disserta¸c˜ao apresentada ao Curso de
P´os-Gradua¸c˜ao em Engenharia de Eletricidade da
Universidade Federal do Maranh˜ao como parte
dos requisitos necess´arios para obten¸c˜ao do
grau de Mestre em Engenharia El´etrica.
Orientador: Anselmo Cardoso de Paiva
Co-orientador: Arist´ofanes Corrˆea Silva
S˜ao Lu´ıs
2008
ads:
Silva Serr˜ao, Ronald
Algoritmo de Otimiza¸c˜ao para Visualiza¸c˜ao de Modelos Urbanos
com Banco de Dados Geogr´aficas / Ronald Silva Serr˜ao. - S˜ao Lu´ıs,
2008.
96f.:il.
Impresso por computador (Fotoc´opia).
Orientador: Anselmo Cardoso de Paiva.
Disserta¸c˜ao (Mestrado) - Universidade Federal do Maranh˜ao,
Programa de P´os-Gradua¸c˜ao em Engenharia de Eletricidade, Centro
de Ciˆencias Exatas e Tecnologia, 2008.
1. Realidade Virtual 2. Modelo Virtual Urbano 3. Banco de Dados
Geogr´aficos 4. Sistema de Informa¸c˜ao Geogr´afica. I. T´ıtulo.
CDU 007.51
”A verdade n˜ao ´e, de modo algum, aquilo que se demonstra,.
mas aquilo que se simplifica.”
Antoine de Saint-Exup´ery
`
A minha fam´ılia e amigos, pelo apoio e companheirismo.
Agradecimentos
Em primeiro lugar, a Deus.
Aos meus pais e meus irm˜ao, por toda a dedica¸c˜ao, confian¸ca e amor.
Ao meu amor
´
Adilla pelo carinho, compreens˜ao, incentivo e apoio.
Ao meu orientador, Prof
o
. Dr. Anselmo Cardoso de Paiva, e ao meu co-
orientador, Prof
o
. Dr. Arist´ofanes Corrˆea Silva, pela compreens˜ao, colabora¸c˜ao e
orienta¸c˜ao segura.
Aos amigos pela for¸ca que sempre me emprestam quando eu necessito.
A todos que contribu´ıram de maneiras diversas para a realiza¸c˜ao deste
trabalho.
Resumo
Sistemas de Realidade Virtual tˆem sido utilizados em diversas ´areas nos ´ultimos
anos, apresentando v´arios benef´ıcios. Uma classe desses sistemas ´e a de
manipula¸c˜ao e visualiza¸c˜ao de modelos virtuais urbanos, que podem ser usados
para planejamento urbano, planejamento arquitetˆonico, visualiza¸c˜ao e jogos.
Apresenta-se a concep¸c˜ao e o desenvolvimento de um algoritmo otimizado de
visualiza¸c˜ao de modelos virtuais urbanos com cache baseado em Banco de Dados
Geogr´aficos. A estrat´egia de cache proposta possibilita um bom desempenho no
caminhar (walktrough) em modelos virtuais urbanos. Para testar o algoritmo
proposto foi construido um modelo virtual urbano baseado no centro hist´orico da
cidade de S˜ao Lu´ıs.
Palavras-Chave: Realidade Virtual. Modelo Virtual Urbano. Banco de Dados
Geogr´aficos. Sistema de Informa¸c˜ao Geogr´afica.
Abstract
Virtual Reality Systems have been used in diverse areas in recent years, providing
many benefits. A class of these systems is for visualization and manipulation
of virtual urban models, that can be used for urban planning, architectural,
visualization and games. This work presents the conception and development
of an optimized algorithm for urban virtual models visualization with cache,
based in Geographical Database. The proposed cache strategy provides a good
performance for urban virtual models walktrough. To test the proposed algorithm
it was built an urban virtual model based on S˜ao Lu´ıs historical town.
Keywords: Virtual Reality. Urban Virtual Model. Geographical Database.
Geographic Information System.
Artigo Cient´ıfico Publicado pelo Autor
Relacionado `a Disserta¸c˜ao
SERR
˜
AO, R. S. ; PAIVA, A. C. ; SILVA, A. C. . Architecture Based on Virtual
Reality Techniques and Geographic Database for Storage and Visualization
of Urban Virtual Models. In: 26th Urban Data Management Symposium
(UDMS 2007), 2007, Stuttgart, Germany. Proceedings of the 26th Urban Data
Management Symposium - UDMS 2007, 2007.
1
Lista de Figuras
2.1 Pipeline gr´afico. Fonte: (Tortelli and Walter 2007) . . . . . . . . . 12
2.2 Esquema do descarte de faces de tr´as. . . . . . . . . . . . . . . . . 14
2.3 Volume de vis˜ao. Fonte: (Valente 2004) . . . . . . . . . . . . . . . 15
2.4 Esquema do descarte por volume de visualiza¸c˜ao. Fonte: (Valente
2004) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Esquema do descarte por oclus˜ao . . . . . . . . . . . . . . . . . . 16
17figure.2.6
2.7 Estrutura de um grafo de cena. Fonte: (Reiners 2002) . . . . . . . 19
2.8 Exemplo de estruturas de arquivos. (a) modelo matricial. (b)
modelo vetorial. Fonte: (USDI 2007) . . . . . . . . . . . . . . . . 20
2.9 Estrutura do tipo de dados espacial proposta pelo OGC. Fonte:
(OGC 2007) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.10 Tipos de dados espaciais do Oracle Spatial. Fonte: (Oracle 2005) 31
2.11 (Rela¸c˜oes Topol´ogicas implementadas no Oracle Spatial. Fonte:
(Oracle 2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.12
´
Indice hier´arquico R-tree. Fonte: (Oracle 2005) . . . . . . . . . . 36
37figure.2.13
3.1 Compara¸c˜ao de casa com ou sem textura. Fonte: (Wilmott et al.
2001) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 Visualiza¸c˜ao de modelo 3D com t´ecnica ilustrativa. Fonte: (D¨ollner
et al. 2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3 Vista do Trinity College em Dublin. Fonte: (Hamill and O’Sullivan
2003) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4 Exemplo de modelagem 3D dos quarteir˜oes da cidade. Fonte:
(Netto et al. 2005) . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3
3.5 Vista de uma quadra cidade de Heidelberg. Fonte: (Schilling and
Zipf 2003) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1 Poss´ıveis formas de buffers. (a) buffer triangular. (b) buffer
circular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2
´
Areas cobertas pelos buffers . . . . . . . . . . . . . . . . . . . . . 51
4.3
´
Area de tolerˆancia no deslocamento da cˆamera . . . . . . . . . . . 51
4.4 Diagrama de classes da aplica¸c˜ao desenvolvida . . . . . . . . . . . 52
4.5 Vis˜ao geral da arquitetura . . . . . . . . . . . . . . . . . . . . . . 54
4.6 Imagem com as informa¸c˜oes do objeto 3D sendo exibidas . . . . . 56
4.7 Cen´ario de atualiza¸c˜ao do grafo de cena e a visualiza¸c˜ao . . . . . 56
4.8 Grafo de cena do modelo . . . . . . . . . . . . . . . . . . . . . . . 58
4.9 Modelo de dados desenvolvido . . . . . . . . . . . . . . . . . . . . 60
4.10 Ilustra¸c˜ao criada com os m´etodos de desenho a partir das
geometrias no banco de dados . . . . . . . . . . . . . . . . . . . . 61
4.11 Visualiza¸c˜ao do mapa 2D da ´area modela da aplica¸c˜ao . . . . . . 62
4.12 Modelos 3D das constru¸c˜oes visualizadas na aplica¸c˜ao . . . . . . . 63
4.13 Modo de visualiza¸c˜ao em primeira pessoa . . . . . . . . . . . . . . 63
4.14 Vis˜ao panorˆamica da ´area urbana . . . . . . . . . . . . . . . . . . 64
4.15 Vis˜ao do modelo com a taxa de quadros por segundos . . . . . . . 65
4.16 Trajet´oria de navega¸c˜ao utilizada para testes . . . . . . . . . . . . 65
4.17 Gr´afico de compara¸c˜ao de fps . . . . . . . . . . . . . . . . . . . . 66
4.18 Gr´afico de compara¸c˜ao de fps para diferentes raios do buffer . . . 66
4.19 Objetos carregados no cache . . . . . . . . . . . . . . . . . . . . 67
A.1 General view of the architecture . . . . . . . . . . . . . . . . . . . 82
A.2 Data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.3 Areas covered for buffers . . . . . . . . . . . . . . . . . . . . . . . 84
A.4 Graph scene of model . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.5 Imagem com as informa¸c˜oes do objeto 3D sendo exibidas . . . . . 85
A.6 Visualization 2D from the application . . . . . . . . . . . . . . . . 86
A.7 Objects 3D (a) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.8 Objects 3D (b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.9 Loaded objects in cache . . . . . . . . . . . . . . . . . . . . . . . 88
4
Lista de Abreviaturas e Siglas
API Application Programming Interface
AVC Ambientes Virtuais Colaborativos
BLOB Binary Large OBject
CAD Computer-Aided Detection
DEM Digital Elevation Model
DML Data Manipulation Language
FPS Frames Per Second
GID Numeric Geometry Identifier
GLSL OpenGL Shading Language
GPU Graphics Processing Units
HLSL High Level Shading Language
LOD Level of Detail
MBR Minimum Bounding Rectangle
OCCI Oracle C++ Call Interface
OGC Open Geospacial Consortium
OSG OpenSceneGraph
ROAM Real-time Optionally Adapting Meshes
RV Realidade Virtual
SGBD Sistema de Gerenciamento de Banco de Dados
SGBD-OR Sistema de Gerenciamento de Banco de Dados Objeto Relacional
SIG Sistema de Informa¸c˜ao Geogr´afica
SQL Structured Query Language
SRID Spatial Reference System Identifier
TDE Tipo de Dados Espaciais
VRML Virtual Reality Modeling Language
5
Sum´ario
1 Introdu¸c˜ao 8
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Organiza¸c˜ao do Trabalho . . . . . . . . . . . . . . . . . . . . . . . 10
2 Fundamenta¸c˜ao Te´orica 11
2.1 Conceitos B´asicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 Descarte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.2 N´ıvel de Detalhe . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.3 Grafo de Cena . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.4 Sistema de Informa¸c˜ao Geogr´afica . . . . . . . . . . . . . . 19
2.1.5 Banco de Dados Geogr´aficos . . . . . . . . . . . . . . . . . 21
2.2 Tecnologias Envolvidas . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.1 OpenSceneGraph . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.2 Oracle Spatial . . . . . . . . . . . . . . . . . . . . . . . . . 30
3 Trabalhos Relacionados 38
4 Estrat´egia de Otimiza¸c˜ao para Acelera¸c˜ao da Visualiza¸c˜ao de
Modelos Virtuais Urbanos 47
4.1 T´ecnica de Acelera¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2 Arquitetura de Visualiza¸c˜ao Proposta . . . . . . . . . . . . . . . . 53
4.2.1 Camada de Apresenta¸c˜ao . . . . . . . . . . . . . . . . . . . 55
4.2.2 Camada de Aplica¸c˜ao . . . . . . . . . . . . . . . . . . . . . 57
4.2.3 Camada de Dados . . . . . . . . . . . . . . . . . . . . . . 59
4.3 Prot´otipo Desenvolvido - RevVir . . . . . . . . . . . . . . . . . . 61
4.3.1 Aquisi¸c˜ao de Dados . . . . . . . . . . . . . . . . . . . . . . 62
6
Cap
´
ıtulo 1
Introdu¸c˜ao
Uma das ´areas que tem utilizado largamente tecnologia de Realidade Virtual (RV)
´e a modelagem de ambientes urbanos, que possibilita a reconstru¸c˜ao realista de
lugares existentes no mundo, ou inser¸c˜ao de ferramentas para a sua visualiza¸c˜ao
interativa e a simula¸c˜ao de diversas situa¸c˜oes poss´ıveis de acontecer no mundo
real. Al´em disso, a constru¸c˜ao antecipada destes ambientes virtuais, simulando
ambientes urbanos reais a serem constru´ıdos, tamb´em tem sido realizada a fim de
prever e evitar problemas.
Os modelos virtuais urbanos tˆem sido amplamente empregados como interfaces
para sistemas de informa¸c˜ao. A RV possibilita a constru¸c˜ao de modelos bastante
interativos e a associa¸c˜ao de outros componentes como banco de dados, p´aginas
Web e componentes multim´ıdia. Esses modelos favorecem seu uso intuitivo como
reposit´orio de informa¸c˜oes, sendo ´util em ambientes virtuais nas ´areas de turismo,
arte e cultura, planejamento urban´ıstico, sistemas de navega¸c˜ao, testes mecˆanicos
e estruturais, impacto ambiental e visual, meteorologia, entre tantas outras. Por
exemplo, pode-se construir ruas, bairros e, at´e mesmo, cidades e disponibilizar
via Web para o turismo virtual.
Outro aspecto importante que pode ser explorado pela constru¸c˜ao de modelos
virtuais urbanos ´e a ´area de preserva¸c˜ao do patrimˆonio hist´orico. Assim, pode-
se usar esses modelos urbanos como ferramenta para a documenta¸c˜ao cient´ıfica
de ´areas urbanas de interesse hist´orico. Outra alternativa de utiliza¸c˜ao ´e a
reconstru¸c˜ao virtual de monumentos ou regi˜oes n˜ao preservadas ou parcialmente
preservadas. Nesses casos, os modelos s˜ao usados como uma met´afora para uma
8
CAP
´
ITULO 1. INTRODUC¸
˜
AO 9
interessante interface para a navega¸c˜ao atrav´es de um conjunto de informa¸c˜oes
sobre a cultura e monumentos hist´oricos em diversas m´ıdias como fotografias,
v´ıdeos e hipertexto.
Os monumentos arquitetˆonicos s˜ao parte importante do nosso patrimˆonio
cultural. Mas, enquanto que outros elementos desse patrimˆonio podem ser
protegidos por tr´as de um vidro em um museu, monumentos arquitetˆonicos
s˜ao amplamente utilizados e amea¸cados por estar sob grandes influˆencias
como tr´afego, a polui¸c˜ao do ar ou eventos destrutivos que causaram graves
danos, como terremotos, incˆendios ou guerras. Mas, por todos os meios,
quando monumentos est˜ao seriamente danificados, ou completamente destru´ıdos,
a quantidade e qualidade de qualquer documenta¸c˜ao sobrevivente torna-se
extremamente importante (Duran and Toz 2001).
Com as tecnologias de RV ´e poss´ıvel a reconstitui¸c˜ao de ambientes,
personagens e cen´arios hist´oricos, que podem ser criados usando gr´aficos
tridimensionais em tempo real ou apenas fotos e v´ıdeos, e permitem envolvimento
e intera¸c˜ao com um cen´ario real. A demonstra¸c˜ao desses tipos de cen´arios
em circunstˆancias de intera¸c˜ao serve como suporte para o desenvolvimento
educacional, cultural e de car´ater tur´ıstico.
Para atender essas demandas os ambientes virtuais, no caso os modelos virtuais
urbanos, devem propiciar impress˜oes semelhantes `as que ocorrem no mundo real.
Entretanto, devido ao tamanho desses modelos, sua constru¸c˜ao requer, em geral, a
utiliza¸c˜ao de hardware de alta performance e alto custo, o que restringe a utiliza¸c˜ao
dessas tecnologias.
1.1 Objetivos
O prop´osito deste trabalho ´e a concep¸c˜ao e desenvolvimento de um algoritmo
que propicie a acelera¸c˜ao da visualiza¸c˜ao de modelos virtuais urbanos, com cache,
baseado em um buffer georeferenciado, que utiliza banco de dados geogr´aficos
como suporte para o armazenamento, recupera¸c˜ao de dados, e que permite a
visualiza¸c˜ao e navega¸c˜ao em modelos urbanos de larga escala em tempo real, em
uma plataforma de hardware convencional em termos de recursos computacionais.
Al´em disso, prop˜oe-se a constru¸c˜ao de uma interface 3D para uma base de
CAP
´
ITULO 1. INTRODUC¸
˜
AO 10
dados espacial, que poder´a ser utilizada para adicionar conte´udo multim´ıdia,
possibilitando o fornecimento de informa¸c˜oes a respeito dos monumentos hist´oricos
presentes na regi˜ao representada.
Foi utilizado um modelo urbano constru´ıdo de maneira ad hoc a partir de um
mapa da ´area do centro hist´orico da cidade de S˜ao Lu´ıs, tombada como patrimˆonio
hist´orico da humanidade.
1.2 Organiza¸c˜ao do Trabalho
O trabalho est´a organizado da seguinte maneira:
No Cap´ıtulo 2, apresentam-se os conceitos b´asicos necess´arios ao entendimento
das tecnologias que foram utilizadas no desenvolvimento deste trabalho. Sendo
expostos detalhes sobre as t´ecnicas de otimiza¸c˜ao da visualiza¸c˜ao de grandes
modelos, grafo de cena, sistema de informa¸c˜oes geogr´aficas, e por fim banco de
dados geogr´aficos. Al´em disso, s˜ao apresentadas as tecnologias envolvidas na
implementa¸c˜ao deste trabalho.
No Cap´ıtulo 3, ´e feita a exposi¸c˜ao de alguns trabalhos relacionados `a
otimiza¸c˜ao do rendering e visualiza¸c˜ao de modelos urbanos e com o emprego
de banco de dados espaciais aliados `a realidade virtual. Estes contribu´ıram para
o embasamento te´orico deste trabalho e motivaram o desenvolvimento de solu¸c˜oes
at´e ent˜ao n˜ao empregadas.
No Cap´ıtulo 4, ´e apresentado em detalhes o algoritmo de otimiza¸c˜ao de
visualiza¸c˜ao baseado em cache com o prot´otipo desenvolvido para que seja poss´ıvel
a visualiza¸c˜ao do modelo constru´ıdo.
E finalmente, no Cap´ıtulo 5, conclui-se o trabalho com uma reflex˜ao sobre os
resultados obtidos, al´em de sugerir trabalhos futuros a serem desenvolvidos.
Cap
´
ıtulo 2
Fundamenta¸c˜ao Te´orica
Neste cap´ıtulo, apresenta-se a fundamenta¸c˜ao te´orica em que se baseou o
desenvolvimento deste trabalho. S˜ao mostrados os conceitos b´asicos relacionados
ao assunto, que permitem o entendimento das tecnologias empregadas, as quais
s˜ao apresentadas na seq¨uˆencia.
2.1 Conceitos B´asicos
Nessa se¸c˜ao, apresentam-se alguns conceitos b´asicos necess´arios ao entendimento
das tecnologias que foram utilizadas no desenvolvimento deste trabalho.
Destacando-se entre eles, algumas t´ecnicas de acelera¸c˜ao do rendering, grafo de
cena, sistema de informa¸c˜ao geogr´afica e banco de dados geogr´aficos.
Antes de conceituar as t´ecnicas de acelera¸c˜ao propriamente ditas, faz-se
necess´aria a explica¸c˜ao do que ´e pipeline gr´afico. O pipeline gr´afico ´e um conjunto
de etapas realizadas pelo hardware para gerar a visualiza¸c˜ao de uma imagem de
uma cena, a partir de alguns parˆametros desta. Os parˆametros da cena incluem
os v´ertices, pol´ıgonos, dados sobre ilumina¸c˜ao (fontes de luz, vetores normais das
superf´ıcies), transforma¸c˜oes geom´etricas, entre outros.
Em (Tortelli and Walter 2007) h´a uma descri¸c˜ao mais detalhada do pipeline
gr´afico da nova gera¸c˜ao de hardwares gr´aficos, que possuem est´agios program´aveis
(Vertex Shader, Geometry Shader e Pixel Shader), vistos na Figura 2.1. Os
shaders s˜ao conjuntos de comandos que aceitam recursos gr´aficos de entrada,
executam uma s´erie de instru¸c˜oes sobre esses recursos e apresentam o resultado.
11
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 12
Os shaders s˜ao escritos em linguagens espec´ıficas, tais como: HLSL (High Level
Shading Language) para Direct3D, ou, GLSL (OpenGL Shading Language) para
OpenGL (OpenGL 2006), que permitem a programac˜ao de shaders em n´ıvel de
algoritmos. A implementac˜ao de shaders em uma aplica¸c˜ao gr´afica em tempo
real permite maior flexibilidade ao programador para tratar os dados dentro
do pipeline, e criar novos efeitos, aumentando a qualidade visual das cenas,
proporcionando uma experiˆencia de imers˜ao com muito mais realismo.
Figura 2.1: Pipeline gr´afico. Fonte: (Tortelli and Walter 2007)
As GPUs (Graphics Processing Units) mais modernas possuem trˆes tipos de
processadores: de v´ertices, de geometria e de fragmentos (Coutinho et al. 2007),
um para cada tipo de shader. O processador de v´ertices recebe como entrada um
v´ertice juntamente com seus atributos: normalmente a posi¸c˜ao, cor, coordenada
de texturas e a sua normal. Para cada um destes v´ertices, o processador executa
uma determinada seq¨uˆencia de instru¸c˜oes, que consiste no vertex shader. Este
pequeno programa far´a altera¸c˜oes nos parˆametros do v´ertice, de acordo com a
sua l´ogica, possibilitando criar efeitos complexos em tempo real (Clua 2004). Ao
terminar de processar o vertex shader, o v´ertice ´e encaminhado para o restante do
pipeline gr´afico, no caso, para o geometry shader que ´e respons´avel por especificar
como as primitivas ser˜ao processadas, al´em de permitir criar novas primitivas. J´a
o pixel shader consiste em um conjunto de instru¸c˜oes que especificam como os
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 13
pixels gerados s˜ao processados.
No pipeline gr´afico, o est´agio de rasteriza¸c˜ao processa um fragmento
individualmente, calculando sua cor atrav´es de uma interpola¸c˜ao da cor dos
v´ertices do pol´ıgono a que pertence, bem como das coordenadas da sua textura.
A sa´ıda de um programa deste tipo consiste numa cor. Tal recurso permite que
alguns efeitos de ilumina¸c˜ao, antes imposs´ıveis para visualiza¸c˜ao em tempo real,
possam ser eficientemente implementados (Clua 2004).
Para gerar uma cena ´e necess´ario configurar as vari´aveis de estado que definem
os atributos gr´aficos dos objetos que a comp˜oem. Portanto, o estado define as
caracter´ısticas de um objeto: material, textura, ilumina¸c˜ao, etc. Por exemplo,
pode-se aplicar uma ilumina¸c˜ao sobre os objetos de uma cena. Desta forma,
diz-se que o estado de ilumina¸c˜ao est´a “ligado”. Embora essa afirma¸c˜ao possa
n˜ao aparentar nenhuma complexidade, quando se determina que o hardware
gr´afico deva utilizar ilumina¸c˜ao, este ´e configurado para realizar uma s´erie de
opera¸c˜oes especiais, podendo ser bastante custoso quanto `a utiliza¸c˜ao de recursos
de m´aquina. O pipeline gr´afico ´e projetado para realizar uma tarefa da melhor
forma poss´ıvel, de acordo com a sua configura¸c˜ao. Ao se alterar um estado
talvez seja necess´ario interromper o pipeline para que este se ajuste aos novos
parˆametros.
´
E poss´ıvel perceber que, dependendo do estado que for alterado, o
pipeline pode ter que descartar todo o trabalho feito anteriormente, para poder
se reconfigurar e retomar o trabalho com a nova configura¸c˜ao. Um exemplo de
um estado que poderia causar esse efeito ´e o de ilumina¸c˜ao.
Al´em da ilumina¸c˜ao, existem v´arios outros tipos de estados, como
configura¸c˜oes de materiais (textura, cores) e configura¸c˜ao do sistema de
coordenadas.
O pipeline envolve a realiza¸c˜ao de in´umeras opera¸c˜oes que demandam por
muito esfor¸co de processamento e em raz˜ao disso ´e necess´aria a busca por
t´ecnicas que minimizem o esfor¸co computacional evitando c´alculos desnecess´arios
e otimizando o processamento para a visualiza¸c˜ao da cena.
Entre as diversas t´ecnicas propostas para realiza¸c˜ao de otimiza¸c˜ao do rendering
podemos destacar o descarte (culling) e n´ıvel de detalhe (LOD sigla do inglˆes Level
of Detail), as quais ser˜ao detalhadas nas se¸c˜oes seguintes.
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 14
2.1.1 Descarte
Descarte ´e o processo de elimina¸c˜ao de dados que contribuem pouco para a imagem
final. Esses dados incluem objetos que n˜ao podem ser vistos pelo observador
por alguns motivos. O descarte pode ser feito em diversas etapas no processo
de rendering. Trˆes tipos interessantes de descarte s˜ao o descarte das faces de
tr´as (backface culling), descarte por volume de visualiza¸c˜ao (frustum culling) e o
descarte por oclus˜ao (occlusion cullling).
Descarte das Faces de Tr´as
Este tipo de descarte ´e feito no espa¸co dos objetos, analisando os pol´ıgonos. Um
pol´ıgono possui dois lados: o lado da frente e o lado de tr´as. Normalmente, o
observador visualiza apenas um desses lados, o lado da frente. Assim, pol´ıgonos
que seriam visualizados por tr´as podem ser descartados. Desta forma, ao utilizar
o descarte das faces de tr´as, a complexidade da cena ´e reduzida, j´a que o lado dos
pol´ıgonos voltado para tr´as n˜ao ser˜ao processados.
Existem algumas maneiras de se determinar o descarte de faces. Uma das
mais aceitas consiste em calcular o ˆangulo formado entre o vetor normal ao
plano da face do pol´ıgono e o vetor partindo da cˆamera em dire¸c˜ao a este mesmo
plano, se o ˆangulo formado estiver entre 0
o
e 90
o
esta face ser´a vis´ıvel, no caso
desse ˆangulo ser maior, a face n˜ao ser´a vis´ıvel, sendo descartada do processo de
rendering. A Figura 2.2 mostra esse procedimento.
Figura 2.2: Esquema do descarte de faces de tr´as.
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 15
Descarte por Volume de Visualiza¸c˜ao
Ao contr´ario do descarte das faces de tr´as, o descarte por volume de visualiza¸c˜ao
pode eliminar objetos inteiros (compostos por v´arios pol´ıgonos). O processo
baseia-se em comparar se os objetos s˜ao vis´ıveis, ou seja, se est˜ao dentro do volume
de visualiza¸c˜ao conhecido como frustum. O frustum ´e um volume tridimensional
(volume de visualiza¸c˜ao), relacionado com uma determinada proje¸c˜ao (perspectiva
ou ortogr´afica). Em uma proje¸c˜ao em perspectiva, esse volume corresponde a uma
pirˆamide imagin´aria limitada pelos planos delimitadores near e far (plano pr´oximo
e distante.), que correspondem a distˆancias relativas ao observador, na dire¸c˜ao de
sua linha de vis˜ao. Este esquema ´e ilustrado na Figura 2.3.
Normalmente, os objetos possuem geometrias arbitr´arias e complexas. Desta
forma, para se decidir se um objeto ´e vis´ıvel ou n˜ao, s˜ao utilizadas formas
geom´etricas mais simples para aproximar o volume ocupado pelo objeto. O
objetivo de se utilizar formas geom´etricas mais simples ´e padronizar e facilitar
o c´alculo da interse¸c˜ao. Essas formas geom´etricas, que s˜ao conhecidas como
volumes envolventes (bounding volumes), s˜ao usualmente de dois tipos: esferas
(esfera envolvente, menor esfera que envolve o objeto) e paralelep´ıpedos (caixa
envolvente, menor paralelep´ıpedo que envolve o modelo).
Figura 2.3: Volume de vis˜ao. Fonte: (Valente 2004)
A Figura 2.4 ilustra um esquema para o descarte por volume de visualiza¸c˜ao,
Todos os objetos que se encontram no interior do volume s˜ao vis´ıveis.
A vantagem de se usar o frustum culling ´e que uma grande quantidade de
dados (pol´ıgonos) pode ser exclu´ıda do processo de renderiza¸c˜ao, antes de serem
enviados ao hardware. Se um objeto est´a totalmente inclu´ıdo no frustum, ele ´e
enviado para o hardware. Se um objeto est´a parcialmente dentro do frustum,
diversas estrat´egias podem ser aplicadas. Os objetos que se encontram fora do
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 16
frustum s˜ao descartados imediatamente.
Figura 2.4: Esquema do descarte por volume de visualiza¸c˜ao. Fonte: (Valente
2004)
Descarte por Oclus˜ao
´
E uma varia¸c˜ao mais sofisticada de descarte onde os objetos que s˜ao encobertos
por outros s˜ao eliminados do processamento gr´afico (Figura 2.5). Como exemplo,
um observador que est´a localizado em frente a um pr´edio. Atr´as deste,
existem diversos objetos complexos. Nesse exemplo, uma grande quantidade
de processamento computacional pode ser poupada ao se descartar inicialmente
todos os objetos que se encontram por tr´as do pr´edio, j´a que estes n˜ao podem ser
visualizados de maneira nenhuma.
Figura 2.5: Esquema do descarte por oclus˜ao
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 17
Como pode ser visto na Figura 2.5, o objeto C est´a totalmente encoberto pelos
outros dois, pois ao se tra¸car qualquer segmento de reta partindo da cˆamera
nenhum alcan¸car´a o objeto C. Portanto, este objeto ser´a descartado do processo
de visualiza¸c˜ao.
2.1.2 N´ıvel de Detalhe
Em computa¸c˜ao gr´afica, n´ıvel de detalhe (LOD) significa a diminui¸c˜ao da
complexidade da representa¸c˜ao de um objeto 3D `a medida que o observador se
afasta do mesmo, de acordo com alguma m´etrica, como o tamanho do objeto
(Funkhouser et al. 1992), velocidade de deslocamento do observador ou posi¸c˜ao
(Watson et al. 1996). Os objetos mais distantes s˜ao substitu´ıdos por vers˜oes
mais simples. Com isso, as t´ecnicas de LOD aumentam a eficiˆencia do rendering,
diminuindo a carga de trabalho nas fases do processamento gr´afico. A qualidade
visual reduzida do modelo ´e muitas vezes impercept´ıvel quando est˜ao distantes
ou em movimento r´apido. A Figura 2.6 mostra a representa¸c˜ao do mesmo objeto
com v´arios n´ıveis de detalhes, nesse caso, a representa¸c˜ao mais detalhada tem
uma quantidade bem maior de pol´ıgonos.
Figura 2.6: Exemplo da utiliza¸c˜ao de LOD. Fonte: (Alliez et al. 2002)
Embora as t´ecnicas de LOD sejam aplicadas em geral apenas a geometrias bem
detalhadas, o conceito b´asico pode ser generalizado.
2.1.3 Grafo de Cena
Em computa¸c˜ao gr´afica, uma “cena”se refere a uma cole¸c˜ao de objetos, seus
relacionamentos, e a defini¸c˜ao da forma como o observador vˆe esses objetos na
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 18
cena. Em matem´atica, um grafo discreto representa um sistema constru´ıdo a
partir de duas entidades fundamentais: n´os e arestas. Ambas as defini¸c˜oes nos
permitem explicar o que ´e um grafo de cena. Um grafo de cena ´e um grafo discreto,
dirigido, ac´ıclico, no qual n˜ao h´a nenhuma liga¸c˜ao de um n´o a ele mesmo, e nem
um caminho at´e alguns de seus predecessores no grafo (Tenenbaum et al. 1995).
Geralmente, um grafo de cena ´e uma organiza¸c˜ao hier´arquica de formas, grupos
de formas, e grupos de grupos que coletivamente definem o conte´udo de uma cena.
O grafo de cena permite ordenar dados em forma hier´arquica onde n´os pai afetam
seus n´os filho. Ele pode ter quantos filhos quiser, assim como uma ´arvore. Mas
n˜ao se trata de apenas uma ´arvore, ele representa tamb´em alguma a¸c˜ao a ter
lugar antes de proceder aos objetos filho. As formas e as sub-´arvores podem ser
compartilhadas entre m´ultiplos grupos (Sola et al. 2005).
Computacionalmente falando, um grafo de cena ´e uma estrutura de dados
que permite a organiza¸c˜ao hier´arquica de objetos que constituem uma cena
(Zeev 2003). Por exemplo, quando se representa um ve´ıculo com quatro rodas, ´e
desej´avel que a altera¸c˜ao da posi¸c˜ao ou da orienta¸c˜ao do carro seja transmitida
para as rodas. Outra rela¸c˜ao explorada no grafo de cena ´e a hierarquia de volumes
envolventes, onde objetos pr´oximos s˜ao agrupados para que, durante a etapa de
descarte, sejam eliminados com apenas um teste feito no topo da hierarquia,
evitando a necessidade de visitar cada um de seus filhos.
Um grafo de cena ´e uma estrutura de dados que utiliza uma abordagem
de alto n´ıvel para modelagem e gest˜ao de cenas, ao contr´ario das interfaces de
programa¸c˜ao de aplicativos (API) gr´aficas b´asicas (OpenGL e Direct3D). Os
usu´arios desse tipo de estrutura de dados n˜ao necessariamente precisam conhecer
os detalhes de implementa¸c˜ao de baixo n´ıvel para utiliz´a-la.
Um dos conceitos centrais a respeito de um grafo de cena ´e que este implementa
uma estrutura hier´arquica (Valente 2004). Em um grafo de cena todos os n´os
s˜ao ligados a um n´o raiz, que ´e usado para definir o come¸co dos dados da cena.
Para gerar a imagem da cena, o grafo ´e percorrido a partir da raiz. Altera¸c˜ao
de dados ou estrutura do grafo, assim como a especifica¸c˜ao de algoritmos de
travessia diversos, pode produzir imagens diferentes ao final do processo.
Uma diferen¸ca entre grafos de cena e grafos matem´aticos ´e que os grafos de
cena s˜ao heterogˆeneos, isto ´e, os n´os tˆem tipos diferentes. Como pode ser visto
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 19
na Figura 2.7, em um grafo de cena, a distin¸c˜ao principal est´a entre os n´os de
grupo e os n´os folha. As folhas carregam a geometria visualiz´avel, os demais n´os
do grafo s˜ao estruturados em grupos l´ogicos (Reiners 2002).
Figura 2.7: Estrutura de um grafo de cena. Fonte: (Reiners 2002)
2.1.4 Sistema de Informa¸c˜ao Geogr´afica
Um Sistema de Informa¸c˜ao Geogr´afica (SIG) ´e um sistema computacional capaz de
capturar, armazenar, analisar, e exibir informa¸c˜oes referenciadas geograficamente;
isto ´e, dados identificados de acordo com a localiza¸c˜ao sobre a superf´ıcie terrestre
(USDI 2007). Um SIG tamb´em pode ser definido como um sistema de hardware,
software, informa¸c˜ao espacial e procedimentos computacionais, que permitem e
facilita a an´alise, gest˜ao ou representa¸c˜ao do espa¸co e dos fenˆomenos que nele
ocorrem.
Essa tecnologia pode ser usada para investiga¸c˜oes cient´ıficas, estudos de
impacto ambiental ou de prospec¸c˜ao de recursos, e aux´ılio ao planejamento de
desenvolvimento urbano. Sendo de grande importˆancia por constituir um sistema
espacial de apoio a decis˜ao, que disponibiliza informa¸c˜oes referentes `a localiza¸c˜ao;
ou `a an´alise de rotas, onde ´e poss´ıvel o c´alculo de caminhos ´otimos entre dois ou
mais pontos; ou `a gera¸c˜ao de modelos explicativos a partir do comportamento
observado de fenˆomenos espaciais; ou at´e a utiliza¸c˜ao em material jornal´ıstico,
onde pode ser usado para aprofundar coberturas jornal´ısticas onde a espacializa¸c˜ao
´e importante.
Existem v´arios modelos de dados aplic´aveis em SIG. Por exemplo, o SIG pode
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 20
funcionar como uma base de dados com informa¸c˜ao geogr´afica que se encontra
associada aos objetos gr´aficos de um mapa digital. Desta forma, selecionando-se
uma ´area pode-se saber o valor dos seus atributos geogr´aficos, e inversamente,
selecionando um registro da base de dados ´e poss´ıvel saber a sua localiza¸c˜ao e
apont´a-la num mapa.
Os modelos de dados mais comuns em SIG s˜ao o modelo raster ou matricial e o
modelo vetorial. O modelo de SIG matricial centra-se nas propriedades do espa¸co,
fragmentando-o em c´elulas regulares (habitualmente quadradas, mas podendo ser
retangulares, triangulares ou hexagonais). Cada c´elula representa um ´unico valor
(Figura 2.8a). Quanto maior for a dimens˜ao de cada c´elula (resolu¸c˜ao) menor ´e
a precis˜ao ou detalhe na representa¸c˜ao do espa¸co geogr´afico. No caso do modelo
de SIG vetorial (Figura 2.8b), o foco das representa¸c˜oes centra-se na precis˜ao
da localiza¸c˜ao dos elementos no espa¸co. Para modelar digitalmente as entidades
do mundo real utilizam-se essencialmente trˆes formas espaciais: o ponto, a linha
e ´area (ou pol´ıgono). As estruturas vetoriais s˜ao utilizadas para representar as
coordenadas das fronteiras de cada entidade geogr´afica (USDI 2007).
(a) (b)
Figura 2.8: Exemplo de estruturas de arquivos. (a) modelo matricial. (b) modelo
vetorial. Fonte: (USDI 2007)
Na tentativa de chegar a uma padroniza¸c˜ao dos citados tipos de dados, foi
criado o Open Geospatial Consortium (OGC 2007), que ´e um cons´orcio
internacional com mais de 250 companhias, agˆencias, universidades participando
no desenvolvimento de solu¸c˜oes conceituais dispon´ıveis publicamente que podem
ser ´uteis a todos os tipos de aplica¸c˜oes que gerenciam dados espaciais. O objetivo ´e
incentivar os desenvolvedores de software de SIG e Geoprocessamento adotarem as
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 21
especifica¸c˜oes OpenGIS (OGC 2007), onde se encontram os padr˜oes que permitem
a interoperabilidade entre as tecnologias de geoprocessamento.
2.1.5 Banco de Dados Geogr´aficos
A pesquisa na ´area de Banco de Dados, j´a h´a algum tempo, passou a preocupar-se
com o suporte a aplica¸c˜oes n˜ao convencionais (Schneider 1997). Uma aplica¸c˜ao
´e classificada como n˜ao convencional quando trabalha com outros tipos de dados,
al´em dos tradicionais (inteiros, reais, caracteres), como tipos de dados espaciais,
temporais e espa¸co-temporais.
Ao longo dos anos, as implementa¸c˜oes de SIGs colaboraram para o surgimento
de diferentes arquiteturas, distinguindo-se principalmente pela estrat´egia adotada
para o armazenamento e recupera¸c˜ao de dados espaciais. Mais recentemente,
tais arquiteturas evolu´ıram para utilizar, cada vez mais, recursos de Sistemas de
Gerenciamento de Banco de Dados (SGBD) (Casanova et al. 2005), surgindo com
isso as extens˜oes espaciais dos principais SGBDs dispon´ıveis no mercado. Com
isso, torna-se comum a perspectiva da constru¸c˜ao de SIG onde tanto os atributos
como as geometrias de dados espaciais sejam gerenciados pelo SGBD.
Existem basicamente duas formas principais de integra¸c˜ao entre os SIGs e
os SGBDs, que s˜ao a arquitetura dual e a arquitetura integrada (Casanova et
al. 2005). A arquitetura dual armazena as componentes espaciais dos objetos
separadamente. A componente convencional, ou alfanum´erica, ´e armazenada em
um SGBD relacional e a componente espacial ´e armazenada em arquivos com
formato propriet´ario, o que ocasiona dificuldade no controle e manipula¸c˜ao das
componentes espaciais, e tamb´em dificuldades de interoperabilidade, j´a que cada
sistema trabalha com arquivos em formatos propriet´arios.
A arquitetura dominante atualmente ´e a integrada, que consiste em armazenar
todos os dados num SGBD, ou seja, tanto a componente espacial quanto a
alfanum´erica. Sua principal vantagem ´e a utiliza¸c˜ao dos recursos de um SGBD
para controle e manipula¸c˜ao de objetos espaciais, como gerˆencia de transa¸c˜oes,
controle de integridade, concorrˆencia e linguagens pr´oprias de consulta. Com isso,
a manuten¸c˜ao de integridade entre a componente espacial e alfanum´erica ´e feita
pelo SGBD.
Esta arquitetura pode ainda ser subdividida em trˆes abordagens: baseada em
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 22
campos longos, em extens˜oes espaciais e combinada.
A arquitetura integrada baseada em campos longos utiliza BLOBs (Binary
Large OBject) para armazenar a componente espacial dos objetos. Nesse caso,
o SGBD trata um BLOB como uma cadeia de bits sem nenhuma semˆantica
adicional. Portanto, ao codificar dados espaciais em BLOBs, esta arquitetura
torna a sua semˆantica opaca para o SGBD. Ou seja, passa a ser responsabilidade
do SIG implementar os operadores espaciais, capturando a semˆantica dos dados,
e m´etodos de acesso que possam ser ´uteis no processamento de consultas, embora
seja bastante dif´ıcil incorpor´a-los ao sistema de forma eficiente.
A arquitetura integrada com extens˜oes espaciais consiste em utilizar extens˜oes
espaciais desenvolvidas sobre um SGBD Objeto Relacional (SGBD-OR). Esta
arquitetura oferece algumas vantagens, entre as quais podemos destacar:
• Permite definir tipos de dados espaciais, equipados com operadores
espec´ıficos (operadores topol´ogicos e m´etricos);
• Permite definir m´etodos de acesso espec´ıficos para dados espaciais.
Exemplos desta arquitetura s˜ao o Oracle Spatial (Murray 2003), PostGIS
(PostGIS 2007) e a extens˜ao espacial do SGBD MySQL (MySQL 2006). Embora
largamente baseados nas especifica¸c˜oes do OpenGIS, estas implementa¸c˜oes
possuem varia¸c˜oes relevantes entre os modelos de dados, semˆantica dos operadores
espaciais e mecanismos de indexa¸c˜ao.
As extens˜oes espaciais utilizadas nas arquiteturas integradas possuem as
seguintes caracter´ısticas:
• Fornecem tipos de dados espaciais (TDE) em seu modelo de dados, e
mecanismos para manipul´a-los;
• Estendem a linguagem SQL para incluir opera¸c˜oes sobre TDEs,
transformando-a de fato em uma linguagem para consultas espaciais;
• Adaptam outras fun¸c˜oes de n´ıvel mais interno ao SGBD para manipular
TDEs eficientemente, tais como m´etodos de armazenamento e acesso, e
m´etodos de otimiza¸c˜ao de consultas.
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 23
No caso de aplicativos SIG que manipulam objetos com geometrias tanto
matriciais quanto vetoriais, ´e poss´ıvel a utiliza¸c˜ao de uma arquitetura integrada
combinada, formada pela combina¸c˜ao da arquitetura baseada em campos longos
e, em extens˜oes espaciais. Ou seja, as geometrias vetoriais s˜ao armazenadas
utilizando-se os recursos oferecidos pelas extens˜oes e as geometrias matriciais s˜ao
armazenadas em BLOBs.
As atuais extens˜oes espaciais possibilitam o melhor aproveitamento do SGBD
com dados deste tipo, pois quando se utiliza extens˜ao espacial pode-se trabalhar
com tipos de dados espaciais definidos por elas, tais como ponto, linha e pol´ıgono.
Estas extens˜oes permitem que tais dados sejam manipulados como qualquer outro
tipo de dado de SGBD (Campos et al. 2007). Al´em desta caracter´ıstica, h´a a
extens˜ao da linguagem SQL ofertando opera¸c˜oes e fun¸c˜oes para consultar rela¸c˜oes
espaciais.
Nas se¸c˜oes a seguir ser˜ao detalhados conceitos inerentes aos SGBDs com
extens˜oes espaciais, tais como: tipo de dados espaciais, indexa¸c˜ao espacial,
opera¸c˜oes espaciais, fun¸c˜oes espaciais, predicados espaciais, m´etricas espaciais e
fun¸c˜oes construtoras.
Tipos de Dados Espaciais
Tipo de dados espacial permite que o banco de dados reconhe¸ca pontos, linhas
e pol´ıgonos como objetos espaciais dentro da base de dados. O banco de dados
nativamente tem a capacidade de reconhecer tipos de dados, tais como reais,
inteiros, e caracteres. No entanto, um novo tipo deve ser inclu´ıdo a fim de que
o banco de dados possa compreender os objetos espaciais (Weinberger 2002).
O Open GIS Consortium (OGC) definiu uma estrutura para o tipo de dados
espaciais. Este foi definido como um tipo Geometry, como visto no modelo
simplificado na Figura 2.9.
O tipo Geometry ´e composto por ponto, linha, ´area e outros que podem ser
combinados para representar praticamente qualquer objeto geom´etrico (MySQL
2006). Neste modelo, cada objeto geom´etrico tem as seguintes propriedades gerais:
•
´
E associado com um Sistema de Referˆencia Espacial, que descreve a
coordenada espacial, na qual o objeto ´e definido;
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 24
Figura 2.9: Estrutura do tipo de dados espacial proposta pelo OGC. Fonte: (OGC
2007)
• Pertence a alguma classe geom´etrica.
Algumas destas classes s˜ao abstratas (n˜ao-instanci´avel). Isto ´e, n˜ao ´e poss´ıvel
criar um objeto desta classe. Outras classes s˜ao instanci´aveis e os seus objetos
podem ser criados. Cada classe tem propriedades e podem ter declara¸c˜oes (regras
que definem instˆancias de classes v´alidas).
A classe abstrata Geometry ´e a base da hierarquia, sendo que as subclasses
instanci´aveis de Geometry s˜ao restritas a objetos geom´etricos com zero, uma
ou duas dimens˜oes que existem no espa¸co de coordenadas bidimensional. Em
Geometry est´a presente um conjunto de propriedades que s˜ao comuns `as suas
subclasses.
Um objeto da classe geometry ter´a as seguintes propriedades:
• Tipo: cada geometria pertence a uma das classes instanci´aveis na hierarquia.
• Identificador de Referˆencia Espacial (SRID): este valor identifica o Sistema
de Referˆencia Espacial associada da geometria, o qual descreve a coordenada
espacial onde o objeto geom´etrico est´a definido.
• Coordenadas em seu Sistema de Referˆencia Espacial: todas as geometrias
n˜ao-vazias incluem pelo menos um par de coordenadas (X,Y). Coordenadas
est˜ao relacionadas ao SRID. Por exemplo, em sistemas de coordenadas
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 25
diferentes, a distˆancia entre dois objetos podem diferir mesmo quando os
objetos tˆem as mesmas coordenadas, porque as distˆancias no sistema de
coordenadas planar e a distˆancia no sistema geocˆentrico (coordenadas na
superf´ıcie da Terra) s˜ao coisas diferentes.
• Interior, limite e exterior: todas as geometrias ocupam alguma por¸c˜ao no
espa¸co. O exterior de uma geometria ´e todo espa¸co n˜ao ocupado pela
geometria. O interior ´e o espa¸co ocupado pela geometria. O limite ´e a
interface entre o interior e o exterior
• M´ınimo Retˆangulo Envolvente (MBR do inglˆes Minimum Bounding
Rectangle) da geometria: isto ´e, a geometria delimitadora, formada pelas
coordenadas de m´ınimo e m´aximo (X,Y):
• Propriedade fechado ou n˜ao-fechado: valores geom´etricos de alguns tipos
(LineString, MultiString) podem ser fechado ou n˜ao-fechado. Cada tipo
determina a sua pr´opria afirma¸c˜ao de ser fechado ou n˜ao-fechado.
• Propriedade vazia ou n˜ao-vazia: uma geometria ´e vazia se ela n˜ao tem
nenhum ponto. Exterior, interior e limite de uma geometria vazia n˜ao est˜ao
definidos (s˜ao representados por valores NULL).
• Dimens˜ao: uma geometria pode ter uma dimens˜ao de -1, 0, 1 ou 2:
– -1 usado para geometrias vazias
– 0 usado para geometrias sem tamanho e sem ´area.
– 1 usado para geometrias com tamanho diferente de zero e sem ´area.
– 2 usado para geometrias com ´area diferente de zero.
A classe base Geometry tem as subclasses: Point, Curve, Surface e
GeometryCollection:
• Point representam objetos sem dimens˜ao.
• Curve representam para objetos de uma dimens˜ao, e tem a subclasse
LineString, com subclasses Line e LinearRing.
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 26
• Surface ´e criado para objetos bidimensionais e tem a subclasse Polygon.
• GeometryCollection tem classes de cole¸c˜ao com zero, uma e duas-dimens˜oes
chamadas MultiPoint, MultiLineString e MultiPolygon para modelagem
geom´etrica correspondente a cole¸c˜oes de Points, LineStrings e Polygons
respectivamente. MultiCurve e MultiSurface s˜ao introduzidas como
superclasses abastratas que generalizam a interface de cole¸c˜ao para tratar
Curves e Surfaces.
Geometry, Curve, Surface, MultiCurve e MultiSurface s˜ao definidos como
classes n˜ao instanci´aveis. Eles definem em conjunto de m´etodos comuns para
suas subclasses inclu´ıdos por raz˜oes de extensebilidade.
Point, LineString, Polygon, GeometryCollection, MultiPoint,
MultiLineString, MultiPolygon s˜ao classes instanci´aveis.
Indexa¸c˜ao Espacial
Outro importante componente das extens˜oes espaciais ´e o ´ındice espacial.
Praticamente todos os bancos de dados incluem sistemas de indexa¸c˜ao para
permitir a r´apida localiza¸c˜ao e recupera¸c˜ao dos dados. No entanto, esses sistemas
s˜ao projetados para trabalhar com os tipos de dados nativos. Essas estruturas
tradicionais de dados de apenas uma dimens˜ao como tabelas hash (estrutura de
dados especial, que associa chaves de pesquisa (hash) a valores) ou ´arvores-B (B-
trees) n˜ao funcionam para dados de mais de uma dimens˜ao, pois essas estruturas
trabalham com compara¸c˜oes de igualdade entre vari´aveis enquanto aplica¸c˜oes
espaciais necessitam realizar compara¸c˜oes entre intervalos (Oliveira et al. 2007).
´
Indices espaciais s˜ao estruturas de dados que permitem promover acesso aos dados
de mais de uma dimens˜ao de maneira eficiente. Em um esfor¸co para permitir
que se recuperem rapidamente dados espaciais, foram desenvolvidas diversas
estruturas de dados com o prop´osito de indexar dados de mais de uma dimens˜ao,
entre elas est˜ao: Quadtrees, R-trees, hB-trees, TV-trees, SS-trees (Kothuri et
al. 2002). Recentemente, tem havido um movimento de migra¸c˜ao na utiliza¸c˜ao de
outros tipos de estruturas para R-trees como o mecanismo preferido de indexa¸c˜ao
de dados espaciais nas ferramentas dispon´ıveis no mercado (Weinberger 2002).
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 27
Os dados espaciais devem ser indexados para que se possa utilizar os
operadores e fun¸c˜oes espaciais sobre os campos do tipo geogr´aficos com um
melhor tempo de resposta. H´a casos, em que para utilizar operadores espec´ıficos
´e obrigada a indexa¸c˜ao espacial da tabela a ser utilizada.
Opera¸c˜oes Espaciais
Tipos de dados espaciais e indexa¸c˜ao espacial permitem que os dados sejam
armazenados e recuperados a partir de dados relacionais. No entanto, isto ´e
in´util, a menos que vocˆe tenha um modo de manipular os dados. A manipula¸c˜ao
desses dados ocorre atrav´es da utiliza¸c˜ao de operadores espaciais. Os operadores
espaciais dividem-se em v´arias categorias, entre os quais se incluem fun¸c˜oes
espaciais, predicados, medi¸c˜ao e construtor. O OGC define todas estas fun¸c˜oes,
mas nem todas s˜ao implementadas nas ferramentas e alguns SGBD espaciais
oferecem mais recursos do que outros. Todas essas fun¸c˜oes podem ser acessadas
usando comandos SQL.
As fun¸c˜oes espaciais permitem aos usu´arios executar opera¸c˜oes que geram
novas geometrias, como a cria¸c˜ao de um buffer em torno de um objeto (gera
uma nova geometria a partir de uma distˆancia de um objeto espec´ıfico). Fun¸c˜oes
espaciais devem ter uma entrada, que ser´a utilizada para efetuar a opera¸c˜ao, e em
seguida disponibilizar como resultado uma nova geometria.
Os predicados espaciais s˜ao desenvolvidos a partir de relacionamentos espaciais
entre fei¸c˜oes geogr´aficas, o que permite aos usu´arios consultas ao banco de dados
que retornam como resposta o resultado verdadeiro ou falso. Os predicados
espaciais podem representar os relacionamentos topol´ogicos disjoint, intersects,
inside, contains, touches, covers, covered-by, equal e crosses.
J´a as m´etricas espaciais fazem exatamente o que o nome sugere: c´alculo de
´area, comprimento ou per´ımetro e distˆancia entre geometrias. Uma medi¸c˜ao
espacial pode retornar a ´area ou comprimento de uma dada geometria.
As fun¸c˜oes construtores permitem aos usu´arios criar novos objetos espaciais
usando comandos SQL. Fornecendo-se as coordenadas X, Y um ponto pode ser
criado. Um conjunto de pontos pode servir como entrada para criar uma linha ou
pol´ıgono.
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 28
2.2 Tecnologias Envolvidas
Nessa se¸c˜ao, s˜ao apresentadas as tecnologias envolvidas no desenvolvimento do
modelo de arquitetura e na constru¸c˜ao do prot´otipo. Toda a implementa¸c˜ao deste
trabalho foi feita em C++ em conjunto com a biblioteca gr´afica OpenSceneGraph
(Osfield and Burns 2006), sendo utilizado para o armazenamento e gerenciamento
da base de dados a extens˜ao espacial do SGBD Oracle (Oracle 2005).
2.2.1 OpenSceneGraph
O OpenSceneGraph (OSG) ´e uma biblioteca gr´afica open source, usada por
desenvolvedores de aplica¸c˜oes nos campos tais como simula¸c˜ao visual, jogos
eletrˆonicos, realidade virtual, visualiza¸c˜ao cient´ıfica e modelagem. Escrita
inteiramente em Standard C++ e OpenGL, sendo independente de plataforma,
podendo rodar sobre as plataformas Windows, OSX, o GNU / Linux, IRIX,
Solaris, HP-Ux, AIX FreeBSD (Osfield and Burns 2006).
No desenvolvimento desse trabalho, decidiu-se utilizar o OSG por ser um toolkit
de alta performance e por oferecer um pacote completo com grande parte do que
se pode esperar de um gerenciador de grafo de cena. J´a traz implementadas
v´arias otimiza¸c˜oes, que permitem boa representa¸c˜ao de ambiente virtual 3D e
renderiza¸c˜ao eficiente (Sola et al. 2005), fundamentais quando se objetiva bom
desempenho em modelos grandes.
A constru¸c˜ao de aplica¸c˜oes gr´aficas com o OSG possibilita ao desenvolvedor
concentrar-se em rotinas de n´ıvel mais alto, j´a que a biblioteca livra o
desenvolvedor de implementar e otimizar chamadas gr´aficas de baixo n´ıvel, com
isso, agiliza o desenvolvimento dessas aplica¸c˜oes e poupa o desenvolvedor de
programar rotinas complexas de computa¸c˜ao gr´afica 3D e renderiza¸c˜ao (Sola
et al. 2005).
Dentre as caracter´ısticas do OSG, podem-se listar algumas das mais
interessantes para o desenvolvimento de aplica¸c˜oes gr´aficas:
Maximiza¸c˜ao do desempenho: O OSG ´e uma biblioteca que maximiza o
desempenho durante a visualiza¸c˜ao. Para isso s˜ao utilizadas duas t´ecnicas: culling
e propriedades de estado. A t´ecnica culling ´e aplicada quando se deseja excluir do
processamento partes geom´etricas de objetos 3D que n˜ao s˜ao visualizados naquele
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 29
momento, economizando tempo e capacidade de processamento da CPU e da placa
gr´afica. A t´ecnica de propriedades de estado se aplica quando diversos objetos
possuem caracter´ısticas iguais, tais como luzes, texturas e materiais. Nesse caso,
as propriedades iguais s˜ao armazenadas em um ´unico n´o e compartilhadas para
todos os objetos 3D que usam essas propriedades em um ambiente virtual. Isso
auxilia a economizar mem´oria relativa `as estruturas de dados necess´arias para
representar o ambiente virtual em uso.
Melhoria da Produtividade: O OSG auxilia a reduzir o tempo e o
trabalho requerido para programar aplica¸c˜oes gr´aficas de alto desempenho. Ele
esconde a complexidade do gerenciamento de todas as partes gr´aficas, reduzindo a
quantidade de linhas de c´odigo e chamadas para a biblioteca gr´afica de baixo n´ıvel,
OpenGL. Por ter uma estrutura baseada em orienta¸c˜ao a objetos, o OSG pode ser
considerado como uma biblioteca flex´ıvel que permite aumentar o reuso de c´odigo.
Assim, auxilia o desenvolvedor a criar aplica¸c˜oes com facilidade diminuindo o
tempo de an´alise e desenvolvimento e, conseq¨uentemente, a manuten¸c˜ao do c´odigo
dessas aplica¸c˜oes.
Portabilidade: O OSG encapsula muitos detalhes relativos a rotinas gr´aficas
de baixo n´ıvel, processamento gr´afico, e a leitura e escrita de dados, coibindo a
necessidade de criar c´odigo espec´ıfico para uma plataforma. Sendo assim, para
portar a aplica¸c˜ao em outras plataformas ´e necess´ario apenas recompilar o c´odigo
para outra plataforma.
Al´em da infra-estrutura para gerenciamento dos dados, vantagens adicionais
s˜ao oferecidas na forma de gerenciamento de detalhes e problemas. Uma cena
complexa em trˆes dimens˜oes cont´em muitos elementos diferentes, incluindo fontes
de luz, um modelo de cˆamera usado para visualizar a cena, os objetos na cena,
entre outros. Detalhes adicionais a serem gerenciados incluem os planos de
clipping, o mecanismo para otimizar a utiliza¸c˜ao dos buffers de cor e profundidade
em cada frame, os controles dos viewport. Manter um seguimento adequado de
toda esta informa¸c˜ao, al´em de prover defaults razo´aveis, pode ser amplamente
simplificado por um bom sistema de grafos de cena (Sola et al. 2005). Estas
caracter´ısticas foram importantes na decis˜ao pela utiliza¸c˜ao do OSG para o
desenvolvimento da arquitetura proposta neste trabalho.
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 30
2.2.2 Oracle Spatial
O conhecido SGBD Oracle possui a extens˜ao desenvolvida sobre o modelo objeto-
relacional para ser empregado do desenvolvimento de SIG. O Oracle Spatial ´e uma
extens˜ao espacial, que ´e baseada nas especifica¸c˜oes do OpenGIS. Esta extens˜ao
cont´em um conjunto de funcionalidades e procedimentos que permitem armazenar,
acessar, modificar e consultar dados espaciais em um banco de dados Oracle.
O Oracle Spatial ´e formado pelos seguintes componentes (Oracle 2005):
• Um modelo pr´oprio de dados chamado MDSYS que define a forma de
armazenamento, a sintaxe e semˆantica dos tipos espaciais suportados;
• Mecanismo de indexa¸c˜ao espacial;
• Um conjunto de operadores e fun¸c˜oes para representar consultas, jun¸c˜ao
espacial e outras opera¸c˜oes de an´alise espacial;
• Aplicativos administrativos.
A seguir ser´a detalhado o modelo conceitual do Oracle Spatial, al´em disso,
como ´e a sua representa¸c˜ao de geometrias, o seu objeto espacial para a
representa¸c˜ao de dados geogr´aficos, o seu conjunto de opera¸c˜oes implementadas,
a sua semˆantica das opera¸c˜oes e os seus m´etodos de indexa¸c˜ao.
Modelo Conceitual
O modelo de dados do Oracle Spatial consiste em uma estrutura hier´arquica de
elementos, geometrias e camadas de informa¸c˜ao (layers). Cada camada ´e formada
por uma cole¸c˜ao de geometrias que possuem um mesmo conjunto de atributos,
que por sua vez s˜ao formadas por um conjunto de elementos (Sharma 2001).
Cada elemento ´e associado a um tipo espacial primitivo, como ponto, linha ou
pol´ıgono (Point, LineString ou Polygon). Uma geometria pode ser formada por
um ´unico elemento ou por um conjunto homogˆeneo (MultiPoint, MultiLinesString
ou MultiPolygon) ou heterogˆeneo (Collection) de elementos.
Um elemento ´e o componente b´asico de constru¸c˜ao das geometrias do Oracle
Spatial. Eles s˜ao os tipos primitivos de dados suportados pelo Oracle e que
ser˜ao apresentados adiante. Os elementos s˜ao constru´ıdos utilizando coordenadas,
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 31
podendo ter um ou v´arios pares de coordenadas dependendo do elemento
(Silva 2002).
Uma geometria ´e uma representa¸c˜ao de um objeto espacial, modelada com um
conjunto ordenado de elementos primitivos (homogˆeneos ou heterogˆeneos). Cada
geometria possui um identificador, conhecido como Numeric Geometry Identifier
(GID), que ´e ´unico e que associa a geometria com o correspondente conjunto de
atributos (Silva 2002).
Um layer ´e uma cole¸c˜ao heterogˆenea de geometrias que compartilham o mesmo
conjunto de atributos (Silva 2002).
Representa¸c˜ao da Geometria
O Oracle Spatial suporta trˆes tipos primitivos de geometrias (ponto, linha ou
pol´ıgono) e uma cole¸c˜ao de outras geometrias (Figura 2.10) formadas a partir
desses tipos primitivos, tais como: arcos circulares, c´ırculos, linhas compostas e
pol´ıgonos compostos.
Figura 2.10: Tipos de dados espaciais do Oracle Spatial. Fonte: (Oracle 2005)
Os tipos espaciais bidimensionais s˜ao compostos por pontos formados por duas
ordenadas X e Y. A extens˜ao tamb´em suporta o armazenamento e indexa¸c˜ao
de tipos tridimensionais e tetradimensionais, mas as fun¸c˜oes e operadores s´o
funcionam para os tipos bidimensionais.
Os pontos s˜ao elementos compostos de duas coordenadas, X e Y,
freq¨uentemente correspondentes `a longitude e latitude. Linhas s˜ao compostas
de um ou mais pares de pontos que definem o segmento de linha. Pol´ıgonos s˜ao
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 32
compostos de linhas conectadas que formam um anel fechado, cujo interior do
pol´ıgono ´e impl´ıcito. Pol´ıgonos podem conter “buracos”que s˜ao constru´ıdos, por
defini¸c˜ao, internos aos pol´ıgonos. Neste caso, o anel exterior e o anel interior do
pol´ıgono s˜ao considerados como dois elementos distintos que juntos formam um
pol´ıgono complexo.
Objeto Espacial
Baseado no modelo objeto-relacional, o Oracle Spatial define um tipo de
objeto, para representar dados espaciais a serem manipulados, chamado
SDO GEOMETRY. Este objeto cont´em a geometria em si, suas coordenadas,
e informa¸c˜oes sobre seu tipo e proje¸c˜ao. Em uma tabela espacial, os
atributos alfanum´ericos da geometria s˜ao definidos como colunas de tipos b´asicos
(VARCHAR2, NUMBER, DATE, dentre outros), e a geometria como uma coluna
espacial (ou layer) particular da tabela do tipo MDSYS.SDO GEOMETRY. Em
uma tabela espacial, cada instˆancia do dado espacial ´e armazenada em uma linha,
e o conjunto de todas as instˆancias dessa tabela forma uma camada de informa¸c˜ao.
Conjunto de Opera¸c˜oes Implementadas
O Oracle Spatial fornece um conjunto de operadores espaciais (spatial operators)
e fun¸c˜oes espaciais (geometry functions), que s˜ao utilizados juntamente com a
linguagem SQL, para suportar consultas espaciais. A diferen¸ca b´asica entre essas
duas abordagens ´e que, as fun¸c˜oes n˜ao utilizam ´ındices nas tabelas espaciais, caso
existam. J´a para a utiliza¸c˜ao dos operadores, ´e necess´aria obrigatoriamente a
existˆencia de´ındices nas tabelas espaciais e, por conta disso, as consultas efetuadas
com operadores s˜ao mais eficientes. Outra diferen¸ca ´e que as fun¸c˜oes podem ser
utilizadas tanto na cl´ausula SELECT como na cl´ausula WHERE, enquanto que
os operadores s´o podem ser utilizados na cl´ausula WHERE.
A Tabela 2.1 apresenta algumas dessas opera¸c˜oes com uma breve descri¸c˜ao de
suas funcionalidades.
A Tabela 2.2 mostra as fun¸c˜oes espaciais implementadas com uma resumida
descri¸c˜ao do que fazem.
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 33
Tabela 2.1: Operadores Espaciais do Oracle Spatial. Fonte: (Oracle 2005)
Operadores Espaciais Descri¸c˜ao
SDO NN Determina os vizinhos mais pr´oximos a uma geometria
SDO NN DISTANCE Determina a que distˆancias est˜ao os objetos retornados
pelo operador SDO NN de uma dada geometria
SDO RELATE Determina se duas geometrias se interagem de algum
modo
SDO WITHIN DISTANCE Determina se uma geometria est´a a uma dada
distˆancia da outra
Semˆantica das Opera¸c˜oes
Para consultar rela¸c˜oes topol´ogicas entre duas geometrias ´e utilizado o operador
SDO RELATE ou a fun¸c˜ao SDO GEOM.RELATE. Estes implementam o Modelo
de 9-Interse¸c˜oes definido em (Egenhofer and Herring 1991). Este modelo considera
as interse¸c˜oes, vazia (0) ou n˜ao vazia (1), entre os interiores, fronteiras e
exteriores de duas geometrias. O SDO RELATE e a SDO GEOM.RELATE
recebe como parˆametro o tipo de rela¸c˜ao topol´ogica que deve ser computada. Os
poss´ıveis parˆametros s˜ao: Equal, Disjoint, Touch, Inside, OverlapBdyIntersect,
OverlapBdyDisjoint, Anyinteract, Contains, On, Covers e Coveredby (Oracle
2005). A seguir s˜ao apresentadas as descri¸c˜oes de cada relacionamento topol´ogico:
• EQUAL: dois objetos s˜ao iguais quando eles possuem a mesma fronteira e
o mesmo interior.
• DISJOINT: dois objetos s˜ao disjuntos quando nem o interior nem a fronteira
de ambos se interceptam, ou seja, n˜ao h´a relacionamento entre eles.
• TOUCH: dois objetos se tocam quando suas fronteiras se interceptam, mas
o interior n˜ao. Isto ´e, suas fronteiras compartilham pelo menos um ponto
comum, mas sem que haja nenhum ponto comum a ambos os interiores.
• INSIDE: ocorre quando o primeiro objeto est´a totalmente dentro do segundo
e suas fronteiras n˜ao se tocam.
• OVERLAPBDYINTERSECT: dois objetos tˆem um relacionamento desse
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 34
Tabela 2.2: Fun¸c˜oes Espaciais do Oracle Spatial. Fonte: (Oracle 2005)
Fun¸c˜oes Espaciais Descri¸c˜ao
SDO GEOM.RELATE Determina como duas geometrias se
interagem
SDO GEOM.SDO AREA Calcula a ´area de um pol´ıgono de duas
dimens˜oes
SDO GEOM.SDO BUFFER Gera um buffer (nova geometria) ao redor
de uma geometria
SDO GEOM.SDO DIFFERENCE Retorna a geometria correspondente `a
diferen¸ca topol´ogica entre duas geometrias
SDO GEOM DISTANCE Calcula a distancia entre duas geometrias
SDO GEOM.SDO INTERSECTION Retorna a geometria correspondente
`a interse¸c˜ao topol´ogica entre duas
geometrias
SDO GEOM.SDO LENGTH Calcula o comprimento ou per´ımetro de
uma geometria
SDO GEOM.SDO UNION Retorna a geometria correspondente `a
uni˜ao topol´ogica entre duas geometrias
SDO GEOM.VALIDATE GEOMETRY Determina se uma geometria ´e v´alida
SDO GEOM.VALIDATE LAYER Determina se todas as geometrias
armazenadas em uma coluna espacial s˜ao
v´alidas
SDO GEOM.WITHIN DISTANCE Determina se uma geometria est´a a uma
distˆancia espec´ıfica (distˆancia Euclidiana)
de outra
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 35
tipo (Overlap Boundaries Intersect) quando a fronteira e o interior de ambos
se interceptam.
´
E aplic´avel quando ambos os objetos s˜ao do tipo pol´ıgono.
• OVERLAPBDYDISJOINT: dois objetos tˆem um relacionamento desse tipo
(Overlap Boundaries Disjoint) quando o interior de um objeto intercepta a
fronteira e o interior de outro, mas as duas fronteiras n˜ao se interceptam.
´
E
aplicado quando o teste e efetuado entre objetos do tipo linha e pol´ıgono.
• ANYINTERACT: dois objetos tˆem algum tipo de intera¸c˜ao quando n˜ao s˜ao
disjuntos.
• CONTAINS: ocorre quando o segundo objeto est´a totalmente dentro do
primeiro e suas fronteiras n˜ao se tocam.
• ON: ocorre quando o interior e a fronteira do primeiro objeto est˜ao na
fronteira de outro objeto (e o segundo objeto abrange o primeiro objeto).
• COVERS: ocorre quando o segundo objeto est´a totalmente dentro do
primeiro e suas fronteiras se tocam em um ou mais pontos.
• COVERBY: ocorre quando o primeiro objeto est´a totalmente dentro do
segundo e suas fronteiras se tocam em um ou mais pontos.
Na Figura 2.11 s˜ao exibidas essas rela¸c˜oes topol´ogicas.
Figura 2.11: (Rela¸c˜oes Topol´ogicas implementadas no Oracle Spatial. Fonte:
(Oracle 2005)
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 36
M´etodos de Indexa¸c˜ao
O Oracle Spatial d´a suporte `a cria¸c˜ao de ´ındices para dados espaciais, podendo ser
de dois tipos: R-tree e Quadtree. Esses ´ındices espaciais podem ser criados com
extens˜oes de sintaxe SQL. Cada um desses ´ındices ´e apropriado para diferentes
situa¸c˜oes e podem ser usados simultaneamente para indexar uma mesma coluna
com geometria. Segundo Sharma (2001), o ´ındice R-tree pode ser utilizado em
lugar do Quadtree, ou em conjunto com ele.
As R-trees no Oracle spatial logicamente est˜ao implementadas como ´arvores e
internamente est˜ao implementadas em tabelas do Banco de dados. As buscas
envolvem SQL recursivos para se chegar da raiz aos n´os da ´arvore Kothuri
(2002). Essa abordagem resulta em buscas mais eficientes devido a uma melhor
preserva¸c˜ao de aproxima¸c˜oes espaciais, mas pode tornar-se lenta para atualiza¸c˜oes
e para a cria¸c˜ao dos ´ındices (Oliveira et al. 2007).
Para uma camada de geometrias, um ´ındice R-tree cont´em um ´ındice
hier´arquico no m´ınimo retˆangulo envolvente (MBR) da geometria na camada,
como visto na Figura 2.12.
A Quadtree realiza aproxima¸c˜ao das geometrias atrav´es de aproxima¸c˜oes
com quadrantes, que s˜ao resultantes da subdivis˜ao recursiva do espa¸co, tamb´em
conhecido como tesselamento (Figura 2.13).
Figura 2.12:
´
Indice hier´arquico R-tree. Fonte: (Oracle 2005)
A quadtree utiliza ´ındices e ´arvores-B para realizar buscas espaciais e outras
opera¸c˜oes de manipula¸c˜ao de dados (DML do inglˆes Data Manipulating
Language). Essa abordagem acarreta em uma cria¸c˜ao simplificada para os´ındices,
atualiza¸c˜ao r´apida dos ´ındices e uma heran¸ca de um controle de concorrˆencia de
´arvore B (Kothuri et al. 2002).
CAP
´
ITULO 2. FUNDAMENTAC¸
˜
AO TE
´
ORICA 37
Figura 2.13: Decomposi¸c˜ao Quadtree. Fonte: (Murray 2002)
Para o desenvolvimento deste trabalho optou-se pela extens˜ao espacial do SGBD
Oracle pela robustez da ferramenta, por conta da extensa documenta¸c˜ao e por ter
a licen¸ca gratuita para uso n˜ao comercial.
Cap
´
ıtulo 3
Trabalhos Relacionados
O uso da Realidade Virtual na constru¸c˜ao de grandes modelos urbanos em
conjunto com sistemas de informa¸c˜ao pode servir como um importante ve´ıculo
de informa¸c˜ao. Surge com isso, a necessidade do desenvolvimento de t´ecnicas que
otimizem a visualiza¸c˜ao desses modelos, que sejam associadas a um banco de dados
geogr´afico, permitindo o fornecimento de informa¸c˜oes mais fi´eis `a realidade. Dessa
maneira a visualiza¸c˜ao se transforma em uma excelente met´afora de interface para
an´alise de dados no banco.
Em (Porto et al. 2004) ´e abordado o problema de recupera¸c˜ao de modelos
tridimensionais de objetos em SGBD Objeto Relacional, buscando otimiz´a-lo com
o emprego de um algoritmo de oclus˜ao desenvolvido especificamente para este
sistema. O trabalho se insere em um contexto maior de desenvolvimento de um
sistema completo de apoio `a recupera¸c˜ao e exibi¸c˜ao de objetos 3D em aplica¸c˜oes
de AVC (Ambientes Virtuais Colaborativos) e SIG-3D. Entretanto, n˜ao foram
utilizados dados geogr´aficos reais e nem foi constru´ıdo um m´odulo de visualiza¸c˜ao,
sendo gerados arquivos de sa´ıda em AutoLISP para visualiza¸c˜ao no AutoCAD.
Pode-se observar que n˜ao s˜ao tratadas as quest˜oes relacionadas `a visualiza¸c˜ao
e nem de deslocamento dentro do ambiente virtual, e apesar de apresentar t´ecnicas
de otimiza¸c˜ao em SGBD Objeto-Relacional, n˜ao utiliza dados de uma ´area extensa
para os seus testes.
Em (Wilmott et al. 2001) ´e descrito um pacote que traz um conjunto
de t´ecnicas de renderiza¸c˜ao e otimiza¸c˜ao para a visualiza¸c˜ao de grandes e
complexos ambientes urbanos com taxas de quadros por segundo interativas. O
38
CAP
´
ITULO 3. TRABALHOS RELACIONADOS 39
pacote foi constru´ıdo baseado em uma estrutura de Grafo de Cena propriet´aria
desenvolvido para o projeto CHARISMATIC (Havemann and Fellne 2005).
O trabalho apresenta a combina¸c˜ao de Adapta¸c˜ao em Tempo-real de Malhas
(ROAM), Descarte de Objetos por Volume de Visualiza¸c˜ao (View Frustum
Culling), Descarte por Oclus˜ao (Occlusion Culling) e N´ıveis de Detalhe (LOD)
para as edifica¸c˜oes em uma ´unica aplica¸c˜ao com o objetivo de conseguir um
caminhamento em tempo-real no modelo virtual. Como resultado, ´e apresentado
uma compara¸c˜ao das m´edias de quadros por segundo no caminhamento do modelo
composto de 544.002 pol´ıgonos, sendo que sem a utiliza¸c˜ao das t´ecnicas de
otimiza¸c˜ao foi obtida uma taxa de quadros por segundos de 1,6 quadros por
segundo (fps), enquanto que com o emprego delas foi obtida uma taxa de 35,54 fps.
Na Figura 3.1 s˜ao mostrados os resultados de aplica¸c˜ao de t´ecnicas de texturas.
Figura 3.1: Compara¸c˜ao de casa com ou sem textura. Fonte: (Wilmott et al.
2001)
Apesar dos bons resultados apresentados em rela¸c˜ao ao desempenho, n˜ao h´a um
banco de dados geogr´aficos incorporado a sua arquitetura e por isso n˜ao apresenta
uma maneira pr´atica de adicionar informa¸c˜oes ´uteis a respeito das constru¸c˜oes que
comp˜oem todo o modelo.
Em (D¨ollner et al. 2005) ´e apresentada uma t´ecnica que proporciona a
visualiza¸c˜ao expressiva de representa¸c˜oes de grandes modelos 3D de cidades,
CAP
´
ITULO 3. TRABALHOS RELACIONADOS 40
inspirada em ilustra¸c˜oes art´ısticas e visualiza¸c˜oes cartogr´aficas utilizando a
vis˜ao panorˆamica do modelo. S˜ao definidos uma cole¸c˜ao de componentes do
modelo da cidade e um algoritmo de m´ultiplas etapas em tempo-real que atinge
representa¸c˜oes aceit´aveis do modelo, baseado em realce das bordas das principais
constru¸c˜oes do modelo, efeito de profundidade utilizando cor e sombra, e utiliza¸c˜ao
de texturas nas fachadas. Com essa apresenta¸c˜ao estilizada, busca-se facilitar o
reconhecimento, a navega¸c˜ao, explora¸c˜ao e an´alise de informa¸c˜ao espacial urbana.
O algoritmo tem quatro fases de rendering: Fase 1 gera uma codifica¸c˜ao de
textura das regi˜oes sombreadas da imagem; Fase 2 renderiza a cena com os realces
das bordas, sombreamento e fachadas com texturas; Fase 3 renderiza as bordas
estilizadas; e Fase 4 renderiza o restantes dos componentes do modelo 3D da
cidade. A Figura 3.2 mostra um exemplo de um modelo ilustrativo da cidade 3D
criado pela t´ecnica apresentada.
Figura 3.2: Visualiza¸c˜ao de modelo 3D com t´ecnica ilustrativa. Fonte: (D¨ollner
et al. 2005)
N˜ao s˜ao detalhadas as t´ecnicas empregadas na gera¸c˜ao dos pr´edios, e nem o
emprego de t´ecnicas de otimiza¸c˜ao do rendering. Existe um custo razo´avel para
o pr´e-processamento antes da visualiza¸c˜ao final. Nesse trabalho n˜ao ´e mostrada
como se d´a a integra¸c˜ao com uma base de dados espacial.
Um sistema de simula¸c˜ao urbana que tem como objetivo criar uma simula¸c˜ao
imersiva em grande escala da cidade de Dublin ´e descrito em (Hamill and
O’Sullivan 2003). A navega¸c˜ao pelo ambiente ´e feita em primeira pessoa dando
CAP
´
ITULO 3. TRABALHOS RELACIONADOS 41
ao usu´ario liberdade para ir onde desejar. Como foram inclu´ıdas praticamente
todas as constru¸c˜oes da cidade foi empregado LOD, Descarte por Oclus˜ao e um
algoritmo de gerenciamento de texturas para otimizar o sistema. O sistema foi
desenvolvido a partir de um modelo CAD existente com as bibliotecas OpenGL
e OpenAL (OpenAL 2006), esta ´ultima para ´audio 3D que pode ser utilizados
em v´arias aplica¸c˜oes, tais como jogos. Os modelos utilizados para simular as
constru¸c˜oes foram feitos com o 3D Studio Max (AutoDesk 2008), tˆem em
m´edia 500 pol´ıgonos, utilizam aproximadamente 1 MB de textura cada, sendo
que o maior tem 13500 pol´ıgonos e 6 MB de texturas (Figura 3.3). A carga e
posicionamento dos modelos no ambiente s˜ao controlados por um simples arquivo
texto. Diante disso, a taxa de quadros por segundos fica entre 25 e 60 fps,
dependendo da complexidade da cena atual.
Figura 3.3: Vista do Trinity College em Dublin. Fonte: (Hamill and O’Sullivan
2003)
Nesse caso, pode-se observar que apesar dos bons resultados apresentados em
rela¸c˜ao ao desempenho, tamb´em n˜ao h´a no modelo um banco de dados geogr´aficos
incorporado a sua arquitetura e, portanto, n˜ao s˜ao aproveitados os benef´ıcios da
utiliza¸c˜ao de bases de dados espaciais.
Em (Netto et al. 2005) ´e apresentado o desenvolvimento de uma interface
gr´afica 3D utilizando a tecnologia de ambientes virtuais com o objetivo de
auxiliar a tomada de decis˜ao em um sistema computacional para redu¸c˜ao de
perdas em redes de distribui¸c˜ao de energia el´etrica. Essa interface 3D foi
CAP
´
ITULO 3. TRABALHOS RELACIONADOS 42
constru´ıda para a visualiza¸c˜ao de uma grande quantidade de dados em um sistema
de distribui¸c˜ao, com redes de grande porte, al´em de facilitar a interpreta¸c˜ao
(avalia¸c˜ao) das solu¸c˜oes propostas pelo sistema e de permitir uma f´acil editora¸c˜ao
do sistema de distribui¸c˜ao com o objetivo de planejamento dessas redes. Nesse
trabalho, foi criado um SIG capaz de contemplar o maior n´umero de informa¸c˜oes,
ligadas ao georeferenciamento, onde houve a necessidade de armazenamento
de in´umeros dados e informa¸c˜oes sobre a carga da rede de distribui¸c˜ao de
energia el´etrica, tal como tens˜ao nos postes, carregamento dos cabos da rede,
capacidade da subesta¸c˜ao e dos alimentadores de energia; dados sobre localiza¸c˜ao
e posicionamento dos postes e subesta¸c˜oes em rela¸c˜ao `a cidade; informa¸c˜oes sobre
os diferentes tipos de postes, cabos e chaves de abertura e fechamento encontradas
na rede el´etrica, etc. Para dar suporte a esse grande volume de informa¸c˜oes foi
necess´ario a utiliza¸c˜ao de um banco de dados espacial. A constru¸c˜ao do modelo
baseou-se em um mapa 2D no formato CAD e imagens a´ereas da cidade de
S˜ao Carlos (SP). A partir do mapa 2D foi gerado o mapa tridimensional. Na
Figura 3.4, uma vista de quarteir˜oes modelados.
Figura 3.4: Exemplo de modelagem 3D dos quarteir˜oes da cidade. Fonte: (Netto
et al. 2005)
Nesse trabalho n˜ao foram citadas a utiliza¸c˜ao de t´ecnicas de otimiza¸c˜ao do
processo de rendering.
Em (Schilling and Zipf 2003) s˜ao tratados problemas relacionados `a gera¸c˜ao de
mundos 3D dinamicamente, e tenta resolver os problemas de integra¸c˜ao de dados
2D e 3D automaticamente. S˜ao introduzidos alguns mecanismos que permitem
CAP
´
ITULO 3. TRABALHOS RELACIONADOS 43
a gera¸c˜ao automatizada de conjuntos de dados geogr´aficos em 3D, que s˜ao
mostrados no prot´otipo implementado, onde s˜ao exibidas anima¸c˜oes otimizadas
do caminhamento por ´areas pr´e-selecionadas, sendo poss´ıvel a gera¸c˜ao de modelos
em VRML
1
(VRML 2005) dessas regi˜oes. A cidade de Heidelberg (Figura 3.5),
na Alemanha, foi utilizada para demonstra¸c˜ao.
´
E proposta a utiliza¸c˜ao de um
Servidor de Realidade Virtual (VR-Server) como camada intermedi´aria para
prover interfaces espec´ıficas para a carga de diferentes fontes geogr´aficas de dados
em 2D e 3D, onde as diversas bases de dados geogr´aficas tˆem seus sistemas
de referˆencias convertidos para um ´unico tipo comum a todos.
´
E utilizado
modelo digital de eleva¸c˜ao (DEM - digital elevation model), com base nas alturas
armazenadas de cada constru¸c˜ao, para a gera¸c˜ao da superf´ıcie da ´area. Os modelos
s˜ao gerados por extrus˜ao e reposicionados de acordo com sua eleva¸c˜ao. Os objetos
mais pr´oximos da cˆamera s˜ao trocados por modelos VRML mais detalhados.
Figura 3.5: Vista de uma quadra cidade de Heidelberg. Fonte: (Schilling and Zipf
2003)
Nesse caso, apesar da boa integra¸c˜ao com bases de dados geogr´aficas, no quesito
intera¸c˜ao com o modelo, h´a restri¸c˜oes quanto `a navega¸c˜ao no modelo, j´a que ´e
necess´aria uma sele¸c˜ao pr´evia de parte da ´area para que seja gerado o modelo, e
por conta disso ainda h´a um pr´e-processamento para cada nova sele¸c˜ao de regi˜oes.
Nos trabalhos citados podem-se observar as diferentes solu¸c˜oes para os
1
Virtual Reality Modeling Language - linguagem utilizada para a modelagem de ambientes
virtuais.
CAP
´
ITULO 3. TRABALHOS RELACIONADOS 44
problemas relacionados `a visualiza¸c˜ao de modelos urbanos. No entanto,
todos apresentam alguma carˆencia. O primeiro trabalho apresenta t´ecnicas
de otimiza¸c˜ao em SGBD Objeto-Relacional, mas n˜ao utiliza dados de uma
´area extensa para os seus testes, nem s˜ao tratadas as quest˜oes relacionadas
`a visualiza¸c˜ao e deslocamento dentro do ambiente virtual. Apesar dos bons
resultados apresentados em rela¸c˜ao ao desempenho, em (Wilmott et al. 2001)
e (Hamill and O’Sullivan 2003), os modelos n˜ao incorporam um banco de dados
geogr´aficos a sua arquitetura e por isso n˜ao apresenta uma maneira pr´atica
de adicionar informa¸c˜oes ´uteis a respeito das constru¸c˜oes que comp˜oem todo
o modelo. Em (D¨ollner et al. 2005) n˜ao ´e citado o emprego de t´ecnicas de
otimiza¸c˜ao da renderiza¸c˜ao, existindo um custo razo´avel de pr´e-processamento
antes da renderiza¸c˜ao final, nem ´e mostrado como se d´a a integra¸c˜ao com uma
base de dados espaciais. J´a (Netto et al. 2005) implementa SIG, mas n˜ao aborda
t´ecnicas de otimiza¸c˜ao em rela¸c˜ao a renderiza¸c˜ao e visualiza¸c˜ao. O ´ultimo trabalho
apresenta uma interessante integra¸c˜ao com a base de dados, mas possui limita¸c˜oes
quanto a navega¸c˜ao no ambiente urbano, e alto custo de pr´e-processamento para
a gera¸c˜ao das ´areas selecionadas a serem visualizadas. Na Tabela 3.1 ´e mostrado
um comparativo resumido entre os trabalhos pesquisados.
CAP
´
ITULO 3. TRABALHOS RELACIONADOS 45
Tabela 3.1: Resumo comparativo dos trabalhos pesquisados
(Porto et
al. 2004)
(Wilmott et
al. 2001)
(D¨ollner et
al. 2005)
(Hamill and
O’Sullivan 2003)
(Netto et
al. 2005)
(Schilling and
Zipf 2003)
Tamanho 164 objetos 544.002
pol´ıgonos
N/D* 80 modelos N/D N/D
Taxa de
quadros por
segundos
N/D 35,54 N/D Entre 25 e 60 N/D N/D
SGBD
espacial
N˜ao N˜ao N/D N˜ao Sim Sim
T´ecnica de
Otimiza¸c˜ao
Descarte por
oclus˜ao
Descarte por
vis˜ao e por
oclus˜ao, LOD,
ROAM
N/D Descarte por
oclus˜ao, LOD,
gerenciamento de
textura
N/D LOD
Visualiza¸c˜ao N˜ao Sim Sim Sim Sim Sim
Deslocamento
no modelo
N˜ao N/D Sim Sim Sim Sim
* N/D - Informa¸c˜ao n˜ao dispon´ıvel
CAP
´
ITULO 3. TRABALHOS RELACIONADOS 46
Na metodologia proposta neste trabalho, buscou-se utilizar as t´ecnicas que
permitissem obter um melhor desempenho na visualiza¸c˜ao e navega¸c˜ao em
ambiente virtual urbano sem que se fizesse necess´aria a utiliza¸c˜ao de hardware
com alto poder de processamento. Al´em disso, o modelo gerado ´e associado a
uma base de dados geogr´aficos, o que permite atrelar importantes informa¸c˜oes ao
modelo.
Cap
´
ıtulo 4
Estrat´egia de Otimiza¸c˜ao para
Acelera¸c˜ao da Visualiza¸c˜ao de
Modelos Virtuais Urbanos
Para realizar a visualiza¸c˜ao de um grande modelo 3D que represente uma
´area urbana e que possibilite um deslocamento por dentro dele com um bom
desempenho, s˜ao necess´arias v´arias etapas que empregam t´ecnicas de otimiza¸c˜ao
desde a recupera¸c˜ao dos dados espaciais ao gerenciamento do grafo da cena, bem
como na visualiza¸c˜ao do ambiente virtual constru´ıdo.
O problema estudado neste trabalho concentra-se na otimiza¸c˜ao da
visualiza¸c˜ao de um modelo urbano constru´ıdo a partir de uma base de dados
espacial associada a um conjunto de arquivos com os modelos 3D, os quais
representam as constru¸c˜oes de uma ´area urbana. Com a utiliza¸c˜ao de um banco de
dados geogr´aficos ´e dado suporte ao armazenamento, recupera¸c˜ao e visualiza¸c˜ao
desse modelo virtual urbano em tempo real.
Neste cap´ıtulo, ser´a detalhado o algoritmo de visualiza¸c˜ao, a arquitetura de
visualiza¸c˜ao proposta e apresentado os resultados obtidos nos testes realizados
com a aplica¸c˜ao desenvolvida.
47
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 48
4.1 T´ecnica de Acelera¸c˜ao
O algoritmo proposto neste trabalho gerencia o grafo de cena, com base nos
dados acessados no banco espacial, utilizando uma estrat´egia de cache baseada
em um buffer em volta da posi¸c˜ao da cˆamera. Com isso, ´e poss´ıvel selecionar
um conjunto espec´ıfico de objetos a uma determinada distˆancia do observador
que ser˜ao adicionados ao grafo, limitando assim a quantidade de n´os no grafo,
j´a que n˜ao s˜ao carregados todos os objetos do modelo. Com isso, obt´em-se uma
redu¸c˜ao consider´avel no consumo de recursos computacionais, imaginando um
cen´ario onde seja necess´aria a visualiza¸c˜ao de modelos de grandes propor¸c˜oes que
podem ter algumas centenas de objetos ou at´e mesmo milhares ou milh˜oes de
objetos.
Inicialmente, pensou-se em utilizar um buffer com ´area triangular com um
v´ertice situado por tr´as da cˆamera e os outros dois `a frente, como podem ser
visto na Figura 4.1a. Nesse caso, seriam pesquisados e carregados no grafo
aqueles objetos que estivessem dentro da regi˜ao cinza claro mais os que estivessem
na ´area cinza escuro, sendo estes ´ultimos carregados mesmo n˜ao sendo vis´ıveis,
funcionando apenas como uma margem para o caso da cˆamera ser rotacionada,
onde o usu´ario mudaria o seu campo de vis˜ao para os lados.
(a) (b)
Figura 4.1: Poss´ıveis formas de buffers. (a) buffer triangular. (b) buffer circular.
No entanto, foi adotado um buffer circular (Figura 4.1b) em volta da cˆamera,
optando-se por essa forma ao inv´es de uma forma triangular para minimizar
o n´umero de inser¸c˜oes e remo¸c˜oes de objetos no grafo quando a cˆamera for
“girada”rapidamente e em um ˆangulo n˜ao contemplado pela regi˜ao triangular.
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 49
Por conta disso, os objetos situados atr´as da cˆamera tamb´em s˜ao carregados,
desde que estejam dentro da ´area delimitada pelo buffer. Este buffer tem um raio
que ´e passado como parˆametro e que define a sua ´area total.
Para obter-se a lista de objetos que s˜ao carregados ou descartados do grafo
de cena ´e feita a interse¸c˜ao da ´area contida no buffer com as geometrias contidas
nas tabelas espaciais. Essa opera¸c˜ao ´e realizada utilizando os operadores espaciais
adequados em conjunto com as fun¸c˜oes espaciais necess´arias. Para agilizar o acesso
dos dados espaciais foram criados ´ındices espaciais para cada uma das tabelas
que contˆem dados geogr´aficos. No desenvolvimento deste trabalho foi utilizado o
Oracle Spatial, que obriga a se criar ´ındices espaciais para que se possam usar os
operadores espaciais. Abaixo ´e mostrada a sintaxe de cria¸c˜ao de um dos ´ındices
utilizados. Nesse caso, est´a sendo criado o ´ındice espacial square idx para o campo
GEOMETRY da tabela square.
CREATE INDEX square_idx ON square(GEOMETRY)
INDEXTYPE IS mdsys.spatial_index;
Neste trabalho, foi utilizado o operador espacial SDO RELATE do
Oracle Spatial utilizando a m´ascara ANYINTERACT e as fun¸c˜oes espaciais
SDO GEOM.SDO DIFFERENCE e SDO GEOM.SDO BUFFER.
O operador espacial SDO RELATE ´e utilizado para determinar se duas
geometrias interagem entre si, e com a utiliza¸c˜ao da m´ascara ANYINTERACT
s˜ao retornados todos os objetos que tenham alguma rela¸c˜ao topol´ogica entre eles.
A fun¸c˜ao espacial SDO GEOM.SDO DIFFERENCE fornece como resultado de
sua chamada, uma geometria que corresponde `a diferen¸ca topol´ogica entre duas
geometrias. J´a a fun¸c˜ao SDO GEOM.SDO BUFFER cria uma nova geometria
ao redor da geometria passada como parˆametro. Abaixo um exemplo de uma das
consultas espaciais realizadas usando a sintaxe dos operadores e fun¸c˜oes espaciais
para o Oracle Spatial.
SELECT lot.idlot, square.idsquare, street.name, lot.geometry, lot.path
FROM lot , square, street
WHERE lot.idsquare = square.idsquare
AND lot.idstreet = street.idstreet
AND SDO_RELATE(lot.geometry,
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 50
SDO_GEOM.SDO_DIFFERENCE(
SDO_GEOM.SDO_BUFFER( MDSYS.SDO_GEOMETRY( 3001, 1,
MDSYS.SDO_POINT_TYPE("oldCoordX", "oldCoordY", 0), NULL,
NULL ), sizeBuffer, 0.01, ’unit=m arc_tolerance=0.005’ ),
SDO_GEOM.SDO_BUFFER( MDSYS.SDO_GEOMETRY(3001,1,
MDSYS.SDO_POINT_TYPE("coordX", "coordY", 0) , NULL, NULL ),
sizeBuffer, 0.01,’unit=m arc_tolerance=0.005’ ),
0.001
) ,
’mask = ANYINTERACT querytype = WINDOW’
) = ’TRUE’
Na primeira itera¸c˜ao, s˜ao consultadas todas as geometrias contidas nas tabelas
espaciais que tˆem qualquer intera¸c˜ao com a ´area delimitada pelo buffer, e ent˜ao
s˜ao carregados todos os objetos 3D correspondentes. A partir do primeiro
deslocamento da cˆamera ´e feita a diferen¸ca entre o buffer atual e o buffer anterior
para que se possa obter as ´areas que contˆem os objetos que dever˜ao ser removidos
e inseridos no grafo de cena. Com isso n˜ao ´e necess´ario fazer a interse¸c˜ao das
tabelas espaciais com toda a ´area do contemplada pelo buffer, mas somente com
as ´areas resultantes das diferen¸cas entre os buffers da posi¸c˜ao atual e anterior.
Estas consultas s˜ao realizadas a partir da execu¸c˜ao do m´etodo de remo¸c˜ao de
objetos e na seq¨uˆencia pelo m´etodo respons´avel pela inser¸c˜ao dos novos objetos
no grafo.
Este procedimento ´e mostrado na Figura 4.2, onde est˜ao representadas as ´areas
resultantes dessa opera¸c˜ao, mostrando-se o deslocamento da cˆamera do ponto A
ao ponto B. Nesse exemplo, a ´area em amarelo envolve todos os objetos a serem
descartados, os quais s˜ao determinados pela diferen¸ca entre o buffer da posi¸c˜ao
anterior (A) e o novo buffer (B) da posi¸c˜ao atual. J´a os objetos que est˜ao na
´area de interse¸c˜ao s˜ao mantidos e aqueles que est˜ao dentro da ´area em azul ser˜ao
inclu´ıdos no grafo, sendo estes obtidos pela diferen¸ca entre o buffer atual (B) e o
buffer antigo (A).
A cada inser¸c˜ao ´e verificado se os objetos que est˜ao no buffer consultado
j´a est˜ao ou n˜ao no grafo. Em caso afirmativo eles ser˜ao desconsiderados, caso
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 51
contr´ario, ser˜ao inseridos no grafo. Com essa checagem impede-se a redundˆancia
na carga dos objetos. Essa verifica¸c˜ao ´e feita atrav´es de listas de objetos com
os ´ındices das geometrias dos n´os inseridos anteriormente no grafo, onde a cada
inser¸c˜ao no grafo ´e tamb´em inserido um objeto de identifica¸c˜ao na lista de ´ındices,
contendo a identifica¸c˜ao espacial (id) desta geometria.
Figura 4.2:
´
Areas cobertas pelos buffers
Como mais uma estrat´egia de redu¸c˜ao de intera¸c˜oes com o grafo da cena, o
que acarreta um consider´avel consumo de recursos de hardware, definiu-se um
mecanismo baseado em uma tolerˆancia no deslocamento feito pelo usu´ario da
cˆamera. Isto ´e, ao inv´es de realizar a cada deslocamento todo o procedimento de
busca no banco e atualiza¸c˜ao do grafo, ´e checado se a posi¸c˜ao da cˆamera encontra-
se dentro da ´area circular da tolerˆancia, e em caso afirmativo n˜ao ser´a realizada
qualquer atualiza¸c˜ao, como pode ser visto na Figura 4.3.
Figura 4.3:
´
Area de tolerˆancia no deslocamento da cˆamera
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 52
Enquanto a cˆamera for deslocada dentro da ´area em amarelo claro nenhum outro
objeto ser´a inserido ou removido do grafo. As jun¸c˜oes das ´areas internas e mais
externas representam a regi˜ao onde est˜ao todos os objetos contidos no grafo
naquele momento. Essa ´area mais interna, ou ´area de tolerˆancia, tamb´em tem o
seu valor parametrizado.
No diagrama de classes mostrado na Figura 4.4, s˜ao exibidas as principais
classes implementadas do modelo, bem como os seus atributos e m´etodos mais
relevantes. No diagrama exposto, a classe Application corresponde ao arquivo
fonte onde se encontra a fun¸c˜ao principal do prot´otipo implementado.
Figura 4.4: Diagrama de classes da aplica¸c˜ao desenvolvida
Em Application s˜ao instanciados os objetos: de conex˜ao ao banco de dados, a raiz
do grafo de cena (do tipo osg::Group), o viewer (do tipo osgProducer::Viewer) e
o manipulador da cˆamera (do tipo Manipulator::osgGA::MatrixManipulator).
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 53
A classe Manipulator tem uma referˆencia para o objeto root, com ela pode-se
anexar outros grupos de objetos ao grafo. No caso, s˜ao instanciados trˆes objetos
do tipo osg::Group (groupSquare, groupStreet e groupLot), um para cada tipo
espacial utilizados no trabalho, nos quais s˜ao adicionados os objetos 3D ou 2D
correspondentes. Nessa classe, s˜ao instanciados objetos do tipo Feature, tamb´em
um para cada entidade espacial. Ainda nesta classe, s˜ao definidos os parˆametros
da cˆamera o do buffer, bem como os m´etodos respons´aveis pelo c´alculo da posi¸c˜ao
e de movimento da cˆamera, de acordo com a utiliza¸c˜ao do mouse.
A classe Feature ´e respons´avel pelo gerenciamento de um grupo espec´ıfico de
geometrias, por exemplo, as quadras do modelo. Por conta disso, ela instancia
a classe osg::Group e utiliza polimorfismo com as classes Square, Street e Lot.
S˜ao criados trˆes objetos da classe Feature em Manipulator para que se possam
executar as consultas espaciais e os m´etodos de remo¸c˜ao e inser¸c˜ao de objetos
no grafo, por isso necessita tamb´em da referˆencia do objeto raiz (root) do grafo.
Nela tamb´em, est˜ao as listas de ´ındices dos objetos presentes no grafo para cada
entidade, por exemplo, o objeto que representa a feature Square tem uma lista
de ´ındices dos n´os do mesmo tipo inseridos anteriormente no grafo, utilizada para
consultas no momento de novas inser¸c˜oes. Esta lista ´e do tipo IndexFeatureChild,
nela est˜ao os atributos necess´arios para o gerenciamento dos objetos no grafo de
cena, tais como o ´ındice de n´o no grafo e os atributos utilizados como chave nas
buscas na lista.
As classes Square, Street e Lot s˜ao respons´aveis pelo mapeamento das
entidades no banco espacial. Nelas, podemos incluir dados n˜ao geogr´aficos
espec´ıficos a cada tipo.
4.2 Arquitetura de Visualiza¸c˜ao Proposta
Para realizar a visualiza¸c˜ao de modelos urbanos desenvolveu-se a modelagem
do problema com um banco de dados espacial 2D, sobre o qual s˜ao realizadas
consultas espaciais para que sejam recuperados os objetos (features) que
representam as quadras, os segmentos de rua e os lotes dos pr´edios, e a partir
disso s˜ao carregados os objetos 3D que representam as constru¸c˜oes arquitetˆonicas,
ou ent˜ao s˜ao desenhadas essas features.
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 54
Na abordagem adotada neste trabalho, optou-se pela navega¸c˜ao em primeira
pessoa, por ser mais pr´oximo da vis˜ao real e por se adequar muito bem a estrat´egia
de cache proposta, onde somente os objetos dentro de um determinado raio em
volta da cˆamera s˜ao carregados. O modelo aqui apresentado baseia-se na premissa
de que modelos urbanos s˜ao densos, no que diz respeito `a quantidade de objetos
nele contidos, quando visualizados do solo e, em como conseq¨uˆencia, os pr´edios
mais pr´oximos obstruem a visualiza¸c˜ao dos demais. Por conta disso, em todas as
dire¸c˜oes de visada os espa¸cos s˜ao preenchidos pelos pr´edios sem a necessidade de
ser carregado um grande volume de objetos. Caso fosse utilizada outra alternativa
de visualiza¸c˜ao, como de vis˜ao panorˆamica, seria necess´aria a implementa¸c˜ao de
outras estrat´egias de otimiza¸c˜ao.
Na Figura 4.5, exp˜oe-se uma vis˜ao geral da arquitetura de visualiza¸c˜ao
proposta, a qual est´a organizada em trˆes camadas: apresenta¸c˜ao, aplica¸c˜ao e
dados.
Figura 4.5: Vis˜ao geral da arquitetura
A camada de apresenta¸c˜ao ´e respons´avel pela visualiza¸c˜ao da cena. Nela h´a o
la¸co de visualiza¸c˜ao que ´e executado por todo o per´ıodo de execu¸c˜ao da aplica¸c˜ao
utilizando m´etodos do objeto viewer para gerar a cena. Tamb´em ´e definida e
parametrizada a cˆamera da cena em conjunto com o objeto manipulator, este
´ultimo respons´avel por tratar os eventos de entrada e atualizar os parˆametros da
cˆamera. Esta camada caracteriza-se como a interface de intera¸c˜ao entre o usu´ario
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 55
e a aplica¸c˜ao desenvolvida.
Na camada de aplica¸c˜ao fica hospedada a l´ogica de neg´ocios do sistema, na qual
´e implementada a classe Manipulator, onde ´e utilizada uma referˆencia ao objeto
de conex˜ao com a base de dados para realizar as consultas, s˜ao processados os
resultados e implementada a estrat´egia de cache baseada nas consultas espaciais
para a obten¸c˜ao dos dados geogr´aficos relevantes `a visualiza¸c˜ao. A partir disso, ´e
feita a inser¸c˜ao e exclus˜ao de objetos no grafo de cena, bem como o gerenciamento
dos dados relacionado aos modelos 3D das constru¸c˜oes armazenados em disco que
s˜ao carregados nas cenas.
Por fim, a camada de dados que encapsula o acesso `a base de dados, tanto dos
dados armazenados no banco de dados como nos arquivos dos objetos 3D que se
encontram em disco. A seguir o detalhamento de cada uma delas.
4.2.1 Camada de Apresenta¸c˜ao
Na camada de apresenta¸c˜ao encontra-se o m´odulo de visualiza¸c˜ao que ´e
respons´avel pela exibi¸c˜ao da cena gerada a partir do grafo. Para isso ´e criado o
objeto de visualiza¸c˜ao da cena, o viewer, que recebe como um de seus argumentos a
cˆamera, bem como o objeto manipulator, respons´avel pelo tratamento dos eventos
do mouse e a atualiza¸c˜ao dos parˆametros da cˆamera. Al´em disso, ´e nessa camada
que ´e criado o objeto raiz do grafo de cena, respons´avel por agrupar todos os
demais n´os que comp˜oem a cena. Faz-se necess´ario tamb´em a utiliza¸c˜ao de
um la¸co respons´avel pelo rendering que garante a atualiza¸c˜ao da cena a cada
mudan¸ca ocorrida na mesma ou ent˜ao na cˆamera. Sendo exibidas tamb´em algumas
informa¸c˜oes sobre cada n´o do grafo `a medida que se passa o cursor do mouse sobre
eles, tais como a identifica¸c˜ao do objeto dentro do grafo de cena, o nome do arquivo
em disco e as coordenadas do objeto dentro do modelo, como visto na Figura 4.6.
A interface entre o usu´ario e a aplica¸c˜ao se d´a atrav´es do mouse, que ao
mover o mouse com o bot˜ao esquerdo pressionado aplica uma rota¸c˜ao em rela¸c˜ao
ao eixo vertical da cˆamera, enquanto que ao mover o mouse com o bot˜ao
direito pressionado, este aplica `a cˆamera um deslocamento horizontal em todas as
dire¸c˜oes.
Inicialmente s˜ao carregados os objetos de uma localiza¸c˜ao pr´e-determinada
e a partir do primeiro movimento de cˆamera ´e executado o fluxo de tarefas
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 56
ilustrado resumidamente no diagrama de seq¨uˆencia apresentado na Figura 4.7.
Figura 4.6: Imagem com as informa¸c˜oes do objeto 3D sendo exibidas
Figura 4.7: Cen´ario de atualiza¸c˜ao do grafo de cena e a visualiza¸c˜ao
1. Usu´ario movimenta o mouse;
2. Tratamento do evento do mouse, no caso o bot˜ao direito pressionado e
arrastando para realizar uma transla¸c˜ao;
3. Chamada de m´etodo que calcula a nova posi¸c˜ao da cˆamera;
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 57
4. Executado o m´etodo de remo¸c˜ao dos objetos;
5. S˜ao consultados no banco os objetos a serem removidos de acordo com o
buffer;
6. Retornam os objetos removidos;
7. Executado o m´etodo de carga dos objetos;
8. S˜ao consultados no banco os objetos a serem adicionados no grafo de acordo
com o buffer;
9. Retorna objetos adicionados;
10. Grafo atualizado e cena gerada para a visualiza¸c˜ao.
4.2.2 Camada de Aplica¸c˜ao
A camada de aplica¸c˜ao ´e respons´avel pela l´ogica de neg´ocios. Nela ´e implementada
a classe Manipulator. Esta classe recebe e trata os eventos repassados pela
interface com o usu´ario, realiza as transforma¸c˜oes espaciais sobre a cˆamera, obt´em
uma referˆencia para o objeto de conex˜ao `a base de dados, instancia objetos da
classe Feature para realizar as consultas espaciais de acordo com a estrat´egia de
cache utilizando um buffer em volta da posi¸c˜ao da cˆamera. Na seq¨uˆencia, processa
os resultados das consultas para obter os objetos que ser˜ao inclu´ıdos ou exclu´ıdos
do grafo de cena, realizando a atualiza¸c˜ao do grafo de cena do modelo.
Como resultado dos procedimentos realizados nesta camada, obt´em um grafo
de cena estruturado que ´e utilizado para a visualiza¸c˜ao da cena na camada de
apresenta¸c˜ao. Na Figura 4.8, observa-se como est´a estruturado o grafo de cena
desenvolvido neste trabalho, nele se encontra o n´o raiz que tem como n´os filhos
trˆes n´os de agrupamento. Um para cada grupo de entidades espaciais contidas no
banco de dados (Street, Square e Lot). Por fim, a esses n´os est˜ao ligados os n´os
que armazenam os objetos 3D ou desenhos das geometrias.
Esta camada ´e composta pelos seguintes m´odulos: acesso ao banco de dados
espacial, manipula¸c˜ao e carga dos objetos 3D.
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 58
Figura 4.8: Grafo de cena do modelo
O m´odulo de acesso ao banco de dados espacial ´e a interface respons´avel por
conectar a aplica¸c˜ao ao banco de dados, atrav´es de uma referˆencia `a instˆancia do
objeto de conex˜ao `a base de dados, permitindo que os dados geogr´aficos sejam
reconhecidos e utilizados na mesma. Foi criada uma classe gen´erica de acesso
ao banco de dados com todos os m´etodos necess´arios `a intera¸c˜ao da aplica¸c˜ao
com a base de dados geogr´aficos. Como citado anteriormente, foi utilizada a
extens˜ao espacial do Oracle, atrav´es da biblioteca OCCI
1
(Oracle 2007) onde
est˜ao definidos m´etodos espec´ıficos para acesso aos dados espaciais desse SGBD.
Mas com a estrutura de classes desenvolvida torna f´acil a extens˜ao para usar
outros SGBDs espaciais que sejam compat´ıveis com o padr˜ao Open Geospatial
(OGC 2007).
O m´odulo de manipula¸c˜ao do grafo de cena ´e respons´avel por construir e
atualizar o grafo da cena, baseado nos dados fornecidos pela camada de acesso
aos dados, e tratar os eventos enviados pela camada de apresenta¸c˜ao, realizando
as transforma¸c˜oes geom´etricas (transla¸c˜ao e rota¸c˜ao) sobre a cˆamera utilizando
uma estrat´egia de cache baseada em um buffer em volta da cˆamera. Atrav´es
1
Oracle C++ Call Interface - Interface de Chamadas Oracle para linguagem de programa¸c˜ao
C++.
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 59
desta estrat´egia ´e permitido selecionar os objetos que est˜ao a certa distˆancia do
observador, os quais ser˜ao adicionados ao grafo.
J´a o m´odulo de carga dos objetos 3D realiza a inser¸c˜ao ou descarte de objetos
3D no grafo de cena, sendo verificado a cada inser¸c˜ao se os objetos que est˜ao
no buffer consultado j´a est˜ao ou n˜ao no grafo. Em caso afirmativo eles ser˜ao
desconsiderados, caso contr´ario, ser˜ao inseridos no grafo. Com essa checagem
impede-se a redundˆancia na carga de objetos.
4.2.3 Camada de Dados
A camada de dados ´e representada por uma instˆancia de um banco de dados
espacial, denominada de fonte de dados, bem como um conjunto de arquivos
armazenados em disco dos objetos 3D modelados. Essa camada ´e a respons´avel
pela independˆencia de bancos de dados na manipula¸c˜ao de dados geogr´aficos.
Como se tem a camada de dados implementada como estrutura de classes de forma
isolada, apesar de utilizar o Oracle Spatial, a arquitetura pode ser estendida para
lidar com diferentes fontes de dados, por exemplo, Postgresql, MySQL e IBM
DB2. Para o desenvolvimento deste trabalho optou-se pela utiliza¸c˜ao do Oracle
pelas vantagens descritas anteriormente.
A base de dados ´e composta por um conjunto espec´ıfico de tabelas para a
representa¸c˜ao dos dados geogr´aficos no SGBD. O esquema de dados foi constru´ıdo
levando em considera¸c˜ao o relacionamento das entidades espaciais e n˜ao-espaciais
que representam o espa¸co urbano modelado. Todas as tabelas com atributos
espaciais (SEGMENT, SQUARE e LOT ) tˆem os campos chamados Geometry
e Path. Este ´ultimo utilizado para guardar a referˆencia para os objetos 3D
(constru¸c˜oes arquitetˆonicas) em disco, enquanto que o primeiro armazena a
geometria bidimensional da entidade espacial.
´
E necess´aria tamb´em a defini¸c˜ao
das tabelas n˜ao-espaciais STREET e SEGMENT STREET, sendo a primeira
utilizada para armazenar os c´odigos e nomes de cada rua, e a segunda para
materializar o relacionamento N-N entre as tabelas SEGMENT e SQUARE. A
partir do relacionamento da tabela STREET com as tabelas SEGMENT e LOT,
´e poss´ıvel realizar consultas para se identificar, por exemplo, todos os lotes que
pertencem a uma determinada rua, ou ent˜ao, a partir de um dado segmento de
rua obtˆem-se todos os lotes por onde passa a rua a qual este segmento pertence.
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 60
A Figura 4.9 mostra o diagrama do esquema de dados desenvolvido para este
trabalho.
Figura 4.9: Modelo de dados desenvolvido
As informa¸c˜oes n˜ao-espaciais, a exemplo de conte´udo informativo sobre os
monumentos hist´oricos, podem ser armazenadas em outras tabelas que devem
ser relacionadas com as tabelas com atributos espaciais (SEGMENT, SQUARE
e LOT ), tornando poss´ıvel a associa¸c˜ao de todo o tipo de informa¸c˜ao sobre os
monumentos.
Vale ressaltar que os objetos 3D que s˜ao visualizados na aplica¸c˜ao n˜ao
s˜ao armazenados no banco, mas somente uma referˆencia para eles. Estes
s˜ao armazenados em disco com uma nomenclatura padronizada, onde o nome
do arquivo dever´a ser composto pelo nome da classe de objetos (SEGMENT,
SQUARE e LOT ), concatenado com os valores que comp˜oem as chaves de cada
tabela mais a extens˜ao do arquivo. Por exemplo, tem-se o arquivo lot1 66 3.3DS
que ´e um lote da quadra de c´odigo 1, como c´odigo do lote 66 e o c´odigo 3 que
identifica a respectiva rua.
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 61
4.3 Prot´otipo Desenvolvido - RevVir
O RevVir ´e o nome da aplica¸c˜ao desenvolvida neste trabalho, onde pode-se
observar os reultados do algoritmo proposto sendo executado. Consiste em
um visualizador que al´em de exibir os objetos 3D no ambiente virtual tamb´em
possibilita a exibi¸c˜ao de um conjunto de informa¸c˜oes de cada objeto, bem como
o caminhar dentro do modelo urbano. Nele o usu´ario tem o modo de visualiza¸c˜ao
em primeira pessoa por padr˜ao, mas ´e poss´ıvel ter-se uma vis˜ao panorˆamica de
todo o modelo, entretanto, para este caso n˜ao foram implementadas estrat´egias
de otimiza¸c˜ao. Tamb´em foram desenvolvidos m´etodos de desenho a partir das
geometrias armazenadas no banco, possibilitando com isso a visualiza¸c˜ao de um
mapa 2D de toda a ´area com todas as geometrias armazenadas, como pode ser
visto na Figura 4.10.
Figura 4.10: Ilustra¸c˜ao criada com os m´etodos de desenho a partir das geometrias
no banco de dados
As linhas em amarelo s˜ao as ruas e as verdes, as quadras e lotes presentes nesta
regi˜ao. Neste caso, em vez de utilizar os m´etodos de carga dos objetos 3D, foram
executados os m´etodos de desenho em 2D.
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 62
4.3.1 Aquisi¸c˜ao de Dados
Como referˆencia para a modelagem do ambiente urbano a ser utilizado na
aplica¸c˜ao, foi utilizado como base o centro hist´orico da cidade de S˜ao Lu´ıs, capital
do Estado do Maranh˜ao no Nordeste do Brasil que foi declarada patrimˆonio da
humanidade pela UNESCO. O centro hist´orico ´e composto por 115 quadras, 53
ruas que foram divididas em 205 segmentos de rua e 962 lotes. Cada segmento
de uma rua ´e delimitado pelo cruzamento com as outras ruas. Na Figura 4.11,
podem-se visualizar em azul as ruas da ´area usada como referˆencia para o modelo.
Figura 4.11: Visualiza¸c˜ao do mapa 2D da ´area modela da aplica¸c˜ao
A aquisi¸c˜ao dos dados espaciais utilizados para povoar o banco com os dados
referentes ao centro hist´orico foi feita a partir de um modelo CAD. Ap´os a
constru¸c˜ao da base de dados foi implementada a aplica¸c˜ao respons´avel por
se comunicar com o banco de dados, acessar `a base de dados espacial, fazer
as pesquisas espaciais e com os seus resultados gerar a visualiza¸c˜ao da ´area
georeferenciada e dos modelos 3D.
4.3.2 Modelagem de Objetos 3D
Foi dada prioridade `a modelagem dos objetos em 3D que representam as
quadras e as constru¸c˜oes que s˜ao carregadas no modelo urbano. Dentre estes
foram modeladas 115 cal¸cadas com as dimens˜oes das quadras, 962 pr´edios e as
pra¸cas, al´em disso, 205 segmentos de rua. Totalizando 1282 objetos para serem
visualizados na cena, com 42228 primitivas e 94236 v´ertices.
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 63
Foram feitos testes somente com objetos simplificados para representar
estes volumes. N˜ao foram aplicadas texturas ao modelo. Para a realiza¸c˜ao da
modelagem dos objetos 3D foi utilizado o software 3D Studio Max. A Figura 4.12
mostra a visualiza¸c˜ao de parte dos objetos modelados em duas ´areas distintas do
modelo.
Figura 4.12: Modelos 3D das constru¸c˜oes visualizadas na aplica¸c˜ao
Na Figura 4.13, observa-se os poss´ıveis modos de visualiza¸c˜ao, a forma padr˜ao de
visualiza¸c˜ao no RevVir, enquanto que na Figura 4.14, uma alternativa de vis˜ao
panorˆamica do modelo.
Figura 4.13: Modo de visualiza¸c˜ao em primeira pessoa
4.3.3 Resultados Obtidos
No desenvolvimento do prot´otipo foram realizados alguns testes de desempenho
a cada etapa do trabalho. Inicialmente, sem a implementa¸c˜ao da estrat´egia de
cache de visualiza¸c˜ao, a taxa m´edia de quadros por segundos (fps) ficava em torno
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 64
de 45 fps, pois n˜ao havia nenhuma pol´ıtica de gerenciamento do grafo de cena que
otimizasse o processo, sendo necess´ario carregar todos os 1282 objetos do modelo
antes da visualiza¸c˜ao come¸car. Por conta disso, eram consumidos razo´aveis
recursos de hardware e demandava um maior tempo de pr´e-processamento
antes que se pudesse visualizar a cena. A configura¸c˜ao de hardware onde foram
realizados esses testes foi a seguinte: processador um AMD Athlon 64 3000+ de
1.8 GHz de clock, 1024 MB de mem´oria RAM, placa aceleradora de v´ıdeo NVidia
GeForce FX 5500 de 128 MB, rodando o sistema Operacional Windows XP.
Figura 4.14: Vis˜ao panorˆamica da ´area urbana
Ap´os a inclus˜ao da t´ecnica de cache utilizando o buffer, que limitou o n´umero
de objetos no grafo de cena, a taxa m´edia de quadros por segundos passou
a ser de 68 fps aproximadamente, no hardware citado acima, sendo reduzido
consideravelmente o n´umero de objetos no grafo e o consumo de recursos de
m´aquina. Na Figura 4.15, pode-se verificar a taxa de quadros por segundos em
uma regi˜ao do modelo.
Nos testes que foram registrados, determinou-se uma trajet´oria em que foram
obitidas a taxa de quadros por segundo em alguns pontos desta. Na Figura 4.16,
s˜ao destacados a trajet´oria e os pontos (representados por letras) de conferˆencia
dos fps. O gr´afico da Figura 4.17 mostra os n´umeros que ilustram os testes
realizados, com a varia¸c˜ao m´edia das taxas de quadros por segundos nas duas
situa¸c˜oes. Em azul, a representa¸c˜ao da navega¸c˜ao sem otimiza¸c˜ao, enquanto que
na cor laranja tˆem-se os fps com otimiza¸c˜ao.
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 65
Figura 4.15: Vis˜ao do modelo com a taxa de quadros por segundos
Figura 4.16: Trajet´oria de navega¸c˜ao utilizada para testes
No ponto E, observa-se a menor taxa devido maior n´ıvel de detalhamento, e
tamb´em, por ter uma grande concentra¸c˜ao de constru¸c˜oes. A partir do ponto G,
come¸ca a diminuir o n´umero de pr´edios e a aumentar o fps, sendo que na posi¸c˜ao
I n˜ao h´a pr´edios e a cˆamera est´a direcionada para fora dos limites do modelo
urbano.
Para se chegar a um valor de parˆametro para o tamanho do raio do buffer, foram
realizados alguns testes a fim de garantir um bom desempenho. Na Figura 4.18,
s˜ao mostradas as taxas para tamanhos de raios entre 100 e 300.
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 66
Figura 4.17: Gr´afico de compara¸c˜ao de fps
Figura 4.18: Gr´afico de compara¸c˜ao de fps para diferentes raios do buffer
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 67
Optou-se pela utiliza¸c˜ao do buffer com raio de 200 unidades como valor
padr˜ao, devido a melhor rela¸c˜ao entre performance e representa¸c˜ao aceit´avel de
um modelo urbano. Nos testes realizados com o raio de 100, resultaram em taxas
mais altas, mas com pequena quantidade de objetos, assim como o caso de raio
de 150 unidades. Utilizando os raios com 250 e 300 unidades o fps diminui pouco.
Foram realizados tamb´em testes em duas outras m´aquinas, com as seguintes
configura¸c˜oes: o primeiro, com processador Pentium 4 de 3.0 GHz de clock, 1024
MB de mem´oria RAM, placa aceleradora de v´ıdeo NVidia Ge-Force 6200 de 128
MB. O segundo, com processador AMD Athlon 64 3000+ de 1.8 GHz de clock,
1024 MB de mem´oria RAM e placa aceleradora de v´ıdeo ATI Radeon 9600 Pro
de 256 MB. Ambas as m´aquinas com o sistema Operacional Windows XP. A
primeira obteve a mesma taxa de quadros por segundos obtidos pela m´aquina
citada anteriormente, enquanto que a segunda houve um ganho consider´avel,
atingindo taxas de aproximadamente 200 quadros por segundo. Atribui-se estes
´ultimos resultados `a placa aceleradora de v´ıdeo presente na segunda m´aquina.
Na Figura 4.17 pode-se observar uma vis˜ao da planta do modelo. Nesse caso,
o agrupamento de objetos corresponde aqueles que tˆem alguma intera¸c˜ao com o
buffer com um raio de 200 unidades em torno da posi¸c˜ao da cˆamera.
Figura 4.19: Objetos carregados no cache
CAP
´
ITULO 4. ESTRAT
´
EGIA DE OTIMIZAC¸
˜
AO PARA ACELERAC¸
˜
AO DA
VISUALIZAC¸
˜
AO DE MODELOS VIRTUAIS URBANOS 68
Foram feitos, tamb´em, testes com o banco de dados e a aplica¸c˜ao de visualiza¸c˜ao
em m´aquinas distintas para que fossem observadas poss´ıveis varia¸c˜oes nos
resultados. No entanto, n˜ao foram notadas varia¸c˜oes consider´aveis na taxa de
quadros por segundo.
Cap
´
ıtulo 5
Conclus˜ao
Os modelos virtuais urbanos tˆem sido empregados para v´arios fins. Com
o uso de realidade virtual ´e poss´ıvel realizar passeios tur´ısticos por mundos
virtuais, planejamento urban´ıstico de cidades, sistemas de navega¸c˜ao e localiza¸c˜ao,
entre outros. Por isso, ´e crescente o n´umero de pesquisas relacionadas ao
desenvolvimento de grandes modelos virtuais urbanos. Entretanto, as aplica¸c˜oes
desenvolvidas para esse fim, normalmente necessitam de hardware poderoso e de
alto custo.
Durante o levantamento bibliogr´afico realizado nesta pesquisa, pode-se
observar o emprego de v´arias t´ecnicas para a solu¸c˜ao do problema de visualiza¸c˜ao
de modelos urbanos nos trabalhos relacionados. Alguns destes trabalhos
empregam SGBDs espaciais e concentram-se em t´ecnicas de otimiza¸c˜ao no
rendering, tais como culling e LOD, no entanto, n˜ao foi observada nesses trabalhos
a utiliza¸c˜ao em conjunto de base de dados espaciais, otimiza¸c˜ao no banco de dados
e t´ecnicas de otimiza¸c˜ao na visualiza¸c˜ao neles, necessitando, por isso, do emprego
de hardware de alto desempenho e custo.
O principal objetivo do algoritmo proposto neste trabalho ´e possibilitar a
visualiza¸c˜ao de grandes modelos urbanos em sistemas com restri¸c˜oes de hardware,
sem sacrificar a sensa¸c˜ao de continuidade no deslocamento pelo ambiente virtual.
Al´em disso, incorporar ao ambiente virtual um grupo de informa¸c˜oes contidas
em uma base de dados geogr´afica, propiciando uma interface homem m´aquina.
Possibilitando a utiliza¸c˜ao da arquitetura para a constru¸c˜ao de uma poss´ıvel
interface de intera¸c˜ao com v´arios tipos de informa¸c˜oes multim´ıdia do ambiente
69
CAP
´
ITULO 5. CONCLUS
˜
AO 70
urbano, especialmente interessante para a constru¸c˜ao de aplica¸c˜oes dedicadas
`a populariza¸c˜ao, o ensino e `a preserva¸c˜ao de informa¸c˜ao cultural associado `as
cidades hist´oricas.
Neste trabalho foi desenvolvido um algoritmo de acelera¸c˜ao da visualiza¸c˜ao
de modelos virtuais urbanos, com um cache de objetos que se baseia em
um buffer espacial em banco de dados geogr´aficos, que garante o suporte ao
armazenamento, recupera¸c˜ao e a visualiza¸c˜ao desses modelos urbanos em tempo
real. O algoritmo desenvolvido apresentou um bom desempenho, baseado em
opera¸c˜oes realizadas no banco de dados, atrav´es de ´ındices, operadores e fun¸c˜oes
espaciais, que foram utilizados para implementar a estrat´egia de cache, que
possibilita consultas eficientes dos objetos que devem ser mantidos ou removidos
do cache. Com disso, obteve-se um gerenciamento mais eficaz do grafo de cena,
com a simplifica¸c˜ao e redu¸c˜ao de tamanho deste, possibilitando a execu¸c˜ao da
aplica¸c˜ao desenvolvida sobre uma plataforma de hardware convencional em termos
de recursos computacionais.
Os resultados obtidos podem ser considerados satisfat´orios devido ao
desempenho m´edio conseguido durante os testes, onde se mantiveram aceit´aveis
taxas de quadros por segundo durante o caminhar por dentro do modelo urbano.
Entretanto, houve redu¸c˜oes mais acentuadas na taxa de atualiza¸c˜ao em ´areas
do modelo com alta concentra¸c˜ao de objetos, ou ent˜ao quando estes tinham um
maior n´ıvel de detalhes. N˜ao foram aplicadas texturas nestes objetos, j´a que
n˜ao foi implementada nem uma otimiza¸c˜ao para a utiliza¸c˜ao das mesmas. Foram
realizados testes com o SGBD instalado local e remotamente, entretanto, n˜ao
foram percebidas grandes diferen¸cas no desempenho, j´a que o servidor estava
presente em uma rede local.
Como trabalho futuro, pretende-se estender a arquitetura, incorporando outras
t´ecnicas de otimiza¸c˜ao a fim de aumentar a eficiˆencia e usabilidade do sistema
(LOD e prefetch), e tamb´em expandir o m´odulo de acesso a banco de dados para
possibilitar acesso a fontes de dados em outros SGBD’s espaciais. Al´em disso,
empregar a utiliza¸c˜ao de modelos digitais de terreno (DEM) para a visualiza¸c˜ao
do relevo, levando em considera¸c˜ao dados de eleva¸c˜ao de terreno para a gera¸c˜ao
de superf´ıcies mais fi´eis a realidade. Pretende-se ainda, desenvolver estrat´egias
de otimiza¸c˜ao para a visualiza¸c˜ao panorˆamica tamb´em. Finalmente, pretende-se
CAP
´
ITULO 5. CONCLUS
˜
AO 71
incorporar textura aos objetos que representam as constru¸c˜oes arquitetˆonicas a
fim de tornar mais agrad´avel e realista a navega¸c˜ao no modelo, e se for o caso,
desenvolver algoritmos de otimiza¸c˜ao no gerenciamento de mem´oria utilizada para
o mapeamento dessas texturas. Com isso, permitir a constru¸c˜ao de uma biblioteca
digital multim´ıdia de ´areas urbanas de interesse do patrimˆonio hist´orico cultural.
Referˆencias Bibliogr´aficas
Alliez, P., M. Meyer and M. Desbrun (2002). Interactive Geometry Remeshing.
SIGGRAPH 2002 conference proceedings pp. 347–354.
AutoDesk (2008). Autodesk. Dispon´ıvel em http://usa.autodesk.com.
Campos, Samuel R. S., Adriana Z. Martinhago, Thomas C. de A. Oliveira, Luca
Ara´ujo Egas Prieto, Ronaldo A. Silva, Aleksander M. Fran¸ca and Ivayr
D. F. Netto (2007). Integra¸c˜ao do Sgbd Oracle Spatial e do Google Earth
para disponibilizar informa¸c˜oes relacionadas ao Invent´ario Florestal de Minas
Gerais. IX Brazilian Symposium on GeoInformatics pp. 227–232.
Casanova, M., G. Cˆamara, C. Davis, L. Vinhas and G.R. Queiroz (2005). Bancos
de Dados Geogr´aficos. MundoGEO. Curitiba, Brasil.
Clua, Esteban W. G (2004). Impostores com Relevo. Master’s thesis. PUC Rio.
Coutinho, Bruno Barcellos S., Gilson Antˆonio Giraldi, Antˆonio
L. Apolin´ario Jr. and Paulo S´ergio S. Rodrigues (2007).
Um Modelo de Simula¸c˜ao para Escoamento Superficial de
´
Aguas sobre Terrenos Baseado em GPU. Dispon´ıvel em
http://arquivosweb.lncc.br/pdfs/GPU%20Flow%20Simulation.pdf.
D¨ollner, J., H. Buchholz, Nienhaus and F. M., Kirsch (2005). Illustrative
Visualization of 3D City Models. Proceedings of Visualization and Data
Analysis 2005 (Electronic Imaging 2005,SPIE Proceedings) pp. 42–51.
Duran, Z. and G. Toz (2001). Obtaining 3D Information of Historical Monuments
by Means of Photogrammetry. Proceedings of Fourth International
Symposium - Turkish-German Joint Geodetic Days 1, 277–285.
72
REFER
ˆ
ENCIAS BIBLIOGR
´
AFICAS 73
Funkhouser, T. A., C. H. Sequin and S. J. Teller (1992). Management of Large
Amounts of Data in Interactive Building Walkthroughs. Computer Graphics
(1992 Symposium on Interactive 3D Graphics) 25, 11–20.
Hamill, J. and C. O’Sullivan (2003). Virtual dublin - a Framework for Real-Time
Urban Simulation. Journal of WSCG 11, 221–225.
Havemann, S. and D. Fellne (2005). A Versatile 3D Model
Representation for Cultural Reconstruction. Dispon´ıvel em
http://citeseer.ist.psu.edu/543956.html.
Kothuri, R., S. Ravada and D. Abugov. (2002). Quadtree and R-tree Indexes in
Oracle Spatial: A Comparison using GIS Data. ACM SIGMOD 2002 pp. 546–
557.
Murray, C. (2002). Oracle Spatial User’s Guide and
Reference Release 9.2. Dispon´ıvel em http://download-
uk.oracle.com/docs/cd/B10501 01/appdev.920/a96630.pdf.
Murray, C. (2003). Oracle Spatial User’s Guide and
Reference 10g Release 1 (10.1). Dispon´ıvel em
http://www.oracle.com/technology/products/spatial/pdf/qt.pdf.
MySQL (2006). Manual de Referˆencia do MySQL 4.1.. Dispon´ıvel em
http://dev.mysql.com/doc/refman/4.1/pt/index.html.
Netto, A.V., J.G. Denipote and P. S. H. Cateriano (2005). Interface 3D para
Manipula¸c˜ao de Dados em Redes de Distribui¸c˜ao de Energia El´etrica. Revista
Infocomp 4(4), 73–81.
OGC (2007). Open Geospatial Consortium. Dispon´ıvel em
http://www.opengeospatial.org.
Oliveira, Thomaz C. A., Samuel R. S. Campos, Luca A. E. Pietro and
Elias B. C. Lasmar (2007). Indexa¸c˜ao dos Dados Espaciais do Banco de
Dados do Invent´ario de Minas Gerais. Anais XIII Simp´osio Brasileiro de
Sensoriamento Remoto pp. 5973–5981.
REFER
ˆ
ENCIAS BIBLIOGR
´
AFICAS 74
OpenAL (2006). Openal Cross-Platform 3D Audio. Dispon´ıvel em
http://www.openal.org.
OpenGL (2006). Opengl the Industry’s Foundation for High Performance
Graphics. Dispon´ıvel em http://www.opengl.org.
Oracle (2005). Oracle Spatial User’s Guide and
Reference 10g Release 2. Dispon´ıvel em
http://youngcow.net/doc/oracle10g/appdev.102/b14255/toc.htm.
Oracle (2007). Oracle c++ call interface. Dispon´ıvel em
http://www.oracle.com/technology/tech/oci/occi/index.html.
Osfield, R. and D. Burns (2006). Openscenegraph. Dispon´ıvel em
http://www.openscenegraph.org.
Porto, F.A.M., J.C. Oliveira and E.S. Coutinho (2004). Algoritmo de Oclus˜ao para
Tratamento de Objetos em um SIG 3D. Technical report. Instituto Militar
de Engenharia - Departamento de Engenharia de Sistemas.
PostGIS (2007). Postgis manual. Dispon´ıvel em http://postgis.refractions.net.
Reiners, Dirk (2002). Scene Graph Rendering. Dispon´ıvel em
http://oldsite.vrjuggler.org/pub/scenegraph-rendering.ieeevr2002.pdf.
Schilling, Arne and Alexander Zipf (2003). Generation of VRML City Models for
Focus Based Tour Animations. pp. 347–354.
Schneider, M. (1997). Spatial Data Types for Database Systems. Technical report.
Springer-Verlag. Berlin Hidelberg.
Sharma, J. (2001). Oracle Spatial: an Oracle Technical white paper. Dispon´ıvel
em http://www.oracle.com.
Silva, Rosˆangela (2002). Bancos de dados geogr´aficos: Uma An´alise das
Arquiteturas Dual (Spring) e Integrada (Oracle Spatial). Master’s thesis.
Escola Polit´ecnica da Universidade de S˜ao Paulo.
Sola, J., P. H. Cateriano and A. V. Netto (2005). Processo de Rendering para
Sistema 3D Interativo Utilizando Grafos de Cena. REIC ANO V.
REFER
ˆ
ENCIAS BIBLIOGR
´
AFICAS 75
Tenenbaum, A. M., Y. Langsam and Moshe J. Augenstein (1995). Estruturas de
Dados Usando C. MAKRON Books.
Tortelli, D. M. and M. Walter (2007). Implementa¸c˜ao da T´ecnica de Displacement
Mapping em Hardware Gr´afico. SBGames 2007 - VI Brazilian Symposium
on Computer Games and Digital Entertainment.
USDI (2007). U. S. Geological Survey. U.S. Department of the Interior. Dispon´ıvel
em http://erg.usgs.gov/isb/pubs/gis poster/index.html.
Valente, L. (2004). Representa¸c˜ao de Cenas Tridimensionais: Grafo de Cenas.
Technical report. Universidade Federal Fluminense. Niter´oi, Brasil.
VRML (2005). VRML Virtual Reality Modeling Languagem. Dispon´ıvel em
http://www.w3.org/MarkUp/VRML/.
Watson, B., N. Walker, L. Hodges and A. Worden (1996). Effectiveness of
Peripheral Level of Detail Degradation when used with Head-mounted
Displays. Technical report. Graphics, Visualization and Usability (GVU)
Center, Georgia Institute of Technology.
Weinberger, J. (2002). The Spatial RDBMS in the
Enterprise. Directions Magazine. Dispon´ıvel em
http://www.directionsmag.com/article.php?article id=259&trv=1.
Wilmott, J., L.I. Wright, D.B. Arnold and A.M. Day (2001). Rendering of Large
and Complex Urban Environments for Real-time Heritage Reconstructions.
ACM Press pp. 111–120.
Zeev, Avi Bar (2003). Scenegraphs: Past, Present and Future. Dispon´ıvel em
http://www.realityprime.com/scenegraph.php.
Ap
ˆ
endice A
Artigo Cient´ıfico Publicado
Architecture Based on Virtual Reality Techniques and
Geographic Data Base for Storage and Visualization of
Urban Virtual Models
R.S. Serr˜ao
Universidade Federal do Maranh˜ao, S˜ao Lu´ıs, MA, Brasil
A.C. Paiva
Universidade Federal do Maranh˜ao, S˜ao Lu´ıs, MA, Brasil
ABSTRACT: Virtual Reality systems have been used in diverse areas in
recent years presenting numerous benefits. One class of such systems deal
with urban virtual models manipulation and visualization, that can be used
for urban planning, architectural visualization and games. This paper presents
conception and development of a software architecture based on geographical
database that supports storage, recovery and real time visualization of urban
virtual models. The proposed architecture makes intensive use of geographical
databases technology to develop algorithms for these operations performance
optimization. The cache strategy lead to a good performance of navigation in
virtual urban models. We built an urban virtual model based on the historical
center of S˜ao Lu´ıs to test the proposed architecture.
1 INTRODUCTION
One of areas that has been widely used Virtual Reality (VR) technology is the
76
AP
ˆ
ENDICE A. ARTIGO CIENT
´
IFICO PUBLICADO 77
urban environment modeling, that makes possible the realistic reconstruction of
places in the world beyond the insertion of tools for its interactive visualization and
simulation of diverse possible situations to happen in the real world. Moreover,
the previous construction of virtual urban environment, simulating real urban
environments, also it has been carried out in order to foresee and to prevent
problems.
The urban virtual models have been widely used as interfaces for information
systems. The VR makes possible the construction of sufficiently interactive models
and the association of other components as data base, Web pages and multimedia
components. Furthermore, it favors intuitive use as information repository, being
useful in virtual environments on tourism, art and culture, urban planning,
navigation systems, mechanical and structural tests, environmental and visual
impact, meteorology, among much others. For example, streets, quarters and,
even though, cities can be constructed and to divulge by Web for the virtual
tourism.
Another important aspect that can be explored by urban virtual models
construction is the preservation area of historic patrimony. Thus, we can use
these urban models as tool for the scientific documentation of urban areas of
historical interest, and also for the virtual reconstruction of monuments or not
preserved or partially preserved regions. Some initiatives, aiming at to the
scientific documentation of urban patrimony in digital way, have been developed
around of the world. The Conference of the VSMM (Virtual Systems and
Multimedia Society) opened, from 1998, a thematic session about virtual reality
techniques applied to historic patrimony, as well as the Seminary of the SIGraDi
(Latin American Digital Graphical society), from 1999, it started to include a
session about “Digital Patrimony/ Digital Heritage”. In 1996, deriving of VSMM
Society, the Virtual Heritage Network was created (net for studies dissemination
about the virtual patrimony). In 2002, UNESCO promoted a series of conferences
to celebrate 30o anniversary of Convention for Protection of the Humanity
Patrimony. The conference, occurred in Alexandria, exactly dealt with systems
of geographic and multimedia information applied to historic patrimony (Paraizo
et al. 2003). Consequently, we can observe the growth of virtual models use of
historic patrimony areas with intention to catalogue and to preserve data about
AP
ˆ
ENDICE A. ARTIGO CIENT
´
IFICO PUBLICADO 78
these historical monuments.
This work considers to the conception and development of a software
architecture based on geographic data base that gives support to the storage,
recovery and visualization of urban virtual models in real time, prioritizing the
implementation of algorithms of optimization and strategies of cache that makes
possible the navigation in urban models of wide scale. It was used a urban
model constructed ad hoc from a map of S˜ao Lu´ıs historical center, tumbled
as humanity’s historical patrimony.
2 RELATED WORKS
The use of Virtual Reality in construction of great urban models in set with
information systems can serve as an important vehicle of information. Thus,
appearing plus a media alternative that contributes for the preservation and the
spreading of the historic patrimony. Therefore, there is necessity of a visualization
program of urban models that be efficient and be associated with a geographic
data base. In this way, the visualization transforms into an excellent interface
metaphorfor analysis of data on database.
In (Wilmott et al. 2001) is described a package that brings a set of
rendering and optimization techniques for great and complex urban environment
visualization with rates of interactive pictures for second. The package was
constructed based on a structure of proprietor Scene Graph developed for
CHARISMATIC project (Havemann et al. 2005). The article presents the
combination of Real-time Optionally Adaptation Meshes (ROAM), View Frustum
Culling, Occlusion Culling and Levels of Detail (LOD) for the constructions in an
single application with objective to obtain a walk in real-time in virtual model. As
result, a comparison of pictures averages for second in walk of composed model
of 544.002 polygons is presented, being that, without the use of optimization
techniques it has obtained a rate of 1,6 frame per seconds (fps), whereas with the
use of them it was gotten a rate of 35,54 fps.
A system of urban simulation that has as objective to create a large-scale
imersive simulation of Dublin city is described in (Hamill et al. 2005). The
navigation through environment is made in first person giving freedom for the
user to go where to desire. As practically all constructions of the city had been
enclosed, it was used LOD, Discarding for Occlusion and an algorithm of textures
AP
ˆ
ENDICE A. ARTIGO CIENT
´
IFICO PUBLICADO 79
management to optimize the system. The system was developed from a CAD
model with OpenGL and OpenAL libraries (OpenGL et al. 2006), the last one
for sound. The models used to simulate the constructions had been made with
3D Studio Max (AutoDesk et al. 2006), have, on average, 500 polygons, use
approximately 1 MB of texture each, being that the greater has 13500 polygons
and 6 MB of textures. The load and position of the models in the environment
are controlled by a simple archive text. Ahead of this, the frame rate is between
25 and 60 fps, depending on the complexity of the current scene.
In (Netto et al. 2005) is presented the development of a 3D graphical
interface using the virtual environments technology with the objective of assisting
the decision taking in a computational system for reduction of losses in nets
of distribution of electric energy. This 3D interface was constructed for the
visualization of a great amount of data in a distribution system, with great carriage
nets, beyond facilitating to interpretation (evaluation) of proposals solutions for
the system and to allow an easy modification of the system of distribution with
objective of planning these nets. In this work, it was created a SIG capable of
contemplating the biggest number of information, linked to georeferencement ,
where it had the necessity of innumerable data storage and information about the
net load of electric energy distribution, such as pole tension, substation and the
feeders of energy capacity; substation and poles localization and positioning data
in relation to city; information about different poles, handles and keys of found
opening and closing types on electric net, etc. To give support to this great volume
of information was necessary to use a spatial data base. The model construction
was based on a 2D map in CAD format and aerial images of S˜ao Carlos city (SP).
From the 2D map was generated the three-dimensional map. In this article the
use of optimization techniquesof rendering and visualization process had not been
cited.
The work (Porto et al. 2004) approaches the recovery problem of three-
dimensional object models in DBMS Relational-Object, searching to optimize
it with use of an occlusion algorithm developed specifically for this system. The
work inserts it in a bigger development context of a support complete system to
recovery and exhibition of 3D objects in AVC (Ambientes Virtuais Colaborativos)
and SIG-3D applications. However, real geographic data were not used and nor it
AP
ˆ
ENDICE A. ARTIGO CIENT
´
IFICO PUBLICADO 80
was constructed a visualization module, being generated exit archives in AutoLIPS
for visualization in AutoCAD.
In the cited examples it can be observed that although the good results
presented in relation to the performance, in the two first works, the models do
not incorporate a geographic data base on its architecture and therefore it does
not present a practical way to add useful information regarding the constructions
that compose the model all. Already the third article implements SIG but it does
not approach optimization techniques in relation to rendering and visualization.
The fouth article presents optimization techniques in DBMS Object-Relational,
but do not use data of an extensive area for tests.
3 INVOLVED TECHNOLOGIES
In this section, we present the technologies involved in development of the model
and construction of the archetype. All the work was developed in C++ in set
with OpenSceneGraph (OSG) graphical library (Osfield & Burns et al. 2006),
using DBMS Oracle for the storage of the database (Oracle et al. 2006).
In the development of this work, it was decided to use the OSG because it offer
a complete package with great part of what it can wait of a scene graph. It brings
implemented some important optimizations for a program that works with great
models. OSG is a graphical library with opened code, independent of platform,
writing in the programming language C++ on the graphical library OpenGL.
The OSG possess various constructed optimizations, among them it can be
cited the following ones: view-frustum culling, occlusion culling, techniques of
reduction of exchanges of states of the OpenGL (lazy-state-change), occlusion
plan, discarding of small objects, support in detail levels, support to diverse types
of archives.
As DBMS, we used the Oracle Spatial that is a spatial extension developed
on the Relational-object model of DBMS Oracle. This extension is based on
specifications of OpenGIS and contains a set of functionalities and procedures that
allows to store, to have access, to modify and to consult spatial data of vectorial
representation. The Oracle Spatial is formed by the following components
(Casanova, M. et al. 2005):
• A proper model of data called MDSYS that defines storage form, syntax
and semantics of supported spatial types;
AP
ˆ
ENDICE A. ARTIGO CIENT
´
IFICO PUBLICADO 81
• Mechanism of spatial indexation;
• A set of operators and functions to represent consultations, spatial junction
and other operations of spatais analysis;
• Applications administrative.
The data model of Oracle Spatial consists of a elements hierarchic structure,
geometries and plans of information (layers). Each plan is formed by a set
of geometries, that in turn are formed by a set of elements. Each element is
associated with a primitive spatial type, as point, line or polygon (with or without
islands).
The bidimensional spatial types are composed by points formed for two
commanded X and Y, frequently corresponding to longitude and latitude.
The extension also supports storage and indexation of three-dimensional and
tetradimensionais types, but the functions and operators just function for the
bidimensional types. A geometry can be formed by an only element, or by
a homogeneous set (multipoints, multilines or multipolygons) or heterogeneous
(collection) of elements. An information plan is formed by a geometries collection
that possess the same set of attributes.
Based on Relational-object model, the Spatial defines a type of object, to
represent spatial data to be manipulated, call SDO GEOMETRY. This object
contains geometry in itself, coordinates, e information about its type and
projection. In a spatial table, the geometry alphanumeric attributes are defined as
columns of basic types (VARCHAR2, NUMBER, IT DATES, amongst others), e
geometry as a column of SDO GEOMETRY type. In spatial table, each instance
of the spatial data is stored in a line, and the set of all instances of this table
forms an information plan.
For the development of this work, we opted to the spatial extension of the
DBMS Relational-Object Oracle for having gratuitous license for not commercial
use; for the robustness of the tool and extensive documentation.
4 ARCHITECTURE PROPOSAL
The architecture (Fig. 1) proposal is based on three layers, where we have the
data presentation layer, the application layer, the it lodges the system logic and
finally the data layer.
AP
ˆ
ENDICE A. ARTIGO CIENT
´
IFICO PUBLICADO 82
Figura A.1: General view of the architecture
The data layer is represented by an instance of a special data base, called of data
source. Our architecture can deal with different sources of data, for example,
Oracle, Postgresql and IBM DB2. This layer is responsible for independence of
data bases in manipulation of geographic data.
The database is composed by a specific set of tables for representation of
geographic data in the DBMS. The data project was constructed taking in
consideration the relationship of the spatial and not-spatial entities that represent
the shaped urban space. All the tables with spatial attributes (SEGMENT,
SQUARE and LOT) have the fields called Geometry and Path, this used to keep
the path in disk of 3D objects whereas that one stores the geometry of the spatial
entity. It was also necessary the definition of not-spatial tables STREET and
SEGMENT STREET, being the first one used to store the codes and names of
each street, and second to materialize the relationship between SEGMENTS and
SQUARE tables. In Figure 2, the diagram of the data project is presented. It
must to stand out that the 3D objects, which are visualized on application, are
not stored in the bank, e yes in record with standardized name that is composed
by the object class’s name concatenated with the values that composes the keys
of each table plus the archive extension, for example, lot1 66 3.3DS, that it is a
lot of square of code 1, as code of 66 lot and code 3 that identifies the respective
street.
The application layer is responsible for the logic business. It receives and treats the
repassed events through the interface, it carries out the spatial transformations on
the camera, from it are made spatial consultations and scene graph manipulation
of the model (Fig. 3), formatting it for to be rendered and visualized in the
AP
ˆ
ENDICE A. ARTIGO CIENT
´
IFICO PUBLICADO 83
Figura A.2: Data model
presentation layer. This layer is composed for the following modules: of access to
the spatial data base, of manipulation and the structure management module of
the scene graph.
The access module to the spatial data base is the responsible interface for
connecting the application to data base, allowing that geographic data being
recognized and used in the same one.
The manipulation module is responsible for dealing with the events sent by
presentation layer, to carry out the geometric transformations (translation and
rotation) on the camera and to implement a strategy of pre-cache based on a
buffer involving the camera, that allows to select objects to a certain distance of
observer that will be added to the graph. A circular buffer involving the camera,
that has parameterized ray, was adopted, opting it to this form instead of one
triangular forms in order to minimize the number of insertions and object removals
in the graph, not being necessary to modify the structure when the camera will
be turned quickly.
To get the object list that is loaded or discarded of the scene graph is made
the intersection of the area contained in the buffer with the geometries contained
in spatial tables. From the first displacement of camera is made the difference
between the current buffer and the previous buffer in order to get the area that
makes intersection with new objects to be loaded, e also the area that contains
the objects that will have to be unloaded. With this, it is not necessary making
the intersection of spatial tables with allarea of the buffer, but only with the
resultant areas of the differences. This procedure is clearly shown at Figure 3,
where the resultant areas of this operation are represented the displacement of
AP
ˆ
ENDICE A. ARTIGO CIENT
´
IFICO PUBLICADO 84
the camera of the point A to point B is shown, being that area in gray involves
all objects to be discarded, already the objects that are in the intersection area
are kept and those that are inside of the clear yellow area will be enclosed in the
graph.
Figura A.3: Areas covered for buffers
Moreover, the management module of scene graph that carries out the insertion
or discarding of objects of scene graph, it verifies to each insertion if the objects
that are in the current buffer are not in the graph, hindering the redundancy in
the object load. These operations with sptial tables are carried out through the
operators implemented in space DBMS.
Figura A.4: Graph scene of model
In the presentation layer, we meet the visualization module that is responsible
for exhibition of scene generated from the graph. It also shows, in a window,
some informations about each graph node as mouse’s cursor goes by them.
The interface between user and application only give it for mouse, whereas
when dragging pressuring the right button it applies to the camera a horizontal
AP
ˆ
ENDICE A. ARTIGO CIENT
´
IFICO PUBLICADO 85
displacement in all the directions.
Initially, the objects of a predetermined localization are loaded and from the first
movement of camera is executed the tasks flow illustrated in Figure 5.
Figura A.5: Imagem com as informa¸c˜oes do objeto 3D sendo exibidas
1. User moves the mouse;
2. Treatment of mouse’s event, in this case, pressuring and dragging the right
button to carry out a translation;
3. Call of method that calculates the new position of the camera;
4. Executed the method of removal of objects;
5. The objects, to be removed, are consulted in the bank according with the
buffer;
6. Removed objects return;
7. Executed the load method of objects;
8. The objects, to be added in the graph, are consulted in the bank according
with the buffer;
9. Added objects return;
10. Brought up to date graph and renderized scene.
AP
ˆ
ENDICE A. ARTIGO CIENT
´
IFICO PUBLICADO 86
5 ARCHETYPE (RevVir)
The RevVir is an archetype developed to make possible the use of proposal
architecture. It consists of a viewer that beyond showing 3D objects in virtual
environment also makes possible to show a set of information of each object.
Also methods of drawing from the geometries stored in the bank had been
implemented.
5.1 Acquisition of Data
As reference for the modeling of urban environment, the historical center of S˜ao
Lu´ıs city, composed for 115 squares, 53 streets that had been divided in 205
segments of street and 962 lots. From a CAD model it was made to acquisition
of the spatial data used to populate the bank with the data referring to the
historical center. After the construction of the database it was implemented the
responsible application for to communicate with the data base, to access the
spatial data base, to make spatial research and, with its results, to generate the
visualization of the georeferenciated area and the 3D models. Figure 4 shows to
a 2D view of the region.
Figura A.6: Visualization 2D from the application
5.2 Object modeling 3D
Priority was given to the 3D objects modeling that represent squares and
constructions loaded in the urban model. Amongst these 115 sidewalks of
square, 400 buildings and the squares had been shaped . Initially tests had
been made only with simplified objects to represent these volumes. For the
accomplishment of 3D objects modeling is being used the tool 3D Studio Max.
AP
ˆ
ENDICE A. ARTIGO CIENT
´
IFICO PUBLICADO 87
The following Figures 7-8 show the current period of visualization implemented
in the application.
Figura A.7: Objects 3D (a)
Figura A.8: Objects 3D (b)
5.3 Results
In archetype development, some performance tests to each stage of the work
had been carried through. Initially, without the implementation of visualization
cache, the rate of pictures per seconds was around 19 the 30, because it have none
management politic of scene graph , being necessary to load all objects before the
visualization starting, what it consumed reasonable hardware resources. After
the inclusion of cache technique, that limited the objects number in scene graph,
AP
ˆ
ENDICE A. ARTIGO CIENT
´
IFICO PUBLICADO 88
the rate of pictures per seconds kept it between 30 and 60, reducing considerably
the objects number in graph and the consumption of machine resources. In
Figure 9, we can observe the objects grouping that are inside of a ray of 200
units around the position of the camera.
Figura A.9: Loaded objects in cache
6 CONCLUSION
In this work an architecture of software was presented based on geographic data
base that propose to give support to the storage, recovery and visualization of
urban virtual models in real time, using an performance optimization algorithm
based on operations carried out in the spatial data base and a more efficient
management of scene graph.
The proposal architecture aims at to make possible the visualization of
great urban models in systems with restrictions of hardware without sacrificing
the sensation of continuity on displacement through the virtual environment.
Moreover, a group of information contained in a database is incorporated to virtual
environment, propitiating an interesting interface man machine.
As future works, we intended to extend the architecture still more,
incorporating others optimization techniques, as multiresolution and
multitrheads, in order to increase the efficiency and usability of system.
Moreover, it is intended to extend the data sources to make possible the
construction of access modules to other spatial DBMSs.
7 REFERENCES
AutoDesk, http://usa.autodesk.com, January 2006.
Casanova, M., Cˆamara, G., Davis, C., Vinhas, L. & Queiroz, G.R. 2005.
AP
ˆ
ENDICE A. ARTIGO CIENT
´
IFICO PUBLICADO 89
Bancos de Dados Geogr´aficos. Curitiba: MundoGEO.
Hamill, J. & O
´
Sullivan, C. 2003. Virtual Dublin A Framework for Real-Time
Urban Simulation. Journal of WSCG 11: 221-225.
Havemann, S. & Fellner, D.W. 2001. A versatile 3D Model Representation for
Cultural Reconstruction. ACM Press: 205-212.
Netto, A.V., Denipote, J.G. & Cateriano, P. S.H. 2005. Interface 3D para
manipula¸c˜ao de dados em redes de distribui¸c˜ao de energia el´etrica. Infocomp. 4:
73-81.
OpenGL The Industry’s Foundation for High Performance Graphics,
http://www.opengl.org, September 2006.
Oracle Spatial, Oracle, Document Reference Manual,
http://www.oracle.com/technology/products/spatial, March 2006.
Osfield, R. & Burns, D. OpenSceneGraph, http://www.openscenegraph.org,
March 2006.
Paraizo, R.C. 2003. A representa¸c˜ao do Patrimˆonio Urbano em
hiperdocumentos: um estudo sobre o Pal´acio Monroe. Rio de Janeiro:
Universidade Federal do Rio de Janeiro.
Porto, F.A.M., Oliveira, J.C. & Coutinho, E.S. 2004. Algoritmo de oclus˜ao
para tratamento de objetos em um SIG 3D. Rio de Janeiro: Instituto Militar de
Engenharia.
Wilmott, J., Wright, L.I., Arnold, D.B. & Day, A.M. 2001. Rendering of Large
and Complex Urban Environments for Real time Heritage Reconstructions. ACM
Press. 111-120.
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
