Pergunta

I recentemente comparou algumas das motor de física para fora lá para simulação e desenvolvimento de jogos. Alguns são gratuitos, alguns são opensource, alguns são comerciais (1 é ainda muito comercial $$$$). Havok, Ode, Newton (aka oxNewton), Bala, PhysX e "raw" build-in física em alguns 3D motores.

Em algum momento cheguei a conclusão ou a pergunta: Por que devo usar qualquer coisa, mas NVidia PhysX se eu posso fazer uso de seu desempenho incrível (se eu precisar dele) devido ao processamento de GPU? Com futuras placas NVidia posso esperar mais independente melhoria das etapas regulares de geração de CPU. O SDK é gratuito e está disponível para Linux também. Claro que é um pouco de vendor lock-in e não é opensource.

O que é a sua visão ou experiência? Se você começar agora com o desenvolvimento, você concorda com o acima?

aplausos

Foi útil?

Solução

Disclaimer: PhysX Eu nunca usei, minha experiência profissional é restrito a bala, Newton, e ODE. Desses três, ODE é de longe o meu favorito; é o mais estável numericamente e os outros dois têm questões de maturação (articulações úteis não implementadas, joint legal / combinações de motor comportam de maneiras indefinidas, & c).

Você aludiu ao vendor lock-in problema em sua pergunta, mas vale a pena repetir: se você usar o PhysX como sua solução de física única, as pessoas que utilizam AMD cartões não será capaz de executar o seu jogo (sim, eu sei que pode ser feito para trabalhar , mas não é oficial ou apoiados pela NVIDIA). Uma maneira de contornar isso é definir um mecanismo de failover, usando ODE ou algo em sistemas com AMD cartões. Isso funciona, mas ele dobra sua carga de trabalho. É sedutor para pensar que você vai ser capaz de esconder as diferenças entre os dois motores por trás de uma interface comum e escrever a maior parte de seu código física do jogo uma vez, mas a maioria de suas dificuldades com a física do jogo será em lidar com as idiossincrasias do seu especial motor de física, decidir sobre valores para coisas como o atrito de contacto e restituição. Esses valores não têm significados consistentes em motores de física e (principalmente) pode não ser formalmente derivados, assim que você está encontrando preso de boa aparência, valores que podem ser reproduzidos por experimento. Com PhysX mais um failover que está fazendo todo esse trabalho SCUT duas vezes.

Em um nível superior, eu não acho que qualquer do fluxo de APIs de processamento são ainda totalmente cozido, e eu estaria relutante em se comprometer com um até, pelo menos, nós temos como a reação do cliente Larrabee da Intel molda projetos dos povos.

Assim, longe de ver PhysX como a escolha óbvia para o desenvolvimento de jogos high-end, eu diria que ele deve ser evitado a menos que ou você não acha que as pessoas com AMD cartões compõem uma fração significativa de sua base de jogadores (altamente improvável ) ou você tem o suficiente de codificação e QA mão de obra para teste de dois motores de física (mais plausível, embora se sua empresa é que rico eu ouvi coisas boas sobre Havok). Ou, eu acho que, se você tiver criado um jogo de física com exigências de desempenho tão intensa que só streaming de física pode satisfazê-lo - mas, nesse caso, eu aconselho você a começar uma banda e deixe a Lei de Moore fazer a sua coisa por um ano ou dois.

Outras dicas

Um início de 2013 resposta atualização: I desenvolver para o que eu considero os três grandes OS: Linux, OS X, MS. Eu também desenvolver com as três grandes bibliotecas físicas:. PhysX, Havok, Bala

No que diz respeito PhysX, eu recentemente fiz alguns testes com o mais recente encarnação sendo 3.2.2 a partir do momento da redação deste texto. Na minha opinião nVidia realmente reduziu a eficácia da biblioteca. O maior deles é a falta de aceleração de corpos rígidos. A lib só acelera as partículas e pano. Mesmo aqueles que não interagir com corpos rígidos gerais. Estou completamente confuso com nVidia fazendo isso uma vez que têm uma unidade de marketing enorme empurrando GPU acelerada aplicativos, com foco em computação científica com uma grande força motriz sendo simulação de física.

Assim, enquanto as minhas expectativas do rei da física sim sendo PhysX, Havok, e Bullet nessa ordem vejo o contrário na realidade. Bala lançou lib 2.8.1 com uma amostragem de apoio OpenCL. Bala é um relativamente pequeno lib com generosa de licenciamento. Seu objetivo é ter versão 3 com aceleração corpo rígido OpenCL totalmente integrada.

