You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today I've been experimenting with MCPatcher's CTM functionality to see if I could backport the WIP resource pack I'll never complete back to then, and to understand the differences between historical and modern implementations of connected textures (such as things mentioned in #231). There's one thing I've noticed about innerSeams back then: they would apply against any full blocks which obstructed a face, rather than only instances of the same block.
Here's a screenshot using the experimental pack in 1.7.10. This is how it looks with innerSeams disabled:
And with it enabled:
With Continuity in 1.19.4, even if innerSeams is enabled, blocks of other types will not cause this effect to happen.
The same is true in OptiFine (so I may also open a request there):
Of course, just changing the current innerSeams behaviour to this one from 1.7.10 would be undesirable since many resource packs are built under the assumption of the current behaviour. However, I think I personally prefer the MCPatcher handling of cases like these. Would an option of some sort be possible that could allow for changes between these two different types of innerSeams behaviour (current "only against same block type" behaviour would be default, and there'd be a second "against any block that culls the face of this block" option), assuming it doesn't exist already? I'm not sure if this would fit entirely in the scope of the mod if it's only meant to be compatible with OptiFine's CTM implementation, but it's something I'd very much like to see if possible.
I can provide the resource packs used in each case if desired for testing purposes.
The text was updated successfully, but these errors were encountered:
This is simple enough to do. I will have to confirm exactly how it works in MCPatcher by looking at its code. A new property can be added to switch between the modes, with Optifine's mode being the default. This plan is not final, however; after investigation I may make changes to it.
I should clarify that "only against same block type" is not correct. innerSeams in Optifine uses the connection predicate connect; if the original block would connect to the obstructing block, the connection does not happen.
Today I've been experimenting with MCPatcher's CTM functionality to see if I could backport the WIP resource pack I'll never complete back to then, and to understand the differences between historical and modern implementations of connected textures (such as things mentioned in #231). There's one thing I've noticed about innerSeams back then: they would apply against any full blocks which obstructed a face, rather than only instances of the same block.
Here's a screenshot using the experimental pack in 1.7.10. This is how it looks with innerSeams disabled:
And with it enabled:
With Continuity in 1.19.4, even if innerSeams is enabled, blocks of other types will not cause this effect to happen.
The same is true in OptiFine (so I may also open a request there):
Of course, just changing the current innerSeams behaviour to this one from 1.7.10 would be undesirable since many resource packs are built under the assumption of the current behaviour. However, I think I personally prefer the MCPatcher handling of cases like these. Would an option of some sort be possible that could allow for changes between these two different types of innerSeams behaviour (current "only against same block type" behaviour would be default, and there'd be a second "against any block that culls the face of this block" option), assuming it doesn't exist already? I'm not sure if this would fit entirely in the scope of the mod if it's only meant to be compatible with OptiFine's CTM implementation, but it's something I'd very much like to see if possible.
I can provide the resource packs used in each case if desired for testing purposes.
The text was updated successfully, but these errors were encountered: