Embed Size (px)
Citation preview
Animação e Visualização Tridimensional - Alameda 18 de Dezembro 2008
Lost Fight
Edgar Santos 56877 MEIC
Eduardo Knopfli 56887 MEIC
Diogo Mariano 56935 MEIC
Sumário
Este documento descreve o jogo Lost Fight, focando-se no seu conceito, na sua jogabilidade, assim como vários aspectos relacionados com desenvolvimento do jogo.
Em primeiro lugar, vai-se falar, como já referido, no conceito de jogo, ou seja, que tipo de jogo é, em que jogo foi baseado, e a forma como o conceito foi evoluindo ao longo do tempo. É também descrito, tudo o que é necessário para se conseguir jogar, com especial ênfase no que são os tesouros, e a importância destes no jogo.
De seguida, é explicada a decomposição em módulos da nossa aplicação, justificando-se sempre o porquê dessa decomposição e em que medida essa decomposição cumpre e ajuda a cumprir os requisitos. Um desses requisitos que nos propusemos a cumprir foi o da flexibilidade, tanto do ponto de vista do programador, como do utilizador. Acreditamos que cumprimos este último, graças à facilidade que o utilizador pode alterar a aplicação e os níveis, recorrendo a ficheiros de configuração. Este documento explica como atingimos essa elevada configurabilidade.
Finalmente, menciona, os algoritmos mais relevantes, e as conclusões que foram tiradas durante o desenvolvimento do projecto, o que correu mal e o que correu bem.
1. Conceito
A nível do conceito de jogo, houve uma longa "discussão" acerca deste. Por um lado queríamos uma variante de Role-Playing Game com 1ªpessoa (“à lá” Oblivion), mas por outro queríamos algo mais para a diversão imediata do jogador (mais virado para um jogo com níveis e um “puzzle” para resolver). Assim, resolvemos juntar elementos destas duas vertentes, criando um conceito não muito visto e que achámos ser motivador e original. Da primeira ideia, retirámos os inimigos bem como um cenário, o mais realista possível. Este realismo é espelhado numa floresta (“à lá” Oblivion como é mostrado na imagem acima), em que o jogador é “engolido” na imensidão de árvores (daqui surgiu o nome do jogo). Da segunda ideia, retirámos a existência de níveis labirínticos e a lógica de jogo baseada em apanhar tesouros numa determinada ordem (havendo bonificações a recompensar a correcta execução deste acto, apelando à memória do jogador), tendo sempre em conta que os inimigos dificultam a tarefa. Este conceito acabou por se revelar sólido e foi sujeito a poucas alterações (imagem à esquerda). Uma das componentes que desde início se revelou ser um factor de risco (e foi considerado como tal), foi a existência de bonificações do tipo “espada” e “arco” que implicavam a existência de um sistema de combate. Também desde cedo, traçamos um plano para compensar a eventual falta desta componente. Tal acabou por acontecer e estas bonificações foram substituídas por outras (por ex. escudo e vista aérea), não alterando assim a essência do jogo. Assim, é impossível destruir os inimigos (apenas deixá-los mais fracos ou mais lentos), o que reforça ainda mais o nome do jogo.
2. Manual para Utilizador Experiente
Neste jogo, o jogador irá controlar uma personagem perdida numa floresta, cujo principal objectivo é apanhar todos os tesouros espalhados no mapa. Os tesouros poderão dar benefícios ou penalizações ao jogador, dependendo da ordem em que são apanhados. Para dificultar ainda mais a tarefa, alguns inimigos divagarão pelo mapa, tentado causar danos físicos ao jogador.
2.1. Primeiros passos no jogo
O jogo inicia-se com a câmara numa perspectiva de primeira pessoa. Se preferir uma
visão mais abrangente pode carregar na tecla 'c' para mudar para uma perspectiva de terceira pessoa.
Para movimentar a personagem, deverá utilizar as teclas 'w', para andar para a frente, 'a' para a esquerda, 'd' para a direita e 's' para trás. Para controlar a orientação da câmara poderá utilizar o rato. (as teclas apresentadas representam os valores “default” da aplicação, podendo ser alteradas tanto no ficheiro de configuração, como no menu respectivo dentro da aplicação)
2.2. Elementos presentes no ecrã (GUI)
Legenda:
1 – Minimapa
2 – Mensagens
3 – Sequência de cores
4 – Indicador do nível actual
5 – Indicador da vida do jogador
6 – Tesouros já apanhados
1
2
3
4 5
6
2.3. Menus 2.3.1 Menu principal:
New Game/Continue: Começa um novo jogo/continua o jogo.
Options: Acede ao menu de opções.
Exit Game: Sai do jogo. 2.3.2 Menu Options:
Display: Acede ao menu de opções de visualização.
Key Defs: Acede ao menu de definição de teclas. Para definir uma nova tecla para uma determinada acção, simplesmente premir enter, seguido da tecla pretendida para essa acção.
2.3.3 Menu Display:
FullScreen: Activa/Desactiva o modo de ecrã inteiro;
Lights: Liga/desliga todas as luzes, presentes no jogo;
Fog: Activa/Desactiva o nevoeiro presente na floresta;
WireFrame: Activa/Desactiva o modo WireFrame;
Smooth: Alterna entre Smooth Shading e Flat Shading.
2.4. Tesouros
Os tesouros são um elemento fundamental neste jogo visto que é necessário apanhá-los todos para concluir cada um dos níveis. Apresentaremos de seguida uma pequena explicação da Sequência de Cores, um conjunto de bonificações e penalizações para cada cor.
2.4.1 Sequência de Cores
Ao início de cada nível é mostrada uma sequência de cores, que define a ordem certa pela qual os tesouros deverão ser apanhados. Um tesouro apanhado pela ordem certa dá direito a uma bonificação, um tesouro apanhado pela ordem errada dá direito a uma penalização. O jogador não é obrigado a apanhar os tesouros pela ordem correcta (a não ser que queira obter todas as bonificações).
O que interessa na sequência é a posição absoluta (primeira, segunda, quinta,...) de cada cor nessa mesma sequência. Por exemplo, na seguinte sequência:
Vermelho, Azul, Verde, Amarelo, Azul Claro, Roxo
Se o jogador apanhar as cores pela seguinte ordem,
Vermelho, Amarelo, Azul, Verde, Azul Claro, Roxo
só ganhará bonificações quando apanha os tesouros, Vermelho e Azul Claro.
O tesouro Roxo só aparecerá quando todos os outros tiverem sido apanhados, portanto será sempre o último a ser apanhado. (ao contrário dos outros que são gerados aleatoriamente no início de cada nível.
2.4.2 Bonificações
Tesouro Bonificação
Azul Jogador mais rápido.
Vermelho Pontos de vida extra.
Amarelo Escudo, que reduz o dano em metade.
Verde Inimigos mais lentos.
Azul Claro Câmara aérea (permite ver o mapa todo).
Roxo Ganha o jogo.
2.4.3 Penalizações
Tesouro Penalização
Azul Jogador mais lento.
Vermelho Jogador perde pontos de vida.
Amarelo Inimigos mais fortes.
Verde Inimigos mais rápidos
Azul Claro Jogador perde todos as bonificações e penalizações, e tem de apanhar todos os tesouros outra vez.
Roxo
3. Arquitectura e Bibliotecas Externas
Desde cedo foi criada uma arquitectura da aplicação e perdemos imenso tempo a pensar em todos os aspectos para que não tivesse que ser alterada, com pequenas excepções mas que não afectaram a sua "espinha dorsal”. Isto foi feito, porque potenciais alterações implicariam imenso tempo a portar a aplicação para uma nova arquitectura. A arquitectura final da aplicação pode ser vista na imagem seguinte:
Como pode ser visto na imagem, a nível da aplicação existem 7 componentes de mais alto nível e 2 de auxílio a toda a aplicação (bibliotecas externas e ficheiros de configuração). Passa-se uma breve descrição dos primeiros 7 componentes:
Input: Camada fina de gestão de eventos da nossa aplicação. Ouve eventos do teclado e do rato reencaminhando-os para as respectivas entidades;
Player: Maneja toda a informação referente ao jogador, incluindo a actualização do seu estado, o seu desenho e animação. Utiliza uma biblioteca externa para a sua animação;
Camera: Gere toda a informação referente à câmara (os seus diferentes modos, volume de visualização, posição da câmara, etc...);
MenuManager: Conduz os Menus da aplicação. Controla quais os menus que são carregados/descarregados e que entidades devem ou não ser carregadas consoante a opção escolhida no menu actual. Debaixo deste Manager estão todos os menus da aplicação;
WorldManager: É responsável pela desenho do "Mundo" da aplicação. É este componente que tem por baixo os componentes que são responsáveis pela floresta, terreno (mapa de alturas), SkyBox e Nevoeiro;
GameManager: Administra toda a Lógica de Jogo. Tudo o que tem haver com o jogo em si, como regras de jogo e bonificações/penalizações, está no GameManager. Contém a Interface do jogo, o gestor de tesouros e o gestor de inimigos;
ResourceManager: Por fim, este Manager que acaba por ser uma maneira de abstrair uma data de aspectos relacionados com as outras componentes. São eles o carregamento de modelos, as texturas, as luzes e os materiais.
Porquê esta divisão?
Tal como foi referido anteriormente, o nosso conceito surgiu de duas ideias diferentes, que por sinal foram de duas pessoas diferentes. Logo, tendo em vista uma possível continuação deste projecto (tirando partido da sua configurabilidade e extensibilidade detalhadas a seguir) quisemos ter uma aplicação na qual fosse fácil mudar a lógica de jogo. E veja-se, toda a lógica de jogo está encapsulada no GameManager. Podemos assim, usar a floresta e o jogador para outro jogo conceptualmente diferente. É este o lado mais forte da nossa arquitectura, e o sentido de modificabilidade é o que acabámos de referir. A flexibilidade da arquitectura também pode ser vista a outros níveis, por exemplo no encapsulamento das texturas, modelos, materiais e luzes no ResourceManager ou no terreno, árvores e céu encapsulados no WorldManager.
A nível dos ficheiros de configuração, permitiram que configurações importantes da
aplicação não estivessem "hard-coded", bem como facilitou e tornou flexivel o carregamento de níveis. A criação de níveis vai ser explicada mais adiante neste relatório.
Finalmente, vamos fazer uma pequena explicação das bibliotecas externas por nós
utilizadas. As bibliotecas usadas são as seguintes:
CGLib: permitiu um desenvolvimento mais "Object Oriented" e facilitou o tratamento de eventos.
ltga: para carregar ficheiros *.tga usados em texturas.
pcxLoader: para carregar ficheiros *.pcx usados em texturas.
MD2_model/MD2_file: para carregar ficheiros *.md2 usados para carregar e animar modelos.
glm: para carregar ficheiros *.obj usados para carregar modelos (não animados).
O uso da CGLib é extremamente vantajoso, já que entre outras coisas nos trás benefícios da aplicação de uma metodologia OO.
Temos dois carregadores de texturas, já que para modelos animados usamos texturas *.pcx e para modelos não animados usamos texturas *.tga. A primeira foi usada pela sua facilidade de utilização (e existência de exemplos) e a segunda exactamente pela mesma razão tendo em conta a sua utilização para os nossos modelos animados.
A nível dos carregadores de modelos, começámos por usar a glm, já que é extremamente simples de usar (além de já ter sido usado anteriormente noutro projecto). Mais tarde tivemos necessidade de carregar modelos animados, e como esta não o suportava, passámos a usar um
carregador específico para modelos *.md2. Este formato e carregador foram os escolhidos, já que os modelos são de um jogo muito conhecido e bem sucedido, o Quake II, e foi relativamente fácil encontrar imensos modelos animados.
Tal como seria de esperar, estas bibliotecas (excepto a CGLib, por razões óbvias) foram integradas na parte da arquitectura referente ao ResourceManager. (ele é o responsável pelo carregamento de texturas, objectos, iluminação e materiais tal como foi descrito anteriormente).
Em suma, o desenvolvimento desta arquitectura facilitou a programação concorrente,
bem como facilita a posterior alteração/extensão do projecto. Podemos dizer que à medida que fomos exercitando esta arquitectura ao longo do desenvolvimento, fomos ficando cada vez mais contentes com ela, porque a quantidade de ficheiros e código aumentava e ainda assim as dependências e responsabilidades continuavam bem definidas, fáceis de perceber e de alterar.
4. Configurabilidade e Extensibilidade
Alterar mapas é bastante fácil. A definição dos elementos de cada mapa é feita através de ficheiros de imagem *.tga. É portanto, possível alterar os mapas, através de qualquer editor de imagens capaz de ler esse tipo de ficheiros.
Os mapas têm 640x640 píxeis, cada pixel correspondendo a uma unidade de área do mundo do jogo. Este valor pode ser modificado no ficheiro de configuração. Píxeis a preto representam as árvores, píxeis vermelhos representam inimigos, verdes representam os tesouros e finalmente os píxeis brancos correspondem a pontos vazios. De referir ainda que o número de píxeis a verde tem de ser obrigatoriamente 6, pois é esse o número de tesouros que o nosso jogo tem. As cores têm de ser puras, ou seja, o preto tem de ter as componentes RGB todas a 0, o vermelho tem de ter essas componentes, respectivamente a (1,0,0), o verde a (0,1,0) e finalmente o branco tem de ter todas as componentes igual a 1. A imagem a direita mostra um dos mapas que está a ser utilizado actualmente no jogo.
Se fosse necessário expandir o nosso jogo, por exemplo, introduzir outro tipo de elemento para embelezar o cenário, como casas, teríamos apenas de acrescentar o modelo de uma casa, e designar pontos azuis, para definir a posição de cada casa ou se quisermos alterar as árvores apenas a temos de trocar por outro modelo. Apresentamos de seguida exemplo de dois modelos por nós utilizados:
Da mesma maneira que se define o posicionamento de cada elemento de jogo no mapa, é também possível definir a altura do terreno. É possível, portanto, criar montanhas no jogo. Para tal terá, apenas, de modificar o respectivo ficheiro de imagem, utilizando para isso, mais uma vez, um editor de imagem capaz de ler ficheiros *.tga.
Tal como os mapas dos níveis, os mapas de alturas, têm 640x640 píxeis, pois o tamanho do terreno de jogo também tem esse tamanho. Na imagem, píxeis a preto correspondem a zonas baixas, enquanto píxeis a branco definem zonas altas. Píxeis com cores intermédias (entre preto e branco) definem, obviamente, alturas intermédias. A imagem abaixo ilustra o que foi descrito anteriormente.
5. Algoritmos Relevantes
Como algoritmos que consideramos serem os mais relevantes no nosso projecto podemos identificar os seguintes: algoritmo para o mapa de alturas; algoritmo para calcular altura no mapa de alturas; algoritmo de detecção de colisões.
Algoritmo para o desenho do mapa de alturas e respectiva optimização
Quando iniciamos a implementação do algoritmo de mapa de alturas estivemos a
consultar algumas fontes de informação, pois sabíamos este seria um ponto muito importante do projecto de forma a tornar a nossa floresta mais real. Numa visão mais de alto nível o nosso algoritmo consiste no seguinte:
1. Criação da matriz com as alturas a partir de um ficheiro de imagem:
1. Ler de uma imagem qualquer componente do pixel (indiferente ser Red, Green ou Blue pois temos a imagem em escala de cinzas e as três componentes são iguais);
2. Guardar essa informação numa matriz em que cada posição fica com a informação de cada pixel;
3. Fazer a optimização das alturas, através da média de todas as posições adjacentes de todas as posições da matriz. (figura a baixo)
2. Fazer o cálculo das normais para cada ponto da matriz guardando essas informações
noutra matriz: 1. A normal em cada ponto depende da altura de cada ponto na matriz anterior e
das normais directamente adjacentes. 3. Desenho do mapa de alturas:
1. Percorrer a matriz de alturas e por cada três pontos seguidos desenhar um triângulo com as respectivas coordenadas obtidas através da altura no mapa;
2. Por cada vértice desenhado designar a normal para esse ponto a partir das mesmas calculadas anteriormente.
(i,j)
Grande parte dos algoritmos que consultamos na web tinha grandes problemas no grau de realismo, pois ao aplicarmos a nossa navegação nestes, o jogador fazia subidas e descidas muito bruscas devido a existir uma grande diferença entre muitas posições da matriz. De forma a resolver este problema, a nossa solução apresenta um “add-on” que consiste no ponto 1.3 (figura a cima). Aí fazemos uma média de cada posição com todas as posições que a rodeiam, n vezes, para que as movimentações e o aspecto do mapa sejam mais perfeitos, sendo bastante notadas as diferenças no aspecto do mapa de alturas. Essas diferenças podem ser observadas nas duas imagens seguintes:
Algoritmo para o cálculo de uma posição genérica no mapa de alturas
Após o desenho do mapa de alturas faltava então completar a integração deste, fazendo a adaptação dos movimentos e posicionamento das nossas entidades no mundo. Como tal surgiu-nos um pequeno problema - como saber a posição exacta num dado plano (pois temos milhares de pequenos triângulos a definir o terreno). A solução que implementámos consiste em determinar a equação do plano que contém o ponto, para o qual queremos saber a altura.
Ficamos com o seguinte algoritmo: 1. Dadas duas coordenadas no mundo saber quais os 3 pontos que definem esse
mesmo triângulo;
2. Calcular as duas rectas que se podem definir através desses 3 pontos; 3. Fazer o produto externo entre essas duas rectas para saber a normal dessas mesmas
rectas;
4. Aplicar a equação do plano para dado um ponto e uma normal ao plano saber a
equação do plano;
5. Calcular a altura com as duas coordenadas que sabemos.
Algoritmo de detecção de colisões Na nossa aplicação temos dois tipos de algoritmos de detecção de colisões: • Inimigos e jogador com as árvores • Jogador com tesouros e inimigos Jogador com tesouros e inimigos: Sempre que a função update() de um tesouro ou de um inimigo é chamada, a posição actual dessa entidade é comparada com a posição do jogador. Se a diferença entre as coordenadas for menor do que um determinado número, considera-se que ocorreu uma colisão. Note-se que apenas as coordenadas x e z são testadas, visto que o mundo apenas tem um plano (não há edifícios com vários andares, por exemplo) e que todas as entidades se encontram sempre no chão.
Inimigos e jogador com árvores: Na nossa primeira implementação deste tipo de colisões, optámos por, a cada update() do jogador e do inimigo, comparar a sua posição actual com a posição de todas as árvores. Como o número de árvores num mapa é muito grande, o número de comparações também o ia ser, algo que afectava muito a performance do programa. A solução que adoptámos, que se demonstrou ser muito mais eficiente, foi a cada update() do jogador e do inimigo utilizar a sua posição para indexar a matriz que guarda todos os elementos do nível. Como cada posição da matriz corresponde ao tamanho duma árvore, facilmente se verifica se essa posição tem uma árvore ou não, logo a verificação da colisão é uma operação trivial, e mais importante realiza-se em tempo linear, tornando o programa muito mais rápido.
6. Post-Mortem
6.1 O que correu bem
Uma das opções que se revelou bastante boa, foi o carregamento de níveis através de uma imagem. Graças a esta funcionalidade torna-se extremamente fácil adicionar mapas novos ou alterar os já existentes, bastando para tal modificar a imagem, utilizando um programa de edição de imagem. Antes utilizávamos um ficheiro de texto com números, onde cada número representava um elemento do mapa. Era muito mais difícil tanto visualizar o formato que o nível iria ter, como alterar o posicionamento dos elementos. O Mapa de alturas foi feito de maneira semelhante. Esse elemento foi claramente o que superou as nossas expectativas, já que achamos que está muito perto da perfeição. A sua configurabilidade foi uma decisão acertada, já que nos permitiu testar com diferentes mapas de alturas, o nosso algoritmo já explicado. Por fim, a decisão de fazermos um labirinto de árvores também excedeu as expectativas pela sensação que transmite ao jogador. Empenhamo-nos muito no aspecto da floresta e ao fazermos isso criámos um ambiente de jogo que dá a clara sensação de desnorte, fruto de todos os modelos, texturas, materiais e efeitos por nós usados.
6.2 O que correu menos bem
Durante o desenvolvimento do jogo, houve algumas funcionalidades que não conseguimos implementar por diversas razões. Nesta secção vamos mencionar quais essas funcionalidades, o impacto que poderiam ter no jogo, e porque razões não foram implementadas.
Inicialmente tínhamos planeado que alguns dos tesouros, se apanhados na ordem certa, dariam acesso ao jogador a armas que poderiam ser utilizadas para eliminar inimigos. No entanto, como não tivemos tempo para implementar um sistema de combate, dada a complexidade do mesmo, optámos por não dar essas bonificações ao jogador. Foi necessário, então, encontrar outras bonificações para substituir as armas. O sistema de combate poderia tornar a jogabilidade mais interessante, mas por outro lado, também poderia trivializar o jogo.
Outro aspecto que correu menos bem foi as colisões entre inimigos. Ainda tentámos implementar esta funcionalidade, mas após inúmeras tentativas resolvemos deixá-la de parte, visto que não tinha grande impacto na jogabilidade. Foi possível fazer com que os inimigos colidissem entre si, situação que levava a que cada um dos inimigos mudasse a direcção do seu rumo. No entanto, era bastante frequente vários inimigos ficarem bloqueados junto das paredes, fruto das colisões, tanto com a parede, como das colisões com os outros inimigos.
A animação do jogador também podia ter corrido melhor. Essa parte foi feita já com falta de tempo e então é uma animação muito simples. Em relação ao que tinha sido pensado de início, o jogador poderia (por ex.) defender-se se tivesse o escudo. Para colmatar isto, assume-se que o jogador está sempre a usar o escudo. Este é apenas um pequeno pormenor, mas aliado ao sistema de combate (factor de risco desde o inicio do projecto), tornou-se um ponto que não correu tão bem, mas que acabou por ser compensado (tal como referido acima), sem alterar a essência do jogo e reforçando ainda mais o nome do jogo.
7 Impressões Finais e Conclusões
Descrevam os aspectos que mais marcaram o desenvolvimento do projecto assim como os elementos de que mais se orgulham.
Em primeiro lugar, e como já foi referido neste relatório, convém reforçar que a arquitectura escolhida nos enche de orgulho. Falamos dela em primeiro lugar, porque foi a partir dela que se fez tudo o resto, sendo um importante artefacto do processo de desenvolvimento da aplicação.
Depois, destacamos a animação do modelo. Tal como foi referido na secção 6.2, foi uma coisa que correu menos bem, mas que ainda assim nos orgulha, por ter sido desenvolvida num curto espaço de tempo sob muita pressão.
Outra coisa que ficou, do nosso ponto de vista, perto da perfeição, foi o mapa de alturas. Além da sua elevada configurabilidade, sob o ponto de vista visual e da interacção com os restantes elementos, está muito bom mesmo.
Os últimos dois aspectos referidos referem-se sobretudo ao aspecto visual da cena. Neste ponto é impossível passar ao lado do aspecto da floreste. Os modelos das árvores em conjunto com o nevoeiro/Skybox, fazem com que se atinja um nível de imersividade estupendo, tal como o que nos propusemos a criar.
Em relação há lógica de jogo, somos forçados a referir a imprevisibilidade dos inimigos. A maneira como “vagueiam” pelo mapa, é extremamente difícil de prever, aumento o desafio do jogo.
O último aspecto do qual nos orgulhamos especialmente é o editor de mapas. A capacidade da nossa aplicação suportar algo deste género, é algo muito útil, tanto para testes, como para a extensão/alteração dos próprios níveis do jogo.
O momento mais marcante durante o desenvolvimento do projecto, foi o fim-de-
semana antes da 2.ªentrega. Até essa data, o nosso projecto estava bastante simples, especialmente a nível visual. No entanto, esse “atraso” deveu-se ao dispêndio de tempo em criar solidez a nível da estrutura da aplicação. O fim-de-semana referido foi marcante na medida em que depois deste, a nossa aplicação (tanto a nível visual como a nível de lógica de
jogo), progrediu duma maneira extremamente rápida! Pareceu que dois dias atrás não tínhamos nada, e dois dias depois tínhamos quase tudo. Foi exactamente este o ponto em que percebemos que íamos cumprir os principais objectivos a que nos propusemos.
Por fim, deixamos aqui uma espécie de “final aberto”. Qualquer um de nós acha que
este projecto, apesar de ser uma “release” sólida, está longe de estar acabado. Se calhar uns num sentido, e outros noutro, gostaríamos de extender, continuar, alterar este projecto para uma aplicação ainda melhor, mais completa, mais ao gosto de cada um usando os pontos fortes já existentes. Em suma, o principal ponto do qual nos orgulhamos é a nossa aplicação nos dar essa possibilidade…
Referências http://tfc.duke.free.fr/old/models/md2.htm http://www.videotutorialsrock.com/opengl_tutorial/terrain/home.php http://www.swiftless.com/tutorials/opengl/heightmap.html http://www.lighthouse3d.com/opengl/terrain/index.php3?heightmap
