Continuity

Continuity

9M Downloads

connect=tile property works incorrectly in some cases - unwanted directional behaviour

muzikbike opened this issue ยท 2 comments

commented

The following resource pack changes orange stained glass and pink stained glass to both use a new, identical model, which uses the normal glass texture on the outside and the tinted glass texture on the inside:
continuity-connected-directionality-test.zip

If we make a structure out of only one of these blocks, everything works as expected: the textures connect, innerSeams applies to the outside but not the inside, and so on.
2023-04-10_14 22 33
2023-04-10_14 22 38

The resource pack is set up so that the glass textures used on both blocks should connect to each other, and this is where the problem arises. If we build a structure like this using both blocks:
2023-04-10_14 23 46

we can see that from this side, the normal glass texture connects, which is as expected. However, the interior tinted glass texture does not connect up, and this is a problem. (The inner planes are an intentional vanilla feature, but I've proposed in #241 a way they could be made removable by packs.)

If we go around to the back of it, we can see that the normal glass isn't connected up, which isn't good. The tinted glass textures behind it are, which is good.
2023-04-10_14 23 52

Similar issues arise for the other sides.
2023-04-10_14 23 56
2023-04-10_14 24 01

It'd be expected that the textures would connect as expected on all sides. This, however, does not happen.

commented

connect=tile and connectTiles (for overlays) works by checking the current quad sprite against the adjacent block state's sprite for the current face. If the sprites are exactly the same, the connection succeeds.

The single sprite for block state $S$ on face $F$ is retrieved using the following steps.

  1. Get the model of $S$.
  2. Get all quads with cull face $F$.
  3. If there is at least one quad in the list, the resulting sprite is the sprite of the first quad in the list.
  4. Otherwise, get all quads that do not have a cull face.
  5. If there is at least one quad in the list, the resulting sprite is the sprite of the first quad in the list.
  6. Otherwise, the resulting sprite is the model's particle sprite, which always exists.

Note: In Continuity, once the sprite is retrieved for a certain block state and direction, it will remain the same until the next resource reload. This may not be the case in Optifine.

This issue is inherent to how connect=tile works and is not a bug. Since each combination of block state and face can only have a single sprite, cases like your example where a face may have more than one sprite across multiple quads will not work correctly. In my testing, only the inner textures or the outer textures connected for a specific face, which is to be expected.

A potential solution to specifically this case would be to allow the more reliable connectBlocks to be used on non-overlay methods, which would allow you to specify that orange and pink stained glass should always connect only to each other. Improving the existing connect=tile is not an option because it would potentially break compatibility with other packs that rely on the existing behavior. However, adding a better connect=tile method is possible. It could collect all sprites for the necessary face instead of just one, though this could cause issues if the multiple quads that contain the multiple sprites are on different sides of the block or spread out in such a way that would otherwise make connected textures look incorrect.

commented

Some further screenshots: these are rings of eight glass blocks with one beacon in the middle on each axis. I've made beacons look identical to glass in the resource pack for testing purposes and used MoreCullingExtra to enable culling between glass and beacons.

The connected textures work fine on one side but not the other.
2023-04-22_19 03 09
2023-04-22_19 03 15