Adjacent node dependent tiles / Connected textures

[cx384]

Problem

It's not possible to have custom node tiling, when nodes of the same kind are next to each other.

It would also be great to be able to specify different kinds of connections to different kinds of nodes, but I would be very happy to at least have it for one type, like it is the case for connected nodeboxes.

Related:
#2748
#5369
#8334
#11546

All of those should be solvable by this feature.

Solutions

A solution could work similar to connected nodeboxes, but per tile (a node usually has 6 tiles). It should be able to be connected to all sides, including corners, and maybe also nodes above and below.
We already have glasslike_framed, so I guess it is doable without performance problems.
It does not need param2 so no new drawtype is needed, instead it would be part of the tile definition like animation and align_style.

For the API I think it could look like this, or similar:

• Tile definition = {name = "image1.png", connection = {Tile Connection definition}}, where image.png is the base image
• Tile Connection definition = {Tile modifier, Tile modifier, Tile modifier, ...}
• Tile modifier =

{
  condition = {right = {"node:name", "group:name", ...}, not_left = {"node:name", ...}, not_x_plus_1 = {...} ...}
  type = "concat"
  name = "^image2.png"
}

• The used texture would be "image1.png^image2.png".

It's a flexible and easy to use solution, but if this doesn't work performance wise, the condition could use bools per side to only support one kind of connected node.

Note that you can't do it like connected nodeboxes, since the order of overlaid textures matters, and fixed textures would mean that you have to manually specify about 2^6 textures even for a very simple connected glass with corners use case.

Alternatives

• Registering multiple nodes with different textures is unfeasible, even if Add node texture variants #13811 becomes a thing, since you would need to register about 2^10 nodes. (26 adjacent nodes - 8 edges - 8 bit from param2)
• A less flexible API with a hardcoded tilemap for connected nodes.
• A more explicit API where you have to set a fixed texture for every connection case. (define up to 6 * 2^26 textures)

Additional context

This is how it could look like for some MTG things, e.g. the Stone Block texture.

[hlqkj]

I like the proposed condition definition! I think it could also be extended to work with the node meta as well? It would offer even more flexibility to an implementation of texture variants of a node, without consuming param2 bits.

[cx384]

I suppose this wouldn't work performance wise, reading node meta is quite expensive if I'm not wrong.

[Desour]

Reading node meta just requires a hashtable lookup, afaik. The issue is rather that the mapblock mesh maker thread has no access to node meta. And changing this would require copying the respective meta fields, and remeshing if they change.