CN111833429A - 三维游戏渲染方法、三维引擎、电子设备及可读存储介质 - Google Patents

Abstract

本申请提供了一种三维游戏渲染方法、三维引擎、电子设备及可读存储介质，三维游戏渲染方法包括：获取至少两种协议版本的、包括渲染参数的着色程序；将至少两种协议版本的着色程序包括的多个渲染参数缓存为一组全局数据参数组，通过调用应用程序编程接口来更新所述全局数据参数组；根据更新后的所述全局数据参数组进行三维游戏渲染。本申请提供的三维游戏渲染方法通过对渲染参数分组更新，能够实现一次操作批量更新大量的渲染参数，更新效率更高，从而大幅度提高游戏渲染效率；另外，包括渲染参数的着色程序均具备至少两种协议版本，能够在多平台上得到支持，因此渲染后参数跨平台交互操作和执行的顺畅程度更高。

Description

三维游戏渲染方法、三维引擎、电子设备及可读存储介质

技术领域

本申请涉及电子技术领域，具体而言，本申请涉及一种三维游戏渲染方法、三维引擎、电子设备及可读存储介质。

背景技术

三维游戏引擎(下称3D引擎)，是将现实中的物质抽象为多边形或者各种曲线等表现形式，在计算机中进行相关计算并输出最终图像以应用于游戏开发中，3D引擎实际上是多种算法实现的集合。通常，具备数据管理能力、渲染能力和交互能力三个方面的算法集合，就能称为3D引擎。目前，很多游戏是基于H5开发的，H5是HTML5的简称，代指一个开放的网络标准，H5具备可以支持跨平台操作、自适应屏幕、支持多媒体、互动操作、实时更新等特点。

对于3D引擎的渲染能力而言，现有技术当中3D引擎对于全局参数(Uniform参数)的更新是独立进行的，而Uniform参数众多，会大量挤占计算机计算资源，导致渲染效率低下。为适应H5平台的特点，尤其需要提高3D引擎的渲染效率。另外，由于需要适应H5平台可支持跨平台操作的特点，实际的游戏开发时，需要考虑到材质系统在多平台上的顺畅运行，现有技术当中，多采用格式转换工具实现多平台支持，然而这种方式容易造成数据丢失，导致渲染后的参数跨平台交互操作和执行时出现不顺畅的问题。

发明内容

本申请的目的旨在至少能解决上述的技术缺陷之一，特别是三维引擎渲染效率低下的技术缺陷。

第一方面，提供了一种三维游戏渲染方法，包括下列步骤：

获取至少两种协议版本的、包括渲染参数的着色程序；

将至少两种协议版本的着色程序包括的多个渲染参数缓存为一组全局数据参数组，通过调用应用程序编程接口来更新全局数据参数组；

根据更新后的全局数据参数组进行三维游戏渲染。

在其中一个实施例中，协议版本包括两种三维绘图协议，分别为WebGL1和WebGL2；

获取至少两种协议版本的、包括渲染参数的着色程序，包括：

根据预先检测到的原生平台的类型获取至少两种协议版本的、包括渲染参数的着色程序。

进一步的，原生平台包括Windows平台、Android平台或iOS平台中的任意一种；检测原生平台的类型的方式，包括：

当检测到原生平台接入时，确定原生平台的属性信息，属性信息包括原生平台的类型。

在其中一个实施例中，通过调用应用程序编程接口来更新全局数据参数组的步骤，包括：

根据预定的全局数据缓存更新策略，更新全局数据缓存；

全局数据缓存更新策略包括以下任一项：

每帧图像的渲染对应更新一次；

在每帧图像渲染中依据每个场景更新一次；

在每帧图像渲染中依据每个模型更新一次。

在其中一个实施例中，全局数据参数以Javascript语言开发，更新全局数据参数组之后，该方法还包括：

通过至少一种原生语言对所述全局数据参数组进行编译；

将编译后的全局数据参数组提供至与原生语言对应的原生平台。

进一步的，全局数据参数组为场景节点更新、场景剪裁、骨骼动画更新或粒子更新中的至少一个。

进一步的，将编译后的全局数据参数组提供至与原生语言对应的原生平台的步骤包括：

