meta data for this page
📚 差别
这里会显示出您选择的修订版和当前版本之间的差别。
| 两侧同时换到之前的修订记录前一修订版后一修订版 | 前一修订版 | ||
| extend:model [2023/04/04 22:56] – ↷ 页面assetdev:model被移动至extend:model bibiboxs | extend:model [2025/08/05 16:22] (当前版本) – bibiboxs | ||
|---|---|---|---|
| 行 1: | 行 1: | ||
| < | < | ||
| - | # | + | # 模型开发扩展 |
| 在《沙盘引擎》世界场景中,模型占据了视觉上绝大部分,**任何3D模型都被统称为“模型”(Model)。** | 在《沙盘引擎》世界场景中,模型占据了视觉上绝大部分,**任何3D模型都被统称为“模型”(Model)。** | ||
| 行 6: | 行 6: | ||
| 沙盘引擎默认内置了不同分类下的**多种预制模型**,进阶玩家\开发者可直接在此基础上使用《地图编辑器》进行地图的创作,以供不同模组的调用使用。 | 沙盘引擎默认内置了不同分类下的**多种预制模型**,进阶玩家\开发者可直接在此基础上使用《地图编辑器》进行地图的创作,以供不同模组的调用使用。 | ||
| - | 除了内置的预制模型外,沙盘引擎也**支持导入外部文件到当前模组**(支持`gltf\obj`格式),通过此机制,进阶玩家\模组开发者可以将自己想要的模型导入到引擎,同时引擎会自动(或辅助注册`json`)将模型添加到世界列表,无论是地图编辑器或脚本Exec,都可以直接进行创建模型对象及修改属性。 | + | 除了内置的预制模型外,沙盘引擎也**支持导入外部文件到当前模组**(支持`gltf\glb\obj`格式)。 |
| - | > 本文将主要介绍模型开发教程及扩展规范,如果有意将自定义模型导入到沙盘引擎使用,建议参考本文介绍。 | + | 通过外部导入机制,开发者可将自己想要的模型导入到世界,同时引擎会自动(或开发者手动注册`json`)将模型添加到世界列表,无论是地图编辑器或脚本API,均可直接创建模型对象及修改属性。 |
| + | |||
| + | > **本文将主要介绍模型开发教程及扩展规范,如果有意将自定义模型导入到沙盘引擎使用,建议参考本文介绍。** | ||
| > | > | ||
| - | > 在此之前,建议优先查看[《世界资源实例》](reference/ | + | > **在此之前,建议优先查看[《世界资源实例》](reference/ |
| - | ## | ||
| - | 如果你已经拥有一些模型等待被导入,那么可以参考以下步骤和介绍。 | ||
| - | 首先,任何模型都是基于模组框架下来注册的,你应该先选择(或新建)一个模组目录,并找到目录下的`Store\Model`文件夹,将任何你想要添加的模型文件放置到这里。 | + | ## 模型导入及注册 |
| - | *前提:必须是受支持的模型格式(如:`gltf及obj文件`)* | + | > 如果拥有一些外部模型想要导入到模组中,那么可以参考以下步骤和介绍。 |
| + | > | ||
| + | > **导入前提:必须是受支持的模型格式(如:`gltf\glb\obj文件`)** | ||
| - | > 每次模型的注册和导入都会在引擎加载模组时触发。 | + | 模型的导入与注册全部基于模组框架,首先找到模组目录下的`Store\Model`文件夹,将任何你想要导入的模型文件放置到这里,**并正确修改标准文件名(例如:`ID_Name | 10000_Model`)(如果没有修改ID文件名则不会被识别)**。 |
| + | |||
| + | |||
| + | 或重启引擎程序来触发更新。** |
| + | |||
| + | 在完成上述步骤后,如果模型文件本身没有特别的问题,那么最简单的方式,可以打开《地图编辑器》在模型列表中找到导入成功的模型==**(文件名绑定的ID就是引擎内模型ID)**==,反之可以查看[~]控制台是否出现异常报错。 | ||
| + | |||
| + | |||
| + | |||
| + | ### GLTF\GLB格式 | ||
| + | |||
| + | GLTF模型仅支持导入**标准\规范格式**的文件,如果出现==导入报错或不确定是否能导入==,可通过[【glTF Viewer】](https:// | ||
| + | |||
| + | > 建议优先使用:`gltf\glb`格式。 | ||
| + | |||
| + | |||
| + | |||
| + | ### OBJ格式 | ||
| + | |||
| + | OBJ格式通常由多个文件组成一个模型(例如:`.obj|.mtl|.png`等),这些文件分别表示【模型网格、材质配置、材质贴图等】,如果缺少部分文件可能会导致显示异常(GLTF模型通常为一体化的文件格式,则可以忽略这个问题)。 | ||
| + | |||
| + | 基于多文件组成的原因,导入OBJ模型时需要注意:只将`.obj`文件修改前缀ID文件名,其他附带文件通常不需要更改。 | ||
| + | |||
| + | > 示例:开发者希望导入一套obj模型(`Book.obj | Book.mtl | Book.png`),首先**按照正常步骤**将所有文件放置到`LocalMod\Store\Model`目录内,紧接着**==只==需要修改`Book.obj`文件名为`10000_Book.obj`即可**,其他的`mtl\png`等附带文件不需要修改前缀。 | ||
| - | 在完成上述步骤后,如果模型文件本身没有特别的问题,那么最简单的方式,可以打开《地图编辑器》在模型列表中找到导入成功的模型,反之,你也可以优先查看[~]控制台是否出现异常报错。 | ||
| ### 高级设定 | ### 高级设定 | ||
| 行 38: | 行 65: | ||
| 如果你看过了[《世界资源实例》](reference/ | 如果你看过了[《世界资源实例》](reference/ | ||
| - | 根据上述提及的文章所示,==**任何非官方内置的模型资源,模型ID都是从10000开始递增的**==,也就是说**无论外部模型是否进行了高级设定注册,模型的ID都永远不会是10000以下的数字,==且默认被放置到`模组资源包(特殊)`包内==**。 | + | 根据上述提及的文章所示,==**任何非官方内置的模型资源,模型ID都是从10000开始递增的**,也就是说**无论外部模型是否进行了高级设定注册,模型的ID都永远不会是10000以下的数字,且默认被放置到【模组资源包(特殊)】包内==**。 |
| - | --- | + | |
| + | |||
| + | ### 高级设定步骤 | ||
| 那么如果想要为模型注册高级设定,请参考以下步骤来进行操作: | 那么如果想要为模型注册高级设定,请参考以下步骤来进行操作: | ||
| - | 首先找到模组目录下的`Data\Model`文件夹,然后找到或新建一个`json`文件,打开进行编辑(默认原始情况下,此目录可能需要手动新建一个json文件)。 | + | 首先找到模组目录下的`Store\Data\Model`文件夹,然后找到或新建一个`json`文件,打开进行编辑(默认原始情况下,此目录可能需要手动新建一个json文件)。 |
| - | > 注意:这里的json文件命名会有一些讲究。 | + | > **注意:这里的json文件命名会有一些讲究。** |
| > | > | ||
| - | > 如果你只希望为导入模型添加一些高级设定,那么你可以直接建立一个`Custom.json`文件,这里可以放置任何属于【未分类、外部导入模型】分类下的高级设定数据。 | + | > 如果你只希望为导入模型添加一些高级设定,那么你可以直接建立一个`Custom.json`文件,这里可以放置任何属于**【未分类、外部导入模型】**分类下的高级设定数据。 |
| > | > | ||
| - | > 反之来说,如果你主要希望使用《地图编辑器》的玩家方便分类寻找**(或特别规范的开发)**,那么你可以参考上文《世界资源实例》文章内表格的格式,按照《沙盘引擎》内置的分类来进行覆盖分类。 | + | > 反之来说,如果**主要希望使用《地图编辑器》的玩家方便分类寻找(或特别规范的开发)**,那么你可以参考上文《世界资源实例》文章内表格的格式,**按照《沙盘引擎》内置的分类来进行覆盖分类**。 |
| > | > | ||
| - | > 比如:如果只是在`Custom.json`文件内编写属性,那么最终地图编辑器(模型分类)会被分类到【未分类+外部导入模型】,如果只是内部使用或者小范围使用,这没有什么问题。 | + | > 比如:如果只是在`Custom.json`文件内编写属性,那么最终地图编辑器(模型分类)会被分类到**【未分类+外部导入模型】**,如果只是内部使用或者小范围使用,这没有什么问题。 |
| > | > | ||
| > 但是,如果希望规范开发,或者导入的模型比较多,希望未来自己或其他玩家使用《地图编辑器》制作地图时方便分类寻找,那么就应该按照分类格式json来进行覆盖或叠加。 | > 但是,如果希望规范开发,或者导入的模型比较多,希望未来自己或其他玩家使用《地图编辑器》制作地图时方便分类寻找,那么就应该按照分类格式json来进行覆盖或叠加。 | ||
| 行 62: | 行 91: | ||
| > **扩展:**根据《世界实例资源》文档介绍,`0004_TEST.json`应该表示**乡村资源包**,如你所见,命名最关键的主要是" | > **扩展:**根据《世界实例资源》文档介绍,`0004_TEST.json`应该表示**乡村资源包**,如你所见,命名最关键的主要是" | ||
| - | *当然,如果你已经理解了这些内容,你完全可以决定是否这样做,这会增加一些操作成本,但是会换取一些分类便利。* | + | *当然,如果你已经理解了这些内容,你完全可以决定是否这样做,这会增加一些操作成本,但是也许会换取一些分类便利。* |
| - | ### 高级设定配置 | + | |
| + | |||
| + | ### 配置文件 | ||
| 根据上方介绍的高级设定内容,应该已经大致了解设定注册的意义,现在开始介绍具体的json配置方式。 | 根据上方介绍的高级设定内容,应该已经大致了解设定注册的意义,现在开始介绍具体的json配置方式。 | ||
| 行 112: | 行 143: | ||
| > | > | ||
| > 只是更多为有兴趣建模的开发者指引一条可能的道路和指引。 | > 只是更多为有兴趣建模的开发者指引一条可能的道路和指引。 | ||
| + | |||
| + | |||
| ### 推荐建模工具 | ### 推荐建模工具 | ||
| 行 121: | 行 154: | ||
| | 软件名 | | 软件名 | ||
| | ------------------------------------------------------------ | ------------------------------------------------------------ | ---- | | | ------------------------------------------------------------ | ------------------------------------------------------------ | ---- | | ||
| - | | [Magicavoxel](https:// | + | | [Magicavoxel](https:// |
| - | | [Blockbench](https:// | + | | [Blockbench](https:// |
| - | | [Blender](https:// | + | | [Blender](https:// |
| 建模工具最终实现的效果几乎是一致的,只是不同工具有不同的限制和操作方式,开发者可根据自身需要探索学习。 | 建模工具最终实现的效果几乎是一致的,只是不同工具有不同的限制和操作方式,开发者可根据自身需要探索学习。 | ||
| - | 经过实际测试操作,以上工具均可以导出至少`gltf\obj`格式其中的一种,所以可直接按照上文方式导入到引擎内使用。 | + | 经过实际测试操作,以上工具均可以导出至少`gltf\glb\obj`格式其中的一种,所以可直接按照上文方式导入到引擎内使用。 |
| *有关建模工具的教程请参考http:// | *有关建模工具的教程请参考http:// | ||
| + | |||
| + | |||
| ## 特殊模型规范 | ## 特殊模型规范 | ||
| - | 如果细心了解过沙盘引擎,你会发现之所以命名为《沙盘引擎》,其中一个原因便是**游戏视角主流是2.5D鸟瞰视角**。 | + | ### LOD模型及命名 |
| + | 注意:如果模型存在父子节点关系,应该避免将子物体命名包含`_LOD`相关字样,这可能会触发引擎其他机制,导致碰撞等系统出现问题。 | ||
| + | |||
| + | |||
| + | |||
| + | |||
| - | 正因为这样的一个核心机制*(虽然后续可能会支持其他视角)*,**使用沙盘引擎衍生出的游戏大部分都是如此的视角方式**,那么通常偶尔会遇到一些特殊类型模型的规范问题。 | ||
| - | > **比如:**游戏内添加一些可进入的建筑房屋,但是这样的视角默认由上到下看到的只能是“房顶”,看不到具体内部的布局和情况,这明显是不符合玩家常理的。 | ||
| - | > | ||
| - | > **沙盘引擎在设计时考虑到了这个问题,所以增加了一种虚拟化的“楼层”方案:** | ||
| - | > | ||
| - | > 当相机按照鸟瞰视角向下看去的时候,**会自动检测当前跟随目标的“所在楼层”**,并通过**向上射线检测+半透明**的方式反馈给玩家视角。 | ||
| - | > | ||
| - | > 也就是说,如果有一个3层楼的建筑,玩家对象当前走进了第一层,那么相机视角将只能看到第一层内的信息**(建筑模型、这一层的载具、对象等)**,其他的层模型会以**半透明或全透明的方式剔除**。 | ||
| - | > | ||
| - | > 如果玩家对象走进了第二层,默认一层和三层都是“遮挡剔除”的==(1层不透明,但由于3D遮挡所以默认不可见;2层可见;3层不可见、楼顶半透明)==。 | ||
| - | > | ||
| - | > 第三层原理和第二层差不多,**利用3D遮挡本身的机制**,无需隐藏1、2层,直接展示第三层即可,同时将第三层的楼顶半透明化。 | ||
| - | --- | ||
| - | 如上文所述的问题和解决方案理解,目前并不能通过全自动的手段解决这个问题。 | ||
| - | 也就是说,如果开发者在制作一个允许进入内部的建筑房屋,那么就需要按照以下介绍的方法,针对模型进行一些特殊的修改,以适配“可进入建筑的视角机制”。 | ||
| - | ==(此处内容等待同步更新完善)== | ||
| </ | </ | ||