Mostrar uma colisão em câmera lenta é computacionalmente relaxante?

Em muitos jogos de corrida ( Burnout Paradise , por exemplo), quando uma colisão está prestes a acontecer, o jogo muda automaticamente para câmera lenta e continua em sequência lenta até que a colisão esteja completa.

Eu sempre pensei que isso era para os efeitos. Você não quer perder nenhuma parte da colisão! Recentemente, um dos meus amigos sugeriu que isso seja feito para garantir que não haja uma taxa esmagadora de processamento necessária quando ocorrer uma colisão.

Agora acho que é realmente o contrário. Quando ocorre uma colisão, muitos detalhes são mostrados em câmera lenta, tenho certeza de que há uma sobrecarga no pipeline de computação e renderização.

O que é correto?

Uma cena de câmera lenta aumenta o uso da CPU / GPU ou diminui-o?

Se você estiver executando sua simulação física com um timestap fixo (como deveria), uma câmera lenta colocará menos carga na simulação física, porque menos cálculos terão que ser feitos por quadro.

Vamos supor que você esteja executando sua física com 200 atualizações por segundo. Por exemplo. uma atualização a cada 0.005segundo do tempo de simulação. Ao executar o jogo com 50 atualizações por segundo, isso resultaria em 4 atualizações físicas por atualização de renderização. Agora você rodaria o jogo em câmera lenta, o que significa que você está diminuindo o tempo da simulação. Portanto, se o jogo ainda rodar a 50 atualizações por segundo ( 0.02segundos de tempo de simulação), mas você estiver mostrando o mundo em câmera lenta (digamos metade da velocidade), um quadro será equivalente a 0.01segundos de tempo de simulação. Portanto, apenas 2 atualizações físicas por quadro renderizado. Significando menos cálculos físicos por quadro renderizado.

Portanto, se você está olhando da perspectiva do uso da CPU por quadro renderizado, a câmera lenta é menos pesada (a menos que você opte por aumentar sua taxa de simulação física durante a câmera lenta). A carga da GPU por quadro é obviamente bastante constante.

Se você está perguntando sobre a carga cumulativa de CPU / GPU pela duração de uma colisão , obviamente a simulação de física é a mesma, seja em câmera lenta ou em velocidade normal. A carga da GPU será maior, porque você renderiza mais quadros.

É possível que esse seja o caso. A menos que você esteja fazendo física pela colisão na GPU, isso significa agachamento para isso. Mas em termos da própria física ... é possível.

Se você estiver simulando o movimento de vários corpos, eles tendem a se mover de uma maneira muito previsível. Forças e campos de força (isto é, gravidade) são facilmente previsíveis. Onde as coisas se movem é rapidamente calculado.

Até que uma coisa atinja outra. Veja, em física, você tem o que é chamado de divisão do tempo; essa é a quantidade de tempo que a execução do sistema de física cobre. Se sua divisão temporal cobrir 1/30 de segundo (30 fps para a atualização física), cada atualização física moverá objetos 33,3 milissegundos para o futuro.

Quando os objetos não colidem, você pode movê-los do início desses 33,3ms para o final. A física para fazê-lo é simples e é conhecida há séculos. Você apenas determina a aceleração das forças da rede, aplica essa aceleração para a fatia do tempo ao objeto e move-a em sua nova velocidade (nota: isso pode ser mais complexo se você desejar maior precisão).

O problema é quando os objetos colidem. De repente, agora você precisa processar as forças da física dentro de um intervalo de tempo, em vez de apenas uma vez no início. Se um objeto colidir duas ou três vezes dentro de um quadro de física, então é preciso refazer mais cálculos de física.

Se você tiver muitas colisões dentro de uma fatia de tempo, poderá realmente matar sua taxa de quadros. No entanto, a chance de várias colisões em uma fatia de tempo diminui à medida que o tamanho da fatia de tempo diminui. Sims de corrida sofisticados, como Forza e Gran Turismo, executam seus sistemas de física em incríveis taxas de quadros. Acho que um deles atinge mais de 300 fps na atualização física.

Câmera lenta é o equivalente efetivo disso. Ao diminuir o tempo da física, sem aumentar também a taxa de quadros de renderização para compensar, o mundo parece mais lento. E, portanto, você torna muito menos provável que você tenha várias colisões em um intervalo de tempo.

Dito isto, duvido que seja por isso que jogos como esse entrem em câmera lenta. Em geral, é mais para talento visual e apresentação dramática. Esses sistemas de física geralmente podem lidar com isso, em termos de desempenho.

Antes de tudo, isso é feito pelo efeito visual, não por razões de desempenho.

A maneira padrão de lidar com o desempenho em jogos pesados ​​de física é escalar o número de objetos, escalar a complexidade do objeto e mexer nas configurações do mecanismo para escalar entre precisão e desempenho da simulação. Se houver problemas, você descartará o que considera os recursos menos significativos.

Lembre-se, porém, a indústria criou jogos de carros bastante realistas nos últimos 15 anos, com computadores modernos, não é como se eles tivessem que voltar para três rodas para fazer as coisas funcionarem.

O problema:
é verdade que uma colisão pode causar trabalho extra, quanto depende muito das especificidades do jogo, um mecanismo de física mais detalhado terá muitas colisões pequenas entre partes diferentes que podem constituir um aumento significativo na computação necessária . Mas isso deve ser levado em consideração quando a física é dimensionada, não é um problema obter uma boa física que ainda possa lidar com algumas colisões.

Se você simplesmente executar a simulação física mais lentamente para obter câmera lenta, a carga cairá proporcionalmente. No entanto, deve-se notar que os requisitos para câmera lenta e física em tempo real são diferentes, você pode ter menor precisão quando as coisas acontecem na velocidade da corrida. Desde que o jogador não perceba que o mecanismo de física está errado, isso não é um grande problema, o movimento lento torna os deslizamentos muito mais fáceis de capturar, portanto, o movimento lento tem um requisito de precisão mais alto.

Pode-se optar por usar a mesma física, dimensionada para atender aos dois conjuntos de requisitos. Essa solução exigirá um poder de processamento extra, mas é fácil de implementar e dados computadores modernos perfeitamente viáveis.

Mudar as configurações físicas é mais complicado, mas pode resultar em algumas colisões deslumbrantes, além de aumentar a precisão, também é possível trocar os modelos físicos dos carros por modelos mais detalhados que quebram de maneira mais realista. Esse modo deve acabar usando aproximadamente a mesma quantidade de tempo de CPU para a física que o modo normal, simplesmente porque ambos são dimensionados para serem executados na mesma configuração de minspec.

Uma maneira intermediária é usar um mecanismo de física de passo variável; em geral, eles aumentam a precisão quando você diminui a velocidade da simulação, resolvendo pelo menos parte do problema. Existem outras razões para não usar a física de passo variável, mas o passo variável ainda é bastante comum no setor.