Right now it's not possible to do simple bitmask autotiling, because there's no option to ignore if there's a surrounding tile or not in the chosen position. This creates the need to repeat an image to cover all possibilities, consuming space and time.
Things like a simple dirt -> grass in a minecraft-like style, water where the top tile is shorter, etc. are more complicated to be done than needed because of this.
i'm not sure what you mean, but you could easily: slice your tiles in half the size using 2x2 mode or add a tool script to the tileset and override the virtual function _forward_subtile_selection
http://docs.godotengine.org/en/3.0/classes/class_tileset.html#class-tileset-forward-subtile-selection
@MarianoGnu
When creating the autotile's bitmask, there's two options: either there is a surrounding tile (red) or there isn't (transparent). There's no possibility to ignore if there's a surrounding tile. If there would be such feature, then there would be no need for a minimal 3x3, or controlling subtile selection manually to achieve such a common scenario.
Sorry, I don't see an use case for this, can you give me an example?
Right now there's the need for a 3x3 and a 3x3 minimal. But the 3x3 isn't really usable, since you need to cover so many cases. If this would be implemented, there would be no need for a 3x3 minimal and the 3x3 would become usable, since you can ignore some cases.
so, 3x3 minimal is too simple and 3x3 is too complex? i'm not buying this U_U as much i'd add a 2x2 custom and 3x3 custom and let the user generate the bitmask himself using an script, the same way _is_tile_bound and _forward_subtile_Selection works, but i'm not sure what do you expect with a mixed frankenstein like that, it's so confusing to me
Okay, you're clearly not understanding, since this is the default for about every autotiling mechanism I've ever seen.

_Example bitmask. There must be tiles on top and bottom, not be tiles on right and left, and it doesn't matter if there's tiles on the corners._
It's pretty simple. On the current bitmask tab on autotiles, you can paint it red or transparent, as to check or not to check for adjacent tiles. It's only natural to have an option to ignore adjacent tiles (which is blue on the example). There is no generating the bitmask yourself whatsoever (where did you take that from?), just clicking on a tab like you do now.
This can be achieved without hassle, adding a shit ton of functionality, uniting 3x3 and 3x3 minimal, simplifying minimal tilesets and so much more.
this is because the bitmask is not generated on the tile and then see if it fits the map, it's done on the inverse, it's generated on the map and then search for a tile that matches it, i really dont see too much of a win on this, but if someone wants to to this, PR welcome
this needs to be supported.
there is actually a unity addon called rule tiles which does this.
I would suggestion the following colors to make it more clear.
green = must have adjacent tile
red = must not have adjacent tile
off = don't care whats adjacent
this would make autotiles much more customizable.
@Shadowblitz16 Yeah. Right now you can't really do 2D platform games using TileMaps because of the lack of this. I don't think I made my point very sellable though, hahaha.
And I can't bother to learn the tilemap logic and alter it, unfortunately. Nobody else seems to care too. Probably never going to be implemented.
what why? this is a major flaw in autotiling
@MarianoGnu please add this. it would be used I guarantee it.
for example this is my tilemap

I can't make the middle piece be picked when there is a tile top,bottom,left,right.
I don't want it to take in account diagonal tiles.
I'm also having a problem with this, autotiling is basically unusable unless you design your tileset FOR the godot autotiling:/
I'm about to implement this. Do you think I should use an extra integer for this bitmask or use the same that is used for regular autotiles.
I think the second option would cause less problems with existing tilemaps. But I'd have to extend it to 32 bits. Additionally it would probably be better to use the 16th bit of the integer as the first of the ignore bits so there's some room for additional flags in between. (Yes I already have something in mind but I need this to work first.)
Edit: I mean in the tileset code. For the implementation I have in mind I would use a bitmask to decide if the original bitmask value is ignored and it akts as a "don't care" bit
Done
Most helpful comment
Done