3D游戏渲染引擎的资源管理方法.pdf

本发明提供了一种3D游戏渲染引擎的资源管理方法，包括：在进行渲染计算和渲染时，统一调配管理运行时建构出来的内存资源、显存资源以及从外部加载的原始静态资源，使得其中的数据资源在未被销毁前能被引用和使用到所有显示对象中；且使得：当其中某个或某些数据资源在预设的第一时间内未被引用和使用时，相应的数据资源被放至相应的待销毁队列中；待销毁队列中的数据资源经过预设的第二时间后即被销毁；若在第二时间内又被引用或使用，则将相应的数据资源从所述待销毁队列中移除。

权利要求书
1.  一种3D游戏渲染引擎的资源管理方法，其特征在于：包括：
在进行渲染计算和渲染时，统一调配管理运行时建构出来的内存资源、显存资源以及从外部加载的原始静态资源，使得其中的数据资源在未被销毁前能被引用和使用到所有显示对象中；且使得：
当其中某个或某些数据资源在预设的第一时间内未被引用和使用时，相应的数据资源被放至相应的待销毁队列中；
待销毁队列中的数据资源经过预设的第二时间后即被销毁；若在第二时间内又被引用或使用，则将相应的数据资源从所述待销毁队列中移除。

2.  如权利要求1所述的3D游戏渲染引擎的资源管理方法，其特征在于：在销毁数据资源时，优先销毁显存资源数据和外部加载的非共享原始静态资源，内存资源数据次之，最后是外部加载的共享原始静态资源数据。

3.  如权利要求1所述的3D游戏渲染引擎的资源管理方法，其特征在于：在渲染中，还包括：
依据当下所需的逻辑以及输入的变化更新各显示对象的静态数据和/或动态数据，将更新后的所述静态数据和/或动态数据传至GPU或用于CPU计算的内存；
所述GPU和CPU响应更新后的所述静态数据和/或动态数据，做渲染前置计算，进而所述GPU以渲染前置计算的结果以及已确定的渲染场景、渲染层、渲染节点、渲染树以及渲染单元进行每一帧3D图像中的各显示对象的渲染。

4.  如权利要求1或3所述的3D游戏渲染引擎的资源管理方法，其特征在于：在渲染前，还包括：
将显示对象加入渲染场景中，为各显示对象准备静态数据和初始的动态数据；
得到所述显示对象的若干渲染单元；
将所述渲染单元加入到对应的渲染层中，生成渲染节点，确定各渲染层的渲染树。

5.  如权利要求4所述的3D游戏渲染引擎的资源管理方法，其特征在于：得到所述显示对象的若干渲染单元后，还包括对所述渲染单元依据功能做分类的过程；将同一类别的渲染单元合并，再加入到对应的渲染层中。

6.  如权利要求1或3所述的3D游戏渲染引擎的资源管理方法，其特征在于：所述显示对象包括不需要矩阵运算的基础显示对象和需要矩阵运算的高级显示对象，所述CPU用以对所述高级显示对象对应的静态数据和/或动态数据进行渲染前置计算；所述GPU用以对所述基础显示对象对应的静态数据和/或动态数据进行渲染前置计算。

7.  如权利要求1或3所述的3D游戏渲染引擎的资源管理方法，其特征在于：在进行渲染计算和渲染时，针对每一帧3D图像：
若其中的静态数据和/或动态数据已经完成过渲染前置计算，则不再对其进行再一次的渲染前置计算，采用已计算出的结果进行渲染。

8.  如权利要求7所述的3D游戏渲染引擎的资源管理方法，其特征在于：对其中的静态数据和/或动态数据完成渲染前置计算后，还将此计算的结果存放，并将其标注为无需再次更新操作的状态；否则将其标注为需要再次更新操作状态，然后在该帧3D图像渲染的后续处理中依据相应的状态标注判断是否进行渲染前置计算。

