Project Hex Part 5 – Growing Grass

 By Shamus Nov 17, 2010 74 comments

Last time I created a texture for the world. It was okay.

hex_texture11.jpg

The next step is to give this texture a bit more depth and to make it less rigid and mechanical. The first thing I want to do is make the grass edging a little more interesting. I’m going to be basing my efforts on this tutorial. (Halfway down the page.) It shows some grass hanging over onto some dirt. Two things I’m taking away from this:

1) The grass looks much more interesting if it seems to spill over onto the non-grass.
2) The surface looks “deeper” if the grass casts shadows onto the non-grass. The shadows don’t even need to be accurate based on the direction of the light source. (And we don’t have a light source yet anyway.) It just needs a simple drop-shadow effect where it outlines the grass in dark pixels. The eye will do the rest of the work.

Just to recap how I’m drawing the world. I’m putting a splat of texture at each point of the grid, like so:

hex_edges2.jpg

But I draw the splats large, so that they overlap. I draw all of the deep water ones first, then the shallow water, then the beach, then the grass, and so on. In the end we get a nice layered effect:

hex_edges3.jpg

But I want that grass that borders the sand to have a drop shadow effect. So what we do is this:

Before I draw the grass splat, I draw a splat that is slightly larger, and colored pure black:

hex_edges4.jpg

Then once the black is down, I draw the grass splats. Since they’re smaller, the black peeks out a bit around the edge:

hex_edges5.jpg

But of course that black outline is much too harsh. Let’s make it slightly transparent:

hex_edges6.jpg

Now, at the end of the last entry I was fiddling with the splat sizes. It turns out that grass looks better if the splats are smaller, while water and beach look nicer with really big splats. So I adjust things so that the splats of each layer can be sized independently.

hex_edges8.jpg

I like this better. The downside is that internally the game isn’t taking these oversized splats into account. Note the hex I highlighted in the above image. That’s shallow ocean as far as the game is concerned. But we got sand all over while we were drawing. The player will see beach, but find that the game treats it as water. In some games this would be unacceptable. I’m not sure if or how this will impact my game, so I’ll ignore this for now and move on.

The next step is to make the grass hang over onto the beach a bit. Right now I’m using this texture for the grass:

hex_edges1.jpg

(Again, pink = transparent.)

I’d like the grass to sort of hang over onto the sand, using a texture more like this:

hex_edges9.jpg

Dropping that into place, it looks a lot more interesting.

hex_edges10.jpg

Except. There’s a problem here. Not all of the grass is pointed in the right direction. I know it’s hard for you to see in these images. Here, let me illustrate the problem for you:

hex_edges11.jpg

I took out most of the textures and replaced the grass with a downward facing arrow. If the program was working correctly, then all of these arrows would be pointing out to sea. Or at least, roughly in the direction of downhill. I’ve added some code to look at each grid point, then examine its neighbors (the three points which connect to it on the hex grid) and then compare them to figure out the lowest neighbor. The direction to that lowest neighbor is “downhill”. This code is not perfect, and it’s possible for it to become confused in certain situations. In particular, I know I can’t count on it to come up with the right answer when dealing with saddle-shaped depressions, or when looking at a single point that juts up over its neighbors. But wrong-way arrows should be an occasional aberration, and here we’re seeing almost half of them are way off and pointing directly uphill. This should not happen.

Now, the grass actually looks okay. The problem is so slight that I doubt most people would notice. But this is troubling because it means I have a bug in my code. It’s probably the code I use to examine the grid and determine which points are related to which other points. While it’s harmless now, this same code will end up being used later on, and if it’s malfunctioning then it will cause problems that look like they’re caused by something else. I’m actually lucky to have spotted it now. If this manifested itself later when I added (say) line-of-sight checking, then I would likely blame the LOS code I had just written and end up on a wild goose chase.

So.. let’s fix this bug. Should be easy. Let’s just cover the map in arrows so we can spot which points are misbehaving.

hex_edges13.jpg

Ugh. This is no good. Too hard to spot “bad” points with the surface this complex. Let’s simplify things. I’ll turn the entire world into a big slope and get rid of the coloring.

