UNIVERSIDADE FEDERAL DE SÃO CARLOS

CENTRO DE CIÊNCIAS EXATAS E DE TECNOLOGIA

PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

“Projeto de um framework para auxilio no desenvolvimento

de aplicações com gráficos 3D e animação.”

Rodrigo de Godoy Domingues

São Carlos

Julho / 2003
 2

Ficha catalográfica elaborada pelo DePT da

Biblioteca Comunitária da UFSCar

Domingues, Rodrigo de Godoy

D628pf Projeto de um framework para auxilio no desenvolvimento de
aplicações com gráficos 3D e animação. / Rodrigo de Godoy
Domingues – São Carlos : UFSCar, 2003.
200 p.

Dissertação (Mestrado) -- Universidade Federal de São Carlos,

2003.

1. Computação gráfica. 2. Jogos por computador. 3. Animação por

computador. 4. Renderização em tempo real.
I. Título.

CDD: 006.6 (20ª)

 3

“A maioria das disciplinas não se destina a liberar

e sim a limitar. Não pergunte por quê. Seja
cauteloso com o como. O por quê conduz
inexoravelmente ao paradoxo. O como o
aprisiona num universo de causa e efeito. Ambos
negam o infinito.”
Frank Herbert.

“A memória nunca apreende a realidade. A

memória a reconstrói. Toda reconstrução
modifica o original, tornando-se uma estrutura
externa de referência que inevitavelmente
apresenta falhas.”
Frank Herbert
 4

Aos meus pais, por toda atenção e incentivo prestados;

A Álvaro Fonseca e Silva Jr., por me mostrar que a vida pode ser mais agradável
quando vista através de um espelho distorcido em uma sala dos espelhos.
A todos os criadores de sonhos, pois eles nos fornecem algo pelo que lutar.
 5

Agradecimentos
A Roberto Batista, Marina Batista, Paulo Dias e Olavo D’antonio, pela amizade
existente entre nós e por fazerem minha estada em São Carlos ser mais agradável.
Ao meu professor e orientador, André Luiz Battaiola, atualmente professor no
departamento de Design da Universidade Federal do Paraná, pela confiança
depositada, pela orientação e além de tudo por sua amizade e compreensão.
Aos professores do Departamento de Informática da Universidade Federal de
Uberlândia, pelo incentivo à busca de desafios, pelo conhecimento transmitido e
principalmente pela amizade.
A Mamede Lima Marques, por me incentivar na área de pesquisa, por me fazer
gostar de aprender, por me auxiliar em integrar conhecimentos, pelo auxílio na
decisão em cursar o mestrado e por sua amizade.
A meu amigo Marcus Henrique Lopes Falcão, por me ensinar que na vida
precisamos não apenas ser especialistas, mas também lutar pela aquisição de
conhecimento em outras áreas.
Aos professores do Departamento de Computação da Universidade Federal de
São Carlos, em especial ao professor José Hiroki Saito, por todo auxílio prestado
direta ou indiretamente.
A Rodrigo Assaf e Daniel Gomes de Almeida, pelo auxílio prestado no projeto,
por se interessarem pelo aprendizado e acima de tudo pela amizade e
companheirismo.
A Adriano Cunha, Daniel Caetano, Ricardo Jurckzyk e a todos os outros amigos
ligados ao microcomputador MSX,.pelas horas de diversão, pela troca de idéias e
por ajudarem a manter vivo um sonho.
À Universidade Federal de São Carlos e à CAPes, pelo auxílio financeiro durante
todo o período de curso.
A todos vocês o meu
Muito Obrigado
 6

Resumo
O avanço das técnicas algorítmicas de produção de gráficos e de hardware
dedicados a renderização e processamento geométrico proporcionou o
desenvolvimento de técnicas avançadas em animação e a exibição de gráficos cada
vez mais realistas, impulsionando o mercado tanto de visualização científica quanto
o de entretenimento. Porém, apesar dessas técnicas e algoritmos estarem muito
bem definidos, a comunidade de computação gráfica e animação, muitas vezes,
ignora os processos de planejamento e projeto, objetivando acelerar o
desenvolvimento de um projeto específico, obrigando aos desenvolvedores realizar
o mesmo trabalho de codificação de classes, ou rotinas, repetidas vezes em projetos
diferentes, contrariando os princípios de engenharia de software. Nesse contexto
faz-se necessário o projeto de um framework, objetivado tanto à criação de
aplicações gráficas quanto à criação de aplicações de animação. Apesar de
existirem diversos frameworks para gráficos dinâmicos, a grande maioria ou é
voltada à produção de gráficos bidimensionais ou foram propostos para sistemas
computacionais de estações gráficas caras e voltadas unicamente à produção de
trabalhos acadêmicos ou cinematográficos. Nesse contexto este trabalho apresenta
um estudo sobre as técnicas de computação gráfica, aplicadas a renderização em
tempo real e animações através do levantamento de características e requisitos
objetivando aplicações de simulações visuais, jogos por computador e aplicações
multimídia; analisa diversos motores de jogos para justificar alguns desses requisitos
e, dentro desse contexto, apresenta um conjunto de classes de maneira a compor
um framework cuja finalidade é facilitar o desenvolvimento de aplicativos
configuráveis, independentes de plataforma e que necessitem de renderização 3D
ou animação.
 7

Abstract
The graphics algorithm techniques and geometrical rendering dedicated hardware
advance leaded the development of advanced animation techniques and photo
realistic graphics, impelling both the scientific visualization and the entertainment
markets. However, even this techniques and algorithms being well defined, the
animation and computer graphics community ignores, the most of time, the planning
and design processes, aiming the earlier release of a project, forcing the developers
to do the same classes or routine coding repeated times in different projects, ignoring
the software engineering principles. In this context the design of a framework, aimed
either to graphical or animation applications, is made necessary. Despite the many
dynamic graphics frameworks existence, many of them is aimed to bi-dimensional
graphics production or were proposed to expensive graphical workstations and
aimed only to scientific or cinematographic production. In this context, this work
presents a study about computer graphics and animation techniques gathered
through the characteristics and features aiming visual simulations, computer games
and multimedia applications; analyses several game engines to justify these features
and, in this context, presents a set of classes to compose a framework to ease the
platform independent configurable applications that needs 3D rendering or animation.
 8

Índice

AGRADECIMENTOS............................................................................................................. 5

RESUMO................................................................................................................................. 6

ABSTRACT.............................................................................................................................. 7

ÍNDICE..................................................................................................................................... 8

ÍNDICE DE FIGURAS..........................................................................................................13

ÍNDICE DE TABELAS......................................................................................................... 15

CAPÍTULO 1. - INTRODUÇÃO......................................................................................... 16
1.1. MOTIVAÇÃO E RELEVÂNCIA............................................................................................... 17
1.2. OBJETIVOS...................................................................................................................... 21
1.3. ORGANIZAÇÃO DO TRABALHO............................................................................................ 23
CAPÍTULO 2. - JOGOS ELETRÔNICOS.......................................................................... 25
2.1. CLASSIFICAÇÃO QUANTO AO TIPO...................................................................................... 26
1.1. ESTRATÉGIA..................................................................................................................... 26
1.2. SIMULAÇÃO..................................................................................................................... 26
1.3. AÇÃO............................................................................................................................. 27
1.4. HISTÓRIAS INTERATIVAS (RPG)......................................................................................... 27
1.5. ADVENTURES................................................................................................................... 28
1.6. INFANTIS......................................................................................................................... 28
2.2. CLASSIFICAÇÃO VISUAL....................................................................................................28
1.7. 1ª PESSOA....................................................................................................................... 29
1.8. 3ª PESSOA (GOD VIEW OU GOD’S EYES)............................................................................. 29
2.3. CLASSIFICAÇÃO POR AMBIENTAÇÃO.................................................................................... 31
1.9. AMBIENTES INTERNOS....................................................................................................... 31
1.10. AMBIENTES EXTERNOS.................................................................................................... 32
1.11. ESPAÇO SIDERAL............................................................................................................ 32
1.12. AMBIENTES MISTOS........................................................................................................ 33
2.4. A ESTRUTURA DE UM JOGO................................................................................................ 34
CAPÍTULO 3. - JOGOS COMO APLICAÇÕES MULTIMÍDIA..................................... 35
3.1. VÍDEO.............................................................................................................................36
3.2. ÁUDIO............................................................................................................................ 40
3.3. DISPOSITIVOS DE ENTRADA................................................................................................ 42
1.13. TECLADO.......................................................................................................................43
1.14. JOYSTICK.......................................................................................................................43
1.15. GAME PAD.................................................................................................................... 43
1.16. MANCHE....................................................................................................................... 43
1.17. SISTEMA AUTOMOBILÍSTICO.............................................................................................. 44
1.18. TRACKBALL.................................................................................................................. 44
 9

1.19. MOUSE......................................................................................................................... 44
1.20. RECONHECIMENTO DE VOZ...............................................................................................45
CAPÍTULO 4. - GRÁFICOS................................................................................................. 46
4.1. RENDERIZADOR................................................................................................................ 47
1.21. ESTÁGIO DE APLICAÇÃO.................................................................................................. 50
1.22. ESTÁGIO DE GEOMETRIA..................................................................................................51
1.23. ESTÁGIO DE RASTERIZAÇÃO............................................................................................. 54
1.24. PERFORMANCE EM SISTEMAS DE RENDERIZAÇÃO................................................................. 56
CAPÍTULO 5. - PROCESSAMENTO GEOMÉTRICO....................................................58
5.1. OBJETOS GRÁFICOS.......................................................................................................... 59
1.25. ESTRUTURA VETORIAL.................................................................................................... 59
1.26. CONJUNTO DE FACES...................................................................................................... 60
1.27. ORDENAÇÃO DE VÉRTICES............................................................................................... 61
1.28. ESTRUTURA PARAMÉTRICA...............................................................................................62
5.2. PROCESSAMENTO DE VISIBILIDADE...................................................................................... 63
1.29. PARTICIONAMENTO DO ESPAÇO......................................................................................... 64
1.30. OCTREES....................................................................................................................... 64
1.31. PARTIÇÃO BINÁRIA DO ESPAÇO (BSP)..............................................................................66
1.32. CONJUNTO DE VISIBILIDADE POTENCIAL (PVS)..................................................................68
1.33. REDUÇÃO DE COMPLEXIDADE GEOMÉTRICA E VISUAL......................................................... 70
1.34. NÍVEL DE DETALHE (LOD)............................................................................................ 70
1.35. MIPMAPPING.................................................................................................................73
CAPÍTULO 6. - ANIMAÇÕES..............................................................................................75
6.1. TRADICIONAL................................................................................................................... 78
6.2. PROCEDIMENTAL............................................................................................................... 79
6.3. ESTRUTURAL.................................................................................................................... 80
1.36. ANIMAÇÃO DE OBJETOS ARTICULADOS................................................................................ 80
1.37. ANIMAÇÃO DE OBJETOS MALEÁVEIS:................................................................................. 83
6.4. ESTOCÁSTICA................................................................................................................... 84
6.5. COMPORTAMENTAL............................................................................................................ 85
6.6. CONTROLE DE BAIXO NÍVEL.............................................................................................. 85
1.38. SISTEMAS DE SCRIPT....................................................................................................... 85
1.39. QUADROS CHAVE........................................................................................................... 86
1.40. PARAMÉTRICAS...............................................................................................................87
CAPÍTULO 7. - BIBLIOTECAS GRÁFICAS..................................................................... 88
7.1. DIRECTX........................................................................................................................ 88
7.2. OPENGL........................................................................................................................ 90
7.3. OUTRAS.......................................................................................................................... 92
CAPÍTULO 8. - MOTORES DE JOGOS............................................................................. 93
8.1. MOTORES 2D.................................................................................................................. 94
8.2. MOTORES 3D.................................................................................................................. 95
1.41. ANÁLISE DOS MOTORES...................................................................................................95
1.42. GOLGOTHA.................................................................................................................... 96
1.43. CRYSTAL SPACE............................................................................................................. 98
 10

1.44. GÊNESIS 3D.................................................................................................................. 99

1.45. FLY 3D...................................................................................................................... 100
1.46. FORGE V8.................................................................................................................. 101
CAPÍTULO 9. - DADOS INERENTES A MOTORES DE JOGOS................................106
9.1. OBJETOS GRÁFICOS....................................................................................................... 106
1.47. SPRITES.......................................................................................................................107
1.48. OBJETOS 3D................................................................................................................107
1.49. OBJETOS NÃO ARTICULADOS........................................................................................... 108
1.50. OBJETOS ARTICULADOS OU DEFORMÁVEIS........................................................................109
1.51. BILLBOARDS/IMPOSTORS............................................................................................... 110
1.52. TERRENOS....................................................................................................................111
1.53. TEXTURAS................................................................................................................... 114
1.54. ESTÁTICAS...................................................................................................................115
1.55. ANIMADAS................................................................................................................... 116
1.56. DINÂMICAS.................................................................................................................. 117
9.2. OBJETOS EMPÍRICOS........................................................................................................ 117
1.57. SISTEMA DE PARTÍCULAS............................................................................................... 118
1.58. CONTROLADORES (OSSOS).............................................................................................. 119
1.59. ILUMINAÇÃO................................................................................................................ 120
1.60. EMPÍRICA.................................................................................................................... 121
1.61. MAPAS DE ILUMINAÇÃO.................................................................................................122
1.62. ESTÁTICA.................................................................................................................... 123
1.63. DINÂMICA................................................................................................................... 123
1.64. GRAFO DE CENA.......................................................................................................... 124
1.65. CÂMERAS.................................................................................................................... 126
1.66. JANELAS DE VISUALIZAÇÃO (VIEWPORTS)....................................................................... 127
1.67. RENDERIZADORES......................................................................................................... 127
CAPÍTULO 10. - PRINCÍPIOS DE ENGENHARIA DE SOFTWARE.......................... 129
10.1. PRINCÍPIOS BÁSICOS DA ENGENHARIA DE SOFTWARE.......................................................... 129
1.68. INSTANCIAÇÃO..............................................................................................................129
1.69. ENCAPSULAMENTO........................................................................................................ 130
1.70. REFERÊNCIAS A OBJETOS................................................................................................ 131
10.2. PRINCÍPIOS DE ORIENTAÇÃO A OBJETOS........................................................................... 131
1.71. MODULARIDADE........................................................................................................... 133
1.72. REUSABILIDADE............................................................................................................134
10.3. REUSABILIDADE DE PROJETOS: PADRÕES DE PROJETOS....................................................... 136
1.73. EXEMPLO: ITERATORS....................................................................................................138
10.4. UNIFIED MODELLING LANGUAGE (UML)....................................................................... 140
10.5. RELACIONAMENTO DE CLASSES....................................................................................... 140
1.74. CLASSIFICAÇÃO E HERANÇA...........................................................................................140
1.75. HERANÇA.................................................................................................................... 141
1.76. CLASSIFICAÇÃO............................................................................................................ 142
1.77. EXEMPLO: PONTOS E VETORES SÃO TUPLAS....................................................................... 143
1.78. AGREGAÇÃO................................................................................................................ 144
1.79. ASSOCIAÇÃO................................................................................................................ 145
CAPÍTULO 11. - FRAMEWORKS GRÁFICOS.............................................................. 147
 11

11.1. O MODELO MVC....................................................................................................... 147

1.80. O COMPONENTE MODELO................................................................................................148
1.81. O COMPONENTE VISÃO...................................................................................................149
1.82. O COMPONENTE CONTROLADOR....................................................................................... 150
11.2. APLICAÇÃO DO MODELO MVC....................................................................................... 152
CAPÍTULO 12. - PROJETO: FRAMEWORK PARA GRÁFICOS 3D INTERATIVOS
................................................................................................................................................. 154
12.1. METODOLOGIA............................................................................................................. 154
12.2. FRAMEWORK................................................................................................................ 156
1.83. ESTRUTURA ABSTRATA.................................................................................................. 157
12.3. CARACTERÍSTICAS......................................................................................................... 158
1.84. MÓDULO DE MODELO................................................................................................... 158
1.85. REPOSITÓRIO................................................................................................................159
1.86. REPRESENTAÇÃO DE CENA............................................................................................. 160
1.87. GERENCIADOR DE CENA................................................................................................. 161
1.88. MÓDULO DE VISÃO...................................................................................................... 162
1.89. VOLUME DE VISÃO....................................................................................................... 163
1.90. PROJEÇÃO....................................................................................................................164
1.91. CÂMERA..................................................................................................................... 165
1.92. VIEWPORT...................................................................................................................166
1.93. RENDERIZADOR............................................................................................................ 167
1.94. MÓDULO CONTROLADOR............................................................................................... 168
1.95. SINAL......................................................................................................................... 169
1.96. TEMPORIZADOR............................................................................................................ 170
1.97. DISPOSITIVO DE ENTRADA.............................................................................................. 170
1.98. GERENCIADOR DE ENTRADA........................................................................................... 171
1.99. LEI FÍSICA...................................................................................................................172
1.100. PROPRIEDADE FÍSICA...................................................................................................172
1.101. GERENCIADOR DE SIMULAÇÃO FÍSICA............................................................................173
1.102. OSSOS...................................................................................................................... 175
1.103. REPRESENTAÇÃO DE ANIMAÇÃO.................................................................................... 176
1.104. GERENCIADOR DE ANIMAÇÃO....................................................................................... 177
CAPÍTULO 13. - ESTUDOS DE CASO............................................................................. 179
13.1. ANIMAÇÃO TRADICIONAL............................................................................................... 179
13.2. ANIMAÇÃO CONTROLADA POR SIMULAÇÃO....................................................................... 181
CAPÍTULO 14. - RESULTADOS........................................................................................ 183
14.1. EFICIÊNCIA.................................................................................................................. 183
14.2. GENERALIDADE E DOCUMENTAÇÃO................................................................................. 184
14.3. FACILIDADE DE USO..................................................................................................... 185
CAPÍTULO 15. - CONCLUSÕES....................................................................................... 187
15.1. CONTRIBUIÇÕES............................................................................................................ 187
15.2. PRINCIPAIS DIFICULDADES.............................................................................................. 188
15.3. PROPOSTAS PARA TRABALHOS FUTUROS............................................................................. 188
15.4. CONSIDERAÇÕES FINAIS................................................................................................. 189
 12

APÊNDICE A. – DIAGRAMAS DE CLASSE DO FRAMEWORK..............................191

MÓDULO DE MODELO........................................................................................................... 191
MÓDULO DE VISÃO.............................................................................................................. 192
MÓDULO CONTROLADOR....................................................................................................... 194
BIBLIOGRAFIA.................................................................................................................. 195
 13

Índice de Figuras

FIGURA 1: IMAGEM DO JOGO QUAKE II..................................................................... 29

FIGURA 2: IMAGEM DO JOGO TOMB RAIDER...........................................................30

FIGURA 3: IMAGEM DO JOGO EMPEROR, BATTLE FOR DUNE............................31

FIGURA 4: IMAGEM DO JOGO F1 WORLD GRAND PRIX........................................32

FIGURA 5: IMAGEM DO JOGO PRIVATEER II.............................................................33

FIGURA 6: A CONSTRUÇÃO BÁSICA DO PIPELINE DE RENDERIZAÇÃO...........49

FIGURA 7: O ESTÁGIO DE GEOMETRIA DIVIDIDO EM UM PIPELINE DE

ESTÁGIOS FUNCIONAIS.................................................................................................... 51

FIGURA 8: COMO A ILUMINAÇÃO AFETA A PERCEPÇÃO DA IMAGEM.............52

FIGURA 9: DIFERENÇAS NA PROJEÇÃO PARALELA E EM PERSPECTIVA........53

FIGURA 10: REPRESENTAÇÃO POR CONJUNTO DE FACES...................................61

FIGURA 11: REPRESENTAÇÃO GRÁFICA E ESTRUTURAL DE UMA OCTREE...65

FIGURA 12: ILUSTRAÇÃO DE UMA ÁRVORE BSP BIDIMENSIONAL....................68

FIGURA 13: RESOLUÇÃO DE VISIBILIDADE DO INTERIOR DE UM PRÉDIO

POR []. À ESQUERDA O MODELO TOTAL, À DIREITA A PORÇÃO VISTA PELO
OBSERVADOR....................................................................................................................... 69

FIGURA 14: TRÊS NÍVEIS DE DETALHE DE UM WARBIRD ROMULANO............71

FIGURA 15: PIRÂMIDE DE MIPMAP...............................................................................73

FIGURA 16: CORREÇÃO DE TEXTURA POR MIPMAPPING, O OBJETO DA

ESQUERDA NÃO POSSUI MAPEAMENTO DE TEXTURA POR MIPMAP...............74

FIGURA 17: MÁQUINAS DE ESTADOS DE ANIMAÇÃO............................................78

FIGURA 18: GRAUS DE LIBERDADE.............................................................................. 82

FIGURA 19: ESTRUTURA HIERÁRQUICA, TERMINAÇÕES E NÓ RAIZ...............82

FIGURA 20: ESQUELETO DE UM TENTÁCULO E OS PARÂMETROS (OSSOS) DE

TRANSFORMAÇÃO DE VÉRTICES................................................................................. 84
 14

FIGURA 21: A FIGURA DA ESQUERDA APRESENTA PARAMETRIZAÇÃO DE

INTERPOLAÇÃO POR ROTAÇÃO ENQUANTO QUE A DA DIREITA INTERPOLA
LINEARMENTE OS PONTOS INICIAIS E FINAIS........................................................87

FIGURA 22: CAMADAS E COMPONENTES DO MOTOR FORGE V8.....................103

FIGURA 23: ESTRUTURA DE UM SPRITE....................................................................107

FIGURA 24: BILLBOARDS COMO ÁRVORES EM UMA CENA................................111

FIGURA 25: TERRENO GERADO A PARTIR DE MAPA DE ALTURA E TÉCNICA

DE VOXEL............................................................................................................................ 112

FIGURA 26: EXEMPLO DE UM LIGHTMAPPING...................................................... 122

FIGURA 27: REPRESENTAÇÃO DE UM GRAFO DE CENA......................................125

FIGURA 28: EXEMPLO DE DIAGRAMA DE HERANÇA............................................144

FIGURA 29: RELACIONAMENTO DE AGREGAÇÃO: UM POLÍGONO É

FORMADO POR TRÊS OU MAIS PONTOS................................................................... 145

FIGURA 30: RELACIONAMENTO DE ASSOCIAÇÃO: SEGMENTO DE RETA É

REPRESENTADO POR DOIS PONTOS.......................................................................... 146

FIGURA 31: ESTRUTURA GERAL DO FRAMEWORK...............................................157

FIGURA 32: EXEMPLO DO GRAFO DE CENA DO OBJETO A ANIMAR...............180

FIGURA 33: DIAGRAMA DE CLASSES DO MÓDULO DE MODELO......................191

FIGURA 34: DIAGRAMA DE CLASSES DO MÓDULO DE VISÃO...........................193

FIGURA 35: DIAGRAMA DE CLASSES DO MÓDULO CONTROLADOR..............194

 15

Índice de Tabelas

TABELA 1: REPRESENTAÇÃO DOS TIPOS DE MALHAS POR VÉRTICES

ORDENADOS......................................................................................................................... 62

TABELA 2: ANÁLISE DE EFICIENCIA DE UMA APLICAÇÃO UTILIZANDO A

ARQUITETURA PROPOSTA............................................................................................ 184
 16

Capítulo 1. - Introdução

O avanço nos dispositivos gráficos para estações de trabalho e computadores

pessoais proporcionou o surgimento de um novo estilo de aplicações

computacionais, que se fundamenta na rápida exibição de gráficos de alta qualidade

acoplados a dispositivos de entrada expressivos para obter animação e

renderização em tempo real e metáforas de interação por manipulação direta

permitindo a criação de aplicações com características lúdicas, denominadas de

jogos eletrônicos ou jogos por computador, cujo início, em 1962 com o jogo

Spacewar [1], iniciou uma nova era no ramo da computação e do entretenimento.

Porém, apesar do grande sucesso comercial, o objetivo desses sistemas era voltado

somente ao entretenimento, o que gerou um certo preconceito por parte das

empresas de computação e instituições de pesquisa, as quais não se interessaram

de imediato pela área, fundamentando-se em pesquisas específicas em computação

gráfica ou animação, sem interação com desenvolvedores de tais sistemas que

desenvolviam, paralelamente, suas próprias técnicas.

Atualmente os softwares de entretenimento apresentam níveis excelentes de

qualidade gráfica, efeitos avançados em animação e, conseqüentemente, uma alta

complexidade no seu desenvolvimento devido à necessidade de integração e

interoperabilidade de novas tecnologias atuando em conjunto com os problemas

clássicos, intrínsecos a essas aplicações.

Esta dissertação analisa as metodologias de programação para computação

gráfica e técnicas de animação, referenciando-se a conceitos e funcionalidades já

definidos em muitos projetos de jogos para a criação de um framework, objetivando

auxiliar em projetos de criação bibliotecas de desenvolvimento de jogos, conhecidas

 17

como motor gráfico no jargão dos programadores de jogos, bem como o de

aplicações multimídia em geral.

1.1. Motivação e Relevância

A informática passou por diversas revoluções desde seu surgimento. A evolução

dos computadores para mini e, em seguida, para microcomputadores,

proporcionando a criação dos computadores pessoais, o desenvolvimento dos

ambientes gráficos e sistemas operacionais gráficos, facilitando a utilização para os

usuários leigos e, atualmente, com a disponibilidade e a redução do custo das

unidades de processamento gráficas (GPU), a informática passa por mais uma

revolução, a do entretenimento.

Dados da Interactive Digital Software Association (IDSA), associação

responsável pela realização da Electronic Entertainment Expo (E3), apontam que em

1996 o mercado de jogos eletrônicos movimentou cerca de US$ 3.7 bilhões e em

1999 atingiu o montante US$ 6.1 bilhões só nos Estados Unidos, o que indica um

mercado altamente lucrativo e promissor. Pesquisa da IDSA também mostra que, em

1996, jogos em PC's eram mais usados do que processadores de texto [2].

Em 2002, dados da Datamonitor [3], empresa de consultoria americana, indicam

que as vendas no mercado americano e europeu de software de jogos para

microcomputadores e consoles atingiu a cifra de US$ 10,9 bilhões. A previsão para

2005 é de um mercado internacional avaliado em US$ 20 bilhões, dados da PC

Data. Todos estes dados justificam os investimentos milionários feitos por empresas

como a Sony e a Microsoft nos consoles de jogos PlayStation 2 e XBox,

respectivamente, bem como o investimento feito pela industria de software no

desenvolvimento de jogos.
 18

Atualmente jogos para celulares é o novo foco de investimento da indústria de

jogos. O relatório Wireless Gaming da Datamonitor, [3], indica que 4 entre 5 usuários

de dispositivos móveis em 2005 utilizarão jogos, o que representa um universo de

200 milhões de consumidores na Europa Ocidental e Estados Unidos. Em 2003, os

jogos em celulares deverão movimentar cerca de US$ 1,6 bilhões de dólares nos

EUA e Europa. Este número deverá saltar para US$ 6,0 bilhões em 2005.

Embora o mercado seja altamente lucrativo, poucas instituições científicas

oferecem a devida atenção à área. Este desinteresse se deve em parte ao

preconceito, desinformação, e multidisciplinariedade da área, pois o

desenvolvimento de jogos por computador exige conhecimento em diversas áreas

da Computação, tais como:

a) Computação Gráfica (CG): Necessária ao desenvolvimento da parte de

apresentação visual e de animação dos jogos por computador e, atualmente, é a

área fundamental no desenvolvimento devido ao apelo visual exigido pelo

mercado;

b) Inteligência Artificial (IA): Necessária ao desenvolvimento das ações dos

personagens controlados pelo computador e pelo controle lógico da aplicação, a

qual é responsável por dar “vida” ao jogo propondo os objetivos e oferecendo

obstáculos ao usuário;

c) Engenharia de Software: Responsável pela criação de metodologias para

o processo de análise e desenvolvimento de aplicações em geral;

d) Arquitetura de Computadores: Responsável pelo projeto da arquitetura de

Consoles;
 19

e) Eletrônica: Responsável pela produção dos hardwares e dos projetos de

Consoles;

f) Redes e Sistemas Distribuídos: Responsável pelo desenvolvimento de

protocolos específicos para uso em jogos multi-usuários e

g) Interface Homem-Máquina (IHC): Responsável pelo estudo de novos

dispositivos, interfaces e funções de entrada e saída que facilitem a interação

dos jogadores.

A produção de jogos por computador também envolve conceitos de outras áreas

de conhecimento, tais como música, artes, letras, etc., o que caracteriza a presente

multidisciplinariedade na produção de jogos por computador.

Lamothe [4] cita que a comunidade acadêmica pensa em jogos por computador

como brincadeira de criança e não como um desafio em projeto, programação e

pesquisa. Segundo ele uma classificação errada, pois ele caracteriza a produção

desse tipo de aplicação como um conduto para uma nova dimensão, sintetizada pela

imaginação e realizada pelo desejo do criador. Em outras palavras, um trabalho de

arte.

Apesar de alguns preconceitos ainda encontrados no mundo acadêmico, o valor

mercadológico, tecnológico e educacional do produto tem justificado esforços para a

criação de disciplinas e até de cursos inteiros dedicados à análise e

desenvolvimento de jogos. Revistas técnicas e conferências científicas sobre o

assunto também estão surgindo.

Algumas universidades estrangeiras já apresentam como linha de pesquisa a

área de jogos eletrônicos: University of North Texas (EUA)1, Institut d’informatique de

1
http://larc.csci.unt.edu
 20

Québec (Canadá)2, Centre National d’Animation et de Design (Canadá)3, Middlesex

University School of Computing Science (Reino Unido)4, Universisty of Teesside

(Reino Unido)5, University of Michigan (Reino Unido)6, NgeeAnn Polytechnic

(Singapura)7 e Hong Kong Polytechnic University (Hong Kong). Outras duas

universidades americanas já oferecem cursos completos de graduação: Full Sail

Real World Education8 e DigiPen Institute of Technology9. Todos esses esforços

objetivam fortalecer a indústria de jogos e estreitar os laços com o mundo

acadêmico.

No Brasil, três instituições criaram grupos de pesquisa na área. São elas:

Universidade Federal de Pernambuco (UFPE), Pontifica Universidades Católicas do

Rio de Janeiro (PUC-RJ) e Universidade Federal de São Carlos. Duas disciplinas de

graduação foram criadas no CIn/UFPE para atender e incentivar os alunos

interessados na área e duas universidades criaram cursos de Pós-graduação Latu

Sensu envolvendo jogos por computador, a saber: Centro Universitário Positivo

(Unicemp), campus Curitiba-PR e PUC-RJ.

Na área comercial, o Brasil atualmente se destaca internacionalmente com várias

empresas, das quais três empresas merecem destaque especial: 1) Continuum

10
Entertainment , de Curitiba, PR, com o jogo de estratégia em tempo real Outlive,

por ser a primeira empresa a comercializar um jogo no exterior, 2) SouthLogic

Entertainment 11, de Porto Alegre, RS, por ser a primeira empresa nacional a firmar

2
http://www.iiq.qc.ca
3
http://www.nad.qc.ca
4
http://www.cs.mdx.ac.uk/msc-cg
5
http://www-scm.tees.ac.uk/courses/degree/compgames.html
6
http://bigfoot.eecs.umich.edu/~soar/Classes/494
7
http://www.np.edu.sg
8
www.fullsail.com
9
www.digipen.edu
10
www.continuum.com.br
11
www.southlogic.com.br
 21

acordo com a Infogrames, um Publisher bastante conhecido no mundo por publicar

títulos como a série Alone in the Dark, dentre outros e 3) Jynx Playware12, de Recife,

PE, por implementar o primeiro jogo massive multiplayer no Brasil. Porém, no

cenário nacional, diversos projetos estão sendo, ou já foram, criados. Tal é o caso da
13
Banana Games de São Paulo, SP, Joy Studios 14, em Recife, PE, 4X de Maringá,

PR, além de outras.

1.2. Objetivos

Este trabalho de dissertação propõe uma arquitetura e documentação de um

framework objetivado para a produção de aplicações que utilizem gráficos 3D,

animação interativa e simulação física utilizando, como base de referência, motores

de jogos e trabalhos científicos na área de maneira a levantar as características

fundamentais desse tipo de aplicação.

De acordo com Gobbetti e Turner [5], é possível explorar a similaridade das

estruturas das aplicações que utilizam esses recursos de maneira a criar

frameworks que definem e implementam o projeto orientado a objetos de todo um

sistema inteiro de tal forma que seus componentes relevantes sejam modelados por

classes abstratas que definem o protocolo geral e gerenciam o comportamento

dinâmico padrão que seja usualmente apropriado para a maioria dos casos. Apenas

as características específicas das aplicações devem ser implementadas pelo

projetista através de métodos de herança e redefinições de classes de maneira a

customizar a aplicação. A característica chave de frameworks é que o reuso do

projeto abstrato oferecido por eles é mais importante que o reuso de código.

12
www.jynx.com.br
13
www.bananagames.com.br
14
www.pernambuco.com/tecnologia/empresas.html
 22

O estudo baseado em jogos por computador tem o objetivo de extrair todas as

características e funcionalidades desse tipo de aplicação devido à característica

multimídia inerente a esse tipo de aplicação, como demonstrado no (3) e o interesse

por frameworks que implementam características de renderização em tempo real, ou

seja, gráficos 3D, deve-se a essa ser uma área relativamente inexplorada [5].

Existem diversas bibliotecas para produção de jogos disponíveis publicamente ou

comercialmente, porém elas apresentam desvantagens quanto à generalidade para

produção de aplicações, pois muitas foram projetadas para fins específicos, isto é,

para um produto específico, o que inibe desenvolvedores de jogos a usá-las devido