说明书3D游戏渲染引擎的资源管理方法
技术领域
本发明涉及3D游戏渲染引擎，尤其涉及一种轻量高效的3D游戏渲染引擎的资源管理方法。
背景技术
3D游戏渲染引擎，是各类程序系统中的一类，相对于绝大部分其他程序系统，它需要高频率地执行大规模的复杂计算，耗能高，因此需要基于合理的管控系统来实现3D游戏渲染引擎。
市面上各种3D图像渲染引擎很多，其中，FlashStage3D是跨平台的系统，可以运行在PC、网页、移动端等。3D图形渲染系统是通过实时计算来动态生成图像，而这其中的3D游戏渲染引擎是通过GPU实时运算来实时呈现不同时间点不同视角的各种游戏画面，以便让游戏玩家感觉置身其中，因此其对于系统动态运行的性能要求比较苛刻。
3D游戏渲染系统要求能尽量快的计算出尽量丰富的画面，以保证玩家的视觉体验和交互体验。一个游戏启动之后，玩家可能会持续玩很长时间，经历不同的内容，因此系统稳定性是一个重要的需求。良好的效能和稳定性是建立在良好的系统结构和运行机制基础上的。对于游戏渲染程序系统而言，需要不停的通过代码来操作CPU、内存、GPU这些相关的硬件，因此完成相同的任务，操作越少，效能就越高。操作少就是耗能少，由此可以说，优秀的系统就是能量利用率高的系统。
现有技术中，基于FlashStage3D的引擎市面上现有不少，例如:Away3D、Flare3D、Minko、Alternativa3D这四个引擎。
Away3D引擎开源，其系统结构完善但是运行机制繁冗，不能达到高性能。运行时产生的大量冗余对象和冗余计算，随着游戏运行的时间增加会逐渐消耗掉越来越多的内存以及CPU性能。
Flare3D引擎不开源，其为商业引擎，能实现的画面效果颇多，引擎体系结构复杂，但是用于游戏中的大规模实施渲染性能平平，其没有深入的考虑运行时资源问题，运行时性能无法达到一个新的高度。
Minko引擎开源，能实现颇多的画面效果，系统结构合理，只是没有考虑有效的运行时资源管理，而且冗余对象会在运行时也会大量产生，所以无法作为真正意义上的游戏引擎。
Alternativa3D结构完善，可以实现颇多的渲染效果，它是以游戏引擎为最终目的来实现的。只是引擎本身并没有完全封装运行时资源管理机制，依旧需要用户来做比较多的资源管理的底层工作。
发明内容
本发明要解决的技术问题是如何提高资源利用率。
为了解决这一技术问题，本发明提供了一种3D游戏渲染引擎的资源管理方法，包括：
在进行渲染计算和渲染时，统一调配管理运行时建构出来的内存资源、显存资源以及从外部加载的原始静态资源，使得其中的数据资源在未被销毁前能 被引用和使用到所有显示对象中；且使得：
当其中某个或某些数据资源在预设的第一时间内未被引用和使用时，相应的数据资源被放至相应的待销毁队列中；
待销毁队列中的数据资源经过预设的第二时间后即被销毁；若在第二时间内又被引用或使用，则将相应的数据资源从所述待销毁队列中移除。
可选的，在销毁数据资源时，优先销毁显存资源数据和外部加载的非共享原始静态资源，内存资源数据次之，最后是外部加载的共享原始静态资源数据。
可选的，在渲染中，还包括：
依据当下所需的逻辑以及输入的变化更新各显示对象的静态数据和/或动态数据，将更新后的所述静态数据和/或动态数据传至GPU或用于CPU计算的内存；
所述GPU和CPU响应更新后的所述静态数据和/或动态数据，做渲染前置计算，进而所述GPU以渲染前置计算的结果以及已确定的渲染场景、渲染层、渲染节点、渲染树以及渲染单元进行每一帧3D图像中的各显示对象的渲染。
可选的，在渲染前，还包括：
将显示对象加入渲染场景中，为各显示对象准备静态数据和初始的动态数据；
得到所述显示对象的若干渲染单元；
将所述渲染单元加入到对应的渲染层中，生成渲染节点，确定各渲染层的渲染树。
可选的，得到所述显示对象的若干渲染单元后，还包括对所述渲染单元依据功能做分类的过程；将同一类别的渲染单元合并，再加入到对应的渲染层中。
可选的，所述显示对象包括不需要矩阵运算的基础显示对象和需要矩阵运 算的高级显示对象，所述CPU用以对所述高级显示对象对应的静态数据和/或动态数据进行渲染前置计算；所述GPU用以对所述基础显示对象对应的静态数据和/或动态数据进行渲染前置计算。
可选的，在进行渲染计算和渲染时，针对每一帧3D图像：
若其中的静态数据和/或动态数据已经完成过渲染前置计算，则不再对其进行再一次的渲染前置计算，采用已计算出的结果进行渲染。
可选的，对其中的静态数据和/或动态数据完成渲染前置计算后，还将此计算的结果存放，并将其标注为无需再次更新操作的状态；否则将其标注为需要再次更新操作状态，然后在该帧3D图像渲染的后续处理中依据相应的状态标注判断是否进行渲染前置计算。
本发明认为，对于实现高效的程序系统有以下普适原则：
i)运行时程序代码对象能不创建就不创建。
ii)运行时程序代码逻辑能不执行逻辑计算就不执行。
iii)运行时程序代码对象能不销毁就不销毁。
通过这个普适原则，实现最大限度的重复使用现有结果，以便减少冗余操作。要达到这个目的就需要引擎程序系统中有严格的运行时资源管理机制。在3D游戏渲染引擎系统中，运行时资源这个概念包含了逻辑对象、数据对象、加载到内存中的外部资源、上传到显卡中的显存资源,以及被执行的逻辑计算等。
管理好运行时资源，才能实现上述三原则。因此实现3D游戏渲染引擎，系统结构和运行时机制要优先考虑资源的良好管控。有了这个基础，实现具体的游戏功能就方便很多。
基于该认识，本发明至少做了以下改进：
通过资源管理模块对内存、显存以及外部加载的原始静态资源的统一管理，在引擎中整合完善的运行时资源管控机制，让上层开发者不用再处理引擎中的这类问题；
进一步在本发明可选的方案中，还通过对渲染流程的优化，尽量减少了运行时不必要的渲染操作，以提高资源的利用率。
附图说明
图1和图2是本发明一实施例中资源管理的流程示意图；
图3是本发明一可选实施例中渲染流程基本逻辑的示意图；
图4是本发明一可选实施例中将所述渲染单元分类并加入到对应的渲染层的示意图；
图5是本发明一实施例中渲染中流程的示意图；
图6是本发明一实施例中显示对象的示意图；
图7是本发明一实施例中协作关系示意图；
图8是本发明一实施例中3D游戏渲染引擎的资源管理方法的流程示意图。
具体实施方式
以下将结合图1至图8对本发明提供的3D游戏渲染引擎的资源管理方法 进行详细的描述，其为本发明可选的实施例，可以认为，本领域技术人员在不改变本发明精神和内容的范围内对其进行修改和润色。
请参考图1和图2，以及图8，本发明提供了一种3D游戏渲染引擎的资源管理方法，包括：
在进行渲染计算和渲染时，统一调配管理运行时建构出来的内存资源、显存资源以及从外部加载的原始静态资源，使得其中的数据资源在未被销毁前能被引用和使用到所有显示对象中；且使得：
当其中某个或某些数据资源在预设的第一时间内未被引用和使用时，相应的数据资源被放至相应的待销毁队列中；
待销毁队列中的数据资源经过预设的第二时间后即被销毁；若在第二时间内又被引用或使用，则将相应的数据资源从所述待销毁队列中移除。
在本发明的附图中，图1具体展示了本发明统一调配管理内存资源、显存资源以及从外部加载的原始静态资源的一种可行方案，图2更进一步就调配流程进行了展开，其上文字均可现实本发明可选方案的具体内容。
综合以上资源管理方法的描述，可见，运行时资源的管控是3D游戏引擎中一项很重要的工作。这项工作奠定了引擎高性能的基础和后续开发的方便与安全。本发明的资源管理方法可以遵循以下途径来实现：
a)最大化的保证资源的共享(重复利用)
i)通过计数器的方式共享外部加载进来的静态数据资源
ii)通过计数器的方式共享系统生成的显存和内存对象。
iii)通过内存池的方式共享矩阵、位图数据、GPU程序代码等运行时产生的大对象
iiii)通过状态标记来标识状态数据是否已经更新到位，如果已经更新过了， 就不需要再次做相应的逻辑处理。
b)通过引擎内置的机制来实现加载，构建，运行控制，释放销毁对象。
运行时资源管理模块同时管理了内存和显存所需的资源，以及从外部加载进来的原始静态资源。
将资源管理方法进一步展开描述可以为：
在运行时资源管理中，只要发现某个资源一定时间段(即前文提到的第一时间)内没有被任何人引用和使用，那么这个资源将会被放到相应的准备销毁队列中。如果再销毁之前，它被重新使用了，那么这个资源将从准备销毁队列中移除。如果处于准备销毁队列中的时间足够长(这个由用户设定一个时间间隔，即前文提到的第二时间)，这个资源将被销毁。一般来讲，从资源的销毁顺序来讲，先销毁显存资源，在销毁内存资源最后才是原始静态资源，即在本发明可选的方案中，在销毁数据资源时，优先销毁显存资源和外部加载的非共享原始静态资源，内存资源次之，最后是外部加载的共享原始静态资源。当然，也有例外:原始静态资源在内存资源产生之后就被立刻销毁掉，本发明可选的方案对其原则性的手段进行了限制，可见，上文描述的“优先销毁显存资源数据和外部加载的非共享原始静态资源，内存资源数据次之，最后是外部加载的共享原始静态资源数据”不应该机械的理解，而是解读为，在非特殊情况下的本发明构思下的一种推荐的选择。显存资源相对于内存资源不同的地方在于，显存资源只要一段时间没有被使用，就会被销毁，即使引用正常存在。这是因为显卡的显存是有限的，要适时的销毁不需要用的显存资源，以防止显存超载，所以其在优先级上高于其他两项。
运行时资源管理，会在游戏逻辑循环中间隔一定的时间不停的检测各个管理子内的资源使用状况，以便正确的适时销毁和新建。这样做是为了自动完成 有效的内存和显存管理，而不需要用户再为这个难点而花费力气。
将以上方法对比现有技术可以看出，大部分现有的其他引擎实际上只有外部资源加载管理(将远程服务器或者本地硬盘或存储卡上的静态资源加载到内存中)，而且这个加载管理中并没有完全实现资源的重复利用。实际上加载管理包含了加载和卸载，加载要考虑重复利用，卸载也要处理重复利用带来的卸载管理问题(例如一个资源被多个不同类型的对象使用，这时候就要保证只要使用者还在此资源就不能被卸载)。
共享资源不仅是共享静态资源，还包括更大量的运行时构建出来的内存或者显存资源，可见，本发明中“统一调配管理运行时建构出来的内存资源、显存资源以及从外部加载的原始静态资源，使得其中的数据资源在未被销毁前能被引用和使用到所有显示对象中。”是本发明相对于现有技术的重要改进。
在实现手段上，获得这类资源的引用就使用这个资源，解除这个资源的引用就不使用此资源。运行时数据整合生成运行时所需的资源，共享机制保证了资源不会被频繁的多次构建。内存显存数据管理模块是实现运行时资源管理的核心，是整个资源管理系统共享机制的支持。内存显存数据管理模块最大限度的保证了资源被显示对象以及其他子系统共享使用，也保证了资源被适时的销毁和卸载。这一套机制非常多的其他引擎并没有内置，而是需要用户后期慢慢补全。包括现在比较流行的Unity3D引擎，他也没有完善的运行时资源管理机制。
运行时资源管控系统，保证了3D游戏渲染引擎在运行时内存和显存的稳定。同时也减少了生成内存或者显存资源时对CPU的不必要消耗，这也有利于游戏产品画面的稳定与流畅。
除了以上描述外，请参考图3至图5，本发明还对渲染流程进行了改进，通 过流程上的改进也能进一步优化资源的管控，提高资源利用率。
在渲染前，包括：
将显示对象加入渲染场景中，为各显示对象准备静态数据和初始的动态数据；
得到所述显示对象的若干渲染单元；
将所述渲染单元加入到对应的渲染层中，生成渲染节点，确定各渲染层的渲染树。
得到所述显示对象的若干渲染单元后，还包括对所述渲染单元依据功能做分类的过程；将同一类别的渲染单元合并，再加入到对应的渲染层中。
在渲染中，还包括：
依据当下所需的逻辑以及输入的变化更新各显示对象的静态数据和/或动态数据，将更新后的所述静态数据和/或动态数据传至GPU或用于CPU计算的内存；
所述GPU和CPU响应更新后的所述静态数据和/或动态数据，做渲染前置计算，进而所述GPU以渲染前置计算的结果以及已确定的渲染场景、渲染层、渲染节点、渲染树以及渲染单元进行每一帧3D图像中的各显示对象的渲染。
在进行渲染计算和渲染时，针对每一帧3D图像：
若其中的静态数据和/或动态数据已经完成过渲染前置计算，则不再对其进行再一次的渲染前置计算，采用已计算出的结果进行渲染。
以下结合图3至图5对上文的方案进行进一步的说明，以期将其技术效果阐述清晰。
对于一个3D游戏渲染系统，显示对象主要通过GPU渲染出来呈现到屏幕上。在渲染之前先要做相应的逻辑计算处理，上文将其描述为“渲染前置计算”， 这一步是为了收集渲染所需的各种用于渲染出目标图像的状态数据，可以理解为上文提到的“静态数据和/或动态数据”。收集好状态之后，接着要显示对象整理为实际可以直接用于渲染的最小单元。整理好之后，对每一个单元做实际渲染所需的数据准备。准备好相应的数据，上传GPU，GPU将其渲染出最终结果。
结合前文的描述，进一步可分为渲染前的数据准备、渲染单元的规划、实施渲染三个阶段。引擎中的数据准备做了相应的存储处理，也就是如果状态没有改变就不会去重新计算以及更新。
对于渲染最小单元的规划，这里的做法是在显示对象加入渲染器的时候就已经做好了，除非需要动态的改变才会重新做规划。这样做虽然实现起来有些复杂，但是不至于使用全动态规划的方式在运行时不停的做动态规划的工作而损失性能。市面上有些引擎就是全动态规划，这毫无疑问损失了不必要的性能。
在实施渲染的阶段，主要是如何调度GPU的各个API，这里的做法是如果相同的操作，如果状态未发生改变，就不会再去操作它。即上文提到的若其中的静态数据和/或动态数据已经完成过渲染计算，则不再对其进行再一次的渲染计算，采用已渲染计算过的结果进行渲染；
本发明可选的方案为了进一步达到以上的效果，对其中的静态数据和/或动态数据完成渲染前置计算后，还此计算的结果存放，并将其标注为无需再次更新操作的状态；否则将其标注为需要再次更新操作状态，然后在3D图像渲染的后续处理中依据相应的状态标注判断是否进行渲染前置计算。
从以上描述可以看出，本发明中，优化渲染流程，一方面降低了CPU的计算压力，另一方面减少了对GPU的操作次数，这在总体上提升了渲染性能。
对于渲染流程方面的改进，以下给出一个更具体的实施例：
首先需明确，渲染是使用当前帧的数据呈现出当前帧的画面效果，整个渲染过程主体上由数据准备、渲染单元的规划、实施渲染三个阶段组成。
在数据准备阶段，所准备的数据包括两部分：
i)基础数据，即上文提到的静态数据，包括纹理，顶点流，Shader等；
ii)实时数据，即上文提到的动态数据，包括实时得到的空间位置，缩放值，色彩，光照参数等动态数据；
基础数据在加入渲染器的时候已经准备完成，除非运行期间需要动态变化，否则这类数据是一直持有。
实时数据是在运行起来之后才确定的，很多运行时数据需要实时的动态计算。虽然这么说，但是仍然有一部分实时数据可以只计算一次或者只有计算很少的次数。那么可以在实施渲染过程中通过一些机制来降低实时数据计算所带来的消耗。
本发明可选的方案所采用的方式：
1.在显示对象加入渲染器的过程中，通过功能进行分类，以减少不必要的更新调用次数。
关于此，在本发明可选的方案中，在开始渲染前，还包括对所述渲染单元依据功能做分类的过程；然后将同一类别的渲染单元合并，再加入到对应的渲染层中。
2.通过数据记录来存放已经处理好的数据，通过状态标记来记录是否需要再次更新数据。
关于此，本发明可选的方案中，正如上文提到的，对其中的静态数据和/或动态数据完成渲染前置计算后，还将此计算的结果存放，并将其标注为无需再次更新操作的状态；否则将其标注为需要再次更新操作状态，然后在该帧3D图 像渲染的后续处理中依据相应的状态标注判断是否进行渲染前置计算。
渲染单元的规划，是渲染器所做的一个重要的工作，它保证了现实对象能被正确的实施渲染呈现正确的对应画面。一个显示对象实际上是由若干部分组成的，只要很少一部分显示对象就是源自一个独立的网格模型。对于由多个部分组成的显示对象，在实时渲染之前需要整理好渲染所需的渲染单元。因为每部分的渲染效果并非都一样，因此需要对显示对象的若干部分做整理归类，可能是合并也可能只是渲染前的分类。这个过程不能全部动态执行，需要尽可能的只执行一次，以提高渲染效能。
实施渲染，是每一个显示对象被呈现出来的最后阶段，我们可以理解为用GPU将3D模型绘制出来。这个过程首先要将对应的基础数据和一部分实时数据传递给GPU，控制GPU的渲染前置计算行为，正如前文提到，也可以是CPU渲染前置计算，最终达到渲染目的。这里面的关键点就是要尽量减少对于GPU的操作次数，能不操作就不操作。对于大数据，能不上传就不上传。对于渲染结果能不等待就不必刻意等待。
请参考图2和图3示意的具体实施例，以期待能够说明渲染器的两个操作机制：
a)显示对象加入渲染器
显示对象经过这个过程之后，才会被渲染器接受，显示对象才会在运行时被渲染出来。显示对象里面实际包含了若干的渲染单元，在实际的渲染中，每一个渲染单元实际需要执行一次GPU绘制的操作。在添加到渲染层的过程中，首先会通过功能来分类显示对象的数据处理逻辑，然后通过显示对象的具体情况来决定是否合并渲染单元。通过上面的处理之后，将显示对象中实际的渲染单元按照渲染需求做分类处理，同一类合并到一个渲染循环中。
上述加入流程，演示了整个渲染器对于现实对象的管理机制。
通过加入流程中的分类操作，预处理了相当一部分逻辑，避免运行时不必要的CPU消耗。
b)渲染运行时
这个过程就是对每一个渲染单元实施渲染的过程，在实际的游戏中，这个过程可能在一帧中执行好几百遍才能将整个游戏画面呈现出来。当然，这个流程执行的次数越少越好，越少越节省性能。因为整个系统中有完全的共享机制，本发明的效果描述中所提到的共享机制可以从上文的描述“若其中的静态数据和/或动态数据已经完成过渲染计算，则不再对其进行再一次的渲染计算，采用已渲染计算过的结果进行渲染”中进行理解。
所以很多显示对象的用于渲染的数据是共享的。如果上一次渲染部分数据和当前渲染所需的相同，则在当前的渲染中，就不需要因为当前的这部分数据去操作GPU。在这个前提下，渲染器的渲染工作就要利用共享机制，来减少对于GPU的操作。
除了以上阐述的渲染流程和资源管理两方面的改进，本发明可选的方案还在显示对象的管理上做了重要的改进：
在本发明可选的方案中，所述显示对象包括不需要矩阵运算的基础显示对象和需要矩阵运算的高级显示对象，所述CPU用以对所述高级显示对象对应的静态数据和/或动态数据进行渲染前置计算；所述GPU用以对所述基础显示对象对应的静态数据和/或动态数据进行渲染前置计算。
请参考图6，显示对象是渲染引擎中在运行时可见对象的逻辑表现对象。用户在使用引擎时主要操作的就是显示对象。3D游戏渲染引擎运行时大量的计算和渲染呈现的内容也是来自显示对象。
为了减轻CPU大量计算带来的压力，很多显示相关的实时计算交给了GPU，例如粒子系统的一些变化逻辑。
矩阵运算是在CPU的实时计算中，也是不小的消耗，因此能交给GPU的也交给GPU运算。而且在显示对象分类设计时，将基础显示对象设计为不需要矩阵运算也能正确显示，设计上这类对象在游戏中用的很多(例如Billboard)，这也减少了相应的矩阵运算。
摄像机这类特殊的对象，在游戏中每一帧，每一个摄像机所做的相关矩阵运算以及操作也最多只有一次。
在显示对象的运行逻辑管理上，只有相应的状态发生了变化，矩阵等相关计算在渲染前会被实际执行一次。如果没有变化，相关计算不会发生。这一内容在前文以阐述多次，故而不再做展开描述。
显示对象所使用的内存资源和显存资源都基于运行时资源管理系统，显示对象的构建会引用到运行时对应的资源，销毁显示对象则解除运行时对应的资源。显示对象本身并不会影响运行时资源管理，而且运行时资源管理不会影响到显示对象显示逻辑(例如即使没有对应的资源，显示对象最多是看不到，但不会出错)。
本发明可选方案中简洁有效的显示对象管理机制，尽量降低了显示对象相关计算对CPU造成的压力。这有助于游戏产品画面流畅和运行时承载更多的显示单位。
需要指出的是，上文提到的显示对象的管理、资源的管理以及渲染流程的优化这三方面的方案的改进并非各自独立的，而是互相可以两两结合，甚至三个统一结合在一个引擎中的、整合在一个方法中，无论其名称为3D游戏渲染引擎的资源管理方法还是3D游戏渲染引擎的渲染方法，均不妨碍这几个方面改进 的结合。
除了以上描述的，本发明可选的方案中，各个子系统间尽量降低耦合性，通过组合的方式让各系统间关联协作。
请参考图7，其显示了显示对象、动画控制、灯光、纹理数据、顶点数据、材质对象、Shader子系统在本引擎中的关系。
从理念上来说，低耦合，是本3D渲染引擎系统设计的一个出发点。显示对象持有数据和相关控制对象，动画控制更新显示对象状态，而Shader子系统收集并使用显示对象最新的数据，渲染器依据数据和shader中的控制程序将显示对象呈现出来。因为低耦合的原因，显示对象的动画控制可以任意切换为不同功能的控制对象。灯光、纹理、顶点、残材质对象三者也是相互独立的，只要数据格式匹配，就可以任意切换。切换完成之前，以前的对应对象之和显示对象有依赖关系。切换完成之后，以前的对应对象也只需要和显示对象解除依赖关系即可，和别的子系统无关。这样的低耦合性，保证了逻辑结构的清晰可靠。更有利于运行时资源管理。
在本发明请求保护的方案中，对于此也有一定阐述，即统一调配管理运行时建构出来的内存资源、显存资源以及从外部加载的原始静态资源，使得其中的数据资源在未被销毁前能被引用和使用到所有显示对象中。
综上所述，本发明及其可选的方案至少做了以下几个方面改进：
1)、通过资源管理模块对内存、显存以及外部加载的原始静态资源的统一管理，在引擎中整合完善的运行时资源管控机制，让上层开发者不用再处理引擎中的这类问题；
2)、通过对渲染流程的优化，尽量减少了运行时不必要的渲染操作；
3)、保证引擎系统的轻量性，去繁从简，集中紧凑，目标明确。