MAC0499 - Trabalho de Formatura Supervisionado
Modelador de Sólidos e Editor de Cenas
Tridimensionais
Aluno: Marcelo Kenzo Yamada
Orientador: Prof.
João Antonio Zuffo
Co-orientador: Prof. Marcelo Knörich Zuffo
Supervisor: Prof. Alfredo Goldman vel Lejbman
Tipo de trabalho: IC
Primeira Parte
Introdução
Natureza da
organização e da atividade
Motivação
Objetivos do trabalho
Descrição
do software
Forma de
organização da equipe de trabalho e
atribuição de responsabilidades
Estimativa inicial de
prazos e do andamento do projeto
Atividades realizadas
Métricas
post-mortem do andamento do
projeto
Forma de
acompanhamento utilizada pelo gerente/administrador do projeto
Conclusão
Bibliografia utilizada
Segunda Parte
Desafios e
frustrações encontrados
Lista das disciplinas
cursadas no BCC mais relevantes para o projeto
Interação
com membros da equipe que tenham agido como
mentores do trabalho
Diferenças
notadas entre a forma de cooperação com
colegas do BCC nas tarefas em grupo das disciplinas e a forma de
trabalho conjunto no laboratório
Se fosse continuar
atuando na área do projeto, que passos
tomaria para aprimorar os conhecimentos
técnicos/metodológicos/comerciais/científicos/etc
relevantes para esta atividade
Figuras
Figura 1: tela inicial
Figura 2: recuperando um arquivo de dados de
cena
Figura 3: após abrir um arquivo
de dados de cena
Figura 4: opções do menu
edit
scene
Figura 5: opções
do menu edit scene->object
Figura 6: selecionando o segundo
objeto com o comando up
Figura 7: selecionando o terceiro
objeto com o comando up
Figura 8: após remover o cone com o
comando delete
Figura 9: após mover o toro com o
comando move
Figura 10: mudando a escala de um objeto
Figura 11: resultado da
mudança de escala sobre o toro
Figura 12: resultado da
mudança de orientação do sistema de coordenadas de
um objeto
Figura 13: após mover o toro
Figura 14: adicionando um cone, entrada de
deslocamento
Figura 15: adicionando um cone, entrada de
deslocamento
Figura 16: adicionando um cone, entrada do
raio
Figura 17: adicionando um cone, entrada da
altura do cone
Figura 18: adicionando um cone, entrada do
número de seções
Figura 19: adicionando um cone, com o cone
posicionado na origem do sistema de coordenadas globais, aguardando
translado e fixação
Figura 20: adicionando um cone, fixando o
cone (final do comando de adição)
Figura 21: menu principal do editor
de sólidos
Figura 22: arquivo recuperado de
disco
Figura 23: menu rotate
Figura 24: menu show mostrando a
projeção paralela do sólido sobre o plano xy
Figura 25: menu show mostrando a
projeção paralela do sólido sobre o plano yz
Figura 26: menu show mostrando a
projeção paralela do sólido sobre o plano zx
Figura 27: adicionando um vértice
Figura 28: adicionando um vértice
Figura 29: adicionando um vértice
Figura 30: inserindo um vértice
antes do último da lista
Figura 31: inserindo um vértice
entre o primeiro e o segundo vértice
Figura 32: inserindo um vértice
no início da lista
Figura 33: adicionando um
vértice após as inserções acima
Figura 34: removendo um vértice
com o comando delete
(vertex)
Figura 35: resultado do comando
delete
(vertex)
Figura 36: movendo um vértice com o
comando move
(vertex)
Figura 37: resultado do comando move
(vertex)
Figura 38: o sólido de
revolução gerado pelo corte
da figura 37 (projeção sobre o plano xy)
Figura 39: o sólido de
revolução gerado pelo corte
da figura 37 (projeção sobre o plano yz)
Figura 40: o sólido de
revolução gerado pelo corte
da figura 37 (projeção sobre o plano zx)
Figura 41: adicionando um sólido
gerando no editor de
sólidos
Figura 42: sólido de
revolução inserido na origem do
sistema de coordenadas globais
Figura 43: usando o comando de escala
sobre objeto para redimensionar um
sólido na cena
Figura 44: resultado da
mudança de escala de um sólido
Figura 45: deslocamento de um sólido
com o comando move
Figura 46: mudando as
coordenadas do observador
Figura 47: mudando as
coordenadas do observador
Figura 48: cena formada por três
primitivas (cone, cilindro e
seção de cone)
Figura 49: sólido de
revolução com valores
diferentes do default (ângulo de 1.4*PI)
Figura 50: corte de uma
taça
Figura 51: taça gerada
pelo corte da figura 50 vista no editor de
sólidos (plano xy)
Figura 52: taça gerada
pelo corte da figura 50 vista no editor de
sólidos (plano zx)
Figura 53: taça gerada pelo
corte da figura 50 vista no editor de
cenas
Primeira Parte
Introdução
O trabalho é sobre a IC (iniciação
científica) com bolsa do CNPq
realizada de
maio de 1990 a fevereiro de 1992, no Grupo de Computação
Gráfica do LSI
(Laboratório de
Sistemas Integráveis da Escola
Politécnica da
Universidade de São Paulo),
quando foi desenvolvido um sistema de computação
gráfica para a geração
de imagens tridimensionais sob a orientação do Professor
João Antonio Zuffo e co-orientação do Professor
Marcelo K. Zuffo.
Natureza da organização e da
atividade
O laboratório faz parte da Faculdade de Engenharia
Elétrica da Escola Politécnica da USP, e portanto visa a
pesquisa, o desenvolvimento de conhecimento científico, e a
preparação e introdução de seus alunos
à pesquisa acadêmica. O projeto foi exclusivamente de
software, visando a integração com sistemas de hardware
que estavam sendo desenvolvidos no laboratório naquela
época.
Por se tratar de um projeto exclusivamente de software e
desenvolvido a partir do zero não houve dependências
significativas por recursos materiais ou resultados externos.
Motivação
A principal motivação para o desenvolvimento de um
pacote de software desta natureza era o domínio do código
fonte. Na época existiam pacotes prontos para ambientes de ponta
(estações gráficas de alto desempenho), entretanto
não eram abertos. Estavam sendo desenvolvidos projetos de
hardware no laboratório (LSI) sobre paralelização
maciça (na época, dezenas de processadores fortemente
acoplados), e uma das principais aplicações em mente era
a paralelização do processamento de imagens, onde se
visava eventualmente alcançar o processamento em tempo real.
Objetivos
do trabalho
O objetivo era ter ao final um pacote de software
totalmente desenvolvido no laboratório que pudesse ser
rapidamente otimizado para diferentes plataformas de hardware, com o
intuito de usar o conjunto como demonstração de
poder de computação.
Descrição
do software
Introdução
Um modelador de sólidos é um programa que permite que o
usuário gere dados que descrevem sólidos mais facilmente
do que editando arquivos de dados manualmente. Um sólido de
revolução é um objeto
tridimensional que foi ou ao menos pode ser gerado a partir da
rotação de um corte bidimensional ao redor de um eixo.
Similar a um sólido de revolução, um sólido
de extrusão foi ou pode ser gerado a partir de uma
translação de um corte bidimensional.
Um editor de cenas tridimensionais permite que o usuário gere
dados que descrevem uma cena composta geralmente por diversos objetos e
um observador mais facilmente do que editando arquivos de dados
manualmente.
O software desenvolvido nesse projeto permitia que o usuário
criasse sólidos de revolução e de extrusão
e os combinasse com diversas primitivas disponíveis para
compor
cenas. Essas cenas eram então "alimentadas" em programas de
visualização em
alta definição para gerar imagens foto-realísticas.
Os cortes bidimensionais eram desenhados no modelador de sólidos
com um mouse (ou teclado). Os pontos (vértices) eram ligados por
linhas que mostravam a forma do corte. Esses vértices podiam ser
modificados através de opções disponíveis
no menu de edição (inserção,
remoção e deslocamento), e os sólidos de
revolução podiam não ser de
revolução completa (360 graus).
Uma vez com os objetos (sólidos) gerados e salvos em disco,
podia-se adicioná-los a cenas tridimensionais no Editor de
Cenas. Lá era possível modificar o posicionamento dos
sólidos tanto em coordenadas de origem como também em
orientação no espaço. Também era
possível realizar transformações como mudar a
escala de objetos, mantendo as proporções entre eixos ou
não, tudo individualmente ou na cena como um todo. Naturalmente
o observador também podia ser movido, assim como a sua
direção de vista, ambos interativamente, o que dava um
primitivo "walk-through".
Funcionamento
Ao iniciar o programa encontrava-se no modo
tridimensional, sem nenhuma cena carregada. A tela era
constituída de um viewport para a visualização de
imagens que ocupava quase que a sua totalidade, três conjuntos de
coordenadas tridimensionais no canto superior direito para coordenadas
do cursor, do observador e do ponto de observação,
respectivamente, e pelo menu principal, que tinha quatro
opções: file, edit scene, edit lib e quit.
Figura 1: tela inicial
Clicando-se em file entrava-se no menu file, com as
seguintes
opções: dir, open, save, new e exit. dir mostrava os
arquivos do diretório corrente a partir de onde o programa havia
sido carregado, open
carregava os dados de uma cena gravados em disco, save gravava os
dados da cena atualmente em memória no disco, new inicializava
todas as estruturas de dados, variáveis e memória,
e exit
voltava ao menu principal.
Figura 2: recuperando um arquivo de
dados de cena
Figura 3: após abrir um
arquivo de dados de cena
Entrando no menu edit
scene a
partir do menu principal eram mostradas as seguintes
opções: object, move, proportion, scale, observer e exit.
Figura 4: opções do
menu edit scene
O submenu object
apresentava as opções up, down, add, delete, move, orientat, proportion, scale e exit. Uma cena
podia e geralmente era composta por mais de um sólido, ou
objeto, sendo que dentro do submenu object
manipulava-se os objetos individualmente. O objeto selecionado era
mostrado em wireframe vermelho, e os demais em wireframe ciano.
Para selecionar outro objeto na cena eram usados os comandos up e down, que
percorriam a lista ligada de objetos nos dois sentidos, circularmente. add adicionava
um objeto ao final da lista, e podia ser tanto uma primitiva como um
sólido gerado no editor de sólidos. delete removia o
objeto selecionado, move deslocava a
origem do sistema de coordenadas do objeto selecionado para outro ponto
no espaço tridimensional interativamente através do uso
do mouse ou do teclado. orientat, de
orientation, permitia que a orientação do sistema
de coordenadas do objeto selecionado fosse redefinida, assim
conseguindo rotações do objeto selecionado. proportion e scale
modificavam o tamanho do objeto selecionado, mas diferiam em um
aspecto: scale
era o caso específico em que todos os três fatores de
escala recebiam o mesmo valor, fazendo um zoom usual do objeto.
Já proportion
permitia que os fatores de escala fossem atribuídos
independentemente para cada eixo (x, y, z), deformando o objeto. exit
voltava ao menu edit
scene.
Figura 5: opções
do menu edit scene->object
Figura 6: selecionando o segundo
objeto com o comando up
Figura 7: selecionando o terceiro
objeto com o comando up
Computer
Graphics: Principles and Practice
Figura 8: após remover o cone com
o comando delete
Figura 9: após mover o toro com o
comando move
Figura 10: mudando a escala de um objeto
Figura 11: resultado da
mudança de escala sobre o toro
A orientação default de objetos é (0,1,0) para o
vetor que aponta para cima e (0,0,1) para o vetor que aponta para
frente. Na figura 12 vemos o resultado da mudança de
orientação do sistema de coordenadas do toro de default
para {(0,0,1), (0, -1, 0)}. O resultado é uma
rotação do objeto nas coordenadas globais (mundo).
Figura 12: resultado da
mudança de orientação do sistema de coordenadas de
um objeto
Figura 13: após mover o toro
A adição de primitivas passava por uma
seqüência de entradas via teclado de acordo com a primitiva
que fosse selecionada (raio, altura, número de
seções, etc), e no último passo o objeto era
mostrado na cena e era transladado como no comando move até
ser fixado.
Figura 14: adicionando um cone, entrada de
deslocamento
Figura 15: adicionando um cone, entrada de
deslocamento
Figura 16: adicionando um cone, entrada do
raio
Figura 17: adicionando um cone, entrada da
altura do cone
Computer
Graphics: Principles and Practice
Figura 18: adicionando um cone, entrada do
número de seções
Figura 19: adicionando um cone, com o cone
posicionado na origem do sistema de coordenadas globais, aguardando
translado e fixação
Figura 20: adicionando um cone, fixando o
cone (final do comando de adição)
Para adicionar um sólido gerado no editor de sólidos era
mais simples, bastava ao selecionar ED LIB entrar com o nome do arquivo
contendo os dados do sólido e caíamos direto na
última etapa, onde o sólido era mostrado na
posição default (origem do sistema de coordenadas
globais), movido e depois fixado na
cena.
Os comandos move,
proportion
e scale do
menu edit scene
eram análogos aos mesmos comandos específicos para cada
objeto (menu object),
mas aplicavam-se à cena como um todo. Assim, move transladava
todos os objetos da cena, e proportion e scale faziam
escalas não-proporcionais e proporcionais de todos os objetos,
respectivamente. O comando observer
permitia que fossem mudadas as coordenadas do observador, tanto a sua
posição como o ponto de observação (para
onde o observador olha, definindo assim a direção). exit
naturalmente voltava ao menu principal.
No menu principal, edit
lib levava ao editor de sólidos, que tinha como comandos:
file, rotate, stretch, twist, show, insert, delete, move e exit. file levava ao
menu de tratamento de arquivos, com as mesmas opções do
seu equivalente para cenas: dir, open, save, new e exit, com
funções equivalentes agora para arquivos no formato do
editor de sólidos, apenas save não
possuindo
opções de formato.
Figura 21: menu principal do
editor de sólidos
Figura 22: arquivo recuperado de
disco
O menu rotate
tinha as opções: stages, angle, axis, calculate e exit. stages permitia
entrar/alterar o número de seções ou setores, e
sector
teria sido uma escolha melhor para o seu nome. angle permitia
entrar/alterar o ângulo da rotação em reais
múltiplos de PI, isto é, um ângulo de 2.0
representava 2.0 * PI, ou seja, um rotação de 360 graus. axis definia o
eixo ao redor do qual o corte bidimensional deveria ser rotacionado (x
ou y), sendo y o default. Finalmente calculate gerava
os pontos tridimensionais, e exit voltava ao
menu principal do editor de sólidos.
Como para todas as variáveis existiam valores default, era
possível apenas clicar sobre calculate para
se ter idéia do sólido, e caso fosse necessário ou
desejado podia-se então alterar esses valores.
Figura 23: menu rotate
stretch
gerava sólidos por extrusão a partir do corte
bidimensional e de valores para profundidade e deslocamentos em x e em
y. twist
fazia rotações planas sobre a segunda face gerada por stretch, gerando
torções sobre esses prismas.
show
mostrava três possíveis projeções: sobre o
plano xy, sobre o plano yz, e sobre o plano zx.
Figura 24: menu show mostrando a
projeção paralela do sólido sobre o plano xy
Figura 25: menu show mostrando a
projeção paralela do sólido sobre o plano yz
Figura 26: menu show mostrando a
projeção paralela do sólido sobre o plano zx
A inserção de vértices se dava na forma default
como uma função append, ou seja,
eram adicionados novos
vértices ao final da lista. Para se inserir vértices no
início ou no meio da lista era necessário selecionar insert (clicar
sobre insert
para mudar a cor para vermelho), e então clicar com
o mouse próximo ao ponto que deve ser o posterior ao novo ponto
inserido. Dessa forma era possível inserir pontos mesmo no
início da lista, bastando para isso selecionar o primeiro ponto.
A inserção default (final da lista) se dava com a
opção insert
desativada, ou seja, na cor branca.
Figura 27: adicionando um
vértice
Figura 28: adicionando um
vértice
Figura 29: adicionando um
vértice
Computer
Graphics: Principles and PracticeComputer Graphics:
Principles and Practice
Figura 30: inserindo um
vértice antes do último da lista
Figura 31: inserindo um
vértice entre o primeiro e o segundo vértice
Figura 32: inserindo um
vértice no início da lista
Computer
Graphics: Principles and Practice
Figura 33: adicionando um
vértice após as inserções acima
Selecionando-se delete
(mudava a cor para vermelho no menu) era
possível
remover vértices, bastando clicar no viewport próximo ao
vértice a ser removido. O vértice mais próximo ao
cursor era selecionado, e uma mensagem de confirmação era
mostrada.
Figura 34: removendo um vértice
com o comando delete
(vertex)
Figura 35: resultado do comando
delete
(vertex)
Para mover um vértice usava-se o comando move. Da mesma
forma que insert
e delete,
selecionava-se o vértice desejado com o mouse (o mais
próximo ao clicar era o selecionado), e ao posicionar o cursor
sobre a
nova coordenada desejada bastava clicar novamente. Uma mensagem pedia a
confirmação da fixação do ponto.
Figura 36: movendo um vértice com
o comando move
(vertex)
Figura 37: resultado do comando
move
(vertex)
Exemplos adicionais:
Figura 38: o sólido de
revolução gerado pelo corte da figura 37
(projeção sobre o plano xy)
Figura 39: o sólido de
revolução gerado pelo corte
da figura 37 (projeção sobre o plano yz)
Figura 40: o sólido de
revolução gerado pelo corte
da figura 37 (projeção sobre o plano zx)
Figura 41: adicionando um sólido
gerado no editor de sólidos
Figura 42: sólido de
revolução inserido na origem do
sistema de coordenadas globais
Figura 43: usando o comando de escala
sobre objeto para redimensionar um
sólido na cena
Figura 44: resultado da
mudança de escala de um sólido
Figura 45: deslocamento de um
sólido com o comando move
Figura 46: mudando as
coordenadas do observador
Figura 47: mudando as
coordenadas do observador
Figura 48: cena formada por
três primitivas (cone, cilindro e
seção de cone)
Figura 49: sólido
de revolução com valores
diferentes do default (ângulo de 1.4*PI)
Figura 50: corte de uma
taça
Figura 51: taça gerada
pelo corte da figura 50 vista no editor de
sólidos (plano xy)
Figura 52: taça gerada
pelo corte da figura 50 vista no editor de
sólidos (plano zx)
Figura 53: taça gerada
pelo corte da figura 50 vista no editor de
cenas
Estrutura dos menus:
Parte Técnica
O software foi totalmente escrito em linguagem C. Não foi
utilizado nenhum ambiente de programação
específico ou bibliotecas além das padrões da
linguagem, e foram escritas funções para absolutamente
tudo apenas em C. Desta forma desde funções para mostrar
o cursor, desenhar linhas na janela gráfica, exibir textos (para
montar menus, pedir confirmação, carregar/salvar
arquivos,
etc) e tudo o que o
software necessitou para funcionar foi escrito a partir do zero, e
podia ser compilado (a princípio) em qualquer plataforma. Apenas
as funções do mouse é que eram específicas
para cada arquitetura, mas a funcionalidade a partir do teclado era
justamente para que o software, mesmo que perdesse facilidade de uso,
sempre fosse usável.
O princípio básico para saber onde mostrar um ponto na
tela é simples. Basta encontrar a interseção da
semi-reta definida por esse ponto no espaço tridimensional e as
coordenadas do observador com o plano da tela. Se acharmos os dois
extremos de uma semi-reta sobre o plano de projeção
(tela), unindo-os temos a projeção dessa semi-reta. Tanto
no Modelador como no Editor de Cenas foram usadas apenas semi-retas
para
gerar todos os gráficos. Esferas, bases de cilindros e cones,
etc, eram representados por aproximações
(seções como em sólidos de
revolução).
Triângulos são geralmente usados para modelar
sólidos tridimensionais, pois três pontos distintos
definem um plano e não corre-se o risco de especificar quatro
pontos (supostamente) coplanares que não estão de fato no
mesmo
plano. Entretanto, pela natureza dos sólidos gerados pelo
Modelador foram usados sólidos parametrizados com
trapézios. Observe que tanto sólidos de
revolução como extrusões geram faces
trapezóides ou até mesmo retangulares. Isso gerava uma
economia de aproximadamente 33% no tamanho do arquivo de dados,
já que cada face com quatro pontos substituía duas faces
com três pontos cada.
Exemplo 1:
P4 0.0 0.0 0.0 1.0 0.0 0.0 1.0 1.0 0.0 0.0
1.0 0.0
para um quadrado contra
P3 0.0 0.0 0.0 1.0 0.0 0.0 0.0 1.0 0.0
P3 0.0 1.0 0.0 1.0 0.0 0.0 1.0 1.0 0.0
para dois triângulos que fariam o mesmo efeito.
Era possível salvar os dados tanto nos formatos internos dos
editores como também no formato NFF, usado pelos programas de
renderização disponíveis no laboratório na
época.
Forma de organização da
equipe de trabalho e atribuição de responsabilidades
O projeto foi desenvolvido individualmente sob a supervisão
do co-orientador, o que eliminou diversas dificuldades pertinentes a
sincronização de membros da equipe e divergências
tanto técnicas como não, e pelo mesmo motivo a
distribuição do trabalho foi trivial.
Anterior ao início do projeto houveram reuniões onde o
co-orientador averiguou a adequação do estagiário
ao
perfil desejado. O estagiário já estava desenvolvendo por
conta própria sistemas semelhantes para uso pessoal, e este
sincronismo de interesses foi determinante para o fluxo quase ideal no
ritmo de desenvolvimento ao longo de todo o projeto.
Em determinadas ocasiões, entretanto, alguns resultados do
trabalho foram postos a prova, quando dados gerados pelo software em
desenvolvimento foram usados por outros pesquisadores do
laboratório para apresentações em eventos
organizados pelo laboratório ou onde o mesmo estava presente,
com modelos sendo gerados na hora e alimentados em geradores de imagens
de alta definição para demonstração em
estandes. Nestas ocasiões a não-conformidade ou
não-corretude das saídas geradas seria vergonhosa para o
laboratório como um todo.
Estimativa inicial de prazos e do andamento
do projeto
Teve-se como meta seguir o seguinte cronograma:
Mês
|
Atividades
programadas
|
| Maio/1990 |
|
| Junho/1990 |
|
| Julho/1990 |
- Estudo de bibliografia;
- Especificação do modelador.
|
| Agosto/1990 |
- Implementação do modelador.
|
| Setembro/1990 |
- Implementação do modelador.
|
| Outubro/1990 |
- Implementação do modelador.
|
| Novembro/1990 |
- Implementação do modelador.
|
| Dezembro/1990 |
- Testes do modelador e ajustes/correções.
|
| Janeiro/1991 |
- Testes do modelador e ajustes/correções.
|
| Fevereiro/1991 |
- Confecção de relatórios dos trabalhos
realizados em 1990.
|
| Março/1991 |
|
| Abril/1991 |
- Estudo de bibliografia;
- Especificação do editor de cenas;
- Ajustes na implementação do modelador para
acomodar
eventuais mudanças.
|
| Maio/1991 |
- Implementação do editor de cenas.
|
| Junho/1991 |
- Implementação do editor de cenas.
|
Julho/1991
|
- Implementação do editor de cenas.
|
| Agosto/1991 |
- Implementação do editor de cenas.
|
| Setembro/1991 |
- Implementação do editor de cenas.
|
| Outubro/1991 |
- Testes do sistema e ajustes/correções.
|
| Novembro/1991 |
- Implementação das funções de
animação (possivelmente).
|
| Dezembro/1991 |
- Implementação das funções de
animação (possivelmente).
|
| Janeiro/1992 |
- Implementação das funções de
animação (possivelmente);
- Testes e ajustes/correções.
|
| Fevereiro/1992 |
- Confecção de relatórios finais dos
trabalhos
realizados.
|
Atividades
realizadas
Resumo das atividades realizadas durante o projeto:
Mês
|
Atividades
realizadas
|
| Maio/1990 |
|
| Junho/1990 |
|
| Julho/1990 |
- Estudo de bibliografia;
- Especificação do modelador.
|
| Agosto/1990 |
- Implementação do modelador.
|
| Setembro/1990 |
- Implementação do modelador.
|
| Outubro/1990 |
- Implementação do modelador.
|
| Novembro/1990 |
- Implementação do modelador.
|
| Dezembro/1990 |
- Implementação do modelador.
|
| Janeiro/1991 |
- Implementação do modelador;
- Testes com a geração de imagens renderizadas
a
partir de sólidos
modelados com o sistema KAD (nome dado ao sistema projetado).
|
| Fevereiro/1991 |
- Confecção de relatórios dos trabalhos
realizados em 1990.
|
| Março/1991 |
- Ajustes na implementação do modelador;
- Especificação do editor de cenas.
|
| Abril/1991 |
- Ajustes na implementação do modelador;
- Especificação do editor de cenas.
|
| Maio/1991 |
- Implementação do editor de cenas.
|
| Junho/1991 |
- Implementação do editor de cenas.
|
Julho/1991
|
- Implementação do editor de cenas.
|
| Agosto/1991 |
- Implementação do editor de cenas.
|
| Setembro/1991 |
- Implementação do editor de cenas.
|
| Outubro/1991 |
- Testes do sistema e ajustes/correções.
|
| Novembro/1991 |
- Estudo de pacotes de modelagem, renderização
e
animação para o então recém
adquirido supercomputador Silicon
Graphics (IRIS 4D/480VGX).
|
| Dezembro/1991 |
- Estudo de pacotes de modelagem, renderização
e
animação para o então recém
adquirido supercomputador Silicon Graphics (IRIS 4D/480VGX).
|
| Janeiro/1992 |
- Estudo de pacotes de modelagem, renderização
e
animação para o então recém
adquirido supercomputador Silicon Graphics (IRIS 4D/480VGX).
|
| Fevereiro/1992 |
- Confecção de relatórios finais dos
trabalhos
realizados.
|
Métricas post-mortem do andamento do
projeto
Como pode-se observar na duas seções anteriores, o
cronograma inicial foi seguido praticamente de ponta a ponta. Houve
atrasos na fase de implementação do modelador, quando
ainda havia menos experiência tanto de
programação como em fazer estimativas por parte do
desenvolvedor, mas a seqüência do trabalho mostra que essa
deficiência foi superada durante o processo.
Por ter cumprido com o cronograma proposto inicialmente até a
mudança de foco em novembro de 1991 e ter produzido o pacote com
o modelador de sólidos e o editor de cenas dentro do prazo
previsto pode-se afirmar que o projeto foi concluído com sucesso.
Forma de acompanhamento utilizada pelo
gerente/administrador do projeto
Eram feitas reuniões a cada dois a três meses para que
o co-orientador pudesse verificar se o andamento do projeto estava de
acordo com o cronograma previsto. Não houveram problemas nem
grandes divergências ao longo de todo o processo, e por isso o
acompanhamento em si tomou pouco tempo (diversas fatias muito pequenas
de tempo). Havia um controle de horas trabalhadas por semana, que era
flexível como para todos os demais estagiários do
laboratório em função de épocas de provas e
finais de semestre. Em épocas de férias escolares ou
academicamente menos complicadas ao longo dos semestres era comum se
trabalhar bem mais do que o estabelecido, assim como em épocas
mais complicadas em termos acadêmicos era comum descontar dessas
horas acumuladas para dedicar mais tempo aos estudos
universitários, como hoje é conhecido esse sistema em
diversas empresas pelo nome de banco de horas.
Conclusão
Ao final do período da IC o software (com
exceção do módulo de animação)
estava pronto e funcional. Era possível modelar sólidos e
compor cenas tridimensionais em wireframe, e exportar ambos
para programas de visualização existentes nas
estações gráficas da Sun,
no
então recém adquirido supercomputador gráfico da
Silicon Graphics, assim como para o hardware desenvolvido no
laboratório. Com a aquisição do supercomputador,
os
últimos meses da IC foram usados para o estudo e
familiarização com este e alguns dos diversos pacotes
gráficos disponíveis para ele.
O projeto foi dado como concluído com sucesso. Além
da grande quantidade de conhecimento técnico adquirida ao longo
do processo houve o aprendizado com a participação em um
projeto de maior duração onde é exigido maior grau
de planejamento e comprometimento, o convívio com outros membros
da comunidade acadêmica de quem muito foi assimilado tanto em
conhecimento como em postura e ética de trabalho, pesquisa e
atitude, e a obrigatoriedade de prestar contas tanto para superiores
como para um órgão financiador.
Sem dúvida foi uma experiência marcante que
acrescentou muito à minha bagagem cultural e profissional.
Bibliografia
utilizada
FOLE90 Foley, J., A. van Dam, S. Feiner, and J. Hughes,
Computer Graphics: Principles and
Practice - 2nd ed.
Segunda Parte
Desafios e
frustrações encontrados
A maior dificuldade encontrada foi não ter domínio
suficiente sobre o projeto antes das fases de
codificação. Não foi feito nenhum estudo
prévio de como dividir os módulos, apenas foram definidas
as funcionalidades desejadas, e a codificação ficou
totalmente a cargo do programador. Teria sido consideravelmente mais
fácil escrever o código somente após ter
especificado todo o problema.
Lista das disciplinas cursadas no BCC mais
relevantes para o projeto
Apesar de na época não estar cursando Ciência da
Computação e portanto não ter podido tirar
proveito das matérias do BCC, é
possível listar uma relação de matérias que
poderiam ter sido ou mesmo que foram aplicadas no
projeto.
MAT-112 - Vetores e Geometria
Analítica, atualmente parcialmente englobada em MAT-139 -
Álgebra Linear para Computação: Essa disciplina
foi fundamental, pois sem ela não seria possível sequer
tratar o problema de parametrização e
transformações lineares. É a base
matemática de todo o projeto.
MAC-332 - Engenharia de Software:
Infelizmente muito pouco valorizada por muitos colegas que estudaram
comigo no BCC na época em que a cursamos. Na época da IC
eu dispunha apenas de alguns dos seus conceitos, e mesmo assim
não formalmente. Teria ajudado tremendamente na
especificação do cronograma, com menor margem de erro e
provavelmente diminuindo também o tempo gasto em
codificação. Posteriormente eu aprendi arduamente
diversos dos conceitos de Engenharia de Software no mercado de
trabalho, e tenho essa matéria como uma das mais importantes do
currículo do BCC, já que parece-me que a parte
técnica, seja ela matemática ou de
codificação, é sempre mais fácil de ser
assimilada individualmente, e a importância da parte
administrativa e de planejamento de projetos de
computação é muitas vezes subestimada.
MAC-211 - Laboratório de
Programação I e MAC-242
- Laboratório de Programação II: Por
motivos óbvios os laboratórios de
programação teriam dado maior experiência e
familiaridade com ambientes de programação e
compilação que eu não tinha tido prévio
contato.
MAC-122 - Princípios de Desenvolvimento de
Algoritmos: Foram usadas listas de estruturas (ligadas e
duplamente ligadas) e reordenações. Conceitos vistos em
MAC-122 teriam diminuído a quantidade de leitura
necessária na ocasião.
Apesar de ter usado poucos conceitos dados no BCC para este projeto,
é ao meu ver importante salientar que a maioria das
matérias obrigatórias do departamento de
Computação (MAC) presentes no atual currículo do
BCC são importantes para a formação profissional
na área para quem não pretende seguir carreira
acadêmica. Para o segundo grupo eu imagino que as demais,
inclusive dos outros departamentos, devem ser igualmente importantes.
Interação
com membros da equipe que tenham agido como
mentores do trabalho
O desenvolvimento foi feito por uma equipe de um desenvolvedor
apenas, e por isso não houve conflitos ou problemas de
interação. Para simplificar ainda mais o andamento do
projeto, em praticamente todos os tópicos os orientadores e o
orientado tinham posições/visões equivalentes ou
muito próximas, e não houve necessidade de
intervenção por parte dos primeiros. Havia
interação com outros desenvolvedores do mesmo grupo
(Grupo de Computação Gráfica) para ajuda
mútua, e era comum trocar idéias e sugestões com
colegas desenvolvedores. Com isso muitos erros eram descobertos com a
ajuda de colegas (multilateral).
Em nenhum momento houve conflito ou atrito com outros membros do
grupo.
Diferenças
notadas entre a forma de cooperação com
colegas do BCC nas tarefas em grupo das disciplinas e a forma de
trabalho conjunto no laboratório.
Esse é um ponto fraco na minha forma de trabalhar. Eu sou
deficiente em ambientes de grupo. Eu sempre gostei de estudar sozinho,
trabalhar sozinho, praticar esportes individuais, em especial esportes
que dependem mais do que o normal de concentração e
dedicação ao treino. O trabalho no LSI pode ser
desenvolvido com certa facilidade porque não era um trabalho em
equipe. O software foi desenvolvido por apenas uma pessoa, com a ajuda
de colegas de trabalho assim como eu também tive a oportunidade
de ajudar a outros. Eu já trabalhei em diversas empresas, e em
todas nas quais eu fiz trabalho de desenvolvimento
(programação), acabei fazendo sozinho. Dessa forma, ser
obrigado a trabalhar em equipe durante o BCC foi uma experiência
positiva, já que por conta própria eu não tomaria
uma iniciativa dessas.
De uma forma geral eu posso dizer que ficou mais claro ainda aos
meus olhos a importância de conceitos de Engenharia de Software.
Ferramentas de auxílio para cooperação em
desenvolvimento de código podem ajudar, mas nada
comparável ao entrosamento de uma equipe. Se para projetos
pequenos como trabalhos escolares é possível resolver
impasses apenas com diálogos, isso certamente não
é verdade para projetos de grande porte. Planejamento e formas
de expressar definições com precisão são
fundamentais para o desenvolvimento de trabalhos em equipe.
Se fosse continuar
atuando na área do projeto, que passos
tomaria para aprimorar os conhecimentos
técnicos/metodológicos/comerciais/científicos/etc
relevantes para esta atividade
Na época eu mantive contato ainda por um tempo com
pesquisadores do laboratório que tinham interesse na mesma
área, e mantive ainda por alguns anos as assinaturas de revistas
como a Computer e a Computer Graphics and Applications,
ambas do IEEE, além de
comprar alternadamente exemplares de outras publicações
periódicas relacionadas. Eu já possuía os
principais
livros textos no assunto.
Se fosse voltar para essa área eu com certeza primeiro
buscaria contato com pesquisadores que estão envolvidos com o
assunto atualmente para saber quais campos de conhecimento eu tenho
maior necessidade de atacar primeiro, para ter alguma
noção do que está sendo feito e principalmente do
que ainda não foi feito. Já se fosse para mudar o enfoque
de científico para comercial, além das medidas acima eu
entraria em contato com algumas empresas líderes em
computação gráfica, como a ILM, por exemplo. Trabalhar em
estúdios de cinema para desenvolver novas técnicas de
animação/visualização também
não está fora das minhas considerações.
2005/02/13 Kenzo Yamada