dalai_tfg_domoimersivoarq

136 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
136
No SlideShare
0
A partir de incorporações
0
Número de incorporações
5
Ações
Compartilhamentos
0
Downloads
2
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

dalai_tfg_domoimersivoarq

  1. 1. 1
  2. 2. À minha família, aos meus amigos, ao meu país. A Deus (e até breve) 2
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  66. 66. void RenderDome(void); void RenderDomeFrame(KX_Scene* scene, KX_Camera* cam, int i); void BindImages(int i); void SetViewPort(GLuint viewport[4]); void CalculateFrustum(KX_Camera* cam); void RotateCamera(KX_Camera* cam, int i); //Mesh creation Functions void CreateMeshDome180(void); void CreateMeshDome250(void); void CreateMeshPanorama(void); void SplitFace(vector <DomeFace>& face, int *nfaces); void FlattenDome(MT_Vector3 verts[3]); void FlattenPanorama(MT_Vector3 verts[3]); //Draw functions void GLDrawTriangles(vector <DomeFace>& face, int nfaces); void GLDrawWarpQuads(void); void Draw(void); void DrawDomeFisheye(void); void DrawEnvMap(void); void DrawPanorama(void); void DrawDomeWarped(void); //setting up openGL void CreateGLImages(void); void ClearGLImages(void);//called on resize bool CreateDL(void); //create Display Lists void ClearDL(void); //remove Display Lists bool CreateFBO(void);//create FBO (for warp mesh) void ClearFBO(void); //remove FBO void CalculateCameraOrientation(); void CalculateImageSize(); //set m_imagesize 66
  67. 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

×