CN117839206A - 数据处理方法、装置及电子设备 - Google Patents

Abstract

本申请公开了数据处理方法、装置、电子设备及计算机可读存储介质，方法包括：获取第一虚拟角色在包括多个场景区域的游戏场景中所处的目标场景区域；确定与目标场景区域的距离小于或等于第一距离的第一场景区域以及距离大于第一距离的第二场景区域；获取包括第一建筑部件对应的第一模型和第一模型的渲染细节数据的第一建造部件数据，第一建筑部件为第一场景区域和目标场景区域中的建筑；获取第二场景区域中多个第二建筑部件对应的合批模型的第二建造部件数据；根据第一建造部件数据和第二建造部件数据分别渲染显示第一建筑部件和第二建筑部件。本方案能够在不增加性能消耗的情况下为玩家呈现大世界中较近的建筑以及较远的建筑。

Description

数据处理方法、装置及电子设备

技术领域

本申请涉及计算机技术领域，具体涉及一种数据处理方法、装置、电子设备及计算机可读存储介质。

背景技术

目前，虚拟游戏通常包括能够使玩家在游戏场景中建设、管理、修改各种建筑的玩法。在该类型游戏中，通常在终端上仅显示距离玩家所操作的虚拟角色很近的建筑。

当期望在终端上显示距离玩家所操作的虚拟角色较远的建筑时，由于建造类游戏的游戏场景中所包含的建筑的数量级非常之高，并且每个建筑对应的数据量也较高，这将会导致渲染显示时需要同步的数据量非常之高，产生严重的空间占用，带来极大的性能消耗。

发明内容

本申请提供了一种数据处理方法、装置、电子设备及计算机可读存储介质，能够在不增加性能消耗的情况下，为玩家呈现游戏场景中较近的建筑和较远的建筑。具体方案如下：

第一方面，本申请实施例提供了一种数据处理方法，所述包括：

获取第一虚拟角色在游戏场景中所处的目标场景区域，所述游戏场景包括多个场景区域；

从所述多个场景区域中确定与所述目标场景区域之间的距离小于或者等于第一距离的第一场景区域，以及确定与所述目标场景区域之间的距离大于所述第一距离的第二场景区域；

针对所述目标场景区域和所述第一场景区域中的第一建筑部件，获取所述第一建筑部件对应的第一建造部件数据，所述第一建造部件数据包括所述第一建筑部件对应的第一模型以及针对所述第一模型的渲染细节数据；

针对所述第二场景区域中的多个第二建筑部件，获取所述第二建筑部件对应的第二建造部件数据，所述第二建造部件数据包括合批模型，所述合批模型为基于至少一个所述第二建筑部件的修改数据对所述多个第二建筑部件进行合批得到的结果；

根据所述第一建造部件数据和所述第二建造部件数据分别渲染显示所述第一建筑部件和多个所述第二建筑部件。

第二方面，本申请实施例提供了一种数据处理装置，所述装置包括：

第一获取单元，用于获取第一虚拟角色在游戏场景中所处的目标场景区域，所述游戏场景包括多个场景区域；

第一确定单元，用于从所述多个场景区域中确定与所述目标场景区域之间的距离小于或者等于第一距离的第一场景区域，以及确定与所述目标场景区域之间的距离大于所述第一距离的第二场景区域；

第二获取单元，用于针对所述目标场景区域和所述第一场景区域中的第一建筑部件，获取所述第一建筑部件对应的第一建造部件数据，所述第一建造部件数据包括所述第一建筑部件对应的第一模型以及针对所述第一模型的渲染细节数据；

第二确定单元，用于针对所述第二场景区域中的多个第二建筑部件，获取所述第二建筑部件对应的第二建造部件数据，所述第二建造部件数据包括合批模型，所述合批模型为基于至少一个所述第二建筑部件的修改数据对所述多个第二建筑部件进行合批得到的结果；

渲染显示单元，用于根据所述第一建造部件数据和所述第二建造部件数据分别渲染显示所述第一建筑部件和多个所述第二建筑部件。

第三方面，本申请还提供了一种电子设备，包括：

处理器；以及

存储器，用于存储数据处理程序，该电子设备通电并通过所述处理器运行该程序后，执行如第一方面所述的方法。

第四方面，本申请实施例还提供了一种计算机可读存储介质，存储有数据处理程序，该程序被处理器运行，执行如第一方面所述的方法。

与现有技术相比，本申请具有以下优点：

本申请提供的数据处理方法，包括：获取第一虚拟角色在游戏场景中所处的目标场景区域，游戏场景包括多个场景区域；从多个场景区域中确定与目标场景区域之间的距离小于或者等于第一距离的第一场景区域，以及确定与目标场景区域之间的距离大于第一距离的第二场景区域；针对目标场景区域和第一场景区域中的第一建筑部件，获取第一建筑部件对应的第一建造部件数据，第一建造部件数据包括第一建筑部件对应的第一模型以及针对第一模型的渲染细节数据；针对第二场景区域中的多个第二建筑部件，获取第二建筑部件对应的第二建造部件数据，第二建造部件数据包括已烘焙的合批模型或未烘焙的合批模型，合批模型为基于至少一个第二建筑部件的修改数据对多个第二建筑部件进行合批得到的结果；根据第一建造部件数据和第二建造部件数据，在控制第一虚拟角色的第一终端上分别渲染显示第一建筑部件和多个第二建筑部件。

可见，本申请提供的数据方法，游戏场景包括多个场景区域，并且，根据多个场景区域与第一虚拟角色所处的目标场景区域之间的距离，对第一场景区域的第一建筑部件和第二场景区域中的第二建筑部件分别使用不同的数据进行渲染。对于与第一虚拟角色的距离较近的目标场景区域和第一场景区域，对应的第一建筑部件的建造部件数据，由于第一建造部件数据中包括第一建筑部件对应的第一模型以及针对第一模型的渲染细节数据，因此第一建造部件数据用于生成细化的第一建筑部件，这样，对于距离第一虚拟角色较近的第一场景区域和目标场景区域，可以通过第一建造部件数据生成细化的第一建筑部件；对于与第一虚拟角色的距离较远的第二场景区域，加载第二场景区域中第二建筑部件对应的第二建造部件数据，由于第二建造部件数据包括合批模型，这样，根据第二建造部件可以生成仅具有模型的粗粒度的第二建筑部件。可见，上述方法中对于距离第一虚拟角色较近的建筑部件，生成细化的建筑部件，对于距离第一虚拟角色较远的建筑部件，本申请通过获取预先生成的合批模型或基于玩家操作实时生成的合批模型进行渲染，即本申请在渲染之前提前进行了烘焙处理，从而可以有效降低大世界游戏客户端的计算压力，从而降低了游戏的卡顿问题。因此，本申请提供的数据处理方法，能够在不增加性能消耗的情况下，在大世界的游戏场景中同步用于渲染对应的建筑部件的数据，进而为玩家呈现游戏场景中较近的建筑和较远的建筑。

附图说明

图1是本申请实施例提供的游戏处理方法的系统架构图；

图2是本申请实施例提供的数据处理方法中以场景区域为单位进行数据同步的示意图；

图3是本申请实施例提供的数据处理方法中微服务平台的架构图；

图4-1～图4-4是本申请实施例提供的数据处理方法中的数据交互细节的流程图；

图5本申请提供的数据处理方法的流程图；

图6是本申请实施例提供的数据处理方法中目标区域的一例的示意图；

图7是本申请实施例提供的数据处理装置的一例的结构框图；

图8是本申请实施例提供的电子设备的一例的结构框图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

需要说明的是，本申请的权利要求书、说明书及附图中的术语“第一”、“第二”、“第三”等是用于区别类似的对象，并不用于描述特定的顺序或先后次序。这样使用的数据在适当情况下是可以互换的，以便于本文所描述的本申请的实施例，能够以除了在本文图示或描述的内容以外的顺序实施。此外，术语“包括”、“具有”以及他们的变形形式，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在详细说明本申请的实施方式之前，首先对对现有技术进行进一步说明。

在建造类游戏中，为了能够向玩家呈现大世界中的建筑，通常是根据玩家所操作的虚拟角色当前所处的位置，计算得到该虚拟角色周围九宫格的索引，并创建对应的数据同步对象，使用property(属性)同步机制来将周围九宫格内的建造部件数据同步并显示到玩家所持有的终端的显示界面上。

然而，上述方案存在以下技术问题：

1、上述方案中所同步的数据为玩家周围九宫格中的建造部件数据，九宫格外的距离玩家较远的建筑无法呈现给玩家。

2、property同步机制中，property系统需要对每个字段的数据进行额外的封装，以确保数据的正确性和一致性，这种封装可能会增加系统的复杂性，降低系统的效率，并且需要消耗大量的计算资源。并且，在建造类游戏中，数据量通常非常大，可能会达到上千数量级，在这种情况下，使用property系统可能会导致存储和同步成本非常高。例如，如果每个物体都有许多属性，那么需要存储和同步的数据量可能会非常大，这可能会对系统性能和网络带宽造成压力。同时，在建造类游戏中，数据结构可能会随着时间的推移而发生变化。如果使用property系统，那么可能需要频繁地修改和更新系统代码，以适应数据结构的变化。这可能会增加系统的复杂性，降低系统的可维护性，并且需要消耗大量的时间和精力。

基于上述原因，为了能够在不增加性能消耗的情况下，在大世界的游戏场景中同步用于渲染对应的建筑部件的数据，从而为玩家呈现游戏场景中较近的建筑和较远的建筑，本申请第一实施例提供了一种数据处理方法，该方法应用于数据处理方法的系统，该系统可以包括客户端和服务端。

在介绍本申请提供的数据处理方法之前，以下先结合图1、图2以及图3介绍本申请实施例提供的数据处理方法的系统架构，并结合图4介绍本申请实施例提供的数据处理方法中的数据交互细节。

如图1所示，本申请实施例提供的游戏处理方法的系统架构中包括终端110和服务端11。其中，终端10中可以包括多个终端，例如第一终端、第二终端、……第N终端，服务器11中包括游戏服务器12和服务节点15，其中，游戏服务器12中包括第一分线服务器3和主线服务器14，第一分线服务器3中包括多个阜宁县服务器，例如，第一分线服务器、……第N分线服务器。终端10通过网络与游戏服务器12相互连接，第一分线服务器3通过网络与主线服务器14相互连接，主线服务器14通过网络与服务节点15相互连接，服务节点15通过网络与终端10相互连接。

其中，游戏服务器是为客户端提供计算、存储等功能的服务器设备，可以是独立的物理服务器，也可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。

游戏服务器中的分线服务器用于分布存储多个场景区域的建造部件数据，一个场景区域的建造部件数据以场景区域为单位存储于一个分线服务器中，一个分线服务器中可以存储多个场景区域的建造部件数据。

游戏服务器中的主线服务器用于同步所述多个分线服务器中的进行建造操作的场景区域的建造部件数据，并将预设时长内每一个进行建造操作的场景区域的建造部件数据进行整合，整合后的建造部件数据用于向终端同步，以使终端基于同步数据渲染显示。

服务节点用于从主线服务器同步整合后的建造部件数据，并向终端同步整合后的建造部件数据。

终端是具有计算硬件的任何设备，能够支持和执行各应用程序。终端包括但不限于台式电脑、笔记本电脑、手机、平板电脑、服务器等。终端可以具有用于感测和获得用户通过在一个或者多个触控显示屏的多个点执行的触摸或者滑动操作的输入的一个或者多个多触敏屏幕，终端还可以与键盘和/或鼠标和/或游戏手柄等相连接，使得用户能够通过键盘和/或鼠标和/或游戏手柄进行界面操作。

如图2所示，是本申请实施例提供的数据处理方法中以场景区域为单位进行数据同步的示意图。终端10中的第一终端和第二终端针对场景区域01中的建筑部件进行建造操作，则存储场景区域01的第一分线服务器更新场景区域01中的建造部件数据，并将更新后的建造部件数据发送至主线服务器14，主线服务器14将预设时长内场景区域01的建造部件数据进行整合，并将整合后的建造部件数据发送至服务节点15，以使得主线服务器15向能够呈现场景区域01中建筑部件的终端同步场景区域01对应的数据。

需要说明的是，对于每一场景区域，可以设置两种数据，其一是用于呈现具有细节的建筑部件的建造部件数据，其二是用于呈现不具有细节的建筑部件的合批模型。因此，本申请中针对可以被玩家进行建造操作的场景区域中的建筑部件，设置有在线合批的计算节点，通过在线合批的计算节点对可以被玩家进行建造操作的场景区域中的建筑部件的建造部件数据进行合批计算。

如图3所示，是本申请实施例提供的数据处理方法中微服务平台的架构图。微服务平台16中包括计算节点17、版本管理服务器18以及存储服务器19，其中存储服务器19包括两种服务器，其一是数据结构服务器20，其二是文件服务器21。