à generalização de seu produto [43].

Além do problema da falta de generalidade, as bibliotecas publicamente

disponíveis, analisadas para a produção do presente trabalho, apresentam pouca ou

nenhuma documentação, inviabilizando o seu uso, pois o desenvolvedor deve

realizar um trabalho de engenharia reversa de maneira a entender como ela

funciona para poder realizar a sua tarefa, algo inaceitável devido às complicações e

atrasos no desenvolvimento.
 23

1.3. Organização do Trabalho

Este trabalho está organizado em quatorze capítulos, excluindo o apêndice e as

referências bibliográficas.

Cada capítulo é descrito a seguir:

O capítulo 1 apresenta uma introdução, a motivação, relevância e os objetivos da

dissertação;

O capítulo 2 apresenta uma descrição sobre jogos eletrônicos, as classificações

quanto a tipo, visualização e ambientação e uma descrição sobre os elementos que

compõe os jogos por computador;

O capítulo 3 discute jogos como aplicações multimídia, apresentando uma

justificativa dessa assertiva por descrever os componentes de jogos eletrônicos;

O capítulo 4 apresenta uma descrição sobre gráficos em aplicações multimídia,

com o texto focado em gráficos 3D. Apresenta também a estrutura do processo de

geração de gráficos 3D, conhecido como renderização;

O capítulo 5 apresenta técnicas sobre processamento geométrico e visual de

maneira a otimizar a performance de um sistema de renderização e de

gerenciamento de dados em aplicações;

O capítulo 6 apresenta um estudo sobre os diversos tipos de animação que

surgiram ao longo da história, bem como uma breve apresentação da história da

animação em si;

O capítulo 7 apresenta um estudo sobre bibliotecas gráficas, descrevendo duas

das bibliotecas gráficas mais utilizadas atualmente: DirectX e OpenGL;

 24

O Capítulo 8 apresenta uma descrição do que é um motor de jogo, suas

possíveis construções e uma análise de 4 motores de jogos e 1 trabalho de pesquisa

realizado na Universidade Federal de Pernambuco;

O Capítulo 9 apresenta a descrição de alguns dados inerentes a jogos por

computador, os quais são analisados de maneira a compor o projeto do framework

proposto nessa dissertação;

O capítulo 10 apresenta as técnicas de engenharia de software utilizadas no

projeto, bem como a metodologia de projeto com a Unified Modelling language;

O capítulo 11 discute o conceito de frameworks no contexto da computação

gráfica, apresentando alguns frameworks desenvolvidos;

O capítulo 12 descreve o framework projetado no programa de mestrado

apresentando sua organização e suas classes com base na análise dos requisitos

apresentados nessa dissertação, utilizando as técnicas de engenharia de software

apresentadas no (Capítulo 10) e alguns conceitos apresentados no (Capítulo 11);

O capítulo 13 apresenta dois estudos de caso focados em animação tradicional e

animação com simulação física utilizando os conceitos apresentados no projeto do

framework e

O capítulo 14 apresenta as conclusões obtidas no desenvolvimento do projeto e

os trabalhos futuros que podem ser realizados com o conhecimento adquirido

através dessa proposta, bem como os artigos publicados utilizando os conceitos

aqui apresentados.

O apêndice apresenta o diagrama de classes proposto para o framework.

 25

Capítulo 2. - Jogos Eletrônicos

Jogos Eletrônicos são programas cuja finalidade é apresentar um ambiente

lúdico e entreter o usuário, através da proposta de objetivos apresentados em

roteiros, geralmente, fictícios.

Tal tipo de software tem evoluído rapidamente ao longo do tempo, pois em seu

início apresentava textos ou gráficos 2D, usualmente baseados em texturas, e sons

rudimentares criados por geradores de onda (também denominado de canal de

ruído), como os encontrados nos PC’s com a denominação de “PC Speaker”, ou por

processadores sonoros rudimentares, como os presentes em alguns

microcomputadores de 8 bits.

Atualmente jogos por computador fazem uso de diversas mídias (texto, vídeo,

animações, som, etc), apresentam gráficos 3D com excelente qualidade visual, bem

como contam com sons e músicas primorosas que fazem uso de técnicas

sofisticadas de ambientação sonora tais como o estéreo e o surround. Porém,

apesar dessa evolução ampliar a sensação de imersão, a proposta funcional desse

tipo software se mantém inalterada.

De forma a apresentar os objetivos e responder às ações dos usuários, os jogos

devem propor enredos, objetivos e uma interface para a interação do usuário com o

sistema. Geralmente enredo, objetivo e interface estão, até o presente momento,

intimamente relacionados e, em conjunto, classificam o tipo de jogo.

A seguir encontram-se as classificações por tipo, visualização e ambientação de

diversos jogos analisados.

 26

2.1. Classificação Quanto ao Tipo

Embora o tipo de jogo seja de pouca relevância para o presente projeto uma

breve análise dos tipos existentes se faz necessária para que o motor de jogo

implemente funcionalidades capazes de criar as características exigidas nos

mesmos. De acordo com Battaiola [2] os tipos reconhecidos de jogos são:

1.1. Estratégia

São jogos que exigem raciocínio, podem ser em turnos, tais como os tradicionais

jogos de xadrez ou damas, ou de estratégia em tempo real, tais como o Emperor

Battle for Dune [Figura 3] da Westcoast, que, geralmente, apresentam um enredo

que envolve guerra.

1.2. Simulação

São jogos que possuem níveis de complexidade variando de média a alta,

geralmente com jogabilidade15 média a baixa devido à grande quantidade de

comandos necessários para se jogar. Geralmente, respeitam, ou tentam respeitar,

de forma fiel, as leis da física. Dentre estes jogos pode-se citar o Flight Simulator

que apesar de não ser um jogo, é classificado como tal, a série Test Drive e os

diversos títulos de jogos de ação em 1 ª pessoa (Simulação de pessoa ou

guerreiro/soldado).

15
Termo utilizado para indicar o quão atrativo o jogo é em termos de manipulação dos personagens/objetos. Um
jogo de boa jogabilidade geralmente atrairá mais adeptos, como é o caso do clássico Tetris, um jogo de baixa
jogabilidade atrairá menos, tais como os simuladores de vôo.
 27

1.3. Ação

Os jogos de ação podem ser classificados dentre os mais antigos. Suas

características principais são a boa jogabilidade, devido às poucas teclas

necessárias (geralmente as setas direcionais e uns poucos botões), o objetivo bem

definido, uma história simples e a exigência de bons reflexos. Dentre este tipo de

jogo encontram-se os títulos Tomb Raider da Eidos Interactive, Tekken 3 da Namco,

Nemesis da Konami, dentre outros.

1.4. Histórias Interativas (RPG)

RPG é o acrônimo para Role Playing Game, ou jogo de interpretação de papel.

Esse tipo de jogo consiste em uma ambientação contextual (fantasia medieval,

horror, futurista) e um conjunto de regras estatísticas denominado de “sistema de

jogo” onde um dos jogadores denominado de “mestre” cria o esqueleto de uma

história, com diversos pontos em aberto. Essa história se desenvolverá de acordo

com as ações dos personagens interpretados pelos jogadores e as interações deles

com os personagens não jogadores, interpretados pelo “mestre”. O sucesso ou a

falha de suas ações é resolvido, geralmente, através de jogada de dados e do

sistema de regras.

Esse tipo de jogo tem por objetivo criar no computador um ambiente capaz de

proporcionar ao jogador o mesmo tipo de jogo que ele jogaria com um grupo de

amigos. Inicialmente eram desenvolvidos com visualização em 1ª pessoa e,

atualmente, em 3ª pessoa. Sua jogabilidade é fraca devido às diversas teclas

necessárias para executar as ações e a interatividade é baixa devido ao fato da

história estar pré-determinada, porém geralmente o forte desse tipo de jogo é a

 28

história bem elaborada. Dentre este tipo encontram-se os títulos Diablo I e II,

Baldur’s Gate I e II, as diversas séries do Ultima, dentre outros.

1.5. Adventures

Esse tipo de jogo, muito popular entre os micros da geração 8 bits, tinha como

peculiar a interatividade da sua interface. Inicialmente o jogador digitava os textos

para que as ações pudessem ser interpretadas. Geralmente, o jogo não possuía

gráficos, apenas textos. Em evoluções desse tipo de jogo a interface já era

composta pelas palavras (ações), que poderiam ser selecionadas com o mouse e

executadas com um clique num objeto na tela, apresentando, assim, gráficos

estacionários ou com pouca animação. Esse tipo de jogo se caracteriza pela

exigência de raciocínio lógico e pode ser classificado, também, como uma história

interativa. Como exemplo encontram-se os títulos: Amazônia (do brasileiro Renato

Degiovanni), Full Throttle da Lucas Arts, as incansáveis séries Space Quest e King’s

Quest da Sierra, dentre outros.

1.6. Infantis

Jogos infantis se caracterizam por sua interface simples e seu caráter

educacional voltado essencialmente para as crianças. Este tipo de jogo pode

apresentar características de quaisquer dos jogos acima citados.

2.2. Classificação Visual

A interface de um jogo está relacionada ao seu aspecto visual e interativo. Ela

representa o meio pelo qual o usuário incorpora o ambiente do jogo e possui grande

interferência no desenvolvimento de seu motor gráfico.

 29

De acordo com o contexto narrativo do jogo, bem como o seu processo de

interação, apenas dois tipos de visualização podem ser definidos. São eles:

1.7. 1ª Pessoa

Apresenta uma interface responsável por incorporar o usuário/jogador na “pele”

do personagem. O jogador tem a mesma visão do personagem do jogo, o que cria

uma grande sensação de imersão.

Jogos em primeira pessoa requerem interfaces 3D em função da sua própria

característica visual, ou seja, a tela é o olho do jogador, como demonstrado na

[Figura 1].

Figura 1: Imagem do jogo Quake II

1.8. 3ª Pessoa (God View ou God’s eyes)

Jogos em 3a. Pessoa apresentam uma interface em que o jogador consegue

visualizar a si mesmo, seja ele apenas um personagem do jogo, tal como em Tomb

Raider, ou um exército, tal como em Emperor, Battle for Dune. Esse tipo de

visualização é denominado de “God View” pois o usuário tem uma visão completa do

mundo e do(s) objeto(s) que cercam o(s) personagem(s).

A visualização em 3a. Pessoa se subdivide em duas outras, sendo:

 30

- Visualização Perspectiva: A visualização em perspectiva assemelha-se

muito à visualização em 1a. Pessoa, porém, apesar da câmera ser posicionada

atrás do personagem, permitindo que o jogador tenha um campo de visão mais

abrangente, apresenta todas as características da visualização em 1a. Pessoa,

tal como a sensação de profundidade, devido à convergência de retas paralelas,

possibilitando maior imersão. Dentre os jogos nessa categoria encontram-se os

jogos da série Tomb Raider [Figura 2], da Eidos Interactive, que foram muito

bem aceito devido a esse tipo de visualização;

Figura 2: Imagem do jogo Tomb Raider

- Visualização Axonométrica: Diversos jogos 2D utilizaram a técnica da

visualização por projeção axonométrica através do uso de Sprites (9.1) com

diferentes posicionamentos, permitindo a percepção tridimensional, porém, sem

apresentar a noção de profundidade, pois mantêm o paralelismo entre retas

paralelas. Atualmente jogos 3D com esse tipo de visualização consistem em

definir uma câmera posicionada para gerá-la. Dentre os jogos nessa categoria

encontram-se os jogos de estratégia em tempo real mais recentes, tais como

 31

Emperor, Battle for Dune [Figura 3], da Westwood e Star Trek Armada, da

Interplay.

Figura 3: Imagem do jogo Emperor, Battle for Dune

2.3. Classificação por Ambientação

Uma das partes fundamentais na definição das funcionalidades do motor de um

jogo é o seu ambiente, pois ele caracteriza objetos, formas de iluminação, limites de

movimentação, etc. Apesar de diversas características de um jogo serem

imprevisíveis, alguns modelos básicos de ambientação podem ser definidos. A

combinação de funcionalidades genéricas de ambientação com outras dos motores

de jogo cria uma gama maior de funcionalidades úteis para o desenvolvimento do

ambiente de jogo. Os ambientes básicos se resumem a:

1.9. Ambientes Internos

São ambientes fechados, normalmente conhecido como dungeons ou

masmorras, muito popular entre jogos de 1a. pessoa como o Quake [Figura 1] ou o

Doom, da ID Entertainment, onde a iluminação é nitidamente artificial, pois provêm

 32

de fontes de luz como tochas ou spotlights. Geralmente a iluminação é estática,

porém há a possibilidade de iluminação dinâmica. O ambiente é constituído de salas

e suas interconexões, tais como, corredores e portas, de forma similar à planta de

uma casa.

1.10. Ambientes Externos

São ambientes abertos criados a partir de geradores de terreno ou por um mapa

de altitude, denominado Voxel (9.1), geralmente com iluminação ambiente e a

possibilidade de contar com outras fontes de luz. Os ambientes externos,

geralmente, simulam o céu por meio de uma caixa ou domo texturizado denominado

de SkyBox16. Esse tipo de ambientação é muito utilizado em jogos de simulação

(2.1), principalmente aqueles que operam com aviões ou automóveis, tal como o F1

World Grand Prix [Figura 4] da Eidos Interactive.

Figura 4: Imagem do jogo F1 World Grand Prix

1.11. Espaço Sideral

São ambientes que simulam o espaço sideral renderizando estrelas, planetas,

nebulosas e outros objetos espaciais. Geralmente possuem iluminação variável de

16
SkyBox: Forma geométrica, geralmente um domo ou uma caixa, com textura de céu que contêm todo o
ambiente do jogo.
 33

acordo com as fontes de iluminações (sois) disponíveis no sistema sideral em que o

personagem se encontra. Exemplos de jogos que se caracterizam por essa

ambientação são Privateer I e II [Figura 5] da Origin Systems.

Figura 5: Imagem do jogo Privateer II

1.12. Ambientes Mistos

Ambientes mistos podem ser compostos por dois ou pelos três tipos de

ambientes apresentados de maneira a criar uma aplicação mais atrativa ao

consumidor, porém, a estrutura do sistema da aplicação deve ser capaz de gerenciar

os métodos necessários para processar os diferentes tipos de informação inerentes

a cada tipo de dado representativo da ambientação.

 34

2.4. A Estrutura de um Jogo

Jogos de computador são constituídos por três extensos componentes, sendo

eles:

a) O enredo, responsável pelo tema, trama e objetivos do jogo, fatores que não

envolvem apenas pesquisa e criatividade, mas também uma interação com

psicólogos, roteiristas e especialistas no assunto [2];

b) Uma interface interativa, responsável pela comunicação entre o motor e o

usuário, desenvolvida a partir de conceitos técnicos e cognitivos onde o valor

artístico da interface tem por finalidade valorizar a apresentação do jogo, de

forma a criar um ambiente atraente ao usuário e aumentar a sua satisfação

ao jogar, e;

c) Um motor (biblioteca de produção), responsável por controlar o jogo e os

estados de seus personagens de acordo com a ação do usuário ou a

interação entre os personagens, analisados no(8).

De acordo com Battaiola [2], o sucesso de um jogo está associado à combinação

perfeita destes componentes.

Dentre os três componentes analisaremos mais especificamente o motor de um

jogo (8), o qual diz respeito à contextualização do trabalho aqui desenvolvido.

 35

Capítulo 3. - Jogos como Aplicações Multimídia

Sistemas multimídia integram uma grande variedade de mídias com diferentes

características temporais, como, por exemplo, as mídias dependentes do tempo, tais

como, vídeo, áudio ou animação e as mídias que não são dependentes do tempo,

como textos, gráficos ou imagens [6].

Inicialmente jogos por computador apresentavam apenas animações

rudimentares; ruídos sonoros e textos. A evolução dos processadores permitiu que

fosse adicionada complexidade aos jogos. Os processadores gráficos permitiram

que, aos poucos, imagens fossem inseridas no contexto do jogo gerando, portanto,

aplicações mais interessantes. As placas de som permitiram que sons primorosos

fossem adicionados, aumentando o trabalho dos produtores de jogos devido à

exigência de músicas e efeitos sonoros bem elaborados, incrementando a qualidade

inerente do produto, adicionando mais temperamento ao enredo e fixando a atenção

do jogador cada vez mais.

Neste contexto, os modernos jogos por computador apresentam, pelo menos,

cinco dos componentes de sistemas multimídia citados acima, a saber, vídeo, áudio,

imagens estacionárias, texto e animação, sendo que alguns ainda apresentam

gráficos analíticos para indicar o rendimento do jogador perante o computador ou

perante outros jogadores.

Além disso, uma das características fundamentais dos jogos por computador é a

integração e sincronização das mídias de acordo com a temporização do sistema e

também de acordo com a interação do usuário.

 36

Conclui-se, portanto, que jogos por computador são sistemas que exploram de

maneira intensiva o conceito de multimídia, utilizando todos os recursos oferecidos

pelo computador de maneira a entreter o usuário.

Por ser um sistema que faz uso intensivo das diversas mídias oferecidas pelo

computador, jogos por computador exigem uma série de requisitos para operarem a

contento.

Abaixo se detalha os requisitos que um jogo deve ter, bem como suas

respectivas funções dentro do contexto do jogo. Gráficos e animações, por fazerem

parte do projeto desenvolvido, serão analisados em capítulos separados.

3.1. Vídeo

Vídeo é um elemento muito usado em jogos por computador. No entanto, muitas

vezes, os desenvolvedores de jogos não sabem como utilizá-lo adequadamente.

Observe que quando bem usado, o vídeo pode aumentar o prazer e a compreensão

da trama do jogo, reforçar uma narrativa, introduzir um personagem, etc. Quando

mal usado, ele pode “matar” o jogo [7].

Os vídeos imersos em ambientes interativos foram denominados inicialmente de

vídeos interativos. Atualmente, a nomenclatura adotada é FMV (Full-Motion Video),

significando vídeo com movimentação total.

A história de uso de vídeos em jogos começa em 1983 com Dragon’s Lair, o

primeiro a usar vídeo analógico mesclado com objetos de jogo. Sherlock Holmes:

Consulting Detective, liberado em 1992, foi o primeiro a usar vídeo digital. O primeiro

jogo com vídeo de sucesso foi The 7th Guest, da Trilobyte, liberado em 1993. O mais

popular de todos foi Myst, da Cyan, jogo liberado para PC em 1994 e que contribuiu
 37

para expandir significativamente o mercado de entretenimento interativo e de drivers

para CD. Myst utilizou adequadamente o vídeo através de pequenas inserções que

se casam com o contexto geral do ambiente do jogo. Na seqüência, vieram os bons

jogos Phantasmagoria, 1996, e Wing Commander III.

Uma regra importante para a utilização de vídeos em jogos é o da naturalidade

da transição, ou seja, a mudança de vídeo para a animação gráfica e vice-versa

deve estar totalmente de acordo com o contexto do jogo, possibilitando que, em

alguns casos, o usuário nem a perceba. O uso de um vídeo longo e maçante no

começo do jogo, ou então, de vídeos curtos e desconexos da trama no começo de

cada nível não é um procedimento que vai ao encontro desta regra.

Os cuidados que devem ser tomados com a inserção de vídeos em jogos são:

- Vídeo entrelaçado: O vídeo é entrelaçado, ou seja, a imagem é dividida

em duas partes, um conjunto de linhas horizontais pares e ímpares (1, 2, 3,

4, ...). As linhas pares são capturadas 1/60 de segundo depois das linhas

ímpares. Quando os objetos filmados se movimentam muito rapidamente,

durante a exibição do vídeo no computador, surgem borrões com padrões que

evoluem em escada e ocasionam um efeito visual muito ruim. A maioria dos

programas de edição digital de vídeo permite o desentrelaçamento do vídeo.

- Taxa de exibição de quadros errada: Vídeos normalmente têm taxa de

30 fps (quadros por segundo) e filmes de 24 fps. Estas taxas têm de ser

compatibilizadas para evitar problemas de sincronização nas cenas. Programas

como o Media Cleaner Pro 4 da Terran Interactive tratam deste tipo de

conversão.
 38

- Manchas nas bordas: Quase sempre é possível se encontrar manchas

nas bordas de vídeos analógicos que não são vistos em um monitor de TV, mas

sim no de um computador. Estas manchas tem de ser cortadas das bordas.

- Atores ruins: A escolha dos atores deve ser feita com cuidado, pois há

um ditado entre os diretores de produção de vídeo de que um bom ator não

repete a sua boa performance em um grande palco com platéia na frente da

objetiva de uma câmera.

- Diálogos ruins e pobres: Usualmente o diálogo é mais difícil de ser

finalizado do que a encenação. Isto porque sons são uma constante em jogos e

normalmente se considera sua produção mais simples do que a do vídeo, o que

nem sempre é verdadeiro. Além do esmero técnico, é necessário que os atores

responsáveis pela dublagem tenham experiência e aptidão para a tarefa.

Adicionalmente, é preciso que os técnicos de som tenham a qualificação

requerida para a produção de um som limpo e claro.

- Áudio de 8-bit: O recomendável é nunca se usar áudio de 8 bit. Os

modernos compactadores de som (codecs) geram arquivos maiores e de menor

qualidade sonora para o áudio de 8-bit do que para o de 16-bit.

- Combinação inadequada do vídeo com o fundo renderizado : Deve

haver um casamento perfeito entre os elementos de ação no vídeo (ator, armas,

motos, etc) recortados pela técnica do cromaqui, descrita a seguir, e o fundo

renderizado do jogo. O ideal é o produtor do cromaqui ter uma idéia do fundo do

jogo em termos de cores, luzes, materiais, etc, para poder planejar as tomadas e

possibilitar este casamento.

 39

- Requisitos técnicos do vídeo diferentes dos de todo o jogo : Os jogos

são planejados para serem jogados em um computador com uma configuração

mínima. Se a qualidade do vídeo exigir uma configuração mais sofisticada,

detalhes sofisticados de cenas, ou até o todo, poderão não ser vistos.

O cromaqui é uma técnica que consiste em filmar uma cena em que o cenário de

fundo é totalmente pintado de verde ou azul, o qual depois será removido e

substituído por uma imagem, animação gráfica ou outro vídeo. Tradicionalmente, a

técnica utilizava equipamentos ópticos especiais para a eliminação do fundo.

Atualmente, placas gráficas permitem a captura do vídeo por um computador e a

sua edição através de programas específicos que possibilitam também a realização

do cromaqui.

Apesar da tecnologia de compactação de vídeos e da tecnologia de

armazenamento indicarem melhoras na produção e armazém de vídeos digitais o

uso de vídeos em jogos está fadado a ser extinto em um futuro próximo devido aos

seguintes fatores:

- A qualidade atual dos softwares de modelagem e dos modeladores

favorece a criação de modelos perfeitos, muito próximos do real;

- O avanço na tecnologia de unidades de processamento gráfico,

principalmente no que diz respeito a processamento de gráficos 3D, permite que

gráficos 3D de qualidade sejam renderizados em tempo real, como, por

exemplo, no jogo Warcraft III, da Blizzard Entertainment e

- O baixo custo da produção das animações geradas em relação à

produção de vídeos, principalmente no que diz respeito a atores, figurinos,

cenários, assistentes de filmagem, etc.

 40

3.2. Áudio

A função básica do áudio em um jogo é, assim como a do vídeo, atrair a atenção

do usuário. Porém, enquanto vídeos são artifícios apenas de contextualização do

jogo, áudio é fundamental para adicionar temperamento aos jogos.

Essa adição se intensifica se considerarmos os avanços tecnológicos na área de

áudio devido à tecnologia de áudio ambiental ou 3D, o que faz com que o jogador

tenha noção da proveniência do som.

Atualmente existe uma gama de formatos de arquivos de representação de áudio

disponíveis para adicionar às capacidades de um motor de jogo. Dentre os diversos

formatos de arquivos de áudio cinco deles merecem destaque. São eles:

- WAV: O Microsoft Windows Riff Wave popularizou-se em função do

grande número de plataformas com o Microsoft Windows e seus aplicativos. O

Wav é atualmente a base do áudio digital, sendo largamente utilizado em efeitos

sonoros. Existem vários tipos de ferramentas que manipulam este formato,

permitindo a geração dos mais variados tipos de efeitos, bem como a utilização

das mais variadas taxas de amostragem. Dependendo da qualidade utilizada

para um arquivo Wav, ele pode requerer uma taxa de transmissão de 40 Mbytes

por minuto, o que o torna muito pesado para operar em computadores de

pequeno porte. Em função da sua grande difusão, todos os outros formatos

possuem conversores para Wav.

- MIDI: A interface MIDI (Musical Instrument Digital Interface) [8] define uma

linguagem de transmissão de dados digital entre sistemas computacionais,

sintetizadores e instrumentos musicais. A comunicação pode ser feita com base

no protocolo ou em arquivos MIDI. Por exemplo, quando uma nota é tocada em

 41

um teclado, a porta de comunicação MIDI envia para um sintetizador, ou

computador, conectado a ela, um evento contendo todas as informações

pertinentes, tais como a nota, a sua velocidade, instrumento, etc. O MIDI não é

áudio digital, portanto não há a possibilidade de se gravar vozes ou efeitos

sonoros, ele somente mantém a seqüência de notas tocadas e as armazena

como um tipo de som pré-definido, sendo eles variados, como guitarra, teclado,

gaita, etc. Isto acentua a flexibilidade deste tipo de som, pois permite que todas

as suas características possam ser mudadas facilmente de forma manual

(direta) ou via programa. A característica mais interessante do MIDI é o pouco

espaço em disco que ele ocupa, por exemplo, um minuto de som com só uma

trilha e sem nenhum evento a ele ligado requer 3Kb, o que, comparado com o

formato Wav e muitos outros, é extremamente pequeno. Por trabalhar com

eventos o formato MIDI se torna viável para a produção de áudio interativo, o

que adiciona mais temperamento a um jogo. Atualmente sintetizadores MIDI já

vêm embutidos nas placas de som mais comuns e apresentam uma qualidade

de boa a ótima, o que favorece a utilização desse tipo de arquivo em jogos.

- MP3: O formato MP3, Moving Pictures Experts Group Audio Layer 3

compressed audio, objetiva armazenar som compactado. A sua definição é

baseada em um modelo psico-acústico, ou seja, o ouvido humano não é capaz

de ouvir todas as freqüências, há um limite entre 20Hz e 20KHz e ele é mais

sensitivo entre 2KHz e 4 KHz. Assim, um algoritmo elimina grande parte das

freqüências que um ouvido humano possa não escutar e ainda algumas que

possam ser retiradas sem que haja perda na qualidade sonora. Ressalte-se que

esta compactação é destrutiva, ou seja, a compactação do MP3 elimina

 42

informações que nunca mais poderão ser recuperadas. A maioria dos rippers,

dos codificadores e dos decodificadores trabalha com qualidade igual ao CD e

12 vezes menor que um arquivo igual no formato Wav.

- MP4: Utiliza o mesmo conceito do MP3, porém apresenta melhor

algoritmo de compactação, o que tem aumentado o interesse por ele. O MP3

compacta a uma razão de 11:1 enquanto o MP4 a 16:1. O ganho de 30% advém

de otimizações realizadas no algoritmo.

- RA: O formato Real Audio foi desenvolvido para uso na Internet. Ele

permite que o som possa ser ouvido com boa qualidade, diretamente pela rede,

em tempo real, sem a necessidade de download.

3.3. Dispositivos de Entrada

Por se tratar de um software interativo é imprescindível que jogos por

computador necessitem de uma interface de comunicação com o usuário para a

entrada de dados representando os eventos que o jogador deseja realizar.

Apesar de que, para computadores, o teclado e o mouse possam suprir todas as

necessidades exigidas pelos jogos desenvolvidos até hoje, muitos jogos,

principalmente os de simulação, se tornam mais atrativos com dispositivos de

entrada específicos.

Alguns desses dispositivos possuem, inclusive, funcionalidades de Force

Feedback, que provê ao jogador uma resposta tátil, por exemplo, sendo o dispositivo

de entrada um manche ou joystick (de avião), o avião do jogador, ao ser atingido faz

o manche tremer.
 43

Abaixo estão alguns dispositivos cuja entrada pode ser passível de uso em um

motor de jogo:

1.13. Teclado

É o dispositivo mais primordial para um jogo por computador, porém sua grande

quantidade de teclas oferece um conjunto bastante amplo de comandos a serem

implementados nos jogos;

1.14. Joystick

Após o teclado, o joystick é o segundo dispositivo mais utilizado pelos jogadores.

Ele consiste de uma haste móvel que indica a direção desejada pelo jogador e um

ou mais botões. O joystick pode ou não ter a funcionalidade de force feedback, no

entanto, a maioria dos dispositivos atuais apresentam essa opção.

1.15. Game Pad

Introduzido pela Nintendo Entertainment, o game pad possui o mesmo princípio

de operação que o joystick, porém no lugar da haste móvel encontra-se um

direcionador onde o jogador, com o seu polegar, indica a direção desejada. O game

pad possui dois ou mais botões e também tem a possibilidade de possuir force

feedback, porém, nesse caso, todo o dispositivo vibra;

1.16. Manche

Manches são dispositivos de entrada projetados especificamente para

simuladores de avião. Ele possui um princípio de operação ligeiramente diferente

dos joysticks e game pads, pois o manche pode ter a possibilidade de permitir mais
 44

graus de movimentação que os dois últimos dispositivos citados e, assim como eles,

podem ou não possibilitar force feedback;

1.17. Sistema automobilístico

Como o próprio nome cita, é um sistema que consiste em uma direção e um ou

dois pedais de maneira a servir de dispositivo de entrada para simuladores

automobilísticos. Como analogia, os pedais seriam equivalentes à movimentação da

haste do joystick para frente ou para trás e a direção seria equivalente a mover a

haste para a esquerda ou direita. Assim como os outros dispositivos esse sistema

pode ou não ter a opção de force feedback;

1.18. TrackBall

Durante muitos anos o campo de realidade virtual utilizou esse dispositivo como

modo de comunicação com sistemas virtuais. Apesar de ter sido desenvolvido

especificamente para a área de realidade virtual, o trackball pode ser utilizado para a

comunicação com um ambiente de jogo por computador de maneira eficiente. Uma

possível utilização seria para jogos de ação em primeira pessoa, como Quake ou

Descent.

1.19. Mouse

Esse dispositivo, projetado inicialmente sem previsão de aplicabilidade, tornou-se

essencial para os sistemas operacionais atuais devido ao seu modo de operação. A

indústria de jogos, aproveitando das capacidades de referências diretas às

coordenadas de tela, absorveu a idéia e projetou jogos cuja jogabilidade se torna

ruim se esse dispositivo não for utilizado como dispositivo de entrada. Tal é o caso
 45

dos jogos de estratégia em tempo real, como Warcraft ou Command&Conquer-Red

Alert que requerem esse dispositivo para uma boa jogabilidade.

1.20. Reconhecimento de Voz

Apesar de ainda não ser aplicável, o reconhecimento por voz consiste em um

interessante método de interface com aplicações e, conseqüentemente, com jogos.

A viabilização desse método de entrada de informações poderá causar uma

revolução no mercado tanto de jogos quanto de aplicações em geral.

 46

Capítulo 4. - Gráficos

Os gráficos surgiram para contextualizar visualmente o cenário dos jogos.

Antigamente jogos por computador, ou adventures, como eram denominados,

apresentavam uma interface puramente textual, com interação através da digitação

de comandos verbais e exibição de respostas baseadas na lógica do jogo.

O primeiro jogo conhecido que apresentou gráficos foi desenvolvido no MIT em

1962. Denominado de SpaceWar ele apresentava gráficos grotescos e uma

simulação física simples, porém ficou marcado, não somente por ser considerado o

primeiro jogo, mas também por ser o precursor de gráficos em jogos, porém, por ter

sido implementado em um computador acadêmico (DEC-PDP1) ele não pode ser

considerado como um produto de consumo.

Apesar de jogos não exigirem, necessariamente, gráficos, como no caso dos

antigos adventures, o mercado consumidor desse tipo de aplicação tem sido cada

vez mais exigente quanto a essa característica.

Essa exigência diz respeito tanto às questões de entretenimento, como efeitos

especiais, animações baseadas em cartoon, quanto às questões visuais

propriamente ditas, como o foto-realismo.

Um jogo, quanto aos gráficos, pode ser classificado em três tipos: a) 2D; b) 3D e

c) misto.

Jogos 2D, atualmente, utilizam apenas imagens 2D, desenhadas por um artista e

combinadas para formar a aplicação, enquanto que em jogos 3D as imagens são

geradas pelo computador a partir de dados de modelos criados por artistas em

programas de modelagem, como o Blender 3D [9].

 47

Jogos mistos apresentam tanto gráficos 3D quanto gráficos 2D, como o caso do

Escape from Monkey Island, da Lucas Arts, que apresenta personagens 3D

integrados em um cenário formado por um conjunto de imagens bidimensionais

organizadas em camadas.

Enquanto jogos 2D necessitam apenas de procedimentos para posicionar e

desenhar as imagens, jogos 3D ou mistos necessitam de um conjunto de

procedimentos para gerar as imagens a partir de dados descritivos dos objetos. A

esse conjunto de procedimentos foi atribuído o nome de Renderizador:

4.1. Renderizador

Um dos principais objetivos da computação gráfica é sintetizar imagens realistas

de ambientes virtuais tridimensionais, isto é, ambientes representados como

modelos formais na memória do computador [10].

Ultimamente esse objetivo tem se mostrado cada vez mais próximo de sua

conclusão, principalmente devido aos diversos avanços tanto em software,

produzindo algoritmos cada vez mais eficazes e eficientes, quanto em hardware,

produzindo aceleradores gráficos cada vez mais velozes.

O processo de síntese de uma imagem de um ambiente virtual tridimensional é

