CN112546633B - 虚拟场景的处理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请提供一种虚拟场景的处理方法、装置、设备及存储介质，属于图像处理技术领域。该方法包括：将第一引擎中构建的场景模型传输至第二引擎中，其中，第一引擎为场景模型的运行引擎；响应于在第二引擎中展示的场景模型中构建的目标光源，在第二引擎的场景模型中进行打光及烘焙，以得到打光及烘焙后的贴图；将打光及烘焙后的贴图发送至第一引擎。本申请的实施例中，由第二引擎专门来处理打光及烘焙，可以提高对打光、烘焙处理的效率，进而整体提升场景的处理效率。

Description

虚拟场景的处理方法、装置、设备及存储介质

技术领域

本申请涉及图像处理技术领域，具体而言，涉及一种虚拟场景的处理方法、装置、设备及存储介质。

背景技术

在游戏场景制作过程中，打光和烘焙奠定了场景的整体氛围，是一个十分关键的步骤。

目前，游戏场景制作过程中，模型摆放、打光和烘焙通常是在同一个引擎中进行。首先根据原画放置各类模型资源，并由工作人员根据氛围设定去打光。

然而，对于一些较为复杂的打光过程，例如：面光源打光，难以达到实时帧率，导致了相关工作人员不能及时预览，因此处理效率较为低下。

发明内容

本申请的目的在于提供一种虚拟场景的处理方法、装置、设备及存储介质，可以提升游戏场景的处理效率。

本申请实施例的一方面，提供一种虚拟场景的处理方法，包括：

将第一引擎中构建的场景模型传输至第二引擎中，其中，第一引擎为场景模型的运行引擎；

响应于在第二引擎中展示的场景模型中构建的目标光源，在第二引擎的场景模型中进行打光及烘焙，以得到打光及烘焙后的贴图；

将打光及烘焙后的贴图发送至第一引擎。

可选地，将第一引擎中构建的场景模型传输至第二引擎中，包括：

将第一引擎中构建的场景模型转换为第二引擎可识别格式，获取转换后的场景模型，其中，场景模型包括下述至少一项模型参数：尺寸、位置、朝向；

根据转换后的场景模型，在第二引擎中构建并展示与第一引擎中一致的场景模型。

可选地，将打光及烘焙后的贴图发送至第一引擎，包括：

将打光及烘焙后的贴图转换为第一引擎可识别格式，获取转换后的贴图，贴图包括下述至少一项模型参数：尺寸、位置、朝向。

可选地，将打光及烘焙后的贴图发送至第一引擎之后，还包括：

响应于场景运行指令，展示打光及烘焙后的场景。

可选地，响应于在第二引擎中展示的场景模型中构建的目标光源，在第二引擎的场景模型中进行打光及烘焙，以得到打光及烘焙后的贴图，包括：

响应于在第二引擎中展示的场景模型中构建的目标光源，获取目标光源的属性信息，属性信息包括：光源的类型、位置；

根据目标光源的属性信息、以及对应的打光算法，获取打光后的场景；

对打光后的场景进行烘焙，以得到打光及烘焙后的贴图。

可选地，目标光源的类型为面光源打光。

可选地，根据目标光源的属性信息、以及对应的打光算法，获取打光后的场景，包括：

根据目标光源的属性信息、以及对应的打光算法，获取目标光源的类型对应的打光信息，打光信息包括下述一种或多种：辐射方向、辐射能量强度、辐射距离；

根据打光信息，生成打光后的场景。

可选地，根据目标光源的属性信息、以及对应的打光算法，获取打光后的场景之后，还包括：

基于第二引擎，生成实时预览的打光后的场景。

本申请实施例的另一方面，提供一种虚拟场景的处理装置，包括：传输模块、打光及烘焙模块；

传输模块，用于将第一引擎中构建的场景模型传输至第二引擎中，其中，第一引擎为场景模型的运行引擎；

打光及烘焙模块，用于响应于在第二引擎中展示的场景模型中构建的目标光源，在第二引擎的场景模型中进行打光及烘焙，以得到打光及烘焙后的贴图；

传输模块，还用于将打光及烘焙后的贴图发送至第一引擎。

可选地，传输模块，具体用于将第一引擎中构建的场景模型转换为第二引擎可识别格式，获取转换后的场景模型，其中，场景模型包括下述至少一项模型参数：尺寸、位置、朝向；根据转换后的场景模型，在第二引擎中构建并展示与第一引擎中一致的场景模型。

可选地，传输模块，具体还用于将打光及烘焙后的贴图转换为第一引擎可识别格式，获取转换后的贴图，贴图包括下述至少一项模型参数：尺寸、位置、朝向。

