Física de alto rendimiento en Unity 5

ANTHONY YAKOVLEV / UNITY TECHNOLOGIESContributor
Jul 8, 2014|8 minutos
Física de alto rendimiento en Unity 5
Para tu comodidad, tradujimos esta página mediante traducción automática. No podemos garantizar la precisión ni la confiabilidad del contenido traducido. Si tienes alguna duda sobre la precisión del contenido traducido, consulta la versión oficial en inglés de la página web.
Nos gustaría destacar algunos de los cambios en la física 3D que puedes esperar en Unity 5.0.

Llevamos un tiempo utilizando PhysX 2.8.3. No nos hemos limitado a utilizar el PhysX de serie, sino que lo hemos ampliado con numerosos parches creados por los ingenieros de Unity a lo largo de los años. Ha pasado mucho tiempo, y damos las gracias a PhysX 2 por todo el pescado. Como se anunció en la GDC'14, Unity 5.0 incluye una actualización a PhysX 3.3. Veámoslo más de cerca.

PhysX SDK 3 es un rediseño radical del viejo PhysX SDK 2.x. Básicamente, el equipo de PhysX ha tomado las mejores ideas y los mejores enfoques de la versión 2.x y ha reescrito todo el SDK desde cero. Eso significa que toda la base de código es diferente, todas las interfaces son diferentes y la mayor parte de la funcionalidad es diferente.

Ahora vamos a darte una muestra de cómo se siente usar la física de Unity 5.0.

Para empezar con algo sencillo, hemos hecho que la fuerza adaptativa sea conmutable y esté desactivada por defecto. La fuerza adaptativa es una técnica especial de PhysX para compensar errores numéricos al simular pilas. Sin embargo, los comentarios de los desarrolladores de Unity nos dicen que la fuerza adaptativa contribuye mucho a la inestabilidad general del contenido del juego. Espera que tus cosas apiladas se comporten mejor en el futuro.

Desplazamiento de los colisionadores estáticos

Mover los Static Colliders será mucho menos costoso. Un Static Collider es simplemente un gameobject con un componente collider en él, pero sin un componente Rigidbody. Anteriormente, como el SDK asumía que los Static Colliders no se movían, mover un Static Collider provocaba una costosa reconstrucción del árbol AABB que afectaba gravemente al rendimiento general.

En Unity 5, usaremos la misma estructura de datos para manejar el movimiento de los colliders dinámicos y estáticos. Por desgracia, perderemos la ventaja de que los colisionadores estáticos consumen menos memoria que los dinámicos. Sin embargo, ahora mismo, el coste asociado al movimiento de los Static Colliders es una de las 3 principales causas de problemas de rendimiento en los juegos de Unity. Queríamos cambiar eso.

Detección de colisiones

La detección continua de colisiones se ha mejorado en un orden de magnitud. La detección continua de colisiones se utiliza para evitar que los cuerpos que se mueven rápidamente atraviesen a otros cuerpos sin que se detecte ninguna colisión. Imagínese una bala disparada a un trozo de papel, o una partida de billar en la que algunas bolas se mueven más rápido que otras.

En Unity 5.0, el SDK genera todos los datos necesarios para manejar el movimiento rápido. Sólo tienes que activar la detección continua de colisiones y funciona. PhysX3 cuenta con un algoritmo utilizado para detectar si la costosa simulación CCD es realmente necesaria dada la velocidad actual del cuerpo o si una discreta por defecto funcionaría bien. Se activa una vez que habilitas el CCD.

mesa de billar
Cuerpos rígidos en la fase ancha

PhysX3 soporta más Rigidbodies en el broadphase. De hecho, podrás tener varios cientos de miles de cuerpos en un solo fotograma en plataformas de sobremesa y similares. Antes, había un límite fijo de 64k en los cuerpos. No era una constante que pudiéramos aumentar fácilmente, sino la consecuencia de ahorrar muchos bits en todo el SDK. Algunos objetivos de consola, como PlayStation 3, seguirán teniendo esta limitación. También hay un límite en los materiales de física: en el momento de escribir esto, no puedes tener más de 64k de materiales en ninguna plataforma.

Escalar los Mesh Colliders es gratis (más o menos)

En Unity 5.0 hemos reducido el costo de escalar Mesh Colliders. Antes, al escalar un Mesh Collider, había que crear una nueva malla con la escala incorporada en los vértices, lo que requería un tiempo y una memoria valiosos. Con PhysX3 somos capaces de soportar el escalado no negativo sin ningún tipo de baking. Básicamente es gratis.

A continuación, echemos un vistazo a dos subsistemas que difieren tanto de la versión Unity 4.x que puedes considerarlos nuevos: los módulos de telas y vehículos.

Componente de tela

Empecemos por la tela. En Unity 4 la simulación de telas es soportada a través de los componentes InteractiveCloth y SkinnedCloth. InteractiveCloth tiene un comportamiento de malla tipo tela, es decir, "tela física" que interactúa con otros cuerpos físicos, puede aplicar fuerzas, etc. InteractiveCloth es caro computacionalmente, por lo que Unity 4 tiene otro, SkinnedCloth, para la ropa de los personajes.

Dado que SkinnedCloth está desacoplado del proceso principal de simulación, su rendimiento es mejor que el de InteractiveCloth. El principal problema de la tela es que ambos componentes eran bastante inestables y costaban mucho. Con la llegada de la integración de PhysX3, hemos decidido dejar de dar soporte a InteractiveCloth y tener sólo un componente de tela, llamado simplemente Cloth, diseñado pensando en la ropa de los personajes.

