¿Seguridad en el cálculo ó Fallo en la programación?.

music: MOBY -"Natural Blues"-

Bueno, pues al fín terminé de vér cómo funciona el sistema de Collision Detection. Pero hay algo que no termino de enterarme, y no sé si lo están haciendo por seguridad ó es un bug de la demo. Anoto aquí la duda sobre el asunto, el cual explico resumidamente:

1-Por una parte tenemos 8 vértices, y tenemos que comprobar que alguno de ellos, está ó no dentro de un espacio cuadrado delimitado por cuatro vértices que están dentro de un plano. Para ello vamos a tener un bucle for que lo que va a ir haciendo es coger cada uno de dichos vértices (de entre los 8 a comprobar), hallar la proyección ortogonal de ellos sobre el plano, y comprobar si dicha proyección está ó no dentro del espacio cuadrado del plano. OK

2-En cuanto se demuestra que la proyección ortogonal sobre el plano de uno de estos 8 vértices está, además, dentro del espacio cuadrado, se procede a calcular la distancia existente entre el vértice y su proyección; si es aproximadamente 0, se considera que el vértice mismo está colisionando contra ese plano. Y además, se rompe el bucle for y no se siguen comprobando el resto de los vértices. También OK.

3-Hasta aquí, todo bien. El asunto es que al citado bucle for de los 8 vértices lo engloba un bucle infinito; si se cumple todo lo del paso 2, se incrementará un contador... ¡PERO PERMANECEREMOS DENTRO DEL BUCLE INFINITO!. En la siguiente iteración de dicho bucle infinito NO se pasa a evaluar otro grupo de 8 vértices, sino los mismos; no se cambia de plano (ni de su correspondiente espacio cuadrado, sigue siendo el mismo). Con lo cual volverá a evaluarse y volverá a salir, digo yo, EL MISMO VÉRTICE; se volverá a incrementar el contador, se rompe el bucle for de los 8 vértices, volvemos a entrar en el bucle infinito...

4-...y así, hasta que el valor almacenado contador sea mayor que 20, y ahora sí, salimos del bucle infinito. Momento en que, si bien los 8 vértices van a ser los mismos, se toma un nuevo plano (el cual tendrá su correspondiente espacio cuadrado definido por cuatro vértices que están dentro de él) y se pasa al punto 1.

OK, pero... ahí está la duda: hasta llegar al punto 4 ,hemos realizado el proceso explicado en el punto 3... ¡¡¡20 VECES!!!. Y lo que no llego a ver es si esto algo que se desea realizar de esa manera por alguna razón (quizás por seguridad, para evitar posibles errores de punto flotante, o lo que sea)... o es directamente un fallo en la programación.

Pero bueno, ahí se va a quedar la cosa; ya me enteraré otro año.

Hasta otra. :P

No eran proyecciones, sino ecuaciones de planos...

music: COPTIC RAIN -"Barefoot / Perfect Lie"-

Estos días los he pasado averiguando cómo funcionaba el sistema de C0llision Detection de la famosa demo de los Donuts, algo en lo que me había quedado encasquillado en otra ocasión... pero esta vez he tenido más éxito.

El problema radicaba, principalmente, en el enfoque. Mientras veía el funcionamiento del método encargado de realizar la Colission Detection estaba entendiéndolo como una serie de proyecciones de cada uno de los vértices del Bounding Box del primer objeto (aquel que realiza la Collision Detection con el resto de objetos) sobre las normales de las caras del Bounding Box del "segundo objeto (en cada caso, éste último será el objeto digno del análisis de Collision Detection por parte del primer objeto; cabe destacar que Objeto 1 siempre será distinto de Objeto 2).

Bajo esta perspectiva la explicación "casi funcionaba", pero me fallaba algo: no comprendía cómo con una simple resta del vértice actual del Objeto 1 sobre lo que yo consideraba "la proyección de él mismo" sobre la normal de la cara actual del Objeto 2 hallábamos ya la proyección de dicho vértice actual sobre la cara actual del Objeto 2.