可选地，该装置还包括：展示模块；展示模块，用于响应于场景运行指令，展示打光及烘焙后的场景。

可选地，打光以烘焙模块，具体用于响应于在第二引擎中展示的场景模型中构建的目标光源，获取目标光源的属性信息，属性信息包括：光源的类型、位置；根据目标光源的属性信息、以及对应的打光算法，获取打光后的场景；对打光后的场景进行烘焙，以得到打光及烘焙后的贴图。

可选地，该装置中，目标光源的类型为面光源打光。

可选地，打光及烘焙模块，还用于根据目标光源的属性信息、以及对应的打光算法，获取目标光源的类型对应的打光信息，打光信息包括下述一种或多种：辐射方向、辐射能量强度、辐射距离；根据打光信息，生成打光后的场景。

可选地，打光及烘焙模块，还用于基于第二引擎，生成实时预览的打光后的场景。

本申请实施例的另一方面，提供一种计算机设备，包括：存储器、处理器，存储器中存储有可在处理器上运行的计算机程序，处理器执行计算机程序时，实现上述虚拟场景的处理方法的步骤。

本申请实施例的另一方面，提供一种存储介质，存储介质上存储有计算机程序，该计算机程序被处理器执行时，实现上述虚拟场景的处理方法的步骤。

本申请实施例的有益效果包括：

本申请实施例提供的虚拟场景的处理方法、装置、设备及存储介质中，可以将第一引擎中构建的场景模型传输至第二引擎中，并响应于在第二引擎中展示的场景模型中构建的目标光源，在第二引擎的场景模型中进行打光及烘焙，以得到打光及烘焙后的贴图，进而可以将打光及烘焙后的贴图发送至第一引擎。其中，通过采用第二引擎进行打光及烘焙处理，可以减少第一引擎的工作量，另外，由第二引擎专门来处理打光及烘焙，可以提高对打光、烘焙处理的效率，且可以在第二引擎中实时预览，提高工作人员的工作效率，进而整体提升场景的处理效率。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的第一应用场景的场景示意图；

图2为本申请实施例提供的第二应用场景的场景示意图；

图3为本申请实施例提供的虚拟场景的处理方法的流程示意图；

图4为本申请实施例提供的虚拟场景的处理方法的流程示意图；

图5为本申请实施例提供的虚拟场景的处理方法的流程示意图；

图6为本申请实施例提供的虚拟场景的处理方法的流程示意图；

图7为本申请实施例提供的点光打光的场景示意图；

图8为本申请实施例提供的平行光打光的场景示意图；

图9为本申请实施例提供的聚光灯打光的场景示意图；

图10为本申请实施例提供的面光源打光的场景示意图；

图11为本申请实施例提供的虚拟场景的处理装置的结构示意图；

图12为本申请实施例提供的虚拟场景的处理装置的另一结构示意图；

图13为本申请实施例提供的计算机设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

在本申请的描述中，需要说明的是，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

为了方便对本申请中相关内容进行更加清晰的解释，下面对本申请中采用的几个本领域中使用的词语进行相关的解释。

引擎：本申请实施例中提供的引擎可以是游戏引擎或者是应用程序的相关引擎，可以是一些已编写好的可编辑电脑游戏系统或者一些交互式实时图像应用程序的核心组件。通过引擎可以让游戏设计者或者应用程序的开发者提供各种编写相关程序所需的各种工具，可以让游戏设计者或者应用程序的开发者能更加容易和快速地做出相关程序设置。需要说明的是，每个引擎主要应用于某一个或者某一类相关信息的处理，也即是说，对于不同的引擎而言，其处理不同类型的信息的速度是不同的，例如：游戏运行引擎，可以是用于支持某一游戏进程的引擎，其对于其他方面的支持能力相对较弱；渲染引擎，可以是专门用于对某些图像或者视频的进行渲染的引擎，若将该引擎用于支持某一游戏进程，则不能达到预期的支持效果。

打光：本申请实施例中提供的打光可以是在某一多维场景中的某一位置设置一个光源，并根据该光源的相关属性信息，实现对该多维场景中的元素的光照情况进行设置，以三维场景为例，若该场景中布置了可以发光的相关元素(台灯、电视、手电筒等)，则可以对这些可以发光的相关元素的发光位置设置光源进而实现打光。

烘焙：本申请实施例中提供的烘焙可以是在打光完成后对多维场景进行渲染的过程，打光的过程通常是可以调节的，工作人员根据需求进行打光调整，调整达到满意的效果后，可以进行烘焙，通过烘焙，可以使多维场景的展示图像更加美观或者更加真实，在实际工作的过程中，可以分别对每一个对象打光后进行烘焙，也可以对该场景中所有的对象打光后进行烘焙，在此不作限制。