En Unity 5.0, Cloth ya no reacciona a todos los colliders en una escena, ni aplica fuerzas de vuelta al mundo. En su lugar, tenemos una solución de confección de caracteres más rápida, multihilo y estable. Al añadirlo, el nuevo componente Tela ya no reacciona ante ningún cuerpo.

Por lo tanto, Cloth y el mundo no se reconocen ni se ven hasta que añades manualmente colisionadores del mundo al componente Cloth. Incluso después de eso, la simulación sigue siendo unidireccional: la tela reacciona a esos cuerpos pero no aplica fuerzas de vuelta. Además, sólo puedes usar tres tipos de colisionadores con tela: uno de esfera, uno de cápsula y uno de cápsula cónica, construido usando dos colisionadores de esfera. Todos estos cambios se han introducido para aumentar el rendimiento.

La interfaz de creación en Unity 5.0 es similar a la de SkinnedCloth, y estamos trabajando duro para mejorarla en 5.x. Es de esperar que durante el ciclo 5.x se añadan cosas como la integración con los avatares de Mecanim.

El nuevo componente Cloth es compatible internamente con la GPU a través de CUDA, pero hemos decidido publicarlo más adelante en el ciclo 5.x por varias razones. En primer lugar, CUDA sólo funciona en Windows con hardware NVIDIA, y tenemos una gran presencia en Mac y Linux. En segundo lugar, queremos centrar nuestros esfuerzos de corrección de errores primero en el núcleo y pasar después a integrar cosas más sofisticadas.

Nuevo SDK para vehículos

Ahora, unas palabras sobre los vehículos. PhysX3 tiene un nuevo y brillante SDK de vehículos que hemos utilizado para implementar nuestro componente WheelCollider. El nuevo componente ofrece una suspensión y una fricción de los neumáticos mucho más realistas. Además, soluciona otros problemas de larga data.

En Unity 5.0, el nuevo componente se puede utilizar directamente para generar un comportamiento sencillo. Sólo espero que los desarrolladores recurran a los paquetes de vehículos de la Tienda de Activos cuando quieran algo que ya esté afinado, sea realista o avanzado, como el paquete de vehículos de Edy.

Mira lo que he sido capaz de montar en un par de horas usando una malla gratuita descargada de la web (la mayor parte de ese tiempo lo pasé en Blender preparando el modelo):

Y aquí está uno de los SUV del paquete de vehículos de Edy:

Edy está trabajando actualmente en la nueva versión de su paquete que traerá más cosas increíbles. Póngase en contacto directamente con él para más detalles.

Hay muchos detalles técnicos fantásticos sobre los vehículos que me gustaría compartir con ustedes, pero, por ahora, echemos un vistazo a los nuevos artilugios WheelCollider. Esto también le dará una idea de cómo va a funcionar la suspensión.

wheel gizmo

En la imagen anterior, el círculo y el diámetro de la rueda están marcados en verde, el segmento de recorrido de la suspensión en naranja y la esfera del punto de aplicación de la fuerza en verde. En el segmento de recorrido de la suspensión, hay marcas para la posición de compresión máxima, la posición de caída máxima y la posición objetivo.

Como es de esperar, la rueda sólo puede desplazarse entre las posiciones de máxima compresión y máxima caída. La posición de destino (también denominada posición de reposo en las charlas técnicas) se sitúa exactamente donde el peso elástico está equilibrado por la fuerza del muelle; es decir, la posición en la que se encuentra la rueda cuando el vehículo está parado sobre una superficie plana. Puede parecer difícil de afinar, pero, en realidad, la posición de compresión máxima es donde se encuentra originalmente su rueda en la malla.

A continuación, especifica la distancia de suspensión y la posición objetivo como fracción de la distancia de suspensión. Sólo dos carrozas para gobernarlas a todas, ¡no es gran cosa! ¿Te he dicho que el nuevo artilugio de la rueda actualiza ahora la rotación y la posición a partir de los datos de simulación? Ni siquiera tienes que añadir la geometría real de la rueda y escribir el código de posicionamiento de la rueda para previsualizar tu configuración. Está todo integrado.

Rendimiento

PhysX3 está ahora preparado para funcionar en multinúcleos, ya que el modelo de cálculo interno está organizado en tareas que pueden ejecutarse en distintos núcleos. El SDK se encarga de todo el multithreading, ocupándose él mismo de todas las dependencias y garantizando una descomposición óptima del trabajo.

Por lo que hemos visto hasta ahora, es razonable esperar una duplicación del rendimiento en general sólo como resultado de tener una mejor base de código y un multihilo mejorado. En algunos casos, la mejora es espectacular, hasta diez veces superior.

Los ninjas del rendimiento interesados en más datos deberían visitar el blog de Pierre Terdiman. Es el principal desarrollador del SDK de PhysX.

Compatibilidad

Las nuevas funciones se parecen a las de Unity, pero todavía hay casos en los que el comportamiento es diferente, los parámetros significan cosas diferentes o, en algunos casos, los comportamientos antiguos ya no son compatibles. Por lo tanto, la física de Unity 5.0 no es 100% compatible con Unity 4.x. Prepárese para reajustar sus antiguos proyectos y reescribir parte de su código de física al migrar desde versiones anteriores de Unity.

Hay muchos más detalles sobre la física en Unity 5 de los que puedo compartir en este post. No dudes en hacer preguntas en los comentarios, o si vas a visitar nuestra conferencia de desarrolladores Unite 2014 este año, asiste a mi charla en profundidad sobre la física en Unity 5.0 y ven a saludarme y charlar un rato.

Más información sobre Unity 5