在服务节点15接收到场景区域01的建筑部件的整合后的建造部件数据时，将该整合后的建造部件数据发送至计算节点17，计算节点17用于在版本管理服务器18中更新场景区域01对应的建造部件数据，并对整合后的建造部件数据进行合批计算，得到合批模型，在合批模型对应的数据量小于预设数据量的情况下，将合批模型存储至数据结构服务器20中，在合批模型对应的数据量小于预设数据量的情况下，将合批模型存储至文件服务器21中。服务节点15通过网络从存储服务器19中拉取合批模型。

如图4-1～图4-4所示，是本申请实施例提供的数据处理方法中的数据交互细节的流程图，包括以下步骤S001～S019。

其中，图4-1包括步骤S001～步骤S006：

步骤S001：终端10接收针对建筑部件1进行的建造操作；

步骤S002：终端10上，根据进行建造操作的建筑部件1的中心位置坐标，确定该建筑部件所属的场景区域1；

步骤S003：终端10向存储场景区域1的数据的第一分线服务器发送针对建筑部件1进行的建造操作；

步骤S004：第一分线服务器更新建筑部件1对应的建造部件数据；

步骤S005：第一分线服务器向主线服务器14同步建筑部件1对应的建造部件数据；

步骤S006：主线服务器14整合预设时长内场景区域1中的建造部件数据，得到场景区域1的整合数据。

图4-2包括步骤S007～步骤S012：

步骤S007：主线服务器14将场景区域1的整合数据同步至服务节点15；

步骤S008：服务节点15将场景区域1的整合数据同步至计算节点16；

步骤S009：计算节点16更新版本管理服务器所存储的场景区域1的数据；

步骤S010：计算节点16对场景区域1的整合数据进行合批计算，得到合批模型；

步骤S011：当合批模型对应的数据量小于预设数据量时，计算节点16将合批模型存储至数据结构服务器20；

步骤S012：当合批模型对应的数据量大于或等于预设数据量时，计算节点16将合批模型存储至文件服务器21。

图4-3包括步骤S013～步骤S015：

步骤S013：主线服务器14向与场景区域1之间的距离小于第二距离的虚拟角色所对应的附近终端广播建筑部件进行建造操作的消息以及该建造操作的操作时刻；

步骤S014：附近终端比较操作时刻和附近终端上最近一次更新场景区域1中的建造部件数据的所响应的建造操作的最近操作时刻；

步骤S015：在操作时刻大于最近操作时刻的情况下，附近终端中与场景区域1之间的距离小于或者等于第一距离的虚拟角色的终端1从服务节点15上拉取场景区域1的建造部件数据，与场景区域1之间的距离大于第一距离的虚拟角色的终端2从服务节点15上拉取场景区域1的合批模型。

图4-4包括步骤S016～步骤S019：

步骤S016：服务节点15从数据结构服务器20或者文件服务器21上拉取场景区域1的合批模型；

步骤S017：服务节点15向终端1发送场景区域1的建造部件数据；

步骤S018：在拉取到场景区域1的合批模型的情况下，服务节点15向终端2发送场景区域1的合批模型，在未拉取到的情况下，服务节点15向终端2发送场景区域1中的建筑部件对应的原始模型；

步骤S019：终端1根据拉取到的建造部件数据渲染显示场景区域1中具有细节的建筑部件；终端2根据拉取到的场景区域1的合批模型或者场景区域1中建筑部件对应的原始模型渲染显示不具有细节的建筑部件。

需要说明的是，图4-3中的步骤S013和图4-2中的步骤S008没有执行上的先后顺序，步骤S013可以在步骤S008之前或者之后执行。

以下，结合图5介绍本申请实施例提供的数据处理方法。

如图5所示，本申请提供的数据处理方法包括以下步骤S10～步骤S50。步骤S10～步骤S50可以应用于数据处理方法的系统中的客户端侧。

步骤S10：获取第一虚拟角色在游戏场景中所处的目标场景区域，所述游戏场景包括多个场景区域。

本申请中第一虚拟角色在游戏场景中所处的目标场景区域可以通过第一虚拟角色在大世界中所处的位置来确定，一个场景区域中可以包含多个位置。

第一虚拟角色在大世界中所处的位置可以由世界坐标来表示，世界坐标是游戏中的基本坐标系，所有游戏元素的位置和方向都可以用世界坐标来描述。在游戏中，虚拟角色和虚拟物体可以通过改变对应的世界坐标来实现在游戏场景中的移动。可以理解的，除了世界坐标，游戏中还可能使用其他坐标系，例如，角色坐标系、摄像机坐标系等。角色坐标系通常以虚拟角色为中心，摄像机坐标系通常以摄像机为中心。

本申请中，第一虚拟角色为虚拟游戏中由玩家操作的虚拟角色，虚拟角色是指在文学艺术作品中塑造出来的具有个性化特征的形象综合表达，通常情况下，虚拟角色为现实中不存在的角色，包括电视剧、电影、漫画、游戏中的至少一个创作性作品中虚构的角色。

在本申请实施例中，玩家可以使用终端操作位于虚拟游戏的游戏场景中的虚拟角色进行游戏行为，该游戏行为包括但不限于：对建筑进行拆除、对建筑进行重建、对建筑进行调整、调整身体姿态、爬行、步行、跑步、跳跃、驾驶、拾取、移动、疾跑、中的至少一种。

在实际应用中，虚拟游戏是指根据游戏应用需求而开发的应用程序，虚拟游戏的类型可以包括但不限于以下至少之一：二维(Two Dimension，二维)游戏应用、三维(ThreeDimension，三维)游戏应用、虚拟现实(Virtual Reality，VR)游戏应用、增强现实(Augmented Reality，AR)游戏应用、混合现实(Mixed Reality，MR)游戏应用。在本申请实施例中，虚拟游戏可以是多人在线战术竞技游戏(Multiplayer Online Battle ArenaGames，简称Moba)、多人在线角色扮演游戏(Multiplayer Online Role-Playing Game，简称MMORPG)等应用程序中的任意一种。

在本申请实施例中，虚拟游戏为建造类游戏或者具有建造功能的虚拟游戏，能够使得玩家在虚拟游戏中建设、管理、修改各种建筑。

游戏场景为虚拟游戏大世界对应的全部游戏场景，游戏场景为进行游戏的虚拟角色提供了可以用于进行游戏行为的虚拟空间。

本申请中游戏场景包括多个场景区域，可以理解为游戏场景的场景地面预先被划分为了多个场景区域，多个场景区域可以是区域尺寸相同的场景区域，也可以是区域尺寸不同的场景区域，各个场景区域之间互不交叠，场景区域可以是圆形、三角形、矩阵、不规则图形等，本申请对此并不限定。

步骤S20：从所述多个场景区域中确定与所述目标场景区域之间的距离小于或者等于第一距离的第一场景区域，以及确定与所述目标场景区域之间的距离大于所述第一距离的第二场景区域。

步骤S20用于确定距离第一虚拟角色较近的第一场景区域以及确定距离第一虚拟角色较远的第二场景区域。

本申请中，目标场景区域与场景区域之间的距离具体可以是目标场景区域的区域中心与场景区域的区域中心的距离，还可以是目标场景区域的各个位置点与场景区域中各个位置点之间的距离中的最大距离，本申请对此不具体限定。

这样，针对第一虚拟角色，确定出了距离该第一虚拟角色较近的第一场景区域，和距离该第一虚拟角色较远的第二场景区域。为了与现实世界中的视野呈现相一致，针对第一场景区域中的建筑，可以呈现具有各个细节、精致的建筑，针对第二场景区域中的建筑，可以呈现粗略的、仅具有轮廓的建筑。

步骤S30：针对所述目标场景区域和所述第一场景区域中的第一建筑部件，获取所述第一建筑部件对应的第一建造部件数据，所述第一建造部件数据包括所述第一建筑部件对应的第一模型以及针对所述第一模型的渲染细节数据。

建筑部件是指建筑中的各种组成部分，通常包括：墙体、楼板、梁、柱、楼梯、阳台、屋面、门窗等。本申请中第一场景区域中的第一建筑部件为第一场景区域中所包含的所有建筑部件，第一建筑部件可以是一个虚拟建筑的部分建筑部件，也可以是一个虚拟建筑的全部建筑部件，也即，一个虚拟建筑可能占用一个场景区域，也可能占用多个场景区域。

可以理解的，本申请中第一建筑部件包括目标场景区域和第一场景区域中的建筑，第一建筑部件可以是一个建筑部件，也可以是多个建筑部件(本申请中多个指两个或者两个以上)，本申请对于一个区域场景中所包含的建筑部件的数量不做具体限定。

步骤S30中针对第一建筑部件获取了对应的第一建造部件数据，第一建造部件数据包括第一建筑部件对应的第一模型以及针对第一模型的渲染细节数据，第一模型可以用于指示第一建筑部件的结构框架，针对第一模型的渲染细节数据可以用于对具有一定的结构框架的第一建筑部件增添建筑细节，因此，第一建筑部件对应的建造部件数据可以用于生成细化后的第一建筑部件。

具体的，针对第一模型的渲染细节数据可以包括但不限于以下至少一种：颜色数据、法线数据、纹理数据、材质数据、第一建筑部件中各部位对应的位置数据、刚体组件数据、特效数据、动画数据。其中，颜色数据可以用于指示第一建筑部件所具有的颜色，颜色数据可以是对应的颜色贴图；法线数据可以用于指示第一建筑部件对应的凹凸感，法线数据可以是对应的法线贴图；纹理数据可以是对应的纹理贴图，纹理数据赋予到第一建筑部件表面，可以提升第一建筑部件的真实感和视觉效果；第一建筑部件中各部位对应的位置数据可以包括各部位的移动参数、旋转参数、缩放参数以及各部位之间的连接信息。刚体组件数据用于描述一个物体物理特性的数据，刚体组件通常是一个物理模拟对象的组成部分，它包含了一些参数和属性，用于控制物体的行为和运动。

这样，针对距离第一虚拟角色较近的目标场景区域和第一场景区域中的第一建筑部件，获取了用于生成细化的第一建筑部件的完整的第一建造部件数据，以使得在后续步骤中根据第一建筑部件对应的第一建造部件数据生成细致的、包括各个建筑细节的第一建筑部件。

步骤S40：针对所述第二场景区域中的多个第二建筑部件，获取所述第二建筑部件对应的第二建造部件数据，所述第二建造部件数据包括合批模型，所述合批模型为基于至少一个所述第二建筑部件的修改数据对所述多个第二建筑部件进行合批得到的结果。

在本申请中，建筑部件均以场景区域为单位进行计算。

可以理解的，上述第一建造部件数据为用于生成细致的包括建筑细节的数据，因此，第一建造部件数据的数据量通常较大。本申请中，为了能够有效的降低渲染过程中导致的性能消耗，并且降低终端上的数据占用，针对距离第一虚拟角色较远的第二场景区域中的第二建筑部件，可以生成较为粗略的、展示对应的轮廓的第二建筑部件。

具体的，第二建筑部件对应的第二建筑部件数据可以是多个第二建筑对应的合批模型，这样，根据多个第二建筑对应的合批模型生成粗略的第二建筑部件。

需要说明的是，烘焙是一种将复杂的计算和渲染过程预先计算并存储起来，以便在运行时快速调用的技术。在游戏开发中，烘焙通常用于优化模型的渲染性能。

合批是指将多个模型合并成一个大的模型，以减少渲染开销的技术。在游戏开发中，合批可以显著提高渲染性能，尤其是在处理大量模型和复杂场景时。本申请中第二建造部件数据中所包括的合批模型具体可以是已烘焙的合批模型。

已烘焙的合批模型是指已经使用烘焙技术进行了优化的合批模型。在这种情况下，模型的光照、阴影和其他复杂的视觉效果已经被预先计算和存储起来，因此在运行时只需要简单地调用这些数据即可。这可以大大减少渲染的计算量，提高渲染性能。

未烘焙的合批模型是指没有使用烘焙技术进行优化的合批模型。在这种情况下，模型的所有视觉效果都需要在运行时实时计算和渲染，这会消耗大量的计算资源和时间，降低渲染性能。

需要说明的是，本步骤中的合批模型为预先生成的合批模型或基于玩家操作实时生成的合批模型，也即，本申请在渲染之前进行了烘培处理。

在一种可选的实施方式中，为了降低渲染时的性能消耗，可以将已烘培的合批模型作为第二建筑部件数据。这样通过一个渲染批次就可以完成对多个第二建筑部件的渲染，对于客户端性能来说，建筑部件合批后，渲染需要的绘制指令(drawcall)大大减少，并且所渲染的面数也大为降低，有效地降低了渲染时的性能消耗以及数据的空间占用。

