Plugins en Unity 5.0
Shaders en Unity 5.0

Física en Unity 5.0

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.

Panorama general las actualizaciones

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.

Cambios que probablemente afectan los proyectos:

La fuerza Adaptive ahora es apagada por defecto

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.

Las Colisiones Suaves de Esferas son quitadas de ambos los terrenos y meshes.

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.

Los Springs exponen mayores amplitudes con PhysX3.

usted querrá ajustar los parámetros de spring después de actualizarse.

La configuración del Material de Terreno de Física ha cambiado

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.

El Shape Casting y sweeping ha cambiado:

  • Shape sweeps reporta todas las figuras que choque (i.e CapsuleCast y SphereCast va a devolver todas las figuras que choquen, incluso las que contentan completamente la primitiva)
  • Raycasts filtra las figuras que contienen el origen del raycast

Eventos del Compound Collider:

Cuando utilice CollidersC Compound, OnCollisionEnter ahora es llamado una vez por cada par en contacto

Los Triggers deben ser convexos:

De ahora en adelante, usted solamente puede tener triare en figuras convexas (una restricción de PhysX):

  • TerrainCollider no soporta más la flag IsTrigger
  • MeshCollider puede tener IsTrigger solamente si es convexo

Los cuerpos dinámicos deben ser convexos:

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.

Ragdoll joints (Articulaciones Ragdoll):

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.

Las restricciones del Rigidbody’s son aplicados en espacio local.

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.

WheelCollider

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í.

Cloth

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:

  • usted ya no puede utilizar cloth para colisionar con geometría del mundo arbitraria.
  • tearing no está ya soportado.
  • usted ya no puede aplicar pressure (presión) en Cloth.
  • usted ya no puede adjuntar cloth a colliders o tener cloth aplicar fuerzas a rigidbodies en la escena.
Plugins en Unity 5.0
Shaders en Unity 5.0