• 低代码
• 代码生成
• 桌面应用
• 游戏开发

导读

本文围绕 MCreator 生物实体（Living Entity）定义中的"纹理"（Texture）字段展开，讲解实体纹理与所选用模型的兼容关系、不同模型对纹理尺寸的硬性要求，以及当基础纹理无法满足复杂表现时如何借助"模型图层"（Model Layers）机制进行扩展。通过阅读本文，你将掌握在 MCreator 中为自定义生物正确选择与导入实体纹理的方法，理解纹理从工作区资源到生成代码的完整流转链路，并能够利用模型图层实现发光、条件显示等多层渲染效果。文中所有结论均以 mcreator-localization 帮助文档 与当前仓库源码为依据。

一、实体纹理字段在编辑器中的位置

在 MCreator 的"生物实体"（Living Entity）定义编辑器中，纹理字段位于视觉外观页面（Visual 页面）。源码中该页面被明确注册为elementgui.living_entity.page_visual，并与模型名称、碰撞箱等视觉参数同组管理，见 LivingEntityGUI.java。

纹理字段本身由一个专用的TextureComboBox控件承载，并带有指向entity/texture帮助文档的帮助按钮，代码如下：

mobModelTexture = new TextureComboBox(mcreator, TextureType.ENTITY).requireValue( "elementgui.living_entity.error_entity_model_needs_texture"); // ... spo2.add(HelpUtils.wrapWithHelpButton(this.withEntry("entity/texture"), L10N.label("elementgui.living_entity.texture"))); spo2.add(mobModelTexture);

见 LivingEntityGUI.java 与 LivingEntityGUI.java。

两点值得注意：

1. 纹理是必填项：requireValue(...)使该字段强制校验，若未选择纹理，保存时会在界面上提示error_entity_model_needs_texture（实体模型需要纹理），从机制上保证每个实体定义都具备可用的外观纹理。
2. 纹理类型限定为 ENTITY：TextureComboBox的构造参数TextureType.ENTITY决定了下拉框只列出工作区中"实体纹理"类别的图片资源，不会混入物品、方块等其他类型的纹理。

二、纹理必须与所选模型兼容

帮助文档的第一条核心要求是："确保纹理与所选模型兼容"（原文：Make sure the texture is compatible with the model you selected，见 默认英文文档）。

在 MCreator 的数据模型中，实体外观由两个字段共同决定（见 LivingEntity.java）：

• mobModelName：所选模型名称，内置模型集合包括Biped（两足动物）、Chicken、Cod、Cow、Creeper、Ghast、Ocelot、Pig、Piglin、Salmon、Silverfish、Slime、Spider、Villager、Witch，且允许填入自定义值（allowCustom = true）；
• mobModelTexture：实体纹理名称，通过@TextureReference(TextureType.ENTITY)注解关联到工作区纹理资源。

模型与纹理的"兼容"包含两层含义：

2.1 贴图布局必须匹配模型的 UV 展开

不同模型对纹理的 UV 布局约定不同。例如Biped（两足动物）模型使用的是 Minecraft 标准的人形生物 UV 布局，纹理中的头、身体、四肢各区域必须按该布局绘制，否则模型表面会出现纹理错位。而Villager、Witch等模型同样有各自的头部与身体 UV 约定。

2.2 纹理尺寸必须满足模型规格

文档明确指出（见 默认英文文档）：

两足动物模型（Biped models），例如，只支持 64x64（Minecraft 1.18 之前为 64x32）的两足类型纹理。

这是 Minecraft 对两足动物模型贴图尺寸的硬性约束：

• Minecraft 1.18 及以后：两足动物模型标准纹理为64x64 像素；
• Minecraft 1.18 之前：旧版两足动物模型使用64x32 像素的纹理。

因此，在 MCreator 中为Biped模型制作纹理时，必须根据目标 Minecraft 版本选择 64x64 或 64x32 的画布尺寸，否则纹理会被拉伸、压缩或出现未覆盖区域。其他内置模型（如Cow、Pig、Chicken等）同样遵循各自的规格纹理尺寸，绘制时应以其原始贴图为参考。

三、纹理资源从哪来：实体纹理的导入与管理

实体纹理属于工作区资源中ENTITY类型的纹理。在源码的TextureType枚举中可以看到完整的纹理类型体系（见 TextureType.java）：

BLOCK("block"), ITEM("item"), ENTITY("entity"), EFFECT("effect"), PARTICLE("particle"), SCREEN("screen"), ARMOR("armor"), OTHER("other")

对应的实体纹理导入入口是"导入实体纹理"（Import Entity Texture）动作，注册代码见 ActionRegistry.java：

this.importEntityTexture = new TextureImportAction(this, L10N.t("action.import_entity_texture"), TextureType.ENTITY).setIcon(UIRES.get("16px.importentity"));

导入后的纹理文件实际存储在工作区的纹理目录下。WorkspaceFolderManager.getTextureFile()将纹理标识符解析为具体的 PNG 文件路径，而目录位置由生成器配置中的entity_textures_dir决定（见 WorkspaceFolderManager.java 与 WorkspaceFolderManager.java）：

public File getTextureFile(String textureIdentifier, TextureType section) { return new File(getTexturesFolder(section), textureIdentifier + ".png"); }

以 NeoForge 生成器为例，entity_textures_dir对应生成项目中的src/main/resources/assets/<modid>/textures/entities/目录，这也是后文渲染器代码中纹理标识符路径的由来。

四、纹理如何进入生成的代码：渲染器实现剖析

实体纹理最终会被写入到生成模组的实体渲染器类中。以当前仓库的 NeoForge 26.3 生成器模板为例，livingentity_renderer.java.ftl 中可以看到纹理标识符的生成逻辑：

