Godot 4 Issues and Proposals
This plugin addresses the following issues and proposals from the main engine.
Godot 4's terrain algorithm can't fully update the neighboring tiles, and this causes problems in this issue when attempting to erase a single tile. Terrain Autotiler does fully update its neighbors.
Godot 4 does not choose peering bits between different terrains deterministically. They differ based on draw order, which tiles are available for update, and the terrain order in the TileSet. As seen with issue #70218 below, Terrain Autotiler also makes choices based on the terrain order in the TileSet. But in a case like this, it always prefers a solution that does not introduce a third terrain.
Issue #70218: Terrain set gives unexpected results, algorithm creates bit masks impossible to express in 3x3 minimal
This issue shows the editor choosing non-matching tiles when it has too many tiles to choose from. The MRP has many terrains, and full 47-tile sets for transitions back and forth between them. This means, for the water and beach tiles here, that there are 47 tiles of water on beach and 47 tiles of beach on water. Water is listed first.
Terrain Autotiler's result has matching tiles, but it also made some big changes.
The original square of sand and line of water were drawn with the editor's tools. Terrain Autotiler chooses peering bits in a deterministic way to achieve the same results regardless of draw order or whether you are painting single terrain or updating a whole layer. It ended up updating its whole layer with its chosen peering bits (which is why it was on a separate layer).
In this case, water and beach both have a full set of their own and each other's peering bits, which means that water or beach peering bits are equally good choices. When deciding between equally good choices, Terrain Autotiler chooses the peering bit terrain with the lowest index (first in the list). It also extends current terrains out to match to empty squares (unless the terrains have empty bits set). So in this example, it also updated the neighboring beach tiles so they would match to empty according to its algorithm.
Here is the terrains list before:
Here is the terrains list after swapping beach and water:
(Note: Changing terrain order erases the center bits, and can cause the editor to crash -- both of which occurred here when I did this. Back up first.)
With this new order, the results are actually different in both the editor and in Terrain Autotiler. This can be demonstrated by re-drawing the original rectangles and lines.
Despite the differences in peering bit selection, the editor still chooses some non-matching tiles, and Terrain Autotiler still chooses matching ones.
Issue #73903: TileMap terrain system gives different results depending the order you place the tiles
This issues involves a Corners and Sides TileSet that is missing one tile. Godot sometimes draws it correctly in the end, sometimes doesn't, and when it doesn't the results are inconsistent. It also choose non-matching tiles as as you draw, even though there are always correct tiles available.
Terrain Autotiler is not optimized for this situation either, but it is consistently able to solve it via backtracking. I say that with some confidence -- I turned this into a GUT test and, as of v0.2.0, it can solve >30k different draw orders without choosing non-matching tiles at any step.
That being said, Terrain Autotiler is better optimized for working with full sets. So, if you are a situation with one missing tile, you will get faster results if you just give it a full set.
Issue #71829: Tilemap tools in terrain mode 'connect mode' and 'path mode' not behaving as described or in a predictable way.
This issue requests a return of 256-tile corners and sides matching to draw diagonals. There is an open PR Add a new terrain painting mode in TileMap to force diagonal connection #72030 to turn this matching into a new draw mode. As of 6/2023, I was unable to get it working correctly in the editor.
Terrain Autotiler includes 256-tile corners and sides mode as a sub-mode of Corners and Sides.
This was a proposal that addressed limitations of Godot 4's terrain system as of Oct 2022. Some aspects were merged into the main engine (like center bits). The author of the proposal (portponky) went on to create Better Terrain to address the other points.
Terrain Autotiler is not an overhaul of the underlying terrains system, just the tile placement algorithm, so there are points in the proposal it does not address.
However, it is able to correctly place the bridge tiles as described in this comment.
This was an interesting challenge to the algorithm. In order to work consistently, it requires:
- Being able to change tiles of neighboring cells completely freely. This means that the neighbor's neighbors 2 cells away from the painted tile must also be able to change their tiles.
- That the algorithm chooses water peering bits over empty peering bits for the road tile -- even though choosing empty peering bits is far more likely to result in a successful match in most cases. (There are only 2 road tiles with water peering bits but there is a full set of road tiles with empty peering bits.) This means the algorithm has to infer when the user wants peering bits with an incomplete set of tiles to be placed -- and also when they don't, since doing it routinely would cause slowdowns or non-matching tiles.
Proposal #4689: Allow multiple terrain types as a tile's peering bits
Proposal #4896: Add "Any Terrain", "Ignore", and "Other" as options for terrain tile interactions
Discussion #6157: TileSet Terrain slope and multiple terrains per tile
These were features in Godot 3 that did not make it into Godot 4. This plugin brings back ignore bits by defining an ignore terrain and the ability to join multiple terrains by setting custom primary peering terrains.