This page will discuss all the changes between CTM and CTMF.

Resource Pack Changes

• The "layer" property in CTM texture metadata has been changed. "TRIPWIRE" is no longer an option and the default behavior, which is the same as in CTM, can now be defined using "DEFAULT".

• A new "extra" property for texture metadata has been added: "untransform": [boolean]. This property is set to false by default and is only read by connecting texture types. Setting the property to true will make quads' UVs unreflected and derotated before further transformations are applied to them later in the pipeline. Even though CTM always derotates and sometimes unreflects quads when processing connecting texture types, the default value was chosen to be false because it makes textures look more natural and enables features that are not available in the original CTM. For example, multiple extra models had to be created to make connecting glass panes look correct in CTM. In CTMF with this option disabled, they work without any extra models, and just adding the texture metadata for glass is enough. Enabling this option could be useful when, for example, untransformed UVs are required for a specific connected texture but it is undesirable to override an entire model that rotates/reflects the UVs for that texture.

• Models that use CTM features do not require the "loader": "ctm:ctm" line.

Code Changes

• The pillar texture type now supports the Facade interface.

• CTM overrides in JSON models now support texture references. This means that the additional textures in an override can use the "#[name]" value to be replaced by a an actual texture when the reference is defined in the same model's or a parent model's "textures" block. Note: this feature was present in older CTM versions, but is not available in some of the newer ones.

• All usage of Forge API code has been removed and replaced with either new, manually written code, or Fabric API code. This is the reason behind the "layer" property change, as the Fabric Rendering API does not support certain layers. The way that the Fabric Rendering API works, in comparison to Forge's Rendering API, should also make parts of the code more efficient. CTMF's rendering is entirely based on the Fabric Rendering API and therefore is completely compatible with it, but is not compatible with mods that do not support it, such as Sodium and Optifine (through OptiFabric).

• The public facing API has received a few changes. Other mods can interact with CTMF through the two registry classes. TextureTypeRegistry lets users add new texture types, while OffsetProviderRegistry allows users to register conditional texture offsets. This registry is only used for the "RANDOM" and "PATTERN" texture type, but other mods can access it for other purposes. Since both classes are interfaces, an instance can be retrieved by accessing the INSTANCE field. For example, TextureTypeRegistry.INSTANCE will retrieve an instance of the registry for texture types. This registry style was chosen for consistency, as it is the same one that is used in Fabric API.

• Many classes and packages have been renamed to either be consistent with Fabric API, provide more information, or help with organization.