Una grulla, cara a cara

Publicado el 24 de octubre de 2026

De pequeño me gustaba plegar papel, y la grulla era la figura que siempre acababa saliendo. Cuando quise una mascota para esta web, la elección era evidente; lo que no lo era tanto es cómo hacerla. Dibujar una grulla de polígonos a ojo es fácil y queda bien, pero no es una grulla de papel: no sale de una hoja. Así que la primera versión de la mascota era un dibujo, y este artículo cuenta cómo pasó a ser una hoja cuadrada plegada de verdad, cara a cara, y qué hizo falta para que el plegado no se rompiera por el camino.

Todo lo que aparece aquí funciona en el navegador. El plegado completo, con una barra para avanzar y retroceder, está en el laboratorio de plegado; la grulla resultante es la que vive en la esquina de la portada.

Los datos: una grulla en 24 instrucciones

No hacía falta inventar el patrón. Origami Odyssey, un proyecto abierto (licencia MIT) para aprender origami con modelos 3D, publica una grulla tradicional en un formato derivado de FOLD: una hoja cuadrada de lado 2 dividida en 76 vértices y 88 caras (48 cuadriláteros y 40 triángulos), y una secuencia de instrucciones que, aplanada, son 24 pasos: los pliegues guía, el colapso en la base preliminar, los pliegues de pétalo de la base del pájaro, el cuello, la cola, la cabeza y las alas.

Cada instrucción es una lista de aristas con un ángulo:

[19, 4, 1]    [11, 19, 1]    [21, 11, 1] …    ← «doblar por la mitad en vertical»

El ángulo es el diedro entre las dos caras que comparten la arista: 180 es la hoja plana; 0 y 360 son la arista plegada del todo, una en cada sentido (valle o monte); las alas se bajan con 110 y 250. Un paso solo dice qué aristas cambian y a qué ángulo; las demás se quedan como estaban. El estado de la hoja en el paso $k$ es, por tanto, el ángulo acumulado de las 163 aristas.

Caras rígidas y un recorrido

El motor de Origami Odyssey coloca los vértices uno a uno, rotando cada uno alrededor de la arista que acaba de plegarse y propagando el giro a los vecinos. Yo quería algo que además me dijera si el resultado tiene sentido, así que escribí un motor distinto, pequeño y sin dependencias.

La idea es tratar cada cara como una pieza rígida. Se fija una cara, la que contiene el centro de la hoja, y se recorre la hoja de cara en cara (en anchura). Cuando se pasa de una cara $i$ a su vecina $j$ por la arista común, la posición de $j$ es la de $i$ compuesta con un giro alrededor de esa arista, tomada en la hoja plana:

donde ${\hat{e}}_{ab}$ es la dirección de la arista y el signo depende de a qué lado de la arista queda la cara $j$. Con una transformación rígida por cara (un giro y una traslación), la posición de cualquier punto de la hoja sale de aplicar la de su cara a sus coordenadas planas.

La prueba: el error de cierre

Ese recorrido es un árbol: cada cara se coloca una sola vez, por un único camino. Pero la hoja no es un árbol. Un vértice interior pertenece a varias caras, y cada una lo coloca según el camino por el que se llegó a ella. Si los ángulos del paso son coherentes, todas esas copias coinciden. Si no, se separan.

Esa separación es una medida gratuita de si el plegado es posible. La llamo error de cierre: la mayor distancia entre las copias de un mismo vértice, en tanto por ciento del lado de la hoja. Un cero significa que la hoja cierra sin cortes; un 50 % significa que se ha roto.

El resultado fue mejor de lo que esperaba: los 25 estados (la hoja plana y los 24 pasos) cierran con un error de como mucho el 1,1 % (en el paso 18), y la grulla terminada, con el 0,55 %. Incluidos los dos pasos que el propio autor marca como «no mostrados» en su visor. Las coordenadas del fichero están redondeadas a tres decimales (0,293 en lugar de $1-\sqrt{2}/2=0,29289\dots$). Si sustituyo las doce que tienen un valor exacto evidente, el error máximo baja al 0,9 %; el resto de vértices son cruces de pliegues cuyo valor exacto no he reconstruido. El redondeo es la explicación más probable del error que queda, pero no la he demostrado.

Cuando la línea recta rompe la hoja

Los estados cierran, pero una animación también tiene que cerrar entre estados. Lo obvio es interpolar: si una arista pasa de 180° a 0°, a mitad de paso está a 90°. En 19 de los 24 pasos funciona. En cinco, la hoja se rompe a mitad de camino:

Los pasos 12 a 14 resultaron ser un problema de sentido, no de camino. Esa punta se dobla atravesando cuatro capas, y cada capa está girada respecto a la anterior. Para una arista plegada del todo, 0° y 360° dan exactamente la misma forma final, pero caminos opuestos: si una capa gira hacia arriba y la de al lado hacia abajo, a mitad de paso se atraviesan. Los 16 tramos de ese pliegue están acoplados, así que probar a darles la vuelta de uno en uno no encuentra la combinación buena. Probarlas todas sí: son $2^{16}=65536$, y la buena deja la hoja cerrada en todo momento (0,4 %).

El colapso y los pétalos son otra cosa: ahí los ángulos no avanzan en línea recta, sino coordinados. Al colapsar la base preliminar, los pliegues del centro se cierran a ritmos distintos según la geometría. Para esos pasos calculo de antemano una trayectoria: 32 fotogramas de ángulos que minimizan el error de cierre más un término que los mantiene cerca del avance lineal, para que el movimiento no se invente otro camino:

