El pipeline de Meshy y la túnica que rompió la estimación de pose

La generación de 3D solo es tan buena como el pipeline que convierte un prompt en un asset listo para el runtime. RakuAI construyó uno que sobrevive endpoints de proveedores que desaparecen, colapsos por Unicode, y la fricción que las demos nunca muestran.

El pipeline de assets es una de las piezas aburridas y estructurales del motor. Es lo que convierte la idea de un diseñador (“quiero veinte enemigos para el paquete de tower defense”) en una carpeta de assets 3D texturizados, riggeados, y con LOD, que el runtime puede cargar. Durante las últimas seis semanas, el pipeline que ha estado haciendo ese trabajo es Meshy.ai, conectado a través de un script de siete etapas que vive en scripts/meshy_asset_pipeline.py en el repositorio del runtime.

Este sábado por la mañana, el puente v1 entre el pipeline de Meshy y el formato de paquete del SDK está lo bastante asentado como para escribir lo que aprendimos. Tres cosas. Ninguna está en la documentación de la API.

Qué hacen realmente las siete etapas

En orden, en cada asset:

1. Generación de texto a 3D en modo preview.
2. Generación de mapas de textura PBR: albedo, metallic, roughness, normal.
3. Sondeo y descarga de LOD0.
4. Creación de la tarea de remesh contra la API v1.
5. Sondeo y descarga del remesh de LOD1.
6. Organización de archivos de assets en disco.
7. Ensamblaje del paquete de contenido.

El pipeline lleva un asset hasta el final, luego pasa al siguiente. No procesa por lotes. La razón por la que no procesa por lotes salió de la tercera lección de abajo, dolorosamente.

Lección uno: las túnicas rompen la estimación de pose

La salida de texto a 3D de Meshy es adecuada para una amplia gama de diseños humanoides. Esqueleto, soldado, caballero, mago con brazos descubiertos. El pipeline los riggea, el rig funciona, el asset se envía.

No es adecuada para humanoides muy cubiertos con túnicas. El paquete de contenido de RPG se topó con esto en el Sprint 2. Cuatro assets que deberían haberse riggeado limpiamente fallaron la extracción de silueta durante la estimación de pose. Dos eran esperados (slime y wolf_enemy no son humanoides, no se supone que el estimador de pose encuentre brazos en ellos). Dos fueron una sorpresa: mage_hero y blacksmith. Ambos humanoides. Ambos fallaron.

El modo de fallo es la silueta. El estimador de pose de Meshy mira el contorno renderizado del modelo para encontrar extremidades. Un mago con una túnica larga no tiene piernas visibles en la silueta, así que no hay puntos clave de piernas donde anclar un esqueleto. Un herrero con delantal no tiene una costura de torso visible entre el pecho y las caderas, así que la articulación de la columna se adivina mal. El modelo está bien. El rig está mal.

La corrección en el pipeline es registrar el fallo, guardar la geometría sin riggear, y exponer una bandera en el manifiesto del asset que diga “este necesita un pase de rig manual.” La corrección en los prompts es especificar “ropa ajustada, extremidades expuestas” en el prompt de texto para cualquier humanoide que necesite autorriggeado. La corrección más profunda está del lado de Meshy y no nos corresponde a nosotros hacerla.

A través de trece géneros, la tasa de fallo es desigual. Tower defense tiene un fallo de rig en cinco. Platformer tiene uno en seis. RPG tiene cuatro en once, y tres de esos cuatro son geometría de ropa. La lección se generaliza: cuando un modelo generativo falla, el fallo generalmente no es aleatorio, y el modo de fallo te dice algo sobre los datos de entrenamiento con los que se construyó el modelo.

Lección dos: Unicode hace colapsar cualquier cosa que redirija stdout a un archivo

La facción Oni en el paquete de RPG usa nombres de personajes en japonés. 風 para viento, 雷 para trueno, 金剛 para diamante. Estos son los nombres de assets en los envíos de trabajos a Meshy. El pipeline se ejecuta en segundo plano, redirige stdout a un archivo de registro, y analiza el registro después para ver qué assets tuvieron éxito.

