-
Notifications
You must be signed in to change notification settings - Fork 14
08. Resource Packs
In MiEx very little is hardcoded. Pretty much everything is defined and controllable via files in resource packs. MiEx supports Minecraft Java Edition resource packs, Minecraft Bedrock Edition resource packs, and Hytale resource packs / mods. It uses the files in the same way as the games do. MiEx also defines some additional files that resource packs can contain, to further control how MiEx exports out worlds. This page provides an overview of all of the different files found in resource packs that MiEx uses.
Resource packs are typically located in the resources folder next to the MiEx.jar file, although the location of the folder containing the resource packs can be changed via environment variables or command-line arguments. MiEx only supports resource packs in the form of folders, rather than zip files. If you have a resource pack, addon, behavior pack, data pack, or mod that you want to use that is a zip file, then you would need to unzip it into a folder first.
Block states are files that define blocks. It provides information about the block and most importantly, specifies what models to use for the block and how to combine them. If no block state file exists for a block, then MiEx won't know how to export out that block.
Block states in Minecraft Java Edition resource packs are located in assets/<namespace>/blockstates and the name of the file is the name of the block (minus the namespace). These block state files indicate what models to use for the block and how to modify those models, depending on what the properties of the block are.
Most mods also use these block state files to define their blocks, which allows MiEx to easily be able to support those modded block as well. Some mods do make use of custom formats for their block state files, which MiEx cannot read in. In those cases, you would need to replace it with a version of the block state file that follows the vanilla format.
MiEx does extend the format by adding in a special property that can be checked against called miex_connect_<xOffset>_<yOffset>_<zOffset>, which lets you check what the neighbouring blocks are. This lets you use different models based on what blocks are around it, which helps with implementing block states for modded blocks that use a custom format that MiEx cannot understand. Here's a list of possible values that you can use with this property:
| Syntax | Description |
|---|---|
this |
The block id of the current block. Allows you to check for the same block. |
<Block Name> |
The Minecraft resource identifier for a specific block id. |
<Tag Name> |
The Minecraft resource identifier for a specific tag. It will then match against all blocks specified by that tag. |
!<value> |
Inverts the result of the check against the value. |
<value>|<value> |
Allows you to match against a list of possible values. |
For variant block states, when specifying the properties to match against, MiEx adds in the OR operator with ||. The AND operator is already in there using ,, but you can now also do OR. Do note: OR has the higher priority. It first splits the string against the OR operator and then the AND operator. This is to keep better compatibility with Minecraft Java Edition.
Block states in Minecraft Bedrock Edition resource packs are located in blocks. MiEx follows the same format as Bedrock Edition. Addons use the same format as well and do not make use of custom format, unlike some Java Edition mods, so blocks from addons should always be fully supported.
Block states in Hytale resource packs are located in Server/Item/Items and the name of the file specifies the block name. While Hytale does not make use of namespaces, within MiEx it will always add in the namespace hytale: to block names. MiEx follows the same format as Hytale. Mods use this format as well, so all blocks from mods should be fully supported.
MiEx also has a custom format for specifying block states that can be placed in any kind of resource pack. These blockstates are located in builtins/<namespace>/blockstates. This built-in format provides a much more powerful way of defining blocks. It can use expressions, query neighbouring blocks, and make use of "generators" which allows it to add in the models of blocks, items, entities, and text. MiEx uses this format to define a couple of blocks that otherwise are hardcoded in Minecraft, like beds, chests, end portals, signs, hanging signs, shulker boxes, and skulls.
For more information about how this built-in format works, see the page Built-in Block State Format.
Block models provide the actual geometry for the blocks. They are referenced by the block states. If a block state references a block model that does not exist, then MiEx won't know what that block should look like and won't be able to export that block out.
Block models in Minecraft Java Edition are located in assets/<namespace>/models with the name of the file specifying the model name. MiEx follows the same format as Java Edition.
MiEx also allows for model files to be .obj files rather than Minecraft's .json files. The .obj support is very limited. It only supports quads (triangles are converted into quads) and it also needs to define what textures to use. When it finds a usemtl statement, the name after that should be the resource identifier of the texture to use. All faces defined after that statement will then have that texture assigned to it, until the next usemtl statement. Any faces defined before the first usemtl statement are ignored.
Block models in Minecraft Bedrock Edition resource packs are located in models. MiEx follows the same format as Bedrock Edition.
Block models in Hytale can be located anywhere in the Common folder. MiEx follows the same format as Hytale.
Textures help give blocks their look. They are typically referenced by block models or block states. If a texture is referenced that does not exist, then MiEx will export out a generic grey material. MiEx supports .png, .tga, and .exr textures.
Textures in Minecraft Java Edition are located in assets/<namespace>/textures with the name of the file specifying the texture name.
Textures in Minecraft Bedrock Edition are located in textures. Next to that, textures/terrain_textures.json and textures/item_textures.json is used to map texture names specified in block states to the actual texture files.
Textures in Hytale can be located anywhere in the Common folder.
Textures may be made up of multiple frames stacked on top of each other. MiEx supports these texture animations and material templates can query whether textures are animated like this and set up the materials to make sure that the textures are animated in the export.
Texture animations in Minecraft Java Edition are specified in .mcmeta files located right next to the textures themselves. So fire_0.png would have a fire_0.png.mcmeta file which provides the information about the texture animation. MiEx follows the same format as Java Edition.
Texture animations in Minecraft Bedrock Edition are specified in textures/flipbook_textures.json. MiEx uses the same format as Bedrock Edition.
Hytale currently does not have a system for texture animations similar to Minecraft Java Edition and Minecraft Bedrock Edition. Instead, texture animations are part of block animations.
Blocks may have looping animations on them. MiEx can export these out, where it will export out the animated geometry for one loop and then at every instance of that block place a prim in the USD file that then references the animated geometry and makes it loop for however long it needs to. MiEx can randomly offset these animations per block by specifying the block names in randomAnimationXZOffset and / or randomAnimationYOffset in a miex_config.json file.
Block animations are currently not supported for Minecraft Java Edition as it has no system for specifying this.
Block animations are currently not supported for Minecraft Bedrock Edition as it has no system for specifying this.
Block animations can be located anywhere in the Common folder. MiEx follows the same format as Hytale. If a block state defines CustomModelAnimation for a block and Looping is set to true, then MiEx will load in the block animation specified by CustomModelAnimation.
Some blocks, like item frames in Minecraft, may show items as part of their model. MiEx can export this out.
Items in Minecraft Java Edition are located in assets/<namespace>/items and the name of the file specifies the item name. MiEx uses the same format as Minecraft Java Edition.
MiEx currently does not support items specified in Minecraft Bedrock Edition resource packs.
MiEx currently does not support items specified in Hytale resource packs.
Biomes provide biome colours which are used to tint certain blocks. Which blocks should get which biome colours is specified in miex_block_tints.json. Blocks can either be given a hardcoded tint or be assigned to a "colormap", which allows the tint to vary based on the biome. Colormaps are defined via a resource identifier. Common colormap names are minecraft:grass, minecraft:foliage, minecraft:water, hytale:tint.
Biomes in Minecraft Java Edition are located in data/<namespace>/worldgen/biome and the name of the file specifies the biome name. MiEx uses the same format as Minecraft Java Edition.
Biomes can specify temperature and downfall values which are used to specify where in colormap textures it should pick the biome colour from. Biomes can also specify a hardcoded tint for a biome colour. Hardcoded tints are specified in effects/<name>_color json property, where <name> is the colormap name (if no namespace is defined, it defaults to minecraft: namespace).
Colormap textures are located in assets/<namespace>/textures/colormap, where the name of the texture file is the name of the colormap. Adding in more textures in here will define new colormaps that can be used to tint blocks.
Biomes in Minecraft Bedrock Edition are located in biomes or biomes_client.json. MiEx uses the same format as Minecraft Bedrock Edition.
Biomes can specify temperature and downfall values which are used to specify where in colormap textures it should pick the biome colour from. Biomes can also specify a hardcoded tint for a biome colour. Hardcoded tints are specified in minecraft:biome/minecraft:map_tints/<name> json property, where <name> is the colormap name (if no namespace is defined, it defaults to minecraft: namespace).
Colormap textures are located in textures/colormap, where the name of the texture file is the name of the colormap (with minecraft: namespace added). Adding in more textures in here will define new colormaps that can be used to tint blocks.
Biomes in Hytale are located in Server/Environments, where the name of the file is the name of the biome (with hytale: namespace added). Biome colours are actually specified in the chunk data in Hytale and so that is loaded from there, rather than from the biome. The biome colours from the chunks are put under the hytale:tint colormap. Biomes can still specify hardcoded tints for other colormaps by specifying <name>Tint json property. This is done for the water tint for example. If no namespace is specified, it defaults to minecraft: namespace).
MiEx has limited support for entities. It can export them out as static geometry (typically done for item frames, paintings, and display entities), but it can also do a basic simulation of them and export out animated geometry.
MiEx does not support entities defined in Java Edition resource packs as there is no format to specify entities.
Entities in Minecraft Bedrock Edition are located in entity and entities. MiEx uses the same format as Minecraft Bedrock Edition. The files in entity define the main entity itself and how to export it out. The files in entities define the AI for entities and is used when simulating these entities.
MiEx also supports animations and animation controllers specified in Bedrock Edition resource packs and will use these when simulating entities.
MiEx currently does not support entities defined in Hytale resource packs.
MiEx also has a custom format for specifying entities that can be placed in any kind of resource pack. These entities are located in builtins/<namespace>/entities. MiEx comes with a default implementation for item frame, painting, and display entities that is written using this format. It uses the same format as the built-in format for block states, but with a few small tweaks. Rather than blocks specifying the list of blocks, or uses entities to specify the list of entities that this file handles. And it specifies posX, posY, posZ, rotX, and rotY as top-level properties that can contain an expression to specify the location and orientation of the entity, rather than taking the default values from the entity data.
Whenever blocks or biomes need to be specified, they are specified via their resource identifier. Blocks and biomes can also be grouped under "tags", which lets you easily specify all blocks under that tag rather than having to list out all blocks manually. Tags are used instead of normal block or biome names by using a hashtag: #<name> (defaults to minecraft: namespace if none is provided).
Tags in Minecraft Java Edition are located in data/<namespace>/tags where the name of the file is the name of the tag. MiEx uses the same format as Minecraft Java Edition.
When block states are defined in Bedrock Edition resource packs, if it contains any component whose name is in the format tag:<name> then it will register that block under that tag. This is the same as how it works in Minecraft Bedrock Edition.
When biomes are defined in Bedrock Edition resource packs, if it contains the component minecraft:tags then it will register that biome under the tags specified in there. This is the same as how it works in Minecraft Bedrock Edition.
Blocks in Hytale resource packs can be assigned to a Group, that block is then registered to the tag with the name specified by Group (defaults to hytale: namespace if none is specified).
Minecraft has banners which can have various images painted onto them by combining patterns. Which patterns are available are specified by resource packs.
Banner patterns in Minecraft Java Edition are located in data/<namespace>/banner_pattern and the name of the file is the name of the banner pattern. MiEx uses the same format as Minecraft Java Edition.
MiEx does not support banner patterns specified in Minecraft Bedrock Edition resource packs.
MiEx does not support banner patterns specified in Hytale resource packs.
Minecraft has paintings which can be placed in the world. Which paintings are available are specified by resource packs.
Paintings in Minecraft Java Edition are located in data/<namespace>/painting_variant and the name of the file is the name of the painting. MiEx uses the same format as Minecraft Java Edition.
MiEx does not support paintings specified in Minecraft Bedrock Edition resource packs. The painting textures themselves can be specified in Bedrock Edition resource packs.
MiEx does not support paintings specified in Hytale resource packs.
Some blocks make use of text (for example signs). In order for MiEx to be able to export these out, it needs to have a font definition. Fonts are specified by resource packs.
Fonts in Minecraft Java Edition are located in assets/<namespace>/font and the name of the file is the name of the font. It uses the same format as Minecraft Java Edition.
MiEx does not support fonts specified in Minecraft Bedrock Edition resource packs.
MiEx does not support fonts specified in Hytale resource packs.
MiEx supports exporting out "locators" for blocks. Locators are points that can be specified for blocks where MiEx will export out a points or particle object with the locators for each instance of a block that has locators specified. This lets you easily find all positions of torches so that you can have a tool automatically place lights where torches or other blocks are. MiEx by default comes with locators for various light emitting blocks.
Locators a placed in locators/<namespace>/points/<locator name>.json. Each specified JSON file will be its own point cloud in the export that matches the namespace and name of the file. The data in the JSON file is a JSON object. It should have a property called blocks which is a JSON list of "selections". Each selection can be a string specifying a block resource id or tag resource id (which will make it match all blocks specified by that tag), or a JSON object with a property called id that is a string specifying a block resource id or tag resource id and a state property that is a JSON object with key/value pairs of block properties to match. If a block matches any of the selections specified, then it will add in the locators specified in this JSON file to the point cloud. The locators are specified in the root JSON object using a property called points which is a JSON array of "points". Each point is a JSON array containing three numbers corresponding to X, Y, and Z position. The position is relative to the block, where a unit block is in the range (0, 0, 0) to (16, 16, 16) which are the same model coordinates as Minecraft Java Edition block models.
Examples for locators can be found here.
MiEx supports atlases, which are large textures that contain other textures. This allows MiEx to output way fewer materials as they have effectively been merged. The file miex_atlas.json located in the resource pack's root folder contains a mapping of the textures to the atlas textures and where in the atlas textures they are located. The file is a json object with an item for each texture where the name is the resource identifier of that texture. The value of the item is another json object with the following values:
| Name | Type | Description |
|---|---|---|
atlas |
String | The texture resource identifier of the atlas texture file. |
x |
Integer Value | The horizontal tile coordinate in the atlas that this texture is located in. Keep in mind that this isn't a pixel coordinate, but rather a tile coordinate! |
y |
Integer Value | The vertical tile coordinate in the atlas that this texture is located in. Keep in mind that this isn't a pixel coordinate, but rather a tile coordinate! |
width |
Integer Value | The number of horizontal tiles in the atlas. In other words atlas_width / texture_width. |
height |
Integer Value | The number of vertical tiles in the atlas. In other words atlas_height / texture_height. |
padding |
Integer Value | The number of times that the texture has been repeated leftwards and downwards. |
Normally this is created by the Atlas Creator tool.
The miex_config.json file located in the root folder of the resource packs provides the main settings on how to export out a world. Any resource pack can specify this file and the final settings are set by composing these files together. So, each resource pack should only specify the settings that it wants to change. Settings specified in resource packs higher up in the active resource packs list will override settings specified in resource packs lower in the list.
Some settings are lists. Specifying a new value for it will fully override previous values. You can also do <name>.add as the setting name, in which case it will add to the list, rather than override. Similarly, you can also do <name>.remove to remove items from the list.
Some settings are maps (json objects). Specifying a new value for it will fully override previous values. Using <name>.add as the setting name, will add the key/value pairs to the existing map (overriding the existing value is a key already exists in the map), rather than override. You can also do <name>.remove and then provide a list of keys to remove those keys from the map.
Whenresource identifiers or names are to be specified, they normally should contain a namespace identifier. If none is given, then the default namespace identifier minecraft is used. So grass_block would be read in as minecraft:grass_block.
The miex_config.json file can have the following settings:
| Name | Type | Description |
|---|---|---|
liquid |
List | A list of block names that should be treated as liquids. |
waterlogged |
List | A list of block names that should have their waterlogged property default to true. |
transparentOcclusion |
List | A list of block names that should occlude other blocks as transparent. Basically, it will occlude other transparent blocks, but it won't occlude non-transparent blocks. |
leavesOcclusion |
List | A list of block names that should occlude other blocks as leaves. Basically, it doesn't occlude other blocks and will generate faces in between other leave blocks (just like the game), but it gets rid of double faces in between leave blocks. |
detailedOcclusion |
List | A list of block names that are not transparent or leaves but should run a more detailed occlusion algorithm, because they use more detailed models than normal blocks. The default occlusion algorithm splits each side of a block up into four squares, allowing it to handle slabs and stairs, but for anything more detailed than that, you want to use this occlusion algorithm. |
noOcclusion |
List | A list of block names that should not be occluded by anything. |
bannedMaterials |
List | A list of texture resource identifiers where any polygons using that texture shouldn't be exported. |
individualBlocks |
List | A list of block names of blocks where each occurrence of that block should be exported out as an individual instance rather than all combined into a big mesh. This allows you to hide specific instances of blocks so that you can replace them with a rig to animate them, like chests and doors. |
caveBlocks |
List | A list of block names of blocks that should be tagged as cave blocks. |
randomOffset |
List | A list of block names that should receive a small random offset on the x and z axis, replicating what Minecraft does for vegetation. |
randomYOffset |
List | A list of block names that should receive a small random offset on the y axis, replicating what Minecraft does for some vegetation. |
forceBiomeColor |
List | A list of textures where any face that uses that texture should have the biome colour exported out regardless of whether tintindex is specified for that face in the model file. |
forceNoBiomeColor |
List | A list of block names that should not have biome colours exported out regardless of whether tintindex is specified for that face in the model file. |
doubleSided |
List | A list of block names whose meshes should be tagged as double sided. By default, geometry is single sided to match Minecraft. To get double sided faces, Minecraft specifies two polygons in the block models. If a block is specified in this list, MiEx will remove one of the two polygons and tag the mesh as double sided. This reduces the polygon count by up to half for those blocks. |
randomAnimationXZOffset |
List | A list of block names that should receive a random offset to their animated textures where the random offset is determined by the x and z axis. This also will apply a random time offset to block animations. |
randomAnimationYOffset |
List | A list of block names that should receive a random offset to their animated textures where the random offset is determined by the y axis. To get a block's random offset determined by all three axis, put the block name in both lists. This also will apply a random time offset to block animations. |
lodPriority |
Map | A map of block names as the key and an integer specifying a priority value for that block. The default priority value for a block is 1. A value of 0 will ban that block from the LOD calculations. The higher the value, the more likely it is that block will be chosen when calculating a lower LOD for the far background. |
lodNoUVScale |
List | A list of block names where the UVs shouldn't be scaled up on the LOD model. Level-of-Detail is implemented by replacing a group of blocks by one bigger block. In order to not make it look like a scaled up version of that block, the UVs are scaled up as well so that the texture repeats and each pixel on that texture is still the same size. However, for some block models this won't work well. For those blocks, you can specify them in this list. |
lodNoScale |
List | A list of block names where the block shouldn't be scaled up when used in LOD. |
ignoreAtlas |
List | A list of texture resource identifiers that should never be replaced with an atlas texture. |
noFaceOptimisation |
List | A list of texture resource identifiers where meshes with this texture applied to them should not be run through the face optimiser. |
separateMeshForBlocks |
List | A list of block names whose geometry should be put into their own meshes rather than be combined with other geometry that share the same textures. |
runOptimiser |
Boolean Value | Turns all optimisers on or off. |
runRaytracingOptimiser |
Boolean Value | Turns the raytracing optimiser on or off. This optimiser can improve performance with render engines that use ray tracing. |
runFaceOptimiser |
Boolean Value | Turns the face optimiser on or off. This optimiser reduces polycount by combines faces into larger faces whenever possible. |
raytracingOptimiserUseMeshSubsets |
Boolean Value | Whether the raytracing optimiser should use geometry subsets to split up meshes or create multiple objects to split up meshes (if set to false). |
fgFullnessThreshold |
Float Value | Specifies the fullness threshold for foreground export chunks when running the optimiser. The optimiser splits meshes up into smaller meshes where each mesh then has a bounding box with less empty space in it. Empty space in bounding boxes has a negative impact on render times. This value specifies how full a mesh's bounding box needs to be for the optimiser to accept it. Otherwise, it will split it up into smaller meshes. The value ranged from 0.0 to 1.0. 0.0 will disable the optimiser. Keep in mind that the higher the value, the more it will split meshes up into smaller meshes, which means that the object count of the scene will increase. This can make it take longer to process the scene. |
bgFullnessThreshold |
Float Value | Same as fgFullnessThreshold but then for background export chunks. |
chunkSize |
Integer Value | The size of each export chunk in Minecraft chunks. Larger chunk sizes can be more efficient, but means less granularity when it comes to choosing which chunks to load or be visible or not. MiEx also does parallelisation based on export chunks. Each export chunk is exported on its own thread. Therefore, the more export chunks there are, the better it can scale to many cores. |
biomeBlendRadius |
Integer Value | The blending radius in blocks for the biome colours. |
smoothBiomeColors |
Boolean Value | If true, it will smoothly interpolate the biome colours within a block, rather than apply the same biome colour to all vertices of a block. |
removeCavesSearchRadius |
Integer Value | The search radius used by the remove caves algorithm to figure out whether a block is in a cave or not. |
removeCavesSearchEnergy |
Integer Value | The search energy used by the remove caves algorithm to figure out whether a block is in a cave or not. |
removeCavesSurfaceRadius |
Integer Value | The radius around a potential cave block where it will look for the surface. Used by the remove caves algorithm to figure out whether a block is in a cave or not. |
removeCavesAirCost |
Integer Value | The cost of an air block used by the remove caves algorithm to figure out whether a block is in a cave or not. |
removeCavesCaveBlockCost |
Integer Value | The the cost of a normal block used by the remove caves algorithm to figure out whether a block is in a cave or not. |
animatedTexturesFrameTimeMultiplier |
Float Value | A multiplier added to the frame times specified in .mcmeta files of textures. This is useful for projects with varying framerates. Minecraft by default runs texture animations at 20 FPS. If your project is for example 60 FPS, then you want each frame to last three times longer and so you should use a multiplier of 3.0. |
renderGamut |
String Value | The gamut that the biome colour tints should be in when exporting. Can be the following values: sRGB, ACEScg, LOOCSG2. |
blockSizeInUnits |
Float Value | The size of a single block in units. This allows you to specify the scale of the world. |
blockCenteredXZOnOrigin |
Boolean Value | If true, the bottom centre of the block will be at (0,0,0). If false, the bottom front left of the block will be at (0,0,0). |
atlasMaxResolution |
Int Value | The maximum resolution in pixels of an atlas texture file. This value will be used for both the width and the height. |
atlasMaxTileResolution |
Int Value | The maximum resolution in pixels of a singular texture in an atlas. This value will be used for both the width and the height. The aspect ratio of the original texture will be preserved. |
exportVertexColorAsDisplayColor |
Boolean Value | Export out vertex colours as USD's displayColor primvar, rather than the Cd primvar. |
exportDisplayColor |
Boolean Value | Export out a displayColor primvar with a preview colour for the block based on the block's texture. This is purely a preview for use in viewports when textures are disabled. |
vertexColorGamma |
Float Value | A gamma applied on vertex colours when exporting out. |
calculateAmbientOcclusion |
Boolean Value | If true, it will calculate an ambient occlusion value and export that out as a vertex color set. |
exportAmbientOcclusionAsDisplayOpacity |
Boolean Value | If true, the ambient occlusion value is exported out as USD's displayOpacity primvar, rather than the CdAO primvar. |
calculateLighting |
Boolean Value | If true, it will calculate Minecraft-style lighting and export that out as a vertex color set. |
blockLightingAdditive |
Boolean Value | If true, lighting from different kinds of blocks will be added additively rather than taking the maximum. Taking the maximum is in line with how Minecraft handles lighting. |
calculateCornerUVs |
Boolean Value | If true, it will calculate a second UV set with texture coordinates into a "corner atlas". This corner atlas can be used to give blocks rounded edges or edge highlights. |
subdivideModelsForCorners |
Boolean Value | If true, it will subdivide faces so that the rounded corners created via the corner UVs don't show up on places where there shouldn't be any. |
memoryPerThread |
Integer Value | A rough estimate of how many megabytes of memory each thread will use to export out a single export chunk. This value is automatically scaled by the configured size of an export chunk. This will help prevent MiEx from running out of memory, by limiting how many export chunks it can export out at the same time. The default value should be good in most cases, but some modded worlds might take more memory to export out, so if you end up running out of memory then increasing this value should help. |
forceDoubleSidedOnEverything |
Boolean Value | If true, forces all models to export out as doubleSided geometry (no backface culling). Minecraft and Hytale terrain are normally all singleSided geometry, but not all render engines support this, so this setting can be used to make sure that things still show up normally for those render engines. Although a few blocks would look slightly different from how they look in the game. |
minCubeSize |
Float Value | The minimum size that a cube may be in models. A value of -1 means no minimum size. This can be used to prevent z-fighting on doubleSided models. |
preventZFighting |
Boolean Value | If true, cubes with the exact same dimensions are scaled to slightly different sizes to prevent z-fighting. Defaults to true. |
maxMaterialNameLength |
Int Value | The maximum number of characters that a material may be. A value of -1 means no limit. Some animation software have a limit on how long a material name may be, which can cause issues as MiEx can sometimes generate long material names. |
useGeometrySubsets |
Boolean Value | If true, combine all meshes within an export chunk into one mesh with multiple material assignments, rather than a different mesh for each material. |
useIndexedUVs |
Boolean Value | If true, UVs are indexed which helps reduce the amount of memory that geometry takes up. |
useIndexedVertexColors |
Boolean Value | If true, vertex colours are indexed which helps reduce the amount of memory that geometry takes up. |
useIndexedNormals |
Boolean Value | If true, normals are indexed which helps reduce the amount of memory that geometry takes up. |
usePointInstancersForIndividualBlocks |
Boolean Value | If true, point instancers are used rather than regular instances for individual blocks. |
usePointInstancersForAnimatedBlocks |
Boolean Value | If true, point instancers are used rather than regular instances for animated blocks. |
useSinglePointInstancer |
Boolean Value | If true, a single big point instancer is used rather than multiple point instancers for each individual or animated block prototype. |
animatedBlocksPointInstancerTimeOffsetMergeRadius |
Integer Value | When animated blocks are exported out using point instancers and they have random animation offsets, each unique animation offset would require its own prototype, which can quickly become a lot. Animation offsets within x number of frames, specified by this value, are merged together to reduce the number of prototypes. |
useIndexedNormals |
Boolean Value | If true, normals are indexed which helps reduce the amount of memory that geometry takes up. |
allowBlockAnimations |
Boolean Value | If true, block animations are allowed to export out if they are enabled in the Advanced Settings Panel. |
animationFrameRate |
Float Value | The frame rate at which it should export out animations. |
animationStartFrame |
Float Value | The frame number at which animations should start. |
animationEndFrame |
Float Value | The frame number at which animations should end. |
usdMetersPerUnit |
Float Value | The value to write out in the metersPerUnit stage metadata on the USD export. |
fillWorldBorders |
Boolean Value | If true, the borders of export regions are filled in, rather than occluded. |
defaultLocalisation |
String Value | Name of the default language file used for translate text components in things like signs. |
exportEntityAsBlocks |
List | A list of entity type ids that should be exported out as if they were regular blocks rather than entities. |
The miex_block_tints.json file located in the root folder of resource packs is used to assign tints and colormaps to blocks. It is a json object with an item for each block. The name of the item is the name of the block (defaults to the minecraft: namespace if none is specified) and the value is a json object specifying the tint.
Each tint object would specify a tint item containing a tint value or tint layers, and it can also specify a states item which is a json object where the names of its items are block property conditions and the value is then a tint value or tint layers. By default a block will get the tint specified by tint, but if it matches any of the block property conditions in states, then it will get the tint specified by that.
A tint value can either be a string containing a colormap name (must include the namespace), a string containing a hexadecimal sRGB colour, or an integer containing a hexadecimal sRGB colour. If a colour is specified directly, then that is the tint it always applied. If a colormap name is specified, then it will look up the tint of in that colormap for the biome that the block is in.
A tint layers is a json object where the names of its items specify tint indices and the values are tint values. This allows you to specify different tints for different tint indices used in block models. So far, all vanilla Minecraft blocks just use a single tint index and so this feature isn't used for those blocks, but if any block model uses multiple tint indices, then this can be used to tint those faces different colours. The tint indices are numbers, where "0" is the first tint index, "1" is the second tint index, and "-1" means no tint index. If you do specify "-1" then that will tint all faces that don't have a tint index specified (or had it set to -1 explicitly). This lets you force tints onto blocks that don't use tint indices in their models. The lowest non-zero tint index specified will also be the default tint applied to any faces with non-zero tint indices that you didn't specify here. You could also use "*" to explicitly specify the default tint.
The miex_lighting.json file located in the root folder of resource packs specifies block lighting information. If calculateLighting in miex_config.json is set to true, then MiEx will calculate Minecraft-style block lighting and export out the resulting lighting values as vertex colour sets on the meshes. The file specifies two different things, light maps and block lighting properties.
The Minecraft-style lighting works by calculating a light level for each block. Light levels are integers that can range from 0 to a maximum of 127, but for Minecraft the maximum is 15. Minecraft keeps track of two different light level types, a sky light level and a block light level. MiEx keeps track of a sky light level and an arbitrary number of block light level types, but each block may only have up to seven block light level types affecting it at the same time. If more than seven block light level types affect it, it will keep the seven highest block light level types. Each block light level type also has a light map associated with it, which will provide the colour and differentiates different light level types.
Light maps specify the RGB colour of the lighting for different light values. They are specified in the lightMaps property of the miex_lighting.json root JSON object. The value is a JSON object whose keys are the names of the light maps. The values are "light map definitions". Light map definitions are JSON objects. It may have a key for each light level, where the key is the light level value and the value is the colour to output for it. The highest light level specified here is the maximum light level that the light map supports. The colour may be specified as a string with an RGB hex value in sRGB, an integer specifying the 24 bit RGB value in sRGB, a JSON array with RGB floats in render space, or a JSON object with the key color that specifies a colour as previously defined and the key intensity which is a floating point that gets multiplied with the colour. If colours for any light levels are missing, then those will be filled in by interpolating neighbouring values, and light level 0 is always forced to black. In a light map definition, you may also specify the property gamma which will specify the gamma in which it interpolates neighbouring colour values. Next to that a light map definition may also specify the property lightGamma which is a gamma of how quickly the light value will falloff to black over distance and defaults to 2.0. Light map definitions can also specify colorSet which would then be the name of the vertex colour set that holds the lighting data for this light map and defaults to lighting.
Light level types that have the same color set are combined into the same vertex colour set. By default this combination matches Minecraft where the combined light level is the maximum of all light levels with that color set. If the setting blockLightingAdditive in miex_config.json is true, then the light is additively combined.
Light maps may have any name, but the name skyLight is reserved and used for the sky light. This can be specified to change how sky light is exported out.
Block lighting properties are specified in the blocks property of the miex_lighting.json root JSON object. The value is a JSON object where the keys are block resource identifiers. The values are "lighting properties" which are JSON objects. Lighting properties may specify the property emissiveLightLevel which is an integer of the light level that this block emits and defaults to 0 meaning it does not emit any light. If emissiveLightLevel is specified, then it should also specify emissiveLightColor which is a string holding the name of a light map associated with the light that this block emits. Lighting properties may also specify lightAttenuationX, lightAttenuationY, and lightAttenuationZ which are integers specifying how much the light levels drop over the distance of this block in the X, Y, and Z directions. It is specified for different directions to match Minecraft Java Edition where light can pass through blocks based on their shape. These values default to -1 which means that it should be automatically calculated based on the block's model and whether it's transparent or not. A value of 0 means that light should not attenuate at all (air attenuates it by 1 light level per block). Blocks that shouldn't attenuate light should typically have a value of 1. A value of 127 means that it fully blocks light.
Minecraft has the option of "smooth lighting" which is enabled by default and introduces ambient occlusion in its lighting. MiEx can also calculate this ambient occlusion as its own vertex colour set by setting the setting calculateAmbientOcclusion in miex_config.json to true.
For Blender, there is the BlenderBlockLighting example resource pack which enables lighting calculations and sets up the materials to output the lighting to three different shader AOVS lighting_sky, lighting_blocks, and lighting_albedo. You still need to register these shader AOVs in Blender's render settings. Then in the compositor, you can multiply the lighting_sky and lighting_blocks with lighting_albedo and then add them together and add that to the main image. The lighting_sky and lighting_blocks are thus without any textures, which makes it easy control the lighting during compositing.
For other applications, the easiest approach would be to follow a similar scheme. Read in the lighting vertex colour sets, multiply it with the ambient occlusion vertex colour sets if desired, and output that to AOVs in the materials. Then during compositing it can all be combined.
Another approach, could be to already combine all of the lighting, multiply it by the texture, and then output that via the emission. Care should be placed to add in a switch based on the ray type, so that it only outputs this via the emission for camera rays. This does reduce the amount of control during compositing that you'd have, but it would make it show up during regular lighting.
Modifiers are simple node graphs that run either per block or per face when exporting out a world and can be used to modify things like biome colours, vertex color sets, and face normals. They are located in modifiers/<namespace>/block and modifiers/<namespace>/face in any kind of resource pack. For more information about modifiers, see the Modifiers page.
World translations are files that map blocks, biomes, file paths, and ids from one name to another. This is mainly used for when loading in Bedrock Edition worlds, to map Bedrock Edition blocks and biomes to Java Edition blocks and biomes to allow Bedrock Edition and Java Edition worlds and resource packs to be used interchangeably. They are located in translation/minecraft/java, translation/minecraft/bedrock, and translation/minecraft/hytale in any kind of resource pack. For more information about translations, see the World Translations page.
MiEx exports out materials for you, so that you don't have to set them up after importing the export into your animation software. It generates these materials using material templates, which are defined in resource packs. Material templates are located in materials/minecraft/templates in any kind of resource pack. For more information about material templates, see the Material Templates page.
The PBR Generator tool lets you batch process textures in resource packs, applying a node graph of image manipulations to those textures. This can be used to generate PBR textures from non-PBR resource packs and to convert a resource pack from one PBR format to another. The node graphs are located in pbr/<namespace>/nodegraphs in any kind of resource pack. For more information about PBR and the PBR Generator, see the PBR page.