当检测到原生平台接入时，确定原生平台支持的原生语言；

将通过该原生语言编译得到的全局数据参数组提供至该原生平台。

在其中一个实施例中，更新全局数据参数组之后，该方法还包括：

将更新后的全局数据参数组对应的底层数据封装成面向数据架构的数据结构，面向数据架构的数据结构支持Neon指令和SIMD指令。

进一步的，将更新后的全局数据参数组对应的底层数据封装成面向数据架构的数据结构的步骤，包括：

确定对接的硬件设备的指令类型；

确定到硬件设备的指令类型对应Neon指令，面向数据架构的数据结构存放3个浮点值；

或者，确定到硬件设备的指令类型对应SIMD指令，面向数据架构的数据结构存放4个浮点值。

第二方面，提供了一种三维引擎，包括：

材质模块，用于获取至少两种协议版本的、包括渲染参数的着色程序；

更新模块，用于将至少两种协议版本的着色程序包括的多个渲染参数缓存为一组全局数据参数组，通过调用应用程序编程接口来更新全局数据参数组；

渲染模块，用于根据更新后的全局数据参数组进行三维游戏渲染。

第三方面，提供了一种电子设备，其包括：

处理器、存储器和总线；

总线，用于连接处理器和存储器；

存储器，用于存储操作指令；

处理器，用于通过调用操作指令，使处理器执行如本申请的第一方面所示三维游戏渲染方法。

第四方面，提供了一种计算机可读存储介质，其上存储有计算机程序，存储介质存储有至少一条指令、至少一段程序、代码集或指令集，至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行以实现如本申请第一方面提供的三维游戏渲染方法。

本申请提供的三维游戏渲染方法通过将多个渲染参数缓存为一组，对渲染参数分组更新，能够实现一次操作批量更新大量的渲染参数，更新效率更高，从而大幅度提高游戏渲染效率；另外，包括渲染参数的着色程序均具备至少两种协议版本，能够在多平台上得到支持，因此渲染后参数跨平台交互操作和执行的顺畅程度更高。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。

图1为本申请实施例提供的一种三维游戏渲染方法的流程示意图；

图2为本申请一实施例提供的更新全局数据参数组之后的方法流程示意图；

图3为本申请一实施例提供的将编译后的全局数据参数组提供至与原生语言对应的原生平台的流程示意图；

图4为本申请实施例提供的一种三维引擎的结构示意图；

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

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

首先对本申请涉及的几个名词进行介绍和解释：

着色器(又名着色程序，英文单词Shader)是用来实现图像渲染的，用来替代固定渲染管线的可编辑程序。Shader是一种GPU着色器语言，在写GPU编程时，都是写的Shader程序，Shader计算中用到的外部传递进来的参数都是Uniform参数(全局数据参数)。

全局数据缓存(Uniform Buffer)，是图形应用程序编程接口提供一种基础类接口，Uniform(全局数据)变量是着色器(Shader)和应用程序之间共享数据的桥梁，UniformBuffer是GPU上的内存空间，从应用程序传递数据到GLSL(OpenGL Shading Language)程序。

本申请提供的三维游戏渲染方法、三维引擎、电子设备和可读存储介质，旨在解决现有技术的如上技术问题。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

本申请实施例中提供了一种三维游戏渲染的方法，如图1所示，该方法包括：

步骤S100：获取至少两种协议版本的、包括渲染参数的着色程序；

步骤S200：将至少两种协议版本的着色程序包括的多个渲染参数缓存为一组全局数据参数组，通过调用应用程序编程接口来更新全局数据参数组；

步骤S300：根据更新后的全局数据参数组进行三维游戏渲染。

上述三维游戏渲染方法通过将多个渲染参数根据其自身特点缓存为一组，对具有相同特点的渲染参数进行分组化更新，能够实现一次操作批量更新大量的渲染参数，更新效率更高，从而大幅度提高游戏渲染效率。另外，包括渲染参数的着色程序均具备至少两种协议版本，能够在多平台上得到支持，因此渲染后，参数跨平台交互操作和执行的顺畅程度更高，也避免了在不同平台交互时的数据丢失，保证不同平台之间具有相同的渲染质量。

