Ano: 2003/2004 - Semestre: 1

Método de Avaliação

Esta disciplina será avaliada por uma componente prática sob a forma de um trabalho. Os alunos devem formar grupos de 2 ou 3 elementos e escolher um dos enunciados apresentados.

O trabalho prático será avaliado de forma contínua, e portanto encontra-se dividido em três etapas. Cada etapa corresponde a uma etapa de desenvolvimento do projecto. As duas primeiras etapas são comuns a todos os projectos, sendo a terceira da escolha do grupo dentro das opções aqui apresentadas. Para cada etapa deve ser produzido um relatório escrito segundo as indicações fornecidas para cada etapa. Para cada etapa existe uma data limite para a sua entrega.

Note-se no entanto que não existe uma avaliação individual por etapa, sendo a avaliação realizada sobre o trabalho no seu todo, ou seja, no conjunto das três etapas. Para as duas primeiras etapas é somente indicado se o resultado apresentado pelo grupo é suficiente ou se terá de ser submetido de novo.

Nas duas primeiras etapas não é necessário uma apresentação oral do trabalho sendo somente necessário entregar o seguinte material:

• um relatório impresso e encadernado;
• um CD contendo o relatório, código fonte e executável.

O relatório das duas primeiras etapas deve ser visto como um capítulo do relatório final.

A terceira etapa implica a entrega do relatório e CD, tal como nas etapas anteriores, e uma discussão oral com o grupo que deve envolver todas as etapas do trabalho. Na discussão do trabalho devem comparecer todos os elementos do grupo para discutir o trabalho oralmente.

Nas duas primeiras etapas admite-se a utilização de excerptos de código disponível na internet. A terceira fase deve obrigatóriamente ser da autoria exclusiva do grupo. Nos relatórios, só no caso especifico das figuras é que se permite que estas não sejam originais.

Caso uma etapa não seja entregue até à data limite anunciada, o grupo pode entregar essa mesma etapa até à data limite da etapa seguinte com uma penalização de 15% sobre a nota final do trabalho. O mesmo se aplica caso uma etapa tenha de ser submetido de novo. Após essa data, o trabalho não será aceite correspondendo à não avaliação do grupo na disciplina. A última fase não tem tolerância, devendo ser entregue até à respectiva data limite.

A avaliação terá em conta os seguintes critérios:

• Qualidade do trabalho
• Qualidade do relatório escrito
• Empenho dos alunos na discussão oral

A ordem dos factores apresentados acima nãoimplica uma relação de importância entre os mesmos. Os alunos de um mesmo grupo poderão ter notas diferenciadas consonante o seu desempenho na discussão oral do trabalho.

Template para relatório da etapa 1 (tempRel1.zip)

Template para relatório da etapa 2 (tempRel2.zip)

Trabalhos Práticos

Etapa 1 - Model Loader :: Data Limite - 14 de Novembro

Desenvolver uma aplicação que permita carregar e visualizar modelos gráficos a partir de ficheiros de gráficos segundo o formato OBJ, MAX ou TrueSpace (um dos formatos, à escolha do grupo). A aplicação deve ainda, através da consola, fornecer informação sobre o número total de vértices e polígonos dos modelos carregados.

A aplicação deve ser invocada a partir da linha de comando, com um parâmetro que representa o nome de um ficheiro de configuração. O ficheiro de configuração determinará não só quais os ficheiros onde se encontram os modelos gráficos a carregar, mas também a sua distribuição espacial e escala.a aplicar aos modelos.

No ficheiro de configuração, cada linha indica um ficheiro de gráficos e a respectiva translação, rotação e escala. A ausência da informação relativa à translação e escala implica utilizar uma translação (0,0,0), uma rotação de 0 graus, e uma escala (1,1,1). O formato para cada linha é o seguinte:

nome do ficheiro tx ty tz ang rx ry rz ex ey ez

por exemplo:

porsche.obj 10 10 0 45.0 0.0 1.0 0.0 0.1 0.1 0.1

o que corresponde a carregar o ficheiro porsche.obj, e aplicar ao modelo a translação (10,10,0), uma rotação de 45 graus em torno do eixo dos Y e a escala (0.1,0.1,0.1).

O código para leitura e interpretação dos ficheiros pode ser obtido na Internet.

Etapa 2 - Octrees com View Frustum Culling :: Data Limite - 19 de Dezembro

Esta etapa tem como ponto de partida a aplicação desenvolvida na etapa anterior. Uma das técnicas mais simples de optimização consiste em determinar à priori quais os polígonos que são visiveis a partir da câmara, ou seja que se encontram dentro do volume de visualização, e não enviar polígonos não visiveis para a placa gráfica. Esta técnica é geralmente utilizada em conjunto com octrees (arvores octais que permitem uma fácil partição espacial) por forma a permitir eliminar um número significativo de polígonos com um número reduzido de testes. Desta forma as células da octree são testadas recursivamente para determinar a sua visibilidade e só os polígonos dentro de células visiveis são enviadas à placa gráfica.

Pretende-se assim que os modelos previamente carregados sejam inseridos numa octree, ou árvore octal. Durante a visualização, a aplicação deve realizar view frustum culling.

Factor de valorização: Utilização de Vertex Buffer Object.

