Como os mecanismos de jogos modernos conseguem renderização em tempo real versus a renderização "lenta" do Blender?


90

Eu sou novo no gamedev e no Blender, e há algo que não posso abalar:

No Blender, uma renderização única (mesmo usando o renderizador Cycles mais avançado) pode levar até 45 segundos na minha máquina. Mas, obviamente, em um jogo, você pode ter gráficos incríveis e, portanto, a renderização está obviamente acontecendo continuamente, várias vezes por segundo em tempo real.

Então, eu também estou me perguntando o que é a desconexão, com relação à renderização "lenta" do Blender, em comparação com a forma como os mecanismos de jogo atingem a renderização em tempo real (ou quase em tempo real).


3
A renderização em tempo real é um tópico enorme por si só, há muitos livros escritos sobre ela (incluindo "Renderização em tempo real"). E prestadores de como ciclos de trabalho de forma completamente diferente do que prestadores de 3D em motores de jogo - você realmente não pode compará-los
UnholySheep

42
@ UnholySheep Claro que você pode compará-los. De que outra forma alguém explicaria a diferença, para responder à pergunta?
User985366

2
@ 10Respostas Mas essa pergunta não seria atual nesse site.
GiantCowFilms

3
@ 10: Enquanto o OP menciona o Blender, a questão se resume basicamente a por que os mecanismos de jogos em tempo real parecem renderizar cenas em 3D mais rapidamente do que os renderizadores em 3D aproximadamente foto-realistas (como o Blender, mas também muitos outros). Observe que esta também é a pergunta respondida pela resposta aceita. Com isso em mente, concordo que a questão é mais abordada aqui no Desenvolvimento de Jogos , onde perguntas sobre tecnologia geral de desenvolvimento de jogos podem ser feitas, e não no Blender , onde as perguntas são mais específicas do Blender em particular.
OR Mapper

3
Eu acho que o segredo aqui é que incrível não precisa ser preciso. Há aproximações rápidas para matemática utilizados na renderização em 3D, como InvSqrt
Dmitry Grigoryev

Respostas:


115

A renderização em tempo real, mesmo a renderização em tempo real moderna, é uma sacola de truques, atalhos, hacks e aproximações.

Pegue sombras, por exemplo.

Ainda não temos um mecanismo completamente preciso e robusto para renderizar sombras em tempo real a partir de um número arbitrário de luzes e objetos arbitrariamente complexos. Nós temos várias variantes nas técnicas de mapeamento de sombra, mas todas elas sofrem com os problemas conhecidos dos mapas de sombra e até as "correções" são apenas uma coleção de soluções alternativas e trocas (como regra geral, se você vê os termos "desvio de profundidade" ou "deslocamento de polígono" em qualquer coisa, então não é uma técnica robusta).

Outro exemplo de uma técnica usada pelos renderizadores em tempo real é o pré-cálculo. Se algo (por exemplo, iluminação) é muito lento para calcular em tempo real (e isso pode depender do sistema de iluminação que você usa), podemos pré-calculá-lo e armazená-lo, então podemos usar os dados pré-calculados em tempo real - tempo para um aumento no desempenho, que geralmente ocorre às custas de efeitos dinâmicos. Essa é uma troca direta de memória versus computação: a memória geralmente é barata e abundante, a computação geralmente não é, portanto, queimamos a memória extra em troca de uma economia na computação.

Os renderizadores offline e as ferramentas de modelagem, por outro lado, tendem a se concentrar mais na correção e qualidade. Além disso, como eles estão trabalhando com a geometria que muda dinamicamente (como um modelo que você está construindo), eles geralmente precisam recalcular as coisas, enquanto um renderizador em tempo real estaria trabalhando com uma versão final que não possui esse requisito.


14
Outro ponto a ser mencionado é que a quantidade de computação usada para gerar todos os dados que um jogo precisará para renderizar rapidamente vistas de uma área pode ser uma ordem de magnitude maior que a quantidade de computação necessária para renderizar uma vista. Se a renderização de visualizações de uma área demorar um segundo sem qualquer pré-cálculo, mas alguns dados pré-calculados puderem reduzir para 1/100 segundo, gastar 20 minutos nos pré-cálculos poderá ser útil se forem necessárias visualizações em um jogo em tempo real, mas se um quer apenas um dez segundo filme 24fps, teria sido muito mais rápido para passar quatro minutos ...
supercat

9
... gerando as 240 visualizações necessárias a uma taxa de um por segundo.
21817

