-
Notifications
You must be signed in to change notification settings - Fork 78
Resource pack based Texture Config
This applies to AntiqueAtlas 6.0.0 or newer
Though the generic idea of how textures are done in AntiqueAtlas stayed the same, all configurations moved to resource packs.
As resource packs are client-side only, the server isn't involved in the rendering of the map at all.
The server just transmits a representation of the world to the clients as tile data.
Tiles are either an identifier of a biome, like minecraft:birch_forest
, or an identifier of a pseudo biome used in AntiqueAtlas, like antiqueatlas:ravine
. Every tile gets assigned exactly one Texture Set. Texture sets define the visual representation in the atlas and can be reused for similar tiles. For example, different forest biomes might share the texture set antiqueatlas:forest
. To improve the visual diversity, texture sets can list several different textures.
Note to mod authors: You can either ship the files as part of your own mod, or create your own resource pack and load that on the clients.
If you are working on support for new biomes, you definitely need to define the texture sets used for tiles.
This translation is defined in individual files located under assets/<modid>/atlas/tiles/<biome>.json
.
For instance, for the vanilla biome minecraft:birch_forest
, this path is assets/minecraft/atlas/tiles/birch_forest.json
.
This JSON file only contains two keys, i.e., version
and texture_set
. Where the texture_set
defines the texture set used for the biome.
For the birch forest, the content of the file looks like this:
{
"version": 1,
"texture_set": "antiqueatlas:birch"
}
Note: As AntiqueAtlas defines the texture sets it's bringing with it, even those used for all vanilla biomes, the built-in texture sets all start with
antiqueatlas:
and notminecraft:
.
Texture sets are defined under assets/<modid>/atlas/texture_sets/<name>.json
. For example, the texture set antiqueatlas:birch
is located under assets/antiqueatlas/atlas/texture_sets/birch.json
. The file contents of the texture sets can be a bit more involved. However, in most cases, it should be enough to only list the textures used for the texture set. For example, the file contents for the antiqueatlas:birch
texture set looks like this:
{
"version": 1,
"data": {
"textures": {
"antiqueatlas:birch": 1,
"antiqueatlas:birch2": 1
}
}
}
The textures
object list all textures and their associated weights. The higher the weight, the more prominent the particular texture will be used. The weight must be a whole number greater than zero.
Note: You should make sure that the listed textures can tile together! (Tiling in the sense of they don't look messy when drawn directly next to each other)
Any biomes, which are shores need a bit of extra treatment. You need to define the "water" texture set, which this shore connects to. For example, while a regular overworld shore has antiqueatlas:water
as water, in the nether, the antiqueatlas:lava_shore
uses antiqueatlas:lava
as "water". A space mod adding the moon Titan may add a space:methan_shore
that uses space:liqud_methan
as "water".
Example:
{
"version": 1,
"data": {
"shore": {
"water": "antiqueatlas:water"
},
"textures": {
...
}
}
}
Note: From a technical view point, shores stitch to every texture_set, except the texture set defined as water. See the next section for more details on stitching.
Note: Make sure that all shores that could be connected to the same "water" pool use the same "water". In particular, you probably DO NOT want to define your own water texture set for shores used in the overworld.
Sometimes different texture sets should be drawn without a border between them when rendered next to each other. For example, texture sets representing snowy tiles should stitch together such that there are no borders between neighboring chunks. If a texture should stitch to another texture, the stitch
object is used. The keys are the other texture set. Possible values are both
, vertical
, and horizontal
. These define the directions in which stitching will be done, which is almost always both
. Exceptions are textures like the nether bridge x/z
, which have an inherent direction.
Example for the nether bridge:
{
"version": 1,
"data": {
"textures": {
...
},
"stitch": {
"antiqueatlas:nether_bridge_gate": "both",
"antiqueatlas:nether_tower": "both",
"antiqueatlas:nether_hall": "both",
"antiqueatlas:nether_fort_stairs": "both",
"antiqueatlas:nether_throne": "both",
"antiqueatlas:nether_bridge_x": "horizontal",
"antiqueatlas:nether_bridge_end_x": "horizontal",
"antiqueatlas:nether_bridge_z": "vertical",
"antiqueatlas:nether_bridge_end_z": "vertical"
}
}
}
Note: When different texture sets are stitched together, this as well means, that each texture of every texture set needs to tile to every other texture of any texture set involved.
You can make your own textures and assign them to any tile. Your textures must follow the Autotile layout. Examples:
In order to fit in with the default texture style, your textures should have a transparent background and be drawn with the single color 0x330000
(dark brown) with various alpha (transparency) levels.
During the load of a resource pack, all .png
files under assets/<modid>/textures/gui/tiles/<texture>.png
are read. These will be available to texture sets under the shortended id <modid>:<texture>
.
For example, the texture set antiqueatlas:birch
references the texture antiqueatlas:birch2
. This means AntiqueAtlas will look for the actual texture file under the path: assets/antiqueatlas/textures/gui/tiles/birch2.png
.