MC Voxel Studio

3D-Modell hochladen → Minecraft-Bedrock-Paket (Entity/Statue und Block) · inklusive Test mit dem heruntergeladenen Tripo3D-Modell

1 · So sieht es aus

2 · Das geladene Tripo3D-Modell

Der Weg dahin: die Studios-Seite liefert keinen direkten Dateilink; über die Projekt-Detail-Schnittstelle (api.tripo3d.ai/v2/studio/project/detail/v3/<id>, mit Referer-Header) kommt eine signierte CDN-Adresse, über die das GLB geladen wurde. Genau dieses GLB ist der Testfall für das Werkzeug.

3 · Was das Werkzeug rechnet

1. Voxelisieren: jedes Dreieck wird konservativ in ein Voxelraster gespritzt (Ebenen-Abstand + baryzentrische Prüfung), Texturfarben werden über die UV-Koordinaten abgetastet, transparente Stellen fallen über die Alpha-Grenze weg.
2. Hülle verdichten (schließt Löcher), Flood-Fill von außen, Innenvolumen füllen, Innenfarben per Mehrquellen-BFS von der Oberfläche.
3. Kanten abdunkeln: Voxel in Ecken und Vertiefungen werden über die Nachbarschaftsbelegung leicht dunkler — die Statue wirkt plastischer, ohne dass mehr Würfel nötig sind.
4. Palette: Median-Cut-Quantisierung auf 16 … 256 Farben; jede Farbe bekommt einen Bildpunkt in einer 16 × 16 großen Palette-Textur, die UVs aller Würfel zeigen auf einzelne Pixel.
5. Greedy-Meshing: gleichfarbige Voxel werden zu möglichst großen Quadern verschmolzen — im Test 168× weniger Würfel als Voxel.
6. Bedrock-Ausgabe: Geometrie 1.12.0 mit Per-Face-UV, Client-Entity, Entity-Verhalten (beschwörbar, unbeweglich, unverwundbar), Block-Variante 1.21.0 in den Blockwürfel (−8 … +8) skaliert, Palette-PNG, Terrain-Atlas, Manifeste (min_engine_version 1.20.60) und eine deutsche Anleitung.

Die Palette als Textur

• Die ganze Statue hängt an dieser 16 × 16-Bilddatei (hier 128 Farben belegt).
• Jeder Würfel zeigt auf genau einen Bildpunkt → eine flache Farbe je Quader.
• Umfärben heißt: die PNG in einem Bildprogramm ändern. Kein UV-Atlas, kein Verrutschen.

4 · Test mit einem einfachen Modell (Materialfarben)

5 · Prüfergebnisse

Was die Python-Prüfung kontrolliert (328 Einzelprüfungen)

Rundlauf in echter Blockbench-Software

Blockbench 5.2.1 (Original, aus dem Quelltext gebaut) hat die erzeugten Dateien geöffnet — über denselben Codec, den auch das Datei-Menü benutzt — und wieder nach Bedrock exportiert:

Dabei kamen zwei Feinheiten heraus, die jetzt fest eingebaut sind: Blockbench nennt das Bedrock-Entity-Format intern bedrock (nicht bedrock_entity), und es spiegelt Bedrock-Entity-Modelle in der X-Achse. Die .bbmodel-Datei speichert die X-Werte deshalb in der Editor-Konvention — dadurch sieht man in Blockbench dasselbe wie im Spiel und der Rückexport trifft unsere Datei exakt.

6 · Was herauskommt (Dateien)

Fertige Installationsdateien (.mcaddon)

Zu jedem Paket gibt es _statue.mcaddon und _block.mcaddon einzeln. Alles liegt in test-model-addons/ samt LIESMICH und Vorschaubildern (aus den Exportdateien gerendert).

Alle Pakete, Testskripte und Protokolle liegen im Arbeitsbereich: voxel-studio-ausgaben/ (ZIPs), mc-voxel-studio/ (Werkzeug + Modelle), test_voxel_studio_ausgabe.txt, test_bbmodel_ausgabe.txt, pruefe_ausgabe.txt (vollständige Protokolle).

7 · Gefunden und behoben: weiße Flächen im Spiel

Ursache

Wir hatten die Flächen so geschrieben, wie es das Java-Format tut — nämlich als Objekt faces am Würfel:

