Alles geklont und auseinandergenommen Zusätzlich zur App selbst: die offizielle Website und der komplette Plugin-Store. Dazu zwei Code-Deep-Dives (Painter & Animation) – und ein echtes, funktionierendes Erweiterungs-Plugin, das ich für dich gebaut habe.

18Die Website blockbench.net

Die Website ist kein statisches HTML, sondern eine eigenständige Nuxt-4-Anwendung (Vue 3) im selben Autoren-Repo. ~213 Dateien, Klon-Umfang 46 MB.

Aufbau

Interessante Details

• Wiki statt Dokuseite: Die technische Dokumentation (u. a. docs/bbmodel.md mit der Format-Spezifikation, docs/plugin.md, docs/undo.md) liegt als Markdown im Repo und wird zu statischen Seiten gerendert. Ein Redirect führt sogar /faq auf den Wiki-Pfad.
• Download-Seite als Live-Ansicht: downloads.vue baut die Links zu Blockbench_${version}.exe, _arm64_.dmg, .deb, .rpm, .AppImage aus der GitHub-Releases-API. Fällt die API aus (version == '1.0.1'), zeigt die Seite einen Fallback-Text. Flatpak kommt von Flathub (net.blockbench.Blockbench) – passend zur Datei static/.well-known/org.flathub.VerifiedApps.txt.
• Prerendering-Strategie: nitro.prerender.crawl = true, aber /plugins und /downloads sind ausgenommen – die beiden Seiten mit Live-Daten werden also immer dynamisch gerendert.
• Deployment: Die Web-App selbst wird über einen GitHub-Actions-Workflow auf gh-pages gebaut (npm run prepublish-web = Web-Build + PWA-Service-Worker + Typedoc), die Website liegt getrennt davon (Cloudflare davor, x-origin-cache: HIT).

19Der Plugin-Store (Infrastruktur)

Der Store ist kein Server, sondern ein GitHub-Repository (JannisX11/blockbench-plugins). Die App liest daraus zwei JSON-Dateien und lädt Plugin-Quelltext direkt von einem CDN – das erklärt, warum der Store praktisch keine Infrastrukturkosten hat und beliebig skalierbar ist.

Die drei Endpunkte, die die App benutzt

Store-Statistik (aus dem geklonten Index)

Ein vollständiger, filterbarer Katalog aller 144 Plugins liegt als Excel-Datei daneben: blockbench-plugin-store-uebersicht.xlsx – drei Blätter (Plugins mit Tags/Autor/Größe/Abhängigkeiten, Statistik, Quellen & Commit-Stand).

Was ein Store-Eintrag enthält

// plugins.json – Feldreichster Eintrag als Beispiel
"optifine_player_models": {
  "title": "OptiFine Player Models", "icon": "icon.png", "author": "Ewan Howell",
  "description": "Adds a new format that allows you to create OptiFine player models.",
  "tags": ["Minecraft: Java Edition", "OptiFine", "Player Models"],
  "version": "1.5.2", "min_version": "5.0.0", "variant": "both",
  "await_loading": true,                       // App wartet beim Start auf dieses Plugin
  "creation_date": "2022-05-29",
  "contributes": { "formats": ["optifine_player_model"] },   // „ich kann .xyz öffnen"
  "website": "…", "repository": "…", "bug_tracker": "…"
}

Das Feld contributes ist dabei besonders praktisch: Blockbench weiß dadurch über nicht installierte Plugins, welches Format sie beisteuern würden, und kann beim Öffnen einer unbekannten Datei gezielt vorschlagen: „Diese Datei braucht Plugin X."

20Wie man ein Plugin veröffentlicht

Der Weg in den Store führt über einen Pull Request. Die Datei scripts/validate.js ist die Türsteher-Prüfung und läuft in der CI. Sie ist streng und deckt genau die Fallstricke ab, über die ich beim Plugin-Bauen gestolpert bin:

Für Multifile-Plugins gibt es src/<id>/ als Quellprojekt (eigene package.json, Webpack/Esbuild-Konfiguration), aus dem die gebündelte Einzeldatei erzeugt und mit eingecheckt wird. Deshalb liegt im Store neben Mesh Tools der 501-KB-Build auch das Quellprojekt im src/-Ordner.

