Modelldaten sind Textdateien mit Informationen zur dreidimensionalen Darstellung von Spielelementen. Zur Zeit gibt es Modelldaten für alle Blöcke und Gegenstände, aber noch nicht für die Objekte.
Arten[]
- Blockmodelle werden nur zur Darstellung der Blöcke in der Spielwelt verwendet.
- Gegenstandsmodelle dienen zur Darstellung der Blöcke und Gegenstände in der Hand oder auf dem Kopf des Spielers, als Drop auf dem Boden, im Inventar oder in einem Rahmen. Dabei übernehmen die Gegenstandsmodelle oft die Blockmodelle, sodass diese nicht zweimal definiert werden müssen. Doch nicht alle Blöcke werden als Gegenstand dreidimensional dargestellt, einige haben spezielle Gegenstandsmodelle, die flach aussehen, weil das besser erkennbar ist (z.B. Setzling).
- Für die beweglichen Objekte, zu denen z.B. die Kreaturen gehören, gibt es zur Zeit noch keine Modelldaten. Deren Modelle sind noch fest im Programm codiert.
Herkunft[]
- minecraft.jar: Die Original-Modelldaten stehen in minecraft.jar.
- assets: Die Standard-Ressourcen.
- minecraft: Die Minecraft-Standard-Ressourcen.
- blockstates: Die Blockzustandsdateien, jeweils mit Verweis auf das zugehörige Blockmodell. Die Dateinamen sind vom Spiel fest vorgegeben und können nicht geändert werden.
- models: Die Modelldaten.
- block: Die Blockmodelldateien, auf die von den Blockzustandsdateien verwiesen wird. Im Gegensatz zu diesen können die Dateinamen der Modelle beliebig lauten und auch in Unterordnern vorhanden sein, wichtig ist nur, dass sie von den Blockzustandsdateien exakt referenziert werden.
- item: Die Gegenstandsmodelldateien. Die Dateinamen der Modelle sind vom Spiel vorgegeben und können nicht geändert werden.
- textures: Die Modelldaten greifen auf die Texturdaten zurück, ohne die sie nicht sichtbar wären.
- minecraft: Die Minecraft-Standard-Ressourcen.
- assets: Die Standard-Ressourcen.
Änderbarkeit[]
Die Modelldaten sind Teil der Standard-Ressourcen und können mit Ressourcenpaketen geändert werden.
- Dabei ist möglich: Ändern des Aussehens für einen existierenden Block in einem bestimmten, existierenden Blockzustand.
- Nicht mit dem Originalspiel möglich: Die Eigenschaften eines Blockes ändern (Transparenz, Leuchtstärke etc.), einen Blockzustand hinzufügen oder entfernen, oder einen Block hinzufügen oder entfernen. So etwas ist nur mit Modifikationen möglich.
Die Modelldaten haben den Dateityp .json (JavaScript Object Notation), sind aber ganz normale Textdateien, die mit jedem Texteditor gelesen und verändert werden können. Die zugehörigen Texturdaten haben den Dateityp .png und können mit Bildbearbeitungsprogrammen verändert werden.
Um eine Datei auszutauschen, legt man ein Ressourcenpaket an und platziert die entsprechende Datei mit dem richtigen Namen im richtigen Ordner (siehe Ressourcenpaket-Aufbau). Das bedeutet, man muss nicht alle Modelle in ein Ressourcenpaket stellen, sondern nur das, welches man verändert hat. Im Minimalfall ist das nur ein einziges. Beispiel:
.minecraft/resourcepacks/Name des Ressourcenpakets/assets/minecraft/models/block/beacon.json
Das Spiel enthält eine spezielle Welt mit allen Blöcken in allen ihren Varianten. Dazu muss man eine Welt im Debug-Modus erzeugen und kann neue Blockmodelle testen.
Funktionsweise[]
Wenn ein Block dargestellt werden soll, stellt das Spiel zunächst seinen Blockzustand fest (siehe im Debug-Bildschirm oben rechts). Viele Blöcke haben keinen besonderen Zustand (Beispiel Melone), manchen haben einen Zustand (die Ausrichtung des Kürbis), manche mehrere (bei der Tür: Ausrichtung, Hälfte, Scharnierseite, Öffnung und Redstoneaktivierung). Durch Kombination der Zustände ergeben sich bei der Tür 64 Varianten.
Die Zustände sind im Programm festgelegt und können nicht geändert werden. Aber es existiert für jeden Block eine Blockzustandsdatei, die alle Zustände in allen Varianten auflistet und jeder Variante eine Blockmodelldatei zuordnet. Dadurch sieht jede Variante anders aus und der Spieler kann sie optisch voneinander unterscheiden. Man kann sich das in einer Debug-Modus-Welt anschauen.
In der Blockmodelldatei ist beschrieben, wie das Blockmodell aussieht, wobei Modelle, die von mehreren Blöcken benutzt werden (z.B. der normale Würfelblock) in zentrale Dateien ausgelagert sind, auf die von all diesen Blöcken zugegriffen wird.
Neben dem Konstruktionsmodell wird das Aussehen auch von der Textur bestimmt. Dazu lädt jedes Blockmodell die zugehörige Texturdatei. Nun sind alle Informationen vorhanden, um den Block darzustellen.
Die Darstellung von Gegenständen funktioniert ähnlich, nur ohne Zustandsdateien. Gegenstände, die dreidimensional dargestellt werden (meistens Blöcke) werden aus einem Blockmodell geladen. Flach dargestellte Gegenstände (das gilt auch für einige Blöcke) haben dagegen gar kein Konstruktionsmodell, sie werden programmintern aus der Textur generiert. Und dann gibt es noch einige Sonderfälle für bewegliche Gegenstände wie Uhr und Kompass.
Datenstruktur[]
Fachbegriffe[]
- UV: Dieser Begriff ist keine Abkürzung, sondern bezeichnet die Koordinaten einer Fläche, welche zu einem dreidimensionalen Körper gehört. Die Koordinaten eines Körpers werden üblicherweise mit XYZ bezeichnet, sodass sie nicht auch noch für dessen Oberfläche verwendet werden können. Dafür haben sich andere Buchstaben des Alphabetes eingebürgert, nämlich U und V. In Grafikprogrammen bezeichnet UV die Textur der Körper.
- Rendering: Das Umrechnen von Koordinaten, Texturen und sonstigen Informationen in ein Bild. Für Animationsfilme kann das Rendern für jedes einzelne Bild mehrere Stunden dauern, was kein Problem ist, weil sich der fertige Film nicht mehr ändert. Rendern in Echtzeit muss dagegen sehr schnell sein, damit die Illusion des bewegten Bildes erhalten bleibt. Eine Bildrate von 60 fps (Bilder pro Sekunde) bedeutet 60 Rendervorgänge pro Sekunde. Je weniger Flächen und Details gerendert werden müssen, desto flüssiger erscheint die Bildbewegung.
- Culling: Das Aussondern (engl. culling) von Flächen aus dem Rendervorgang, um diesen zu beschleunigen. Beispielsweise werden alle Flächen außerhalb des Sichtfeldes ausgesondert. Ebenso alle Rückseiten. Zusätzlich kann man auch Vorderseiten aussondern, wenn diese verdeckt sind.
Vererbung[]
Die Modelldateien nutzen das Konzept der Vererbung, das viel Schreibarbeit spart: Häufig wiederkehrende Eigenschaften werden nur einmal aufgeschrieben und alle Modelle, für die diese Eigenschaften zutreffen, verweisen darauf. Die Modelle sind in diesem Konzept die Kinder, die die Eigenschaften der Eltern (parent) erben. Besondere Rollen spielen folgende Modelldateien:
- block/block: alle Blöcke
- block/cube: alle soliden Würfelblöcke (für spezielle Blockgruppen gibt es weitere cube-Modelldateien)
- block/orientable: alle Blöcke mit markanter Vorderseite (z.B. Ofen, ähnlich ist block/orientable_vertical)
- block/cross: alle Blöcke mit gekreuzten Texturen (z.B. Setzling)
- block/crop: alle Ackerpflanzenblöcke (z.B. Weizenpflanzen)
- item/generated: alle flachen Gegenstände
- item/handheld: alle Gegenstände, die senkrecht in der Hand gehalten werden, (z.B. Stock)
Neben diesen gibt es noch weitere allgemeine Modelldateien für bestimmte Blockgruppen, z.B. alle Teppiche (block/carpet) oder alle Knöpfe (block/button). Die meisten allgemeinen Block- und Gegenstands-Modelldateien haben das Präfix template_ im Namen.
Das folgende Beispiel zeigt die rote Wolle. Es beginnt mit der Datei block/block
, die für alle Blöcke die Drehung und Skalierung für die unterschiedlichen Anzeigen (linke Hand, rechte Hand, Inventar, Drop etc.) festlegt.
Die Datei cube.json
erbt die Eigenschaften von block/block
(parent) und legt zusätzlich die Größe aller soliden Blöcke fest (from, to) sowie die Texturen ihrer sechs Seiten (faces).
Die Datei cube_all.json
gilt für alle Blöcke, die dieselbe Textur für alle Seiten verwenden. Die Datei erbt die Eigenschaften von block/cube
(parent) und legt fest, dass jede Seite dieselbe Textur #all
verwenden soll. Es gibt noch weitere cube-Modelle, z.B. cube_bottom_top.json
, die für Unter- und Oberseite spezielle Texturen vorsieht, während die vier Seiten gleich aussehen.
Das Modell red_wool.json
erbt schließlich die Eigenschaften von block/cube_all
und legt nur noch fest, dass für all
die rote Wolltextur verwendet werden soll. Nicht nur die Modelle für die 15 anderen Wollblöcke, sondern für sämtliche Blöcke mit sechs gleichen Texturen sind so kurz wie das für den roten Wollblock.
Dateiname: assets/minecraft/models/block/cube.json { "parent": "block/block", "elements": [ { "from": [ 0, 0, 0 ], "to": [ 16, 16, 16 ], "faces": { "down": { "texture": "#down", "cullface": "down" }, "up": { "texture": "#up", "cullface": "up" }, "north": { "texture": "#north", "cullface": "north" }, "south": { "texture": "#south", "cullface": "south" }, "west": { "texture": "#west", "cullface": "west" }, "east": { "texture": "#east", "cullface": "east" } } } ] } Dateiname: assets/minecraft/models/block/cube_all.json { "parent": "block/cube", "textures": { "particle": "#all", "down": "#all", "up": "#all", "north": "#all", "east": "#all", "south": "#all", "west": "#all" } } Dateiname: assets/minecraft/models/block/red_wool.json { "parent": "block/cube_all", "textures": { "all": "block/red_wool" } }
Blöcke[]
Die Hitboxen (und ggf. davon abweichende Kollisionsboxen) der Blöcke sind zur Zeit noch fest im Programm codiert. Wenn man also ein Blockmodell mithilfe eines Ressourcenpaketes ändert, kann man nur die Darstellung, nicht die Hitbox ändern. Auch alle weiteren Eigenschaften der Blöcke sind noch fest codiert, wovon für die Lichtberechnung die Transparenz entscheidend ist. Verkleinert man also das Blockmodell des Schwammes z.B. auf ein Viertel, wird er trotzdem eine Hitbox in voller Blockgröße haben und trotz umgebender Luft kein Licht durchlassen.
Geändertes Blockmodell für den Schwamm. Hitbox und Transparenz können nicht geändert werden, daher bedeckt er trotz Verkleinerung den ganzen Blockboden, der schwarz erscheint |
Geändertes Blockmodell für die Quarzsäule. Auch sie bedeckt trotz Verkleinerung den ganzen Blockboden, weshalb der gemeißelte Quarzblock ebenfalls verändert wurde (kein Culling) |
Links: Blockmodell der Quarzsäule zwischen beliebigen soliden Blöcken (hier Quarzblöcke). Man erkennt, dass die Säule trotz optischer Verkleinerung die gesamte Blockfläche bedeckt, die dadurch durchsichtig wird Rechts: Der veränderte gemeißelte Quarzblock wird nicht durchsichtig, daher kann die Säule problemlos auf ihm stehen |
Verändertes Blockmodell der gefärbten Wolle |
Blockzustände und Varianten[]
Der Ordner assets/minecraft/blockstates
enthält für jeden Block eine Blockzustandsdatei, die alle Zustandsvarianten des Blockes auflistet und mit den entsprechenden Modellen verlinkt. Da man diese Verlinkung ändern kann, ist es möglich, auf die Darstellung jedes einzelnen Blockzustandes Einfluss zu nehmen. Blöcke ohne besonderen Zustand haben auch eine Blockzustandsdatei mit einem namenlosen Zustand ""
.
Wenn ein Block in einem bestimmten Zustand dargestellt werden soll, schaut das Spiel in die Blockzustandsdatei und sucht dort den zugehörigen Variantennamen. Wenn ein Ressourcenpaket geladen ist und für den Block eine Blockzustandsdatei enthält und dort der Variantenname fehlt oder verändert wurde, findet ihn das Spiel nicht und holt ihn aus den Standard-Ressourcen (bzw. untergeordneten Ressourcenpaketen), um den Block anzuzeigen.
Alternative Blockmodelle[]
Üblicherweise wird ein Blockzustand durch ein einziges Modell dargestellt. Es ist aber auch möglich, alternative Modelle oder Texturen anzuwenden. Im Spiel wird das mit einigen Blöcken gemacht, die in großen Mengen zu sehen sind, wie Sand, Stein oder das Seerosenblatt. Die alternativen Modelle sind dabei gedreht, sodass bei großen Flächen ein natürlicherer Gesamteindruck entsteht. Die Drehung ist aber nur eine Möglichkeit für alternative Blockmodelle, in Ressourcenpaketen können sie auch unterschiedliche Texturen haben (z.B. Sand mit Muscheln oder Seesternen). Das Konzept der alternativen Modelle hat folgende Eigenschaften:
- Die Anzahl ist frei wählbar. Im Spiel sind es häufig vier, weil es nur vier Drehungsmöglichkeiten einer Seitentextur gibt. Der Netherrack hat aber z. B. 16 alternative Drehungen, weil seine Seiten unterschiedliche Texturen haben.
- Die Verteilung ist zufällig und ortsgebunden. Das heißt, an einer bestimmten Position (XYZ-Koordinate) wird stets dasselbe Blockmodell gezeigt, egal wie oft man den Block dort abbaut und wieder setzt, und egal in welcher Welt und Dimension man sich befindet. Daher ist es nicht möglich, ein bestimmtes Blockmodell an einer bestimmten Position zu platzieren. Aus diesem Grund ist es auch nicht sinnvoll, Teiltexturen zu erstellen, die zusammengenommen ein größeres Bild ergeben, z. B. die vier Teile einer großen Wasserpflanze.
- Die Alternativen wirken sich immer nur auf die Darstellung der Blöcke in der Landschaft aus. Sobald der Block abgebaut wird, wird nicht mehr das Blockmodell, sondern das Gegenstandsmodell verwendet, das keine Alternativen kennt. Man erhält dann immer den normalen Block. Erst wenn dieser erneut in der Landschaft platziert wird, erscheinen wieder die alternativen Blockmodelle an ihren festen Positionen.
- Alternative Blockmodelle können vom Spiel nicht erkannt werden. Für das Spiel sind alle Alternativen derselbe Block.
Fehlende Blockmodelle[]
Bislang fehlen noch die Modelle für einige Blöcke. Ihre Darstellung ist weiterhin im Programm fest codiert:
- Wasser und Lava mit ihren zahlreichen Zusammenfluss-Kombinationen,
- Schilder, Banner und Köpfe mit ihren Schildbeschriftungen, Bannermustern und Kopftexturen,
- alle Truhen und die Shulker-Kiste mit ihrer Öffnungsanimation,
- alle Betten mit dem Problem, dass darin auch der Spieler liegen kann,
- die Buch-Animation des Zaubertisches (für die Basis des Tisches gibt es ein Modell),
- der Aquisator, der beweglich sein kann,
- Endportal und Endtransitportal (für das Netherportal existiert ein Modell),
- der bewegte Block, der die Verschiebeanimation bei Kolben darstellt,
- die unsichtbare Barriere.
Zwar gibt es Modelldateien für diese Blöcke, die enthalten aber nur die Definition der Abbau-Partikeltextur und nicht das Konstruktionsmodell für den Block.
Das einzige Objekt, für das es bereits ein Modell gibt, ist der Rahmen. Er ist zur Zeit bei den Blöcken einsortiert.
Datenstruktur der Blockzustandsdateien[]
- Die namenlose Haupteigenschaft.
- variants: Beinhaltet alle Varianten eines Blockes.
- Name der Variante: Eine Variante. Der Name ist vom Spiel fest vorgegeben und kann nicht geändert werden. Bei einem Block mit nur einer Variante ist der Variantenname leer
""
. Wenn ein Block seinen Zustand verändern kann, hat jede Zustandsveränderung einen eigenen Variantennamen. Für die Wachstumsphasen der Netherwarze heißen die Variantennamen beispielsweise:"age=0"
,"age=1"
,"age=2"
und"age=3"
. Das Gleichheitszeichen ist hier Teil des Namens. Bei Blöcken mit mehreren Zuständen sehen die Varianten wie eine Auflistung aus, sind aber trotzdem als Ganzes ein fest vorgegebener Name, den man nicht ändern kann. Bei den Türen heißt der erste Variantenname z. B.:"facing=east,half=lower,hinge=left,open=false"
. Alle Zustände und Varianten sind im Spiel fest codiert, man kann keine ändern oder hinzufügen.
Durch die Zuordnung von Varianten zu Blockmodellen kann jeder einzelne Blockzustand anders dargestellt werden, sodass der Spieler die Blockzustände optisch voneinander unterscheiden kann (z.B. Zauntor offen, Zauntor geschlossen). Das muss aber nicht unbedingt so sein: Der Ackerboden hat zwar einen Bewässerungszustand in acht Varianten, aber die ersten sieben verweisen auf dasselbe Blockmodellblock/farmland
, lassen ihn also trocken aussehen. Erst der letzte Zustand"moisture=7"
verweist auf das Blockmodellblock/farmland_moist
. Der Spieler kann daher die Zustände"moisture=0"
bis"moisture=6"
optisch nicht voneinander unterscheiden. Da es trotzdem acht Varianten gibt, kann man diese mit einem Ressourcenpaket für eine unterschiedliche Darstellung nutzen.
Einer Variante kann genau ein Modell zugeordnet sein oder eine Liste von alternativen Modellen. Wenn der Variante genau ein Modell zugeordnet ist, kann die Listenklammerung weggelassen werden. Wenn der Variante eine Liste von alternativen Modellen zugeordnet ist, wird vom Spiel abhängig von den XYZ-Koordinaten und der weight-Eigenschaft zufällig ein Modell ausgewählt.- Ein Modell.
- model: Der Name des Modells ab dem Pfad
assets/minecraft/models/
und ohne Dateiendung. Beispiel: Der Name "block/beacon" verweist auf die Modelldatei "assets/minecraft/models/block/beacon.json". Wenn man eigene Modelldateien verwenden möchte, gibt man den Namen entsprechend an. Beispiel: Der Name "alle_tische/mit_tischdecke" verweist auf die Modelldatei "assets/minecraft/models/alle_tische/mit_tischdecke.json". Wenn zu dem Namen keine Modelldatei gefunden werden kann, wird der Block mit der fehlenden Textur angezeigt. - uvlock: true oder false. Der Wert false ist Standard und kann weggelassen werden. true bedeutet, dass bei einer Drehung des Blockmodells um die X- oder Y-Achse die Textur (UV) nicht mitgedreht wird. Dadurch erhalten nebeneinanderstehende und verschieden gedrehte Blöcke (z.B. Treppen) eine Textur, die sich einheitlich über alle Blöcke zieht. Ohne UV-Lock wird die Textur mitgedreht, was im Fall der Treppen einen uneinheitlichen Anblick ergäbe. Umgekehrt würde beim Kürbis der UV-Lock bewirken, dass das Gesicht immer in dieselbe Richtung zeigt, egal, wie man den Kürbis platziert.
- weight: Die Gewichtung zur Verteilung alternativer Blockmodelle in der Landschaft. Ohne Angabe ist dieser Wert 1. Zur Ermittlung der Wahrscheinlichkeit wird der Wert durch die Summe aller Werte einer Modellliste geteilt. Beispiele:
• Die Variante hat nur ein einziges Modell und der Wert ist 70 => Die Summe ist 70 => Die Wahrscheinlichkeit für den Block ist 70⁄70 = 100%. Der Block erscheint also immer.
• Die Variante hat drei alternative Modelle und die Werte sind 5, 70 und 300 => Die Summe ist 375 => Die Wahrscheinlichkeit für das 5er-Modell ist 5⁄375 = 1,3%, für das 70er-Modell 70⁄375 = 18,7% und für das 300er-Modell 300⁄375 = 80%.
• Die Variante hat drei alternative Modelle, aber nur eins hat einen Wert, nämlich 10 => Die Summe ist 12 => Die Wahrscheinlichkeit für die beiden Modelle ohne Wert ist jeweils 1⁄12 = 8,3% und für das Modell mit Wert 10⁄12 = 83,3%.
• Die Variante hat vier alternative Modelle ohne Wert => Die Summe ist 4 => Die Wahrscheinlichkeit für alle Modelle ist jeweils 1⁄4 = 25%.
Das heißt, wenn einer Variante alternative Blockmodelle zugeordnet sind, erscheint das Modell mit der höchsten Gewichtung am häufigsten in der Landschaft. - x: Rotation des Modells um die X-Achse in 90° Schritten. Die X-Achse verläuft waagerecht in West-Ost-Richtung. Es gibt nur wenige Blöcke, die so gedreht werden. Sie können dadurch auf dem Boden bzw. an der Decke platziert werden, z.B. Treppen, Knöpfe, Hebel, Kolben, Werfer und Spender. Interessanterweise gibt es keine Drehung um die Z-Achse, die in Nord-Süd-Richtung verläuft, die Angabe eines z-Wertes wird ignoriert.
- y: Rotation des Modells um die Y-Achse in 90° Schritten. Die Y-Achse verläuft senkrecht. Anwendungsbeispiel sind alle Blöcke, die in verschiedene Himmelsrichtungen zeigen können, z. B. der Kürbis und die Blöcke mit gedrehten Alternativen, z.B. das Seerosenblatt.
- model: Der Name des Modells ab dem Pfad
- Ein Modell.
- Name der Variante: Eine Variante. Der Name ist vom Spiel fest vorgegeben und kann nicht geändert werden. Bei einem Block mit nur einer Variante ist der Variantenname leer
- multipart: Wenn es sehr viele Varianten eines Blockes gibt, kann statt der variants-Auflistung das Blockmodell in unabhängige Teile zerlegt werden, die mit multipart kombiniert werden. Dabei kann für jedes Teilmodell eine Bedingung angegeben werden (siehe Beispiel: Birkenholzzaun). multipart ist eine geordnete Liste, d.h. die Darstellung der Teilmodelle wird in der angegebenen Reihenfolge abgearbeitet.
- Darstellung eines Teilmodells.
- when: Optional kann die Darstellung mit einer when-Bedingung verknüpft sein. Wenn die when-Bedingung fehlt, wird das Teilmodell immer dargestellt.
- OR: Zur Veroderung von Bedingungen wird mit OR eine Liste angegeben. Sobald eine Bedingung der Liste erfüllt ist, ist die Veroderung insgesamt erfüllt. Benötigt man keine Veroderung, lässt man die Liste weg und schreibt stattdessen nur eine einzige Bedingung.
- Eine Bedingung besteht aus einem einzelnen Fall oder einer Aufzählung von Fällen. Wenn es eine Aufzählung ist, muss jeder Fall erfüllt sein, damit die Bedingung insgesamt erfüllt ist.
- Name des Blockzustandes: Wert des Blockzustandes. Ein Fall ist ein Blockzustand und sein Wert, z.B.
"north":"none"
. Es ist auch möglich, mehrere Werte zu verodern, dazu wird ein senkrechter Strich verwendet, z.B."north":"side|up"
.
- Name des Blockzustandes: Wert des Blockzustandes. Ein Fall ist ein Blockzustand und sein Wert, z.B.
- Eine Bedingung besteht aus einem einzelnen Fall oder einer Aufzählung von Fällen. Wenn es eine Aufzählung ist, muss jeder Fall erfüllt sein, damit die Bedingung insgesamt erfüllt ist.
- OR: Zur Veroderung von Bedingungen wird mit OR eine Liste angegeben. Sobald eine Bedingung der Liste erfüllt ist, ist die Veroderung insgesamt erfüllt. Benötigt man keine Veroderung, lässt man die Liste weg und schreibt stattdessen nur eine einzige Bedingung.
- apply: Darstellung des Teilmodells wie bei variants (siehe oben). Das kann genau ein Modell oder eine Liste von alternativen Modellen sein.
- when: Optional kann die Darstellung mit einer when-Bedingung verknüpft sein. Wenn die when-Bedingung fehlt, wird das Teilmodell immer dargestellt.
- Darstellung eines Teilmodells.
- variants: Beinhaltet alle Varianten eines Blockes.
Beispiel: Fackel[]
Für die Fackel gibt es zwei unterschiedliche Blöcke: die aufrecht stehende und die Wandfackel. Jeder Block hat seine eigene Blockzustandsdatei. Die aufrecht stehende Fackel hat keinen besonderen Zustand, daher ist der Name leer ""
. Das zugehörige Modell ist block/torch
.
Für die Wandfackel gibt es vier Varianten "facing=east"
, "facing=west"
, "facing=south"
und "facing=north"
, die immer dasselbe Modell "block/wall_torch"
verwenden, aber je nach Variante um ein Vielfaches von 90° auf der Y-Achse gedreht.
Dateiname: assets/minecraft/blockstates/torch.json { "variants": { "": { "model": "block/torch" } } } Dateiname: assets/minecraft/blockstates/wall_torch.json { "variants": { "facing=east": { "model": "block/wall_torch" }, "facing=south": { "model": "block/wall_torch", "y": 90 }, "facing=west": { "model": "block/wall_torch", "y": 180 }, "facing=north": { "model": "block/wall_torch", "y": 270 } } }
Beispiel: Grasblock[]
Der Grasblock hat die zwei Varianten "snowy=false"
und "snowy=true"
, wobei die erste durch vier alternative Modelle dargestellt werden kann. Dabei handelt es sich jeweils um dasselbe Modell "block/grass_block"
, nur gedreht. Ohne weitere Angabe werden alle vier Alternativen gleich häufig dargestellt, sodass durch die gedrehten Grastexturen eine natürlichere Grasoberfläche entsteht. Zu beachten ist hier die Angabe einer Liste, in JSON wird sie mit [ ]
geklammert.
Dateiname: assets/minecraft/blockstates/grass_block.json { "variants": { "snowy=false": [ { "model": "block/grass_block" }, { "model": "block/grass_block", "y": 90 }, { "model": "block/grass_block", "y": 180 }, { "model": "block/grass_block", "y": 270 } ], "snowy=true": { "model": "block/grass_block_snow" } } }
Beispiel: Birkenholzzaun[]
Der Zaun wird je nach zutreffenden Blockzuständen aus Teilmodellen zusammengesetzt (multipart
). Der senkrechte Pfosten block/birch_fence_post
wird immer angezeigt (apply
ohne when
). Die waagerechten Balken block/birch_fence_side
werden nur dann angezeigt, wenn in der entsprechenden Richtung ein Verbindungsblock ist, was durch die vier Zaun-Blockzustände north, south, east, west
, die vom Spiel ermittelt wurden, vorgegeben wird. Statt alle 16 möglichen Kombinationen als Varianten aufzulisten, werden die Teilmodelle über die when
-Bedingungen zusammengesetzt.
Dateiname: assets/minecraft/blockstates/birch_fence.json { "multipart": [ { "apply": { "model": "block/birch_fence_post" }}, { "when": { "north": "true" }, "apply": { "model": "block/birch_fence_side", "uvlock": true } }, { "when": { "east": "true" }, "apply": { "model": "block/birch_fence_side", "y": 90, "uvlock": true } }, { "when": { "south": "true" }, "apply": { "model": "block/birch_fence_side", "y": 180, "uvlock": true } }, { "when": { "west": "true" }, "apply": { "model": "block/birch_fence_side", "y": 270, "uvlock": true } } ] }
Datenstruktur der Blockmodell-Dateien[]
- Die namenlose Haupteigenschaft.
- parent: Übernimmt (erbt) alle Informationen von einem anderen Modell (siehe Vererbung). Der Pfad muss ab
assets/minecraft/models/
angegeben werden. - textures: Verweis auf die Texturdateien des Modells, wobei der Pfad jeder Textur ab
assets/minecraft/textures/
angegeben werden muss.- particle: Legt die Textur fest, die von den block-Partikeln verwendet wird, d.h. wenn ein Block abgebaut wird oder man auf diesen Block springt. Wenn particle fehlt oder die Textur nicht gefunden wird, wird die fehlende Textur verwendet.
- Name der Texturen-Variable: Der Name kann frei gewählt werden. Sinnvollerweise nimmt man die Bezeichnung der Seite, die diese Textur darstellt, z.B. "top", "bottom", "north" etc. oder wenn alle Seiten gleich aussehen "all" oder "texture". Der Name kann über Vererbung an eine andere Variable übergeben werden, aber ohne Vererbung ist das nicht möglich.
- ambientocclusion: true oder false. Der Wert true ist Standard und kann weggelassen werden. Er bewirkt eine ungleichmäßige Schattierung aller Flächen des Modells, die durch die angenommene Verdeckung (occlusion) der Umgebung (ambience) berechnet wird. Sichtbar ist die Schattierung nur, wenn im Menü/Optionen/Grafikeinstellungen die "weiche Beleuchtung" eingeschaltet ist. Die berechnete Schattierung ist unabhängig vom Sonnenstand und von Lichtquellen. Sie ist nur auf den Flächen dieses Blockes zu sehen, Nachbarblöcke haben ihre eigene Schattierung. Gemeinsam ergibt sich dadurch die Illusion eines Schattenwurfes. Echter Schlagschatten, der durch die Sonne auf andere Blöcke geworfen wird, ist das nicht. So etwas wird nur von Shader-Mods berechnet. Der Wert false muss explizit gesetzt werden, was immer dann sinnvoll ist, wenn es sich um ein relativ kleines Blockmodell handelt, bei dem die Schattierung kaum sichtbar wäre (z.B. Blumen, Eisengitter, Hebel). Durch die Einsparung der Berechnung wird das Rendering beschleunigt. Zusätzlich zu dieser ungleichmäßigen Schattierung gibt es noch eine gleichmäßige Schattierung, siehe die shade-Eigenschaft.
- elements: Alle Elemente eines Blockmodells, wobei die einzelnen Elemente immer nur Quader sein können, mit unterschiedlicher Größe. Die meisten Blöcke bestehen nur aus einem einzigen Element, dem großen Würfel. Blöcke mit mehreren Elementen sind z.B. der Trichter oder der Redstone-Verstärker. Je mehr Elemente ein Block hat, desto mehr nimmt die Renderingzeit zu. Falls Elemente über parent vererbt wurden, werden sie hiermit überschrieben.
- Ein Element.
- from: Startpunkt eines Elements nach dem Schema
[x, y, z]
. - to: Endpunkt eines Elements nach dem Schema
[x, y, z]
. Start und Endpunkt bezeichnen die zwei diagonal gegenüberliegenden Punkte eines Quaders. Der normale Würfel hat den Startpunkt [0, 0, 0] und den Endpunkt [16, 16, 16], wobei der Startpunkt immer links (x) unten (y) hinten (z) und der Endpunkt rechts oben vorne liegen sollte, damit alle anderen Koordinaten dazu passen. Koordinaten kleiner Null oder größer 16 sind auch möglich und ergeben Elemente, die über den Block hinaus ragen. Da sich dadurch die Hitbox des Blockes nicht ändert, kann man aber andere Blöcke in diesen Überhang hineinstellen und ihn verdecken. Auch Kommazahlen sind möglich, sie sind mit einem Punkt zu schreiben. Die Koordinaten sind unabhängig von der Auflösung der Textur. Die Standardtextur einer Blockseite ist 16×16 Pixel groß, sodass zwischen 0 und 1 genau ein Pixel liegt. Bei einer hochauflösenden 128-Pixel-Textur liegen zwischen 0 und 1 schon 8 Pixel. - rotation: Jedes Element kann an einer Achse gedreht werden.
- origin: Rotationsmittelpunkt nach dem Schema
[x, y, z]
. Kommazahlen sind möglich. Ohne Angabe ist der Standard [8, 8, 8], was genau im Zentrum des Würfels liegt. - axis: Rotationsachse, die
"x"
,"y"
oder"z"
sein kann. Eine Rotation um mehrere Achsen ist nicht möglich. - angle: Rotationswinkel. Nur die Werte -45, -22.5, 0, 22.5 und 45 sind möglich. Ohne Angabe wird 0 angenommen, was keine Rotation ergibt.
- rescale: true oder false. Der Wert false ist Standard und kann weggelassen werden. true bewirkt eine Vergrößerung der Flächen nach der Rotation, sodass ihre Projektion auf die Seitenflächen des Blockes den jeweiligen Flächeninhalt vor der Rotation ergibt. Vereinfach gesagt ist dies ein optischer Effekt, dessen Anwendung in manchen Fällen notwendig ist, damit das rotierte Element natürlich aussieht. Genutzt wird diese Funktion bei allen Blöcken mit cross-Texturen (z.B. die Blumen und Setzlinge), weil die Texturen durch die Rotation optisch zu klein wirken.
- origin: Rotationsmittelpunkt nach dem Schema
- shade: true oder false. Der Wert true ist Standard und kann weggelassen werden. Er bewirkt eine gleichmäßige Schattierung der Flächen des Elementes. Dies ist ein rein optischer Effekt um das Element realistischer aussehen zu lassen, Sonnenstand und Lichtquellen werden dabei nicht beachtet. Wie die ambientocclusion-Schattierung ist auch die shade-Schattierung nur sichtbar, wenn im Menü/Optionen/Grafikeinstellungen die "weiche Beleuchtung" eingeschaltet ist. Der Wert false muss explizit gesetzt werden, was immer dann sinnvoll ist, wenn es sich um ein relativ kleines Element handelt, bei dem die Schattierung kaum sichtbar wäre (z.B. Blumen). Durch die Einsparung der Berechnung wird das Rendering beschleunigt.
- faces: Alle Flächen des Elementes, die sichtbar sein sollen. Nicht sichtbare Verbindungsflächen zwischen zwei Elementen sollten aus Beschleunigungsgründen nicht gerendert werden. Sie werden dazu einfach weggelassen.
- down, up, north, south, west oder east: Die Eigenschaften der entsprechenden Fläche. Es sind nur genau diese Flächenbezeichnungen möglich. Betrachtet man eine Seite, schaut man in die Gegenrichtung. Beispiel: Steht man vor einem Block und schaut nach Osten, betrachtet man die Westseite des Blockes.
- texture: Textur für diese Fläche in Form der Texturen-Variable (siehe textures-Eigenschaft). Vor die Variable wird ein
#
gestellt. Hier können nur Texturen-Variablen angegeben werden, keine Namen oder Pfade von Texturdateien. - uv: Optional: Textur-Ausschnitt nach dem Schema
[u1, v1, u2, v2]
. Kommazahlen sind möglich. Blocktexturen sind immer quadratisch und gelten für genau eine Seite des Blockes. Hat ein Block auf seinen Seiten unterschiedliche Texturen, benötigt man dafür mehrere Texturdateien (siehe textures-Eigenschaft). Der Nullpunkt [0, 0] liegt immer links (u) oben (v) auf der Textur, der Maximalwert [16, 16] rechts unten. Die UV-Koordinaten sind unabhängig von der Auflösung der Textur, d.h. zwischen 0 und 1 liegt immer 1⁄16 der Textur. Wenn uv nicht angegeben wird, wird die komplette Textur auf die Fläche gelegt (entspricht dem UV-Ausschnitt [0, 0, 16, 16]). Durch Veränderung der U- und V-Koordinaten kann man auch Ausschnitte für kleinere Flächen wählen. U und V dürfen nicht kleiner 0 oder größer 16 sein, sonst werden Bereiche außerhalb der Textur dargestellt. Der angegebene UV-Ausschnitt wird immer komplett auf die Fläche gelegt. Hat er andere Proportionen, wird er entsprechend skaliert. So kann man auch eine ganze Blockseite mit einem einzigen Pixel ausfüllen oder die gesamte Textur in einen kleinen Ausschnitt pressen. u2 und v2 sollten immer größer als u1 und v1 sein, damit alle anderen Koordinaten dazu passen. - rotation: Dreht die Fläche nach der Auftragung der Textur (siehe uv-Eigenschaft) in 90°-Schritten.
- cullface: Flächenweglassungsrichtung. Wenn in der angegebenen Richtung (nur
down
,up
,north
,south
,west
odereast
möglich) ein solider Block steht, wird die Fläche beim Rendervorgang weggelassen (Culling). Flächen außerhalb des Sichtfeldes und Rückseiten werden schon grundsätzlich nicht gerendert. Hier geht es zusätzlich um das Weglassen einer Vorderseite, wenn sie verdeckt ist. Für jede Fläche eines soliden Blockes wird genau diese Seite auch als cullface angegeben. Wenn z.B. die Westseite eines Blockes durch einen anderen Block verdeckt wird, wird sie beim Rendern weggelassen, denn sie ist sowieso nicht zu sehen. Bei dem anderen Block gilt dasselbe für die Ostseite. Das beschleunigt den Rendervorgang erheblich. Die cullface-Eigenschaft ist nur für Flächen, die genau an einer Blockgrenze liegen, anzugeben. Für Flächen, die weiter innen liegen, ist kein Cullface anzugeben, weil sie aus bestimmten Blickwinkeln noch gesehen werden können. Man kann jedoch auch für sämtliche Flächen eines kleinen Elementes dieselbe Seite als Cullface angeben. Wenn dann ein solider Block auf die angegebene Seite gestellt (oder von einem Kolben dorthin geschoben) wird, verschwindet das Element vollständig, indem alle Flächen automatisch unsichtbar werden. Dies kann man beispielsweise für Signalanlagen oder zur Aufdeckung geheimer Inhalte nutzen. - tintindex: Eine Veränderung des Wertes hat keine Auswirkung. Stattdessen kann durch komplette Weglassung dieser Eigenschaft bewirkt werden, dass die Farbe der Textur nicht mehr biomabhängig ist (tint = Farbton). Dies gilt für bestimmte Blöcke (Laub, Grasblock, Gras, Farn, Ranken und Seerosenblatt). Für alle anderen Blöcke hat die Hinzufügung oder Weglassung keine Auswirkung. Die Farbe ist in den Dateien
assets/minecraft/textures/colormap/foliage.png
undgrass.png
hinterlegt. Möglicherweise kann mit dem Farbtonindex zukünftig auf eine bestimmte Farbe aus der Colormap verwiesen werden.
- texture: Textur für diese Fläche in Form der Texturen-Variable (siehe textures-Eigenschaft). Vor die Variable wird ein
- down, up, north, south, west oder east: Die Eigenschaften der entsprechenden Fläche. Es sind nur genau diese Flächenbezeichnungen möglich. Betrachtet man eine Seite, schaut man in die Gegenrichtung. Beispiel: Steht man vor einem Block und schaut nach Osten, betrachtet man die Westseite des Blockes.
- from: Startpunkt eines Elements nach dem Schema
- Ein Element.
- parent: Übernimmt (erbt) alle Informationen von einem anderen Modell (siehe Vererbung). Der Pfad muss ab
Schattierung:
|
Schattierung:
|
Ambient Occlusion:
|
Rotierte Flächen mit und ohne Rescale |
Zwei alternative Blockmodelle für den Plattenspieler[1][2] |
Blockmodell mit zusätzlichen Elementen zur Veranschaulichung der UV-Koordinaten.
| |
Wenn man z.B. beim Diamanterz die cullface-Eigenschaften für alle sechs Richtungen entfernt, werden die Seiten auch gerendert, wenn sie von einem Nachbarblock verdeckt werden. Dadurch sind sie im Zuschauermodus unter der Erde zu sehen |
Beispiel: stehende Fackel[]
In diesem Beispiel werden die stehenden Fackeln betrachtet. Es gibt drei Varianten, die durch die Blockmodelle redstone_torch.json
, redstone_torch_off.json
und torch.json
definiert werden. Sie legen die jeweilige Textur fest (textures). Da sie alle dasselbe Blockmodell haben, wird dieses in der Datei template_torch.json
beschrieben, die von den drei Varianten geerbt wird (parent). Es gibt noch weitere template_
-Dateien für andere Blockfamilien.
Das Blockmodell besteht interessanterweise nicht aus einem, sondern aus drei Elementen (elements). Dies hat den Zweck, dass die Redstonefackel eine rote Umrandung haben kann oder bei der Fackel eine Flamme in die Textur gezeichnet werden kann, sonst würden diese abgeschnitten und man würde nur die mittleren Pixel sehen. Das Spiel hat allerdings keine Flamme in der Textur, es realisiert die Flamme als Partikel.
In diesem Fall ist das erste Element der in der Zeichung hellblau gefärbte Quader. Von ihm werden nur die Ober- und Unterseite gerendert (faces). Sie erhalten die rosa und gelb markierten Ausschnitte aus der Textur (uv). Das zweite Element ist der in der Zeichung rot gefärbte Quader. Er ist viel zu groß, aber es geht hier nicht um die Hitbox, sondern nur um das Rendern. Seine West- und Ostseite erhalten beide die volle 16×16-Größe der Fackeltextur inkl. der großen durchsichtigen Flächen (blau markierter Ausschnitt der Textur). Dadurch fällt die Fackeltextur genau auf die Mitte, wo sie hingehört. Dasselbe wird für die Nord- und Südseite des dritten Elementes gemacht, das in der Zeichung grün gefärbt ist.
Die Schattengenerierung ( ambientocclusion und shade) wird für alle Fackeln deaktiviert, weil sie zu klein für Schattenflächen sind (und nicht weil sie leuchten, denn die deaktivierte Redstone-Fackel gehört auch dazu).
Dateiname: assets/minecraft/models/block/template_torch.json { "ambientocclusion": false, "textures": { "particle": "#torch" }, "elements": [ { "from": [ 7, 0, 7 ], "to": [ 9, 10, 9 ], "shade": false, "faces": { "down": { "uv": [ 7, 13, 9, 15 ], "texture": "#torch" }, "up": { "uv": [ 7, 6, 9, 8 ], "texture": "#torch" } } }, { "from": [ 7, 0, 0 ], "to": [ 9, 16, 16 ], "shade": false, "faces": { "west": { "uv": [ 0, 0, 16, 16 ], "texture": "#torch" }, "east": { "uv": [ 0, 0, 16, 16 ], "texture": "#torch" } } }, { "from": [ 0, 0, 7 ], "to": [ 16, 16, 9 ], "shade": false, "faces": { "north": { "uv": [ 0, 0, 16, 16 ], "texture": "#torch" }, "south": { "uv": [ 0, 0, 16, 16 ], "texture": "#torch" } } } ] } Dateiname: assets/minecraft/models/block/torch.json { "parent": "block/template_torch", "textures": { "torch": "block/torch" } }
Beispiel: Setzling[]
In diesem Beispiel werden die Setzlinge betrachtet. Es gibt mehrere Varianten, die durch die Blockmodelle acacia_sapling.json
, birch_sapling.json
, dark_oak_sapling.json
, jungle_sapling.json
, oak_sapling.json
und spruce_sapling.json
definiert werden. Sie legen die jeweilige Textur fest (textures). Da sie alle dasselbe Blockmodell haben, wird dieses in der Datei cross.json
beschrieben, die nicht nur von den Setzling-Varianten geerbt wird (parent), sondern von allen Blöcken, die aus einer gekreuzten Textur bestehen: Pilze, Blumen, Gras, Farn, toter Busch und Spinnennetz.
Das Blockmodell besteht aus zwei flachen Elementen (elements). In der Zeichnung wird die Draufsicht des ersten Elements veranschaulicht (grüner Strich). Das Element ist etwas kürzer als der Block (x von 0.8 bis 15.2) und hat keine Dicke (z von 8 bis 8). Es wird 45° um die Y-Achse, die durch den Mittelpunkt des Blockes geht, gedreht (rotation, roter Strich).
Äußerst interessant ist die Tatsache, dass für beide Seiten des Elementes dieselbe Textur verwendet wird, ohne sie zu spiegeln, obwohl sie nicht symmetrisch ist. Das mittlere Bild zeigt die Textur von vorne, von hinten und wie das Ergebnis aussehen würde, wenn beide gerendert würden. Aber da aus Beschleunigungsgründen immer nur die Seite gerendert wird, auf die man schaut, wird die Rückseite nicht gerendert und die asymmetrische Überdeckung ist nicht zu sehen. Daher ist der Stamm des Eichensetzlings immer drei statt vier Pixel breit, egal von wo man schaut.
Nach der Drehung erfolgt noch eine Streckung (rescale, blaue Pfeile) und zwar immer genau auf die Größe, die die ungedrehte Textur hatte. Ohne diese Streckung würde der Setzling zu schmal wirken (rechtes Bild).
Dasselbe geschieht mit dem zweiten Element, wodurch das gekreuzte Blockmodell entsteht.
Die Schattengenerierung ( ambientocclusion und shade) wird für alle Setzlinge deaktiviert, weil sie zu klein für Schattenflächen sind.
Dateiname: assets/minecraft/models/block/cross.json { "ambientocclusion": false, "textures": { "particle": "#cross" }, "elements": [ { "from": [ 0.8, 0, 8 ], "to": [ 15.2, 16, 8 ], "rotation": { "origin": [ 8, 8, 8 ], "axis": "y", "angle": 45, "rescale": true }, "shade": false, "faces": { "north": { "uv": [ 0, 0, 16, 16 ], "texture": "#cross" }, "south": { "uv": [ 0, 0, 16, 16 ], "texture": "#cross" } } }, { "from": [ 8, 0, 0.8 ], "to": [ 8, 16, 15.2 ], "rotation": { "origin": [ 8, 8, 8 ], "axis": "y", "angle": 45, "rescale": true }, "shade": false, "faces": { "west": { "uv": [ 0, 0, 16, 16 ], "texture": "#cross" }, "east": { "uv": [ 0, 0, 16, 16 ], "texture": "#cross" } } } ] } Dateiname: assets/minecraft/models/block/oak_sapling.json { "parent": "block/cross", "textures": { "cross": "block/oak_sapling" } }
Gegenstände[]
Gegenstandszustände und Varianten[]
Die Zustände und Varianten werden direkt in den Gegenstandsmodell-Dateien angegeben (predicate-Eigenschaft), es gibt für Gegenstände keine separaten Zustandsdateien. Das betreffende Gegenstandsmodell erscheint im Inventar des Spielers und wird von anderen Spielern gesehen, wenn es der Spieler hält oder trägt.
Gegenstand | Zustand | Varianten | Bemerkung |
---|---|---|---|
Alle Gegenstände | lefthanded | 1 oder 0 (true/false) | Für Linkshänder: Wenn zur Variante "lefthanded":1 ein Gegenstandsmodell angegeben ist, wird es verwendet, solange im Menü/Optionen/Skin-Anpassung die Haupthand auf "links" steht. Dabei ist es unerheblich, in welcher Hand der Gegenstand tatsächlich gehalten oder ob er am Körper getragen wird, entscheidend ist die eingestellte Haupthand. Bei Variante 0 wird das Modell immer verwendet.
|
custom_model_data | Integer-Ganzzahl | Wenn z.B. zur Variante "custom_model_data":3 ein Gegenstandsmodell angegeben ist, wird es verwendet, wenn der Gegenstand die NBT-Daten {CustomModelData:3} hat.
| |
Alle Gegenstände mit Haltbarkeitsbalken | damaged | 1 oder 0 (true/false) | Wenn zur Variante "damaged":1 ein Gegenstandsmodell angegeben ist, wird es verwendet, sobald der Gegenstand das erste Mal benutzt wird und nicht die Unbreakable-Eigenschaft hat. Bei Variante 0 wird das Modell immer verwendet.
|
damage | Dezimalwert zwischen 0.0 und 1.0 | Mit einem Prozentwert wie z.B. "damage":0.25 kann ein anderes Gegenstandsmodell ab Erreichen dieser Beschädigung festgelegt werden. 0.0 ist ein unbenutzter Gegenstand, 1.0 ist ein 100% beschädigter Gegenstand. Eine Kombination dieses Zustands mit "damaged":1 ist möglich, aber nicht notwendig.
| |
Angel | cast | 1 oder 0 (true/false) | Wenn zur Variante "cast":1 ein Gegenstandsmodell angegeben ist, wird es verwendet, solange die Angel ausgeworfen ist. Bei Variante 0 wird das Modell immer verwendet.
|
Bogen | pulling | 1 oder 0 (true/false) | Wenn zur Variante "pulling":1 ein Gegenstandsmodell angegeben ist, wird es verwendet, solange der Bogen angespannt ist. Solange die Anspannung steigt, wird das Modell automatisch in die Breite gezogen, bis es mit maximaler Anspannung die maximale Breite erreicht hat. Bei Variante 0 wird das Modell immer verwendet.
|
pull | Dezimalwert zwischen 0.0 und 1.0 | Mit einem Prozentwert wie z.B. "pull":0.25 kann ein anderes Gegenstandsmodell ab Erreichen dieser Bogenspannung festgelegt werden. 0.0 ist ein ungespannter Bogen, 1.0 ist ein 100% gespannter Bogen. Eine Kombination dieses Zustands mit "pulling":1 ist nicht notwendig.
| |
Elytren | broken | 1 oder 0 (true/false) | Wenn zur Variante "broken":1 ein Gegenstandsmodell angegeben ist, wird es verwendet, sobald die Elytren zu 100% abgenutzt sind. Bei Variante 0 wird das Modell immer verwendet. Alternativ kann man auch "damage":1.0 verwenden, das hat denselben Effekt.
|
Schild | blocking | 1 oder 0 (true/false) | Wenn zur Variante "blocking":1 ein Gegenstandsmodell angegeben ist, wird es verwendet, solange der Spieler mit Rechtsklick das Blocken mit dem Schild ausführt. Bei Variante 0 wird das Modell immer verwendet.
|
Uhr | time | Dezimalwert zwischen 0.0 und 1.0 | Mit einem Prozentwert wie z.B. "time":0.0416667 kann ein anderes Gegenstandsmodell ab Erreichen dieser Tageszeit festgelegt werden. 0.0 und 1.0 sind Mittag (Befehl /time set 6000 ), 0.5 ist Mitternacht (Befehl /time set 18000 ), eine Stunde = 1⁄24 = 0.0416667. Das Spiel verwendet jedoch nicht 24 verschiedene Gegenstandsmodelle für die Uhr, sondern 64, um eine gleichmäßige Bewegung zu simulieren.
Umrechnung des Zeitticks in eine Prozentzahl: 6000 vom Zeittick subtrahieren (wenn das Ergebnis negativ ist, 24000 auf das Ergebnis addieren), dann durch 24000 teilen. Beispiel: 1000 => 0.7916667. |
Kompass | angle | Dezimalwert zwischen 0.0 und 1.0 | Mit einem Prozentwert wie z.B. "angle":0.125 kann ein anderes Gegenstandsmodell ab Erreichen dieses Winkels festgelegt werden. 0.0 und 1.0 sind das direkte Anvisieren des ursprünglichen Spawnpunktes, 0.5 ist die entgegengesetzte Richtung, 45° = 1⁄8 = 0.125. Das Spiel verwendet jedoch nicht acht verschiedene Gegenstandsmodelle für den Kompass, sondern 32, um eine gleichmäßige Bewegung zu simulieren.
|
Enderperle Chorusfrucht |
cooldown | Dezimalwert zwischen 0.0 und 1.0 | Mit einem Prozentwert wie z.B. "cooldown":0.5 kann ein anderes Gegenstandsmodell ab Erreichen dieser Abkühlung festgelegt werden. 1.0 ist heiß (sofort nach Benutzung), 0.0 ist kalt (nach kompletter Abkühlung, bereit zur erneuten Benutzung).
|
Dreizack | throwing | 1 oder 0 (true/false) | Wenn zur Variante "throwing":1 ein Gegenstandsmodell angegeben ist, wird es verwendet, solange der Spieler den Dreizack mit Rechtsklick hochhält, um ihn zu werfen. Bei Variante 0 wird das Modell immer verwendet.
|
Overlays[]
Einfärbungen werden bei den Blöcken durch jeweils 16 verschiedene Modelldateien realisiert. Bei den Gegenständen ist das anders gelöst, besonders für die Lederrüstung, die es in Millionen verschiedener Farben geben kann. Für die Farben gibt es eine zweite Textur, die vom Spiel automatisch eingefärbt und über die erste gelegt wird, das sogenannte Overlay. Das gibt es für besagte Lederrüstung sowie für die unterschiedlich gefärbten Tränke, Spawn-Eier und Feuerwerksterne.
Fehlende Gegenstandsmodelle[]
Für die Blöcke gibt es grundsätzlich zum jeweiligen Blockmodell auch ein Gegenstandsmodell, das zur Anwendung kommt, wenn der Block in der Hand gehalten oder auf dem Kopf getragen wird, als Drop auf dem Boden liegt oder im Inventar oder in einem Rahmen zu sehen ist. Für einige Blöcke fehlen jedoch die zugehörigen Gegenstandsmodelle. Solche Blöcke kann man nur in der Welt sehen, aber nicht in der Hand halten etc. (d.h. der Befehl /setblock
funktioniert mit ihnen, aber nicht der Befehl /give
). Eine Liste der Blöcke ohne Gegenstandsmodell ist in der Blockliste in der Spalte "Inventar" zu finden.
Datenstruktur der Gegenstandsmodell-Dateien[]
- Die namenlose Haupteigenschaft.
- parent: Übernimmt (erbt) alle Informationen von einem anderen Modell (siehe Vererbung). Der Pfad muss ab
assets/minecraft/models/
angegeben werden.- Um das dreidimensionale Blockmodell inkl. Textur zu übernehmen, wird es einfach angegeben, z.B. "block/pumpkin".
- Um stattdessen aus der Textur ein flaches Modell zu generieren, wird
"builtin/generated"
angegeben. - Einige Blöcke haben noch keine Blockmodell-Datei, ihr Blockmodell ist fest programmiert. Für diese Blöcke wird
"builtin/entity"
angegeben. Auf andere Gegenstände kann diese Angabe nicht angewendet werden. Das gilt z.B. für Truhen, Köpfe und Banner.
- textures: Verweis auf die Texturdateien des Modells, wobei der Pfad jeder Textur ab
assets/minecraft/textures/
angegeben werden muss.- layer#: Wenn mit "builtin/generated" ein flaches Modell generiert wird, ist die Textur als layer0 anzugeben. Einige Gegenstände haben auch ein layer1, das für die programmseitige Einfärbung mittels Overlay verwendet wird: Lederrüstungen, Tränke, Spawn-Eier und Feuerwerksterne. Ansonsten kann man auch für andere Gegenstände ein layer1 und sogar noch weitere Layer angeben, sie werden einfach alle übereinander gelegt.
- display: Ermöglicht das Rotieren, Verschieben und Skalieren der Modelle um sie an die unterschiedlichen Darstellungsvarianten anzupassen.
- gui, firstperson_righthand, firstperson_lefthand, thirdperson_righthand, thirdperson_lefthand, head, ground oder fixed: Darstellungsvariante:
• gui: In jedem Inventar (Spielerinventar, Truhen und andere Behälter, Handel etc.)
• firstperson_righthand, firstperson_lefthand: In der rechten beziehungsweise linken Hand des Spielers aus Spielersicht. Wenn nur eine der beiden Darstellungen angegeben ist, wird die andere identisch belegt. Man benötigt also nur dann beide Varianten, wenn sie unterschiedlich sein sollen.
• thirdperson_righthand, thirdperson_lefthand: In der rechten beziehungsweise linken Hand des Spielers aus Sicht anderer Spieler. Hier gilt genauso: Wenn nur eine der beiden Darstellungen angegeben ist, wird die andere identisch belegt. Man benötigt also nur dann beide Varianten, wenn sie unterschiedlich sein sollen.
• head: Auf dem Kopf des Spielers. Einige Modelle erhalten damit eine Sonderbehandlung und werden an speziellen Positionen des Kopfes dargestellt, siehe Spieler#Kopfslot.
• ground: Als gedroppter Gegenstand
• fixed: In einem Rahmen- rotation: Rotation des Modells mit Angabe der Gradzahl nach dem Schema
[x, y, z]
. Kommazahlen sind möglich, sie sind mit einem Punkt zu schreiben. - translation: Verschiebung des Modells in 1⁄8 Blocklängen nach dem Schema
[x, y, z]
. Die Angabe von 8 verschiebt die Darstellung z.B. um einen ganzen Block. Kommazahlen sind möglich, sie sind mit einem Punkt zu schreiben. - scale: Skalierung des Modells in Blockgrößen nach dem Schema
[x, y, z]
. Die Angabe von 2 verdoppelt die Größe, die Angabe von 0.5 halbiert sie. Kommazahlen sind möglich, sie sind mit einem Punkt zu schreiben.
- rotation: Rotation des Modells mit Angabe der Gradzahl nach dem Schema
- gui, firstperson_righthand, firstperson_lefthand, thirdperson_righthand, thirdperson_lefthand, head, ground oder fixed: Darstellungsvariante:
- overrides: Das Gegenstandsmodell wird durch ein anderes Modell ersetzt, wenn eine der aufgelisteten Zustandsbedingungen zutrifft. overrides ist eine geordnete Liste, d.h. die Prüfung der Zustandsbedingungen wird in der angegebenen Reihenfolge abgearbeitet. Sind mehrere Zustandsbedingungen zutreffend, gilt somit die letzte.
- Eine Zustandsbedingung.
- predicate: Ein oder mehrere Gegenstandszustände. Sind mehrere Zustände in dieser Bedingung enthalten, müssen alle zutreffen, damit die Bedingung insgesamt zutreffend ist.
- Name des Gegenstandszustandes: Wert des Gegenstandszustandes. Siehe Liste.
- model: Das Modell für den Gegenstandszustand. Der Pfad muss ab
assets/minecraft/models/
angegeben werden.
- predicate: Ein oder mehrere Gegenstandszustände. Sind mehrere Zustände in dieser Bedingung enthalten, müssen alle zutreffen, damit die Bedingung insgesamt zutreffend ist.
- Eine Zustandsbedingung.
- parent: Übernimmt (erbt) alle Informationen von einem anderen Modell (siehe Vererbung). Der Pfad muss ab
Beispiel: Fackel[]
In diesem Beispiel wird die normale Fackel als Gegenstand betrachtet. Der Dateiname item/torch.json
wird vom Spiel aus aufgerufen. Die Fackel wird wie viele andere Gegenstände als flacher Gegenstand aus der Textur generiert. Dafür gibt es die allgemeine Modelldatei item/generated.json
, die von der Fackel geerbt wird (parent
) und die die Darstellung für alle flachen Gegenstände festlegt:
- Das Modell für einen flachen Gegenstand wird nicht aus einer Modelldatei geerbt, sondern aus der Texturdatei generiert:
"builtin/generated"
. - Die Darstellung als Drop wird angepasst (
ground
): Sie wird etwas nach oben gehoben und in der Größe halbiert. Würde man bei translation eine 0 einsetzen und bei scale drei Mal eine 1, dann wären die Drops zu groß und würden teilweise im Boden hängen. - Die Darstellung im Kopf wird angepasst (
head
): Sie wird stark nach oben und etwas nach hinten verschoben und um 180° gedreht, sodass alle Gegenstände wie eine Feder am Hinterkopf sitzen und nicht im Kopf verschwinden. Die Größe bleibt unverändert. Beispiel: Befehl/item replace entity @p armor.head with minecraft:torch
. Es gibt auch ein paar Ausnahmen mit spezieller Kopfposition, siehe Spieler#Kopfslot. - Die Darstellung in der Hand des Spielers aus Sicht anderer Spieler wird angepasst (
"thirdperson_righthand"
): Da die Darstellung für beide Hände identisch sein soll, muss nur eine angegeben werden, hier die rechte: Der Gegenstand wird um 3⁄8 Block nach vorne verschoben, damit er wie am unteren Ende angefasst wirkt, und er wird um 1⁄8 Block nach oben verschoben, damit er in der Hand liegt und nicht unter der Hand klebt. Außerdem ist er zu groß und wird um fast die Hälfte verkleinert. - Die Darstellung in der Hand des Spielers aus eigener Sicht wird angepasst (
"firstperson_righthand"
): Da die Darstellung für beide Hände identisch sein soll, muss ebenfalls nur eine angegeben werden, hier die rechte: Der Gegenstand wird gedreht, damit er nicht flach von vorne angeschaut wird, in alle Richtungen ein wenig verschoben, weil er sonst zu nahe am Spieler wäre und etwas verkleinert. - Die Darstellungen im Rahmen wird angepasst (
"fixed"
): Das Modell wird um 180° gedreht, damit es genauso aussieht, wie im Inventar. - Die Darstellung für das Inventar bleibt unverändert.
Dateiname: assets/minecraft/models/item/torch.json { "parent": "item/generated", "textures": { "layer0": "block/torch" } } Dateiname: assets/minecraft/models/item/generated.json { "parent": "builtin/generated", "display": { "ground": { "rotation": [ 0, 0, 0 ], "translation": [ 0, 2, 0], "scale":[ 0.5, 0.5, 0.5 ] }, "head": { "rotation": [ 0, 180, 0 ], "translation": [ 0, 13, 7], "scale":[ 1, 1, 1] }, "thirdperson_righthand": { "rotation": [ 0, 0, 0 ], "translation": [ 0, 3, 1 ], "scale": [ 0.55, 0.55, 0.55 ] }, "firstperson_righthand": { "rotation": [ 0, -90, 25 ], "translation": [ 1.13, 3.2, 1.13], "scale": [ 0.68, 0.68, 0.68 ] }, "fixed": { "rotation": [ 0, 180, 0 ], "scale": [ 1, 1, 1 ] } } }
* ohne Transformation * mit Transformation |
* ohne Transformation * mit Transformation |
Beispiel: Eichenzaun[]
In diesem Beispiel wird der Eichenzaun als Gegenstand betrachtet. Für den Gegenstand des Zaunes wird nicht das Blockmodell verwendet, weil es nur einen Pfosten darstellen würde (block/oak_fence_post.json
). Die Modellbildung aus einer Textur (builtin/generated
) würde dagegen zu flach wirken (wie z.B. beim Braustand). Daher gibt es ein spezielles Modell, das nur für die Darstellung des Zaunes als Gegenstand verwendet wird. Da es für alle Zäune verwendet wird, heißt es block/fence_inventory
. Es steht bei den Blockmodellen. Dort sind nicht nur für alle Zäune, sondern auch für andere Blöcke wie Knöpfe, Mauern etc. spezielle Modelle hinterlegt, die nur für die Darstellung als Gegenstand verwendet werden (alle mit dem Namensteil "_inventory"
). Das Gegenstand-Zaunmodell nimmt übrigens einfach die Textur der Holzbretter, die über das Modell gelegt wird.
Dateiname: assets/minecraft/models/item/oak_fence.json { "parent": "block/oak_fence_inventory" } Dateiname: assets/minecraft/models/block/oak_fence_inventory.json { "parent": "block/fence_inventory", "textures": { "texture": "block/oak_planks" } }
Beispiel: Angel[]
Die Angel erbt die Eigenschaften von item/handheld_rod
, wo die Darstellung aller Angeln festgelegt wird und legt die Angeltextur items/fishing_rod
darüber. Bei der Karottenrute ist es die Textur items/carrot_on_a_stick
. Im Gegensatz zur Karottenrute hat die Angel aber einen weiteren Zustand, nämlich "ausgeworfen". Sobald dieser gegeben ist ("cast": 1
), wird ein ganz anderes Modell verwendet: item/fishing_rod_cast
.
Dateiname: assets/minecraft/models/item/fishing_rod.json { "parent": "item/handheld_rod", "textures": { "layer0": "item/fishing_rod" }, "overrides": [ { "predicate": { "cast": 1 }, "model": "item/fishing_rod_cast" } ] }
Einzelnachweise[]
- ↑ https://www.youtube.com/watch?v=_Gk5wnt-G4k
- ↑ Xor_Boole's Handcrafted 3D Resource Pack https://www.reddit.com/r/Minecraft/comments/2qymnr/handcrafted_3d_resource_pack_updates/
Geschichte[]
Versionsgeschichte der Java Edition | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Standard-Ressourcen |
| ||||
---|---|---|---|---|---|
Standard-Weltdaten |
| ||||
Spielwelt |
| ||||
Software | |||||
Speicherformate | |||||
Einstellungen | |||||
Mehrspieler | |||||
Historisch |