具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本公开实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本公开。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本公开的描述。

数字沙盘是一种通过三维模型技术和数字影像技术，将楼盘模型以三维可视化的方式展示在用户面前，相比于实体沙盘，数字沙盘用一种虚拟化的三维场景更直观更全面的展示楼盘的相关信息，并可支持各种三维可视化特效和沙盘功能应用。数字沙盘又称为三维数字沙盘，三维数字沙盘可以通过屏幕显示数字影像来展示模型，一般可以利用三维GIS技术、三维建模技术、互联网技术将模型通过屏幕进行展示。

在数字沙盘技术的应用中，房景展示是数字沙盘中的一项重要组成功能，该功能是通过一些简单交互和筛选支持用户能够比较直观的选择沙盘模型中的楼栋和房型，并模拟该楼栋、该层高、该户型所对应的景观视角，从而提升购房者的使用体验。

在相关技术中，数字沙盘中的房景配置主要是基于人工批量搭建的方式生成的，例如：配置人员在数字沙盘中根据楼盘的户型分布、窗户位置和朝向等手动配置每个户型的相机位置，也即以人工的方式为每个户型逐个添加相机位置，并添加户型、房号等参数以及标号。但是，目前实际场景中一个楼盘可能存在数十栋楼以及上千个户型，因此，使用现有的以人工手动在数字沙盘中配置房景的方式，当楼盘户型非常多时，配置房景的过程变得越来越复杂，耗费的时间和人力成本也越来越高，导致出现人为误差的几率也越来越大，同时，极大降低了在数字沙盘中配置房景的效率。

鉴于以上现有技术中的问题，需要提供一种能够自动在数字沙盘中为每个房型生成对应的相机点位，提升房景配置的效率，降低房景配置的难度，提升房景展示的效果的房景展示方案。下面结合附图对本公开实施例技术方案的整体实现过程进行说明，图1是本公开实施例对应技术方案的整体处理流程示意图。如图1所示，该技术方案的整体流程具体可以包括：

通过获取楼盘或楼栋对应的完整的建筑信息模型（如Revit模型），一方面，从建筑信息模型中筛选出建筑专业的模型，并将包含建筑专业的建筑信息模型导出为模型中间文件，该模型中间文件采用datasmith格式；另一方面，对筛选得到的建筑信息模型进行解析，提取出建筑信息模型中每个房型对应的房型信息，根据建筑信息模型筛选出每个房型对应的窗户，并进一步计算出每个窗户的法向量，基于窗户的法向量生成相机点位，将房型信息和相机点位一起导出为Json格式的要素信息对象。

进一步地，在导出datasmith格式的模型中间文件以及Json格式的要素信息对象之后，利用数字沙盘所依赖的UE4引擎记载这两部分信息，其中，在加载模型中间文件之后，直接将模型中间文件渲染成为数字沙盘中的三维模型；在加载要素信息对象之后，对要素信息对象进行解析，生成每个房型的房型体块，并根据要素信息对象中的相机点位，在房型体块中的相机点位坐标对应的位置处添加相机对象，通过建立相机对象与房型体块之间的交互方式，例如：配置点击房型体块将沙盘模型的视角移动到相机对象所对应的视角上。至此整个房景的配置操作就已经完成，当接收针对数字沙盘中某个房型的交互请求时，将数字沙盘的视角调整到该房型对应的相机对象的视角，从而达到一个房型对应一个外景，即对一房一景进行展示的效果。

图2是本公开实施例提供的一种基于数字沙盘的房景展示方法的流程示意图。图2的基于数字沙盘的房景展示方法可以由服务器执行，如图2所示，该基于数字沙盘的房景展示方法具体可以包括：

S201，获取第一建筑信息模型，对第一建筑信息模型对应的模型文件进行处理得到第二建筑信息模型，并将第二建筑信息模型转化为预定格式的模型中间文件；

S202，对第二建筑信息模型中的每个房型依次进行遍历，得到每个房型对应的房型数据，并基于窗户属性信息生成房型对应的相机点位，将房型数据和相机点位组合成要素信息对象；

