Cómo QuickFigen simula física desde un grafo, sin plantillas

Hay dos pedidos que se repiten en los prompts que recibe QuickFigen. Uno, casi textual: "¿cómo hago que se mueva solo?". El otro, de un docente que armó su escena paso a paso: "agregar el cálculo de la fricción usando sumatoria de fuerzas, bien detallado".

Parecen pedidos distintos. Uno quiere animación; el otro quiere un desarrollo con números. Pero por dentro son el mismo pedido: que el diagrama sepa física, no solo que la dibuje.

En este post cuento cómo resolvimos eso. La idea central cabe en una frase: la escena que un docente arma en el editor ya tiene la forma que necesita un motor de física para trabajar. No hay que reconocer el problema ni buscarle una fórmula. Hay que leer lo que se dibujó.

Dos caminos que no tomé

Cuando decidí que las escenas de QuickFigen tenían que moverse y calcular, había dos caminos conocidos.

El primero es usar un motor de juego. Son los motores que mueven las cosas en los videojuegos y en sandboxes como Algodoo. Funcionan por pasos: muchas veces por segundo calculan una aproximación de dónde estará cada cuerpo un instante después, corrigen los choques, y siguen. Son extraordinarios para lo suyo. Pero el número que producen es una aproximación que cambia según el tamaño del paso, y a veces tiembla. En un aula, la tensión de la cuerda no es un valor cercano a algo: es una conclusión. Si el libro dice que la tensión vale dos tercios del peso, el diagrama tiene que decir exactamente eso.

El segundo es una biblioteca de casos. Detectar que la escena "es una máquina de Atwood" y aplicar la fórmula de la máquina de Atwood; detectar que "es un plano inclinado con polea" y aplicar la suya. Es la solución que uno escribe primero, y la que se rompe primero. La lista de casos es finita, la detección falla en cuanto el docente agrega un tercer bloque o inclina la mesa, y cada variante nueva es código nuevo.

QuickFigen no hace ninguna de las dos cosas.

Un grafo es una red de cuerpos y vínculos

Un grafo, en el sentido matemático, es una red: puntos unidos por enlaces. En un mapa de rutas, los puntos son ciudades y los enlaces son carreteras. En una escena de física, los puntos son los cuerpos y los soportes, y los enlaces son los vínculos físicos entre ellos: este bloque se apoya sobre esa rampa; esta cuerda está atada a aquel bloque y pasa por esa polea; la polea está fijada al techo.

Lo importante es que esa red ya existe en QuickFigen desde antes de la simulación. En un post anterior conté que una escena no es una imagen sino un archivo estructurado que describe cada objeto y cómo se relaciona con los demás. Esas relaciones son los enlaces del grafo. Cuando arrastras un bloque hasta que se asienta en la rampa, o atas una cuerda a su cara superior, no estás decorando un dibujo: estás escribiendo un vínculo.

Cómo se resuelve un grafo

Aquí está el truco, y es más simple de lo que parece.

Cada cuerpo con masa aporta una ecuación: la segunda ley de Newton, la suma de fuerzas es igual a la masa por la aceleración. Cada vínculo aporta otra: una cuerda inextensible obliga a que sus dos extremos avancen lo mismo; un apoyo obliga a que el cuerpo no atraviese la superficie. Las incógnitas son las aceleraciones de los cuerpos y las fuerzas que los vínculos ejercen: la tensión de cada cuerda, la normal de cada apoyo.

Con eso queda un sistema de ecuaciones lineales. Se resuelve de una vez, con álgebra, y devuelve todas las incógnitas a la vez y con exactitud.

Tomemos la máquina de Atwood de la figura, con bloques de 5 kg y 3 kg. Dos ecuaciones de Newton, una por bloque. Una ecuación de cuerda: los dos bloques aceleran igual, uno hacia arriba y otro hacia abajo, y la tensión es la misma en ambos extremos. Tres ecuaciones, tres incógnitas. El sistema devuelve una aceleración de 2,45 m/s², que es un cuarto de g, y una tensión de 36,8 N.

En ninguna línea de ese procedimiento aparece la palabra Atwood. El motor no supo que estaba resolviendo una máquina de Atwood. Vio dos cuerpos con masa, un vínculo entre ellos, y escribió las ecuaciones que ese grafo pedía. Con el mismo procedimiento resuelve la mesa con polea y masa colgante, donde un bloque de masa m sobre una mesa sin fricción es tirado por otro de masa 2m que cuelga: la aceleración es dos tercios de g y la tensión es 2mg/3, el resultado de libro. Y resuelve el plano inclinado con colgante, o dos poleas, o un bloque tirado por dos cuerdas. Nadie tuvo que enumerar esos casos.

