Automapping: Output objects don't contribute to output region

[eishiya]

When determining what parts of a rule to output, Automapping only seems to look at tiles, and if objects are present, they are only output if they overlap an output tile as well. This is unintuitive and feels like a bug.

For example, these two rules that look for "NonEmpty" on the input layer and have just an object output layer will output nothing:

My input, unmodified by this rule:

But this is what I expect:

And this rule that outputs a tile in a location other than the object's location will output the tile, but not the object:

However, this rule, which outputs both an object and a tile at the same location, will work correctly:

If I want to make a rule that outputs only an object at some location, I have to have a tile output layer with a tile on it that will be ignored:

I think any tile touched by an output object should count as part of the output region. For example, this small object would add the selected tile to the output region:

Care would need to be taken with non-rectangular objects. For example, these are the total regions I expect these two rules to have:

But if the bounding box of the object is used instead of checking whether a tile actually overlaps the object, then the regions would be like this, and considered a single rule:

Alternatively, if it's intended that objects don't contribute to the output region (e.g. to avoid specifically this kind of weirdness with the shapes), then the fact that they don't contribute and may need output Tile Layers with Ignore tiles to output should be documented (I can add it to my rewrite draft).

[bjorn]

Care would need to be taken with non-rectangular objects. For example, these are the total regions I expect these two rules to have:

The linked PR fixes the general issue, but does not make AutoMapping work correctly for polygon or polyline objects. I believe since it works only with the object's rectangle, it will handle these as if they were point objects.

When I would fix it, I'd likely use the bounding box, even if it may cause unintentional merging of rules in some cases. I just think that any more complicated handling of that case is not worth the effort given how rare it must be in practice. Eventually, it would be good to add a rule regions visualization, which would help spot such cases when they do happen.

[eishiya]

The PR fixes the issue as described, but misses the same thing for DeleteTiles: that still only deletes those Objects that overlap a tile in the match region. This rule's output objects will never be deleted:

But this one's objects will be deleted:

Perhaps this is fine, I don't know as I haven't done practical Automapping with Objects. On one hand, I expect DeleteTiles to prevent stacking outputs like this, but on the other, I wouldn't want it to delete Objects that I placed manually that happen to be near the output area.

I checked the behaviour for Polygons, and it indeed looks like their bounds are handled like Points. If their position is exactly at the edge of the cell (e.g. because of Snapping), they're not considered part of the region, their origin point has to be within the cell. Using the bounding box would indeed be a big improvement over this, and I guess it's fair enough to use that rather than doing something more complex, given how rare this scenario is.

[bjorn]

@eishiya I haven't tested it yet, but isn't this behavior consistent with tile layers? As far as I know, DeleteTiles has always only worked for regions where any of the input layers have any tiles. This is to have it only delete tiles in regions which can be expected to be "refreshed" by Automapping rules.

[eishiya]

DeleteTiles is the only way to delete Objects from a map via AutoMapping, so preventing the stacking of Objects due to repeated Automapping is one of the uses I expected of it. I could be wrong, as I never found DeleteTiles intuitive even for just tile work xP

[bjorn]

@eishiya I'm open to explore better options for deletion, but I've closed this issue since I think that one has been fixed now. Thanks for testing and the additional feedback! :-)