S203，利用预设的数字沙盘对应的引擎加载模型中间文件，以便在数字沙盘中渲染出模型中间文件对应的建筑模型，并对要素信息对象执行解析操作，得到每个房型对应的房型体块；

S204，建立每个房型的相机点位与房型体块之间的交互关系，当触发针对数字沙盘的建筑模型中的房型体块的选择操作时，将数字沙盘的视角调整为相机点位的视角，以便展示相机点位的视角对应的房景。

具体地，本公开实施例中的数字沙盘，可以认为是由楼盘三维模型以及楼盘周边一定范围内的外景所共同构建得到的三维数字沙盘，其中，楼盘三维模型的数量不受限制，既可以是单独的一栋楼，也可以是由多栋楼所组成的楼盘；楼盘的外景是提前根据楼盘周边几公里之内的实际外景所构建的虚拟外景环境，楼盘的外景包括但不限于以下景观：树木、其它建筑物、湖、河流等。

进一步地，第一建筑信息模型和第二建筑信息模型都可以采用基于BIM正向设计的模型，BIM（Building Information Modeling）简称建筑信息模型，BIM是指在建设工程及设施的规划、设计、施工以及运营维护阶段全寿命周期创建和管理建筑信息的过程，全过程应用三维、实时、动态的模型涵盖了几何信息、空间信息、地理信息、各种建筑组件的性质信息及工料信息。在BIM中，Revit是一个主流的BIM可视化及建模工具，因此，本公开实施例中的建筑信息模型可以采用Revit模型。

进一步地，预定格式的模型中间文件是指能够被UE4引擎所识别和加载的模型文件，在实际应用中，模型中间文件可以采用.datasmith后缀的模型文件。 这里，UE4引擎是一种游戏引擎，本公开实施例中的数字沙盘的底层引擎使用的是UE4引擎，当然除了UE4引擎之外，其他3D引擎也同样可以作为数字沙盘的底层引擎被使用。本公开实施例中的房景是在UE4引擎的数字沙盘中进行展示的，且房景的交互功能也是在UE4引擎的数字沙盘中实现的。

根据本公开实施例提供的技术方案，本公开实施例包含两部分内容，第一部分，通过将Revit模型转化为datasmith格式的模型文件，并对Revit模型进行解析得到每个房型的属性数据（即房型数据），并计算每个房型对应的相机点位，根据房型的属性数据与相机点位生成Json格式的要素信息对象；第二部分，通过基于UE4引擎的数字沙盘加载datasmith格式的模型文件，并解析Json格式的要素信息对象，生成每个房型的房型体块，并建立相机点位与房型体块之间的交互关系，使得房型体块具备一定的交互功能，当点击房型体块时，整个数字沙盘的视角可以移动到房型体块对应的相机点位的视角。本公开能够自动为每个房型生成对应的相机点位，减少人工手动配置造成的配置效率低以及错误率提升的问题，降低了房景配置的难度，提升了房景展示的效果。

在一些实施例中，获取第一建筑信息模型，对第一建筑信息模型对应的模型文件进行处理得到第二建筑信息模型，包括：获取模型文件以及模型文件对应的文件名称，根据预设的目标模型文件对应的关键字符串，对模型文件的文件名称依次进行匹配，将成功匹配的模型文件进行加载，得到第二建筑信息模型；其中，目标模型文件为与建筑结构相关的模型文件，第一建筑信息模型以及第二建筑信息模型均为Revit模型。

具体地，第一建筑信息模型可以认为是初始的包含了多种专业的模型，在实际应用中，一个完整的Revit模型中会包含多种专业模型，比如建筑模型、机电模块、结构模型等，而数字沙盘中通常只需要建筑专业的模型即可，因此，首先对初始的建筑信息模型（即第一建筑信息模型）中的模型进行筛选，只需要加载建筑专业的模型即可。

