Map most block state model classes 1.21.8 #739

Penguin-Spy · 2025-10-10T08:42:45Z

This PR adds mappings for most classes related to loading and baking the models of blocks from their block state definition files. The biggest (breaking?) change in this PR is renaming n.m.client.render.model.ModelVariantMap to BlockstateDefinition, the rationale for which is given below.

Because there's a lot of new stuff, here's a rough guide to how it relates to the block state definition JSON files:

{ // BlockStateDefinition
  "variants": { // BlockStateDefinition.Variants, a map of String to BlockStateModel.Part. decoded by map of String to BlockStateModelPart.VARIANTS_CODEC
    // either:
    "property=value": { // SingleBlockStateModel.SinglePart, a BlockStateModel.Part. decoded by SingleBlockStateModel.SinglePart.CODEC
        "model": "a:b",    \  ModelVariant (from json)
        "x": 0,         \  |
        "y": 0,         | ModelVariant.Orientation
        "uvlock": false /
    }
    ,// or:
    "property=value": [ // WeightedBlockStateModel.WeightedParts, a BlockStateModel.Part. decoded by BlockStateModel.Part.VARIANT_LIST_CODEC
        {
            "model": "a:b",  \
            "x": 0,          | ModelVariant
            "y": 0,          |  |
            "uvlock": false, /  | VARIANT_LIST_ENTRY_CODEC
            "weight": 1         /
        }
    }
    // VariantMatcher is used before baking to determine which variant shows for each block state
  },

  "multipart": [ // BlockStateDefinition.Multipart, a list of MultipartModelCase. decoded by MultipartModelCase.CODEC
    { // a single MultipartModelCase
      "when": { // MultipartModelSelector
        // either:
        "OR": [ // OperatorMultipartModelSelector (using .OR Operator)
            { "property": "value" } // MultipartModelSelector (these can nest i'm pretty sure)
        ]
        ,// or:
        "AND": [ // OperatorMultipartModelSelector (using .AND Operator)
            { "property": "value" } // MultipartModelSelector
        ]
        ,// or:
        "property": "value" // SimpleMultipartModelSelector, which contains a map of ValueSelector, which contains multiple selector terms (seperated by '|' characters)
      },

      // BlockStateModel.Part (same as variants' value above)
      // either:
      "apply": { }
      ,// or:
      "apply": [ { } ]
    }
  ]

  // `MultipartModelCase`s turn into `MultipartBlockStateModel.Selector`s before baking to determine which parts appear for which block states
}

And the classes that the definitions turn into before baking:

n.m.client.render.block.BlockStateModel (interface): a block state model
- WeightedBlockStateModel: a block state model with multiple (weighted) parts to be chosen to be rendered
- SingleBlockStateModel: a block state model with one part to be rendered
- MultipartBlockStateModel: a block state model comprised of multiple models to be rendered, depending on if their selectors match the block state
  And after baking:
n.m.client.render.block.BakedBlockModel (interface): a baked block model, with methods getQuads and getParticleSprite
- Its only implementation is the unmapped class C_eqeibyds, i don't know enough about Minecraft's rendering to map this.

Other classes (most in n.m.client.render.model.):

BlockStateLoader: the main class that manages loading block state definitions and turning them into unbaked models for baking
ItemModelLoader: the same thing, but for item models. not mapped other than the name, a couple fields, and the load() method
BakedModelManager: just renamed RESOURCE_NAMESPACE to MODEL_NAMESPACE (there's multiple resource namespaces used, this one is for "models")
ModelBaker: just an interface for ModelLoader.ModelLoaderBaker
n.m.data.client.model.ModelVariantModifier: utility class for modifying ModelVariants during data generation
moved n.m.client.render.model.WeightedUnbakedModel to n.m.data.client.model.WeightedUnbakedModel; it appears to only be used during data generation

for the only breaking change: i renamed ModelVariantMap to BlockstateDefinition because

it specifically applies to blocks, not all models (compare n.m.client.render.item.model.BaseItemModel)
it's equivalent to the block state definition files in assets/<namespace>/blockstates/<entry>.json
"variants" are a specific term used within blockstates definitions, but not everything in them is variants
blockstate loading has changed quite a lot since this class was first mapped, the behavior of this class has morphed over time
why BlockStateDefinition?
- it's what the Minecraft Wiki calls it, and it's the generally agreed upon term for this thing
- BlockStateDefinitionProvider already exists in the client data generation package (though that class's name actually might be incorrect now that items also have model definitions)

i tried to follow the naming conventions & guidelines as much as i could, but this is my first mappings PR; let me know if anything should be changed :)

…del package; finish mapping a couple more things

….model.json is for plain models themselves), fix some things

supersaiyansubtlety

This is good coverage, thanks!
The breakdown and explanations were super helpful, and I especially like the ModelVariantMap -> BlockstateDefinition refactor; nice catch of an outdated name!

I did a bit of a deep dive review, so I have some nit picks and a couple suggestions, but overall this is a great PR.

supersaiyansubtlety · 2025-10-10T18:34:06Z