21Mal-/Textursystem im Detail (gemessen)

Der Painter ist der zweitgrößte Block der App (3.859 Zeilen) und funktioniert als Zustandsmaschine über Ereignisse, nicht als kontinuierlicher Loop. Der Ablauf einer einzigen Pinselbewegung:

Wie der Pinsel über die Fläche „weiß", wohin er darf

Vor jedem Strich wird ein Clipping-Pfad aus den UV-Rechtecken gesetzt: setupRectFromFace() berechnet aus der Face-UV (und optional der aktiven Mirror-Achse) den erlaubten Bereich, ctx.rect(...) spannt ihn auf, und alles Malen (Kreis, Quadrat, Linie) läuft in diesem Bereich. Bei Mesh-Flächen kommt eine „Occupancy Matrix" hinzu – eine Pixelmaske der tatsächlichen Dreiecksform, damit der Pinsel nicht über schräge Kanten hinausläuft.

Was ich live gemessen habe

Fund: Das Bitmap-Undo arbeitet asynchron

Meine erste Messung zeigte „Undo stellt die Bitmap nicht wieder her" – das war falsch, wie die genauere Messung entlarvte. Die Bitmap wird nicht synchron zurückgesetzt, sondern über ein Bild-onload: Beim Wiederherstellen legt Undo die Pixel aus image_data in den Canvas und setzt die Bildquelle; sichtbar wird das Ergebnis erst im nächsten Tick.

Codebeleg: UndoSystem.save.load() → tex.convertToInternal(image_data) → tex.updateSource(). Zusätzlich gibt es einen Sonderpfad: Wenn die Bilddatei auf der Platte seit dem letzten Speichern verändert wurde (source_overwritten), wird der Originalstand aus dem Undo-Snapshot rekonstruiert, damit man nicht versehentlich fremde Änderungen mit-überschreibt.

22Animations-Engine im Detail (gemessen)

Animation ist praktisch ein zweiter Editor in der App. Ich habe einen kompletten Zyklus aufgebaut: Rig → Keyframes (inkl. Molang) → Timeline-Wiedergabe → Export → Animation Controller.

Datenmodell

Erzeugung über die API (so macht es auch der Datei-Import)

// 1) Animator für eine Gruppe holen (erzeugt ihn bei Bedarf)
const animator = anim.getBoneAnimator(armGroup);
// 2) Keyframes hinzufügen – exakt der Pfad aus animation.js beim JSON-Import
animator.addKeyframe({ channel: 'rotation', time: 0.5, interpolation: 'linear',
                       data_points: [{x:0, y:60, z:0}, {x:0, y:60, z:0}] });
// 3) Molang als Wert – wird beim Abspielen live ausgewertet
animator.addKeyframe({ channel: 'rotation', time: 1.0, interpolation: 'linear',
                       data_points: [{x:0, y:'math.sin(query.anim_time * 180) * 45', z:0},
                                     {x:0, y:'math.sin(query.anim_time * 180) * 45', z:0}] });
anim.setLength();

Timeline-Wiedergabe, gemessen am echten 3D-Objekt

Timeline.setTime(t); Animator.preview();   // dann Rotation des Arm-Meshes auslesen
t = 0.00 s →   0.0°     (Keyframe)
t = 0.25 s →  30.0°     (interpoliert)
t = 0.50 s →  60.0°     (Keyframe)
t = 0.75 s →  45.9°     (Molang: math.sin(0.75·180°)·45 = 31,8 … hier greift die Frame-Quantisierung)
t = 1.00 s →   0.0°     (Molang bzw. Loop-Grenze)

Wichtig: Die Animation läuft nicht über CSS oder Videos, sondern über echte Three.js-Transformationen – arm.mesh.rotation.y wird pro Timeline-Zeit neu gesetzt. Molang-Ausdrücke werden dabei mit query.anim_time gefüttert und bei jedem Preview-Schritt neu evaluiert.

