游戏模型的合批处理方法、装置及电子设备与流程

本申请涉及游戏技术领域，尤其是涉及一种游戏模型的合批处理方法、装置及电子设备。

背景技术：

现有的游戏模型的资源合批处理方法为：从弥赛亚引擎中把模型导出到3dmax软件中，在3dmax软件中手动把导入的模型合批成一个模型，在手动合批过程中，会产生许多中间文件，比如，max文件或psd文件等，一旦有一个文件发生错误，就会影响整个模型的合批过程，这种资源合批方式操作繁琐、耗时严重而且容错率较低。

技术实现要素：

本申请的目的在于提供一种游戏模型的合批处理方法、装置及电子设备，能够对多个游戏模型进行自动化合批操作，得到合批后的整体模型。

第一方面，本申请实施例提供一种游戏模型的合批处理方法，通过电子设备显示游戏引擎的图形用户界面，该方法包括：响应针对于图形用户界面的模型获取操作，得到多个待合批的游戏模型；响应针对于多个游戏模型的摆放操作，确定多个游戏模型的模型摆放形态；通过游戏引擎提取多个游戏模型对应的模型资源；按照模型摆放形态，对各个游戏模型对应的模型资源进行合批处理，得到模型摆放形态对应的整体游戏模型。

进一步的，上述响应针对于图形用户界面的模型获取操作，得到多个待合批的游戏模型包括：响应针对于图形用户界面中的模型的选择操作和/或复制操作，得到多个待合批的游戏模型。

进一步的，上述响应针对于多个游戏模型的摆放操作，确定多个游戏模型的模型摆放形态的步骤，包括：响应针对于多个游戏模型的拖动操作和/或旋转操作，调整多个游戏模型的位置关系，基于调整后的多个游戏模型确定模型摆放形态。

进一步的，上述确定多个游戏模型的模型摆放形态的步骤之后，还包括：响应于针对模型摆放形态的保存操作，对模型摆放形态的多个游戏模型分别对应的模型资源进行保存。

进一步的，上述通过游戏引擎提取多个游戏模型对应的模型资源的步骤，包括：通过游戏引擎获取多个游戏模型对应的标识；根据各个游戏模型分别对应的标识，从预设数据库中查找各个标识分别对应的模型资源。

进一步的，上述模型资源包括：模型文件、材质球、贴图和模型信息；所述模型信息包括：lod层级细节、物理碰撞和uv图。

进一步的，上述uv图包括：用于贴图合批的uv图和用于烘焙的uv图。

第二方面，本申请实施例还提供一种游戏模型的合批处理装置，通过电子设备显示游戏引擎的图形用户界面，装置包括：模型获取模块，用于响应针对于图形用户界面的模型获取操作，得到多个待合批的游戏模型；模型形态确定模块，用于响应针对于多个游戏模型的摆放操作，确定多个游戏模型的模型摆放形态；模型资源提取模块，用于通过游戏引擎提取多个游戏模型对应的模型资源；模型合批模块，用于按照模型摆放形态，对各个游戏模型对应的模型资源进行合批处理，得到模型摆放形态对应的整体游戏模型。

第三方面，本申请实施例还提供一种电子设备，包括处理器和存储器，存储器存储有能够被处理器执行的计算机可执行指令，处理器执行计算机可执行指令以实现上述方法。

第四方面，本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质存储有计算机可执行指令，计算机可执行指令在被处理器调用和执行时，计算机可执行指令促使处理器实现上述方法。

本申请实施例提供的一种游戏模型的合批处理方法，通过电子设备显示游戏引擎的图形用户界面，然后针对图形用户界面的一些操作，可以确定出多个待合批的游戏模型以及合批后要呈现的模型摆放形态；然后通过游戏引擎提取多个游戏模型对应的模型资源，并按照模型摆放形态，分别对各个游戏模型对应的模型资源进行合批处理，得到模型摆放形态对应的整体游戏模型。本申请实施例可以在游戏引擎中对多个游戏模型进行自动化合批处理，不会存在max文件、psd文件等中间文件，节省时间、节省人力，能够提高模型合批效率，且容错率较高。

附图说明

为了更清楚地说明本申请具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种游戏模型的合批处理方法的流程图；

图2为本申请实施例提供的一种待合批的游戏模型示意图；

图3为本申请实施例提供的一种模型摆放形态的示意图；

图4为本申请实施例提供的一种合批后的整体游戏模型的示意图；

图5为本申请实施例提供的一种游戏模型的合批处理装置的结构示意图；

图6为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

下面将结合实施例对本申请的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

