Which way to subdivide a hex grid?

Question

Here are, it seems, two ways to draw a smaller grid of tiles from an initial hexagon:

Hexagon subdivided

On the left, we halve the side length \$s\$ and create most of the new tiles centered at the midpoint of sides. The area of the new regular shapes is one quarter because the parent sees one and six halves children. On the right, we use the vertices as centers for the new hexagons; the side length goes to \$\frac{\sqrt{3}}{3}s\$ and the area a 1:3 ratio because there will be one and six thirds children reporting to the first hexagon.

I am hoping we think through the advantages of these systems. The first may be of more convenience and reduced overhead, which could be outweighed by artistic value. But I suspect there are other criteria for my purposes and it's also a general question. (For now feeling a little bewildered by geometry.)

My project is a game map (in this iteration, a globe; both subdivision methods generalize to a starting icosahedron I think) which should have nice "zooming" properties. I want to use larger tiles to summarize features under them which can be generated in more detail at will.

• Kromster: Seems like the question should be structured other way round. Firstly clarify your goal, what are you trying to achieve? What goals and criteria are there. Then solutions you have identified, then their properties and details.
• clwhisk: @Kromster That's good enough advice but I thought this question would be welcome.
• Kromster: It is welcome, I'm just adding my 2c to help to improve it
• amitp: There are three that I know of, starting from the sides, the vertices, or the centers. See the K=3, K=4, K=7 diagrams on en.wikipedia.org/wiki/Central_place_theory#Predictions

Answer 1

I'm working on a very different project, but with similar desires: A reasonably intuitive way to overlay larger hex grids over smaller hex grids such that the alignment isn't too complicated.

One feature I'm requiring in mine is for the larger hexes to be required to be at the same angle as the smaller hexes, which means that if I were to use the right-hand option you provided, I would be required to iterate that twice before getting an acceptable grid. (Since your right-hand subdivision rotates the hexes by 30 deg, performing the subdivision twice rotates a total of 60 deg, resulting in the same alignment as the original.)

So that's one pro-con you can weigh: Do the original hexes align in angle with the subdivided hexes? Users may get confused if every time they zoom in, the cardinal directions shift from N/S, ENE/WSW, WNW/ESE to E/W, NNE/SSW, SSE/NNW. If you intend your game to have keyboard controls for accessibility, this is particularly relevant, as the keyboard layout would have to alternate between two different interpretations, confusing both to program and to use as a player.

It seems that one implicit rule you're using is, for every hex in the original grid, one hex in the subdivision must have the same center. This makes sense when the thing the viewer is focusing on are the areas of the hexes. However, in my project, the viewer is focusing on the edges, the boundaries, so I am instead trying to optimize for subdivisions that share as much edge length as possible. If you're using the hexes to model things in your game such as political boundaries, you may similarly prioritize sharing edges between zoom levels.

There's two ways you can describe the subdivision I show in the figure below.

1. Every white hex is subdivided into three and three-thirds hexes. (Scale factor is 1/2, so each hex has 1/4 the area.) Three vertices each get a 1/2-size hex aligned with both edges, while the alternate three vertices each get a 1/2-size hex centered on the old vertex.

2. Every white hex is subdivided into kites in the standard way. Then three kites are subdivided into three pieces to be shared with neighboring kites to reform hexagons.

White-lined kites in a large hex grid overlaying a black-lined hexagonal tiling.

I mention the kite subdivision because it (or the triangular grid it reveals) may help you realize other kinds of subdivisions convenient for whatever you're doing. (After all, the triangular grid is the dual of the hex grid, exchanging vertices for faces, so each implies the other.) It's also plausible that showing the kite (or triangular) grid while zooming occurs may help users understand how the subdivision is occurring. (That's true for your subdivisions as well: The left-hand one could display the standard subdivision of each hex into 6 equilateral triangles, while the right-hand one could display the kite subdivision I used.)

For your two area-focused subdivisions, zooming with just the basic lines is likely already too noisy. In that case, you could instead remove the line display and show center dots of all the hexes while zooming. That way, it would very simply illustrate the part that is preserved from zoom level to zoom level, and give an intuition for how detailed the map currently is.