La solución ha venido de la mano del libro "Real-Time Collision Detection", del cual ya puedo decir que ha merecido la pena el dinero invertido aunque sólo sea por esto (no obstante, espero tener más razones aún en el futuro). :P

Como preliminares:

1) Volví a repasar algo el tema de vectores, recordando un elemento clave: un vector representa una magnitud, dirección y sentido... pero NO posee dirección.

2) Volví a ver las ecuaciones del plano, y las propiedades asociadas a dichas ecuaciones.

A partir de aquí, lo ví claro: lo que verdaderamente se estaba haciendo NO era proyectar sobre las normales... sino hallar el punto más cercano de cada vértice del Bounding Box del Objeto 1 a cada una de las caras del Bounding Box del Objeto 2, tratando dichas caras como planos mediante la ecuación del plano:

n · X - d = 0, siendo:

--> · la operación Producto Escalar,
--> n, la normal de la cara actual del Objeto 2,
--> d = n · P, tal que P sea un punto perteneciente a la cara actual del Objeto 2.

Dicho punto más cercano, si prefiere verse así, puede verse directamente como la proyección del
vértice actual del Bounding Box del Objeto 1 sobre la cara actual del Bounding Box del Objeto 2.

Desde aquí:

-Si a dicho punto más cercano lo llamamos R y al vértice actual del Bounding Box del Objeto 1 lo llamamos Q,

-Y si tenemos en cuenta que las normales de los Boundings van a estar normalizadas...

... la cosa queda así: R = Q - [(n · Q) - d]n <-- Esta es la citada resta, ahora sí teniendo sentido, que comentaba más arriba; esto es lo que verdaderamente se hace en la demo.

Y ahora sí: una vez hallado ese punto más cercano a Q, R (o esa proyección de Q, R, si prefieres verlo así), se comprueba que se encuentra dentro de los límites de la cara actual del Bounding Box del Objeto 2; si lo está, se puede decir "con la boca pequeña" que ambos objetos están colisionando; si no, debe proseguirse con el análisis.

Pues ya quedan poquitas cosas de las que quería ver de esta demo. Tengo que ponerme a realizar un recuento de objetivos a realizar para Super Pong.

Por cierto, todo esto me ha dado una idea acerca de algo que tenía ganas de hacerle: poder proyectar puntos, líneas o algo así desde la posición de la pelota hacía las paredes del recinto para que el jugador pueda hacerse una mejor idea sobre la distancia a la que se encuentra la pelota de la raqueta, que dada la cámara a veces no sabes muy bién dónde está.

Hasta otra. :P

Edición Española de RUNAWAY: A Twist of Fate

music: JMM -"My Dear Tula"- / HIS HAIRCUT -"Cultural"-

El pasado 25 de marzo salío a la venta la Edición Española de Runaway: A Twist of Fate, ¡¡¡al fin!!!.

Espero que aquellos que lo jugueis os guste. Los que hemos participado en la creación de este juego hemos dado lo mejor de nosotros para que ello sea así. : )

Por mi parte ya he conseguido ambas ediciones -single y trilogía- y dejo por aquí algunas fotillos que les he hecho, junto con la camiseta de promoción, como hice con la versión alemana; la versión francesa es practicamente igual a la versión single española.

Me gustaría ver las Ediciones Checa y China; la primera, por si tiene un diseño de caja tan... digamos "espectacular"... como en las entregas anteriores de la saga. Y la China... porque tiene que ser el despiporre escuchar a los personajes en chino -no sé si mandarín ó cantonés-. Pero aún no sé nada de dichas versiones.

Y de la edición en habla inglesa... bueno, si nos fiamos de Gamespot parece ser que se pondrá a la venta en mayo. ¡En fín, a esperar un poquito más, jeje...!.

Hasta otra. :P