绘制指令是指CPU向GPU发出的绘制指令，在图形渲染中，CPU将图形数据传输到GPU后，GPU需要根据CPU的指令来渲染图形。每次GPU处理的绘制指令都称为DrawCall。

上述至少一个第二建筑部件的修改数据可以是在玩家的修改操作下产生的数据，该修改操作例如可以包括但不限于针对至少一个第二建筑部件的拆除操作、增加操作、修改部件操作等中的一个或者多个。

这样，针对距离第一虚拟角色较远的第二场景区域中的第二建筑部件，获取了对应的用于生成粗略的第二建筑部件的第二建筑部件数据，以使得在后续步骤中根据第二建筑部件对应的第二建筑部件数据生成粗糙的、对应的数据量较小的第二建筑部件。

步骤S50：根据所述第一建造部件数据和所述第二建造部件数据分别渲染显示所述第一建筑部件和多个所述第二建筑部件。

步骤S50用于根据第一建筑部件对应的第一建造部件数据和第二建筑部件对应的第二建筑部件数据在控制第一虚拟角色的第一终端的显示界面上进行最终呈现。可以理解的，第一建筑部件呈现在距离第一虚拟角色较近的目标场景区域和第一场景区域中，第二建筑部件呈现在距离第一虚拟角色较远的第二场景区域中。

这样，在第一虚拟角色处于游戏场景中时，可以避免加载数据量较大的完整数据，即可在大世界的游戏场景中同时呈现距离较近的区域内的建筑部件以及距离较远的建筑部件，降低了性能消耗以及数据的空间占用，并且各建筑部件的呈现符合真实世界中建筑的呈现。

本申请提供的数据处理方法，包括：获取第一虚拟角色在游戏场景中所处的目标场景区域，游戏场景包括多个场景区域；从多个场景区域中确定与目标场景区域之间的距离小于或者等于第一距离的第一场景区域，以及确定与目标场景区域之间的距离大于第一距离的第二场景区域；针对目标场景区域和第一场景区域中的第一建筑部件，获取第一建筑部件对应的第一建造部件数据，第一建造部件数据包括第一建筑部件对应的第一模型以及针对第一模型的渲染细节数据；针对第二场景区域中的多个第二建筑部件，获取第二建筑部件对应的第二建造部件数据，第二建造部件数据包括已烘焙的合批模型或未烘焙的合批模型，合批模型为基于至少一个第二建筑部件的修改数据对多个第二建筑部件进行合批得到的结果；根据第一建造部件数据和第二建造部件数据，在控制第一虚拟角色的第一终端上分别渲染显示第一建筑部件和多个第二建筑部件。

可见，本申请提供的数据方法，游戏场景包括多个场景区域，并且，根据多个场景区域与第一虚拟角色所处的目标场景区域之间的距离，对第一场景区域的第一建筑部件和第二场景区域中的第二建筑部件分别使用不同的数据进行渲染。对于与第一虚拟角色的距离较近的目标场景区域和第一场景区域，对应的第一建筑部件的建造部件数据，由于第一建造部件数据中包括第一建筑部件对应的第一模型以及针对第一模型的渲染细节数据，因此第一建造部件数据用于生成细化的第一建筑部件，这样，对于距离第一虚拟角色较近的第一场景区域和目标场景区域，可以通过第一建造部件数据生成细化的第一建筑部件；对于与第一虚拟角色的距离较远的第二场景区域，加载第二场景区域中第二建筑部件对应的第二建造部件数据，由于第二建造部件数据包括合批模型，这样，根据第二建造部件可以生成仅具有模型的粗粒度的第二建筑部件。可见，上述方法中对于距离第一虚拟角色较近的建筑部件，生成细化的建筑部件，对于距离第一虚拟角色较远的建筑部件，本申请通过获取预先生成的合批模型或基于玩家操作实时生成的合批模型进行渲染，即本申请在渲染之前提前进行了烘焙处理，从而可以有效降低大世界游戏客户端的计算压力，从而降低了游戏的卡顿问题，本申请能够有针对性的对远景区域中的建筑部件进行预先烘焙，从而兼顾了游戏性能和显示效果。因此，本申请提供的数据处理方法，能够在不增加性能消耗的情况下，在大世界的游戏场景中同步用于渲染对应的建筑部件的数据，进而为玩家呈现游戏场景中较近的建筑和较远的建筑。

可选的，游戏场景可以通过以下方式划分为多个场景区域：按照预设的区域尺寸，将所述游戏场景对应的游戏地面划分为所述预设的所述区域尺寸的多个所述场景区域。

这样，按照预设的区域尺寸将游戏场景对应的游戏地面划分为了相同大小的多个场景区域，在这种情况下，场景区域可以是矩形，三角形、六边形等形状。

可选的，由于游戏场景通常情况下是一个比较大的虚拟空间，为了进一步降低渲染时的性能消耗以及降低数据的空间占用，本申请中具体可以针对上述第二场景区域中与目标场景区域之间的距离小于第二距离的第二场景区域，渲染较为粗略的建筑部件，第二距离大于第一距离。

因此，步骤S40可以包括以下步骤：

针对所述第二场景区域中与所述目标场景区域之间的距离小于第二距离的目标第二场景区域中的多个第二建筑部件，获取所述第二建筑部件对应的第二建造部件数据。

此外，针对与目标场景区域之间的距离大于第二距离的其他场景区域，可以不进行渲染显示，这是由于该其他场景区域与第一虚拟角色之间的距离已经足够远，在现实世界中，距离眼睛足够远的建筑可能会看不见，这样，既降低了渲染时的性能消耗，又降低了数据的空间占用，还提升了虚拟游戏中的真实感和拟真度。

在一种可选的实施方式中，本申请实施例提供的数据处理方法还可以包括以下步骤：

基于所述第一虚拟角色在游戏场景中所处的位置，在所述游戏场景中确定目标区域，所述目标区域包含所述多个场景区域。

本申请实施例中，可以获取当前第一虚拟角色在游戏场景中所处的位置，根据该位置来确定目标区域，目标区域中包括上述第一场景区域和第二场景区域。

在具体实施方式中，目标区域可以是圆形、矩阵、三角形等，在满足包括第一场景区域和第二场景区域的基础上，目标区域的区域大小可以根据游戏需求具体设计，本申请对于目标区域的形状和区域大小并不具体限定。

本申请中，游戏场景可以预先划分为多个网格，第一虚拟角色所处的目标场景区域为目标网格，上述步骤“在所述游戏场景中确定目标区域”可以通过以下方式实现：

接收配置数量；

以所述目标网格为正方形的中心；

基于所述中心以及所述配置数量的网格确定正方形的对角线；

基于所述对角线生成所述目标区域，所述目标区域为正方形。

需要说明的是，这里所说的配置数量用于表征虚拟角色为起点(不包含虚拟角色所处的格子)的网格数量，基于该配置数量以及预配置的单个网格的边长，从而确定待生成的正方形(目标区域)的对角线的长度。

在具体实现方式中，虚拟游戏的策划人员可以根据游戏需求以及终端上的显示需求设置一定的配置数量n，在获取了第一虚拟角色所处的目标网格后，可以将目标网格作为目标区域的中心，并根据配置数量n来确定正方形的对角线，从而生成形状为正方形的目标区域。

相应的，本申请中可以通过以下方式确定第一场景区域和第二场景区域：

从所述目标区域中确定网格中心与所述目标网格的网格中心之间的距离小于或者等于所述第一距离的第一网格，并将所述第一网格确定为所述第一场景区域；

从所述目标区域中确定网格中心与所述目标网格的网格中心的距离大于所述第一距离的第二网格，并将所述第二网格确定为所述第二场景区域。

如图6所示，是本申请实施例提供的数据处理方法中目标区域的一例的示意图。其中，第一虚拟角色606位于目标区域的中心，配置数量n为4，形成图6所示的目标区域，在该目标区域内，深灰的网格为第一场景区域和目标场景区域，白色的网格为第二场景区域。需要说明的是，图6中虚线框607内的网格即为配置数量的网格，在具体实现时，可以将配置数量作为第一虚拟角色所处目标网格在预设方向上对应的网格数量，预设方向可以目标网格边长的垂线且远离该边长的方向，基于配置数量4，可以得到第一虚拟角色所处网格在上下左右四个方向分别对应有4个网格，从而得到图6所示的目标区域。

可选的，本申请实施例提供的数据处理方法还可以包括以下步骤：

响应于针对所述游戏场景中目标位置的建造操作，将所述建造操作对应的建造信息发送至服务器中，以通过所述服务器将所述建造信息同步至第二虚拟角色对应的客户端，其中，所述第二虚拟角色为视野范围内包含所述目标位置的虚拟角色。

具体的，目标位置为游戏场景中的任一位置，当目标位置上发生了建造操作时，则可以将建筑操作对应的建筑信息发送至服务器，服务器可以向第二虚拟角色对于的客户端广播关于该目标位置进行了建造操作对应的操作信息。可以理解的，第二虚拟角色为视野范围内包括目标位置的虚拟角色。

可以理解的，由于建筑的复杂性，目标位置上可以包括一个建筑部件也可以包括多个建筑部件，因此，上述建筑操作可以是针对一个建筑部件的修改操作或者针对多个建筑部件的修改操作。

以下结合服务端中的系统架构来介绍本申请实施例提供的数据处理方法：

本申请中，服务端可以包括主线服务器和多个分线服务器，各所述分线服务器用于分布存储所述多个场景区域的建造部件数据；所述主线服务器用于同步所述多个分线服务器中的进行建造操作的场景区域的建造部件数据，并按预设时长间隔将每一个进行建造操作的场景区域内的建造部件数据进行整合，整合后的建造部件数据用于向终端同步，以使终端基于同步的整合后的建造部件数据渲染显示。

在具体实施方式中，主线服务器可以为游戏服务器中的任一服务器，通常，主线服务器可以是发生异常次数最少的游戏服务器，这样，可以有效降低主线服务器上所同步的所有分线服务器中的数据的丢失概率。

上述步骤“将所述建造操作对应的建造信息发送至服务器中”可以通过以下步骤实现：

将所述建造操作对应的建造信息发送至所述目标位置对应的目标分线服务器；

所述目标分线服务器将所述建造信息发送至所述主线服务器，所述主线服务器将所述建造信息发送至微服务平台；

所述微服务平台向第二虚拟角色对应的客户端发送通知，以通知所述第二虚拟角色对应的客户端获取所述建造信息。

存储所述目标建筑部件所在场景区域的建造部件数据的目标分线服务器可以是分线服务器中一个。

可以理解的，上述微服务平台向第二虚拟角色对应的客户端发送通知可以理解为：广播关于该目标位置进行了建造操作对应的操作信息，微服务平台可以理解为上述介绍中的服务节点和在线合批系统。

另外，一个场景区域中的建造部件数据可以以区域标识的形式打包存储于对应的游戏服务器中。区域标识可以理解为场景区域的唯一标识，场景区域于区域标识具有一一对应关系，通过一个区域标识可以确定唯一的场景区域，区域标识可以是字符串或者图片，本申请对此不做限定。

本申请实施例中，上述建造操作可以是针对目标位置上的目标建筑部件的修改操作，上述建造信息可以是基于修改操作获得的增量数据。

建造信息是指在游戏开发中，与建筑物相关的数据和信息。这些数据可能包括建筑物的外观、结构、功能、交互方式等方面的数据。

修改操作是指对目标建筑部件进行修改的操作，例如改变目标建筑部件的位置、旋转角度、大小等属性。在游戏开发中，玩家可能会通过在游戏中进行交互操作对目标建筑部件进行修改。

增量数据是指只包含新添加或更新的数据，而忽略已经存在的数据。在游戏开发中，为了提高性能和减少网络传输量，通常会采用增量数据的方式处理数据更新。当有新的数据需要添加或更新时，只需要发送这部分增量数据即可，而不是重新发送整个数据集。

因此，“建造信息是基于修改操作获得的增量数据”指的是，建造信息是由修改操作产生的新的或更新的数据组成的，这些增量数据可以用于更新游戏中的建筑信息，以实现建筑的变化和动态效果。

另外，本申请实施例提供的数据处理方法还可以包括以下步骤：

根据所述建造操作，确定所述目标建筑部件所在场景区域；

确定存储所述目标建筑部件所在场景区域的建造部件数据的各所述游戏服务器中的目标分线服务器；

根据所述建造信息更新所述目标分线服务器上存储的所述目标建筑部件所在场景区域的建造部件数据。

在玩家对某一个场景区域中的建筑部件进行第一建造操作时，可以确定该建筑部件所在的场景区域，具体可以是该建筑部件所在的场景区域的区域标识，通过区域标识确定管理该区域标识对应的场景区域的游戏服务器，这样，可以快速高效的更新该游戏服务中所存储的被玩家进行第一建造操作的建筑部件对应的建造部件数据，这样，实现了终端和游戏服务器之间的快速高效的数据同步。

