This page says how to lay out a resource pack repository so that MCME's release pipeline can build it: which files go where, the rules each file must follow, which branches the pipeline builds, and how to see the result on your own computer before you release. It applies to new packs and to existing ones. What happens after you push is in The release pipeline.

Sodium pack or vanilla-only pack?

Decide this first. It sets the layout, the release script and the zip names.

As soon as one blockstate or item points at an mcme: model with an .obj file, the pack must be a Sodium pack. A vanilla-only release zips those models unconverted. Only players with the Special Model Loader mod can render them, so everyone else sees missing-model blocks.

Layout of a Sodium pack

This is the layout of RP-Human, RP-Mordor and RP-PathOfTheDead on master.

RP-<Name>/
├── pack.mcmeta                 in every zip; see below
├── pack.png                    in every zip
├── license.txt                 in every zip
├── README.md                   in every zip
├── .gitignore                  never in a zip (nor is any name starting with a dot)
├── .github/workflows/check-shaders.yml   the shader check on GitHub
├── .mcme-shaders.json          which shader modules the pack turns on
├── .mcme-shaders.lock          written by the shader sync; commit it, don't edit it
├── assets/
│   ├── minecraft/
│   │   ├── blockstates/        which model each block state uses; may name mcme: models
│   │   ├── items/              item definitions; may name mcme: models
│   │   ├── models/             ordinary JSON models
│   │   ├── textures/
│   │   └── shaders/            the shader base (written by the sync) and your hooks
│   ├── sodium/shaders/         the shader base's Sodium copies (written by the sync)
│   └── mcme/
│       ├── models/block/       the 3D models: <name>.json + .obj + .mtl (+ .objmeta)
│       ├── textures/block/     the textures the .mtl files name
│       └── sml_load_scopes/    Special Model Loader's list of models (Sodium zip only)
├── mc26_3/                     the shaders as Minecraft 26.3 needs them (written by the sync)
├── vanilla/                    optional: files only the Vanilla and Lite zips get
└── 1_*/                        optional version overlays

The shader files, .mcme-shaders.lock and mc26_3/ are written by the shader sync, never by hand: see The shader base.

What ends up in which zip

How assets/ is rebuilt for the Vanilla and Lite zips:

• Everything under assets/ is copied, except these folders in every namespace: blockstates, items, models, textures/block and textures/item. assets/mcme/sml_load_scopes is left out too. (The modelengine namespace keeps its models and items.)
• Those folders are rebuilt from what the blockstates and item definitions actually use: every mcme: model is baked into a vanilla model plus a texture, and every other model the pack overrides is copied, with its parents and textures.
• Anything nothing points at is left out. A texture in textures/block that only a font or a GUI uses is lost, so keep such textures elsewhere, for example in textures/gui.

How the conversion works has the full details.

pack.mcmeta

RP-Human's, as an example:

{
  "pack": {
    "pack_format": 88,
    "min_format": 88,
    "max_format": 97,
    "description": "MCME Human v4.1.5 for MC 26.3 (and 26.2)"
  },
  "sodium": {
    "ignored_shaders": ["fog.glsl", "terrain.fsh", "terrain.vsh"]
  },
  "overlays": {
    "entries": [
      { "min_format": 97, "max_format": 97, "directory": "mc26_3" }
    ]
  }
}

• Pack formats: 88 is Minecraft 26.2 and 97 is 26.3. A range from 88 to 97, with the mc26_3 overlay for 97, lets one zip serve both versions. The shader sync writes min_format, max_format and the overlay entry for you when the pack has an mc26_3/ folder.
• The release note reads these formats. It names every Minecraft version all the zips support, for example "Version v4.1.5 for Minecraft 26.2 and 26.3".
• The description must be a plain string. A text component ({"text": …}) stops generateVanilla with an error.
• Put the version in the description, and update it before each release. Nothing does it for you.
• If the description contains Sodium (case-sensitive), the Vanilla and Lite zips get Vanilla there instead, so players can tell the variants apart in their pack list. Without it, all three variants show the same description.
• sodium.ignored_shaders is written by the shader sync. It tells Sodium that the pack's vanilla terrain shaders are there on purpose. Leave it in.
• Overlays: a folder only does something in game if overlays lists it. Folders named 1_… are copied into every zip whether listed or not; any other overlay folder reaches the Vanilla and Lite zips only when overlays lists it.

The 3D models in assets/mcme

Every 3D model is a set of files with the same name in assets/mcme/models/block/:

RP-Human's pine_leaves.json, shortened:

{
  "parent": "special-model-loader:builtin/obj",
  "model": "mcme:models/block/leaves_parent.obj",
  "mtl_override": "mcme:models/block/pine_leaves.mtl",
  "particle": "mcme:block/beech_leaves",
  "flip_v": true
}

The .mtl it names:

newmtl m_b2bff805-3e5a-c860-a1cb-7ffdc3695c42
map_Kd mcme:block/pine_leaves

Rules:

• model must point at an .obj that is committed. A model JSON without model, or a missing .obj, is skipped without any message, and the block shows as a missing model in the Vanilla and Lite zips.
• model and mtl_override use the mcme: namespace.
• map_Kd must start its line and name the texture as mcme:block/<texture> (in assets/mcme/textures/) or minecraft:block/<texture> (in the pack's own assets/minecraft/textures/; the vanilla client's textures can't be used). Only the first map_Kd counts: one texture per model.
• The texture must be at least 8 pixels wide.
• Textures used with one shared parent must all be the same size. Several models can share one .obj named parent, or ending in _parent, optionally followed by one number: leaves_parent.obj, leaves_parent_2.obj, parent.obj. The Vanilla zip then stores that geometry once. Treat the warning shares parent group … but its baked texture is … as an error and fix the texture sizes (see Shared parents).
• Names like leaves_vertical_slab_parent_1_2.obj aren't shared parents (only one number may follow _parent). They work, but every model using them gets its own copy of the geometry.
• Cutout textures (leaves, plants) should use only fully transparent and fully opaque pixels. One semi-transparent pixel makes the whole texture render with soft edges in the Vanilla zip.
• Animated textures need a .png.mcmeta next to the texture. The sheet must divide evenly into frames.
• Keep sml_load_scopes in step with your models. Special Model Loader reads it; the Vanilla and Lite zips leave it out. The packs keep one file, assets/mcme/sml_load_scopes/test_scopes.json, which lists models as "mcme:block/<name>" under "entry".
• The old .objmeta key parent: is ignored. Many of RP-Human's .objmeta files still have it; it does no harm.

Blockstates and item definitions

They live in assets/minecraft/blockstates/ and assets/minecraft/items/, and point at 3D models with an mcme: identifier:

{
  "variants": {
    "": [
      { "model": "mcme:block/hornbeam_leaves" },
      { "model": "mcme:block/hornbeam_leaves_2" },
      { "model": "mcme:block/hornbeam_leaves_3" }
    ]
  }
}

• Put the most important models first in a list. The Lite zip keeps only the first two of every list.
• Rotate around one axis only. The converter bakes an x, y or z rotation into a model, not two. With x and y on one entry, y is dropped with a warning. Make a pre-rotated model instead.
• Rotations must be numbers (90, 180, 270).
• Only blocks and items that exist in Minecraft 26.2 reach the Vanilla and Lite zips (see Known limits).

The vanilla folder

vanilla/ is optional (RP-Human, RP-Mordor and RP-PathOfTheDead have none). It holds files only the Vanilla and Lite zips need, merged into the converted pack's assets/.

• blockstates and items here replace the pack's own, for blocks that should look different without the mod.
• models, textures/block and textures/item here are ignored. Those folders are rebuilt from what the blockstates use, so old pre-baked models in vanilla/ do nothing.
• Everything else is copied on top: fonts, GUI textures and so on.
• vanilla/1_… folders are merged into the overlay folders of the same name.
• No shaders here. The shader base lives in the pack's root assets/ (see The shader base). A changed copy of a base file anywhere, vanilla/ included, stops the build.

Without a vanilla/ folder the converter prints WARNING!!! Missing vanilla overrides folder. That is expected and harmless.

Layout of a vanilla-only pack

RP-<Name>/
├── pack.mcmeta
├── pack.png
├── license.txt
├── README.md
├── .gitignore
├── .mcme-shaders.json          if the pack uses the shader base, with what the sync writes
├── .mcme-shaders.lock
├── assets/
│   └── minecraft/
│       ├── blockstates/
│       ├── models/
│       ├── textures/
│       └── shaders/
└── mc26_3/

• Everything at the top except names starting with a dot goes into the zip, as it is. A folder named inventories is left out.
• No mcme: models with .obj files. If you start adding them, turn the pack into a Sodium pack first.
• The shader base is synced into vanilla-only packs too (Dwarven and Lothlorien have it). A vanilla-only release zips the repository as it is, so whatever the sync last wrote is what players get.
• The same pack.mcmeta rules apply, apart from the Sodium word.

Branches

• Work on a feature branch and open pull requests into development, so several people can work on the pack at once.
• Bring tested work to production with a pull request from development into master.
• A release builds exactly what GitHub has on the branch its stage builds. Work that is only on your computer, or on another branch, isn't in it.

.gitignore

Keep it short. Nothing in a pack needs ignoring except editor and OS clutter:

# OS and editor files
.DS_Store
Thumbs.db
desktop.ini
.idea/
.vscode/
*.bak
*.tmp

Never ignore *.obj, and don't start from the stock Visual Studio or Python .gitignore. Those ignore *.obj, folders named obj/, build/ or release/, and *.meta and *.log files. An ignored .obj never reaches GitHub, so the server builds the pack without it. That happened to a test release in October 2026: its 3D blocks showed as missing models.

To check that a file is really committed, run git check-ignore -v <file>. It prints the rule that ignores the file, or nothing.

Don't commit OS clutter deeper in the tree either: only names that start with a dot at the top are kept out of the zips, so a committed assets/.DS_Store ships.

Try the conversion on your computer

The server runs the same converter, so a local run shows what a release will contain, with every warning, in a few minutes. You need Python 3.10 or newer and Git.

1. Get the converter:

   git clone https://github.com/MCME/ResourcePackScripts.git
   cd ResourcePackScripts
   pip install -r requirements.txt
   

2. Get Minecraft 26.2's resources. Start 26.2 once in the launcher, so the client jar is downloaded to versions/26.2/26.2.jar in your Minecraft folder (%APPDATA%\.minecraft on Windows). A .jar is a zip file: open it with any zip tool and extract its assets folder into a new folder, for example minecraft-26.2, next to ResourcePackScripts. Use 26.2, because the server does.

3. Convert, from the ResourcePackScripts folder, with your pack checked out next to it:

   # Vanilla variant
   python generateVanilla/generateVanilla.py ../RP-Human ../out-vanilla ../minecraft-26.2 --objmc generateVanilla/objmc.py
   # Lite variant
   python generateVanilla/generateVanilla.py ../RP-Human ../out-lite ../minecraft-26.2 --objmc generateVanilla/objmc.py --limit 2
   

   • Always pass --objmc. Without it the converter looks for objmc.py in the folder you run it from.
   • Use a new, empty output folder every time. The converter adds to an existing folder but never deletes from it.
   • Read every WARNING, Error, Missing and Note: line. Not every message starts with WARNING. Troubleshooting says what each one means.

4. Try it in game. Zip the contents of the output folder, so that pack.mcmeta is at the top of the zip, and put the zip in your resourcepacks folder.

Bring a new pack into the pipeline

1. Create the repository under the MCME organisation as RP-<Name>, with master and development branches.

2. Lay it out as a Sodium pack or a vanilla-only pack. For a Sodium pack, RP-Human's pack.mcmeta and license.txt are a good start. Don't copy RP-Human's .gitignore: use the short one above.

3. Add the shader base: write a .mcme-shaders.json, run the sync and commit what it wrote. Copy ResourcePackScripts' ci/check-shaders.yml to .github/workflows/check-shaders.yml. See The shader base.

4. Try the conversion locally and fix the warnings.

5. Ask an operator to add the pack to the release automation, with:

   They need	Example
   The pack's name in the pipeline: one word, letters only. Every zip is named after it, and staff type its first letters.	Rivendell
   Sodium pack or vanilla-only	Sodium
   The repository	MCME/RP-Rivendell
   The test release repository	A test repository, or MCME/RP-Rivendell itself
   The Minecraft versions it is for	26.2 and 26.3
   Where players should get it	An RP region on the RP server, then the main servers

   Choose a name whose first letter isn't taken by another pack, and keep it short: every download URL (https://github.com/<owner>/<repo>/releases/download/<tag>/<zip>) must stay under 100 characters. The operators' side is in Resource pack server (operators only).

6. Make the first test release on the RP server and check it in game (see The release pipeline).

Turn a vanilla-only pack into a Sodium pack

For a pack that so far is zipped as it is, and now gets .obj models.

1. Commit the models properly. Remove *.obj and similar rules from .gitignore, then add every .obj, .mtl, .objmeta and model JSON under assets/mcme/models/block/, and the textures under assets/mcme/textures/.
2. Bring the shader base in, if the pack doesn't have it yet: replace the pack's own text.vsh, fog.glsl and any objmc shaders by adding a .mcme-shaders.json and running the sync, with --force the first time. Commit what it wrote.
3. Check pack.mcmeta. Optionally add Sodium to the description.
4. List the models in assets/mcme/sml_load_scopes/, as RP-Human does.
5. Try the conversion locally. Check that blocks only your pack has still appear in the Vanilla output. If one is missing, see Known limits.
6. Ask an operator to switch the pack to releaseVanillaSodium.sh. Its zips get new names (<Pack>-Vanilla.zip instead of <Pack>.zip, and so on), and its server slots get the six-zip layout at the same time.
7. Make a test release on the RP server and check it with a vanilla client, with the MCME modpack, and with /rp client lite.

Checklist before every release

• Everything is pushed to development (test) or merged into master (production).
• The version in pack.mcmeta's description is updated.
• git status shows nothing left uncommitted, and no .obj is ignored.
• If you changed a shader, a fluid texture or .mcme-shaders.json, the sync has run and its changes are committed, and the shader check on GitHub is green.
• For a Sodium pack, a local conversion runs without new warnings.
• You know the new tag, and nobody else is releasing right now.

Known limits

• Blocks newer than Minecraft 26.2 are dropped from the Vanilla and Lite zips, 26.3's included. The converter walks the block and item list of the vanilla resources it is given, and the server gives it 26.2's.
• Only one rotation axis per model entry is baked.
• Overlay folders aren't converted. They are copied as they are, so an mcme: model inside one isn't baked.
• No biome tint on baked models. The converter strips tintindex, so baked grass and leaves don't take the biome colour.
• The Sodium-Footprints zip swaps only activator_rail.png, not activator_rail_on.png as the other Footprints zips do.
• A release may run for 30 minutes before MCME-Architect stops it, unless an operator gives the pack a longer time.