I've highlighted some of the obviously incorrect arrows.  The slope points down to the lower-right, and these ones aren't pointing that way.
I've highlighted some of the obviously incorrect arrows. The slope points down to the lower-right, and these ones aren't pointing that way.

After a lot of time-consuming experimentation and scrutiny, I’m still not finding the problem. Hm. Using a simple slope as my test case is probably a bad idea. It will only catch wrong arrows going in one direction. Let’s make the terrain a spike and look at it then.

hex_edges14.jpg

(HOURS LATER.)

Wow. This a toughie. I think I need to table this and come back to it later. I’m betting the problem is simple, but I’m not seeing it in the code. Sometimes it’s like proofreading: You read what you think you wrote, not what you really wrote. Coming back to it later will let me see the code fresh again.

2020201474 comments? This post wasn't even all that interesting.


  1. Nyax says:

    You might want to rethink making your dropshadow black. I looked through that tutorial you’ve been following and they do point out that no shadow is truelly black. A dark dark purple might work better. I cut out the specific section for your convenience.

    “Now I’ll explain the weird blues and purples…This goes into color theory, which says that shadows are NEVER black. They always have some blue in them…always. When you use black, it makes things look “flat” and uninteresting…When you use a black that has a bit of color in it, you bring it forward, make it feel closer to the “camera”. This is why if you look at the darkest parts of the tree, you can see they’re not black…They’re just very dark shades of green. And going with the blue shadow rule, this is why half the tree is shaded in blues and purples. It’s the shaded area. Now you don’t actually have to use blue in all your shadows, but you should keep that in mind…Don’t use thick black shadows ”

    Then again maybe you thought of all that and it didn’t work or something. Just trying to be helpful! I look forward to seeing the finished product and good luck finding that bug!

    • Tesh says:

      Seconded. Shadows work best with a little color, usually blues or browns. It’s not a big deal, but as it could be a relatively simple tweak it might be worth investigating.

    • StranaMente says:

      I agree too. Shadows are never black. And I add, from the previous post, Earth still doesn’t look so good, as you put near yellow ocre to brown/purple, because they are complementary.

    • glassdirigible says:

      The drop shadow isn’t actually black. It’s black with transparency, which means it’s just a darker version of whatever it’s on. If I recall correctly that’s actually what it says to do in the tutorial.

      The guy in the tutorial is doing it by hand so transparency (if it’s even feasible in his software, this looks relatively old) is not really any less time consuming than drawing darker pixels.

  2. Daemian Lucifer says:

    I know that its just my weird mind,but when I read the first sentence I thought of:

    “And on day 4 Shamus has created the texture for his world,and saw that it was good.”

    Am I the only one?

  3. PTC says:

    Just wanted to say that I find this type of game-building stuff absolutely fantastic. Please keep them coming! And I look forward to the solution to your arrow pointing problem too. It looks downright random to me, which makes me think that it’s something that only happens very rarely in the code. Like a +/- sign inverted in a check that only happens when a>b but b<c type of thing. Regardless, best of luck!

    -PTC

  4. Klay F. says:

    Am I the only one who thinks this?

    The grass looks like its “floating” over the sand because of the drop shadow. That doesn’t look very good at all IMO.

    • Tesh says:

      It might benefit from tightening the shadow a bit (so it’s narrower and less visually “elevated”), but even as is it’s a lot better than shadowless.

    • Zukhramm says:

      Maybe a dark green color rather than the transparent black (making the shadow dark sand colored) would be better?

    • Abnaxis says:

      I will third this criticism. I think if the shadow were both darker and tighter it would look much better. I think you need to make the shadow splat, by hand, and just have it one or two pixels beyond the edge of the grass splat.

      I also don’t know if transparent black is the way to go, either. In the quoted tutorial, you will note that the color used for the grass shadows is used for accenting in the dirt itself, as well. For this application to merge right, I think you need to use a color for the shadows thats in the same palette as the colors used in the sand texture. Maybe add a darker color used sparingly in the sand shadows, and for the outlines in the grass?

      • Felblood says:

        The transparency of the black will automatically turn it into a darker shade of what’s below. It might need to be a tad paler, so it doesn’t fight the lighting, when it appears.

        Also, we don’t need to re-use colors, as Shamus isn’t limited to an 8-bit color palette.

        However, tightening up the shadows, to make them closer and more subtle would really help things.

        • Abnaxis says:

          This isn’t about whether we have to use an 8-bit color palette. This is about making it look right. If you use a color for shadows that doesn’t actually appear in the sand itself, it separates the grass from the sand too much, and you wind up with the funky floating thing you’ve got going here.

          Its not all that much work to just pick a color and use that instead of trying to be fancy with transparency. I think this is one of those cases where you come up with a “better” shortcut to manually doing it and wind up with something funky, that doesn’t even save that much time…

          • Sumanai - a grouchy ball of bile and cynicism says:

            I’d say that first “tighten” the shadow (only one, in the extremes at most two, pixels wide) and then look if it needs readjustment.

            • Sumanai - a grouchy ball of bile and cynicism says:

              If the shadows need readjustment as a whole, not the width of it.

              Edit: Also I feel the need to note that when you create a shadow using pure black with alpha, it ends up feeling wrong. Sort of too pure. It would be better in this case to use a very dark brown, possibly with a slight green tinge.

  5. Jericho says:

    Probably something like instead of looking at the value of the height, it’s looking at the value of the index of the height, or the value of the pointer to the height.

  6. Fizban says:

    I seem to remember you saying that you randomized the direction of the texture splats so they wouldn’t make obvious patterns.

  7. X2-Eliah says:

    I’d say that the drop shadow distance is still way too large. Can you do a gradial shadow that is dark at centre and light at edges itself?

    For the arrows – didn’t your game logic count the hex grid as a faux hex-grid? I’m willing to bet that the distortion to shape hexes is messing with the arrow directions.

  8. Jon Ericson says:

    And like proofreading, someone else will probably see it as soon as they understand the code in question. Even talking someone else through the problem helps sometimes (though not, apparently, this time). Good luck!

    By the way, this series has inspired me to pick up an idea I’d abandoned for a while. Thank you.

  9. Narida says:

    If you posted the code you’d probably have a bugfix in 30min :P
    Unless someone can figure out what’s wrong with only the screenshots. :D

  10. 4th_Dimension says:

    To me this feels like the problem is in that computer sees “hexes” in one way, and you render them in another. In times like that, I like to get out the pen and paper, and dig deep. Check most trivial matter, and do everything by hand.

  11. ngthagg says:

    Looking at the screenshots, specifically the second last one, the hexes are quite clearly not co-planar. Or maybe they aren’t actually hexes, I can’t tell for sure. But they may give you a place to look. The code to find the downslope may be working correctly, but it will look wrong if the downslopes aren’t where they should be.

    • X2-Eliah says:

      This is a valid point, by the way – I also noticed that on several pictures of “clean slopes”, the hexes are, in fact, not hexagonal themselves – thus distortion happens even where it oughtn’t.

    • Caffiene says:

      Agreed. Something is obviously not right, there…

      Although its hard to tell whether they are coplanar or not in a 2d image. It could be that the hexes arent regular, or they could even be both irregular and non-coplanar.

      For anyone following along at home: see eg http://img241.imageshack.us/img241/7673/badhexes.jpg

    • Zak McKracken says:

      You cannot make a hexagonally subdivided surface that is not flat if all hexagons must be planar.

      If you stick three hexes together at one corner, and each of them is flat, then the three must lie within the same plane and so on. So the code must allow for some amount of distortion. The question is how this is handled …

  12. Nurgh says:

    Once you find your bug, you might get a more reliable pointing by changing the algorithm to compute the height of the middle of the neighboring hexes and find the direction from those heights. It’ll incorporate more data and be less likely to be thrown off by individual points.

  13. Pickly says:

    Aside from the downward arrow bug, I am curious what sort of game this could be where a gameplay water tile appearing to be sand might not be an issue.

    I do know that dominions 3 seemed to have this issue sometimes, where the province connections, and land vs. water, sometimes didn’t match with map appearance, although the movement mechanics in that game did seem to help the issue somewhat.

  14. Mark says:

    Shamus,

    In the screenshot of the sloped terrain with highlighted arrows, you can really see some artifacts of using an underlying square grid. Maybe the mechanism you use to shift certain rows of vertices to create your hex grid is affecting your gradient calculation. Are you shifting them along the slope of the terrain or all in a fixed direction?

    Also, instead of using just the three 3 bordering vertices to calculate the gradient, I recommend you add 3 more: the centers of the bordering hexes.

    I still think you ought to reconsider “equilateral” triangles as your primitive.

    Edit: One more thought: gradients would allow rivers.

    • LintMan says:

      Yes. In the spike example, it looks to me almost as if you were to flatten the “houses” back into squares, the arrows might actually be correct. If you easily can disable the “house” effect, this might be worth trying. Or even just testing your arrow directionality on a straight grid.

      • Sumanai - a grouchy ball of bile and cynicism says:

        It seems that the height is checked while the grid is still square, leaving the house/hex grid as a purely visual effect. So apparently the code doesn’t take the line shift into consideration at all.

        Edit: I meant the grid point shift. It seems to completely ignore both the hex and house grids and think it’s a square gird, with shifted lines like in Bookworm.

  15. Isy says:

    I have to say the terrain spike is pretty neat and would make for an interesting different sort of game.

  16. anaphysik says:

    Shamus, I think a big reason why the larger splats look better is because we simply expect to see more sand and shallow water in our terrains than the code generates. I would change your definitions for beach and shallow water such that more tiles are covered by the definition (frex, tiles at sea level next to land are ‘shallow water’, tiles at sea level next to ‘shallow water’ that aren’t ‘shallow water’ are ‘also shallow water’, with ‘shallow water’ and ‘also shallow water’ being displayed with the same splat)

    • Decius says:

      Or generate depth information initially. Even if you throw it out later, calling height of less than 64 “deep water”, height from 64 to 128 “shallow water”, and ground from height 128 to 192 that is contigous with water “beach” might give you some more interesting terrain.

      Edit: If you ever want to be able to modify terrain features in-game, you need to consider how this texture will be recreated. If the terrain type on a specific hexis important to the player, you need to make sure that information is clearly available.

  17. Jabor says:

    Looking at the last screenshot (which is really useful, showing the raw houses instead of the hexes is a good idea), we see the problem evident again.

    Looking at the fourth horizontal line from the bottom, on the right-hand side there are arrows pointing right (downslope), then halfway they correct transition to left (again downslope), and then way on the left side of the screen they change to up (which they shouldn’t). Perhaps comparing the calculations for the points where it changes from left to up might reveal something?

  18. mike says:

    I have a little constructive criticism (I hate to do this at such an early stage of development, but I somehow feel compelled. It must be the internet)!
    1. Try not to mix pixel sizes – if a texture looks better bigger, then the “smaller” version probably just needs bigger “blocks” of color and smoother transitions.
    This also relates to your shadow. Instead of scaling the texture, draw a new texture that outlines your original in dark gray or something.

    2. Try using a darker pixel at the outline/edge of your overhanging grass it could help sell the shadow effect.

    [edit] 3. Almost forgot this one; Try moving your color hue into a more “dirty” or pastel color. Your green shouldn’t be just rgb(0,200,0) or something. Throw in some red, and maybe a slight bit of blue if you like. Something like rgb(116,160,0) might come up nice. Same goes for the brown of the dirt ;-)
    Your blues are great. How about an “extra deep” tile for some variety in the ocean scenes?

    Hope this is helpful, I respect your work Shamus! Keep it up.
    Also, feel free to disregard everything I’ve said – it’s your game ;-)

    • Sumanai - a grouchy ball of bile and cynicism says:

      Oh, since we’re talking about the grass texture:

      Make the dark lines shorter, I’d say maximum of 3 pixels long, most at 2 pixels. Possibly just have one pixle spots instead of lines. Or make it lighter green. Maybe add a fourth color, which will replace it as the darkest, and use it only in one pixel spots.

      Change the background color to the second lightest, as opposed to the current which is the lightest. It doesn’t even matter if the whole scale changes, it just feels wrong to have the “highlight” color as the background.

  19. Oh man. I feel you. Been there many times. “What is going on? Everything is correct!” The worst is when you finally find the mistake and it isn’t even a forehead slap; it’s just some stupid sign error or a misplaced variable name.

    I usually get into situations like this by comparing the wrong things in the right way. It’s like trying to make a peanut butter sandwich with ham. You end up with a ham-jelly sandwich, and you’re continually wondering why the ham won’t spread properly.

  20. Decius says:

    The most significant thing I see in the arrows is that the ‘down’ arrows (pointing towards the camera) (on the ‘gutters’ of the house) change to northeast arrows due south of the peak. Assuming a cone, this is the line where ‘southeast’ would ovetake ‘southwest’ as lowest point. Those same arrows in the ‘flat scape’ pattern point northwest when they sould point southeast.

    Try priting the (x,y) locations of the points on them.

    • Decius says:

      Grr.. edit not working.

      “Try printing the (x,y,z) locations of the points on them.

      • Bryan says:

        Exactly.

        All the points on the horizontal lines are correct (or at least, the ones I can see in the spike screenshot). Following one of these lines from west to east (assuming we’re looking north into this screenshot), the arrows all go from pointing west, to pointing east, and the transition point is the middle of southern slope (where the path is highest).

        But the points on some of the various roof peaks look wrong. In particular, the points on the southernmost roof peaks (the peaks of the houses-pointing-down), on the east side of the southern slope, are all wrong. They should be pointing directly south, not northeast.

        But it looks like it’s *only* that quadrant, and *only* those points. The peaks of the houses-pointing-north all look correct (as you go from west to east, they go from pointing southwest, to pointing southeast, and the transition point is the highest point on that path).

        Not sure if this helps narrow down the problem, though; it’s just the only set of wrong points that I can see. There is at least a nice pattern in this particular shot; that helps a lot.

        • Decius says:

          I bet in the quadrants of the spike that we can’t see, the problem locations change. I think that six ‘straight’ lines ‘evenly’ spaced from the center peak would divide all of the houses into groups with all the arrows pointing the same way.

          Looking at the flat map, which is supposed to have constant slope, I see bumps where there should not be. Most obvious are the very top of the map, where I expect to see a very regular shape and do not, and in the lower right of what would be (3,-4) in cartesean if the origin was the top left corner.

          One possible solution (to this current issue) would be to select the texture according to which adjoining hexes were beach. There are only 2^6 possible arrangements of grass and beach, 3^6 for grass, beach and cliff, and 4^6 if you add another terrain. Many of those will be rotations of each other.

          4 terrain types, 4^6 possible types of surronding terrain, 16384 possible combinations, divided by an ungodly number of rotational identities and actual impossible terrain (mountain next to water).

          And on the second picture, second row up, middle of the screen, there is a shallow water hex where the closest land is the center of the hex to the left. Further up, above the pennisula, there is a deep water in a hex with land on a vertex of that hex. That says that the adjacency rules themselves are either misapplied (by the program) or misunderstood (by me).

  21. Glen says:

    I’d love to hear more about some of the math you use to solve these problems.

  22. porschecm2 says:

    Shamus, what is the scale of each hex? Because I’m totally confused. At first I was thinking it was some enormous scale, like most turn based strategy games, where each hex is somewhere between hundreds of feet and several miles. But, now you’re talking about putting grass, with shadows, on the hexes, and what looks to be individual grass blades. Is this an intentional juxtaposition of scale (like the units in the Civ games) or are you just working at a much smaller scale than I previously understood?

    • Kacky Snorgle says:

      My thoughts exactly. Many of the issues people are bringing up can be reduced to a question of scale….

      For example, several people said the grass shadows should be smaller. That’s true if the hexes are meant to look large; but if the hexes are a foot across instead of a mile, then the current shadow size looks about right.

      On the other hand, it was pointed out above that there ought to be more tiers of beach and shallow-ocean hexes along the shoreline. That’s true if the hexes are *small*, but the current setup is fine if they’re *large*.

      In other words, the current terrain looks a bit odd because we’re getting conflicting information about the scale. The width of the beach, and the sharpness of the sand/water edge, makes it appear that we’re zoomed far out (each hex is at least hundreds of feet across). But the shadows and the blades of grass make it appear that we’re zoomed pretty far in (each hex is a couple feet across at most). If the world is to look realistic, one of these things needs to give–Shamus needs to pick a scale and design all the topography and textures to appear compatible with that scale.

      Or, perhaps Shamus is simply envisioning an alien landscape of 100-foot blades of grass. That could be cool too…. :)

  23. SatansBestBuddy says:

    I love how, on the last picture, the arrow on the very top is pointing up.

    I mean, I know that’s bad and means that you really do have a bug that doesn’t calculate properly, but it’s still funny.

    That and the two arrows to the left pointing at each other are what tell me that I’m of no help here, as I’d just suggest something crazy, like rethinking how you draw your hex’s when you’ve already come up with a working solution for that.

    • rofltehcat says:

      You’re right… it is really pointing up. Thid is really strange… maybe it is a problem at this spot because it looks like those 2 lower corners might have the height values. Maybe the program tries to calculate a mid solution arrow and turns it the wrong way around by missing a minus or something?

      Good luck, Shamus.

  24. unitled says:

    I’m only an Mechanical Engineer so my coding knowledge is relatively limited, but someone once told me something that has stuck with me for years: “The code that is hardest to debug is the code you know can’t possibly be wrong.”

  25. potemkin.hr says:

    Darn shamus, someone stole your idea and released is as Minecraft before you :P

  26. DaveMc says:

    I’m really enjoying this series — thanks, Shamus! These series are some of my favourite stuff on this site.

    Is the “amusingly annotated coding” genre unique to Shamus, or do other people do similar things?

  27. Kevin C says:

    I suspect that the incorrect arrows may be based off the fact that you are doing freaky math with boxes to make the hexes. If that squishing/manipulation is carried through, there may be spots where an intermittent (and unused) point is undefined (in elevation) and therefore ends up lower, resulting in the grass pointing that way even through the 3 vertex around it indicate otherwise.

    An example of what I mean…and this will be simplified. Say you have a grid as such:
    .–.–.
    |—–|
    .–.–.
    |—–|
    .–.–.

    Now, if things require the center dot to be removed from the view _but it still exists_ in the “world”, then it’s value (being unassigned) would end up being (depending on your code) the lowest value possible, and therefore being “downhill”.

    Conversely, if those unused points have no elevation assigned to them (uninitialized values? Shame on you!), then they could have a random value which gives them and equally possible chance of being “above” or “below” the other vertexes around it…which would equate to a random amount of “correctly facing” downhills.

    Make sense?

    In re-reviewing the last image, the only ones that I can find wrong are all in the same relative location. They are on the right hand side of the “high” point, at the same vertex…see if I can draw it….it’ll be the @ symbol:

    ..|..|..
    ./@/@/
    .||.||.|

    Put that in notepad. The “@” is at the point at the top of the | (I tried to use a backslash in there, but the software doesn’t like it). That seems to be the only place that it’s wrong, but it’s on all of them.

    Given the recurring nature of the error, it should be easier to find.

    • Sumanai - a grouchy ball of bile and cynicism says:

      Let me try something:

      .–.–.
      |—–|
      .–.–.
      |—–|
      .–.–.

      And,


      ..|..|..
      ./@/@/
      .||.||.|

      Nope, I still don’t get what you’re trying form with those. Using the [code]-tag makes 'em fixed width, so no-one has to paste into a text editor. (Use less-than and greater-than signs instead of '[' and ']')

      Also the comment software automatically removes extra spaces. And man, are you right about the backslash.

      • Kevin C. says:

        Consider the @ symbols as backslashes, then compare it to the last image in the post and you may see what I was trying to do…and where the wrong arrows recur.

  28. scob says:

    Poor Shamus takes a few hours off to sleep and gets slammed with advice.

    Shamus, I came to your site when you were doing the city coding project, stuck around for various reasons, and now I’m really digging this project – thanks for sharing your thoughts and process with us.

    I’ve been looking over the pictures, and I think it’s going to turn out to be related to the grid-hex conversion… concepts like “downhill” might not map directly across. But however it goes, I’m looking forward to seeing how you proceed from here.

  29. Zak McKracken says:

    About the problem with the water hex looking like sand:
    You are placing textures in the hex centers _plus_ on the hex nodes. Now if all nodes have one elevation and the center has another, it will be barely visible (look at the sand bit on the northern side of the peninsula, 3/4 surrounded by grass). I think that the easiest way to deal with that is to use textures in the hex centers (and make them a bit bigger). That might a bit more discretized, though. Or you give textures in hex center precedence over border textures.

    About the arrows:
    I’d try this to determine the steepest descent, ignoring the point itself, use only the adjacent six points:
    There are three ways you can cut the hex in half, with three points on each side. Compute the height difference between for each grouping, and when you’ve found the maximum, the downwards direction is normal to the divider (i.e. towards the middle point on the lower side). That’s a little more computation than comparing six values, but since the whole surface can be noisy, that’s probably more reliable. And it only needs to be done once.

    The alternative method is to compute the center normal for both triangles that can be built out of the neighbouring points, add them and project the result on the ground plane (i.e. ignore the z coordinate). But that could point in an arbitrary direction. You might not like that. On the other hand it gives you even less regular results. It might also not alway be reliable, depending on how noisy your elevation data is.

  30. Zack says:

    As many others have said. The slope bugs really does looks like they are confined to “altered” grid from converting square to hex. I suspect that the trick you used is starting to bite you now. Several suggestions given above are quite good and hopefully will help you crack this case.

    And let me also say that I really do love these posts and the discussion that follow. As a developer seeing the programming you have going into the art of the game is fascinating.

  31. Franco says:

    I’m not a programmer or game designer at all and I still have to say that I love love love these programming posts. This, the Procedural City, A.I. Follies, they’ve got to be some of my favorite entries. You’ve got a knack for explaining this stuff in clear and entertaining ways. Ever think about writing a book?
    Er..a non-fiction book, that is.

  32. scob says:

    Trying to learn more about hex methods,
    i found a great here that has links to various papers about hex-grid systems. So far everything I’ve read is pretty different from what you are doing, so some of it might be of no help unless it does turn out to be the hex representation that is biting you and you end up needing to perform major conceptual overhauls on that bit of code.

    Looking at the second picture here, it seems like you could directly map the centers of the hexagons into a skewed grid with simple coordinates; perhaps deriving values for the corners by interpolating between hexes in each of the (3) directions.

    Just a thought.

  33. Zack says:

    The links Scob includes are fantastic reading. I also liked some of the links discussing different implications for pathfinding and distance calculations later on. (you might want to make a few subtle change to your coordinate system to avoid some nasty path finding bugs later on.)

  34. Cuthalion says:

    EDIT: Looks like Jabor @17 noticed this, too… and some others… a couple days ago. :P

    I notice that in the spike pic:

    The arrows pointing to the upper-right when they should be pointing downwards only occur on the right side of the seam in the spike. The left half of the spike doesn’t seem to have this problem. Possibly an issue with positive and negative numbers or maybe even numbers wrapping around after the area reaches a certain width? (E.g. 254 -> 255 -> 0 -> 1)

    • tussock says:

      Should just be in the height comparison. He’ll have an early return when (B < A) without checking (C < B), like a fall-through case that doesn't.

      Maybe accidently returning the greater of B and C when B < A, and the lesser of A and C otherwise. Either way it's right 2/3 of the time, and wrong as in the pictures.

Leave a Reply

Comments are moderated and may not be posted immediately. Required fields are marked *

*
*

Thanks for joining the discussion. Be nice, don't post angry, and enjoy yourself. This is supposed to be fun.

You can enclose spoilers in <strike> tags like so:
<strike>Darth Vader is Luke's father!</strike>

You can make things italics like this:
Can you imagine having Darth Vader as your <i>father</i>?

You can make things bold like this:
I'm <b>very</b> glad Darth Vader isn't my father.

You can make links like this:
I'm reading about <a href="http://en.wikipedia.org/wiki/Darth_Vader">Darth Vader</a> on Wikipedia!