Die Meshy-Pipeline und die Robe, die die Pose-Schätzung kaputt gemacht hat

Generative 3D ist nur so gut wie die Pipeline, die aus einem Prompt ein laufzeitfertiges Asset macht. RakuAI hat eine gebaut, die verschwindende Vendor-Endpoints, Unicode-Abstürze und die Reibung übersteht, die die Demos nie zeigen.

Die Asset-Pipeline ist eines der langweiligen-und-tragenden Teile der Engine. Sie ist das, was die Idee eines Designers („ich will zwanzig Gegner für das Tower-Defense-Pack”) in einen Ordner mit texturierten, riggten, LOD-versehenen 3D-Assets verwandelt, den die Runtime laden kann. Die letzten sechs Wochen war die Pipeline, die diese Arbeit erledigt hat, Meshy.ai, verdrahtet über ein siebenstufiges Skript, das im Runtime-Repo unter scripts/meshy_asset_pipeline.py liegt.

Diesen Samstagmorgen ist die v1-Brücke zwischen der Meshy-Pipeline und dem SDK-Pack-Format weit genug ausgereift, dass ich aufschreiben kann, was wir gelernt haben. Drei Dinge. Keines davon steht in der API-Dokumentation.

Was die sieben Stufen tatsächlich tun

In dieser Reihenfolge, für jedes Asset:

1. Text-zu-3D-Generierung im Vorschaumodus.
2. PBR-Texturkarten-Generierung: Albedo, Metallic, Roughness, Normal.
3. LOD0-Polling und Download.
4. Remesh-Task-Erstellung gegen die v1-API.
5. LOD1-Remesh-Polling und Download.
6. Asset-Dateiorganisation auf der Festplatte.
7. Content-Pack-Zusammenstellung.

Die Pipeline führt ein Asset komplett durch, dann geht sie zum nächsten über. Sie batcht nicht. Der Grund, warum sie nicht batcht, ergab sich schmerzhaft aus der dritten Lektion unten.

Lektion eins: Roben brechen die Pose-Schätzung

Die Meshy-Text-zu-3D-Ausgabe ist für ein breites Spektrum humanoider Designs in Ordnung. Skelett, Soldat, Ritter, Magier mit nackten Armen. Die Pipeline riggt sie, das Rig funktioniert, das Asset wird ausgeliefert.

Es ist nicht in Ordnung für stark berobte Humanoide. Das RPG-Content-Pack traf darauf in Sprint 2. Vier Assets, die sauber hätten riggen sollen, scheiterten bei der Silhouetten-Extraktion während der Pose-Schätzung. Zwei waren erwartet (slime und wolf_enemy sind keine Humanoide, der Pose-Schätzer soll bei ihnen keine Arme finden). Zwei waren eine Überraschung: mage_hero und blacksmith. Beide humanoid. Beide scheiterten.

Der Fehlermodus ist die Silhouette. Meshys Pose-Schätzer betrachtet den gerenderten Umriss des Modells, um Gliedmaßen zu finden. Ein Magier in einer langen Robe hat keine sichtbaren Beine in der Silhouette, also gibt es keine Bein-Keypoints, an denen ein Skelett verankert werden könnte. Ein Schmied mit einer Schürze hat keine sichtbare Rumpfnaht zwischen Brust und Hüfte, also rät das Wirbelsäulengelenk falsch. Das Modell ist in Ordnung. Das Rig ist falsch.

Der Fix in der Pipeline ist, den Fehlschlag zu loggen, die ungeriggte Geometrie zu speichern und eine Markierung im Asset-Manifest zu setzen, die sagt „dieses hier braucht einen manuellen Rig-Durchgang.” Der Fix in den Prompts ist, „enge Kleidung, freiliegende Gliedmaßen” im Text-Prompt für jeden Humanoiden anzugeben, der Auto-Rigging braucht. Der längere Fix liegt auf Meshys Seite und ist nicht unserer, um ihn zu machen.

Über dreizehn Genres hinweg ist die Fehlerrate ungleichmäßig. Tower Defense hat einen Rigging-Fehlschlag von fünf. Platformer hat einen von sechs. RPG hat vier von elf, und drei dieser vier sind Kleidungsgeometrie. Die Lektion verallgemeinert sich: Wenn ein generatives Modell scheitert, ist das Scheitern normalerweise nicht zufällig, und der Fehlermodus sagt etwas über die Trainingsdaten aus, mit denen das Modell gebaut wurde.

Lektion zwei: Unicode bringt alles zum Absturz, das stdout in eine Datei pipet

Die Oni-Fraktion im RPG-Pack verwendet japanische Charakternamen. 風 für Wind, 雷 für Donner, 金剛 für Diamant. Das sind die Asset-Namen in den Meshy-Job-Einreichungen. Die Pipeline läuft im Hintergrund, leitet stdout in eine Log-Datei um und parst das Log später, um zu sehen, welche Assets erfolgreich waren.

