I see a lot of potential in the ability to conditionally proxy textures based on connection predicates. It could be applicable in a lot of varying situations. This ticket is an elaboration on possible implementations of this system. Currently, the format is as follows:

"proxy": "blocks/my_block_texture"

This suggestion will not impact the behaviour of this proxy statement. I suggest that to define a conditional texture proxy, the proxy entry in the metadata should be handled as an array. This would also allow for multiple proxy conditions for multiple texture references. A prototype of this format can be seen here:

"proxy": [
    {
        "texture" : "blocks/my_block_texture",
        "condition": [{
                "block": "sand",
                "predicate": [{ "variant": "sand" }]
        }]
    }
]

In this example, any application of the original texture on a model would be changed to my_block_texture when the condition of an adjacent sand block is met for that model's block. This implementation could similarly be applied as a model override too. The texture string and condition array would be requirements of a proxy object, and the game should throw an exception if these requirements are not met. If the texture string were present without a condition array, the exception should inform the user of the existing implementation of proxies for "always-on" proxying.

Regarding storing this conditional proxy information, it could either be stored in the texture metadata, or as "ghost sprites" in the wrapping model. The sprites would be paired with a predicate object for the conditions defined in metadata, and would then be matched against each quad's texture sprite during quad collection. Quad texture sprites would be replaced with the predicates paired sprite if there were a match.

I am aware that this would increase the memory footprint of the model significantly, dependant on the number of proxy definitions and condition complexity. I believe that this is a worthy sacrifice for complex conditional texture proxying, however. If end-users wish to abuse this functionality, the memory footprint is their own issue.