chamado de renderização. Esse processo é realizado por sistemas denominados de

sistemas de renderização que realizam cálculos matemáticos de projeção e

visualização através de informações de geometria, textura, iluminação e visão.

No contexto de um jogo 3D sistemas de renderização são fundamentais,

principalmente por ter que renderizar as cenas muito rapidamente. Esse tipo de
 48

sistema de renderização é denominado por sistema de renderização em tempo real

devido à rapidez de processamento das informações.

Apesar das teorias matemáticas, científicas e computacionais estarem bem

definidas para sistemas de renderização em tempo real, a aplicabilidade das

mesmas, até pouco tempo atrás, só era viável em estações gráficas dedicadas ou

com otimizações por software. Felizmente, o avanço na área de hardware viabilizou

a aplicação da maioria das teorias, proporcionando a criação de aplicações para as

mais diversas áreas. Porém os sistemas de renderização em tempo real dessas

aplicações eram sistemas dedicados ou, no caso dos motores de jogos, sistemas

fechados, pouco modulares e caros.

Um sistema de renderização em tempo real é a área mais interativa da

computação gráfica. O usuário age ou reage de acordo com a imagem exibida e

essa retro-alimentação afeta o que será gerado em seguida. Este ciclo de reação e

renderização acontece em uma taxa rápida o suficiente que o usuário não percebe

imagens em uma taxa discreta, mas que, ao contrário, ele se torne imerso em um

processo contínuo [11].

O processo de renderização consiste em um conjunto bem definido de regras

matemáticas de projeção e iluminação que tem por objetivo gerar uma imagem

bidimensional através do cálculo de projeção de uma câmera virtual que visualiza

objetos tridimensionais com uma determinada textura, a qual pode sofrer

modificações na coloração e na luminância de acordo com fontes de luz definidas no

ambiente. A imagem gerada depende de como o sistema calcula a intensidade da

refletância da luz provinda das fontes de luz e dos outros objetos. Tal cálculo é

denominado modelo de iluminação.

 49

O processo de renderização, também denominado de pipeline de renderização

consiste de diversos estágios [12] e definem restrições cujos dados não podem ser

enviados para o estágio seguinte caso o estágio atual não esteja finalizado.

O estágio mais demorado do pipeline é o responsável por determinar a

velocidade de renderização [11]. Essa velocidade pode ser expressa em quadros por

segundo (FPS), que é o número de imagens geradas por segundo, ou em hertz

(HZ). Dessa forma pode-se realizar processos de otimização através da execução

de estágios de pipeline em paralelo. Se o gargalo, isto é, o estágio mais lento do

pipeline, for conhecido e o tempo que leva para que o dado seja processado por ele

puder ser definido, pode-se computar a velocidade de renderização permitindo que

modificações sejam realizadas em outros estágios do pipeline de tal forma que se

reduza o tempo total do processo. Assuma, por exemplo, que o gargalo leve 20ms

(milisegundos) para executar, assim, a velocidade de renderização seria de

1/0.20=50Hz. Contudo, isso apenas é verdadeiro caso o dispositivo de saída for

capaz de atualizar a tela nessa velocidade. Caso contrário, a taxa real de saída será

mais baixa.

A Figura 6 demonstra os passos de execução do processo de renderização em

um sistema gráfico.

Aplicação Geometria Rasterizador

Figura 6: A Construção básica do pipeline de renderização

 50

1.21. Estágio de Aplicação

Este estágio é dirigido pela aplicação e, portanto, é implementado totalmente por

software. Seus objetivos consistem, por exemplo, em realizar verificações de

detecção de colisão, técnicas de otimização, animações, etc.

O desenvolvedor tem total controle sobre o que acontece nesse estágio, pois ele

é executado por software, possibilitando mudar a implementação de maneira a

alterar a performance. Nos outros estágios é difícil mudar a implementação porque

várias partes do processo estão embutidas tanto em hardware ou software, através

de bibliotecas desenvolvidas por terceiros.

Ao terminar a execução esse estágio alimenta o estágio seguinte com a

descrição do mundo e com a geometria e propriedade dos objetos contidos nele.

Tais dados são fundamentais para o sistema e essa é a tarefa mais importante

realizada pelo estágio de aplicação.

Dois processos muito comuns implementados nesse estágio são o de detecção

de colisão que gera uma resposta ao sistema caso dois objetos colidam e o de

restrição (culling), que identifica quais polígonos ou objetos gráficos estão dentro do

volume de visão determinado por uma câmera de maneira a impedir que os dados

descritivos de geometria dos que não estão visíveis sejam enviados ao estágio

seguinte aumentando, portanto, a performance do sistema. Outros processos

importantes para otimização, tais como representação de dados, processamento de

visibilidade (5.2) e LOD (5.2), também são implementados nesse estágio.

No contexto desse projeto, o estágio de aplicação consiste nos módulos de

animação e renderização, responsáveis por definir a estrutura de dados da

geometria dos objetos, a estrutura hierárquica dos objetos de jogo e realizar os

 51

cálculos de detecção de colisão e operações matemáticas ou físicas nos objetos ou

vértices dos objetos de acordo com algoritmos específicos da teoria de animação.

1.22. Estágio de Geometria

Esse estágio é o responsável por realizar as operações matemáticas referentes

aos gráficos 3D.

Pode se considerar que esse estágio se subdivide em cinco estágios funcionais

que podem ou não ser equivalentes a estágios de um pipeline. Em alguns casos um

certo número de estágios funcionais forma um único estágio de pipeline (que

executa em paralelo com outros estágios de pipeline). Em outros casos um estágio

funcional pode ser subdividido em diversos estágios de pipeline menores.

A Figura 7 demonstra a subdivisão do estágio de geometria em um pipeline

contendo cinco estágios funcionais.

Transformação Iluminação e Projeção Recorte Mapeamento de

de modelo e Sombreamento tela
visão

Figura 7: O estágio de geometria dividido em um pipeline de estágios funcionais

O primeiro estágio do pipeline é o responsável por posicionar os objetos no

mundo através das transformações de escala, translado e rotação e por realizar as

transformações sobre posicionamento da câmera através da modificação da matriz

de modelo/visão do sistema, permitindo realizar operações como remoção de

polígonos que não estejam contidos no volume de visão definido pela câmera e
 52

calculado pelo modelo de projeção enviando, ao próximo estágio, apenas os objetos

e os atributos que estão contidos entre os planos de recorte.

Com o intuito de se criar imagens mais realistas dos modelos pode-se adicionar

à cena uma ou mais fontes de luz. Os objetos podem apresentar cores associadas a

cada vértice, ou então podem ter uma textura aplicada a ele. Dessa maneira a

iluminação afeta as cores, seja dos vértices ou da textura, criando um realismo

maior. A Figura 8 demonstra o efeito da iluminação na cena. Observe como, em uma

cena sem iluminação, uma textura em um objeto oferece uma idéia de sua

tridimensionalidade, porém objetos com cores sólidas não apresentam profundidade,

parecendo ser figuras achatadas (2D).

Figura 8: Como a iluminação afeta a percepção da imagem

Apesar de estarem diretamente relacionadas com o pipeline de renderização, por

definir como os objetos serão visualmente definidos, as operações de iluminação

são executadas no segundo estágio do pipeline de geometria por necessitarem de

dados referentes à mesma, tais como as normais das faces dos polígonos que

definem os objetos.

Nesse estágio também são considerados os atributos visuais dos objetos, tais

como os atributos de material, como cor de reflexão ambiente, difusa e especular,

nível de reflexão especular e emissão de luz e nível de emissão.

 53

Após realizar as operações de iluminação, o processo de geometria envia os

dados ao terceiro estágio, responsável por realizar as projeções, isto é, os cálculos

necessários para transformar o volume de visão em um cubo denominado de

volume canônico de visão, cujos pontos extremos estão entre as coordenadas 1 e –

1. Há basicamente dois tipos de projeção planares: a projeção paralela e a projeção

em perspectiva [13]. A diferença entre os dois tipos de projeção é que na projeção em

perspectiva o sistema de coordenadas utilizado é um sistema não cartesiano,

proporcionando o não paralelismo entre retas paralelas, fazendo com que retas

paralelas se cruzem em um ponto no infinito, denominado de ponto de fuga, na

imagem projetada, assim como mostra a Figura 9, enquanto que a projeção

ortográfica mantêm o paralelismo entre as retas e as reais dimensões dos dados do

objeto.

PROJ. PLAN. ORTOG. PROJEÇÃO PERS PECTIVA

AXONOMÉTRICAS
Com 2 Pontos de Fuga
ISOMÉTRICAS
y
y’

x’
x

PF - 1 PF -2
z

Figura 9: Diferenças na projeção paralela e em perspectiva.

Os dados transformados são enviados para o quarto estágio, responsável pelo

processo de recorte, o qual decide quais objetos estão totalmente ou parcialmente

dentro do volume de visão. Dados dos objetos que estão totalmente dentro do

volume são passados sem alteração para o próximo estágio. Os objetos

parcialmente dentro do volume de visualização sofrem uma transformação para que

 54

seja possível realizar o preenchimento de polígonos ou a aplicação de texturas nos

polígonos que formam o mesmo e, só então, passam para o próximo passo do

estágio de geometria.

Observe que o processo de recorte no estágio de geometria diz respeito aos

objetos que estão dentro ou parcialmente dentro do volume de visão definidos pela

câmera. As estruturas geométricas enviadas para o segundo estágio do pipeline de

renderização possuem os dados completos, sem alteração, dos objetos a serem

processados. A operação de recorte, nesse estágio, diz respeito à alteração da

estrutura geométrica poligonal dos objetos de maneira a modifica-las corretamente

para que o processo de renderização realize de maneira adequada as operações

para processamento de produção dos fragmentos e de cor dos fragmentos, dados

representando pixels e que não foram processados pelo z-buffer.

Os objetos que estão, portanto, dentro do volume de visualização sofrem uma

transformação nas coordenadas de seus vértices de tal forma que as coordenadas

x, y e z de cada primitiva formem as coordenadas de visualização. Essas

coordenadas, denominadas de coordenadas canônicas [11], são mapeadas para

coordenadas de janela, através de uma equação de interpolação por meio de uma

transformação de escala.

1.23. Estágio de Rasterização

Após passar pelo estágio de geometria os dados, com suas coordenadas

transformadas, iluminação calculada e textura aplicada, os dados são enviados para

o terceiro estágio do pipeline de renderização, denominado de estágio de

rasterização, responsável por atribuir as cores corretas aos pixels para que a
 55

imagem seja renderizada adequadamente. O processo de rasterização converte os

vértices bidimensionais no espaço da tela, obtidos através do estágio de geometria,

em pixels na tela do computador através do cálculo da textura associada a cada

vértice, da cor da posição e da luminância do pixel de acordo com o valor da

coordenada Z daquele pixel, obtida através de um buffer de profundidade.

Ao contrário do estágio de geometria, que realiza operações entre polígonos, o

estágio de rasterização realiza operações em pixel e entre pixels, onde a informação

de cada pixel está localizada em um buffer de cores (uma matriz linha de cores com

dados representando os pigmentos: verde, vermelho e azul). Para gráficos de alta

performance é ideal que o processo de rasterização esteja implementado em

hardware dado a complexidade das operações. Akeley e Jermoluk [14] e Rogers [15]

oferecem mais informações sobre a rasterização.

De maneira a evitar que os visualizadores humanos percebam as primitivas

serem desenhadas é utilizado um processo chamado de double buffering, onde a

imagem é desenhada em uma área de memória e, quando finalizada, a memória de

vídeo referencia essa área de memória trocando, assim, a área de memória a ser

desenhada.

Este estágio também é responsável por calcular a visibilidade dos objetos de

acordo com sua profundidade. Isso significa que quando toda a cena tiver sido

renderizada o buffer de cores contenha as cores definidas de acordo com as

primitivas da cena que são visíveis do ponto de vista da câmera. Isso é realizado

através de processamento de visibilidade, na camada de aplicação, e do algoritmo

de Z-Buffer (também conhecido como buffer de profundidade) [16]. Caso não haja um
 56

buffer de profundidade técnicas tradicionais de eliminação de superfícies ocultas são

utilizadas ao preço de maior processamento.

1.24. Performance em Sistemas de Renderização

Maximizar a taxa de quadros por segundo e a qualidade da imagem se torna um

problema quando se deseja fazer o melhor uso de cada estágio disponível e,

concomitantemente, evitar os gargalos [17].

De maneira a aumentar a performance do sistema algumas técnicas devem ser

adotadas:

a) Redução da Complexidade Geométrica: A medida usual para a

complexidade da cena é o número de primitivas geométricas que a compõe.

Como os hardware atuais impõe um certo limite para o número de primitivas

permitidas, qualquer redução da complexidade geométrica é desejável [17]. O

interesse principal é diminuir o número de primitivas geométricas de um

objeto sem que o objeto final não sofra uma modificação perceptiva para a

visão humana. Isso é possível de ser realizado devido à acuidade da visão,

que denota o grau de percepção das características de um objeto ou imagem.

Essa percepção é medida de acordo com o ângulo medido entre as

características do objeto em relação ao olho. Em uma medida axial, esse

ângulo é em torno de 1 arco-minuto, ou seja, se o ângulo formado entre uma

e outra característica do objeto geométrico for menor do que um arco-minuto,

o usuário não perceberá a mudança e operações serão desperdiçadas no

processamento desse objeto. Se a simplificação não puder ser realizada

normalmente, há uma negociação entre a fidelidade da imagem e a taxa de

 57

quadros por segundo desejada. Os métodos mais importantes de redução de

complexidade geométrica são processamento de visibilidade e cálculo para

nível de detalhe, analisados no (5) e

b) Otimização dos Processos do Pipeline: Antes de se reduzir a carga de

dados do sistema de processamento, faz-se necessário garantir a eficiência

das capacidades disponíveis no sistema. Isso envolve, geralmente, otimizar a

estrutura dos dados geométricos de maneira que eles possam representar o

mesmo objeto com menos informação. Isso normalmente é realizado pelo uso

de malhas triangulares ao invés de triângulos em separado, o que reduz em

muito o número de vértices, ou seja, de dados a serem armazenados ou

carregados na memória do computador [18]. Processar animações de objetos

que não sofram com a interação do jogador também é um ponto importante

na otimização da renderização. Ao invés de se processar as transformações

em tempo real, realiza-se um pré-processamento das transformações de

modo a otimizar o sistema, liberando, assim, recursos para as transformações

em tempo real dos objetos que irão interagir com o jogador.

Por ser parte essencial do projeto desenvolvido no programa de mestrado

detalhes sobre gráficos e objetos gráficos, bem como métodos sobre processamento

geométrico e espacial podem ser encontrados no (5).

 58

Capítulo 5. - Processamento Geométrico

Um dos grandes mitos a respeito dos computadores é o de que um dia teremos

poder de processamento suficiente. Mesmo em aplicações relativamente simples,

como processadores de texto, descobrimos que funcionalidades adicionais podem

ser aplicadas para todo tipo de coisa, tal como verificação gramatical e ortográfica

em tempo de digitação, apresentações gráficas mais elaboradas, exibição de textos

sem o efeito de escada (antialiasing), reconhecimento e digitação por voz, etc [11].

Em renderização em tempo real existem, pelo menos, três objetivos: mais

quadros por segundo; resoluções mais altas e objetos cada vez mais realísticos na

cena.

Uma velocidade de 60-72 quadros por segundo é considerada mais que

suficiente e, talvez, uma resolução de 1600 por 1200 pixels seja suficiente por

enquanto, mas não há um limite superior para a complexidade de uma cena. A

renderização perfeita de um Boeing-777 incluiria 132,500 partes diferentes, o que

incluiria um modelo poligonal com mais de 500.000.000 polígonos [ 19]. Donde pode-

se concluir que técnicas de aumento velocidade e esquemas de aceleração sempre

serão necessários.

Esse capítulo lida com algumas metodologias adotadas para processamento

geométrico e visual de maneira a tornar o processamento de dados gráficos mais

rápido e, conseqüentemente, acelerar o processo de renderização.

Essas metodologias dizem respeito ao método de representação dos objetos na

cena, processamento de visibilidade e redução de complexidade geométrica.

 59

5.1. Objetos Gráficos

Enquanto que para a maioria das aplicações 2D um conjunto de imagens que

irão compor o sistema é suficiente, para as aplicações 3D a maioria do trabalho

realizado é de natureza matemática, apenas o passo final de uma imagem 3D é de

natureza gráfica. Portanto necessita-se de se definir um conjunto de estruturas de

dados descritivos para representar os objetos que irão compor o sistema [4].

Essa estrutura descritiva, ou conjunto dessas estruturas, que formará a base

para o sistema de renderização é o responsável, muitas vezes, pela medida de

performance no sistema.

A representação de um objeto através de uma estrutura que requer muitos dados

para descrevê-lo pode ser um empecilho caso estejamos implementando uma

aplicação para um sistema com memória limitada.

Da mesma forma, um objeto representado por uma função pode fazer com que o

sistema consuma muito tempo para o processamento visual de sua forma,

diminuindo a performance do renderizador.

Essas estruturas podem ser classificadas em duas categorias: vetorial ou

paramétrica; cada qual com suas vantagens, desvantagens e sub-categorias:

1.25. Estrutura Vetorial

Objetos descritos através da estrutura vetorial (objetos poligonais) são

representados através de um conjunto de vértices ou vetores e de um conjunto de

relacionamento entre esses vértices de maneira que um dado desse conjunto

represente um polígono a ser desenhado na tela após sua transformação.

Essa estrutura é a mais utilizada nas aplicações 3D atuais, pois as descrições e

definições matemáticas para operações nesse tipo de estrutura estão muito bem
 60

descritas e são, em sua grande maioria, implementadas nas aceleradoras gráficas

3D atuais. Porém necessita-se de um enorme volume de dados para que um objeto

possa ser fielmente descrito por essa estrutura.

Existem basicamente dois tipos de regras para descrever um polígono a partir da

associação de faces, linhas e vértices, a qual denominaremos de estrutura de

Conjunto de Faces e através de uma estrutura de regra e ordenação de vértices.

1.26. Conjunto de Faces

A representação por conjunto de faces é a mais fácil de ser criada. Ela descreve

que, dado um conjunto de vértices existe um conjunto de bordas, cujos elementos

são formados por uma relação entre dois vértices e, através desse conjunto, existe

um conjunto de faces cujos elementos são formados através da relação entre três ou

mais bordas criando, portanto, um polígono.

O algoritmo para a renderização dessa estrutura percorre cada face, buscando,

ordenadamente, os vértices de cada borda das faces de maneira a formar o

polígono desejado.

Apesar de simples essa estrutura tem uma desvantagem clara: em um objeto

com muitas faces sempre existirão duas faces que compartilham pelo menos um

vértice. Caso o sistema poligonal lide com triângulos, o número máximo de vértices

a serem compartilhados é 2, caso lide com polígonos gerais, quadriláteros ou

polígonos irregulares, o número máximo de vértices compartilhados por um polígono

pode chegar a o valor do número de vértices do polígono com maior número de

vértices subtraído de um. Esse compartilhamento indica que um mesmo vértice pode

ser processado mais de uma vez no sistema, o que pode causar um atraso no

processamento de renderização devido ao volume de dados processados.

 61

,Y2,Z2) (X3,Y3,Z3) ... (Xn-1,Yn-1,Zn-1) (Xn,Y n,Zn)

(X1,Y1,Z1) ( 2X

Borda 1 Borda 2 ... Borda n-1 Borda n

Face 1 Face 2 ... Face n

Figura 10: Representação por Conjunto de Faces

1.27. Ordenação de Vértices

Para contornar o problema dos objetos poligonais representados por conjunto de

vértices, bordas e faces surgiu o método de malha por ordenação de vértices ou

stripping.

Esse método descreve que os objetos poligonais são descritos por uma lista

ordenada de vértices e uma regra de composição desses vértices na ordem em que

eles se encontram.

Essa regra de composição é a responsável por formar as faces poligonais que

irão definir o objeto e ela geralmente define objetos triláteros, quadriláteros ou linhas,

como demonstrado na tabela a seguir.

 62

Regra Lista Representação Gráfica

Linha 0,1,2,3,4

Linha conectada 0,1,2,3,4,5

Quadrilátero 0,1,2,3,4,5,6,7

Triângulo 0,1,2,3,4,5

Triângulos 0,1,2,3,4

Centrados

Tabela 1: Representação dos tipos de malhas por vértices ordenados

Tomando como exemplo a estrutura de conjunto de faces, o objeto processado

pela regra do triângulo demonstrada na tabela acima necessitaria processar os

dados na seguinte ordem: 0,1,2,1,2,3,2,3,4,3,4,5, enviando, portanto, 12 vértices ao

sistema; enquanto que no processo de vértices ordenados apenas 5 vértices são

enviados.

1.28. Estrutura Paramétrica

Algumas bibliotecas gráficas podem implementar métodos paramétricos de

descrição de objetos. Isto é, objetos tridimensionais podem ser descritos a partir de

 63

uma função f(u,v)., muito útil para terrenos, objetos quádricos ou superfícies não

“fechadas”, como um cilindro, um círculo ou superfícies NURBS.

Por não ter um volume grande de dados essa representação consome pouca

memória, porém caso a biblioteca ou a placa gráfica não suporte essa

representação ela pode (e deve) ser convertida para uma representação poligonal, o

que pode consumir tempo de processamento.

5.2. Processamento de Visibilidade

Atualmente muita atenção tem sido dada a algoritmos que resolvam o problema

da visibilidade de superfícies opacas. A invenção do z-buffer, uma solução relativa

de força bruta substituiu todos os outros métodos de geração de imagens em

workstation devido ao mérito de sua eficiente implementação em hardware.

Contudo, os ambientes virtuais que se deseja renderizar atualmente possui tantas

primitivas geométricas que solucionar o problema de oclusão apenas com o z-buffer

se torna ineficiente.

Esse problema é solucionado através do cálculo de quais porções da cena estão

realmente visíveis e do processamento desse subconjunto. A oclusão de faces

ocultas é um exemplo trivial.

Essa tarefa de processamento de visibilidade é calculada pela CPU e pode ser

dividida em duas fases: 1) pré-processamento de visibilidade é uma tarefa realizada

no momento da execução do software e antes de qualquer exibição de cena,

gerando dados para serem processados pela fase seguinte e 2) resolução de

visibilidade, tarefa realizada em tempo real que se encarrega de eliminar as partes

da cena que não são visíveis.

 64

A maneira mais simples de resolução de visibilidade é aquela realizada através

do frustum de visualização17. O problema, neste caso, é não deixar que primitivas

geométricas invisíveis passem para o processo de recorte/renderização,

descartando a porção da cena que está fora do volume de visualização da câmera.

Para isso se faz necessário uma organização espacial das primitivas da cena, a qual

é realizada através do agrupamento de primitivas ou objetos espacialmente

coerentes. Volumes de contenção hierárquicos podem ser utilizados para ordenar a

geometria da cena.

1.29. Particionamento do Espaço

Técnicas de particionamento do espaço são necessárias para aumentar a

eficiência no cálculo da visibilidade de objetos por organizá-los em uma estrutura

cujas propriedades permitem que grandes regiões do espaço sejam calculadas a

partir de um conjunto visível de geometria utilizando testes simples [61].

Existem duas variedades muito conhecidas dos métodos de particionamento do

espaço: Octrees e Árvores de Partição Binária do Espaço, ambas discutidas a

seguir.

Nesta seção está apresentada uma outra técnica de processamento geométrico

para eliminar regiões em massa da geometria do ambiente através de um conjunto

de visibilidade (PVS).

1.30. Octrees

Suponha que toda a geometria pertencente ao mundo como um todo, ou a uma

região particular do mundo, esteja contida em uma caixa retangular B.

17
Frustum: Volume de visualização que representa o conjunto do espaço visível ao usuário. Todo e qualquer
objeto que estiver total ou parcialmente dentro do frustum será renderizado.
 65

Uma octree é uma estrutura que particiona essa caixa em oito caixas

retangulares eqüiláteras menores denominadas de octantes, as quais são

subseqüentemente subdivididas em oito octantes menores até que se tenha ocorrido

um número máximo de interações denominado de profundidade da octree.

Cada octante está associado à caixa pela qual ele foi particionado e cada objeto

do mundo está associado ao menor octante que o contêm completamente (podendo,

inclusive, ser a caixa original, B).

A Figura 11 ilustra uma representação de uma octree construída para um volume

contendo um único objeto e demonstra como a estrutura de dados correspondente

está organizada.

Cada nó em uma octree possui, no máximo, oito sub-nós. Como demonstrado na

Figura 11, octantes que não possuem objetos não são subdivididos e são removidos

da árvore.

Raíz

1o Nível

2o Nível

Figura 11: Representação gráfica e estrutural de uma octree

Organizar a geometria em uma estrutura de árvore tem o benefício de que ao se

determinar que um nó não está dentro do volume de visualização, então todos os

 66

seus descendentes também não estarão e, portanto, não é necessário realizar

testes de visualização nos descendentes diminuindo, portanto, o processamento.

Contudo, o problema da representação da octree está no custo de

processamento. Pode-se calcular a octree previamente à execução do sistema para

uso posterior, porém, em termos de animação a octree deve ser recalculada para a

menor mudança nos parâmetros posicionais de cada objeto, o que é altamente

custoso para o sistema.

Uma alternativa seria utilizar a representação octree para objetos estáticos, como

a superfície de um ambiente aberto ou os muros de um ambiente fechado e realizar

para cada polígono desse ambiente o teste do frustum culling. Para cada objeto da

cena também seria realizado o teste de frustum culling após a determinação de

visibilidade da octree.

1.31. Partição Binária do Espaço (BSP)

Partição binária do espaço é um método de particionamento e ordenamento

espacial proposto por Naylor [20] em que um espaço n-dimensional é recursivamente

particionado em subconjuntos convexos através de hiper-planos.

A estrutura de representação e processamento do método de partição binária do

espaço é denominada de árvore de partição binária do espaço (BSP-tree) e divide, a

cada nível, o espaço em dois sub-espaços, porém, ao contrário da octree, os planos

de partição da árvore BSP podem ser arbitrariamente orientados, o que pode

ocasionar na redução de dados a serem processados.

Ela é construída para um conjunto de objetos através da escolha de um plano de

partição, algumas vezes chamado de plano de divisão [61], e ordena a geometria em

dois grupos: objetos do lado positivo do plano e objetos do lado negativo do plano.
 67

Tradicionalmente elas são alinhadas aos polígonos que formam a geometria do

mundo. A Figura 12 demonstra um exemplo bidimensional de uma região contendo

diversos polígonos responsáveis por determinar a estrutura da árvore BSP.

A cada nível um polígono é escolhido para representar o plano de partição e os

polígonos restantes são ordenados em grupos positivos ou negativos. Caso um

polígono intercepte um plano, ele pode ser dividido em dois novos polígonos cujas

partes se situarão uma no lado positivo e outra no lado negativo, ou ele pode ser

adicionado a ambos os lados. Esse processo é repetido até que todos os polígonos

tenham sido processados.

O problema com árvores BSP é que o grande número de polígonos e superfícies

curvas usados nas cenas 3D a torna impraticável. Em uma outra maneira de se

calcular uma árvore BSP calcula-se divisões para cada objeto e não para cada

polígono, de maneira que na estrutura final cada objeto se situe em uma única

região da partição e que cada região contenha apenas um objeto.

Os planos de partição podem, então, serem calculados utilizando-se as

dimensões cúbicas do objeto, as quais são obtidas através da recuperação das

coordenadas máximas e mínimas de cada objeto nos planos X, Y e Z.

 68

Figura 12: Ilustração de uma árvore BSP bidimensional

1.32. Conjunto de Visibilidade Potencial (PVS)

Airey [21], propôs o emprego de conjunto de visibilidade potencial (PVS) para

aplicação em estruturas de ambientes densamente ocultos, como prédios, casas,

masmorras, etc, os quais possuem salas conectadas através de portas (ou portais).

Esses ambientes são representados em uma estrutura denominada de sistema

de portais, uma técnica eficiente para eliminar rapidamente regiões em massa da

geometria do mundo do conjunto visível.

O ambiente é decomposto em células conectadas por portais, os quais são

representados por polígonos convexos que informam qual célula pode ser

visualizada através dele.

A vantagem em se utilizar sistemas de portais é que qualquer região que não

pode ser vista através de uma série de portais não é considerada para a

renderização e quando se determina quais partes do mundo são visíveis, esse

sistema nos permite referenciar apenas uma pequena fração do conjunto de dados

total, porque qualquer geometria que se situe no lado oposto de um portal não

visível é ignorada.

O sistema pré-computa as células, constrói o grafo de adjacência de células e

associa a cada célula um PVS, que é uma super-estimativa conservativa da porção

 69

visível que pode ser eficientemente computada. Teller e Séquin [22], utilizaram muito

esse conceito e descobriram uma solução analítica para o problema de visibilidade

por portais.

Usando programação linear eles calcularam um conjunto completo de relações

célula para célula e célula para objeto visíveis [Fig 13]. Esse é um processo que

envolve intensa computação.

Figura 13: Resolução de visibilidade do interior de um prédio por [23]. À esquerda o modelo

total, à direita a porção vista pelo observador.

Apesar do alto custo computacional requerido no cálculo do PVS, por ele ser

uma superestimativa conservativa do sistema, pode-se pré-processar os dados

necessários, armazenar os resultados em uma base de dados e utilizá-los

posteriormente sem custo adicional e combinado com uma estrutura de partição do

espaço, como octrees ou BSP’s, ele pode oferecer resultados surpreendentemente

eficientes.
 70

1.33. Redução de Complexidade Geométrica e Visual

A renderização de um objeto detalhadamente complexo que consiste em

milhares de polígonos e texturas amplas são percebidas apenas quando o modelo

está perto do ponto de visão. O tempo que leva para processar esse alto número de

triângulos e suas coordenadas de texturas associadas são válidos no ganho da

qualidade visual. Contudo, quando o mesmo modelo está distante do ponto de visão

o detalhe provido por milhares de polígonos pode não ser perceptível, pois a

cobertura do espaço de tela do modelo renderizado pode ser apenas uma pequena

quantidade de pixels.

Nessa situação a negociação entre tempo e qualidade visual não é válida, pois

se o resultado da imagem final for apenas uma pequena quantidade de pixels, a

quantidade de polígonos processados deveria ser proporcional, assim como a

largura da textura associada a ele.

Os procedimentos descritos nessa seção lidam com o processamento no sentido

em reduzir a complexidade geométrica e visual de objetos de acordo com padrões

definidos sem perda significativa da representação gráfica final dos mesmos através

de processos conhecidos como nível de detalhe (LOD) e mipmapping.

1.34. Nível de Detalhe (LOD)

Em ambientes visuais extensos é comum o caso em que objetos estejam muito

distantes ou sejam muito pequenos, fazendo com que as características geométricas

desses objetos estejam abaixo do nível de percepção humana ou sejam

renderizados apenas em pontos na tela do computador. De maneira a liberar

recursos para o renderizador, faz-se uso de diversas representações geométricas

diretamente relacionadas ao nível de percepção de um mesmo objeto. O conjunto

 71

dessas representações é denominado de nível de detalhe [Figura 14] e a utilização

do detalhe mais simples pode ser útil para melhorar a taxa de quadros por segundo

do renderizador.

Figura 14: Três níveis de detalhe de um Warbird Romulano.

Essa técnica foi introduzida por Clark [24] em 1976 e tem sido utilizada desde

então. Estratégias importantes para a determinação do nível de detalhe a ser

utilizado para a renderização são fundamentais e levantam questões tais como o

melhor método de transição entre dois níveis de detalhe consecutivos ou em como

criar níveis de detalhe eficientes o suficiente para preservar a fidelidade do objeto

geométrico.

Como a percepção humana é uma característica essencialmente estética, não há

um método genérico para a seleção da melhor representação dos diferentes níveis

de detalhe para um determinado objeto. Métodos heurísticos simples utilizam a

distância ou o tamanho do objeto projetado na tela como um método de medida para

o nível de detalhe. Infelizmente, esses métodos heurísticos, por serem estáticos, não

se adaptam muito bem à carga variável no pipeline gráfico, ou seja, se muitos

objetos complexos estão próximos ao observador, a sobrecarga pode não ser

detectada e a performance do renderizador, certamente, cairá.

Funkhouser e Séquin atacaram esse problema [25] implementando um algoritmo

de previsão seletiva formulado através da relação custo/benefício atacando

 72

problemas como: “Qual seleção de nível de detalhe para cada objeto produz a

melhor imagem enquanto o custo acumulado para se renderizar cada objeto se

mantenha abaixo da capacidade máxima do gerador de imagens, de maneira a

produzir uma taxa de quadros por segundo desejável?”.

Apesar do nível de percepção não notar as diferenças nos níveis de detalhe do

objeto, a troca imediata de um nível para outro causa efeitos perceptíveis devido,

principalmente, à mudança na definição geométrica do objeto. Uma alternativa a

esse problema seria um curto período de transição entre um nível de detalhe e outro

através de técnicas como, por exemplo, o fading, porém, nesse caso, o sistema

ficaria carregado com duas definições de malha para o mesmo objeto. Outro método

útil seria utilizar a técnica de morphing, que realiza transformações nos vértices da

malha levando-o à forma desejada, porém essa técnica, geralmente, só é viável

quando há uma correspondência geométrica bem definida entre as duas formas.

Outro problema especializado que vale a pena ser discutido é quanto à

representação e simplificação de terrenos. Terrenos geralmente são representados

por modelos de elevação ou campos de altura de amostras de pontos obtidos

através de uma função bidimensional discreta e, geralmente, distribuídos em uma

grade retangular. Tais dados são facilmente obtidos por fontes tais como imagens de