Beim ersten Mal, dass die Oni-Assets liefen, scheiterten sie alle, jedes einzelne. Der Fehler war ein UnicodeEncodeError von Pythons stdout. Die Standard-Kodierung auf den Build-Maschinen ist ASCII für stdout, wenn stdout kein TTY ist. Die japanischen Zeichen sind nicht ASCII. Das Print-Statement stürzt ab, bevor das Asset überhaupt bei Meshy eingereicht wird.

Der Fix ist eine Zeile im Launcher-Skript: PYTHONIOENCODING=utf-8. Sobald diese Umgebungsvariable gesetzt ist, funktionieren die Print-Statements, und die Assets werden generiert.

Die Lektion ist älter als ich: Alles, das Unicode durch eine stdout-umgeleitete Pipeline schickt, braucht die Kodierung explizit gesetzt. Zwei Tage verloren an ein Problem, das seit zwanzig Jahren dokumentiert ist. Im Verhaltensjournal festgehalten. Im Launcher gefixt. Nicht von Meshy gefixt, weil es nicht Meshys Problem ist, es zu fixen.

Lektion drei: Vendor-APIs verschwinden

Auf halber Strecke durch Sprint 2 begann der Meshy-v2-Endpoint /remesh, 404 zurückzugeben. Nicht für ein bestimmtes Asset. Für jeden Aufruf.

Die Remesh-Stufe ist das, was LOD0 (hochauflösend, teuer zu rendern) in LOD1 (niedrigauflösend, günstig zu rendern) verwandelt. Ohne Remesh werden die Assets nur mit LOD0 ausgeliefert. Sie rendern gut auf den Entwicklermaschinen und bringen auf dem AR-Brillen-Ziel die Framerate um.

Ich weiß nicht, ob der Endpoint abgeschafft wurde, hinter einen höherwertigen Plan gesperrt wurde, ohne Weiterleitung verschoben wurde oder vorübergehend down war. Die Meshy-Dokumentation referenziert ihn immer noch. Aufrufe darauf geben 404 zurück. Die Pipeline kann nicht warten, bis der Vendor herausfindet, welches davon es ist.

Der Fix ist in meshy_asset_pipeline.py an der Remesh-Stufe. Ein try/except um den Remesh-Aufruf. Bei Fehlschlag: das Asset als nur-LOD0 loggen, diese Tatsache ins Asset-Manifest schreiben und mit dem Rest der Pipeline fortfahren. Jedes Asset hat LOD0. Manche haben LOD1. Das Pack wird so oder so ausgeliefert.

Die Lektion ist die, die jedes Projekt, das von einer Vendor-API abhängt, irgendwann lernt: Die API, von der du abhängst, gehört dir nicht, und sie kann sich unter dir ändern, und die einzige Verteidigung ist graziöse Degradation. Jetzt haben wir sie.

Wo die Pipeline jetzt steht

Acht von dreizehn Genres abgeschlossen. Space Shooter, Puzzle, Card Battle, Runner, Platformer, Racing, Tower Defense, RPG. Fünf verbleibend (Sports, Simulation, Sandbox, Fighting, MMO-Lite) in der Warteschlange.

Das Credit-Budget ist der Überraschungsgewinn. Die Schätzung für Sprint 2 lag bei etwa 510 Credits über beide Fraktionen des Genres hinweg. Der tatsächliche Verbrauch lief konsequent 25 bis 35 Prozent unter der Schätzung. Das gibt dem Programm genug Spielraum, um die verbleibenden fünf Genres ohne Budget-Gespräch durchzuziehen.

Die v1-Brücke, die Anfang dieses Monats landete, scripts/generate_rakupack.py mit vierundzwanzig Konformitätstests, ist das, was das Ganze von der SDK-Seite aus adressierbar macht. Ein Entwickler, der das SDK verwendet, muss nicht wissen, ob ein Asset aus Meshy kam oder aus einer handmodellierten Pipeline. Das Pack-Format ist der Vertrag. Die Meshy-Pipeline produziert Packs. Das SDK lädt Packs.

Warum ich das aufschreibe

Zwei Gründe.

Der erste ist, dass die drei Lektionen oben die Art von Reibung sind, die nicht in Vendor-Demos auftaucht und nicht auf Marketing-Seiten auftaucht. Roben und Pose-Schätzung. Unicode und stdout. Remesh und 404. Wenn du einen generativen-3D-Vendor evaluierst und das hier liest und sagst „das ist die Art von Sache, die ich wissen wollen würde, bevor ich mich darauf festlege”, dann hat sich das Schreiben gelohnt.

Der zweite ist, dass die Pipeline jetzt stabil genug ist, dass das nächste Gespräch nicht „funktioniert Meshy für uns” ist. Es ist „was wollen wir, dass die Asset-Bibliothek ist.” Das ist ein Designer-Gespräch, kein Engineering-Gespräch. Die Engineering-Seite hat ihren Job gemacht, indem sie aus dem Weg gegangen ist.

Acht Genres erledigt. Fünf zu gehen. Die Pipeline übersteht einen 404. Die Pipeline übersteht ein japanisches Zeichen. Die Pipeline übersteht, noch, keine Robe. Samstag gut genutzt.