Cuantas veces hemos oído eso de: «El motor de físicas de ese juego es el Havok» o «El motor de físicas tiene muchos bugs«, pero ¿sabemos que es exactamente este motor y de que se encarga?¿Tan difícil es hacer un motor de físicas en el que las cosas no salgan disparadas o nos quedemos atascados en el nivel? ¿Por qué consume tanto? A todas estas preguntas intentaremos darle una respuesta hoy con este artículo. Veremos en que se basa, como se aplica y algunos ejemplos, con los que ya sabremos valorar mejor si un motor es bueno o no, y por qué pasan las cosas que pasan. Sabréis a quien echarle la culpa, porque en la mayoría de casos, aunque no lo parezca, no es culpa del motor.
Un motor de físicas es indispensable prácticamente en cualquier videojuego, solo juegos como los de tablero pueden prescindir de él. Cosas como que nuestro personaje pueda andar por un pasillo sin atravesar las paredes son posibles gracias a él. Hay casos mas sofisticados, como la simulación de la destrucción de un barril y ver como las piezas caen al suelo de una manera realista. La aplicación es distinta, pero el principio es lo mismo, una formula matemática.
La base matemática
Con el vector normal de un polígono, tenemos directamente su ecuación del plano correspondienteLa base matemática sobre la que se construye un motor de físicas es la ecuación del plano. ¿Ya está?¿Sólo eso? Prácticamente sí, solo con eso ya se construye gran parte de la funcionalidad que debe tener un motor de físicas, las colisiones con los objetos. ¿Cómo funciona? Imaginaos un punto cualquiera y queremos saber si está encima o debajo del plano. Si aplicamos la función y el resultado es mayor que cero, quiere decir que el punto está encima del plano, y si es negativo, es que está debajo.
Como veis en la imagen, el plano está definido por todos los puntos en el que la ecuación vale cero, por lo que si lo pensáis es bastante lógico, pero ¿Cómo se traslada a las colisiones de un objeto 3D? Si se realiza esta operación para cada uno de los polígonos de un objeto 3D, cuya ecuación del plano viene representada por su vector normal, y en todos los casos tenemos que el valor es negativo, quiere decir que el punto está en el interior del objeto, y por lo tanto, colisionando con él. En el momento que cualquier cara de un valor positivo, podemos decir que el punto está fuera y no hay colisión.
Estaréis pensando que hacer todo este cálculo es muy costoso, mas aún con la complejidad poligonal que hay hoy día, pero resulta que el objeto que se utiliza para detectar colisiones y el objeto que se dibuja son muy diferentes. Tan diferentes como que suelen ser «Bounding boxes«, o lo que es lo mismo, un cubo que envuelve a la perfección la totalidad de el objeto 3D, y reducimos un objeto con miles de polígonos, a solo seis.
La bounding box
Todo objeto, por complejo que sea, se puede contener dentro de un cubo y realizar sobre este todas las funciones de colisiones. Por lo tanto, a la hora de mover el objeto, lo moveremos como si fuese un cubo, pero renderizaremos el objeto 3D contenido dentro con todos los cambios que haya sufrido ese cubo. Si alguna vez habéis visto como un objeto cilíndrico caía al suelo y no rodaba, es porque seguramente, está representado como un cubo en el motor físico.
¿Quiere decir esto que todos los objetos se representan con cajas? No, solo es el caso mas simple posible. Dependiendo del objeto, podemos crear su envolvente con forma cilíndrica, esférica, etc. según convenga, pero el principio es el mismo, utilizamos un objeto mas simple para realizar los cálculos de colisiones. El conjunto de formas, como se comportan, y las diferentes funciones para detectar colisiones son lo que gestiona un motor de físicas.
El motor de físicas
En este punto ya podéis entender lo que es realmente un motor de físicas. Es un conjunto de funciones que permite dar envolventes a nuestros objetos a renderizar y un comportamiento determinado. Por ejemplo, los objetos 3D que formen parte del nivel en si, deben ser estáticos, no les puede afectar la gravedad ni moverlos, es la tierra firme, y por lo tanto, solo necesitan estar ahí para que los demás objetos colisionen. Es por ello que el nivel no suele tener un objeto que lo envuelva, a no ser que sea de una complejidad poligonal muy alta, y suele usarse los mismos polígonos que luego se renderizan también como objetos para el motor.
Aquí podemos ver las bounding boxes en amarillo, y las normales de los polígonos del suelo en azul.Por otro lado, tenemos los detalles del nivel, como podrían ser barriles, botellas, papeles, etc. que sí que nos puede interesar que se muevan, y por ello le decimos al motor que tienen gravedad. Y les daremos a todos alguna forma que se ajuste bien para el motor de físicas. Cuanto mas similar sea, mas realista será luego, y menos probable será que pasen cosas como que haya partes de nuestro objeto que atraviesen a los demás.
La representación del jugador en el motor de físicas, tiene un trato especial. Suele tener una forma cilíndrica para que pueda resbalar por las paredes lisas y no nos quedemos atascados, y una cierta tolerancia con la fricción del suelo, para que pueda subir escalones por ejemplo, sin necesidad de saltar.¿Os suena cuando se os queda el prota atascado en una piedra? Pues suele ser porque al modelar el nivel se pone una piedra demasiado alta, o porque el valor de tolerancia de nuestro protagonista está demasiado bajo. En un caso es un fallo de diseño, y en el otro de configuración, pero no es problema del motor como podéis ver. Tampoco queremos que salga disparado como si fuese un barril, por lo que los objetos rebotan contra él, pero no lo mueven.
Un ejemplo práctico
[yframe url=’http://www.youtube.com/watch?v=yuBCrGv3EIs’]
En este vídeo podemos ver los diferentes comportamientos que se utilizan del motor Havok. Por ejemplo, al matar a los enemigos pasan a ser muñecos («Ragdoll«), que permite verles caer al suelo de una forma creíble y moverlos al pasar por encima. Otros objetos, como cajas y barriles, son estáticos hasta el momento que los destruimos, cuyas piezas caen al suelo afectados por la gravedad, y se quedan estáticas una vez dejan de moverse, aunque pasemos por encima, a diferencia de los cuerpos de los enemigos. Esto es una forma de optimizar un motor físico, solo se calculan colisiones hasta que los objetos dejan de moverse, y pasan a ser estáticos desde entonces, o ni tan siquiera tienen una envolvente que afecte al jugador.
Conclusiones
Un motor de físicas debe gestionar una gran cantidad de objetos y realizar cálculos de colisiones, que aunque no es excesivamente complejo, sí que es costoso al realizarse para cada cara de un objeto. Pero esto no quiere decir que no se pueda realizar en cualquier máquina. Una consola como la Wii puede ejecutar juegos que utilicen un motor de físicas sofisticado, siempre y cuando diseñemos el nivel y los objetos con una complejidad baja para el motor. En máquinas mas potentes, podremos realizar un mayor número de cálculos de colisiones, y aplicar mas optimizaciones para que el comportamiento de los objetos sea mas realista. Seguramente será en la siguiente generación de consolas donde veremos un salto mayor en este ámbito, al poder ejecutar un mayor número de cálculos y poder introducir mas elementos interactivos que se comporten de forma mas realista, al tener en cuenta muchos mas factores. Podremos ver cosas como esta en tiempo real:
[yframe url=’http://www.youtube.com/watch?v=WwSrSHI6lHA’]
¿Qué os gustaría ver en el futuro? ¿Qué es lo que mas rabia os da que pase en un videojuego en la detección de colisiones?¿Os ha gustado el artículo? Como siempre, todas las preguntas y sugerencias las podéis hacer en los comentarios de este artículo. Y si tenéis alguna sugerencia para futuros artículos no dudéis en hacerla.