1.背景介绍
君方智能设计平台(ShipMaker)，使用OCC中的图形构造功能和图形渲染功能。OCC的图形渲染采用Opengl API 并且将所有图形渲染相关的逻辑放置在TKOpenGL模块中。
性能场景1：
大场景中包含2万个构件，超过300万三角面片时，对模型做视图的缩放、旋转和旋转等操作，存在卡顿现象，帧率小于10。
性能场景2：
在小场景中，动态绘制墙等线性构件时，非常流畅。当场景中包含2万个构件，超过300万三角面片时，动态创建线性构件墙，鼠标在移动过程中会动态绘制墙构件，存在卡顿现象。
对于场景1和场景2，在笔者的配置机器上，大场景中超过5万构件，2000~3000万面片，应该不存在卡顿现象。经过调试追踪，OCC中显示渲染逻辑存在性能卡点，通过优化渲染逻辑应该可以大大提升渲染性能。
2.TKOpenGL模块分析
1.场景数据
渲染相关的场景数据包括：渲染物体集合(OpenGl_LayerList)，光照数据(Graphic3d_LightSet)，帧缓存(OpenGl_FrameBuffer), ....
我们只关注渲染物体集合（OpenGl_LayerList）中的数据，即XC-Lab显示场景中绘制的墙、柱、梁、板楼、幕墙、......。这些数据在TKOpenGL中的组织方式如下图：
2.对应关系
3.TKOpenGL中渲染队列
所有需要显示的数据，在被渲染时都需要被依次处理组成一个渲染队列后，再提交到GPU渲染，最后才能获得完整的渲染图像。
OCC中渲染队列，安层级展示：
2.半透明物体渲染队列生成的影响
OCC中生成渲染队列有两种情形，依据场景中有没有半透明物体：
A.没有半透明物体：程序只需要遍历一次场景中结构体数据就可以生成渲染队列。
B.有半透明物体：程序需要遍历两次场景中的结构体数据，第一次先绘制不透明物体结构体，第二次绘制透明物体结构体。
即：场景中如果有半透明物体TKOpenGL会对场景中的物体遍历两次。
3.选中物体高亮对渲染队列的影响
在OCC目前的逻辑中，为保证半透明物体高亮的显示效果，修改了高亮物体的优先级（详细可见函数OpenGl_LayerList::ChangePriority），也就是修改结构体渲染队列中的渲染顺序。将高亮的物体在最后渲染。但是这种修改是永久的。即，用户选中一个构件，高亮后该构件的结构体在渲染队列中的顺序将会永久改变，不能恢复。
渲染顺序的改变对不透明物体渲染没有影响，但是对半透明物体渲染效果有很大的影响。
半透明物体绘制顺序影响见下图：
4.渲染开销分析
在程序中显卡设备的访问操作不能同时进行，即生成渲染列表的操作必须是单线程的。忽略将顶点数据，索引数据，纹理数据等传送到显卡中的操作。每帧图像数据的渲染开销包括CPU端开销和GPU端开销。
CPU端开销：生成渲染列表操作。需要处理的结构体越多，结构体越复杂开销越大。
GPU端开销：根据渲染列表渲染出图象。渲染列表中绘制命令（glDrawElements，glDrawArrays，...）调用的越多，绘制图元数量越大开销越大。
OCC渲染模块中开销较大的逻辑：
- 场景中渲染对象放到同一个列表中。每次操作都需要对整个队列遍历操作。
- 场景中数据按照结构体（OpenGl_Structure）组织。渲染时以结构体为单位，如结构体中需要绘制点、线段和三角面片，需要完成一个结构体中点、线段和三角面片的绘制才能开始下一个结构体的绘制。不能按照图元类别进行批量绘制。
- 视锥体剖切等有开销操作在CPU端操作，即在生成渲染列表时操作。
3．优化方案
重构TKOpenGL模块，重新实现Graphic3d_GraphicDriver，Graphic3d_CView，...等接口。在重构模块中使用高效的数据结构和渲染策略。
- 使用优化的数据结构
（1）根据渲染需求细化渲染物体类别。按照不同图元（点，线段，三角面片），不同材质（不透明，半透明，不同显示颜色），不同渲染效果（需正常渲染的物体，不能被遮挡等特性）分类组织对象。按照类别顺序批量绘制图元。
（2）同类别对象，将较小对象组成大小适量的数据块。以数据块为单位启动绘制。
- 使用优化的渲染策略
（1）使用条件渲染方式将视锥体剖切放到GPU端。
（2）使用渲染实例方式减少GPU显存的使用（如：针对柱这种构件，所有相同的柱，渲染模块可以只保存一份三角面片数据，渲染时只根据变换矩阵显示不同的实例）。
对于场景2的优化策略
分批渲染和屏幕缓存同时开启时，临时节点会在最后一个批次呈现在屏幕上，这样就能够大大提高渲染性能。