需要说明的是，在第一引擎为游戏正常运行时的引擎的情况下，第一引擎自身也可以对场景模型进行打光及烘焙，而由于每个引擎运行的工作量的影响以及相对可支持处理的内容不同，第一引擎主要用于对游戏运行的支持，如果同一个引擎即负责场景构建、支持，还同时进行打光、烘焙的话，效率相对较差，导致了工作人员不能实时观察到对该场景模型进行打光、烘焙的处理情况。也即是说，工作人员在制作场景时可能只能靠经验和直觉来操作，通常会与期望的结果偏差很多，造成更多的返工和迭代，浪费人力和时间成本、效率低下。

下面通过具体的实施例来解释本申请实施例中提供的其中一种可以应用的场景。

图1为本申请实施例提供的第一应用场景的场景示意图，请参照图1，第一应用场景可以是处于不同计算机设备中的第一引擎和第二引擎。

可选地，第一引擎设置于第一计算机设备110中，第二引擎设置于第二计算机设备120中，第一计算机设备110可以与第二计算机设备120通讯连接，第一计算机设备110和第二计算机设备120可以是电脑，也可以是服务器或者其他类型的计算处理设备。

可选地，第一计算机设备110和第二计算机设备120中可以分别设置有进行同步的操作软件，工作人员可以通过操作软件控制第一引擎和第二引擎的执行相关工作。

需要说明的是，对于第一应用场景，可以适用于游戏制作的过程，场景模型制作的相关工作人员可以使用第一计算机设备110，通过第一引擎对场景模型执行相关的工作；打光烘焙的相关工作人员可以使用第二计算机设备120，通过第二引擎对场景模型中的相关元素进行打光以及烘焙处理，可以实现不同类型工作人员的工作分配，进而提高工作效率。

图2为本申请实施例提供的第二应用场景的场景示意图，请参照图2，第二应用场景可以是处于同一计算机设备中的第一引擎的第二引擎。

可选地，计算机设备中还可以设置有进行同步的操作软件，工作人员可以通过操作软件控制第一引擎和第二引擎进行数据的交互。工作人员操作第一引擎是打开第一引擎，同步完成后，操作第二引擎时打开第二引擎即可，两个引擎彼此独立，互补干扰。

需要说明的是，对于第二应用场景，可以适用于工程检查的过程，工作人员在同一台计算机设备上进行检查，当通过第一引擎检查到某位置需要重新进行打光和烘焙的情况下，可以通过第二引擎进行相应的操作处理。

下面通过具体的实施例来解释本申请实施例中提供的虚拟场景的处理方法的具体实施过程。

图3为本申请实施例提供的虚拟场景的处理方法的流程示意图，请参照图3，该方法包括：

S310：将第一引擎中构建的场景模型传输至第二引擎中。

其中，第一引擎为场景模型的运行引擎。

可选地，第一引擎可以是游戏运行时实际使用的引擎，场景模型可以用于在游戏或其他图像软件内展示的场景，并作为运行时的载体，其中，场景主要制作是在第一引擎中进行。例如，在第一引擎中，工作人员可以根据原画设计来布置场景中的模型、地形、植被等元素。在这个第一引擎中，工作人员还可以检查场景模型的相关设置的是否正确，以及是否充分利用了场景的整体空间等。

场景模型可以在第一引擎中预设构建好后，传输至第二引擎中。

S320：响应于在第二引擎中展示的场景模型中构建的目标光源，在第二引擎的场景模型中进行打光及烘焙，以得到打光及烘焙后的贴图。

可选地，第二引擎是专门用来进行打光和烘焙的引擎，将场景模型传输至第二引擎后，可以在第二引擎中展示该场景模型，第二引擎中可以预设有多种构建好的光源，工作人员可以根据实际需求选择其中的一种或者多种作为目标光源，也可以根据实际需要建立符合需求的新的目标光源。其中，目标光源可以是不同的打光光源。

可以根据上述确定的目标光源在第二引擎的场景模型中进行打光及烘焙，进而以得到打光及烘焙后的贴图。

其中，打光及烘焙后的贴图可以是在进行打光和烘焙过程之后，得到的场景模型中某一个或者多个位置的图像，每个图像的大小可以根据对该位置打光及烘焙的范围来进行确定。

S330：将打光及烘焙后的贴图发送至第一引擎。

进而，第一引擎收到打光及烘焙后的贴图后，可以在原来构建的场景模型中进行叠加显示，那么就可以看到打光及烘焙后的完整场景了。

