Gostaria de desenhar gráficos muito grandes (~ 500 px) de planetas girando lentamente. Esses gráficos foram feitos para impressionar. Qual é a melhor maneira de fazer isso? Não tenho experiência com nenhum mecanismo 3D específico e nem tenho certeza de qual plataforma este jogo seria executada, então:
- Eu poderia pré-renderizar cada quadro, mas a 500px e um período de rotação de 10 segundos, é uma quantidade absurda de dados por planeta.
- Eu poderia usar um mecanismo 3D e mapear a textura do planeta em uma malha que se aproxima de uma esfera, mas a 500px, eu temo que a contagem de polígonos precise ser enorme para torná-la boa.
- Eu poderia escrever um tipo de mecanismo 3D personalizado que não faz nada além de renderizar eficientemente uma esfera texturizada, convertendo a coordenada x / y de cada pixel de exibição no espaço de coordenadas da textura da esfera - mas isso está envolvido e não pode se beneficiar aceleração gráfica.
- Algo mais em que não pensei?
Aqui está um exemplo de GIF animado do que quero dizer. (Com 100 x 100 px e 60 quadros, já é muito grande, desculpe.) Imagine isso muito, muito maior, girando muito mais devagar e animando mais suavemente:
Mas se fossem 500 x 500 px e 10 x 25 = 250 quadros, estaríamos falando de centenas de MB de dados, portanto, essa abordagem direta não funciona.
2d
3d
graphics
graphics-programming
Zarkonnen
fonte
fonte
Respostas:
O número de polígonos para renderizar uma esfera "boa aparência" de 500x500px com uma única chamada de empate é trivial para as GPUs manipularem na maioria das plataformas, especialmente se não houver muito mais na cena. Há também algumas notas sobre esferas de texturização para evitar distorção texel; certifique-se de usar um mapa de cubo.
fonte
Como você está olhando a esfera com uma câmera constante, é possível renderizar alta qualidade com extrema rapidez com uma simples tabela de pesquisa pré-calculada.
Como etapa pré-calculada, com qualquer método que você desejar (geralmente com polígonos ou traçados de raios), você renderiza uma esfera mapeada de textura em um buffer externo, mas, em vez de calcular as cores com base na textura, armazena apenas as coordenadas u / v da textura.
Então, ao renderizar o planeta real, você renderiza um quadrado simples e, para cada pixel, você busca as coordenadas u / v reais da tabela de pesquisa e as cores de pixel da textura do planeta usando essas coordenadas u / v. Para girar a esfera, basta deslocar a coordenada u com o ângulo de rotação.
Essa técnica era muito popular na demoscene, por exemplo, com efeitos de túnel mapeados por textura, mas infelizmente não consegui encontrar bons tutoriais sobre ela.
fonte
Se você estiver fazendo isso em uma configuração 2D, consulte esta pergunta anterior ...
Ilusão 3D de uma textura de planeta 2D
O mesmo conceito funcionaria bem com uma imagem grande e movendo dinamicamente a textura do terreno em uma camada abaixo do "buraco" no espaço.
Leia o link acima para saber o que quero dizer com isso.
fonte
Se você comprimisse a animação resultante com um codec de vídeo moderno, ele não seria particularmente grande nem chegaria nem perto de "várias centenas de MB de dados" nem ridículo ...
Mas, como já foi dito, tudo depende do que é sua plataforma de destino e como todo mundo disse; apenas renderizar uma esfera 3D suave realmente envolveria uma quantidade insignificante de polígonos e muito pouco armazenamento de dados (a textura é tudo o que existe e mesmo em resoluções realmente altas, a compactação jpeg padrão não a reduziria).
Tudo depende também de como você é exigente - se você está atrás dos detalhes de aparência e textura de rolagem de um quarto de pixel, a par das demos de ponta, e não apenas dos jogos contemporâneos com toda sua interpolação e aliasing problemas até na 8x FSAA - então ele poderia se envolver quase infinitamente para alcançar (e exigir um pouco de artifício artístico também) ^^
fonte
Se você tiver problemas com o desempenho, faça isso da maneira tradicional (textura e mapeamento normal em uma esfera de polígono alto), que muitos mencionaram não deve ser um problema nessa resolução:
"Raytrace" com um shader de fragmento. Se sua câmera estiver fixa, tudo o que você precisa é de uma entrada flutuante uniforme para o shader de fragmento (para o ângulo de rotação) e o shader pode cuidar da computação das coordenadas da textura. Os vetores de iluminação também podem ser os mesmos em cada quadro. Quanto ao anti-aliasing, você também pode obter uma silhueta esférica perfeita com pouca criatividade (se o pixel estiver no limite da esfera, calcule sua cobertura)
Isso faz com que você envie apenas 4 vértices pelo pipeline e não exige que você aloque um buffer de quadros gigantesco com várias amostras para combater jaggies.
Com o custo de ter que criar vários algoritmos personalizados.
fonte