godot
godot copied to clipboard
godotengine
Godot 4.0 Terrain tiles not updating
Godot version
4.0.alpha14
System information
MacOS 12.5, 2.3 GHz Dual-Core Intel Core i5
Issue description
The terrain tile placement in Godot 4 is often bugged, and will end up with tiles I didn't place, or tiles not updating after placing new ones
https://user-images.githubusercontent.com/32573897/185769867-32bde2b3-d81d-4d19-bd63-c7f122f60c82.mov
.
Steps to reproduce
- Create a minimal tileset setup with terrain.
- Draw an odd shape.
- About 30% of the time it will be broken.
Minimal reproduction project
I think this is more or less a wontfix.
The algorithm is now quite complex, it tries to find a good working solution for each situation, trying to minimize how many terrain bits or transitions gets modified. When your terrain does not have a lot of possible combinations (as yours does), then it may not find a tile to fit in there . It may modify the surrounding tiles, but to avoid testing all possible combinations it limits itself to the first surrounding tiles, and does some sort of a guess to find a solution. We can't really make this more complex however, as it would slow down significantly the painting process.
We may try to change the constraints weights here and there in the algorithm to see if it improves the situation, but I don't think it will be possible to improve the situation that much.
Ok, thanks for saying. Yeah, I guess I haven't tried it with a full tile set, as I usually don't need one. :)
We can't really make this more complex, however, as it would slow down significantly the painting process.
Tiled has a similar issue. To solve this, they offer a button to "hard refresh" the entire tilemap to ensure the rendering is displayed correctly.
I appreciate the complexity of tile painting, and i have looked at the Tilemap source code. Though i'm only a few hours deep into the problem i might be able to help with a solution.
I have developed a dynamic tile painting algorithm in the past for a Carcassonne (board game) simulator written in go. If i remember correctly it would compare tiles based on an internal 3x3 'corners and edges' matrix which is analogous to how terrain painting is done in godot. The algorithm was incredibly lightweight, and could compare hundreds of tiles together in microseconds.
I might take a shot at improving this, as the terrain issue stands directly in the way of progress in my motherload-esque game idea. My actual problem is something in the same vein as this issue. In the editor this tool actually works perfectly, but when i try to replicate the paint and erase tool in gdscript, i have only set_cells_terrain_connect and set_cells_terrain_path as the API to the terrain tooling, and after trying various approaches i cannot get it to function the same as the editor. Maybe someone involved in writing the GDscript API could advise on how it's intended to be used when trying to erase cells?
(using editor - works well)
(one attempt of many to get the GDscript API to work like the editor)
I too struggled with getting the same results with script calls to set_cells_terrain_connect() to work the same as the editor. I had to pass in false for the last optional parameter dealing with empty cells which helped a lot. But still the tiles don't update/repaint 100% of the time.
Im having issues with set_cells_terrain_connect(), especially if im using it to patch the terain after removing some tiles in game. Its quite ruining my project.
Ofc, don't forget to call update_bitmask_region() after changing cells to rebuild autotiles. If you think this might be the issue, try calling with no args and if it does fix it, you can calc more specific area to update for better performance.
Ah, im using godot 4.0, where no such equivalent function seems to exist. I figured out a solution, and it is to use set_cells_terrain_connect(0, [tiles to erase], 0, -1, false) instead of erase_cell(), as i found on this reddit thread https://old.reddit.com/r/godot/comments/11hradq/trying_to_replace_tilemapset_cellv_and/
I've been playing around with procedural generation in Godot4 and have found the terrain system to be somewhat inconsistent when calling set_cells_terrain_connect. I frequently get instances where chunks have generated but the terrain has bugged out and can't quite figure out why.
In those screenshots you can see that the terrain has been generated as the colliders for the edge tiles have been placed yet no actual sprite is drawn for some reason. Whats annoying is that if I move the player far enough away and come back to regenrate the terrain it works fine.
It's possible this could be caused by something in the way I'm generating the terrain but it works fine throughout the project just every now and again a little patch like in the screenshots above doesn't seem to generate properly.
I think my issue is down to using Task.Run in C# to help avoid lag spikes when generating terrain. Will raise a separate issue for this as it seems to be happening quite consistently
@groud has done some work with the tilemaps before. Could you maybe help direct where I should look to fix this? looking to make a hotfix.
(specifically referring to this https://github.com/godotengine/godot/pull/67390)
this issue still persists in 4.0.2 and 4.1 dev branch
Even when there is a correct tile for the autotile, with 2 different sets of terrain, Godot chooses incorrectly.
What's the situation with this? Seems like a big stopper for a procedurally generated games :/
Even when there is a correct tile for the autotile, with 2 different sets of terrain, Godot chooses incorrectly.
@groud correct me if I'm wrong but isn't this the proof that this is a legitimate bug and not a "won'tfix"?
@groud correct me if I'm wrong but isn't this the proof that this is a legitimate bug and not a "won'tfix"?
No. A single picture without an MRP isn't enough to explain it as a bug, and I explained what were the tradeoff of the algorithm implementation with my first comment.
That being said, I am not against a rework of the terrain system as a whole that would fix the original issue, I just don't have the time to work on it. It also requires a solid proposal, that would understand all the tradeoffs each solutions will require.
In the meantime, you can try this plugin: https://github.com/Portponky/better-terrain, it seems it had made several people happy (it has limitations too, but they might not apply to you project)
There are a couple of proposals, but idk if they count as solid: https://github.com/godotengine/godot-proposals/issues/7670 https://github.com/godotengine/godot-proposals/issues/5575