本申请实施例提供的虚拟场景的处理方法中，可以将第一引擎中构建的场景模型传输至第二引擎中，并响应于在第二引擎中展示的场景模型中构建的目标光源，在第二引擎的场景模型中进行打光及烘焙，以得到打光及烘焙后的贴图，进而可以将打光及烘焙后的贴图发送至第一引擎。其中，通过采用第二引擎进行打光及烘焙处理，可以减少第一引擎的工作量，另外，由第二引擎专门来处理打光及烘焙，可以提高对打光、烘焙处理的效率，且可以在第二引擎中实时预览，提高工作人员的工作效率，进而整体提升场景的处理效率。

图4为本申请实施例提供的虚拟场景的处理方法的流程示意图，请参照图4，将第一引擎中构建的场景模型传输至第二引擎中，包括：

S410：将第一引擎中构建的场景模型转换为第二引擎可识别格式，获取转换后的场景模型。

其中，场景模型包括下述至少一项模型参数：尺寸、位置、朝向。

可选地，场景模型模型参数中的尺寸可以包括场景内每个元素在模型中的尺寸大小以及整个场景模型的尺寸大小；位置可以包括场景内每个元素在模型中的具体位置，例如可以通过模型坐标的方式对每个元素进行记录；朝向可以包括场景内每个元素在模型中的方向，例如：场景中布置了一个沙发，可以该沙发的正面朝向的方向作为该元素在模型中的方向。

可选地，可以将上述场景模型中的需要传输至第二引擎的模型参数提取出来，并可以将这些模型参数转换为第二引擎可识别格式，进而得到转换后的场景模型。具体地，可以由同步软件来完成转换。

需要说明的是，第一引擎、第二引擎都有自己的私有格式，可选地，转换过程中，获取第一引擎的场景模型后，先转换为中间格式，可以包括：顶点信息、索引信息等，在传输到第二引擎后，再由中间格式转换为第二引擎可识别格式。其中，顶点信息可以包括场景内每个元素的顶点位置；索引信息可以包括场景内每个元素的索引关系。

转换后的场景模型中，包括了所有需要传输至第二引擎的模型参数，这些模型参数为第二引擎可识别的模型参数。

例如：当需要对某一游戏场景进行打光及烘焙处理时，可以先根据工作人员的选择，确定该游戏场景中需要进行打光及烘焙的具体一个或者多个场景，进而将这些场景中相关的尺寸、位置、方向等模型参数转换为第二引擎可识别格式，进而得到转换后的场景模型。

S420：根据转换后的场景模型，在第二引擎中构建并展示与第一引擎中一致的场景模型。

可选地，得到上述转换后的场景模型后，第二引擎可以对该转换后的场景模型进行识别处理，进而根据识别的结果构建并展示与第一引擎中一致的场景模型。

需要说明的是，该场景模型中的每个模型参数都与第一引擎中的场景模型中的模型参数相互对应，例如：在第二引擎中通过空间坐标所表示的某一位置的元素，与同样通过相对应空间坐标所表示的某一位置的元素是相互对应的。

可选地，第二引擎可以是用于打光及烘焙的引擎，其内设置有符合烘焙要求的相关材质，例如：基础色贴图、自发光贴图和法线贴图等材质的基本构成元素。第二引擎与第一引擎的材质不完全相同，第二引擎中只需要设置有可以实现打光及烘焙的过程的相关材质即可，不需要包含第一引擎中的全部材质。

需要说明的是，预设在计算机中的传输软件可以通过窗口编辑器的方式执行相关工作，在该窗口编辑器中，可以预设有多个工作相关的按键，例如同步按键，工作人员可以通过点击同步按键的方式来实现上述S410-S420的步骤。

可选地，将打光及烘焙后的贴图发送至第一引擎，包括：

将打光及烘焙后的贴图转换为第一引擎可识别格式，获取转换后的贴图。

其中，贴图包括下述至少一项模型参数：尺寸、位置、朝向。

可选地，贴图的模型参数中的尺寸可以包括该贴图在模型中的尺寸；位置可以包括该贴图在的模型中的具体位置，例如可以通过模型坐标的方式对每个贴图的具体位置进行记录；朝向可以包括该贴图在模型中的方向，例如：该贴图为电视对应的贴图，可以该电视的屏幕朝向的方向作为该贴图在模型中的方向。

需要说明的是，通过打光以及烘焙之后，可以获取多个贴图，可以将这些贴图的模型参数全部转换为第一引擎可以识别的格式，然后使第一引擎得到转换后的贴图。可选地，转换过程中，获取第二引擎生成的贴图后，先转换为中间格式，可以包括贴图的每个像素的颜色值，在传输到第一引擎后，再由中间格式转换为第一引擎可识别格式。