satélites. Para a velocidade na renderização uma triangulação dos pontos é

realizada de modo a produzir uma representação tridimensional com baixo número

de polígonos. Tal esquema de triangulação pode ser categorizado em um modelo de

subdivisões regulares ou em uma rede irregular de triângulos (TIN). A renderização

interativa é melhor obtida através da utilização de subdivisões de múltiplas

resoluções de forma que os níveis de detalhe possam ser selecionados em tempo

 73

real para diferentes áreas do terreno. Falby [26], cita como o gerenciamento em

tempo real de dados de terreno pode ser obtido através do gerenciamento de

regiões de contenção definida a partir da posição do observador.

1.35. MipMapping

Enquanto que nível de detalhe lida com a complexidade geométrica dos objetos,

a técnica de mipmapping diz respeito à complexidade visual da textura a ser

aplicada no objeto.

Além de ser uma técnica de redução de complexidade visual, a técnica de

mipmapping é utilizada também no antialiasing de texturas [27].

Através do mipmapping, a textura original é denotada como sendo de nível 0, a

textura de nível 1 contêm o resultado da textura original quando aplicada sobre um

filtro passa baixa e aplicando a média da área de 2x2 pixels ou texels. Dessa forma

um mipmap de nível n será um quarto do tamanho do mipmap do nível n-1, o que

exige algumas modificações na estrutura básica da textura, permitindo definir um

conjunto de imagens de acordo com o nível de detalhe percebido, denominado de

pirâmide de mipmap, como demonstrado pela Figura 15. A Figura 16 demonstra o

problema da aplicação da textura e a correção desse problema por mipmap.

Figura 15: Pirâmide de MipMap

 74

Figura 16: Correção de textura por mipmapping, o objeto da esquerda não possui mapeamento

de textura por mipmap.

O método de aplicação do mipmapping vai além da utilização da distância do

objeto ao ponto de visão, ele é aplicado diretamente nos polígonos dos objetos e,

portanto, requer um cálculo intensivo. Porém, muitas placas gráficas e bibliotecas

implementam o algoritmo de aplicação de mipmapping.

 75

Capítulo 6. - Animações

Animar significa, literalmente, dar vida a algo, mover algo que não pode mover

por si só. A animação adiciona aos gráficos a dimensão do tempo, o que significa um

aumento considerável na quantidade de informação transmitida [28].

Projetos em animação tiveram início por volta de 1800 com a descoberta da

persistência da visão. Essa descoberta levou à criação de um instrumento chamado

Zoetrope [28], que consistia de um cilindro oco, com rotação em seu eixo de simetria

e uma fita, com diversas imagens ligeiramente modificadas, em seu interior. Ao

rotacionar o cilindro o espectador tinha a ilusão de que as imagens se moviam,

porém,a primeira idéia de se usar uma câmera para fazer com que objetos ou

imagens sem vida se movessem surgiu em 1890 [28].

A primeira e maior técnica no processo de desenvolvimento de animações pode

ser atribuída por John Bray por volta de 1910. Esta técnica foi patenteada em 1915.

Ele utilizou-se de celulóide translucente para criar animações em diversas camadas.

Dessa maneira a cena de um ambiente estático não precisaria ser redesenhada,

apenas a cena de movimentos teria essa necessidade e seria desenhada em um

dos celulóides que iria sobrepor o cenário [28].

A produção tradicional de animação consiste em, primeiramente, apresentar uma

história de modo a se criar um story board onde se esboça algumas cenas chaves

da animação acompanhadas de textos explicativos com o objetivo de discutir a

viabilidade da animação. Caso aprovada, a história detalhada é criada de modo a

identificar os movimentos e as ações dos personagens. Em seguida quadros chaves

são determinados e desenhados pelos artistas principais para que sejam

identificados e aprovados os personagens e a qualidade da imagem.

 76

Posteriormente, associados e artistas secundários produzem os quadros entre os

quadros chave, processo conhecido por in-betweening. Finalmente cores são

aplicadas às células de animação.

Em termos computacionais essa técnica é semelhante à da produção de

animações por sprites, onde um fundo é desenhado na tela e os sprites são, por

analogia, os objetos desenhados nos celulóides.

Atualmente animação por computador está mais relacionada a outros métodos

de produção de animação, a saber, a técnica stop-motion [29], onde modelos

articulados e modelos de cenários são utilizados em conjunto com uma câmera. A

cada quadro gravado os modelos são ligeiramente modificados criando, portanto, a

ilusão de animação.

Em sua forma mais primitiva, animação por computador significa usar um

renderizador padrão para produzir quadros consecutivos [30], porém, o termo

animação, no contexto da computação gráfica e dos jogos por computador, se refere

a qualquer alteração em uma cena em função do tempo. As características passíveis

de modificação, neste caso, são: posição, forma, cor, iluminação, material,

transparência, etc. [31], [32].

De acordo com Parent, R. [28], a animação por computador classifica-se,

basicamente, em dois tipos:

a) Animação assistida por computador (Computer Aided Animation), que

1/2
geralmente se refere às animações 2D ou 2 D e se aproxima muito das

animações tradicionais, desenhadas à mão, onde o único método algorítmico

realizado por esse tipo de animação é a interpolação entre formas chave

(morphing) ou quadros chave (in-betweening), onde o objeto e os quadros

 77

que formarão a ilusão de movimento já estão definidos, geralmente por meio

da estrutura de sprites e

b) Animação gerada por computador (Computer Generated Animation), diz

respeito a animações totalmente geradas por computador. Ainda de acordo

com Parent [28], as técnicas para produção desse tipo de animação se

classificam como:

- Técnicas de baixo nível: são, geralmente, algoritmos de interpolação de

quadros chave (in betweening) ou de formas chave (morphing) e

- Técnicas de alto nível: são técnicas obtidas através de algoritmos ou

modelos usados para gerar movimento através de um conjunto de regras ou

restrições. O movimento é gerado através da especificação das regras ou

restrições no modelo ou algoritmo desejado e de um conjunto de parâmetros

iniciais. O sistema é, então, executado e o movimento dos objetos é calculado

através dessas regras e restrições. Um modelo que se encaixa perfeitamente

nesse parâmetro é o de animação baseada em física.

Animações tridimensionais por computador possuem vantagens únicas não

disponíveis nas animações tradicionais. Por exemplo: animações podem ser

produzidas diretamente de modelos ou de um conjunto de equações especificando o

comportamento dinâmico de estruturas ou máquinas e isso possui implicações

maiores no campo da visualização científica. Esse tipo de animação é, algumas

vezes, qualificado como “simulação” e é, por definição, capaz de produzir animações

extremamente realistas.
 78

6.1. Tradicional

A animação tradicional é a animação mais simples de ser reproduzida em

sistemas computacionais. Tudo o que se necessita é de um conjunto de quadros que

contenham o tempo de exibição em milisegundos de maneira que ao se esgotar

esse tempo o quadro é substituído pelo seguinte.

Em animação tradicional interativa, o procedimento utiliza sprites e uma regra de

controle para a exibição de quadros onde, caso haja uma interferência do usuário, a

animação continua até o quadro inicial da mesma e então é alterada para o quadro

inicial da próxima animação, que diz respeito à informação transmitida pelo usuário.

Esse tipo de animação pode ser projetado por um conjunto de máquinas de

estado que indicam o estado da animação total. Cada estado da animação

representa uma máquina de estados que indica um tipo de animação (andando,

correndo, parado, etc) e caso haja interferência há uma transição de uma máquina

de estados para outra.

A Figura 17 demonstra um exemplo abstrato de como seria a modelagem dessas

máquinas de estados:

Pular Pulando
Z ms
Pular

Caiu
Parado
X ms Andando
Andar Y ms

Parar

Figura 17: Máquinas de Estados de animação

 79

Em aplicações 2D esse tipo de animação é construído através da rápida

sobreposição de imagens, porém, em aplicações 3D ela necessita de interpolações

entre formas num processo conhecido por morphing ou então através de

manipulações de controladores que podem especificar a orientação do próprio

objeto ou de como os vértices (ou alguns dos vértices) dos objetos serão

modificados, através de animação por controle de baixo nível e, portanto, não pode

ser considerada de animação tradicional, pois precisa de procedimentos de controle

para a sua produção.

6.2. Procedimental

Em animações procedimentais o controle sobre a especificação do movimento é

realizado através do uso de procedimentos que definem explicitamente o movimento

como uma função do tempo. Tal definição vaga engloba uma grande faixa de

trabalho [30].

Um tipo de animação procedimental é o uso de simulação por leis da física para

realizar animações de comportamentos dinâmicos, tais como gravidade, rotação,

etc.

Esse tipo de animação, no contexto do projeto desenvolvido, está implementado

no módulo de simulação física, detalhado mais explicitamente no (Capítulo 12),

seção 10.6.3.
 80

6.3. Estrutural

Esta categoria estende o campo da animação para além daquele que especifica

como um objeto rígido se move no espaço por permitir que a própria estrutura do

objeto mude sua forma e por animá-la mudando de forma [30].

Nesse tipo de animação a distinção entre modelagem e animação é quebrada,

pois os problemas de como o objeto é representado e como essa representação é

animada estão intimamente ligados. Problemas, tais como colocar,

automaticamente, uma “pele” na figura articulada ou como controlar os músculos,

responsáveis por produzirem as deformações na malha já estão consolidados,

porém não esgotados [33], [34].

Pode-se separar essa categoria em duas subseções: Animação de objetos

articulados e Animação de objetos maleáveis, discutidas a seguir.

1.36. Animação de objetos articulados

Um objeto articulado é composto de segmentos conectados ou ligações cujo

movimento relativo um ao outro está restringido de alguma forma. Esse assunto está

relacionado diretamente com os tópicos de cinemática e cinemática inversa.

Animações de objetos articulados se tornou popular recentemente devido ao

desejo de se utilizar seres humanos como atores sintéticos em ambientes de

animação tridimensional por computador.

Muitos resultados de experimentos em robótica se provaram úteis no campo da

animação de objetos articulados devido à própria natureza desses tipos de objetos,

que, quando simples, podem simular um robô.

Dessa maneira muitos dos conceitos utilizados na robótica também é utilizado no

campo da animação de objetos articulados e estão especificados abaixo:

 81

- Figura articulada: é uma estrutura que consiste de uma série de ligações

rígidas conectadas por juntas. Embora existam diversos tipos de juntas

especificadas no campo da robótica, no campo da animação trabalha-se

especificamente com juntas de revolução ou juntas de rotação;

- Cinemática: é o estudo ou a especificação do movimento

independentemente das forças atuantes que o produz. Nesse campo estão o estudo

da posição, velocidade e aceleração, ou seja, todas as propriedades geométricas e

propriedades relativas ao tempo do movimento. Existem dois tipos de cinemática, a

direta e a inversa. A cinemática direta diz que o movimento de todas as juntas deve

ser especificado explicitamente pelo animador e que o movimento da terminação é

determinado indiretamente através do acúmulo de todas as transformações que

levaram àquela terminação, pois a estrutura da árvore de ligação é descendente, ou

seja, os objetos são afetados de acordo com as transformações na hierarquia

superior. A cinemática inversa, também conhecida por movimento direcionado ao

objetivo, diz que o movimento de todas as juntas é calculado apenas através da

especificação da posição desejada das terminações resolvendo a posição e

orientação de todas as juntas na hierarquia de ligamento que levaram a terminação

àquela posição;

- Graus de Liberdade (DOF): indica o número de variáveis de posições

independentes necessárias para especificar o estado de uma estrutura. A Figura 18

demonstra uma estrutura que consiste de duas juntas de revolução e uma junta de

deslizamento contendo, portanto, três graus de liberdade;

 82

Figura 18: Graus de Liberdade

- Terminações: São os pontos finais de uma cadeia em uma estrutura

articulada, como demonstrado na Figura 19. Analogamente à estrutura de dados

denominada árvore, uma terminação seria uma folha da árvore;

Hierarquia de nós:

Nó Raiz: ;

Terminações: ;

Nós Convencionais: .

Figura 19: Estrutura Hierárquica, terminações e nó raiz.

 83

- Vetor de Estado: é um conjunto de parâmetros independentes definindo a

posição, orientação e rotação de todas as juntas que constituem o objeto articulado.

A dimensão do espaço de estado, isto é, a dimensão do espaço que contêm todas

as possíveis posições de todas as juntas é igual ao grau de liberdade da estrutura

articulada. Dessa maneira, descobrir uma animação de um objeto articulado se

reduz a descobrir um caminho N-dimensional em seu espaço de estado.

Atualmente há basicamente dois modelos para a geração de animações visando

objetos articulados: Modelos cinemáticos e modelos dinâmicos [35]. O modelo

cinemático é o método mais direto para animação de objetos articulados. Ele diz

respeito apenas à articulação de juntas, velocidade angular dos objetos e a

hierarquia entre eles e não diz respeito às forças de atuação ou torque que atuam no

objeto ou nas articulações do mesmo. Uma alternativa ao método cinemático é o

método dinâmico ou animação baseada em física, onde a movimentação é resultado

de simulações físicas, que incluem modelagem detalhada de forças e torques

atuando no objeto, a massa do objeto, seu momento de inércia e sua interação com

o ambiente, o que introduz novos desafios a serem resolvidos de maneira a ser de

uso prático, pois envolve o controle de movimento sobre o tempo o que,

historicamente, tem tido um alto custo computacional.

1.37. Animação de objetos Maleáveis:

Essa área inclui as técnicas mais gerais de deformação e animação de

deformação dos objetos. Essas técnicas são extremamente importantes, pois

permitem que os princípios tradicionais básicos da animação de personagens

bidimensionais sejam estendidos para a animação computacional tridimensional

[30].
 84

Em qualquer método empregado para realizar a animação de objetos maleáveis

pode se identificar dois processos distintos. Estes podem ou não estar

explicitamente separados dependendo da técnica utilizada e são classificados como:

Mecanismo ou método que facilita a deformação da representação do objeto ou

Método que anima a natureza da deformação como função do tempo.

Em sua forma básica, a deformação é normalmente realizada através da

movimentação dos vértices de um modelo poligonal ou pelo controle de pontos de

um modelo paramétrico; a animação é realizada através da coreografia desses

movimentos, como demonstra a Figura 20.

- Arestas;

- Ossos.

Figura 20: Esqueleto de um tentáculo e os parâmetros

(ossos) de transformação de vértices

6.4. Estocástica

Esse tipo de animação controla as características gerais da animação por invocar

processos estocásticos que geram uma grande quantidade de detalhes de baixo

nível. Esse método é particularmente útil para sistemas de partículas. Fenômenos

como quedas d’água [36], fogos de artifício e campos de grama perturbados pelo

vento [37] foram modelados utilizando esse método.

 85

6.5. Comportamental

Nesse método de animação o animador exerce o controle definindo como os

objetos se comportam ou como eles interagem com seu ambiente. O animador faz

isso adotando atores ou personagens na animação com uma percepção local do

ambiente e um conjunto de regras dizendo a eles como reagirem.

Como exemplo, Reynolds [38] refere-se a isso como simulação comportamental

ou animação “o que aconteceria se...”. Nesse estudo intrigante ele simulou o

comportamento de agrupamento de pássaros e peixes. Cada membro da reunião é

um ator independente que navega de acordo com sua percepção local do ambiente

dinâmico, as leis da física simulada que governam seu movimento e um conjunto de

comportamento é programado pelo animador.

6.6. Controle de Baixo Nível

O controle de baixo nível é o nível mais baixo na hierarquia de animação no que

diz respeito à especificação do movimento. Fundamental a esse nível está o

problema de como se parametrizar os modos básicos de movimentação e orientação

dos objetos no espaço.

Os assuntos relevantes no controle de baixo nível são os sistemas de script,

keyframing, animação dirigia por spline através de controle paramétrico e a

parametrização da orientação [30].

1.38. Sistemas de Script

Sistemas de Script são interpretadores de uma linguagem de script para gerar

uma animação. O animador deve, explicitamente, especificar os movimentos,

 86

orientação e posição dos objetos no tempo e espaço e, a partir de um conjunto de

comandos, criar as regras para que o sistema crie a animação automaticamente.

Muitos sistemas de script para animação foram desenvolvidos e, dentre eles, os

melhores sistemas mais conhecidos e quotados são o ASAS (Actor Script Animation

System)[39] e o MIRA [40].

Com o advento da interação na produção da animação os sistemas de script

perderam a popularidade devido ao apelo lúdico da animação interativa, porém,

combinados podem criar aplicações interessantes por iludir o usuário quanto à

independência de objetos não controlados por ele.

1.39. Quadros Chave

Sistemas de quadro chave obtiveram esse nome devido ao tradicional sistema de

produção hierárquica desenvolvido primeiramente por Walt Disney. Nesses

sistemas, animadores habilidosos desenhavam alguns quadros da seqüência de

animação denominados quadros chave. A produção da seqüência completa era,

então, passada para artistas menos habilidosos para criarem os, assim chamados,

quadros intermediários (inbetween).

Esse processo é melhor implementado em um sistema de tempo real onde o

animador reespecifica ou ajusta interativamente os quadros chave.

A emulação dessa técnica pelo computador através de interpolações substitui o

artista menos habilidoso através da produção automática dos quadros

intermediários.

Essa técnica foi generalizada para permitir a interpolação de qualquer parâmetro

que afeta o movimento provendo, portanto, um controle de mais alto nível do que o

processo tradicional.
 87

Deve-se tomar muito cuidado com a parametrização dos dados para que a

interpolação dos quadros não seja feita de maneira errônea. A Figura 21 indica como

uma parametrização distinta pode afetar significativamente uma animação.

Figura 21: A figura da esquerda apresenta parametrização de interpolação por rotação

enquanto que a da direita interpola linearmente os pontos iniciais e finais.

1.40. Paramétricas

Essa técnica é semelhante à técnica de interpolação por quadros chave, porém a

especificação das características do movimento é realizada através do uso de

funções paramétricas, como as splines cúbicas.

O primeiro uso prático de splines é especificar o movimento de um objeto ao

longo de um caminho formado pela spline, assim interpola-se a posição dos pontos

de controle da spline tanto no espaço quanto no tempo onde tais pontos indicam a

posição do objeto naquele instante. A partir desses dados o sistema se encarrega de

calcular a posição do objeto ao longo do tempo fazendo com que ele siga o caminho

especificado. Pode-se também recuperar informações sobre a orientação do objeto

através da obtenção da tangente da curva num determinado ponto.

 88

Capítulo 7. - Bibliotecas Gráficas

Até algum tempo atrás, projetos que envolviam gráficos 3D deviam implementar

todos os processos para a geração dos gráficos, sendo muitas vezes ineficientes ou

ineficazes em termos de produção de imagens e apresentando incompatibilidades

com algumas placas gráficas.

Como muito dos procedimentos efetuados por esse processo é corroborado por

teorias matemáticas bem definidas e aceitas pela comunidade de computação

gráfica, surgiram diversas bibliotecas de programação que implementavam e

ofereciam os recursos necessários para facilitar a criação de aplicativos 3D.

As bibliotecas gráficas em maior uso atualmente no desenvolvimento de jogos

para computador são OpenGL [41] e DirectX [42]. A OpenGL apresenta, numa primeira

avaliação, facilidades de escrita de código e maior portabilidade. Por outro lado, o

DirectX apresenta melhores resultados quanto à performance e à velocidade de

processamento quando os recursos são emulados por software.

7.1. DirectX

O DirectX da Microsoft é um conjunto de Interface de Programação de

Aplicações (API) multimídia desenvolvido de maneira a prover uma plataforma

padrão de desenvolvimento para PCs com sistema operacional Windows,

habilitando desenvolvedores a acessar aspectos especializados de hardware sem a

necessidade de escrever códigos específicos para tal. O DirectX foi introduzido em

1995 e é um reconhecido padrão para desenvolvimento de aplicações multimídia

para o sistema citado.

 89

A meta da Microsoft ao desenvolver o DirectX era fornecer aos desenvolvedores

um conjunto comum de instruções e componentes, garantindo-lhes que suas

aplicações multimídia executariam em qualquer PC com Windows, sem se

preocupar com detalhes de hardware. Ao mesmo tempo, os desenvolvedores

poderiam estar seguros de que seus produtos aproveitariam ao máximo as

capacidades do hardware disponível na máquina para alcançar a melhor

performance possível.

O DirectX fornece aos desenvolvedores novas oportunidades de criatividade e

inovação permitindo-lhes centrarem seus esforços na construção de aspectos únicos

para suas aplicações sem se preocuparem com qual adaptador de monitor, placa de

som ou acelerador 3D está instalado no computador. E como o DirectX foi idealizado

para suportar futuras inovações de software e hardware, desenvolvedores e

consumidores podem estar certos de que eles continuarão a obter a melhor

performance possível de suas aplicações conforme a tecnologia for progredindo.

O DirectX permite um acesso melhorado aos aspectos avançados de hardware

de alta performance como aceleradores gráficos 3D e placas de som. Estas API’s

controlam as “funções de baixo nível”, inclusive aceleradores gráficos, tanto 2D

quanto 3D, suportam dispositivos de entrada como joysticks, teclados e mouse e

controlam a inclusão de som. As funções de baixo nível são implementadas pelos

componentes que fazem parte do DirectX: Microsoft DirectDraw®, Microsoft

Direct3D®, Microsoft DirectInput®, Microsoft DirectSound®, Microsoft DirectPlay®,

Microsoft DirectShow® e Microsoft DirectMusic®.

Antes do DirectX, os desenvolvedores de aplicações multimídia para Windows

tinham que adaptar seus produtos para que eles funcionassem bem em uma enorme
 90

variedade de dispositivos e configurações de hardware. O DirectX implementa uma

camada de abstração de hardware (HAL - “hardware abstraction layer”), que usa

drivers de software para a comunicação entre os programas de jogos e o hardware

do computador. Como resultado, o desenvolvedor pode usar o DirectX para escrever

uma versão simples do seu produto sem se preocupar com a grande quantidade de

dispositivos e configurações de hardware existentes.

O DirectX também fornece ferramentas que ajudam a obter a melhor

performance da máquina que está sendo utilizada. Ele automaticamente determina a

capacidade de hardware da máquina e então regula a combinação dos parâmetros

da aplicação. Com o DirectX, é possível executar aplicações multimídia que

requerem certos aspectos que o sistema não possua simulando dispositivos de

hardware através da camada de simulação de hardware (HEL – “hardware

emulation layer”), que fornece drivers de software que agem como hardware. Por

exemplo, um jogo DirectX que utiliza gráficos 3D pode rodar numa máquina que não

possua um acelerador 3D, pois o DirectX simula o serviço de uma placa 3D.

Os componentes do DirectX também fornecem aos criadores de hardware uma

plataforma flexível. Como ele acessa o hardware de um computador através dos

drivers de software, desenvolvedores de hardware podem criar drivers especiais que

asseguram a obtenção das vantagens em tecnologia de hardware.

7.2. OpenGL

OpenGL é definida como um software que faz a interface com o hardware

gráfico. Em essência, ela é uma biblioteca gráfica 3D que é extremamente portável e

muito rápida em computadores que possuam aceleradoras 3D. Com a biblioteca

OpenGL é possível criar gráficos 3D bonitos e elegantes com quase a mesma

 91

qualidade visual de uma renderização foto-realista. Ela usa algoritmos

cuidadosamente desenvolvidos e otimizados pela Silicon Graphics, Inc., um dos

lideres mundiais em gráficos e animação por computador.

OpenGL é um padrão relativamente novo que em apenas alguns anos já ganhou

vários seguidores. O predecessor do OpenGL foi a GL, da Silicon Graphics,

implementada para as estações IRIX, da mesma empresa. Estas estações foram

mais do que computadores com uma proposta geral, eles tinham um hardware

especializado e otimizado para manipular gráficos sofisticados. Esse hardware

fornecia a capacidade de se realizar transformações matriciais de maneira muito

rápida (um pré-requisito para gráficos 3D), suporte de hardware para buffer de

profundidade, além de outros aspectos. Quando a Silicon Graphics tentou portar sua

biblioteca em outras plataformas alguns problemas ocorreram.

O resultado dos esforços para resolver os problemas de portabilidade da GL

resultaram na OpenGL. A nova biblioteca ofereceria o poder da GL e seria aberta,

permitindo fácil adaptabilidade para outras plataformas e sistemas operacionais,

com sua primeira versão liberada no dia primeiro de julho de 1992

OpenGL é uma biblioteca gráfica mais procedimental do que descritiva. Ao invés

de descrever a cena e como ela deveria aparecer, o programador descreve os

passos necessários para obter uma determinada aparência ou efeito. Estes passos

envolvem chamadas a uma API altamente portável que oferece diversas

funcionalidades. Elas são usadas para desenhar primitivas gráficas como pontos,

linhas e polígonos em três dimensões. Além destas características, a OpenGL

suporta procedimentos para descrição visual, como iluminação, mapeamento de

texturas, transparências, dentre outros.

 92

A OpenGL não possui funções para manuseio de janelas, interação com o

usuário ou entrada e saída de arquivo. Cada ambiente (tal como Microsoft Windows)

tem suas próprias funções com essas finalidades e o acesso ao retorno gráfico

oferecido pela OpenGL é realizado através de drivers, cuja funcionalidade é prover

um contexto de renderização para a janela criada pelo programador.

7.3. Outras

Além das duas bibliotecas gráficas citadas, diversas empresas ou pessoas

desenvolveram suas próprias bibliotecas gráficas para uso em aplicações genéricas

ou específicas.

Tal é o caso das bibliotecas: a) RenderMan™, biblioteca de renderização da

Pixar; b) MesaGL™, um porte que implementa as funções da OpenGL para sistemas

linux, dentre outras.

 93

Capítulo 8. - Motores de Jogos

Do ponto de vista de programadores, um motor é uma ferramenta que permite

novos jogos serem construídos a partir das interfaces e funcionalidades que ele

provê, cabendo aos programadores implementar as peculiaridades de um jogo em

específico. Do ponto de vista de requisitos, espera-se que um motor assuma uma

série de tarefas e disponibilize uma série de módulos de fácil utilização e extensão

para cada novo jogo [43].

Motores são considerados peças chave no desenvolvimento de um jogo, pois

são os responsáveis pelo controle e processamento básico de todas as mídias

envolvidas em um jogo. O motor abstrai a complexidade da implementação de

módulos básicos do jogo e, assim, facilita o desenvolvimento permitindo que se

concentre os esforços de projeto nas questões lógica, visual e sonora do produto e

não em questões de codificação.

De acordo com Hodorowicz, L. [44], um motor bem projetado deve apresentar dois

módulos ou “fachadas” de comunicação: a) um módulo de abstração de hardware,

responsável por isolar todos os componentes que necessitam de acesso à

plataforma utilizada pelo usuário (hardware e sistema operacional) e b) um módulo

de abstração de software, responsável por prover as funcionalidades de alto nível do

motor para serem utilizadas nos projetos de jogos. Tais módulos podem ser

implementados em três camadas, sendo elas: a) camada de baixo nível,

responsável pela comunicação com o hardware e com o Sistema Operacional; b)

camada de médio nível, responsável pela integração e sincronização das mídias e c)

camada de alto nível, responsável por prover as funcionalidades essenciais para a

programação e/ou criação do jogo.

 94

Abaixo se encontra um estudo sobre motores de jogos 2D e 3D, bem como uma

análise entre os diversos motores disponíveis na Internet.

8.1. Motores 2D

Jogos 2D foram os pioneiros a utilizarem gráficos, porém, devido à arquitetura

dos computadores da época em que eles surgiram, eles eram implementados

utilizando-se linguagem de máquina de maneira a aproveitar eficientemente os

recursos providos pelo hardware.

Ao que os computadores foram evoluindo e tornando-se mais rápidos, os

desenvolvedores de jogos mudaram o processo de desenvolvimento utilizando

linguagens de mais alto nível, como o “C”, porém a metodologia de produção das

aplicações manteve-se inalterado e, a cada produto, a grande maioria do código

tinha que ser implementado novamente e o pouco que era aproveitado de projetos

anteriores devia sofrer alterações de maneira a funcionar corretamente no projeto.

Após algum tempo, os desenvolvedores perceberam que se fosse especificado

um conjunto de rotinas básicas para manipulação de imagens o processo de

produção se tornaria menos custoso, facilitando o trabalho dos programadores,

agilizando a finalização e comercialização do produto e tornando a empresa mais

lucrativa. Surgia então o primeiro conceito em motores de jogos.

Atualmente motores de jogos 2D compreende um conjunto de rotinas e scripts

para controlar os processos gráficos, sonoros, comportamentais e interativo das

aplicações, porém, os motores dessa categoria conhecidos são muito específicos,

servindo para a produção apenas de aplicações semelhantes, como é o caso do

SCUMM™ da LucasArts™, utilizado nos adventures gráficos: “Maniac Mansion”,

 95

“Indiana Jones and the Fate of Atlantis”, “Full Throttle”, dentre outros, da mesma

companhia.

8.2. Motores 3D

Motores de jogos 3D são uma extrapolação dos motores de jogos 2D, pois eles,

além de implementarem diversas características encontradas em motores 2D, como

desenho de gráficos 2D, sistemas de script e inteligência artificial, eles também

implementam as técnicas para renderizar gráficos 3D.

Apesar de apresentarem uma generalidade maior, os motores gráficos 3D

geralmente são implementados para aplicações com um objetivo específico,

geralmente apenas para ambientes abertos, fechados ou espaciais e

especificamente com um tipo de visão.

Existem diversos motores 3D disponíveis publicamente na Internet. Abaixo

apresentamos a análise de alguns dos motores.

1.41. Análise dos Motores

Com a popularidade da Internet e dos projetos de código aberto, diversos

motores de jogo com esse tipo de licença surgiram e estão disponíveis

gratuitamente na rede. Porém muitos foram desenvolvidos para projetos específicos

ou de maneira alheia aos padrões de software tornando-se, portanto, pouco

modulares.

No mercado existem alguns motores gratuitos desta natureza em

desenvolvimento, como por exemplo, o Genesis3D [45], o Crystal Space [46], o

Golgotha [47] e alguns outros comerciais voltados exclusivamente a atender

funcionalidades específicas: gráficos, personagens, sons ou modelagem física.

 96

De acordo com análises realizadas por Madeira, C. [48], foi reportado um conjunto

de problemas: arquiteturas não modulares; paradigma de orientação a objetos

ignorado em muitos aspectos; pouca documentação; pouca reusabilidade; baixo

desempenho e, em alguns desses motores, a não portabilidade, ou seja, foram

projetados para trabalhar com plataformas e/ou bibliotecas gráficas específicas.

Abaixo se encontra a análise dos três motores acima citados, uma análise do

motor de jogo Fly3D [49] e do Forge V8 [48], projeto desenvolvido na UFPe por

Charles Madeira, bem como uma análise comparativa do ForgeV8 com o presente

projeto:

1.42. Golgotha

O Golgotha foi projetado para ser um motor comercial, desenvolvido pela Crack

dot Com18 com o intuito de construir um jogo 3D homônimo, mas após dois anos de

desenvolvimento, devido ao esgotamento do prazo de lançamento do jogo e não

mais existir verbas para a continuidade, a Crack dot Com decidiu adotar os

princípios de software livre e liberou o código fonte do Golgotha para o público. O

motor é composto por um conjunto de bibliotecas, ferramentas para a construção de

cenários, e um exemplo de código da demonstração do jogo Golgotha. O motor

executa a renderização de cenários de ambientes abertos (terrenos limitados ou não

limitados) compostos por objetos (malha de polígonos) em seu formato proprietário.

Os seus cenários podem ser constituídos por terrenos em diversos níveis de relevo,

de modo que lagos, montanhas, e outras formações possam ser inseridos ao

ambiente. Os objetos móveis possuem capacidades de modelagem física

avançadas. Utiliza renderização em profundidade e apresenta como resultado um

18
http://www.crack.com
 97

desempenho excelente. Mas, em contraposição, não possui documentação, e sua

estruturação visa um jogo específico, causando uma grande dificuldade para a

reutilização das suas bibliotecas, além de apresentar uma padronização de código

bastante confusa.

As principais características do Golgotha são: mapeamento de texturas com

perspectiva de sombreamento; filtragem de texturas; renderização de paisagens;

uso de uma biblioteca de renderização portável com suporte a Glide 19, Direct3D,

OpenGL e rasterização por software; suporte a sons 3D; uso de plug-in para

importação/exportação de objetos 3D Studio Max, da Discreet [51]; editor de

cenários; uso de código portável para rede com suporte aos protocolos UDP e TCP;

interpretador LISP com coletor de lixo threaded; sistema de janelas com interface de

usuário portável; sistema de gerenciamento de texturas JPEG, e apontadores de

texturas 1024x1024 pelo uso de memória cache; LOD em terrenos; suporte a trilha

musical em formato WAV e MP3; histogramas e quantização de imagens;

otimizações em linguagem Assembly para rasterização por software em Pentium e

K6-3D; e código fonte em C/C++ que pode ser executado em Windows (DirectX,

Glide, software), Linux (Glide, OpenGL), e Mac (RAVE, Glide).

19
GLIDE: Graphical Library Integrated Design Environment, biblioteca gráfica precursora do DirectX.
 98

1.43. Crystal Space

Crystal Space é um software livre que consiste de um pacote de componentes e

bibliotecas que pode ser utilizado para a construção de jogos de computador 2D e

3D. Ele disponibiliza ferramentas para a construção de cenários, exemplos de

código que demonstram suas capacidades básicas, e uma boa documentação da

sua estruturação e utilização. Uma das principais características do Crystal Space é

que seus componentes e bibliotecas são, quando possível, independentes uns dos

outros. Todos os componentes são projetados para serem funcionalmente

independentes uns dos outros.

Da mesma maneira que o Genesis3D, o Crystal Space foi projetado inicialmente

para renderizar cenários de ambientes fechados com polígonos que apresentem