现有的模型资源合批处理方法和流程繁琐、耗时。下面以游戏模型a、b、c三种模型的合批为例进行说明：比如最终的合批模型d，包含6个子模型，两个模型a、三个模型b和一个模型c，在3dmax等三维软件中，把6个子模型手动合批制作成d，需要重新调整3级别远景细节显示，假设每个子模型都允许复制，至少需要产生3个级别，每个级别一个远景细节显示文件lodx3，重新调整物理碰撞，如物理碰撞x6。每个子模型会有3级别远景细节显示(lodx3)，每层远景细节显示都需要一套贴图用firstuv和一套烘焙用seconduv。重新调整贴图用的18个firstuv分布(firstuvx6个子模型x3个lod层级＝18firstuv)、重新调整烘焙用的18个seconduv分布(seconduvx6个子模型x3个lod层级＝18seconduv)。这个流程一共需要3x3+18+18+18＝63个过程文件调整，如果是4个不同的子模型参与合批，过程文件数量就是4x3+18+18+24＝72以此类推，并且任意一个过程文件出错，最终的文件也会作废，制作起来比较耗时，容错率较低。

基于此，本申请实施例提供一种游戏模型的合批处理方法，可以在游戏引擎中对多个游戏模型进行自动化合批处理流程，提高模型合批效率，且容错率较高。

图1为本申请实施例提供的一种游戏模型的合批处理方法的流程图，通过电子设备显示游戏引擎的图形用户界面，上述游戏引擎可以是弥赛亚引擎，也可以是其它的游戏引擎。该方法包括以下步骤：

步骤s102，响应针对于图形用户界面的模型获取操作，得到多个待合批的游戏模型。

上述图形用户界面中显示有多个可选择的游戏模型，如房屋、道具等等，这些可选择的游戏模型为用户预先上传至引擎中的，包括游戏模型对应的模型资源，如模型文件、材质球、贴图和模型信息。用户可以根据实际需要选择想要合批的游戏模型，具体的模型获取方式可以是对同一个模型的复制操作或者选择操作，最终可以得到多个待合批的游戏模型，如图2所示，选择三个游戏模型a、b、c，然后对a复制一次，对b复制两次，最终得到待合批的6个游戏模型：两个a、三个b和一个c。

步骤s104，响应针对于多个游戏模型的摆放操作，确定多个游戏模型的模型摆放形态。

上述对游戏模型的摆放操作可以根据游戏场景需求、美术效果来进行，摆放操作可以是对游戏模型的拖动操作，也可以是对游戏模型手旋转操作等，模型摆放形态如图3所示，上述6个游戏模型堆叠在一起。

步骤s106，通过游戏引擎提取多个游戏模型对应的模型资源。

上述模型资源包括：模型文件、材质球、贴图和模型信息；上述模型信息包括：lod层级细节、物理碰撞和uv图，其中，uv图包括：用于贴图合批的uv和用于烘焙的uv。上述贴图指的是模型需要用到的贴图，带有颜色信息的图；uv图为模型表面展开得到的图，其不具有颜色属性，在具体实施过程中，按照uv图的分布分别显示贴图上的颜色信息，可以使上述贴图链接到模型上。

模型资源的提取方式有多种，如可以通过游戏引擎直接从数据库中提取，或者也可以通过游戏引擎中配置的插件进行自动提取。

步骤s108，按照模型摆放形态，对各个游戏模型对应的模型资源进行合批处理，得到模型摆放形态对应的整体游戏模型。

上述合批处理的过程可以是游戏引擎自动来完成，也可以是游戏引擎调用其配置的合批插件来实现，最终通过模型资源整合，得到上述模型摆放形态对应的整体游戏模型，也就是一个完整的游戏模型，其对应的模型资源，如：模型文件、材质球、贴图和模型信息均是合批处理后的。如图4所示，合批后的游戏模型d与上述模型摆放形态是对应的。

本申请实施例提供的一种游戏模型的合批处理方法，通过电子设备显示游戏引擎的图形用户界面，然后针对图形用户界面的一些操作，可以确定出多个待合批的游戏模型以及合批后要呈现的模型摆放形态；然后通过游戏引擎提取多个游戏模型对应的模型资源，并按照模型摆放形态，分别对各个游戏模型对应的模型资源进行合批处理，得到模型摆放形态对应的整体游戏模型。本申请实施例可以在游戏引擎中对多个游戏模型进行自动化合批处理，不会存在max文件、psd文件等中间文件，节省时间、节省人力，无需将模型资源导出到3d软件中，可以提高模型合批效率，且提高容错率。

