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

Alumas definições antes de descrever o software:

Funcionamento

Modelador de Sólidos

O Modelador de Sólidos foi o primeiro módulo desenvolvido, sendo que ao final do primeiro ano de trabalho operava como um software independente. Ao concluir o Editor de Cenas Tridimensionais o Modelador de Sólidos passou a ser apenas um dos módulos do programa principal.

O Modelador funcionava com uma janela gráfica que ocupava quase toda a tela e um menu ao lado direito. Esta janela mostrava o sólido em edição nos planos xy, xz ou yz, sempre em projeção paralela. O menu a direita possuia a seguintes opções: file, transform, show, edit (subdividido em insert, delete e move) e quit, sendo que quit foi trocado por exit ao incorporar o Modelador no Editor de Cenas. A operação era feita através de mouse ou teclado, sendo que no segundo caso as teclas de setas para cima, baixo, direita e esquerda movimentavam o cursor e as teclas "espaço" e "enter" operavam como os botões esquerdo e direito do mouse, respectivamente. Para selecionar uma opção no menu bastava clicar com o cursor sobre a mesma. Dentro da janela gráfica um clique com o botão esquerdo do mouse ativava a função selecionada (apenas uma das funções de edição podia estar ativa de cada vez, e se nenhuma estivesse ativa a função ativa era append), p.e., no caso de append (o menu, branco, tinha a opção ativa em amarelo, então nesse caso com todas as três opções de edição na cor branca) era adicionado um ponto ao final da lista de pontos com as coordenadas atuais. Se delete estivesse ativo, o ponto com a menor distância do mouse era selecionado (as linhas verdes de conexão a esse ponto eram substituídas por linhas vermelhas, e uma linha ciano era mostrada conectanto o ponto anterior ao posterior, mostrando como ficaria o desenho após a remoção) e uma janela pedindo a confirmação da remoção era exibida. Move funcionava de forma semelhante a delete, selecionando o ponto mais próximo ao cursor e transformando as suas linhas de ligação com os pontos imediatamente anterior e posterior da lista em linhas elásticas na cor ciano que acompanhavam o cursor até que o botão esquerdo fosse pressionado novamente, fixando o ponto na coordenada corrente. Insert inseria um ponto na lista com as coordenadas atuais na posição do ponto mais próximo ao cursor. Não era possível inserir um ponto depois do último da lista, para isso era usado append.

Selecionando show eram mostradas as opções xy, xz e yz, e a projeção paralela do sólido era exibida na janela gráfica. Transform levava às opções extrusion e revolution. Extrusion abria janelas de texto pedindo a profundidade no eixo z e deslocamentos nos eixos x e y. Essas informações precisavam ser entradas via teclado. Revolution pedia o número de seções verticais, o ângulo da rotação e o eixo ao redor do qual esta deveria acontecer. O motivo de extrusion não oferecer o eixo de extrusão decorre do fato que temos como manipular a orientação dos sólidos no Editor de Cenas, e assim ficou convencionado que para extrusões seria feito o desenho no plano xy. Observe que não é possível gerar qualquer sólido de revolução da mesma forma sem aplicar uma rotação do corte no plano. Por isso para gerar sólidos de revolução foi determinado que poderia ser usado qualquer um dos eixos (x, y ou z).

File dispunha de open, save e new. Open para recuperar um sólido previamente gerado e gravado em disco, save para gravá-lo, e new para limpar todos os dados da memória do Modelador e iniciar um novo objeto. Nas opções open e save eram mostrados os arquivos já presentes no disco.

Editor de Cenas Tridimensionais

Possuia uma interface similar à já criada para o Modelador de Sólidos, com diversas opções adicionais nos menus. File se comportava de forma similar, só que agora para o formato de arquivos de cenas tridimensionais. Object levava ao menu de manipulação de objetos. Nele podíamos selecionar o sólido ativo, adicionar, apagar e transladar sólidos, assim como modificar a sua orientação no espaço, fazer escalas proporcionais e não proporcionais. Para adicionar sólidos podiam ser usados tanto sólidos gerados pelo Modelador como alguma das primitivas já embutidas no Editor, como por exemplo cilindros, cones, esferas, cubos, paralelepípedos, pirâmides, seções de cones e de pirâmides. A opção edit no menu principal levava a move, proportion e scale, mas esses de todos os objetos simultaneamente, ou seja, da cena inteira. Tinham as funções de transladar, mudar as escalas não proporcionais e proporcionais respectivamente. A opção observer levava ao menu de manipulação do observador. Lá podíamos mudar a sua posição ou o ponto para o qual o mesmo olhava, ambas interativas, ou seja, "andando" pela cena. Era também possível modificar a distância entre o observador e o "viewport", o plano onde a imagem é projetada (mais precisamente, a janela), que pode ser entendido também como o plano da tela, e assim conseguia-se diferentes efeitos de perspectiva (grande-angular, zoom, vista "normal").

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, 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 semireta 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 semireta sobre o plano de projeção (tela), unindo-os temos a projeção dessa semireta. Tanto no Modelador como no Editor de Cenas foram usadas apenas semiretas 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 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:

s4  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

s3  0.0 0.0 0.0  1.0 0.0 0.0  0.0 1.0 0.0
s3  0.0 1.0 0.0  1.0 0.0 0.0  1.0 1.0 0.0

Forma de organização da equipe de trabalho e atribuição de responsabilidades

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:

Atividades realizadas

Resumo das atividades realizadas durante o projeto:

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, assim como exportar ambos para programas de visualização existentes nas estações gráficas tanto da Sun como do então recém adquirido supercomputador gráfico da Silicon Graphics. 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.

O projeto foi dado como concluído com sucesso, e 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.

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 cooeperaçã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á possuia 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.

2004/12/06 Kenzo Yamada