quantidade moderada de vértices e na versão atual ainda funciona desta maneira.

Mas, nas definições das etapas de projeto de versões futuras há a previsão de se

poder construir cenários abertos, e então renderizar terrenos externos não limitados.

As principais características do Crystal Space são: mapeamento de texturas com

perspectiva de sombreamento; mipmapping (5.2); precisão de sub-pixel e sub-

texel20; uso de portais para delimitação de áreas permitindo renderização seletiva da

geometria do ambiente; iluminação estática com sombreamento pré-calculado;

iluminação dinâmica colorida com sombreamento transparente e semitransparente;

espelhamento; suporte a árvores BSP (5.2); suporte a superfícies curvas; suporte a

correção de profundidade e neblina volumétrica colorida; sistema hierárquico de

detecção de colisão; teste de visibilidade baseado em z-buffer; suporte a sons 3D;

movimentação de objetos e scripts para controle da movimentação; malha de

20
Medidas e Precisões ao nível de coordenadas de tela e coordenadas de textura respectivamente.
 99

triângulos com preenchimento gouraud; suporte a LOD; suporte a DirectX para

Windows, OpenGL para Linux, BeOS, MacOS/9 , OS/2 e Windows, e Glide para

Linux e Windows; leitor para modelos do Quake II (MD2) e 3D Studio (3DS); suporte

a rede; e código fonte em C++.

1.44. Gênesis 3D

Genesis3D é um pacote de desenvolvimento que permite construir aplicações

gráficas 3D. Ele é composto de bibliotecas, ferramentas para a construção de

cenários, exemplos de código que demonstram suas capacidades básicas, e uma

documentação para ensino da sua utilização. O Genesis3D adota os princípios de

software livre, disponibilizando ao público o código fonte das suas bibliotecas e

ferramentas, com exceção de alguns módulos que são disponibilizados apenas em

bibliotecas de ligação dinâmica precompiladas (DLL's).

O Genesis3D foi inicialmente projetado para renderizar cenários de ambientes

fechados com polígonos que apresentem quantidade moderada de vértices. Ele

também pode ser usado para construir cenários abertos não extensos, mas com

diversas restrições, e várias precauções devem ser tomadas para a apresentação

destes cenários de forma correta. Genesis3D não é projetado para renderizar

cenários compostos de terrenos abertos não limitados, e nem para realizar

processamento de visibilidade (5.2) em velocidade satisfatória para geometrias

arbitrárias.

As principais características do Genesis3D são: mapeamento e animação de

texturas; uso de texturas translúcidas; morphing de texturas; sombreamento

dinâmico; iluminação em múltiplas cores; neblina; morphing de vértices; distorção de

superfícies aquosas em tempo real; espelhamento; suporte a detecção de colisão;

 100

processamento de visibilidade; suporte a simulação física de corpos rígidos

integrados; hierarquia e disjunção de personagens poligonais de malha maleável;

suporte a arquivos de animação do 3D Studio Max; suporte a LOD (5.2); uso de

portais para delimitação de áreas permitindo renderização seletiva da geometria do

ambiente; uso de renderização baseada em Direct3D (DirectX versão 6.0), Glide e

rasterização por software; sistema de scripting; editor de cenários; posicionamento e

atenuação de sons 3D; suporte a rede; e código fonte em C/C++.

1.45. Fly 3D

O motor de jogo Fly3D foi implementado por Fabio Policarpo com a assistência

do pesquisador inglês Allan Watt para promover o livro 3D Games Real Time

Rendering and Software Technologies [50] de autoria dos mesmos. Ele permite a

criação tanto de jogos 3D quanto de jogos 2D provendo uma interface gráfica de

configuração básica do jogo e plug-in’s para o software 3D Studio Max, da

Discreet™ [51] que realizam a exportação de objetos criados e modelados nesse

software para objetos no formato suportado pelo referido motor.

O livro apresenta teorias matemático-computacionais para o desenvolvimento de

sistemas de renderização em tempo real e um tutorial de como se utilizar o motor,

bem como o kit de desenvolvimento provido na instalação do mesmo.

O Fly3D foi desenvolvido utilizando-se a biblioteca OpenGL [41] para

renderização e módulos da biblioteca DirectX [42] para entrada de dados, exibição

de filmes (AVI’s), sonorização e suporte aos protocolos TCP e UDP.

A versão completa do motor (motor, SDK e código fonte) é obtida apenas através

da aquisição do livro [50], porém o motor e o kit de desenvolvimento, essenciais para

 101

a produção de um jogo, estão disponíveis em [49] e atualmente encontra-se na

versão 2.0 beta.

A versão atual apresenta as seguintes funcionalidades: Plug-in’s completos

direcionados para a produção; gerenciador de renderização BSP/PVS (5.2);

Shaders21 com até 8 passos; suporte a múltiplas texturas; Suporte de combinação de

registradores para efeitos de pixel, mapas de iluminação para geometrias estáticas;

neblina volumétrica com mapas de neblina; luzes de cores dinâmicas com

atenuação por distância; reprodução de vídeos AVI; reprodução de sons em MP3 ou

MIDI (3.2); renderização em texturas, com suporte a espelhos e portais; animação

de malhas através de morphing ou por esqueleto; diversos tipos de faces para

polígonos (5.1); LOD dinâmico (5.2); geração dinâmica de sombras; suporte a

multiusuário através da tecnologia cliente/servidor; suporte a som estéreo e 3D e

editor de scripts para os arquivos proprietários do motor.

1.46. Forge V8

Forge V8 é um projeto realizado por Charles Madeira [48] em sua dissertação de

mestrado na Universidade Federal de Pernambuco e teve como meta ser um motor

genérico e portável para jogos e aplicações multimídia, apresentando diversas

características essenciais a essas aplicações, como interface gráfica, sonorização,

inteligência artificial, simulação física, e suporte a rede, de maneira a possibilitar a

construção de aplicações 2D e 3D.

O Forge V8 propõe a construção de interfaces possibilitando a implementação

para os diversos modelos possíveis de maneira que o desenvolvedor possa

configurar a aplicação para o modelo que lhe convier, no intento de gerar

Funcionalidade específica de unidades de processamento gráfico de última geração que permite renderização
21

mais precisa e mais rápida.

 102

componentes e bibliotecas com um bom grau de independência, apresentando um

alto nível de integração para a produção de jogos e aplicações multimídia.

Ele foi proposto numa composição em três camadas, cujas responsabilidades

devem incluir desde os componentes que tratam problemas de baixo nível até os

que trabalham em alto nível. Sua estrutura pretende abstrair diversas das

dificuldades intrínsecas ao desenvolvimento de jogos e possibilitar uma maneira de

fácil utilização por disponibilizar modelo de acesso de alto nível. Esse modelo de

acesso é composto por classes que podem ser extendidas por aplicações

específicas e por métodos que podem ser utilizados para a execução de tarefas

implementadas pelo motor. As camadas do Forge V8 são: camada de sistema, de

gerenciadores e de aplicação. Uma abstração do sistema de camadas proposto,

bem como uma relação de acesso dos módulos de estão definidos pela Figura 22

seguida de uma descrição dos módulos de interesse para o projeto:

 103

Figura 22: Camadas e componentes do motor Forge V8

I. Dispositivos Gráficos: É o módulo mais complexo presente nos motores de

jogos devido à exigência cada vez mais alta na qualidade de imagens

renderizadas. Ele provê as funcionalidades oferecidas por bibliotecas gráficas,

tais como OpenGL ou DirectX, bem como permite que se especifique outras

bibliotecas gráficas, seja desenvolvidas para um projeto em específico ou

obtidas de terceiros, de maneira a prover as funcionalidades para

processamento de renderização.

Temporização: É responsável por fornecer informações relacionadas ao tempo

necessárias a sistemas de simulação e animações. Sua implementação é relativa ao

hardware e ao sistema operacional, porém, o ponto de acesso às funcionalidades

 104

oferecidas deve ser idêntico, independendo das configurações do computador em

que a aplicação está sendo executada de maneira a tornar o sistema portável.

Dispositivos de Entrada: Provê os serviços para entrada de dados de maneira a

criar uma interface de interação da aplicação com o usuário e serviços de respostas

a eventos ocorridos na aplicação, quando presentes no dispositivo de entrada como,

por exemplo, o force feedback. Da mesma maneira que o subsistema de dispositivos

gráficos, ele provê os serviços fornecidos por bibliotecas de entrada, como o

DirectInput ou o SDL, e possibilita a configuração para prover serviços de outras

bibliotecas.

Gerenciador Gráfico: É responsável por gerenciar e controlar os componentes

utilizados nos aspectos visuais da aplicação. Dentre esses aspectos encontram-se

repositórios para dados de processamento visual, como janelas de visão, câmeras,

projeções, malhas, texturas, textos e iluminação, bem como uma instância do

renderizador, responsável por processar as informações visuais, obtidas do módulo

gerenciador de objetos, as quais serão enviadas através do módulo de dispositivos

gráficos.

Gerenciador de Objetos: É responsável pela representação e controle do ambiente

(mundo) e suas entidades (objetos e personagens). Esses dados devem ser

armazenados em uma estrutura de dados de maneira a controlar as referências

espaciais, permitir processamento de visibilidade e facilitar processamentos de

detecção de colisão. O gerenciador de objetos é uma máquina de estados que

indica o estado atual da aplicação de acordo com referências espaciais e

informações explícitas da aplicação.

 105

Gerenciador de Eventos: É o responsável por definir como os eventos, tanto de

entrada quanto os internos à aplicação, serão processados. Eventos como detecção

de colisão, de Inteligência Artificial e eventos gerados pelo gerenciador de

modelagem física são considerados eventos internos à aplicação, eventos como

dados de rede ou de dispositivos de entrada são considerados eventos externos à

aplicação.

Gerenciador de Modelagem Física: É o responsável por controlar as simulações

baseadas em física do jogo oferecendo, assim, a possibilidade de se produzir

aplicações com animações ou simulações realistas baseadas nas regras da física

mecânica (Dinâmica e Cinemática).

Devido à arquitetura genérica e à utilização de técnicas de engenharia de

software, o Forge V8 foi extensamente analisado para o desenvolvimento do projeto

que é o foco deste trabalho. Porém, devido a muitas funcionalidades do Forge V8

não terem sido definidas, o projeto foi desenvolvido utilizando-se alguns conceitos

dos módulos detalhados acima corrigindo e modificando-os de maneira a dar

continuidade a um projeto acadêmico na área.

 106

Capítulo 9. - Dados Inerentes a Motores de Jogos

Assim como todos os softwares, motores de jogo também necessitam de um

conjunto de estruturas de dados. Porém, devido ao grande tipo de informações

gerenciadas, a definição das estruturas de dados torna-se um desafio significante no

projeto.

O projetista deve definir estrutura de dados para todos os tipos de objetos

tratados no motor de jogo. Muitos desses objetos possuem, contextualmente, o

mesmo significado, porém suas estruturas podem diferir acentuadamente. Tal é o

caso das definições da ambientação do mundo que, como já citado, pode ser

fechado, aberto, de espaço sideral ou misto, porém eles representam a mesma

contextualização no desenvolvimento do jogo: o ambiente.

Abaixo definimos alguns tipos de dados básicos já identificados, no que se refere

a motores de jogos quanto a gráficos e animações, tanto para os motores de jogos

2D quanto para os 3D e que serão trabalhados e avaliados durante o

desenvolvimento do projeto proposto. São eles:

9.1. Objetos Gráficos

Objetos gráficos constituem a estética de um jogo por computador e são os

responsáveis pelo conteúdo artístico das aplicações, seja ele bi ou tridimensional.

Esta seção descreve os dados relativos às estruturas de dados referentes ao

conteúdo gráfico em jogos e aplicações multimídia.

 107

1.47. Sprites

Sprite é uma estrutura de dados muito utilizada pelos jogos 2D. Consiste em um

conjunto de imagens ligeiramente modificadas, tal como no tradicional processo de

animação quadro a quadro (6.1), indexada por uma estrutura de lista circular e um

procedimento para definir qual será a próxima imagem a ser exibida de acordo com

a ação do usuário ou do sistema de IA. A imagem a ser exibida na tela é a indicada

pelo apontador. A Figura 23 exemplifica a estrutura abstrata de um Sprite

Figura 23: Estrutura de um Sprite

1.48. Objetos 3D

Em aplicações 2D os gráficos podem ser totalmente descritos através de sprites,

porém, em aplicações 3D os gráficos têm que ser transformados de um conjunto de

dados espaciais para um conjunto de dados de visualização. Essa transformação é

realizada pelo renderizador.

Gráficos 3D se encontram em duas categorias distintas: a) objetos não

articulados ou não deformáveis e b) objetos articulados ou malhas deformáveis.

Abaixo estão exemplificadas como as estruturas para essas duas categorias

podem ser representadas dentro de um motor de jogo:

 108

1.49. Objetos não articulados

Objetos não articulados ou não deformáveis constituem o conjunto de estruturas

básicas para um motor de jogo. Eles são formados através de uma especificação

simples, com uma malha única e um conjunto de atributos visuais, incluindo texturas,

comportamento perante iluminação, etc.

Atualmente a maioria das aplicações de renderização em tempo real utiliza

estruturas poligonais para representar os objetos. O (Capítulo 5) já discutiu como as

estruturas poligonais podem ser representadas levando em consideração os dois

tipos de representação para malhas poligonais, porém é possível que se utilize uma

estrutura paramétrica para a definição dos objetos.

Malhas poligonais são compostas pelo tipo de primitiva a ser usada na

renderização, pelos vértices que formam o modelo 3D e podem conter um conjunto

de faces, caso os vértices não estejam ordenados.

Dessa maneira, para objetos poligonais, existem duas possíveis estruturas de

dados para sólidos 3D, as quais podem ser facilmente representadas em um

framework e compartilham os métodos de descrição dos dados objeto e do tipo de

primitiva a ser usado, porém, não compartilham como os dados do objeto serão

enviados ao pipeline geométrico. Podemos, portanto, representar os objetos

poligonais através de uma classe abstrata e duas classes herdadas, para que eles

sejam processados pelo renderizador.

Objetos formados por uma estrutura paramétrica são definidos através de uma

função unidimensional ou bidimensional de maneira a criar curvas ou superfícies,

respectivamente. Elas podem ser representadas de maneira analítica, isto é, através

de uma função matemática ou através da interpolação de um conjunto de dados [52].

 109

Apesar da estrutura desse tipo de malha ocupar pouco espaço em memória,

muitas placas gráficas não suportam o processamento direto desse tipo de

representação, o que requer algoritmos de geração de malhas poligonais e,

conseqüentemente, impede a implementação de classes abstratas para esse tipo de

representação de objetos.

Essa representação é muito útil para implementar terrenos a serem renderizados

ou curvas que podem servir de parâmetros para caminhos ou orientação em

métodos de animação pré-programada.

Portanto, objetos gráficos com estrutura paramétrica devem possuir um método

de geração de malha de acordo com uma função paramétrica definida pelo

programador exigindo, portanto, uma estrutura de classe abstrata.

1.50. Objetos Articulados ou Deformáveis

Esse tipo de estrutura é uma extensão à dos objetos não articulados,

representados por malhas poligonais ou por estruturas paramétricas. Essas

estruturas são combinadas através de um conjunto de transformações e

representação hierárquica para formarem esse conjunto de objetos. Existem, pelo

menos, quatro estruturas para definir os objetos articulados ou deformáveis, são

elas:

I. Articulação por composição de objetos não articulados: reúne em um

único objeto diversas malhas que possuirão uma regra para a articulação,

geralmente definida por um modelo de animação hierárquica (6.3);

II. Deformação por Morphing: formada por mais de uma malha que são

referenciadas em diferentes espaços de tempo e cuja animação depende da

interpolação de posições dos vértices fazendo com que animações desse tipo
 110

de objeto sejam fáceis de serem criadas, porém, custosas devido ao grande

número de vértices requeridos exigindo, portanto, muita memória [53];

III. Articulações e deformações por esqueleto, que são animações de uma

malha por meio da associação de deformações através de objetos não

renderizáveis denominados ossos ou controladores (6.3) e

IV. Deformações por sistema elástico, criado através de um conjunto vértices

que estão conectados aos vértices vizinhos utilizando-se de uma regra física

através das leis de elasticidade de maneira a produzir efeitos avançados, como

simulação de tecidos [54].

1.51. BillBoards/Impostors

Billboard é um objeto planar que possui uma regra de posicionamento definida de

acordo com a câmera de visualização. Normalmente a regra de posicionamento diz

que a face do objeto (o vetor normal do objeto) está na mesma direção da normal da

câmera, porém no sentido contrário. A direção da normal do billboard pode ser

restrita a alguns eixos ou sem restrição alguma. Geralmente é associada uma

textura, animada ou não, aos billboards de maneira a tornar uma cena mais realista

sem um alto custo computacional. Os principais usos para essa estrutura são para

objetos naturais, como árvores, pedras ou estandartes ou para objetos que simulem

neblinas ou fumaças [11].

A Figura 24 demonstra uma cena com diversos billboards texturizados para

representarem árvores.
 111

Figura 24: Billboards como árvores em uma cena.

Impostors funcionam exatamente como os billboards, porém a imagem associada

a ele é renderizada no início da execução do sistema e armazenada em uma base

de dados para utilização posterior.

1.52. Terrenos

Apesar de muitas vezes serem representados por malhas poligonais ou objetos

paramétricos, os terrenos possuem um conjunto de propriedades próprias em uma

aplicação de jogos por computador.

Devido à sua estrutura ser muito ampla, ela deve ser quebrada em diversas sub-

estruturas de acordo com uma regra de particionamento do espaço de maneira a

limitar o número de vértices a serem enviados ao pipeline de geometria tornando,

assim, a renderização mais eficiente.

Para estruturas de terrenos podemos explicitar três categorias de representação,

cada uma com suas vantagens e desvantagens, as quais estão analisadas abaixo:
 112

I. Voxel

Voxel é o acrônimo para volumetric pixel, uma técnica para representar objetos

3D por uma definição que não seja através das primitivas geométricas, mas sim

através de um número de pontos. Voxel pode ser a largura de um pixel na tela, uma

grande esfera ou qualquer outro formato desejado para um ponto [55].

A Figura 25 demonstra uma imagem 3D gerada a partir de um mapa de altitude

através da utilização de voxels.

Figura 25: Terreno gerado a partir de mapa de altura e técnica de voxel.

Por não ser representado através de primitivas geométricas deve-se processar a

estrutura dos voxels de maneira a enviar dados de primitivas geométricas para o

pipeline de geometria.

Esse procesamento pode ser realizado de 4 maneiras diferentes: a)considerando

todos os pontos vizinhos ao dado processado; b) considerando apenas os pontos

vizinhos na horizontal e vertical ao dado processado; c)considerando apenas os

pontos vizinhos diagonais ao dado processado e d)considerando o valor do dado

processado como um valor de altura.

Os métodos que consideram os pontos vizinhos possuem custo computacional

mais alto, porém a qualidade gráfica produzida é mais realista, enquanto que o

método que considera o valor do dado como um valor de altura possui custo
 113

computacional baixo, mas qualidade visual mais baixa devido à apresentação de

descontinuidade no terreno (efeito escada).

II. Paramétricos:

Terrenos paramétricos são gerados através de estruturas gráficas que possuem

representação paramétrica e são classificados em duas categorias: Malhas

Paramétricas ou Voxel Paramétrico.

A estrutura de terreno por malha paramétrica é idêntica à descrita no item 5.1 e

sua vantagem é o reduzido número de dados para representação, porém o

processamento para gerar os dados geométricos a serem enviados ao pipeline de

geometria pode ser custoso. Exemplos de terrenos por malhas paramétricas são

terrenos gerados por superfícies NURBS ou por superfícies Bezièr.

A estrutura do terreno por voxel parametrizado estabelece que uma imagem é

gerada por um conjunto de parâmetros e em seguida é referenciada como uma

estrutura de voxel. A vantagem dessa estrutura é que ela pode ser pré-processada e

utilizada como voxel em tempo de execução. Exemplos de geração paramétrica de

textura é através da utilização do Ruído Perlin [56] ou da geração de uma imagem

bidimensional através de fractais.

III. Fractais:

Fractais [57] possuem uma definição matemática precisa e de acordo com Ebert

[58], a definição de fractais, em computação gráfica, foi extendida para referenciar

geralmente estruturas com alto grau de similaridade própria, onde sub pedaços de

um objeto parecem ser o próprio objeto, porém numa escala e orientação diferente.
 114

Fractais têm sido usados em computação gráfica para representar objetos do

mundo real que exibem essas características, tais como montanhas, ilhas, plantas e

terrenos.

A maioria dos algoritmos de geração de terrenos por fractais trabalha através de

subdivisões recursivas e perturbações pseudo-aleatórias, onde novos vértices são

adicionados com um deslocamento pseudo-aleatório com magnitude de

deslocamento menor a cada interação.

Para terrenos gerados por fractais os únicos dados requeridos são: parâmetros

para controlar o gerador de números pseudo-aleatórios; o nível de subdivisão e a

“rugosidade” da superfície podendo, portanto, ser implementado em uma classe

concreta.

1.53. Texturas

Textura pode ser considerada como um dos objetos primitivos em um jogo 3D.

Ela consiste simplesmente em uma imagem bidimensional que pode ser

armazenada nos formatos BMP, JPEG, GIF, etc.

Por ser uma imagem bidimensional há a possibilidade de que uma textura possa

ser animada, seja por inserção de vídeo ou por meio da estrutura de sprites onde o

ponteiro para a estrutura da imagem é o ponteiro para a imagem atual do sprite.

As texturas geralmente são associadas a objetos formados pelas primitivas

geométricas através de um processo que modifica a aparência da superfície do

objeto em cada localidade utilizando alguma função de imagem ou outro conjunto de

dados.
 115

Abaixo se detalha as classes de texturas necessárias para a criação de um motor

genérico de jogo, as quais serão utilizadas para a criação de classes abstratas no

framework proposto neste trabalho.

1.54. Estáticas

Texturas estáticas são imagens cuja estrutura e conjunto de dados não são

modificados de acordo com o tempo.

Elas podem ser representadas através de uma matriz bidimensional de cores

com algumas regras de aplicação, tais como nível de transparência e podem ser

geradas previamente à especificação do sistema, carregadas antes da execução do

sistema ou automaticamente geradas na configuração da aplicação.

Abaixo se detalha os dois tipos de texturas estáticas determinadas em aplicações

3D, bem como suas possíveis aplicações:

I. Pré-Definidas: São imagens geradas por um artista, obtidas por um scanner ou

geradas por um programa de computador. Elas existem no sistema como

arquivos para serem carregados ou como um conjunto de dados especificados

como matriz dentro do código do programa. Sua utilização se restringe a alterar

o aspecto visual dos objetos 3D de maneira a fornecer-lhes mais detalhes

visuais ou para a criação de terrenos utilizando o método de voxel.

II. Matematicamente Geradas: Como o próprio nome diz são imagens geradas

utilizando-se um conjunto de regras matemáticas de maneira a serem aplicadas

como texturas. Dois exemplos de métodos para geração desse tipo de textura

são: a) Fractais, muito utilizados para a geração de terrenos, árvores, ilhas, etc.

e b) Ruído Perlin, muito utilizado na geração de terrenos, texturas de nuvens,

fumaça, etc.
 116

1.55. Animadas

Texturas animadas, ao contrário das estáticas, devem ser controladas pelo

sistema e geradas ou ter sua referência mudada em tempo real, pois elas possuem

uma característica temporal.

Exemplos de aplicações a utilizarem texturas animadas são vídeos, jogos 2D

utilizando bibliotecas 3D e na geração de imagens paramétricas:

I. Vídeo: Vídeos são a aplicação mais simples em textura animada, pois eles

possuem uma organização linear e temporal previamente definidas. A

complicação está na obtenção dos quadros, pois para cada tipo de arquivo de

vídeo existem diversos conjuntos de tipos de codificação, o que impede a

definição de classes concretas para esse tipo de dados, portanto, em um

framework, o uso de classes abstratas se faz necessário.

II. Sprites: Por serem imagens bidimensionais sprites se tornam um alvo

relevante para aplicação em texturas. Eles possuem uma estrutura bem

definida e podem ser facilmente representados em classes.

III. Imagens Paramétricas: Imagens paramétricas diz respeito a texturas

matematicamente geradas em tempo real em função do tempo. Uma boa

aplicação para esse tipo de textura seria o efeito de fogo ou de plasma, porém

essa estrutura matemática nem sempre é trivial, o que requer a composição de

um algoritmo específico em classes com essa natureza.

 117

1.56. Dinâmicas

Texturas dinâmicas são texturas geradas em tempo real através da utilização do

próprio sistema de renderização.

O renderizador gera a imagem no buffer de fundo, o qual é aplicado a uma

imagem para ser utilizada na cena. Esse buffer renderizado não é exibido ao

usuário, ao contrário, é realizada uma segunda renderização para exibir a cena ao

usuário aplicando a textura gerada em algum objeto visível.

A utilização prática para texturas dinâmicas é a renderização de espelhos, portais

ou objetos reflexivos, como objetos cromados.

Esse tipo de textura deve realizar uma chamada ao renderizador utilizando a sua

posição central como centro da câmera e um vetor de direção na mesma direção da

câmera do ponto de visão do usuário, porém com sentido inverso de maneira a gerar

a imagem no sentido oposto do usuário/jogador. Ao renderizar a cena, o

renderizador sinaliza a finalização do processo ao objeto de textura dinâmica, o qual

captura a imagem do buffer traseiro e sinaliza à aplicação para continuar o processo

normal de renderização.

Para impedir que a renderização normal não se perca, é ideal que todo esse

processo de renderização para as texturas dinâmicas se dê antes da renderização

da cena.

9.2. Objetos Empíricos

Objetos empíricos não são visíveis ao usuário, mas modificam a cena ou objetos

de maneira a alterar a estrutura visual da cena, a forma, posição ou orientação de

objetos ou ainda, de fornecer a regra de visualização da cena.

 118

Esses objetos são os mais difíceis de se definir em uma aplicação, pois apesar

de suas características serem previsíveis, elas não podem ser analisadas

imediatamente, como no caso dos objetos gráficos.

Por exemplo, um objeto de iluminação (luz) altera a luminância e a cor de uma

superfície, porém é difícil saber se a alteração está correta, pois o desenvolvedor

pode não ter certeza das características desejadas, ou pode pensar que o modelo

se encaixa nas características desejadas e em um certo momento da execução

ocorrer algum artifício visual devido à configuração errada do objeto.

Abaixo descrevemos os objetos empíricos analisados para compor o projeto

inicial do framework, bem como suas aplicações:

1.57. Sistema de Partículas

Partículas são objetos que possuem posição, massa, velocidade e que

respondem à ação de forças, porém não possuem extensão espacial e, apesar de

sua simplicidade, partículas podem ser úteis para uma ampla variedade de

aplicações, como, por exemplo, a construção de malhas não rígidas através de uma

malha de partículas conectadas utilizando uma lei elástica.

Um sistema de partículas é uma coleção de pontos independentes que são

estimulados por um conjunto de regras com a intenção de modelar determinado

efeito. Tem, portanto, como objetivo representar e simular alguns dos fenômenos

que ocorrem no mundo real tais como a chama de um fogo, o choque de uma bola

com uma parede, a explosão de um objeto ou um conjunto de vértices conectados

por uma regra elástica [59].

No exemplo citado, o objeto que representa uma malha formada por partículas

conectadas através de uma lei elástica deve gerenciar o comportamento das

 119

partículas através da lei da física responsável por elasticidade. Existem diversas

representações para esses modelos, tais como molas, cordas, tecidos ou objetos

não rígidos, como gelatinas.

Por não ter uma representação única, sistemas de partículas devem ser

representados através de classes abstratas com uma conexão às classes referentes

ao simulador de física para definir as leis aplicadas às partículas que ele gerencia.

1.58. Controladores (ossos)

Controladores são objetos empíricos responsáveis por alterar a estrutura dos

vértices de um objeto. A eles são associados conjuntos de vértices que serão

deformados de acordo com sua posição e orientação, baseado num sistema de

coordenadas próprias de cada controlador.

Controladores podem ser modelados em uma estrutura hierárquica definindo o

esqueleto de um objeto como, por exemplo, o esqueleto humano que, aplicado a

uma malha que representa um humanóide pode gerar animações de malha maleável

de maneira simples.

O renderizador, ao renderizar um objeto associado a um ou mais controladores,

deve chamar um método do controlador para alterar a estrutura ou forma da malha

antes de processar seus vértices através de primitivas geométricas para a

renderização.

O procedimento para esse tipo de algoritmo é dado a seguir:

 120

n n
V ' = ∑ wi M iV , com ∑w i = 1 , onde
i i

V’: Vértice transformado;

V: Vértice da malha Original;

n: Número de controladores associado ao vértice;

M: Matriz de transformação do controlador i;

w: Peso da transformação do controlador i associado ao vértice V [60].

O processo de alteração da malha através de controladores é conhecido como

skinning e as operações realizadas nos vértices é denominada de combinação de

vértices (vertex blending).

1.59. Iluminação

Os objetos de iluminação são os responsáveis por alterar as características

visuais dos objetos gráficos.

O processo de iluminação, também denominado de sombreamento, requer que

se determine, para cada pixel processado, a cor da luz refletida em direção ao

visualizador. Essa cor depende das propriedades das fontes de luz (objetos de

iluminação) que iluminam as superfícies assim como das propriedades reflexivas

das próprias superfícies.

A interação entre luz e superfície é um processo físico complexo. Fótons podem

ser absorvidos, refletidos ou transmitidos quando atingem a superfície de um

material [61].
 121

Modelar essa interação utilizando-se dos atuais conhecimentos em física é um

processo computacionalmente alto, por isso deve-se definir modelos que se

aproximam dos modelos físicos de maneira adequada.

Muitos desses modelos aproximados estão implementados nas placas gráficas e

são referenciados através das bibliotecas gráficas atuais.

Objetos de iluminação podem ser classificados em duas categorias distintas:

objetos empíricos, que descrevem o comportamento de uma fonte de luz e objetos

concretos, que possuem uma representação gráfica a ser mesclada com a

aparência padrão do objeto:

1.60. Empírica

Iluminação empírica descreve como uma fonte de luz atua no ambiente através

de seus componentes de iluminação ambiente, difusa e especular.

Esses componentes são, então combinados e processados para atuar no

ambiente em todas as direções ou em uma direção com uma limitação de

espalhamento através de um cone de iluminação (spotlight).

Os componentes de descrição da luz são formados através de uma tripla

representando os componentes principais das cores, no formato vermelho, verde e

azul (RGB).

Objetos empíricos de iluminação não são renderizáveis. Eles somente são

percebidos se há algum objeto no ambiente cuja aparência visual é afetada pelos

“raios de luz” provindos dessa fonte de luz.

Os raios de luz, ao atingirem a superfície do objeto por esse modelo de

iluminação, são combinados com as características de refletividade ambiente, difusa

 122

e especular do objeto, e, a cada posição do objeto, a cor final do pixel a ser exibido

na tela é calculada de acordo com a posição da câmera e da fonte de luz.

Esses objetos possuem, também, informações sobre a atenuação da luz de

acordo com a distância, posição (local ou no infinito) e, caso seja uma spotlight

possui também informações sobre direção, área de penumbra e ângulo de corte [62].

1.61. Mapas de Iluminação

De acordo com Miller [63], mapeamento de iluminação (lightmapping) pode ser

descrito como o processo de se utilizar um mapa de luz, essencialmente o mesmo

que uma textura padrão, para armazenar informação sobre iluminação para uma

superfície.

Mapas de luz são armazenados em uma resolução menor que as texturas

convencionais, tipicamente: 32x32 ou 64x64 e são combinados com a textura da

superfície através de um processo conhecido como convolução, calculado tanto em

tempo de renderização, caso a aceleradora gráfica permita, quanto em tempo de

configuração do sistema, através de um sistema de caching obtendo um resultado

semelhante ao demonstrado pela Figura 26.

* =

Figura 26: Exemplo de um LightMapping

Aplicações que utilizam o sistema de mapeamento de iluminação produzem um

resultado melhor do que as que utilizam apenas textura, porque essa técnica cria um
 123

senso de profundidade devido à utilização de mapas de luz que podem ser usados

para a geração de sombras.

1.62. Estática

Mapas de iluminação estática são obtidos através de uma imagem,

representando a função de iluminação a ser aplicada na superfície e de um vetor

normal ao plano da superfície a qual o mapa de iluminação será aplicado.

Dessa maneira um mapa de iluminação estático contêm uma imagem

bidimensional e necessita, para o processamento, apenas do vetor normal do plano

da superfície a ser aplicada de maneira a realizar o cálculo das coordenadas de

textura a aplicar nessa superfície.

1.63. Dinâmica

Como mapas de luzes utilizam uma estrutura semelhante às das texturas, pode-

se utilizar animação na descrição da imagem aplicada a ela de maneira a criar

efeitos como flickering, iluminação estroboscópica ou estruturas de iluminação

controlada.

Dessa maneira, cada objeto associado por um mapa de luz dinâmico irá

instanciar seu próprio objeto de mapa de luz de forma a permitir que eles possam

ser controlados independentemente. Devido à instanciação ter a possibilidade de

ocorrer em tempo de execução o objeto também deve calcular as coordenadas de

textura da superfície a que ele será aplicado em tempo de execução, o que pode

consumir tempo caso o processo de aplicação de mapas de luz não seja suportado

pela aceleradora gráfica.

 124

Como podem existir diversos tipos de iluminação dinâmica de mapas de luz além

dos três acima citados, a estrutura de definição de mapas de luz dinâmica não pode

ser previamente definida, devendo ser representada por uma classe abstrata a ser

herdada no projeto de um sistema.