对于步骤S100，通常着色程序采用的是一种协议版本的形式，在不同平台之间应用时存在兼容性问题，而本申请提供的技术方案中，Shader直接以两种或两种以上协议版本的形式存在，这种协议版本指三维绘图协议版本，基本的两种三维绘图协议如WebGL1和WebGL2。对开发者提供统一的高版本GLSL Shader，开发者只需要编写一套Shader，采用步骤S100，系统会直接生成不同原生平台的对应版本，在运行时能够根据设备平台的类型，自动选择与之兼容的版本，而无需临时转化再使用。也即，步骤S100首先获取到具备两种协议版本，当然，在具有更多协议版本时，也可以获取具备两种以上协议版本的Shader，Shader中包括一项或一项以上的渲染参数。需要说明的是，原生平台包括Windows平台、Android平台或iOS平台中的任意一种，并不排除还有其他类似的原生平台。对于系统检测原生平台的类型的方式，步骤具体包括：当检测到原生平台接入时，确定原生平台的属性信息，而属性信息包括有原生平台的类型，当判断到原生平台类型，就能够根据原生平台类型获取到与之兼容的Shader的协议版本，也为处理完成之后的数据交互提供基础。

对于步骤S200，主要是对渲染参数进行分组，然后按组对组内的渲染参数进行批量一次性更新，从而实现提高更新效率，并进而提高渲染效率的目的。每个Shader可能包括多个渲染参数，多个Shader则包括更多的渲染参数，将多个渲染参数缓存为一组全局数据参数组，实际是根据全局数据(Uniform)来分类编组，而Uniform具体代表OpenGL(OpenGraphics Library，开放图形库)中用到的全局数据，是客户端向OpenGL传送数据的重要方式，该类数据不属于某个具体的Shader。将渲染参数以全局数据为单位进行分组，然后对组内的多个全局数据，也即对一个全局数据参数组进行更新，由于Uniform Buffer将单独的Uniform参数打包在一起，因此执行时是对Uniform Buffer进行更新，以实现全局数据参数组的更新。将不同的Uniform Buffer抽象归类，每种类型的Uniform Buffer有不同的更新策略，这样就可以减少更新频率，提高性能。

在可行的方案中，通过调用应用程序编程接口来更新全局数据参数组的步骤，包括：根据预定的全局数据缓存更新策略，更新全局数据缓存，参数更新的实现是三维引擎在每帧渲染时自动执行的。具体而言，UniformBuffer是图形API提供的一种基础类接口，本申请三维游戏渲染方法中提供的全局数据缓存更新策略包括以下任意一项：

策略一：每帧图像的渲染对应更新一次。这种定义为Global UniformBuffer，对应的是全局的渲染参数。

策略二：在每帧图像渲染中根据每个场景更新一次。这种包括LightUniformBuffer，具体定义的是每帧图像中每个场景的灯光参数。

策略三：在每帧图像渲染中依据每个模型更新一次。这种定义为LocalUniformBuffer，对应的是每帧图像渲染中每个模型的变换矩阵，例如自身的位置信息等。

在一个可行的实施例中，全局数据参数组以Javascript语言(以下或称JS语言)开发，如图2所示，经过步骤S200的更新全局数据参数组之后，步骤S200还包括有下列具体步骤：

步骤S210：通过至少一种原生语言对全局数据参数组进行编译。

步骤S220：将编译后的全局数据参数组提供至与原生语言对应的原生平台。

原生语言对于iOS来说就是Objective C，而对于Android来说，所用到的Linux内核是用C语言开发的，而中间层的库是用C/C++开发的，但应用程序框架和应用程序都是用"Java"开发的，这个系统就是用一堆开源的工程拼起来的，所以Android系统的原生语言有多种。C#是微软公司专门为.net量身定做的编程语言，.net整个框架系统用C#语言开发，所以C#是.net的原生语言。传统web游戏引擎都是用Javascript开发的，这种语言与原生语言相比，例如与C++相比，执行效率有差距，为了提升引擎效率，可以将游戏渲染中比较耗时的计算，如场景节点更新，场景裁剪，骨骼动画更新，粒子更新等，以更高效的执行语言执行。这些计算中的全局数据参数组原本以Javascript语言开发，现将这些全局数据参数组再用原生语言实现，并将其嵌入到三维引擎中，用于上述的游戏渲染中比较耗时的计算，能够提高渲染效率和引擎效率。

将以JS语言开发的全局数据参数组采用至少一种原生语言进行编译之后，JS语言开发的全局数据参数组和原生语言编译的全局数据参数组并存，在步骤S220中，确定到原生语言平台支持某一原生语言，就向该原生平台对应提供以该原生语言编译的全局数据参数组，以实现三维引擎能够实现高效率执行。另外，对于直接由原生语言编译的全局数据参数组，也可以通过支持JS平台的工具将其转化为执行效率较高的形式，例如通过EmScripten(一种编译器)也可将C++语言编译为WebAssembly，而JS平台可以对WebAssembly直接调用，兼容性目前在一些主流浏览器中都支持，如Chome、IE、MicrosoftEdge、FireFox和Safari等，以后还会支持更多的浏览器。WebAssembly是一种JS语言的二进制格式，其执行效率近似原生语言。

如图3所示，对于步骤S220中的将编译后的全局数据参数组提供至与原生语言对应的原生平台的步骤具体包括：

步骤S221：当检测到原生平台接入时，确定原生平台支持的原生语言。

步骤S222：将通过该原生语言编译得到的全局数据参数组提供至该原生平台。

判断到原生平台类型，进而确定得到原生平台能够支持的原生语言，就将对应原生语言编译的全局数据参数组提供到该原生平台，从而实现某些计算量较大的功能模块以较快的执行效率执行。

此外，在一个可行的实施例中，经过步骤S200更新全局数据参数组之后，本申请提供的三维游戏渲染方法还包括：将更新后的全局数据参数组对应的底层数据封装成面向数据架构的数据结构，面向数据架构的数据结构支持Neon指令和SIMD指令。之所以将底层数据封装为面向数据架构的数据结构(Structure of Array，下称SOA的数据结构)，是为实现原生平台的C++多线程支持，封装成SOA的数据结构的好处在于，能够使CPU访问数据更加友好高效。该方法步骤的具体过程为：

Step A：确定对接的硬件设备的指令类型。硬件设备的指令类型要么是Neon指令，要么是SIMD指令。SIMD(Single Instruction&Multiple Data)，单指令、多数据，能够复制多个操作数，并把这些操作数打包在大型寄存器的一组指令集。Neon指令是适用于ARMCortex-A系列处理器的一种128位SIMD的扩展结构。

Step B：确定到硬件设备的指令类型对应Neon指令，面向数据架构的数据结构存放3个浮点值；或者，确定到硬件设备的指令类型对应SIMD指令，面向数据架构的数据结构存放4个浮点值。根据硬件设备支持的指令类型不同，对应在SOA的数据结构中存放3个或4个浮点值，因此一次可以计算3个或4个节点，计算效率更高，节点是指场景中的一种数据结构，是用来组织场景中的模型的位置信息的，开发者的使用方式是将模型挂在节点下，然后通过操作节点来改变模型的位置等信息。

与我们在面向对象编程中使用的OO(Object Oriented，面向对象)的数据结构设计不同，SOA的数据结构把数据紧凑地组织在一起，有利于CPU高效访问。我们在底层的数据组织采用SOA的形式，可以按照硬件设备对于Neon指令和SIMD指令的支持程度，动态选择SOA的数据结构中的数据排列个数。CPU多线程和SIMD指令同时发生作用，能够产生乘法级的速率提升，例如4核CPU开启4个线程，而SIMD指令集支持4个单位数据的并行计算，理论上可以达到4×4倍的速率提升。

本申请实施例提供了一种三维引擎，也称为三维游戏引擎系统，如图4所示，该三维引擎10可以包括：材质模块11、更新模块12以及渲染模块13，其中，材质模块11用于获取至少两种协议版本的、包括渲染参数的着色程序。材质模块11将获取到的包括渲染参数的Shader，生成为多个多种协议版本，为更新模块12以及后续的渲染模块13提供渲染参数。更新模块12用于将至少两种协议版本的着色程序包括的多个渲染参数缓存为一组全局数据参数组，通过调用应用程序编程接口来更新全局数据参数组。渲染模块13用于根据更新后的全局数据参数组进行三维游戏渲染。

