Getting ChatGPT to make a Minecraft model

The part that works: geometry

Ask a chat model to "write the model JSON for a simple wooden table in Minecraft" and you get something sensible. Box coordinates make sense, it knows the 16-unit block scale, it names the parts.

{
  "elements": [
    { "name": "top",  "from": [1, 12, 1],  "to": [15, 14, 15] },
    { "name": "leg1", "from": [2, 0, 2],   "to": [4, 12, 4] },
    { "name": "leg2", "from": [12, 0, 2],  "to": [14, 12, 4] }
  ]
}

So far, fine. The trouble starts on the next line.

Wall 1: the texture file

The model JSON points at a PNG, but a chat model cannot hand you a PNG. It produces text, not binary files. You have to prepare the texture separately — which means opening an image editor and painting an atlas with room for every face your model has.

Handing the job to an image-generating AI does not solve it either: a texture atlas is not an artistic image, it is a layout plan that has to land on specific coordinates. A pixel in the wrong place becomes the tabletop texture stretched across a table leg.

Wall 2: UV coordinates

This is the genuinely hard part. Every box has six faces, and where each face gets painted from is written in its uv field. On a three-part table that is 18 faces, 72 numbers — all of which must be consistent with each other and with the texture you painted.

"faces": {
  "up":    { "uv": [0, 0, 14, 14], "texture": "#0" },
  "down":  { "uv": [14, 0, 28, 14], "texture": "#0" },
  "north": { "uv": [0, 14, 14, 16], "texture": "#0" }
}

A chat model can produce those numbers but cannot check them: it has no texture in hand, cannot see the output, and cannot notice two faces overlapping. The usual result is a file that loads and a model that is painted wrong.

Wall 3: the plugin config

The model JSON alone does nothing in game. ItemsAdder, Nexo, Oraxen or CraftEngine each need their own yml, the right folder tree, and a hitbox measured in blocks. Furniture also needs scale compensation.

A chat model will write those too, but it does not know which version expects which key, and where it is unsure it invents something plausible. A yml that errors at server startup is a long evening for anyone who does not know where to look.

So when is it useful

• For learning. If you want to understand the format, having a chat model write an example and talking through it is a good route.
• For editing an existing file. "Make the legs on this model two units longer" is faster than changing numbers by hand.
• For understanding config. Asking what a yml field does works well — but verify against the docs before using the output as-is.

What is missing is the loop closing

The problem is not the chat model's knowledge, it is the missing setup. A system that does not produce the texture cannot verify texture coordinates; a system that cannot render the output cannot tell you it looks right. What you are left with is a plausible file that has never been tried.

So in practice there are two routes: finish the three missing pieces by hand — texture, UVs and config — or use something that delivers all four together. With MineModel AI you write a description and the pack arrives ready to install; what comes out, and where it falls short, is covered in a separate article.