1.64. Grafo de Cena

Organizar uma cena com transformações, principalmente quando essa cena

envolve hierarquia de objetos e alguns desses objetos estão se movendo envolve

conceitos relativamente complexos que necessitam ser sistematicamente

organizados de maneira a criar uma cena bem sucedida [52]. Isso se torna ainda

mais difícil quando a câmera é um desses objetos, ou um objeto dentro de uma

hierarquia, que se movem.

Sistemas gráficos recentes, tais como Java 3D e VRML2, implementaram um

conceito denominado de grafo de cena, uma poderosa ferramenta tanto para a

modelagem de cena ou objetos quanto para organizar o processo de renderização

desses objetos.

Objetos de cena são, portanto, estruturas de dados em forma de árvore que

abstrai toda a complexidade da cena através do agrupamento de nós de

transformações e de malhas podendo, também, possuir nós de comportamento

visual.

Sua estrutura define um objeto raiz, denominada cena, que conterá os objetos de

ambiente, denominado de mundo e os objetos gráficos que se situam nesse

ambiente.
 125

Cada objeto gráfico pode, por si só, ser um sub-grafo de cena, representando

uma modelagem hierárquica através de composições de malhas e conjuntos de

transformações, como demonstrado na Figura 27:

Figura 27: Representação de um grafo de cena

A cena tradicionalmente possui duas divisões: sub-árvore de visualização e sub-

árvore de conteúdo. A sub-árvore de conteúdo contém os objetos gráficos que

compõe a cena, enquanto que a sub-árvore de visualização contém as

transformações realizadas sobre uma câmera que será responsável por selecionar e

retornar os objetos visíveis pertencentes à cena para a renderização.

Como, para aplicações de jogos, o ambiente pode ser considerado um objeto à

parte, devido à sua extensão, definimos, portanto, três tipos de nó para o sistema: a)

nó de mundo, o qual possuirá uma regra de partição para diminuir o conteúdo

geométrico processado; b) nó de conteúdo, que conterá todos os objetos de jogo e

 126

suas respectivas transformações e c) nó de visualização, que conterá as

transformações realizadas sobre a câmera para visualizar a cena.

1.65. Câmeras

Câmeras são objetos não renderizáveis responsáveis pela projeção da cena na

janela de visualização. Elas representam a visão do jogador e, apesar de ter uma

estrutura simples, definindo sua posição, orientação e volume de visão, as câmeras

são de importância fundamental em um jogo por computador por definir o tipo de

visualização que o jogador terá do ambiente. É através da câmera que se define se

a visualização do jogo será em 1a. ou em 3a. Pessoa, o que também define, de

acordo com o contexto do jogo, se o jogo será ou não bem aceito pelos usuários.

Existem, basicamente, três tipos de câmeras:

1. Estática: Toda e qualquer interação realizada pelo usuário não irá alterar o

posicionamento e orientação da câmera. Um exemplo de aplicação com esse

tipo de câmera é o jogo Vertrix 2, da The Clusters [64];

2. Dinâmica sem associação: A interação do usuário altera a posição ou orientação

da câmera no grafo de cena, porém essa alteração não influencia em nenhum

objeto gráfico pertencente ao grafo de cena, como exemplo encontra-se o jogo

Warcraft III, da Blizzard entertainment e

3. Dinâmica com associação: A interação do usuário altera a posição ou orientação

de um objeto na cena, o qual, por sua vez, altera a posição ou orientação da

câmera caso esta esteja associada a ele, o jogo Tomb Raider, da Eidos

Interactive é um exemplo de aplicação com esse tipo de câmera.

 127

1.66. Janelas de Visualização (ViewPorts)

Janelas de visualização, no contexto da computação gráfica, são estruturas de

renderização na tela definidas pelo programador de maneira a renderizar diferentes

visualizações da cena na tela.

Com esse objetivo o motor de jogo deve ser capaz de criar janelas de

visualização de modo a prover mais realismo a uma cena. A cada janela de

visualização deve ser associada uma câmera de modo a renderizar mais de uma

parte do mundo na tela.

Um exemplo para aplicação de janelas de visualização é em simuladores

automobilísticos, onde se pode criar uma janela de visualização na área dos

retrovisores e associar câmeras que apontam para a parte traseira do veículo

utilizando uma mesma representação da cena. Dessa maneira conseguimos simular

eficientemente a visualização de um retrovisor no simulador.

O resultado de uma janela de visualização pode ser aplicado a uma textura,

objetivando criar uma textura dinâmica (9.1), de maneira a realizar processamentos

complexos no sistema, como renderização de portais ou de espelhos.

1.67. Renderizadores

Renderizador é o objeto básico para o processamento visual da cena. Ele é o

responsável por definir o que vai ser desenhado, e onde vai ser desenhado nas

coordenadas de janela.

O renderizador possui um conjunto de janelas de visão de maneira a constituir

toda a aplicação. O renderizador faz uma requisição a cada janela de visão para

retornar um conjunto de objetos visíveis e as propriedades da câmera associada a

 128

cada janela de visão de maneira a processar esses objetos com as matrizes de

modelo/visão e de projeção retornada pela câmera.

Cada janela de visão é renderizada na ordem em que foram atribuídas ao

renderizador e, portanto, o projetista deve levar essa propriedade em consideração

de maneira a não obter resultados errados na finalização de seu projeto.

No contexto do projeto desenvolvido o objeto de renderização (renderizador)

implementa apenas o estágio de aplicação do pipeline de renderização, responsável

por detecção de colisão, redução de complexidade geométrica, processamento de

visualização e formatação dos dados a serem enviados ao estágio de geometria.

 129

Capítulo 10. - Princípios de Engenharia de Software

De acordo com a engenharia de software, um framework é um conjunto de

classes que incorporam um projeto abstrato para a solução de inúmeros problemas

relacionados.

Por se tratar de projetos definidos pela engenharia de software, esse capítulo

descreve os termos da engenharia de software utilizados no decorrer desta

dissertação, detalhando princípios básicos de orientação a objetos e padrões de

projetos.

Elementos pertinentes ao padrão de documentação de sistemas de software, a

Unified Modelling Language (UML) está descrita na seção (10.4) deste capítulo,

concluindo com uma discussão sobre generalidade e segurança de tipos.

10.1. Princípios básicos da Engenharia de Software

Talvez a primeira regra da engenharia de software seja encapsular variáveis e

seus respectivos procedimentos de tal forma que apenas esses procedimentos

tenham acesso a essas variáveis. Ainda mais, acoplar dados e seus algoritmos

acompanhantes é um método de apresentação padrão para os presentes algoritmos

[65].

A seguir apresentamos a terminologia usada por demonstrar como cada conceito

poderia ser levantado de uma maneira evolutiva.

1.68. Instanciação

Considere o problema do sistema de partículas P que, ao ser acionado, retorna

um conjunto de partículas C com as características definidas por P. Imagine agora

que dois personagens de jogo possuam, cada um, uma arma, cada qual possui um
 130

sistema de partículas, P1 e P2, responsável por gerar os projéteis, C1 e C2, para as

mesmas.

Ao invés de declararmos esses sistemas de partículas como objetos globais no

sistema, o método ideal seria instanciá-los dinamicamente de acordo com o uso

liberando, portanto, memória da aplicação.

É possível realizar a instanciação utilizando um método procedural, porém esse

tipo de programação é apenas uma simulação de um conceito poderoso para uma

linguagem de programação simples. Para se reduzir a quantidade de esforço

necessário para realizar tal implementação deve-se utilizar uma linguagem de

programação orientada a objetos.

Em programação orientada a objetos o procedimento designado para se criar

uma coleção de estruturas de dados é denominado de construtor e essa estrutura de

dados dinamicamente alocada é denominada de instância de variável. Um número

arbitrário de construtores pode ser invocado, os quais, em cada invocação, criarão

estruturas denominadas de objetos.

Um objeto pode ser manipulado por uma coleção designada de funções ou

procedimentos denominados de métodos, funções membro ou operação. Um

método que retorna um resultado booleano é denominado de predicado.

1.69. Encapsulamento

Uma desvantagem do método acima descrito é que a coleção de funções

membro que operam em um objeto não foram agrupadas. Quando se projeta um

sistema extenso é importante agrupar métodos que operam em um tipo de dado

abstrato (TDA) em uma classe, cujo nome é o nome da TDA, consistindo na

 131

estrutura de dados que o representa, no construtor e nos métodos, os quais

determinam o comportamento da classe.

A vantagem principal desse sistema, denominado encapsulamento, é a ocultação

de informações, o que previne um programa de ser tão interdependente que

pequenas mudanças possam ter efeitos colaterais massivos no programa como um

todo [66].

1.70. Referências a objetos

Algumas linguagens de programação, como o C++, oferecem múltiplas formas de

se criar e referenciar objetos. Em um programa de xadrez, por exemplo, pode-se

definir um objeto r como uma instanciação da classe peao usando uma das duas

construções: peao *r = new peao(); ou peao r;, onde, no primeiro caso r é um

apontador para o objeto, enquanto que no segundo r é o nome do objeto.

A utilização de apontadores desperdiça espaço em memória, pois, para alguns

sistemas, são alocados quatro bytes extras para referenciar o endereço de memória

do objeto. Contudo, passar o objeto como referência para uma função simplesmente

requer a passagem de r como parâmetro, enquanto que no segundo método, apesar

de não se desperdiçar memória, é necessário todo um mecanismo para poder

passar o objeto r por referência.

10.2. Princípios de Orientação a Objetos

Projetos orientados a objetos têm apresentado sucesso na indústria de software

em geral devido a melhor qualidade oferecida as aplicações e por permitir a

construção de grandes sistemas mais gerenciáveis.[67].

 132

Uma razão para o sucesso do paradigma orientado a objetos é que ele utiliza um

modelo cognitivo, relacionado à maneira como pensamos. As funcionalidades de um

sistema podem ser corretamente particionadas em componentes e então

empacotadas, isoladas de outros subsistemas de um projeto, o que é difícil

conseguir com a programação procedural.

Os fatores de qualidade implicam na condução de propostas para a construção

de arquiteturas flexíveis, produzidas por componentes de software autônomos e

reusáveis (módulos). Componentes tem-se apresentado como uma excelente

técnica de desenvolvimento [67]. Na substituição de escrever um grandioso

componente de software (desenvolvimento monolítico), escreve-se um conjunto de

pequenos componentes que se comunicam entre si. Esta decomposição caracteriza

um bom grau de independência que pode ser aplicado a estes componentes, de

maneira que eles possam ser utilizados em diferentes projetos sem a necessidade

de ajustes, além da possibilidade de realizar modificações e testes também de forma

independente.

Estas técnicas aplicadas de forma ideal provêem componentes que podem ser

facilmente conectados para construir um novo sistema. Não é nada interessante que

todo novo desenvolvimento deva partir do início. Deve existir um catálogo de

componentes de software, como existem catálogos de dispositivos de hardware,

possibilitando a reutilização destes componentes, sem a necessidade de “reinventar

a roda”. Conseqüentemente, diminuindo a quantidade de código a ser construído, e

provavelmente gerando um resultado muito melhor [68].

A seguir são apresentados os principais conceitos e técnicas da engenharia de

software, relacionados ao desenvolvimento de projetos orientados a objetos, os

 133

quais podem ser largamente utilizados na construção de jogos de computador e

motores de jogos.

1.71. Modularidade

No desenvolvimento de um sistema de software, códigos que realizam uma

operação específica podem ser organizados em pacotes autônomos, robustos e

eficientes denominados módulos, projetados de maneira a serem extensíveis e

portáveis para serem facilmente integrados em outros sistemas.

Existem cinco critérios para auxiliar na caracterização da modularidade [67]:

a) Decomposibilidade: O problema deve ser decomposto em diversos

subproblemas de maneira que sua solução possa ser facilmente encontrada;

b) Composibilidade: O sistema suporta a produção de elementos de software

que permitem a produção de novos sistemas a partir da livre combinação dos

módulos;

c) Compreensibilidade: O sistema produz módulos que podem ser

compreendidos separadamente ou em conjunto com um pequeno número de

outros módulos;

d) Continuidade: Uma modificação necessária na especificação de um

problema resulta na modificação de um conjunto limitado, geralmente

pequeno, de módulos e

e) Proteção: O sistema apresenta uma arquitetura de tal forma que, em tempo

de execução, uma condição anormal em determinado módulo fique restrita a

ele. Estes critérios apontam para cinco princípios que devem ser seguidos de

maneira a atingir a modularidade [69];

 134

f) Unidade Linguística Modular: Módulos devem corresponder à unidade

sintática utilizada na estrutura do sistema;

g) Poucas Interfaces: Todo módulo deve se comunicar com a menor

quantidade possível de outros módulos;

h) Pequenas Interfaces: Caso haja a comunicação entre dois módulos, eles

devem trocar a menor quantidade possível de informações;

i) Interfaces Explícitas: Na comunicação os módulos devem se acoplar

diretamente, trocando informações restritas aos seus dados e aos dados da

função a ser executada e

j) Ocultar Informações: Toda informação de um módulo deve ser privada,

salvo o caso em que seja necessário declará-la como pública.

Módulos podem ser formatados de maneira aberta, permitindo extensibilidade

por acrescentar estruturas de dados ou funções para manipular esses dados em sua

estrutura ou podem ser formatados de maneira fechada, permitindo apenas o uso de

seus métodos ou dados, como um componente, apresentando uma interface estável

e bem definida [67].

1.72. Reusabilidade

Reusabilidade de software é o problema básico da engenharia de software, que

busca metodologias e características para a reutilização de problemas já

solucionados em vez de tentar buscar, novamente, a solução. Apesar de parecer

uma tarefa trivial, essa questão não tem uma resposta simples pois envolve vários

fatores [67].

Bibliotecas que apresentem um conjunto de características necessárias para o

desenvolvimento de um sistema podem ser encontradas, mas podem necessitar de

 135

licenciamento, adaptações ou apresentarem problemas que não podem ser

solucionados no espaço de tempo requerido, o que exige a necessidade de

implementação de componentes, os quais devem ser projetados de maneira que o

seu reuso seja maximizado, definindo duas formas de reusabilidade no

desenvolvimento de sistemas: Reusabilidade de código e reusabilidade de projeto

[43].

O reuso de código, apresentado nesta seção, é especificado para produzir um

conjunto de componentes e ferramentas que possam ser aproveitados no

desenvolvimento de diversos produtos e devem ser projetados de maneira a permitir

extensibilidade desde o início do projeto.

Devido à necessidade de expansibilidade, esse conjunto de componentes deve

ser construído de forma que possa ser liberado de maneira incremental, permitindo o

funcionamento parcial de um sistema.

Abaixo são apresentadas alguns problemas inerentes às estruturas modulares,

que devem ser resolvidos para produzir componentes reusáveis [67].

a) Variação de Tipos: Um módulo deve ser aplicado a estruturas diferentes de

tipos;

b) Variação em estruturas de dados e algoritmos: Como as ações

executadas durante um algoritmo podem depender do tipo da estrutura de

dados, o módulo deve permitir o direcionamento para variações de diversas

estruturas;

c) Rotinas Relacionadas: um módulo deve ter acesso às rotinas para

manipular as diferentes estruturas de dados;

 136

d) Independência de representação: Um módulo deve permitir ao usuário

especificar uma operação sem que ele saiba como ela foi implementada ou

qual a estrutura de dados utilizada e

e) Comunidade com outros subgrupos: Devem ser construídas interfaces

abstratas que não exponham estruturas de dados de maneira a permitir

diversas formas de implementação e garantir a não repetição de blocos de

códigos similares.

Um dos grandes feitos da comunidade de desenvolvimento de software, que tem

resultado num dos grandes métodos de reuso, tem sido o de reuso de projeto

através de padrões, formando um catálogo de soluções para diversos problemas de

projeto.

Devido à importância dos padrões de projeto e à utilização do mesmo no projeto

aqui apresentado, este se encontra numa seção à parte.

10.3. Reusabilidade de Projetos: Padrões de Projetos

Projetar software orientado a objeto é complicado e projetar software reutilizável

orientado a objeto é ainda mais complicado. Deve-se descobrir objetos pertinentes,

fatorá-los em classes na granularidade correta, definir as interfaces das classes, a

hierarquia de heranças e estabelecer relacionamentos chave entre elas. O projeto

deve ser específico ao seu problema, mas também geral o suficiente para resolver

problemas futuros, evitando a realização de um novo projeto ou, pelo menos,

minimizando-o [68].

Padrões de projeto torna fácil a reutilização de projetos e arquiteturas bem

sucedidas, ajudam na escolha de alternativas de projeto que tornam um sistema

reutilizável e evitam alternativas que comprometam a reutilização. Podem, inclusive,

 137

ajudar a documentar e manter sistemas existentes através do fornecimento de

especificações explícitas de classes e interações de objetos e suas intenções

podem, também, simplificar e ajudar o projetista a conseguir um projeto “correto”

mais rapidamente.

Cristopher Alexander, [70], analisou projetos de arquitetura e, através de

características comuns a alguns deles, montou um catálogo de padrões a serem

utilizados por engenheiros e arquitetos na construção civil, tornando-se o pioneiro na

área de reusabilidade de projetos e foi a base de referência para a área de

reusabilidade de projetos de software.

Segundo Cristopher Alexander, “cada padrão descreve um problema que ocorre

constantemente em nosso ambiente e descreve o núcleo da solução para tal

problema de uma maneira que se pode utilizar essa solução milhões de vezes sem,

sequer, fazer a mesma coisa duas vezes”.

Padrões de projeto são bastante populares na comunidade de orientação a

objetos devido a proverem a reutilização de informações de bons projetos [71].

Um padrão descreve um problema que ocorre em um ambiente e a sua solução,

realizada de uma maneira a ser utilizada infinitas vezes sem a necessidade de ser

reescrita [68]. As soluções são descritas através de objetos e interfaces e, em geral,

um padrão possui quatro elementos essenciais:

I. O nome do padrão é uma referência que se pode usar para descrever um

problema de projeto, suas soluções e conseqüências em uma ou duas

palavras;
 138

II. O problema descreve quando aplicar o padrão. Ele explica o problema em si e

o seu contexto e pode descrever problemas específicos de projeto tal como a

representação de algoritmos em objetos;

III. A solução descreve os elementos que compões o projeto, suas relações,

responsabilidades e colaborações, porém, não descrevem um projeto ou

implementação concreta em particular devido a padrões serem mais como um

modelo que pode ser aplicado a diversas soluções diferentes e

IV. As conseqüências são os resultados e os custos de se aplicar o padrão.

Embora conseqüências sejam freqüentemente ignoradas quando se descreve

decisões de projetos, elas são críticas para resolver alternativas de projeto e

para se entender os custos e benefícios da aplicação dos padrões.

Um padrão de projeto nomeia, abstrai e identifica aspectos chave de uma

estrutura comum de projeto que se torna útil para criar um projeto orientado a objeto

reutilizável através da identificação da participação de classes e instâncias, seus

papéis, colaborações e distribuição de responsabilidades.

1.73. Exemplo: Iterators

Considere um segmento de programa que adiciona elementos em uma matriz.

Seja A a matriz especificada, cujos índices variam de 0 a n-1. Em uma linguagem de

programação, como o “C” o segmento de código que faria isso seria semelhante ao

descrito abaixo:

for(i=0; i<n; i++)

Realize Adição
 139

Essa construção é tão abundante em programas que utilizam matrizes que se

torna conveniente que a linguagem de programação usada forneça uma construção

simples para iterar entre os elementos da matriz.

Iterar sobre matrizes é fácil, portanto, considere um exemplo em que tenhamos

que iterar sobre uma estrutura mais complexa, como, por exemplo, sobre os nós de

uma estrutura de grafo.

Um programa que lida com grafos consistirá de um grande número de

construções que lidam com tais iterações de tal forma que se torna conveniente

definir uma classe extra que torne o código mais legível e reduza as chances de

erros de programação.

O padrão de projeto Iterator [68] é uma construção útil para tais casos. Para

iterar sobre os nós de um grafo define-se uma classe denominada IteradorDeNo

com os métodos primeiro, seguinte, corrente e feito, onde, um cliente utilizando a

classe em uma estrutura de grafo G codificaria da seguinte forma:

for( IteradorDeNo n = new IteradorDeNo(G) ; !n.feito() ; n.proximo())

realiza iteração no nó

O código intencionalmente é parecido com o código para se iterar sobre os

elementos de uma matriz. A pequena sobrecarga que o padrão iterator requer é a

escrita do código para a classe IteradorDeNo de maneira concisa e livre de erros.

 140

10.4. Unified Modelling Language (UML)

Linguagens humanas são muito descritivas e verbais para serem utilizadas na

descrição de sistemas extensos. Devido a isso diversas linguagens gráficas de

descrição foram criadas, das quais, a indústria está utilizando intensivamente a

Unified Modelling Language (UML) [72], a qual está se tornando um padrão de fato.

Os principais componentes da UML são os diagramas de classe, os quais foram

utilizados para descrever o framework projetado.

Um diagrama de classes é uma representação esquemática do relacionamento

entre as classes de um sistema, representando um método conciso de descrição

entre as estruturas de dados e os métodos pertencentes a tal sistema.

Enquanto um diagrama de classes representa um método estático de descrição

de um sistema, diagramas de objetos representam os relacionamentos dinâmicos na

forma de objetos que existem em um instante de tempo.

Relacionamento entre classes é importante na construção de projetos orientados

a objeto e, devido a isso, eles estão definidos numa seção separada.

10.5. Relacionamento de classes

Nessa seção apresentamos três tipos principais de relacionamento de classes

utilizados intensamente no projeto.

1.74. Classificação e Herança

Quando um programa em linguagem procedimental cresce em tamanho durante

o desenvolvimento, o programador nota, eventualmente, algumas repetições de

código entre dois procedimentos. Ele normalmente move a parte comum dos
 141

códigos para um terceiro procedimento e realiza uma chamada de procedimento dos

dois lugares para realizar a funcionalidade comum.

1.75. Herança

Uma maneira de se extrair funcionalidades similares em programação orientada

a objetos é através da utilização do sistema de herança de classes.

Ao que o programa orientado a objetos cresce em tamanho durante o

desenvolvimento o programador, eventualmente, nota similaridades no código que,

no caso, podem ser tanto entre procedimentos ou entre variáveis. Uma linguagem

de programação baseada em objetos permite definir TDA's e instanciar múltiplas

cópias do mesmo. Em adição a múltiplas instanciações, as linguagens orientadas a

objetos permitem extrair as similaridades entre duas classes e definir uma terceira,

contendo essas similaridades onde, as duas classes a definir são derivadas da

terceira classe contendo a similaridade entre as duas, denominada de classe base.

Uma representação pictórica de um diagrama de herança está demonstrado na

Figura 28.

Um programador em linguagem procedimental que espera até que o código

explicite similaridades para poder realizar a extração em um novo procedimento irá

encontrar dificuldades não apenas por realizar uma análise e reestruturação do

código, mas também por realizar uma reestruturação no próprio projeto em si e, em

programação orientada a objetos essa dificuldade é amplificada. Porém o

desenvolvimento iterativo de programas consome tempo e gera um projeto pobre de

programas, o que gera a crescente necessidade de um corpo de conhecimento

substancial [73] [66] de se projetar o sistema antes de que qualquer linha de código

seja escrita.
 142

Antes da fase de implementação é necessário considerar as múltiplas opções de

projeto e avaliar cada uma cuidadosamente, assim como um engenheiro constrói e

consulta as plantas de projetos antes de ordenar aos trabalhadores de construção

realizar seu trabalho. Portanto, é importante alcançar um projeto estável antes da

fase de implementação.

É importante apontar a inadequação do número de linhas de código tanto como

uma medida da complexidade do sistema quanto do número de horas necessário

para desenvolvê-lo.

1.76. Classificação

Além da herança, uma tarefa importante durante as fases de análise e projeto de

um sistema é a classificação, a qual consiste na busca de similaridades entre as

diferentes abstrações, o que leva na identificação de classes, mas essa busca é um

processo inerentemente iterativo, pois nem as “bordas” das classes nem os tipos de

similaridades são conhecidos durante a fase de análise e o projetista procede por

iterar sobre diferentes escolhas.

O projeto adotado é apenas uma de muitas escolhas e Fowler [ 74] orienta a

manter uma documentação detalhada sobre os motivos da não escolha de um certo

projeto.

O processo de classificação em um projeto de sistema não difere do processo de

classificação de espécies [73], as quais possuem gênero, filo, classe, família, etc.

Assim como a lista de especialização que leva a uma espécie provê conhecimento

suficiente sobre a mesma, a lista de derivações sobre uma classe provê

conhecimento sobre a classe. Ainda mais, se a família da qual a espécie é derivada

for conhecida; o esforço para levantar as características dessa espécie é

 143

minimizado. Assim como nos projetos de sistemas, se a classe base da qual uma

classe foi herdada for conhecida; os esforços para identificar as características da

classe e implementa-la serão minimizados.

Um projetista de sistemas orientados a objetos tem a necessidade de identificar a

hierarquia das classes na medida em que as classes forem identificadas, o que leva

a separar as abstrações comuns a uma classe base e usar a herança para definir

duas ou mais classes derivadas. A coleção dessas classes base-derivadas gera o

diagrama de heranças.

1.77. Exemplo: pontos e vetores são tuplas

Suponha que um projetista deseje definir uma classe de pontos no espaço,

denominada de Ponto3d, a qual armazenará as coordenadas (X,Y,Z) para cada uma

das instâncias dessa classe. Ela também irá prover um construtor que receberá

essas coordenadas como parâmetros para instanciar e iniciar o objeto e três

métodos, cada um dos três responsáveis por retornar o valor de uma das

coordenadas. Em adição, a classe poderia prover um método, por exemplo,

“distancia" para retornar a distância entre dois pontos.

Suponha também que ele queira definir uma classe para representar vetores no

espaço, a qual será denominada vetor3d, a qual também necessita armazenar as

coordenadas (X,Y,Z) para cada instância da classe, o construtor e os três métodos

para retornar as coordenadas. Contudo a classe de vetor difere da classe de ponto,

pois faz sentido normalizar um vetor, porém, não faz sentido normalizar um ponto.

Para tirar vantagem da similaridade entre as duas estruturas definimos uma

classe denominada tupla3d que armazenará os valores das coordenadas e os

 144

métodos para retornar as coordenadas e definiremos as classes ponto3d e vetor3d

como classes derivadas da classe base tupla3d, como demonstrado na Figura 28.

Tupla3D
X
Y
Z

Tupla3D(X, Y, Z)
tX() : X
tY() : Y
tZ() : Z

Vetor3D
Ponto3D

prodVetorial(Vetor3D) : Vetor3D
translada(x, y, z)
ProdutoEscalar(Vetor3D) : Inteiro

Figura 28: Exemplo de Diagrama de Herança

1.78. Agregação

Relacionamentos de herança são relacionamentos fortes, no sentido de que eles

têm que ser identificados durante o processo de projeto e que é crítico que sua

identificação seja correta, pois erros de classificação são difíceis de serem

corrigidos.

Outro relacionamento importante entre classes é a agregação. Uma classe é dita

ser agregada a um conjunto de classes se todas as classes desse conjunto definem,

coletivamente, partes dessa classe. Exemplos de agregação são simples de serem

identificados se o domínio a ser modelado for físico. Podemos seguramente dizer

que uma bicicleta é um agregado de duas rodas, um quadro, um guidom, um

sistema de freio, etc. É seguro dizer também que o “The Art of Computer

Programming” do David Knuth é um agregado de três livros. Contudo, normalmente

será necessário criar um argumento para estabelecer um relacionamento de

agregação num domínio abstrato.

 145

Por exemplo, podemos modelar um polígono no espaço como um agregado de

três ou mais pontos. Na Figura 29, as classes de polígono e de ponto são ligadas

através de uma linha e a forma de um losango é adicionada ao lado da classe

polígono indicando que um objeto polígono é um agregado de objetos da classe

ponto. É também adicionada uma faixa de números próximos à classe ponto

indicando a cardinalidade de objetos ponto que formam um polígono.

Poligono 3.. Ponto

*

Figura 29: Relacionamento de Agregação: Um polígono é formado por três ou mais pontos

1.79. Associação

O tipo mais fraco de relacionamento entre classes e também o mais abundante é

o relacionamento de associação. Duas classes são unidas por esse relacionamento

se o objeto de uma classe interage com um ou mais objetos de outras classes.

Por exemplo, pode-se dizer que uma classe segmento, representando um

segmento de reta no espaço, está associada à classe ponto, representando um

ponto no espaço. Como um segmento de reta é definido por dois pontos, a

cardinalidade da associação segmento->ponto é de 2. Finalmente uma seta é

desenhada da classe segmento à classe ponto indicando que a associação é

unidirecional, ou seja, um objeto da classe segmento é capaz de identificar dois

pontos, porém um objeto da classe ponto não é capaz de identificar os objetos da

classe segmento que eles definem.

 146

seg mento +2 Ponto

Figura 30: Relacionamento de associação: segmento de reta é representado por dois pontos
 147

Capítulo 11. - Frameworks Gráficos

Quando se discute sobre o conceito de frameworks, dificuldades terminológicas

podem surgir devido à não existência de uma definição comum a framework e

devido à dificuldade de distinção de aspectos específicos de frameworks e aspectos

específicos de aplicações.

A melhor definição foi proposta por Johnson e Foote [75]: “um framework é um

conjunto de classes que incorporam um projeto abstrato para solucionar um conjunto

de problemas relacionados”. Em outras palavras, um framework é um projeto parcial,

com alguma implementação, para aplicações em um dado domínio de problema.

No presente caso, o domínio do problema é a apresentação de gráficos,

animados ou não, os quais foram analisados através de diversas ferramentas

(toolkits) de programação gráfica.

A idéia de frameworks foi desenvolvida nos laboratórios da Xerox no Centro de

Pesquisa de Palo Alto (PARC) pelo grupo Smalltalk e o primeiro framework

amplamente usado foi baseado no conceito modelo-visão-controlador (MVC) do

projeto utilizado no smalltalk-80 [76].

11.1. O Modelo MVC

O framework MVC é baseado em um modelo uniforme de representar objetos

gráficos interativos. Para se construir tal objeto são requeridos três componentes

denominados de visão, controlador e modelo, os quais são discutidos a seguir.

 148

1.80. O componente modelo

Objetos desse componente mantêm a informação do domínio da aplicação e

provê a interface que permite o acesso pelos controladores e visões.

Como gráficos dinâmicos e interativos devem responder a eventos de entrada

em tempo real, normalmente é impossível prever quando e em que ordem esses

eventos ocorrerão. Portanto, em qualquer momento durante a execução de uma

aplicação dinâmica, o estado deve ser explicitamente mantido em uma estrutura de

dados global.

Um exemplo comum desse princípio é o de simplesmente desenhar uma figura

gráfica na tela. Em bibliotecas gráficas tradicionais, o programador desenha um

círculo por chamar uma das rotinas de desenho de círculo, as quais tem o efeito

imediato de fazer um círculo aparecer na tela. Contudo, não há registros que o

círculo exista, então, em sistemas dirigidos a eventos, eventos subseqüentes podem

não ter conhecimento sobre o círculo e é o programador da aplicação quem deve

explicitamente tomar conta da manutenção dessa informação.

Em um sistema orientado a objetos um círculo é desenhado por primeiramente

criar um objeto círculo e colocá-lo na hierarquia gráfica e então realizar um comando

de redesenho. Dessa forma o estado gráfico do sistema é sempre conhecido de um

ciclo de evento ao próximo: cada figura visível na tela é um objeto pertencente a um

único banco de dados e todos os detalhes sobre a aparência do objeto são mantidos

como variáveis de estado dentro da própria estrutura de dados do objeto. Se a tela

precisa ser redesenhada o procedimento é apenas percorrer essas estruturas de

dados.
 149

Dessa maneira, uma estrutura bastante utilizada atualmente para prover a

funcionalidade de representação do modelo é o grafo de cena, que hierarquicamente

descreve toda uma cena tridimensional e ainda contêm estados visuais nos objetos

pertencentes à cena.

1.81. O componente visão

Esse objeto diz respeito a renderização e deve manipular rotinas para converter

os aspectos importantes do modelo para uma forma visível.

O objeto modelo é utilizado para organizar e manter as estruturas de dados das

aplicações de gráficos dinâmicos. Dessa maneira o objeto visão é responsável por

percorrer essas estruturas identificando os aspectos geométricos e visuais de

maneira a criar a imagem final a ser apresentada na tela do monitor.

Para gráficos dinâmicos os dois tipos de operações mais importantes são

implementar a aparência visual e o comportamento dinâmico dos diferentes tipos de

objetos gráficos. Uma questão importante de projeto é a da definição de onde

codificar a aparência gráfica e o comportamento dinâmico.

Em gráficos bidimensionais o código de aparência gráfica e de comportamento

dinâmico pode ser implementado em uma única classe como, por exemplo, um

objeto deslizador, para interface com usuário, possui um comportamento de, ao

deslizar, mudar o valor de um atributo associado a ele e de redesenhar sua

aparência numa nova posição. Porém, em aplicações mais avançadas, como jogos,

pode ser necessário implementar o aspecto visual e comportamental em classes

separadas, pois dois objetos podem possuir o mesmo comportamento, porém

aparências diferentes, como no caso dos personagens de um jogo.

 150

Outra questão importante a se levantar sobre o objeto de visão é onde

implementar o processo de renderização. Aplicações bidimensionais são simples de

serem portadas a outras plataformas ou bibliotecas gráficas, pois possuem poucos

atributos, favorecendo a escrita dos métodos de renderização desse tipo de objetos

no próprio modelo.

Porém diferentes bibliotecas para renderização 3D possuem diversas

características e funcionalidades que, na maioria das vezes, diferem tanto em

