programacion unity 3d

FISICAS: CONCEPTOS BASICOS

Examinadas las clases principales de Unity, quisiera ahora realizar una serie de incursiones más o menos
extensivas en algunos aspectos del engine que creo que merecen una atención 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 físicas del engine, que considero que es
el centro neurálgico del noventa y pico por ciento de los videojuegos que se han creado.
Existe entre los recién llegados a Unity bastante confusión entre los términos y conceptos que envuelven
su apartado de físicas, y en consecuencia a veces no seaplican correctamente los elementos necesarios
para –por ejemplo- detectar adecuadamente una colisión o permitir que un determinado gameobject sea
inmune a la gravedad. Para que nuestro juego funcione adecuadamente y no consuma más recursos de
los necesarios debemos tener muy claro cuál es la mejor solución para cada necesidad.
Vamos a intentar desgranar para qué sirve cada cosa. Empezaremospor examinar las diferentes
posibilidades de detección de colisiones que nos brinda Unity, y para ello necesitaremos introducir el
primer concepto:
COLLIDER:
Un collider, en términos muy básicos, es un envoltorio que hace que un determinado objeto se torne
sólido y en consecuencia pueda chocar con otros objetos (siempre que a su vez esos otros objetos
tengan otro collider). Un collider secompone, 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 creíbles) y, por otro, de un determinado material físico (aquí no estamos hablando de colores o
modos de reflejar la luz de una superficie, sino de capacidad de rebote y/o fricción de dicho objeto, así
que no confundamosel término “material” que usamos para renderizar un objeto con el material físico).
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 aplicación 3d tipo Blender o
3dMax. Al seleccionar dicha malla desde la vista deProyecto 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). Podríamos pensar: “pues ya está, es tan sencillo como pedira Unity
que genere colliders para todas las mallas que vayamos importando y ya tenemos nuestro sistema de
detección de colisiones montado, sin necesidad de complicarnos la vida asignando colliders de primitivas

que además no cuadran tan perfectamente con nuestras mallas como los colliders de malla”.
Pero no es tan sencillo. Para empezar, dos colliders de malla no colisionarán entre sí si almenos 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 colisión.
“¿y para el caso de objetos que sépositivamente que no se moverán 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 deberíamos usar los colliders de malla en...