Problemas Con Colisiónes Aabb/triángulo

[ALBSIM]

 Hola, tengo un problema que por mas que le doy vueltas no consigo solucionar. Estoy implementando la detección de colisiones entre un objeto móvil (representado por una AABB) y el escenario (todos los polígonos son triángulos). Sigo el método descrito en el libro '3D GAMES Vol. 2', y parece que todo funciona bien hasta que encuentro zonas del tipo:
             
             1

!Menudos dibujos, estoy hecho un artista!. En estos casos, normalmente detecta la siguiente colisión, pero si sigo insistiendo en la misma dirección acabo traspasando el plano:


             2

Imagino que es debido a errores de precisión en el redondeo de los floats, pero quizás sea un error en mi código (que al final va a ser eso ya verás). Bueno si alguien sabe porqué puede pasar ésto que me eche un cable por favor. Otro tema es que una vez la caja penetra al polígono, el algoritmo no lo detecta, ¿cuál podría ser una forma óptima de hacerlo? Así podría volver a la posición anterior y evitar estos errores.
¿Conocéis algún tutorial o código en internet aparte del mencionado sobre este tipo de colis.?
Gracias.
¿Hey, porque leches no puedo meter imágenes en el mensaje?

[Mars Attacks]

 Sobre lo primero, con el Blast también nos pasaba y creo que se solucionó aumentando el número de veces por frame que se calculaban las físicas (Drakkar te lo dirá mejor).

Sobre lo segundo, creo que es porque las direcciones deben ser del tipo http://www.loquesea y la tuya es http://be.sierra.eresmas.net/1.bmp

Un saludín.

[ALBSIM]

  Vale, gracias tío, voy a probarlo porque ya no se que hacer con las puñeteras detec. de colis.

[Mars Attacks]

 De todas formas, yo sólo soy el "grafista". Espérate a que pasen por aquí programatas de verdad XD

[ALBSIM]

  Bueno pero aun así me das mil vueltas como programador eso seguro.

[ALBSIM]

  Vale, en mi código, como utilizo GLUT, la función que la pasaba como arg. a glutIdle se encargaba de calc. los FPS, actualizar las pos, realizar la detec. de colis. y renderizar la escena.
Ahora 1º he intentado renderizar la escena sólo cada 20ms. y así no perdería tanto tiempo en cada loop del juego, pero no ha servído de nada.
Luego se me ha ocurrido la siguiente chapuza: cada vez que voy a detectar las colisiones, si he calculado que ha transcurrido x tiempo desde el último test, entro e un bucle de, digamos 10 iteraciones, por ejemp., y llamo a la función de colisiones con tiempo x/10, así realizo 10 cálculos de colisiones con vectores de desplazamiento 10 veces menores, esto parece solucionar el error, pero imagino que es correcto, porque ahora, al deslizar por una parez, el programa lo hace de forma mas lenta y a trompicones (quizás también pueda ser por el mayor nº de cálculos que realizo).
 Ayuda por favor, que soy un negao y estoy desesperao (estoy a punto de tirar el ordenador por la ventana)

[Mars Attacks]

 Si la tarjeta gráfica es buena, mándamela antes de tirarlo. La pantalla también quédatela porque te puede servir para el que venga después.

Sobre las colisiones, paciénciate un poco. No sería mala idea que alguien se currara el COTW sobre este tema con el que todos chocan (qué ironía).

Y yo de programador nanai. Mis "personajes" siempre se mueven por una matriz virtual de unos y ceros, así que no he tenido problemas ni con el comeagers ni con el mataterrestres  B)  

[DraKKaR]

 Es muy difícil saber a ciencia cierta cuál es el problema así de palabra. El problema que tenia yo no era el mismo creo, mi problema es que en ordenadores lentos las físicas se calculaban con valores "demasiado grandes" y daban resultados erroneos... para resolverlo lo que hice fue lo que ha dicho Mars: calcular varias veces las fisicas para tiempos menores.
Si nos pone sun poco de código o algún pseudocódigo tal vez pillemos el fallo...

[ALBSIM]

  Como mi código es una guarrada ¡está en c! (Si, si, yo también he dao ingeniería del SW y se las ventajas de la POO, pero es que lo empecé antes de aprender C++, y como soy tan vago, por no cambiarlo todo...), pues mejor pongo algo de pseudocódigo, además, las funciones son grandes y no quiero quitaros mucho tiempo, tendréis cosas mejores que hacer. Bueno como he dicho antes, lo he resuelto de una forma que no se si es la correcta:

// En el loop principal del juego llamo a la func. ActualizaSistema

glutIdleFunc(ActualizaSistema);

//...