需要说明的是，预设在计算机中的传输软件也可以通过窗口编辑器的方式上述过程，在该窗口编辑器中，还可以预设有第二同步按键，工作人员可以通过点击第二同步按键的方式来实现上述将打光及烘焙后的贴图转换为第一引擎可识别格式，获取转换后的贴图的步骤。

第一引擎得到转换后的贴图后，可以展示打光及烘焙后的场景，下面通过具体的实施例来解释本申请实施例中提供的展示打光及烘焙后的场景的具体实施过程。

可选地，将打光及烘焙后的贴图发送至第一引擎之后，还包括：

响应于场景运行指令，展示打光及烘焙后的场景。

其中，场景运行指令可以是工作人员输入的指令，或者可以是用户实际操作游戏过程中运行游戏的指令。接收到场景运行指令后，可以将上述转换后的贴图展示于其对应的位置，可以将第一引擎中初始场景模型的对应位置删除，替换为打光及烘焙后的贴图，也可以将打光及烘焙后的贴图叠加于该位置上，在此不作限制。

例如：初始场景模型的某一位置设置有一个台灯，在第二引擎进行打光及烘焙处理过程之后，该台灯被渲染了灯光的效果，并且得到了该台灯对应的贴图，第一引擎获得了格式转换后的贴图之后，可以将被渲染了灯光效果的贴图覆盖于第一引擎中初始场景模型的对应位置，其模型参数可以未发生过改变，进而可以展示被覆盖后的场景模型，也即是上述打光及烘焙后的场景。

需要说明的是，第一引擎得到的打光及烘焙后的贴图不止一张，展示的打光及烘焙后的场景中，可以是包括有多个覆盖了打光及烘焙后的贴图的场景模型。

可选地，第一引擎获取的是打光及烘焙后的贴图，贴图的存储空间相对整个模型而言较小，因此，第一引擎可以很快地实现对贴图的获取，进而显示打光及烘焙后的场景模型。

下面通过具体的实施例来解释本申请的实施例中提供的打光烘焙处理的具体实施过程。

图5为本申请实施例提供的虚拟场景的处理方法的流程示意图，请参照图5，上述响应于在第二引擎中展示的场景模型中构建的目标光源，在第二引擎的场景模型中进行打光及烘焙，以得到打光及烘焙后的贴图，包括：

S510：响应于在第二引擎中展示的场景模型中构建的目标光源，获取目标光源的属性信息。

其中，属性信息包括：光源的类型、位置。

可选地，在构建目标光源的过程中，可以根据工作人员的操作确定使用的目标光源的类型，对于不同类型的光源，其光照的辐射方式不尽相同，工作人员可以根据第二引擎中展示的场景模型选择其中需要进行打光和烘焙的位置，例如：场景模型中包括台灯、沙发、电视等多个元素，工作人员可以根据场景的布置需求结合每个元素的实际作用选择对其中的某一个元素或者多个元素进行打光，以上述场景模型中的元素为例，台灯、电视均可以作为打光和烘焙的位置，而结合实际情况，台灯与电视的光源的类型并不相同，因此，可以基于实际情况选择与每个元素匹配的目标光源的类型。

S520：根据目标光源的属性信息、以及对应的打光算法，获取打光后的场景。

可选地，第二引擎中可以预设有多种类型的目标光源属性信息，工作人员根据场景模型中的每个元素确定了目标光源的属性信息后，可以选择对应的属性信息，相应地，第二引擎中还可以存储有每种光源的属性信息对应的打光算法，对于不同位置、不同光源的类型的目标光源而言，其对应的打光算法也不尽相同。

确定上述目标光源的属性信息后，可以根据第二引擎中存储的该目标光源的属性信息以及对应的打光算法进行打光，进而可以获取打光后的场景。

S530：对打光后的场景进行烘焙，以得到打光及烘焙后的贴图。

可选地，获取到打光后的场景后可以对该打光后的场景进行烘焙，进而得到打光及烘焙后的贴图。

需要说明的是，打光及烘焙后的贴图可以是整个场景被烘焙后的贴图，也可以是该场景中某个部分被烘焙后的贴图。以某个部分被烘焙后的贴图为例，在打光的过程中，某一光源所辐射的整个范围都会产生打光的效果，相应的，烘焙后得到的贴图也不仅仅是某一光源对应的元素的贴图，而是整个光源辐射范围内所有元素对应的贴图。例如：当以电视机作为光源进行打光和烘焙时，电视机投射到地面以及墙面的范围内都会受到打光效果的影响，因此，该目标光源对应的打光及烘焙后的贴图，不仅仅包括电视机本身，还可以包括电视机打光效果覆盖范围内的所有元素，例如墙面、地面等。相应地，若是整个场景被烘焙后的贴图，则该贴图的尺寸等即为整个场景的尺寸。

