FISICAS: CONCEPTOS BASICOS (II)

Veamos en la entrada anterior que un collider vendra a ser meramente un caparazn que le
aadimos a una malla para que pueda colisionar con otras mallas, pudiendo ese caparazn
tener la misma forma que la malla (mesh collider) o una forma que nosotros le diseemos para
l a partir de una o varias formas primitivas (primitive collider)que Unity nos ofrece.

Supongamos entonces que tenemos dos mallas en nuestra escena, a cada una de las cuales le
asignamos un collider (del tipo que sea, eso no importa para este ejemplo). A travs de un
script vinculado a una de las mallas movemos su transform para que colisione contra la otra
malla. Probadlo si queris con dos cubos (que ya traen "de serie" un collider primitivo
(obviamente, un box collider)). Comprobaris que pese a tener cada malla un collider, a
efectos prcticos es como si no lo tuvieran, ya que se atraviesan.

Esto sucede porque para que dos mallas puedan colisionar, adems de estar ambas dotadas de
su pertinente collider, es preciso que al menos una de las dos mallas tenga vinculado adems
un Rigidbody no kinemtico.

Olvidmonos de momento del palabro "kinemtico" y centrmonos en el Rigidbody.

Un rigidbody es el conjunto de datos que permiten a Unity calcular, entre otras cosas, las
consecuencias que tendr una colisin para el gameobject al cual se asigna dicho rigidbody.

Al igual que nos pasara a nosotros si estuviramos en clase de fsica, para que Unity calcule las
consecuencias de una hipottica colisin necesita tener en cuenta factores como la masa del
gameobject al que se vincula, la velocidad relativa a que se produce la colisin, si existe o no
rozamiento y en qu medida, si hay o no gravedad, etc. Por resumir, asignando un rigidbody a
un gameobject automticamente estamos dotando a dicho gameobject de una serie de
propiedades fsicas, tales como gravedad, rozamiento y peso, ya que sin saber la masa de un
objeto - por ejemplo- es imposible calcular el resultado de una colisin (probad si no a patear
de manera indiscriminada objetos con diferentes masas, paredes de carga y yorkshires
inclusive, para que comprobis las diferentes posibilidades de desplazamiento).

Lo ms impactante para los recin llegados a Unity cuando le asignamos un rigidbody a una
malla -como muchos ya habris comprobado- es que automticamente, salvo que el suelo a su
vez tenga otro collider, nuestra malla se pierde en las profundidades de la escena. Por eso se
tiende por algunos (manuales de pago incluidos) a simplificar en ocasiones cuando se explica lo
que es un rigidbody, limitndolo a "lo que hace que un objeto se vea afectado por la
gravedad".

Y por ah suelen empezar tambin las confusiones entre colliders y rigidbodies, debido a que
los dos tienden a solaparse y es difcil explicar uno sin mencionar al otro. Es verdad que ambos
son necesarios para que se produzca una colisin, pero intervienen en apartados distintos: el
collider sera el dnde (se produce la colisin) y el rigidbody el cmo.

Supongo que se entiende que no tendra sentido asignar un rigidbody a una malla que no
tenga un collider, ya que de nada sirve calcular una colisin que nunca tendr lugar (ya que no
hay collider para esa malla con el que colisionar o ser colisionado)

S cabe pensar en un collider que no tenga rigidbody. De hecho, es lo que en Unity se conoce
como "static colliders".

Un collider esttico, como su nombre indica, est pensado para objetos que no se van a mover
en la escena. Este tipo de colliders sin rigidbody pueden interactuar/colisionar con otros
colliders siempre que stos colliders s tengan vinculado un rigidbody (ya hemos visto que si
ninguno de los dos objetos tiene un rigidbody la colisin no se produce, bsicamente porque
Unity no tiene ninguna forma de calcular las consecuencias de dicha colisin entre dos objetos
"no fsicos" y directamente obvia la colisin).

Lo que sucede es que cuando un collider dinmico (con rigidbody) se mueve y fruto de ese
movimiento colisiona con un collider esttico (sin rigidbody), como Unity ignora las
propiedades fsicas del collider esttico, meramente ste -haciendo honor a su nombre- no se
mover. Y de hecho, si se moviera, y precisamente por lo expuesto (Unity no sabe calcular
cmo y cunto se ha de mover) el costo computacional sera brutal.

Por todo lo anterior, los static colliders son ptimos para las partes fijas de nuestro juego, tal
como paredes, libreras, rboles y objetos similares que no han de moverse pero que tampoco
han de atravesarse por los personajes y dems partes mviles del juego.

Espero que estos conceptos que estoy intentando explicar a cuentagotas queden claros. S
que al principio parece todo un poco confuso, pero es esencial entenderlos correctamente.

Un abrazo y hasta pronto.

08
ene 2012
POSTED BY UnityScripts
POSTED IN MONOGRAFICOS
DISCUSSION 10 Comments
FISICAS: CONCEPTOS BASICOS



