VISUALIZAÇÃO DE MODELOS VTK UTILIZANDO WEBGL:UM ESTUDO EXPERIMENTAL

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ – UTFPR PROGRAMA DE PÓS-GRADUAÇÃO EM PROJETO E DESENVOLVIMENTO DE

SISTEMAS BASEADOS EM OBJETOS PARA AMBIENTE INTERNET

JAN PALACH VICENTE CRUZ DA SILVA

VISUALIZAÇÃO DE MODELOS VTK UTILIZANDO WEBGL:UM ESTUDO EXPERIMENTAL

MONOGRAFIA DE ESPECIALIZAÇÃO

MEDIANEIRA

2011

2

JAN PALACH VICENTE CRUZ DA SILVA

VISUALIZAÇÃO DE MODELOS VTK UTILIZANDO WEBGL:UM ESTUDO EXPERIMENTAL

Trabalho de Conclusão de Curso apresentado à Universidade Tecnológica Federal do Paraná – Câmpus Medianeira, como requisito parcial à obtenção do grau de Especialista em Projeto e Desenvolvimento de Sistemas Baseados em Objetos para Ambiente Internet. Orientador: Prof. M.Sc. Fernando Schütz

MEDIANEIRA 2011

TERMO DE APROVAÇÃO

Visualização de Modelos VTK utilizando WebGL: Um estudo experimental

Por

Jan Palach Vicente Cruz da Silva

Esta monografia foi apresentada às 19:00h do dia 10 de outubro de 2011

como requisito parcial para a obtenção do título de ESPECIALISTA, no curso de

Especialização em Projeto e Desenvolvimento de Sistemas baseados em Objetos

para Ambiente Internet, da Universidade Tecnológica Federal do Paraná, Câmpus

Medianeira. O acadêmico foi arguido pela Banca Examinadora composta pelos

professores abaixo assinados. Após deliberação, a Banca Examinadora considerou

o trabalho aprovado.

Prof. Me. Fernando Schütz

Orientador

UTFPR – Campus Medianeira

Prof. Me. Pedro Luiz de Paula Filho

Convidado


Prof. Me. Juliano Rodrigo Lamb

Convidado


Prof. Me. Fernando Schütz

Coordenador do Curso de Especialização


A FOLHA DE APROVAÇÃO ASSINADA ENCONTRA-SE NA DIRETORIA DE PÓS-GRADUAÇÃO DA UTFPR CÂMPUS MEDIANEIRA

Ministério da Educação Universidade Tecnológica Federal do Paraná

Diretoria de Pesquisa e Pós-Graduação Especialização em Projeto e Desenvolvimento de Sistemas baseados

em Objetos para Ambiente Internet

UTFPR – DIRPPG Av. Brasil, 4232 – Pq Independência

85884000 – Medianeira – PR www.utfpr.edu.br/medianeira

+55(45) 3240-8074

DEDICATÓRIA

À minha esposa Anicieli.

5

AGRADECIMENTOS

Em especial à minha esposa Anicieli que me dá apoio e me ajuda a enfrentar os desafios da vida.

Aos meus pais pela educação e cuidados na minha criação. A “turma B”, pelos momentos de risada, e especialmente pelas trocas de

datas dos eventos que ocorriam aos sábados. Ao professor Rodrigo Luis de Souza da Silva, por responder meus e-mails e

questionamentos sobre computação gráfica, isso foi fundamental para a conclusão do estudo.

Ao professor Everton que no início da caminhada me brindou com seu ponto de vista ímpar, sobre as versões iniciais de código e do texto.

Ao professor Fernando Schütz, por orientar este trabalho apontando as devidas correções.

A Blizzard Entertainment por ter criado clássicos como StarCraft e Diablo. A Steve Jobs, por fazer da computação pessoal o que ela é hoje, e

reinventar a tablet e o smartphone. A Apple, por fazer computadores fantásticos e um sistema operacional digno de respeito e admiração.

6

RESUMO

SILVA, Jan. Visualização de modelos VTK utilizando WebGL: um estudo experimental. 2011. 67 f. Monografia (Especialização em Desenvolvimento de Sistemas Orientados a Objeto) – Programa de Pós-Graduação em Tecnologia, Universidade Tecnológica Federal do Paraná. Medianeira, 2011.

Este estudo apresenta o uso da tecnologia WebGL para visualização de modelos VTK Polygonal Data através da Web, sem a necessidade de instalação de plug-ins em navegadores. Apresenta também ferramentas, métodos e conceitos que integrados, fornecem um meio para construção de um protótipo de visualização de modelos VTK Polygonal Data na Web. O estudo foi desenvolvido com base em pesquisas sobre as diferentes tecnologias presentes no processo de construção do protótipo implementado neste estudo, desde a definição do modelo de dados e a utilização de um framework Web, até o uso do framework SceneJS na construção da representação gráfica. A aplicação das tecnologias pesquisadas, permitiu a implementação do protótipo de visualização de modelos VTK Polygonal Data através da Web.

Palavras-chave: Plug-ins. SceneJS. HTML5. Datasets. Python.

7

ABSTRACT

SILVA, Jan. Visualization of the VTK models using WebGL: an experimental study. 2011. 67 f. Monografia (Especialização em Desenvolvimento de Sistemas Orientados a Objeto) – Programa de Pós-Graduação em Tecnologia, Universidade Tecnológica Federal do Paraná. Medianeira, 2011.

This study presents an usage of WebGL technology for VTK Polygonal Data visualization over the Web, without need for installing browser plugins. It also shows tools, methods and concepts that, integrated, provide a way for creating a prototype for visualizing VTK Polygon Data models over the Web. The study was developed based in researches about different technologies involved in the process of creating the prototype that was implemented in this study, since data model definition and utilization of a Web framework, to using the SceneJS framework in the construction of graphical representation. The application of the researched technologies allowed implementing the prototype of VTK Polygonal Data model visualization over the Web.

Keywords: Plug-ins. SceneJS. HTML5. Datasets. Python.

8

LISTA DE ABREVIATURAS E SIGLAS

API Application Programming Interface.

CG Computação Gráfica.

CAD Computer Aided Designed.

CS Cliente/Servidor.

CM Camada Modelo.

CC Camada Controladora.

CA Camada de Apresentação.

CSV Comma Separated Values.

FW Framework.

GPU Graphic Processing Unit.

HeMoLab Hemodynamics Modelling Laboratory.

HTML5 Hypertext Markup Language 5.

HTTP Hypertext Transfer Protocol.

HTML Hypertext Markup Language.

ISO International Organization for Standardization.

JSON JavaScript Object Notation.

JTE Jinja Template Engine.

MVC Model View Controller.

MER Modelo Entidade Relacionamento.

OpenGL Open Graphic Library.

SQL Structured Query Language.

TE Template Engine.

URL Uniform Resource Locator.

W3C World Wide Web Consortium.

WebGL Web Graphic Library.

XML Extensible Markup Language.

9

SUMÁRIO

1 INTRODUÇÃO ....................................................................................................... 10 1.2.1 Objetivo Geral ................................................................................................... 11 1.2.2 Objetivos Específicos ....................................................................................... 12 1.3 JUSTIFICATIVA ................................................................................................... 12 1.4 ESCOPO DO TRABALHO ................................................................................... 13 2 FUNDAMENTAÇÃO TEÓRICA ............................................................................. 15 2.1 COMPUTAÇÃO GRÁFICA .................................................................................. 15 2.2 WEBGL ................................................................................................................ 16 2.3 HTML5 ................................................................................................................. 17 2.4 LINGUAGEM DE PROGRAMAÇÃO JAVASCRIPT ............................................. 17 2.5 FRAMEWORK SCENEJS .................................................................................... 18 2.6 BIBLIOTECA VTK ................................................................................................ 21 2.7 LINGUAGEM DE PROGRAMAÇÃO PYTHON .................................................... 23 2.8 FRAMEWORK FLASK ......................................................................................... 23 2.9 ORM SQLALCHEMY ........................................................................................... 24 3 PROCEDIMENTOS METODOLÓGICOS ............................................................... 25 3.1 LEVANTAMENTO E ANÁLISE BIBLIOGRÁFICA ................................................ 25 3.2 TIPO DA PESQUISA ............................................................................................ 25 3.3 ARQUITETURA ................................................................................................... 25 3.3.1 Camada Modelo ............................................................................................... 27 3.3.2 Camada Controladora ...................................................................................... 29 3.3.3 Camada de Apresentação ................................................................................ 31 3.4 ESTRUTURA DO PROTÓTIPO ........................................................................... 33 3.5 DIAGRAMA DE CASOS DE USO ........................................................................ 34 3.6 DESCRIÇÃO DOS CASOS DE USO ................................................................... 35 3.7 MODELOS VTK ................................................................................................... 40 3.8 TIPO DE DATASET VTK ABORDADO NO PROJETO ........................................ 41 3.9 LEITURA DE MODELOS VTK COM PYVTK ........................................................ 42 3.10 RENDERIZANDO O MODELO VTK USANDO SCENEJS ................................. 48 3.11 INTERAGINDO COM O MODELO ..................................................................... 55 3.11.1 Transformações geométricas ......................................................................... 55 3.11.1.1 Rotação ....................................................................................................... 55 3.11.1.2 Translação ................................................................................................... 56 3.11.1.3 Escala .......................................................................................................... 57 4 RESULTADOS E DISCUSSÕES ........................................................................... 59 4.1 LOGIN .................................................................................................................. 59 4.2 REGISTRO NO SISTEMA ................................................................................... 60 4.3 PÁGINA PRINCIPAL ............................................................................................ 60 4.4 PÁGINA DE VISUALIZAÇÃO E INTERAÇÃO COM O MODELO ........................ 61 5. CONSIDERAÇÕES FINAIS .................................................................................. 64 REFERÊNCIAS ......................................................................................................... 65

10

1 INTRODUÇÃO

Segundo a ISO – (International Organization for Standardization), A

definição de computação gráfica é: “Um conjunto de ferramentas e técnicas para

converter dados de ou para um dispositivo gráfico através do computador”. (CONCI;

AZEVEDO, 2003, p. 03)

