Posso envolver minha cabeça usando uma função de ruído perlin 2D para gerar o valor da altura, mas não entendo por que uma função de ruído perlin 3d seria usada. No blog de Notch, http://notch.tumblr.com/post/3746989361/terrain-generation-part-1 , ele mencionou o uso de uma função de ruído perlin 3d para a geração de terreno no Minecraft. Alguém sabe como isso seria feito e por que seria útil? Se você estiver passando os valores x, ye z, isso não implica que você já tenha a altura?
Respostas:
O ruído 2D perlin é bom para mapas de altura, mas, neste caso, parece que ele não está usando um mapa de altura. Em vez disso, ele tem uma grade 3D, onde qualquer célula pode estar vazia. Isso permite cavernas e tais formações, onde a altura do solo não é um valor único para determinada localização 2D.
Em vez de amostrar a “altura do solo”, tratei o valor do ruído como a “densidade”, onde qualquer coisa menor que 0 seria ar e qualquer coisa maior que ou igual a 0 seria terra.
Simplificando, para todo lugar em que um bloco possa estar, uma função de ruído é avaliada e, se for> 0, um bloco é colocado. A função de ruído do Notch é distorcida adicionando altura do nível da água ao seu valor, é por isso que as áreas mais baixas são mais sólidas (a altura é grande negativa, então a altura + o ruído também é negativo) e as áreas mais altas ficam quase vazias (a altura é grande e positiva, então a altura + ruído também é positivo).
Provavelmente existe alguma alquimia adicional para decidir que tipo de bloco será gerado e para esculpir cavernas. Mas acho que não está diretamente relacionado a essa função de ruído.
Observe também que esse método funciona para o Notch porque o Minecraft possui um terreno baseado em voxel. Se você tentasse fazer isso em um mundo baseado em polígonos, simplesmente amostrar a função de ruído não seria suficiente. Você precisa usar algum algoritmo para transformar amostras em uma superfície e criar polígonos que se aproximem dessa superfície. Um desses algoritmos é marchar cubos .
O ruído 3D se torna obrigatório se o terreno precisar de redes de cavernas e saliências.
Para extrair uma isossuperfície das informações de densidade, as 2 técnicas mais populares são Cubos de Marcha (MC) e o mais recente Dual Contouring (DC). A estrutura de dados necessária é bem diferente, dependendo do método escolhido.
Como mencionado anteriormente, o artigo da Geiss GPU Gems 3 é um ponto de partida muito instrutivo para a compreensão e implementação de terrenos de MC na GPU (observe que sua abordagem de MC funciona inteiramente na GPU e requer pelo menos uma SM4 - compatível com GS).
Como os dados de densidade nos voxels do MC só podem permanecer nas bordas do voxel, o MC clássico pode contornar o volume sem preservar os recursos das bordas afiadas. O DC não sofre essa desvantagem, pois as informações de densidade são expressas como um ponto 3D (minimizador de QEF) localizado em qualquer lugar dentro do voxel mais o sinal em cada canto.
Por outro lado, o MC não sofre de faces que se cruzam automaticamente porque todos os triângulos gerados estão entre seus voxels correspondentes, enquanto o DC precisa de cálculos adicionais para evitar interseções entre as faces geradas. Os autores da DC abordaram esse problema em uma versão aprimorada de seu algoritmo.
http://www.cs.wustl.edu/~taoju/research/interfree_paper_final.pdf
http://www.cs.berkeley.edu/~jrs/meshpapers/SchaeferWarren2.pdf
Esse sujeito também propõe uma abordagem provavelmente mais limpa, com base na análise convexa / côncava, para evitar interseções automáticas. Ele também usa regras de divisão de quadratura melhores para ajudar a preservar a orientação da borda:
http://www2.mae.cuhk.edu.hk/~cwang/pubs/TRIntersectionFreeDC.pdf
O Classic MC também não está pronto para uso "livre de trincas" e pode exigir correção de trincas se executado em locais sem restrições. DC não sofre com este último problema.
Aqui está uma pesquisa bastante agradável e completa da maioria das técnicas de extração de malha: http://www.cs.berkeley.edu/~jrs/mesh/
Uma abordagem octree / voxel é intrinsecamente "compatível com CSG", o que facilita o planejamento de uma estratégia de nível de jogo totalmente "destrutível", mas se for necessário implementar tudo isso em um jogo, a profundidade da octree também precisará ser frustum -dependente.
Se todo o material couber na memória ou for transmitido corretamente, os dados também podem ser usados para renderizar AO e computar física / colisão.
O Minecraft usa o algoritmo de cubos de marcha para gerar terreno 3D. Eu não tenho uma referência para isso, me desculpe. Não tenho certeza exatamente do que Notch estava falando quando mencionou a função Perlin Noise - talvez uma semente para o algoritmo de marchar em cubos. Mais informações aqui:
E um ótimo artigo sobre GPU Gems se você estiver interessado em marchar em cubos:
for (int x = 0; x < Width)
{
for (int y = 0; y < Depth)
{
for (int z = 0; z < Height)
{
if(z < Noise2D(x, y) * Height)
{
Array[x][y][z] = Noise3D(x, y, z)
} else {
Array[x][y][z] = 0
}
}
}
}