Unity 5.0 tiene una actualización a Physx3.3 SDK. Por favor darle un vistazo rápido a este blogpost antes de realizar cualquier acción en sus proyectos 4.x. Esto le podría dar una idea de qué esperar del nuevo código base: High Performance Physics in Unity 5. Por favor tenga cuidado que PhysX3 no es 100% compatible con PhysX2 y requiere algunas acciones del usuario cuando actualice.
La física de Unity 5.0 puede esperarse que funcione hasta 2 veces más rápido que en versiones previas. La mayoría de los componentes los cuales usted estaba familiarizado todavía están ahí, y usted los encontrará funcionando como antes. Claro está, algunos comportamientos han sido imposible de que sigan iguales y algunos simplemente eran comportamientos raros causados por limitaciones del código-base preexistente, por lo que tenemos que realizar cambios. Las dos áreas que obtuvieron el cambio más significante son los componentes Cloth y WheelCollider. Nosotros estamos incluyendo una sección de cada uno de ellos a continuación. Luego, hay unos cambios pequeños sobre todo el código de física que causan incompatibilidad.
La fuerza Adaptive fue introducida para ayudar con la simulación de stacks (pilas) más grandes, pero resulto ser excelente solamente para demos. En los juegos reales sucedió para causar el comportamiento equivocado. Usted puede cambiarlo en las propiedades del editor de física: Edit -> Project settings -> Physics -> Enable adaptive force.
PhysX3 tiene una característica que aborda el mismo tema y ya no es conmutable, ya que está considerado como una solución sin mayores inconvenientes.
usted querrá ajustar los parámetros de spring después de actualizarse.
Utilice TerrainCollider.sharedMaterial y TerrainCollider.material para especificar el material de física para el terreno. La anterior manera de configurar el material de física a tráves de TerrainData ya no va a funcionar. Como un bonus, usted puede ahora especificar el material de física para el terreno en una base por colisionador.
Cuando utilice CollidersC Compound, OnCollisionEnter ahora es llamado una vez por cada par en contacto
De ahora en adelante, usted solamente puede tener triare en figuras convexas (una restricción de PhysX):
Los cuerpos dinámicos (i.e. aquellos que tienen un Rigidbody adjuntado con Kinematic = false) ya no pueden tener mes colliders cóncavos (una limitación de PhysX).
Si usted quiere tener colisiones con mesh cóncavos, usted puede solamente tenerlos en colliders estáticos y cuerpos kinematic.
Las configuraciones de Joint (articulaciones) para ragdolls tendrán que necesitar un ajuste.
Estas sugerencias aplican a articulaciones en general también.
Ver la página de Joint And Ragdoll Stability para la versión más reciente de esta guía.
Evite ángulos pequeños de “Angular Y Limit” y “Angular Z Limit”. Dependiendo en sus ajustes el mínimo de ángulos debería ser alrededor de 5 a 15 grados con el fin de ser estable. En vez de utilizar un ángulo pequeño, intente ajustar el ángulo a cero. Esto va a bloquear el eje proporcionar una simulación estable.
Configure “Enable Preprocessing” a falso (sin marcar). Desactivando el pre-procesamiento puede ayudar contra articulaciones “explotando”. Las articulaciones pueden “explotarse” si son puestas en situaciones dónde no hay una manera de satisfacer las restricciones de las articulaciones. Esto puede ocurrir si los rigió bodies que están juntos son separados por geometría estática de colisión, como generar un ragdoll parcialmente dentro de una pared.
Estabilidad del Ragdoll o estiramiento: Si los ragdolls son dados circunstancias extremas, como generarse parcialmente dentro de una pared o ser empujados con una fuerza grande, el joint solver (solucionador de articulaciones) no podrá mantener la proyección de las articulaciones, utilizando ya sea “ConfigurableJoint.projectionMode” o “CharacterJoint.enableProjection”.
Si los cuerpos conectados con articulaciones tienen titileo, intente aumentar Edit->Project Settings->Physics->“Solver Iteration Count”. Intente entre 10 o 20.
Nunca utilice el acceso directo al transform con cuerpos kinematic unidos a otros cuerpos. Haciendo esto salta el paso dónde PhysX computa las velocidades internas de los cuerpos correspondientes y por lo tanto hace que el solver (solucionador) proporcione resultados no esperados. Nosotros hemos visto algunos proyectos 2D utilizando el acceso directo al transform para voltear los personajes vía alterando transform.direction en la raíz boon del rig. Esto se comporta mucho mejor si usted utiliza MovePosition / MoveRotation / Move más bien.
El mecanismo de bloqueo que nosotros utilizamos en Unity 4 estaba básicamente descartando los cambios en las rotaciones bloqueadas y fue restableciendo las velocidades angulares como un paso posterior al solver. Esto estaba funcionando en su mayoría excepto que hubo algunos problemas con cuerpos cayendo en un estado de adormecimiento a medida que el solver quería ajustar las rotaciones cada frame; y un pocos casos relacionados fueron notados a través de los años. Cuando se trabaje con la integración en PhysX3, nosotros utilizamos esta nueva y bonita característica de PhysX 3.3 dónde nosotros podemos configurar los componentes infinite inertia tensor para grados de rotación bloqueados a su libertad. Esto ahora es soportado en el solver para que el cuerpo pueda ahora irse a “dormir” apropiadamente, pero debido a que esto es inercia, también es aplicado a coordenadas locales.
El nuevo WheelCollider está funcionando gracias al PhysX3 Vehicles SDK que es básicamente una nueva librería de simulación vehicular cuando es comparada al código que teníamos en PhysX2.
Lea más acerca del nuevo WheelCollider aquí.
Unity 5 utiliza el solver de Cloth completamente re-escrito proporcionado por el nuevo PhysX SDK. Este cloth solver ha sido diseñado con el clothing de personajes en mente, y es un gran avance comparado a las versiones anteriores en términos de rendimiento y estabilidad. Unity 5 remplaza los componentes SkinnedCloth y InteractiveCloth en Unity 4 con un solo componente Cloth, que funciona en conjunto con un SkinnedMeshRenderer. La funcionalidad es similar al previo componente SkinnedCloth, pero ahora es posible asignar arbitrariamente, meshes non-skinned al SkinnedMeshRenderer, por lo que usted puede todavía manejar la simulación de cloth en un mesh aleatorio.
Sin embargo, alguna funcionalidad que fue disponible en el viejo InteractiveCloth ahora no está más soportado por la nueva versión de PhysX ya que es difícil implementar estos con un buen rendimiento. Específicamente: