Armor Model API

# Armor Model API Renders armor with **custom geometry** authored in the Bedrock/GeckoLib `.geo.json` format, through the **vanilla armor rendering pipeline**.  ## Capabilities - **Custom armor geometry** per armor set: robes, pauldrons, hats, skirts — any cuboid-based Blockbench model - **Per-slot rendering** with the standard armor bone convention, including separate **boot bones** and a chest-anchored **waist bone** for leg pieces - **Armor trims** with per-set trim textures (vanilla smithing-table trims, your art) - **Emissive glowmasks** — the hand-authored `_glowmask.png` convention; pixels that stay bright in the dark - **Radiant glow** — a high-luminance variant that burns toward white and feeds shader-pack bloom - **Custom render layers** — a small interface for adding your own passes (extra overlays, effects) - Everything vanilla armor does comes for free: pose and animation following, sneaking/swimming, armor stands, baby mobs, dyed leather color, enchantment glint, the glowing outline effect ### How it works - **Loading** — on resource load (and every F3+T reload), each registered `.geo.json` is parsed and baked **once** into a vanilla `ModelPart` tree (the same `TexturedModelData` every vanilla entity model is built from), cached until the next reload. Textures are plain resources, resolved by the render layers on demand — nothing is preprocessed. - **Hooking in** — when an armor piece is about to render, the library steps in per registered item: on Fabric through Fabric API's `ArmorRenderer` hook, on NeoForge through a small equivalent mixin. Vanilla's overlay rendering is skipped for that piece and the dispatcher renders the baked model instead — vanilla pose copied on, slot visibility applied. Unregistered items are untouched. - **Pass order** — each piece draws as a stack of passes over the same model: **base texture → your render layers** (glow, then trim so it lands on top), with enchantment glint riding the base pass. Renderers built through the fluent API keep the layers sorted into that stack automatically; a renderer constructed with an explicit layer list draws them in list order (see [Render layers](#render-layers)). Every extra pass is just the model rendered again with a different render layer and buffer. From bake to buffer this is 100% the vanilla code path — the same pose copy, render layers, and buffers vanilla armor uses. That is the whole compatibility and performance story: Sodium, Iris, and anything else that works with vanilla armor sees ordinary vanilla model rendering. There is no custom vertex pipeline. ## For developers For developer documentation, check out the GitHub readme.