My hexagon guide^[1] has many conversion routines — axial to cube, cube to offset, hex to pixel, etc. Sometimes these steps can be combined into larger steps or separated into smaller steps. There’s a balancing act between:

1. give the reader the final answer
2. give the reader the ingredients so they can adapt them as needed

My original goal was to provide code for these 22 conversions:

However, I didn’t know all the conversion formulas, and ended up providing only these 16:

So that means if you want to go in reverse from pixel to odd_r, you build the chain pixel → axial → cube → odd_r. Not great.

Things got more complicated when I added doubled_h, doubled_v. And I want to add several spiral systems:

Last week I wanted to add conversions for non-uniform pixel sizes. That was adding far more edges to this graph. I simplified by splitting the pixel conversion into multiple steps:

The problem is that … I think most readers want a formula that solves their problem. Breaking things into steps makes it easier for me, and I think it’s better for understanding what’s going on, but it’s less convenient for the reader. I took the single step conversion from axial to pixel:

And split it into axial to cartesian and then scaling the cartesian:

Why? Because it allows scaling non-uniformly, to match a desired pixel art size:

If we inline the calculations we end up with this:

It’s nice. There’s no more sqrt(3) there!

By keeping the steps separate, it allows for adapting to more situations:

• translate transform to get a non-zero origin
• scale transform to get non-regular hexagon sizes
• rotation transform to get angles other than “pointy” and “flat”
• isometric view combined a shear and rotation operation

I think it’s easier to understand inverting the process from hex-to-pixel to pixel-to-hex when the steps are separate. I have mixed feelings about this change but I made it in part because I wanted to show how to adjust the conversions to match the size of art assets.

You can see the new code in the hex-to-pixel^[2] and pixel-to-hex^[3] sections of the hexagons guide. I’ve added a section where you can enter the pixel art asset size, and I output the conversion routine. Maybe I can extend that interactive code generator to work for all the coordinate systems. Let me know what you think. I might change it back based on feedback.

While working on this section, I realized I want to add more direct support for doubled coordinates. It probably makes more sense to go from offset coordinates to doubled to pixel than offset to cube to axial to pixel. But that will wait for another day. [Update: that day was in mid-June.]

I also realized that the main page has pixel-to-hex that returns a rounded value, but the implementation guide has a pixel-to-hex that returns a fractional value, and you have to round it yourself. That’s because the fractional value is sometimes useful. I updated the implementation guide to provide both.