需要说明的是，建筑信息模型中不同专业的模型可以认为是不同图层下的模型，即一个专业对应一个图层文件，对于完整的Revit模型来说，所有专业的模型都会显示，而本公开中只需要加载建筑专业的模型，因此，需要判断哪些图层文件对应的是建筑业务的图层，将建筑专业的图层文件加载出来，其他专业的图层不加载或者隐藏显示。下面结合具体实施例对加载得到第二建筑信息模型的过程进行说明，具体可以包括以下内容：

通常在利用BIM正向设计得到建筑信息模型后，不同类型的模型结构具有单独规则化的命名方式，比如，建筑专业模型和机电专业模型的文件名称就不相同，因此可以通过模型文件的名称对不同类型的模型进行区分，从而判断哪些模型文件是需要最终加载的目标模型文件。例如，建筑专业模型的命名规则为“XX-项目名称-A-F01.rvt”，那么在加载Revit模型文件的时候，可以通过Revit模型中原生的API接口，利用关键字符串遍历Revit模型文件中的所有文件名称，其中，关键字符串是基于上述建筑模型的命名规则所生成的字符串，根据上述命名规则可以生成“-A-”关键字符串对模型文件进行遍历和匹配，从而筛选出符合上述命名规则的模型文件，将匹配到的模型文件进行加载，未匹配到的则不加载。

在一些实施例中，将第二建筑信息模型转化为预定格式的模型中间文件，包括：将第二建筑信息模型对应的Revit模型转化为以datasmith作为后缀格式的模型中间文件。

具体地，第二建筑信息模型中可以认为只包含建筑模型，datasmith格式是Revit模型支持加载到UE4引擎的一种中间格式，在UE4引擎中有专门的插件和API导出接口，将Revit模型文件导出为datasmith格式的模型中间文件是Revit模型所具备的功能，因此，本公开实施例不对格式转化的具体过程进行展开说明。

在一些实施例中，对第二建筑信息模型中的每个房型依次进行遍历，得到每个房型对应的房型数据，包括：确定第二建筑信息模型中的所有楼层，并以楼层为单位，沿楼层依次对每个楼层中的房型进行遍历，以便提取出每个房型对应的楼层标识、房型标识、外轮廓线、以及标高；根据每个房型中各个房间对应的面积参数，计算每个房型对应的房型面积，基于楼层标识、房型标识、外轮廓线、标高、以及房型面积生成结构化数据，将结构化数据作为房型数据。

具体地，由于在Reivt建模过程中，设计师会首先搭建楼盘的标准层的模型，或者搭建标准层的一半，再沿中线左右对称得到完整的标准层，并通过镜像或者复制的方式把楼盘的中间层全部搭建完成，最后再补足每栋楼房的底层和顶层。在对标准层进行建模的过程中，设计师会将同一层的所有房间的墙立面搭建完成，并标上房间的标签、面积轮廓和所属户型。因此，在对第二建筑信息模型进行遍历生成房型数据时，可以标准层作为基础的遍历单位，遍历所有房间的属性数据，下面结合具体实施例对房型数据的遍历过程进行详细说明，具体可以包括以下内容：

获取第二Reivt模型文件（即第二建筑信息模型）中的每个楼层对应的数据文件，依次遍历每个楼层数据文件中的每个房间对应的数据文件，并按照户型对每个房间进行分类，通过遍历数据可以得到一个房型维度的数组结构，每个房型维度的数组结构中包含一个或多个房间维度的数组结构。其中，每个房型维度的数组结构中至少包含楼层标识、房型标识、外轮廓线、以及标高等信息，将组成每个房型的房间所对应的面积参数相加，便得到每个房型的整体面积，在实际应用中，可以采用多边形的面积计算方法求每个房型的面积。

进一步地，根据计算得到的每个房型的整体面积，结合上述遍历得到的每个房型的楼层标识、房型标识、外轮廓线、以及标高，将这些参数综合生成一套用于描述户型结构的数据结构，将结构化数据作为房型数据。需要说明的是，上述所谓的标准层可以认为是将整个楼房去掉顶层和底层之后的中间层，即在实际应用中，Reivt模型文件中表示中间层的楼层数据文件就可以认为是标准层的文件，当然在本公开实施例中标准层可以认为是中间层中的任意一个楼层。