本申请提供的三维引擎10能够将多个渲染参数缓存为一组，对渲染参数进行分组更新，可以实现一次操作而批量更新大量渲染参数的效果，更新效率更高，游戏渲染效率相较于其他三维引擎有显著提高。另外，本申请提供的三维引擎10中，经材质模块处理后，包括渲染参数的着色程序均具备至少两种协议版本，能够在多平台上得到支持，因此使得渲染后的参数跨平台交互操作和执行的顺畅程度更高。

材质模块11中，协议版本包括两种三维绘图协议，具体分别为WebGL1和WebGL2。该材质模块获取至少两种协议版本的、包括渲染参数的着色程序，具体包括：根据预先检测到的原生平台的类型获取至少两种协议版本的、包括渲染参数的着色程序。而原生平台包括Windows平台、Android平台或iOS平台中的任意一种，检测原生平台的类型的方式，包括：当检测到原生平台接入时，确定原生平台的属性信息，属性信息包括原生平台的类型。

更新模块12根据预定的全局数据缓存更新策略，更新全局数据缓存。更新策略包括以下任一项：

每帧图像的渲染对应更新一次；

在每帧图像渲染中依据每个场景更新一次；

在每帧图像渲染中依据每个模型更新一次。

更新模块12更新全局数据参数组之后，还可以执行：通过至少一种原生语言对全局数据参数组进行编译，全局数据参数组是以Javascript语言开发的，然后，将编译后的全局数据参数组提供至与原生语言对应的原生平台。进一步的，以Javascript语言开发的全局数据参数组为场景节点更新、场景剪裁、骨骼动画更新或粒子更新中的至少一个。另外，将编译后的全局数据参数组提供至与原生语言对应的原生平台的步骤包括：

当检测到原生平台接入时，确定原生平台支持的原生语言；

将通过该原生语言编译得到的全局数据参数组提供至该原生平台。

在一个可行的实施方案中，更新模块12在更新全局数据参数组之后，还需要执行的方法步骤包括：将更新后的全局数据参数组对应的底层数据封装成面向数据架构的数据结构，面向数据架构的数据结构支持Neon指令和SIMD指令。具体地，将更新后的全局数据参数组对应的底层数据封装成面向数据架构的数据结构的步骤，包括：首先，确定对接的硬件设备的指令类型。其次，确定到硬件设备的指令类型对应Neon指令，面向数据架构的数据结构存放3个浮点值。或者，确定到硬件设备的指令类型对应SIMD指令，面向数据架构的数据结构存放4个浮点值。

本申请实施例中提供了一种电子设备，该电子设备包括：存储器和处理器；至少一个程序，存储于存储器中，用于被处理器执行时，执行前述的三维游戏渲染方法，与现有技术相比可实现：更高的更新效率，游戏渲染效率相较于其他三维引擎有显著提高，此外还能够在多平台上得到支持，渲染后的参数跨平台交互操作和执行的顺畅程度更高。

在一个可选实施例中提供了一种电子设备，如图5所示，图5所示的电子设备1000包括：处理器1001和存储器1003。其中，处理器1001和存储器1003相连，如通过总线1002相连。可选地，电子设备1000还可以包括收发器1004。需要说明的是，实际应用中收发器1004不限于一个，该电子设备1000的结构并不构成对本申请实施例的限定。