Se resuelve fotograma a fotograma con descenso por gradiente (numérico), empezando cada uno desde la solución del anterior. El resultado: 0,2 % en el colapso y 1,8–1,9 % en los pétalos, con saltos de menos de 10° entre fotogramas. Muestreando la animación igual que la reproduce el navegador, el peor cierre en todo el recorrido es el 1,96 %. El navegador no optimiza nada: solo interpola entre fotogramas ya comprobados.

Capas que no se atraviesan

Con todo cerrado, quedaba un problema visual. Cuando varias capas quedan en el mismo plano, el ordenador no sabe cuál dibujar delante y parpadean. La primera solución fue dejar los pliegues completos a 3° de cerrarse, para que las capas se separen en abanico. Pero cada solapa tiene su propia bisagra y su propio largo, y esos abanicos se cruzan: una parte de una capa asoma por encima de otra y el resto queda debajo.

La solución actual separa las dos cosas. La pose se dibuja exacta, sin margen, y en cada fotograma se buscan las caras que quedan en el mismo plano y se solapan. Para cada par, la pose con margen dice cuál queda encima junto a su bisagra, que es donde ese orden es fiable. Con esas relaciones se apilan las caras en niveles, separados un 0,2 % del lado, y el grosor total se limita al 0,6 % (algo menos de un milímetro en una hoja de 15 cm), como un papel de verdad. Dos caras vecinas de la misma capa no se apilan: el redondeo las hacía solaparse un pelo y, sin esa regla, la grulla terminada acumulaba 35 niveles y de canto parecían tres papeles.

No es un cálculo de colisiones: en algún sitio el orden podría salir al revés. Pero se vería como una capa encima de otra, no como un papel atravesando otro.

De la hoja a la mascota

La grulla de la portada es la pose final de ese motor. Un script toma el paso 24 con las capas apiladas, la pone de pie (con el pico, la cola y las puntas de las alas como referencias) y la parte por las bisagras de las propias instrucciones: cortar la hoja por las aristas del paso 23 separa un ala; por las del 24, la otra; por las del 20, el cuello; por las del 22, la cabeza dentro del cuello; por las del 21, la cola. Cada corte deja una pieza entera, con su esquina de la hoja: las alas son las esquinas 1 y 5, el pico la 3 y la cola la 7.

Cada pieza gira alrededor de su bisagra real, que es la recta de los vértices de sus pliegues. Así, cuando la grulla aletea, el ala pivota donde lo haría el papel; y cuando escucha, piensa o habla, es la cabeza la que se inclina sobre su propio pliegue invertido.

El resultado son 136 triángulos y 22,6 KB (unos 3 KB comprimidos), que se cargan solo cuando alguien abre la mascota. El botón de la portada es la misma geometría proyectada a un SVG de 6 KB, así que la portada no carga Three.js hasta que hace falta.

Lo que cuesta

Medido sobre esta web, en escritorio y en un móvil de gama media simulado (CPU cuatro veces más lenta y una conexión 4G lenta):

• Sin abrir la mascota, la portada carga 1,9 KB de JavaScript más el icono.
• Al abrirla, descarga 213 KB (Three.js y la grulla) y la dibuja en 0,3 s en escritorio y en 1,9 s en el móvil.
• Mientras está abierta, la animación gasta unos 33 ms de CPU por segundo en escritorio y unos 105 en el móvil. En reposo se dibuja a 30 fotogramas por segundo; al volar o reaccionar, a todos los que da la pantalla.
• Al cerrarla, el bucle de dibujo se para y la página vuelve a gastar lo mismo que sin mascota.

La simulación dibuja el 3D por software, así que en un móvil con GPU real esas cifras de CPU deberían ser mejores.

Lo que el motor no sabe

• No hay física del papel. Las caras son rígidas y no se doblan, no se estiran y no tienen grosor. Algunos pliegues reales, sobre todo los de pétalo, se hacen dejando que el papel se curve un poco; aquí se aproximan con una trayectoria de caras rígidas que cierra con un error de hasta el 2 %.
• No hay colisiones. El orden de las capas se deduce de cómo se abren junto a sus bisagras, no de un cálculo de choques.
• Las trayectorias no son únicas. Son una manera coherente de ir de un estado al siguiente, la más parecida al avance lineal, no necesariamente la que seguirían unas manos.
• Los datos tienen redondeo. El error de cierre que queda es compatible con él, pero no está demostrado.

Cómo está hecho

El código todavía no es público; estas son las piezas:

• web/src/lib/origamiFold.ts: el motor (estados, recorrido, error de cierre, apilado de capas).
• web/scripts/origami-trayectorias.mjs: búsqueda de sentidos y trayectorias (unos dos minutos y medio); escribe public/data/crane-trayectorias.json.
• web/scripts/grulla-mascota.mjs: de la pose final a las piezas de la mascota y al icono.
• web/src/pages/lab/origami-plegado.astro: el visor, con ?paso=N para ir a un paso concreto (también fraccionario: ?paso=8.5 es la mitad del colapso).

El patrón y las instrucciones son de Origami Odyssey, de Robb Doering, con licencia MIT.

Etiquetas: origami · geometría · Three.js · visualización · optimización