在一些实施例中，基于窗户属性信息生成房型对应的相机点位，包括：获取每个房型对应的窗户属性信息，根据窗户属性信息确定窗户所对应的墙立面，计算墙立面对应的中心线的平面向量，并根据平面向量确定窗户的法向量；沿窗户的法向量向正负方向分别移动预设距离，得到两个点位坐标，根据点位坐标判断点位是否在外轮廓线内，将属于外轮廓线内的点位坐标作为相机点位。

具体地，在获取第二Reivt模型文件中每个房型各自对应的窗户属性信息之前，首先需要确定对房型中的哪些窗户对应的窗户属性信息进行处理生成相机点位。由于一个房型可能对应多个窗户，而在UE4引擎中对房型的外部景观进行展示时，往往只需要关注阳台和主卧的窗户位置处的景观，因此，在获取Reivt模型文件中的窗户属性信息时，可以只采集阳台和主卧的窗户对应的窗户属性信息。下面结合具体实施例对如何在Reivt模型文件中选择特定的窗户属性信息提取的过程进行说明，具体可以包括以下内容：

在Revit模型文件中窗户是以点来表示的，房型轮廓线是一个闭合的面，通过点与面的交集关系判断哪些点（窗户）在哪些轮廓线（房间）内，根据轮廓线上映射的房间标签信息即可得出属于阳台、客厅的窗户。即根据外轮廓线以及第二建筑信息模型中窗户对应的点位，将窗户的点位与外轮廓线进行求交，根据窗户的点位与外轮廓线之间的交集关系，判断窗户所在的房间。

进一步地，在确定所要提取的窗户对应的窗户属性信息之后，根据窗户属性信息生成相机点位，下面结合附图以及具体实施例对相机点位的生成方式进行详细说明。图3是本公开实施例提供的在Revit模型中确定相机点位的示意图。如图3所示，该相机点位的生成过程具体可以包括：

获取阳台窗户或者主卧窗户的中心点位，计算窗户的法线方向，在Revit建模设计中，通常窗户都会挂在墙面上，因此可以通过窗户属性查找出窗户对应的墙立面，并计算出立面对应的中心线的XY平面向量，进而计算得出垂直于该墙立面的法向量，窗户的法向量是垂直于墙立面上的三维向量。这里涉及到相机点位的计算方法如图3所示，以窗户中心点为圆点，顺着法向量正方向和负方向分别移动1m的距离，得出两个点位，再根据点位判断是否包含于房间轮廓线中，包含的则视为正确相机点位，保存相机点位的坐标。

在一些实施例中，将房型数据和相机点位组合成要素信息对象，包括：根据与每个房型相对应的房型数据和相机点位，为每个房型生成用于表示户型结构以及相机位置的数据结构，并将数据结构导出为Json格式的要素信息对象。

具体地，在从Revit模型文件中解析出房型数据，并通过计算确定相机点位之后，根据房型数据和相机点位针对每个房型生成一个Json格式的要素信息对象，要素信息对象中包含每个房型对应的楼层标识、房型标识、外轮廓线、标高、整体面积、窗户正方向、窗户中心点位、以及相机点位等信息。因此，在最终生成的Json格式的要素信息对象中包含了相机点位对应的坐标。

需要说明的是，每个模型中间文件对应一个模型文件标识，建立模型文件标识与要素信息对象的标识之间的对应关系。在实际应用中，还会进一步提取户型外轮廓线、户型标识（如户号）、房间轮廓（由轮廓线坐标对应的二维数组）、标高等信息，生成房间唯一识别ID并进行关联。