为了使模型摆放形态更符合游戏场景或者展现出更好的美术效果，上述响应针对于多个游戏模型的摆放操作，确定多个游戏模型的模型摆放形态的步骤，可以通过以下方式实现：

响应针对于多个游戏模型的拖动操作和/或旋转操作，调整多个游戏模型的位置关系，基于调整后的多个游戏模型确定模型摆放形态。

通过对待合批的游戏模型的多种操作，调整多个游戏模型的位置关系，可以达到一种较好的美术效果，以提高游戏场景的逼真度。

在上述确定多个游戏模型的模型摆放形态的步骤之后，还可以包括以下步骤：

响应于针对模型摆放形态的保存操作，对模型摆放形态的多个游戏模型分别对应的模型资源进行保存。

这种方式是将模型摆放形态对应的引擎文件进行保存，引擎文件中包括各个游戏模型分别对应的模型资源，如模型文件、材质球、贴图和模型信息；上述模型信息包括：lod层级细节、物理碰撞和uv图，其中，uv图包括：用于贴图合批的uv图和用于烘焙的uv图。

上述通过游戏引擎提取多个游戏模型对应的模型资源的步骤，可以有两种实现方式：

第一种：通过游戏引擎获取多个游戏模型对应的标识；根据各个游戏模型分别对应的标识，从预设数据库中查找各个标识分别对应的模型资源如：模型文件、材质球、贴图、lod层级细节、物理碰撞和uv图。

第二种：上述游戏引擎配置有合批插件；调用合批插件从游戏引擎中获取多个游戏模型对应的标识；并根据各个游戏模型分别对应的标识，从预设数据库中查找各个标识分别对应的模型文件、材质球、贴图、lod层级细节、物理碰撞和uv图，得到各个游戏模型分别对应的模型资源。

这里的预设数据库可以是引擎中存放多个游戏模型的模型数据库，也可以是上一步骤中保存的引擎文件。

上述按照模型摆放形态，分别对各个游戏模型对应的模型资源进行合批处理的步骤，也有两种实现方式：

第一种，按照模型摆放形态，调用合批插件分别对各个游戏模型对应的模型资源进行合批处理。通过直接调用引擎中配置的插件来完成自动化合批过程。该插件通过识别引擎level文件，加载组合合批所需要游戏模型对应的材质球、贴图、lod、物理碰撞和uv图，对多个游戏模型进行合并处理，自动生成组合后模型所需要的正确的lod层级、物理碰撞、用于贴图合批的uv图和用于烘焙的uv图，以及合批后的整体模型对应的材质球和贴图。

第二种，检查各个所述游戏模型对应的模型资源的资源类型；对所述资源类型为材质球或贴图的模型资源进行合批处理，得到第一类模型资源；将所述资源类型为模型文件或模型信息的模型资源作为目标模型资源，按照所述模型摆放形态对所述目标模型资源进行合批处理，得到第二类模型资源；基于所述第一类模型资源和第二类模型资源确定所述模型摆放形态对应的整体游戏模型。

上述对所述资源类型为材质球或贴图的模型资源进行合批处理，得到第一类模型资源的步骤，可以通过以下方式实现：

如果所述资源类型为材质球，将各个所述游戏模型对应的材质球中的贴图信息进行叠加，得到合批后的材质球；如果所述资源类型为贴图，将各个所述游戏模型对应的贴图放置于预设尺寸的矩形范围内，得到合批后的贴图；将所述合批后的材质球和所述合批后的贴图，作为第一类模型资源。

上述将所述资源类型为模型文件或模型信息的模型资源作为目标模型资源，按照所述模型摆放形态对所述目标模型资源进行合批处理，得到第二类模型资源，可以通过以下方式实现：

模型的合批：模型、lod、碰撞都属于模型文件，命名不同。举例：模型名12001_metal_box，lod命名lodmesh_12001_metal_box。碰撞命名autophy_lodmesh_12001_metal_box。lod命名是在模型文件命名基础上增加了前缀，合批识别文件名和前缀，进行2次组合，第一次合并模型本身，第二次合并lod。碰撞在合并过的模型文件上单独生成的。

uv图的合批：1套uv是根据合并的贴图的布局重新生成uv。2套uv按照lightmapoffset的规则(所有2u无重叠)，自动重新展开和合并2uv。

本申请实施例提供的游戏模型的合批处理方法，通过电子设备的游戏引擎显示图形用户界面，可视的直观性和操作的直接性，需要哪个游戏模型直接在引擎中点选就好，不用再导出到其他三维软件中修改制作等。能够提高合批流程的效率，简化传统合批流程手动操作工作量，在增加效率和容错率的同时，减少传统合批流程中产生的过程文件，如上文中范例中3x3+18+18+18＝63个过程文件，以及产生这些过程文件的手动操作步骤。在传统合批制作方法所用的时间上，节省出近一半的时间，极大提高合批的工作效率。