"faces": { "north": { "uv": [5, 0, 6, 1] }, … }        ← Java-Format, im Spiel wirkungslos

Minecraft Bedrock kennt faces nicht. Bedrock erwartet die Flächen als uv-Objekt direkt am Würfel, und dort als uv + uv_size. Belegt wurde das mit der echten Blockbench-Software als Vorbild: Wir haben in Blockbench 5.2.1 ein Modell mit Per-Face-UV exportiert und die Struktur ausgelesen:

"uv": {
  "north": { "uv": [5, 0], "uv_size": [1, 1] },
  "east":  { "uv": [6, 1], "uv_size": [1, 1] },
  "up":    { "uv": [10, 5], "uv_size": [-1, -1] },   ← oben/unten gespiegelt
  "down":  { "uv": [11, 6], "uv_size": [-1, -1] },   ← (macht Blockbench so)
  …
}

Zweite Abweichung: Bedrock spiegelt die X-Achse gegenüber dem Modell im Editor. Blockbench rechnet beim Export origin.x = -(x + Breite). Unsere Datei enthielt die ungespiegelten X-Werte — die Figur wäre also seitenverkehrt dagestanden. Auch das ist jetzt korrekt. Gegenprobe aus zwei unabhängigen Quellen: ein Projekt, das die Achsenfrage in Bedrock auf einem Android-Gerät nachgemessen hat („Bedrock's X axis runs opposite Java's, and a cube's origin is 8 − to.x"), und die Blockbench-Quelle selbst (template.origin[0] = -(origin[0] + size[0])).

Was wir geändert haben

Wie es jetzt aussieht — gezeichnet allein aus der Exportdatei

Die folgenden Bilder sind nicht aus dem Werkzeug, sondern aus der fertigen .geo.json + Palette-PNG gezeichnet: X-Spiegelung rückgängig, Flächenfarbe aus uv/uv_size gelesen — also genau das, was Minecraft zeichnet (links vorn, rechts von der Seite):

• Die Palette des Roboters: 12 belegte Pixel, 16 × 16 Bildpunkte groß.
• Jeder Würfel zeigt auf genau einen dieser Bildpunkte — vorher hat das Spiel diese Angabe ignoriert und die ganze 16 × 16-Fläche auf jede Seite gelegt.

Neue Gegenprüfungen (dauerhaft im Testlauf)

• Strukturvergleich mit Blockbench: Unsere Würfel müssen exakt dieselben Felder tragen wie ein von Blockbench exportiertes Modell (origin, size, uv; je Fläche uv, uv_size; kein faces).
• Spiel-Simulation: Der Test liest die fertige Datei so, wie Minecraft sie liest (X-Spiegelung rückgängig, Farbe aus dem UV-Rechteck) und vergleicht jeden Würfel mit dem, was die Vorschau zeigt — Lage und Farbe. Für Roboter (95) und Dämonenmädchen (4 592 Würfel): identisch.
• Rundlauf in Blockbench 5.2.1 über vier Modelle: 42/42 Prüfungen.

8 · Mehr Details: die Detailstufen

„Detaillierter" heißt bei einem Voxelmodell: feinere Voxel und mehr Farben. Beides war begrenzt — die Auflösung endete bei 96, die Palette bei 256 Farben (16 × 16 Textur). Nach mehreren Ausbaustufen geht die Auflösung jetzt bis 256 (gemessenes Maximum, darüber sprengt der Browser-Speicher), die Palette bis 4 096 Farben (64 × 64), und in der Oberfläche gibt es acht fertige Stufen, die alle Werte zusammen setzen. Die Würfelkante ist dabei Höhe ÷ Voxelzahl — kleinere Würfel bekommt man also über eine höhere Auflösung oder eine niedrigere Bauhöhe.

Das Dämonenmädchen in acht Stufen

Wie man die Würfel weiter verkleinert, obwohl die Auflösung am Anschlag ist: Die Würfelkante ist Bauhöhe ÷ Voxelzahl. Bei gleicher Auflösung (256) und gleicher Würfelzahl wird jeder Würfel also kleiner, wenn die Figur kleiner gebaut wird — 4 Blöcke hoch = 1/48 Block, 3 Blöcke = 1/64, 2 Blöcke = 1/97. Die Optik bleibt dabei identisch, nur der Maßstab ändert sich; die Figur reicht am Ende von den Füßen bis unter die Augen eines Spielers.

Was dabei zusätzlich verbessert wurde

• Kompakte Modelldateien: Die Geometrie wird jetzt ohne Einrückung geschrieben. Aus 19,5 MB wurden bei „sehr fein" 5,4 MB — gleicher Inhalt, nur ohne Leerraum.
• Größere Palette: Über 256 Farben wächst die Palette automatisch auf 32 × 32 Bildpunkte, über 1 024 auf 64 × 64; die UVs folgen der Texturbreite (geprüft bis 4 096 Farben).
• Ehrliche Warnung: Über 2 500 Würfel meldet das Protokoll, dass es im Spiel zäh werden kann; über 10 000 Würfel warnt es deutlich und nennt die passende Gegenmaßnahme.
• Neue Kontrollen: Der Browsertest prüft außerdem, dass jede Stufe gültige Werte setzt (Höhe 0 hätte eine Würfelgröße von 0 ergeben — jetzt fängt das Werkzeug das ab) und dass Palette und Helligkeit über die 256-Farben-Grenze hinweg stimmen.
• Speicher schonen: Zwischenergebnisse (Geometrie-Baum, Blockbench-Baum, Layout-Listen) werden nach dem Export freigegeben und die Flächen-Objekte geteilt — vorher kam bei den hohen Stufen der Speicher an seine Grenze. Zusätzlich gibt es den Aufruf ?ohne3d=1 (Live-Vorschau aus, Umwandlung und Download laufen vollständig) und ab 40 000 Würfeln wird die 3D-Vorschau automatisch ausgelassen.

Der Fehler, der die hohen Stufen unbrauchbar machte

Beim Nachmessen fiel auf, dass die Figur bei 1 024, 2 048 und 4 096 Farben dunkler und körnig aussah als bei 256 Farben. Ursache: Die Zuordnung „Voxel → Palettenfarbe" lag in einem Uint8Array — das kann nur Werte bis 255 speichern. Bei größeren Paletten lief der Index still über (Rechenwert modulo 256), und jeder Würfel bekam die Farbe eines beliebigen anderen Eintrags. Das Werkzeug warf keine Fehlermeldung und kein Test schlug an, weil die Modelldatei formal einwandfrei war — nur die Farben waren falsch.

Behoben mit einem Uint16Array ab 257 Farben. Zusätzlich prüft ein neuer Test jetzt genau das: Bei 256 und bei 4 096 Farben wird die durchschnittliche Helligkeit aller Würfel verglichen (101,6 gegen 101,3) und kontrolliert, dass wirklich mehr als 256 verschiedene Farben ankommen (2 807 von 2 807 möglichen). Alle Pakete wurden danach neu erzeugt.

9 · Als Mod-Version

Auf Wunsch gibt es das Ganze jetzt nicht mehr nur als Test-Addon, sondern als richtige Mod-Version: mit deutschem Namen im Spiel, eigenem Spawn-Ei im Kreativ-Inventar und Paket-Symbol. Der Ordner Minecraft-Bedrock-MOD-Version/ enthält 11 Mod-Dateien mit deutschen Dateinamen, dazu eine ausführliche MOD-LIESMICH.txt und drei Vorschaubilder.

10 · Einbau in Minecraft Bedrock

1. Paket entpacken. Die vier Ordner <name>_rp, <name>_bp, <name>_block_rp, <name>_block_bp in den Ordner resource_packs bzw. behavior_packs kopieren (Windows: %LOCALAPPDATA%\Packages\Microsoft.MinecraftUWP_8wekyb3d8bbwe\LocalState\games\com.mojang\, Android/iOS entsprechend im com.mojang-Ordner).
2. Oder .mcpack bauen: den Inhalt eines Ordners (manifest.json ganz oben) zippen, Endung .zip → .mcpack umbenennen, Datei öffnen. Minecraft importiert sie selbst. (Steht genauso in der mitgelieferten ANLEITUNG.txt.)
3. Welt bearbeiten → Resource Packs und Behavior Packs aktivieren. Kein Experiment-Schalter nötig.
4. Statue beschwören:

   /summon statue:tripo_demon_girl ~ ~ ~

   Block setzen (1×1):

   /setblock ~ ~ ~ statue:tripo_demon_girl

   Entfernen:

   /kill @e[type=statue:tripo_demon_girl,r=20]