融合模组 1.3.12

• 修复了 MutableQuad#chunkLayer 未能始终覆写标志位的问题

融合模组 1.3.11

• 大幅降低了融合模型所占用的内存
  • MutableQuad 的朝向与区块渲染类型现以位标志形式存储
  • 当判定条件恒为真或恒为假时，connecting 纹理将忽略非默认图块
  • 当部分图块为空时，connecting 纹理的子纹理数据现以更紧凑的方式存储
  • 当 connecting 纹理无子纹理时，其图块将按需延迟初始化

融合模组 1.3.10

• 修复了模型物品变换（display 属性）的平移未按 1/16 比例缩放的问题
• 修复了被方块模型修饰器所作用的方块模型在启用 Sodium 时无法获取世界上下文的问题

融合模组 1.3.9

• 修复了 dimension 方块模型判定条件在区块几何体中不生效的问题

融合模组 1.3.8

• 修复了将 continuous 纹理类型用作其他纹理类型的子纹理时引发崩溃的问题
• 修复了按随机偏移分组的方块模型修饰器生成的模型被错误提交至所有模型渲染类型的 bug
• 修复了按随机偏移分组的方块模型修饰器生成的模型未获取世界上下文的问题
• 修复了复合模型的纹理依赖项并非总能被正确加载的问题

融合模组 1.3.7

• 修复了因 Mixin 错误导致破坏被方块模型修饰器作用的方块时崩溃的问题

融合模组 1.3.6

• 为方块模型修饰器的模型条目新增 random_offset 属性，用于覆写硬编码的方块随机偏移量
• 优化了 random 纹理类型的随机性
• 大幅降低了 MutableQuad 及由此生成的融合模型的内存占用
• 修复了 match_state_in_front 行为与 match_state 相同的问题
• 修复了为动画纹理显式指定帧索引时，UV 计算错误导致始终仅显示第一帧的问题
• 修复了因浮点误差导致方块模型判定条件旋转错误的问题
• 修复了 Forge/NeoForge 的 render_type 属性在 cuboid 模型上失效的问题

融合模组 1.3.5

• 方向性模型判定条件（即 match_block 和 match_state）现会随 composite 模型条目一同旋转
• 将原版默认的模型元素 UV 计算方式替换为更优算法，可更好处理位于中心方块空间之外的元素
• 修复了融合模型的物品变换（display 属性）反序列化失败的问题
• 修复了 match_block 与 match_state 模型判定条件，以及 match_block、match_state、match_block_in_front、match_state_in_front 连接判定条件仅使用 blocks 数组属性中最后一个方块的问题
• 修复了 composite 模型变换的原点发生偏移的问题
• 修复了 composite 模型变换与方块状态文件变换之间的组合顺序错误问题

融合模组 1.3.4

• 修复了 match_block 与 match_state 方块判定条件可能因线程问题导致结果错误或崩溃的问题
• 修复了模型元素面的 uv 属性被忽略的问题

融合模组 1.3.3

• 修复了 dimension、match_block 与 match_state 方块判定条件的反序列化问题
• 修复了 dimension 实体判定条件的反序列化问题

融合模组 1.3.2a

• 修复了模组在常规烘焙窗口之外烘焙模型时引发崩溃的问题
• 修复了创建纹理动画帧时引发崩溃的问题

融合模组 1.3.2

• 修复了设置 Forge 覆盖的模组方块错误使用渲染类型的问题
• 修复了物品模型中 connecting 纹理判定条件解析失败的问题

融合模组 1.3.1

• 修复了 overlay 类型的连接纹理布局生成过多四边形的问题
• 修复了连接纹理的 connections 属性失效的问题
• 修复了基础纹理属性对 connecting 和 random 纹理类型无效的问题
• 修复了 base 模型的几何体被重复生成的问题
• 修复了与快速资源包模组配合使用时的崩溃问题
• 将 ConnectingModelData.ConnectingModelDataBuilder 重命名为 ConnectingModelData.Builder
• 修复了 CuboidModelDataBuilder#material 方法递归调用自身的问题
• 修复了模型材质映射序列化时未为引用添加 '#' 符号的问题

融合模组 1.3.0

• 模型相关变更：
  • 重构了 ModelType 及模型加载机制：
    • 任何带有融合模组自定义模型格式的模型均可通过 JSON 文件直接定义，无需额外 Java 类；现有模型仍完全兼容