下面通过具体的实施例来解释本申请实施例中提供的获取打光后的场景地具体实施过程。

图6为本申请实施例提供的虚拟场景的处理方法的流程示意图，请参照图6，根据目标光源的属性信息、以及对应的打光算法，获取打光后的场景，包括：

S610：根据目标光源的属性信息、以及对应的打光算法，获取目标光源的类型对应的打光信息。

其中，打光信息包括下述一种或多种：辐射方向、辐射能量强度、辐射距离。

可选地，打光信息中的辐射方向可以是该目标光源发出光照的方向，辐射方向可以不止一个；打光信息中的辐射能量强度可以是该目标光源光照的强度，光照越强，对应的亮度越高；打光信息中的辐射距离可以是该目标光源发出的光照的距离范围。

可以根据光源的属性信息、以及对应的打光算法来计算获得上述辐射方向、辐射能量强度、辐射距离等打光信息。

例如：若根据目标光源的属性信息，确定对场景模型中的某一位置的台灯进行打光，则可以采用上述台灯对应的目标光源类型确定该等光照计算的对应打光算法，以此进行计算得到台灯光照的辐射方向、辐射能量强度、辐射距离。

可选地，打光信息中还可以包括：打光的颜色、打光的亮度等，这些光照因素与光源的属性信息没有直接关系，工作人员可以根据场景中的实际情况或者结合美观角度考虑进行对应的设置，在此不作限制。

S620：根据打光信息，生成打光后的场景。

需要说明的是，得到上述打光信息后可以通过第二引擎对该场景模型中对应位置进行打光处理，进而生成打光后的场景。

例如：继续以上述台灯打光为例，计算得到了台灯光照的辐射方向、辐射能量强度、辐射距离之后，可以按照上述打光信息，在对应的辐射方向上按照对应的辐射能量强度、辐射距离设置对应的光照效果实现打光，进而得到打光后的台灯所在的场景。

下面通过具体的实施例来解释本申请实施例中提供的光源的类型。

可选地，目标光源的类型为面光源打光。

除了面光源打光外，目标光源的类型还可以包括：点光打光、平行光打光、聚光灯打光等多种类型。

需要说明的是，点光打光可以是以某一点为光源的打光方式，其辐射的方向可以是所有方向，它在场景中表示为一个点，均匀地朝各个方向辐射能量，能量在传播过程中根据与光源的距离平方进行衰减；平行光打光可以是单一方向上的辐射的打光方式，对应于现实生活中的太阳光，平行光没有位置信息，只有方向信息，平行光朝单一方向辐射能量，在光线传播过程中能量不发生衰减；聚光灯打光是以某一点为光源的打光方式，与点光源不同的是，聚光灯只能朝一定方向辐射能量，而不是朝各个方向均匀辐射能量，其中各个方向辐射的能量大小也可能是不同的；面光源打光可以是以某一个平面或者曲面作为光源的打光方式，面光源有体积，对于场景中某个点，从面光源可以有无数的方向达到该位置点，因此求解面光源的光照计算需要进行球面积分。

可选地，点光、平行光和聚光灯都属于精确光源。它们的光照计算不涉及到积分求解，可以实时快速求解，与精确光源不同的是，面光源的求解过程涉及球面积分等复杂运算。具体的计算方式可以根据面光源的体积以及光照的辐射方向等因素进行积分叠加运算，在此不作限制。

下面通过多个具体的实施例来分别解释本申请实施例中提供的多种类型的光源打光。

图7为本申请实施例提供的点光打光的场景示意图，请参照图7，图7中所示的为点光打光的具体场景，在场景模型中，点光打光可以应用于场景中的某一发光的光点，点光源710可以是该场景模型中的任意一个点，以该点作为光的起点，均匀地向每个方向进行辐射。

可选地，对于点光打光，其打光信息中的辐射方向即为所有方向，辐射能量强度在传播过程中根据与光源的距离平方进行衰减，辐射的最大距离即为辐射能量强度衰减至0的位置。

图8为本申请实施例提供的平行光打光的场景示意图，请参照图8，图8中所示的为平行光打光的具体场景，在该场景模型中，平行光打光可以应用于场景中的阳光，光源的位置不可见，是朝向某一固定方向的无衰减的光源。

可选地，对于平行光打光，其打光信息中的辐射方向即为特定的某一方向，辐射能量强度在传播过程中保持不变，不会进行衰减，辐射的最大距离没有限制，直至该光线被墙面或者底面遮挡住为止。

