Resource pack based Texture Config

This applies to AntiqueAtlas 6.0.0 or newer

Overview

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.

You can either ship the files as part of your own mod, or create your own resource pack and load that on the clients.

Tiles to texture set translation

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 used for all vanilla biomes, they start with antiqueatlas: and not minecraft:.

Definition of texture sets

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_set/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)

Shores

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.

Stitching (advanced topic)

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"
    }
  }
}

Textures

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.