这样，基于服务端所具有的系统架构，在根据所述建造信息更新所述目标分线服务器上存储的所述目标建筑部件所在场景区域的建造部件数据之后，可以由目标分线服务器将所述目标建筑部件所在场景区域的建造部件数据发送至所述主线服务器。

由于大世界对应的游戏场景很大，用一个数据节点去管理大世界对应的游戏场景中的所有数据会带来数据更新、存储、同步等各方面的压力，因此，在实际操作时，将整个游戏场景进行划分为多个场景区域，并将游戏场景中的数据以场景区域为单位分布式存储在各个游戏服务器中，通过多个游戏服务器以场景区域为单位来分担管理大世界对应的整个游戏场景中的数据，避免通过一个服务器管理大世界对应的游戏场景中的所有数据所带来的数据更新、存储、同步等各方面的压力。

可选的，上述步骤“确定所述目标建筑部件所在场景区域”可以通过以下步骤实现：

获取所述目标建筑部件对应的中心位置坐标；

根据所述中心位置坐标确定所述目标建筑部件所在场景区域。

本申请中可以根据进行修改操作的目标建筑部件对应的中心位置来确定该目标建筑部件所在的场景区域的区域标识，进而确定该目标建筑部件所在场景区域。

本申请中，通过对大世界的游戏场景划分为各个场景区域，具有以下优势：首先，各个场景区域中的建筑部件对应的建造部件数据分布式存储于各个分线服务器中，有效的减轻了服务器单点压力。其次，在数据初始化和数据库操作时，可以避免加载整个游戏场景中的所有建造部件数据，能够有效减少数据量，降低游戏所产生的性能消耗。另外，在分线服务器中的某一分线服务器宕机时，只会影响所宕机的分线服务器所管理的场景区域中的建造部件数据，游戏场景中不受所宕机的分线服务器管理的场景区域对应的建造部件数据将不会受到影响。

另外，由于主线服务器本质上为用于进行虚拟游戏中的游戏计算的游戏服务器，为了降低游戏服务器的压力，本申请中采用了微服务平台来对客户端进行数据同步，微服务平台中可以包括用于向终端同步建造部件数据的服务节点，所述主线服务器用于将每一个进行建造操作的场景区域对应的整合后的建造部件数据发送至所述服务节点。

基于此，本申请中，主线服务器可以将整合后的建造部件数据同步至所述服务节点，以使所述服务节点将所述整合后的建造部件数据向终端同步。

本申请中的步骤S30～S50具体可以是第一终端从服务节点上获取所整合的最新的目标场景区域和第一场景区域对应的第一建造部件数据以及第二场景区域中第二建筑部件对应的合批模型，这样，第一终端可以基于从服务节点上所获取的数据进行渲染显示。

在实际应用中，当游戏场景中的目标建筑部件进行了修改操作时，存储目标建筑部件所在场景区域的目标分线服务器对应更新目标建筑部件所在场景区域的建造部件数据，并向主线服务器同步更新后的目标建筑部件所在场景区域的建造部件数据。

由于一个场景区域中可能会被多个玩家进行建造操作，为了降低数据传输的次数，避免频繁的向服务节点同步数据，在主线服务器接收到更新后的目标建筑部件所在场景区域的建造部件数据时，可以不立即向服务节点转发，而是整合一个预设时长内目标建筑部件所在场景区域的建造部件数据，将目标建筑部件所在场景区域对应的一个预设时长的整合后的建造部件数据发送给服务节点，在服务节点中的数据更新完成后再向终端同步数据。

例如，每3分钟整合一次一个场景区域中的建造部件数据，在10：00am整合完成上一个周期，玩家a在10：01am对目标建筑部件所在场景区域1中屋顶某一个瓦进行了样式更换，玩家b在10：02am对场景区域1中屋顶添加了一个烟囱，则在10：03am将玩家a和玩家b对场景区域1中进行的建造操作产生的建造数据进行整合。

现有技术中，通常终端直接从游戏服务器上拉取建造数据，而游戏服务器通常包括多个服务器，在这种情况下，需要每个游戏服务器上都同步一份建造数据，从而产生了极大的性能消耗。

本申请提供的系统架构，终端只需要从服务节点上拉取来同步场景区域的建造部件数据，这样，只需要在服务节点上同步场景区域的建造部件数据即可，而无需在各个游戏服务器上同步场景区域的建造部件数据，并且终端无需从用于进行游戏内的数据计算的主线服务器上同步场景区域的建造部件数据，大大减小了主线服务器中的数据量，从而降低了主线服务器的压力，并且降低了数据同步带来的性能消耗。

另外，现有技术中基于property同步机制进行数据同步，在property同步机制中，有些字段是无用的空字段，本申请中以场景区域为单位进行数据同步，去除了冗余字段，进而降低了数据的空间占用。

在实际应用中，本申请中服务节点可以是uwsgi服务器(微服务器)

本申请中采用主线服务器单节点向服务节点同步建造数据还可以避免多节点同时连接服务节点所导致的数据不一致的问题。

在一种可选的实施方式中，终端上可以针对每一个场景区域分别记录有对应的目标建造操作对应的最近操作时刻，目标建造操作为所述终端上最近一次更新所针对的场景区域中的建造部件数据所响应的建造操作。

相应的，本申请实施例提供的数据处理方法还可以包括以下步骤：

向所述第二虚拟角色对应的客户端发送所述修改操作对应的操作时刻；

在所述操作时刻大于所述第二虚拟角色对应的客户端上所记录的所述目标建筑部件所在场景区域对应的所述最近操作时刻的情况下，根据所述第二虚拟角色所在场景区域与所述第三建筑部件所在场景区域之间的距离，在所述第二虚拟角色对应的客户端上渲染显示进行所述修改操作后的所述目标建筑部件。

因此，在具体实施方式中，针对每个场景区域，终端在接收主线服务器发送的某一个场景区域进行建造操作的操作信息时，可以还接收主线服务器发送的该场景区域进行建造操作的操作时刻。

在实际应用中，由于一个场景区域中可能发生了多次建造操作，这就造成主线服务器向终端所广播的操作信息不一定是最新一次的建造操作对应的操作信息，而终端上可能已经拉取了最新一次的建造操作后对应的建造部件数据，在这种情况下，终端去拉取数据并基于拉取的数据进行渲染会增加不必要的数据传输以及渲染操作，产生额外的性能消耗。

因此，本申请中，通过比较修改操作对应的操作时刻和终端上所记录的最近一次更新所响应的建造操作对应的最近操作时刻，在操作时刻大于最近操作时刻情况下，终端可以从服务节点上重新拉取数据进行渲染。

若所述操作时刻小于或者等于所述第二虚拟角色对应的客户端上所记录的所述目标建筑部件所在场景区域对应的所述最近操作时刻，则表示所述第二虚拟角色对应的客户端上当前渲染显示对应的同步数据要新于该操作时刻对应的数据，所述第二虚拟角色对应的客户端可以不从服务节点上拉取数据进行渲染。

另外，当一个场景区域每次发生建造操作时，主线服务器上也可以更新场景区域对应的最新操作时刻，在终端响应建造操作的操作信息从服务节点上拉取数据时，可以检测建造操作的操作时刻与最新操作时刻是否一致，在一致的情况下，终端可以从服务节点上重新拉取数据进行渲染。

可选的，在步骤“将所述建造操作对应的建造信息发送至所述目标位置对应的目标分线服务器”之前，本申请实施例提供的数据处理方法还可以包括以下步骤：

响应于针对所述游戏场景中目标位置的建造操作，在所述目标位置显示基于所述建造信息更新的建造部件；

检测所述建造操作是否符合预设的建造规则。

相应的，步骤“将所述建造操作对应的建造信息发送至所述目标位置对应的目标分线服务器”具体包括：

在所述第一建造操作符合所述预设的建造规则的情况下，将所述建造操作对应的建造信息发送至所述目标位置对应的目标分线服务器。

另外，步骤“所述微服务平台向第二虚拟角色对应的客户端发送通知”可以包括以下步骤：

在所述建造操作符合所述预设的建造规则的情况下，所述微服务平台向第二虚拟角色对应的客户端发送通知。

相应的，在所述建造操作不符合所述预设的建造规则的情况下，将所述目标位置显示的更新的建造部件恢复至更新之前的建造部件。

本申请中，为了使得玩家所进行的建造操作为合理的操作，可以针对建造操作预先设置建造规则，预设的建造规则用于约束玩家对建筑部件进行的建造操作，以使得建筑部件所进行的建筑操作符合常理。

需要说明的是，上述“响应于针对所述游戏场景中目标位置的建造操作，在所述目标位置显示基于所述建造信息更新的建造部件”可以是进行该建造操作的客户端上所进行的步骤，相应的，上述“在所述建造操作不符合所述预设的建造规则的情况下，将所述目标位置显示的更新的建造部件恢复至更新之前的建造部件”也是进行该建造操作的客户端上所进行的步骤。

在具体实现时，若进行该建造操作的终端为上述第一终端，可以响应于针对目标位置的建筑操作，在第一终端上的目标位置显示基于建造信息更新后的建造部件，之后，对建造操作进行合理性的判断，若建造操作合理，则根据建造信息在对应的目标分线服务器上更新对应的建造部件数据。

之后，分线服务器向主线服务器同步对应的建造部件数据，主线游戏服按照预设时长间隔整合一个场景区域对应的建造部件数据，并同步一个场景区域的整合后的建造部件数据到服务节点，在服务节点同步完成后再回调给主线服务器。

再之后，主线服务器可以向第二虚拟角色对应的客户端广播目标位置进行建造操作的操作信息，第二虚拟角色对应的客户端根据所控制的第二虚拟角色与该建筑部件所在场景区域之间的距离，从服务节点上拉取对应的数据进行渲染。

若服务端检测修改操作不合理，则可以向第一终端发送反馈信息，将第一终端上所呈现的进行了修改操作的目标建筑部件更改为进行修改操作之前的目标建筑部件。

上述对建造操作是否符合预设的建造规则的检测可以由主线服务器进行，也可以由分线服务器进行，也可以由终端进行，本申请对此并不具体限定。

以下对本申请实施例提供的数据处理方法中对一个场景区域中的建筑部件的建造部件数据进行合批进行介绍：

针对第二场景区域中的第二建筑部件，实际上并不需要完整的加载整个部件，并且精细度也无需很高。因此，本申请中可以对一个场景区域中的建筑部件的进行合批，来作为建筑物远景使用。通过把多个小模型合并成一个大模型，可以有效的降低资源使用情况，减少drawcall，并且基于合批后的大模型来进行减面等操作。

本申请中，为了能够使得处于距离目标位置所在的场景区域大于第一距离的场景区域中的虚拟角色的终端上，能够加载数据量较小的目标位置上的建筑，本申请中可以在目标位置发生了建造操作，微服务平台接收到建造信息后，还可以基于建造信息进行合批计算，获得合批模型。

本申请实施例中，微服务平台除了包括服务节点外，还可以包括用于合批计算的计算节点。

其中，所述服务节点用于接收所述主线服务器所发送建造信息，并将该建造信息发送给所述计算节点；所述计算节点用于接收所述服务节点所发送的建造信息，并基于建造信息进行合批计算，获得合批模型。

本申请中，可以对游戏场景中属于同一场景区域的建筑部件进行预先合批，得到各场景区域分别对应的合批模型。

另外，在一个场景区域内发生了建造操作后，可以对该场景区域对应的建筑部件进行在线合批。具体的，所述服务节点将所述场景区域中建筑部件的建造部件数据发送至所述计算节点；所述计算节点将同一个所述场景区域的建造部件数据进行合批计算，得到所述各所述场景区域分别对应的合批模型。

在具体实施方式中，对于游戏场景中每一个场景区域来说，都可以通过计算节点来对同一个场景区域中的建造部件数据进行合批计算，得到每一个场景区域分别对应的合批模型。对于每一个场景区域，其所对应的合批模型用于在与该场景区域之间的距离大于第一距离的虚拟角色所对应的客户端上渲染显示该场景区域中的建筑部件。

本申请中，场景区域中的建筑部件根据功能可以分为两类，一类是开发人员预先制作好的预制体建筑，另一类是玩家自由摆放的建筑。通常情况下，玩家无法对开发人员预先制作好的预制体建筑进行建造操作，玩家可以对玩家自由摆放的建筑进行建造操作。

在实际应用中，玩家自由摆放的建筑可能会发生建造操作，在一种可选的实施方式中，为了能够及时得到进行建造操作的场景区域中建筑部件的合批模型，本申请中上述计算节点可以具体用于在某一个场景区域中发生了建造操作时对建造操作对应的建造信息进行在线合批计算。

