PhysX para un rendimiento masivo a través de la GPU?

Question

Hace poco comparado algunos del motor de física que hay para la simulación y el desarrollo del juego. Algunos son gratuitos, algunos son de código abierto, algunos son comerciales (1 es aún muy comercial $$$$). Havok, Oda, Newton (también conocido como oxNewton), Bala, PhysX y "cruda" construir-en la física en algunos motores 3D.

En algún momento llegué a la conclusión o la pregunta: ¿Por qué usar cualquier cosa menos PhysX si puedo hacer uso de su asombrosa actuación (si lo necesito) debido al procesamiento de la GPU? Con las futuras tarjetas NVidia que puedo esperar una mejora adicional independiente de los pasos habituales de generación de CPU. El SDK es gratuito y está disponible para Linux. Por supuesto, es un poco de los proveedores de tecnología y no es de código abierto.

¿Cuál es su visión o experiencia? Si desea comenzar ahora con el desarrollo, ¿está de acuerdo con lo anterior?

aplausos

Answer 1

Renuncia: Nunca he usado PhysX, mi experiencia profesional se limita a bala, Newton y ODE. De los tres, ODE es de lejos mi favorito; Es el más estable numéricamente y los otros dos tienen problemas de madurez (articulaciones útiles no implementadas, conjunta legal / combinaciones de motor que se comportan de un modo indefinido, y C).

aludido al tema dependencia de un proveedor en su pregunta, pero vale la pena repetirlo: si utiliza PhysX como su solución de la física única, las personas que utilizan tarjetas de AMD no será capaz de ejecutar su juego (sí, sé que puede llegar a funcionar , pero no es oficial o con el apoyo de NVIDIA). Una forma de evitar esto es definir un motor de conmutación por error, utilizando ODE o algo en sistemas con tarjetas de AMD. Esto funciona, pero duplica su carga de trabajo. Es seductora a pensar que usted será capaz de ocultar las diferencias entre los dos motores detrás de una interfaz común y escribir la mayor parte de su código de la física del juego una vez, pero la mayor parte de sus dificultades con la física del juego habrá en el tratamiento de la idiosincrasia de su especial motor de física, de decidir sobre los valores para cosas como la fricción de contacto y la restitución. Esos valores no tienen significados coherentes a través de motores de física y (en su mayoría) no pueden derivarse formalmente, por lo que está atascado encontrar buen aspecto, valores reproducibles por el experimento. Con PhysX además de una conmutación por error que está haciendo todo el trabajo sucio sí dos veces.

En un nivel superior, no creo que ninguna de las API de procesamiento de la corriente son totalmente cocido todavía, y me gustaría ser reacios a comprometerse a una hasta, por lo menos, tenemos la forma en la reacción de los clientes de Intel Larrabee da forma a los diseños de las personas.

Así que lejos de ver PhysX como la opción obvia para el desarrollo de juegos de gama alta, yo diría que debe evitarse a menos que cualquiera que no cree que las personas con tarjetas de AMD constituyen una fracción significativa de su base de jugadores (muy poco probable ) o que tiene suficiente mano de obra de codificación y control de calidad para probar dos motores de física (más plausible, aunque si su empresa es que ricos he oído cosas buenas sobre Havok). O, supongo, si usted ha diseñado un juego de la física con las demandas de rendimiento tan intenso que sólo la transmisión de la física que puede satisfacer - pero en ese caso, me gustaría aconsejarle a formar una banda y dejar que la Ley de Moore haga su trabajo durante un año o dos.

Answer 2

Un principios de 2013 actualización respuesta: yo desarrollo por lo que considero los tres grandes SO: Linux, OS X, MS. También se desarrollan con los tres grandes bibliotecas físicas:. PhysX, Havok, Bala

En cuanto a PhysX, hace poco hice algunas pruebas con la nueva encarnación de ser 3.2.2 a partir del momento de escribir estas líneas. En mi opinión nVidia realmente reduce la eficacia de la biblioteca. El más grande es la falta de aceleración de los cuerpos rígidos. El lib sólo acelera partículas y tela. Incluso aquellos no interfase con cuerpos rígidos generales. Estoy completamente desconcertado por nVidia hacer esto, ya que tienen una gran campaña de marketing empujando aplicaciones GPU acelerada, centrándose en la computación científica con una gran fuerza impulsora siendo simulación física.

Así, mientras que mis expectativas de que el rey de la física sim siendo PhysX, Havok, y la bala en ese orden Veo a la inversa en la realidad. Bala ha lanzado lib 2.8.1 con una muestra de apoyo OpenCL. Bala es una parte relativamente pequeña lib con generosa concesión de licencias. Su objetivo es tener la versión 3 con una aceleración OpenCL cuerpo rígido totalmente integrado.