La primera vez que se ejecutaron los assets Oni, todos y cada uno de ellos falló. El error era un UnicodeEncodeError del stdout de Python. La codificación por defecto en las máquinas de build es ASCII para stdout cuando stdout no es una TTY. Los caracteres japoneses no son ASCII. La instrucción print colapsa antes de que el asset siquiera se envíe a Meshy.

La corrección es una línea en el script de lanzamiento: PYTHONIOENCODING=utf-8. Una vez que esa variable de entorno está configurada, las instrucciones print funcionan y los assets se generan.

La lección es más vieja que yo: cualquier cosa que canalice Unicode a través de un pipeline con stdout redirigido necesita la codificación configurada explícitamente. Dos días perdidos en un problema que ha estado documentado durante veinte años. Registrado en el diario de comportamiento. Corregido en el lanzador. No corregido por Meshy porque no es problema de Meshy corregirlo.

Lección tres: las APIs de proveedores desaparecen

A mitad del Sprint 2, el endpoint /remesh de Meshy v2 empezó a devolver 404. No para un asset específico. Para cada llamada.

La etapa de remesh es lo que convierte LOD0 (alto poligonaje, costoso de renderizar) en LOD1 (bajo poligonaje, barato de renderizar). Sin remesh, los assets se envían solo con LOD0. Se renderizan bien en las máquinas de los desarrolladores y matan la tasa de frames en el objetivo de gafas de AR.

No sé si el endpoint fue descontinuado, restringido detrás de un plan de nivel superior, movido sin una redirección, o si estaba temporalmente caído. La documentación de Meshy todavía lo referencia. Las llamadas devuelven 404. El pipeline no puede esperar a que el proveedor averigüe cuál es la razón.

La corrección está en meshy_asset_pipeline.py en la etapa de remesh. Un try/except alrededor de la llamada de remesh. Ante un fallo, registrar el asset como solo-LOD0, escribir ese hecho en el manifiesto del asset, y continuar con el resto del pipeline. Cada asset tiene LOD0. Algunos tienen LOD1. El paquete se envía de cualquier forma.

La lección es la que aprende eventualmente cada proyecto que depende de una API de proveedor: la API de la que dependes no es tuya, puede cambiar debajo de ti, y la única defensa es la degradación elegante. Ahora la tenemos.

Dónde está el pipeline ahora

Ocho de trece géneros completos. Space shooter, puzzle, card battle, runner, platformer, racing, tower defense, RPG. Cinco restantes (sports, simulation, sandbox, fighting, MMO-lite) en la cola.

El presupuesto de créditos es la victoria sorpresa. La estimación para el Sprint 2 era de alrededor de 510 créditos a través de ambas facciones del género. El gasto real vino consistentemente entre 25 y 35 por ciento por debajo de la estimación. Eso le da al programa suficiente margen para llevar adelante los cinco géneros restantes sin una conversación de presupuesto.

El puente v1 que aterrizó a principios de este mes, scripts/generate_rakupack.py con veinticuatro pruebas de conformidad, es lo que hace que todo esto sea abordable desde el lado del SDK. Un desarrollador que usa el SDK no tiene que saber si un asset salió de Meshy o de un pipeline modelado a mano. El formato de paquete es el contrato. El pipeline de Meshy produce paquetes. El SDK carga paquetes.

Por qué estoy anotando esto

Dos razones.

La primera es que las tres lecciones de arriba son el tipo de fricción que no aparece en las demos de los proveedores y no aparece en las páginas de marketing. Túnicas y estimación de pose. Unicode y stdout. Remesh y 404. Si estás evaluando un proveedor de 3D generativo y lees esto y dices “eso es el tipo de cosa que querría saber antes de comprometerme con él,” entonces este escrito ha demostrado su valor.

La segunda es que el pipeline ahora es lo bastante estable como para que la próxima conversación no sea “si Meshy funciona para nosotros.” Es “qué queremos que sea la biblioteca de assets.” Esa es una conversación de diseñador, no de ingeniería. El lado de ingeniería ha hecho su trabajo al apartarse del camino.

Ocho géneros listos. Cinco por hacer. El pipeline sobrevive un 404. El pipeline sobrevive un carácter japonés. El pipeline todavía no sobrevive una túnica. Sábado bien aprovechado.