Foram realizados grandes avanços na área de CG (Computação Gráfica)

graças à evolução do hardware nos últimos anos, o que permitiu a evolução de

áreas como a realidade aumentada, área que visa melhorar a interação dos

humanos com ambientes virtuais. Com o avanço constante da plataforma Web, os

sistemas de CG começam uma migração do paradigma desktop no qual estavam

inseridos, para o ambiente Internet. As Applets1 possibilitaram alguns dos primeiros

experimentos na visualização de gráficos tridimensionais em navegadores. Houve

também o surgimento da tecnologia Flash da Adobe, que hoje permite acesso à

GPU2, porém para ambos os casos se faz necessária a instalação de plug-ins.

Uma solução que vem surgindo e que promete se tornar padrão para o uso

de CG na Web através de browsers é a WebGL, que consiste de uma biblioteca

JavaScript e de código aberto que permite acesso à GPU e exibe elementos gráficos

complexos como modelos tridimensionais. A WebGL funciona em conjunto com o

elemento Canvas do HTML5 (Hypertext Markup Language 5). O elemento Canvas

permite a criação de um contexto para geração de cenas e criação de objetos

tridimensionais e bidimensionais. O HTML5 vem sendo implementado por um

consórcio entre empresas como Apple, Microsoft, Google, Adobe, e tem por objetivo

se tornar o novo padrão para construção de páginas Web.

1 Applets são um tipo especial de programas Java, que um navegador com Java habilitado, pode baixar e rodar dentro de uma página web. (ORACLE, 2011) 2 Abreviatura para Graphics Processing Unit. (OpenGL, A, 2009)

11

1.1 PROBLEMA DA PESQUISA

Antes do surgimento da tecnologia WebGL e HTML5, era necessária a

instalação de plug-ins para visualização de elementos gráficos avançados como

figuras tridimensionais por meio de um navegador através da Web. Foi detectada a

necessidade de possibilitar a fácil visualização de modelos bi e tridimensionais por

meio da Internet sem a necessidade de instalação de plug-ins em navegadores ou

qualquer tipo de cliente desktop.

Na área de visualização científica existem diversos formatos que podem ser

utilizados na visualização de dados e simulações, dentre eles os modelos VTK.

Com base no problema acima, identificou-se o seguinte enunciado: Como

possibilitar a visualização de modelos VTK por meio de navegadores Web sem a

instalação de plug-ins?

1.2 OBJETIVOS

Este trabalho, que trata sobre novas formas de apresentação de modelos

tridimensionais na Internet e sobre Computação Gráfica, tem seus objetivos

descritos nas seções que seguem.

1.2.1 Objetivo Geral

Desenvolver um protótipo de ferramenta Web para visualização de modelos

VTK do tipo VTK Polydata, diretamente no navegador sem a necessidade de

instalação de plug-ins.

12

1.2.2 Objetivos Específicos

a) analisar a viabilidade do uso da WebGL por meio do framework SceneJS

na visualização de modelos VTK Polydata através da Web;

b) criar uma Representação Gráfica (RG), seguindo a estrutura definida pelo

framework SceneJS.

c) implementar mecanismos para interação do usuário com o modelo

utilizado na visualização, fazendo uso do framework SceneJS;

1.3 JUSTIFICATIVA

O ambiente Web fornece um excelente meio para difusão de conhecimento

e informação. Cada vez mais pode-se ver sistemas de computação migrando do

paradigma desktop para Web. A CG já iniciou sua jornada na mudança de

paradigma. Nos dias atuais já aparenta ser possível a execução de jogos

sofisticados que fazem uso de recursos avançados das principais placas de vídeo do

mercado através de um navegador, ou mesmo visualizar o modelo tridimensional

proveniente de algum estudo médico sem a necessidade de plug-ins.

A justificativa deste projeto, é prover um protótipo de visualização de

modelos VTK em ambiente Internet utilizando tecnologias suportadas por grande

parte dos navegadores atuais, e sem a necessidade de instalação de plug-ins,

resultando em praticidade no uso do sistema e menos problemas relacionados à

segurança de plug-ins de terceiros.

13

1.4 ESCOPO DO TRABALHO

Foram necessárias algumas restrições no desenvolvimento do experimento

proposto por este trabalho. O experimento abordou apenas um tipo de modelo VTK,

o VTK Polygonal Data.

É possível que um modelo VTK seja composto por diversos tipos de

primitivas gráficas, como por exemplo, triângulos, quadrados, linhas, pontos, primas,

etc. O VTK é rico em primitivas gráficas que utilizadas em conjunto podem formar

figuras mais complexas. A WebGL apresenta apenas as primitivas PONTO, LINHA e

TRIÂNGULO. Um modelo gráfico na WebGL pode ser composto por apenas um dos

tipos de primitivas citadas, esta limitação está diretamente ligada a como é

construída a conectividade dos pontos que formam a geometria dos objetos.

O protótipo executa apenas em navegadores com suporte à WebGL, e em

alguns casos este suporte deverá ser ativado pelo usuário nas preferências do

navegador, como é o caso do navegador Safari 5.1 disponível no Mac OS X Lion.

Não foi foco deste trabalho avaliar a performance do experimento

comparando-o com alguma solução já existente no mercado.

A viabilidade do experimento está ligada a fatores externos que podem atuar

como limitadores, como por exemplo a velocidade de conexão utilizada para o

tráfego de dados, limitações da tecnologia JavaScript no que diz respeito ao

processamento de grandes quantidades de dados e diferenças na implementação

do JavaScript entre navegadores. Esses fatores não comprometem o estudo, mas

podem restringir por exemplo o tamanho do arquivo de modelo VTK a ser utilizado.

Apenas arquivos legados do VTK foram analisados e apenas no formato

ASCII, muito embora as ferramentas utilizadas na implementação do protótipo

suportem arquivos legados em formato binário.

14

1.5 DIVISÃO DO TRABALHO

Este trabalho está dividido em 5 capítulos.

O capítulo 1 é uma breve introdução sobre o assunto do projeto,

apresentando a justificativa e objetivos do projeto.

O capítulo 2 contém a fundamentação teórica com informações sobre as

ferramentas utilizadas neste trabalho.

O capítulo 3 apresenta os procedimentos metodológicos, tipo da pesquisa

realizada neste trabalho, métodos utilizados, definição da arquitetura do protótipo e a

construção do mesmo.

O capítulo 4 descreve os resultados obtidos no estudo.

O capítulo 5 apresenta a conclusão do trabalho e possíveis direções para a

continuidade desse trabalho.

15

2 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo é apresentada a fundamentação teórica que serviu de base

para este trabalho.

2.1 COMPUTAÇÃO GRÁFICA

Pesquisadores da área concordam que a CG surgiu na década de 50. De

acordo com Machover (1978 p. 38), neste período houve o surgimento das primeiras

pesquisas relacionadas à CG e já haviam projetos de sistemas de CG sendo

desenvolvidos como por exemplo o Whirlwind, que estava em desenvolvimento pelo

Massachusetts Institute of Tecnology. O Whirlwind tinha como objetivo principal

atuar no treinamento e simulação de vôo. Seu projeto foi iniciado pelo Office Naval

Research em parceria com o Massachusetts Institute of Tecnology Digital Computer

Laboratory.

Na década de 60, destaca-se Ivan Sutherland com uma importante

publicação na área da CG (Sketchpad – A Man-Machine Graphical Comunication

System), que se tratava de um estudo sobre estruturas de dados para

armazenamento de informações referentes à elementos gráficos. Em sua obra Ivan

Sutherland também descreve técnicas de interação que utilizavam teclado e caneta

ótica, para realizar desenhos e interagir por meio de toque. A publicação logo

despertou interesse de empresas automobilísticas e aeroespaciais, que utilizariam

os conceitos ali descritos no desenvolvimento de seus produtos. Assim o CAD

(Computer Aided Design) surgiu. (CONCI; AZEVEDO, 2003)

A década de 70 representa o surgimento de empresas interessadas em

fornecer dispositivos e sistemas de CG. Durante este período haviam muitas

empresas que atuavam no ramo da CG, seja fornecendo o hardware necessário à

execução desses sistemas seja criando novos sistemas gráficos. A tecnologia havia

se popularizado. Ainda na década de 70 surgem algoritmos famosos como o z-buffer

e sombreamento. Neste mesmo período a CG passa a ser reconhecida como área

16

especifica da ciência da computação, e surgem congressos específicos como o

SIGGRAPH. (MACHOVER, 1978)

Na década de 80 ganham destaque as técnicas de processamento de

imagens, sendo aplicadas nas áreas de processamento de imagens de satélite e de

explorações interplanetárias. (CONCI; AZEVEDO, 2003)

Na década de 90, a CG já consolidada passa a estar presente também nos

cinemas, sendo que a técnica de fotorrealismo é fortemente empregada em filmes

como Jurassic Park, de 1993, e outras obras como Toy Story, o primeiro longa-

metragem totalmente tridimensional, e Terminator 2. Mas o que marca o período é o

surgimento da biblioteca OpenGL em 1992 e as primeiras placas gráficas fabricadas

pela Nvidia em 1999. (CONCI; AZEVEDO, 2003)

A partir do ano 2000, ganha destaque a modelagem de personagens

tridimensionais, novamente nas telas de cinemas com filmes como Matrix Reloaded,

Final Fantasy, Shrek. (CONCI; AZEVEDO, 2003)

2.2 WEBGL

A WebGL consiste de uma API para renderização tridimensional derivada da

OpenGL ES 2.0 API. A WebGL tem como objetivo fornecer as funcionalidades de

renderização presentes na OpenGL ES 2.0, em um contexto HTML. (KHRONOS

GROUP, 2011)

A WebGL faz uso do elemento Canvas presente no HTML5 para

renderização de objetos. São fornecidas primitivas gráficas pela API, o que facilita o

desenvolvimento e a torna mais amigável aos desenvolvedores que já possuem

experiência com a programação OpenGL para desktops. (KHRONOS GROUP,

2011)

