Visualizaçãi 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

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

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 Prof. Me. Pedro Luiz de Paula Filho
Orientador Convidado
UTFPR – Campus Medianeira UTFPR – Campus Medianeira

Prof. Me. Juliano Rodrigo Lamb Prof. Me. Fernando Schütz
Convidado Coordenador do Curso de Especialização
UTFPR – Campus Medianeira UTFPR – Campus Medianeira

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

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

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

O Componente JSON SceneGraph API fornece métodos baseados em JSON para
criar, pesquisar, atualizar e remover nós 4 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

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.

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)

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

Quadro 6 – Instruções Python no JTE.

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.

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

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.

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 DadosUsuario EfetuarCadastro Msg02
acesso ao protótipo.
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 Coordenadas TransladarModelo Msg08
modelo.

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 2 – Protótipo verifica a existência de um usuário
senha. 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 2 – Protótipo realiza validação do modelo.
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 2 – Protótipo cria a visualização do modelo.
visualização. 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 2 – Protótipo altera propriedade solicitada de
periférico (mouse/teclado), alterando altura, acordo com a posição do cursor na visualização.
largura e profundidade. 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 2 – Protótipo altera posição da câmera.
periférico (mouse/teclado), alterando a posição 3 – Protótipo emite mensagem Msg05 de zoom
corrente da câmera. 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á 2 – Protótipo rotaciona o modelo.
aplicada e valor do ângulo. 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, 2 – Protótipo altera a posição do modelo.
y e z.
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
15
uma dessas propriedades para o tipo de câmera ortogonal, utilizada na
implementação do protótipo.

Tabela 5 – Propriedades do tipo camera.

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.

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.

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.
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.

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

Quadro 15 – Estrutura de um nó do tipo 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.

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).

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

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.

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.

Visualizaçãi de Modelos VTK Utilizando WebGL: Um estudo experimental.

Mais conteúdo relacionado

Mais procurados (17)

Destaque (9)

Semelhante a Visualizaçãi de Modelos VTK Utilizando WebGL: Um estudo experimental. (16)

Último (11)

Visualizaçãi de Modelos VTK Utilizando WebGL: Um estudo experimental.