Probar en vivointeractivo

QuickFigen

Hay un detalle que a los docentes les gusta. Cuando una cuerda tira de un bloque apoyado en una dirección que no es la de la superficie, por ejemplo desde un punto fijo, en diagonal, la tensión se descompone sola. No hay una regla que diga "proyecta sobre el plano": la tensión entra al sistema como un vector con su dirección, la ecuación del apoyo pide que el bloque no se despegue, y el álgebra reparte lo que va a lo largo de la superficie y lo que va contra ella. La normal sale ajustada por esa componente, como en el pizarrón.

La polea es la excepción, y aprendimos por qué a los golpes. Al principio el motor leía del dibujo la dirección de cada tramo de cuerda, también cuando la cuerda pasaba por una polea. Los tramos salen casi rectos, así que parecía inofensivo. Pero el residuo rompía una identidad, no un decimal: con una cuerda inextensible los dos cuerpos tienen que acelerar con el mismo módulo, y salían 3,9204 y 3,9026 m/s². El sistema que se resolvía no era el que se había dibujado. Hoy una cuerda que pasa por una polea se trata como lo que es, una máquina: el tramo del cuerpo apoyado sigue la superficie y el que cuelga cae vertical, aunque el trazo esté un poco torcido. Y el motor lo avisa, porque es una regla suya y no algo que el docente escribió.

Las islas

Cuando una escena tiene varios sistemas a la vez, el grafo también lo dice. Dos bloques apoyados sobre la misma mesa no se tocan entre sí: la mesa es fija y no lleva la fuerza de uno al otro. En el grafo son dos componentes separadas, y el motor resuelve cada una por su cuenta. Las llamamos islas. Un bloque de una isla no se entera de lo que pasa en la otra, y la energía del sistema se calcula por isla, no por escena.

No es una idea nuestra. Box2D, el motor de física que hay detrás de muchísimos juegos en dos dimensiones, agrupa los cuerpos en simulation islands con este mismo criterio y las resuelve por separado. Cuando una idea aparece por las mismas razones en un motor de juegos y en una herramienta para docentes, suele ser señal de que es la idea correcta.

Lo que se suelta y lo que se afloja

Hay un tipo de vínculo que el álgebra sola no sabe manejar: el que solo funciona en un sentido. Una superficie empuja hacia afuera, pero no tira. Una cuerda tira, pero no empuja. Si el sistema de ecuaciones devuelve una normal negativa, eso significa que la superficie tendría que estar tirando del bloque, y eso es imposible: el bloque, en realidad, se despegó. Si devuelve una tensión negativa, la cuerda tendría que estar empujando: en realidad se aflojó.

El motor resuelve esto probando. Para cada vínculo de un solo sentido considera las dos posibilidades, activo o suelto, resuelve el sistema con cada combinación y se queda con la única que es consistente: normales y tensiones positivas, y ningún cuerpo atravesando nada. En una escena escolar hay tres o cuatro de esos vínculos, así que probar todas las combinaciones es barato. Este problema tiene nombre en la literatura, complementariedad lineal, y una solución clásica de David Baraff de 1994 para escenas con cientos de contactos. La nuestra es la versión de bolsillo, suficiente para un aula.

Lo interesante es que esas mismas pruebas son las que hacen posible el movimiento.

De la foto al movimiento

Resolver el grafo da la aceleración de cada cuerpo en la configuración actual. Para que la escena se mueva hace falta algo más: saber cuánto dura esa situación y qué viene después.

Aquí conviene ser honesto con los límites de la idea. Mientras los vínculos no cambian, la aceleración es constante, y un movimiento con aceleración constante tiene fórmula exacta. Eso vale para un bloque que baja por una rampa recta, una Atwood, una mesa con polea. En esas situaciones el motor no aproxima nada: calcula la posición en cada instante con la fórmula, y el número que ves en pantalla es el que sale del álgebra.

Lo que cambia son los vínculos. El bloque llega al final de la rampa y deja de tener apoyo. La cuerda se afloja. La esfera que salió volando toca el piso. Cada uno de esos momentos es un evento, y el motor los detecta con exactitud, no mirando cuadro a cuadro si "parece" que algo pasó. Cuando se acaba el apoyo, el cuerpo sigue como proyectil con la velocidad que traía, tangente a la superficie; la energía mecánica cruza ese instante sin un salto, y lo comprobamos en los tests con una tolerancia de una millonésima de joule. Cuando un cuerpo aterriza se queda donde cayó, y los demás siguen su vuelo.