@ supercat e por isso suas renderizações são praticamente livres de problemas e você ganha muito controle sobre o processo. Você poderia usar um mecanismo de jogo para renderizar ... se estivesse pronto para usar recursos. Mas como você disse, não vale a pena.
Joojaa

Um exemplo impressionante disso que me lembro é o mecanismo Quake original (~ 1996), capaz de obter gráficos 3D em tempo real relativamente impressionantes em máquinas muito limitadas, usando combinações de técnicas de pré-cálculo extremamente demoradas. Árvores BSP e efeitos de iluminação pré-renderizados foram gerados com antecedência; projetar um nível para esse mecanismo geralmente envolvia horas (geralmente durante a noite) de espera pelas ferramentas de compilação de mapas. O trade-off foi, essencialmente, diminuído o tempo de renderização em detrimento do tempo de criação.
Jason C #

(O motor de Perdição original [1993] tinha precalculations semelhantes Marathon. Pode ter também, mas eu não me lembro, eu me lembro construção de níveis de maratona, mas eu não me lembro o que estava envolvido.)
Jason C

109

A resposta atual fez um ótimo trabalho ao explicar os problemas gerais envolvidos, mas sinto que falta um detalhe técnico importante: o mecanismo de renderização "Cycles" do Blender é um tipo diferente de mecanismo usado pela maioria dos jogos.

Normalmente, os jogos são renderizados ao percorrer todos os polígonos de uma cena e desenhá-los individualmente. Isso é feito 'projetando' as coordenadas do polígono através de uma câmera virtual para produzir uma imagem plana. A razão pela qual essa técnica é usada para jogos é que o hardware moderno é projetado com base nessa técnica e pode ser feito em tempo real com níveis relativamente altos de detalhes. Fora de interesse, essa também é a técnica empregada pelo mecanismo de renderização anterior do Blender antes da Fundação Blender abandonar o mecanismo antigo em favor do mecanismo Cycles.

Renderização de polígono

Ciclos, por outro lado, é o que é conhecido como um mecanismo de rastreamento de raios. Em vez de olhar para os polígonos e renderizá-los individualmente, ele lança raios de luz virtuais para a cena (um para cada pixel na imagem final), reflete esse feixe de luz em várias superfícies e usa esses dados para decidir qual cor do pixel deveria estar. O Raytracing é uma técnica muito computacionalmente cara que o torna impraticável para renderização em tempo real, mas é usada para renderizar imagens e vídeos porque fornece níveis extras de detalhes e realismo.

Renderização de Raytracing


Observe que minhas breves descrições de traçado de raios e renderização de polígonos são altamente reduzidas por questões de brevidade. Se você deseja saber mais sobre as técnicas, recomendo que você procure um tutorial ou livro detalhado, pois suspeito que muitas pessoas tenham escrito explicações melhores do que eu poderia imaginar.

Observe também que há uma variedade de técnicas envolvidas na renderização 3D e alguns jogos realmente usam variações do traçado de raios para certos fins.


3
+1 para um ponto muito bom; Eu deliberadamente não fui ao buraco do coelho entre raytracing e rasterização, então é ótimo ter isso como um complemento.
Maximus Minimus

16
Essa resposta chega ao cerne da diferença. Os mecanismos de jogo realizam rasterização (encaminhada ou adiada), enquanto os renderizadores offline (como Blender, Renderman etc.) realizam o rastreamento de raios. Duas abordagens completamente diferentes para desenhar uma imagem.
21317 Sssell

4
@ LeComteduMerde-fou Como o gamedev é voltado para desenvolvedores de jogos, senti que uma explicação técnica suplementar seria benéfica para o leitor mais tecnicamente inclinado.
Pharap

11
@ssell É verdade, mas não se trata apenas de traçado de raios - mesmo sem traçado de raios, mesmo com renderização por GPU, a renderização do Blender é geralmente muito mais detalhada e mais lenta. Isso tem a ver principalmente com o foco na correção - melhor filtragem e resolução de textura, suavização de serrilhado, iluminação, mapeamento de sombras, precisão Z, quads, superfícies bidirecionais, grandes contagens de polígonos, contagens de polígonos grandes, saída de alta resolução, mapeamento de bump preciso , falta de mapas pré-calculados, metamorfose, cinemática precisa ... é uma longa lista de recursos que os mecanismos de jogo não possuem ou que falsificam.
Luaan 6/02

11
@Chii eu me lembrei. Eu estava pensando no ART VPS , era apenas aceleração, não em tempo real.
Jason C
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.