由于预制体建筑不可被玩家进行建造操作，因此，对于预制体建筑，其对应的合批模型将不发生变化，可以预先进行离线合批，得到对应的合批模型，在某一终端所控制的虚拟角色与所包含的建筑部件为预制体建筑的场景区域之间的距离大于第一距离且的情况下，可以根据该场景区域对应的离线的合批模型在该终端上渲染显示该场景区域中的建筑部件。

这样，针对所包含的建筑部件为玩家自由摆放的建筑的场景区域，通过上述的在线合批系统进行合批计算，以在场景区域中的建造数据发生变更时能够通过在线合批系统重新计算合批模型；针对所包含的建筑部件为预制体建筑的场景区域，通过预先进行离线合批得到对应的合批模型，从而无需进行实时计算，大大提升了游戏性能，以在终端存在显示合批模型的需求时根据预先离线合批所得到的合批模型进行渲染显示。

在一种可选的实施方式中，上述微服务平台还可以包括存储服务器和版本管理服务器；其中，所述存储服务器用于存储基于所述建造信息获得的合批模型或未合批的建造部件数据；所述版本管理服务器用于记录不同版本的建造部件数据。

因此，本申请中还可以包括以下步骤：

所述版本管理服务器根据所述建造信息，将所述目标位置所在的场景区域的建造部件数据进行更新。

本申请中版本管理服务器可以记录场景区域每一次进行的建造操作，并且通过版本控制技术对场景区域对应的建造部件数据进行版本管理和更新。以下，对版本管理服务器进行介绍：

版本控制，最主要的功能就是资源文件的存储并追踪资源文件的变更。可以将资源文件的变更时间、变更内容或者变更人员等信息记录下来。每一次资源文件的改变，资源文件的版本号都将增加。

在本实施例中，版本控制工具(即版本管理服务器)采用SVN版本控制系统。

在通过版本管理服务器将发生变化的场景区域的建造部件数据进行更新后，计算节点可以基于更新后的建造部件数据进行合批计算，计算完成的合批模型可以直接存储在上述计算节点上，也可以存储上述存储服务器上。

在一种可选的实施方式中，本申请实施例提供的数据处理方法还可以包括以下步骤：

所述服务节点从所述存储服务器上拉取所述合批模型，并根据数据拉取结果确定所述目标位置所在的场景区域对应的同步数据；

所述第二虚拟角色对应的客户端从所述服务节点上拉取所述同步数据，并基于所拉取的所述同步数据，在所述第二虚拟角色对应的客户端上渲染显示所述目标位置所在的场景区域中的建筑部件。

可以理解的，上述步骤中所述合批模型指的是对所述建造信息进行合批计算所获得的合批模型。

本申请中，计算节点进行合批计算后所得到的合批模型可以是二进制形式的数据，这样，存储在存储服务器中的场景区域对应的合批模型为二进制形式的数据。

由于存储服务器中可以存储每一次进行建造操作后的目标建筑部件所在场景区域对应的合批模型，为了使得附近终端所拉取的为最新数据，在进行数据拉取时，可以通过存储服务器上记录的目标建筑部件所在场景区域对应的合批模型所对应的操作时刻，来使得服务节点从所述存储服务器上拉取所述建造操作产生的所述建造信息进行合批计算后所获得的合批模型。

具体的，步骤“根据数据拉取结果确定所述目标位置所在的场景区域对应的同步数据”可以通过以下步骤实现：

在所述存储服务器中存储有合批模型的情况下，将所述合批模型确定为所述目标位置所在的场景区域对应的同步数据；

在所述存储服务器中未存储合批模型的情况下，将所述目标位置所在的场景区域中未合批的建造部件数据中的原始模型确定为所述目标位置所在的场景区域对应的同步数据。

在实际应用中，合批计算可能会耗费较长的时间，因此，在服务节点从存储服务器上拉取所述合批模型时，可能会出现合批计算还未计算完成进而未存储至存储服务器中的情况，在这种情况下，可以向服务节点返回一份保底数据，该保底数据可以是目标建筑部件所在场景区域中建筑部件数据中的原始模型，将该保底数据作为同步数据以向对应的附近终端同步，该对应的附近终端为第二虚拟角色中与所述目标建筑部件所在场景区域之间的距离大于所述第一距离的虚拟角色对应的终端。

在存储服务器中存储有所述合批模型的情况下，可以向服务节点发送所述合批模型，以向上述附近终端同步该合批模型。

本申请中，对于所包含的建筑部件为玩家自由摆放的建筑的场景区域，在该场景区域进行了建造操作时，数据流走向为：玩家进行建造操作→对应的分线服务器更新→主线服务器更新并整合→服务节点同步整合后数据→计算节点拉取整合后数据，并在版本管理服务器中本地更新→计算节点进行合批计算→计算完成后，存储在存储服务器中。

在一种可选的实施方式中，本申请中所述存储服务器可以包括用于存储对应的建造部件数据的数据量小于预设数据量的场景区域的数据结构服务器和用于存储对应的建造部件数据的数据量大于或者等于所述预设数据量的场景区域的文件服务器；因此，步骤“将所述合批模型发送至所述存储服务器”可以通过以下步骤实现：

在所述合批模型对应的数据量小于所述预设数据量的情况下，将所述合批模型发送并存储至所述数据结构服务器；

在所述合批模型对应的数据量大于或者等于所述预设数据量的情况下，将所述合批模型发送并存储至所述文件服务器。

本申请中服务节点和计算节点可以是go服务器，go服务器是指使用go语言编写的服务器程序。Go语言是一种由Google开发的编程语言，它具有高效、快速、安全、并发性强、开发效率高等特点，便于高效部署和维护，因此被广泛应用于服务器端开发。Go语言的并发性和高性能使得Go服务器可以轻松处理大量的并发请求，同时保持高性能和稳定性。Go服务器的开发和部署通常比较简单，因为Go语言具有自动垃圾回收机制，不需要手动管理内存，而且Go语言的编译器和运行时环境都比较轻量级，可以快速构建和部署服务器程序。

在具体实施方式中，在部署计算节点时，可根据配置文件开启多个节点以进行并行计算提高效率，在接收到合批计算的请求时，将该请求分配给当前负载最低的节点，以使得各个节点的负载相对均衡。

另外，由于大部分场景区域的数据变动较小，因此，合批计算的频率较低，这样，在终端拉取过某一个场景区域的合批数据后，在该场景区域没有数据变动的情况下，终端无需频繁的拉取该场景区域的数据，这样可以大大提高终端的性能。

本申请实施例中，可以通过以下方式获得合批模型：

获取并解析所述属于同一场景区域的建筑部件对应的蓝图文件，得到所述属于同一场景区域的建筑部件对应的建筑模型存储路径和位置数据；

确定所述属于同一场景区域的建筑部件对应的合批参数；

根据所述位置数据以及所述合批参数对所述建筑模型存储路径下所存储的建筑模型进行模型合批，得到所述属于同一场景区域的建筑部件对应的合批模型。

在进行合批计算时，本申请中可以先获取同一场景区域对应的建筑部件对应的蓝图文件，之后解析该蓝图文件，就可以得到属于同一场景区域的建筑部件的模型虚拟路径与位置数据，之后，可以将模型虚拟路径与位置数据写入到合批文件里，再设置对应的合批参数，合批参数例如可以包括但不限于在合批时对属于同一场景区域的建筑部件进行贴图尺寸调整的参数、对合批后模型进行不可见面剔除的第二参数等。

建筑部件的蓝图文件是指一种用于描述建筑结构和设计的文件，蓝图文件通常可以包含建筑部件的平面图、立面图、剖面图等信息，以及建筑部件的尺寸、材料、结构等详细设计数据。

所述建筑模型存储路径是游戏引擎的资源仓库的设定，虚拟游戏中所有的游戏资源都可以具有一个存储路径，通过.repe文件类型可以将存储路径映射到实际的仓库目录里，进而得到对应的游戏资源。因此，本申请中通过属于同一场景区域的建筑部件对应的建筑模型存储路径可以获取到开发人员所制作的对应的建筑模型。

所述位置数据是指属于同一场景区域的建筑部件所设置的在场景区域中所处位置对应的数据。

这样，通过位置数据和合批参数可以对所获取的属于同一场景区域的建筑部件对应的建筑模型进行模型合批，得到属于同一场景区域的建筑部件对应的合批模型，以使得终端在有需求的情况下可以快速使用属于同一场景区域的建筑部件对应的合批模型进行渲染显示，提升了渲染显示的效率。

需要说明的是，上述合批模型的获得方式不仅可以用于对玩家自由摆放的建筑进行合批计算，也可以用于对预制体建筑进行离线合批计算。针对玩家自由摆放的建筑，具体可以通过生成对应的蓝图文件，并通过解析蓝图文件进行合批计算，在玩家自由摆放的建筑进行了建造操作时，则对应更改蓝图文件，这样可以及时使用更改后的蓝图文件进行合批计算。针对预制体建筑，则可以直接使用原始的蓝图文件进行解析以及后续的合批步骤。

需要注意的是，以上获得合批模型的方式仅为本申请实施例提供的一种具体实现方式，本申请中计算节点还可以通过其他可以实现的方式获得合批模型，本申请对此并不具体限定。

在一种可选的实施方式中，为了使得合批模型更加具有真实感，本申请中还可以对合批模型赋予材质和贴图，因此，“根据所述第二建筑部件数据，渲染显示多个所述第二建筑部件”：

基于所述属于同一场景区域的建筑部件分别对应的材质数据确定为合批模型的目标材质数据；

基于所述属于同一场景区域的建筑部件分别对应的纹理贴图确定所述合批模型的目标贴图；

基于所述目标材质数据和所述目标贴图对所述合批模型进行渲染。

其中，材质是模型表面各可视属性的结合，可视属性例如可以包括表面的色彩、纹理、光滑度、透明度、反射率、折射率、发光度等；材质定义了组成该物体所用的表面类型。纹理贴图是指将带有颜色和其它信息的图像(图片)通过UV坐标映射到渲染物体的表面，这些图片将定义模型表面的各个属性。例如，可以使用一张木头的图片来为木制家具贴图，以模拟木头的质地。纹理贴图“贴”在物体表面可以提高物体的真实感和视觉效果。

在具体实施方式中，首先，可以对属于同一场景区域的建筑部件合并材质，其次，对属于同一场景区域的建筑部件合并纹理贴图，这样，得到合批模型的目标材质数据和合批模型的目标贴图。这样，终端在有需求的情况下可以快速基于目标材质数据和目标贴图对合批模型进行渲染显示，这样，终端上渲染显示的建筑部件更加具有真实感，可以提升玩家的游戏体验。

可选的，步骤“将所述属于同一场景区域的建筑部件对应的各纹理贴图合并为目标贴图”可以通过以下步骤实现：

获取各所述纹理贴图中的各颜色贴图；

从各所述颜色贴图中筛选得到存在差异的所述颜色贴图；

将所述存在差异的所述颜色贴图合并为所述目标贴图。

可以理解的，纹理贴图是一个包含了多种类型贴图的集合，其中包括颜色贴图，除了颜色贴图之外，纹理贴图还可以包含其他类型的贴图，例如法线贴图、金属度贴图、漫反射贴图、高光贴图、高度贴图、透明度贴图等。

其中，颜色贴图是一种用于模拟物体表面颜色的贴图，颜色贴图只包含一个颜色通道，用于描述物体表面的颜色信息。通常情况下，颜色贴图是一种彩色图像，其中，每个像素的颜色某个特定位置的颜色；法线贴图用于模拟物体表面的法线(即表面的向量)；金属度贴图用于模拟金属表面的纹理；漫反射贴图用于模拟物体表面的漫反射光(即来自各个方向的光线)；高光贴图用于模拟物体表面的高光。可以理解的，各种类型的贴图赋予到物体表面，可以使得物体表面具有较好的真实感以及视觉效果。

本申请中，由于使用某一场景区域对应的合批模型的前提是终端所控制的虚拟角色距离该场景区域较远，因此，可以仅合并颜色贴图即可，并且，由于不同的建筑部件所使用的颜色贴图可能相同，例如屋顶的多个瓦片对应的颜色贴图相同，多个柱子对应的颜色贴图相同，因此，本申请中为了降低离线合批的性能消耗，可以仅合批存在差异的颜色贴图。

在一种可选的实施方式中，合批参数中包括用于对各所述纹理贴图的尺寸进行约束的第一预设尺寸和用于对所述目标贴图的尺寸进行约束的第二预设尺寸，这样，在将各纹理贴图合并为目标贴图后，本申请实施例提供的数据处理方法还可以包括以下步骤：

对所述目标贴图中的各所述纹理贴图进行尺寸调整，以使得各所述纹理贴图的尺寸大于或者等于第一预设尺寸，且所述目标贴图的尺寸小于或者等于第二预设尺寸，得到调整后的所述目标贴图。