根据本公开实施例提供的技术方案，通过将Revit模型转化为datasmith格式的模型中间文件，并根据Revit模型文件提取并解析得到房型数据，以及基于房型数据生成对应的相机点位，将房型数据和相机点位组合成Json格式的要素信息，使得基于UE4引擎的电子沙盘能够自动加载模型中间文件并解析要素信息。本公开实现自动为每个房型的窗户生成对应的相机点位，无需人为手动添加相机点位，降低了房景配置的工作量，提升了房景配置时相机点位的准确度。

在一些实施例中，预设的数字沙盘对应的引擎采用UE4引擎，利用预设的数字沙盘对应的引擎加载模型中间文件，以便在数字沙盘中渲染出模型中间文件对应的建筑模型，包括：利用预设的插件将datasmith格式的模型中间文件加载到UE4引擎中，并在UE4引擎中对模型中间文件所对应的建筑模型进行渲染，渲染用于在预先配置的包含楼房外景的数字沙盘中展示建筑模型对应的效果。

具体地，UE4引擎提供了datasmith插件用于将Revit模型转化后的datasmith数据导入并加载到UE4引擎中，即通过UE4引擎中预设的API调用datasmith插件，将datasmith格式的模型中间文件自动加载到UE4引擎中。

这里，datasmith格式的是模型文件，在数字沙盘中用来表达模型接口和展示效果，datasmith模型文件本身不具备交互和参数关联的功能，UE4引擎中加载并解析出来的Json要素信息文件是用来生成一些用于交互的体块模型（房型体块），用户在实际做交互操作的时候点击的并不是datasmith模型，而是基于Json文件生成的专门用于交互的体块。

在一些实施例中，对要素信息对象执行解析操作，得到每个房型对应的房型体块，包括：对Json格式的要素信息对象进行序列化处理，在序列化处理后的要素信息对象中对房型对应的房型数据进行遍历，根据每个房型对应的外轮廓线和标高，在UE4引擎的三维坐标系中构建每个房型所对应的房型体块。

具体地，要素信息对象的序列化处理可以认为是将对象转换为可通过网络传输或可以存储到本地磁盘的数据格式（如转换为特定格式的字节串）的过程。对序列化处理之后的要素信息进行遍历，遍历所有的楼层和房型，并根据房型的外轮廓线和标高生成房型体块，将房型标识与房型体块之间进行关联。下面结合具体实施例对房型体块的生成过程进行详细说明，具体可以包括以下内容：

在UE4引擎中三维空间是一个三轴坐标系，分别是X轴，Y轴，Z轴。房型轮廓是一个闭合的多边形面，只在X轴和Y轴有数值，通过房型轮廓线的X轴和Y轴的数值以及Z轴的数字（即标高）计算出多边形空间几何体，这个多边形空间几何体就可以认为是房型体块。也就是说，生成房型体块的原理是通过把多边形面（即房型轮廓）往Z轴方向拉伸，就形成了一个高度为Z轴数值的多边形体块，房型标高就是多边形体块的高度，也即根据标高拉伸就能生成一个建筑的体块。

在一些实施例中，建立每个房型的相机点位与房型体块之间的交互关系，包括：获取房型的相机点位对应的点位坐标，以及房型体块的标识，建立相机点位的点位坐标与房型体块的标识之间的交互关系，交互关系用于表示当点击房型体块时，相机点位将按照预设的交互方式在UE4引擎的建筑模型中进行旋转或移动。

具体地，在UE4引擎中生成的房型体块是可以添加交互操作的体块，在实际应用中，通过在UE4引擎中对每个房型的相机点位与房型体块之间建立交互关系，将相机点位与房型体块之间绑定在一起，并为每个房型体块添加交互操作，该交互操作可以是当房型体块被点击之后，数字沙盘的视角迅速移动至与该房型体块相关联的相机点位的视角位置上，例如，可以通过窗户的法线取反计算得出移动之后的相机位置的视角。

在一些实施例中，该方法还包括：根据每个房型对应的相机点位以及窗户的法向量，在UE4引擎的建筑模型中对每个房型的窗户生成一个相机对象，当触发针对数字沙盘的建筑模型中的房型体块的选择操作时，将数字沙盘对应的当前视角移动到相机对象对应的视角。