Parte dos comentários falar sobre vários caminhos de código. A minha opinião é esta não é negócio um grande demais. Eu já suportam três sistemas operacionais com suporte rígido código mínimo (enfiar em sua maior parte e não usar código específico OS, uso C ++ e modelos lib std). É semelhante para as bibliotecas física. Eu uso uma biblioteca compartilhada e abstrata de uma interface comum. Isso é bom porque a física não muda muito;) Você ainda precisará configurar um ambiente de simulação, gerenciar objetos, render iterações no ambiente, a limpeza quando terminar. O resto é flash, implementado no lazer.

Com o advento da OpenCL em bibliotecas tradicionais (NVIDIA CUDA está muito perto - ver demos Bala OpenCL). A obra física plugin irá encolher

Assim, a partir do zero e só preocupado com modelagem física? Você não pode dar errado com bala. Pequeno, licença flexível (gratuito), muito perto de produção pronto OpenCL que será multi-plataforma através dos três grandes soluções OS e GPU.

Boa sorte!

Você pode achar isso interessante:

http://www.xbitlabs.com/news/video/display /20091001171332_AMD_Nvidia_PhysX_Will_Be_Irrelevant.html

É tendenciosa ... é basicamente uma entrevista com AMD ... mas faz alguns pontos que eu acho que vale a pena considerar no seu caso.

Por causa dos problemas de David Seiler apontou, trocando motores de física em algum momento no futuro pode ser um problema enorme / intransponível ... especialmente se o jogo está fortemente ligada à física.

Então, se você realmente quiser acelerado por hardware física no seu motor Agora, vá para Physx, mas esteja ciente de que quando as soluções tais como aqueles postulada pela AMD neste artigo se tornam disponíveis (eles absolutamente irá , mas eles não estão aqui ainda), você será confrontado com escolhas desagradáveis:

1) reescrever o seu motor para uso (inserir nome do novo hardware multi-plataforma acelerada motor de física), potencialmente alterando a dinâmica do seu jogo de uma maneira ruim

2) continuam usando Physx única, totalmente negligenciar os usuários da AMD

3) tentar obter Physx ao trabalho na AMD GPUs (blech ...)

Além da ideia de David de usar um motor de física CPU como um fallback (fazer o dobro do trabalho e produzindo 2 motores que não se comportam de forma idêntica) sua única outra opção é usar a física CPU puro.

No entanto, como coisas como OpenCL torna-se dominante, podemos ver ODE / Bala / parentes começando a incorporar essa ... IOW se você código-lo agora com ODE / Bala / parentes que você pode (provavelmente acabará) obter a aceleração GPU para "livre", mais tarde (sem alterações em seu código). Ele ainda vai se comportar de forma ligeiramente diferente com a versão GPU (um problema inevitável por causa do efeito borboleta e diferenças na implementação de ponto flutuante), mas pelo menos você terá a ODE / Bala / parentes de trabalho comunidade com você para reduzir essa lacuna .

Essa é a minha recomendação: use uma biblioteca física open source que atualmente só usa a CPU, e esperar por ele para fazer uso de GPUs via OpenCL, CUDA, a linguagem corrente da ATI, etc. O desempenho será gritando rápido quando isso acontece, e você salve-se dores de cabeça.

O benefício hipotético de futuros cartões gfx é tudo muito bem, mas também haverá benefícios futuros de núcleos extra de CPU também. você pode ter certeza que os cartões de futuro gfx terá sempre energia extra para sua física?

Mas, provavelmente, a melhor razão, embora um pouco vago, neste caso, é que o desempenho não é tudo. Como acontece com qualquer biblioteca parte 3, você pode precisar de apoio e atualizar esse código para os próximos anos, e você vai querer ter certeza de que as interfaces são razoáveis, a documentação é bom, e que tem as capacidades que você exigem.

Também pode haver preocupações mais matemáticos tais como algumas APIs que oferecem resolução de equações mais estável e afins, mas vou deixar comentário de que para um especialista.

Eu usei ODE e agora usando PhysX . PhysX faz construindo cenas mais fácil e (a minha opinião pessoal) parece mais realista, no entanto, não há nenhuma documentação adequada para PhysX ; na verdade quase nenhuma documentação. Por outro lado, ODE é de código aberto e há uma abundância de documentos, tutoriais etc. PS: Usando GPU accelaration é ajudar-me e os meus colegas de forma significativa; estamos usando APEX destruição e PhysX partículas.

PhysX funciona com não placas nVidia, ele simplesmente não se acelerado. Deixando-o na mesma posição os outros motores estão para começar. O problema é se você tem uma simulação física que só é viável com aceleração de física hardware.

Se todo o seu código é maciçamente paralelizable, então vá para ele!

para tudo o resto, as GPUs são lamentavelmente inadequados.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top