图9为本申请实施例提供的聚光灯打光的场景示意图，请参照图9，图9中所示的为聚光灯打光的具体场景，在该场景模型中，聚光灯打光可以应用于场景中的台灯、吊灯等被限制了方向的点光源，聚光灯光源910可以是该场景模型中的任意位置，对于不同的方向，聚光灯辐射的能量大小也有所不同。

可选地，对于聚光灯打光，其打光信息中的辐射方向即为被限定的某一或者某几个方向，辐射能量强度与点光源的衰减方式相同，但是对于不同的辐射方向，其衰减的程度有所不同，辐射的最大距离即为辐射能量强度衰减至0的位置。

图10为本申请实施例提供的面光源打光的场景示意图，请参照图10，图10中所示的为面光源打光的具体场景，在该场景模型中，面光源打光可以应用于场景中电视、电脑等具有较大面积、体积的光源，面光源1010可以是该场景模型中的任意位置，对于场景中某个点，从面光源可以有无数的方向达到该位置点，因此求解面光源的光照计算需要进行球面积分。

可选地，面光源打光即为前述过程中计算程度较为复杂的打光方式，对于面光源这类计算程度较为复杂的打光方式，通过第二引擎对其进行打光以及烘焙，得到对应的打光及烘焙后的贴图后传输给第一引擎，可以高效地进行打光操作，弥补第一引擎工作的不足，节省美术制作成本，提升场景烘焙效果。

下面通过具体的实施例来解释本申请实施例中提供的虚拟场景的处理方法另一具体实施过程。

可选地，根据光源的属性信息、以及对应的打光算法，获取打光后的场景之后，还包括：

基于第二引擎，生成实时预览的打光后的场景。

需要说明的是，在获取打光后的场景之后，可以通过第二引擎对该打光后的场景进行展示，并且该打光后的场景可以被实时预览，工作人员可以通过第二引擎中生成的实时预览的打光后的场景进行相关的处理，例如，调整打光的方向、调整打光的范围、调整光照的颜色等，进而可以使得工作人员更加简单、快速、实时地得到每次调整后的打光情况。

下述对用以执行的本申请所提供的虚拟场景的处理方法对应的装置、设备及存储介质等进行说明，其具体的实现过程以及技术效果参见上述，下述不再赘述。

图11为本申请实施例提供的虚拟场景的处理装置的结构示意图，请参照图11，该装置包括：传输模块100、打光及烘焙模块200；

传输模块100，用于将第一引擎中构建的场景模型传输至第二引擎中，其中，第一引擎为场景模型的运行引擎；

打光及烘焙模块200，用于响应于在第二引擎中展示的场景模型中构建的目标光源，在第二引擎的场景模型中进行打光及烘焙，以得到打光及烘焙后的贴图；

传输模块100，还用于将打光及烘焙后的贴图发送至第一引擎。

可选地，传输模块100，具体用于将第一引擎中构建的场景模型转换为第二引擎可识别格式，获取转换后的场景模型，其中，场景模型包括下述至少一项模型参数：尺寸、位置、朝向；根据转换后的场景模型，在第二引擎中构建并展示与第一引擎中一致的场景模型。

可选地，传输模块100，具体还用于将打光及烘焙后的贴图转换为第一引擎可识别格式，获取转换后的贴图，贴图包括下述至少一项模型参数：尺寸、位置、朝向。

图12为本申请实施例提供的虚拟场景的处理装置的另一结构示意图，请参照图12，该装置还包括：展示模块300；展示模块300，用于响应于场景运行指令，展示打光及烘焙后的场景。

可选地，打光以烘焙模块200，具体用于响应于在第二引擎中展示的场景模型中构建的目标光源，获取目标光源的属性信息，属性信息包括：光源的类型、位置；根据目标光源的属性信息、以及对应的打光算法，获取打光后的场景；对打光后的场景进行烘焙，以得到打光及烘焙后的贴图。

可选地，该装置中，目标光源的类型为面光源打光。

可选地，打光及烘焙模块200，还用于根据目标光源的属性信息、以及对应的打光算法，获取光源的类型对应的打光信息，打光信息包括下述一种或多种：辐射方向、辐射能量强度、辐射距离；根据打光信息，生成打光后的场景。

可选地，打光及烘焙模块200，还用于基于第二引擎，生成实时预览的打光后的场景。

上述装置用于执行前述实施例提供的方法，其实现原理和技术效果类似，在此不再赘述。

以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(Application Specific Integrated Circuit，简称ASIC)，或，一个或多个微处理器(digital singnal processor，简称DSP)，或，一个或者多个现场可编程门阵列(Field Programmable Gate Array，简称FPGA)等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(CentralProcessing Unit，简称CPU)或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统(system-on-a-chip，简称SOC)的形式实现。

