# Elevation model for hexagonal game grids

TL;DR:

Where should elevation be anchored on a civ-style hexagonal grid? Center, side or vertex? (Or more complex?)

Question proper:

Consider for a moment a classic game we all know and love (maybe?), Sid Meier's Alpha Centauri. The map model introduced the brand new concept of visible terrain elevation to the classic Civ formula. In SMAC, every vertex of the game board had an elevation, allowing the map beautiful rolling hills, a complete necessity, considering the mind worm boils waiting around every corner.

Would a vertex-only elevation map translate neatly to a hexagonal grid?

The obvious alternatives are side-based elevation mapping and center-based elevation mapping; as well as inner-vertex elevation mapping (giving the opportunity for cliffs! Yay!)

The last option is applying a triangular lattice to the game grid encompassing centers and vertices, and having vertex-only or inner-vertex elevation.

Which of these options is likely to work well? Which are likely to suck all the juice out of the CPU and RAM in a hurry?

-

Would a vertex-only elevation map translate neatly to a hexagonal grid?

It depends on the tessellation of the grid. If you tessellate your plane like so, then yes.

In this case, you can change the green triangle (x6) any way you like:

Which of these options is likely to work well?

They all work well. Chances are that you'll be using multiple methods, anyway. You can't just use mid-point elevation unless you just want one-tile mountain features, you'd have to "raise" the edges as you go up a mountain if you want multiple-tile topography.

Which are likely to suck all the juice out of the CPU and RAM in a hurry?

This is a non-issue (unless you're writing this for some sort of embedded system?) as all the map generation work will be done before anyone plays the game, during the loading phase.

-
By midpoint elevation I mean a situation where you can only set and store the elevation for the midpoint; if two hexes have different enough elevations, edges around them would be lifted to match the elevations of their faces. (e.g. 1,1 has an elevation of 3; 1,2 has an elevation of 5: the face 1,1:1,2 has an elevation of 4 when rendered). – Williham Totland Nov 4 '10 at 14:47
It's not a non-issue at runtime because you'll need to be able to calculate paths for movement, height differences for combat advantage, and so on. It might be a non-issue at runtime because a dozen more floats per hex aren't really that bad on most platforms, but the data still needs to be there to use the map. – user744 Nov 4 '10 at 15:40

Great that at least some one else thought of this. To bad I only encounter this page several years later. However, I am going to answer your question for the basic hexagons instead. The pictures that have been shown until now are not 100%. And on a 1 meter map the grid will be out of shape. Meaning no 60 degree turn possible.

I have been experimenting on:

• Different sizes of hexagons: Which triangle (in pixels) basis gives the highest accuracy on 1 meter maps once printed out. This includes having them as perfect as possible when turning them 60 degree's. Also when turning them 180 degree's for refitting.

• Different combined layers of hexagons.

• Single hexagons for cutting out high detailed pictures (RAM = insufficient at big maps).

• The exact limits of my computer plus what I feel is allowable.

I did not experiment yet on having elevation by making different shaped hexagons. But I do know that the basis needs to be correct before making the elevation.

Summary:

• Accuracy of 1 mm or less on a 1 meter map. The 60 degree rule.

• I need lines that can fit themselves when turned 180 degree´s.

• I need the triangle to fit on my screen with maximum zoom.

I narrowed down my selection to 3 with these rules:

Small:

• Size; +26 x +45, 27 x 46 pixels

• Inaccuracy on 1 meter; 0,74 mm

• Sequence; 131213131312131

Medium:

• Size; +41 x +71, 42 x 72 pixels

• Inaccuracy on 1 meter; 0,20 mm

• Sequence; 1312131313121313131312131

Large:

• Size; +56 x +97, 57 x 98 pixels

• Inaccuracy on 1 meter; 0,05 mm

• Sequence; 1312131313121313131213131312131

The one's are 1 pixel.

The two's and three's are groups of 2 pixels. A 2 is 4 pixels in total and A 3 is 6 pixels in total.

If you add a sequence up, you will see that they are the width in pixels. If you add them up and counting 4 and 6 instead of 2 and 3. You get the hight in pixels.

The + numbers are what you add in pixels when you place 2 triangles on top of each other or against each other.

Feel free to ask questions. On my email.

-
It's not clear how you are addressing the actual question. You have discussed the topic somewhat, though your overall point is also difficult to isolate. What do these pixel sizes have to do with hexagonal geometry and elevation? – Seth Battin Sep 19 '14 at 20:08
Another thing: StackExchange is not a traditional forum. The helpful information should be included in the post, and readers should not need to email you to get a complete answer. Also because this is not a forum, there is no way for people to re-question your answer. So not only is inviting questions inappropriate, it will not work. See gamedev.stackexchange.com/help/how-to-answer. – Seth Battin Sep 19 '14 at 20:18