termos de representação quanto em quantidade de funcionalidades fornecidas e,

portanto, não é viável a implementação do método de renderização na própria

classe do modelo, exigindo uma classe separada para realizar uma interpretação

dos atributos geométricos e visuais para poder produzir a imagem final. Exemplos

podem ser reportados através de programas codificados em OpenGL e Direct3D.

1.82. O componente controlador

O objeto controlador implementa a dinâmica e provê os mecanismos que

interpretam os eventos de entrada como comandos e atualiza o modelo de acordo

com esses comandos.

Comportamentos animados e interativos estão entre os aspectos mais confusos

de projetos de computação gráfica e atualmente podem ser representados como o

problema fundamental de aplicações com gráficos dinâmicos: como modificar a

saída gráfica em resposta a entrada em tempo real?

Analisado dessa maneira a entrada de dados pelo usuário resulta num

comportamento interativo, enquanto que a entrada de dados por outras fontes ou por

temporizadores resultam em comportamento animado em tempo real.

 151

Ao contrário das entidades gráficas, as quais podem ser facilmente

representadas através de estruturas de dados, o comportamento dinâmico é mais

difícil de se visualizar e tende a necessitar de diversos algoritmos. Ainda mais, há

três diferentes técnicas para a obtenção de dados em tempo real: interrupção

assíncrona, polling e fila de eventos.

O desafio de se realizar dinâmica em projetos orientado a objetos está em como

projetar e codificar o comportamento de programas gráficos tão facilmente quanto

projetar e codificar sua aparência visual.

Uma solução geral para esse problema pode ser encontrada na metáfora

alvo/ação apresentada no gerenciador de janelas NextStep [77], onde os objetos se

comunicam através de mensagens de ação possuindo um único parâmetro: a fonte.

Essa fonte é o objeto que enviou a mensagem e pode ser obtido pelo receptor da

mensagem, ou alvo, para qualquer dado associado.

Essa representação introduz o conceito de um evento como um sinal entre dois

objetos conectados, uma fonte e um alvo, assim como dois chips em um circuito

integrado se comunicam através de um fio conector. A única informação transmitida

pelo evento em si é o seu tipo, representado pelo nome do seletor. Qualquer outro

dado pode ser explicitamente obtido da fonte pelo tratador do evento. Esse método

elimina a necessidade de várias estruturas de dados diferentes para cada tipo de

evento.

Esse método é muito importante quando se trata de jogos, pois objetos podem

ter diversos dados associados a eles e criar um método para tratar de todos os

dados possíveis se torna custoso tanto no que diz respeito ao consumo de tempo
 152

para levantar todos os tipos de mensagens possíveis quanto no número de código

necessário para implementar o método de processamento de mensagens.

Como exemplo, poderíamos, em um jogo, citar dois personagens, um

representando o jogador e outro representando um personagem manipulado por IA.

O jogador, ao ver o inimigo, decide disparar sua arma contra o oponente e pressiona

a barra de espaço, a qual envia um sinal ao sistema indicando o evento. O evento é

recebido e enviado ao personagem, que o processa e decodifica como uma ação

para atirar. O objeto personagem envia um sinal para a arma que o recebe, pergunta

ao personagem a direção (se os atributos de direção não estiverem codificados na

arma) e envia um sinal ao sistema de partículas contido na arma para criar projéteis.

Os projéteis criados se movem na direção especificada até atingir um objeto.

Supondo que atinja o oponente, o sistema identifica essa ação através do processo

de detecção de colisão e imediatamente coloca os dois objetos em comunicação, o

projétil sinaliza o contato e o objeto alvo, o oponente, pergunta qual é o dano que o

projétil causa, realizando as operações necessárias após isso e destruindo o objeto

do projétil (caso necessário).

Nessa metodologia o único procedimento externo aos próprios objetos do

sistema foi o processo de detecção de colisão, que identificou se o projétil e o

oponente se colidiram (o projétil atingiu o alvo). As outras mensagens foram

transmitidas apenas entre os próprios objetos, sem interferência externa.

11.2. Aplicação do modelo MVC

Uma aplicação utilizando o paradigma MVC é realizada por prover subclasses

concretas das classes de modelo, controlador e visão para implementar os

comportamentos específicos à aplicação. Essas classes concretas devem prover a

 153

implementação de um número limitado de métodos sobrescritos, com o resto já

sendo suprido pelo framework.

Esse método fornece uma base de abstração bastante interessante para modelar

um sistema 3D, porém, ele não provê a questão essencial sobre o controle de

animação e simulação física; necessários para a definição do projeto aqui descrito.

Diversos frameworks foram implementados baseados no modelo MVC, tais como

o MacAPP [78], que lida com aspectos de aplicações para Macintosh e o ET++ [79],

que oferece características similares para estações Unix, porém, todos foram

implementados de maneira a prover funcionalidades de interface gráfica 2D, botões,

áreas de rolagem, etc, entre as aplicações e o usuário, ignorando a produção de

aplicações com animação, simulação física ou gráficos 3D.

Nesse contexto apresenta-se no próximo capítulo, o projeto desenvolvido nessa

dissertação, enfocando gráficos 3D voltados para jogos e aplicações multimídia,

onde a análise de jogos, como já mencionada, deve-se ao fator inerentemente

multimídia dessas aplicações, conforme analisado no (capítulo 3).

 154

Capítulo 12. - Projeto: Framework para Gráficos 3D Interativos

Produzir aplicações que exijam interação com o usuário e que respondam a essa

interação pode ser uma tarefa simples quando o domínio do problema é conhecido.

Um sistema contábil, um sistema de logística ou até mesmo simples jogos por

computador pode ser implementado de maneira ad hoc. Porém, quando se tenta

extrapolar o domínio e implementar algo que vai além do problema, como os atuais

jogos por computador ou ambientes de simulação, pode se tornar uma tarefa

complexa.

Nesse contexto encontram-se os frameworks, projetos abstratos para um

determinado domínio que podem ser extrapolados de maneira a facilitar a produção

de uma aplicação para prover a solução a um sistema mais complexo.

A presente dissertação analisou diversas características de aplicações gráficas e

de animações, porém, a solução para a implementação efetiva dessas

características ou dos conceitos abstratos inerente a elas ainda não é conhecida.

Esse capítulo descreve o projeto desenvolvido detalhando as diversas classes

que implementarão, de maneira abstrata, os conceitos apresentados de maneira a

serem efetivamente desenvolvidos pelos projetistas e codificadores para realizar um

sistema.

12.1. Metodologia

Esta seção descreve a metodologia utilizada para o desenvolvimento do projeto,

iniciando com as pesquisas em computação gráfica e animações, descrevendo o

resultado da análise dos motores de jogos e finalizando com a justificativa do

conjunto de dados levantados no (Capítulo 9).

 155

A computação gráfica sempre foi uma área em contínua expansão no mundo

computacional. Diversas teorias e conceitos surgiram e desapareceram ao longo das

últimas décadas, porém, nos últimos anos, diversos conceitos estagnaram-se,

tornaram-se padrão e dificilmente irão cair em desuso. Esse fato é corroborado

devido ao avanço e à larga utilização das placas aceleradoras gráficas atualmente,

que trabalham tanto com conceitos matemáticos, como a geometria e o

processamento de imagens, quanto com conceitos empíricos, como no caso da

iluminação. Porém novos conceitos continuam surgindo, o que foi fundamental para

o levantamento de algumas classes projetadas e classificadas no sistema.

Quanto à animação, apesar do surgimento de novas técnicas durante a última

década e da continuidade em pesquisas de forma a produzirem novas técnicas, a

área de animação se mostrou mais estável no que diz respeito do uso da informação

já pesquisada. Desenhos animados, apesar de utilizarem o computador como

ferramenta, continuam sendo produzidos com a técnica desenvolvida por John Bray,

assim como produzidos com quaisquer outras técnicas apresentadas no (Capítulo

6). Animações por computador continuam utilizando técnicas antigas, mas também

existem as que utilizam as mais recentes e esse é um fator importante quando se

projeta uma aplicação de animação. Além do mais, todas as técnicas de animação

possuem um atributo em comum: o tempo, o que facilitou a tarefa de projetar as

classes base para as classes de animação.

A análise de diversos motores de jogos mostrou-se fundamental para determinar

o que não realizar em uma proposta de framework. Os diversos motores analisados

foram implementados de maneira ad hoc, sem documentação e com características

restritas. Deve-se ressaltar que o Forge V8 se encontra aparte dos motores de

 156

jogos, pois foi implementado de maneira a se adequar mais como um framework do

que um motor, porém seu projeto foi concebido de uma maneira tão abstrata que

facilitar implementações especificamente genéricas, como a apresentada nesse

projeto, ficam inviáveis. A questão do gerenciador de objetos não possuir um canal

direto de comunicação com o gerenciador gráfico pode criar gargalos no sistema

gráfico impedindo o desenvolvimento de sistemas gráficos interativos e em tempo

real. Ainda mais, em sua dissertação, o autor do projeto Forge V8 descreve que a

implementação utilizou componentes desenvolvidos com tecnologia Microsoft™, o

que impede a portabilidade da aplicação.

O levantamento dos dados foi realizado através de intensos estudos em livros

específicos da área de jogos, através das análises realizadas nos motores de jogos,

através de diversas análises de jogos e teorias científicas que corroboram diversos

aspectos para a produção de sistemas gráficos com os dados apresentados.

12.2. Framework

O framework é dividido em três módulos projetados conforme o paradigma MVC.

Além desses módulos, ele é implementado em duas camadas, a camada de

aplicação, que será desenvolvida pelos desenvolvedores-usuários do framework e a

camada de realizações, que conterá as classes abstratas a serem extendidas. Ele

não realiza levantamento de requisitos do sistema operacional, o que deve ser

implementado pelo desenvolvedor diretamente nas classes ou através da criação de

uma terceira camada, a de sistema, que realizará a comunicação com o sistema

operacional e o ambiente gráfico.

A seguir são apresentados a estrutura abstrata e o modelo de documentação e

comportamento do framework.
 157

1.83. Estrutura Abstrata

Como já mencionado, o framework utilizará o paradigma MVC. Construir

aplicações com esse paradigma requer a definição de objetos para o controlador,

objetos para o modelo e objetos para o renderizador. Objetos de modelo devem

estar acoplados a um ou mais objetos controladores e a um ou mais objetos de

visão, o mesmo é válido tanto para objetos de controle quanto para objetos de visão.

Esse acoplamento é realizado na camada de aplicação através da configuração

direta pelo desenvolvedor.

Objetos de controle e objetos de visão devem realizar operações de obtenção de

recursos de sistema, seja através de implementação direta ou através de uma

requisição a uma camada de sistema implementada pelo desenvolvedor. Essa

requisição deve conter os parâmetros necessários para executar a aplicação

coerentemente. A Figura 31 demonstra a organização do framework proposto:

App1 App2 ... Appn

Controlador Modelo

Visão

Sistema

Figura 31: Estrutura Geral do Framework

 158

Apesar de bastante abstrata essa figura demonstra muito da funcionalidade do

sistema, cuja interdependência de funcionalidades requer uma análise mais

detalhada das classes pertencentes a cada conjunto, a qual está apresentada a

seguir.

12.3. Características

As características propostas pelo framework estão divididas em três módulos:

visão, modelo e controlador apresentados a seguir, descrevendo as classes e

funcionalidades presentes nelas.

1.84. Módulo de Modelo

É a categoria responsável por prover o modelo geométrico e os atributos visuais

dos objetos em uma cena e provê as funcionalidades de organização de cena,

detecção de colisão, controle de orientação de objetos (billboardings/impostors),

definição de iluminação, projeção de sombras, espelhamento, texto, mapeamento de

texturas, gerenciadores de partículas, neblina volumétrica, e controle de animação

estrutural.

Ela é também responsável por gerenciar esses atributos e atualizar a cena de

acordo com as mensagens enviadas dos objetos pelo controlador através de uma

classe que implementa um gerenciador de cena.

As classes abstratas identificadas nesse contexto são as de Repositório, de

Representação de Cena e de Gerenciamento de Cena, uma vez que existem

diversas bibliotecas de grafo de cena implementadas e distribuídas publicamente na

Internet, a implementação concreta de todas essas classes inviabiliza a

 159

generalidade do framework proposto, cabendo ao desenvolvedor da aplicação

implementá-las adequadamente.

Para as classes de repositório e de gerenciador de cena é sugerido que sejam

implementadas utilizando o padrão singleton [68], que permite apenas uma instância

dessa classe em toda a implementação da aplicação.

O diagrama de classes desse módulo está representado na Figura 32

As funcionalidades das classes abstratas estão apresentadas nas seções

seguintes.

1.85. Repositório

A classe de Repositório tem como finalidade armazenar um conjunto de objetos

e uma matriz de identificadores para cada objeto adicionado ao ambiente. Classes

derivadas da classe de Repositório podem ser utilizadas para armazenar texturas,

câmeras, caminhos de animação, geometria, textos, sprites, etc.

Devido à generalidade dessa classe e às diversas bibliotecas de grafo de cena

implementarem diferentes representações de objetos a implementação concreta

dessa classe torna-se inviável, pois o framework ficaria limitado a uma biblioteca

específica.

Os atributos pertencentes a essa classe são:

- Número de Objetos: indicando o número de texturas presentes no

repositório;

- Nomes de Objetos: uma matriz de nomes de texturas onde a posição do

nome na matriz é a posição da textura na matriz de texturas e

 160

- Matriz de Objetos: representa a matriz que conterá o conjunto de texturas

da aplicação. Esse atributo deverá ser adicionado pelo desenvolvedor e não é

provido na implementação do framework.

Os métodos virtuais pertinentes a essa classe devem prover serviços de:

- Adicionar Objetos: Adiciona uma textura na matriz de texturas e um

nome na matriz de nomes, os argumentos são: um objeto da classe textura e um

nome da textura;

- Remover Objetos: remove uma textura do repositório fornecendo tanto o

nome da textura a ser removida quanto o objeto da classe textura como

argumentos;

- Recuperar Objetos: retorna um objeto textura do repositório e

- Recuperar Quantidade de Objetos: recupera a quantidade de texturas

retornando o valor inteiro do atributo número de texturas. Esse é o único método

concreto das classes de repositório devido à existência e trivialidade do atributo.

1.86. Representação de Cena

A classe de representação de cena é a responsável por manter e gerenciar uma

estrutura de grafo de cena.

Sua funcionalidade consiste em detecção de colisão, remoção de objetos não

visíveis, processamento visual e retorno dos objetos visíveis ao renderizador.

Ele é implementado como uma classe abstrata contendo apenas o nome ou

identificador do grafo de cena que será atribuído a ela e métodos virtuais, devido

justamente ao propósito de generalidade do framework.

 161

Os atributos pertencentes à classe de Representação de Cena devem armazenar

o seguinte conjunto de dados:

- Nome do Grafo de Cena: identifica o grafo de cena na aplicação;

- Nó raiz do grafo de cena: contém o ponto de referência para toda a

estrutura hierárquica da cena e deve ser implementado pelo desenvolvedor. Sua

implementação não está presente no projeto do framework.

Os métodos virtuais pertinentes a essa classe devem prover serviços de:

- Processamento Visual: Realizar o processamento visual da cena

retornando apenas os objetos visíveis para que o renderizador possa criar as

imagens;

- Processamento Geométrico: Realizar o processamento geométrico nos

objetos que possuam essa capacidade de maneira a reduzir o número de

polígonos a serem processados pelo renderizador;

- Detectar Colisão: Detecta, através dos volumes de contenção dos

objetos, se dois objetos se colidiram e

- Informar o nó raiz do grafo de cena .

1.87. Gerenciador de cena

O gerenciador de cena tem por finalidade armazenar todas as representações de

cena da aplicação e fornecer os métodos para a recuperação e liberação dessas

estruturas.

Os atributos pertencentes a essa classe abstrata devem representar os seguintes

conjuntos de dados:
 162

- Matriz de representação de cena: Contêm todas as representações de

cena presentes na aplicação;

- Matriz de repositórios: Contêm os repositórios implementados na

aplicação;

- Número de Cenas: Informa o total de representações;

- Número de Repositórios: Informa o total de repositórios no gerenciador e

- Matriz de Nomes de Repositórios: para poder recuperar o repositório

desejado através do nome.

Os métodos virtuais pertinentes a essa classe devem prover serviços de:

- Recuperar o objeto de estrutura de cena;

- Adicionar objeto de estrutura de cena;

- Remover objeto de estrutura de cena;

- Adicionar Repositório;

- Recuperar objeto de repositório;

- Recuperar quantidade de estruturas de cena e

- Recuperar quantidades de repositório.

1.88. Módulo de Visão

É a categoria responsável por prover as funcionalidades de geração das imagens

através do modelo. Algumas classes pertencentes a essa categoria podem ser

implementadas de maneira concreta, passível de extensibilidade para poder prover

maior funcionalidade a um sistema.

 163

O diagrama de classes do módulo de visão está representado na Figura 34.

As funcionalidades das classes do módulo de visão estão apresentadas a seguir.

1.89. Volume de Visão

Volume de visão é a classe responsável por delimitar o volume de visão de uma

câmera. Através do volume de visão, da orientação da câmera e da projeção é

possível calcular quais objetos do modelo estão visíveis ou não no sistema.

A classe de volume de visão é uma das classes que podem ser implementadas

de maneira concreta, seus atributos são:

- Topo: representa o plano de recorte XoZ do topo do volume por um valor

em ponto flutuante;

- Base: representa o plano de recorte XoZ da base do volume por um valor

em ponto flutuante;

- Esquerda: representa o plano de recorte YoZ à esquerda do volume por

um valor em ponto flutuante;

- Direita: representa o plano de recorte à YoZ direita do volume por um

valor em ponto flutuante;

- Perto: representa o plano de recorte XoY perto da câmera por um valor

em ponto flutuante e

- Longe: representa o plano de recorte XoY distante da câmera por um

valor em ponto flutuante.

Os métodos contidos nessa classe dizem respeito apenas à atribuição ou

recuperação de cada um desses atributos.

 164

1.90. Projeção

Projeção indica o tipo de projeção a ser utilizada por uma câmera para renderizar

a cena.

Essa classe é outra classe passível de representação concreta e possui os

seguintes atributos:

- Volume de Visão: Responsável pela matriz de projeção;

- Tipo de Projeção: Indicando se é Perspectiva ou Ortográfica;

- Pilha de Projeções: Para armazenar projeções alteradas que necessitem

ser recuperadas de maneira a obter diferentes efeitos visuais.

Os métodos pertinentes a essa classe devem prover serviços de:

- Atribuir Volume de Visão: responsável por atribuir um volume de visão

para a projeção. O argumento é um objeto da classe Volume de Visão;

- Atribuir Projeção: responsável por atribuir uma projeção de fato. Esse

método é sobrecarregado (overloaded) devido à grande variedade de

argumentos que ele pode receber. Esses argumentos vão desde o tipo de

projeção, a matriz de projeção ou os planos do volume de visão;

- Atribuir Tipo de Projeção: responsável por atribuir o tipo de projeção a

ser utilizada;

- Recuperar Matriz de Projeção: Retorna a matriz de projeção em uso;

- Empilhar Projeção: Realiza o mesmo que Atribui Projeção, porém

empilha a projeção corrente na pilha de projeções;

 165

- Desempilhar Projeção: descarta a projeção corrente e atribui a projeção

do topo da pilha de projeções como a projeção atual, descartando-a da pilha;

- Descartar Projeção: Descarta a projeção do topo da pilha de projeções,

mantendo a projeção corrente e

- Empilhar Tipo: Empilha a projeção corrente na pilha de projeções e muda

apenas o tipo de projeção.

A classe de projeção pode ter diversos tipos de construtores, a saber:

- Passando tipo e matriz de projeção como argumentos;

- Passando tipo e objeto de volume de visão como argumentos e

- Passando tipo e os planos do volume de visão como argumentos.

1.91. Câmera

A Câmera é o objeto responsável por selecionar quais objetos estão no volume

de visão e retorná-los para que o renderizador possa gerar a imagem. Esses objetos

são os objetos pertencentes ao grafo de cena. A câmera pode estar associada a um

objeto do grafo de cena (ou até mesmo ser um deles) e sofrer transformações.

Devido a isso ela não pode ser implementada como uma classe concreta, pois

depende de dados de usuário, logo, é representada através de uma classe abstrata.

Seus atributos devem armazenar os seguintes conjuntos de dados:

- Projeção: Responsável por realizar a projeção e por determinar o real

volume de visão para o processamento de objetos visíveis;

- Posição: Define a posição da câmera na cena através de um ponto no

espaço;
 166

- Direção: Define a direção para onde a câmera aponta na cena através de

um vetor no espaço;

- UpVector: Define para qual direção o lado de cima da câmera aponta

através de um vetor no espaço;

Os métodos definidos devem prover serviços de:

- Recuperar Objetos: Método virtual responsável por recuperar os objetos

visíveis do grafo de cena a qual a câmera está acoplada;

- Ajustar Posição;

- Ajustar Direção;

- Ajustar UpVector;

- Recuperar Posição;

- Recuperar Direção e

- Recuperar UpVector.

O construtor da câmera receberá os argumentos responsáveis por inicializar os

parâmetros de posição, orientação e upvector da câmera.

1.92. ViewPort

A classe de viewport é a classe responsável por determinar qual será a área de

desenho da imagem gerada a ser exibida na aplicação.

Ela necessita de poucos atributos e poderia ser projetada como uma classe

concreta, porém, por possuir uma câmera para gerar a imagem, ela necessita ser

projetada como abstrata.

Os atributos da ViewPort são:

 167

- Posição em X: identificando a posição no eixo X da janela da aplicação

em valores inteiros;

- Posição em Y: identificando a posição no eixo Y da janela da aplicação

em valores inteiros;

- Largura: identificando a largura da área de apresentação em valores

inteiros;

- Altura: identificando a altura da área de apresentação em valores inteiros;

- Câmera: a câmera que visualizará a cena e.

- Ativo: Identifica se a cena vista pela câmera deve ou não ser renderizada.

Os métodos pertencentes a essa classe devem prover serviços de:

- Redimensionar a área de exibição;

- Enviar Objetos Visíveis ao Renderizador;

- Reajustar os argumentos de posição e dimensão

O construtor da classe de viewport recebe quatro argumentos para atribuição de

posição e dimensão, ou dois argumentos, representando pontos do canto inferior

esquerdo e superior direito da área de exibição da imagem.

1.93. Renderizador

A classe renderizador é a classe fundamental do módulo de visão. Ela é a

responsável por processar todos os atributos geométricos e visuais do grafo de cena

de maneira a gerar a(s) imagem(s) para a aplicação.

 168

Como é dependente dos viewports e das bibliotecas gráficas, essa classe deve

ser implementada de maneira abstrata. Os atributos levantados para a classe

renderizador são:

- Lista de ViewPorts: um renderizador pode ter mais que uma viewport;

- Profundidade de Cores: representando quantos bits terão a tripla RGB

através de um valor inteiro;

- Buffer de Profundidade: Representando quantos bits o buffer de

profundidade utilizará para realizar os cálculos através de um valor inteiro e

- Buffer de Stencil22: Representando quantos bits o buffer de stencil

utilizará para realizar os cálculos através de um valor inteiro;

E seus métodos devem prover serviços de:

- Renderizar cada ViewPort Ativa;

- Adicionar Viewport;

- Remover ViewPort;

- Atualizar os dados dos buffers e

- Requerer atributos do sistema

1.94. Módulo Controlador

O módulo controlador é o responsável pelo comportamento dinâmico do

framework. Ele implementa os gerenciadores responsáveis por manipular os dados

de entrada do usuário, os dados de simulação física, os dados de entrada e saída de

22
Buffer de Stencil: área de dados para controle e cálculo de funções de exibição.
 169

rede ou processar dados referentes à inteligência artificial, todos praticamente

dependentes do tempo.

Dessa maneira obtêm-se quatro classes de gerenciadores no projeto, uma classe

de temporização e uma classe para controle de animações, porém, como redes e

inteligência artificial não são objetos de estudo desse trabalho elas estão omitidas.

O diagrama de classes do módulo controlador está apresentado na Figura 35.

As especificações das classes para o módulo controlador estão descritas a

seguir.

1.95. Sinal

Sinal é a classe responsável por colocar em comunicação, no mínimo, dois

objetos de modelo. Como os objetos de modelo não são definidos pelo framework e

sim indicados pelos desenvolvedores, essa classe deve ser implementada como

uma classe abstrata.

Os atributos pertencentes a essa classe são:

- Objeto fonte: o objeto fonte pode ser implementado como um objeto do

módulo controlador ou um objeto do módulo de modelo. Em ambos os casos o

desenvolvedor deverá especificar como os objetos irão trocar as mensagens de

comando e

- Tipo de mensagem: o tipo de mensagem sinaliza ao objeto alvo qual a

mensagem que o objeto fonte tenta passar.

Os métodos da classe sinal devem ser responsáveis por:

- Acoplar os objetos em comunicação;

- Sinalizar o objeto alvo e

 170

- Verificar se o objeto alvo recebeu a mensagem.

1.96. Temporizador

O objeto temporizador é o responsável por controlar a temporização global da

execução da aplicação. Para isso ele deve ter um ponto de acesso global e ser

único no sistema. Portanto sugere-se que seja implementado utilizando o padrão

singleton.

Seu único atributo é o valor de tempo;

Seus métodos devem ser responsáveis por:

- Inicializar o relógio;

- Configurar o relógio e

- Recuperar o tempo do sistema.

1.97. Dispositivo de entrada

A classe de dispositivo de entrada é a responsável por processar os eventos de

entrada enviados pelo usuário ao sistema através da ativação dos sinais acoplados

a ele.

Os atributos pertencentes a essa classe são:

- Conjunto de Sinais: uma matriz contendo todos os sinais que o

dispositivo ativará;

- Conjunto de Informação: uma matriz indicando o dado recebido. A

posição do dado na matriz indicará qual sinal será ativado;

- Buffer de Informação: Para armazenar dados recebidos ainda não

processados para processamento posterior;

 171

- Identificador: um atributo para identificar o dispositivo de entrada e

- Número de Sinais: o número de sinais que o dispositivo de entrada

poderá acionar.

Os métodos pertencentes a essa classe devem ser responsáveis por:

- Adicionar Sinais: adiciona um sinal e o dado recebido do dispositivo que

ativará o sinal;

- Remover Sinais;

- Reconfigurar Dado;

- Informar o número de Sinais e

- Processar entrada.

1.98. Gerenciador de Entrada

O gerenciador de entrada é o responsável por manter o conjunto de dispositivos

de entrada informando ao sistema quais estão disponíveis ou não. Ele deve possuir

um ponto de acesso global ao sistema. Portanto sugere-se que seja implementado

utilizando o padrão singleton.

Os atributos pertencentes ao gerenciador de entrada são:

- Conjunto de dispositivos de entrada e

- Número de dispositivos de entrada.

Os métodos do gerenciador de entrada devem ter a responsabilidade de:

- Adicionar Dispositivos de entrada;

- Remover dispositivos de entrada;

 172

- Retornar o número de dispositivos de entrada e

- Informar os dispositivos de entrada.

1.99. Lei Física

Lei física é uma classe abstrata que representa uma lei da física, aplicável a cada

quantum de tempo do processamento de simulação.

Normalmente ela é representada por um vetor de direção e uma magnitude, mas

como as bibliotecas de grafo de cena ou algumas bibliotecas gráficas possuem uma

implementação concreta desses parâmetros, essa classe, para fins de generalidade,

deve ser implementada como uma interface.

Os métodos pertencentes a essa classe devem ter a finalidade de:

- Realizar operações matemáticas em vértices, vetores ou objetos de

transformações dos objetos de modelo;

- Sinalizar o objeto ou propriedade física de um objeto para alterar

seus dados;

- Configurar os dados da lei.

A lei física é acessível apenas através do gerenciador de simulação física, assim

como seus métodos.

1.100. Propriedade Física

Uma propriedade física possui as mesmas características que uma lei física. A

diferença está na aplicação da propriedade nos objetos.

Uma maçã caindo continuará caindo aumentando sua velocidade de acordo com

a força da gravidade (lei da gravidade), porém um carro em aceleração apenas

 173

acelerará caso ele receba um sinal para tal. Esse sinal deve ser processado pelo

simulador de física, o qual sinalizará o objeto associado a esse sinal para aumentar

a propriedade física velocidade de acordo com a propriedade física aceleração.

Caso esse sinal pare de enviar dados ao objeto e exista uma lei que faça o carro

diminuir a velocidade de acordo com o tempo, essa lei passará a sinalizar sozinha o

objeto, que diminuirá a velocidade.

O método pertencente a essa classe deverá sinalizar ao objeto para alterar um

atributo. Por exemplo, a propriedade velocidade alterará a posição do objeto no

tempo, enquanto que a propriedade aceleração alterará a velocidade do objeto no

tempo.

Os métodos são idênticos aos da classe de lei física, porém são acionados

apenas quando especificados através de um controlador que não o gerenciador de

simulação física.

1.101. Gerenciador de Simulação Física

O gerenciador de simulação física é o responsável por realizar as operações de

simulação física nos objetos do módulo de modelo.

Sua funcionalidade consiste em processar objetos sólidos, sistemas de partículas

ou vértices dos objetos maleáveis.

Esse processamento se dá através dos sinais, que conectarão um objeto,

sistema de partículas, partícula ou vértice a uma lei ou propriedade física.

Os objetos processados pelo simulador devem ser explicitados para que não

haja artifícios de simulação. Objetos de representação do mundo não sofrem

(diretamente) os efeitos da lei da gravidade. Se sofressem todos os objetos,

 174

inclusive as paredes, chão e teto, por exemplo, cairiam dando a sensação de um

ambiente sem gravidade.

Dessa maneira o gerenciador de simulação física deve ter quatro conjuntos de

dados: a) o conjunto de objetos cujas leis físicas são aplicáveis; b) o um conjunto de

propriedades físicas; c) um conjunto de sinais, indicando quais propriedades físicas

se aplicam a quais objetos e d) um conjunto de leis físicas a aplicar aos objetos.

Alguns desenvolvedores implementam as propriedades físicas diretamente nos

objetos de modelo, isso é perfeitamente aplicável e realizável por esse modelo

bastando apenas configurar o sinal com o objeto e com o atributo de propriedade

física do objeto.

Os atributos pertencentes à classe de gerenciador físico são:

- Conjunto de leis físicas;

- Conjunto de Propriedades físicas (de cada objeto);

- Conjunto de sinais: acoplando um objeto do módulo de modelo a uma

propriedade física;

- Conjunto de objetos aplicáveis às leis físicas: O desenvolvedor pode

não querer usar essa metodologia. Ela não é implementada na classe abstrata

de gerenciador de simulação física;

- Número de leis físicas e

- Número de propriedades físicas.

Os métodos do gerenciador de física são responsáveis por:

- Adicionar leis físicas;

 175

- Remover leis físicas;

- Adicionar propriedades físicas;

- Remover propriedades físicas;

- Adicionar Objetos aplicáveis às leis físicas;

- Adicionar sinais de processamento;

- Processar as leis físicas;

- Resolver colisões e

- Processar temporização.

1.102. Ossos

Ossos são objetos que controlam os nós de transformação de um grafo de cena

ou a posição de vértices. Eles são bastante úteis para animação hierárquica,

animação por morphing, animação tradicional ou animação por skinning.

Sua estrutura é composta por uma matriz de transformação, por um conjunto de

ossos de maneira a formar uma estrutura hierárquica e por uma ou mais

propriedades de transformação de objetos, seja essa propriedade a posição de um

objeto ou um nó de transformação de um ou de um grupo de objetos.

Seus atributos são:

- Matriz de transformação: é a matriz que realizará a transformação da

propriedade de um objeto;

- Conjunto de propriedades: o conjunto de propriedades de um objeto do

módulo de modelo a sofrer as transformações. Como esse conjunto varia a cada

 176

implementação de aplicação ou de biblioteca de grafo de cena, ele deve ser

especificado pelo desenvolvedor e

- Conjunto de ossos: o conjunto de ossos define a estrutura hierárquica

desse tipo de estrutura.

Apesar de não possuir o conjunto de vértices e o conjunto de pesos que o osso

atuará no vértice para a realização do skinning, essas propriedades podem ser

facilmente implementadas através da criação de uma classe derivada da classe

osso.

Os métodos pertencentes à classe de ossos devem ter a responsabilidade de:

- Adicionar ossos;

- Remover ossos;

- Configurar matriz de transformação e

- Adicionar propriedade para transformação.

1.103. Representação de Animação

A classe de representação de animação é responsável por indicar como os ossos

atuarão nos objetos de acordo com o tempo.

Ela pode ser implementada utilizando sistemas de script, animação procedural ou

qualquer outro tipo de animação descrita no (capítulo 6).

Seus atributos são:

- Regra de animação: define como o(s) objetos(s) representado(s) por

essa representação se comportará(ão) em relação ao tempo. Esse é um atributo

que deve ser implementado pelo desenvolvedor devido à sua generalidade;

 177

- Conjunto de ossos: define o conjunto de hierarquia de ossos para

realizar as interpolações no tempo;

- Tempo total de animação: indica a duração completa da animação;

- Identificador de animação;

- Hierarquia Corrente: define a hierarquia de transformações corrente a ser

aplicada nos modelos e

- Tempo corrente de animação: indica o tempo corrente no

processamento da animação.

Os métodos presentes na classe de representação de animação devem ter a

responsabilidade de:

- Configurar a regra de animação;

- Adicionar hierarquia de ossos;

- Remover hierarquia de ossos;

- Configurar o tempo total de animação;

- Atribuir identificador;

- Processar animação e

- Reinicializar animação.

1.104. Gerenciador de Animação

O gerenciador de animação assemelha-se ao gerenciador de simulação física,