Para renderizar objetos tridimensionais no elemento Canvas, a WebGL

gerencia uma viewport3 retangular com origem na posição (0,0) e tamanho e largura

variando de acordo com os atributos largura e altura do elemento Canvas.

3 Viewport é a região destinada ao desenho, onde são renderizados os objetos. (OpenGL, A, 2009)

17

2.3 HTML5

O HTML5 é a próxima geração do HTML, com uma tecnologia que visa

disponibilizar novas características necessárias na criação de aplicações Web

modernas, assim como padronizar funcionalidades que já eram utilizadas por anos

na plataforma Web, porém não possuíam documentação ou padrões. (W3C, 2011)

O surgimento do HTML5 aconteceu em 2007, com a formação do grupo que

iria trabalhar na especificação do HTML5. O grupo era composto pela Apple, Mozilla

e Opera, que permitiram ao W3C publicar a especificação sob os direitos de cópia

do W3C. (W3C, 2011)

O HTML5 foi projetado para ser independente de plataforma, ou seja, não

importa o sistema operacional que é utilizado, sendo que para fazer uso das

aplicações Web baseadas em HTML5 basta utilizar um navegador Web com suporte

a HTML5. (PILGRIM, 2010)

A nova tecnologia adiciona novas características que são interessantes ao

desenvolvimento Web e melhoram a experiência e usabilidade das aplicações Web.

Uma das novas características apresentadas no HTML5 é o elemento Canvas. O

elemento Canvas possibilita a renderização de gráficos, jogos e imagens em uma

página Web. (PILGRIM, 2010)

O HTML5 atualmente é suportado pela maioria dos navegadores modernos,

inclusive as últimas versões dos navegadores Apple Safari, Google Chrome, Mozilla

Firefox e Opera. (PILGRIM, 2010)

2.4 LINGUAGEM DE PROGRAMAÇÃO JAVASCRIPT

O JavaScript surgiu em 1995, tendo como objetivo fazer validação de

formulários do lado cliente. Na época era extremamente caro realizar essas

validações do lado servidor, pois as velocidades de conexão eram relativamente

baixas. Antes do JavaScript as validações eram feitas no lado servidor da aplicação,

sendo assim, se fosse encontrado um erro em algum campo de um formulário, era

18

necessário reenviar o mesmo para nova validação. Este processo de reenvio

poderia demorar minutos, levando-se em consideração as velocidades de 28.8kbps

da época. (ZAKAS, 2009)

Brendan Eich, que trabalhou para Netscape, iniciou o desenvolvimento de

uma linguagem script a qual deu o nome de LiveScript, que foi desenvolvida para a

versão 2 do navegador Netscape. A especificação da linguagem LiveScript foi

finalizada pela Netscape juntamente com a Sun Microsystems a tempo do

lançamento do Netscape 2, e para aproveitar a atenção que o Java estava atraindo

na mesma época o nome da linguagem foi alterado para JavaScript. (ZAKAS, 2009)

Com o sucesso da linguagem, a Nestcape deu continuidade ao

desenvolvimento da linguagem JavaScript, que viria a ser lançada com o navegador

Netscape 3. A Microsoft mostrou interesse por adicionar as novas features

apresentadas pelo JavaScript em um navegador que viria a se chamar Internet

Explorer. Após o lançamento do Netscape navigator 3, a Microsoft anunciou a

chegada do Internet Explorer 3 contendo a sua implementação do JavaScript então

chamada de JScript, nomeada assim com a finalidade de se evitar disputas judiciais

com a Netscape. (ZAKAS, 2009)

Em 1997, foi submetido ao European Computer Manufacturers Association

(ECMA) com uma proposta a fim de se padronizar a sintaxe e semântica,

objetivando tornar o JavaScript multiplataforma. Com a ajuda de programadores de

várias companhias, como por exemplo, Netscape, Sun, Microsoft, Borland. O novo

padrão permitiu o surgimento de uma nova linguagem chamada ECMAScript.

(ZAKAS, 2009)

2.5 FRAMEWORK SCENEJS

A framework SceneJS foi construída sob a WebGL e possui uma API

baseada na tecnologia JSON (JavaScript Object Notation), tendo como objetivo

definir e manipular cenas tridimensionais no WebGL. A arquitetura da engine tem 6

componentes demonstrados pela Figura 1. (SCENEJS, 2011)

19

O Componente JSON SceneGraph API fornece métodos baseados em JSON para

criar, pesquisar, atualizar e remover nós4 dentro de uma cena. Alguns métodos

comuns, que são utilizados na maioria das cenas são demonstrados na Tabela 1.

(SCENEJS, 2011)

Tabela 1 – Métodos de cena do SceneJS

O elemento Utilities API é utilizado para pesquisas complexas, otimização de

cenas, validações, entre outros. Consiste de uma API de utilitários genéricos. Para

criar um utilitário é necessário seguir algumas convenções, devendo possuir um

4 Nós são tipos de classes base para todas os tipos de nós de uma cena. Fornece identificação, conectividade e métodos de acesso, para alteração de propriedades de um nó. (SCENEJS, 2011)

Método Descrição SceneJS.createNode Cria um nó a partir de um objeto JSON.

SceneJS.withNode Retorna um selector com o qual pode-se

interagir para modificar um nó existente.

SceneJS.nodeExists Verifica a existência de um nó.

SceneJS.bind Adiciona um listener para tratar eventos na

cena.

SceneJS.createNodeType Permite definir um novo nó em uma cena

existente.

Figura 1 – Arquitetura do Framework SceneJS Fonte: SCENEJS (2011)

20

construtor que aceite um objeto (baseado em objetos JSON) de configuração como

argumento. A definição do método setConfigs usado para reconfigurar o utilitário é

composta por dois outros métodos, o execute e o getResults. O método execute

aceita parâmetros por execução e um sinal de call-back assíncrono para indicar se a

execução foi completa. O método getResults fornece os resultados da execução do

utilitário. (SCENEJS, 2011)

O componente Message API fornece meios para troca de mensagens entre

objetos JSON no componente JSON SceneGraph API. O sistema de mensagens é

baseado em comandos. O SceneJS disponibiliza dois tipos de comandos: create e

update, sendo possível criar outros tipos. (SCENEJS, 2011)

A Figura 2 ilustra o envio de uma mensagem para três objetos do tipo cena

atualizando seus ângulos, por meio de seus ids5.

Figura 2 – Trecho de código que exemplifica o

envio de mensagens no SceneJS.

O componente Scene Graph Engine é o componente central responsável

por interfacear as chamadas para as funções da WebGL. Existem funções bem úteis

como por exemplo, detecção de hardware, gerenciamento de memória suporte à

múltiplas cenas, dentre outros. (SCENEJS, 2011)

5 Ids no SceneJS, são utilizados para referenciar nós específicos durante as interações.(SCENEJS, 2011)

21

De acordo com SCENEJS, (2011), o componente IoC (Inversion of Control),

é responsável por permitir a conexão de ‘objetos de serviço’6. Hoje existem dois de

objetos de serviço implementados, o NodeLoader, que carrega nós em demanda, e

o CommandService, já visto anteriormente no componente Message API, que é

usado para troca de mensagens entre nós.

2.6 BIBLIOTECA VTK

O VTK (Visualization Toolkit) consiste de uma biblioteca de código aberto,

escrita na linguagem de programação C++, que implementa um sistema de

computação gráfica. O VTK disponibiliza camadas de interface para diferentes

linguagens como TCL/TK, Java e Python. (VTK, 2011)

O VTK é rico no que diz respeito à recursos disponíveis para representação de

dados, possui uma grande variedade de primitivas gráficas, das mais simples (ponto,

linha e triângulos), até as mais complexas, como por exemplo, tetraedros, prismas e

outros. (SCHROEDER, 2002)

A arquitetura do VTK é baseada em pipeline. Sua visualização no VTK

consiste em objetos que podem ser conectados de forma que possam gerar

visualização desejada. Dependendo do objeto ou tipo de visualização a ser

realizado, a extensão do pipeline VTK pode variar, de acordo com os objetos

necessários para a sua execução. (SCHROEDER, 2002)

Um pipeline VTK é composto por três tipos de objetos. As fontes, que são

responsáveis por gerar dados e realizam leitura de arquivos e outras fontes, com o

objetivo de gerar pontos a partir de funções implícitas. Os filtros, objetos que

recebem uma ou mais informações de entrada e produzem uma ou mais saídas. E

os mapeadores, que são a parte final do pipeline, tendo como objetivo converter

dados em primitivas gráficas ou persistir gráficos em arquivos. (SCHROEDER, 2002)

A Figura 3 apresenta um exemplo de pipeline para visualização de uma

esfera juntamente com um trecho de código fonte correspondente.

6 Objetos que fornecem funcionalidades extras na forma de serviço. Úteis para desacoplar o SceneJS das implementações de tais serviços. (SCENEJS, 2011)

22

Figura 3 – Exemplo de pipeline VTK

para visualização de uma esfera

Fonte: SCHROEDER (2002, p. 119).

O VTK implementa dois tipos de objetos: o tipo Data Objects que consiste de

objetos que implementam os diferentes tipos de dados como grids, vetores, dentre

outros e o tipo Process Objects, que representa as etapas de criação e

transformação de dados. (SCHROEDER, 2002)

O Data Objects que possui uma estrutura organizada e associadas a atributos

define o que se conhece como datasets, ilustrados na Figura 4. Um dataset consiste

de uma estrutura dividida em duas informações, topologia e geometria de um objeto.

A topologia define informações que não variam de acordo com certas

transformações geométricas, como por exemplo, rotação e translação. A geometria

é a instância da topologia, mais precisamente a especificação da posição dos dados

no espaço tridimensional. Como exemplo prático, ao nomear que um polígono é um

‘prisma’, especifica-se a topologia. Ao fornecer coordenadas de pontos, definem-se

informações relacionadas à geometria dos dados. (SCHROEDER, 2002)

23

Figura 4 – Exemplos de datasets existentes no VTK

Fonte: SCHROEDER (2002, p. 139).