parte de los comentarios hablan de múltiples rutas de código. Mi opinión es que no es demasiado grande a un acuerdo. Ya soportar tres sistemas operativos compatibles con código de disco mínima (threading en su mayor parte y no usar el código específico del sistema operativo, el uso de C ++ y std plantillas lib). Es similar para las bibliotecas de la física. Yo uso una biblioteca compartida y el resumen de una interfaz común. Esto está bien porque la física no cambia mucho;) De todos modos tendrá que configurar un entorno de simulación, gestión de objetos, render iteraciones en el medio ambiente, limpiar cuando haya terminado. El resto es flash, implementado en el ocio.

Con el advenimiento de OpenCL en las bibliotecas convencionales (NVIDIA CUDA está muy cerca - ver demostraciones de bala OpenCL). Plugin de la obra física se reducirá

Por lo tanto, a partir de cero y sólo se ocupa de modelado de la física? Usted no puede ir mal con bala. licencia pequeño y flexible (gratis), muy cerca de la producción listo OpenCL que será multiplataforma a través de las tres grandes soluciones OS y GPU.

Buena suerte!

Answer 3

Se puede encontrar este interesante:

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

Es sesgada ... es básicamente una entrevista con AMD ... pero tiene algunos puntos que creo que vale la pena considerar en su caso.

Debido a los problemas de David Seiler señaló, el cambio de motores de física en algún momento del futuro puede ser un gran problema / insuperables ... sobre todo si el juego está estrechamente ligada a la física.

Por lo tanto, si realmente desea la física de aceleración por hardware en su motor Ahora, vaya a PhysX, pero tenga en cuenta que cuando las soluciones tales como los postulados por AMD en este artículo están disponibles (que absolutamente , pero que no están aquí todavía), se le enfrenta con opciones desagradables:

1) reescribir su motor a utilizar (insertar nombre del nuevo motor de física acelerada por hardware multiplataforma), lo que podría cambiar la dinámica de su juego en un mal camino

2) continuar usando solamente PhysX, descuidando por completo usuarios de AMD

3) tratar de conseguir PhysX para trabajar en las GPU de AMD (Blech ...)

Además de la idea de David de la utilización de un motor de física de la CPU como punto de retorno (hacer el doble de trabajo y la producción de 2 motores que no se comportan de forma idéntica) a su única otra opción es utilizar la física de la CPU puro.

Sin embargo, como cosas como OpenCL se convierte en la corriente principal podemos ver ODE / bala / kin empezando a incorporar eso ... OIA Si se codifican ahora con ODE / bala / kin es posible que (probablemente con el tiempo) obtener la aceleración de GPU para "libre" más tarde (no hay cambios en su código). Todavía se comportarán de forma ligeramente diferente a la versión de la GPU (un problema inevitable debido al efecto mariposa y diferencias en la implementación de coma flotante), pero al menos tendrá la / bala / ODE comunidad pariente que trabaja con usted para reducir esa brecha .

Esa es mi recomendación: utilizar una biblioteca de la física de código abierto que actualmente sólo se utiliza la CPU, y esperar a que se haga uso de la GPU a través de OpenCL, CUDA, el lenguaje corriente de ATI, etc. El rendimiento puede estar gritando rápido cuando eso sucede, y se ahorrará dolores de cabeza.

Answer 4

El hipotético beneficio de las futuras tarjetas gfx es todo muy bien, pero también habrá beneficios futuros de núcleos de CPU adicionales también. Puede usted estar seguro de que las futuras tarjetas gfx siempre tendrán la capacidad disponible para su física?

Pero, probablemente, la mejor razón, aunque un poco vaga en este caso, es que el rendimiento no es todo. Al igual que con cualquier biblioteca de tercera parte, puede que tenga que apoyar y mejorar ese código en los próximos años, y que va a querer asegurarse de que las interfaces son razonables, la documentación es buena, y que tiene las capacidades que se requerir.

También puede haber problemas matemáticos más como algunas API que ofrecen ecuación más estable resolver y similares, pero voy a dejar comentarios en que para un experto.

Answer 5

He utilizado ODE y ahora utilizando PhysX . PhysX hace que la construcción de las escenas más fácil y (mi opinión personal) parece más realista, sin embargo, no existe documentación suficiente para PhysX ; de hecho, casi ningún tipo de documentación. Por otro lado, ODE es de código abierto y hay un montón de documentos, tutoriales, etc. PS: El uso de la GPU accelaration mí y mis colegas está ayudando de manera significativa; estamos utilizando APEX destrucción y PhysX partículas.

Answer 6

PhysX funciona con tarjetas nVidia no, que simplemente no hay acelerado. Dejándolo en la misma posición de los otros motores son para empezar. El problema es que si tienes una simulación física que sólo es viable con la aceleración física del hardware.

Answer 7

Si todo el código es masivamente paralelizable, a continuación, ir a por ello!

para todo lo demás, las GPU son lamentablemente inadecuados.