Export über den AnimationCodec

// AnimationCodec.codecs.bedrock.compileFile([anim])
{ "format_version": "1.8.0",
  "animations": { "wave": {
      "loop": true, "animation_length": 1,
      "bones": { "arm": { "rotation": {
          "0.0": { "pre": [0,0,0],  "post": [0,0,0] },
          "0.5": { "pre": [0,-60,0], "post": [0,-60,0] },
          "1.0": { "pre": [0,"-math.sin(query.anim_time * 180) * 45",0], "post": […] } } } } } } }

Animation Controller – Zustandsmaschine mit Molang-Übergängen

Aus zwei Zuständen („idle", „waving") und Übergängen in beide Richtungen entstand live dieser Export:

{ "format_version": "1.19.0",
  "animation_controllers": { "wave_controller": {
      "initial_state": "idle",
      "states": {
        "idle":   { "animations": ["wave"], "transitions": [{ "waving": "" }], "blend_transition": 0.2 },
        "waving": { "transitions": [{ "idle": "" }], "blend_transition": 0.4 } } } } }

Die Übergangsbedingung ist ein freies Molang-Feld (hier leer). Zustände bündeln Animationen, Partikel-Effekte, Sounds sowie on_entry/on_exit-Skripte – der Controller-Editor ist entsprechend der größte Einzel-UI-Block der App.

23Das eigene Toolkit-Plugin

Aus den Deep Dives ist ein echtes Werkzeug entstanden: bb_toolkit.js. Es nutzt bewusst die im ersten Teil beschriebenen Kernsysteme – Property-/Node-API, Undo-Aspects, Dialog-Form-API, Panels und die Action-Registry.

Testlauf gegen die laufende Instanz

Plugin geladen:  actions:[toolkit_audit, toolkit_cleanup, toolkit_generator, toolkit_export_zip, toolkit_select_issues]
                 settings:[toolkit_check_blank_faces, toolkit_generator_size]   + Testhaken aktiv

Testmodell (absichtlich kaputt): 4 Würfel · 2 Gruppen · 2 Texturen

Prüfer-Befund:   {"empty_group":1, "untextured_cube":1, "zero_size_cube":1,
                  "uv_out_of_bounds":1, "blank_face":1, "unused_texture":1}
                 → 4 Würfel · 0 Meshes · 2 Gruppen · 24 Flächen · 48 Dreiecke · 2 Texturen (512 Pixel)

Aufräumen:       fixed: 4 · deaktivierte Flächen: 1 · danach 3 Würfel / 1 Gruppe
Undo:            "Toolkit: Modell aufräumen" → 4 Würfel / 2 Gruppen zurück  ✓
Generator:       Pyramide 8×4 → 4 Würfel in Gruppe "pyramide" (Gesamt: 8)
ZIP-Export:      2 Tabs → 4260 Bytes → ["Bedrock Block.bbmodel (3836 Zeichen)",
                                        "Java Block/Item.bbmodel (64 Zeichen)"]  ✓
Markieren:       Auswahl = ["test"]  ✓

Installation

Datei:   blockbench/plugins_demo/bb_toolkit.js
Desktop: Blockbench → Datei → Plugins → „Plugin aus Datei laden" → bb_toolkit.js
Web:     Blockbench → Datei → Plugins → Datei auswählen
Danach:  Werkzeugleiste hat 2 neue Buttons · Tools-Menü hat die vier Einträge
         · Datei-Menü hat „Alle Projekte als ZIP" · Einstellungen enthalten die zwei Toolkit-Optionen

24Gesamtbild & Nutzung

Nach beiden Teilen ist die Landschaft vollständig vermessen. Vier Repositories, ein System:

Dateien im Workspace

Alle Messwerte in diesem Dokument stammen aus der laufenden, selbst gebauten Instanz (v5.2.1, Commit e2ede08) und den geklonten Repositories. Erstellt am 03.10.2026.
Lizenzhinweis: Blockbench steht unter GPL-3.0-or-later; das Toolkit-Plugin nutzt ausschließlich die öffentliche Plugin-API.