在具体实施方式中，可以根据所合并的纹理贴图的尺寸大小进行尺寸的调整，以使得目标贴图中的每张纹理贴图的尺寸大于或者等于都第一预设尺寸，但是当目标贴图对应的尺寸大于第二预设尺寸时，则可以相应的压缩纹理贴图的尺寸，将压缩后的纹理贴图重新排布到目标贴图中，以使得目标贴图的尺寸小于或者等于第二预设尺寸。

与此同时，将会生成属于同一场景区域的建筑部件对应的纹理贴图在目标贴图中的排布的位置映射，进而得到属于同一场景区域的建筑部件的顶点在目标贴图中的位置映射。这样，在将目标贴图赋予到合批模型时，可以根据属于同一场景区域的建筑部件的顶点在目标贴图中的位置映射将目标贴图赋予到合批模型，以使得目标贴图中的各纹理贴图能够合理的被“贴”在合批模型的模型表面。

在一种可选的实施方式中，所述合批参数中包括对合批后模型进行不可见面剔除的第一参数，步骤“根据所述位置数据以及所述合批参数对所述建筑模型存储路径下所存储的建筑模型进行模型合批，得到所述属于同一场景区域的建筑部件对应的合批模型”可以通过以下步骤实现：

根据所述位置数据和所述目标贴图对所述属于同一场景区域的建筑部件进行各顶点数据的合并，得到合并后的顶点数据；

根据所述合并后的顶点数据对所述建筑模型存储路径下所存储的建筑模型进行模型合批，得到所述属于同一场景区域的建筑部件的合批后模型；

根据所述第一参数对所述合批后模型进行不可见面的剔除，得到剔除了所述不可见面的所述属于同一场景区域的建筑部件的合批模型。

所述不可见面的剔除指的是将合批后模型中无法直接展示在终端上的面进行剔除。不可见面剔除(又称隐藏剔除)是一种优化技术，用于减少游戏中的渲染和计算开销。通常情况下，当不可见面剔除的精度越高，计算和渲染的开销将会越小。

可选的，本申请通过以下方式进行不可见面的剔除：

将所述合批后模型转换为由体素网格组成的体素化模型；

沿各方向对所述体素化模型进行深度检测，确定不可达的所述体素网格，所述不可达的所述体素网格所包含的面为不可见面；

将所述不可见面进行剔除，得到剔除了所述不可见面的所述属于同一场景区域的建筑部件对应的合批模型。

本申请中在得到合批后模型后，首先，可以对合批后模型进行体素化，将合批后模型转换为由体素网格组成的体素化模型，其次，沿着每个方向对体素化模型进行深度检测，把可以抵达的体素网格记录下来，最终可以过滤出每个方向都不可达的体素网格，最后，可以将每个方向都不可达的体素网格包含的面都剔除掉，得到剔除了不可见面的合批模型。

这样，通过对合批后模型进行不可见面的剔除，大大降低了计算和渲染时的性能开销。

可选的，所述位置数据包括所述属于同一场景区域的建筑部件的顶点在对应的部件坐标系中的位置坐标、法线向量以及用于指示所述属于同一场景区域的建筑部件在由所述属于同一场景区域的建筑部件所组成的建筑组合中的位置和方向的位置变换矩阵；步骤“根据所述位置数据和所述目标贴图对所述属于同一场景区域的建筑部件进行各顶点数据的合并，得到合并后的顶点数据”具体可以通过以下步骤实现：

根据所述位置变换矩阵，对所述属于同一场景区域的建筑部件的顶点在对应的部件坐标系中的位置坐标以及法线向量进行位置变换，得到所述属于同一场景区域的建筑部件的顶点在所述建筑组合中的位置坐标和法线向量；

修改所述属于同一场景区域的建筑部件的顶点对应的UV坐标数据，以使得修改后的UV坐标数据所指示的映射关系为对应的顶点在所述建筑组合中的位置坐标与在所述调整后的所述目标贴图中的所处位置之间的对应关系，得到所述属于同一场景区域的建筑部件的顶点对应的修改后的UV坐标数据；

将所述属于同一场景区域的建筑部件的顶点在所述建筑组合中的位置坐标和法线向量、以及所述属于同一场景区域的建筑部件的顶点对应的修改后的UV坐标数据确定为所述合并后的顶点数据。

本申请中，由于合批模型是用于远景呈现，不需要骨骼和蒙皮，因此进行的合批主要是修改顶点的位置数据、坐标数据以及法线数据。

所述位置变换矩阵(sub_transform)用于指示属于同一场景区域的建筑部件在由所述属于同一场景区域的建筑部件所组成的建筑组合中的位置和方向，位置变换矩阵开发人员设计蓝图建筑的时候已经确定，并记录在蓝图文件中。通常情况下，位置变换矩阵中包括属于同一场景区域的建筑部件在对应的建筑组合中的位移、旋转以及缩放等至少一方面的信息。

本申请中，通过位置变换矩阵可以将属于同一场景区域的建筑部件的顶点在对应的部件坐标系中的位置坐标和法线向量进行映射，最终得到属于同一场景区域的建筑部件的顶点在对应的建筑组合的坐标系下的位置坐标和法线向量。

本申请中可以通过上述得到的属于同一场景区域的建筑部件的顶点在目标贴图中的位置映射修改属于同一场景区域的建筑部件的顶点对应的UV坐标数据，以使得修改后的UV坐标数据所指示的映射关系从对应的顶点在建筑部件中的位置坐标与纹理贴图中的映射关系变更为对应的顶点在建筑组合中的位置坐标与在调整后的目标贴图中的所处位置之间的对应关系，得到属于同一场景区域的建筑部件的顶点对应的修改后的UV坐标数据。

这样，在得到了属于同一场景区域的建筑部件的顶点在所述建筑组合中的位置坐标和法线向量以及属于同一场景区域的建筑部件的顶点对应的修改后的UV坐标数据后，可以将其确定为合并后的顶点数据。

可选的，在得到合并后的顶点数据后，本申请中可以将属于同一场景区域的建筑部件的三角形索引和合并后的顶点数据合并为新的mesh数据(网格数据)。因此，步骤“根据所述合并后的顶点数据对所述建筑模型存储路径下所存储的建筑模型进行模型合批，得到所述属于同一场景区域的建筑部件的合批后模型”可以通过以下步骤实现：

获取所述属于同一场景区域的建筑部件对应的三角形面片的面片索引；

根据所述合并后的顶点数据以及所述面片索引所索引的三角形面片对所述建筑模型存储路径下所存储的建筑模型进行模型合批，得到所述属于同一场景区域的建筑部件的合批后模型。

Mesh数据通常是一个三维模型的顶点、面片和纹理等信息的集合，它可以用于创建游戏中的模型和贴图。在3D建模软件中，模型是由多个面片组成的，每个面片都是由多个三角形构成的。这些三角形是模型的基本组成单位，用于定义模型的形状和结构。模型的三角形面片的面片索引通常是以索引数组的形式存储的，每个索引对应模型中一个三角形。在渲染模型时，需要使用这些索引来确定每个三角形的位置和方向，以便进行光照和纹理贴图等处理。模型的三角形面片的面片索引通常是在建模过程中生成的，建模软件会根据模型的形状和结构，自动生成相应的索引。在游戏开发中，模型的三角形面片的面片索引通常是由3D建模软件生成的，然后通过游戏引擎进行加载和处理。

为了提高游戏的性能和用户体验，通常需要将属于同一场景区域的建筑部件的顶点和三角形面片的面片索引合并成一个新的mesh数据进行合批渲染，从而减少游戏的内存占用和绘制时间。因此，在顶点数据修改完成后，可以根据属于同一场景区域的建筑部件对应的三角形面片的面片索引和修改后的顶点数据生成新的mesh数据。

在实际应用中，很多建筑部件会使用循环贴图，例如草地、水面这种贴图，这就使得模型中的顶点可能被映射到贴图之外，则需要调整UV坐标，处理uv越界的情况。

因此，在步骤“将所述属于同一场景区域的建筑部件的顶点在所述建筑组合中的位置坐标和法线向量、以及所述属于同一场景区域的建筑部件的顶点对应的修改后的UV坐标数据确定为所述合并后的顶点数据”之前，本申请实施例提供的数据处理方法还可以包括以下步骤：

针对所述纹理贴图为循环贴图的所述属于同一场景区域的建筑部件，对所针对的所述属于同一场景区域的建筑部件的顶点对应的修改后的UV坐标数据进行调整，得到所针对的所述属于同一场景区域的建筑部件的顶点对应的调整后的UV坐标数据，以使得所针对的所述属于同一场景区域的建筑部件的顶点映射在所述目标贴图内。

相应的，步骤“将所述属于同一场景区域的建筑部件的顶点在所述建筑组合中的位置坐标和法线向量、以及所述属于同一场景区域的建筑部件的顶点对应的修改后的UV坐标数据确定为所述合并后的顶点数据”可以通过以下步骤实现：

将所述属于同一场景区域的建筑部件的顶点在所述建筑组合中的位置坐标和法线向量、以及所述属于同一场景区域的建筑部件的顶点对应的调整后的UV坐标数据确定为所述合并后的顶点数据。

循环贴图是一种特殊的纹理贴图，它可以在纹理的边缘进行无缝循环，以实现纹理的无缝重复。在游戏开发中，循环贴图可以用于创建无限大的游戏世界，例如草地、水面、天空等。但是，当模型的UV坐标超出纹理贴图的边界时，如果没有进行处理，可能会导致贴图出现边界锯齿或者纹理丢失等问题。

在具体实施方式中，为了处理UV越界的情况，通常可以将模型的UV坐标进行一些特殊处理。例如，可以将模型的UV坐标进行缩放和偏移，使其在纹理贴图的边界内。或者，可以将模型的UV坐标进行镜像和缩放，使其在纹理贴图的边界内。这些处理方法可以有效地解决UV越界的问题，从而提高游戏的性能和用户体验。

另外，对于一些非常大的三角形，比如屋顶或地基等，三角形顶点的UV跨度可能会超过1，这就使得进行UV映射将贴图赋予到模型上后导致贴图被拉伸，在这种情况下，还可以对UV坐标进行调整。但，合批模型是用于远景呈现，在UV跨度超过1时将贴图赋予到模型上后在远景上使用的效果通常不会对玩家造成视觉上较大的影响，因此，可以不对UV坐标进行调整。

性能方面，合批后的只有一个合批模型且只有颜色贴图，大大降低了drawcall的数量；此外也降低了视锥剔除的开销，在一些极限的情况下，比如鸟巢蓝图，它由4000多个相同的小柱子拼接而成，视锥剔除的开销很高，但是实际上毫无剔除的必要，使用合批模型可以极大的降低剔除的开销。除了这些方面，使用合批模型的好处还在于可以减少与服务端之间数据传输的数据量。合批之后服务端可以直接传输属于同一个场景区域的建筑部件对应的合批模型，不需要考虑一个场景区域中每一个建筑部件。

另外，对于少量需要动画等复杂表现的建筑部件，可以仍然使用完整的建造部件数据，绝大多数建筑部件都是静态的，极少一部分建筑部件比较特殊，属于动态的建筑，对于动态的建筑，即便距离较远也可以使用完整的建造部件数据，加载模型骨骼颜色物理等数据。

因此，步骤“针对所述第二场景区域中的多个第二建筑部件，获取所述第二建筑部件对应的第二建造部件数据”具体可以包括：

针对所述第二场景区域中的静态的多个第二建筑部件，获取所述第二建筑部件对应的包括所述合批模型的第二建造部件数据。

相应的，针对所述第二场景区域中的动态的多个第二建筑部件，可以获取包括多个第二建筑部件对应的第二模型以及针对第二模型的渲染细节数据的第二建筑部件数据，用于针对动态的第二建筑部件渲染显示的完整的具有建筑细节的第二建筑部件。

基于模型合批得到的某一个场景区域对应的合批模型后，当终端控制的虚拟角色距离该场景区域较远时(虚拟角色与该场景区域之间的距离大于第一距离)，则使用合批模型在终端上进行渲染显示，当终端控制的虚拟角色距离该场景区域较近时(虚拟角色与该场景区域之间的距离小于或者等于第一距离)，则使用包括对应的模型以及针对该模型的渲染细节数据在终端上进行渲染显示。这样，既可以为玩家呈现距离较近的场景区域中细致的建筑部件，又可以为玩家呈现距离较远的场景区域中不具有细节的建筑部件，另外，终端能够显示的建筑部件的数量得到了极大的提高，并且每个场景区域中可以容纳的建筑部件的数量也得到了极大的提高。

与本申请第一实施例提供的数据处理方法相对应的，本申请第二实施例还提供了数据处理装置，如图7所示，所述数据处理装置600包括：

第一获取单元601，用于获取第一虚拟角色在游戏场景中所处的目标场景区域，所述游戏场景包括多个场景区域；