pois controla atributos de posicionamento de objetos, vértices ou partículas.

 178

A diferença do gerenciador de animação é que ele sempre processa os dados,

ao contrário do simulador físico que processa as propriedades físicas apenas

quando requisitadas.

Os sinais apenas indicarão ao gerenciador de animação para mudar o estado de

uma estrutura de animação de acordo com a interação do usuário, porém, como os

estados de animação diferem para cada estrutura de animação, fica a cargo do

desenvolvedor implementar os métodos e atributos necessários nas classes

derivadas do gerenciador de animação e/ou na estrutura de animação.

Os atributos do gerenciador de animação são:

- Tempo corrente do sistema: obtido através de uma requisição ao

temporizador;

- Conjunto de estruturas de representação de animação e

- Número de estruturas de animação.

Os Métodos pertencentes à essa classe devem prover as funcionalidades de:

- Adicionar representação de animação;

- Remover representação de animação;

- Reinicializar uma representação de animação;

- Reinicializar todas as representações de animação e

- Processar cada representação de animação.

 179

Capítulo 13. - Estudos de Caso

Definidas as características, os módulos e as classes que compõe o framework é

necessário demonstrar como utilizá-lo em uma aplicação.

Os estudos de caso apresentados, apesar de serem teóricos, indicam os passos

necessários para a configuração de aplicações, bem como justificam as classes e

procedimentos descritos no (capítulo 12).

Apresenta-se, neste capítulo três estudos de caso:

13.1. Animação Tradicional

Animação tradicional diz respeito apenas à questão de keyframming, ou seja,

processamento de tempos chave.

Ela normalmente é utilizada para a produção de animações simples, como

desenhos animados.

A técnica é simples. Um objeto é definido em uma posição e/ou orientação em

determinados espaços de tempo, normalmente igualmente espaçados.

Implementaremos a animação das coxas e da pélvis de um robô modelado

através de uma estrutura hierárquica:

Supondo que o desenvolvedor escolha uma biblioteca de grafo de cena qualquer

e já tenha implementado as classes concretas do modelo. Ele adiciona as texturas a

utilizar no sistema no repositório de texturas;

A pélvis do robô será representada por um elipsóide e as coxas por cilindros,

dessa forma ele adiciona duas estruturas no repositório de geometria: uma esfera e

um cilindro, ambos com dimensões unitárias.

 180

À representação de cena, ele adiciona a raiz do grafo de cena, a qual foi

implementada conforme demonstra a figura:

Raíz
Humanóide
Grupo

Grupo de Transformação

Pélvis Forma Geométrica

escala translacaoRotacao Pernas Transformação

Esquerda Direita

Rotação Rotação

Figura 32: Exemplo do Grafo de Cena do Objeto a Animar.

Ele indica que a câmera, com uma determinada projeção e volume de visão, irá

visualizar a cena toda, adiciona a câmera a uma viewport, a qual é adicionada ao

renderizador.

O desenvolvedor implementa os ossos de animação em uma estrutura

hierárquica para os objetos de translação e de rotação do grupo do robô, e para os

objetos de rotação da perna esquerda e direita;

OssoTransl.addMatriz(Matriz de Translação);

OssoTransl.addTransformacao(robotrans);

OssoRot.addMatriz(Matriz de Rotação);

OssoRot.addTransformacao(roborot);

OssoPernaEsquerda.addMatriz(Matriz de Rotacao 1);

OssoPernaEsquerda.addTransformacao(peRot);

OssoPernaDireita.addMatriz(Matriz de Rotacao 2);

OssoPernaDireita. AddTransformacao(pdRot);
 181

OssoPerna.addOsso(OssoPernaEsquerda);

OssoPerna.addOsso(OssoPernaDireita);

//Não aplica transformações na perna, apenas agrupa.

OssoPerna.addMatriz(Identidade);

OssoRobo.Add(ossoTransl);

OssoRobo.Add(ossoRot);

OssoRobo.Add(ossoPerna);

Obviamente a classe osso deve estar desenvolvida para a aplicação das

estruturas do grafo de cena.

A estrutura de animação conterá a regra de animação para os ossos. A regra de

animação é uma matriz indicando, nas linhas, qual osso será transformado e nas

colunas o quadro chave de interpolação. Como a estrutura de animação possui a

quantidade total de tempo da animação,é possível extrair o intervalo entre os

quadros chave.

Assim, quando se aplica o processamento da animação, a estrutura calcula para

cada osso do robô a quantidade de transformação a realizar através da matriz e

dosétodos de interpolação.

13.2. Animação Controlada por Simulação

Suponha a mesma animação tradicional descrita acima, porém o desenvolvedor

deseja colocar uma estrutura de simulação física de gravidade e de velocidade.

Ele adiciona no gerenciador de simulação física a lei da gravidade, um vetor

direcionado para baixo com uma determinada magnitude e a propriedade de

translação do robô como o objeto o qual a gravidade irá atuar.

 182

Adiciona a propriedade velocidade e o sinal de indicação mudança de velocidade

na translação do objeto robô.

Implementa uma classe de dispositivo de entrada para a manipulação de teclado

e atribui um sinal para notificar o gerenciador de simulação física quando uma

determinada tecla for pressionada, indicando a velocidade no objeto como item a

alterar.

Adiciona um objeto chão no grafo de cena, porém não o adiciona no

processamento físico.

Como o objeto está sempre em contato com o chão a lei física não é percebida,

apesar de sempre estar sendo processada, pois o gerenciador de cena detecta a

colisão entre o objeto e o chão e não permite ao objeto continuar caindo.

Ao sair do chão, a lei da gravidade se faz percebida e o objeto cai, alterando a

propriedade de translação do robô a partir da lei da gravidade.

 183

Capítulo 14. - Resultados

Os capítulos anteriores demonstraram algumas informações úteis para as

pessoas que utilizarão o projeto, descrito no (Capítulo 12), cuja demonstração de

utilização está descrito no (Capítulo 13).

Este capítulo destina-se a demonstrar os resultados alcançados com o projeto

desenvolvido, comparando a eficiência, generalidade e facilidade de uso com outros

dois produtos que apresentam objetivos semelhantes: a) Crystal Space, um motor

de jogo de código aberto e b) OpenSceneGraph, uma biblioteca de grafo de cena

também de código aberto.

14.1. Eficiência

O tipo de eficiência descrita diz respeito ao número de quadros por segundo de

renderização e a comparação com essas duas ferramentas deve-se ao fato de:

a) Crystal Space ser um motor de jogos genérico e de código aberto,

implementa diversas informações aqui descritas e

b) OpenSceneGraph ser uma biblioteca de grafo de cena com algumas

ferramentas para visualização e sistemas de partículas já implementadas.

A tabela a seguir demonstra a comparação de eficiência de um programa de

animação de sistemas de Partículas com simulação física implementado utilizando-

se as ferramentas analisadas e o projeto descrito.

 184

Nome Crystal Space OpenSceneGraph Projeto

Quadros/Segundo 40 58 55

(média)
Qualidade da Boa Razoável Boa

Simulação Física
Tabela 2: Análise de eficiencia de uma aplicação utilizando a arquitetura proposta

Percebe-se que na relação entre quadros por segundo e qualidade de simulação

física o projeto superou as duas outras bibliotecas, mas vale salientar que por não

ter sido especificado a implementação concreta das classes de controle físico o

projeto pode apresentar resultados piores caso seja implementado de uma maneira

pouco eficiente.

14.2. Generalidade e Documentação

O ideal em um framework é que ele seja genérico o suficiente, para auxiliar na

produção dos aplicativos no domínio do problema especificado, e suficientemente

documentado, informando aos desenvolvedores como se utilizar o framework sem

contudo inundá-los com informações muito detalhadas ou irrelevantes ao propósito.

Comparado tanto com o Crystal Space, quanto com o OpenSceneGraph, o projeto

apresentado demonstrou algumas vantagens e desvantagens, descritos a seguir.

- Crystal Space: A biblioteca Crystal Space serve muito bem ao propósito a

que foi criada: Desenvolvimento de Jogos, porém ela foi implementada de

maneira a ser uma biblioteca de funções e não a ser um framework. Sua

documentação é muito extensa e excessiva, confundindo os usuários e sua

aplicabilidade se restringe apenas a jogos por computador;

 185

- OpenSceneGraph: A biblioteca OpenSceneGraph foi implementada

utilizando-se programação orientada a objetos e padrões de projetos de maneira

a ser uma estrutura de grafo de cena pronta para uso, porém ela extende sua

funcionalidade por implementar sistemas triviais de animação e sistemas de

partículas. É muito fácil de usar, porém possui pouca documentação e

orientação de como utilizá-la, o que confunde os usuários iniciantes e

- Projeto: O projeto aqui desenvolvido tem como finalidade ser uma

orientação a desenvolvedores iniciantes em jogos ou aplicações gráficas 3D

com ou sem animação e prover uma estrutura genérica para o desenvolvimento

de aplicações com essas caracteristicas para ser utilizada tanto por

desenvolvedores experientes ou iniciantes. A documentação aqui provida diz

respeito apenas à extrutura organizacional do framework, indicando como o

desenvolvedor pode implementar o seu sistema.

14.3. Facilidade de Uso

A comparação de facilidade de uso foi realizada apresentando o presente

documento até o Capítulo 13 a um profissional da área de Engenharia Civil, a um

profissional da área de Física e a um profissional da área de Sistemas de

Informação que predispunham de conhecimento suficiente de programação

utilizando a linguagem C/C++.

Os resultados foram obtidos analisando-se os quesitos de eficiência,

generalidade e documentação e são apresentados a seguir:

 186

- Crystal Space: Usuários apresentaram dificuldades ao utilizar a biblioteca

Crystal Space devido, primeiramente, à extensa e confusa documentação e

também devido à especificidade de uso da biblioteca;

- OpenSceneGraph: Apesar de aprenderem a utilizar a biblioteca sem

dificuldades devido à finalidade de ser uma estrutura de dados e devido à pouca

documentação os usuários não souberam explorar a biblioteca para as

finalidades as quais queriam aplicar computação gráfica e

- Projeto: O projeto apresentado, apesar de não implementado, orientou os

usuários a desenvolverem aplicações na área de suas respectivas profissões

utilizando a biblioteca OpenSceneGraph, uma vez que já tinham sido

apresentados a ela.
 187

Capítulo 15. - Conclusões

Este capítulo apresenta as conclusões obtidas no desenvolvimento do projeto,

indicando as contribuições oferecidas no estudo e desenvolvimento do framework,

as principais dificuldades encontradas, as propostas para trabalhos futuros e as

considerações finais.

15.1. Contribuições

O trabalho desenvolvido propôs o projeto de um framework modular, configurável

e extensível, sem a limitação de bibliotecas específicas de maneira a torná-lo

portável para a utilização em aplicações multimídia, em específico as que utilizam

gráficos tridimensionais, animações e interação com o usuário.

O objetivo direto desse trabalho foi proporcionar aos desenvolvedores desse tipo

de aplicação uma maneira mais fácil de realizar o projeto de desenvolvimento

através da identificação de características específicas às suas necessidades e a

utilização dos recursos propostos pelo framework através de módulos

independentes, derivando as classes abstratas que ele oferece proporcionando a

não generalização dos produtos desenvolvidos através da utilização do mesmo.

Este trabalho também serve como base de referência para desenvolvedores de

jogos e aplicações multimídia, pois provê uma gama de recursos e informações

relevantes para aplicações nessa área no que diz respeito à organização da

estrutura abstrata de jogos, os tipos de dados utilizados e como eles podem ser

representados, os tipos de representação de jogos e a apresentação das diversas

metodologias de animação.
 188

15.2. Principais Dificuldades

A grande dificuldade no desenvolvimento deste projeto foi o pioneirismo dessa

área no cenário nacional, pois a ausência de pesquisadores limita o processo de

pesquisa.

A falta de informação sobre a metodologia de produção de aplicações multimídia,

principalmente as com gráficos 3D e animações também é um fator relevante a ser

considerado. Apesar de diversas pesquisas acadêmicas na área de animação e na

área de computação gráfica existirem, muito pouco se menciona quando se

considera a correta combinação entre essas duas áreas.

A falta de documentação dos motores de jogos e a maneira como eles foram

organizados e implementados foi um empecilho em matéria de levantamento de

requisitos, algoritmos e estudo da estrutura do projeto para ter uma base de

referência.

E por último, mas não menos importante, o desenvolvimento de um projeto

portável e genérico é um grande desafio quando se trata desses tipos de aplicações.

As classes levantadas devem possuir uma generalidade que permita a utilização do

projeto em diversos sistemas operacionais e com diversas bibliotecas gráficas,

porém, também devem possuir uma especificidade quanto à funcionalidade,

responsabilidades, organizações e escopo de aplicação. Projetar essas classes de

maneira a não se ater a funcionalidades específicas é um desafio quando se trata de

aplicações com naturezas diversas, como os jogos por computador.

15.3. Propostas para trabalhos futuros

O trabalho aqui desenvolvido preenche uma lacuna tanto para desenvolvedores

iniciantes quanto para pesquisadores em diversas áreas de estudo.

 189

Os trabalhos futuros que podem ser realizados com o projeto proposto são:

- Implementação de jogos e aplicações multimídia;

- Utilização em ensino de programação orientada a objetos;

- Pesquisa e otimização sobre o mesmo assunto;

- Desenvolvimento de aplicações de simulação para empresas;

- Desenvolvimento de aplicações de visualização científica;

- Desenvolvimento de aplicações de Sistemas de Informação Geográficos;

- Análise da eficiência da estrutura do projeto;

- Correção e adição de classes;

- Etc.

Enfim, a área de computação gráfica e de animação provê a aplicação em

diversas áreas tanto científicas quanto comerciais e proporciona diversas áreas de

pesquisa para a utilização do framework proposto.

15.4. Considerações Finais

A evolução de sistemas e aplicações gráficas nos últimos anos tem ocorrido de

maneira espantosa, exigindo sempre a capacidade limite dos computadores a cada

novo lançamento e, conseqüentemente, impulsionando o mercado consumidor, a

indústria de hardware e órgãos de pesquisa a se desenvolver conforme as

necessidades desse conjunto de aplicações.

Implementar um framework para qualquer domínio de problema é uma tarefa que

vai além de implementar uma aplicação naquele domínio de problema em particular.

 190

Para tal feito necessita-se investigar todas as possíveis variações naquele domínio,

identificar características comuns, abstrair funcionalidades básicas e projetar o

framework sem estar viciado em uma ou poucas funcionalidades, mas analisando

todo o conjunto possível e extrapolar funcionalidades que possam, porventura, se

tornar necessárias.

Esse projeto foi o pioneiro da área no Departamento de Computação da

Universidade Federal de São Carlos e está entre os cinco projetos com referência a

jogos por computador produzido academicamente no país.

Jogos por computador se mostraram um laboratório interessante para estudos e

pesquisas tanto em disciplinas de graduação quanto em áreas científicas

propriamente ditas devido à sua exigência de diversas áreas de conhecimento.

O framework proposto apresenta um projeto voltado à produção de aplicações

que possuem, até o presente momento, uma metodologia de produção ou ineficiente

ou sigilosa no sentido de que iniciantes produzem código sem considerar as técnicas

de engenharia de software ou em que grandes empresas da área não divulgam sua

metodologia de produção por ser o diferencial para os seus negócios.

 191

Apêndice A. – Diagramas de Classe do Framework.

Módulo de Modelo

G erenciador de Cena
N um Cenas : Integer
Repositorio N um Repositorios : Integer
nom es : String M atrizN om erepositorios : String[]
qtty : Integer
+ 0..* AddEstrutCena(estrutura s : Representação de Cena)
add(objeto, nom e) G etEstrutCena(nom e) : Representação de Cena
get(nom e) : O bjeto deleteEstrutCena(nom e)
delete(nom e) AddRepositorio(re positorio : Repositorio, nom e)
delete(objeto) DeleteRepositorio(nom e)
getN um Ite m s() : Inte ger getRepositorio(nom e) : Repositorio
getN um Repos itorios()
getN um Cenas()

+ 1.. * raíz é o nó raiz do

grafo de cena.
Representação de Cena
Dev e ser
nome : Str ing im plem entado pelo
raiz desenv olv edor na
classe concreta
Cull() : Objet os Render izáv eis de riv ada dessa.
D oLO D()
DetectaColisão()
espec ific aRaiz (objeto de nó de gr afo de c ena)

Figura 33: Diagrama de Classes do módulo de Modelo

 192

Módulo de Visão
 193

V olum eV isão Projeç ão

T opo tipo
Bas e num H istorico
Esquerda
Direit a set Projec tion(v olv is : V olumeV isão, t ipo)
Pert o set Projec tion(t opo, base, es q, dir, per to, longe, t ipo)
Longe set Projec tion(m atriz4, t ipo)
setVolV is (v olv is : V olum eVisão)
Corrente
setT opo(v alor) pushProjection(v olv is : Volum eV isão, tipo)
+1
setB ase(v alor) pushProjection(topo, base, esq, dir, perto, longe, tipo)
set Esquerda(Valor) pushProject ion(M atr iz4, t ipo)
setD ireita(v alor) pushT ipo(t ipo)
+ 1..n setT ipo(tipo)
set Pert o(Valor )
set Longe(v alor ) getProjM atrix () : M at riz 4
setV olum e(M atriz 4) dropPilha()
His torico
getT opo()
getB ase()
getEsquerda()
getD ireita()
getPerto()
getL onge()

ViewPort
Câm era
posX
pos Y Posicao : ponto3d
largura dir eção : v etor 3d
altura upv ector : v etor3d
at iv a reprCena : Representação de Cena
identificador
s etPos icao(pos )
+1 setDirecao(direcao)
setA tiv a()
s etInat iv a() s etU pV ect or(upv ec tor)
addCam era(cam era : Câm era) get Posic ao() : pont o3d
s etPos X (x ) getD ire cao() : v etor3d
s etPos Y (y ) getU pVector() : v etor3d
s etPos (x , y ) Cull() : O bjetos renderizáv eis
setPos(ponto : ponto2D) s etR eprC ena(repr Cena : Represent ação de C ena)
s etL arg(larg)
s etA lt(alt )
setD im ensao(ponto1 : ponto2D, ponto2 : ponto2D )
R edimens iona(larg, alt )
setID(id)
get ID()
+ 1..*
Lista de Viewports

Renderizador
num ViewPorts
prof_de_c ores
bits_profundidade
bit s_s tenc il

addV iewport (v p : V iewPort )

deleteV iewPort(id)
setB itsCor(bits : Integer)
setB itsProf(bits : Integer)
setB itsStencil(bits : Integer)
get Conf igurac ao()
Render()

Figura 34: Diagrama de classes do módulo de Visão.

 194

Módulo Controlador

D isp o sitiv o d e E n tr ad a
I d e n tific ad o r
Sin a l
C o n ju n to D e I n fo r m aç õ es
B u ffer D e D ad o s A lv o

N u m S in ais F o n te
M en sag em

A d d S in al( )
A c o p la r ( )
C o n fig u r aD a d o ( )
S in a liza r ( )
I n fo r m aN u m S in ais( )
V e r ific ar R ec e b im e n to ( )
R em o v er S in al( )
P r o c essaE n tr a d a( )

G e r e n c ia d o r d e E n tr a d a
G er e n d ia d o r d e S im u laç ão F ísic a
N u m D isp E n tr ad a
N u m P r o p F isic a
A d d D isp E n tr ad a ( ) N u m L eis
R em o v eD isp E n tr a d a ( )
I n fo r m aQ td D isp E n tr ad a( ) A d ic io n aL ei( )
I n fo r m aD isp E n tr a d a ( ) A d ic io n aP r o p ( )
A d ic io n aO b jeto L ei( )
A d ic io n aS in alP r o c essam en to ( )
R e m o v eL ei( )
R e m o v eP r o p ( )
R e so lv eC o lisão ( )
P r o c essaT e m p o ( )
P r o c essaL ei( )

T em p o r izad o r
T em p o
L e iF ísic a P r o p r ied ad eF ísic a
I n ic ia( )
C o n fig u r a ( )
R ec u p er a ( )

T em p o C o r r en te P o d e se r
I m p lem en ta d a n o s
G e r en c iad o r d e A n im aç ão o b je to s d e M o de lo

N u m E str u tu r asD eA n im aç ã o

A d ic io n aR ep r ese n taç ã o ( )
R e m o v eR ep r ese n taç ão ( ) R e p r e se n ta ç ã o d e A n im a ç ã o
I n ic ializaR ep r ese n taç ão ( )
T em p o T o tal
I n ic ia liza R ep r ese n ta ç õ es( )
T em p o C o r r en te
P r o c essaR e p r e se n taç õ es( )
I d en tific ad o r I m p lem e n ta a R eg r
I n fo r m aQ td R ep r esen taç õ es( )
a d e a n im aç ão , a
C o n fig u r aR eg r a( ) ser esp ec ifi cad a p el
A d ic io n aO sso s( ) o d e sen v o lv e d o r
H ier ar q u ia C o r r en te R em o v eO sso s( )
C o n fig u r a T em p o T o tal( )
+1
A tr ib u iI D ( )
P r oc e ssa( )
O sso s
R ein ic ializa ( )
M a tr iz d e T r an sfo r m a ç ão

A d ic io n aF ilh o ( )
R e m o v eF ilh o ( ) C o n j u n to d e H ier ar q u ia d e O sso s
A ju staT r an sfo r m aç ã o ( )
A p lic a T r an sfo r m aç ã o ( ) F ilh o s
A ju staM atr iz( ) P o ssu i tam b ém a
tr an sfo r m a ç ão
g eo m étr ic a ( o u
c o n ju n to d e) a
a lte r a r

Figura 35: Diagrama de classes do módulo Controlador.

 195

Bibliografia
1
[d] Fonte: http://www.outerspace.com.br/retrospace, 02/04/2003.
2
[l ] Battaiola, A.: Jogos por Computador – Histórico Relevância Tecnológica e
Mercadológica, Tendências e Técnicas de Implementação, Anais da XIX Jornada de
Atualização em Informática (JAI) - Volume 2, pág.83 a 122, SBC 2000.
3
[¤ ] Fonte: http://www.datamonitor.com/, 02/04/2003
4
[¤ ] Lamothe, A.: Black Art of 3D Game Programming, Waite Group Press, 1995.
5
[¤ ] Gobbetti, E., Turner, R.: Object-Oriented Design of Dynamic Graphics
Applications, in New Trends in Animation and Visualization, John Wiley.
6
[l ] Steinmetz, R.: Synchronisation Properties in Multimedia Systems, IEEE Journal
on Selected Areas in Communications, 8(3):401–412, 4 1990.
7
[[] Waggoner, B. & York, H.: Video in Games: The State of Industry, Game
Developer, Março, 1999.
8
[¤ ] Moog, B.: Musical Instrument Digital Interface, Journal of Audio Engeneering
Society, V. 34, No. 5, Maio de 1986.
9
[¤ ] Disponível em: www.blender.org, 07/04/2003.
10
[[] Shirley, P. et al: Global Ilumination via Density Estimation, Rendering
Techniques, p. 219-230, Springer Verlag, Proc. Eurographics ’95.
11
[d Möller, T. & Haines, E.: Real Time Rendering, A K Peters, 1999.
12
[d Hennessy, John L., & David A. Patterson: Computer Architecture – A
quantitative approach, Morgan Kaufman Publishers, Inc, 1990.
13
[d Battaiola, A.: Projeções e o seu Uso em Computação Gráfica, JAI98, XVIII
Congresso Nacional da Sociedade Brasileira de Computação, 1998.
14
[á Akeley, K. & Jermoluk, T.: High Performance Polygon Rendering, Computer
Graphics (SIGGRAPH ’88 Proceedings), vol.22, no. 4, p. 239-246, Agosto 88.
15
[d] Rogers, David F.: Procedural Elements for Computer Graphics, Second Edition,
McGraw-Hill, New York, 1997.
16
[¤ ] Hearn, D. & Baker, M.: Computer Graphics C Version, Prentice Hall, 1997
17
[[] Schmalstieg, D.: A Survey of Advanced Interactive 3D Graphic techniques,
Vienna University of Technology, Austria, 1997.
18
[d Battaiola, A. L.: Otimização do Processo de Geração de Malhas Triangulares a
partir de Polígonos, XXIV Latinamerican Conference of Informatics CLEI Panel 98, pp.
749-759, 19 a 24 de outubro de 1998, Quito, Equador.
19
[¤ ] Cripe, B. & Gaskins, T.: The DirectModel Toolkit: Meeting the 3D Graphics
Needs of Technical Applications, Hewlett-Packard Journal, pp. 19-27, Maio 1998.
20
[¤ ] Naylor, B.F., Fuchs, H. &: Kedem, Z.M.: On Visible Surface Generation by a
Priori Tree Structures, Computer Graphics (Proceedings of SIGGRAPH), 14(3), 1980
21
[[] Airey, J. M., Rohlf, J. H. & Brooks Jr., F: Towards Image Realism with Interactive
Update Rates in Complex Virtual Building Enviroments, Computer Graphics, Vol. 24, No.
2, pp. 41 (1990).
22
[[] Teller, S. & Séquin, C.: Visibility Preprocessing For Interactive Walktroughs,
Computer Graphics (Proceedings SIGGRAPH), Vol. 25, No. 4, pp. 61-69 (1991).
23
[[] Funkhouser, T., Séquin, C. & Teller, S.: Management of Large Amounts of Data
in Interactive Building Walkthroughs, SIGGRAPH Symposium on Interactive 3D
Graphics, pp. 11-20 (1992).
24
[[] Clark, J.: Hierarchical Geometric Models for Visible Surface Algorithms,
Communications of the ACM, Vol. 19, No. 10, pp. 547-554 (1976).
25
[[] Funkhouser, T. & Sequin, C.: Adaptive Display Algorithm for Interactive Frame
Rates During Visualisation of Complex Virtual Environments, Computer Graphics
(Proceedings SIGGRAPH), pp. 247-254 (1993).
26
[[] Falby, J., Zyda, M., Pratt, D. & Mackey, L.: NPSNET: Hierarchical data
structures for realtime 3-dimensional visual simulation. Computers & Graphics, Vol. 17,
No. 1, pp. 65 (1993).
27
[¤ ] Lance, W.: Pyramidal Parametrics, Computer Graphics, vol. 7, no. 3, pp. 1-
11, Julho 1983.
28
[¤ ] Parent, R.: Computer Animation, Algorithms and Techniques, Morgan Kaufman,
2001.
29
[[] Pettigrew, N.: The Stop-Motion Filmography: A Critical Guide to 297 Features
Using Puppet Animation, McFarland & Company Inc.,1999.
30
[d] Watt, A. & Watt, M.: Advanced Animation and Rendering Techniques, theory
and practice, Addison Wesley, 1992.
31
[¤ ] LaMothe, A., Ratcliff, J., Seminatore, M., Tyler, D.: Tricks of the Game
Programming Gurus , Sams Publishing, 1994.
32
[[] R. B. de Araujo e A. L. Battaiola: Jogos 3D Interativos Multiusuários na Internet:
Estado Atual, Perspectivas e Desafios, Relatório Interno do DC/UFSCar, 1998.
33
[[] Chadwick, J.E., Hauemann, D.R. & Parent, R.E.: Layered Construction for
Deformable Animated Characters, Computer Graphics, 23(3), 243-52, (Proc.
SIGGRAPH ’89).
34
[[] Reeves, W.: Simple and Complex Facial Animation, State of the Art in Facial
Animation, SIGGRAPH Course Notes 26, 1990.
35
[[] Lazlo, J.: Controling Bipedal Locomotion for Computer Animation, University of
Toronto, 1996.
36
[[] Sims, K.: Particle Animation and Rendering using Data Parallel Computation,
Computer Graphics, 24(4), 405-13, (Proc. SIGGRAPH ’90).
37
[[] Reev, W.T.: Particle Systems – A Technique for Modelling a Class of Fuzzy
Objects, Computer Graphics, 17(3), 359-76, (Proc. SIGGRAPH ’83).
38
[[] Reynolds, C.W.: Flocks, Herds, and Schools: A Distributed Behavioral Model,
Computer Graphics, 21(4), 25-34, (Proc. SIGGRAPH ’87).
39
[[] Reynolds, C.W.: Computer Animation with Script and Actors, Computer
Graphics, 16(3), 289-96, (Proc. SIGGRAPH ’82).
40
[[] Magnetat-Thalmann, N. & Thalmann, D.: Computer Animation, Theory and
Practice, Springer, Tokyo, 1895.
41
[l ] Disponível em http://www.opengl.org, 02/04/2003.
42
[d Disponível em http://www.microsoft.com/directx, 02/04/2002.
43
[[] Rollings A., Morris D.: Game Architecture and Design, The Coriolis Group LLC,
2000.
44
[[] Hodorowicz, L.: Elements Of A Game Engine. Disponível em
http://www.flipcode.com, 2001.
45
[Ë ] Genesis3D. Disponível em http://www.genesis3d.com, 02/04/2003.
46
[Ë ] Crystal Space. Disponível em http://crystal.sourceforge.net, 02/04/2003.
47
[Ë ] Golgotha. Disponível em http://www.crack.com/golgotha, 02/04/2003.
48
[l ] Madeira, C. & Ramalho, G.: Forge v8 um framework para desenvolvimento de
jogos e aplicações multimídia, Recife, PE, 2001.
49
[¤ ] Fly3D. Disponível em http://www.fly3d.com.br, 02/04/2003.
50
[¤ ] Policarpo, F, Watt, A.: 3D Games: Real-Time Rendering and Software
Technology, Volume 1, Addison-Wesley, 2001.
51
[Ë ] 3D Studio Max, Disponível em www.discreet.com, 02/04/2003.
52
[l ] Cunningham, S.: Computer Graphics: Programming, Problem Solving and
Visual Comunications, 1o. Seminário Latino Americano de Educação em Computação
Gráfica, Escola Politécnica, USP, SP, 2003.
53
[[] Anderson, Eike F.: Real-Time Character Animation for Computer Games,
National Centre for Computer Animation, Bournemouth University, 2001.
54
[¤ ] Meyer, M. et al: Interactive Animation of Cloth-like Objects in Virtual Reality,
Journal of Visualization and Computer Animation, 2000.
55
[¤ ] Voxel, Definido em http://www.gamedev.net/dict, 02/04/2003.
56
[¤ ] Perlin, K. & Ebert, D. S.: Texturing and Modelling – A procedural approach,
AP Professional, 1998.
57
[¤ ] Peitgen, H. et al: Chaos and Fractals: New Frontiers of Science, Springer-
Verlag, New York, 1992.
58
[¤ ] Ebert, D.: Advanced Modelling Techniques for Computer Graphics, ACM
Survey, 1997.
59
[l ] Ferreira, J.M., et al: Sistema Dinâmico de Partículas,
www.lighthouse3d.com/opengl/appstools/dps/, 02/04/2003.
60
[l ] Dominé, S.: Mesh Skinning,
http://developer.nvidia.com/docs/IO/1356/ATT/skinning.pdf, Nvidia Corporation,
02/04/2003
61
[¤ ] Lengyel, E.: Mathematics for 3D Game Programming & Computer Graphics, Charles
River Media, 2002.
62
[¤ ] Woo, M. et al: OpenGL Programming Guide, 3rd. Edition, Addison Wesley,
1999.
63
[¤ ] Miller, L.: Lightmaps (Static Shadowmaps),
www.flipcode.com/tfiles/kurt01.shtml, 02/04/2003.
64
[l ] Vertrix 2, Disponível em http://clusters.cjb.net, 02/04/2003.
65
[¤ ] A. V. Aho, J. E. Hopcroft, and J. D. Ullman.: The Design and Analysis of
Computer Algorithms, Addison-Wesley, 1974.
66
[¤ ] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen: Object-
Oriented Modeling and Design, Prentice-Hall Inc., 1991.
67
[Ë Meyer, B., Object-Oriented Software Construction, ISE Inc., California,
USA,1997.
68
[¤ ] Gamma, Erich, et al.: Design Patterns: Elements of Reusable Object-
Oriented Software, Addison-Wesley, 1995
69
[¤ ] Eberly, D. H., 3D Game Engine Design: A Practical Approach to Real-Time
Computer Graphics, Morgan Kaufmann Publishers, 2001.
70
[Ë Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I. &
Angel, S.: A Pattern Language, Oxford University Press, New York, 1977.
71
[¤ ] Johnson, Ralph E., Frameworks = (Components + Patterns),
Communications of the ACM, Vol.40, N o 10, October, 1997.
72
[¤ ] Eriksson, H.-E. and Penker, M.: UML Toolkit, John Wiley, 1998.
73
[¤ ] Booch, G.: Object-Oriented Analysis and Design with Applications,
Addison-Wesley, Readings, Massachusetts, second edition, 1994.
74
[¤ ] Fowler, M. and Scott, K.: UML Distilled: Applying the Standard Object
Modeling Language, Addison-Wesley, Reading, Mass., 1997.
75
[¤ ] Johnson, R.E., Foote, B.: Designing Reusable Classes, Journal of Object
Oriented Programming, Vol. 1, no. 2, 1988.
76
[¤ ] Krasner, G.E., et al: A Cookbook for using the Model-View-Controller User
Interface Paradigm in Smalltalk-80, Journal of Object Oriented Programming, Vol. I,
No. 3, pp.26-49.
77
[¤ ] Webster, B.F.: The NeXT Book, Addison Wesley, Reading, MA, 1989.
78
[¤ ] Schmucker, K.J.: Object Orientation, MacWorld, Vol. 3, No 11, Novembro,
1986, pp. 119-123.
79
[¤ ] Weinand, A., Gamma, E. e Marty, R.: Design and Implementation of ET++, a
Seamless Object-Oriented Application Framework, Structured Programming, Vol. 10,
No. 2, pp.63-87, 1989.