User Tools

Site Tools


tutorial:datagen_model

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
tutorial:datagen_model [2025/04/18 14:55] – [Directional blocks (taking vertical blocks as example)] solidblocktutorial:datagen_model [2025/04/18 14:59] (current) – [Model Generation] solidblock
Line 1: Line 1:
 ====== Model Generation ====== ====== Model Generation ======
-We know that almost every item needs a corresponding **item baked model** (or //item model// for short), and an **item models definition** since 1.21.4. Each block needs a **block baked model** (or //block model// for short) and a **block states definition**, and a corresponding item baked model or item models definition. A simble block requires so much complicated JSON files! Obviously, it's too hard to build each file manually. Therefore, we use data generator to generate models for blocks and items.+:!: The page is translated from [[zh_cn:tutorial:datagen_model|other pages]] and the translation may not be fully accurate. 
 + 
 +We know that almost every item needs a corresponding **item baked model** (or //item model// for short), and an **item models definition** since 1.21.4. Each block needs a **block baked model** (or //block model// for short) and a **block states definition**, and a corresponding item baked model or item models definition. A simple block requires so much complicated JSON files! Obviously, it's too hard to build each file manually. Therefore, we use data generator to generate models for blocks and items.
  
 In data generator, models and definitions are generated together. Usually, when generation a model, a model id is returned, which will be used in the block states definition or item models definition. We will go into that from simple ones to details. In data generator, models and definitions are generated together. Usually, when generation a model, a model id is returned, which will be used in the block states definition or item models definition. We will go into that from simple ones to details.
Line 181: Line 183:
   * ''MultipartBlockModelDefinitionCreator'': A block that consists of multiple parts, each of which is a block model variant. Each part is decided whether to display according to its block state. Vanilla redstone write is this type.   * ''MultipartBlockModelDefinitionCreator'': A block that consists of multiple parts, each of which is a block model variant. Each part is decided whether to display according to its block state. Vanilla redstone write is this type.
  
-For ''VariantsBlockModelDefinitionCreator'', we need to define the relations between block states and block model variants, which means to claricy, whether model variants to be used for which block. Multiple block states may use one same model variant (for example, waterlogged blocks and blocks not waterlogged, use the same model), and one block state may also use multiple variants (such as the random rotation for dirt and sands) — but we must ensure there is no duplication or ignorance: we do not need to ensure each block state property to be used, but we need to ensure each possible block state should be contained without duplication, otherwise errors may be thrown. In 1.21.5, there are two ways to define the relations between block states and block model variants:+For ''VariantsBlockModelDefinitionCreator'', we need to define the relations between block states and block model variants, which means to clarify, whether model variants to be used for which block. Multiple block states may use one same model variant (for example, waterlogged blocks and blocks not waterlogged, use the same model), and one block state may also use multiple variants (such as the random rotation for dirt and sands) — but we must ensure there is no duplication or ignorance: we do not need to ensure each block state property to be used, but we need to ensure each possible block state should be contained without duplication, otherwise errors may be thrown. In 1.21.5, there are two ways to define the relations between block states and block model variants:
   * **Method one**: Specify one model variant, and modify the variant according to block states, such as modifying x-rotation, y-rotation and uvlock. All block states use the same model id, with only possible different variants.   * **Method one**: Specify one model variant, and modify the variant according to block states, such as modifying x-rotation, y-rotation and uvlock. All block states use the same model id, with only possible different variants.
   * **Method two**: Allocating model variants for different block states directly, and then you can also continue to modify variants. In this case, the block states may use different model ids.   * **Method two**: Allocating model variants for different block states directly, and then you can also continue to modify variants. In this case, the block states may use different model ids.
Line 221: Line 223:
 > We find that in method two, when calling ''VariantsBlockModelDefinitionCreator.of'', we do not pass ''WeightedVariant'' as the second parameter, but provide once for each block state later. We can also notice that, in method one, what was called is ''BlockStateVariantMap.operations'', and it's only operations for model variants that was registered each time, while in method two, what was called is ''BlockStateVariantMap.models'', and it's a full model variant that was registered each time. After allocating model variants through the ''with'' method, we can continue to modify the variants with ''apply'' or ''coordinate''. > We find that in method two, when calling ''VariantsBlockModelDefinitionCreator.of'', we do not pass ''WeightedVariant'' as the second parameter, but provide once for each block state later. We can also notice that, in method one, what was called is ''BlockStateVariantMap.operations'', and it's only operations for model variants that was registered each time, while in method two, what was called is ''BlockStateVariantMap.models'', and it's a full model variant that was registered each time. After allocating model variants through the ''with'' method, we can continue to modify the variants with ''apply'' or ''coordinate''.
  
-In the method one and method two described above, apart from registering model operations or model variants one by one with the ''reigster'' method, the ''generate'' method can also be used, specifying a model operation or model variants with a lambda, which is a function, taking the corresponding property value as parameter, and returning the model operation or model variant.+In the method one and method two described above, apart from registering model operations or model variants one by one with the ''register'' method, the ''generate'' method can also be used, specifying a model operation or model variants with a lambda, which is a function, taking the corresponding property value as parameter, and returning the model operation or model variant.
  
-If a block state has multiple properties that affect model variants, you can provvide multiple properties in ''BlockStateVariantMap.operations'' and ''BlockStateVariantMap.models'', and specify or use multiple values in the ''register'' or ''generate'' method. You can also call ''coordinate'' twice, allowing each property decide their respective modifications to the model variant.+If a block state has multiple properties that affect model variants, you can provide multiple properties in ''BlockStateVariantMap.operations'' and ''BlockStateVariantMap.models'', and specify or use multiple values in the ''register'' or ''generate'' method. You can also call ''coordinate'' twice, allowing each property decide their respective modifications to the model variant.
tutorial/datagen_model.1744988111.txt.gz · Last modified: 2025/04/18 14:55 by solidblock