Como é feita a renderização do software?

Eu gostaria de explorar a rasterização baseada em software em tempo real. Sei que tudo está indo em direção à GPU hoje em dia, mas há alguns jogos em que ainda faz sentido usar um renderizador de software.

Por exemplo: Voxeltron

Voxatron é um jogo de tiro em arena que acontece em um mundo feito de voxels (cubos pequenos, mais ou menos). Tudo no jogo é exibido em uma tela virtual de 128x128x64 voxel, incluindo os menus e o inventário do jogador. Se você olhar de perto, às vezes poderá ver o inventário (pontuação / vida / munição) projetando uma sombra em alguns dos objetos no chão.

Estou trabalhando nas ferramentas de renderização e modelagem de voxel há muito tempo, com o objetivo final de criar um grande jogo de aventura para explorar. Cerca de meio ano atrás, ele se fundiu com o trabalho que eu fazia nos atiradores da Conflux, e esse é o resultado.

É um jogo bastante simples no coração - principalmente apenas o Robotron ambientado em um mundo destrutível em 3D com criaturas patetas. Não tenho certeza de quão importantes serão as implicações da destrutibilidade para a jogabilidade, mas com certeza é divertido afastar pedaços de parede. Também adicionei uma picape experimental de construção de paredes que você pode usar para construir barreiras para se esconder de monstros assustadores.

O jogo se passa em um pequeno conjunto de arenas. Alguns deles possuem salas com peças de ação, em algum lugar entre Knightlore e Smash TV. Este é um dos projetos originais baseados em aventuras voltando às aulas e uma desculpa para criar ambientes temáticos.

Recursos:

• Renderização de software personalizada com sombras suaves.
• Sintetizador de som e música embutido (também usado para fazer a música do trailer).
• Reprodução e gravação pós jogo.

Suponho que você já conhece alguma álgebra linear básica, do tipo envolvido em: projeções em 3D, configuração da câmera, transformação de vértices em posição mundial, etc. Aqui estão dois que eu gosto:

Arquitetura do Game Engine

• Breve cobertura da álgebra linear básica, mas abrange tudo o que você precisa saber. Vale a pena ter o livro por muitas outras razões também.

Renderização em tempo real

• Cobertura um pouco mais detalhada, mas novamente adere apenas ao que você precisa saber. Novamente, recomendo este para os tópicos abordados no restante dos capítulos.

Depois de saber como representar e manipular objetos 3D, você estará pronto para ver como desenhá-los na tela. Normalmente, isso é feito com uma técnica de rasterização de triângulo de linha de varredura. Na verdade, é um conceito bastante simples. Você desenha uma linha de um triângulo por vez enquanto interpola as coordenadas de cor e textura uv. Este processo é continuado para todos os triângulos na tela. Você pode até implementar um buffer de profundidade para processar renderizações fora de ordem.

Isso é abordado em mais detalhes nestes artigos:

Tutorial - Introdução à renderização baseada em software: rasterização de triângulo

Escola de Renderização de Software: Parte I

E só por diversão, confira o seguinte artigo:

Revisão do código-fonte do Quake 2 3/4 (renderizador de software)

Este é um tópico bastante amplo. No entanto, existem duas partes básicas: a teoria real do pipeline de transformação e rasterização de gráficos e os bits de implementação reais que permitem exibir pixels na tela da maneira que você escolher. Além disso, também há otimização (principalmente do último bit).

Felizmente, a primeira parte é a mesma que a teoria usada para o pipeline de gráficos, exposta por hardware e APIs modernos. Se você já sabe disso, está pronto. Caso contrário, recomendo um bom livro. Este é muito bom.

Existem muitas opções para a segunda parte. Eles dependem muito de suas escolhas de sistema operacional e cadeia de ferramentas. Se você estiver usando C ou C ++, no Windows, você pode simplesmente plotar pixels diretamente em um bitmap GDI ( SetPixelé simples, mas dolorosamente inútil - CreateDIBSectionfornece uma grande quantidade de bytes brutos que você pode manipular a uma taxa muito mais rápida).

Você também pode adquirir uma superfície DirectDraw e gravar nela, ou gravar em uma textura Direct3D ou OpenGL. Nestes últimos casos, você ainda estará usando hardware, mas contanto que faça toda a composição da imagem final na CPU e use as APIs de hardware para copiar os resultados na tela, isso ainda conta. Nos PCs modernos, você não pode acessar a VRAM simples ou qualquer coisa diretamente.

Se você quiser saber mais, provavelmente crie perguntas mais específicas. Eu ou outros ficaríamos felizes em respondê-las.

Ok, vou abordar essa questão desde o básico; qualquer coisa além dessa é ampla para um QA simples; você precisa comprar um livro sobre o assunto.

A diferença mais fundamental entre renderizar no software e usar uma GPU se resume à plotagem de pixels. Ou seja, ao fazer a renderização do software, você é responsável por plotar todos os pixels malditos, enquanto que com uma GPU, a plotagem de pixels é amplamente automatizada pelo hardware e você apenas "massageia" o pipeline de pixels usando shaders.

Por exemplo, pense no que você como programador precisa fazer para exibir um triângulo 3D na tela. Com uma GPU, você simplesmente diz ao hardware quais são as coordenadas X, Y, Z dos vértices e, em seguida, a placa de vídeo preenche todos os pixels na tela que compõem a imagem de um triângulo. Você pode usar um sombreador para dizer à GPU para alterar a cor de cada pixel com base em uma textura ou algo assim, mas, no final, ainda se resume à GPU preenchendo automaticamente todos os pixels para você.

Ao fazer a renderização do software, você teria que calcular quais pixels na tela preencher e, em seguida, fazer o corte para realmente preencher esses pixels. Ou seja, você faria a matemática da matriz para transformar o espaço de coordenadas da cena 3D no espaço de visualização, projetando pontos do espaço de visualização na tela etc.