具体地，根据UE4引擎中每个房型的相机点位和窗户法线方向，为每个房型绑定用于展示一房一景的相机对象，相机对象在UE4引擎中是一种虚拟相机，每个虚拟相机都放置在房型体块中，虚拟相机在房型体块中的位置可以是距离楼层地面1.6m，距离窗户1m的相对坐标位置。

根据本公开实施例提供的技术方案，通过BIM正向设计的Revit模型提取房型数据，并根据Revit模型中的窗户属性数据生成每个房型的相机点位，将房型数据和相机点位组合成要素信息，基于UE4引擎的数字沙盘对Json格式的要素信息进行解析并计算每个房型的房型体块，并根据相机点位在房型体块中自动创建相机对象；具体地，本公开基于窗户与墙面的关系，利用窗户法向量生成和筛选点位来自动化的生成用于一房一景展示的相机点位，并且提取楼层、房型、房间等信息自动化生成用于一房一景的交互的房型体块。在UE4引擎中建立房型体块与相机点位之间的交互关系，使用户选择房型体块之后，数字沙盘将视角自动移动至房型体块对应的相机对象的位置。本公开能够自动生成相机点位，减少人工手动配置造成的配置效率低以及错误率提升的问题，降低了房景配置的难度，提升了房景展示的效果。

下述为本公开装置实施例，可以用于执行本公开方法实施例。对于本公开装置实施例中未披露的细节，请参照本公开方法实施例。

图4是本公开实施例提供的一种基于数字沙盘的房景展示装置的结构示意图。如图4所示，该基于数字沙盘的房景展示装置包括：

获取模块401，被配置为获取第一建筑信息模型，对第一建筑信息模型对应的模型文件进行处理得到第二建筑信息模型，并将第二建筑信息模型转化为预定格式的模型中间文件；

生成模块402，被配置为对第二建筑信息模型中的每个房型依次进行遍历，得到每个房型对应的房型数据，并基于窗户属性信息生成房型对应的相机点位，将房型数据和相机点位组合成要素信息对象；

加载模块403，被配置为利用预设的数字沙盘对应的引擎加载模型中间文件，以便在数字沙盘中渲染出模型中间文件对应的建筑模型，并对要素信息对象执行解析操作，得到每个房型对应的房型体块；

交互模块404，被配置为建立每个房型的相机点位与房型体块之间的交互关系，当触发针对数字沙盘的建筑模型中的房型体块的选择操作时，将数字沙盘的视角调整为相机点位的视角，以便展示相机点位的视角对应的房景。

在一些实施例中，图4的获取模块401获取模型文件以及模型文件对应的文件名称，根据预设的目标模型文件对应的关键字符串，对模型文件的文件名称依次进行匹配，将成功匹配的模型文件进行加载，得到第二建筑信息模型；其中，目标模型文件为与建筑结构相关的模型文件，第一建筑信息模型以及第二建筑信息模型均为Revit模型。

在一些实施例中，图4的获取模块401将第二建筑信息模型对应的Revit模型转化为以datasmith作为后缀格式的模型中间文件。

在一些实施例中，图4的生成模块402确定第二建筑信息模型中的所有楼层，并以楼层为单位，沿楼层依次对每个楼层中的房型进行遍历，以便提取出每个房型对应的楼层标识、房型标识、外轮廓线、以及标高；根据每个房型中各个房间对应的面积参数，计算每个房型对应的房型面积，基于楼层标识、房型标识、外轮廓线、标高、以及房型面积生成结构化数据，将结构化数据作为房型数据。

在一些实施例中，图4的生成模块402获取每个房型对应的窗户属性信息，根据窗户属性信息确定窗户所对应的墙立面，计算墙立面对应的中心线的平面向量，并根据平面向量确定窗户的法向量；沿窗户的法向量向正负方向分别移动预设距离，得到两个点位坐标，根据点位坐标判断点位是否在外轮廓线内，将属于外轮廓线内的点位坐标作为相机点位。