2.7 LINGUAGEM DE PROGRAMAÇÃO PYTHON

“O desenvolvimento da linguagem Python começou em 1989 pelo holandês Guido Van Rossum. O nome da linguagem origina-se do nome da série humorística britânica Monty Python’s Flying Circus, do grupo humorístico britânico Monty Python. Guido queria criar uma linguagem de altíssimo nível, que agregasse características importantes de diversas linguagens de programação. Além disso, queria que essa linguagem de programação mantivesse uma sintaxe simples e clara”. (SANTANA; GALESI, 2010, p.17)

Python é uma linguagem multi-paradigma, ou seja, é uma linguagem

orientada a objetos, procedural e funcional. A linguagem possui hoje uma extensa

biblioteca padrão, possuindo diversas implementações, sendo a principal delas o C

Python, a implementação em linguagem C da especificação do Python. (PYTHON

ORG, 2011)

2.8 FRAMEWORK FLASK

O Framework Flask é um framework para desenvolvimento Web escrito em

Python, baseado no modelo em camadas MVC (Model-View-Controller). O

framework é baseado no princípio da convenção ao invés de configuração,

24

significando que muitas coisas já estão pré-configuradas no framework. Como

exemplo, o Flask determina que templates e arquivos estáticos estejam

obrigatoriamente em um subdiretório dentro do diretório de fontes Python da

aplicação. (FLASK, 2011)

O framework Flask é conhecido como “micro-framework“, pelo fato de a

equipe de desenvolvimento responsável pelo seu núcleo mantê-lo simples, porém

extensível. O núcleo não possui internamente uma camada de abstração de banco

de dados ou mesmo validação de formulário, porém existem diversas bibliotecas que

podem ser agregadas ao projeto, o que o torna flexível. (FLASK, 2011)

2.9 ORM SQLALCHEMY

SQLAlchemy é um ORM7 implementado em linguagem Python, que tem por

finalidade facilitar a persistência de objetos Python, fazendo o mapeamento dos

objetos para tabelas de dados do modelo relacional. (SQLALCHEMY, 2011)

O SQLAlchemy implementa diversos tipos de dialetos, que permitem a

comunicação com uma grande variedade de banco de dados, dentre eles: Drizzle,

Firebird, Informix, MaxDB, Microsoft Access, Microsoft SQL Server, MySQL, Oracle,

PostgreSQL, SQLite, Sybase. (SQLALCHEMY, 2011)

O arquitetura do SQLAlchemy está divida em duas partes principais:

SQLAlchemy ORM e SQLAlchemy Core. O SQLAlchemy ORM trata da configuração

e implementação do ORM. O SQLAlchemy Core é responsável pela construção

dinâmica dos comandos SQL, bem como pela implementação dos dialetos

suportados. O SQLAlchemy Core implementa também os tipos de dados, definições

de esquema, conexões, pools, dentre outros. (SQLALCHEMY, 2011)

7 ORM – Object Relacional Mapper (SQLALCHEMY, 2011)

25

3 PROCEDIMENTOS METODOLÓGICOS

Neste capítulo são apresentados os tipos de métodos utilizados no

desenvolvimento deste trabalho, bem como o tipo de pesquisa a ser aplicada.

3.1 LEVANTAMENTO E ANÁLISE BIBLIOGRÁFICA

Foram realizadas pesquisas em artigos, livros e documentos oficiais de

organizações responsáveis por manter as tecnologias utilizadas no presente

trabalho. A pesquisa foi de fundamental importância para consolidar as informações

sobre o uso da WebGL juntamente com HTML5 e VTK na visualização de modelos

tridimensionais em livros, artigos e outros.

3.2 TIPO DA PESQUISA

Foi utilizado o método de pesquisa aplicada pois foi necessário construir

uma aplicação para validar o estudo realizado. (GIL, 2009)

3.3 ARQUITETURA

Por se tratar de um sistema Web onde há um ou mais servidores

respondendo à requisições de clientes por meio da Internet, no que diz respeito à

infraestrutura o experimento faz uso da arquitetura cliente-servidor (CS). A

arquitetura CS permite que tenhamos uma ou mais entidades (servidor),

disponibilizando informações para computadores clientes por um meio de um

26

protocolo que seja suportado no meio de comunicação escolhido. O experimento

alvo deste trabalho propõe um servidor que irá disponibilizar uma interface para que

usuários por meio de seus computadores (clientes), façam o envio de arquivos no

formato VTK contendo informações da geometria de seus modelos de forma a poder

visualizá-los posteriormente.

A parte cliente por sua vez faz uso de um navegador Web que tenha suporte

ao HTML5. Todo o processamento que trata de renderização8 e interação é feito do

lado cliente do sistema, ficando a cargo do lado servidor apenas armazenar as

informações disponibilizadas de acordo com requisições dos clientes. A Figura 5

exemplifica a arquitetura cliente/servidor.

Figura 5 – Arquitetura Cliente-Servidor. Fonte: KIKUCHI (2011).

A nível de software, o padrão adotado para implementação do experimento

foi o modelo em camadas MVC (Model, View, Controller). Esse modelo fornece

muitas vantagens, sendo a principal delas a fácil manutenção, visto que as

responsabilidades estão bem definidas e distribuídas entre as camadas. As

camadas do modelo MVC e suas respectivas responsabilidades são apresentadas

na Figura 6.

8 Processo de conversão de geometria, especificação para luzes e uma visão de câmera em imagem. (VTK RENDERER, 2011)

27

Figura 6 – Modelo MVC (Model-View-Controller) Fonte: IFRANCA (2011).

3.3.1 Camada Modelo

No MVC, a camada modelo (CM) também conhecida como camada de

persistência, tem o papel de gerenciar o domínio da informação, controlando a forma

como são armazenados e acessados os dados. É nessa camada que definimos as

entidades que representa as informações do nosso sistema. No experimento foi

utilizada a tecnologia ORM (Object Relational Mapping) para implementação da

camada modelo.

Na CM, foi usada a técnica de programação ORM com a finalidade de

mapear as entidades do sistema para classes da programação orientação a objetos

(POO). A principal vantagem deste tipo de abordagem está no fato de ter-se a

definição dos dados e operações de acesso independentes do banco de dados

utilizado, desde que sejam tomados os devidos cuidados, como por exemplo, não

fazer uso de instruções SQL (Structured Query Language) nativas. A ferramenta

ORM escolhida para implementação da CM foi o SQLAlchemy. O SQLAlchemy é

uma ferramenta escrita em linguagem Python que implementa a técnica de ORM.

Aliado ao SQLAlchemy foi selecionado o banco de dados SQLite, por sua

simplicidade e pelo sistema proposto neste trabalho ser de caráter simples também.

Os trechos de código exibidos nos quadros 1 e 2 representam as classes

User e VTKModels, respectivamente necessárias para atender à CM do

experimento.

28

Quadro 1 – Classe User.

A classe User fornece o campos necessários para autenticação de um

usuário no sistema. O atributo __tablename__ define o nome da tabela que é criada

a partir da definição da classe User. As informações a serem persistidas para um

usuário são:

• id: Identificador inteiro e único para uma entrada na tabela de usuários.

Atua como chave primária.

• name: Nome do usuário do sistema.

• email: Endereço eletrônico do usuário para contato.

• password: Senha de acesso ao sistema.

Quadro 2 – Classe VTKModels.

A classe VTKModels que mapeia a tabela vtk_models no banco de dados

está relacionada com cardinalidade 1 para muitos com a tabela users, logo, um

29

usuário pode possuir muitos modelos. A Figura 7 ilustra o Modelo Entidade

Relacionamento entre as tabelas. A tabela vtk_models permite ao usuário submeter

arquivos de modelos VTK para armazenamento e posterior visualização.

Figura 7 – Classe VTKModels.

3.3.2 Camada Controladora

A camada controladora (CC) é responsável por mapear e gerenciar o fluxo de

ações do sistema. A CC está situada entre a CM e a Camada de Apresentação

(CA). Basicamente a CC recebe, processa requisições e gera respostas à eventos

da CA. O Flask, sendo um “micro” FW implementado em linguagem Python, tem

como principais características possuir um núcleo pequeno e enxuto com algumas

poucas funcionalidades já incluídas. Sua camada controladora é composta por

módulos que por sua vez contém funções que tem a finalidade de responder à

estímulos oriundos da CA.

Para o experimento foi criado o módulo frontend.py onde estão situadas todas

as funções controladoras da aplicação. O Quadro 3 ilustra um exemplo de função

controladora do Flask que gera resposta para uma chamada à URL ‘expose-model’,

retornando os dados geométricos do modelo no formato JSON (JavaScript Object

Notation) utilizando o módulo jsonify do Flask.

30

Quadro 3 – Exemplo de função controladora.

A função controladora apresentada na Quadro 3 segue alguns padrões

apresentados por todas as funções controladoras Flask. Para que uma função seja

um controlador, se faz necessário o uso de uma anotação específica que define a

qual rota a função responde e quais tipos de métodos HTTP (HyperText Transfer

Protocol) ela está habilitada a processar. A Quadro 4 apresenta a estrutura da

anotação responsável por definir funções controladoras no Flask.

Quadro 4 – Anotação para funções controladoras.

Detalhando um pouco mais cada item da anotação observa-se:

• Module: Módulo Python onde reside a função anotada. Módulos são

arquivos Python com aglomerados de funções;

• URL: URL mapeada para a função, o Flask internamente delega

todas as requisições da URL para a função controladora mapeada. A

sintaxe aceita parâmetros anexados à URL;

• [methods]: Lista de métodos HTTP aceitos pela função controladora,

como por exemplo, GET, POST.

31

3.3.3 Camada de Apresentação

A camada de apresentação (CA) é responsável pela exibição do conteúdo

gerado pela camada controladora (CC). A CA de uma aplicação Web geralmente é

implementada utilizando tecnologias suportadas pelo navegador do cliente, como

por exemplo, JavaScript, HTML, CSS (Cascade Style Sheet), dentre outras. O

projeto resultante deste estudo utilizou a tecnologia Template Engine (TE) para a

implementação da CA.

