Física de alto desempenho no Unity 5
Estamos usando o PhysX 2.8.3 há algum tempo. Não usamos apenas o PhysX padrão, mas o estendemos com vários patches feitos pelos engenheiros da Unity ao longo dos anos. Já faz muito tempo e agradecemos ao PhysX 2 por todos os peixes. Conforme anunciado na GDC'14, o Unity 5.0 apresenta uma atualização para o PhysX 3.3. Vamos dar uma olhada mais de perto.
O PhysX SDK 3 é uma reformulação radical do bom e velho PhysX SDK 2.x. Basicamente, a equipe do PhysX pegou as melhores ideias e as melhores abordagens da versão 2.x e reescreveu todo o SDK do zero. Isso significa que toda a base de código é diferente, todas as interfaces são diferentes e a maior parte da funcionalidade é diferente.
Agora vamos lhe dar uma amostra de como é usar a física do Unity 5.0.
Para começar com algo simples, tornamos a força adaptativa comutável e desativada por padrão. A força adaptativa é uma técnica especial do PhysX para compensar os erros numéricos ao simular pilhas. No entanto, o feedback dos desenvolvedores da Unity nos diz que a força adaptativa contribui muito para a instabilidade geral do conteúdo do jogo. Espere que suas coisas semelhantes a pilhas se comportem melhor no futuro.
Mover Static Colliders será muito mais econômico. Um Static Collider é apenas um GameObjects com um componente collider, mas sem um componente Rigidbody. Anteriormente, como o SDK presumia que os colisores estáticos não eram movidos, mover um colisor estático acionava uma reconstrução cara da árvore AABB que afetava muito o desempenho geral.
No Unity 5, usaremos a mesma estrutura de dados para lidar com o movimento de colisores dinâmicos e estáticos. Infelizmente, perderemos a vantagem de os colisores estáticos consumirem menos memória do que os dinâmicos. No entanto, no momento, o custo associado à movimentação de Static Colliders é uma das três principais causas de problemas de desempenho em jogos Unity. Queríamos mudar isso.
A detecção contínua de colisões foi aprimorada em uma ordem de magnitude. A detecção de colisão contínua é usada para evitar que corpos em movimento rápido passem por outros corpos sem que nenhuma colisão seja detectada. Imagine uma bala disparada contra um pedaço de papel ou um jogo de bilhar em que algumas bolas se movem mais rápido do que outras.
No Unity 5.0, o SDK gera todos os dados necessários para lidar com movimentos rápidos. Basta ativar a detecção contínua de colisões para que ela funcione. O PhysX3 apresenta um algoritmo usado para detectar se a dispendiosa simulação CCD é realmente necessária, dada a velocidade atual do corpo, ou se uma discreta padrão seria suficiente. Ele é ativado quando você ativa o CCD.
O PhysX3 oferece suporte a mais Rigidbodies na fase ampla. Na verdade, você poderá ter várias centenas de milhares de corpos em um único quadro em desktops e plataformas semelhantes a desktops. Anteriormente, havia um limite fixo de 64 mil em corpos. Essa não foi uma constante que pudemos aumentar facilmente - foi uma consequência da economia de muitos bits em todo o SDK. Alguns consoles, como o PlayStation 3, ainda terão essa limitação. Há também um limite para os materiais físicos: no momento em que este artigo foi escrito, você não pode ter mais de 64 mil materiais em nenhuma plataforma.
No Unity 5.0, reduzimos o custo de dimensionamento de Mesh Colliders. Anteriormente, ao dimensionar um Mesh Collider, era necessário criar uma nova malha com escala incorporada aos vértices, o que exigia tempo e memória valiosos. Com o PhysX3, podemos oferecer suporte a escalonamento não negativo sem nenhuma alteração. É basicamente gratuito.
A seguir, vamos dar uma olhada em dois subsistemas que diferem tanto da versão Unity 4.x que você pode considerá-los novos: os módulos de tecido e veículos.
Vamos começar com o tecido. No Unity 4, a simulação de tecido é suportada pelos componentes InteractiveCloth e SkinnedCloth. O InteractiveCloth tem um comportamento de malha semelhante a um tecido, ou seja, um "tecido físico" que interage com outros corpos físicos, pode aplicar forças e assim por diante. O InteractiveCloth é computacionalmente caro, portanto o Unity 4 tem outro, o SkinnedCloth, para roupas de personagens.
Como o SkinnedCloth é desacoplado do pipeline de simulação principal, ele pode ter um desempenho melhor do que o InteractiveCloth. O principal problema com o tecido é que ambos os componentes eram bastante instáveis e muito caros. Com a integração do PhysX3 chegando, decidimos abandonar o suporte ao InteractiveCloth e ter apenas um componente de tecido, chamado simplesmente de Cloth, projetado com as roupas dos personagens em mente.
No Unity 5.0, o Cloth não reage mais a todos os colisores em uma cena, nem aplica forças de volta ao mundo. Em vez disso, temos uma solução de vestuário de personagens mais rápida, multithread e mais estável. Quando você o adiciona, o novo componente Cloth não reage mais a nenhum corpo.
Portanto, o Cloth e o mundo não se reconhecem ou não se veem até que você adicione manualmente os colisores do mundo ao componente Cloth. Mesmo depois disso, a simulação ainda é unidirecional: o tecido reage a esses corpos, mas não aplica forças de volta. Além disso, você só pode usar três tipos de colisores com tecido: uma esfera, uma cápsula e colisores de cápsula cônica, construídos usando dois colisores de esfera. Todas essas alterações foram introduzidas para aumentar o desempenho.
A interface de criação no Unity 5.0 é semelhante à do SkinnedCloth, e estamos trabalhando arduamente para melhorar isso na versão 5.x. Espere ver coisas como a integração com avatares do Mecanim adicionadas durante o ciclo 5.x.
O novo componente Cloth é compatível com a GPU via CUDA internamente, mas decidimos lançá-lo mais tarde no ciclo 5.x por vários motivos. Em primeiro lugar, a CUDA só funciona no Windows com hardware NVIDIA, e temos uma grande presença no Mac e no Linux. Em segundo lugar, queremos realmente concentrar nossos esforços de correção de bugs nas coisas principais primeiro e, depois disso, passar a integrar as coisas mais sofisticadas.
Agora, algumas palavras sobre os veículos. O PhysX3 tem um SDK de veículo novo e brilhante que usamos para implementar nosso componente WheelCollider. O novo componente oferece suspensão e fricção de pneus muito mais realistas. Além disso, ele corrige uma série de outros problemas de longa data.
No Unity 5.0, o novo componente pode ser usado imediatamente para gerar um comportamento simples. Só espero que os desenvolvedores optem por pacotes de veículos na Asset Store quando quiserem algo que já esteja bem ajustado, realista ou avançado, como o Edy's Vehicle Package.
Veja o que consegui montar em algumas horas usando uma malha gratuita baixada da Web (a maior parte desse tempo foi gasta no Blender preparando o modelo):
E aqui está um dos SUVs do pacote de veículos do Edy:
Atualmente, Edy está trabalhando na nova versão de seu pacote, que trará mais coisas incríveis. Entre em contato diretamente com ele para obter mais detalhes.
Há muitos detalhes técnicos fantásticos sobre os veículos que eu gostaria de compartilhar com você, mas, por enquanto, vamos apenas dar uma olhada nos novos dispositivos do WheelCollider. Isso lhe dará uma ideia de como a suspensão também funcionará.
Na figura acima, o círculo e o diâmetro da roda estão marcados em verde, o segmento do curso da suspensão em laranja e a esfera do ponto de aplicação de força em verde. No segmento de curso da suspensão, há marcas para a posição de compressão máxima, posição de inclinação máxima e posição de destino.
Como era de se esperar, a roda só pode se deslocar entre as posições de compressão máxima e inclinação máxima. A posição de destino (também chamada de posição de repouso em conversas técnicas) está localizada exatamente onde o peso da mola é equilibrado pela força da mola, ou seja, a posição em que a roda está localizada quando o veículo está parado em uma superfície plana. Pode parecer difícil de ajustar, mas, na verdade, a posição de compressão máxima é onde sua roda está localizada originalmente na malha.
Em seguida, você especifica a distância da suspensão e a posição do alvo como uma fração da distância da suspensão. Apenas dois carros alegóricos para governar todos eles, nada demais! Eu já lhe disse que o novo dispositivo de roda agora atualiza a rotação e a posição a partir dos dados de simulação prontos para uso? Você não precisa nem mesmo adicionar a geometria real da roda e escrever o código de posicionamento da roda para visualizar suas configurações. Tudo isso está incorporado.
O PhysX3 agora está preparado para ser executado em vários núcleos, pois o modelo de computação interna é organizado em tarefas que podem ser executadas em núcleos diferentes. O SDK faz todo o multithreading, cuidando de todas as dependências e garantindo a decomposição ideal do trabalho.
Pelo que vimos até agora, é razoável esperar uma duplicação no desempenho, em geral, apenas como resultado de ter uma base de código melhor e multithreading aprimorado. Em alguns casos, a melhora é drástica, chegando a ser dez vezes maior.
Os ninjas do desempenho interessados em mais dados devem visitar o blog de Pierre Terdiman. Ele é o principal desenvolvedor por trás do PhysX SDK.
As novas funções têm aparência semelhante à da Unity, mas ainda há casos em que o comportamento é diferente, os parâmetros significam coisas diferentes ou, em alguns casos, os comportamentos antigos não são mais suportados. Portanto, a física do Unity 5.0 não é 100% compatível com o Unity 4.x. Prepare-se para reajustar seus projetos antigos e reescrever parte de seu código de física ao migrar de versões anteriores do Unity.
Há muito mais detalhes sobre a física no Unity 5 do que posso compartilhar nesta postagem. Sinta-se à vontade para fazer perguntas nos comentários ou, se estiver visitando nossa conferência de desenvolvedores Unity 2014 este ano, assista à minha palestra detalhada sobre física no Unity 5.0 e venha dizer oi e bater um papo.