Etapa 3 :: Datas para Apresentação - 25/Fev a 1/Mar. (folha de inscrições na recepção do DI)

Cada grupo deve escolher uma das seguintes versões. Esta etapa deve ser totalmente implementada pelo grupo sem recorrer a código de terceiros. Todas as versões devem apresentar no seu relatório testes significativos com dados conclusivos em relação ao desempenho obtido.

Versão A - Occlusion Culling NV_occlusion_query

Em ambientes virtuais complexos as aplicações desenham frequentemente polígonos que, embora contidos em cé�[37;1Hlulas da octree dentro do volume de visualização, não contribuem para o resultado final da imagem. Por exemplo, se a câmara se encontrar dentro de um quarto não há necessidade de desenhar polígonos do outro lado das paredes, já que na imagem final estes polígonos não são visiveis. Occlusion culling é ecanismo que consiste em determinar quais os polígonos, ou células da octree, que realmente são visíveis. Pretende-se adicionar à aplicação desenvolvida nas etapas anteriores este mecanismo recorrendo à extensão NV_occlusion_query da Nvidia.

Versão B - Occlusion Culling PLP e cPLP com Item buffer

Os algoritmos PLP e cPLP (conservative PLP) permitem realizar Occlusion Culling contemplando duas situações:

• performance garantida através da limitação do número de polígonos a desenhar, sem no entanto garantir que a imagem está correcta (PLP)
• qualidade de imagem garantida realizando occlusion culling completo (cPLP).

Pretende-se determinar a performance relativa destes dois algoritmos adicionando estes dois algoritmos ao resultado das etapas anteriores.

Versão C - Sombras com Luz Dinâmica e Mapas de Profundidade

A Iluminação fornecida pelas placas gráficas é claramente insuficiente para obter resultados satisfatórios de um ponto de vista de percepção do ambiente virtual. Uma das insuficiências da Iluminação normal é a ausência de sombras num vértice provocadas por outros polígonos.

Pretende-se portanto determinar se um determinado vértice está ou não em sombra, recorrendo a mapas de profundidade, e modificar as suas propriedades de cor respectivamente. A aplicação deverá aplicar este processo a todos os vértices do ambiente virtual dentro do volume de visualização e permitir a visualização com e sem a utilização de sombras.

Versão D - Níveis de Detalhe

A percepção de pormenor dos objectos presentes no mundo é sem dúvida influenciada pela distância a que os objectos se encontram da câmara. Um objecto distante pode ser representado com um parte dos polígonos originais sem que isso afecte a sua aparência. O número de polígonos/vértices pode variar continua ou discretamente de acordo com a variação da distância ao utilizador. Pretende-se nesta etapa adicionar esta funcionalidade à aplicação desenvolvida nas etapas anteriores, de forma a adicionar níveis de detalhe contínuos, de acordo com os algoritmos de Hughes Hoppe, ou Michael Garland. A aplicação deve permitir ainda o controle dos níveis de detalhe através de teclas.

Versão E - Impostores

Para ambientes virtuais constituídos por objectos independentes (carros, árvores, estátuas, prédios,...) é possível substituir os polígonos de um objecto por um impostor, ou seja a imagem desse mesmo objecto. Para que este processo seja de facto uma optimização é portanto necessário que a ilusão 3D seja mantida sem que seja necessário recriar a imagem do objecto em cada frame. Tal verifica-se quando esta técnica se aplica a objectos longiquos. Pretende-se com esta etapa adicionar a hipotese de criar impostores para objectos distantes e estudar a relação (alteração no desempenho da aplicação) / (número de vértices que o impostor substitui).

Etapa 3 (Época Especial):: Datas para Apresentação - 13/Set a 16/Set.

Cada grupo deve escolher uma das seguintes versões. Esta etapa deve ser totalmente implementada pelo grupo sem recorrer a código de terceiros. Todas as versões devem apresentar no seu relatório testes significativos com dados conclusivos em relação ao desempenho obtido.

Versão A - Sombras com Volume Shadows

A Iluminação fornecida por omissão pelas placas gráficas é claramente insuficiente para obter resultados satisfatórios de um ponto de vista de percepção do ambiente virtual. Uma das insuficiências dos modelos de iluminação locais é a ausência de sombras num vértice provocadas por outros polígonos.

Pretende-se portanto determinar se um determinado vértice está ou não em sombra, recorrendo a "shadow volumes", e modificar as suas propriedades de cor respectivamente. A aplicação deverá aplicar este processo a todos os vértices do ambiente virtual dentro do volume de visualização e permitir a visualização com e sem a utilização de sombras.

Versão B - Gerador de Terrenos com Perlin Noise

Pretende-se a implementaç�[55;1Hão de um gerador de terrenos utilizando "Perlin Noise". O gerador deverá ter uma interface gráfica desenhada em GLUI, por forma a permitir a fácil manipulação dos parâmetros da geração. A aplicação deverá ainda utilizar o biblioteca DevIL para permitir carregar e armazenar os terrenos sob a forma de mapa de altun A interactividade da aplicação deverá permitir ao utilizador "andar" e "voar" no terreno. A utilização de técnicas de aceleração como Vertex Buffers é um factor de bonificação no trabalho.