funcion ActualizaSistema ()
{
      tSeg <- tiempo transcurrido desde la última llamada

     Obtengo la entrada por teclado y ratón (acelreac. de la cámara, rotaciones de la cámara...)

     Roto la cámara según el ratón

     // Aquí está la chapucilla

     // Lo del 5 es temporal, debería ser una variable que se ajuste a una frecuencia fija para el cálculo de
     // colisiones, o que dependiese de la longitud del vector desplazamiento que se utilizará para las colis.

     FraccionT=tSeg/5.0f;

     para f<-0 hasta 5 hacer
     {
             // Calculo fracciones de tiempo menores, con lo que el vector de
             // desplazamiento (S = S0 + v0*t + .5 * a *  t*t)  que se calculará en la func. mueveCamara
             // será menor y evitaré los problemas de colis.

             // Aquí llamo a la función que mueve la cámara. y lo hace de forma que respete las colis.

             //                         tiempo,  gravedad ON, tipo de colis (AABB/Tri)
   
             mueveCamara(FraccionT,  GRAVIDEZ     , AABB_COLIS);

      }
   
      Calculamos FPS

      Renderizamos la escena
}

Así parece que funciona y no atraviesa ningún polig. pero como he dicho antes, no se comporta igual: en las colis. parece que se ralentiza algo. No se si es porque esto que hago es erróneo, o porque al calcular mas colisiones aplico mayor nº de veces la fuerza de rozam. o porque sobrecargo la CPU con tantas llamadas y calculos en la función de colis.
Bueno y en relación con lo del 5 temporal en FraccionT y el bucle: es mejor que sea un frecuencia cte. y calculemos el nº de iteraciones según el tiempo transcurrido, o por el contrario es mejor calcular la distancia a recorrer en este frame, y según su módulo, calcular el nº de loops (porque lo que realmente afecta a la eficacia de los cálculos son los vectores velocidad extremadamente grandes ¿no?)

[tiutiu]

 Ten en cuenta que ahora llamas 5 veces mas a la funcion de colisiones, que cuando vas sin colisionar no lo notas pq no hay colision y se sale, pero cuando la hay pues la calcula una sola vez.

Yo usaba elipsoides para las colisiones (casi igual q una esfera, simplemente hay 2 divisones mas xD) y al principio tb tenia ese problema, aunq mejore un monton el algoritmo y luego iba d pm. Para que no te atraviese ni t de 'golpes' con timesteps grandes lo que debes hacer es mas o menos lo siguiente (lo digo de memoria, no tengo el algoritmo delante):
-Calcular el punto de interseccion en el triangulo.
-Si la esfera ha atravesado ese punto pues la hacemos retroceder hasta el pto. d interseccion, asi nos aseguramos que nunca pasara de ese punto.

Supongo q no sera muy complicado pasar ese codigo para aabb

[ALBSIM]

  Si eso es lo que yo pensaba, gracias. Yo no detecto si la caja ha atravesado el pto. pero ahora mismo me pongo con ello, (imagino que me valdrán las funciones que utilizo a la hora de crear el OCTREE y ver si el polig. está o no en el cubo del nodo del octree)  aunque me temo que testear si un polígono cae dentro de una caja total o parcialmente no es un algoritmo muy rápido, al contrario que con la esfera, que si utilizas el método del tal 'telemachos' ese, es rápido y sencillo.  

[tiutiu]

 Por cierto, es un curro del copon testear contra todos los polys del escenario. Si es un interior utiliza BSP, si es exterior pues hay varias opciones: si usas un heightmap puedes calcular la altura en ese punto y darsela al personaje, asi no t atravesara el suelo. Si usas una malla compleja puessssss tonces no se me ocurre mucho q hacer xD

El otro dia me comentaron una cosilla para hacer mas eficientes las colisiones con el terreno: walkable meshes. Se trata de unos parches de terreno de muy baja resolucion que definen una zona por la cual puedes caminar del mapa. Esto te evita tener q probar con cientos o miles d triangulos, se pueden definir en un editor (o en max con gizmos o parches), puedes delimitar por donde puede correr el personaje (para q no salte en un precipicio, camine por el agua, etc...
Yo en mi terreno uso geomipmapping, asi que usare una version del terreno de baja resolucion para las colisiones (aunq supongo que implementare las WM pq es un invento d pm xD)

[ALBSIM]

  Yo utilizo un loose octree, calculo el volumen temporal de movimiento (una AABB que contiene al la AABB de la cámara en el inicio del test, y la AABB en la pos final), calculo el menor nodo del octree en el cual este volumen entra perfectamente, y mando todos los triángulos de dicho nodo a la función de detección de colisiones.
Lo de las walkable meshes es una gra idea, yo hago algo parecido en la colisión de superficies Bézier, ya que realizo los test con la menor resolución de la malla.