hex-grid-axial

Implements axial coordinate math for hexagonal grid positioning in Three.js.

1|Updated Mar 31, 2025
One-click install
npx skills add https://github.com/Iker1211/Resources-Directory --skill hex-grid-axial-iker1211
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: hex-grid-axial
Source: https://github.com/Iker1211/Resources-Directory/tree/main/skills/mnt/user-data/outputs/skills/hex-grid-axial
Command: npx skills add https://github.com/Iker1211/Resources-Directory --skill hex-grid-axial-iker1211

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires three.

What problem does it solve? Positioning hexagonal tiles in 3D scenes is error-prone when using offset coordinates, which require parity-dependent neighbor formulas and complicate pathfinding. This Skill provides calibrated axial coordinate math so every tile position, neighbor lookup, and distance calculation is uniform and correct. ## Core Features & Use Cases - Axial-to-World Conversion: Convert (q, r) coordinates to Three.js Vector3 positions using constants calibrated for the KayKit Medieval Hexagon Pack (HEX_W = 1.82, HEX_H = 1.575). - Grid Operations: Compute the 6 neighbors of any cell, hex distance between cells, and generate rectangular grids procedurally or from world.json data. - Elevation & Rotation: Place props and occupants on elevated layers and apply deterministic 60-degree tile rotations for visual variety. - Use Case: You are building a Three.js strategy game map with KayKit hex tiles. Use this Skill to load cells from world.json, position each tile with axialToWorld, and implement A* pathfinding with clean neighbor math. ## Quick Start Use the hex-grid-axial skill to position the tiles from my world.json file in a Three.js scene using axial coordinates.

Frequently Asked Questions about hex-grid-axial

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I convert axial coordinates to Three.js world positions?▼

Use the formula x = HEX_W * (q + r * 0.5) and z = HEX_H * r for pointy-top hexagons. With KayKit-calibrated constants HEX_W = 1.82 and HEX_H = 1.575, cell (1, 0) maps to (1.82, 0, 0) and cell (0, 1) maps to (0.91, 0, 1.575).

Axial vs offset coordinates for hex grids: which should I use?▼

Axial coordinates (q, r) are superior for any grid logic because neighbors always use the same 6 deltas with no parity conditionals, and distance is max(|dq|, |dr|, |dq+dr|). Offset coordinates require different neighbor formulas for even and odd rows, making pathfinding error-prone.

How do I calculate distance between two hexagonal cells?▼

In axial coordinates, hex distance equals max(|q1-q2|, |r1-r2|, |q1+r1-q2-r2|). This works because the implicit third coordinate s = -(q+r) makes the distance (|dq| + |dr| + |ds|) / 2, which simplifies to the max formula.

Can I migrate existing offset coordinate data to axial?▼

Yes, use the conversion q = col - floor(row / 2) and r = row for offset data where even rows have no displacement. After migration, store only (q, r) in your data files and always derive 3D positions from the axial coordinates.

Why should world data store coordinates instead of 3D positions?▼

Storing (q, r) keeps data independent of rendering constants like tile spacing, which may change when assets are recalibrated. The 3D position is always computed from axial coordinates at runtime, so data stays valid across asset changes.