在一些实施例中，图4的生成模块402根据与每个房型相对应的房型数据和相机点位，为每个房型生成用于表示户型结构以及相机位置的数据结构，并将数据结构导出为Json格式的要素信息对象。

在一些实施例中，预设的数字沙盘对应的引擎采用UE4引擎，图4的加载模块403利用预设的插件将datasmith格式的模型中间文件加载到UE4引擎中，并在UE4引擎中对模型中间文件所对应的建筑模型进行渲染，渲染用于在预先配置的包含楼房外景的数字沙盘中展示建筑模型对应的效果。

在一些实施例中，图4的加载模块403对Json格式的要素信息对象进行序列化处理，在序列化处理后的要素信息对象中对房型对应的房型数据进行遍历，根据每个房型对应的外轮廓线和标高，在UE4引擎的三维坐标系中构建每个房型所对应的房型体块。

在一些实施例中，图4的交互模块404获取房型的相机点位对应的点位坐标，以及房型体块的标识，建立相机点位的点位坐标与房型体块的标识之间的交互关系，交互关系用于表示当点击房型体块时，相机点位将按照预设的交互方式在UE4引擎的建筑模型中进行旋转或移动。

在一些实施例中，图4的交互模块404根据每个房型对应的相机点位以及窗户的法向量，在UE4引擎的建筑模型中对每个房型的窗户生成一个相机对象，当触发针对数字沙盘的建筑模型中的房型体块的选择操作时，将数字沙盘对应的当前视角移动到相机对象对应的视角。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本公开实施例的实施过程构成任何限定。

图5是本公开实施例提供的电子设备5的结构示意图。如图5所示，该实施例的电子设备5包括：处理器501、存储器502以及存储在该存储器502中并且可以在处理器501上运行的计算机程序503。处理器501执行计算机程序503时实现上述各个方法实施例中的步骤。或者，处理器501执行计算机程序503时实现上述各装置实施例中各模块/单元的功能。

示例性地，计算机程序503可以被分割成一个或多个模块/单元，一个或多个模块/单元被存储在存储器502中，并由处理器501执行，以完成本公开。一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序503在电子设备5中的执行过程。

电子设备5可以是桌上型计算机、笔记本、掌上电脑及云端服务器等电子设备。电子设备5可以包括但不仅限于处理器501和存储器502。本领域技术人员可以理解，图5仅仅是电子设备5的示例，并不构成对电子设备5的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如，电子设备还可以包括输入输出设备、网络接入设备、总线等。

处理器501可以是中央处理单元（Central Processing Unit，CPU），也可以是其它通用处理器、数字信号处理器（Digital Signal Processor，DSP）、专用集成电路（Application Specific Integrated Circuit，ASIC）、现场可编程门阵列（Field-Programmable Gate Array，FPGA）或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器502可以是电子设备5的内部存储单元，例如，电子设备5的硬盘或内存。存储器502也可以是电子设备5的外部存储设备，例如，电子设备5上配备的插接式硬盘，智能存储卡（Smart Media Card，SMC），安全数字（Secure Digital，SD）卡，闪存卡（Flash Card）等。进一步地，存储器502还可以既包括电子设备5的内部存储单元也包括外部存储设备。存储器502用于存储计算机程序以及电子设备所需的其它程序和数据。存储器502还可以用于暂时地存储已经输出或者将要输出的数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本公开的范围。

在本公开所提供的实施例中，应该理解到，所揭露的装置/计算机设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/计算机设备实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本公开实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，计算机程序可以存储在计算机可读存储介质中，该计算机程序在被处理器执行时，可以实现上述各个方法实施例的步骤。计算机程序可以包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器（Read-Only Memory，ROM）、随机存取存储器（Random Access Memory，RAM）、电载波信号、电信信号以及软件分发介质等。需要说明的是，计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如，在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

以上实施例仅用以说明本公开的技术方案，而非对其限制；尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本公开各实施例技术方案的精神和范围，均应包含在本公开的保护范围之内。