private final Identifier entityTexture = Identifier.parse("${modid}:textures/entities/${data.mobModelTexture}");

并在渲染状态提取时作为getTextureLocation的返回值交给 Minecraft 渲染管线：

@Override public Identifier getTextureLocation(${renderState} state) { return entityTexture; }

见 livingentity_renderer.java.ftl 与 livingentity_renderer.java.ftl。

可以推断，这一"模型渲染器 + 实体纹理"的生成范式在 Java 版各生成器（Forge / NeoForge / 数据包资源）中保持一致：只要在界面中选好纹理，生成的渲染器类就会以textures/entities/<纹理名>的路径加载它。因此，纹理文件必须为 PNG 格式且位于实体纹理目录下，否则运行时会出现纹理加载失败。

此外，实体纹理还参与工作区中的预览图生成。LivingEntity.generateModElementPicture()会读取实体纹理文件来生成实体元素的预览图片（见 LivingEntity.java），这意味着修改纹理后工作区的实体预览会同步更新。

五、复杂表现：模型图层（Model Layers）选项卡

当单一纹理无法满足需求（例如需要额外发光部位、附加装饰部件、条件显示的第二层外观）时，帮助文档给出了明确指引：

对于更复杂的模型图层定义，请使用"模型图层"（Model Layers）选项卡。

见 默认英文文档 与 模型图层帮助文档。该选项卡对应的页面注册在 LivingEntityGUI.java，由JModelLayerList组件管理（见 JModelLayerList.java）。

5.1 图层的数据模型

每个模型图层在数据模型中对应LivingEntity.ModelLayerEntry，其字段定义见 LivingEntity.java：

public static class ModelLayerEntry implements IWorkspaceDependent { public String model; // 图层使用的模型，可为 "Default"（跟随实体模型） @TextureReference(TextureType.ENTITY) public String texture; // 图层纹理（实体纹理类型） public boolean disableHurtOverlay; // 是否禁用受击红色覆盖层 public boolean glow; // 是否以发光（eyes）模式渲染 public Procedure condition; // 图层显示的条件 }

要点解读：

• 图层纹理同样使用TextureType.ENTITY类型，与主纹理一致，都是实体纹理资源；
• model字段可设为Default：此时图层沿用实体主模型进行渲染，适合做发光层、覆盖层；也可以指定自定义 Java 模型，叠加独立部件（此时通过getLayerModel()解析模型资源，见 LivingEntity.java）；
• glow开关决定渲染方式，与"发光纹理"（Glow Texture）概念相关——帮助文档说明发光纹理中越明亮的区域，对应生物部位发光越强（见 glow_texture.md）。

5.2 图层在生成代码中的实现

渲染器模板对图层列表做了逐条展开，每个图层被编译为一个附加渲染层（addLayer），核心逻辑见 livingentity_renderer.java.ftl：

this.addLayer(new RenderLayer<>(this) { final Identifier LAYER_TEXTURE = Identifier.parse("${modid}:textures/entities/${layer.texture}"); final RenderType RENDER_TYPE = RenderTypes.<#if layer.glow>eyes<#else>entityCutout</#if>(LAYER_TEXTURE); <#if layer.model != "Default"> final EntityModel LAYER_MODEL = new ${layer.model}(...bakeLayer(...)); </#if> // submit 方法内：按条件（layer.condition）渲染 LAYER_MODEL 或父模型， // 并根据 layer.disableHurtOverlay 决定是否使用受击叠加层 });

这段模板清楚地展示了图层机制的三项能力：

1. 多纹理叠加：图层使用独立的实体纹理LAYER_TEXTURE，叠加在基础纹理之上；
2. 发光渲染：勾选glow的图层以RenderTypes.eyes（眼睛/发光模式）渲染，未勾选则使用entityCutout模式；
3. 条件控制：存在condition过程（Procedure）时，图层仅在条件成立时提交渲染，可实现"受伤时显示""夜晚显示"等动态外观。

六、模型与纹理的完整搭配建议

综合帮助文档与源码，为自定义实体配置纹理的推荐流程如下：

1. 先定模型，再定纹理：在"视觉外观"页面确定mobModelName（内置模型或自定义模型）。自定义模型在数据层被识别为Model.Type.JAVA，内置模型为Model.Type.BUILTIN，见 LivingEntity.java 中getEntityModel()的判断逻辑；
2. 按模型规格制作纹理：以Biped为例，Minecraft 1.18 及以上使用 64x64，1.18 之前使用 64x32；其他模型参考其原版贴图规格；
3. 导入并选择纹理：通过"导入实体纹理"将 PNG 加入工作区，在纹理下拉框中选择（该字段为必填）；
4. 按需添加模型图层：如需发光部位、独立装饰部件或条件外观，在"模型图层"选项卡中逐条添加图层，并为每条图层指定实体纹理、模型、发光开关与显示条件。

结语

MCreator 的实体纹理看似只是一个图片选择框，背后却串联着模型 UV 兼容性、版本相关的尺寸规格、纹理资源管理以及渲染器代码生成等多层机制。理解"纹理必须与模型兼容"这条核心原则（尤其是两足动物模型 64x64 / 64x32 的版本差异），再掌握模型图层对纹理叠加的扩展能力，你就能为自定义生物制作出既符合 Minecraft 渲染规范、又具备多层动态表现的外观系统。更多相关细节可继续查阅 mcreator-localization 帮助文档目录 中的模型（model）、模型图层（model_layers）、发光纹理（glow_texture）等条目。

• 低代码
• 代码生成
• 桌面应用
• 游戏开发