第一确定单元602，用于从所述多个场景区域中确定与所述目标场景区域之间的距离小于或者等于第一距离的第一场景区域，以及确定与所述目标场景区域之间的距离大于所述第一距离的第二场景区域；

第二获取单元603，用于针对所述目标场景区域和所述第一场景区域中的第一建筑部件，获取所述第一建筑部件对应的第一建造部件数据，所述第一建造部件数据包括所述第一建筑部件对应的第一模型以及针对所述第一模型的渲染细节数据；

第二确定单元604，用于针对所述第二场景区域中的多个第二建筑部件，获取所述第二建筑部件对应的第二建造部件数据，所述第二建造部件数据包括合批模型，所述合批模型为基于至少一个所述第二建筑部件的修改数据对所述多个第二建筑部件进行合批得到的结果；

渲染显示单元605，用于第一建造部件数据和所述第二建造部件数据分别渲染显示所述第一建筑部件和多个所述第二建筑部件。

可选的，所述第二确定单元604还用于：

基于所述第一虚拟角色在游戏场景中所处的位置，在所述游戏场景中确定目标区域，所述目标区域包含所述多个场景区域。

可选的，所述游戏场景预先划分为多个网格，所述目标场景区域为目标网格；所述第二确定单元604具体用于：

接收配置数量；

以所述目标网格为正方形的中心；

基于所述中心以及所述配置数量的网格确定正方形的对角线；

基于所述对角线生成所述目标区域，所述目标区域为正方形。

可选的，所述第二确定单元604具体用于：

从所述目标区域中确定网格中心与所述目标网格的网格中心之间的距离小于或者等于所述第一距离的第一网格，并将所述第一网格确定为所述第一场景区域；

从所述目标区域中确定网格中心与所述目标网格的网格中心的距离大于所述第一距离的第二网格，并将所述第二网格确定为所述第二场景区域。

可选的，所述数据处理装置600还包括同步单元，所述同步单元用于：

响应于针对所述游戏场景中目标位置的建造操作，将所述建造操作对应的建造信息发送至服务器中，以通过所述服务器将所述建造信息同步至第二虚拟角色对应的客户端，其中，所述第二虚拟角色为视野范围内包含所述目标位置的虚拟角色。

可选的，所述服务器包括主线服务器和分线服务器，所述游戏场景中不同场景区域分别对应一个分线服务器；所述同步单元具体用于：

将所述建造操作对应的建造信息发送至所述目标位置对应的目标分线服务器；

所述目标分线服务器将所述建造信息发送至所述主线服务器，所述主线服务器将所述建造信息发送至微服务平台；

所述微服务平台向第二虚拟角色对应的客户端发送通知，以通知所述第二虚拟角色对应的客户端获取所述建造信息。

可选的，所述建造操作包括针对所述目标位置上的目标建筑部件的修改操作，所述建造信息为基于所述修改操作获得的增量数据。

可选的，所述数据处理装置600还包括合批单元，所述合批单元用于：

所述微服务器平台接收到所述建造信息后，基于所述建造信息进行合批计算，获得合批模型。

可选的，所述微服务平台包括服务节点以及计算节点；

其中，所述服务节点用于接收所述主线服务器所发送的所述建造信息，并将所述建造信息发送给所述计算节点；所述计算节点用于接收所述服务节点所发送的建造信息，并基于所述建造信息进行合批计算，获得合批模型。

可选的，所述微服务平台还在线合批系统包括第三存储服务器和第四版本管理服务器；所述存储服务器用于存储基于所述建造信息获得的合批模型或未合批的建造部件数据；所述版本管理服务器用于记录不同版本的建造部件数据。

可选的，所述同步单元具体用于：

响应于针对所述游戏场景中目标位置的建造操作，将所述建造操作对应的建造信息发送至服务器中，以使所述建造信息发送至所述服务节点；

所述服务节点将从所述存储服务器获取的所述合批模型或未合批的建造部件数据发送至所述服务器中；

所述服务器将所述合批模型或未合批的建造部件数据发送至第二虚拟角色对应的客户端。

可选的，所述同步单元还具体用于：

响应于针对所述游戏场景中目标位置的建造操作，在所述目标位置显示基于所述建造信息更新的建造部件；

检测所述建造操作是否符合预设的建造规则；

在所述建造操作符合所述预设的建造规则的情况下，将所述建造操作对应的建造信息发送至所述目标位置对应的目标分线服务器。

可选的，所述同步单元还用于：

在所述建造操作符合所述预设的建造规则的情况下，所述微服务平台向第二虚拟角色对应的客户端发送通知。

可选的，所述同步单元还用于：

在所述建造操作不符合所述预设的建造规则的情况下，将所述目标位置显示的更新的建造部件恢复至更新之前的建造部件。

可选的，所述合批单元具体用于：

获取并解析所述属于同一场景区域的建筑部件对应的蓝图文件，得到所述属于同一场景区域的建筑部件对应的建筑模型存储路径和位置数据；

确定所述属于同一场景区域的建筑部件对应的合批参数；

根据所述位置数据以及所述合批参数对所述建筑模型存储路径下所存储的建筑模型进行模型合批，得到所述属于同一场景区域的建筑部件对应的合批模型。

可选的，所述合批单元还具体用于：

基于所述属于同一场景区域的建筑部件分别对应的材质数据确定为合批模型的目标材质数据；

基于所述属于同一场景区域的建筑部件分别对应的纹理贴图确定所述合批模型的目标贴图；

基于所述目标材质数据和所述目标贴图对所述合批模型进行渲染。

可选的，所述合批单元具体用于：

获取各所述纹理贴图中的各颜色贴图；

从各所述颜色贴图中筛选得到存在差异的所述颜色贴图；

将所述存在差异的所述颜色贴图合并为所述目标贴图。

可选的，所述合批参数中包括用于对各所述纹理贴图的尺寸进行约束的第一预设尺寸和用于对所述目标贴图的尺寸进行约束的第二预设尺寸，所述合批单元具体用于：

对所述目标贴图中的各所述纹理贴图进行尺寸调整，以使得各所述纹理贴图的尺寸大于或者等于第一预设尺寸，且所述目标贴图的尺寸小于或者等于第二预设尺寸，得到调整后的所述目标贴图。

可选的，所述合批参数中包括对合批后模型进行不可见面剔除的第一参数，所述合批单元具体用于：

根据所述位置数据和所述目标贴图对所述属于同一场景区域的建筑部件进行各顶点数据的合并，得到合并后的顶点数据；

根据所述合并后的顶点数据对所述建筑模型存储路径下所存储的建筑模型进行模型合批，得到所述属于同一场景区域的建筑部件的合批后模型；

根据所述第一参数对所述合批后模型进行不可见面的剔除，得到剔除了所述不可见面的所述属于同一场景区域的建筑部件对应的合批模型。

可选的，所述位置数据包括所述属于同一场景区域的建筑部件的顶点在对应的部件坐标系中的位置坐标、法线向量以及用于指示所述属于同一场景区域的建筑部件在由所述属于同一场景区域的建筑部件所组成的建筑组合中的位置和方向的位置变换矩阵；所述合批单元具体用于：

根据所述位置变换矩阵，对所述属于同一场景区域的建筑部件的顶点在对应的部件坐标系中的位置坐标以及法线向量进行位置变换，得到所述属于同一场景区域的建筑部件的顶点在所述建筑组合中的位置坐标和法线向量；

修改所述属于同一场景区域的建筑部件的顶点对应的UV坐标数据，以使得修改后的UV坐标数据所指示的映射关系为对应的顶点在所述建筑组合中的位置坐标与在所述调整后的所述目标贴图中的所处位置之间的对应关系，得到所述属于同一场景区域的建筑部件的顶点对应的修改后的UV坐标数据；

将所述属于同一场景区域的建筑部件的顶点在所述建筑组合中的位置坐标和法线向量、以及所述属于同一场景区域的建筑部件的顶点对应的修改后的UV坐标数据确定为所述合并后的顶点数据。

可选的，所述合批单元具体用于：

获取所述属于同一场景区域的建筑部件对应的三角形面片的面片索引；

根据所述合并后的顶点数据以及所述面片索引所索引的三角形面片对所述建筑模型存储路径下所存储的建筑模型进行模型合批，得到所述属于同一场景区域的建筑部件的合批后模型。

可选的，所述合批单元具体用于：

将所述合批后模型转换为由体素网格组成的体素化模型；

沿各方向对所述体素化模型进行深度检测，确定不可达的所述体素网格，所述不可达的所述体素网格所包含的面为不可见面；

将所述不可见面进行剔除，得到剔除了所述不可见面的所述属于同一场景区域的建筑部件对应的合批模型。

可选的，所述合批单元具体用于：

针对所述纹理贴图为循环贴图的所述属于同一场景区域的建筑部件，对所针对的所述属于同一场景区域的建筑部件的顶点对应的修改后的UV坐标数据进行调整，得到所针对的所述属于同一场景区域的建筑部件的顶点对应的调整后的UV坐标数据，以使得所针对的所述属于同一场景区域的建筑部件的顶点映射在所述目标贴图内；

将所述属于同一场景区域的建筑部件的顶点在所述建筑组合中的位置坐标和法线向量、以及所述属于同一场景区域的建筑部件的顶点对应的调整后的UV坐标数据确定为所述合并后的顶点数据。

与本申请第一实施例提供的数据处理方法相对应的，本申请第三实施例还提供了一种用于数据处理的电子设备。如图8所示，所述电子设备700包括：处理器701；以及存储器702，用于存储数据处理方法的程序，该设备通电并通过所述处理器运行数据处理方法的程序后，执行如下步骤：

获取第一虚拟角色在游戏场景中所处的目标场景区域，所述游戏场景包括多个场景区域；

从所述多个场景区域中确定与所述目标场景区域之间的距离小于或者等于第一距离的第一场景区域，以及确定与所述目标场景区域之间的距离大于所述第一距离的第二场景区域；

针对所述目标场景区域和所述第一场景区域中的第一建筑部件，获取所述第一建筑部件对应的第一建造部件数据，所述第一建造部件数据包括所述第一建筑部件对应的第一模型以及针对所述第一模型的渲染细节数据；

针对所述第二场景区域中的多个第二建筑部件，获取所述第二建筑部件对应的第二建造部件数据，所述第二建造部件数据包括合批模型，所述合批模型为基于至少一个所述第二建筑部件的修改数据对所述多个第二建筑部件进行合批得到的结果；

根据所述第一建造部件数据和所述第二建造部件数据分别渲染显示所述第一建筑部件和多个所述第二建筑部件。

与本申请第一实施例提供的数据处理方法相对应的，本申请第四实施例提供了一种计算机可读存储介质，存储有数据处理方法的程序，该程序被处理器运行，执行下述步骤：

获取第一虚拟角色在游戏场景中所处的目标场景区域，所述游戏场景包括多个场景区域；

从所述多个场景区域中确定与所述目标场景区域之间的距离小于或者等于第一距离的第一场景区域，以及确定与所述目标场景区域之间的距离大于所述第一距离的第二场景区域；

针对所述目标场景区域和所述第一场景区域中的第一建筑部件，获取所述第一建筑部件对应的第一建造部件数据，所述第一建造部件数据包括所述第一建筑部件对应的第一模型以及针对所述第一模型的渲染细节数据；

针对所述第二场景区域中的多个第二建筑部件，获取所述第二建筑部件对应的第二建造部件数据，所述第二建造部件数据包括合批模型，所述合批模型为基于至少一个所述第二建筑部件的修改数据对所述多个第二建筑部件进行合批得到的结果；

根据所述第一建造部件数据和所述第二建造部件数据分别渲染显示所述第一建筑部件和多个所述第二建筑部件。

需要说明的是，对于本申请第二实施例、第三实施例和第四实施例提供的装置、电子设备及计算机可读存储介质的详细描述可以参考对本申请第一实施例的相关描述，这里不再赘述。

本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。

在一个典型的配置中，区块链中的节点设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他属性的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储介质或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

2、本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。

Claims (28)

1.一种数据处理方法，其特征在于，所述方法包括：

获取第一虚拟角色在游戏场景中所处的目标场景区域，所述游戏场景包括多个场景区域；

从所述多个场景区域中确定与所述目标场景区域之间的距离小于或者等于第一距离的第一场景区域，以及确定与所述目标场景区域之间的距离大于所述第一距离的第二场景区域；

针对所述目标场景区域和所述第一场景区域中的第一建筑部件，获取所述第一建筑部件对应的第一建造部件数据，所述第一建造部件数据包括所述第一建筑部件对应的第一模型以及针对所述第一模型的渲染细节数据；

针对所述第二场景区域中的多个第二建筑部件，获取所述第二建筑部件对应的第二建造部件数据，所述第二建造部件数据包括合批模型，所述合批模型为基于至少一个所述第二建筑部件的修改数据对所述多个第二建筑部件进行合批得到的结果；