De acordo com Ronacher (2011), TE é simplesmente um arquivo texto que

pode gerar qualquer outro formato baseado em texto, como por exemplo, HTML,

XML (Extensible Markup Language), CSV (Comma Separated Values), LaTeX,

dentre outros.

O uso de TE incorporou algumas vantagens ao projeto, como por exemplo, o

uso de herança de templates para reaproveitar código HTML na criação de páginas.

O TE utilizado neste trabalho foi o Jinja template engine (JTE), que consiste em um

TE escrito em Python. O JTE já vem embutido como módulo padrão para criação de

templates no Flask e permite a geração de conteúdo dinâmico em documentos

HTML utilizando sintaxe Python. O Quadro 5 demonstra um exemplo do uso de JTE,

onde observa-se a implementação do template ancestral para todas as páginas do

experimento, enquanto que no Quadro 6 nota-se que além do código HTML, existe a

presença de comandos delimitados por marcadores especiais que permitem

adicionar código Python ao template HTML.

Quadro 5 – Template ancestral.

32

Alguns marcadores tem a simples finalidade de exibir um conteúdo dinâmico

nos templates, sem necessidade de utilizar comandos da linguagem Python. O

exemplo ilustrado nos Quadros 7 e 8 nos mostram respectivamente uma função

controladora da CC realizando uma busca por todos os modelos (na CM)

pertencentes à um determinado usuário, e enviando a variável models contendo os

modelos retornados para um template da CA destino.

No Quadro 8, observa-se um trecho do template main.html que possui um

componente select. Cada componente option do select, tem suas propriedades

populadas com valores dinâmicos passados pela função controladora que

renderizou o template.

Quadro 8 – Trecho do template main.html exibindo modelos de um usuário.

Quadro 6 – Instruções Python no JTE.

Quadro 7 – Função controladora main retorna os modelos para um usuário.

33

3.4 ESTRUTURA DO PROTÓTIPO

Para implementação do protótipo, foi utilizado o editor de texto

TextWrangler. A estrutura do projeto pode ser vista na Figura 8.

Figura 8 – Estrutura do protótipo.

A pasta src é a pasta onde se localizam os fontes do projeto, dentro dela

residem os seguintes pacotes e módulos:

• __init__.py - Módulo Python que define que a posta corrente é um

pacote Python.

• controllers – Pacote contendo o(s) módulo(s) responsáveis por

implementar as funções controladoras (camada controladora) do

protótipo.

• main.py – Módulo Python que inicia o funcionamento do protótipo.

• persistence – Pacote que implementa a camada model do protótipo.

Neste pacote residem os módulos Python que definem as classes que

mapeiam o modelo relacional para objetos.

• settings.py – Módulo Python para configurações globais do projeto,

como string de conexão com o banco de dados por exemplo.

• static – Pasta contendo imagens, arquivos de estilo CSS e arquivos

Javascript utilizados pelo projeto.

34

• templates – Pasta contendo arquivos HTML utilizados na camada de

visualização do projeto.

• utilities – Módulo Python contendo arquivos com funções de apoio,

para leitura de arquivos, validação de tipos de arquivos, etc.

3.5 DIAGRAMA DE CASOS DE USO

A Figura 9 apresenta o diagrama de casos de uso do protótipo desenvolvido

neste estudo. Para construção do diagrama foi utilizada a ferramenta Astah

Community. O diagrama apresenta as interações do usuário, que por sua vez

representa o ator do protótipo.

Figura 9 – Diagrama de casos de uso.

35

3.6 DESCRIÇÃO DOS CASOS DE USO

Cada caso de uso ilustrado na Figura 9, representa uma ação do usuário ao

interagir com o protótipo. A Tabela 2 lista os casos de uso existentes no protótipo.

Tabela 2 – Casos de uso.

Nr. Descrição do Caso de Uso Entrada Caso de Uso Saída

01 Usuário realiza login. DadosUsuario EfetuarLogin Msg01

02 Usuário efetua cadastro para

acesso ao protótipo.

DadosUsuario EfetuarCadastro Msg02

03 Usuário cadastra modelo. DadosModelo CadastrarModelo Msg03

04 Usuário visualiza modelo. DadosModelo VisualizarModelo Msg04

05 Usuário redimensiona modelo. Fator RedimensionarModelo Msg05

06 Usuário aplica zoom. Coordenadas AplicarZoom Msg06

07 Usuário rotacional modelo. Angulo, eixo RotacionarModelo Msg07

08 Usuário aplica translação ao

modelo.

Coordenadas TransladarModelo Msg08

As mensagens de retorno do protótipo e seus significados:

• Msg01: Nome de usuário incorreto! | Senha de usuário incorreta!

• Msg02: Erro na realização do cadastro! | Conta de usuário já

existente! | Cadastro realizado com sucesso!

• Msg03: Modelo com extensão incorreta | Modelo com estrutura

incorreta! | Modelo cadastrado com sucesso.

• Msg04: Modelo não encontrado! | Seu navegador não suporta

WebGL! | Erro no redirecionamento! | Redirecionando para

visualização!

• Msg05: Modelo dimensionado!

• Msg06: Zoom aplicado!

• Msg07: Modelo rotacionado!

• Msg08: Posição alterada!

36

Caso de uso 01: Caso de Uso EfetuarLogin – EL01

Atores usuario

Finalidade Efetuar login para acesso ao protótipo.

Visão Geral O usuário informa seu login e senha para acesso

e o protótipo realiza a validação, permitindo ou

não o acesso às outras funcionalidades.

Tipo Primário

Pré-Condições O usuário deve estar previamente cadastrado no

protótipo.

Sequência Típica de Eventos

Ação do Ator Resposta do Protótipo

1 – Usuário informa login e senha. 2 - Protótipo realiza validação dos dados.

3 – Protótipo redireciona usuário para página

principal.

Exceções

2 – Protótipo realiza validação do login e senha.

2.1.1 – Protótipo detecta login não informado.

2.1.2 – Protótipo emite Msg01, indicando dado inválido.

2.2.1 – Protótipo identifica senha incorreta.

2.2.2 – Protótipo emite alerta de senha incorreta para o usuário.

Pós-Condições Tela principal de acesso ao protótipo.

Caso de uso 02: Caso de Uso EfetuarCadastro – EC01

Atores usuario

Finalidade Efetuar cadastro para acesso ao protótipo.

Visão Geral O usuário informa seu nome, login e senha para

acesso e o protótipo realiza a validação e

inserção dos dados para posterior acesso.

Tipo Primário

Pré-Condições Acessar área de cadastro do protótipo.



1 – Usuário informa nome de usuário, login e

senha.

2 – Protótipo verifica a existência de um usuário

com mesmo login.

3 – Sistema emite Msg02 de informando que o

37

cadastro foi realizado com sucesso.

Exceções

2 – Protótipo verifica a existência de um usuário com o mesmo login.

2.1.1 – Caso exista uma conta de usuário já cadastrada.

2.1.2 – Protótipo emite Msg02, indicando cadastro de usuário já existente e encerra caso de uso.

Pós-Condições Tela de login do protótipo.

Caso de uso 03: Caso de Uso CadastrarModelo – CM01

Atores usuario

Finalidade Efetuar cadastro de modelo para visualização no

protótipo.

Visão Geral O usuário informa o path arquivo de model, o

título do modelo e uma descrição para o modelo.

Tipo Primário

Pré-Condições Efetuar login no protótipo.



1 – Usuário informa path, título e descrição do

modelo.

2 – Protótipo realiza validação do modelo.

3 – Sistema emite Msg03, informando modelo

cadastrado com sucesso.

Exceções

2 – Protótipo realiza validação no modelo.

2.1.1 – Caso o modelo possua a extensão incorreta.

2.1.2 – Protótipo emite Msg03, indicando modelo com extensão incorreta.

2.2.1 – Caso o modelo não tenha a estrutura esperada.

2.2.2 – Protótipo emite Msg03, informando que a estrutura do modelo não está de acordo.

Pós-Condições Tela principal do protótipo.

Caso de uso 04: Caso de Uso VisualizarModelo – VM01

Atores usuario

Finalidade Selecionar modelo para visualização.

Visão Geral O usuário seleciona um modelo dentre uma lista

pré-cadastrada para visualização.

38

Tipo Primário

Pré-Condições 1 – Ter efetuado login no protótipo.

2 – Ter cadastrado modelos no protótipo.



1 – Usuário informa o modelo a ser usado na

visualização.

2 – Protótipo cria a visualização do modelo.

3 – Protótipo emite Msg04 de informando o

redirecionamento para a página de visualização.

Exceções

2 – Protótipo cria a visualização do modelo.

2.1.1 – Caso o navegador não suporte WebGL é exibida a Msg04, informando que o navegador

não suporta WebGL.

3 – Protótipo redireciona usuário para página de visualização.

3.1 – O protótipo exibe a Msg04, informando erro no redirecionamento.

Pós-Condições Tela de visualização do modelo.

Caso de uso 05: Caso de Uso RedimensionarModelo – RM01

Atores usuario

Finalidade Alterar as dimensões do modelo.

Visão Geral O usuário seleciona um modelo e por meio de

ações com o mouse/teclado, altera largura, altura

e profundidade.

Tipo Primário

Pré-Condições Ter criado a visualização.



1 – Usuário interage com o modelo por meio de

periférico (mouse/teclado), alterando altura,

largura e profundidade.

2 – Protótipo altera propriedade solicitada de

acordo com a posição do cursor na visualização.

3 – Protótipo emite mensagem Msg05 de

redimensionamento efetuado.

Exceções


39

Caso de uso 06: Caso de Uso AplicarZoom – AZ01

Atores usuario

Finalidade Aplicar zoom na câmera.

Visão Geral O usuário por meio de interação utilizando

teclado/mouse define as coordenadas correntes

para posicionamento da câmera.

Tipo Primário




1 – Usuário interage com o modelo por meio de

periférico (mouse/teclado), alterando a posição

corrente da câmera.

2 – Protótipo altera posição da câmera.

3 – Protótipo emite mensagem Msg05 de zoom