处理器1001可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC(Application SpecificIntegrated Circuit，专用集成电路)，FPGA(Field Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器1001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线1002可包括一通路，在上述组件之间传送信息。总线1002可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture，扩展工业标准结构)总线等。总线1002可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器1003可以是ROM(Read Only Memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

存储器1003用于存储执行本申请方案的应用程序代码，并由处理器1001来控制执行。处理器1001用于执行存储器1003中存储的应用程序代码，以实现前述方法实施例所示的内容。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，当其在计算机上运行时，使得计算机可以执行前述方法实施例中相应内容。与现有技术相比，使用本申请提供的计算机可读存储介质，计算机具有更高的更新效率，游戏渲染效率相较于其他三维引擎有显著提高，此外还能够在多平台上得到支持，渲染后的参数跨平台交互操作和执行的顺畅程度更高。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (12)

1.一种三维游戏渲染方法，其特征在于，包括下列步骤：

获取至少两种协议版本的、包括渲染参数的着色程序；

将至少两种所述协议版本的所述着色程序包括的多个所述渲染参数缓存为一组全局数据参数组，通过调用应用程序编程接口来更新所述全局数据参数组；

根据更新后的所述全局数据参数组进行三维游戏渲染。

2.根据权利要求1所述的三维游戏渲染方法，其特征在于，所述协议版本包括两种三维绘图协议，分别为WebGL1和WebGL2；

所述获取至少两种协议版本的、包括渲染参数的着色程序，包括：

根据预先检测到的原生平台的类型获取至少两种所述协议版本的、包括所述渲染参数的所述着色程序。

3.根据权利要求2所述的三维游戏渲染方法，其特征在于，所述原生平台包括Windows平台、Android平台或iOS平台中的任意一种；检测原生平台的类型的方式，包括：

当检测到所述原生平台接入时，确定所述原生平台的属性信息，所述属性信息包括所述原生平台的类型。

4.根据权利要求1所述的三维游戏渲染方法，其特征在于，所述通过调用应用程序编程接口来更新所述全局数据参数组的步骤，包括：

根据预定的全局数据缓存更新策略，更新全局数据缓存；

所述全局数据缓存更新策略包括以下任一项：

每帧图像的渲染对应更新一次；

在每帧图像渲染中依据每个场景更新一次；

在每帧图像渲染中依据每个模型更新一次。

5.根据权利要求1所述的三维游戏渲染方法，其特征在于，所述全局数据参数组以Javascript语言开发，更新所述全局数据参数组之后，该方法还包括：

通过至少一种原生语言对所述全局数据参数组进行编译；

将编译后的所述全局数据参数组提供至与所述原生语言对应的所述原生平台。

6.根据权利要求5所述的三维游戏渲染方法，其特征在于，所述全局数据参数组为场景节点更新、场景剪裁、骨骼动画更新或粒子更新中的至少一个。

7.根据权利要求5或6所述的三维游戏渲染方法，其特征在于，所述将编译后的全局数据参数组提供至与所述原生语言对应的原生平台的步骤包括：

当检测到所述原生平台接入时，确定所述原生平台支持的原生语言；

将通过所述原生语言编译得到的所述全局数据参数组提供至所述原生平台。

8.根据权利要求1所述的三维游戏渲染方法，其特征在于，更新所述全局数据参数组之后，该方法还包括：

将更新后的所述全局数据参数组对应的底层数据封装成面向数据架构的数据结构，所述面向数据架构的数据结构支持Neon指令和SIMD指令。

9.根据要求8所述的三维游戏渲染方法，其特征在于，所述将更新后的所述全局数据参数组对应的底层数据封装成面向数据架构的数据结构的步骤，包括：

确定对接的硬件设备的指令类型；

确定到所述硬件设备的指令类型对应所述Neon指令，所述面向数据架构的数据结构存放3个浮点值；

或者，确定到所述硬件设备的指令类型对应所述SIMD指令，所述面向数据架构的数据结构存放4个浮点值。

10.一种三维引擎，其特征在于，包括：

材质模块，用于获取至少两种协议版本的、包括渲染参数的着色程序；

更新模块，用于将至少两种所述协议版本的所述着色程序包括的多个所述渲染参数缓存为一组全局数据参数组，通过调用应用程序编程接口来更新所述全局数据参数组；

渲染模块，用于根据更新后的所述全局数据参数组进行三维游戏渲染。

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

处理器、存储器和总线；

所述总线，用于连接所述处理器和所述存储器；

所述存储器，用于存储操作指令；

所述处理器，用于通过调用所述操作指令，执行上述权利要求1～9中任一项所述的三维游戏渲染方法。

12.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，

所述存储介质存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如权利要求1～9任一项所述的三维游戏渲染方法。

Images