Colisiones Modelos

[misscelan]

 
Cargo mis modelos del mikshape (debería cambiar de programa pero ya lo haré en un momento que no esté metido hasta el cuello).

Ahora estoy pensando en como podría saber en que momento colisiona un objeto con mi modelo (por ejemplo un disparo).

Calcular la trayectoria del disparo y comprobar si colisiona con cada plano del modelo como que no. Supongo que la solución está creando "bounding boxes" o como se diga el plural para cada parte del cuerpo (cabeza, tronco, brazo, etc...).

El problemas es que con milkshape no veo una forma limpia de hacer esto. Lo único que se me ocurre es crear el mismo modelo con los BB y el mismo esqueleto asociado, luego a la hora de cargarlo únicamente cargo los vértices de las BB y lo incluyo con los procedimientos donde creaba las animaciones del antiguo para que que adopte las mimas posiciones al animarse y luego comprobar las colisiones sólo con esto que serán mu pocos planos a comprobar.

Pero me suena un poco chapuza...

Muchas gracias.

Un saludo.

[AK47]

 Saludos
Esto es sólo una idea que tengo en mente: se podría, en tiempo de carga del modelo, recorrer cada hueso y conseguir los vértices asociado a él. Después calculas el boundig box de todos estos vértices. Así ya tendrías una jerarquía de cajas que siguen a los huesos para hacer las colisiones.
Ya te digo que no lo he probado, pero pienso usarlo cuando me llegue el momento (a ver si llego pronto :D)

[misscelan]

 Buenas...

Es parecido a lo que te estoy diciendo yo. A mi me interesa antes de que esté claro que lo haga rápido.

La diferencia es que tu dices que por cada iteración crear los BB yo te digo traerlos cargados y en cada iteración multiplicarlos por el esqueleto del modelo original para obtener la nueva posición.

La verdad no sé cual será más rápido. Me tocará probarlo. O bueno si lo pruebas antes coméntalo por aquí.  (ole)

Muchas gracias.

Un saludo.

[Haddd]

 El problema es más complejo de lo que piensas. El tema de colisiones entre objetos es realmente complejo. Los objetos pueden tener velocidad, con lo cual no basta comprobar si situación en el frame, sino hay que comprobarlo entre los dos frames, además si lo quieres "preciso", me parece que estás en uno de los grandes temas de los motores 3D.

Mírate las librerías de colision, creo que es RAPID. Te lo digo pq no es nada trivial, y ya hay cosas hechas, que suele ser mucho mejor implementar que empezar desde 0.

[misscelan]

 Ya sabes... la ignorancia es osada.

Mi idea es principalmente para los disparos. Y aunque los disparos son proyectiles que avanzan. Los trataré como una recta infinita que durará una iteración (mientras la compruebo con los BB del modelo)

Y todas maneras necesitaré los BB haga lo que haga no?

Un saludo.

[AK47]

 Hombre, si quieres colisionar en base a "sopa de poligonos" puedes usar el OPCODE. Yo lo uso y es muy rápido. La pega que tiene es que no está pensado para mallas deformables, como puede ser una persona.
Si lo que quieres es detectar colisiones entre personas y balas, puedes usar la jerarquía de cajas que te he comentado (donde cada hueso tiene su oriented bounding box). Creo que Half Life (el 1) lo hace así. Además, siempre puedes comprobar la bala contra los polígonos que pertenezcan a la caja en cuestión, si quieres más precisión.

En todo caso, como ha dicho Haddd el tema de colisiones no se reduce a "como calculo la colisión entre una caja y una linea", sino que es mucho más complejo ya que hay que controlar que los objetos no se traspasen, entren unos dentro de otros y un largo etcétera. Por ejemplo está el típico problema de no detectar la colisión entre 2 objetos con velocidades relativas elevadas, como un proyectil y una casa. Si sólo compruebas que ambos cuerpos colisionan o no después de moverlos, es posible (muy posible) que no detectes ninguna colisión cuando si debiera darse. La bala viaja a tal velocidad que recorre mucha distancia entre frame y frame, y si en el frame n estaba delante de la casa, en el frame + 1 es posible que este detrás, por lo que tu juego le parece una puta mierda al jugador. Y no es broma  :ph34r:

Una cosa más: yo no digo que calcules los BB en cada iteración (¡en absoluto! XD) sino calcularlos en tiempo de carga y luego transformarlos con el hueso correspondiente cuando animas al personaje. Asi tendras un personaje "tosco" de cara a las colisiones bala-personaje. Creo que el problema de esta aproximación es cómo calcular los BB de una forma optima o aceptable. Animarlos para que adopten la postura del personaje es facil  :)

