Hexagon Tileset 2D don't use regular hexagon

[m21-cerutti]

Tested versions

• v4.2.2.stable.official [15073af]

System information

Godot v4.2.2.stable - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Ti (NVIDIA; 32.0.15.5585) - 11th Gen Intel(R) Core(TM) i7-11700KF @ 3.60GHz (16 Threads)

Issue description

Seems all the grid with hexagon are not regular ones mathematically, since the outline touch the border on two faces.
To illustrate, the difference beetween this one (regular)

and this one (not regular)

is subtle, but that means distance on extremity are not the same on the second case (and could lead to wrong AStar ?)

Inside Godot TileSet, we use not regular one :

Steps to reproduce

1. Import a tileset with regular hexagon
2. See difference

Minimal reproduction project (MRP)

Chara_TopDown_Hexagon.zip

[m21-cerutti]

Just for visibility, need to verify it would not impact 3D version (like grid visualisation etc)
#85890

[AThousandShips]

This is something to document as a first step, we can't change the tile shape directly

Adding a regular hexagon tile would be something for a proposal IMO

But are you sure you can't achieve this by just adjusting your tile size?

[m21-cerutti]

Would be great for documentation as first step indeed.

But handling irregular hexagon not means that distance calculation would be biaised ? Since we use tile_size for positions when creating after that AStar or whatever grid pathfinding algorithm we use.
I wrote it as bug since I am really not sure this choice was intended, but need some verifications I can't afford.

Also it's a pain to fix it exactly to the size of the regular one, since we make those tiles with a tile_size in mind (like 64x64 or other size), tweaking it with a 13.6 pixel separation not scale.

[m21-cerutti]

Hello,
After some time I was messing with pathfinding, and with no surprise it have an impact.
When using global position with

func astar_add_walkable_cells():
	var points_array = []
	for point in get_used_cells(0):
		var position_cell = to_global(map_to_local(point))
		...
		astar_node.add_point(point_index, position_cell, tile_data.get_custom_data("Cost"))
	return points_array

And debug it back... (pink global distance, red cost)

We can see cells are not equally distanced. And offset coordinates seems correct

In this video 115 * 1 + 115 * 10 < 128 * 10 so it doesn't takes the shortest path.
https://github.com/godotengine/godot/assets/23432929/7a8d7a45-a2e3-45da-8f93-82c9e8f6399a

I was preparing a public template for hexagon map so feel free to test it on my code
https://gitlab.com/neitherlands/godot-4-hexagon-template-2d

[m21-cerutti]

Have made a demo project, could be used to experiment
godotengine/godot-demo-projects#1085

[idbrii]

AThousandShips is right: You need to adjust the "Tile Size" parameter in your tileset. Since it's set with x,y, that's the Apothem x 2 (width from one flat side to another) and the Long diagonal (distance between opposite corners). You can use this online calculator or count the pixels in your art.

I did the latter with your demo to find 56px x 64 px. You also need to adjust the Margins and Separation to match the art:

See it the grid matches the art:

It has black bits everwhere because Regular_1.png from your test project doesn't have a transparent background.

Also it's a pain to fix it exactly to the size of the regular one, since we make those tiles with a tile_size in mind (like 64x64 or other size), tweaking it with a 13.6 pixel separation not scale.

But the art isn't 64x64. It's 56x64.

I was messing with pathfinding, and with no surprise it have an impact.

I'd guess that you should avoid using global position to compute costs in your astar graph? You want tile traversal cost and not visual distance. Not sure if that means calling add_point() with their tilemap position or just changing the implementation of _compute_cost().

[m21-cerutti]

AThousandShips is right: You need to adjust the "Tile Size" parameter in your tileset. Since it's set with x,y, that's the Apothem x 2 (width from one flat side to another) and the Long diagonal (distance between opposite corners). You can use this online calculator or count the pixels in your art.

I did the latter with your demo to find 56px x 64 px. You also need to adjust the Margins and Separation to match the art:

See it the grid matches the art:

It has black bits everwhere because Regular_1.png from your test project doesn't have a transparent background.

Also it's a pain to fix it exactly to the size of the regular one, since we make those tiles with a tile_size in mind (like 64x64 or other size), tweaking it with a 13.6 pixel separation not scale.

But the art isn't 64x64. It's 56x64.

I was messing with pathfinding, and with no surprise it have an impact.

I'd guess that you should avoid using global position to compute costs in your astar graph? You want tile traversal cost and not visual distance. Not sure if that means calling add_point() with their tilemap position or just changing the implementation of _compute_cost().

Maybe it needs some update since it has been one year since the last update.
But the point is the same, it's not mathematicality correct, it's not pixel perfect with the borders, we can't use global node distance as heuristic for pathfinding, and tile distance can be tricky to implement with those ratio with hexagonal path (from what I remember it would need to override both _compute_cost() and _estimate_cost()).

One other solution could be also to have a setting to switch to one mode or the other but yeah, too much work for some kind of niche case.

But yeah, there is plenty of "good enough" solution for developers that don't bother with it, but maybe it is the workflow the problem ? Margins, separation and tile size parameters are great when you now your art, but with external assets I would expect to split a sprite sheet into a grid with the rows and column numbers, make regular separations, and deform with a scale x,y at last resort if it is not regular.