Eine Brauerei in 3D modellieren: prozedurale Tanks und Prozessfluss (Teil 2)

Kurze Antwort: Jeder Tank im Brauerei-Twin — Maischbottich, Läuterbottich, Sudpfanne, Whirlpool, die zylindrokonischen Gärtanks, die Drucktanks — wurde im Code mit React Three Fiber modelliert, nicht in Blender geformt. Sudhausgerät besteht größtenteils aus Zylindern, Kegeln und Kuppeln, also hält prozedurale Geometrie das Bündel winzig, killt die Asset-Pipeline und macht die Geometrie datengetrieben. Der eigentliche Trick sind nicht die Meshes; es ist, dass eine Datei die ganze Anlage beschreibt — jeden Tank und jede Flusskante — und Szene, Etiketten, fließende Rohre und Diagramme alle daraus lesen. Einmal modellieren, überall rendern. Und ja, es gibt eine klare Linie, ab der Blender das richtige Werkzeug ist — die ziehe ich am Ende ehrlich.

Geometrie aus Code, Anlage aus Daten, Szene aus beidem. Ändere eine Datei, und der ganze Twin bewegt sich mit.

Dies ist Teil 2 der Serie. Teil 1 behandelte das Warum und das Gerüst — eine Fabric-gehostete App an einem Nachmittag mit dem Rayfin SDK live zu bekommen. Hier bauen wir das, was die Leute tatsächlich ansehen: die Tanks und den Fluss zwischen ihnen.

Die Entscheidung: die Tanks coden, nicht formen

Der Serien-Teaser sagte „die Tanks in Blender modellieren”, und das ist der Instinkt, den jeder hat. Aber sieh dir ein Sudhaus ehrlich an: Ein Maischbottich ist ein Zylinder mit Kuppeldach und einem Motor obendrauf. Ein Gärtank ist ein Zylinder mit einem darunter geschweißten Kegel. Eine Sudpfanne ist ein Zylinder mit einem Kamin. Das sind Primitive — und Three.js gibt dir Primitive gratis.

Also ging ich prozedural vor. Jeder Tank ist aus cylinderGeometry, coneGeometry und einer Halb-sphereGeometry-Kuppel gebaut, in React Three Fiber zusammengesetzt. Der Gewinn ist konkret:

• Keine Asset-Pipeline — kein glTF-Export, keine Texturdateien, keine Draco-Kompression, nichts mit dem Code synchron zu halten.
• Ein winziges Bündel — der schwere Teil der App ist die Three.js-Bibliothek selbst, nicht die Modelle, was zählt, weil das Ganze als statische Assets zu Microsoft Fabric ausgeliefert wird.
• Datengetriebene Geometrie — Größe und Form eines Tanks kommen aus Zahlen, dieselbe Komponente rendert also einen gedrungenen Läuterbottich und einen hohen HLT, nur durch andere Argumente.

Jeden Tank wie sich selbst aussehen lassen

Eine Brauerei, in der jeder Tank ein identischer silberner Zylinder ist, ist nutzlos — man kann sie nicht lesen. Die Lösung ist funktionsspezifisches Detail: die Teile, die einem Brauer sagen, was er ansieht.

• Maischbottich → ein Rührwerksgetriebe und Antriebsmotor obendrauf.
• Läuterbottich → eine Hackwerk-Antriebsbrücke quer über den Tank.
• Sudpfanne → ein hoher Brüdenkamin und Kondensator.
• Whirlpool → ein kurzer Kamin mit tangentialem Einlaufrohr.
• Gärtanks → zylindrokonisch, auf Beinen stehend, mit Glykol-Mantelbändern umwickelt.
• Drucktanks → druckkuppelig und schlanker.

Ich habe diese als topper pro Tank kodiert, sodass die Geometrie der Funktion folgt. Füge den Tanks Beine, Isolierung und Reifenbänder hinzu, und das Sudhaus wird auf einen Blick lesbar — du findest die Sudpfanne an ihrem Kamin, bevor du je ein Etikett liest.