[Parzival]

 Yo había hecho un sistema de colisiones con balas para 2d bastante chulo, que iba bien aunque le bajaras el frame rate.

Sólo había que conseguir un par de cosillas:

1.- Conseguir el vector de la bala una vez disparada.
2.- Guardar la posición desde donde se ejecutó el disparo.
3.- Ver si la bala ha superado la posición del jugador (antes de dibujar la bala).
4.- Si la bala está dentro del jugador (desde el centro miro si está dentro de un radio), destruir la bala y aplicar lo que sea necesario
5.- Si la bala está detrás del jugador mirar si debería pasar por la posicón del jugador (más bien si está dentro del radio) ayudándote del vector que calculaste antes, si es así destruir la bala y aplicar lo que sea necesario.

En un juego en 3D se podría aplicar este funcionamiento, sólamente tendrías que calcular un vector de 3 dimensiones (x, y, z), sólo que las zonas de colisión serían esféricas y para modelos esbeltos es un pequeño problema ^_^.

[tiutiu]

 Creo que no es necesario usar BB para cada hueso (vertices asociados a el). Colisionar mallas dinamicas ya es de por si chungo como para encima hacerlo con objetos animados.
Yo optaria por usar BV primitivos (capsulas, elipsoides o cilindros) para colisiones entre objetos dinamicos, y contra triangulo o convex hull para los estaticos.
El tema de los tiros se puede solucionar con una jerarquia de BVs para saber en que parte ha tocado la bala.
Ahi quizas si seria bueno usar un BB por hueso (u otra primitiva) para hacer intersecciones con un rayo.

[misscelan]

 Necesito rescartar este hilo...

Estuve dándole algunas vueltas más al tema.

Creo que al final haré un BB tipo caja para contener todo el modelo y después otro con el modelo definido de la forma más simple posible asociado a los huesos que animen el modelo original.

Trabajo con mapas BSP del Q3 así que de una rápida pasada me puedo quitar de encima todos los modelos que no vea comprobando la colisión del rayo con el primer BB.

Después si ha colisionado con el primer BB lo comprobaría con el segundo (el del modelo simple). Triángulo a triángulo....

Para la colisión de triángulos he visto este método
http://www.sorgonet.com/collaborations/3dc...ndetection.html. Que crea una pirámide entre el punto origen y el triángulo si está dentro luego prueba la colisón como si de un plano normal se tratase. El problema que le veo a este método es que a penas puedo tener nada precalculado y hay bastantes operaciones. ¿Qué más métodos conocéis para hacer esto?.

Al final haré algo parecido a esto:

Código [Seleccionar] Expand


 Bucle desde 0 hasta número de modelos
 Inicio
    Si el modelo está en un cluster visible desde el mío
    Inicio
      Si el vector colisiona con el primer BB
      Inicio
        Bucle desde 0 hasta número de triángulos del modelo
        Inicio
          Si el triángulo está de cara
          Inicio
             Si Comprobar colisión con método pirámide
             Inicio
               Si el punto obtenido está más cerca que el anterior lo Guardamos
             Fin
          Fin  
        Fin
      Fin
    Fin
 Fin


Más que aceptar sugerencias se necesitan.

Muchas gracias.

Un saludo.

[Federico1245]

En todo caso, como ha dicho Haddd el tema de colisiones no se reduce a "como calculo la colisión entre una caja y una linea", sino que es mucho más complejo ya que hay que controlar que los objetos no se traspasen, entren unos dentro de otros y un largo etcétera. Por ejemplo está el típico problema de no detectar la colisión entre 2 objetos con velocidades relativas elevadas, como un proyectil y una casa. Si sólo compruebas que ambos cuerpos colisionan o no después de moverlos, es posible (muy posible) que no detectes ninguna colisión cuando si debiera darse. La bala viaja a tal velocidad que recorre mucha distancia entre frame y frame, y si en el frame n estaba delante de la casa, en el frame + 1 es posible que este detrás, por lo que tu juego le parece una puta mierda al jugador. Y no es broma  :ph34r:

Yo se un poco de programar pero nada de programacion grafica pero quiero aportar una idea que no si es posible pero bastante util si se puede hacer, alguien dijo que si por ej un proyectil se acerca a una casa, en un frame esta por llegar y en el siguiente ya la paso, osea en ningun momento tuvo contacto con la casa, pero para comprobar que el contacto estubo puede hacerce estableciendo una linea entre el proyectil del primer frame y del segundo, esta linea marcaria el recorrido, y si esta linea tiene contacto con la casa el proyectil tambien lo tuvo.
Les recurdo que no se nada de programacion grafica, solo quiero dar esta idea de algo que mas o menos pude entender.