1
\$\begingroup\$

So, I can happily render an infinite square grid by moving said grid whenever the camera moves out of a grid square,

auto diff = (cameraTranslation - gridTranslation); bool moveGrid = false; if (diff.x > cellSize.x / 2) { gridTranslation.x += cellSize.x; moveGrid = true; } else if (diff.x < -cellSize.x / 2) { gridTranslation.x -= cellSize.x; moveGrid = true; } if (diff.z > cellSize.z / 2) { gridTranslation.z += cellSize.z; moveGrid = true; } else if (diff.z < -cellSize.z / 2) { gridTranslation.z -= cellSize.z; moveGrid = true; } if (moveGrid) gridTransform.Translate(gridTranslation);

However, when working with a hexagonal grid, things get a bit more complicated. (For that matter, if the grid was textured, I'd have to adjust the grid translation based on the tessellation distance... ouch.)

In this case, I'm dealing with a wireframe hex grid:

enter image description here

And I'm a little unsure how to treadmill in this case.

The first thing that comes to mind is that, given that the camera starts in the center of a hexagon, determine if the camera has exited the cell in which it started. If so, adjust grid position by

float angle_from_center = atan2(camera.z-grid.z,camera.x-grid.x); grid.x += cell_size.x * cos(angle_from_center); grid.z += cell_size.z * sin(angle_from_center);

Which will probably work, but the issue gets more complicated when considering that I'm not only checking if the camera has moved a certain distance from the cell center, but if it has crossed a border.

I could clamp the angle of the camera relative to the cell origin to 1/12 of a circle, which would make hex boundary calculation easier, but this seems like a hack.

Any suggestions? I'm 75% sure I'm over thinking this one.

\$\endgroup\$
3
  • \$\begingroup\$ Why can't you move the grid less often? Since you only translate along the xz plane you can pick a tile delta that is a multiple of the distance between two hex cell centers (of which both cells project onto each other along a given cardinal axis). Does this make sense? \$\endgroup\$ Commented Feb 9, 2014 at 5:13
  • \$\begingroup\$ I would also suggest using a s bigger pattern that is in the form a square or at least rectangle. This will make your code much more simple. \$\endgroup\$ Commented Feb 9, 2014 at 15:15
  • \$\begingroup\$ @Arne Hmmm... so if I can generate a rectangle containing the hex pattern, and tessellate that (via texturing or instancing), I should get the desired effect. Time to whip out the pencil and paper. \$\endgroup\$ Commented Feb 9, 2014 at 18:30

1 Answer 1

Reset to default
5
\$\begingroup\$

Thanks to everyone for the advice.

I spent a few minutes with a notebook and found a suitable tessellation cell for a hex grid:

enter image description here

or, in context:

enter image description here

Note: It doesn't really matter if this is centered on a cell - if your grid is composed of regular hexagons, you can slice it into cells this size starting anywhere you want. Hooray for tessellations. My example below adjusts the grid every time the camera leaves a single cell, but as long as your using an integer multiple of the cell size, it should work fine.

The cell dimensions are:

 width = 2 * radius * sqrt(3) height = 3 * radius

If there's anything special - textures, etc. - on your grid, you'll want to track how far the grid has moved and offset your texture coordinates accordingly.

\$\endgroup\$

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.