Embed Size (px)
Citation preview
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO
ADUBOGL – APLICAÇÃO DIDÁTICA USANDO A
BIBLIOTECA OPENGL
LUCIANA PEREIRA DE ARAÚJO
BLUMENAU 2012
2012/1-19
LUCIANA PEREIRA DE ARAÚJO
ADUBOGL – APLICAÇÃO DIDÁTICA USANDO A
BIBLIOTECA OPEN GL
Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Ciência da Computação — Bacharelado.
Prof. Dalton Solano dos Reis, Mestre - Orientador
BLUMENAU 2012
2012/1-19
ADUBOGL – APLICAÇÃO DIDÁTICA USANDO A
BIBLIOTECA OPEN GL
Por
LUCIANA PEREIRA DE ARAÚJO
Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:
______________________________________________________ Presidente: Prof. Dalton Solano dos Reis, Mestre – Orientador, FURB
______________________________________________________ Membro: Prof. Aurélio Faustino Hoppe, Mestre – FURB
______________________________________________________ Membro: Profª. Joyce Martins, Mestre – FURB
Blumenau, 11 de julho de 2012
Dedico este trabalho a minha família que me apoiou durante toda a minha graduação, ao meu namorado, amigos, ao meu orientador e aqueles que me ajudaram diretamente na realização deste.
AGRADECIMENTOS
A Deus, por iluminar-me durante toda a caminhada.
A minha família, pelo apoio, compreensão, cobrança e por estar ao meu lado.
Ao meu namorado, William, pelos auxílios e por estar sempre presente.
Aos meus amigos, por estarem juntos em quase toda a graduação.
Aos colegas de trabalho e ao secretário do departamento, Vilmar, pelo incentivo.
Aos meus chefes, Mauro Marcelo Mattos e Antônio Carlos Tavares, por acreditarem
no meu potencial.
A todos os professores que estiveram presentes em minha graduação, principalmente
aqueles que me apoiaram, abriram chances para meu crescimento profissional e
compreenderem quando não pude ser prestativa durante o trabalho permitindo a realização
deste e por estarem sempre dispostos a me aconselhar.
Ao Laboratório de Desenvolvimento e Transferência de Tecnologia (LDTT) e a FURB
por ajudarem a moldar minha carreira profissional.
Ao meu orientador, Dalton Solano dos Reis, pela orientação, dedicação e por acreditar
na realização deste.
As oportunidades multiplicam-se à medida que são agarradas.
Sun Tzu
RESUMO
Este trabalho apresenta a implementação de uma aplicação voltada ao aprendizado da computação gráfica com foco nas transformações geométricas, denominada AduboGL. A biblioteca OpenGL é utilizada como ponto fundamental para montar o cenário 2D da aplicação e o resultado no espaço 3D. Para sua construção foram tomados como base alguns conceitos da informática na educação, tornando o seu uso mais simplificado. Na aplicação é possível realizar exercícios através de peças que se encaixam de acordo com as transformações geométricas, empilhamento de transformações e uma forma geométrica simples, o cubo. Essas peças são apresentadas em uma janela para serem montadas em um plano 2D. Após a montagem é possível salvar o exercício e visualizar seu resultado em um espaço 3D na ordem em que as peças foram colocadas. Ainda na AduboGL é possível visualizar o código em C++ e OpenGL das peças que estão sendo colocadas, podendo assim auxiliar o aluno a compreender a ordem lógica dos comandos utilizados para o desenvolvimento da cena. Por fim, é apresentada a análise de desempenho e usabilidade da aplicação.
Palavras-chave: Aplicação. Informática na educação. OpenGL. Matriz de transformação.
ABSTRACT
This work presents a computer graph application oriented learning implementation focused on geometric transformations, called AduboGL. The OpenGL library is used as fundamental point for set up the scene in 2D application and the result in a space 3D. Its construction was based in concepts of computer education, resulting in a more simplified use. In the application it’s possible to realize exercises by means of pieces which fit together according with the geometrical transformations, stacking of transformations and a simple geometric shape, the cube. These pieces are viewed in a window to be organized in a 2D plan. After that, it’s possible to save the exercise and visualize its result in 3D space in the order in which pieces were placed. Yet, in the AduboGL, it’s possible visualize the source code of the pieces being placed in C++ and OpenGL, helping the students to understand the logical order of the commands used for the scene development. Lastly, it’s presented the performance and usability analysis of the application.
Key-words: Application. Computer in education. OpenGL. Transformation matrix.
LISTA DE ILUSTRAÇÕES
Figura 1 – Estrutura padrão de um SE ...................................................................................... 17
Quadro 1 – Estrutura de nome para função OpenGL ............................................................... 20
Quadro 2 – Tipos de dados OpenGL ........................................................................................ 21
Quadro 3 – Representação dos eixos no SRU .......................................................................... 21
Figura 2 – Regra da mão direita ............................................................................................... 22
Quadro 4 – Primitivas gráficas ................................................................................................. 22
Figura 3 - Transformações sobre objeto 3D ............................................................................. 23
Quadro 5 – Fórmula para translação......................................................................................... 23
Quadro 6 – Fórmula para rotação ............................................................................................. 24
Quadro 7 – Fórmula para escala ............................................................................................... 24
Quadro 8 – Multiplicação das matrizes de translação com base na origem ............................. 24
Quadro 9 – Multiplicação das matrizes de escala com base na origem ................................... 24
Quadro 10 – Multiplicação das matrizes de rotação com base na origem para o eixo x .......... 25
Quadro 11 – Especificações das partes de um grafo de cena ................................................... 27
Figura 4 - Telas dos trabalhos correlatos .................................................................................. 28
Quadro 12 - Tabela comparativa dos trabalhos correlatos ....................................................... 30
Figura 5 – Diagrama de casos de uso ....................................................................................... 32
Quadro 13 – Detalhamento do caso de uso UC01 .................................................................... 33
Quadro 14 – Detalhamento do caso de uso UC02 .................................................................... 34
Quadro 15 – Detalhamento do caso de uso UC03 .................................................................... 35
Quadro 16 – Detalhamento do caso de uso UC04 .................................................................... 35
Quadro 17 – Detalhamento do caso de uso UC05 .................................................................... 36
Quadro 18 – Detalhamento do caso de uso UC06 .................................................................... 36
Quadro 19 – Detalhamento do caso de uso UC07 .................................................................... 36
Quadro 20 – Detalhamento do caso de uso UC08 .................................................................... 37
Figura 6 – Diagrama de classes ................................................................................................ 38
Figura 7 – Classe ObjetoGrafico com suas heranças ....................................................... 40
Figura 8 – Classe ObjetoTransformacao com suas heranças ......................................... 40
Figura 9 – Classe GravacaoDeArquivo ............................................................................ 41
Figura 10 – Classe LeituraDeArquivo ............................................................................. 41
Figura 11 – Classe Principal .............................................................................................. 42
Figura 12 – Diagrama de estados ............................................................................................. 43
Figura 13 – Peças glPushMatrix() , glPopMatrix() e cubo ................................... 45
Figura 14 – Peças que representam as transformações............................................................. 45
Quadro 21 – Estrutura das peças na AduboGL ........................................................................ 46
Figura 15 – Análise do clique sobre uma peça ......................................................................... 46
Quadro 22 - Trecho de código que retorna identificador da peça clicada ................................ 47
Quadro 23 – Representação do vetor do exercício com relação ao id da peça ....................... 48
Figura 16 – Deslocamento da peça dentro da bandeja ............................................................. 48
Quadro 24 – Trecho de código correspondente ao reposicionamento da peça colocada ......... 49
Quadro 25 – Inserção de peça filha a uma peça do exercício ................................................... 49
Figura 17 – Deslocamento de uma peça filha........................................................................... 50
Figura 18 – Deslocamento das peças para mais de um filho .................................................... 51
Quadro 26 - Trecho da função escreveCodigo() ............................................................. 52
Quadro 27 – Função adicionarTexto da classe arquivoTexto .................................. 53
Quadro 28 – Código para salvar as peças do exercício ............................................................ 54
Quadro 29 – Código para salvar as particularidades de cada peça ........................................... 54
Figura 19 – Tela da AduboGL .................................................................................................. 55
Figura 20 – Inserção de um cubo na origem da cena ............................................................. 56
Figura 21 – Inserção de peça glPushMatrix() glPopMatrix() com uma translação
interna .................................................................................................................... 57
Figura 22 - Código-fonte alterado da peça translação .............................................................. 57
Figura 23 – Peça com duas sucessoras e visualização de seu código-fonte ............................. 58
Figura 24 – Visualização da resolução do exercício assim como o código do último cubo .... 59
Figura 25 – Aplicação exemplo executando exercício gerado ................................................. 60
Figura 26 – Inserção de peça translação ................................................................................... 60
Figura 27 – Reposição da peça translação ................................................................................ 61
Figura 28 – Cena 3D resultante do exercício ........................................................................... 61
Quadro 30 – Tempo para adicionar uma peça filho a uma peça pai ........................................ 62
Figura 29 - Gráfico de média de tempos .................................................................................. 63
Quadro 31 - Formulário de perguntas aos usuários da aplicação ............................................. 64
Quadro 32 – Comparação entre trabalhos correlatos................................................................ 67
Quadro 33 - Exercício a ser realizado na AduboGL ................................................................ 74
Figura 30 – Rascunho das peças para a AduboGL ................................................................... 75
Figura 31 - Croqui das peças internas ...................................................................................... 75
Figura 32 - Desenho das peças iniciais da AduboGL ............................................................... 76
Figura 33 - Peças encaixadas e modeladas no Corel Draw ...................................................... 76
LISTA DE SIGLAS
2D – 2 Dimensões
3D – 3 Dimensões
AduboGL – Aplicação didática usando a biblioteca openGL
API – Application Programing Interface
CAD – Computer Aidded Design
DAG – Directed Acyclic Graph
FURB – Universidade Regional de Blumenau
GLU – openGL Utility library
GLUT – openGL Utility Toolkit
IDE – Integrated Development Environment
JAR – Java ARchive
OpenGL – Open Graphics Library
RF – Requisito Funcional
RGBA – Red Green Blue Alpha
RNF – Requisito Não Funcional
SA – Software Aplicativo
SE – Software Educativo
SRT – Sistema de Referência da Tela
SRU – Sistema de Referência do Universo
UC – Use Case
UML – Unified Modeling Language
V-ART – Virtual Articulations for viRtual realiTy
XML – eXtensible Markup Language
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................. 14
1.1 OBJETIVOS DO TRABALHO ........................................................................................ 14
1.2 ESTRUTURA DO TRABALHO ...................................................................................... 15
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 16
2.1 INFORMÁTICA NA EDUCAÇÃO ................................................................................. 16
2.1.1 SOFTWARE EDUCATIVO ........................................................................................... 17
2.1.2 SOFTWARE APLICATIVO .......................................................................................... 18
2.1.3 SOFTWARES COM FOCO NA EDUCAÇÃO LÚDICA ............................................. 18
2.2 OPENGL 4.2 ..................................................................................................................... 19
2.2.1 PADRONIZAÇÃO DE NOMES E TIPOS DE DADOS ............................................... 20
2.2.2 ESPAÇO GRÁFICO ....................................................................................................... 21
2.2.3 PRIMITIVAS GRÁFICAS, TEXTO, CÂMERA SINTÉTICA, ILUMINAÇÃO E
PROJEÇÃO .................................................................................................................... 22
2.2.4 TRANSFORMAÇÕES GEOMÉTRICAS ...................................................................... 23
2.2.5 VISUALIZAÇÃO DE OBJETOS GRÁFICOS .............................................................. 25
2.3 GRAFO DE CENA ........................................................................................................... 26
2.4 V-ART ............................................................................................................................... 27
2.5 TRABALHOS CORRELATOS ........................................................................................ 28
3 DESENVOLVIMENTO .................................................................................................... 31
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO ....................... 31
3.2 ESPECIFICAÇÃO ............................................................................................................ 32
3.2.1 Diagrama de casos de uso ............................................................................................... 32
3.2.2 Diagrama de classes ........................................................................................................ 37
3.2.3 Diagrama de estado ......................................................................................................... 43
3.3 IMPLEMENTAÇÃO ........................................................................................................ 44
3.3.1.1 Controle das peças da AduboGL .................................................................................. 44
3.3.1.2 Visualização do código-fonte das peças ....................................................................... 51
3.3.1.3 Visualização do cenário 3D a partir das peças colocadas ............................................. 53
3.3.2 Operacionalidade da implementação .............................................................................. 55
3.3.2.1 Desenvolvendo um exercício na AduboGL .................................................................. 56
3.4 RESULTADOS E DISCUSSÃO ...................................................................................... 61
3.4.1 Resultados obtidos na análise de performance................................................................ 62
3.4.2 Resultados obtidos na análise de usabilidade.................................................................. 63
3.4.3 Considerações gerais ....................................................................................................... 65
3.4.4 Relação dos trabalhos correlatos com o presente trabalho.............................................. 67
4 CONCLUSÕES .................................................................................................................. 69
4.1 EXTENSÕES .................................................................................................................... 70
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 71
APÊNDICE A – Exercício de OpenGL ................................................................................ 74
APÊNDICE B – Croqui das peças da AduboGL e suas imagens em PNG ....................... 75
14
1 INTRODUÇÃO
Com a crescente evolução no mundo tecnológico as tecnologias passaram a ser
utilizadas em diferentes áreas e vários sistemas passaram a ser informatizados, até mesmo a
área da educação. Começou-se a criar vários aplicativos com intuito de ensinar aos alunos
diferentes áreas do conhecimento.
O problema de empregar um software para a educação em qualquer que seja a área é a
forma com que esse é aplicado em uma sala de aula. O programa educacional deve ser
praticado com seriedade pelos professores para que realmente tenha um efeito sobre a
educação dos alunos. Normalmente, um software educacional que seja de interesse também
dos alunos deve trabalhar em forma de jogo ou ter alguma similaridade com um (ALMEIDA,
1994, p. 25-42; OLIVEIRA; COSTA; MOREIRA, 2001, p. 64).
Na disciplina de Computação Gráfica do curso de Ciência da Computação da
Universidade Regional de Blumenau (FURB) é utilizada a biblioteca Open Graphics Library
(OpenGL) para ensinar os diferentes conceitos da computação gráfica. Porém, os alunos
aprendem na teoria e depois devem tentar implementar os conceitos aprendidos em alguma
linguagem de programação, normalmente a linguagem C++ (REIS, 2011).
Levando em consideração os softwares educacionais existentes e não havendo um que
possa ser utilizado diretamente na disciplina de Computação Gráfica do curso de Ciência da
Computação da FURB, propõe-se desenvolver uma aplicação para o estudo da computação
gráfica que utilize a biblioteca OpenGL. Esta aplicação deve possuir algumas funções prontas
da OpenGL para que sejam utilizadas na geração do código-fonte da atividade realizada, bem
como para que o aluno possa utilizá-las em seu programa. Ela é desenvolvida de forma que
permita ser estendida posteriormente com novas funções gráficas.
1.1 OBJETIVOS DO TRABALHO
O objetivo deste trabalho é desenvolver uma aplicação para o estudo da disciplina de
Computação Gráfica do curso de Ciência da Computação da FURB na linguagem C++ que
utilize os conceitos básicos da OpenGL.
Os objetivos específicos do trabalho são:
15
a) desenvolver e disponibilizar a aplicação com conceitos definidos durante o
levantamento bibliográfico;
b) permitir que o aluno da disciplina realize exercícios com a aplicação;
c) disponibilizar um ambiente para que o aluno visualize a cena 3D resultante do
exercício realizado.
1.2 ESTRUTURA DO TRABALHO
Este trabalho está dividido em quatro capítulos, sendo que o segundo apresenta a
fundamentação teórica necessária para o entendimento deste.
O terceiro capítulo apresenta o desenvolvimento da aplicação, iniciando pelos
principais requisitos e a especificação. A especificação é composta pelos diagramas de casos
de uso, de classes e de estado. Também é mostrado como o trabalho foi implementado a partir
das técnicas e ferramentas utilizadas e dos principais trechos de código. O capítulo é
finalizado com os resultados e discussões que aconteceram durante todo o processo de
desenvolvimento do trabalho.
Por fim, o quarto capítulo refere-se às conclusões deste trabalho, bem como sugestões
para extensões futuras.
16
2 FUNDAMENTAÇÃO TEÓRICA
Na seção 2.1 é apresentado como é vista a informática na educação, quais são as
melhores formas de aplicá-la e que tipos de softwares educacionais existem. Na seção 2.2 é
descrito a OpenGL e suas características. Na seção 2.3 é descrito um grafo de cena e suas
partes. Na seção 2.4 é apresentado o framework V-ART e algumas de suas funcionalidades.
Por fim, na seção 2.5 são relacionados três trabalhos correlatos ao trabalho proposto.
2.1 INFORMÁTICA NA EDUCAÇÃO
Com o passar do tempo os jovens adquiriram uma grande familiaridade com os
ambientes tecnológicos, tendo uma boa vivência fora do contexto escolar. Esta realidade vem
mostrando a importância da inclusão de tecnologias e softwares educativos no projeto
pedagógico para que os alunos adquiram com mais facilidade o conhecimento e que não
façam mau uso da tecnologia (OLIVEIRA; COSTA; MOREIRA, 2001, p. 61-64).
Neste novo contexto, o educador tem que se sentir preparado para utilizar as
ferramentas educativas e só estará preparado se tiver um conhecimento profundo sobre o tema
abordado (ALMEIDA, 1994, p. 42).
De acordo com Almeida (1994, p. 42), “não basta criticar a pedagogia dos brinquedos
e dos jogos eletrônicos se não houver um conhecimento profundo desses objetos e das
condições para utilizá-los corretamente”. Para isso, definem-se alguns passos importantes
antes e durante a utilização de ambientes educacionais ou lúdicos, os quais são (ALMEIDA,
1994, p. 42-52):
a) o professor deve se preparar para utilizar o software educacional e receber uma
formação de como utilizá-lo;
b) o professor deve se organizar e planejar sua aula conforme a faixa etária dos
alunos e os objetivos gerais e específicos da matéria;
c) os alunos envolvidos devem receber uma formação e preparação quanto ao uso da
tecnologia;
d) o professor deve executar as atividades lúdicas com os alunos envolvidos;
e) o professor deve avaliar os resultados dos jogos pedagógicos.
17
Uma das ferramentas educacionais onde é possível conciliar a aprendizagem ao lúdico
é o software educacional. Um software educacional é todo programa voltado à educação que
envolve ensino e aprendizagem, onde o educador é importante para ensinar um determinado
conteúdo e o aluno praticará o que foi ensinado para aprender (OLIVEIRA; COSTA;
MOREIRA, 2001, p. 73).
Dentro deste contexto existem dois tipos de softwares: educativo e aplicativo. Os
softwares ainda podem abordar a educação lúdica. Os itens 2.1.1, 2.1.2 e 2.1.3 abordam estes
tipos de softwares.
2.1.1 SOFTWARE EDUCATIVO
Um Software Educativo (SE) é aquele que tem por objetivo favorecer o processo de
ensino-aprendizagem. Para que um software seja um SE ele deve ser desenvolvido com
intuído de favorecer o aluno a adquirir conhecimento relativo a um conteúdo didático, ou seja,
o SE deve possuir um caráter didático. Além disso, o SE deve facilitar a interação entre o
aluno/usuário e o programa, sempre mediada pelo professor e também deve ter uma boa
usabilidade (OLIVEIRA; COSTA; MOREIRA, 2001, p. 73).
O SE baseia-se na junção dos seguintes fatores: conteúdo; interação aluno-SE-
professor; programação e fundamentação pedagógica conforme pode ser observado na Figura
1.
Fonte: Oliveira, Costa e Moreira (2001, p. 75).
Figura 1 – Estrutura padrão de um SE
O software não precisa abranger todas as áreas e nem apenas uma. Existem vários tipos
de SE com foco em determinada área. Os diferentes tipos de SEs são (OLIVEIRA; COSTA;
MOREIRA, 2001, p. 75-82):
a) SE com ênfase na lógica do conteúdo;
18
b) SE que por possuir uma capacidade grande de novas informações, pretende realizar
uma interação progressiva com o usuário. Um exemplo deste tipo de software são
os sistemas inteligentes;
c) SE que por possuir bastante interação com o usuário permite um melhor
aproveitamento pedagógico, como os tutoriais, aplicativos de simulação e jogos
educacionais.
Os SEs envolvem uma grande equipe para seu desenvolvimento. Por envolverem um
grande campo de conhecimento, necessitam de professores especialistas na área abordada;
técnicos e conhecedores da linguagem na qual o software é desenvolvido; pessoas
especializadas em informática na educação; designer para tela e componentes; além de
docentes e alunos para experimentar e validar o material produzido.
2.1.2 SOFTWARE APLICATIVO
Os Softwares Aplicativos (SA) são utilizados em grande escala nas escolas, tanto no
ensino quanto na parte administrativa (OLIVEIRA; COSTA; MOREIRA, 2001, p. 81).
Existem dois tipos de SA:
a) software de apoio a produção de SE, como os sistemas de autoria, sistemas de
hipertexto e ambientes para criação de tutoriais;
b) software de apoio ao trabalho administrativo, como banco de dados, ambientes de
programação, processadores de texto, planilhas eletrônicas, editores gráficos e
programas de comunicação.
2.1.3 SOFTWARES COM FOCO NA EDUCAÇÃO LÚDICA
A educação lúdica favorece a construção do conhecimento de forma sadia e com um
espírito de uma prática democrática. Sua prática promove a interação social e tem em vista o
compromisso de transformar e modificar o meio (ALMEIDA, 1994, p. 41).
A educação lúdica tem por objetivo promover o aprofundamento do conhecimento
científico e profissional de forma que o aluno tenha satisfação e prazer em adquirir
determinado conhecimento. Além disso, ela permite a integração do conhecimento com a vida
19
social e com as situações do mundo, promovendo uma relação afetiva de vida (ALMEIDA,
1994, p. 15-24).
Podem ser considerados softwares lúdicos os jogos que juntam o mundo real com
alguma diversão para o usuário. Existem jogos que buscam promover a educação, como o
jogo Sim City que ensina o jogador a construir e gerenciar cidades. Assim como jogos mais
simples que são utilizados por um professor de matemática para ensinar a tabuada a partir de
imagens, por exemplo.
2.2 OPENGL 4.2
A OpenGL é uma sofisticada Application Programing Interface (API) para
desenvolver programas gráficos bidimensionais e tridimensionais para diferentes plataformas
(COHEN; MANSSOUR, 2006, p. 22; MACHADO; MORAES, 2005, p. 92). A OpenGL
também pode ser considerada um software para construção de interfaces gráficas com
capacidade de modelar gráficos 3D, com uma biblioteca rápida e portátil (WRIGHT JÚNIOR
et al., 2011, p. 33-34).
A OpenGL não é considerada uma linguagem de programação como o C ou o C++,
mas possui algumas funcionalidades pré-configuradas que devem ser utilizadas junto a uma
linguagem. Ela possui um conjunto importante de funções para trabalhar com objetos
geométricos, porém é muito primitivo e não possui recursos para trabalhar com telas, além de
possuir um baixo nível de abstração (WRIGHT JÚNIOR et al., 2011, p. 34). A API pode ser
utilizada para diversas funções, desde Computer Aidded Design (CAD) de engenharia e
aplicações arquitetônicas até para a criação de jogos e filmes (BORGES et al., 2004).
Para facilitar o desenvolvimento de aplicações gráficas foram criadas as bibliotecas
openGL Utility library (GLU) e openGL Utility Toolkit (GLUT) baseadas na OpenGL, mas
com uma abstração maior (MACHADO; MORAES, 2005, p. 94).
A GLU contém uma série de funções que encapsulam comandos OpenGL de mais
baixo nível. Entre elas está a definição de matrizes para projeção e orientação da visualização,
que permitem mapear as coordenadas entre o espaço da tela e do objeto (KHRONOS
GROUP, 2011).
A GLUT foi criada por Mark Kilgard para facilitar o desenvolvimento das interfaces
sem se preocupar com a plataforma, sendo assim uma biblioteca portável. Ela possui diversas
20
funções tanto de janelas quanto de controle de eventos. Com ela é possível criar janelas,
menus, pop-ups, desenhar textos e objetos da OpenGL como paralelepípedos, esferas e
cilindros. Além disso, é possível gerenciar os eventos de mouse, teclado e joystick. Esta
biblioteca é adequada para a aprendizagem da OpenGL e tem o objetivo de ocultar a
complexidade de sistemas de janelas existentes hoje. É utilizada principalmente para
pequenas aplicações (COHEN; MANSSOUR, 2006, p. 53; WRIGHT JÚNIOR et al., 2011, p.
43).
Nas próximas seções são abordados os temas: padronização de nomes e tipos de dados;
espaço gráfico; primitivas gráficas, texto, câmera sintética, iluminação e projeção;
transformações geométricas e visualização de objetos gráficos.
2.2.1 PADRONIZAÇÃO DE NOMES E TIPOS DE DADOS
O nome das funções em OpenGL possui uma padronização. O nome da função é
normalmente dividido em quatro partes: a primeira corresponde a um prefixo que representa a
biblioteca, podendo ser gl , glu ou glut ; a segunda parte é a raiz que representa o comando
OpenGL correspondente à função; a terceira parte é um número e indica a quantidade de
argumentos; por fim, a quarta parte representa o tipo dos argumentos (COHEN;
MANSSOUR, 2006, p. 49). No Quadro 1 pode-se verificar a formatação de uma função
OpenGL.
<PrefixoBiblioteca> <ComandoRaiz> <ContadorArgumentoOpcional> <TipoArgumentoOpcional>
EXEMPLO: void glColor3f (GLfloat red, GLfloat green, GLfloat blue)
gl Prefixo: biblioteca gl . Color Comando raiz que indica o objetivo da função. 3 Indica que a função possui três argumentos. F Indica que os argumentos são valores de ponto flutuante.
Quadro 1 – Estrutura de nome para função OpenGL
Algumas funções não tem parâmetros ou possuem sempre a mesma quantidade. Nestes
casos a nomenclatura da função não tem a parte do contador ou do tipo de argumento. Como
exemplo, cita-se o caso da função glTranslatef() , que sempre possui três parâmetros.
Assim como o nome das funções, também foram especificados tipos de dados próprios
da OpenGL. A maioria dos tipos primitivos começa com o prefixo GL seguido do tipo
primitivo determinado (POZZER, 2011, p. 8). Os tipos de dados são apresentados no Quadro
2.
21
Tipo de dado OpenGL Representação interna Tipo de dado C Sufixo
GLbyte inteiro de 8 bits signed char b GLshort inteiro de 16 bits short s GLint, GLsizei inteiro de 32 bits int ou long i GLfloat, GLclampf ponto flutuante de 32 bits float f GLdouble, GLclampd ponto flutuante de 64 bits double d GLubyte, GLboolean inteiro de 8 bits sem sinal unsigned char ub GLushort inteiro 16 bits sem sinal unsigned short us GLuint, GLenum, GLbitfield
inteiro de 32 bits sem sinal unsigned long/ unsigned int
ui
Fonte: Cohen e Manssour (2006, p. 52). Quadro 2 – Tipos de dados OpenGL
2.2.2 ESPAÇO GRÁFICO
O universo de um espaço gráfico é a região do plano utilizada em uma aplicação.
Pode-se visualizar o espaço gráfico principalmente em duas formas diferentes: 2D e 3D
(MACHADO; MORAES, 2005, p. 94).
Como os espaços gráficos utilizam coordenadas geométricas, deve-se definir um
sistema de referência que define uma origem em relação aos demais pontos descritos no
universo (COHEN; MANSSOUR, 2006, p. 72-77).
Para um plano 2D, o Sistema de Referência do Universo (SRU) é composto por dois
eixos (x e y) perpendiculares entre si. Já para o espaço 3D este sistema é composto por três
eixos (x, y e z) ortogonais entre si (WRIGHT JÚNIOR et al., 2011, p. 133). A representação
de cada um deles pode ser vista no Quadro 3.
Quadro 3 – Representação dos eixos no SRU
Desta forma, uma coordenada em um plano 2D é representada por dois pontos e em
um plano 3D por três pontos e todos os modelos em OpenGL são definidos pelo SRU. O SRU
não representa exatamente os pontos do monitor do computador. O monitor utiliza o Sistema
de Referência da Tela (SRT) onde a origem localiza-se no canto superior esquerdo do
monitor. Para que os objetos sejam representados graficamente nos locais corretos deve ser
realizada uma conversão ou um mapeamento (COHEN; MANSSOUR, 2006, p. 72).
22
Para localizar o eixo z em relação ao eixo x e y em um plano 3D pode-se utilizar a
regra da mão direita ou a regra da mão esquerda. A OpenGL trabalha com a primeira regra.
Para isso deve-se posicionar a mão direita de forma que o indicador fique apontado para o
eixo y (positivo), o polegar para o eixo x (positivo) e o dedo médio apontado para a direção
positiva do eixo z. Na Figura 2 pode-se observar a utilização desta regra (MANSSOUR;
COHEN, 2006, p.9).
Fonte: Manssour e Cohen (2006, p. 9).
Figura 2 – Regra da mão direita
2.2.3 PRIMITIVAS GRÁFICAS, TEXTO, CÂMERA SINTÉTICA, ILUMINAÇÃO E PROJEÇÃO
Com a OpenGL é possível desenhar elementos básicos como pontos, segmentos de
reta, polígonos e círculos. Para realizar estes elementos em um plano 2D foram definidas
algumas primitivas gráficas. Estas primitivas são definidas por um ou mais pares de vértices.
O Quadro 4 representa as diferentes primitivas gráficas disponíveis na biblioteca (POZZER,
2011, p. 8; MACHADO; MORAES, 2005, p. 96).
Primitiva Gráfica Função GL_POINTS Desenhar ponto GL_LINES Desenhar segmento de linha GL_LINE_STRIP Desenhar segmentos de linhas conectados GL_LINE_LOOP Desenhar segmentos de linhas conectados, unindo o primeiro com o último GL_POLYGON Desenhar polígono convexo GL_TRIANGLES Desenhar triângulo GL_TRIANGLE_STRIP Desenhar triângulos conectados GL_TRIANGLE_FAN Desenhar triângulos a partir de um ponto central GL_QUADS Desenhar quadriláteros GL_QUAD_STRIP Desenhar quadriláteros conectados
Quadro 4 – Primitivas gráficas
Para escrever um texto na área gráfica deve-se utilizar a biblioteca GLUT. Ela possui
dois tipos de fontes que podem ser utilizadas: stroke que é formada por segmentos de retas e
23
bitmap que são imagens que representam caracteres. O primeiro tipo possui uma resolução
maior e pode ser escalado e rotacionado, porém não é tão rápido quanto o segundo tipo de
fonte (COHEN; MANSSOUR, 2006, p. 105).
2.2.4 TRANSFORMAÇÕES GEOMÉTRICAS
As transformações geométricas nada mais são que cálculos matemáticos que
transformam as características dos elementos gráficos. Estas transformações alteram apenas o
aspecto do desenho e não sua estrutura (COHEN; MANSSOUR, 2006, p. 113) e são
calculadas sempre a partir da origem do objeto gráfico (REIS, 2012). É comum que essas
alterações sejam feitas de forma interativa. Existem basicamente três tipos de transformações:
translação, rotação e escala (MACHADO; MORAES, 2005, p. 97), como pode ser observado
na Figura 3.
Fonte: Reis (2012).
Figura 3 - Transformações sobre objeto 3D
A translação é utilizada para colocar ou alterar de lugar o objeto em cena. A operação
matemática aplicada à translação é a adição de constantes de deslocamento nas coordenadas
do elemento (WRIGHT JÚNIOR et al., 2011, p. 25-26). Sua fórmula é apresentada no Quadro
5.
x' = x + Tx y' = y + Ty z' = z + Tz , onde T é a constante de deslocamento.
Quadro 5 – Fórmula para translação
A rotação é utilizada para girar um objeto a partir de um ângulo. Quando se deseja
rotacionar um elemento em torno de um determinado eixo, deve-se aplicar um cálculo
matemático de seno e cosseno sobre os demais eixos do objeto (WRIGHT JÚNIOR et al.,
2011, p. 27-28; COHEN; MANSSOUR, 2006, p. 120-122). Por exemplo, para rotacionar um
objeto em torno do eixo z utiliza-se a fórmula descrita no Quadro 6.
24
x' = x * cos(a) + y * sin(a) y' = -x * sin(a) + y * cos(a)
Quadro 6 – Fórmula para rotação
A escala é utilizada para definir o tamanho do objeto no plano gráfico. Com ela,
também é possível ampliar ou diminuir o elemento. Para realizar a escala sobre um objeto
deve-se multiplicar um valor de escala por todas as coordenadas das primitivas gráficas que
compõem o objeto a ser escalado (POZZER, 2011, p. 15), conforme é apresentado no Quadro
7.
x' = x * Ex y' = y * Ey z' = z * Ez , onde E é o fator de escala a ser aplicado.
Quadro 7 – Fórmula para escala
Para que um objeto inteiro sofra a transformação aplicada é necessário realizar a
mesma sobre cada uma das coordenadas do objeto. Por isso, são utilizadas matrizes de
transformação com coordenadas homogêneas. Conforme Cohen e Manssour (2006, p. 124),
“para combinar as transformações geométricas multiplica-se todas as matrizes de
transformação que serão aplicadas, e cada vértice é multiplicado somente pela matriz
resultante, chamada de matriz de transformação corrente”. Nos Quadro 8, Quadro 9 e Quadro
10 observam-se as três transformações com base nas matrizes de transformação. É importante
que a matriz corrente da transformação seja iniciada com uma matriz identidade, para isso
utiliza-se o comando da OpenGL glLoadIdentity() (REIS, 2012; COHEN; MANSSOUR,
2006, p. 124).
Translação homogênea 3D – em relação a origem
Fonte: Reis (2012). Quadro 8 – Multiplicação das matrizes de translação com base na origem
Escala homogênea 3D – em relação a origem
Fonte: Reis (2012).
Quadro 9 – Multiplicação das matrizes de escala com base na origem
25
Rotação homogênea 3D – em relação a origem, eixo x
Fonte: Reis (2012). Quadro 10 – Multiplicação das matrizes de rotação com base na origem para o eixo x
Para que um mesmo objeto sofra vários tipos de transformação ao mesmo tempo, essas
transformações devem ser concatenadas, ou seja, deve haver a multiplicação várias vezes
sobre a mesma matriz conforme as transformações a serem realizadas. Porém, se a cena tiver
mais de um objeto e for aplicada a transformação na cena, todos os objetos sofrerão a
transformação. A OpenGL soluciona esse problema a partir da implementação de uma pilha
de matrizes de transformação. Nesse caso, para definir o escopo das transformações utilizam-
se os comandos glPushMatrix() que empilha a matriz de transformação corrente e
glPopMatrix() que desempilha a matriz de transformação corrente. Dessa forma, as
transformações são concatenas e aplicadas ao objeto que é apresentado na cena (REIS, 2012;
COHEN; MANSSOUR, 2006, p. 129).
Além das transformações sobre o objeto, é possível realizar transformações sobre o
plano gráfico ou janela da aplicação, como o zoom e o pan. O zoom é utilizado para visualizar
um ou mais objetos aproximados (zoom in) ou distantes (zoom out) da tela. O pan é utilizado
para deslocar a tela de visualização de forma que o usuário possa ver diferentes partes do
universo (CARNEIRO et al., 1997).
2.2.5 VISUALIZAÇÃO DE OBJETOS GRÁFICOS
Para visualizar um objeto no sistema de referência existem basicamente duas formas
diferentes. A primeira forma é a partir da matriz de projeção (projection) que é utilizada para
determinar transformações de recorte e projeção. A segunda pela matriz modelview que é
utilizada para indicar transformações aplicadas à câmera ou aos modelos da cena (POZZER,
2011, p. 11-19).
Antes de entender cada um dos tipos de visualização é importante saber que em sua
maioria dependem de uma câmera sintética que auxilia na visualização do objeto. A câmera
26
sintética é semelhante a uma câmera comum. Ela possui uma localização, que por padrão fica
na origem, uma direção para onde está apontando e um vetor up que é o vetor de direção em
relação ao topo da câmera.
Quando um objeto é visualizado a partir da matriz de projeção, ele pode ser
visualizado de duas formas: em perspectiva ou ortogonal (WRIGHT JÚNIOR et al., 2011, p.
136-137). Para visualizá-lo em perspectiva deve-se utilizar o comando da OpenGL
glFrustrum() ou gluPerspective() . Com este tipo de visão a câmera deve estar apontada
para um ponto fixo; isso é feito a partir do comando OpenGL gluLookAt() . Neste comando
deve-se definir a posição da câmera, para onde ela está olhando e por fim o vetor de direção
em relação ao topo dela (NEIDER, 1994; MACHADO; MORAES, 2005, p. 95-103).
Utilizando a matriz modelview para visualizar um objeto, tem-se as transformações
geométricas aplicadas a ele, assim como as coordenadas da câmera sintética. Quando um
objeto sofre uma transformação, o ponto de visualização é alterado. Quem controla o ponto de
visão em relação ao objeto (viewpoint) é a câmera sintética. Estas informações é que
compõem a matriz modelview (POZZER, 2011, p. 13-16; NEIDER, 1994). Essa tem uma
dimensão de quatro linhas por quatro colunas e representa as transformações no sistema de
coordenadas sobre cada um dos objetos (WRIGHT JÚNIOR et al., 2011, p. 138).
Multiplicando as coordenadas dos objetos a serem transformados pela modelview, tem-se as
novas coordenadas de transformação.
2.3 GRAFO DE CENA
Um grafo de cena, também conhecido por scene graphs, é uma estrutura de dados de
alto nível, organizada normalmente através de classes. Ele implementa uma estrutura
hierárquica de objetos e atributos, que possuem informações sobre sua aparência e demais
fatores, podendo-se especificar cenas complexas com maior facilidade (VALENTE, 2004;
POZZER, 2007; NAKAMURA; TORI, 2004, p. 108).
A estrutura de um grafo de cena é matemática e armazena uma coleção de objetos de
forma organizada. Ele é formado por nós, que são conectados por arcos. Um arco pode
conectar até dois nós. Os nós e suas ligações podem receber nomes de acordo com o
posicionamento dentro do grafo (VALENTE, 2004; NAKAMURA; TORI, 2004, p. 108). No
Quadro 11 podem-se visualizar suas especificidades.
27
Tipo Descrição Arco Conexão entre dois nós. Arco Dirigido Arco que possui uma única direção, se ndo uma relação
unidirecional, como pai para filho. Nó Estrutura que representa um ou uma coleção de da dos. Nó pai Nó que é ponto de origem de um arco dirigido , ou seja, que
inicia uma relação. Nó filho Nó que é o ponto de destino de um arco dir igido, ou seja, é
o término da relação. Nó descendente Se um nó B é filho de A, então B é d ito descendente de A.
Todos os filhos de B, também são descendentes de A. Nó ancestral Se um nó A é pai B, então A é dito anc estral de B. Todos os
ancestrais de A são ancestrais de B. Nó raiz /universo
Nó que não possui pai. É o primeiro nó do grafo.
Nó folha Nó que não possui filho. Nó interior Nó que não é raiz nem folha. Caminho Sequência de nós conectados por arco. Inici a em um nó e
finaliza em outro. Travessia Operação em que um caminho é percorrido. Branch Nó que possui vários filhos. Pode ser usado para ag rupar
outros nós. Subgrafo ou branch graph
Representa o conjunto de um nó qualquer e todos os seus filhos e descendentes. Esse nó qualquer é um nó branch.
Directed Acyclic Graph (DAG)
Grafo que possui arcos dirigidos, sendo que nenhum caminho forma um ciclo. Assim, nenhum nó pode ser ao mesmo tempo filho e pai de um ancestral.
Árvore Caso especial de um DAG, onde todos os nós f ilhos possuem um único nó pai.
Fonte: Valente (2004) e Nakamura e Tori (2004, p.108). Quadro 11 – Especificações das partes de um grafo de cena
Com a estrutura do grafo de cena é possível aplicar uma transformação em um nó pai e
esta é propagada para todos os seus nós filhos. Dessa forma, as transformações geométricas
de uma folha do grafo são determinadas pela acumulação recursiva dos estados dos seus pais,
até o nó raiz (NAKAMURA; TORI, 2004, p.108).
2.4 V-ART
Virtual Articulations for viRtual realiTy (V-ART) é um framework multiplataforma e
independente de API gráfica desenvolvido em C++ para facilitar a criação de ambientes em
3D, especialmente aqueles que possuem humanoides. O framework é inteiramente orientado a
objetos, possui um sistema de suporte a animações e permite a representação de articulações
biologicamente corretas (FÉLIX, 2009; SCHNEIDER, 2009).
O V-ART é um software livre sob licença GPLv2 e possui documentação em
DoxyGen para aqueles que desejam utilizar o framework. Também possui um manual com
dicas para criação de projetos com o Microsoft Visual Studio. O site do V-ART ainda
28
disponibiliza exemplos, códigos-fontes, projetos no Microsoft Visual Studio e modelos 3D
que utilizam o próprio framework (SCHNEIDER, 2009).
2.5 TRABALHOS CORRELATOS
Existem várias ferramentas disponíveis no mercado que utilizam as técnicas
educacionais aplicadas a algum conceito da computação, como o Greenfoot (HENRIKSEN;
KÖLLING, 2004) e o Furbot (VAHLDICK; MATTOS, 2008). Estas ferramentas tem por
objetivo ensinar a linguagem Java a crianças e alunos da computação. Além delas, existe o
Edugraph que tem a intenção de ensinar a computação gráfica (BATTAIOLA et al., 2002, p.
283). As três ferramentas apresentadas ensinam de forma lúdica a partir de jogos e algumas de
suas telas podem ser vistas na Figura 4.
Figura 4 - Telas dos trabalhos correlatos
O Greenfoot é um framework e foi desenvolvido nas Universidades de Kent, Inglaterra
e Deakin, Austrália, com intuito de ensinar a programação orientada a objetos a iniciantes,
29
principalmente crianças. O framework é uma mistura de micro mundos com o BlueJ: é como
se o micro mundo fosse o framework Java e o BlueJ o ambiente de desenvolvimento. O
Greenfoot possui duas classes principais: Actor e Word que devem ser implementadas pelos
programadores. Cada classe Actor gera um objeto que pode ser adicionado na classe World
(mundo). O mundo é um espaço bidimensional dividido em linhas e colunas gerando assim
células. São nestas células que os objetos do tipo Actor são adicionados. Seu diferencial é que
é possível criar com facilidade diferentes cenários para que seja trabalhado. O framework
utiliza a linguagem Java como linguagem base (HENRIKSEN; KÖLLING, 2004).
Desenvolvido na FURB, o Furbot também é um framework com o objetivo de ensinar
aos alunos os conceitos introdutórios da programação, misturando o Java com a linguagem
Portugol (SILVA, 2000, p. 13). Ele também possui um espaço bidimensional com grades
(linhas e colunas) que é configurado a partir de um arquivo eXtensible Markup Language
(XML) e cada célula pode conter um objeto predefinido. O objeto principal do mundo é um
robô e junto a ele podem ser adicionados outros elementos. Cada um destes objetos é uma
classe que herda outra classe para que o aluno possa programar a inteligência de cada um
deles. O Furbot é um arquivo Java ARchive (JAR) que é facilmente importado como um
projeto em uma Integrated Development Environment (IDE), como o Eclipse, por exemplo
(VAHLDICK; MATTOS, 2008).
O Edugraph é uma ferramenta de apoio ao ensino da Computação Gráfica a distância.
A ferramenta utiliza os princípios dos jogos de computadores para ensinar principalmente
engenheiros e designers que não possuem o conhecimento em computação (CERQUEIRA;
SILVA, 2009, p. 1735). A ferramenta foi desenvolvida na linguagem C++ utilizando a
OpenGL e componentes do pacote DirectX da Microsoft. Ela é dividida em níveis onde no
primeiro o aluno aprende a teoria que pode ser a partir de diferentes tipos de mídias, como
webcam, hipertexto e sons. Após aprender a teoria, no segundo nível o aluno exercita em um
plano 2D a partir de perguntas e respostas. Ao término desta fase ele passa para a terceira em
um plano 3D onde estuda este espaço selecionando objetos e aplicando operações a ele
(BATTAIOLLA et al., 2002, p. 287-289).
No Quadro 12 é possível visualizar uma comparação entre os três trabalhos correlatos
expostos. Foram levantadas oito características e então foram comparadas.
30
Característica Furbot Greenfoot Edugraph Interação com o aluno a partir de objetos gráficos
Sim Sim Sim
Capacidade de resolver exercícios Sim Sim Sim Resolução de exercícios via código-fonte Sim Sim Não Alteração de parâmetros do código em tempo de execução
Não Não Sim
Explícito uso da OpenGL Não Não Sim Permite alteração da posição da câmera Não Não Sim Tipo de cenário 2D 2D 2D/3D Tipo de integração Framework Framework Ferramenta
Quadro 12 - Tabela comparativa dos trabalhos correlatos
É possível visualizar que todos permitem a interação do aluno com objetos gráficos a
partir da resolução de exercícios. O que os diferencia, principalmente o Edugraph dos outros
dois trabalhos, é que o Edugraph permite alterar os parâmetros em tempo de execução, porém
não permite a resolução de exercícios via código-fonte. Já o Furbot e o Greenfoot permitem a
realização de exercício via código-fonte, e não permitem a alteração de parâmetros em tempo
real. O Edugraph trabalha nos dois tipos de cenário, 2D e 3D, e os outros dois são limitados
em um espaço 2D. Somente o Edugraph utiliza a OpenGL de forma explícita, assim como,
somente ele permite alterar o posicionamento da câmera dentro de uma cena.
31
3 DESENVOLVIMENTO
Este capítulo detalha as etapas do desenvolvimento da aplicação. São apresentados os
principais requisitos, a especificação, a implementação e, por fim, os resultados e discussões.
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO
A aplicação proposta deve:
a) possuir algumas funções que executem comandos e conceitos da OpenGL
(Requisito Funcional – RF);
b) permitir que o usuário resolva exercícios de computação gráfica que utilizem o
cubo e transformações da OpenGL (RF);
c) disponibilizar peças para representar os comandos da OpenGL (RF);
d) permitir o encaixe das peças conforme os comandos que as representam (RF);
e) permitir o agrupamento de transformações sobre um ou mais objetos gráficos (RF);
f) permitir que o usuário altere a cor do cubo a ser desenhado em 3D (RF);
g) permitir que o usuário altere os valores x, y e z a serem passados para a matriz de
transformação (RF);
h) permitir que o usuário da aplicação visualize um cenário 3D a partir das peças
colocadas (RF);
i) permitir a visualização do código gerado pelas peças do exercício, ao clicá-la (RF);
j) permitir que o usuário salve o exercício realizado (RF);
k) permitir que o usuário carregue o exercício salvo para continuá-lo (RF);
l) ser implementado na linguagem C++ (Requisito Não Funcional – RNF);
m) utilizar a biblioteca OpenGL para realizar as funções referentes a computação
gráfica (RNF);
n) utilizar classes da biblioteca V-ART (RNF);
o) ter uma padronização nos nomes das funções (RNF);
p) ser de código aberto (RNF);
q) ser documentado em Doxygen (RNF);
r) ser desenvolvida no Microsoft Visual C++ 2010 Express (RNF);
32
s) executar sobre o sistema operacional Windows e Mac OS (RNF).
3.2 ESPECIFICAÇÃO
A especificação do presente trabalho foi desenvolvida com base nos diagramas da
Unified Modeling Language (UML) em conjunto com a ferramenta Enterprise Architect
9.3.932. Para a modelagem da aplicação foram utilizados os diagramas de casos de uso, de
classes e de estado que são apresentados nas seções seguintes.
3.2.1 Diagrama de casos de uso
Nessa seção são descritos os principais casos de uso da AduboGL. Por se tratar de uma
aplicação voltado à aprendizagem da matéria de computação gráfica a partir da biblioteca
OpenGL, encontrou-se apenas um ator que será o próprio usuário do sistema, sendo ele o
aluno ou o professor da disciplina. A Figura 5 exibe o diagrama de casos de uso do referido
trabalho.
Figura 5 – Diagrama de casos de uso
33
Para entender os casos de uso é necessário ter conhecimento das partes que formam a
aplicação. A AduboGL é formada por cinco janelas, sendo elas: fábrica que é o local onde
as peças são disponibilizadas para serem colocadas no exercício; bandeja é onde o exercício
é construído; janela de código-fonte da peça selecionada é onde o usuário visualiza o
código em C++ das peças conforme são selecionadas; a janela de visualização do
exercício 3D é onde o resultado do exercício é exibido; e por fim, visualização 3D com
câmera é a visualização da janela de resultado a partir de uma câmera, para visualizar o
exercício em um ângulo diferente.
O UC01 mostra como o ator Usuário cria peças para interagir com o exercício da
AduboGL. O Quadro 13 apresenta os detalhes do caso de uso.
UC01 – Criar peças disponíveis na fábrica para realizar um exercício Descrição As peças do exercício são aquelas que são colocadas no cenário para gerar
posteriormente o código-fonte. Cada peça representa um comando da OpenGL, por exemplo, o desenho de um cubo ou o comando glPushMatrix()
glPopMatrix() , ou ainda as transformações escala, rotação e translação (ver seção 2.2.4). A aplicação possui um espaço para disponibilizar todas essas peças a serem utilizadas pelo usuário, o espaço chama-se fábrica. As peças disponíveis nela ficam armazenadas em uma lista da fábrica. A janela a esquerda é dividida em duas partes: fábrica (exibe peças para serem criadas) e bandeja (apresenta as peças já criadas, colocadas e encaixadas). As partes são separadas por uma linha horizontal;
Cenário Principal
1. O Usuário inicia a AduboGL; 2. O Usuário clica com o mouse em uma peça da fábrica e arrasta para
qualquer parte do exercício mantendo o botão do mouse pressionado; 3. A aplicação irá criar uma peça idêntica a clicada.
Pós-Condição A peça criada é armazenada na aplicação em uma lista de peças da bandeja para que o usuário possa realizar os demais movimentos com a mesma. O usuário poderá visualizar a peça conforme o cursor do mouse é movimentado. A peça deve acompanhar o cursor.
Quadro 13 – Detalhamento do caso de uso UC01
Já o UC02 mostra como o ator Usuário coloca uma das peças já criadas no ambiente
do exercício. O Quadro 14 apresenta os detalhes do caso de uso.
34
UC02 – Colocar a peça criada no ambiente do exercício, sobre a bandeja Descrição Após a criação da peça, ela deve ser colocada na bandeja para que o exercício
possa ser iniciado, assim como a aprendizagem da OpenGL e a geração do código-fonte. A bandeja é o local que armazena as peças já criadas que irão compor o exercício. A peça que representa os comandos glPushMatrix() glPopMatrix() poderá receber peças internamente, chamadas de peças filhas. Essas peças filhas representam os comandos que são circundados pelo comando glPushMatrix() e glPopMatrix() .
Pré-Condição UC01 Cenário Principal
1. O Usuário deve soltar o botão do mouse para soltar a peça criada em qualquer local da bandeja;
2. A aplicação colocará a peça abaixo da última já posicionada, caso for a primeira peça, colocará no topo da bandeja.
Cenário Alternativo 1
1. Se no passo 1 do cenário principal o Usuário soltar a peça dentro da fábrica, a peça será removida da bandeja e da lista de peças da bandeja.
Cenário Alternativo 2
1. No passo 1 do cenário principal o Usuário pode soltar a peça ao lado de outra peça;
2. A aplicação verificará se a peça que está ao lado da nova permite ter peças filhas;
3. Se permitir, irá adicionar a peça como filha dela em uma lista de peças filhas e mostrará a mesma encaixada na peça solta;
4. Se a peça já tiver peças filhas, encaixará a nova peça a cima ou abaixo da atual filha, conforme for posicionada na bandeja;
5. Se não permitir apagará a peça criada. Pós-Condição O Usuário deve poder visualizar a peça criada no exercício. Essa peça
corresponde a um dos comandos principais da OpenGL que formarão o código-fonte posterior.
Quadro 14 – Detalhamento do caso de uso UC02
Ainda, o UC03 mostra como o ator Usuário pode alterar as propriedades dos
comandos da OpenGL. Esses comandos são os representados pelas peças já colocadas na
bandeja. O Quadro 15 apresenta os detalhes do caso de uso.
O UC04 mostra como o ator Usuário pode movimentar e alterar a posição das peças já
colocadas na bandeja. O Quadro 16 apresenta os detalhes do caso de uso.
35
UC03 – Alterar propriedades dos comandos da OpenGL Descrição Alguns comandos da OpenGL possuem parâmetros, como o cubo que possui
sua cor e as transformações translação, escala e rotação que possuem os valores de x, y e z a serem transformados. Ao colocar uma peça que representa esses comandos, o Usuário pode alterar suas propriedades.
Pré-Condição UC02 Cenário Principal
1. Se colocar uma peça que representa o cubo, o Usuário pode alterar sua cor pressionando a tecla “R” para colori-lo de vermelho, “G” para colori-lo de verde ou “B” para colori-lo de azul;
2. Se o Usuário colocar uma peça que represente as transformações ele poderá alterar os valores de x, y e z utilizando as teclas numéricas 1 e 2 para diminuir e aumentar o valor de x, ou 3 e 4 para diminuir e aumentar o valor de y, ou ainda 5 e 6 para diminuir e aumentar o valor de z.
Cenário Alternativo
1. Se a peça já estiver colocada e o Usuário desejar alterar suas propriedades, ele deve clicar sobre a peça e então realizar os passos do cenário principal.
Exceção 1. Se o Usuário desejar alterar as propriedades de uma peça filha já posicionada não conseguirá, pois não é possível selecionar a peça filha após ter clicado em outra.
Pós-Condição Quando for um cubo o Usuário visualizará sua nova cor sobre a própria peça. Quando for uma peça de transformação, o Usuário visualizará o valor alterado na janela de código-fonte, nas posições respectivas de x, y e z.
Quadro 15 – Detalhamento do caso de uso UC03
UC04 – Mexer e alterar a posição das peças já criadas e colocadas na bandeja Descrição Depois de posicionar a peça no exercício, o Usuário pode trocá-la de posição,
colocando-a em cima, embaixo ou entre uma já colocada. Pré-Condição UC02
Cenário Principal
1. O Usuário deve clicar e manter pressionado o botão do mouse sobre a peça a ser alterada de lugar;
2. A peça irá se mover na tela conforme o cursor do mouse se movimentar; 3. Quando a peça estiver posicionada ao lado da peça que deseja ser encaixada,
o Usuário deve soltar o botão do mouse; 4. A aplicação realizará comparações para verificar a posição em que a peça
será encaixada, coloca-a no lugar, desloca as demais peças para baixo e atualiza o índice de todas.
Cenário Alternativo
1. Se no item 3 do cenário principal o Usuário soltar a peça na área da fábrica , a peça será removida e apagada do exercício.
Exceção 1. Se o Usuário tentar mover uma peça filha não conseguirá, pois não é permitido.
Pós-Condição O Usuário deve visualizar a peça movida em seu novo lugar e as demais peças deslocadas para baixo.
Quadro 16 – Detalhamento do caso de uso UC04
O UC05 mostra como o ator Usuário pode visualizar o código-fonte de uma peça
selecionada, sendo da fábrica ou da bandeja. O Quadro 17 apresenta os detalhes do caso de
uso.
36
UC05 – Visualizar código da peça conforme peça selecionada Descrição Ao clicar sobre uma peça o Usuário pode visualizar o código-fonte em C++
com OpenGL resultante da montagem da mesma. O Usuário visualizará o código-fonte na janela código-fonte da peça selecionada .
Pré-Condição Nenhuma Cenário Principal
1. O Usuário deve clicar sobre uma peça, sendo da fábrica ou da bandeja; 2. A aplicação exibirá na janela de código-fonte da peça selecionada o
código correspondente a peça (se for da fábrica a peça estará com suas inicializações zeradas, se for da bandeja será exibido o código conforme a montagem e sua configuração no exercício).
Cenário alternativo
1. Se o Usuário clicar sobre uma peça que representa os comandos glPushMatrix() glPopMatrix() e dentro da peça tiver peças filhas, será exibido o código com as configurações de cada uma das peças filhas empilhadas.
Pós-Condição O Usuário deve poder visualizar o código-fonte a partir de um arquivo com extensão cpp . A partir deste arquivo o Usuário pode entender como funciona algumas diretivas e comandos do OpenGL e pode executá-lo em um novo projeto.
Quadro 17 – Detalhamento do caso de uso UC05
O UC06 mostra como o ator Usuário pode salvar o exercício conforme as peças
colocadas na bandeja. O Quadro 18 apresenta os detalhes do caso de uso.
UC06 – Salvar o exercício Descrição Após disponibilizar as peças sobre a bandeja, o Usuário pode salvar o exercício
montado para abri-lo posteriormente ou para visualizá-lo na cena em 3D. Pré-Condição UC02
Cenário Principal
1. O Usuário deve clicar com o botão direito dentro da bandeja; 2. A aplicação mostrará um menu; 3. O Usuário deve clicar na opção “Gravar exercício”; 4. A operação irá gerar um arquivo texto no diretório do projeto com o nome
“Exercicio.txt” com todas as configurações das peças colocadas na bandeja e na mesma ordem. Caso o arquivo já exista, o mesmo é sobreposto.
Pós-Condição O Usuário deve poder visualizar o arquivo gerado na pasta do projeto com o nome de “Exercicio.txt”. E na janela Visualização do exercício 3D deve aparecer a cena em 3D correspondente ao exercício gravado.
Quadro 18 – Detalhamento do caso de uso UC06
O UC07 mostra como o ator Usuário pode abrir o exercício já salvo em um arquivo
texto. O Quadro 19 apresenta os detalhes do caso de uso.
UC07 – Abrir o exercício salvo Descrição Após salvar um arquivo com a disposição das peças o Usuário pode abri-lo
novamente, mesmo tendo fechado a aplicação. Pré-Condição UC06
Cenário Principal
1. O Usuário deve clicar com o botão direito dentro da bandeja; 2. A aplicação mostrará um menu; 3. O Usuário deve clicar na opção “Abrir exercício”; 4. A aplicação carregará as peças na bandeja na mesma ordem e com as
mesmas configurações conforme foram gravadas no arquivo. Pós-Condição O Usuário deve visualizar as peças carregadas na bandeja, conforme foram
salvas, assim como o exercício em 3D. Deve também poder alterar o exercício como é explicado nos casos de uso anteriores.
Quadro 19 – Detalhamento do caso de uso UC07
37
Por fim, o UC08 mostra como o ator Usuário pode visualizar a cena em 3D gerada
pelas peças do exercício. O Quadro 20 apresenta os detalhes do caso de uso.
UC08 – Visualizar cena 3D Descrição Após salvar um arquivo com a disposição das peças o Usuário pode visualizá-
lo na janela de visualização do exercício 3D. Pré-Condição UC06
Cenário Principal
1. O Usuário deve abrir o arquivo exercício, caso não esteja visualizando o cenário em 3D;
2. Na janela Visualização 3D com câmera é exibida a cena 3D correspondente as peças montadas a partir de um frustum de visão.
Pós-Condição O Usuário deve visualizar o cenário 3D conforme as peças gravadas no arquivo. E na janela Visualização do exercício 3D aparece a cena vista de frente.
Quadro 20 – Detalhamento do caso de uso UC08
3.2.2 Diagrama de classes
A Figura 6 representa as classes que compõem a aplicação assim como seus
relacionamentos. Na representação, foram colocadas as classes criadas e as que são utilizadas
da biblioteca V-ART, omitindo-se as classes existentes na biblioteca, mas que não são
utilizadas pela aplicação. No diagrama as classes foram divididas em dois pacotes, dessa
forma sabem-se quais são da aplicação e quais são da biblioteca externa. A seguir as classes
são detalhadas, seguindo sua complexidade da menor para a maior. No detalhamento da
modelagem foram omitidos os construtores e funções assessoras (gets() e sets() ).
38
Figura 6 – Diagrama de classes
O diagrama apresenta cinco classes que pertencem à biblioteca V-ART, que são
Point , Point4D , Transform , Color e BoundingBox . A primeira, Point , possui basicamente
as funções assessoras para atribuir e retornar os três pontos de um ponto no espaço (x , y e z) e
é utilizada apenas de modelo para a segunda classe, não podendo ser instanciada. A segunda,
Point4D , permite ser instanciada e fornece funções para se trabalhar com o ponto. O que foi
utilizado dessa classe no trabalho proposto foi o construtor com valores apenas nos pontos x e
y e as funções assessoras. A terceira classe, Transform , disponibiliza funções para realizar
transformações de escala, rotação e translação sobre uma matriz quadrada 4x4, definida em
um vetor de 16 posições. Além dessas funções está disponível a função para fazer a
identidade da matriz. A quarta classe, Color , é basicamente composta por um vetor de quatro
39
dimensões, onde cada dimensão representa uma cor, seguindo o padrão Red Green Blue Alpha
(RGBA), suas funções assessoras e construtores. Dessa classe foram utilizadas as cores RGB
para definir a cor das peças e objetos utilizados em toda a aplicação. E a quinta classe é
utilizada para pegar os pontos máximo e mínimo em relação aos eixos de uma forma
geométrica representando sua Bounding Box .
As demais classes presentes no diagrama foram construídas para que a aplicação
pudesse executar suas funcionalidades corretamente. A classe ObjetoGrafico constitui
funções responsáveis por desenhar um objeto 2D. A partir dela pode ser definida a cor do
objeto, sua espessura de linha, sua matriz de transformação, seus vértices, sua primitiva
gráfica e seu tipo.
Na classe ObjetoGrafico também é possível adicionar peças filhas, nesse caso elas
são armazenados em um vetor de filhos. Para saber quantos filhos já existem no vetor utiliza-
se a variável de controle quantidade que é incrementada a cada novo filho adicionado. Para
realizar esse controle foi utilizada a ideia do grafo de cena (ver seção 2.3), onde a estrutura
que representa os pais é o vetor listaBandeja da classe Principal (ver Figura 11). E a
estrutura que representa os filhos é o vetor listaFilhos da classe ObjetoGrafico . Assim
cada pai tem uma lista de filhos.
Como a classe é genérica para qualquer objeto 2D não é possível realizar o desenho
das peças. Dessa forma, é definida uma função do tipo virtual denominada Desenha() que
deve ser implementada por quem a herdar. A classe é utilizada também na aplicação exemplo
que gera cena 3D, então foi criada uma classe secundária que herda a ObjetoGrafico
denominada ObjetoGraficoExercicio que possui funções utilizadas somente na AduboGL.
A classe ObjetoGraficoExercicio define se o objeto 2D poderá ser “pai” ou “filho”
de outra peça, assim como o id que a peça representa no exercício e sua BoundingBox que é
utilizada para saber se foi clicado dentro do objeto ou não. Dentro dela a BoundingBox é
calculada conforme o objeto sofre uma transformação, também existe uma função que retorna
a lista dos vértices com sua transformação. Além disso, existe a função que verifica se um
ponto passado como parâmetro pertence ao objeto, ou seja, se está dentro dele. Nessa classe a
função Desenha() , herdada da classe ObjetoGrafico , é implementada. Como essa classe
também serve para desenhar qualquer forma 2D foram criadas outras duas classes com que
herdam a ObjetoGraficoExercicio , são elas PushPop e Cubo. Essas apenas definem em
seu construtor as características que cada objeto possui. Na Figura 7 está a representação das
classes ObjetoGrafico e ObjetoGraficoExercicio com suas variáveis e funções principais,
40
assim como as classes que a herdam.
Figura 7 – Classe ObjetoGrafico com suas heranças
Como a aplicação possui três peças que representam as transformações e essas
dependem dos valores de x , y e z para realizar a transformação, foi criada a classe
ObjetoTransformacao que herda a ObjetoGraficoExercicio e possui simplesmente as três
variáveis de controle. Para representar as três peças foram criadas as três classes Escala ,
Rotação e Translação que informam suas particularidades no construtor. Essa relação pode
ser analisada na Figura 8.
Figura 8 – Classe ObjetoTransformacao com suas heranças
A classe GravacaoDeArquivo , representada na Figura 9, foi criada para facilitar a
gravação do arquivo que corresponde a modelagem das peças da aplicação. Ela possui as
funções para criar o arquivo; gravar ou adicionar em um arquivo já salvo um vetor de char ,
um único char , uma String ou um número; e também a função para finalizar a gravação do
mesmo. Para trabalhar com o arquivo texto foi utilizado o tipo ofstream da linguagem C++.
41
Figura 9 – Classe GravacaoDeArquivo
A classe LeituraDeArquivo é utilizada para carregar um arquivo texto,
especificamente o arquivo salvo. Ela possui funções para carregar um arquivo texto passado
como parâmetro em uma variável da classe, ler e retornar o conteúdo lido do arquivo e
finalizar a leitura do mesmo. Sua representação está na Figura 10.
Figura 10 – Classe LeituraDeArquivo
Por fim, Principal é a classe central da aplicação. Nela são realizadas todas as
interações da tela, como a criação de peças da fábrica, a colocação das peças na bandeja, a
gravação e leitura do exercício e a visualização do código-fonte. A classe possui métodos para
desenhar cada uma das telas que compõem a aplicação, assim como para criar seus menus e
modelá-la. A Figura 11 representa essa classe, com seus atributos e métodos principais.
42
Figura 11 – Classe Principal
As variáveis presentes na classe, em sua maioria, são utilizadas para controles internos.
Os principais exemplos são:
a) ao redimensionar a janela principal, redimensiona as janelas internas;
b) ao soltar um objeto na parte do exercício, calcula sua altura e o posiciona abaixo da
última peça colocada;
c) ao criar uma peça, essa é adicionada em um vetor de peças do exercício após a
última peça colocada;
d) ao trocar os objetos de local, o vetor de peças do exercício é atualizado conforme a
ordem das peças colocadas;
e) ao clicar na janela de peças é verificado se foi clicado em uma peça e, se for, esta é
43
armazenada;
f) ao passar com o mouse sobre as janelas é exibido um contorno em amarelo para
identificar onde está o foco do mouse;
g) ao selecionar uma peça é exibido o código-fonte na janela de códigos
correspondente a peça e suas filhas, quando houver;
h) a cada nova peça seu identificador é incrementado e quando a mesma é removida o
identificador é decrementado e os objetos da lista são atualizados.
3.2.3 Diagrama de estado
O diagrama de estados da Figura 12 mostra os possíveis estados e transações de uma
peça da aplicação.
Figura 12 – Diagrama de estados
Como se pode observar, existem três estados para a peça. O primeiro é uma peça ser da
fábrica e a partir dela ser criada tornando-se peça da bandeja, ou então ser adicionada a uma
peça já existente, tornando-se filha dela. O segundo é a peça ser da bandeja e poder ser
excluída da mesma ou então ser movida por ela. E o terceiro e último estado é a peça ser filha,
podendo ser encaixada na peça antecessora e movida conforme sua peça “pai” é movida.
44
3.3 IMPLEMENTAÇÃO
Para a implementação da aplicação foi utilizada a linguagem de programação C++, a
biblioteca OpenGL 4.2 (ver seção 2.2) e a biblioteca V-ART (ver seção 2.4). O ambiente de
desenvolvimento escolhido foi o Microsoft Visual C++ 2010 Express. A seguir são mostradas
as técnicas utilizadas e a operacionalidade da AduboGL. Também pode ser encontrado em
Araújo (2012) uma descrição da documentação dos fontes.
3.3.1.1 Controle das peças da AduboGL
A parte fundamental da AduboGL é formada por peças que representam uma forma
gráfica ou um comando importante da OpenGL para realizar uma interação no espaço 3D que
será gerado pela junção das peças.
Antes de iniciar a modelagem das peças a partir das primitivas gráficas da OpenGL
foram feitos croquis de seu formato. Os formatos foram estudados para que pudesse ser
iniciado um trabalho com as formas mais simples de serem modeladas, mas também para que
pudessem ser alteradas posteriormente. As peças futuras foram modeladas no Corel Draw e
gravadas no formato PNG, porém não se obteve tempo para substituir as iniciais no presente
trabalho. Os croquis das peças, assim como o resultado das peças finais em PNG podem ser
vistos no Apêndice B.
Primeiro trabalhou-se com dois tipos de peças. As peças podem ser observadas na
Figura 13 e são utilizadas para representar o desenho de um cubo e representar os comandos
glPushMatrix() glPopMatrix() (ver seção 2.2.4), respectivamente. As peças foram
desenhadas para permitir seu encaixe, gerando assim peças filhas. Isso porque ao aplicar uma
transformação em um cubo e colocá-lo entre um comando glPushMatrix() glPopMatrix()
a transformação passa a ser unicamente das peças dentro do bloco. Já se a peça a sofrer a
transformação estiver fora dos comandos, ao transformá-la, transformará as demais peças fora
do bloco.
45
Figura 13 – Peças glPushMatrix() , glPopMatrix() e cubo
Para as transformações, foram criadas três novas peças semelhantes à peça
correspondente ao cubo, porém de outra cor para distingui-las. A peça correspondente a
translação foi desenhada na cor marrom, a correspondente a rotação em um tom verde musgo
e a escala em um tom de roxo. Não foram escolhidas as cores bases do RGB, pois por ter a
mesma forma que o cubo, ao alterar a cor dele, essas peças seriam confundidas. Além da cor,
é apresentada a letra inicial da transformação ao lado da peça, para que o usuário possa
entender qual seu significado. As peças podem ser vistas na Figura 14.
Figura 14 – Peças que representam as transformações
As peças podem pertencer à fábrica, à bandeja do exercício ou ainda, quando não for
do tipo glPushMatrix() glPopMatrix() , podem ser filha de uma peça do tipo
glPushMatrix() glPopMatrix() que está na bandeja. A classe para a peça é a mesma para
os cinco tipos, denominada objetoGraficoExercicio , o que as diferencia é o local onde a
mesma está adicionada na classe Principal e suas características como cor e tipo.
Na classe Principal existem dois vetores. O primeiro armazena todas as peças
representadas na fábrica e o segundo possui aquelas peças que já foram colocadas na bandeja,
na ordem em que estão posicionadas na tela. Por sua vez, cada peça do exercício tem um vetor
de objetos para armazenar os seus filhos. Os vetores presentes na AduboGL podem ser
observados no Quadro 21. Nota-se uma semelhança com o grafo de cena (ver seção 2.3), pois
é uma estrutura onde acontece a relação entre pai e filho. Dessa forma, ao aplicar uma
transformação no objeto antecessor, essa é repassada para todos os seus sucessores. Por outro
lado, se a transformação for aplicada no sucessor, não interferirá na peça antecessora.
46
Quadro 21 – Estrutura das peças na AduboGL
Para que a peça da fábrica possa ser levada para a bandeja e as peças da bandeja
possam ser arrastadas, desenvolveu-se uma rotina que retorna o identificador da peça clicada.
Sempre que é clicada em uma parte da tela correspondente a fábrica ou a bandeja é chamada
uma função que percorre cada uma das três listas da AduboGL. Então é verificado se foi
clicado dentro da peça a partir dos pontos de sua BoundingBox . Se com a análise percebe-se
que foi clicado dentro da BoundingBox é passado o algoritmo da ScanLine para verificar se o
ponto clicado está também dentro da peça (a análise da BoundingBox e do algoritmo da
ScanLine pode ser observado na Figura 15).
Figura 15 – Análise do clique sobre uma peça
O algoritmo da ScanLine verifica se os segmentos de reta do objeto se interseccionam
com a reta da ScanLine. Para cada ponto de intersecção é somado 1 a uma variável que foi
iniciada com 0. Se a soma for par é porque foi clicado fora do objeto e se for ímpar foi clicado
dentro. Isso é necessário porque existe a peça correspondente ao glPushMatrix()
47
glPopMatrix() que é uma peça côncava. Por fim é retornado o id da peça selecionada ou -1
caso não tenha sido clicado em alguma peça. Sabe-se que é uma peça da fábrica quando o id
retornado for menor do que 10, pois foi o número estipulado de elementos para ela, e, se for
maior, é porque foi um objeto da bandeja, podendo ser filho de outra peça. O trecho de código
que realiza a varredura das peças colocadas na bandeja e na fábrica e chama as funções para
verificar a BoundingBox e a ScanLine pode ser analisado no Quadro 22.
GLint getIdPecaClicada(int x, int y) { GLint indice = -1; const Point4D mousePto(x,y,0); for (int i = 1; i < MAX_GABARITO; i++) { if(listaFabrica[i] != NULL) { if (listaFabrica[i]->GetBoundingBox()->testPoint(mousePto)) { //scanline: const Point4D p = *new Point4D(x, y, 0); bool s = listaFabrica[i]->PontoNoObjeto(p, listaFabrica[i]); if (s) { return listaFabrica[i]->GetId(); } } } else { break; } } for (int i = MAX_GABARITO; i < 255; i++) { if(listaBandeja[i] != NULL) { if (listaBandeja[i]->GetBoundingBox()->testPoint(mousePto)) { //scanline: bool s = listaBandeja[i]->PontoNoObjeto(mousePto, listaBandeja[i]); if (s) { return listaBandeja[i]->GetId(); } for (int j = 0; j < listaBandeja[i]->GetQuantidade(); j++) { ObjetoGraficoExercicio *filho = static_cast<ObjetoGraficoExercicio*>( listaBandeja[i]->GetFilho(j)); if (filho != NULL) { if (filho->GetBoundingBox()->testPoint(mousePto)) { //scanline: s = filho->PontoNoObjeto(mousePto, filho); if (s) { return filho->GetId(); } // senão está fora da boudingbox } } // ...código... return indice; }
Quadro 22 - Trecho de código que retorna identificador da peça clicada
Quando é adicionada a primeira peça na bandeja, essa, por sua vez, é adicionada no
vetor de peças da bandeja na posição correspondente ao seu índice, lembrando que esse vetor
possui as primeiras posições reservadas, pois elas identificam os índices das peças da fábrica.
48
Tem-se assim o id da peça correspondente ao índice da posição em que ela está adicionada no
vetor. Desse modo, para capturar a peça clicada do exercício, também é trabalhado o
identificador em conjunto com a posição do vetor. No Quadro 23 podem-se notar as posições
que são ocupadas no vetor da bandeja e sua relação com o identificador da peça. É possível
alocar no máximo 255 peças no vetor, o valor correspondente a um byte , pois não se achou
necessária a criação de mais peças em um mesmo exercício.
Quadro 23 – Representação do vetor do exercício com relação ao id da peça
Na classe principal, quando o botão do mouse é solto é validada a posição em que a
peça é solta. De acordo com o estado da peça definido pela posição em que ela é colocada
acontecerá uma ação a ela (Figura 12). Se a peça for colocada dentro da fábrica a peça é
apagada e removida do exercício. Se for colocada abaixo de todas, esta é reposicionada
abaixo da última peça já colocada na bandeja. Isso ocorre tanto para uma nova peça quanto
para uma já existente na bandeja. Esse processo pode ser analisado na Figura 16. Para realizar
o procedimento é calculada a altura das peças já colocadas e então a peça é transladada com
base nos valores em y e x deslocados. O trecho de código correspondente ao
reposicionamento da peça solta pode ser visto no Quadro 24.
Figura 16 – Deslocamento da peça dentro da bandeja
49
void pecas2D_mouse(int button, int state, int x, int y) { //...código... if (xTrans > sub_largura || yTrans <= alturaLinha) { //dentro da fábrica atualizaAlturaPecas(); } else if (yTrans > alturaY) {//abaixo das outras peças, coloca para cima if (!pecaexercicio) { //peça nova – veio da fábrica GLfloat difX = xTrans - pontoAlto.GetX() + espacoBorda; GLfloat difY = yTrans - alturaY; transAux.MakeTranslation(Point4D(-difX, -difY, 0)); clicado->SetMatrizTransformacao(transAux * clicado->GetMatrizTransformacao()); alturaY += (pontoBaixo.GetY() - pontoAlto.GetY()); } else { //É peça da bandeja que foi colocada para baixo, atualiza a posição de //todas as demais, e adiciona ela ao fim de tudo! ObjetoGraficoExercicio *objAlterado = clicado; atualizaAlturaPecas(); objAlterado->SetId(idPecaExercicio); GLfloat difX = xTrans - pontoAlto.GetX() + espacoBorda; GLfloat difY = yTrans - alturaY; transAux.MakeTranslation(Point4D(-difX, -difY, 0)); objAlterado->SetMatrizTransformacao(transAux * objAlterado->GetMatrizTransformacao()); alturaY += (pontoBaixo.GetY() - pontoAlto.GetY()); listaBandeja[idPecaExercicio] = objAlterado; idPecaExercicio++; } } //...código... }
Quadro 24 – Trecho de código correspondente ao reposicionamento da peça colocada
Se a peça foi criada e colocada no exercício ao lado das demais, ou seja, em uma linha
horizontal, é feita a validação para ver se é uma peça filha e então é removida da lista de
exercício e adicionada na lista de filhas da peça. A adição do filho pode ser analisado no
Quadro 25.
void pecas2D_mouse(int button, int state, int x, int y) { //...código... if (idPecaFilho > idPecaExercicio) { clicado->SetId(idPecaFilho); idPecaFilho--; } if (!cima) obj->AdicionaFilho(clicado); else obj->InserirPrimeiraPosicaoFilho(clicado); //...código... }
Quadro 25 – Inserção de peça filha a uma peça do exercício
Quando uma peça é adicionada como filha de outra, é realizado um cálculo para
descobrir qual será sua peça antecessora. Para isso a lista é percorrida até ser encontrada a
peça que está ao lado da posicionada. Ao pegar a futura antecessora, é calculada a altura da
peça e sua largura para então realizar o encaixe. Esse cálculo é feito a partir dos pontos da
50
peça capturados da lista de pontos. Então, a peça filha é colocada no ponto de origem e em
seguida ela é transladada conforme a largura da peça pai e sua altura em relação ao cenário.
Esse processo pode ser verificado na Figura 17.
Se a peça antecessora já possuir peças filhas, ela também é modificada. Nesse caso, é
calculada também a altura da peça sucessora, para ser acrescentada na altura da peça pai. Essa
altura calculada é acrescentada em cada y dos vértices da parte inferior da peça pai. Assim a
peça fica maior e permite o encaixe do próximo filho. Para o próximo filho também é
acrescida sua altura na translação em y . O filho pode ser inserido na primeira posição, se a
peça estiver no início da antecessora, ou na última posição. Essa interação pode ser analisada
na Figura 18.
Figura 17 – Deslocamento de uma peça filha
51
Figura 18 – Deslocamento das peças para mais de um filho
Se uma peça que já está na bandeja for colocada ao lado de outra peça da bandeja, a
primeira é inserida a cima ou abaixo da segunda peça conforme a posição colocada. Para
encontrar a peça horizontal é feito o mesmo cálculo realizado para encontrar a peça pai de
uma filha. Ao inserir uma peça acima de outra, a peça que está embaixo será transladada em y
a altura da peça que foi adicionada a cima. Isso ocorrerá para todas as peças abaixo da peça
transladada.
3.3.1.2 Visualização do código-fonte das peças
Como cada peça representa um comando da OpenGL ou um código-fonte que alterará
a matriz de transformação, ao clicar sobre uma peça é verificado o tipo dela e então é escrito o
código-fonte com a função desenhaTexto() na janela específica. A janela de código-fonte é
redesenhada cada vez que for clicado em uma peça, ou quando for alterada as propriedades de
uma peça, como a cor ou as coordenadas x , y e z das transformações.
Para fazer o agrupamento de códigos, a função escreveCodigo() é chamada
52
recursivamente dentro de uma peça do tipo glPushMatrix() glPopMatrix() para cada um
de seus filhos. Assim o comando só é finalizado no último filho encontrado. Pode observar
um trecho da função escreveCodigo() no Quadro 26.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
int escreveCodigo(ObjetoGraficoExercicio *obj, int x, int y) { switch (obj->getTipo()) { case 'c': { y += TAMANHO_LINHA; desenhaTexto(x, y, (char *)"SetMatrizTransformacao (GetMatrizTransformacao() * matrizAcumulada);"); y += TAMANHO_LINHA; if (obj->GetCor()->GetR() == 255) desenhaTexto(x, y, (char *)"glColor3f(255, 0, 0);"); //...código... desenhaTexto(x, y, (char*) "glLineWidth(GetEspessura());"); y+= TAMANHO_LINHA; desenhaTexto(x, y, (char*)"glMultMatrixd(GetMatrizTransformacao(). GetData());"); y += TAMANHO_LINHA; desenhaTexto(x, y, (char*) "glutSolidCube(1.0f);"); if (final) y = TAMANHO_LINHA; return y; } case 'e': { char cx[16], cy[16] , cz[16]; ObjetoTransformacao *objTrans = static_cast<ObjetoTransformacao*> (obj); //...código... desenhaTexto(x, y, (char*)"matrizAux.MakeScale("); x += 125; desenhaTexto(x, y, cx); x += 25; desenhaTexto(x, y, (char*)", "); x+= 20; //...código... desenhaTexto(x, y, (char*)"matrizAcumulada = matrizAcumulada * matrizAux;"); if (final) y = TAMANHO_LINHA; return y; } case 't': //...código... case 'r': //...código... case 'p': y += TAMANHO_LINHA; desenhaTexto(x, y, (char*)"glPushMatrix();"); final = false; for (int i = 0; i < obj->GetQuantidade(); i++) { ObjetoGraficoExercicio *filho = static_cast<ObjetoGraficoExercicio*> (obj->GetFilho(i)); y = escreveCodigo(filho, x, y); } y += TAMANHO_LINHA; desenhaTexto(x, y, (char*)"glPopMatrix();"); final = true; y = TAMANHO_LINHA; return y; } }
Quadro 26 - Trecho da função escreveCodigo()
53
Analisando o código, conforme a linha 3 é verificado o tipo da peça selecionada, então
é executada a parte do código interna ao comando case conforme o tipo selecionado. Como
exemplo, a partir da linha 4 até a linha 21 é realizado a construção do código para a peça que
representa o cubo.
O texto do código-fonte sempre é alinhado nos eixos x e y, logo, a variável y controla a
altura em que o texto está sendo escrito dentro da janela de código-fonte e a variável x a
distância com relação a margem. A função desenhaTexto() escreve nas posições x e y um
texto passado como parâmetro dentro da janela de código-fonte. Sempre após escrever todo o
texto de código, a variável y volta a ser inicializada para que o próximo código a ser escrito
inicie também na borda da janela.
Para desenvolver o código do comando do empilhamento de matrizes, como é visto na
linha 45, é feito um laço de repetição para percorrer todas as peças filhas. Para cada peça filha
é chamada recursivamente a função escreveCodigo() . Assim, o código de cada peça interna
é escrita e somente por fim é finalizado o comando do empilhamento com o comando
glPopMatrix() presente na linha 51.
3.3.1.3 Visualização do cenário 3D a partir das peças colocadas
A colocação das peças do exercício é realizada em um plano 2D para então gerar os
objetos gráficos em um espaço 3D conforme a ordem em que essas peças são colocadas (ver
seção 2.2.2). É disponibilizado um código de exemplo em C++ com OpenGL para que o
usuário possa analisá-lo e estudar como construir um espaço com objetos da OpenGL.
O código exemplo necessita da configuração das peças colocadas na bandeja. Essa
configuração é gravada em um arquivo texto a partir da classe gravarArquivoTexto que foi
desenvolvida utilizando o tipo ofstream do C++. A função mais utilizada da classe foi a
gravarString que tem como parâmetro o texto a ser adicionado no arquivo (ver Quadro 27).
void GravacaoDeArquivo::gravarString(std::string texto) { *arquivo << texto << std::endl; }
Quadro 27 – Função adicionarTexto da classe arquivoTexto
Essa função e as funções criarArquivo e finalizar são chamadas na classe
Principal , quando o usuário clica na opção “gravar exercício” sobre a bandeja. O código
gerado armazena apenas as configurações das peças e suas propriedades na ordem em que
54
estão adicionadas no exercício.
Para gravar as peças na bandeja e suas configurações foram criadas duas funções, a
gravarObjetos() que percorre a lista principal e grava os itens da peça a partir da segunda
função gravarItens() . E em seguida percorre a lista de filhos, quando houver, também
chamando a função gravarItens() para gravar suas particularidades. As duas funções
podem ser analisadas nos Quadros Quadro 28 e Quadro 29, respectivamente.
void gravarObjetos(GravacaoDeArquivo arquivo) { for (int i = MAX_GABARITO; i < 255; i++) { //percorre peças da fábrica gravarItens(arquivo, listaBandeja[i]); if (listaBandeja[i] != NULL) { for (int j = 0; j < listaBandeja[i]->GetQuantidade(); j++) { //percorre peças filhas quando há gravarItens(arquivo, static_cast<ObjetoGraficoExercicio*> (listaBandeja[i]->GetFilho(j))); } } } }
Quadro 28 – Código para salvar as peças do exercício
void gravarItens(GravacaoDeArquivo arquivo, ObjetoGraficoExercicio *obj) { if (obj != NULL) { arquivo.gravar(obj->getTipo()); //grava tipo arquivo.gravarNumero(obj->GetListaPontos().at(0).GetY()); //grava ponto mais //baixo arquivo.gravarNumero(obj->GetListaPontos().at(1).GetY());//grava ponto mais //alto //grava cores: arquivo.gravarNumero(obj->GetCor()->GetR()); arquivo.gravarNumero(obj->GetCor()->GetG()); arquivo.gravarNumero(obj->GetCor()->GetB()); arquivo.gravarNumero(obj->GetId()); //grava a translação em x e y: Point4D *p = new Point4D(); obj->GetMatrizTransformacao().GetTranslation(p); std::string str = para_string(p->GetX()); arquivo.gravarString(str); str = para_strin(p->GetY()); arquivo.gravarString(str); str = para_string(obj->GetEspessura()); arquivo.gravarString(str); //grava espessura str = para_string(obj->GetQuantidade()); arquivo.gravarString(str); //grava quantidade de filhos //grava a transformação do objeto a partir dos pontos x, y e z: ObjetoTransformacao *objTrans = static_cast<ObjetoTransformacao*> (obj); str = para_string(objTrans->getX()); arquivo.gravarString(str); str = para_string(objTrans->getY()); arquivo.gravarString(str); str = para_string(objTrans->getZ()); arquivo.gravarString(str); } }
Quadro 29 – Código para salvar as particularidades de cada peça
55
Ao executar a aplicação exemplo, essa lê o arquivo com as configurações das peças e
monta o cenário 3D. Esse cenário carrega as transformações e peças conforme a realização do
exercício na AduboGL. A aplicação exemplo utiliza algumas das classes da AduboGL para
modelar os objetos criados, assim como para ler o arquivo.
3.3.2 Operacionalidade da implementação
A operacionalidade da aplicação é apresentada a partir de imagens que mostram as
funcionalidades e os casos de uso. São exibidas imagens tanto da AduboGL quanto da
aplicação exemplo, que mostra o cenário 3D executado a partir das peças encaixadas.
Ao iniciar a aplicação é aberta a tela que pode ser vista na Figura 19 que é dividida em
4 sub janelas. A primeira janela (esquerda), por sua vez, é dividida em duas partes, onde a
primeira é a fábrica e a segunda a bandeja. A parte da fábrica apresenta as possíveis peças a
serem utilizadas no desenvolvimento do exercício e a bandeja é usada para a montagem do
exercício. A segunda janela é a de código-fonte que corresponde ao código da peça
selecionada, sendo da fábrica ou da bandeja. As outras duas telas são utilizadas para a
apresentação da cena em 3D, resultante do exercício montado.
Figura 19 – Tela da AduboGL
A interação que o usuário da aplicação fará será sobre a janela de fábrica e bandeja. As
demais janelas são apenas visuais, para que o mesmo possa ver o resultado de seu exercício.
56
3.3.2.1 Desenvolvendo um exercício na AduboGL
Nesta seção é mostrado passo a passo como um exercício pode ser resolvido usando da
AduboGL. O exercício a ser resolvido está descrito no Apêndice A e trata da geração de uma
cena 3D com três cubos transformados.
Como o primeiro cubo é para estar na origem da cena e não sofre nenhuma
transformação, a primeira peça a ser colocada deve ser a que representa o cubo, conforme a
Figura 20. Para colocar o cubo na bandeja, deve-se clicar sobre a peça correspondente na
fábrica e arrastá-la para a bandeja. Ao realizar isso é possível visualizar o código
correspondente ao cubo 3D na janela de código-fonte. Observa-se que a matriz de
transformação é multiplicada pela matriz acumulada, para realizar as transformações quando
houver alguma. Nesse caso, não há transformações ainda, então a matriz acumulada será uma
matriz identidade. Pode-se notar também que a cor do cubo será azul e o mesmo será
desenhado com arestas de uma unidade.
Figura 20 – Inserção de um cubo na origem da cena
O segundo objeto a ser colocado na cena 3D é um cubo transladado. Como a
translação será somente do segundo cubo, deve-se colocar uma peça do tipo glPushMatrix()
glPopMatrix() para encapsular a transformação a ser realizada. Para colocar a peça, a
mesma deve ser arrastada da fábrica até abaixo da última peça colocada na bandeja. Após
colocar a peça amarela, que representa esse comando, deve-se colocar a peça correspondente
a translação na linha horizontal ao comando glPushMatrix() glPopMatrix() . Isso fará com
que a translação seja encaixada tornando-se filha do primeiro comando colocado. O processo
pode ser acompanhado na Figura 21. Ao adicionar uma peça filha dentro de outra peça, essa
deve vir da fábrica. Caso venha da própria bandeja, as peças apenas são alteradas de posição.
57
Figura 21 – Inserção de peça glPushMatrix() glPopMatrix() com uma translação interna
Observa-se no quadro de código-fonte (Figura 21) da translação que os valores a serem
transladados em x , y e z estão zerados. Logo, os valores devem ser alterados a partir das
teclas numéricas de 1 a 6. As teclas 1 e 2 aumentam e diminuem o valor do eixo x , as 3 e 4
aumentam e diminuem o valor do eixo y e a 5 e 6 aumentam e diminuem o valor do eixo z,
respectivamente. Deve-se clicar quatro vezes na tecla 2 e cinco vezes na tecla 4 para que a
próxima peça seja transladada 4 unidades em x e 5 em y , lembrando que antes deve ter sido
clicado na peça da translação. O código-fonte da peça deverá ficar como mostrado na Figura
22.
Figura 22 - Código-fonte alterado da peça translação
Após a alteração dos valores a serem transladados pode-se colocar a peça que
representa o cubo. Essa deve ser posicionada ao lado do comando glPushMatrix()
glPopMatrix() , porém abaixo da peça (translação) que já é filha. Assim a translação é
aplicada ao cubo. As peças dentro de uma peça pai não podem ser trocadas de lugar, apenas as
peças antecessoras podem. Assim, caso tenha colocado a peça no local errado, deve-se
remover o pai de todas as peças e então adicioná-lo novamente. Para remover a peça pai,
deve-se clicar sobre ela e arrastá-la até a área da fábrica. Com o cubo encaixado e
selecionado, como ele deve ser na cor verde, deve ser pressionada a tecla G. Dessa forma, a
peça será colorida na cor verde e o código será alterado. Ao clicar na peça pai da
transformação e do cubo é visualizado o código geral na janela de código-fonte. A inserção e
modificação da peça cubo assim como o código da peça pai podem ser visto na Figura 23.
58
Figura 23 – Peça com duas sucessoras e visualização de seu código-fonte
Nota-se que é realizado o comando glPushMatrix() para encapsular as
transformações e em seguida é feito o comando makeTranslation da matriz de
transformação para ser colocada na matriz acumulada. Esse comando recebe os valores de x,
y e z aplicados na peça correspondente a translação colocada no exercício. Após, a matriz
acumulada é multiplicada pela matriz corrente, que é a matriz do cubo, é setada a cor do cubo
que foi modificada para verde e então o cubo é desenhado. Por fim, utiliza-se o comando
glPoMatrix() para desempilhar a matriz de transformação.
A última peça a ser colocada na cena 3D é um cubo na cor vermelha com as três
transformações. Para isso deve ser colocada novamente uma peça do tipo glPushMatrix()
glPopMatrix() . A peça deve conter quatro filhos, sendo eles uma peça do tipo escala, outra
do tipo rotação, outra do tipo translação e por fim a peça do tipo cubo. As peças devem ser
colocadas uma por vez ao lado da peça glPushMatrix() glPopMatrix() e abaixo da peça
anterior, caso a mesma já tenha algum filho. Pode-se colocar todas as peças para depois fazer
a modificação de suas propriedades ou conforme cada peça é colocada a propriedade pode ser
alterada. O importante é ter sempre selecionada a peça antes de aplicar a alteração da
propriedade. Lembra-se que para realizar as modificações nos eixos x , y e z deve-se utilizar as
teclas de 1 a 6 e para colorir o cubo de vermelho deve ser pressionada a tecla R. Após a
construção pode ser clicada sobre a peça antecessora das quatro para visualizar o código
completo do terceiro cubo. A Figura 24 exibe a formação das peças para a resolução do
exercício, assim como o código correspondente ao último cubo.
59
Figura 24 – Visualização da resolução do exercício assim como o código do último cubo
Na janela de código-fonte pode ser visto que o comando glPushMatrix()
glPopMatrix() circundam as transformações realizadas sobre o cubo, assim como a função
que o desenha. Assim, as transformações serão aplicadas somente a essa peça. Também pode
ser notado que cada transformação é aplicada sobre uma matriz auxiliar a partir dos valores
das coordenadas indicadas nas peças e então é multiplicada pela matriz acumulada. Sempre
que é realizado um comando de transformação, a matriz recebe sua identidade e então calcula
a transformação com base no ponto de origem. Logo, é necessário ter uma matriz auxiliar para
não perder as transformações realizadas sobre o objeto. Depois de calculada a transformação
com base na origem, essa deve ser passada para uma matriz que acumula todas as
transformações a serem aplicadas sobre o objeto. Isso é feito a partir da multiplicação da
matriz auxiliar com a matriz acumulada. Assim, quando a matriz do cubo for multiplicada
pela matriz acumulada, ela terá todas as transformações realizadas para aplicar na peça. E
assim a primeira parte do exercício é finalizada.
O código-fonte apresentado na janela código-fonte durante a realização do exercício é
também utilizado para exibir a cena gerada em 3D. Logo, pode-se observar a cena em 3D para
a primeira parte do exercício ao salvá-lo (Figura 24). O exercício é gravado clicando-se com o
botão direito do mouse sobre a bandeja e em seguida no menu “gravar exercício”. Um arquivo
“Exercicio.txt” é gerado na pasta do projeto. A aplicação lerá o arquivo e carregará a cena 3D
conforme é apresentado na Figura 25. Essa cena é carregada de duas formas, uma a partir da
visão de uma câmera e outra vista de frente, assim o usuário pode analisar o cenário em
formas diferentes. Os três cubos montados a partir do plano 2D na AduboGL é visualizado em
um espaço 3D com suas transformações.
60
Figura 25 – Aplicação exemplo executando exercício gerado
Após a visualização da cena em 3D pode ser feita a segunda parte do exercício. Nessa
parte a cena toda deve ser transladada em quatro unidades para x . Para isso, deve-se abrir
novamente o exercício caso tenha fechado, clicando com o botão direito na bandeja e em
seguida no menu “abrir exercício”.
Com o exercício carregado, pode ser realizada a modificação sobre ele. Como toda a
cena deverá ser transladada, deve ser colocada uma peça translação. Lembra-se que para ela
não ser removida do exercício, a primeira vez ela deve ser posicionada abaixo de todas já
colocadas, como mostra a Figura 26.
Figura 26 – Inserção de peça translação
Após a peça colocada, pode-se alterar o valor x a ser transladado pressionando a tecla
numérica 2 quatro vezes. Para que a translação seja sobre toda a cena, ela deve ser
posicionada por primeiro, sobre todas as demais peças. Deve-se clicar sobre a peça a ser
movida e arrastá-la até o topo da bandeja para soltá-la. Assim a peça irá ocupar a primeira
posição da bandeja. O resultado é observado na Figura 27.
61
Figura 27 – Reposição da peça translação
Feita a alteração no exercício, pode-se salvá-lo. A nova cena 3D será a mesma da
anterior, porém deslocada no eixo x , conforme é visto na Figura 28. Assim o exercício é
concluído.
Figura 28 – Cena 3D resultante do exercício
3.4 RESULTADOS E DISCUSSÃO
Para analisar a aplicação foram realizados os testes de performance e usabilidade. Os
resultados obtidos por cada um dos testes pode ser visto nas seções 3.4.1 e 3.4.2.
62
3.4.1 Resultados obtidos na análise de performance
Para realizar o teste de performance a função NOW() do framework V-ART foi
chamada em pontos estratégicos. Essa função retorna a hora atual. Para calcular o tempo que
uma determinada tarefa levou para ser executada foram subtraídos dois tempos. Um capturado
no início da tarefa e outro capturado no término. A partir da subtração dos dois tempos, pode-
se obter o intervalo de tempo que a aplicação levou para apresentar um resultado gráfico na
tela.
O primeiro tempo obtido refere-se ao deslocamento que uma peça faz após ser
colocada na bandeja. O tempo retornado foi de 0,005 milissegundos.
O segundo tempo obtido foi da adição de filhos em uma peça. O tempo inicial para
calcular o intervalo foi determinado quando o algoritmo começou a encontrar a peça pai e o
tempo final foi após a adição da peça filho. Para obter vários intervalos, foram colocadas
cinco peças sucessivas para uma mesma peça. E duas peças sucessoras em uma segunda peça.
Os valores em segundos podem ser observados no Quadro 30.
Peça 1 0,029 ms Peça 2 0,041 ms Peça 3 0,049 ms Peça 4 0,049 ms Peça 5 0,053 ms Peça 6 0,023 ms Peça 7 0,041 ms
Quadro 30 – Tempo para adicionar uma peça filho a uma peça pai
Pode-se notar que o tempo aumenta conforme são adicionados os filhos na peça, pois a
cada novo filho sobre a mesma peça, é realizado um cálculo para verificar qual será a posição
do filho. E ainda, se esse for adicionado como primeiro filho da peça, os demais são
deslocados para baixo.
O terceiro e último tempo obtido foi ao alterar os valores de x , y e z em uma
transformação. O tempo inicial para calcular o intervalo foi no momento em que a tecla é
pressionada e o tempo final após a alteração do texto na janela de código-fonte. Foram feitas
alterações de vários eixos e de transformações diferentes, obtendo-se uma média de 0,010
milissegundos.
No gráfico representado pela Figura 29 tem-se uma comparação entre as médias de
tempos obtidas.
63
Figura 29 - Gráfico de média de tempos
A partir dos tempos obtidos, pode-se notar que conforme aumenta a complexidade da
ação e a quantidade de peças a serem comparadas no código, maior o consumo de tempo.
3.4.2 Resultados obtidos na análise de usabilidade
Como não foi possível aplicar em uma sala de aula, da maneira como um software
educativo deveria ser analisado, foram escolhidos alunos 10 alunos de diversos semestres dos
cursos de Ciência da Computação e Sistemas de Informação para realizar o teste. Seis alunos
já haviam cursado a disciplina de Computação Gráfica, porém os outros quatro ainda não.
Logo, para avaliar a usabilidade da aplicação foi criado um exercício (ver Apêndice A)
e solicitado para esses alunos o realizarem. Como um SE possui relação direta entre professor,
aplicação, aluno, foi realizada uma explicação de como utilizar a AduboGL e como a mesma
funcionada, antes de o entrevistado iniciar o teste, sendo esse o papel do professor.
Para os que não cursaram a disciplina foi informado que para as transformações serem
acumuladas a um objeto, essas devem estar dentro de um comando glPushMatrix()
glPopMatrix() e que devem estar acima do objeto a ser transformado.
Após a realização do exercício foi solicitado para os alunos responderem a um
questionário de cinco perguntas. Essas perguntas tem por objetivo saber o que os mesmo
acharam sobre o uso da aplicação e se ela auxiliou ao entendimento das transformações sobre
os objetos gráfico. As perguntas podem ser vistas no Quadro 31.
64
1. O que você achou do layout do aplicativo? O tamanho das janelas está bom? 2. Qual foi a dificuldade encontrada para realizar o exercício? 3. O código-fonte visualizado na janela de código é legível e fácil de compreender? 4. O aplicativo ajudou no entendimento de transformações? Por quê? 5. Quais são suas sugestões de melhoria para o aplicativo?
Quadro 31 - Formulário de perguntas aos usuários da aplicação
Quase todos os alunos entrevistados conseguiram realizar o exercício, porém a partir
das respostas pode-se observar que aqueles que não cursaram a disciplina de Computação
Gráfica ainda tiveram um pouco de dificuldade em entender a funcionalidade e a ordem em
que as peças devem ser colocadas.
Quanto ao layout do aplicativo, a maioria achou bom, intuitivo e lúdico. E também
acharam adequado o tamanho das janelas. Alguns comentaram que seria melhor aumentar um
pouco a letra da janela de código-fonte e um entrevistado comentou que a cada comando
deveria ter uma representação gráfica diferente.
Com relação à janela de código-fonte, aqueles que já cursaram a disciplina informaram
que é legível, fácil de entender e permite ver o código gerado a partir das peças empilhadas. Já
aqueles que não cursaram a matéria sugeriram criar um material explicando o significado das
variáveis e tiveram um pouco de dificuldade para compreender, embora comentassem ter o
achado simples.
Os entrevistados indicaram que a aplicação ajuda no entendimento das transformações
aplicadas sobre uma peça, pois podem ver os valores da matriz de transformação e como elas
estão sendo aplicadas. Também informaram que conseguem ver facilmente a ordem em que
os comandos são executados na pilha, pois está em uma forma didática. Outro ponto citado foi
a simplificação do código OpenGL que normalmente tende a ser complexo.
Como melhorias, foi apontado que deveria ter um tutorial ou manual ensinando a
utilizar a aplicação. Também foi registrado que poderia ter uma forma de visualizar o cenário
3D em diferentes ângulos. A partir dessas melhorias apontadas, observou-se que a maioria
delas era um objetivo específico ou um RF que foi alterado para as extensões do trabalho (ver
seção 4.1). Um entrevistado que não cursou a disciplina informou que devia ser trocado o
nome de translação para move. Porém, optou-se por manter o nome para que o aluno
associasse o nome à matriz utilizada na transformação geométrica e não às funcionalidades de
uma aplicação gráfica.
65
3.4.3 Considerações gerais
O presente trabalho teve como objetivo inicial o desenvolvimento de um framework,
porém a aplicação desenvolvida ainda não se enquadra nesse conceito, apesar desse trabalho
já disponibilizar alguns trechos de código para o desenvolvedor. Resolveu-se então identifica-
la como aplicação.
Para que o aluno pudesse aprender os conceitos da Computação Gráfica de forma mais
simplificada seria necessário disponibilizar além de um framework um ambiente onde o aluno
pudesse treinar e trabalhar as funções disponíveis nele. Como não havia tempo hábil para o
desenvolvimento dos dois, o framework e a aplicação, foi decidido focar no desenvolvimento
da aplicação.
Logo, o segundo objetivo específico que era a disponibilização de um tutorial
utilizando o framework chegou mais perto do novo objetivo principal, pois este era
desenvolver uma aplicação que permitisse o estudo da computação gráfica a partir da
biblioteca OpenGL e que utilizasse a linguagem C++ como base. E esse conceito foi utilizado
para o desenvolvimento da aplicação resultante, a qual permite que o aluno trabalhe com
diversos conceitos da biblioteca OpenGL com base na linguagem de programação C++.
Como o trabalho não seguiu a linha do framework algumas funcionalidades não
puderam ser implementadas, como permitir que o usuário do framework utilize as funções
definidas em seu programa e permitir que a partir das funções criadas sejam adicionadas
novas funções. Porém, pode-se afirmar que como a aplicação desenvolvida é de código
aberto, o usuário pode pegar funções prontas para reaproveitar em seu código. Outro fator é
que como existe a janela de código-fonte, o código apresentado por ela também pode ser
utilizado pelo usuário em suas aplicações. Nesse caso, o usuário pode montar o exercício na
aplicação, visualizar se a cena resultante era o esperado e analisar o código-fonte gerado por
cada peça. Então, ele pode adaptar o código-fonte gerado e colocar em sua aplicação.
O trabalho realizado pode ser considerado um Software Educativo (ver seção 2.1.1),
pois tem por objetivo favorecer o processo de ensino-aprendizagem na área da computação
gráfica com foco nas transformações geométricas. A partir de exercícios propostos por um
professor, o aluno pode colocar em prática o conteúdo aprendido em sala de aula e esclarecer
eventuais dúvidas que venha a ter. O que mais o caracteriza como um SE é a interação entre o
software, o aluno e o professor. Dessa forma, o trabalho produzido pode ser considerado um
SE com ênfase em simulação de cenas 3D com a utilização da lógica. Ainda, pode-se dizer
66
que se enquadra na classificação de ser interativo com o usuário permitindo assim um melhor
aproveitamento pedagógico. Ao mesmo tempo, a aplicação desenvolvida tem uma ideia
lúdica, pois se baseia em peças, como as de um quebra-cabeça do mundo real, para montar os
exercícios propostos.
Para a aplicação foram desenvolvidas rotinas para controlar a movimentação das peças
do exercício. Inicialmente estava sendo utilizada a cor alpha do pixel para retornar a peça
selecionada. Assim, cada peça utilizava o padrão RGB Alpha (RGBA) onde no campo alpha
era indicado o identificador da peça. Dessa forma, nenhuma peça possuía o mesmo valor para
alpha. Então, quando fosse clicado com o mouse na tela, as cores do pixel eram lidas e a partir
da cor alpha retornada sabia-se o identificador da peça selecionada. No início funcionou
tranquilamente, mas após certo tempo o procedimento passou a funcionar apenas no sistema
operacional MacOS, não funcionando no Windows. Não foi descoberto o motivo do
problema, pois até mesmo os exemplos anteriores que utilizavam o alpha e funcionavam no
Windows, passaram a não funcionar mais. Então a decisão tomada para resolver o problema
foi alterar a estratégia de seleção da peça. Todas as classes correspondentes às peças foram
modificadas para comportar uma boundingbox e foram feitas rotinas para selecionar a peça a
partir dela. Como havia uma peça côncava teve de ser analisado também se a peça foi
selecionada a partir do algoritmo da ScanLine. Dessa forma, o clique sobre as peças e sua
seleção voltou a funcionar.
Outro problema encontrado após a modificação do código para a seleção através da
boundingbox foi que as matrizes de transformação das peças filhas eram zeradas ao adicioná-
la a um pai. Isso ocorre devido a multiplicação das matrizes de transformação. Assim, quando
a filha era selecionada pela boundingbox, o algoritmo criado não retornava que a peça
realmente estava selecionada, pois o algoritmo se baseou na matriz de transformação de cada
peça. Para resolver o problema da seleção de uma peça filha, foi subtraído do ponto clicado a
altura das peças anteriores. Dessa forma, era verificado o ponto dentro da boundingbox como
se este iniciasse do zero.
No decorrer do trabalho, foram criados controles para as ações das peças (ver Quadro
14). Porém, o código não foi preparado para que as peças filhas sofressem o mesmo efeito.
Um dos motivos foi que as peças sucessoras e antecessoras pertencem a listas diferentes, e
uma trata o índice da peça como seu próprio identificador, enquanto a outra trata o
identificador e o índice sendo diferentes.
Foi decidido desenvolver o trabalho apenas com o cubo e três transformações possíveis
sobre ele. Um número restrito de comandos, porém tendo essa base, fica mais fácil de o aluno
67
alterar o tipo da peça e criar funções novas. Foram escolhidas essas funcionalidades, pois a
maior dificuldade dos alunos de computação gráfica é entender e visualizar as matrizes de
transformação de um objeto, principalmente em um espaço 3D. Com as peças de
transformações o aluno pode realizar vários testes na aplicação e ver seu efeito no espaço
gráfico, assim como pode analisar a matriz de transformação resultante, podendo aprimorar
seu conhecimento a partir da aplicação.
O resultado obtido foi satisfatório, pois todos os requisitos elencados foram
alcançados, assim como todos os objetivos específicos apresentados na seção 1.1.
Para testar a aplicação foram realizadas algumas análises com base nas etapas de
deslocamento da peça dentro da bandeja após ser adicionada (Figura 16) de inserção de peças
filha dentro de uma peça pai (Figura 18), de alteração do valor da coordenada x em uma
translação (Figura 22). Todas elas acompanhadas da apresentação de seu código-fonte na
janela de códigos. A seguir são apresentados os resultados obtidos na análise de uso de
performance e de usabilidade, finalizando com o comparativo dos trabalhos correlatos com o
presente trabalho.
Em paralelo ao desenvolvido desse trabalho, ocorreu o trabalho de SCHRAMM (2012)
que teve a mesma ideia fundamental de criar uma aplicação educacional, porém como cenário
o estudo de shaders dentro da disciplina de iOS na FURB. Foram padronizados os nomes do
cenário da aplicação, para que os alunos que cursassem as duas matérias se familiarizassem
melhor aos ambientes.
3.4.4 Relação dos trabalhos correlatos com o presente trabalho
Uma vez construída e testada a AduboGL, pode-se fazer um comparativo com os
trabalhos correlatos apresentados, conforme é apresentado no Quadro 32.
Característica Furbot Greenfoot Edugraph AduboGL Interação com o aluno a partir de objetos Sim Sim Sim Sim Capacidade de resolver exercícios Sim Sim Sim Sim Resolução de exercícios via código-fonte Sim Sim Não Não Alteração de parâmetros do código em tempo de execução
Não Não Sim Sim
Explícito uso da OpenGL Não Não Sim Sim Permite alteração da posição da câmera Não Não Sim Não Tipo de cenário 2D 2D 2D/3D 2D/3D Tipo de integração Framework Framework Ferramenta Aplicação
Quadro 32 – Comparação entre trabalhos correlatos
68
Pode-se observar que a aplicação desenvolvida não se enquadra apenas em dois itens,
que são: resolução de exercícios via código-fonte e permite alteração da posição da câmera. O
primeiro item só é atendido pelos frameworks e o segundo item apenas pelo Edugraph. Como
pontos positivos, observa-se que a aplicação utiliza os dois tipos de cenário e atende os
demais itens.
69
4 CONCLUSÕES
Este trabalho apresentou uma aplicação com objetivo de ensinar transformações
geométricas e o empilhamento delas sobre um objeto gráfico (um cubo), utilizando a
linguagem de programação C++ e a biblioteca gráfica OpenGL de forma interativa e lúdica.
Junto com o trabalho, foi entregue a documentação do código-fonte feita no programa
Doxygen.
A partir do levantamento teórico, viu-se que a aplicação é um SE com foco na
interatividade. Ela é um instrumento auxiliar para o professor da disciplina e para que os
alunos tenham uma forma prática antes de iniciar a programação.
Os estudos apresentados da biblioteca OpenGL, framework V-ART e conceito de grafo
de cena foram importantes para o desenvolvimento da aplicação, pois com eles foi mais fácil
de entender o que utilizar para desenvolvê-la e como funciona cada comando. A ideia do
grafo de cena pode ser facilmente aproveitada para a criação de peças filhas, dando um
aprimoramento à aplicação.
A partir das análises realizadas, foi possível observar que quanto mais complexas as
funções e quanto mais peças do vetor são percorridas, maior o tempo gasto para executar.
Porém esse tempo é aceitável, não chegando a comprometer a aplicação. Quanto à análise de
usabilidade foi satisfatória, pois a maioria dos entrevistados gostou da AduboGL achando o
ambiente simples e fácil de trabalhar.
Depois de configurado o ambiente no Microsoft Visual C++ foi fácil de trabalhar.
Alguns problemas ocorreram durante o desenvolvimento, porém conseguiu-se alcançar todos
os objetivos e requisitos levantados.
A aplicação desenvolvida nesse trabalho apresentou funcionalidades semelhantes aos
trabalhos correlatos. Dentre elas pode-se destacar a ideia de tornar um ambiente interativo e
que ensine parte da computação gráfica, como o Edugraph (BATTAIOLA et al., 2002) e de
trabalhar com objetos e seu código-fonte como o Furbot (VAHLDICK; MATTOS, 2008) e o
Greenfoot (HENRIKSEN; KÖLLING, 2004).
A aplicação desenvolvida apresenta uma ideia inovadora dentro da computação
gráfica, pois não foram encontrados aplicativos que interajam com o usuário com objetivo de
ensinar as transformações geométricas que é um tema fundamental para a disciplina. Ainda
com ela, o professor pode disponibilizar exercícios para serem realizados, permitindo assim
que os alunos pratiquem e visualizem o código e a cena em 3D com maior facilidade.
70
4.1 EXTENSÕES
Sugerem-se as seguintes extensões para a continuidade do trabalho:
a) implementar uma função que ao clicar na peça ou no código-fonte exiba sua matriz
de transformação a partir de um hint;
b) implementar um manual de instrução para a aplicação;
c) permitir que o usuário altere a cor do cubo a ser desenhado em 3D a partir de um
menu ou paleta de cores;
d) colocar as imagens PNG sobre as peças, para melhorar a aparência da aplicação;
e) fazer uma janela onde o usuário possa visualizar o grafo de cena correspondente as
peças encaixadas;
f) criar peças para representar as coordenadas de transformação x , y e z ;
g) permitir o encaixe de peças filhas dentro de uma peça que já possui pai, tendo
assim o conceito de peças netas, bisnetas, e assim por diante;
h) implementar a movimentação das peças filhas pela bandeja;
i) permitir a criação de peças do tipo glPushMatrix() glPopMatrix() dentro dela
mesma;
j) calcular o tamanho e a posição das peças em tempo de execução, para que elas
fiquem alinhadas conforme o usuário aumentar a tela;
k) permitir que o usuário copie o código-fonte a partir da janela de código usando a
área de transferência do sistema operacional;
l) implementar janela com o ambiente 3D para exibir o resultado do encaixe das
peças em tempo real, não precisando salvar o exercício;
m) permitir o usuário alterar a posição da câmera, para olhar a cena em diferentes
ângulos.
71
REFERÊNCIAS BIBLIOGRÁFICAS
ALMEIDA, Paulo N. de. Educação lúdica: técnicas e jogos pedagógicos. 7. ed. São Paulo: Loyola, 1994.
ARAÚJO, Luciana P. AduboGL – aplicação didática usando a biblioteca openGL: documentação. Blumenau. 2012. Disponível em: <http://www.inf.furb.br/gcg/gcg/download/TCC2012-1-19-LucianaPAraujo_documentacao.zip>. Acesso em: 18 jun. 2012.
BATTAIOLA, André L. et al. Desenvolvimento de um software educacional com base em conceitos de jogos de computador. In: SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, 13., 2002, São Leopoldo. Anais... São Leopoldo: SBC, 2002. p. 282-290. Disponível em: <http://www.br-ie.org/pub/index.php/sbie/article/view/189/175>. Acesso em: 15 ago. 2011.
BORGES, Thiago T. et al. Ambiente gráfico para a análise de sistemas elétricos de potência utilizando OpenGL. In: CONGRESSO BRASILEIRO DE AUTOMÁTICA, 15., 2004, Gramado. Anais... Porto Alegre: SBA, 2004. Não paginado. Disponível em: <http://www.lti.pcs.usp.br/robotics/grva/publicacoes/outras/cba2004-cd-rom/cba2004/pdf/694.pdf>. Acesso em: 10 set. 2011.
CARNEIRO, Marcelo M. et al. Interact: um modelo de interação para interfaces 2D por manipulação direta. In: SIMPÓSIO BRASILEIRO DE COMPUTAÇÃO GRÁFICA E PROCESSAMENTO DE IMAGENS, 10., 1997, Campos de Jordão. Anais... Campos de Jordão: SBC, 1997. Não paginado. Disponível em: <http://sibgrapi.sid.inpe.br/rep/dpi.inpe.br/ambro/1998/05.21.14.19?languagebutton=en&mirror=sid.inpe.br/banon/2001/03.30.15.38.24&searchsite=sibgrapi.sid.inpe.br:80&searchmirror=sid.inpe.br/banon/2001/03.30.15.38.24&choice=brief>. Acesso em: 5 set. 2011.
CERQUEIRA, Rômulo G.; SILVA, Vânia C. Aprendendo conceitos de computação gráfica através de um ambiente multimídia e interativo com OpenGL. In: WORKSHOP SOBRE INFORMÁTICA NA ESCOLA / CONGRESSO DA SOCIEDADE BRASILEIRA DE COMPUTAÇÃO, 15., 2009, Bento Gonçalves. Anais... Porto Alegre: SBC, p. 1733-1742. Disponível em: <http://bibliotecadigital.sbc.org.br/?module=Public&action=PublicationObject&subject=0&publicationobjectid=134>. Acesso em: 5 set. 2011.
COHEN, Marcelo; MANSSOUR, Isabel H. OpenGL: uma abordagem prática e objetiva. São Paulo: Novatec, 2006.
FÉLIX, Kao C. V-ART. Porto Alegre, fev. 2009. Disponível em: <http://vart.codeplex.com/>. Acesso em: 22 maio 2012.
72
HENRIKSEN, Poul; KÖLLING, Michael. Greenfoot: combining object visualisation with interaction. In: CONFERENCE ON OBJECT ORIENTED PROGRAMMING SYSTEMS LANGUAGES AND APPLICATIONS, 4., 2004, Vancouver. Procedings... New York: ACM Digital Library, 2008. Não paginado. Disponível em: <http://dl.acm.org/citation.cfm?doid=1028664.1028701>. Acesso em: 20 ago. 2011.
KHRONOS GROUP. GLUT and OpenGL utility libraries . [Califórnia], 2011. Disponível em: <http://www.opengl.org/resources/libraries/>. Acesso em: 03 set. 2011.
MACHADO, Liliane S.; MORAES, Ronei M. Cenários 3D interativos com software livre. Revista de Informática Teórica Aplicada, Porto Alegre, v. 12, n. 2, p. 91-112, maio/ago. 2005. Disponível em: <http://www.de.ufpb.br/~labteve/publi/2005_rita.pdf>. Acesso em: 05 set. 2011.
NAKAMURA, Ricardo; TORI, Romero. Ambientes virtuais em Java. In: CARDOSO, Alexandre; LAMOUNIER, Edgard. (Org.). Realidade virtual: uma abordagem prática. São Paulo: [s.n.], 2004. p. 104-122.
NEIDER, Jackie et al. OpenGL programming guide: the official guide to learning OpenGL, release 1. 5th ed. [Califórnia]: Silicon Graphics, 1994. Não paginado. Disponível em: <http://fly.cc.fer.hr/~unreal/theredbook/>. Acesso em: 10 set. 2011.
OLIVEIRA, Celina C.; COSTA, José W.; MOREIRA, Mercia. Ambientes informatizados de aprendizagem: produção e avaliação de software educativo. Campinas: Papirus, 2001.
POZZER, Cesar T. Grafo de cena. Santa Maria, 2007. Disponível em: <http://www-usr.inf.ufsm.br/~pozzer/disciplinas/cga_2_grafo_cena.pdf>. Acesso em: 04 jun. 2012.
______. OpenGL: conceitos básicos. Santa Maria, 2011. Disponível em: <http://www-usr.inf.ufsm.br/~pozzer/disciplinas/cg_9_opengl_basico.pdf>. Acesso em: 10 set. 2011.
REIS, Dalton S. Computação gráfica. Blumenau, out. 2011. Disponível em: <http://www.inf.furb.br/gcg/disciplinas/cg/Material.html>. Acesso em: 26 out. 2011.
______. Disciplina computação gráfica. Blumenau, abr. 2012. Disponível em: <http://www.inf.furb.br/gcg/disciplinas/cg/CG-Slides/CG-03.pdf>. Acesso em: 30 jun. 2012.
SCHNEIDER, Bruno. O framework V-ART. Lavras, set. 2009. Disponível em: <http://algol.dcc.ufla.br/~bruno/v-art/>. Acesso em: 12 mar. 2012.
SCHRAMM, Elizandro J. AduboGL ES 2.0: aplicação didática usando a biblioteca OpenGL ES no IOS. 2012. 78 f. Trabalho de conclusão de curso (Bacharelado em Ciência da Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
73
SILVA, Djalma I. Visualização científica de dados analíticos filtrados por formulações matemáticas. 2000. 130 f. Dissertação (Mestrado em Informática) - Curso de Pós-graduação em Informática, Universidade Federal do Paraná, Curitiba. Disponível em: <http://dspace.c3sl.ufpr.br:8080/dspace/bitstream/handle/1884/25115/D%20-%20SILVA%2c%20DJALMA%20INACIO%20DA.pdf?sequence=1>. Acesso em: 09 mar. 2012.
VAHLDICK, Adilson; MATTOS, Mauro M. Relato de uma experiência no ensino de algoritmos e programação utilizando um framework lúdico. In: WORKSHOP DE AMBIENTES DE APOIO À APRENDIZAGEM DE ALGORITMOS E PROGRAMAÇÃO/ SIMPÓSIO BRASILEIRO DE INFORMÁTICA NA EDUCAÇÃO, 2., 2008, Fortaleza. Anais... Fortaleza: SBC, 2008. Não paginado. Disponível em: <http://sbie2008.virtual.ufc.br/CD_ROM_COMPLETO/workshops/workshop%202/Relato%20de%20uma%20Experi%EAncia%20no%20Ensino%20de%20Algoritmos%20e.pdf>. Acesso em: 20 ago. 2011.
VALENTE, Luis. Representação de cenas tridimensionais: grafo de cenas. Rio de Janeiro, 2004. Disponível em: <http://www.paiossin.com/wordpress/wp-content/plugins/downloads-manager/upload/Arquivos%20Faculdade/TCC%201/LuisValente_SceneGraph.pdf>. Acesso em: 04 jun. 2012.
WRIGHT JÚNIOR, Richard et al. OpenGL suberbible: comprehensive tutorial and reference. 5th. Boston: Pearson Education, 2011.
74
APÊNDICE A – Exercício de OpenGL
O exercício foi utilizado para testar a aplicação com usuários e também para mostrar
como resolvê-lo dentro da AduboGL. O exercício utiliza de transformações sobre a forma
geométrica cubo. No Quadro 33 tem-se o exercício aplicado no teste de usabilidade.
Exercício de computação gráfica:
1) Faça uma cena 3D que contenha 3 cubos, com as características seguintes:
• o primeiro cubo deve estar na origem e ser de cor azul;
• o segundo cubo deve ser na cor verde e estar transladado em 4 unidades para x e 5
unidades para y ;
• o terceiro cubo deve ser na cor vermelha e deve estar escalado em 2 unidades em
todos os três eixos, deve ser rotacionado 4 unidades em x e 2 em z e deve ser
transladado em 5 unidades no eixo z .
Para isso, utilize o aplicativo AduboGL.
Visualize a cena a partir do aplicativo exemplo, e depois altere o exercício para que as
peças fiquem transladadas em 4 unidades no eixo x . Salve e visualize novamente a
cena.
Quadro 33 - Exercício a ser realizado na AduboGL
75
APÊNDICE B – Croqui das peças da AduboGL e suas imagens em PNG
As peças para a fábrica e bandeja da AduboGL foram inicialmente rascunhadas em um
papel. O modelo inicial para as peças está representado na Figura 30.
Figura 30 – Rascunho das peças para a AduboGL
Após o desenho delas, foi realizado um croqui das peças que representariam as
transformações. Elas tem um detalhe na borda esquerda para se encaixar a um comando
glPushMatrix() glPopMatrix() . Também possuem um encaixe oval para adaptar uma na
outra e três posições sendo elas um triângulo, um quadrado e um losango para representar os
eixos x , y e z respectivamente. Elas podem ser vistas na Figura 31.
Figura 31 - Croqui das peças internas
Depois do croqui das peças originais foi feito um mais simples para iniciar a
implementação. Foi decido ter apenas dois tipos de peças, uma em formato de uma letra “C”
quadrada para representar o comando glPushMatrix() glPopMatrix() e as demais em
forma de um quadrado alterando apenas sua cor. Foram calculadas as dimensões dessas peças
76
para que pudessem se encaixar. A Figura 32 representa a peça glPushMatrix()
glPopMatrix() com uma peça interna e suas dimensões, assim como o ponto quente de
encaixe para ambas.
Figura 32 - Desenho das peças iniciais da AduboGL
As figuras iniciais também foram modelas do Corel Draw 2004 em formato PNG para
posteriormente substituir a modelagem da peça a partir das primitivas da OpenGL.
Figura 33 - Peças encaixadas e modeladas no Corel Draw
Na Figura 33 pode-se observar as peças glPushMatrix() glPopMatrix() com duas
peças filhas, sendo elas o cubo e uma transformação. Por sua vez a transformação possui três
filhas para representar as coordenadas.