Examinadas las clases principales de Unity, quisiera ahora realizar una serie de incursiones ms
o menos extensivas en algunos aspectos del engine que creo que merecen una atencin
especial, bien por su importancia, bien por la dificultad para entenderlos. As que, avisando de
nuevo en que este que os est escribiendo no es en absoluto un experto en la materia,
intentar ayudar en lo que buenamente pueda.

Quisiera empezar con un acercamiento a todo el componente de fsicas del engine, que
considero que es el centro neurlgico del noventa y pico por ciento de los videojuegos que se
han creado.

Existe entre los recin llegados a Unity bastante confusin entre los trminos y conceptos que
envuelven su apartado de fsicas, y en consecuencia a veces no se aplican correctamente los
elementos necesarios para por ejemplo- detectar adecuadamente una colisin o permitir que
un determinado gameobject sea inmune a la gravedad. Para que nuestro juego funcione
adecuadamente y no consuma ms recursos de los necesarios debemos tener muy claro cul
es la mejor solucin para cada necesidad.

Vamos a intentar desgranar para qu sirve cada cosa. Empezaremos por examinar las
diferentes posibilidades de deteccin de colisiones que nos brinda Unity, y para ello
necesitaremos introducir el primer concepto:

COLLIDER:

Un collider, en trminos muy bsicos, es un envoltorio que hace que un determinado objeto se
torne slido y en consecuencia pueda chocar con otros objetos (siempre que a su vez esos
otros objetos tengan otro collider). Un collider se compone, por un lado, de una determinada
forma (que no tiene por qu coincidir con la forma del objeto, aunque es preferible que
casen de alguna manera, para originar colisiones crebles) y, por otro, de un determinado
material fsico (aqu no estamos hablando de colores o modos de reflejar la luz de una
superficie, sino de capacidad de rebote y/o friccin de dicho objeto, as que no confundamos
el trmino material que usamos para renderizar un objeto con el material fsico).

Atendiendo a su forma, podemos diferenciar los colliders en dos subgrupos: colliders de malla
(mesh colliders) y colliders de primitivas (primitive colliders):

El mesh collider lo creamos cuando importamos una malla desde alguna aplicacin 3d tipo
Blender o 3dMax. Al seleccionar dicha malla desde la vista de Proyecto y previo a importarlo,
debemos (caso de querer este tipo de malla) marcar la casilla generate colliders (ver captura
de pantalla) para que nuestra malla tenga un collider de este tipo.



Cuando marcamos esta casilla e importamos la malla, Unity genera un collider que tendr la
misma forma que dicha malla (de ah el nombre). Podramos pensar: pues ya est, es tan
sencillo como pedir a Unity que genere colliders para todas las mallas que vayamos
importando y ya tenemos nuestro sistema de deteccin de colisiones montado, sin necesidad
de complicarnos la vida asignando colliders de primitivas que adems no cuadran tan
perfectamente con nuestras mallas como los colliders de malla.

Pero no es tan sencillo. Para empezar, dos colliders de malla no colisionarn entre s si al
menos uno de ellos no tiene marcado en el inspector el checkbox convex, que hace que el
collider envuelva adecuadamente la malla.

No hay problema podemos pensar- marco la casilla convex y asunto solucionado.

Sigue sin ser tan sencillo. Si dos colliders de malla colisionan entre s a una velocidad
importante es posible que no se detecte la colisin.

y para el caso de objetos que s positivamente que no se movern a mucha velocidad puedo
usar mesh colliders?

La respuesta es: poder, se puede, pero si se puede evitar, mejor. Pensemos que la cantidad de
recursos que consume un PC para calcular colisiones derivadas de mallas complejas es muy
superior a la precisa para hacer lo propio con primitives colliders.

En resumen, que deberamos usar los colliders de malla en objetos que sepamos
positivamente que en nuestro juego se movern poco o nada, que no estarn sometidos a
colisiones continuas con otros objetos y que tengan una forma difcil de casar con un collider
primitivo.


Por su parte, el primitive collider implica asignar a una malla un collider prefabricado por
Unity, pudiendo meramente escoger entre las siguientes formas primitivas: esfera, caja,
cpsula o rueda. Se tratara meramente de teniendo nuestra malla seleccionada- irnos al
men Components=>Physics y seleccionar uno de los indicados colliders, para despus
moverlo de tal forma que encaje lo mejor posible con nuestra malla.

En ocasiones precisaremos usar varios colliders primitivos para cubrir toda la fisonoma de una
malla. Esto se puede conseguir creando un gameobject vaco y emparentar dichos colliders
como hijos de esta, para crear as una unidad manipulable, por decirlo de alguna forma.

Aunque este segundo sistema primitive collider- es ms trabajoso y antiesttico que el
anterior- mesh collider- es recomendable que en la medida de lo posible lo usemos para
nuestras mallas.

En prximos captulos ahondaremos en esto. De momento, lo dejamos por hoy.