Así, una simulación es una secuencia de fases, cada una gobernada por un modelo exacto, unidas por eventos que las conmutan. Esa forma de pensar tampoco es nuestra: en la teoría de sistemas se llama autómata híbrido, y lenguajes de modelado como Modelica llevan décadas expresando la física como ecuaciones que se conectan y eventos que cambian de régimen. Lo que hicimos fue traer esa estructura al tamaño de un problema de secundaria, donde cada fase cabe en una fórmula que el estudiante conoce.

De dónde viene la idea, y qué es nuestro

Vale la pena decirlo con claridad, porque un lector técnico lo va a notar: el grafo de cuerpos y vínculos es la base de casi toda simulación física seria, no una invención de QuickFigen.

• Box2D resuelve por islas, como conté arriba.
• David Baraff mostró en 1996 cómo plantear la dinámica con multiplicadores de Lagrange sobre el grafo de vínculos, y cómo resolverla en tiempo lineal cuando el grafo no tiene ciclos. Nuestro solver es esa formulación, con las incógnitas de siempre: aceleraciones, tensiones y normales.
• Modelica y las herramientas de modelado acausal dejan que el usuario conecte componentes y que el compilador arme el sistema de ecuaciones, con eventos incluidos.
• Algodoo, desde 2009, permite construir libremente y simular, con un solver iterativo.

Lo que sí es una decisión nuestra son tres cosas, y las tres vienen de pensar en el aula.

La estructura viene escrita por el docente. Un motor de juego tiene que descubrir qué toca qué, en cada cuadro, con detección de colisiones. Es la parte más cara y más frágil. En QuickFigen el docente ya dijo que el bloque se apoya en la rampa y que la cuerda pasa por la polea, sea arrastrando en el editor, escribiendo un prompt o con una línea del lenguaje de escenas. El motor no detecta nada: lee.

Se resuelve exacto, no se itera. Porque la estructura es conocida y las fases son simples, podemos permitirnos el álgebra en lugar de la aproximación. El precio es que no todo entra, y de eso hablo enseguida.

El motor dice lo que supone. Cada idealización que aplica sale escrita en el panel de información de la reproducción: que las cuerdas no tienen masa, que las poleas son ideales, qué eje usa para cada tramo de cuerda y cuándo idealiza la máquina en lugar de leer el trazo, y qué hace cuando una superficie se acaba. Un número exacto calculado sobre una suposición que nadie ve es peor que no dar el número, porque nadie puede revisarlo.

Lo que el grafo no sabe todavía

Esta es una primera versión, y prefiero que los límites estén a la vista antes de que alguien los descubra en clase.

• Fricción. El solver todavía resuelve el caso sin rozamiento. Si la escena declara un coeficiente de fricción, la reproducción se rechaza con esa razón, porque reproducirla como si no lo tuviera daría un movimiento creíble y falso. Es la ampliación siguiente.
• Pilas de cuerpos. Un bloque sobre otro bloque es un contacto contra algo que también acelera. Hoy el contacto del solver es contra superficies fijas.
• Resortes. Su fuerza depende del estiramiento en metros, y eso pide una escala de la escena que recién estamos incorporando.
• Superficies curvas. En un tramo curvo hace falta el término centrípeto. Las rampas rectas y las esquinas entre tramos rectos sí funcionan.
• Péndulos y oscilaciones. El grafo cubre la familia lineal. Un péndulo o un bloque con resorte tienen fórmula cerrada propia; entrarán como fases exactas del mismo autómata, no como excepciones.
• Choques. Los cuerpos no chocan entre sí ni con la polea, porque la estructura viene escrita y el motor no detecta contactos nuevos. En una Atwood que corre demasiado tiempo, el bloque que sube llega a la polea y la atraviesa. Lo que sí detecta es el aterrizaje sobre una superficie y la salida del lienzo, y ahí se detiene.

Por qué esto importa en el aula

Un docente no prepara un problema una sola vez. Lo varía: cambia una masa, inclina la mesa, agrega un bloque, pregunta qué pasa si la cuerda se corta. Con una biblioteca de casos, cada variante es una petición nueva a alguien que programe. Con un grafo, la variante es un cambio en el dibujo, y el motor vuelve a leer.

Y el número que aparece es el mismo que el estudiante va a calcular en su cuaderno, porque salió del mismo procedimiento: escribir Newton para cada cuerpo, una ecuación por vínculo, resolver. Esa coincidencia, entre lo que hace el motor y lo que enseñamos, es lo que me convenció de que valía la pena el camino largo.