aplicado.

Exceções


Caso de uso 07: Caso de Uso RotacionarModelo – RM01

Atores usuario

Finalidade Rotacionar o modelo nos eixos indicados e

utilizando um ângulo.

Visão Geral Usuário informa os eixos onde será aplicada a

rotação e o valor do ângulo para deslocamento

do modelo.

Tipo Primário




1 – Usuário informa eixo onde rotação será

aplicada e valor do ângulo.

2 – Protótipo rotaciona o modelo.

3 – Protótipo emite mensagem Msg07,

informando que o modelo foi rotacionado com

sucesso.

Exceções


40

Caso de uso 08: Caso de Uso TransladarModelo – TM01

Atores usuario

Finalidade Aplicar translação no modelo.

Visão Geral Usuário informa coordenadas de destino para

alterar a posição do modelo.

Tipo Primário




1 – Cliente informa as coordenadas nos eixos x,

y e z.

2 – Protótipo altera a posição do modelo.

Exceções


3.7 MODELOS VTK

O VTK consiste em uma biblioteca escrita em C++, que implementa um

sistema de computação gráfica. O VTK oferece diversas ferramentas para

processar, renderizar e armazenar modelos do mundo real. A biblioteca nos permite

trabalhar com informações sobre a geometria e propriedades associadas aos

elementos que o compõe. Imaginando como modelo o exemplo de uma seção da

carótida humana, identifica-se como propriedades deste modelo a pressão

sanguínea para cada ponto da parede da artéria, o coeficiente de elastano da

parede arterial, dentre outras.

Como já descrito anteriormente, um modelo VTK é composto pela geometria

do objeto e por suas propriedades, caso existam. Para construir objetos o VTK

dispõe de um conjunto de células equivalentes ou compostas por primitivas

geométricas da OpenGL, que nada mais são do que formas geométricas que por

sua vez são formadas por pontos e linhas. O VTK permite por meio do uso

combinado de células construir modelos mais complexos.

No que diz respeito aos tipos de elementos que compõem a geometria dos

modelos, pode-se ter malhas homogêneas e heterogêneas. Malhas homogêneas

41

são estruturas compostas em sua totalidade por células de mesmo tipo, como por

exemplo, uma malha composta apenas por células do tipo vtk_triangle. Malhas

heterogêneas como sugere o nome são estruturas compostas por dois ou mais tipos

diferentes de células, como por exemplo a topografia de uma região, contendo

vtk_triangles, vtk_tetrahedrons, etc. A Figura 10 exemplifica alguns dos tipos de

células VTK disponíveis. Apenas o tipo heterogêneo de malha foi considerado neste

estudo.

Figura 10 – Diferentes tipos de células VTK Fonte: VTK FORMATS, (2011)

3.8 TIPO DE DATASET VTK ABORDADO NO PROJETO

Um dataset consiste de objetos que possuem uma estrutura e informações

de atributos associados à mesma. A dataset de um modelo por sua vez é composto

por dois tipos de informações, topológicas e geométricas (SCHROEDER , 2002).

As informações topológicas de um modelo fornecem o conjunto de

propriedades que não variam de acordo com certas transformações geométricas,

como por exemplo, rotação e translação. As informações topológicas nos permitem

identificar os tipos de células utilizados na construção do modelo. (SCHROEDER ,

2002).

As informações geométricas complementam a informação topológica

fornecendo dados sobre sua posição no espaço tridimensional. As informações

42

referentes à geometria dizem respeito às coordenadas espaciais dos pontos.

(SCHROEDER , 2002).

Por último as informações de atributos associadas à geometria e/ou topologia

pode ser um escalar representando temperatura, elastano, pressão, etc.

O tipo de dataset abordado neste estudo foi o VTK Polygonal data, sendo

este tipo selecionado por ser o mais comumente utilizado no VTK para representar

objetos tridimensionais. A Figura 11 ilustra o dataset utilizado neste trabalho o VTK

Polydata .

Figura 11 – Exemplos de estruturas VTK Polydata

De acordo com (SCHOREDER, 2002), VTK Polygonal Data é um dataset

que compreende vertices, polyvertices, lines, polylines, polygons e triangle strips. O

VTK Polygonal Data é um dataset que possui geometria e topologia não

estruturados, e as células que compõem o dataset podem variar de acordo com a

dimensão da topologia, isto é, modelos que possuem este tipo de dataset podem

conter em sua topologia diversos tipos de elementos geométricos, triângulos, linhas

e outros.

3.9 LEITURA DE MODELOS VTK COM PYVTK

Nesta seção é apresentado o módulo escrito em Python, que se destina a

manipular arquivos VTK, contendo informações de modelos VTK. Este módulo

43

permite a fácil leitura e escrita de dados nos formatos de arquivos suportados pelo

VTK de forma simples e rápida.

O protótipo desenvolvido neste estudo necessita das informações de

topologia e geometria do modelo VTK de forma a criar visualização necessária. Após

a submissão dos arquivos VTK pelo usuário do protótipo, o mesmo é armazenado

no lado servidor, e quando este processo é finalizado o usuário do protótipo pode

fazer a visualização do modelo VTK de acordo com as informações contidas no

arquivo enviado.

No momento em que uma visualização é solicitada, o arquivo relativo ao

modelo é aberto pelo módulo PyVTK, e as informações sobre a topologia e

geometria dos objetos são lidas e armazenadas em memória para envio ao lado

cliente do protótipo para que o SceneJS crie a visualização dos dados.

Para entender como a informação é lida do arquivo VTK faz-se necessário

entender como as informações se apresentam no mesmo. Com relatado em

parágrafos anteriores, um modelo VTK possui um dataset que agrupa informações

sobre topologia e geometria de modelos. A divisão de um arquivo VTK é composta

por 5 partes, são elas:

- A primeira parte apresenta uma linha representando a versão9 do arquivo

e o identificador. A versão corresponde à versão do VTK na qual o arquivo

pode ser aberto.

- A segunda parte é o cabeçalho do arquivo. O cabeçalho consiste de uma

cadeia de caracteres terminados com o caracter ‘\n’ e pode conter no

máximo 256 caracteres. O cabeçalho geralmente é usado para se

descrever o modelo.

- A terceira parte consiste no formato do arquivo. O formato informa se o

arquivo está em formato ASCII ou binário na linha correspondente a

palavra ASCII ou BINARY deve estar presente.

- A quarta parte apresenta a estrutura do dataset, que consiste em

informações topológicas e geométricas do modelo. As informações tem

início em uma linha contendo a palavra-chave DATASET seguida da

palavra que descreve o tipo de dataset, como por exemplo,

UNSTRUCTURED_GRID.

9 A versão neste caso se refere à maxima versao possível do VTK habilitada a processar o arquivo.

44

- A quinta e última parte descreve os atributos do dataset, e esta seção

pode conter a palavra-chave POINT_DATA ou CELL_DATA, seguidas de

um valor inteiro que descreve o número de pontos ou células.

O Quadro 9 apresenta uma visão geral da estrutura de um arquivo VTK

legado em formato ASCII.

Quadro 9 – Estrutura de arquivo VTK Fonte: VTK FORMATS (2011).

O Quadro 10 ilustra um trecho de arquivo VTK no formato utilizado ASCII.

45

Quadro 10 – Exemplo de conteúdo interno de arquivo VTK

Fonte: VTK FORMATS (2011)

Sabendo-se como um arquivo VTK está estruturado, basta definir quais

informações precisam ser extraídas do modelo para criar sua representação gráfica.

Para o escopo do presente trabalho, foi definido que apenas a geometria seria

reconstruída, logo não seriam levadas em consideração informações como

escalares associados ao modelo, como por exemplo, tensores e vetores que

poderiam representar algum tipo de grandeza. Para construir uma representação

gráfica do modelo, as informações necessárias são a geométrica e topológica. O

primeiro passo é extrair as coordenadas dos pontos no espaço. Os pontos são lidos

seguindo a ordem sequencial em que aparecem no arquivo, e a posição das

coordenadas dos pontos é equivalente ao índice usado na seção de conexões. Por

exemplo, no Quadro 10, a seção POINTS contém 8 pontos, cada ponto formado

pelas suas coordenadas tridimensionais nos eixos x, y e z, o conjunto de 8 pontos

gera um conjunto de índices que vai de 0 a 7. A Tabela 3 exibe os pontos e seus

respectivos índices.

46

Tabela 3 – Pontos e índices da geometria de um modelo VTK.

Índice do ponto Coordenada X Coordenada Y Coordenada Z 0 0.0 0.0 0.0

1 1.0 0.0 0.0

2 1.0 1.0 0.0

3 0.0 1.0 0.0

4 0.0 0.0 1.0

5 1.0 0.0 1.0

6 1.0 1.0 1.0

7 0.0 1.0 1.0

Os índices são de fundamental importância para a obtenção dos tipos de

primitivas que precisam ser usadas para construção do modelo e a lista de

conexões. Na seção POLYGONS apresentada no Quadro 10, pode-se verificar que

o modelo é composto de 6 polígonos e o total de dados a ser lido na seção

compreende 30 dados numéricos. Cada linha na seção POLYGONS representa o

conjunto de pontos que formam os vértices do polígono precedidos pela quantidade

de pontos que a primitiva usada possui. No caso do arquivo exemplificado pelo

Quadro 10, constata-se que o modelo é composto em sua totalidade por apenas um

tipo de primitiva, e esta primitiva possui 4 lados. A Tabela 4 permite interpretar de

forma resumida a seção POLYGONS que define as primitivas e suas propriedades,

que por sua vez constituem o objeto ilustrado pelo Quadro 10.

Tabela 4 – Seção POLYGONS do arquivo VTK. Índice do ponto Índice 0 Índice 1 Índice 2 Índice 3

4 0 1 2 3

4 4 5 6 7

4 0 1 5 4

4 2 3 7 6

4 0 4 7 3

4 1 2 6 5

47

A Figura 12 apresenta a visualização dos dados referentes ao arquivo de

dados ilustrado no Quadro 10, feita no software Paraview.

