Detección de Colisiones en Videojuegos: Propuesta de Investigación

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/345969391
Métodos y aproximaciones implementadas por los videojuegos para una
óptima detección de colisiones
Research Proposal · November 2020
DOI: 10.13140/RG.2.2.19285.86241
CITATIONS
READS
0
643
3 authors:
Leonardo David Vergara Márquez
Camilo Andres Cespedes Jimenez
Universidad del Norte (Colombia)
Universidad del Norte (Colombia)
1 PUBLICATION 0 CITATIONS
2 PUBLICATIONS 0 CITATIONS
SEE PROFILE
SEE PROFILE
Isaac Alejandro Blanco
Universidad del Norte (Colombia)
1 PUBLICATION 0 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Métodos y aproximaciones implementadas por los videojuegos para una óptima detección de colisiones. View project
All content following this page was uploaded by Isaac Alejandro Blanco on 17 November 2020.
The user has requested enhancement of the downloaded file.
Métodos y aproximaciones implementadas por los videojuegos para una óptima
detección de colisiones.
Presentan:
Isaac Blanco Amador
Camilo Cespedes Jiménez
Kairo Tapias Paternina
Leonardo Vergara Marquez
Directora:
Rocío Ramos Rodríguez
UNIVERSIDAD DEL NORTE
DEPARTAMENTO DE INGENIERIA DE SISTEMAS Y COMPUTACION
Barranquilla, 5 de noviembre de 2020
1
Contenido
Resumen ....................................................................................................................................... 3
Abstract ........................................................................................................................................ 5
CAPITULO I .....................................................................................................................7
INTRODUCCIÓN..............................................................................................................7
Enfoque de la investigación.............................................................................................7
CAPITULO II .................................................................................................................. 13
OBJETIVOS .................................................................................................................... 13
Objetivo general ........................................................................................................... 13
Objetivos específicos ..................................................................................................... 13
CAPITULO III................................................................................................................. 14
MARCO TEORICO ......................................................................................................... 14
CAPITULO IV ................................................................................................................. 63
CONCLUSIONES ............................................................................................................ 63
CAPITULO V .................................................................................................................. 65
BIBLIOGRAFIA.............................................................................................................. 65
2
Resumen
La computación desde el inicio siempre ha buscado llevar la realidad física a un
modelo matemático que nos permita entender y poder analizar desde múltiples
perspectivas que no serían posibles desde nuestras limitaciones físicas.
Uno de los grandes papeles que cultivo fue el campo de las simulaciones, donde
su creación significo un gran avance a la hora de realizar investigaciones respecto a
cualquier campo de estudio. Esto nos permitía estudiar las múltiples reacciones que
podía tener un acontecimiento, donde nosotros en tiempo real podríamos ir variando
parámetros y las situaciones sin necesidad de recrearlos.
Un campo que nació gracias a esta posibilidad fue el campo de los videojuegos
donde la computación ayudo a llevar la creatividad de una persona al plano
computacional, sin embargo, en la creación de estos mundos digitales era necesario
reglas parecidas a nuestro entorno físico.
Muchos de los algoritmos usados para ciertas simulaciones tomaban un tiempo
de cómputo extremadamente largo para la rapidez de procesamiento que necesitaban los
videojuegos, lo que llevo a los ingenieros de sistemas de cada época a la creación de
soluciones ingeniosas y eficientes para cada situación que se presentara.
Haciendo uso de múltiples estructuras de datos y artificios matemáticos, con el
paso de los años, se pudieron generar mayores precisiones a partir de una misma idea, la
caja de colisión, gracias al perfeccionamiento de esta idea, los cálculos se reducían a la
simple intercepción de estas mismas.
3
Con el paso del tiempo, de manera análoga gracias a la ley de Moore, ayudo a la
creación de algoritmos muchos más precisos y eficientes y videoconsolas con una
mayor cantidad de procesamiento, llevando el campo de la creación de videojuegos a
una explosión creativa y técnica inimaginable, generando situaciones de colisiones lo
más parecidas a la realidad.
A lo largo de esta investigación se irán analizando desde las ideas más básicas
de colisiones en el plano más simple, las dos dimensiones, viendo como estas escalaron
y fueron avanzando hasta su perfeccionamiento, para luego realizar el salto a las tres
dimensiones, donde se analizarán como se abordó el problema usando el mismo
concepto y haciendo uso de algoritmos previamente inutilizables.
Palabras clave: Computación, modelo matemático, simulaciones, entorno físico,
eficiencia, algoritmo, estructura de datos.
4
Abstract
Computing from the beginning has always sought to bring physical reality to a
mathematical model that allows us to understand and analyze from multiple
perspectives that would not be possible from our physical limitations.
One of the great roles that I cultivate was the field of simulations, where its creation
represented a great advance when conducting research in any field of study. This
allowed us to study the multiple reactions that an event could have, where we in real
time could vary parameters and situations without having to recreate them.
A field that was born thanks to this possibility was the field of video games where
computing helped to bring a person's creativity to the computational plane, however, in
the creation of these digital worlds, rules similar to our physical environment were
necessary.
Many of the algorithms used for certain simulations took extremely long computation
time for the speed of processing that video games needed, which led the systems
engineers of each era to create ingenious and efficient solutions for each situation that
arose.
Making use of multiple data structures and mathematical artifacts, over the years,
greater precision could be generated from the same idea, the collision box, thanks to the
improvement of this idea, the calculations were reduced to the simple interception of
these.
Over time, in an analogous way thanks to Moore's law, I help to create much more
precise and efficient algorithms and game consoles with a greater amount of
processing, taking the field of video game creation to a creative and technical explosion
unimaginable, generating collision situations as close to reality as possible.
5
Throughout this research, the most basic ideas of collisions in the simplest plane, the
two dimensions, will be analyzed from the most basic ideas, seeing how they escalated
and progressed until their perfection, to then make the jump to three dimensions, where
they will be analyzed how the problem was approached using the same concept and
making use of previously unusable algorithms.
Keywords: Computing, Mathematical model, simulations, physical environment,
efficient, algorithm, data structures.
6
CAPITULO I
INTRODUCCIÓN
Enfoque de la investigación
Desde la creación del Tennis for Two (El primer videojuego de la historia) en el
año 1958 por William Higinbotham y Robert Dvorak, se pudo ver que un videojuego
podía llevar cosas del mundo físico a su entorno, como lo era en este caso el deporte del
tenis, llevando el característico enfrentamiento entre dos tenistas al movimiento de una
esfera alrededor de un plano en dos dimensiones donde tu podías elegir el ángulo y
dirección de golpe inmediatamente cruzaba tu campo.
Ilustración 1. Imagen del juego Tennis For Two
Extraída de: https://sectagamer.com/curiosidades/el-primer-videojuego-de-la-historia-tennis-for-two/
Pero desde ese momento se pudo observar que las computadoras podían detectar
dentro de ellas misma una mínima noción del mundo físico y sus reglas, en este caso las
detecciones de colisiones o choques.
7
Pero para empezar a hablar de colisiones en el plano de los videojuegos,
primeramente, necesitamos entender que es una colisión en el mundo físico y que las
componen.
Con las pequeñas nociones anteriores, a inicios del año 1972 empresas como
Atari empezaron con el desarrollo de múltiples videojuegos con sistemas físicos propios
en cada uno como los manejados para los juegos de Pong, Space Invaders y Asteroids,
donde cada uno usaba abstracciones del plano físico, en distintas maneras, es decir,
Pong lleva a otro nivel la idea Tennis for Two, Space Invaders y Asteroids usan el
concepto de quebrantamiento y proyectil.
Con el paso del tiempo, como evidencia de la ley de Moore, el crecimiento de la
tecnología provoco que muchas empresas como Nintendo y Sega produjeran consolas
de videojuegos que permitieran no solo una mayor capacidad de procesamiento, sino
que videojuegos con mayor complejidad, como el nacimiento de los plataformeros
Mario y Sonic, donde la sola descomposición de sus sistemas de físicas, demuestran un
gran avance comparado con los anteriores mencionados, características como cantidad
de momento, saltos, velocidad, proyectiles, colisiones espontaneas, fricción… y todo
esa cantidad de operaciones en tiempo de ejecución casi inmediato, debido a los
algoritmos ingeniosos y eficientes que usaban para esto.
Todos estos juegos de plataformas que surgieron durante la época de auge
lograron introducir a los demás juegos, lo que se conoce hoy en día como Hitbox o caja
de colisiones, que otros juegos lograron diversificar para un mejor rendimiento en su
género, lo que llevo a la creación de nuevos algoritmos y técnicas para mejorar su
procesamiento.
8
Ilustración 2. Caja de colisión manejada por el videojuego Sonic The Hedgehog
Extraida de https://info.sonicretro.org/Sonic_collision_bugs
Por causa de lo anterior, años más tarde, con el inicio de los juegos de pelea
como Street Fighter y Mortal Kombat, dieron paso a nuevas técnicas de detección más
inmediata y más espontaneas haciendo uso de cambios en la idea de Hitbox, debido a lo
acelerado sistema de juego presentaba. Pasado un tiempo dichas técnicas fueron
logrando un perfeccionamiento, tanto las más simples como las avanzadas, esto sumada
con la gran revolución tanto en ideas como algoritmos, dieron paso a técnicas más
precisas y costeables a la hora de computar.
Ilustración 3. Caja de colisión partida manejada por el personaje de Dhalsim de Street Fighter
Extraída de: 2https://www.hobbyconsolas.com/reportajes/son-hitbox-son-cruciales-videojuegos-aprende-hobbybasics-691145
9
Por último, terminando el siglo XX, durante la época de los 90’s, muchas
empresas logran hacer un salto tecnológico que revoluciona el mundo de las colisiones
y los videojuegos, el paso a la tecnología de tres dimensiones, donde se destacan tres
precursores: Doom del año 1993 de ID Software, Super Mario 64 del año 1996 y Super
Smash Bros del año 1999 de Nintendo, donde logran llevar a la nueva generación de
consolas, técnicas más avanzadas.
En el caso de Doom, podemos observar la creación de la técnica de Ray-casting
que lograba “simular” un espacio en tres dimensiones, lo que les permitió generar una
mejor experiencia al usuario, además de la implementación del apartado de la física de
la óptica para este propósito, que en la actualidad fue implementada directamente a las
librerías de NVIDIA, lo que ayuda a la generación de mejores texturas y gráficos.
Por el lado de Nintendo, la múltiple mezcla de técnicas físicas en Super Mario
64, donde podemos ver la implementación de una cámara, deslizamientos, fricción,
plataformas inestables, cantidad de movimiento, velocidad, lanzamiento de objetos,
explosiones, partículas… siendo una ejemplificación del plataformero inicial en tres
dimensiones ideal.
Acto seguido, el juego de Super Smash Bros no incurrió en nuevos algoritmos,
con respecto al juego de pelea, sin embargo, con el auge competitivo de este, se encargo
de llevar las cajas de colisiones a un nivel de exactitud muy preciso, además de la
introducción de conceptos de objetos estacionarios y sus interacciones, que servirían
para aproximaciones voraces para otros juegos como los FPS.
10
Ilustración 4. Caja de colisiones de un golpe de Link del juego Super Smash Bros Melee
Extraída de: Virtuosos on the Screen: Playing Virtual Characters Like Instruments in Competitive Super Smash Bros.
Melee
Con el paso del tiempo, y el surgimiento de nuevas tecnologías llevo a la
creación de nuevas técnicas, y el funcionamiento ideal de los previamente utilizados
tanto en tres como dos dimensiones, debido al gran poder de computación y
procesamiento, llevando a ciertos algoritmos que antes no se utilizaban debido a su alto
coste relativo en ese entonces, como lo pueden ser el algoritmo de Convex Hull para las
figuras en 3D.
Actualmente las cajas de colisión y su detección cuentan con un nivel de
precisión bastante alto, debido a lo antes mencionado, tomando ejemplos como el uso
del algoritmo de OBB para la generación de esqueletos que cubran todo el volumen del
personaje, un buen ejemplo de dicha técnica, son las cajas de colisiones manejadas por
el Shooter táctico de Valve, Counter Strike Global Ofensive, desarrollado en el año
2012
11
Ilustración 5. Caja de colisión del Shooter Counter Strike Global Offensive
Extraída de: https://counterstrike.fandom.com/wiki/Hitbox
12
CAPITULO II
OBJETIVOS
Objetivo general
•
Contrastar las diferentes técnicas utilizadas para la detección de
colisiones en el ámbito de los videojuegos.
Objetivos específicos
•
Definir el concepto de colisión en el mundo físico.
•
Descomponer los múltiples casos de colisión en el plano de los
videojuegos.
•
Organizar los métodos de colisión según su plano espacial en el
videojuego.
•
Detallar cada una de estas técnicas para su implementación.
•
Contrastar cada uno de los métodos de acuerdo con su plano espacial,
género, dificultad y coste computacional.
•
Mostar su uso con ejemplos cotidianos y en el plano de videojuegos.
13
CAPITULO III
MARCO TEORICO
En el siguiente trabajo de investigación, se asumirán las soluciones con las
perspectivas en función de su complejidad y el plano donde están son efectuadas, por lo
tanto, en primera instancia es necesario.
Primeramente, hay que usar la noción de espacio y colisiones desde un punto de
vista estadístico, esto con el fin de poder tener en cuenta cuantas posibles operaciones
debería realizar nuestros algoritmos, esto va cambiando, dependiendo del modelado que
se le a los entidades y objetos del videojuego y su dimensión.
Podemos partir de la idea de que cada objeto puede chocar con otro objeto por lo
menos una vez, y que las paredes no cuenten como limitación, donde la cantidad de
colisiones puede llevarse (𝑛 − 1)2 , esto se plantea desde un parte estadística-física, sin
embargo, en el artículo “Collision Detection for Solid Objects” (Souto, n.d.) llega a la
conclusión de que llevar esta aproximación completa al plano computación resultaría,
en mayor medida en algoritmos del orden de complejidad espacial de 𝑂(𝑛2 ).
Esta aproximación no solo nace de la naturaleza las colisiones, sino de la
creación de un sistema de reglas físicas, como la creación de la máscara de colisiones,
ya que la aproximación que se tenía en ese entonces era la construcción de una caja
convexa, lo que su generación por medio de algoritmos de fuerza bruta lleva a un coste
bastante extenso de cómputo, que sería la primera aproximación para resolver.
14
Por ejemplo, tomando dos casos de la misma dimensión para poder ilustrar la
cantidad de colisiones a colocar, seria tomar este pequeño fragmento del videojuego
Pong de Atari y el videojuego de Space Invaders de la misma compañía.
Ilustración 6. Gameplay de Pong
Extraído de: https://www.hiig.de/on-imitation-and-innovation-in-the-games-sector-from-pong-to-ridiculousfishing/amp/
En esta instancia del juego, podemos tener en cuenta solo hay 3 entidades
durante este juego, la pelota y las dos barras blancas, donde su cantidad de colisiones
varia, teniendo la pelota seis posibles colisiones, y las dos barras cada una con una
colisión perfecta, puesto que la forma de modelado de su caja de colisiones es el
rectángulo, por lo tanto, su ejecución seria bastante optima y veloz, debido a la forma de
sus figuras.
Estos casos son los más básicos de colisiones, donde podemos decir que la
entidad a verificar cumple con la condición de que su forma coincide perfectamente con
una forma geometría plana en el caso de dos dimensiones.
15
Ilustración 7. Gameplay de Space Invaders.
Imagen extraída de: https://www.lavanguardia.com/tecnologia/20180725/451089770519/space-invaders-40aniversario-marcianitos-arcade.html
Sin embargo, en esta instancia del juego Space Invaders, podemos tener en
cuenta que la bala puede tener en total 48 colisiones, donde en cada instancia le tocaría
calcular si ha colisionado con alguno de los 48 objetos restantes de la escena, también
debemos tener en cuenta las colisiones que debe generar cada proyectil expulsado por
los enemigos, donde una aproximación precisa, llevaría a una ejecución mucho más
compleja, debido a la múltiple composición de sus objetos y su forma no perfecta.
Por ejemplo, podemos ver cada enemigo como la unión de un rectángulo con
dos líneas pequeñas rectangulares, entonces al partir cada uno podemos afirmar que
habría 144 colisiones que realiza el proyectil disparado con la nave, para una colisión
perfecta, por lo tanto, surgieron algoritmos para realizar estas aproximaciones.
Los algoritmos para descubrir una colisión en juegos de 2D dependen del tipo de formas
que deseamos colisionar (Ej.: Rectángulo, Círculo). Por lo general se tendrá una manera sencilla
que cubre la figura, gracias a esto la colisión no será impecable píxel a píxel.
16
Decimos que dos elementos colisionan cuando uno de ellos se sobrepone a otro.
En ese instante, debemos disparar una "señal" y tratar esa colisión consecuentemente,
impidiendo el movimiento si es un sólido, restando vida si es un enemigo, etc. Todo va
a depender del tipo de colisión.
La simplificación es clave para todo tema de representar la realidad en un PC y
en el descubrimiento de colisiones no es menos.
Ilustración 8. Sprite de ejemplo. Extraído de: https://i.blogs.es/b030d8/naves/1366_2000.png
Al descubrir colisiones entre los anteriores sprites es requisito simplificar su
geometría. Para eso, se procede a envolverlos en figuras geométricas sencillas, tal es así
que sea simple de descubrir si colisionan o no.
17
Ilustración 9. Sprites con caja de colisión rectangular. Extraído de: https://i.blogs.es/3e7536/naves2/1366_2000.png
Ahora, se van a usar dos rectángulos rojos para representar a las naves: si estos
colisionan entonces las naves colisionan. Si se aprecia bien, se notará que hay situaciones en las
que no lo harán, puesto que estos rectángulos no representan fielmente a las naves, ya que se
está representando una figura irregular con una regular, como se muestra a continuación
Ilustración 10. Sprite con caja de colisión rectangular poco precisa. Extraído de: https://geeks.ms/cfsfile.ashx/__key/CommunityServer.Blogs.Components.WeblogFiles/jbosch/colision_5F00_rectangulo.png
18
Ilustración 11. Mal uso de las cajas de colisiones para una figura. Extraído de:
https://i.blogs.es/65b693/sin-20titulo-2/1366_2000.png
En este ejemplo, precisamente se está utilizando la figura equivocada para describir las
colisiones. Por este motivo, hay que utilizar una conjunción de figuras geométricas para ser más
leales a la realidad.
Un rectángulo se puede representar por medio de un punto p (x, y) 2D que representa la
coordenada de la esquina inferior izquierda, un valor w que representa el ancho y un valor h que
representa la altura. Por otro lado, para representar un círculo vamos a usar un punto p que
representa el centro de este y un valor r que define el radio.
Ilustración 12. Representación del rectángulo y circulo en el plano. Extraído de:
https://i.blogs.es/2001da/representacion/1366_2000.png
Existen numerosas técnicas de detección de colisiones entre sprites. Lo más fácil
y eficiente es utilizar rectángulos.
19
Para que un rectángulo está colisionando con otro, tienen que cumplirse 4
condiciones. Definiendo dos rectángulos r1 y r2, diremos que estos colisionan si:
1. El lado derecho de r1 es mayor que el lado izquierdo de r2.
2. El lado izquierdo de r1 es menor que lado derecho de r2.
3. El lado superior de r1 es mayor que el lado inferior de r2.
4. El lado inferior de r1 es menor que el lado superior de r2.
De cumplirse estas cuatro condiciones, se concluirá que existe una colisión entre r1
y r2. Ahora resta traducir lo anterior a código…
Entender si dos círculos están colisionando es mucho más fácil: si la suma de sus
radios es más grande que la distancia entre sus centros, entonces hay una colisión.
Fundamentalmente hay que llevar a cabo dos tareas: calcular la distancia entre sus
centros y corroborar si esta es menor a la suma de sus radios.
Para calcular la distancia entre dos puntos lo necesario es agregar una función
“distancia entre centros” a nuestra clase punto que reciba otro punto y devuelva la
distancia entre ellos. La forma de calcular la distancia entre dos puntos es con el
teorema de Pitágoras.
20
Ilustración 13. Código en Python de ejemplificación. Extraido de: https://www.genbeta.com/desarrollo/teoria-decolisiones-2d-conceptos-basicos
La inquietud que se nos podría plantear en este punto es: ¿Qué tipo de
recubrimiento elegir? Vemos que la detección de colisiones entre rectángulos es más
rápida, ya que en la de círculos hay raíces cuadradas de por medio, las cuales son
siempre algo más lentas. Pero los círculos tienen una gran ventaja frente a los
rectángulos, y es que admiten rotaciones.
Ilustración 14. Caja de colisiones poco precisas en figuras irregulares. Extraído de https://i.blogs.es/fd51a5/naves31/1366_2000.png
21
Por mucho que rotes un círculo sigue siendo un círculo. En el momento en que
rotes un rectángulo, estos cálculos tan simples ya no valen.
Una posible solución es comprobar todos los pasos intermedios con distancia
menores al tamaño de los objetos. Así, se asegura que no se atraviese ningún sólido.
Ilustración 15. Representación de Búsqueda Lineal. Extraído de: https://i.blogs.es/d44569/linear/1366_2000.png
Este método incrementa exponencialmente el número de comprobaciones de
colisión a hacer por cada objeto, haciendo un mayor uso de recursos
Esta otra solución consiste en trazar una circunferencia que tenga de diámetro la
distancia desplazada y como centro el medio del vector del desplazamiento.
Ilustración 16. Representación de la búsqueda binaria. Extraído de:
https://i.blogs.es/3b072a/binario1/1366_2000.png
Si este círculo delimitador no colisiona con ningún objeto, entonces no existe
colisión. Por otro lado, si existe una colisión, procedemos a dividir el espacio en dos
circunferencias y comprobar si existe colisión en alguna de ellas.
22
Ilustración 17. Segunda representación de la búsqueda binaria. Extraído de:
https://i.blogs.es/3869e0/binario1/1366_2000.png
Seguimos dividiendo la circunferencia donde encontremos la colisión y
desechando la otra hasta que encontremos la colisión.
Ilustración 18. Colisión de la búsqueda binaria. Extraído de: https://i.blogs.es/ bf951a / binario3/1366_2000.png
Como vemos, la búsqueda binaria reduce muchísimo las comprobaciones que
tenemos que realizar, permitiendo una gestión eficiente de los recursos.
Es evidente que la implementación de algoritmos de detección de colisión crece
en cuanto a complejidad cuando pasamos de 2D a 3D. En esta sección empezaremos
explorando las técnicas básicas y culminaremos en las avanzadas, todo esto
considerando, por un lado, la optimización y la precisión de detección y, por otro, el
rendimiento de la máquina.
Las técnicas más sencillas surgieron a finales del siglo pasado con videojuegos
como Doom o Super Mario 64. El primero, plasmando un pseudo 3D por medio del
23
conocido Raycasting (la técnica que más nos ocupará en este documento) y, el segundo,
cambiando estándares en la industria de videojuegos gracias a su innovador estilo (no
nos detendremos demasiado tiempo en este). Antes de introducir estos métodos de
colisión, pondremos en contexto lo que es trabajar con tres dimensiones extendiendo
algunas de las técnicas vistas con superficies de colisión a su análogo con volúmenes de
colisión.
VOLÚMENES DE COLISIÓN
PLANOS
La intersección de un punto con un plano se determina de una manera sencilla
mediante la ecuación del plano:
𝐴𝑥 + 𝐵𝑦 + 𝐶𝑧 + 𝐷 = 0
(1)
Para ello es necesario considerar un plano cartesiano con 3 dimensiones
definidas por los ejes x, y, z. Sea 𝑃(𝑥0 , 𝑦0 , 𝑧0 ) un punto cualquiera en el espacio, si las
coordenadas de P satisfacen (1), entonces se dice que existe una colisión entre P y el
plano:
𝐴𝑥0 + 𝐵𝑦0 + 𝐶𝑧0 + 𝐷 = 0
ESFERAS
24
Para esferas, se dice que hay una colisión con un punto 𝑃(𝑥𝑝 , 𝑦𝑝 , 𝑧𝑝 ) si la distancia entre
este y el centro de la circunferencia 𝐶(𝑥𝑐 , 𝑦𝑐 , 𝑧𝑐 ) es menor o igual al radio r de la
circunferencia:
La ecuación de la circunferencia viene dada por:
(𝑥 − 𝑥𝑐 )2 + (𝑦 − 𝑦𝑐 )2 + (𝑧 − 𝑧𝑐 )2 = 𝑟 2
(2),
donde r representa el radio. Entonces existe una colisión si:
||𝑃 − 𝐶|| ≤ 𝑟
||(𝑥𝑝 , 𝑦𝑝 , 𝑧𝑝 ) − (𝑥𝑐 , 𝑦𝑐 , 𝑧𝑐 )|| ≤ 𝑟
Para dos esferas 𝐶1 y 𝐶2 , la colisión se calcula en base a la distancia entre el centro de
cada una. Si dicha longitud es menor o igual a la suma de los radios de las
circunferencias, entonces se tiene una colisión:
||𝐶1 − 𝐶2 || ≤ 𝑟1 + 𝑟2
||(𝑥𝑐1 , 𝑦𝑐1 , 𝑧𝑐1 ) − (𝑥𝑐2 , 𝑦𝑐2 , 𝑧𝑐2 )|| ≤ 𝑟1 + 𝑟2
25
CAJAS
Usualmente se conocen como Bounding Boxes. Dado que en este caso se tiene una
mayor complejidad, es habitual utilizar dos tipos de cajas para la detección de
colisiones:
i.
Axis-Aligned Bounding Boxes (AABB): Su orientación nunca cambia y va
alineada a los ejes x, y, z manejados en el espacio de la simulación. Así, los
cálculos son relativamente sencillos.
ii.
Oriented Bounding Boxes (OBB): Su orientación varía con la rotación del
cuerpo a recubrir. Esto proporciona una mayor precisión que las AABBs, a pesar
de que el algoritmo es más complejo y exigente con la máquina.
Más adelante trataremos el tema de las Bounding Boxes, ya que la manera de utilizarlas
dependerá, entre otras cosas, de la técnica de colisión en cuestión.
RAYCASTING.
26
Ilustración 17. Extraído de: https://stackoverflow.com/questions/47239797/ray-casting-with-different-height-size
Tiempo atrás, las computadoras no poseían la capacidad de manejar motores 3D
en tiempo real. Esto dio lugar a técnicas como el Raycasting, el cual es aplicado a
mapas 2D para generar una perspectiva en 3 dimensiones (Vandevenne, 2004). Esta
técnica tuvo como pionero a Scott Roth y fue la primera solución al problema de
representar gráficos 3D, siendo implementada en videojuegos como Doom o
Wolfenstein 3D dada su favorable velocidad de cómputo.
27
EJEMPLARES.
En la Tabla 1 se muestran los ejemplares más destacados del Raycasting en la época:
Título
Año
Wolfenstein 3D
1992
Vista previa
Ilustración 19. Extraído de:
https://wolfenstein.fandom.com/es/wiki/Wolfenstein_3D
28
Doom
1993
Ilustración 20. Extraído de: https://www.nintendo.es/Juegos/Programasdescargables-Nintendo-Switch/DOOM-1993--1610001.html
Duke Nukem
1996
Ilustración 21. Extraído de:
https://as.com/meristation/2016/09/29/album/1472889780_000001.html
Tabla 1. Ejemplares del Raycasting.
Para aplicar esta técnica se requiere un elemento que cumpla la función de láser
apuntador, el cual se extienda hacia el infinito hasta que, eventualmente, colisione con
algún cuerpo sólido. Dicho elemento se conoce como ray.
29
Ilustración 18. Puntero laser
Extraído de: https://www.aao.org/eye-health/news/puntero-laser-peligroso-lesiones-oculares
Formalmente, un ray está compuesto por dos vectores: el vector posición
𝑟𝑎𝑦𝑝𝑜𝑠 , que marca el punto de partida del ray; y el de dirección 𝑟𝑎𝑦𝑑𝑖𝑟 , que empieza en
la cabeza del vector posición y es el que se extiende en una determinada dirección.
Cuando el ray se halla dentro de un cuerpo (colisiona), este último es dibujado con un
tamaño relativo a la distancia hasta el observador.
Para efectuar esta detección se emplea un ciclo que aumenta la posición de
𝑟𝑎𝑦𝑑𝑖𝑟 hasta que este colisione o hasta que se llegue a la distancia límite de detección
establecida. En cualquiera de estos casos, se procede a detener el ciclo y calcular la
distancia entre 𝑟𝑎𝑦𝑝𝑜𝑠 y 𝑟𝑎𝑦𝑑𝑖𝑟 (Vandevenne, 2004).
30
COLISIONES.
A continuación, se exponen distintos tipos de colisión que se pueden tratar por
medio de Raycasting. Para aquellos que van acompañados de su algoritmo en C++ para
su implementación, cabe aclarar que son requeridas las siguientes clases y estructuras a
fin de representar todos los elementos que intervienen en el sistema de detección:
-
Ray: Posee los atributos de tipo Vector3D denominados position y direction
para representar a 𝑟𝑎𝑦𝑝𝑜𝑠 y a 𝑟𝑎𝑦𝑑𝑖𝑟 , respectivamente.
-
SphereVolume: Posee el atributo de tipo float denominado radius, que define el
radio (en pixeles) de la esfera.
-
RayCollision: Esta clase tiene como utilidad abstraer las colisiones, dando
acceso al punto en el que esta se produjo (collidedAt de tipo Vector3) y al objeto
en cuestión (node del tipo especificado al crear una instancia).
de base para representar el ray, los volúmenes de colisión, las matrices de
transformación, entre otros. Ello será obviado en este documento para efectos de
simplicidad. Sin más que decir, los siguientes son los tipos de colisión a estudiar:
PLANOS.
Siempre que el vector normal al plano en cuestión no sea paralelo a 𝑟𝑎𝑦𝑑𝑖𝑟 (𝑟𝑎𝑦𝑑𝑖𝑟 ∙
𝑝𝑙𝑎𝑛𝑜𝑛𝑜𝑟𝑚𝑎𝑙 ≠ 0), se garantiza que habrá una intersección en algún punto P del
espacio. En primer lugar, definamos las variables que siguen:
-
p: punto de intersección de 𝑟𝑎𝑦𝑑𝑖𝑟 con el plano.
-
t: distancia que va desde 𝑟𝑎𝑦𝑝𝑜𝑠 hasta p.
-
𝒑𝒍𝒂𝒏𝒐𝒏𝒐𝒓𝒎𝒂𝒍: vector normal al plano en p.
31
-
𝒑𝒍𝒂𝒏𝒐𝒅 : el término independiente de la ecuación del plano D. En otras palabras,
sea la ecuación del plano 𝐴𝑥 + 𝐵𝑦 + 𝐶𝑧 + 𝐷 = 0, el valor 𝑝𝑙𝑎𝑛𝑜𝑑 equivale a D.
Otro modo de obtener este valor es a través del 𝐷 = ||𝑝𝑙𝑎𝑛𝑜𝑛𝑜𝑟𝑚𝑎𝑙 ∙ 𝑄||, donde
Q es cualquier punto sobre el plano.
Ilustración 19. Proyección normal del plano Extraído de:
https://research.ncl.ac.uk/game/mastersdegree/gametechnologies/physicstutorials/1raycasting/Physics%20%20Raycasting.pdf
En primer lugar, se calcula la distancia t que va desde 𝑟𝑎𝑦𝑝𝑜𝑠 hasta p:
𝑡=
−(𝑟𝑎𝑦𝑝𝑜𝑠 ∙ 𝑝𝑙𝑎𝑛𝑜𝑛𝑜𝑟𝑚𝑎𝑙 + 𝑝𝑙𝑎𝑛𝑜𝑑 )
𝑟𝑎𝑦𝑑𝑖𝑟 ∙ 𝑝𝑙𝑎𝑛𝑜𝑛𝑜𝑟𝑚𝑎𝑙
Finalmente, buscamos el punto en el cual se efectúa la intersección. Este viene dado de
la siguiente manera:
𝑝 = 𝑟𝑎𝑦𝑝𝑜𝑠 + 𝑡(𝑟𝑎𝑦𝑑𝑖𝑟 )
32
ESFERAS.
Ilustración 20. Proyección hacia una esfera de un rayo. Extraído de:
https://research.ncl.ac.uk/game/mastersdegree/gametechnologies/physicstutorials/1raycasting/Physics%20%20Raycasting.pdf
La detección de colisiones con esferas por este método se basa en el centro y radio
de esta. Nuevamente, definimos algunas variables:
-
p: punto que define si hay intersección.
-
p’: punto de intersección con la esfera.
-
𝒔𝒄𝒆𝒏𝒕𝒓𝒐 : centro de la esfera.
-
𝒓: radio de la esfera.
-
d: distancia desde 𝑟𝑎𝑦𝑝𝑜𝑠 hasta p’.
-
dir: vector que inicia en 𝑟𝑎𝑦𝑝𝑜𝑠 y culmina en 𝑠𝑐𝑒𝑛𝑡𝑟𝑜 .
El primer paso consiste en verificar si existe o no una intersección del ray con la
esfera. Para ello, calculamos dir:
𝑑𝑖𝑟 = 𝑠𝑐𝑒𝑛𝑡𝑟𝑜 − 𝑟𝑎𝑦𝑝𝑜𝑠
𝑝 = 𝑟𝑎𝑦𝑝𝑜𝑠 + (𝑑𝑖𝑟 ∙ 𝑟𝑎𝑦𝑑𝑖𝑟 )𝑟𝑎𝑦𝑑𝑖𝑟
33
Si |𝑝 − 𝑠𝑐𝑒𝑛𝑡𝑟𝑜 | ≤ 𝑟, entonces hay una colisión en un punto p’. Para calcularlo,
hallamos, en segundo lugar, la distancia d:
𝑑 = ||𝑝 − 𝑟𝑎𝑦𝑝𝑜𝑠 || − √𝑟 2 − ||𝑝 − 𝑠𝑐𝑒𝑛𝑡𝑟𝑜 ||
2
Finalmente, el punto de colisión será:
𝑝′ = 𝑟𝑎𝑦𝑝𝑜𝑠 + 𝑑(𝑟𝑎𝑦𝑑𝑖𝑟 )
Algoritmo (C++):
El Algoritmo 1 determina si existe una colisión entre un ray una la esfera cuya
matriz de transformación es recibida por parámetros. De ser así, retorna verdadero; caso
contrario, retorna falso. El algoritmo recibe por parámetros al ray r, a la matriz de
transformación de la esfera worldTransform, al volumen de la esfera volume y a la
instancia de colisión collision.
34
Ilustración 21. Código en C++ de detección de colisión hacia una esfera. Extraído de:
https://research.ncl.ac.uk/game/mastersdegree/gametechnologies/physicstutorials/1raycasting/Physics%20%20Raycasting.pdf
CAJAS.
i.
AABB:
Cuando trabajamos con AABBs estamos trabajando con cajas que poseen una
orientación fija basada en los ejes x, y y z en cuestión, de modo que cada caja poseerá un
ancho, un largo y un alto. Para efectos de practicidad, asociaremos estos atributos con
los ejes x, y y z, respectivamente; y, como es de esperarse, definiremos las siguientes
variables:
35
-
𝒃𝒐𝒙𝒄𝒆𝒏𝒕𝒓𝒐 : centro de la esfera.
-
dir: vector que va desde 𝑟𝑎𝑦𝑑𝑖𝑟 hasta 𝑏𝑜𝑥𝑐𝑒𝑛𝑡𝑟𝑜 .
-
𝒔𝒊𝒛𝒆𝒙 : mitad del ancho de la caja.
-
𝒔𝒊𝒛𝒆𝒚 : mitad del largo de la caja.
-
𝒔𝒊𝒛𝒆𝒛 : mitad del alto de la caja.
Ilustración 22. Rayo proyectado hacia caja, Extraído de:
https://research.ncl.ac.uk/game/mastersdegree/gametechnologies/physicstutorials/1raycasting/Physics%20%20Raycasting.pdf
En caso de que sólo deseemos saber si existe alguna colisión entre el ray y la
caja, el proceso a seguir consiste en calcular el vector dir definido previamente y
verificar, por medio de la magnitud de sus componentes, si se da una colisión.
𝑑𝑖𝑟 = 𝑟𝑎𝑦𝑑𝑖𝑟 − 𝑏𝑜𝑥𝑐𝑒𝑛𝑡𝑟𝑜
36
Ahora, se compara la magnitud de los componentes del vector dir con los valores 𝑠𝑖𝑧𝑒𝑥 ,
𝑠𝑖𝑧𝑒𝑦 , 𝑠𝑖𝑧𝑒𝑧 de la siguiente manera. Si:
-
|𝑑𝑖𝑟𝑥 | ≤ 𝑠𝑖𝑧𝑒𝑥 ,
-
|𝑑𝑖𝑟𝑦 | ≤ 𝑠𝑖𝑧𝑒𝑦 y
-
|𝑑𝑖𝑟𝑧 | ≤ 𝑠𝑖𝑧𝑒𝑧 ,
entonces existe una colisión del ray con la caja AABB.
En caso de que se deseemos conocer el punto exacto de colisión, el proceso es
un poco menos sencillo. Como es sabido, las cajas poseen 6 caras, no obstante, no es
necesario realizar los cálculos con cada una de ellas, puesto que podemos descartar
aquellas 3 que se encuentren más lejanas a 𝑟𝑎𝑦𝑑𝑖𝑟 , una por cada eje con el objetivo de
reducir la carga computacional.
Por ejemplo, si el ray se dirige hacia arriba, sabemos que intersectará antes con
la cara inferior de la caja, por lo que descartaremos inmediatamente la cara superior.
Llevando esto a todas las caras de la caja, haremos 3 descartes y el número de
comparaciones será la mitad.
37
Ilustración 23. Proyección normal de colisión hacia la caja. Extraído de:
https://research.ncl.ac.uk/game/mastersdegree/gametechnologies/physicstutorials/1raycasting/Physics%20%20Raycasting.pdf
En la Ilustración 24 se observa una representación de esta situación en 2D en la
cual, habiendo descartado las caras superior e izquierda (y quedando con la cara inferior
y la derecha), notamos que el punto de colisión se dará en aquella cara cuyo eje es el
más lejano a 𝑟𝑎𝑦𝑝𝑜𝑠 . Extrapolaremos esto a una situación 3D, pero antes vamos a
definir las siguientes variables:
-
𝒃𝒐𝒙𝒎𝒊𝒏: vértice con las coordenadas de menor valor de la caja.
-
𝒃𝒐𝒙𝒎𝒂𝒙 : vértice con las coordenadas de mayor valor de la caja.
-
p: punto de colisión del ray con la caja.
-
dist: suponiendo que se han descartado 3 caras de la caja, esta variable indica la
mayor distancia desde 𝑟𝑎𝑦𝑝𝑜𝑠 hasta el plano de las caras restantes que se halla
más lejano.
𝑏𝑜𝑥𝑚𝑖𝑛 = 𝑏𝑜𝑥𝑐𝑒𝑛𝑡𝑟𝑜 − (𝑠𝑖𝑧𝑒𝑥 𝑖 + 𝑠𝑖𝑧𝑒𝑦 𝑗 + 𝑠𝑖𝑧𝑒𝑧 𝑘)
𝑏𝑜𝑥𝑚𝑎𝑥 = 𝑏𝑜𝑥𝑐𝑒𝑛𝑡𝑟𝑜 + (𝑠𝑖𝑧𝑒𝑥 𝑖 + 𝑠𝑖𝑧𝑒𝑦 𝑗 + 𝑠𝑖𝑧𝑒𝑧 𝑘)
38
Calculamos los siguientes 3 valores:
-
-
-
𝑏𝑜𝑥min 𝑥 −𝑟𝑎𝑦𝑝𝑜𝑠 𝑥
𝑟𝑎𝑦𝑑𝑖𝑟 𝑥
𝑏𝑜𝑥min 𝑦 −𝑟𝑎𝑦𝑝𝑜𝑠 𝑦
𝑟𝑎𝑦𝑑𝑖𝑟 𝑦
𝑏𝑜𝑥min 𝑧 −𝑟𝑎𝑦𝑝𝑜𝑠 𝑧
𝑟𝑎𝑦𝑑𝑖𝑟 𝑧
si 𝑟𝑎𝑦𝑑𝑖𝑟 𝑥 > 0, ó
si 𝑟𝑎𝑦𝑑𝑖𝑟 𝑦 > 0, ó
si 𝑟𝑎𝑦𝑑𝑖𝑟 𝑧 > 0, ó
𝑏𝑜𝑥max 𝑥 −𝑟𝑎𝑦𝑝𝑜𝑠 𝑥
en caso contrario,
𝑟𝑎𝑦𝑑𝑖𝑟 𝑥
𝑏𝑜𝑥max 𝑦 −𝑟𝑎𝑦𝑝𝑜𝑠 𝑦
𝑟𝑎𝑦𝑑𝑖𝑟 𝑦
𝑏𝑜𝑥max 𝑧 −𝑟𝑎𝑦𝑝𝑜𝑠 𝑧
𝑟𝑎𝑦𝑑𝑖𝑟 𝑧
en caso contrario y
en caso contrario,
y asignamos el mayor de ellos a la variable dist. Si 𝑑𝑖𝑠𝑡 < 0 entonces significa que el
ray apunta en dirección opuesta a la caja, por lo que no existe una colisión. De no ser
así, calculamos p (esto no garantiza una colisión):
𝑝 = 𝑟𝑎𝑦𝑝𝑜𝑠 + 𝑑𝑖𝑠𝑡(𝑟𝑎𝑦𝑝𝑜𝑠 )
Si se cumple que:
-
𝑝𝑥 ≤ 𝑚𝑎𝑥𝑥 ,
-
𝑝𝑥 ≥ 𝑚𝑖𝑛𝑥 ,
-
𝑝𝑦 ≤ 𝑚𝑎𝑥𝑦 ,
-
𝑝𝑦 ≥ 𝑚𝑖𝑛𝑦 ,
-
𝑝𝑧 ≤ 𝑚𝑎𝑥𝑧 y
-
𝑝𝑧 ≥ 𝑚𝑖𝑛𝑧 ,
Entonces existe una colisión del ray con la caja en p. Por supuesto, lo anterior puede
ser aplicado igualmente con un valor épsilon si se busca aceptar colisiones con cierto
margen de error, debido a que, para ojos del jugador, los cálculos no necesitan tener una
precisión del 100%, en especial cuando tratamos con números reales.
39
Algoritmo (C++):
El Algoritmo 2 lleva los pasos que vimos previamente a código. El algoritmo
recibe por parámetros al ray r, a al centro de la caja boxPos, al tamaño de la caja
boxSize y a la instancia de colisión collision.
Ilustración 24. Algoritmo en C++ de detección hacia cajas. Extraído de:
https://research.ncl.ac.uk/game/mastersdegree/gametechnologies/physicstutorials/1raycasting/Physics%20%20Raycasting.pdf
40
ii.
OBB:
Manejar colisiones con OBBs por medio de Raycasting es mucho más complejo que
con AABBs. Esto se debe principalmente a que el ray y el OBB poseen ejes de referencia
distintos, lo cual obliga a implementar otro tipo de estrategias para calcular las
colisiones.
Visto lo anterior, ¿es posible llevar ambos elementos a un mismo “mundo”? La
respuesta es sí, y ello requiere pasar del sistema de ejes por defecto (world space) a un
sistema pasajero de coordenadas (local space).
La solución que aquí se trata consiste en transformar temporalmente la posición
y dirección del ray, de modo que estos pasen a compartir la orientación del OBB en
cuestión y a fin de convertir esta situación en una que aplique los ya tratados AABBs.
Esto se logra usando el inverso de la matriz de transformación del ray.
Algoritmo (C++):
El Algoritmo 3 recibe por parámetros al ray r, a la matriz de transformación de la
caja transform, al volumen de la caja volume y a la instancia de colisión collision.
Ilustración 25. Código en C++ de detección de colisión hacia caja OBB. Extraído de:
https://research.ncl.ac.uk/game/mastersdegree/gametechnologies/physicstutorials/1raycasting/Physics%20%20Raycasting.pdf
41
SUPER MARIO 64
Super Mario 64 logró revolucionar la industria de los videojuegos, rompiendo
con la tradición de la saga de Mario llena de ejemplares estilo plataforma 2D. En 1996
fue lanzado al mercado un juego de mundo abierto en 3 dimensiones, el cual, a
diferencia de los ya tratados Doom, Duke Nukem y Wolfenstein 3D, sí implementó un
sistema de colisión 3D.
Las superficies del mapa se basaban en triángulos con cierta orientación, a partir
de la cual se definía si se trataba de una pared, techo, suelo, etc.
Ilustración 26. Mapa representado en sus polígonos. Extraído de: https://youtu.be/6hUK1Wbajt4
Cualquier figura 2D en el juego puede ser representada por medio de triángulos,
como se observa debajo.
Ilustración 27. Caj de colisión del piso de Super Mario 64. Extraído de: https://youtu.be/UnU7DJXiMAQ
42
En adición, Super Mario 64 hizo uso de volúmenes de recubrimiento para las
figuras 3D en conjunto con algoritmos capaces de detectar y responder ante colisiones
entre volúmenes con volúmenes y volúmenes con superficies.
Ilustración 28. Representación de una colisión en sus formas elementales. Extraído de:
https://youtu.be/CLNSw11RQCQ
Para examinar las colisiones en el contexto planteado podemos recurrir a los
métodos vistos anteriormente en la sección de Volúmenes de Colisión. No nos
detendremos en este punto dado que es necesario conocer técnicas más avanzadas
encaminadas a trabajar en ambientes de mayor complejidad e, incluso, optimizar los
métodos que hemos estudiado hasta el momento.
43
Luego del salto tecnológico al plano de las tres dimensiones, muchas de las
técnicas se implementaron a esta nueva dimensión.
Muchas de las técnicas avanzadas plantean el uso de estructuras de datos y
nociones matemáticas de mayor complejidad, primeramente, tomamos en cuenta las
estructuras de datos para facilitar los cálculos de las mencionadas cajas de colisiones,
esta vez orientadas a sus volúmenes, donde era necesario cálculos más rápidos a formas
más poligonales, donde ahora esta seria nuestro objeto de colisión, lo que hace que
nuestro numero de combinaciones oscile números inmensos, por ejemplo, tomando en
cuenta la caja de colisiones del videojuego Counter Strike Global Offensive:
Partiendo de que, en una situación normal del juego, podemos partir de que, si hay 9
personas vivas, y cada uno disparar tres balas, cada parte de la caja de colisiones podría
tener alrededor de 27 colisiones, formando en total que sobre tu personaje se calculan
324 colisiones, y si lo llevamos al plano de todo el juego en función de los personajes,
serian 1620 colisiones.
44
Debido a estas reglas nacen unas nuevas aproximaciones voraces y uso de técnicas
antes más ineficientes para solucionar a estos problemas, donde en el libro “Game
Progamming Patterns” podemos encontrar dichas asumpciónes (Nystrom, 2014) :
•
Creación de cajas convexas, donde su resultado, no sea una forma geométrica
regular tridimensional, gracias al avance en procesamiento, esta solución era
más viable.
•
Clasificación de objetos en estacionarios y dinámicos.
•
Reducción de colisiones, en función de su probabilidad.
•
Uso de estructuras dinámicas que ayuden a simular un plano especial.
Gracias a estas aproximaciones, podemos partir de la creación de una mejora de los
algoritmos de AABB, que resulta en un algoritmo de OBB, donde se orientan en el uso
de estructuras dinámicas como arboles binarios parcialmente ordenados con condición
inferior, donde se almacena la partición volumétrica de cada parte de nuestro polígono y
luego apoyarnos en el teorema de SAT para lograr detectar las colisiones.
Esta solución se construyó haciendo uso de los conceptos de recursividad y
programación dinámica para la construcción de las cajas y geometría planar para hallar
las colisiones.
Igual que las soluciones anteriores, iremos construyendo dicha idea, primero en
pasos:
1. Construir la partición por volumen de la figura de manera recursiva
2. Almacenar dichas partes en un montículo o BSP
3. Creación de la OBB
4. Dentro del juego, ejecutar el teorema de SAT cada cuadro para verificar
si existe una colisión.
45
La importancia de este algoritmo reside en la precisión de este, el punto clave a
entender sobre los algoritmos básicos, es el remplazo del modelo AABB a un modelo
OBB, el paso número 3, del algoritmo, esta diferencia reside en que el modelo AABB al
ser rotado sobre su eje debe recalcular sus dimensiones, que en el plano volumétrico
puede causar grandes errores de colisiones.
Ilustración 29. Falla al presentar rotación sobre su eje. Imagen extraída de:
ttps://www.gamasutra.com/view/feature/3190/advanced_collision_detection_.php?print=1
A diferencia de la una caja de colisiones AABB que siempre estará creada sobre
un eje sobre el cual esta se va a alinear cuando se produzca una rotación o movimiento,
este constante calculo provocaría que cada segundo debiera generarse una nueva caja de
colisiones, donde probablemente en ese cálculo puede fallar la colisión, o en el caso de
no generarla, al momento de una rotación el volumen de la caja seria distinto al de su
caja, dando fallas en las colisiones.
Por ejemplo, podemos tomar en consideración un juego donde los cálculos
deben ser rápidos y precisos como la franquicia de Dark Souls, el cual se caracteriza por
su dificultad y frenéticos combates. Debido a esto, necesitan estar verificando
constantemente golpes espontáneos y rápido, por lo que usarían un modelo similar al
AABB, sin embargo, cuando un enemigo ejecute un golpe donde la espada rote lo
suficiente para alterar su eje o el personaje se deslice justo en esos momentos, no se
notara la colisión de manera inmediata.
46
Ilustración 30. Error ocasionado por una mala detección de colisiones del juego Dark Souls. Extraída de:
https://i.kinja-img.com/gawker-media/image/upload/hhn3h9xlne9keaxosw62.gif
La recomendación para este modelo parte de juegos que necesiten una precisión
de calculo eficiente y no tan espontanea, géneros como los FPS hacen uso constante de
este, debido a la importancia de la detección de colisión con explosiones y proyectiles a
lo largo de los mapas y jugadores.
Por lo tanto, primeramente, necesitamos definir el paso 1, que usaremos el
concepto de OVB, que seria en este caso usando, la mejor aproximación actual es el
algoritmo de O'Rourke's, su visualización seria la siguiente, con el personaje de
Megaman:
47
Ilustración 31. Modelo tridimensional de Megaman.Extraída de:
https://es.ssbwiki.com/wiki/Pose_de_referencia
Algorítmicamente la idea detrás de la generación de una caja de convexa es la noción
del concepto de “divide y vencerás”, donde dado un set de puntos que representan las
coordenadas espaciales del polígono iremos usando los dos puntos más distantes en la
coordenada X, y obtendremos un tercer punto que sea la distancia en Z más alta entre esos dos
48
puntos, al construir nuestra pirámide, eliminaremos los puntos internos e iremos repitiendo el
proceso con los puntos seleccionados previamente.
Para un mayor entendimiento de esta figura, se ingresará un fragmento de código en
Python y su ejecución, donde solo se obtiene esta caja para un set de puntos en 2D, si se desea
una mayor manejo y compresión, se dejará el artículo del cual fue sacado el código (Washam,
2016).
Ilustración 32. Generador de la caja convexa en Python. Extraído de: https://startupnextdoor.com/computingconvex-hull-in-python/
Para este caso en particular iremos tomando la figura de Megaman, este partirá su
cuerpo poligonal en dos grandes cajas convexas, el torso y las extremidades superiores, y dichas
partes recursivamente las procesará para lograr genera una caja más pequeña para ese entorno, y
así hasta cuando cubra la mínima en cada uno, donde quedará una caja con bastante precisión.
49
Debido a la gran extensión que cubre el algoritmo, para poder tener una mejor
interpretación de este y su idea, se encuentra una implementación en el lenguaje Mathlab por el
usuario chadogme en el repositorio de OptimalBB 1.
Durante la ejecución del paso anterior iríamos insertando, a un montículo dichas
ejecuciones, donde la raíz seria la totalidad del cuerpo poligonal, y cada división que va
realizando será un hijo, donde a cada hijo se le construirá su OBB, por el fin explorativo de la
investigación se asumirá que dicho algoritmo se encuentra ya construido en nuestro motor
gráfico2.
Si el lector desea tener una mayor exploración sobre el tema de la construcción de OBB,
se le recomienda la lectura del trabajo investigativo “Oriented Bounding Box” (SCHNEIDER
& EBERLY, 2003)
Dando el caso anterior el siguiente árbol montículo de figura repartidas en el espacio o BSP:
Ilustración 33. BSP de la partición del modelo
1
Código de la implementación del algoritmo para la creación de la caja convexa para modelos
en 3D https://github.com/chadogome/OptimalOBB/tree/master/src
2
Actualmente existen una amplia cantidad de modelos matemáticos que se usan para generar
una OBB, sin embargo, en la mayoría de los casos las usadas por los videojuegos vienen
implementadas por los motores comerciales o privados.
50
Podemos ver el árbol de la siguiente manera:
•
A es el modelo en si al dividirla
•
B sería la primera caja vertical
o
•
D y E serian la partición de B
C sería la primera caja horizontal
o
F y G serian la partición de C
Ya luego de haber generado cada OBB para cada entidad de nuestro juego, nos
disponemos a la esencia básica de una colisión otra vez, la intersección de alguna de las cajas de
colisión. Usaremos el mismo método que realizan muchas colisiones en 2D, es el teorema de
SAT (Separating axis theorem), que se encarga de verificar que si al realizar una proyección de
entre dos polígonos, se podría realizar una línea entre estos, si se sobreponen hay colisión.
Sin embargo, en este caso contamos con una particularidad, muchos de los problemas
que se encontraron a la hora de implementar este teorema (Ejes a tomar, formas de las cajas,
proyecciones de ejes…) se resuelven por la naturaleza de nuestra nueva caja de colisiones, que
al ser arbitrariamente ordenada y genera formas convexas para cada entidad, no es necesario
verificar las condiciones anteriores, y el resultado a generar seguirá siendo una línea.
51
De igual manera para una mayor compresión se colocará un fragmento que cuente con
el algoritmo enfocado a las tres dimensiones y un pequeño fragmento de este.
Ilustración 34. Seudocódigo del SAT implementado en 3D Extraído de:
https://gamedev.stackexchange.com/questions/44500/how-many-and-which-axes-to-use-for-3d-obb-collision-withsat
Por otro lado, se dejará una implementación del código funcional en el motor grafico
Unity en el lenguaje de C#, creado por el usuario Bas Emit 3
3
Enlace del código
https://drive.google.com/file/d/1wXoYqQbO5TqkQ9fEgCbFQw4PL05Ap7Xu/view?usp=sharing
52
Ilustración 35. Implementación del teorema de SAT en C#
Ilustración 36. Demostración correcta del código en el motor grafico de Untiy
Como se puede en la esquina inferior izquierda, nos indica que no hay colisión,
donde el mensaje de la consola dice “False”.
53
Ilustración 37. Demostración correcta del código en el motor grafico de Untiy
En el caso contrario nos indica que, si hay colisión, se puede ver en la esquina
inferior izquierda.
Luego, se buscó desarrollar un sistema que aplique los conceptos de Colisión e
Interacción, estos objetivos normalmente iban de la mano con la necesidad de procesar
la ocurrencia de choques de la manera más efectiva y en el menor tiempo posible, ya
que luego de identificar el choque lo común es tener que ejecutar una acción en
consecuencia. Por esto se han buscó nuevas desarrollar técnicas que permitieran
procesar grandes cantidades de posibles colisiones entre entidades en tiempos
convenientemente cortos.
54
A partir de esta necesidad se planteó la idea de dividir los procesos en una etapa
de “preparativos” y otra de ejecución final. Esta es la base de los algoritmos de
detección de colisiones de dos fases4, compuestos por una Narrow Phase, que es la
segunda fase, destinada a la detección propiamente dicha de las colisiones; y una Broad
Phase, que es la primera, que tiene el propósito de simplificar lo más posible el área o
espacio de evaluación, descartando grupos de datos a partir de identificadores
relacionados con su posición en el espacio.
La Narrow Phase de un algoritmo de dos fases se puede llevar a cabo por medio
de diversas técnicas, de las cuales el particionamiento espacial (Spatial Partitioning) es
una de las más representativas, efectivas y sencillas de comprender.
Esta técnica permite ahorrar mucho tiempo de ejecución, ya que en lugar de
evaluar cada una de todas las estadísticamente posibles colisiones que pudieron haberse
producido en un instante de tiempo, categoriza las entidades evaluables por bloques de
los cuales cada uno representa una sección del espacial (Gallego & Rodríguez, n.d.).
Para ejemplificar la importancia de esta partición espacial, imaginemos un
recipiente con esferas rebotando y chocando entre ellas. Si en un momento específico
quisiéramos identificar qué esferas están chocando sin ninguna técnica especializada
previa, nos veríamos en la necesidad de evaluar si existe una colisión para cada par de
esferas posible, lo cual podría aumentar en gran medida su tiempo de ejecución si
agregamos más esferas al recipiente, haciéndolo un método ineficiente.
4
Algoritmo de dos fases: Se basa en separar el procedimiento en una primera fase que identifica la
primera solución factible (y más básica), y en una segunda fase que identifica la solución específica a
partir de la básica encontrada anteriormente.
https://sites.google.com/site/metodosdeprogramacionlinealdan/metodo-de-las-dos-fases
55
Por otro lado, si decidimos separar el espacio del recipiente en varias secciones,
cuando decidamos evaluar las colisiones, tendremos la opción de recorrer el espacio
total por medio de las secciones anteriormente establecidas, cada una con pocas esferas
en su interior, y evaluar para cada sección si se producen colisiones entre los elementos
que contiene. Y si la cuestión fuera evaluar las colisiones de esferas en un área
específica, este razonamiento cobra aún más relevancia. En lugar de evaluar cada una de
las esferas individualmente, verificar si se encuentra en esa área, y comprobar si
colisiona con otra, tenemos la opción de dirigirnos directamente a la partición que nos
representa esa sección del espacio, y evaluar únicamente las entidades en su interior.
A partir de esta básica ejemplificación podemos evidenciar fácilmente un punto
muy importante que se convierte en el fundamento de las particiones espaciales, el
cual indica que “Si organizamos nuestros objetos en una estructura de datos organizada
por sus localizaciones, podemos acceder a ellos mucho más rápido” (Nystrom, 2014)
Ilustración 38. Ejemplo de árbol k-d (Tipo de estructura para partición espacial). Extraído de:
https://www.google.com/url?sa=i&url=http%3A%2F%2Fwww.gitta.info%2FSpatPartitio%2Fen%2Ftext%2FSpatParti
tio.pdf&psig=AOvVaw333wr5eMG3wgdSuk0grA9l&ust=1604629221681000&source=images&cd=vfe&ved=0CA0Qjh
xqFwoTCIDRkfSr6uwCFQAAAAAdAAAAABAU
Estas particiones pueden ser puesta en práctica con un ejemplo práctico bastante
simple expuesto en el libro Game Programming Patterns por Robert Nystrom, en el
cual busca modelar colisiones entre varios soldados en un campo amplio, para lo cual
divide el campo en secciones de una cuadrícula:
56
Algoritmo (C++):
Clase de la cuadrícula:
Clase de soldados:
57
Nótese que cada celda de la cuadrícula es a fin de cuentas un “apuntador” hacia una
unidad, por lo que el espacio estaría siendo organizado en una lista doblemente
enlazada, tal que:
Ilustración 39. Representación de la relación celda-unidad. Extraído de:
https://gameprogrammingpatterns.com/images/spatial-partition-linked-list.png
Dentro de esta estructura organizada, se evaluaría cada celda una por una, y estas
manejarían las acciones entre soldados de esta manera:
Ilustración 40. Código que representa el sistema de casillas. Extraído de:
https://gameprogrammingpatterns.com/images/
58
Si se decidiera evaluar las colisiones entre soldados sin una partición espacial, sería de
esta forma:
Nótese que ambos algoritmos de comparación realizan exactamente los mismos pasos
(con sintaxis distinta), pero con la diferencia de que el último realiza estas
comparaciones entre cada uno de los soldados y todos los demás, mientras que con la
implementación de la partición espacial descartamos todos los soldados que estén en
celdas distintas al que se está evaluando, y solo se comparan posiciones con aquellos
que estén lo suficientemente cerca para que se produzca una colisión (en la misma
celda).
Las particiones espaciales pueden implementarse por medio de diversas
estructuras de datos, pero las más comunes son:
59
Grid: También conocida como cuadrícula, un grid es un arreglo de datos que
puede presentarse en cualquier forma. En esta estructura los datos no necesitan
ser adyacentes entre ellos.
Ilustración 41. Representación de un grid. Extraído de:
https://gameprogrammingpatterns.com/images/spatial-partition-grid.png
BSP (Binary Space Partitioning): Es un método para realizar dos subdivisiones del
espacio de manera recursiva, de forma que estas dos nuevas particiones tengan
aproximadamente el mismo número de elementos.
Ilustración 42: Representación de una BSP Extraído de:
https://upload.wikimedia.org/wikipedia/commons/thumb/8/81/Binary_space_partition.png/600pxBinary_space_partition.png
60
Quadtree: O árbol cuaternario, empieza con todo el espacio como una única partición.
Para este espacio se designa un límite de elementos, y en el momento en que el número
de elementos supere el límite admisible, el espacio en el cual fue superado se parte en 4
secciones. Este proceso se realiza de manera recursiva hasta que cada una de las
secciones generadas poseen menos elementos que el límite designado.
Ilustración 42: Representación de una BSP Extraído de: https://opendsaserver.cs.vt.edu/ODSA/Books/CS3/html/_images/PRexamp.png
Respecto a colisiones, el árbol cuaternario está destinado principalmente a un ambiente
en dos dimensiones, si se desea implementar este tipo de partición en tres dimensiones,
se deben manejar los datos un Octree, que es básicamente el análogo directo para 3D de
un QuadTree. En lugar de particiones de a 4 secciones cada una, se realizan particiones
de a 8 volúmenes cada una. Además de la dimensión adicional, el manejo de este árbol
no se distancia mucho del manejo de un QuadTree.
61
Ilustración 42: Representación de un Octree. Extraído de:
https://upload.wikimedia.org/wikipedia/commons/thumb/2/20/Octree2.svg/1200px-Octree2.svg.png
62
CAPITULO IV
CONCLUSIONES
A lo largo de la investigación hemos visto desde las primeras ideas de la lo que
los primeros ingenieros de sistemas tenían sobre modelar el concepto de colisión, como
desde el uso de múltiples teoremas matemáticos lo único que necesitaron fue mejorar
sus maneras de crear estas colisiones, desde los modelos de caja perfecta hasta los
modelos de caja convexa o OBB.
Primeramente, podemos concluir que no existe un algoritmo mejor en cuanto a
tiempos de ejecución a grandes rasgos, este solo depende de nuestra necesidad. Aunque
su eficiencia y tiempo de ejecución varié de manera significativa entre ellos,
actualmente con la potencia de procesamiento que tenemos, hace que muchos
algoritmos que hace mucho tiempo fueran inviables como el Modelo RayCasting –
OBB, las mejoras realizadas a estos y el aumento del poder de procesamiento llevaron a
que hoy en día podamos ejecutar la mayoría de estos algoritmos en nuestros
videojuegos de una manera “rápida” en nuestro juego, donde la variante es su precisión.
Consecuentemente con la idea anterior, podemos afirmar que los algoritmos
residen en su precisión y necesidad, es decir, como ingenieros de sistemas debemos de
primera mano entender el contexto en el cual deseamos realizar y verificar las
colisiones. Por ejemplo, al realizar un juego de deportes como FIFA, seria
completamente inviable la generación de una caja de colisiones AABB, donde tanto los
jugadores como el balón estarán en constante movimiento, teniendo contacto físico
entre ellos y el balón recibiendo distintos tipos de efecto para realizar algunos tiros al
arco o a otros jugadores, un modelo tan rápido, pero poco preciso generaría una mala
experiencia de juego y posibles fallos no intuitivos.
63
Gracias a esto podemos afirmar, la importancia del análisis del contexto a la
hora de realizar una solución para un problema dado, enfatizando el área de
planificación y maquetado de un sistema de soluciones, en vez de realizar directamente
la codificación, ya que se pudo ver a lo largo del desarrollo de esta investigación que
múltiples motores gráficos comerciales como Unity o Unreal Engine, vienen con ciertos
modelos creados como el OBB y el AABB, sin embargo, tú mismo puedes realizar tu
propio modelo de colisión y en cual enfocarte para tu videojuego.
Para concluir, pudimos ver de manera general como grupo la importancia de
conocer todas las soluciones posibles que disponemos a la hora de generar una solución
a un problema, y que no existe una única respuesta a nuestro problema, sino múltiples
maneras de abordarlo y abstraerlos. En el campo de los videojuegos y aprendizaje
grupal pudimos ver como se reúnen todos los conocimientos que hemos tenido a lo
largo del desarrollo de la carrera, además de aprender una nueva serie de conceptos que
nos permite un mejor desarrollo como profesionales.
64
CAPITULO V
BIBLIOGRAFIA
Gallego, F., & Rodríguez, S. (n.d.). Detección de colisiones 3D. Test.
Nystrom, B. (2014). Game Programming Patterns (G. Be (ed.)).
https://gameprogrammingpatterns.com/
SCHNEIDER, P., & EBERLY, D. (2003). Oriented Bounding Box.
https://www.sciencedirect.com/topics/computer-science/oriented-bounding-box
Souto, N. (n.d.). Video Game Physics Tutorial - Part II: Collision Detection for Solid Objects.
https://www.toptal.com/game/video-game-physics-part-ii-collision-detection-for-solidobjects
Vandevenne, L. (2004). Raycasting. https://lodev.org/cgtutor/raycasting.html
Washam, J. (2016). Computing Convex Hull in Python.
https://startupnextdoor.com/computing-convex-hull-in-python/
Daddu. (2018). SM64 Janky Hitboxes (4:39).
https://www.youtube.com/watch?v=CLNSw11RQCQ&feature=youtu.be&ab_channel=da
ddu
UncommentatedPannen. (2017). Walls, Floors, & Ceilings (37:22).
https://www.youtube.com/watch?v=UnU7DJXiMAQ&feature=youtu.be&ab_channel=Un
commentatedPannen
Josh65536. (2017). SM64DS: Mesh Colliders Part 2: Collision Detection (9:26).
https://www.youtube.com/watch?v=6hUK1Wbajt4&feature=youtu.be&ab_channel=Josh
65536
Physics - Raycasting Introduction. (n.d.). 1–17.
Ford, C. M. (2017). Virtuosos on the Screen: Playing Virtual Characters Like Instruments in
Competitive Super Smash Bros. Melee. Proceedings of the 2017 CHI Conference on
Human Factors in Computing Systems.
Bobic, B. N. (2009). Advanced Collision Detection. AdvancED ActionScript 3.0 Animation, 1–47.
https://doi.org/10.1007/978-1-4302-1609-4_1
Washam, J. (2016). Computing Convex Hull in Python.
https://startupnextdoor.com/computing-convex-hull-in-python/
Adrian. (2013). Teoría de colisiones 2D: Conceptos básicos.
https://www.genbeta.com/desarrollo/teoria-de-colisiones-2d-conceptos-basicos
65
View publication stats