2. À minha família, aos meus amigos, ao meu país.
A Deus
(e até breve)
2
3. Índice
Introdução...........................................................................................................................................4
História do projeto..............................................................................................................................6
SAT (Montreal): a demanda atual por 3D e ambientes imersivos.............................................7
a escolha do Blender™ como ferramenta de desenvolvimento.................................................8
A racionalização da visão humana na arte e na arquitetura........................................................10
O domo imersivo...............................................................................................................................14
história do surgimento do domo imersivo................................................................................14
domos imersivos com lentes olho de peixe de grande campo visual.......................................16
domos imersivos com espelho esférico....................................................................................19
benefícios do sistema de espelhos esféricos sobre lentes olho de peixe:.................................20
O domo imersivo aplicado à arquitetura........................................................................................22
sistemas de visualização arquitetônica.....................................................................................22
problemas do sistema atual de visualização arquitetônica.......................................................25
a contribuição do domo imersivo para arquitetura e suas aplicações......................................26
possíveis aplicações do domo imersivo em arquitetura............................................................27
Implementação e desenvolvimento do sistema de domo imersivo para a Blender Game Engine
- parte I..............................................................................................................................................28
da planta baixa ao cenário virtual com o Blender™................................................................29
1. integrando programas CAD com o Blender™......................................................................29
2. modelagem virtual.................................................................................................................30
3. integrando o SketchUp com o Blender™.............................................................................32
4. explorando o ambiente virtual...............................................................................................35
Implementação e desenvolvimento do sistema de domo imersivo para a Blender Game Engine
- parte II.............................................................................................................................................36
utilizando GLSL Vertex Shader para reproduzir uma lente olho-de-peixe..............................37
utilizando múltiplo renders remapeados para reproduzir uma lente olho-de-peixe.................38
limitações da câmera em OpenGL e projeções geométricas....................................................38
mapa Cúbico - cubemap...........................................................................................................41
transformando um Mapa Cúbico em uma esfera.....................................................................43
planificando a esfera................................................................................................................44
deformando para usar o espelho...............................................................................................46
3
4. Testes realizados e avaliação dos resultados...................................................................................50
University of British Columbia - Vancouver, Canadá...............................................................50
Societe D'Arts et Technologie - Montreal, Canadá...................................................................51
University of Plymouth - Londres, Inglaterra...........................................................................52
University of Western Australia - Perth, Australia....................................................................54
implementação final..................................................................................................................55
Conclusão do trabalho.....................................................................................................................56
encaminhamentos.....................................................................................................................57
Bibliografia........................................................................................................................................58
Glossário............................................................................................................................................59
Anexos................................................................................................................................................61
Anexo I: carta da Society for Arts and Technology referente ao comprimento do
desenvolvimento do trabalho...................................................................................................62
Anexo II: documento que suporta o método por trás da tecnologia desenvolvida..................63
Anexo III: alterações no script de importação de arquivos OBJ no Blender™.......................65
Anexo IV: código fonte do recurso de domo na Blender Game Engine..................................66
4
5. Introdução
Ver em 3D . . . o que para alguns pode ter sido banalizado pela massiva introdução de
tecnologias novas no dia-a-dia do arquiteto, pertence ainda à esfera de brincadeiras e
experimentações para o autor deste trabalho. De forma descontraída, tecnologia vira brinquedo, e
um trabalho de conclusão de curso vira um quebra-cabeça de um número incontável de peças (com
algumas delas notavelmente desaparecidas até o momento final). Pesquisa-se, estuda-se e diverte-
se, pois graduar-se é também celebrar a entrada em um mercado de trabalho que escolhemos e nos
acompanhará por importantes fases de nossas vidas. Abaixo a demagogia acadêmica! Abaixo as
lamúrias das obrigações estudantis! É sobretudo com satisfação de aplicar os conhecimentos
adquiridos ao longo do curso de arquitetura e urbanismo da Universidade Federal Fluminense que
este projeto se realiza.
Este trabalho propõe uma contribuição à área de visualização arquitetônica através do
desenvolvimento de uma tecnologia para potencializar o uso de ambientes virtuais no processo de
entendimento do projeto arquitetônico. A tecnologia escolhida é conhecida como domo imersivo, e
o foco do presente trabalho é o estudo de possibilidades de utilização desta mídia para visualização
arquitetônica. Como plataforma de desenvolvimento, testes, e implementação da prova conceitual, o
presente estudo se utiliza do programa de visualização Blender™.
É também missão deste trabalho apresentar a visão de um arquiteto aplicada a outras áreas
de atuação - no caso específico a arquitetura de informações (informática). Deste desafio surge uma
reflexão sobre a evolução das artes e da própria arquitetura, bem como uma compreensão mais
ampla das possibilidades de envolvimento do profissional formado. As etapas para conclusão do
mesmo são diversas. Este portanto encontra-se dividido em 7 etapas: (1) história do projeto, (2) a
5
6. racionalização da visão humana na arte e na arquitetura, (3) o domo imersivo, (4) o domo imersivo
aplicado à arquitetura, (5) desenvolvimento do sistema do domo para a Blender Game Engine, (6)
implementação e desenvolvimento do sistema de domo imersivo para a Blender Game Engine, (7)
testes realizados e avaliação dos resultados e (8) conclusões do trabalho e encaminhamentos. Estas
etapas não necessariamente correspondem à ordem a partir da qual o problema foi enfrentado, mas
se encerram em uma sequência lógica para a compreensão do problema proposto e do devido
desdobramento de sua solução.
Pela natureza técnica do tema, uma parte considerável deste trabalho encerra termos,
conceitos e técnicas provavelmente desconhecidas ou relegadas a distantes partes da memória do
arquiteto leitor. À esta zona de estranheza entre as áreas de conhecimentos visitadas por este
trabalho, foi criado um glossário, para tentar maximizar a zona de diálogo entre o autor e o público
não-técnico. Além deste, houve uma tentativa de organizar as introduções dos diferentes assuntos
com abordagens mais brandas e de ampla compreensão, seguidas de um desenvolvimento mais
aprofundado que possa servir de referência caso este trabalho algum dia vá de encontro com seus
encaminhamentos propostos.
6
7. História do projeto
Este trabalho final de graduação começou como a união de uma demanda real por parte de
um cliente, as motivações pessoais e o processo investigativo do autor. O seu objetivo é explorar as
possibilidades presentes em tecnologias imersivas e expandir seu uso para a área de arquitetura e
urbanismo.
À parte de todo processo de pesquisa, o escopo deste projeto se encerra no desafio de se
produzir conteúdo imersivo para a mídia conhecida como domo. Vamos chamá-los de domos
imersivos ao longo dos textos, de modo a diferenciar-los de domos arquitetônicos comuns em
catedrais e templos religiosos. Imersão, então, é o processo de se sentir perdido, desorientado,
cercado por todos os lados e de todas as maneiras por um meio externo. Assim o é o ambiente
aquoso, por mais prazerosa ou desprazerosa que possam ser as memóricas evocadas por esta
metáfora. O náufrago afogado e o bebê uterino compartilham uma forte sensação comum: não há
barreiras entre o seu espaço pessoal, e o ambiente que os rodeia - ambos estão completamente
imersos.
Esta é a sensação que se evoca no uso de domos imersivos. Apesar das limitações da
tecnologia, o uso de uma superfície esférica para projeção de imagens de um ambiente arquitetônico
permite maravilhas no processo de se experimentar este espaço. Se nós pudermos então, utilizar um
projeto arquitetônico no momento prévio ao de sua encarnação em ripas e pilaretes, faz-se mágica.
A incógnita espacial de nossos elefantes brancos, futuros edifícios, se dissolve em comunicação
compartilhada entre arquitetos e clientes.
Isto é de tal forma verdade, que este projeto não se iniciou sob a demanda de arquitetos em
busca de expandir suas possibilidades de comunicação com este público que consome e se
empanturra de sua arquitetura. Talvez estejamos satisfeitos com os meios que dispomos para
comunicar nossas ideias. Difícil entretanto é não colecionar casos e causos de amigos ou clientes
7
8. que hipnotizados por apresentações vistosas - ou perdidos pela ausência delas - não se decepciona
ao constatar que o projeto construído não os agrada de uma forma que não pôde ser identificada a
priori de sua construção. Muito antes pelo contrário. Este trabalho foi iniciado sob solicitação de
uma escola de arte e tecnologia que buscava alternativas para usar seus domos imersivos na
exibição de ambientes construídos e projetados. Uma ferramenta de visualização em grande escala,
para um grande público. Uma maneira de usar tecnologia para cobrir lacunas de comunicação entre
o artista (arquiteto), sua obra e seu público.
SAT (Montreal): a demanda atual por 3D e ambientes imersivos
A Sociedade de Artes e Tecnologias é uma escola situada em Montreal no Canadá. A missão
da escola é integrar os campos técnicos e artísticos através de tecnologias de ponta e criatividade.
Desde que começaram a estudar as possibilidades de se trabalhar com tecnologia imersiva para
criações artísticas, eles decidiram explorar as possibilidades de uso e aplicações de domos
imersivos. Hoje em dia o SAT é um dos três maiores centros de pesquisa no mundo que não apenas
emprega domos imersivos em seus projetos, como também se ocupa em desenvolver tecnologia
nesta área.
A pesquisa recente do SAT buscava atender a duas demandas principais: criar uma
ferramenta para visualização de projetos arquitetônicos e criar uma ferramenta para entretenimento
utilizada por VJs (Video Jockeys).
Para o uso do domo imersivo em arquitetura o SAT procurou mapear o maior número de
possibilidades para que artistas e arquitetos tivessem à sua disposição todos os instrumentos
necessários para criarem para o domo imersivo. Isso pode ser compreendido entre dois diferentes
campos: visualizações interativas e animações pré-renderizadas. Para animações pré-renderizadas
de passeios arquitetônicos eles já contavam com soluções utilizando o pacote de visualização 3D
XSI® da Autodesk® e outras ferramentas externas. Para passeios virtuais interativos entretanto não
8
9. havia ainda uma solução acessível que se encaixasse no fluxo de trabalho deles. O mais importante
para eles era que artistas pudessem se preocupar somente com o conteúdo, enquanto que eles
facilitariam o acesso à tecnologia para a produção nesta mídia. Portanto era fundamental para o
sucesso do projeto que eles pudessem contar com alguma ferramenta passível de ser utilizada para
capacitar artistas, ao mesmo tempo que tecnicamente atendesse aos requisitos muito particulares de
seu sistema de projeção esférico. Na ausência de algum programa que cumprisse com a expectativa
deles, eles decidiram financiar o desenvolvimento do programa de criação 3D Blender™ para que
este pudesse ser utilizado em seus trabalhos. A ferramenta em si não encerra a busca por alternativa
para produção de conteúdo interativo em domos imersivos, mas atendeu a sua proposta de servir de
passo inicial para a criação e visualização deste tipo de material. Por casualidades e circunstâncias,
o autor deste projeto foi convidado a realizar este trabalho para o SAT. Por conseguinte, a primeira
parte do desenvolvimento deste trabalho foi focado no modelo de domo imersivo com o que se
trabalha no SAT - um domo horizontal tipo planetárico com um campo de visão de 360º horizontal e
220º vertical. A partir deste primeiro contato com esta tecnologia e o desenvolvimento inicial da
pesquisa pelo autor, a solução se desdobrou com o objetivo de abranger diferentes tipos de domos
imersivos e sistemas de projeção mais economicamente viáveis. Apesar desta expansão ter sido
realizada fora do escopo do contrato de trabalho original, foi obtido bastante suporte e apoio do
SAT em todas as etapas deste trabalho.
a escolha do Blender™ como ferramenta de desenvolvimento
Para a produção de conteúdo e adequação do projeto à soluções existentes, este trabalho foi
construído em cima do código do programa livre Blender™ e sua Game Engine. Os conceitos aqui
explorados e desenvolvidos são entretanto comuns a qualquer ferramenta de visualização 3D que se
encontre no mercado. Seria portanto possível se implementar solução parecida nestas outras
ferramentas. Para isso, contudo, seria necessário que as empresas que as desenvolvam encontrem
interesse pelos possíveis desdobramentos do presente trabalho.
9
10. Algumas características entretanto fazem do Blender™ um programa perfeito para o escopo
deste projeto. O Blender™ é uma ferramenta que atende em perfeição ao chamado artista técnico.
Por um lado ele possui ferramentas que possibilitam a liberdade criativa e recursos artísticos para
muito além de programas CAD. Por outroa lado ele permite que seu código seja estudado e alterado
de acordo com a sua necessidade. Por mais que a modificação de seu código não seja atividade
corriqueira, isto permite que o Blender™ funcione como uma ótima ferramenta para pesquisas,
testes de conceitos e viabilidade.
Além disto, o Blender™ é um dos programas de código aberto mais famosos que existe.
Isto significa dispor de uma enorme comunidade online para testes, e suporte ao longo do
desenvolvimento deste projeto. Isto foi de especial importância principalmente para as etapas finais
de ajustes na interface, revisão do código e testes em diferente tipos de domos imersivos.
10
11. A racionalização da visão humana na arte e na arquitetura
Entender como nossa visão funciona é o primeiro passo para podermos ludibriá-la. Assim
tem sido feito desde a remota Grécia - com a elaboração da geometria euclidiana, na posterior
renascença - com a racionalização da visão e a elaboração da perspectiva, e finalmente no século
XIX - com o desenvolvimento da geometria descritiva. A aplicação destes estudos nas artes
produzia o que muitos consideravam mágica. Um exemplo destes desdobramentos são as pinturas
realizadas em tetos de igrejas simulando abóbadas. Uma das obras notáveis produzidas nesta época
é sem dúvida a igreja de Santo Inácio em Roma. Seu teto foi pintado de tal forma que a percepção
do mesmo produz uma ilusão de volume abobadado.
Para a realização desta obra, o artista do século XVII Andrea Pozzo estudou
minuciosamente como uma abóbada seria percebida, caso observada de determinado ponto de vista
(a via da nave principal da igreja). O resultado deste estudo foi então pintada no teto da igreja. Isto
produziu a ilusão de realmente se haver uma abóboda quando o teto era observado a partir da
entrada da igreja. Caso observado a partir de sua base, contudo, a ilusão era desfeita. Esta técnica é
conhecida como trompe l'oeil, e apesar de ser antiga, tem sido revisitada por artistas
contemporâneos na produção da chamada 3D Street Art.
11
Ilustração 1: Teto da Igreja de Santo Inácio sob diferentes pontos de observação
12. Apesar de percebermos o mundo em suas três dimensões espaciais, cada um de nossos olhos
capta na realidade uma imagem bidimensional. Somente depois que as imagens são processadas e
interpretadas pelo nosso cérebro que a percepção de tridimensionalidade e consequentemente a
apreensão da distância são produzidas e percebidas. Parte deste processamento se dá por
generalizações adquiridas quando ainda somos crianças. Por exemplo, uma pessoa muito distante é
vista como uma pessoa bem pequena; um prédio alto visto de baixo aparentará ter suas paredes
convergindo em um ponto acima dele. Ainda assim lidamos com estas imagens com naturalidade,
transformando pessoas pequenas em distantes, e edificações curvilíneas em esbeltas. Esta falta de
estranheza ao enxergar pessoas pequeninas e prédios curvos é fruto de anos interpretando a
informação que chega a nossos olhos. É também o que faz ser tão fácil enganar a nosso cérebro e
produzir ilusões de ótica.
Um exemplo arquitetônico que utiliza este conhecimento para alterar a percepção da obra é
o Parthenon em Athenas na Grécia. Seus pilares foram construídos de tal forma que quando o
templo era visitado pela sua entrada principal, os mesmos eram vistos como paralelos. Como linhas
12
Ilustração 2: 3D Street Painting por Manfred Stader. Ilusão criada para um único ponto de vista
13. paralelas são vistas como curvas convergentes, a única maneira de se enxergar pilares como
realmente paralelos é na verdade construindo-os de maneira inclinada, na direção oposta à de
convergência natural da visão.
Este domínio construtivo do processo de percepção visual é fruto de conhecimento anterior a
própria cultura grega. Mas foi um grego, contudo, que primeiro compilou postulados e tratados de
matemática espacial criando o que ficou conhecido como geometria. Hoje em dia estes estudos são
chamados de geometria euclidiana, em referência ao homem que organizou e publicou este material
no século III A.C. sob o nome de Elementos. Na renascença, um artista italiano chamado
Brunelleschi desenvolveu diversas técnicas para realizar seus afrescos em abóbadas (neste caso
verdadeiros domos construídos) baseado em estudos de geometria euclidiana. Uma de seus técnicas
mais famosas era realizar pinturas com uma perspectiva com um ponto de fuga central, fazer-lhes
13
Ilustração 3: Templo Grego Parthenon
14. um furo bem em cima de seu ponto de fuga, e enxergá-las pelo seu verso através do furo enquanto
segurava um espelho na frente do quadro. Se a distância utilizada fosse a correta, a imagem vista da
tela através do espelho deveria acompanhar e reproduzir a mesma perspectiva percebida do espaço
quando se retirava o espelho. Desta maneira a pintura passou a representar o espaço como ele seria
percebido por um espelho, com a impressão de elementos volumétricos e tridimensionais, e não
mais figuras bidimensionais planas e achatadas. Com base nas técnicas desenvolvidas por
Brunelleschi, foram desenvolvidos diversos estudos como a construzione legittima por Leonardo
da Vinci, e os esquemas de perspectiva criados por Albertini e por Viator. Foi portanto durante o
período da renascença que o entendimento da visão foi racionalizado através da criação e
aprimoramento do método de perspectiva através das áreas de artes, arquitetura e construção.
14
15. O domo imersivo
O domo imersivo é uma superfície semi-esférica utilizada como tela de projeção para
sistemas digitais. Ao contrário de outras técnicas imersivas, o domo imersivo não requer nenhum
outro aparelho de interação, como capacetes e óculos especiais. Isto reduz consideravelmente o grau
de desconforto e estresse visual provocados pelo uso prolongado do domo imersivo. Isto também
proporciona um campo visual livre e desimpedido de obstáculos para quem o utilize.
história do surgimento do domo imersivo
O domo enquanto ferramenta imersiva moderna surgiu em meados dos anos 90 como
ferramenta de visualização e treinamento militar. O primeiro modelo comercial conhecido é o
VisionStation® e era produzido pela empresa Elumens™. Este modelo possui um projeto portátil,
com altura de 1,65 metros, e uma tela curva de projeção com um campo de visão de 160º e diâmetro
de 1,50 metros. O equipamento inclui ainda um projetor com uma lente patenteada f-theta
desenvolvidos pela empresa para proporcionar um campo de visão de até 180º e profundidade
visual para foco infinito. Este sistema ainda pode ser encontrado à venda com preços em torno de
U$20.500,00 e U$41.900,00 (R$40.000,00 e R$83.800,00) de acordo com o modelo.
15
Ilustração 4: VisionStation
16. As principais vantagens do VisionStation comparado com outras tecnologias imersivas da
época são:
• ele proporciona uma experiência imersiva mais completa devido ao campo de visão do
equipamento ser superior ao da visão humana.
• ele não requer o uso de capacetes ou outros equipamentos de realidade virtual.
• ele pode ser usado para visualização de ambientes virtuais e reais (com o uso de imagens).
• ele é de configuração rápida.
• ele é portátil devido a seu tamanho e peso.
• ele funciona como uma tela de computador tradicional.
• ele pode ser usado para uma variedade de aplicativos.
A empresa não existe mais, porém alguns de seus membros fundaram o que é hoje a maior
empresa no ramo de visualizações com domos, a Elumenati™. Eles se especializaram no
desenvolvimento de projetores, lentes e aplicativos para produção de conteúdo em sua plataforma.
Hoje em dia este mercado já cresceu e se consolidou, e já há diferentes alternativas relativas a
equipamentos, programas e profissionais. Porém por se tratar de um nicho especializado, a maior
parte dos produtos desta área possui elevado valor agregado. Isto se justifica pelo comum
dependência a equipamentos sujeitos ao pagamento de patentes e ainda a forma como são
comercializados os equipamentos em conjunto com um pacote fechado que inclui desde a estrutura
esférica, até equipamentos de projeção digital, lentes e pacotes de aplicações específicas para
domos imersivos. Com a disseminação de seu uso nas áreas de visualização científica, educação
pública e entretenimento, outras soluções começaram a ser desenvolvidas focadas na redução de
custos e em tornar a tecnologia mais acessíveis e de melhor qualidade. Com esta evolução, hoje em
dia a maior parte das soluções envolve ou o uso de sistemas de projeção com lentes especiais de
16
17. grande campo de visão ou projetores de alta-definição e espelhos esféricos. Dentre estas alternativas
a que mais se destaca sem dúvidas é o uso de espelhos esféricos com projetores de lente comum,
pois esta solução descarta a necessidade de se utilizar produtos e tecnologia patenteados e consegue
assim reduzir drasticamente os custos envolvidos na instalação.
Do ponto de vista da estrutura do domo diversos sistemas já foram desenvolvidos, sendo os
mais populares os sistemas infláveis pela sua portabilidade, e os sistemas de fibra de vidro, pela sua
precisão, robustez e qualidade.
domos imersivos com lentes olho de peixe de grande campo visual
A forma mais simples de se projetar uma imagem em um domo imersivo, é através de uma
lente olho-de-peixe. Estas lentes cobrem um campo visual de aproximados 180º e são desenvolvidas
especificamente para que trabalhem com um tipo específico de projetor. Para que a distorção seja
correta é necessário que o projetor esteja apontado para o centro do domo imersivo e a área de
projeção de sua lente coincida com a superfície do domo.
17
18. Como a lente distribui a imagem por toda a superfície do domo imersivo, a imagem a ser
projetada tem que ser uma imagem que capture 180º. Para se utilizar domos imersivos com fotos, é
preciso que as fotos sejam tiradas com uma lente olho-de-peixe. Para ambientes virtuais é
importante utilizar alguma técnica equivalente de captura de imagem. Isto é assunto abordado na
parte final deste trabalho.
18
Ilustração 5: Domo com um sistema de projeção digital olho-de-peixe
19. Estes sistemas são adquiridos como sistemas fechados. O domo imersivo é comercializado
junto com o sistema de projeção e programas para a sua utilização - visualização de vídeos, imagens
e comumente outras funções específicas como visualização de estrelas ou dados terrestres.
domos imersivos com espelho esférico
Uma alternativa mais barata e relativamente mais atual é a junção de domos imersivos,
sistemas de projeção simples e espelhos esféricos. Na verdade o uso de espelhos esféricos para
projeção em grandes áreas é bem antigo. O inventor James S. Conant registrou uma patente em
outubro de 1942 sobre o uso de aparelhos e métodos para obter e projetar imagens em grandes
ambientes com espelhos esféricos. Para o uso em planetários há registro do uso de técnica similar
em 1957 em Hamburg na Alemanha. Porém o uso de espelhos esféricos para projeção em domos
imersivos com um sistema de projeção digital foi desenvolvido originalmente na Swinburne
University of Technology em Melbourne, Australia pelo pesquisador Paul Bourke. Atualmente ele
continua a desenvolver esta tecnologia dentro da Western University of Australia na cidade de
Perth. Seu trabalho se concentra na maximização da qualidade deste sistema de projeção fulldome
19
Ilustração 6: Foto capturada utilizando uma lente olho-de-
peixe
20. voltado principalmente para domos verticais e planetários com aplicações para visualização
científica, educação e entretenimento.
Um sistema de projeção com espelhos esféricos consiste em se utilizar um projetor alinhado
com um espelho esférico que refletirá a imagem em uma superfície também esférica. Com isso é
possível cobrir superfícies com um campo de visão que um projetor com lente normal não
conseguiria. Para que a imagem percebida tenha uma distorção correta, é necessário que a imagem
projetada seja previamente distorcida para atender a uma dada instalação (projetor + espelho +
domo). Esta distorção é calculada pelo programa utilizado no sistema e será abordada com maiores
detalhes nos capítulos subsequentes.
benefícios do sistema de espelhos esféricos sobre lentes olho de peixe:
• A principal razão para se considerar o uso de espelhos esféricos é o custo - uma fração das
soluções de projeção olho de peixe.
• Como o espelho esférico é colocado na base do domo, o seu centro fica completamente
desobstruído. Além de se liberar o melhor ponto de observação do domo imersivo que é o
centro, ainda se obtém mais segurança pela ausência de cabos e energia próximos ao
mesmo.
20
Ilustração 7: Sistema de domo imersivo com projeção em espelho esférico
21. • O sistema ótico é independente do projetor. Desta maneira o projetor pode ser atualizado
sem a necessidade de se substituir também o sistema ótico. No caso de lentes olho-de-peixe
elas costumar estar atadas diretamente aos projetores para o qual elas foram desenvolvidas.
• Existe maior flexibilidade para se variar a extensão de cobertura do domo. Pode-se obter
maior campo de visão com menor resolução, ou vice-versa.
• Como não envolve o uso de nenhum equipamento proprietário ou patenteado, esta
tecnologia é acessível a um público muito maior.
21
22. O domo imersivo aplicado à arquitetura
O processo projetual arquitetônico é conhecido por ser extremamente visual. Desde as
etapas de concepção até a apresentação, uma das principais peças de comunicação entre o arquiteto
e seu cliente se dá através do uso de desenhos, perspectivas e maquetes. Enquanto desenhos
técnicos são necessários para as etapas de orçamento e construção do projeto, eles se constituem
uma verdadeira barreira no processo de comunicação do mesmo. Existe uma enorme lacuna entre a
formação técnica do arquiteto e o público leigo, e devemos buscar de todas as formas aproximar o
universo de representação de ambas as partes para o entendimento mútuo.
sistemas de visualização arquitetônica
“Então levantarás o tabernáculo conforme ao modelo que te foi mostrado no monte.”
Êxodo 26:30
“Tudo isto, disse Davi, fez-me entender o SENHOR, por escrito da sua mão, a saber todas as obras desta planta.”
Crônicas 28:19
Foi através de uma maquete recebida de um anjo celestial que Davi compreendeu como
construir o templo de Salomão. E a partir do modelo do templo ele desenhou suas plantas e
conseguiu fazer a sua obra. A partir destas passagens da Bíblia, fica evidente a natureza divina de
Davi. Construir um projeto exatamente como o encomendado, e ainda por cima dentro do prazo, só
pode mesmo ser considerado um milagre.
Esta metáfora, além de sua mensagem religiosa, demonstra a função de uma das ferramentas
de representação e visualização arquitetônica mais antigas que existem. A maquete tem diversos fins
e é considerada uma das formas de representação arquitetônica das mais completa. Por se tratar de
um modelo tridimensional, não é necessário para o seu entendimento que se abstraia a compreensão
espacial a partir de representações planas bidimensionais. O fato de que ela permite sua
manipulação espacial facilita enxergar e entender diferentes ângulos do projeto. Entre suas
desvantagens da maquete estão os custos com materiais para montá-la, o tempo empregado na sua
22
23. execução, e as dificuldades para se trabalhar aspectos da iluminação natural no objeto construído.
Hoje em dia, as maquetes são mais utilizadas nas etapas de conceituação volumétrica ou de
apresentação de grandes empreendimentos.
Uma outra forma de visualização arquitetônica muito importante são os desenhos de
perspectiva. Tradicionalmente estes eram realizados com técnicas próprias de distorção geométrica
como a vista isométrica ou a perspectiva com apenas dois pontos de fuga. Por anos estas formas de
desenho eram uma das principais peças nas etapas de desenvolvimento do projeto e no processo de
comunicação com o cliente. As perspectivas realizadas desta forma apresentam o inconveniente de
restringirem-se a mostrar pontos de vista selecionados pelo arquiteto, e por mais que servissem bem
propósito de ilustração, não tinham a capacidade de evocar o sentido de espacialidade alcançado
pela maquete.
Com o advento da informática, o uso de computadores para geração de perspectivas
eletrônicos se difundiu muito. A chamada perspectiva eletrônica permite uma aproximação muito
maior ao objeto fotográfico do que a desenhos realizados com papel e lápis. Isso se faz presenta na
iluminação, nos reflexos, e na câmera mais cinematográfica em geral simulada. De acordo com o
grau de realismo almejado com a perspectiva eletrônica, esta é chamada de volumétrica ou foto-
realista.
Uma grande vantagem dos computadores está na escala de seu processo de produção. Uma
vez terminada as etapas de criação do objeto arquitetônico virtual, é possível produzir diversas
imagens a partir do mesmo modelo. Até então isto também era possível com o uso combinado de
fotos de maquetes e perspectivas realizadas em cima deste material. Porém o mesmo não pode-se
dizer das animações computadorizadas. Assim como se pode extrair imagens a partir de uma
maquete eletrônica, também é possível simular uma movimentação da câmera pelo espaço
projetado. Com isso é possível produzir verdadeiras animações digitais - passeios virtuais de obras
arquitetônicas em suas etapas de projeto. Do ponto de vista comunicativo, uma grande vantagem da
23
24. representação arquitetônica através do computador é a familiaridade do público em geral com a
forma de mídia produzida. Fotos e filmes, são mídias bidimensionais que já estão amplamente
difundidos como formas de representação espacial.
É importante ressaltar que o computador já está tão inserido e mesclado com o processo de
desenvolvimento arquitetônico nos dias de hoje, que mesmo para visualizações volumétricas o seu
uso é preferido em detrimento das formas tradicionais de apresentação. Isto também é muito
influenciado pelas facilidades proporcionadas pelos sistemas de desenho integrado existentes
atualmente - muitos dos programas utilizados em arquitetura permite que se trabalhe ao mesmo
tempo com desenhos técnicos, produção de um modelo tridimensional e a geração de perspectivas e
animações.
Uma outra forma de representação arquitetônica que é pouco utilizada, mas se fez possível
principalmente com os avanços na área de equipamentos de computadores é a realização de
passeios interativos por um modelo arquitetônico virtual. Esta tecnologia ainda não alcançou grande
popularidade para arquitetura. Porém sua linguagem é muito semelhante a o de jogos eletrônicos, e
possui grande aceitação pelo público consumidor desta mídia. Passeios virtuais são mais comuns
em grandes lançamentos imobiliários, mídias eletrônicas (páginas de internet) e espaços
publicitários.
Uma outra forma de visualização do projeto são as plantas baixas, vistas, cortes e
detalhamentos. Desenhos técnicos executados a partir de um conjunto de normas (códigos) criado e
compartilhado por arquitetos e construtores. Por mais que sejam a maneira mais precisa de se
representar um projeto, são também as mais indecifráveis para um público leigo.
Um último recurso muito eficiente para a compreensão do projeto arquitetônico são
apartamentos montados e decorados encontrados em estandes de venda. Estes ambientes simulam o
potencial dos espaços projetados, e são, estas sim, formas fidedignas de representação dos
moesmos. Porém seus custos correspondem a uma boa fração do custo final de uma obra, e são
24
25. inviáveis nas etapas anteriores à finalização do mesmo. Na verdade os custos envolvidos são
próximos do custo final de construção de um imóvel (quando se considera apenas os ambientes
internos) e viáveis apenas em empreendimentos de grande porte. Na realidade eles são utilizados
mais como um elemento extra de sedução e persuasão para o objeto de venda, do que como um
instrumento de percepção da arquitetura.
problemas do sistema atual de visualização arquitetônica
Que por um lado a informática traga grandes avanços nas áreas de foto-realismo, criação de
filmes e na velocidade de produção visual em grandes escalas, isso é inegável. Porém um assunto
pouco abordado são os efeitos colaterais desta transformação na maneira de se apresentar projetos.
Muitos profissionais já tem substituído o uso exclusivo de computadores por um método de
trabalho combinado de técnicas tradicionais e produção eletrônica. Não entraremos aqui no mérito
do prejuízo ao projeto arquitetônico pela introdução das novas mídias, mas vamos expor
brevemente alguns dos problemas introduzidos nas etapas de visualização.
O primeiro deles é o abandono de maquetes volumétricas em detrimento de sua contra parte
eletrônica. É necessário muita prática para se adquirir uma visualização espacial a partir de imagens
planas, problema este pouco comum no uso de maquetes. Isto produz a falsa sensação de
compreensão de espaço por parte do cliente e muitas vezes por parte do próprio arquiteto. Como
um projeto é percebido e vivenciado em sua materialização espacial, o simples entendimento dele
através de fotos é por si só muito limitado.
Um segundo problema é o uso abusivo de perspectivas eletrônicas para esconder falhas
projetuais. Os pontos de vista escolhidos para serem representados em geral ilustram apenas os
pontos fortes e interessantes do projeto, enquanto que eventuais problemas são relegados à atenção
secundária na forma como o são representados (e quando o são). É prática comum o
ajuste/reposicionamento de elementos de projeto - altura do teto, disposição dos móveis,
25
26. composição do entorno - para que produzam um bom resultado na sua representação. Isto muitas
vezes induz o cliente/comprador a uma compreensão falsa das vantagens e desvantagens do projeto.
Um terceiro problema, comum também nas formas de visualização empregados antigamente
é a ausência de uma apreensão periférica do espaço. Enquanto que o campo de visão humano
compreende até 160º, o espaço contemplado por uma tela de computador ou uma perspectiva
impressa é pouco mais do que o de uma câmera fotográfica comum com um campo visual de 50º.
Por mais que isso atenda à demanda de representação do espaço percebido objetivamente pela visão
frontal, isso não transmite a percepção adquirida pela visão periférica humana. A falta de apreensão
panorâmica do espaço limita a capacidade do seu entendimento espacial.
a contribuição do domo imersivo para arquitetura e suas aplicações
“Unfortunately, no one can be told what the Matrix is. You have to see it for yourself.”.
[ Infelizmente, é impossível dizer o que é a Matrix. Você tem de ver por si mesmo.]
The Matrix, 1999
Ainda não existe tecnologia que simule a sensação de realidade como o que se pode ver em
alguns filmes de ficção científica. Porém o desenvolvimento de equipamentos imersivos nos
aproxima cada vez de um futuro aonde a fronteira entre real e virtual passarão a ser imperceptíveis.
O domo imersivo restringe-se a estimular somente o processo de percepção visual. Porém apresenta
grandes avanços neste sentido. Como ele não é mais necessário levar o projeto para o cliente. Pelo
contrário, o cliente é trazido para dentro do projeto. O domo imersivo é portanto um convite à
experimentação do espaço arquitetônico.
A superfície esférica do domo permite que se projete em uma área muito maior do que a que
o olho humano consegue enxergar. Isto amplia os meios de percepção indireta do espaço através da
visão periférica, ao mesmo tempo que permite inclusive que um mesmo ponto de observação seja
explorado através de múltiplo ângulos de rotação da cabeça.
26
27. possíveis aplicações do domo imersivo em arquitetura
O uso mais óbvio de domos imersivos é enquanto ferramenta de visualização do ambiente
arquitetônico em suas etapas de projeto e de apresentação. Porém as suas possibilidades como mídia
imersiva são as mais diversas.
Um uso repleto de potencial é o acesso à obras clássicas de arquitetura e sítios históricos. O
primeiro passo para isso é a construção de um modelo virtual que se assemelhe à obra original. Uma
vez que se tenha esta geometria construída, é possível explorá-la em um passeio virtual. A
possibilidade de explorar estes ambientes utilizando o domo imersivo aproximaria a teoria e a
história arquitetônica de seus objetos de estudo. Este seria um recurso inestimável para se criar um
acervo de obras de forma o mais acessível possível. Isto naturalmente poderia se estender à obras e
projetos de arquitetos e urbanistas mais novos.
Uma outra possibilidade é a criação de espaços de visitação e exposição totalmente virtuais.
Com uma mídia imersiva, o conceito de ambientes efêmeros se torna ainda mais refinado. É
possível projetar um espaço cenográfico sem qualquer necessidade de se materializar o projeto por
meios físicos. Além disso o mesmo espaço de um museu, por exemplo, poderia ser utilizado para
um número ilimitado de exibições simultâneas.
Uma outra aplicação importante para os domos imersivos é enquanto ferramenta de
compreensão de projetos executivos. Projetos muito complexos são de difícil compreensão através
de desenhos técnicos ou perspectivas planas. Visualizar um sistema de construção dentro de um
campo visual extenso permite uma apreensão maior dos sistemas interligados e menos restrita ao
recorte enclausurado por uma única vista ou desenho técnico.
Como pode-se ver, os usos do domos imersivos são dos mais diversos. Muitos deles
caminham lado a lado com a expansão cada vez maior do uso de realidade virtual em arquitetura.
Neste sentido, é possível que a própria tecnologia do domo imersivo seja em breve aperfeiçoada
para melhor potencializar seu uso específico para arquitetura.
27
28. Implementação e desenvolvimento do sistema de domo
imersivo para a Blender Game Engine - parte I
Para se utilizar o domo imersivo em visualizações arquitetônica é necessário três coisas: (1)
uma maquete eletrônica, (2) uma forma de passear virtualmente por ela, e (3) uma forma de
visualizá-la com o campo de visão necessário para o domo. Hoje em dia mais e mais programas de
desenho arquitetônicos suportam recursos de modelagem tridimensional - muitos deles inclusive o
fazem automaticamente (como é o caso de Revit® e do ArchiCad®). Além disso programas como
o SketchUp popularizaram bastante a possibilidade de se desenhar diretamente em três dimensões.
Com isso o primeiro dos três passos já pode ser obtido com facilidade. Para o segundo passo - o
passeio virtual - é possível utilizar ferramentas como o SketchUp Viewer, ou a função
Walkthrough do Revit®. Porém a forma de visualização produzida por estes programas é voltada a
telas de computador tradicionais, sem atender às necessidades do Domo imersivo - um grande
campo de visão (em geral em torno de 180º) e uma distorção que compense a deformação do
sistema de projeção e da superfície esférica. Para adaptar os programas citados, seria necessário que
a empresa responsável pelos mesmos alterasse seus códigos-fonte. Como este tipo de
implementação iria além do escopo deste projeto, decidiu-se utilizar uma plataforma livre que
atendesse aos duas primeiras etapas iniciais, e permitisse a sua expansão para o desenvolvimento da
terceira: a Game Engine do Blender™. Ao contrário de outras ferramentas para produção de
maquetes eletrônicas, o Blender™ permite a modificação de seu código-fonte para quaisquer usos.
Como entretanto ele não é uma ferramenta voltada exclusivamente ao mercado de arquitetura,
resolveu-se primeiro mapear algumas das possibilidades de integração com outras ferramentas que
atendam às etapas iniciais, para então podermos abordar a implementação da terceira etapa: a
renderização de imagens para o Domo imersivo em tempo real.
Este capítulo divide-se em duas partes. A primeira abrange um apanhado dos recursos
28
29. empregados para se produzir uma maquete eletrônica desde a planta baixa até o modelo eletrônico e
um sistema de interação e passeio virtual. A segunda diz respeito ao desenvolvimento da opção de
câmera olho-de-peixe para a produção de apresentações imersivas.
da planta baixa ao cenário virtual com o Blender™
1. integrando programas CAD com o Blender™
O primeiro passo para se construir uma maquete eletrônica é dispor dos desenhos técnicos
para a reprodução da geometria tridimensional no computador. Estes desenhos técnicos podem estar
dispostos de duas formas. A maneira mais direta é se dispor de um arquivo que contenha toda a
informação vetorial dos elementos que compõe o desenho - linhas, curvas, eixos. Desta maneira é
possível obter o máximo de precisão na execução da maquete eletrônica. Outra possibilidade
envolve utilizar blueprints - arquivos de imagem (mapas de bit/bitmap) gerados a partir dos
desenhos originais. Apesar da primeira forma permitir o máximo de precisão na execução da
maquete eletrônica, ela depende do suporte existente ao formato de arquivo utilizado, gerado pelo
programa de origem. Quando arquivos de imagem são utilizados, garante-se maior
interoperabilidade entre os programas ao custo da exatidão final obtida no trabalho. Como muitas
vezes a apresentação tem caráter mais artístico do que técnico, esta troca costuma valer a pena para
o maquetista eletrônico.
Os programas de uso mais difundido para a produção destes desenhos são chamados de
CAD - Computer Aided Design (desenho auxiliado por computador), sendo o mais popular deles o
AutoCAD® da Autodesk®. O formato de arquivos nativo do AutoCAD® não segue um padrão
aberto, e desta forma a utilização do mesmo por outros programas costuma ser intermediada pela
própria Autodesk® que detêm os direitos sobre o formato de arquivo DWG e cobra pelo uso de
suas bibliotecas externas. A outra alternativa é o suporte ao formato de arquivos através de
engenharia reversa, resultando muitas vezes em perda de informação ou mesmo informações
incorretas. Para solucionar estes problemas e permitir uma maior troca de informações entre os
29
30. diferentes programas de desenho técnico 2D, criou-se um formato de especificações abertas
chamada DXF - Drawing Exchange Format (formato de troca de desenhos). Ele é o formato mais
utilizado para se levar desenhos técnicos de programas CAD para dentro do Blender™.
Outras alternativas são o uso do formato vetorial PDF - Portable Document Format, ou o uso
de conversores de DWG para formatos abertos e documentados como o SVG - Scalable Vectorial
Graphics, o PS - PostScript ou mesmo o DXF. Mais recentemente surgiu um formato de arquivo
próprio para troca entre programas BIM de modelagem 3D para arquitetura - o IFC. Como seu
formato segue um padrão aberto, quase todos os aplicativos tem a possibilidade de trocar modelos
via IFC , e isso faz ele ser considerado o padrão de interoperabilidade.
2. modelagem virtual
Uma vez que se dispunha das informações referentes ao ambiente a ser construído, dá-se
início a etapa conhecida como modelagem. O processo de modelagem serve para produz uma
geometria tridimensional localizada dentro de um sistema de coordenadas cartesiano. É a partir do
posicionamento de uma câmera virtual em um ponto definido dentro deste sistemas de coordenadas
que se transforma as coordenadas tridimensionais dos objetos em coordenadas bidimensionais na
imagem que se compõe na tela. Este processo é conhecido como render, ou renderização.
Apesar do Blender™ não ser um programa voltado especificamente para arquitetura, as
suas ferramentas de modelagem são muito utilizadas para a produção de jogos, se adequando
portanto também às necessidades de modelagem do espaço arquitetônico. Alguns dos recursos
muito usados por arquitetos são: Array, Bevel, Boolean, EdgeSplit, Extrusão, Lattice, Mirror,
Particles, SubSurf e Wave. Entretanto existem dois recursos importantes que podem fazer falta para
a modelagem de alguns projetos arquitetônicos: NURBS e N-GONS.
Objetos Nurbs são objetos cuja forma é determinada através de curvas orientadas por
fórmulas matemáticas. São muito usados para se construir estruturas curvas complexas como se vê
30
31. nas obras arquitetônicas de Frank Gehry e Sara Hadid. Em 2005 o estudante canadense Emmanuel
Stone participou do programa Google Summer of Code com a proposta de expandir o suporte à
NURBS no Blender™. Apesar de continuar trabalhando nesta direção desde então, a falta de tempo
disponível para desenvolvimento impediu o projeto de alcançar um alto nível de usabilidade. A
forma encontrada por artistas e arquitetos tem sido produzir a malha em outro programa e importá-
la no Blender™. O programa com mais ampla inserção no mercado para cobrir esta lacuna é o
Rhinoceros® da McNeel.
NGONS são polígonos definidos por um número ilimitado de vértices co-planares. Eles
permitem uma modelagem mais flexível onde o artista tem que se preocupar menos com a limpeza
da malha final e mais com sua forma resultante. A ferramenta mais popular à adotar este sistema de
modelagem é o Google™ SketchUp e o Lightwave3D® da NewTek. É interessante notar que do
ponto de vista do usuário o processo de modelagem com NGONS se simplifica bastante, enquanto
que para o programa ocorre o oposto, pois isto envolve operações matemáticas muito mais
complexas. Assim como no caso dos NURBS, existe um desenvolvedor trabalhando para
implementar NGONS no Blender™. Joseph Eagar é um programador estados unidense que
atualmente se dedica a reformulação do sistema de modelagem poligonal do Blender™. O fruto do
seu trabalho contanto não é esperado até o final deste ano de 2009 e meados de 2010.
É importante ressaltar que ambos os recursos citados não influenciam tanto o
desenvolvimento de cenários virtuais para apresentações interativas. Neste caso qualquer objeto
modelado é convertido para a forma de polígonos simples como triângulos e quadrados antes de ser
enviado para a placa de vídeo, independentemente de sua estrutura interna (curva, número de
vértices, ...). Além disso, como apresentações interativas demandam bastante recursos de
processamento do computador, uma boa parte dos detalhes presentes nos modelos é simulado com o
uso de texturas, ao invés de presentes na malha dos objetos.
31
32. 3. integrando o SketchUp com o Blender™
Hoje em dia, é cada vez mais comum o uso de ferramentas 3D durante o processo criativo. A
maquete eletrônica passa a ser elemento de estudo, e não simplesmente objeto de apresentação.
Neste caso o arquiteto já dispõe de um modelo eletrônico de seu ambiente arquitetônico e
necessitaria levá-lo para dentro do Blender™. Como estudo de caso resolve-se estudar as
possibilidades de integração entre o programa Google™ SketchUp e o Blender™.
O SketchUp é um programa de modelagem tridimensional desenvolvido especialmente para
o mercado de arquitetura. Apesar de ter se destacado por ser um programa simples e de pequena
curva de aprendizado, ele possui recursos poderosos possibilitando a criação de maquetes
eletrônicas com aplicação de texturas e a presença de faces transparentes. A versão PRO do
SketchUp dispõe de diversos formatos possíveis para se exportar o trabalho. O formato mais
adequado entretanto é o formato desenvolvido pela Wavefront Technologies empresa que se fundiu
com a Alias Systems Corporation e em 1996 lançaram o pacote 3D de maior popularidade entre
animadores até os dias de hoje conhecido como Maya®. Com a compra da Alias™ pela
Autodesk® em novembro de 2005 o formato OBJ continou a ser largamente suportado e
implementado em cada vez mais programas 3D. Uma característica importante deste formato é que
além de ser um formato aberto e ricamente documentado, ele é um tipo de formato simples de ser
implementado por se tratar de arquivos de texto de fácil compreensão.
A importação de arquivos OBJ no Blender™ se dá através de um script escrito na
linguagem de programação Python pelo desenvolvedor australiano Campbell Barton. Segundo as
palavras do próprio Barton, o Blender™ pode ser considerado o programa que melhor suporta a
importação de arquivos OBJ atualmente. Isto se deve principalmente à alta tolerância a erros no
arquivo e dados incorretos por parte do Blender™ e que impossibilitam programas como o
3DStudio MAX® da Autodesk® de importar arquivos parcialmente corretos.
No caso específico do SketchUp existem três pontos mais importantes a serem considerados
32
33. na hora da exportação e importação: (1) orientação das faces, (2) transparência e (3) suavidade das
superfícies. Para todos eles existem soluções e maneiras de se contornar o problema ao longo do
processo de trabalho.
A orientação das faces é uma característica a qual as pessoas costumam prestar pouca
atenção no SketchUp. Ela também é conhecida como a direção de sua normal, e de forma
simplificada pode ser entendida como uma indicação de se uma face está voltada para dentro ou
para fora de uma dada geometria. Ao contrário da maioria dos programas de modelagem 3D
existentes no mercado, o SketchUp permite que o usuário aplique diferentes texturas (imagens) em
cada um dos lado das faces. Devido a esta particularidade do programa, no momento de exportação
existe uma opção que permite exportar ou somente o lado externo das faces ou ambas os lados
como faces individuais. Esta opção - export two-sided faces - deve ser desmarcada de modo a
evitar a criação de faces sobrepostas no arquivo exportado (resultando em graves problemas na hora
de importação. Com isso toda a informação contida nas faces internas (mais especificamente seus
materiais) é descartada do arquivo resultante. Portanto é muito importante que as faces estejam em
suas corretas orientações na hora de se aplicar as texturas. Para isso o SketchUp dispõe de um
modo de visualização conhecido como Monochrome (monocromático) que permite distinguir entre
as orientações das faces e invertê-las quando necessário - através dos comandos ReverseFaces.
A suavidade das faces é uma propriedade utilizada no SketchUp para se produzir superfícies
que aparentem ser arredondadas. As arestas suavizadas podem ser visualizadas quando se habilita a
opção View Hidden Geometry. Elas são geradas automaticamente quando se utiliza a ferramenta
de extrusão em superfícies curvas (círculos ou superfícies arqueadas) ou manualmente quando se
utiliza a ferramenta de borracha junto com a tecla Ctrl. Entretanto o formato OBJ lida com a
suavidade aplicada a objetos, e não a arestas. Na hora de exportar seria necessário a criação portanto
de smooth groups, dividindo um mesmo objeto em mais de um se necessário para se adequar às
especificações do formato. Infelizmente o SketchUp simplesmente ignora este parâmetro na hora
33
34. de gerar arquivos OBJ. Consequentemente a suavização de faces e arestas dos objetos arrendados
deve ser realizada dentro do Blender™, uma vez importado o arquivo.
A transparência de materiais no SketchUp utiliza uma técnica derivada da técnica conhecida
como Z-Buffer Depth Test. Este sistema foi desenvolvido pelo matemático Edwin Catmull
pioneiro na área de computação gráfica em 1974. Este sistema é considerado bem eficiente e rápido,
atendendo a grande parte dos usos necessários para aplicações de tempo real até os dias de hoje. A
principal limitação deste sistema é a ausência de um método de sorting - ordenamento de faces
semi-transparentes sobrepostas. Com isso é comum encontrar-se problemas em objetos no
SketchUp que contenham faces com imagens com transparência se sobrepondo. No caso do
Blender™, o programa dispõe de um sistema de alpha sorting que pode ser aplicado diretamente
nas faces desejadas. Isto é portanto uma tarefa a ser realizada após o processo de importação. Um
outro problema encontrado nesta etapa foi uma falha em reconhecer a transparência de algumas das
faces do arquivo importado. Neste caso o arquivo gerado pelo SketchUp estava correto, e o
problema residia no script de importação do Blender™. Ao se utilizar o script oficial que
acompanha a versão mais recente do Blender™ até o momento (2.49a) é necessário configurar os
materiais para que utilizem transparência. Por mais que isto seja uma etapa de ajustes simples, foi
possível contornar o problema alterando o arquivo original do script. As alterações encontram-se
nos documentos anexos a este trabalho, e já faz parte do código oficial do Blender™ (e estará
presente em sua próxima versão, 2.49b).
Outras ferramentas podem ser usadas nesta etapa de modelagem. O importante neste caso é
encontrar um formato de exportação que seja também suportado pelo Blender™. Por exemplo, uma
tecnologia que está se expandindo no mercado de arquitetura são os chamados sistemas BIM. Os
arquitetos que trabalhem com programas como o Revit® da AutoDesk® , o VectorWorks® da
Nemetschek, ou o ArchiCAD® da Graphisoft, dentre outros, já dispõe de um modelo
tridimensional de seu projeto à medida em que o desenho em planta baixa é realizado. Porém até a
34
35. presente data o formato padrão de troca de arquivos entre aplicativos BIM, o IFC - Industry
Foundation Classes - não pode ser importado diretamente pelo Blender™. Entretanto o SketchUp
com a ajuda de plugins para importar arquivos IFC pode ser usado como programa intermediário
para esta operação.
4. explorando o ambiente virtual
Uma vez concluída a etapa de modelagem do ambiente virtual no Blender™, é possível
explorar suas possibilidades como ferramenta de visualização interativa. Para se realizar um passeio
virtual - interativamente mover-se dentro da maquete eletrônica - é necessário utilizar uma
ferramenta conhecida como motor de jogos ou game engine. No caso do Blender™ dispomos de
um motor de jogos integrado ao programa, chamado BGE ou Blender Game Engine. Uma
característica importante da BGE é a possibilidade de se construir aplicações simples através de
uma interface puramente visual - portanto sem a necessidade de dominar linguagens de
programação. Esta característica aproxima muito a ferramenta e artistas, que podem focar no
desenvolvimento de sua apresentação sem a preocupação com aspectos mais técnicos. Interessante
notar que ao contrário dos módulos interativos de programas como SketchUp e Revit®, um motor
de jogos completo permite muito mais do que o simples caminhar por um ambiente. É possível
interagir com o cenário, animar personagens, e outras possibilidades que se encontra em jogos
eletrônicos. Nesta linha já existem escritórios de arquitetura desenvolvendo (ou terceirizando)
apresentações interativas de seus projetos que se assemelham muito em qualidade e recursos
técnicos a lançamentos na área de entretenimento.
Uma apresentação interativa utiliza intensamente os recursos disponíveis na placa de vídeo
do computador. Por mais que a capacidade de processamento das placas de vídeo tenha evoluído de
maneira muito superior aos processadores de computador nos últimos anos, elas ainda enfrentam
sérias limitações devido a alta quantidade de cálculos necessários em uma visualização desta
natureza.
35
36. Implementação e desenvolvimento do sistema de domo
imersivo para a Blender Game Engine - parte II
Para se produzir imagens para domos imersivos a técnica mais comum é a utilização de
lentes especiais conhecidas como olho-de-peixe. Para animações pré-renderizadas é possível usar
renderizadores do tipo fullraytracing (como o V-Ray®, PovRay ou o Yafray) e simular um efeito
de lente olho-de-peixe digital. Para passeios virtuais interativos entretanto, não existe um aparelho
do gênero que possa ser conectado à saída da placa de vídeo e produza este efeito antes da imagem
alcançar a superfície de projeção. Tampouco a placa de vídeo tem condições de lidar com
algoritmos avançados de renderização de raios luminosos (raytracing) em tempo real. Existem
portanto duas soluções possíveis encontradas: (1) utilizar um glsl vertex shader para deformar
todas as geometrias antes de renderizá-las e (2) realizar múltiplos renders a cada quadro, aplicá-los
a uma geometria pré-calculada e renderizar esta geometria. O trabalho agora explicará os dois
métodos, e se aprofundará no segundo - que foi o adotado e desenvolvido com sucesso no sistema
testado. Esta etapa foi realizada com orientação de Paul Bourke e a solução encontrada foi baseada
profundamente no sistema desenvolvido pelo mesmo para outros programas (como por exemplo o
Unity 3D® e o Quicktime® da Apple™). Uma outra alternativa não explorada é a utilização de
uma biblioteca chamada Omni Map API desenvolvida pela empresa elumenati. Esta biblioteca
contém um conjunto de funções que podem ser integradas facilmente por programas de interação
em tempo real que utilizem as bibliotecas gráficas openGL ou DirectX para se produzir
visualizações compatíveis com os sistemas que eles comercializam ou sistemas equivalentes.
Entretanto apesar da Omni Map API ser disponibilizada gratuitamente, a sua licença a torna
incompatível com o programa Blender™ e portanto foi desconsiderada neste estudo depois de que
detalhes de sua licença foram esclarecidos após contato inicial realizado com a empresa.
36
37. utilizando GLSL Vertex Shader para reproduzir uma lente olho-de-peixe
Este método é mais complexo, mais técnico, e não pôde ser utilizado neste estudo. Ele
consta aqui para fins de referência do processo de pesquisa ao longo do desenvolvimento deste
trabalho.
Quando se utiliza a biblioteca gráfica openGL, a informação relativa à geometria da cena é
enviada para a placa de vídeo, e lá ela é renderizada - é calculada sua cor final, considerando
textura, luz e outras informações. Esta geometria na realidade é armazenada na forma de triângulos
e quadrados, contendo a posição de cada vértice, a normal da face (sua orientação) e outras
informações. Em outubro de 2004 uma nova versão da linguagem openGL foi lançada,
introduzindo uma linguagem de programação de shading para os vértices (e para os pixels)
chamada GLSL - OpenGL Shading Language. Com GLSL é possível rodar um programa na placa
de vídeo depois que os vértices são enviados para ela e antes da cena ser renderizada. Desta maneira
é possível alterar a posição dos vértices e aplicar efeitos avançados com pouco custo em termos de
processamento (GLSL shaders são extremamente velozes, otimizados e eficientes). Para se criar o
efeito olho-de-peixe, poderia se usar um vertex shader que transformasse (movesse) todos os
vértices de tal modo que o resultado visto por uma câmera ortográfica seja uma projeção olho-de-
peixe. Este método apresenta a vantagem de só se precisar renderizar a cena uma única vez. Porém
alguns de seus problemas tornam ele inviável para se usar no Blender™ - o que não o impede de
ser uma solução exequível em algum outro programa.
O principal problema desta solução, é que uma linha vista em modo perspectivado, não
resulta em uma linha no modo olho-de-peixe. Logo para faces muito grandes, o simples
posicionamento de seus vértices na posição “correta” não é o suficiente, é necessário ainda
subdividir as geometrias de modo a suavizar a sensação de curvatura desejada. Caso esta subdivisão
seja excessiva, a quantidade de vértices e faces a ser enviados para a placa de vídeo será muito
maior, resultando em baixa performance. Uma solução para isso seria considerar o tamanho
37
38. aparente de cada face para que se subdivide-as de acordo.
Um outro problema é que o Blender™ já utiliza glsl vertex shaders em suas geometrias, e
inclusive existem planos para expandir seu uso ainda mais substituindo seu sistema de animação das
geometrias por um sistema de glsl vertex skinning shader como é chamado. Atualmente não é
possível rodar dois vertex shaders para a mesma geometria, o que por si inviabiliza esta solução
para o Blender™. Para um programa que utilize geometrias mais simples (como comumente o são
os de arquitetura) talvez não encontre tanta dificuldade com este método.
utilizando múltiplo renders remapeados para reproduzir uma lente olho-
de-peixe
A outra solução encontrada é conhecida como o método de múltiplo passes. Neste método a
cena é renderizada múltiplas vezes, para compor a imagem final. A principal razão para se utilizar
múltiplos renders, é porque uma câmera sozinha não possui campo de visão suficiente para cobrir
os 180º necessários para um domo imersivo (na verdade alguns domos imersivos trabalham com um
campo visual ainda maior). Esta técnica é uma derivação de uma técnica conhecida como Cube
Map (mapa cúbico) que será explicada no decorrer deste capítulo. Uma vez obtida as imagens, cabe
ao programa a tarefa de remapeá-las para que componham uma imagem olho-de-peixe. Mais uma
vez diferentes alternativas foram exploradas, em especial a possibilidade infrutífera de se utilizar
somente a placa de vídeo para esta operação, a possibilidade de se utilizar malhas pré-calculadas e a
solução final de se gerar esta deformação de forma dinâmica de acordo com as características do
domo imersivo em questão. Por fim entraremos na explicação mais detalhada do método final
utilizado, com especial atenção ao seu processo de desenvolvimento e a avaliação do resultado final
obtido.
limitações da câmera em OpenGL e projeções geométricas
Quando utilizamos uma câmera para navegar em um ambiente virtual, estamos
transformando coordenadas de um sistema tridimensional do ambiente modelado em coordenadas
38
39. bidimensionais do plano da câmera. Em teoria, é possível realizar a projeção geométrica para
mapear um ambiente virtual de acordo com o domo imersivo. Contudo, o acesso aos recursos da
placa de vídeo são restritos e intermediados pela biblioteca gráfica adotada (neste caso o openGL).
No caso do openGL a projeção geométrica é restrita a dois modos: (1) um modo ortogonal - um
sistema isométrico similar onde o tamanho resultante das geometrias independe de sua distância em
relação à câmera, e (2) um modo de câmera perspectivada - onde os objetos ficando menores a
medida que se afastam da câmera. O segundo modo é o que mais se aproxima do resultado
esperado, porém por si só não resolve o problema de projeção esférica. A projeção geométrica linear
(como é conhecido este método) tem uma progressão exponencial a medida que se aproxima de
180º, em termos práticos isso significa que qualquer imagem realizada com uma câmera de campo
de visão acima de 140º já se mostra impraticável para qualquer uso devido ao alto grau de distorção
produzido.
mapa Cúbico - cubemap
A técnica conhecida como Mapa Cúbico consiste na obtenção de seis imagens com câmeras
de campo visual de 90º ortogonais entre si. As câmeras são dispostas como se estivessem dentro de
um cubo, cada uma posicionada no centro do mesmo, e orientada perpendicular a uma de suas
faces. Desta maneira é possível recriar o ambiente de entorno a partir das imagens obtidas.
39
Ilustração 8: Comparação entre imagens produzidas pela câmera openGL e pela olho-de-peixe
40. Técnicas similares são utilizadas por exemplo para tirar fotos panorâmicas a partir de máquinas
fotográficas com lentes de pequena abertura angular. Para um domo imersivo de 180º não é
necessário se obter informação relativa a todo o entorno. Neste caso quatro câmeras são o suficiente
contanto que dispostas do seguinte modo:
• uma câmera rotacionada 45º para a esquerda.
• uma câmera rotacionada 45º para a direita.
• uma câmera rotacionada 45º para a esquerda e 90º para cima.
• uma câmera rotacionada 45º para a esquerda e 90º para baixo.
As câmeras em openGL são na realidade uma matriz matemática de 3x3 com informação
referente a sua localização e sua orientação. Para se rotacionar uma câmera neste sistema deve-se
multiplicar uma matriz que resulte em sua nova orientação. Por se tratar de assunto de cunho muito
mais técnico do que o restante desta abordagem, a explicação de como estas matrizes são calculadas
não é abordado aqui, mas acompanha a parte referente ao código fonte produzido para a solução
final.
Apesar de ser extremamente eficiente, este método de quatro câmeras não pode ser usado
para domos imersivos de campo visual superior a 180º. Neste caso o mínimo de câmeras
40
Ilustração 9: Mapa Cúbico, representação esquemática
41. necessárias é o de cinco câmeras dispostas desta maneira:
• uma câmera orientada para frente, tal qual a câmera original
• uma câmera rotacionada 90º para a esquerda.
• uma câmera rotacionada 90º para a direita.
• uma câmera rotacionada 90º para cima.
• uma câmera rotacionada 90º para baixo.
Com cinco câmeras é possível um campo visual de até 250º completo, e 270º incompleto.
Para se gerar imagens para domos imersivos com um campo visual maior do que 250º seria
necessária uma sexta câmera (orientada 180º para trás). Porém o processo de geração da imagem
para o domo passa a ser muito mais complexo utilizando a técnica empregada. Devido a esta
particularidade e a existirem poucos domos com campo visual desta magnitude este estudo se
resume a suportar domos de 250º.
transformando um Mapa Cúbico em uma esfera
41
Ilustração 10: Transformando um Cubo em uma esfera
42. Uma vez que as imagens necessárias para compor o cubemap são obtidas, é necessário
transformar o cubo em uma esfera (na realidade utilizaremos meio cubo para obtermos a forma
equivalente à tela do domo imersivo, uma meia esfera). O primeiro passo é construir um cubo com
as imagens obtidas formando suas faces. Para um cubo inteiro teríamos então seis faces. O passo
seguinte é normalizar seus vértices. Esta operação seria o equivalente a inflar um cubo de borracha
até ele se transformar em uma bola perfeita.
Se convertermos cada vértice que compõe as faces do cubo por um vetor - uma seta
centralizada no centro do cubo e apontada para o vértice - normalizar os vértices seria o equivalente
a escalonar todas os setas de modo que elas passem a possuir o mesmo tamanho. Se cada face do
cubo for dividida ao meio múltiplas vezes, e cada vértice for normalizado, obteremos centenas de
vértices circundando um centro comum, e equidistantes ao mesmo. Se pudessemos repetir esta
operação infinitas vezes, obteríamos justamente uma esfera.
planificando a esfera
Planificar uma esfera significa converter uma forma tridimensional, em uma análoga
bidimensional. No nosso caso precisamos que a forma final seja semelhante à imagem obtida com a
lente olho-de-peixe, portanto vamos transformar um globo em um disco. Por mais elaborado que
este conceito possa parecer, é uma operação na realidade simples e corriqueira. Quando utilizamos
um mapa-mundi, por exemplo, estamos utilizando na uma versão planificada de um globo terrestre.
De uma forma ou de outra, pode-se acessar toda a informação que estava disposta no globo, e
inclusive pode-se recriar o globo se necessário. Um mapa-mundi é gerado a partir de um tipo de
projeção conhecido como projeção de Mercator. Uma característica deste tipo de projeção é o
exagero com que as regiões polares são representadas e a disposição dos meridianos e paralelos em
forma de grade perpendicular. Outras formas populares de projeção cartográfica são a de Peters,
Ortográfica, Cônica, Moolweide, Goode, Holzel e Azimutal Eqüidistante (Oblíqua e Polar).
Como pode-se ver, a operação de planificar uma esfera é repleta de opções para os mais diversos
42
43. usos. A principal diferença entre elas é relativa à distorção produzida. No nosso caso precisamos
que os meridianos e paralelos da semi-esfera sejam equidistantes quando planificados. Neste caso
portanto precisamos utilizar a Projeção Azimutal Equidistante, que converterá coordenadas
esféricas em coordenadas polares.
Para fins de referência, esta foi a fórmula utilizada:
fórmula planificar_esfera(vertice.XYZ)
{
raio = arco_tangente(√vertice.X² + vertice.Y², vertice.Z²);
raio /= domo_angulo_radiano / 2;
φ = arco_tangente(vertice.Z, vertice.X);
vertice.X = raio * cosseno(φ);
vertice.Y = 0;
vertice.Z = r * seno(φ);
}
43
Ilustração 11: Imagem planificada. Modelo por Mike Pan
44. Apesar da matemática envolvida neste processo aparentar escapar às competências do
arquiteto, ela na verdade em muito pouco se distância de álgebra linear, conteúdo comum de
ementas de vestibular e de disciplinas de sistemas estruturais.
Com este passo, conseguimos produzir uma imagem olho-de-peixe equidistante. Este tipo de
imagem já atende a maior parte dos domos imersivos.
deformando para usar o espelho
Esta etapa é necessária apenas para domos imersivos que utilizem espelhos esféricos. Se a
imagem produzida na etapa anterior for projetada diretamente sobre o espelho, o resultado
percebido no domo será dos mais catastróficos. Por mais que a imagem produzida na etapa anterior
contenha toda a informação necessária para ser visualiza-da no domo imersivo, ela precisa ser pré-
deformada uma vez mais, de modo a compensar a distorção resultando do espelho. Este processo se
assemelha ao processo descrito quando falamos sobre a racionalização da visão humana na arte e
na arquitetura. Nós temos que produzir uma imagem que, quando projetada no domo imersivo,
pareça uma imagem olho-de-peixe correta.
44
Ilustração 12: Deformação de imagem olho-de-peixe para projeção com espelhos
45. Entender a matemática por trás do processo de reflexão espacial em superfícies esféricas
está fora do escopo deste trabalho e da competência do autor. Entretanto é possível solucionar este
problema sem precisar entrar no mérito de seus cálculos. Existe um formato de arquivo muito
popular para domos imersivos com espelhos esféricos, que descreve como que a imagem olho-de-
peixe deve ser remapeada para uma dada instalação em particular. Este arquivo é produzido
considerando-se a resolução do projetor, seu alinhamento (offset), o tamanho do espelho, e a
distância entre eles.
45
46. Testes realizados e avaliação dos resultados
Durante o processo de desenvolvimento do sistema, algumas instalações foram utilizadas
para fins de teste. Vamos agora descrever os diferentes tipos de domos imersivos utilizados, e a
avaliação quanto à adequação da solução encontrada ao sistema em questão.
University of British Columbia - Vancouver, Canadá
O domo imersivo da University de British Columbia foi o primeiro a ser testado, em Janeiro
de 2009. O sistema desenvolvido neste trabalho ainda estava em sua fase preliminar, então não
possível percebe-lo funcionando em sua totalidade.
Este domo imersivo é chamado de domo front-truncated (truncado frontal). O sistema utiliza
46
Ilustração 13: Domo imersivo na University of British Columbia
47. uma bomba de sucção para manter a tela que cobre a sua superfície esférica. Além disso o sistema
de projeção utiliza uma lente olho-de-peixe alinhada com o centro do domo. Este domo é vertical e
truncado em sua quarta parte inferior. Devido à presença do equipamento de projeção no centro do
domo, a melhor posição encontrada para utilizá-lo era sentado no chão ao lado do projetor. Foi um
teste importante para entender como domos truncados funcionam, e constatar as desvantagens deste
sistema de projeção olho-de-peixe.
Societe D'Arts et Technologie - Montreal, Canadá
Para rodar os testes no domo imersivo do SAT, o autor passou três dias em Montreal para se
familiarizar com o equipamento, realizar diferentes testes in loco e discutir as implementações
futuras. O domo imersivo que estava à disposição para os testes era um protótipo em
desenvolvimento. Neste caso se usou um domo horizontal de 180º de campo de visão com três
projetores distribuídos ao longo de seu perímetro. O computador que rodava o passeio virtual é
conectado a uma máquina central, que era responsável por redistribuir para os três projetores a
imagem olho-de-peixe recebida. Este é um sistema bem robusto e de alto investimento. Os
resultados obtidos foram bem satisfatórios.
47
Ilustração 14: Domo imersivo no SAT - foto interna
48. Na próxima etapa da pesquisa, o SAT planeja construir um domo imersivo de 15 metros de
diâmetro, e um campo de visão de 360º horizontal por 220º vertical. Este domo imersivo será
utilizado por um público disposto perto do seu centro, tanto sentado quanto em pé. Depois dos
testes iniciais in loco, a própria equipe do SAT continuou realizando testes para se averiguar a
performance depois das otimizações da solução final. Os resultados foram de tal modo satisfatórios,
que eles decidiram continuar utilizando a Blender Game Engine como motor de jogos final (e não
apenas para as fases de estudos) para as apresentações deles.
University of Plymouth - Londres, Inglaterra
Este é primeiro dos dois locais de testes que o autor não pode estar presente para conduzir os
testes pessoalmente. Neste caso, o responsável pelo domo imersivo da universidade, Pete Carss,
entrou em contato com o autor, interessado nos desdobramentos do projeto, e no seu potencial para
48
Ilustração 15: Domo imersivo no SAT - foto externa
49. a sua instituição. A University of Plymouth concentra um centro de realidades virtuais e ministra
aulas sobre produção de conteúdo interativo para domos imersivos e realidade virtual. Já
ministradas aulas para duas plataformas de produção de jogos compatíveis com domos (Unity3D e
Panda3D) e eventualmente eles tinham interesse em expandir seu curso para ministrar Blender
Game Engine também, dado que agora esta também se tornou compatível com sua tecnologia. As
suas instalações se assemelham em muito a um planetário convencional, com um domo imersivo
horizontal inclinado 20º em relação ao chão.
49
Ilustração 16: Domo imersivo na University of Plymouth
50. Este é um domo imersivo de 180º rear-truncated, pois ao contrário do domo da universidade
de UBC a parte completa do domo é sua parte inferior, enquanto que a superior é truncada. Foi
graças à solicitação por parte do Pete Carss que uma opção para se configurar a inclinação (tilt) da
câmera no ambiente virtual foi implementada. Deste modo fica mais fácil utilizar apresentações
desenvolvidas para outros domos imersivos em um domo inclinado.
University of Western Australia - Perth, Australia
O último teste foi realizado com a ajuda do professor Paul Bourke. O centro de pesquisa
onde ele continua aprimorando e desenvolvendo a técnica do uso de espelhos esféricos possui um
domo imersivo conhecido como iDome. Este sistema utiliza um domo imersivo vertical front-
truncated com 180º de campo de visão, e a quarta parte truncada na parte inferior do mesmo. A
grande particularidade deste sistema é a disposição do projetor do lado de trás do domo encaixado
em um buraco feita em sua parte inferior. Deste modo o projetor consegue focar no espelho esférico
de 60cm, localizado na prumada do domo. Quem utiliza o domo fica confortavelmente sentado
com a cabeça ocupando o lugar do seu centro, e o teclado e mouse acessíveis em uma mesa
ligeiramente atrás do espelho (para não produzir sombras).
50
Ilustração 17: Domo imersivo na University of Western Australia
51. Este teste foi realizado na etapa final de desenvolvimento do projeto, em meados de junho, e
após ajustes feitos no código depois dos primeiros testes, foi-se dado um parecer positivo ao
sistema desenvolvido. Este sistema é muito interessante para arquitetura, pela sua escala ser mais
portável (próprio de domos imersivos verticais) e pelo seu custo reduzido de implementação, dado a
engenhosidade da solução com espelhos esféricos.
implementação final
A etapa dos testes foi de fundamental importância para o desenvolvimento deste trabalho.
Foi possível identificar diversas demandas próprias de instalações reais, ao mesmo tempo que
identificava-se problemas a tempo de serem sanados. Uma vez passada esta fase, a implementação
na Blender Game Engine estava oficialmente pronta. Apesar desta ferramenta ter sido usada como
plataforma de estudo e viabilidade, ela tem um público próprio, público este também interessado na
expansão de sua ferramenta para novas possibilidades. Portanto as alterações em seu código foram
submetidas para revisão e por fim incluídas na versão oficial do programa (a partir de sua versão
2.49 lançada dia 30 de maio de 2009).
51
52. Conclusão do trabalho
O trabalho que se iniciou em dezembro de 2008, encontra seu desfecho em julho de 2009.
Após sete meses de trabalho e pesquisa, logrou-se êxito na tentativa de se expandir um sistema
imersivo para seu uso em arquitetura e urbanismo. No primeiro momento isto já permite que
estudantes e arquitetos familiarizados com o programa Blender™ possam utilizar esta ferramenta
em domos imersivos. Num passo seguinte é possível que a contribuição para a divulgação desta
tecnologia permita que ela se torne cada vez mais acessível a todos, arquitetos e o público em geral.
É possível em um futuro próximo que instalações como os planetários das cidades tenham seus usos
revertidos para atender também à apresentação de projetos públicos e discussões sobre o âmbito das
cidades. Ferramentas que potencializam a eficiência da tomada de discussão na escala do urbano, de
encontro com as novas políticas de gestão urbana e participação coletiva.
Na escala do pequeno projeto, ou de um público individual, a solução potencial é ainda mais
ampla. Um domo imersivo instalado dentro de uma universidade pode contribuir com cada uma das
categorias da tríade acadêmica - o ensino a pesquisa e a extensão. A área de pesquisa tem um campo
fértil para explorar o seu uso. A possível integração com outros cursos, a expansão de suas
funcionalidades e o número de programas adaptados para esta mídia seria apenas alguns dos
exemplos de seu uso potencial. A área de extensão e ensino universitário talvez consiga aproveitar o
equipamento ainda mais. Como um complemento às aulas de história de arquitetura às disciplinas
de projeto, as possíveis aplicações de uma ferramenta imersiva para passeios virtuais são as mais
variadas. E com uma ferramenta como esta acessível a uma geração já acostumada a consumir
tecnologia, seus desdobramentos são sem dúvidas imprevisíveis.
Por fim, o processo de graduação em arquitetura e urbanismo que começou em 2003, se
encerra em 2009. A amplitude de possibilidades de atuação do profissional arquiteto urbanista está
atrelada às diversas esferas de conhecimento que lhe são apresentados durante sua formação. Este
52
53. trabalho neste sentido, ao contrário de fugir às atribuições do arquiteto, se propõe a coroar esta
diversidade através de sua linha de desenvolvimento artístico, técnico e humano. Talvez este
caminho seja, sim, tangente e oblíquo ao percurso esperado do estudante futuro profissional. Ou,
como o é a aposta do autor, talvez seja simplesmente um caminho que pavimenta-se a medida que
se percorresse. Pois criar o seu próprio mercado de trabalho transforma-se em tarefa rotineira para
quem faz da criação seu dia-a-dia profissional.
encaminhamentos
Este trabalho apresentou uma tecnologia conhecida como domo imersivo, analisou seu
potencial para o uso em arquitetura e desenvolveu uma solução para uma plataforma específica, a
Blender Game Engine. Uma vez que a solução se mostrou eficiente, um encaminhamento possível e
desejável para este trabalho, é a aplicação desta pesquisa em outros programas da área de
arquitetura. Existem cada vez mais programas integrando as funções de projeto e de visualização
arquitetônica. Quanto mais conseguirmos tornar-los ferramentas de comunicação visual mais
eficientes, melhor será a qualidade de nossos projetos, nossos espaços e nossas cidades. Se este
trabalho tiver de alguma forma contribuído nesta direção, ele terá alcançado seu objetivo.
53
54. Bibliografia
• AZEVEDO, Eduardo. Computação Gráfica - Teoria e Prática. Rio de Janeiro,
Elsevier, 2003.
• BODIN, Bertrand [et al.]. Montagem de fotos panorâmicas. Porto Alegre, Bookman,
2007.
• BOURKE, Paul D., Immersive gaming: a low cost projection environment. Dime
2006.
• BOURKE, Paul D., Using a spherical mirror for projection into immersive
environments. Graphite (ACM Siggraph), Dunedin Nov/Dez 2005.
• IVINS, William M. Ivins, Jr. On the rationalization of sight: With an examination of
three renaissance texts on perspective. New York, Da Capo Press, 1973
• SHREINER, Dave [et al.], The OpenGL Programming Guide - The Redbook.
Addison-Wesley, 1997
• SPARACINO, Flavia. Narrative Spaces: bridging architecture and entertainment vi.a
interactive technology. MIT Media Lab
54
55. Glossário
Arquivo Vetorial - um formato de arquivo que armazena elementos gráficos como fórmulas
matemáticas. Isto permite que os arquivos sejam visualizados em grandes resoluções sem perda de
qualidade.
Biblioteca - arquivos com um conjunto de funções prontas para serem usadas em um programa.
Código Livre - um termo que refere-se a programas que utilizam alguma licença aberta
(comumente GPL, BSD ou MIT)
Formato aberto - um formato de arquivo cujas especificações são definidas a partir de um
conjunto de normas documentadas, compartilhadas e de livre uso.
GLSL Vertex Shader - um programa que é executado dentro da placa de vídeo e é responsável
pelo cálculo da posição de um conjunto de vértices a cada quadro antes de eles serem renderizados.
Linguagem de programação - um conjunto de sintaxe que define como se escrever um texto
para ser interpretado pelo computador na criação de programas.
Mapa de Bits/Bitmap - uma espécie de arquivo que ao contrário de arquivos vetoriais
armazena a informação das imagens diretamente como pontos coloridos. O número de pontos
define a resolução da imagem.
Maquete Eletrônica - um modelo tridimensional de um ambiente arquitetônico desenhado no
computador
Material - termo utilizado em computação gráfica que compreende as informações de reflexão,
refração, e cor de um objeto,
Normalização de vetores - operação matemática que consiste em se dividir os componentes do
55
56. vetor pelo seu tamanho (módulo). O módulo de um vetor é determinado pela raiz quadrada da some
do quadrado de seus componentes.
Script - um arquivo de texto que complementa/expande as funcionalidades existentes de um
programa.
Tempo Real - este termo é usado para se referir a aplicações que permitem a interação com o
usuário com taxas de atualização a partir de 12 ou 30 quadros por segundo. Os exemplos mais
famosos deste tipo de aplicações são jogos eletrônicos (video games).
Textura - uma imagem que é utilizada como cor de um material.
56
57. Anexos
Anexos
Anexo I: carta da Society for Arts and Technology referente ao comprimento do
desenvolvimento do trabalho...................................................................................................56
Anexo II: documento que suporta o método por trás da tecnologia desenvolvida..................57
Anexo III: alterações no script de importação de arquivos OBJ no Blender™.......................59
Anexo IV: código fonte do recurso de domo na Blender Game Engine..................................60
57
58. Anexo I: carta da Society for Arts and Technology referente ao
comprimento do desenvolvimento do trabalho.
Montreal – 2009 April 28th
[SAT] Society for Arts and Technology
Research & Development Department
www.sat.qc.ca
In the name of the [SAT] Society for Arts and Technology, I wish to express my
appreciation for the work of Dalai Felinto. His work was very helpful in our immersive
research program. M. Felinto played a major role, programming a fisheye camera to the
Blender Game Engine (BGE). This expansion of the BGE brings interactive physical
simulations and an easy to use program development interface to immersive video
environments (such as digital planetaria and spherical visualisation displays).
As Blender is free software, these tools have been made freely available to the world, and
specialy to artists and to other « open source » developers who could bring this feature to
another level in further development programs.
Many thanks to Dalai Felinto for developing this amazing tool!
If you have any questions, or would like to see examples of how our organization has
benefited from the BGE fisheye camera, please do not hesitate to contact me.
Thank you.
Louis-Philippe St-Arnault
Director - Production and Immersive Development
SAT - Society for Arts and Technonogy
Tel :: 514.844.2033 #212
Mob :: 514.916.4265
Fax :: 514.982.6093
Mail :: lp@sat.qc.ca
Web :: www.sat.qc.ca
58
59. Anexo II: documento que suporta o método por trás da tecnologia
desenvolvida.
Jogos em Blender no iDome
escrito por Paul Bourke
Implementação por Dalai Felinto: dfelinto@yahoo.com
Suportado pela SAT (Society for Arts and Technology) através do SAT Metalab immersion research
program.
Contribuição de códigos-fonte e testes por Paul Bourke
Abril 2009
Este documento serve de suporte ao uso de projeções fisheye [olho de peixe] e warped
fisheye [olho de peixe com deformação] na engine interativa do Blender (Blender Game Engine).
Apesar dos exemplos mostrados aqui utilizarem um iDome, a técnica é acessível à qualquer
superfície orientada semi-esférica, incluindo o tradicional domo encontrado em planetários. O
suporte foi incluído na última atualização do Blender, na versão 2.49. O método empregado utiliza
um algoritmo para processamento da textura em múltiplos passos como descrito aqui. Em resumo
isso envolve renderizar a cena 4 vezes e colocar cada uma das imagens em uma malha desenhada
especialmente de modo que, quando visto de uma câmera ortográfica, resulte em uma projeção
fisheye. Para se obter uma projeção fulldome [de domo completo] usando um espelho esférico ao
invés de lentes olho de peixe, se utiliza um método de deformação de imagem como o descrito aqui.
A implementação em Blender suporta diretamente projeção fisheye (para projetores com lente olho
de peixe) assim como sistemas que requeiram mapas de deformação (warped fisheye images). A
solução através de mapas de deformação foi desenvolvida para suportar sistemas baseados em
espelhos esféricos (ilustrado ao longo desta página), sistemas truncados, e suporte para lentes olho
de peixe de função radial não linear.
59
60. Apesar das imagens no iDome parecerem distorcidas, este é um efeito da posição (incorreta)
da câmera. Quando se senta no meio da semi-esfera a cena parece natural, ou seja, todas as linhas
retas se parecem retas. É por isso que em ambientes de projeção estereoscópica ou imersiva as
imagens só são consideradas corretas à partir de um único e específico ponto de observação.
Na maior parte dos programas que suportam espelhos esféricos, primeiramente cria-se uma
imagem fisheye através de algoritmos próprios. Esta imagem é então mapeada de acordo com uma
malha desenhada especificamente para a instalação em particular. Desta maneira, uma vez criada a
malha de distorção para um equipamento, esta pode ser usada por qualquer programa que a suporte.
É importante lembrar que o programa não precisa, portanto, ser configurado de acordo com as
particularidades de uma dada instalação. Isso é exatamente o papel da malha de deformação,
independente do programa interativo usado. A implementação em Blender não é diferente. A
primeira imagem abaixo mostra uma grade polar (deformada) sobreposta a uma imagem fisheye
também deformada. Uma vez projetada, a imagem resultante no domo surge sem quaisquer
distorções ou deformações aparentes.
As imagens e a versão original em inglês encontram-se no documento online:
http://local.wasp.uwa.edu.au/~pbourke/miscellaneous/domemirror/BlenderiDome/
60
61. Anexo III: alterações no script de importação de arquivos OBJ no
Blender™
Index: import_obj.py
===================================================================
--- import_obj.py (revision 20982)
+++ import_obj.py (revision 21175, 21230 and 21232)
@@ -125,6 +125,16 @@
image= obj_image_load(imagepath, DIR, IMAGE_SEARCH)
has_data = image.has_data
texture.image = image
+
+ if not has_data:
+ try:
+ # first time using this image. We need to load it first
+ image.glLoad()
+ except:
+ # probably the image is crashed
+ pass
+ else:
+ has_data = image.has_data
# Adds textures for materials (rendering)
if type == 'Kd':
@@ -208,6 +218,7 @@
context_material.setIOR( max(1, min(float(line_split[1]), 3))) # Between 1 and 3
elif line_lower.startswith('d') or line_lower.startswith('tr'):
context_material.setAlpha(float(line_split[1]))
+ context_material.mode |= Material.Modes.ZTRANSP
elif line_lower.startswith('map_ka'):
img_filepath= line_value(line.split())
if img_filepath:
61
62. Anexo IV: código fonte do recurso de domo na Blender Game Engine
Estes dois arquivos em anexo - KX_Dome.cpp e KX_Dome.h - foram incorporados ao
código fonte do Blender™ em sua versão 2.49 que teve seu lançamento oficial no dia 30 de maio de
2009. Eles fazem nexo dentro de um contexto maior - o código fonte completo do Blender™ - que
encontra-se disponível para download no site da Blender Fundation - www.blender.org.
Ambos foram licenciados sobre a licença GNU Lesser General Public License versão 2. Em
termos gerais, a GPL garante o contínuo acesso ao código-fonte e baseia-se em 4 princípios:
• A liberdade de executar o programa, para qualquer propósito
• A liberdade de estudar como o programa funciona e adaptá-lo para as suas necessidades.
• A liberdade de redistribuir cópias do programa de forma comercial ou não comercial.
• A liberdade de aperfeiçoar o programa, e liberar os seus aperfeiçoamentos.
62
63. /* $Id: KX_Dome.h 20244 2009-05-17 20:37:13Z dfelinto $
-----------------------------------------------------------------------------
This program is free software; you can redistribute it and/or modify it under
the terms of the GNU Lesser General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any later
version.
This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License along with
this program; if not, write to the Free Software Foundation, Inc., 59 Temple
Place - Suite 330, Boston, MA 02111-1307, USA, or go to
http://www.gnu.org/copyleft/lesser.txt.
Contributor(s): Dalai Felinto
This source uses some of the ideas and code from Paul Bourke.
Developed as part of a Research and Development project for SAT - La Société des arts technologiques.
-----------------------------------------------------------------------------
*/
#if !defined KX_DOME_H
#define KX_DOME_H
#include "KX_Scene.h"
#include "KX_Camera.h"
#include "DNA_screen_types.h"
#include "RAS_ICanvas.h"
#include "RAS_IRasterizer.h"
#include "RAS_IRenderTools.h"
#include "KX_KetsjiEngine.h"
#include <BIF_gl.h>
#include <vector>
63
64. #include "MEM_guardedalloc.h"
#include "BKE_text.h"
//Dome modes: limit hardcoded in buttons_scene.c
#define DOME_FISHEYE 1
#define DOME_TRUNCATED_FRONT 2
#define DOME_TRUNCATED_REAR 3
#define DOME_ENVMAP 4
#define DOME_PANORAM_SPH 5
#define DOME_NUM_MODES 6
/// class for render 3d scene
class KX_Dome
{
public:
/// constructor
KX_Dome (
RAS_ICanvas* m_canvas,
/// rasterizer
RAS_IRasterizer* m_rasterizer,
/// render tools
RAS_IRenderTools* m_rendertools,
/// engine
KX_KetsjiEngine* m_engine,
short res,
short mode,
short angle,
float resbuf,
short tilt,
struct Text* warptext
);
/// destructor
virtual ~KX_Dome (void);
//openGL checks:
64
65. bool dlistSupported;
bool fboSupported;
//openGL names:
GLuint domefacesId[7]; // ID of the images -- room for 7 images, using only 4 for 180º x 360º
dome, 6 for panoramic and +1 for warp mesh
GLuint dlistId; // ID of the Display Lists of the images (used as an offset)
typedef struct {
double u[3], v[3];
MT_Vector3 verts[3]; //three verts
} DomeFace;
//mesh warp functions
typedef struct {
double x, y, u, v, i;
} WarpMeshNode;
struct {
bool usemesh;
int mode;
int n_width, n_height; //nodes width and height
int imagesize;
int bufferwidth, bufferheight;
GLuint fboId;
vector <vector <WarpMeshNode> > nodes;
} warp;
bool ParseWarpMesh(STR_String text);
vector <DomeFace> cubetop, cubebottom, cuberight, cubeleft, cubefront, cubeback; //for fisheye
vector <DomeFace> cubeleftback, cuberightback; //for panorama
int nfacestop, nfacesbottom, nfacesleft, nfacesright, nfacesfront, nfacesback;
int nfacesleftback, nfacesrightback;
int GetNumberRenders(){return m_numfaces;};
65
67. int canvaswidth;
int canvasheight;
protected:
int m_drawingmode;
int m_imagesize;
int m_buffersize; // canvas small dimension
int m_numfaces; // 4 to 6 depending on the kind of dome image
int m_numimages; //numfaces +1 if we have warp mesh
short m_resolution; //resolution to tesselate the mesh
short m_mode; // the mode (truncated, warped, panoramic,...)
short m_angle; //the angle of the fisheye
float m_radangle; //the angle of the fisheye in radians
float m_resbuffer; //the resolution of the buffer
short m_tilt; //the dome tilt (camera rotation on horizontal axis)
RAS_Rect m_viewport;
MT_Matrix4x4 m_projmat;
MT_Matrix3x3 m_locRot [6];// the rotation matrix
/// rendered scene
KX_Scene * m_scene;
/// canvas
RAS_ICanvas* m_canvas;
/// rasterizer
RAS_IRasterizer* m_rasterizer;
/// render tools
RAS_IRenderTools* m_rendertools;
/// engine
KX_KetsjiEngine* m_engine;
};
#endif
67
