With the first condition, it is determining cases where the redstone_dust_dot model should be added, which requires either all of the four sides being set to 'none', or any two sides that form a corner both being set either to up or side. This example is taken from the file wall_torch.json, which can be found at assets/minecraft/blockstates. The wall torch has several variants: It can be placed at a wall facing in four different directions. If set to an array, the model is chosen randomly from the options given, with each option being specified in separate subsidiary -tags. There can be one model or an array of models.

apply: Determines the model(s) to apply and its properties.

It can be set to a list separated by | to allow multiple values to match. A single case that has to match one of the block states.

A condition A list of cases that all have to match the block to return true.

OR: Matches if any of the contained cases return true.

when: A list of cases that have to be met for the model to be applied.

A case Determines a case and the model that should apply in that case.

multipart: Used instead of variants to combine models based on block state attributes.

The probability of each model being used would then be determined by dividing each weight by 4: 1/4, 1/4 and 2/4, or 25%, 25% and 50%, respectively.) (For example, if three models are used with weights 1, 1, and 2, then their combined weight would be 4 (1+1+2). If more than one model is used for the same variant, the probability is calculated by dividing the individual model's weight by the sum of the weights of all models.

weight: Sets the probability of the model for being used in the game, defaults to 1 (=100%).

This way the texture does not rotate with the block when using the x and y-tags above. Locks the rotation of the texture of a block, if set to true.

uvlock: Can be true or false (default).

y: Rotation of the model on the y-axis in increments of 90 degrees.

x: Rotation of the model on the x-axis in increments of 90 degrees.

model: Specifies the path to the model file of the block, in form of namespaced ID.

All specified models alternate in the game.

A model: Contains the properties of a model, if more than one model is used for the same variant.

Item frames are treated as blocks and use 'map=false' for a map-less item frame, and 'map=true' for item frames with maps. Each variant can have one model or an array of models and contains their properties. A block with just one variant uses '' as a name for its variant.

or A variant: Name of a variant, which consists of the relevant block states separated by commas.

variants: Holds the names of all the variants of the block.

The files are used directly based on their filename, thus a block state file with another name than the existing ones does not affect any block. These files are stored in the following folder: assets//blockstates. The models are then used depending on the block states of the block.

Blocks can also be compound of several different models at the same time, called 'multipart'. There are several different variants of some blocks (like doors, which can be open or closed), hence each block has its own block state file, which lists all its existing variants and links them to their corresponding models. The object specified by namespaced ID and its corresponding object_type and suffix are as follows:

In these files, the path corresponding to the namespaced ID namespace:name is assets/ namespace/object_type/ name.suffix, where the name can contain subfolders separated by /, such as namespace:foo/bar/baz (foo and bar are folders, baz is the real file name). See also Namespaced ID#Locating contents in packs. In JSON files of models and block states, the namespaced ID in the form of namespace:name (the namespace minecraft: can be omitted) is used to represent the local file path. 3.4 Examples: Condensing multiple textures into one file.

Minecraft player model blender