All das sind Zylinder, Kegel und Kuppeln aus Code — die Topper und Proportionen machen jeden Tank lesbar.

Der eigentliche Trick: eine Datei beschreibt die ganze Anlage

Hier ist der Teil, der einen wartbaren Twin von einer 3D-Szene unterscheidet, die verrottet. Es gibt eine einzige Prozessdatei. Sie listet jeden Tank — id, Anzeigename, Position auf dem Boden, Radius, Höhe, was er hält und seinen Topper — und jede Flusskante: einen from-Tank, einen to-Tank und das, was zwischen ihnen fließt (Heißwasser, Schrot, Maische, Würze, Bier).

Alles liest aus dieser Datei:

• die Szene platziert jeden Tank an seiner Position,
• die Etiketten und Statusringe kommen aus denselben Datensätzen,
• die Rohre werden zwischen den from- und to-Positionen jeder Kante gezeichnet,
• selbst die Diagramme pro Tank schlüsseln auf die Tank-id.

Verschiebe einen Tank, benenne ihn um oder füge eine neue Transferleitung hinzu, und du editierst Daten, keine Geometrie. Das Modell ist die Quelle der Wahrheit; das 3D ist nur eine Art, es auszudrücken. (Der andere Ausdruck — die Live-Zahlen — kommt in Teil 3.)

Den Fluss animieren

Eine statische Anlage ist ein Diagramm. Was sie zu einem Twin macht, ist zu sehen, wie Produkt sich bewegt. Für jede Flusskante zeichnet die Szene ein dünnes Rohr zwischen den beiden Tanks und lässt ein paar kleine Partikel daran entlanglaufen, nach Inhalt eingefärbt — Bernstein für Maische, Gold für Würze, Kupfer für Bier, Blau für Kaltwasser. Der Render-Loop interpoliert die Position jedes Partikels von from nach to und lässt sie kreisen.

Weil Fluss Daten ist, ist das Hinzufügen eines Transfers — sagen wir, eine neue Leitung von einem Drucktank zu einem vierten Hahn — ein Eintrag in der Kantenliste. Kein neues Mesh, keine manuelle Platzierung. Das Rohr und sein fließendes Produkt erscheinen automatisch.

Diagramme pro Tank, die zum Prozess passen

Wenn du einen Tank anklickst, bekommst du keine generische Anzeige — du bekommst das Diagramm, das dieser Tank verdient: ein Maische-Rastprofil für den Maischbottich, Läuterabfluss für den Läuterbottich, eine Kurve aus fallender Stammwürze und steigendem ABV für einen Gärtank, Karbonisierung für einen Drucktank. Das sind leichte, handgezeichnete SVG-Liniendiagramme statt einer Diagrammbibliothek, aus demselben Grund wie die prozedurale Geometrie — die Last klein und die Kontrolle vollständig halten. Jedes Diagramm ist nur eine Funktion der Tank-id, sodass die richtige Kurve für den richtigen Tank erscheint.

Maischbottich ausgewählt: ein Rasttemperaturprofil — Eiweißrast, Verzuckerung, Abmaischen — keine generische Anzeige.

Gärtank ausgewählt: die Stammwürze fällt, während der ABV steigt — das Diagramm, das dieser Tank wirklich verdient.

Wo das an Grenzen stößt

Die ehrlichen Grenzen, denn „einfach coden” ist nicht immer richtig. Prozedurale Geometrie hat eine Decke — sie ist perfekt für Zylinder, Kegel und Kuppeln, aber sobald du ein gebrandetes, organisches oder fotorealistisches Asset willst (ein geformtes Logo, ein realistischer Gabelstapler, eine texturierte Backsteinwand), wehren sich Primitive, und Blender plus glTF-Export ist das richtige Werkzeug; die Entscheidungsregel ist Realismus-und-Einzigartigkeit gegen Klarheit-und-Gewicht. Detail kostet Frames — jedes Bein, Band und jeder Topper ist mehr Mesh zum Zeichnen, bei einer großen Anlage willst du also Instancing oder zusammengeführte Geometrie, bevor die Bildrate leidet; ich habe das noch nicht gebraucht, aber eine Anlage mit 200 Tanks schon. Ein sauberes Modell kann trotzdem lügen — Geometrie, die richtig aussieht, sagt nichts darüber, ob sie an echte Daten angebunden ist; ein schöner Twin auf falschen Zahlen ist ein Bildschirmschoner, und genau diese Lücke schließt Teil 3. Und „datengetrieben” stimmt nur, wenn man diszipliniert ist — in dem Moment, in dem jemand eine Position in der Szene statt in der Datendatei hartkodiert, bricht das Versprechen der einen Quelle der Wahrheit still.

