Sobre COLLISION

[panreyes]

Una pregunta para Splinter y otros experimentados...

¿Cómo funciona internamente la función COLLISION? Tengo entendido que primero se comprueban las distancias entre los gráficos de los procesos, teniendo en cuenta su ancho, alto, size, size_x, size_y, etc... Y si cabe la posibilidad de que los gráficos estén colisionando, luego se comprueba a nivel de pixel generando mapas de máscara para ver si se solapan, ¿cierto?

Me interesa sobre todo saber cómo funciona esa segunda parte, para ver si es posible optimizarla.

[SplinterGU]

si

[panreyes]

Perfecto. Ahora, ¿sería posible u óptimo hacer colisiones píxel perfect con menor resolución?
En vez de revisar píxel a píxel, revisar cada 2 o 4 píxeles. O que las máscaras de los gráficos fueran de un tamaño menor.

Esto sería muy útil cuando utilizamos resoluciones altas (tipo 1920x1080, por ejemplo) y queremos hacer comprobaciones de colisiones por píxel. En vez de que los gráficos comprobasen hasta esos 1920x1080, comprobarían 480x270 (1/4, por ejemplo). Las colisiones no serían tan exactas, pero conseguiríamos un rendimiento muy superior al que obtendríamos si utilizásemos los tamaños de los gráficos originales. Quizás sería necesario generar las máscaras de colisión escaladas por adelantado, lo cual tampoco sería mala idea.

La idea de todo esto es no deshacernos de las colisiones por píxel en los motores acelerados por GPU.

¿Qué opinas Splinter? :)

[Drumpi]

Yo creo que sería más óptimo implementar un sistema de colisiones alternativo, y que incluso se pudiera pasar al HW de la aceleradora gráfica, que ya incluye un sistema para eso.
Sería más o menos poder definir una serie de figuras, tipo rectángulos y círculos, que no se verían, pero que se les podrían pasar a la gráfica para cmprobar si hacen colisión. Un sistema más sencillo, que sólo tuviera en cuenta, en los rectángulos, el ancho, alto y la rotación, o en circunferencias sólo el radio. Algo similar a lo que tiene planteado Unity para las colisiones en 2D.

El collision actual me parece perfecto, y lo uso siempre, pero cuando me falta rendimiento, el collision_box no me soluciona el problema porque sigue teniendo demasiados parámetros de cálculo encima (x, y, z, angle, size, flags) y a veces pienso que "abs(x-target.x)<10 and abs(y-target.y)<5" en código Bennu es igual de lento que el propio collision.

No pido un capsule collider ni las chorrocientas cosas que trae Unity, porque para eso usaría un motor de físicas, pero el Echo en Wiz me ha hecho replantearme esto de la forma más eficiente, y no sé si vosotros lo veis igual o si teneis más información que podría ayudarnos a entenderlo mejor.

[SplinterGU]

Perfecto. Ahora, ¿sería posible u óptimo hacer colisiones píxel perfect con menor resolución?
En vez de revisar píxel a píxel, revisar cada 2 o 4 píxeles. O que las máscaras de los gráficos fueran de un tamaño menor.

Esto sería muy útil cuando utilizamos resoluciones altas (tipo 1920x1080, por ejemplo) y queremos hacer comprobaciones de colisiones por píxel. En vez de que los gráficos comprobasen hasta esos 1920x1080, comprobarían 480x270 (1/4, por ejemplo). Las colisiones no serían tan exactas, pero conseguiríamos un rendimiento muy superior al que obtendríamos si utilizásemos los tamaños de los gráficos originales. Quizás sería necesario generar las máscaras de colisión escaladas por adelantado, lo cual tampoco sería mala idea.

La idea de todo esto es no deshacernos de las colisiones por píxel en los motores acelerados por GPU.

¿Qué opinas Splinter? :)

a menos que la penetracion sea muy profunda, no se lograria mucha mejora.

podrias probar haciendo un vs, del normal y otro con graficos a 1/4 de tamaño.