根据所述第一建造部件数据和所述第二建造部，件数据分别渲染显示所述第一建筑部件和多个所述第二建筑部件。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

基于所述第一虚拟角色在游戏场景中所处的位置，在所述游戏场景中确定目标区域，所述目标区域包含所述多个场景区域。

3.根据权利要求2所述的方法，其特征在于，所述游戏场景预先划分为多个网格，所述目标场景区域为目标网格；

所述在所述游戏场景中确定目标区域，包括：

接收配置数量；

以所述目标网格为正方形的中心；

基于所述中心以及所述配置数量的网格确定正方形的对角线；

基于所述对角线生成所述目标区域，所述目标区域为正方形。

4.根据权利要求3所述的方法，其特征在于，所述从所述多个场景区域中确定与所述目标场景区域之间的距离小于或者等于第一距离的第一场景区域，包括：

从所述目标区域中确定网格中心与所述目标网格的网格中心之间的距离小于或者等于所述第一距离的第一网格，并将所述第一网格确定为所述第一场景区域；

所述确定与所述目标场景区域之间的距离大于所述第一距离的第二场景区域，包括：

从所述目标区域中确定网格中心与所述目标网格的网格中心的距离大于所述第一距离的第二网格，并将所述第二网格确定为所述第二场景区域。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

响应于针对所述游戏场景中目标位置的建造操作，将所述建造操作对应的建造信息发送至服务器中，以通过所述服务器将所述建造信息同步至第二虚拟角色对应的客户端，其中，所述第二虚拟角色为视野范围内包含所述目标位置的虚拟角色。

6.根据权利要求5所述的方法，其特征在于，所述服务器包括主线服务器和分线服务器，所述游戏场景中不同场景区域分别对应一个分线服务器；

所述将所述建造操作对应的建造信息发送至服务器中，包括：

将所述建造操作对应的建造信息发送至所述目标位置对应的目标分线服务器；

所述目标分线服务器将所述建造信息发送至所述主线服务器，所述主线服务器将所述建造信息发送至微服务平台；

所述微服务平台向第二虚拟角色对应的客户端发送通知，以通知所述第二虚拟角色对应的客户端获取所述建造信息。

7.根据权利要求5所述的方法，其特征在于，所述建造操作包括针对所述目标位置上的目标建筑部件的修改操作，所述建造信息为基于所述修改操作获得的增量数据。

8.根据权利要求5所述的方法，其特征在于，所述方法还包括：

所述微服务器平台接收到所述建造信息后，基于所述建造信息进行合批计算，获得合批模型。

9.根据权利要求8所述的方法，其特征在于，所述游戏场景中属于同一场景区域的建筑部件对应有合批模型。

10.根据权利要求8所述的方法，其特征在于，所述微服务平台包括服务节点以及计算节点；其中，所述服务节点用于接收所述主线服务器所发送的所述建造信息，并将所述建造信息发送给所述计算节点；所述计算节点用于接收所述服务节点所发送的建造信息，并基于所述建造信息进行合批计算，获得合批模型。

11.根据权利要求10所述的方法，其特征在于，所述微服务平台还包括存储服务器和版本管理服务器；

所述存储服务器用于存储基于所述建造信息获得的合批模型或未合批的建造部件数据；所述版本管理服务器用于记录不同版本的建造部件数据。

12.根据权利要求11所述的方法，其特征在于，所述响应于针对所述游戏场景中目标位置的建造操作，将所述建造操作对应的建造信息发送至服务器中，以通过所述服务器将所述建造信息同步至第二虚拟角色对应的客户端，包括：

响应于针对所述游戏场景中目标位置的建造操作，将所述建造操作对应的建造信息发送至服务器中，以使所述建造信息发送至所述服务节点；

所述服务节点将从所述存储服务器获取的所述合批模型或未合批的建造部件数据发送至所述服务器中；

所述服务器将所述合批模型或未合批的建造部件数据发送至第二虚拟角色对应的客户端。

13.根据权利要求6所述的方法，其特征在于，在所述将所述建造操作对应的建造信息发送至所述目标位置对应的目标分线服务器之前，所述方法还包括：

响应于针对所述游戏场景中目标位置的建造操作，在所述目标位置显示基于所述建造信息更新的建造部件；

检测所述建造操作是否符合预设的建造规则；

所述将所述建造操作对应的建造信息发送至所述目标位置对应的目标分线服务器，包括：

在所述建造操作符合所述预设的建造规则的情况下，将所述建造操作对应的建造信息发送至所述目标位置对应的目标分线服务器。

14.根据权利要求13所述的方法，其特征在于，所述微服务平台向第二虚拟角色对应的客户端发送通知，包括：

在所述建造操作符合所述预设的建造规则的情况下，所述微服务平台向第二虚拟角色对应的客户端发送通知。

15.根据权利要求13所述的方法，其特征在于，所述方法还包括：

在所述建造操作不符合所述预设的建造规则的情况下，将所述目标位置显示的更新的建造部件恢复至更新之前的建造部件。

16.根据权利要求8所述的方法，其特征在于，所述基于所述建造信息进行合批计算，获得合批模型，包括：

获取并解析所述属于同一场景区域的建筑部件对应的蓝图文件，得到所述属于同一场景区域的建筑部件对应的建筑模型存储路径和位置数据；

确定所述属于同一场景区域的建筑部件对应的合批参数；

根据所述位置数据以及所述合批参数对所述建筑模型存储路径下所存储的建筑模型进行模型合批，得到所述属于同一场景区域的建筑部件对应的合批模型。

17.根据权利要求16所述的方法，其特征在于，根据所述第二建筑部件数据渲染显示多个所述第二建筑部件，包括：

基于所述属于同一场景区域的建筑部件分别对应的材质数据确定为合批模型的目标材质数据；

基于所述属于同一场景区域的建筑部件分别对应的纹理贴图确定所述合批模型的目标贴图；

基于所述目标材质数据和所述目标贴图对所述合批模型进行渲染。

18.根据权利要求17所述的方法，其特征在于，所述基于所述属于同一场景区域的建筑部件分别对应的各纹理贴图确定所述合批模型的目标贴图，包括：

获取各所述纹理贴图中的各颜色贴图；

从各所述颜色贴图中筛选得到存在差异的所述颜色贴图；

将所述存在差异的所述颜色贴图合并为所述目标贴图。

19.根据权利要求17所述的方法，其特征在于，所述合批参数中包括用于对各所述纹理贴图的尺寸进行约束的第一预设尺寸和用于对所述目标贴图的尺寸进行约束的第二预设尺寸，所述方法还包括：

对所述目标贴图中的各所述纹理贴图进行尺寸调整，以使得各所述纹理贴图的尺寸大于或者等于第一预设尺寸，且所述目标贴图的尺寸小于或者等于第二预设尺寸，得到调整后的所述目标贴图。

20.根据权利要求17所述的方法，其特征在于，所述合批参数中包括对合批后模型进行不可见面剔除的第一参数，所述根据所述位置数据以及所述合批参数对所述建筑模型存储路径下所存储的建筑模型进行模型合批，得到所述属于同一场景区域的建筑部件对应的合批模型，包括：

根据所述位置数据和所述目标贴图对所述属于同一场景区域的建筑部件进行各顶点数据的合并，得到合并后的顶点数据；

根据所述合并后的顶点数据对所述建筑模型存储路径下所存储的建筑模型进行模型合批，得到所述属于同一场景区域的建筑部件的合批后模型；

根据所述第一参数对所述合批后模型进行不可见面的剔除，得到剔除了所述不可见面的所述属于同一场景区域的建筑部件对应的合批模型。

21.根据权利要求20所述的方法，其特征在于，所述位置数据包括所述属于同一场景区域的建筑部件的顶点在对应的部件坐标系中的位置坐标、法线向量以及用于指示所述属于同一场景区域的建筑部件在由所述属于同一场景区域的建筑部件所组成的建筑组合中的位置和方向的位置变换矩阵；

所述根据所述位置数据和所述目标贴图对所述属于同一场景区域的建筑部件进行各顶点数据的合并，得到合并后的顶点数据，包括：

根据所述位置变换矩阵，对所述属于同一场景区域的建筑部件的顶点在对应的部件坐标系中的位置坐标以及法线向量进行位置变换，得到所述属于同一场景区域的建筑部件的顶点在所述建筑组合中的位置坐标和法线向量；

修改所述属于同一场景区域的建筑部件的顶点对应的UV坐标数据，以使得修改后的UV坐标数据所指示的映射关系为对应的顶点在所述建筑组合中的位置坐标与在所述调整后的所述目标贴图中的所处位置之间的对应关系，得到所述属于同一场景区域的建筑部件的顶点对应的修改后的UV坐标数据；

将所述属于同一场景区域的建筑部件的顶点在所述建筑组合中的位置坐标和法线向量、以及所述属于同一场景区域的建筑部件的顶点对应的修改后的UV坐标数据确定为所述合并后的顶点数据。

22.根据权利要求20所述的方法，其特征在于，所述根据所述合并后的顶点数据对所述建筑模型存储路径下所存储的建筑模型进行模型合批，得到所述属于同一场景区域的建筑部件的合批后模型，包括：

获取所述属于同一场景区域的建筑部件对应的三角形面片的面片索引；

根据所述合并后的顶点数据以及所述面片索引所索引的三角形面片对所述建筑模型存储路径下所存储的建筑模型进行模型合批，得到所述属于同一场景区域的建筑部件的合批后模型。

23.根据权利要求22所述的方法，其特征在于，所述根据所述第一参数对所述合批后模型进行不可见面的剔除，得到剔除了所述不可见面的所述属于同一场景区域的建筑部件对应的合批模型，包括：

将所述合批后模型转换为由体素网格组成的体素化模型；

沿各方向对所述体素化模型进行深度检测，确定不可达的所述体素网格，所述不可达的所述体素网格所包含的面为不可见面；

将所述不可见面进行剔除，得到剔除了所述不可见面的所述属于同一场景区域的建筑部件对应的合批模型。

24.根据权利要求21所述的方法，其特征在于，在所述将所述属于同一场景区域的建筑部件的顶点在所述建筑组合中的位置坐标和法线向量、以及所述属于同一场景区域的建筑部件的顶点对应的修改后的UV坐标数据确定为所述合并后的顶点数据之前，所述方法还包括：

针对所述纹理贴图为循环贴图的所述属于同一场景区域的建筑部件，对所针对的所述属于同一场景区域的建筑部件的顶点对应的修改后的UV坐标数据进行调整，得到所针对的所述属于同一场景区域的建筑部件的顶点对应的调整后的UV坐标数据，以使得所针对的所述属于同一场景区域的建筑部件的顶点映射在所述目标贴图内；

所述将所述属于同一场景区域的建筑部件的顶点在所述建筑组合中的位置坐标和法线向量、以及所述属于同一场景区域的建筑部件的顶点对应的修改后的UV坐标数据确定为所述合并后的顶点数据，包括：

将所述属于同一场景区域的建筑部件的顶点在所述建筑组合中的位置坐标和法线向量、以及所述属于同一场景区域的建筑部件的顶点对应的调整后的UV坐标数据确定为所述合并后的顶点数据。

25.根据权利要求1所述的方法，其特征在于，所述游戏场景通过以下方式划分为所述多个场景区域：

按照预设的区域尺寸，将所述游戏场景对应的游戏地面划分为所述预设的所述区域尺寸的多个所述场景区域。

26.一种数据处理装置，其特征在于，所述装置包括：

第一获取单元，用于获取第一虚拟角色在游戏场景中所处的目标场景区域，所述游戏场景包括多个场景区域；

第一确定单元，用于从所述多个场景区域中确定与所述目标场景区域之间的距离小于或者等于第一距离的第一场景区域，以及确定与所述目标场景区域之间的距离大于所述第一距离的第二场景区域；

第二获取单元，用于针对所述目标场景区域和所述第一场景区域中的第一建筑部件，获取所述第一建筑部件对应的第一建造部件数据，所述第一建造部件数据包括所述第一建筑部件对应的第一模型以及针对所述第一模型的渲染细节数据；

第二确定单元，用于针对所述第二场景区域中的多个第二建筑部件，获取所述第二建筑部件对应的第二建造部件数据，所述第二建造部件数据包括合批模型，所述合批模型为基于至少一个所述第二建筑部件的修改数据对所述多个第二建筑部件进行合批得到的结果；

渲染显示单元，用于根据所述第一建造部件数据和所述第二建造部件数据分别渲染显示所述第一建筑部件和多个所述第二建筑部件。

27.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储数据处理程序，该电子设备通电并通过所述处理器运行该程序后，执行如权利要求1-26中任一项所述的方法。

28.一种计算机可读存储介质，其特征在于，存储有数据处理程序，该程序被处理器运行，执行如权利要求1-26中任一项所述的方法。