Fazit

Greif nicht zu Blender, weil Modellieren „dort” passieren „sollte”. Sieh dir an, was du modellierst: Ein Sudhaus sind Primitive, also code die Tanks, gib jedem das Detail, das seine Funktion signalisiert, und — am wichtigsten — treibe die ganze Anlage aus einer einzigen Prozessdatei, damit Szene, Fluss und Diagramme sich mitbewegen, wenn du sie editierst. Reserviere Blender für die Formen, die Primitive wirklich nicht ausdrücken können. Die Geometrie ist der einfache Teil; die Disziplin einer einzigen Quelle der Wahrheit macht einen Twin, den man tatsächlich warten kann. Als Nächstes Teil 3: ihn an Echtzeitdaten und Klartext-Sprache anbinden, damit der Twin aufhört zu simulieren und anfängt zu berichten.

Häufige Fragen

Braucht man Blender, um eine Brauerei in 3D zu modellieren? Nein. Sudhaustanks sind größtenteils Zylinder, Kegel und Kuppeln, lassen sich also prozedural im Code mit React Three Fiber und Three.js-Primitiven bauen. Das hält das Bündel winzig, entfernt die Asset-Pipeline und bedeutet, dass die Geometrie von Daten statt von Dateien getrieben wird. Blender verdient seinen Platz, wenn du organische Formen, Markendetails oder fotorealistische Materialien brauchst, die Primitive nicht ausdrücken können — dann exportierst du glTF und lädst es. Für einen Prozess-Twin, bei dem Klarheit über Realismus geht, gewinnt prozedural.

Wie lässt man verschiedene Tanks wie verschiedene Gefäße aussehen? Funktionsspezifisches Detail. Ein Maischbottich bekommt ein Rührwerksgetriebe obendrauf, ein Läuterbottich eine Hackwerk-Antriebsbrücke, eine Sudpfanne einen hohen Brüdenkamin, Gärtanks sind zylindrokonisch auf Beinen mit Glykolbändern. Ich habe diese als ein ‘Topper’-Feld pro Tank kodiert, sodass die Geometrie dem entspricht, was der Tank tatsächlich tut — man liest das Sudhaus auf einen Blick, ganz ohne Etiketten.

Wie wird der Fluss zwischen den Tanks animiert? Jede Verbindung ist eine Kante in einer Datendatei mit einem ‘from’, einem ‘to’ und dem, was fließt (Heißwasser, Maische, Würze, Bier). Die 3D-Schicht zeichnet ein Rohr zwischen den beiden Tankpositionen und lässt kleine Partikel daran entlanglaufen, nach Inhalt eingefärbt, indem sie ihre Position im Render-Loop interpoliert. Es liest sich, als bewege sich Produkt physisch durch die Anlage, und ein neues Rohr hinzuzufügen ist eine Zeile Daten, keine neue Geometrie.

Warum alles aus einer einzigen Datendatei treiben? Weil ein Digital-Twin nur wartbar ist, wenn das Modell die Quelle der Wahrheit ist. Eine Datei listet jeden Tank — id, Name, Position, Größe, Inhalt, Topper — und jede Flusskante. Die Szene, die Etiketten, die Flussanimation und die Diagramme lesen alle daraus. Ändere die Anlage an einer Stelle, und der ganze Twin aktualisiert sich, was einen wartbaren Twin von einer handplatzierten 3D-Szene unterscheidet, die verrottet.