Apareció hace unas semanas un test al que se sometía a varios LLM's, consistente en pedir que creasen una rutina en Python que modelase una pelotilla rebotando por dentro de las paredes de un cuadrado que rota. Por lo visto solo Grok 3 dio una solución correcta, los demás modelos no detectaban bien las colisiones y la pelota se salía del cuadrado o hacía cosas raras.

update_position()
: "write an R function that updates the position of a particle located at (xp,yp) moving in the direction phi, travelling a distance of D". La usamos para situar la bola en cada frame.rotate_point()
: "write an R function that calculates the rotation of a point (xp,yp) around the origin (0,0) by an amount of theta radians". La usamos para rotar el cuadrado rotando sus cuatro vértices.distance_to_line()
: "write an R function that calculates the distance between a point (xp,yp) and the line defined by points (x0,y0) and (x1,y1)". La usamos para la detección de colisiones con los lados del cuadrado (colisión = la bola está más cerca de alguno de los lados que su radio).specular_bounce()
: "write an R function that calculates the new moving direction of a particle currently moving in the direction defined by phi radians, after a collision with a line defined by points (x0,y0) and (x1,y1) assuming a specular bounce on the line". La usamos para calcular la nueva dirección de movimiento de la bola tras cada rebote (colisión).
Analizado en profundidad, hacer bien el ejercicio tiene más intríngulis de lo que podría pensarse porque hay una discordancia entre el mundo geométrico perfecto, donde una pelota choca contra una recta justo cuando su centro está a un radio de distancia de la misma, y la traducción a una animación donde dicha pelota puede moverse a saltos discretos de varios píxeles en cada frame, lo que complica detectar y tratar con precisión las colisiones.
Si nos fijamos en la animación previa, en ocasiones la bola llega a atravesar ligeramente las paredes del cuadrado antes de rebotar, precisamente debido a que las colisiones se detectan después de dibujarla y la bola avanza varios píxeles en cada frame. Para solucionarlo se me ocurren dos métodos:
- Predetección de colisiones: detectar las colisiones antes de dibujar la bola, y entonces descomponer su próximo avance en dos partes: un tramo inicial de
a
píxeles en la dirección de movimiento actual, más un segundo tramo deA
píxeles en la nueva dirección tras el rebote. La suma dea + A = D
píxeles es la distancia total en píxeles que la bola debe avanzar tras cada frame.
- Sobremuestreo: consiste en usar el método original, pero sobremuestreando en los cálculos el movimiento de la bola de modo que cada avance de la misma (en teoría más el posible movimiento de paredes del cuadrado) no supere 1 píxel de desplazamiento. En la animación final solo 1 de cada N frames serán dibujados para atender a los fps finales buscados, pero en ellos la bola ya nunca traspasará los límites del cuadrado.
Repositorio con el código R: GitHub.
No hay comentarios:
Publicar un comentario
Por claridad del blog, por favor trata de utilizar una sintaxis lo más correcta posible y no abusar del uso de emoticonos, mayúsculas y similares.