基于上述方法实施例，本申请实施例还提供一种游戏模型的合批处理装置，通过电子设备显示游戏引擎的图形用户界面，参见图5所示，该装置包括：

模型获取模块52，用于响应针对于图形用户界面的模型获取操作，得到多个待合批的游戏模型；

模型形态确定模块54，用于响应针对于多个游戏模型的摆放操作，确定多个游戏模型的模型摆放形态；

模型资源提取模块56，用于通过游戏引擎提取多个游戏模型对应的模型资源；

模型合批模块58，用于按照模型摆放形态，对各个游戏模型对应的模型资源进行合批处理，得到模型摆放形态对应的整体游戏模型。

本申请实施例提供的游戏模型的合批处理装置，可以解决前文提到的传统合批方法里繁冗的手动操作部分，包括将子模型导入到3d软件中制作相关远景细节显示层级、两套uv分布、整理物理碰撞等，优化掉原先一大堆的过程文件和手动操作的工作量，大大提高模型合批效率及容错率。

在一种可能的实施方式中，上述模型获取模块52还用于，响应针对于图形用户界面中的模型的选择操作和/或复制操作，得到多个待合批的游戏模型。

在另一种可能的实施方式中，上述模型形态确定模块54还用于，响应针对于多个游戏模型的拖动操作和/或旋转操作，调整多个游戏模型的位置关系，基于调整后的多个游戏模型确定模型摆放形态。

在另一种可能的实施方式中，上述模型形态确定模块54还用于，响应于针对模型摆放形态的保存操作，对模型摆放形态的多个游戏模型分别对应的模型资源进行保存。

在另一种可能的实施方式中，上述模型资源提取模块56还用于，通过游戏引擎获取多个游戏模型对应的标识；根据各个游戏模型分别对应的标识，从预设数据库中查找各个标识分别对应的模型资源。

在另一种可能的实施方式中，上述模型资源包括：模型文件、材质球、贴图和模型信息；模型信息包括：lod层级细节、物理碰撞和uv图。

在另一种可能的实施方式中，上述uv图包括：用于贴图合批的uv图和用于烘焙的uv图。

本申请实施例提供的游戏模型的合批处理装置，其实现原理及产生的技术效果和前述方法实施例相同，为简要描述，上述装置的实施例部分未提及之处，可参考前述方法实施例中相应内容。

本申请实施例还提供了一种电子设备，如图6所示，为该电子设备的结构示意图，其中，该电子设备包括处理器61和存储器60，该存储器60存储有能够被该处理器61执行的计算机可执行指令，该处理器61执行该计算机可执行指令以实现上述方法。

在图6示出的实施方式中，该电子设备还包括总线62和通信接口63，其中，处理器61、通信接口63和存储器60通过总线62连接。

其中，存储器60可能包含高速随机存取存储器(ram，randomaccessmemory)，也可能还包括非不稳定的存储器(non-volatilememory)，例如至少一个磁盘存储器。通过至少一个通信接口63(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。总线62可以是isa(industrystandardarchitecture，工业标准体系结构)总线、pci(peripheralcomponentinterconnect，外设部件互连标准)总线或eisa(extendedindustrystandardarchitecture，扩展工业标准结构)总线等。所述总线62可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

处理器61可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器61中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器61可以是通用处理器，包括中央处理器(centralprocessingunit，简称cpu)、网络处理器(networkprocessor，简称np)等；还可以是数字信号处理器(digitalsignalprocessor，简称dsp)、专用集成电路(applicationspecificintegratedcircuit，简称asic)、现场可编程门阵列(field-programmablegatearray，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器61读取存储器中的信息，结合其硬件完成前述实施例的游戏模型的合批处理方法的步骤。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机可执行指令，该计算机可执行指令在被处理器调用和执行时，该计算机可执行指令促使处理器实现上述方法，具体实现可参见前述方法实施例，在此不再赘述。

本申请实施例所提供的方法、装置和电子设备的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。

除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对步骤、数字表达式和数值并不限制本申请的范围。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

在本申请的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本申请和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本申请的限制。此外，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。

最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

起点商标作为专业知识产权交易平台，可以帮助大家解决很多问题，如果大家想要了解更多知产交易信息请点击 【在线咨询】或添加微信 【19522093243】与客服一对一沟通，为大家解决相关问题。

此文章来源于网络,如有侵权,请联系删除