图13为本申请实施例提供的计算机设备的结构示意图，请参照图13，该计算机设备，该计算机设备可以是上述第一应用场景中的第一计算机设备和第二计算机设备，也可以是第二应用场景中的计算机设备，该计算机设备包括：存储器410、处理器420，存储器410中存储有可在处理器420上运行的计算机程序，处理器420执行计算机程序时，实现上述虚拟场景的处理方法的步骤。

本申请实施例的另一方面，还提供一种存储介质，存储介质上存储有计算机程序，该计算机程序被处理器执行时，实现上述虚拟场景的处理方法的步骤。

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

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

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

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本发明各个实施例方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(英文：Read-Only Memory，简称：ROM)、随机存取存储器(英文：Random Access Memory，简称：RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种虚拟场景的处理方法，其特征在于，包括：

将第一引擎中构建的场景模型传输至第二引擎中，其中，所述第一引擎为所述场景模型的运行引擎；

响应于在所述第二引擎中展示的所述场景模型中构建的目标光源，在所述第二引擎的所述场景模型中进行打光及烘焙，以得到打光及烘焙后的贴图；

将所述打光及烘焙后的贴图发送至所述第一引擎，其中，所述第一引擎收到打光及烘焙后的贴图后，在构建的场景模型中进行叠加显示；

所述将所述打光及烘焙后的贴图发送至所述第一引擎，包括：

将所述打光及烘焙后的贴图转换为所述第一引擎可识别格式，获取转换后的贴图，所述贴图包括下述至少一项模型参数：尺寸、位置、朝向。

2.如权利要求1所述的方法，其特征在于，所述将第一引擎中构建的场景模型传输至第二引擎中，包括：

将第一引擎中构建的场景模型转换为所述第二引擎可识别格式，获取转换后的场景模型，其中，所述场景模型包括下述至少一项模型参数：尺寸、位置、朝向；

根据所述转换后的场景模型，在所述第二引擎中构建并展示与所述第一引擎中一致的场景模型。

3.如权利要求1所述的方法，其特征在于，所述将所述打光及烘焙后的贴图发送至所述第一引擎之后，还包括：

响应于场景运行指令，展示打光及烘焙后的场景。

4.如权利要求1所述的方法，其特征在于，所述响应于在所述第二引擎中展示的所述场景模型中构建的目标光源，在所述第二引擎的所述场景模型中进行打光及烘焙，以得到打光及烘焙后的贴图，包括：

响应于在所述第二引擎中展示的所述场景模型中构建的目标光源，获取所述目标光源的属性信息，所述属性信息包括：光源的类型、位置；

根据所述目标光源的属性信息、以及对应的打光算法，获取打光后的场景；

对所述打光后的场景进行烘焙，以得到打光及烘焙后的贴图。

5.如权利要求4所述的方法，其特征在于，所述目标光源的类型为面光源打光。

6.如权利要求4或5所述的方法，其特征在于，所述根据所述目标光源的属性信息、以及对应的打光算法，获取打光后的场景，包括：

根据所述目标光源的属性信息、以及对应的打光算法，获取所述目标光源的类型对应的打光信息，所述打光信息包括下述一种或多种：辐射方向、辐射能量强度、辐射距离；

根据所述打光信息，生成所述打光后的场景。

7.如权利要求4或5所述的方法，其特征在于，所述根据所述目标光源的属性信息、以及对应的打光算法，获取打光后的场景之后，还包括：

基于所述第二引擎，生成实时预览的所述打光后的场景。

8.一种虚拟场景的处理装置，其特征在于，包括：传输模块、打光及烘焙模块；

所述传输模块，用于将第一引擎中构建的场景模型传输至第二引擎中，其中，所述第一引擎为所述场景模型的运行引擎；

所述打光及烘焙模块，用于响应于在所述第二引擎中展示的所述场景模型中构建的目标光源，在所述第二引擎的所述场景模型中进行打光及烘焙，以得到打光及烘焙后的贴图；

所述传输模块，还用于将所述打光及烘焙后的贴图发送至所述第一引擎，其中，所述第一引擎收到打光及烘焙后的贴图后，在构建的场景模型中进行叠加显示；

传输模块，具体还用于将打光及烘焙后的贴图转换为第一引擎可识别格式，获取转换后的贴图，贴图包括下述至少一项模型参数：尺寸、位置、朝向。

9.一种计算机设备，其特征在于，包括：存储器、处理器，所述存储器中存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时，实现上述权利要求1至7任一项所述的方法的步骤。

10.一种存储介质，其特征在于，所述存储介质上存储有计算机程序，该计算机程序被处理器执行时，实现权利要求1至7中任一项所述方法的步骤。