Figura 12 – Visualização de modelo VTK no software Paraview.

Após realizar a leitura dos dados o módulo PyVTK mantém objetos que

refletem as seções descritas anteriormente. Durante a implementação do protótipo

deste estudo, foi criado um módulo10 Python chamado vtk_reader.py que utiliza o

módulo PyGTK para realizar a leitura dos dados do modelo e disponibilizar para as

próximas camadas do sistema. No módulo vtk_reader.py foi implementada a classe

VTKPolyDataReader, classe responsável pela leitura de datasets VTK Polydata a

partir de arquivos VTK. O diagrama de classe apresentado na Figura 13, apresenta

a classe seus atributos e operações.

10 Arquivo Python contendo uma ou mais classes e/ou funções utilitárias.

48

Figura 13 – Diagrama de classe do leitor de modelos VTK Polydata.

A utilização da classe é bem simples. Ela foi desenhada de forma a receber o

caminho completo do arquivo, e de posse desta informação realizar a leitura dos

dados existentes no arquivo. Após a leitura dos dados a classe disponibiliza 6

atributos importantes são eles:

- indices: Uma lista contendo as conexões dos pontos que formam as

primitivas/células na ordem em que aparecem no arquivo.

- vertices: Uma lista de todas as coordenadas encontradas no arquivo na

ordem em que aparecem no mesmo.

- normals11: Lista contendo os valores das normais para cada vértice, sendo

que os valores não vem do arquivo, são calculados pela classe

VTK vtkPolyDataNormals, que retorna uma lista de objetos

PolyDataNormals, um para cada vértice. Ao final do

processamento a classe filtra os valores das normais e as

armazena no atributo normals cuja sequência acompanha a

sequência dos vértices obtidos no arquivo.

3.10 RENDERIZANDO O MODELO VTK USANDO SCENEJS

De posse dos dados do modelo, a próxima etapa a ser executada é a

representação gráfica (RG) dos dados no lado cliente da aplicação. No protótipo

desenvolvido neste trabalho, a responsabilidade por criar a representação gráfica 11 São vetores de direção, normalmente usados por sistemas de computação gráfica para controlar o uso de shading em objetos. Podem ser usados também para controlar a orientação e geração das primitivas. (SCHROEDER, 2002)

49

dos modelos cabe ao framework SceneJS. Para se criar RGs no SceneJS, devem-

se criar nós que representam cada recurso presente na RG. Com o SceneJS pode-

se criar diversos tipos de nós, como por exemplo, um nó do tipo scene12. A estrutura

de um nó no SceneJS consiste de atributos (que variam de acordo com o tipo de nó)

e “nós filhos”13. O Quadro 11 ilustra a definição da estrutura de um nó do tipo scene

no SceneJS.

Quadro 11 – Estrutura de um nó do tipo scene

Com exceção do atributo id, todos os outros atributos apresentados no

Quadro 11 são obrigatórios na definição de uma cena, e se não informados,

recebem valores padrão. O atributo type tem como valor uma cadeia de caracteres

que define o tipo de nó que está sendo criado. Id é um atributo identificador, utilizado

para se obter e interagir com nós no contexto da página Web por meio de DOM14

(Document Object Model). O atributo canvasId tem como objetivo definir em que

elemento Canvas da página Web onde se cria a cena. O atributo loggingElementId

define o elemento presente na página Web para onde o SceneJS redireciona suas

12 Nó raiz de uma representação gráfica, cria um contexto tridimensional dentro do elemento Canvas do HTML5. 13 Nós que residem dentro de outros nós, geralmente agrupados em lista. Nós que possuem nós filhos, podem realizar operações nos mesmos e alterar seus atributos. 14 Interface independente de linguagem e plataforma que possibilita o acesso a estrutura de documentos. (DOM, 2011)

50

mensagens de log. Por fim, o atributo nodes que agrupa uma lista de nós filhos, no

caso de uma cena um nó filho pode ser um nó do tipo câmera, renderer, e outros.

O protótipo desenvolvido neste estudo cria uma RG, seguindo a estrutura

ilustrada pela Figura 14, onde são apresentados os nós e seus componentes.

Figura 14 – Estruturas de nós típica para criação de uma representação gráfica.

O nó de tipo lookAt fornece algumas configurações iniciais para ajuste de

câmera. O Quadro 12 apresenta uma configuração básica de um nó do tipo lookAt.

Quadro 12 – Estrutura de nó do tipo lookAt.

51

No Quadro 12 nota-se a presença de alguns atributos particulares ao nó

lookAt. O atributo eye que define a posição da câmera no espaço recebe um objeto

JSON, contendo as coordenadas nos eixos x, y e z. Caso não sejam informados

valores, o padrão é 0.0 para todos os eixos. O atributo look determina a direção para

onde a câmera estará observando, assim como no atributo eye recebe um objeto

com valores para os 3 eixos, sendo que eixos que são omitidos recebem o valor 0.0

por padrão. O atributo up define qual dos eixos x, y ou z serão apresentados na

vertical. No caso do exemplo ilustrado no Quadro 12, o eixo y foi selecionado.

O tipo de nó camera possui por sua vez atributos particulares. O atributo

optics, que consiste de um objeto JSON contendo uma série de propriedades, tendo

por exemplo type, fovy, aspect, near e far. A Tabela 5 descreve a função de cada

uma dessas propriedades 15 para o tipo de câmera ortogonal, utilizada na

implementação do protótipo.

Tabela 5 – Propriedades do tipo camera.

O Quadro 13 apresenta uma configuração básica de um nó do tipo camera.

Figura 13 – Estrutura de um nó do tipo camera.

15 As propriedades variam de acordo com o tipo de camera adotado.

Propriedade Função type

Tipo de câmera: perspectiva, ortogonal,

frustrum.

fovy Campo de visão horizontal em graus.

aspect Aspect ratio do campo de visão.

near Limite de proximidade do plano de corte.

far Limite de distanciamento do plano de corte.

52

Os nós do tipo light fornecem meios para aplicação de iluminação nos

materiais a serem renderizados. Existem diversos tipos de iluminação, difusa,

especular, ambiente. O SceneJS permite a definição de diferentes modos de

iluminação, por ponto e iluminação direcionada. No protótipo foi utilizado um nó de

iluminação direcionada, com direção definida a partir da coordenada espacial x, y e z

(0.0, -1.0, 0.0). As Figuras 16 e 17 apresentam uma esfera com iluminação e sem

iluminação respectivamente.

Figura 16 – Esfera com iluminação.

Figura 17 – Esfera sem iluminação.

O Quadro 14 ilustra a definição de um nó do tipo light.

53

Quadro 14 – Estrutura de um nó do tipo light.

Nós de tipo material define como a iluminação será refletida pela geometria

definida dentro do material. A Tabela 6 apresenta algumas propriedades específicas

que podem ser configuradas.

Tabela 6 – Propriedades de um nó do tipo material.

O Quadro 15 exibe um nó do tipo material e suas configurações básicas.

Quadro 15 – Estrutura de um nó do tipo material.

Propriedade Função emit Coeficiente de emissor do material, controla

intensidade de emissão de luz.

baseColor Configura a cor do material.

specularColor Define a cor da iluminação reflexiva a ser

aplicada.

specular Fator de intensidade da iluminação reflexiva.

shine Fator que controla a intensidade de brilho do

material.

54

Os nós do tipo material encapsulam nós do tipo geometry, porém existem

situações onde há necessidade de aplicação de transformações geométricas como

por exemplo, rotação, translação, escala. Existem nós de tipos que refletem

operações geométricas a serem executadas em nós de tipo geometry, podendo-se

citar, rotate, translate, scale. Podem existir mais de um nó aninhado de forma a

combinar operações geométricas para se chegar ao resultado esperado. O Quadro

16 apresenta um conjunto de nós que aplicam rotação, translação e escala.

Quadro 16 – Conjunto de nós para operações geométricas.

Nós de tipo geometry definem informações geométricas dos objetos a serem

apresentados na cena. A Tabela 7 exibe informações dos principais propriedades e

sua função.

Tabela 7 – Propriedades de um nó do tipo geometry.

Propriedade Função primitive Tipo de primitiva gráfica adotada no objeto.

positions Coordenadas x, y, z de cada ponto que forma o

objeto.

normals As normais pertencentes ao objeto.

índices Conectividade dos pontos que formam os

objetos.

55

3.11 INTERAGINDO COM O MODELO

O protótipo desenvolvido neste estudo permite a interação do usuário com o

modelo VTK em cena. As interações só se tornam possíveis graças ao mecanismo

de listeners do elemento Canvas presente no HTML5. Com o recurso de listeners,

pode-se adicionar funções que devem ser executadas caso um certo tipo de evento

ocorra, como por exemplo, mousedown, mousemove, etc. O Quadro 17 apresenta a

configuração de listeners para o Canvas presente no protótipo.

Quadro 17 – Configuração de listener.

3.11.1 Transformações geométricas

Dentre os tipos de interações presentes no protótipo desenvolvido neste

estudo, pode-se citar as transformações geométricas, rotação, translação e escala.

3.11.1.1 Rotação

A operação de rotação consiste em alterar o ângulo de corrente em um dos

eixos x, y ou z. No protótipo, foi criada uma função para efetuar rotação nos eixos x

e y de acordo com a movimentação do mouse. O Quadro 18 ilustra a implementação

da função JavaScript mouseMove que identifica se um evento de arrastar do mouse

está ocorrendo e executa as mudanças necessárias nos nós de rotação, em seguida

atualizando a cena.

56

Quadro 18 – Função mouseMove.

Nota-se no Quadro 18 que há o uso da função withNode presente no SceneJS,

função esta que permite obter um nó presente na cena, possibilitando a alteração de

suas propriedades.

3.11.1.2 Translação

A translação consiste em mover todos os pontos de um dado objeto nos

eixos ortogonais especificados dado o valor das distâncias em cada eixo. As Figuras

18 e 19 ilustram um objeto nas coordenadas (x: 0.0, y: 0.0, z: 0.0), e o mesmo objeto

