CoderSkins

Start Page Browser Play! This page MT worlds Player Basics Bucket Game Downloads Contact Devel Center

minetest.org minetest.io 9,000 gits CoderChat EdgyNet

---

Introduction

This page discuss CoderSkins. CoderSkins is the skins system used by Bucket Game.

CoderSkins Features

CoderSkins supports many features including:

• Skin browser with preview
• Both GUI and CLI (command) interface
• Works in Bucket Game with both MT 4 and MT 5
• Fully integrated with 3D Armor
• Supports multiple skin image shapes
• Advanced architecture (see below)

CoderSkins Advanced Architecture

CoderSkins has the most advanced architecture of any MT skins system. This section explains some of what's under the hood.

---

A 3D model typically has an associated "materials" array. Each materials array contains one or more "material" entries. We'll refer to such entries as "materials" for short.

Early "materials" stored color, "shininess", "roughness", and "alpha". These days, they store a number of additional properties as well.

A "material ID" is an index in the materials array. Note: The first index may be 0, 1, or something else depending on the platforms used.

Each polygon in a model is assigned a material ID. Note: Many polygons may share the same material ID.

---

There's a face-list which defines the polygons that are to be used in a given model. The face-list doesn't directly specify the locations of the polygons in 3-space. It references external vertex data which stores that information.

Each face-list entry typically stores one material ID and 3 or more vertex IDs (where each vertex ID identifies the 3-space location of one vertex in the vertex data).

---

In the 1980s, a supplemental mechanism known as "UV maps" evolved. The "UV maps" approach works like this:

A 3D model typically has one or more "model texture" images. Each may contain multiple types of practical textures (such as "brick" or "grass") combined to produce a single larger image.

The textures may be organized, in each model texture image, in different ways. It isn't necessarily as simple as paste a set of square practical textures together to produce a larger model texture.

A 3D model typically has one or more "UV maps". Each UV map is a definitions table that lists sets of 2D polygons.

In the modern era, "materials" entries specify exactly one UV map. So, a face-list entry indirectly specifies one UV map by way of the materials ID that it [the face-list entry] stores.

The 2D-space polygons stored at the UV-map level need to line up with the 3D-space polygons stored at the face-list and vertex-data level to the following extent:

• The number of polygons needs to be the same
• The side count for corresponding polygons needs to be the same
• Corresponding vertexes need to be listed in the same order

A UV map is used as follows: Sub-regions in a particular shape associated with the UV map are copied out of the model texture associated with the UV map. One sub-region is copied for each of the 2D-space polygons in the UV map. It's used to fill the corresponding 3D-space polygon.

---

There may be multiple UV maps. This is due to the fact that each UV map is designed to select texture image subregions of a different shape and a particular model may need to use multiple shapes in this context.

---

"UV maps" aren't absolutely required but their use became common after the 1980s. Poikilos cites the rise of CGI in movies starting in that decade as a turning point:

"For anything that wasn't supposed to look abstract, UV maps were pretty much necessary."

The most advanced use of non-UV map models in movies was probably in the 1982 film "Tron". You generally need to use UV-maps for anything much beyond "Tron" that needs to fit visually into a concrete world."

"Young Sherlock Holmes" (1985) was an early example of the use of UV maps in CGI. The stained-glass creature in that film was modeled using this mechanism."

---

The older Minetest 3D character models were based on just a single material ID. It allowed the use of a single UV map to put a "skin" on a character.

In 2013, "StuJones11" created a "3D Armor" mod that used 3 material IDs:

ID #1 or "pngim_rect": The model texture image used is a 2:1 ratio image (such as 64x32). It defines a low-resolution skin similar to old Minecraft skins.

ID #2 or "pngim_armor: The model texture image used is a 2:1 ratio image (such as 64x32) again. It's used in conjunction in a 64x32 skin and adds armor.

Some types of armor go, in a type-2 texture, in the same place as the corresponding body parts in the 64x32 skin. Other types [such as shields] go at unique reserved locations in the overlay.

ID #3 or "pngim_wield": The model texture image used is a 1:1 ratio image (typically 16x16).

Note: "pngim_wield" is different than the Minetest API's "wield-item" feature. "wielditem" only applies to the simplified HUD version of the character model that is part of the Minetest core engine.

Sizes larger than 16x16 may have a negative effect on the "wield-item" feature.

In 2017, Jordach aka Maciej Kasatkin implemented a material that he assigned material ID #2 to. This conflicted with the StuJones11 ID set and so Jordach's change wasn't compatible with 3D Armor. Jordach's ID #2 material was as follows:

ID #2: The model texture image used was a 1:1 ratio image (such as 64x64). It defined a high-resolution skin similar to newer Minecraft skins.

OldCoder subsequently made 3D Armor and Jordach's enhanced skins work together through the simple kludge of truncating 64x64 skins to 64x32 when players put on items 3D Armor. This sacrificed details, of course.

In 2021, Poikilos moved Jordach's ID #2 to ID #4 and made various changes to Bucket Game and 3D Armor. The result was a MT "_game" that supported all 4 "material" types as well as both MT 4 and MT 5 clients at the same time.