Modding:CompositeTexture
CompositeTexture is the type of the json object stored in the textures
property of blocks, items, and entities. Here is an example from a block with the surrounding textures dictionary. Note that the composite texture is only the part that contains the "base" field.
textures: {
all: { base: "block/glass/{type}" },
}
Properties
Property | Type | Default | Usage | Reference |
---|---|---|---|---|
CompositeTexture |
||||
base |
string | required | The asset location of the main texture. | Any block |
overlays |
deprecated: array of strings | empty | Asset locations for overlays. Use blendedoverlays instead. | - |
blendedoverlays |
array of overlays | empty | Combines the overlay textures with the base texture. | door |
Each entry of the array is a simplified texture, with the fields { base: "block/wood/debarked/{wood}", blendedOverlays: [{ base: "block/wood/door/overlay-wide", blendMode: "Overlay" }] }
The available blend modes are:
|
||||
alternates |
array of composite textures | empty | If alternates are present, every time a block is placed in the world, either the base texture or one of the alternates is randomly chosen. Alternates can also be chosen through a base wildcard. | rock |
The top level rotation and overlay properties do not apply to alternates, but those property can be set directly on each alternate. Example that directly specifies the alternatives: {
base: "block/clay/hardened/{type}1",
alternates: [{ base: "block/clay/hardened/{type}2"}, { base: "block/clay/hardened/{type}3" }],
}
Example that uses the base wildcard to specify alternates. Every file matching the wildcard is registered as an alternative. { base: "block/stone/rock/{rock}*" }
|
||||
tiles |
array of composite textures | empty | Similar to alternates , this is a list of different textures to use. The difference is that these alternate textures are used in a repeating grid pattern. |
tilingcobblestonetest |
{
base: "block/stone/cobblestone/tiling/1",
tiles: [
{ base: "block/stone/cobblestone/tiling/*" }
],
tilesWidth: 4
}
|
||||
tilesWidth |
integer | 0 | The width of the tile grid. Every this many textures from tiles forms a new tile row. This property only has an effect if tiles non-empty. |
tilingcobblestonetest |
rotation |
integer | 0 | Amount to rotate the texture counter-clockwise. The number must be a multiple of 90. | planks |
alpha |
integer | 255 | 255 keeps the input alpha channel without altering it. Other values are a percentage to adjust the texture alpha channel. For example, 200 doubles the alpha channel in the input image. | - |
For example, 50 would half the alpha values in the texture (make it more transparent), and 200 would double the alpha values in the texture (make it more opaque). |
Video Memory Cost
All of the properties that alter a single image, such as , are convenient for remixing the textures.
Composite textures are processed into BakedBitmaps. All of the properties that modify a single texture are baked into the bitmap, including rotation
, blendedoverlays
, and alpha
. The baked bitmaps are loaded into the video card memory through the texture atlas. If two different blocks use the same composite texture (including the same rotation
, etc..), then those blocks share the same entry in the texture atlas. However, if the rotation property is different, then those composite textures are stored as different baked bitmaps in the texture atlas.
The planks block has oriented variants. The variants use the "cube" drawtype. They share the same base textures but rotate them using the rotation
property of the composite textures. This cases every 90 degree rotation to be separately loaded into the texture atlas.
{
code: "planks",
// The "cube" drawtype is inefficient for oriented blocks
drawtype: "cube",
texturesByType: {
"*-ud": {
all: { base: "block/wood/planks/{wood}*", rotation: 90 }
},
"*-we": {
all: { base: "block/wood/planks/{wood}*", rotation: 0 }
},
"*-ns": {
all: { base: "block/wood/planks/{wood}*" },
verticals: { base: "block/wood/planks/{wood}*", rotation: 90 }
},
},
}
The altar block also has orient variants. However, it accomplishes the rotations through the rotateY
field of the shape
block property instead of the textures
property. Even though the shapes are rotated, they use the same textures. Internally the rotation is accomplished by changing the uv coordinates of the triangles. So it is more efficient to create oriented variants by rotating the shape rather than rotating the textures.
{
code: "altar",
// drawtype: "json" is the default when shape is defined.
shapeByType: {
"*-north": { base: "block/basic/cube", rotateY:0 },
"*-east": { base: "block/basic/cube", rotateY:90 },
"*-south": { base: "block/basic/cube", rotateY:180 },
"*-west": { base: "block/basic/cube", rotateY:270 },
},
textures: {
up: { base: "block/stone/altar/top" },
down: { base: "block/stone/altar/bottom" },
south: { base: "block/stone/altar/front" },
north: { base: "block/stone/altar/back" },
west: { base: "block/stone/altar/left" },
east: { base: "block/stone/altar/right" },
},
}
Wondering where some links have gone?
The modding navbox is going through some changes! Check out Navigation Box Updates for more info and help finding specific pages.
Modding | |
---|---|
Modding Introduction | Getting Started • Theme Pack |
Content Modding | Content Mods • Developing a Content Mod • Basic Tutorials • Intermediate Tutorials • Advanced Tutorials • Content Mod Concepts |
Code Modding | Code Mods • Setting up your Development Environment |
Property Overview | Item • Entity • Entity Behaviors • Block • Block Behaviors • Block Classes • Block Entities • Block Entity Behaviors • Collectible Behaviors • World properties |
Workflows & Infrastructure | Modding Efficiency Tips • Mod-engine compatibility • Mod Extensibility • VS Engine |
Additional Resources | Community Resources • Modding API Updates • Programming Languages • List of server commands • List of client commands • Client startup parameters • Server startup parameters Example Mods • API Docs • GitHub Repository |