após sofrer translação para as coordenadas (x: 3.0, y: 3.0, z: 0.0). O Quadro 19

exibe a função javascript que realiza a translação do modelo.

Figura 18 – Objeto nas coordenadas (0.0, 0.0, 0.0).

57

Figura 19 – Objeto nas coordenadas (3.0, 3.0, 0.0).

3.11.1.3 Escala

A operação de escala afeta o objeto alterando suas dimensões nos eixos

especificados. As Figuras 20 e 21 apresentam respectivamente um objeto em seu

tamanho original e o mesmo objeto com sua altura alterada.

Quadro 19 – Função translate, responsável por transladar o modelo.

58

Figura 20 – Objeto e suas dimensões originais.

Figura 21 – Objetos com alterações em sua dimensão.

O Quadro 20 mostra a função responsável por calcular a escala do objeto.

Quadro 20 – Função scale.

As funções Javascript apresentadas até então residem dentro do código

HTML5 da página onde a representação gráfica do Modelo VTK Polydata é criada.

59

4 RESULTADOS E DISCUSSÕES

Neste capítulo serão apresentados os resultados e funcionalidades do

sistema.

4.1 LOGIN

O login para acesso ao protótipo possibilita a entrada de um usuário

previamente cadastrado no mesmo. A Figura 22 ilustra a página de login.

Figura 22 – Página de Login.

Após informar usuário e senhas válidos o usuário tem acesso ao protótipo e

suas funcionalidades, como por exemplo, o envio de arquivos de modelos VTK e sua

visualização.

60

4.2 REGISTRO NO SISTEMA

A página de registro ao protótipo é acessada através do link “sign up”

presente na tela de login do protótipo. Ao acessar a página de registro, uma tela de

cadastro de informações é exibida ao usuário do protótipo. A Figura 23 apresenta a

tela de registro de usuários.

Figura 23 – Página de registro de usuários.

Após preencher o nome, email e senha o cadastro do usuário é realizado e

ele está apto a acessar as funcionalidades do protótipo.

4.3 PÁGINA PRINCIPAL

Ao acessar o protótipo informando usuário e senha corretos na tela de login,

o usuário é redirecionado para a página principal do protótipo para então fazer uso

de suas funcionalidades. Conforme apresentado na Figura 24.

61

Figura 24 – Página principal do protótipo.

Na página principal o usuário possui acesso às seguintes funcionalidades:

• Seleção de modelos VTK Polydata previamente cadastrados para

visualização e interação no Canvas.

• Registro de novos arquivos de modelo, neste caso o usuário deve

informar a localização do arquivo, o título do modelo e uma breve

descrição do mesmo.

4.4 PÁGINA DE VISUALIZAÇÃO E INTERAÇÃO COM O MODELO

Ao selecionar o modelo e em seguida clicar no botão “show model”, uma

página contendo a “viewport” e o modelo nela inserido para visualização e

manipulação por parte do usuário. Algumas funções são disponibilizadas ao usuário

na página de visualização e interação, como ilustra a Figura 25.

62

Figura 25 - Página principal do protótipo.

Na página principal o usuário possui acesso às seguintes funcionalidades:

• Seleção de modo de visualização, podendo-se escolher entre o modo

superfície e malha de grade ( wireframe ).

• Realizar translação do objeto desde que sejam fornecidas as

coordenadas nos eixos x, y e z.

• Alterar a escala do objeto, bastando para isso fornecer o valor da

escala nos eixos x, y e z.

• Operações de zoom com o botão scroll do mouse são suportadas.

Ao acessar o protótipo informando usuário e senha corretos na tela de login,

o usuário é redirecionado para a página principal do protótipo para então fazer uso

de suas funcionalidades.

Nota-se que a protótipo criado neste estudo permite a visualização de

modelos VTK do tipo VTKPolydata, preservando suas características geométricas e

topológicas.

Este trabalho não tinha como objetivo analisar o desempenho da

visualização nem mesmo comparar à performance de uma aplicação desktop.

Porém a performance do protótipo está ligada diretamente a alguns fatores que

podem influenciar a experiência do usuário, como por exemplo, hardware existente

no lado servidor, largura de banda da rede do usuário, tamanho dos arquivos de

dados dos modelos, dentre outros.

Futuramente algumas características podem ser adicionadas ao protótipo,

como por exemplo, visualização em grade e visualização dos pontos. A adição de

informações relacionadas aos elementos que compõem a malha do objeto, como

63

pontos de pressão, pontos de velocidade e qualquer outro escalar associado aos

elementos dependendo do domínio de estudo.

O aprimoramento da interação do usuário com o modelo se faz necessário

também, permitindo não só a leitura como também a edição de propriedades do

modelo.

A adição de suporte às primitivas existentes no VTK é necessária para que

outros tipos de datasets possam ser visualizados. O trabalho consistiria em portar os

algoritmos de triangulação e geração de conexões existentes na biblioteca VTK.

64

5. CONSIDERAÇÕES FINAIS

As pesquisas realizadas neste trabalho e sua aplicação na construção do

protótipo de visualização de modelos VTK Polydata, comprova que é possível

construir softwares para visualização científica de modelos 3D utilizando HTML5 e

WebGL em conjunto.

A área de visualização científica de modelos tridimensionais utilizando

HTML5 e WebGL, vem se popularizando com a adoção das tecnologias pelos

navegadores mais modernos, o que torna promissor o cenário para este tipo de

aplicação.

O presente trabalho visou a construção de um protótipo para visualização de

um tipo específico de modelo VTK, o Polygonal data. Como sugestão para trabalhos

futuros, indica-se o estudo sobre o suporte a modelos formados por malhas

heterogêneas, aquelas compostas por mais de um tipo de polígono. Outras

funcionalidades a serem consideradas são a adição de mais tipos de interação,

suporte a tipos diferentes de modelos 3D e melhorias de performance.

65

REFERÊNCIAS

CONCI, Aura et al. Computação Gráfica Teoria e Prática. Rio de Janeiro: Editora

CAMPUS, 2003.

DOM. W3C Document Object Model. Disponível em: <

http://www.w3.org/DOM/#what> . Acesso em: 20 setembro. 2011.

FLASK. Flask v0.8-dev documentation. Disponível em:

<http://flask.pocoo.org/docs/ > . Acesso em: 17 setembro. 2011.

IFRANCA. MVC Para Iniciantes. Disponível em:

< http://ifranca.com.br/blog/2010/04/23/mvc-para-iniciantes-–-parte-1/> . Acesso em: 17

setembro. 2011.

GIL, A. C. Como elaborar projetos de pesquisa. 4.ed. São Paulo: Atlas, 2009.

JINJA. JINJA documentation, Disponível em: < http://jinja.pocoo.org/> . Acesso em:

27 maio. 2011.

KHRONOS GROUP. WebGL especification. Disponível em:

<https://www.khronos.org/registry/webgl/specs/1.0/> . Acesso em: 3 de setembro.

2011.

MACHOVER, Carl. "A Brief, Personal History of Computer Graphics", Computer,

vol. 11, no. 11, pp. 38-45, Nov. 1978, doi:10.1109/C-M.1978.217981.

ORACLE. LESSON: JAVA APPLETS. Disponível em:

<http://download.oracle.com/javase/tutorial/deployment/applet/index.html>, Acesso

em 12 de setembro. 2011.

66

OpenGL, A. OpenGL Programming Guide. The Official Reference to Learning

OpenGL. Versions 3.0 and 3.1. 7th Ed. ISBN: 978-0-321-55262-4, Addison-Wesley,

Reading MA, 2009.

PARAVIEW. Open Source Cientific Visualization. Disponível em:

<http://www.paraview.org/> . Acesso em: 21 setembro. 2011.

PILGRIM, Mark. HTML5 Up and Running. United States of America: ISBN 978-0-

596-80602-6, O’Reilly Media Inc, 2010.

PYTHON ORG. The Python Tutorial. Disponível em:

<http://docs.python.org/tutorial/index.html> . Acesso em: 17 setembro. 2011.

RONACHER, Armin. Template Design. Disponível em: <

http://jinja.pocoo.org/docs/templates/> . Acesso em: 27 maio. 2011.

SANTANA, Osvaldo, GALESI, Thiago. Python e Django : Desenvolvimento ágil de aplicações Web. São Paulo: ISBN: 978857522-247-8, Novatec Editora LTDA,

2010.

SQLALCHEMY. SQLAlchemy 0.7 Documentation. Disponível em:

<http://www.sqlalchemy.org/docs/> . Acesso em: 17 de setembro. 2011.

SCENEJS, Xeolabs. WebGL Scene Graph Library. Disponível em:

<https://github.com/xeolabs/scenejs/wiki> . Acesso em: 13 setembro. 2011.

SCHROEDER, Will et al, The Visualization Toolkit, 3rd Ed. ISBN 1-930934-07-6,

Kitware, Inc. publishers, 2002.

KIKUCHI. Vídeo em redes Par-a-Par. Disponível em:

< http://www.gta.ufrj.br/ensino/eel879/trabalhos_vf_2009_2/kikuchi/introducao.html> .

Acesso em: 17 de setembro. 2011.

67

VTK. Visualization Toolkit. Disponível em: <http://www.vtk.org/ > . Acesso em: 17

de setembro. 2011.

VTK FORMATS. VTK File Formats. Disponível em:

<http://www.vtk.org/VTK/img/file-formats.pdf> . Acesso em: 22 setembro. 2011.

VTK RENDERER. vtkRenderer Class Reference. Disponível em:

<http://vtk.org/doc/nightly/html/classvtkRenderer.html#details> . Acesso em: 28

setembro. 2011.

W3C. HTML5 Introduction. Disponível em:

<http://www.w3.org/TR/html5/introduction.html#introduction> . Acesso em: 24

agosto. 2011.

ZAKAS, Nicolas. Professional JavaScript for Web developers. Indianapolis,

indiana: ISBN: 978-0-47022780-0, Wiley Publishing, Inc, 2009.

Documents

VISUALIZAÇÃO DE MODELOS VTK UTILIZANDO WEBGL:UM ESTUDO EXPERIMENTAL