一种三维场景渲染方法及引擎系统与流程

1.本发明涉及三维图形渲染技术领域，更具体的涉及一种三维场景渲染方法及引擎系统。


背景技术：

2.随着计算机软、硬件突飞猛进的发展，计算机图形学近年来得到了众多的关注和快速发展，在各行各业得到了广泛的应用。三维图形技术包含了许多的图形图像处理算法，增加了开发难度。尽管有底层图形开发库的支持，但是在实际的项目开发中，通过直接调用这些底层图形库提供的接口来开发图形应用程序，仍存在着一定的局限性，制约着三维图形应用的开发进度，影响开发效率。


技术实现要素：

3.本发明实施例提供一种三维场景渲染方法，包括：
4.获取场景渲染所需要的场景元素；
5.采用自适应二叉树算法组织场景元素，构建自适应二叉树；
6.根据自适应二叉树节点包含的包围球和包围盒与视锥体的位置关系，进行节点及节点分支下节点可见性判断；
7.将可见的节点及节点分支封装后进行渲染；
8.其中，在渲染过程中，将表示一个特定渲染过程并且包含渲染元素的渲染序列，组成一个渲染组，完成渲染任务。
9.优选地，获取场景渲染所需要的场景元素，包括：
10.网格、材质、纹理、着色器程序、动画、物理参数。
11.优选地，构建自适应二叉树的过程，包括：
12.将与坐标轴对齐且覆盖整个场景的包围盒作为根节点；
13.执行递归剖分函数，将当前的包围盒用一个垂直于三个主坐标轴之一的最优分割面分开，作为当前节点的两个子节点；
14.分别对两个子节点继续采用最优分割面进行细分，直到节点中的面的数量达到预定阈值或树的深度上限。
15.优选地，最优空间分割面，包括：
16.采用随机采样方法，确定用于分割的候选面数据集；
17.采用评分函数对候选面数据集中的每个候选面进行评分，分数最高者则为最优分割面。
18.优选地，据自适应二叉树节点包含的包围球和包围盒与视锥体的位置关系，进行节点及节点分支下节点可见性判断，包括：
19.判断节点的包围球和视锥体的位置关系；
20.如果包围球位于视锥体内，直接送入渲染管道进行绘制；
21.如果包围球位于视锥体之外，停止对该分支上的节点的可见性判断；
22.当包围球与视锥体相交时，判断节点的包围盒与视锥体的位置关系；
23.如果包围盒位于视锥体内，将该节点及其分支节点直接送入渲染管道进行制；
24.如果包围盒位于视锥体外，则停止对该节点及其分支子节点的可见性判断；
25.如果包围盒与视锥体相交，则遍历子节点，对子节点同样进行基于包围球和包围盒的可见性判断。
26.优选地，判断节点的包围球和视锥体的位置关系，包括：
27.计算包围球球体中心到视锥体的6个平面的距离；
28.如果距离的绝对值小于包围球球体的半径，那么包围球球体与视锥体平面相交；
29.如果距离大于0，那么包围球球体位于视锥体平面的前侧；
30.如果距离小于0，那么球体位于视锥体背面，绝对在视锥体之外。
31.优选地，判断节点的包围盒与视锥体的位置关系，包括：
32.用三个最小值和三个最大值来定义包围盒；
33.然后将该包围盒的8个顶点与视锥体进行比较；
34.如果所有的点在视锥体内，那么说明这个包围盒位于视锥体内；
35.如果包围盒至少有一个顶点不在视锥体内，则说明包围盒与视锥体相交；
36.如果包围盒所有的点都在特定的视锥体平面的背面，包围盒位于视锥体的外面。
37.本发明还提供一种三维场景渲染引擎系统，包括：
38.资源管理子模块，用于提供场景渲染所需要的场景元素；
39.场景管理子模块，采用自适应二叉树算法组织场景元素，构建自适应二叉树；根据自适应二叉树节点包含的包围球和包围盒与视锥体的位置关系，进行节点及节点分支下节点可见性判断；
40.渲染管理子模块，采用渲染序列完特定的渲染过程，将多个渲染序列组成渲染组的渲染方式，将可见的节点及节点分支送入渲染管道进行复杂图元的渲染。
41.优选地，还包括基础图元管理子模块，用于将基础图元封装成较为复杂的图元，供三维图形图像处理程序调用，绘制复杂的三维模型。
42.优选地，资源管理子模块，包括：
43.资源访问接口子模块，存放了所有资源的信息，用于通过资源类resource和资源管理类reourcemanager对资源访问进行权限的控制，其中资源类resource对资源的属性和操作方法进行抽象的封装，资源管理类reourcemanager负责资源的查找；
44.文件系统子模块，用于通过directory、fileoperator和directorymanager进行文件管理，其中，directory用于管理文件的目录信息，directorymanager用于完成对具体指定的文件的创建、查找和删除等操作，fileoperator用于完成对指定文件的读取；
45.材质管理子模块，用于通过材质管理者类materialmanager以及材质类material，其中，材质类material对材质的属性信息进行了封装，并对提供了材质文件的加载、卸载的方法；materialmanager继承了resourcemanager，对resourcemanager提供的处理资源的抽象方法重写；
46.模型管理子模块，用于通过模型类model和模型管理者类modelmanager进行模型文件的读取与解析以及模型文件的加载、卸载；
47.纹理管理子模块，用于通过纹理类texture和纹理管理类texturemanager对底层图形开发库opengl封装，其中，纹理类texture对纹理操作进行封装，纹理操作包括纹理的创建、纹理的绑定、纹理的存储等方法，纹理管理类texturemanager通过对纹理对象的管理，实现纹理的创建、销毁等；
48.字体管理子模块，用于通过字体类和字体管理类对文字进行管理，其中，字体类封装了与字体相关的属性，负责字体的初始化和绘制，字体管理类负责设置字体对象的各种属性，通过调用字体对象提供的字体绘制接口，实现文字的绘制。
49.本发明实施例提供一种三维场景渲染方法及引擎系统，与现有技术相比，其有益效果如下：
50.1、三维渲染引擎按照功能和任务的不同分为核心功能模块和扩展功能模块。为了充分发挥现代图形处理器的优势，进一步提高渲染的效率和质量。
51.2、在场景管理模块采用了先进的自适应二叉树场景组织算法负责场景中对象的划分。在自适应二叉树场景组织结构的基础上采用基于包围球和包围盒的视锥体裁剪算法，减少了参与可见性计算的节点的数量，提高了裁剪的精确性和后续渲染效率。针对传统二叉树(bsp)存在的问题，本专利采用自适应二叉树算法(abt)进行场景的组织管理，其较强的自适应性，适合剖分任何类型的场景。与传统的八叉树相比，自适应二叉树(abt)提供了“多态”的优点，在某种意义上是几何模型和空间划分的抽象，而不限于固定的形状。它主要用在复杂3d场景下的视锥体裁剪。而八叉树由于其严格的空间结构，增加了可见性计算的开销。这可以通过使用松散的八叉树来缓解，但是仍然有很多限制，特别是八叉树并不能保证网格数据的唯一性(这在现代3d硬件上是非常重要的)，此外，八叉树不如自适应二叉树那样平滑地适应于几何体的分割。为了中等或复杂场景的通用渲染，自适应二叉树(abt)比八叉树更有效率。自适应二叉树(adaptive binary tree)是基于场景的几何体对空间进行分割。分割体可以动态的改变大小，也能够部分重叠从而减少分割面的数量。分割平面由一个考虑了多种不同参数(分割面的数量和位置等)的评分系统决定，正因为有了这个评分机制，在针对不同的场景进行空间划分的时候，该评分机制会根据实际的参数情况，选择合适的分割面进行场景的分割。所以它这种自适应的特性，abt对复杂的室内外场景均适用。
附图说明
52.图1为本发明实施例提供的一种三维场景渲染方法及引擎系统结构图；
53.图2为本发明实施例提供的一种三维场景渲染方法及引擎系统的自适应二叉树建立的执行流程；
54.图3为本发明实施例提供的一种三维场景渲染方法及引擎系统搜索分割面的算法流程；
55.图4为本发明实施例提供的一种三维场景渲染方法及引擎系统资源管理内容的示意图；
56.图5为本发明实施例提供的一种三维场景渲染方法及引擎系统由fileoperator类的实现子类完成配置文件的读取与解析示意图；
57.图6为本发明实施例提供的一种三维场景渲染方法及引擎系统目录管理者查找并读取文件的用例图；
58.图7为本发明实施例提供的一种三维场景渲染方法及引擎系统材质管理子模块用例图；
59.图8为本发明实施例提供的一种三维场景渲染方法及引擎系统资源管理者materialmanager加载材质文件的序列图；
60.图9为本发明实施例提供的一种三维场景渲染方法及引擎系统对模型进行处理的用例图。
具体实施方式
61.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
62.参见图1～9，本发明实施例提供一种三维场景渲染引擎系统，该系统包括：
63.1三维渲染引擎的架构
64.为了使开发的三维渲染引擎能够为不同领域的应用提供服务，因此，在进行三维渲染引擎的设计时，需要进行全面的考虑。对具体的功能模块进行具体的分析，设计好各功能模块之间的关系。由于三维图形应用程序可能运行在不同的平台，所以要根据引擎的特点，做好移植，使其能够跨平台为各个图形应用程序提供服务，而不受平台的制约。本文参考了已有的国内外的技术成果，设计了本发明的三维渲染引擎的总体架构。该引擎主要由核心功能模块和扩展功能模块两部分组成。如图1所示：
65.三维渲染引擎位于中间层，在应用程序与底层图形库之间，通过开放出的功能接口为上层的应用程序提供调用的服务。三维渲染引擎的核心部分主要包括了场景管理子模块、渲染管理子模块以及资源管理子模块等功能模块。而在扩展模块部分，主要包含了gui、脚本系统等子模块。
66.2.三维渲染引擎的各功能子模块
67.2.1场景管理子模块
68.该模块在三维渲染引擎中作为重要的模块之一，负责对场景中的元素进行组织管理。一个好的场景管理技术对场景的划分、可见性剔除、碰撞检测、加速场景渲染均有着重要的影响。当前的复杂场景具有可交互性高、场景模型数量大、动态场景多等特点，因此有效的组织场景，提高对场景的渲染效率和质量具有重要的研究意义。
69.本发明的三维渲染引擎的场景管理模块中不仅提供了二叉树、八叉树、场景图的场景管理策略，而且还提出了一种新的基于自适应二叉树和场景图的场景管理方法。自适应二叉树空间剖分算法引用分割平面的评分标准，形成自适应的行为，提高了场景划分的效率，有利于后续的渲染。本发明采用自适应二叉树空间剖分算法而且还融入了场景图的管理模式，针对不同的场景类型运用不同的abt权重，形成了场景管理策略，构建了场景管理模型，从而有效提升场景的空间组织和实时渲染效率。
70.具体地，自适应二叉树的建立：
71.自适应二叉树(abt)算法基于场景的几何体对空间进行分割。分割平面由一个考虑了多种不同参数(分割面的数量和位置等)的评分系统决定，使得到的分割平面更适合特
定类型的场景的模型划分。自适应二叉树建立的具体算法的执行流程如图2所示：
72.在创建过程中，首先，将与坐标轴对齐且覆盖整个场景的包围盒作为根节点(在创建节点的过程中，每个节点中都要存放一个包围盒和包含该包围盒的一个包围球,用来进行后续的裁剪和碰撞检测)。然后，开始执行一个递归剖分函数，该递归剖分函数的功能就是将当前的包围盒用一个垂直于三个主坐标轴之一的分割面分开，作为当前节点的两个子节点。然后分别对两个子节点继续进行细分，直到节点中的面的数量达到预定阈值或树的深度上限。
73.获取最优空间分割面算法
74.在自适应二叉树的创建过程中，最困难的部分就是如何选择合适的分割平面。一个好的分割平面会将当前的几何体集合分割的越完美，所构建的二叉树在结构上会具有很高的平衡性，更利于后续的裁剪和渲染。针对场景中空间几何体的划分，分割面的选择分为三步进行：
75.步骤1：采用随机采样方法，确定用于分割的候选面数据集。
76.步骤2：采用评分函数对候选面数据集中的每个候选面进行评分，分数最高者则为最优分割面。
77.步骤3：采用最优分割面对节点进行分割。
78.实现这个搜索分割面的算法流程如图3：
79.通过最优空间分割面对当前几何体集合实施有效的分割，有利于后续可见性判断和碰撞检测。
80.2.2渲染管理子模块
81.本发明的三维渲染引擎中渲染管理模块，通过对大量重复性渲染操作的封装，明显的提高了渲染的效率。在该渲染管理模块中提出了一个渲染序列和渲染组的概念，一个渲染序列表示一个特定渲染的过程，一个渲染序列包含了数据源、渲染状态、渲染对象和输出结果等渲染过程中所需要的渲染元素。多个渲染序列组成一个渲染组，来完成更为复杂的渲染任务。该引擎的渲染管理子模块通过对渲染过程中的相关操作的封装以及各种渲染机制的处理，大大地提高了渲染的效率。
82.2.3资源管理子模块
83.在任何一个完整的软件项目中，资源管理部分是必不可少，主要负责对系统运行过程当中所需要的一些资源文件、配置文件等信息进行管理。在该三维渲染引擎当中，渲染管理子模块主要用来管理对场景进行渲染时所用到的图形文件、资源配置文件的管理。
84.2.4消息管理子模块
85.消息管理是三维渲染引擎中比较重要的功能模块之一，在一个渲染引擎中分为多个模块，为了有一个好的渲染效果，各个模块之间需要相互配合，才能实现对复杂场景的渲染。消息在各个模块之间的工作协调发挥了重要作用。对于三维渲染引擎主要包含了两类消息，一类是操作系统产生的用户操作消息，另一类是渲染引擎自定义的消息。操作系统的消息主要是反映了用户针对键盘或者鼠标的操作的事件，在引擎中通过消息处理模块获取到操作系统的消息缓冲队列中的消息，构建相应的消息处理函数，对接收到的系统消息进行处理。自定义消息则适应于协调模块之间的工作。
86.2.5时钟管理子模块
87.当前流行的各类图形图像处理软件中，都具备了时钟管理的功能。时钟管理模块是三维渲染引擎中必不可少的。三维渲染引擎中的时钟管理模块主要是通过设置时钟实现对帧率的统计与控制
88.2.6基础图元管理子模块
89.基础图元是绘制图形的基本单位，虽然使用基础图元可以勾勒出复杂场景，但是这需要很大的工作量，影响开发进度。底层的图形开发包尽管提供了基础图元的绘制，但是存在设置繁杂，使用极不方便地问题。所以三维渲染引擎应该有自己的基础图元管理工具，并对一部分的基础图元封装成较为复杂的图元，减少绘制图元的工作量，提高了对封装的图元的重用性。三维图形图像处理程序可以直接调用该基础图元管理子模块实现复杂模型的绘制。
90.3、对三维渲染引擎框架中主要子模块进行了类的结构设计与实现。
91.3.1资源管理子模块
92.3.1.1资源管理的内容
93.对渲染资源的管理由资源管理子模块负责，该模块需要对多种资源文件进行管理。资源管理内容的示意图如图4所示：
94.3.1.2资源管理子模块
95.在进行场景渲染时，除了对一些模型配置文件进行解析、建立模型、销毁模型以外，还需要做一些更为复杂的工作。因此，针对图形资源的管理，我们封装了相关的类和接口，下面将依次展开介绍。
96.(1)、文件系统管理策略
97.每个资源管理器都会包含有大量的文件系统。在个人计算机中，程序员调用的是操作系统提供的图形文件库实现对文件的存取。但是，三维渲染引擎有时需要对原生的文件系统的api进行进一步的封装，转换为自己私有的文件系统api。之所以这样做主要是有以下两方面的考虑：第一，三维渲染引擎需要跨平台，在这需求下，引擎自己的文件系统api就能对系统的其他部分产生隔离作用，隐藏不同目标平台之间的区别。其次，就是操作系统提供的文件系统api未必能满足三维渲染引擎的需求。
98.对操作系统提供的原生的文件i/oapi进行包装，至少有三方面的好处。第一，引擎程序员能够保证这些自定义封装的文件i/oapi在所有的目标平台上具有相同的行为。第二，引擎程序员可以对原生的文件i/o进行精简，只保留渲染引擎实际需要的函数，从而减少维护开支。第三，可对文件系统的功能进行扩展，例如，通过对原生文件i/o的包装可以处理不同媒介上的文件。
99.在本专利设计的文件系统中，在对文件及文件目录的查找与读取方面，我们对不同的文件类型定义了不同的文件操作类，通过这些特定的文件操作类来完成对特定资源文件的处理。该文件系统提供了以下几类功能：一是能够操作文件名和路径，而是打开、关闭、读取、写入文件，三是扫描目录下的内容。
100.(2)、资源管理策略
101.对于一个复杂的三维场景，里面包含了很多的资源，例如有网格、材质、纹理、着色器程序、动画、物理参数等。这些渲染场景中用到的资源必须得到妥善的管理。从功能上讲，资源管理模块需具备两方面的功能，一方面是建立资源的离线工具，用来创建资源以及把
它们转换为渲染引擎可用的形式。另一方面是在执行期间实现资源的载入、卸下等操作。涉及到具体的资源的管理。
102.3.1.3资源管理子模块的实现
103.三维渲染引擎中管理的资源主要包含了多种资源，为了对资源进行更清晰合理的管理，可将资源管理模块进一步进行细分，针对每一种资源都构建相应的模块，通过相应的模块实现对各自资源的管理。
104.(1)、资源管理主模块
105.该模块存放了所有引擎资源的信息，作为一个资源访问接口，负责对资源访问进行权限的控制。
106.资源类resource对引擎中资源的属性和操作方法进行了抽象的封装。特定的资源类必须继承该类并实现该类提供的虚方法。模型类、纹理类、材质类等都是资源类resource的子类。
107.资源管理类reourcemanager负责资源的查找，在类的内部维护一张资源路由表，方便用户快速找到所需的资源。
108.(2)、文件系统子模块
109.在该文件系统子模块中涉及到的主要类有directory、fileoperator和directorymanager。directory主要用于管理文件的目录信息，directorymanager主要用来完成对具体指定的文件的创建、查找和删除等操作，fileoperator则用来完成对指定文件的读取，由于三维渲染引擎中包含了多种不同类型的文件，对每
110.一种类型的文件的内容进行解析的方法都一样，所以fileoperator类对各种支持的文件的解析方法进行了封装，从而fileoperator类可以实现对文件的读取与解析工作。
111.directory是一个抽象类，它作为派生类filefolderdir的基类，filefolderdir实现了基类的方法。directory作为文件系统的一个统一的接口，提供了文件目录及文件的检索功能。
112.fileoperator类作为文件读取的抽象类，提供了对不同文件处理的虚方法，对不同的文件具体的处理过程由其子类去实现。对于三维渲染引擎中的配置文件，需要进行解析的工作，文件系统在查找配置信息时，首先，由目录管理者directorymananger找到配置文件，然后由fileoperator类的实现子类完成配置文件的读取与解析。如图5所示:
113.目录管理者查找并读取文件的用例图如图6所示：
114.(3)、材质管理子模块
115.该模块负责对材质资源的管理。主要包含了材质管理者类materialmanager以及材质类material。用例图如图7所示：
116.材质类material对材质的属性信息进行了封装，并对提供了对材质文件的加载、卸载的方法。materialmanager继承了resourcemanager，并对resourcemanager提供的处理资源的抽象方法进行了重写。由materialmanager实现材质资源的初始化工作。资源管理者materialmanager加载材质文件的序列图如图8所示:
117.(4)、模型管理子模块
118.模型管理子模块主要是负责模型文件的读取与解析以及模型文件的加载、卸载等功能。该模块主要包含了模型类model和模型管理者类modelmanager。模型类model是资源
类的子类，具备对模型文件的加载、卸载的功能以及对其他渲染属性的处理，如阴影、动画等。
119.三维模型文件是由许多信息块组成的，块作为三维模型文件的基本单位。每个信息块是由块头和主体内容组成。其中块头包含了块id和块长度两个信息字段。其中块的id字段是一个整型资源，用来标识块的信息类别；块长度是一个长整型数据，它指出了下一个块相对于该块的偏移字节数。根据当前块的首地址和长度偏移量，就能找到下一个块。在三维模型文件中，内容的组织像是一种树结构，所以就有了父块和子块的概念，父块中包含了子块。其中id号是0x4d4d的块就是树根，而id为0x3d3d的3d editor chunk(描述对象信息)和editkeyframe(关键帧信息)就是树根的二级子节点，其余的子节点按照这种树形结构的形式组织下去。
120.对模型进行处理的用例图如图9所示：
121.(5)、纹理管理子模块
122.在opengl中，纹理是一个容器对象，它包含一个或多个图像。纹理有三个属性；纹理类型，纹理尺寸以及图像格式。纹理类型定义纹理内的图像如何排列。纹理的尺寸定义纹理中的每个图像的尺寸，每个图像是一个一维、二维或三维的像素数组，图像格式则定义每个像素的格式。本渲染引擎通过对底层图形开发库opengl的封装，设计并实现了该纹理管理子模块，该纹理管理子模块主要的核心类有：纹理类、纹理管理类。
123.纹理类texture对纹理的一系列操作进行了封装，包括了纹理的创建、纹理的绑定、纹理的存储等方法。
124.纹理管理类texturemanager通过对纹理对象的管理，实现纹理的创建、销毁等。
125.(6)、字体管理子模块
126.该模块负责对文字进行管理，由于底层图形开发库opengl并没有直接提供文字显示的功能，而且，opengl也没有自带专门的字库。因此要进行文字的绘制，需要依赖操作系统所提供的功能，目前比较流行的操作系统像windows系统和linux系统都提供了相关的功能，支持opengl在程序中显示文字。显示文字最常用的方法是首先给出要显示的文字，然后初始化一个显示列表，然后由操作系统把绘制这个字符的opengl命令装到制定的显示列表中，当需要进行文字绘制的时候，只需要调用这个显示列表即可。在该字体管理子模块中主要包含了字体类和字体管理类。
127.字体类封装了与字体相关的属性，负责字体的初始化与绘制。
128.字体管理类负责设置字体对象的各种属性(包括字体大小、位置、颜色)，通过调用字体对象提供的字体绘制接口，实现文字的绘制。
129.(5)场景管理子模块的设计
130.场景管理的目的是优化场景组织，方便后续的可见性判断和碰撞检测，提高渲染的效率。可见性判断和碰撞检测的实现过程中都需要对场景中的节点对象进行判断，一个好的场景组织结构对后续的渲染步骤有着极其重要的影响。鉴于当前的场景体系一般都比较庞大，若采用链表的结构来组织场景元素，在进行可见性判断时，需要对每个节点依次进行遍历，则耗费了大量的时间开销，影响了整体的渲染效率。基于树形结构存在的优势，本发明采用了能够处理各种场景的自适应二叉树来进行场景的组织。
131.场景树的生成是一个递归的过程。首先，选择合适的空间分割平面将场景模型一
分为二，然后以同样的方式对划分后的子节点继续进行分割，直到节点中的面的数量达到预定阈值或树的深度上限时，场景树构建成功。为了便于进行可见性判断，视角位于根节点内。场景中的实体除了包含渲染所需的摄像机、灯光等必需的元素，还包含了用户根据特定的需求自己制作的三维模型。通过相应的空间划分算法实现对场景的划分，并构建了场景树，场景中的实体作为场景树中节点的一部分挂载到场景树中。
132.(2)场景管理子模块的体系结构
133.该体系结构显示了场景管理模块所负责的工作以及如何与其他模块进行交互。虚线框内的是场景管理模块，虚线框外是引擎中的其他模块。
134.在该结构中场景管理者负责场景树的构建以及管理场景节点，并将需要渲染的部分送入渲染管理子模块，由渲染管理子模块负责对场景管理者提供的模型数据进行绘制。
135.(6)场景管理子模块的实现
136.在该子模块中，主要包含了三个功能类，分别是场景树节点类、可移动对象类和场景管理者类。对于场景树节点类，由于对场景的划分有很多种算法，例如二叉树、四叉树、八叉树、自适应二叉树等场景组织算法，不同的场景划分算法有着不同的数据结构，所以在对场景节点类进行封装时，每一种算法都对应着各自的场景节点封装类，在本发明的三维渲染引擎中除了提供了传统的场景分割算法的节点封装类，还针对自适应二叉树算法设计了场景节点封装类。场景节点类(scenenode)主要对场景中实体进行管理，对实体的各种属性如位置、旋转缩放的大小、是否是叶子节点等的控制。场景中可移动对象，使用了可移动对象类(movableobj)进行了属性成员的定义和封装。场景管理者类(scenemanager)是场景管理中的核心类，它用来控制场景中的所有对象，包括构建对象、移除对象、设置对象的属性等功能。在该三维渲染引擎中，由场景管理者类负责对场景节点类、模型实体类、可移动对象类的管理。
137.6.1、基于自适应二叉树的视锥体裁剪算法实现
138.三维场景规模越来越大，能够有效地减少绘制对象，降低模型复杂度，是三维渲染引擎中实现复杂场景快速绘制的关键所在。可见性判断是一种很有效的方法，可见性裁剪算法常常分为三类：视锥体裁剪、背面裁剪和遮挡裁剪。本发主要研究在自适应二叉树的场景组织的基础上采用基于包围球和包围盒的层次化的裁剪方式进行视域剔除。在既定的场景中，采用自适应二叉树算法来组织场景元素，面片在在叶子节点中分布的更加均匀，树的深度达到最佳，形成了一棵高效平衡的二叉树，基于此优势，在该数据结构上进行视锥体裁剪，会大大的提高裁剪的效率。
139.6.2、基于包围球和包围盒的视锥体算法描述
140.该算法的原理是首先利用abt算法对场景中的对象进行组织，构建起自适应二叉树，自适应二叉树中的每个节点都包含了一个包围球和包围盒(轴对齐包围盒)，然后在视锥裁剪方面，采用递归的方式对树中的节点进行裁剪处理，首先，判断节点的包围球是否在视锥体内，如果包围球位于视锥体内，那么就说明该节点分支下的所有子节点均是可见的，所以可直接送入渲染管道进行绘制。如果包围球位于视锥体之外，则说明该节点及分支下的子节点均不可见，则可以直接停止对该分支上的节点的可见性判断，从而节省了cpu的周期开销。当包围球与视锥体相交时，就开始判断视锥体与包围球中的轴对齐包围盒的位置关系，如果包围盒位于视锥体内，同样将该节点及其分支节点直接送入渲染管道进行制。如
果包围盒位于视锥体外，则停止对该节点及其分支子节点的可见性判断。如果包围盒与视锥体相交，则继续遍历其子节点，然后对其子节点同样进行基于包围球和包围盒的可见性判断。
141.6.3、确定包围球、包围盒与视锥体的位置关系
142.确定包围球是位于视锥体内、视锥体外还是与视锥体相交实际上是一个非常简单的过程，需要做的是计算球体中心到视锥体的6个平面的距离。如果距离的绝对值小于球体的半径，那么球体与平面相交。在相交不成立的情况下，如果距离大于0，那么球体位于平面的前侧(也可能在视锥体内)。如果小于0，那么球体位于视锥体背面，绝对在视锥体之外。
143.确定视锥体与包围盒的位置状态，用以下方式来完成该操作，首先，用三个最小值和三个最大值来定义包围盒，然后将该包围盒的8个顶点与视锥体进行比较。如果所有的点在视锥体内，那么说明这个包围盒位于视锥体内，如果包围盒至少有一个顶点(但不是全部)不在视锥体内，则说明包围盒与视锥体相交。如果包围盒所有的点都在特定的视锥体平面的背面。那么这个包围盒位于视锥体的外面，是不可见的。考虑到，视锥体完全包含在包围盒内的情况。在这种情况下，这些点都不在视锥体内，但包围盒仍然被视为可见的。
144.以上公开的仅为本发明的几个具体实施例，本领域的技术人员可以对本发明实施例进行各种改动和变型而不脱离本发明的精神和范围，但是，本发明实施例并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围内。