渲染状态管理

TAG:

简介：

　　提高3D图像程式的性能是个很大的课题。图像程式的优化大致能够分成两大任务，一是要有好的场景管理程式，能快速剔除不可见多边形，并根据对象距相机远近选择合适的细节（LOD）；二是要有好的渲染程式，能快速渲染送入渲染管线的可见多边形。
　　我们知道，使用OpenGL或Direct3D渲染图像时，首先要配置渲染状态，渲染状态用于控制渲染器的渲染行为。应用程式能够通过改变渲染状态来控制OpenGL或Direct3D的渲染行为。比如配置Vertex/Fragment Program、绑定纹理、打开深度测试、配置雾效等。
　　改变渲染状态对于显卡而言是比较耗时的操作，而假如能合理管理渲染状态，避免多余的状态转换，将明显提升图像程式性能。这篇文章将讨论渲染状态的管理。

基本思想
　　我们考虑一个典型的游戏场景，包含人、动物、植物、建筑、交通工具、武器等。稍微分析一下就会发现，实际上场景里很多对象的渲染状态是相同的，比如任何的人和动物的渲染状态一般都相同，任何的植物渲染状态也相同，同样建筑、交通工具、武器也是如此。我们能够把具备相同的渲染状态的对象归为一组，然后分组渲染，对每组对象只需要在渲染前配置一次渲染状态，并且还能够保存当前的渲染状态，配置渲染状态时只需改变和当前状态不相同的状态。这样能够大大减少多余的状态转换。

下面的代码段演示了这种方法：

// 渲染状态组链表，由场景管理程式填充  
RenderStateGroupList groupList;  
 
// 当前渲染状态  
RenderState curState;  
 
……  
 
// 遍历链表中的每个组  
RenderStateGroup *group = groupList.GetFirst();  
while (group)  
{  
// 配置该组的渲染状态  
RenderState *state = group->GetRenderState();  
state->ApplyRenderState( curState );  
 
// 该渲染状态组的对象链表  
RenderableObjectList *objList = group->GetRenderableObjectList();  
 
// 遍历对象链表的每个对象  
RenderableObject *obj = objList->GetFirst();  
while (obj)  
{ 
// 渲染对象 
obj->Render(); 
obj = objList->GetNext(); 
} 
 
group = groupList.GetNext(); 
} 
 
其中RenderState类的ApplyRenderState方法形如：  
void RenderState::ApplyRenderState(RenderState &curState) 
{ 
// 深度测试  
if (depthTest != curState.depthTest)  
{  
SetDepthTest(depthTest);  
curState.depthTest = depthTest;  
} 
 
// Alpha测试  
if (alphaTest != curState.alphaTest)  
{  
SetAlphaTest(alphaTest);  
curState.alphaTest = alphaTest;  
}  
 
// 其他渲染状态  
……  
}

　　这些分组的渲染状态一般被称为Material或Shader。这里Material不同于OpenGL和Direct3D里面用于光照的材质，Shader也不同于OpenGL里面的Vertex/Fragment Program和Direct3D里面的Vertex/Pixel Shader。而是指封装了的显卡渲染图像需要的状态（也包括了OpenGL和Direct3D原来的Material和Shader）。

　　从字面上看，Material（材质）更侧重于对象表面外观属性的描述，而Shader（这个词实在不好用中文表示）则有用程式控制对象表面外观的含义。由于显卡可编程管线的引入，渲染状态中包含了Vertex/Fragment Program，这些小程式能够控制物体的渲染，所以我觉得将封装的渲染状态称为Shader更合适。这篇文章也将称之为Shader。

　　上面的代码段只是简单的演示了渲染状态管理的基本思路，实际上渲染状态的管理需要考虑很多问题。
渲染状态管理的问题

　消耗时间问题
　　改变渲染状态时，不同的状态消耗的时间并不相同，甚至在不同条件下改变渲染状态消耗的时间也不相同。比如绑定纹理是个很耗时的操作，而当纹理已在显卡的纹理缓存中时，速度就会很快。而且随着硬件和软件的发展，一些很耗时的渲染状态的消耗时间可能会有减少。因此并没有一个准确的消耗时间的数据。

　　虽然消耗时间无法量化，情况不同消耗的时间也不相同，但一般来说下面这些状态转换是比较消耗时间的：
Vertex/Fragment Program模式和固定管线模式的转换（FF，Fixed Function Pipeline）
Vertex/Fragment Program本身程式的转换
改变Vertex/Fragment Program常量
纹理转换
顶点和索引缓存（Vertex & Index Buffers）转换

　　有时需要根据消耗时间的多少来做折衷，下面将会碰到这种情况。

渲染状态分类
　　实际场景中，往往会出现这样的情况，一类对象其他渲染状态都相同，只是纹理和顶点、索引数据不同。比如场景中的人，只是身材、长相、服装等不同，也就是说只有纹理、顶点、索引数据不同，而其他如Vertex/Fragment Program、深度测试等渲染状态都相同。相反，一般不会存在纹理和顶点、索引数据相同，而其他渲染状态不同的情况。我们能够把纹理、顶点、索引数据不归入到Shader中，这样场景中任何的人都能够用一个Shader来渲染，然后在这个Shader下对纹理进行分组排序，相同纹理的人放在一起渲染。

多道渲染（Multipass Rendering）
　　有些比较复杂的图像效果，在低档显卡上需要渲染多次，每次渲染一种效果，然后用GL_BLEND合成为最终效果。这种方法叫多道渲染Multipass Rendering，渲染一次就是个pass。比如做逐像素凹凸光照，需要计算环境光、漫射光凹凸效果、高光凹凸效果，在NV20显卡上只需要1个 pass，而在NV10显卡上则需要3个pass。Shader应该支持多道渲染，即一个Shader应该分别包含每个pass的渲染状态。

不同的pass往往渲染状态和纹理都不同，而顶点、索引数据是相同的。这带来一个问题：是以对象为单位渲染，一次渲染一个对象的任何 pass，然后渲染下一个对象；还是以pass为单位渲染，第一次渲染任何对象的第一个pass，第二次渲染任何对象的第二个pass。下面的程式段演示了这两种方式：

以对象为单位渲染

// 渲染状态组链表，由场景管理程式填充  
ShaderGroupList groupList;  
 
……  
 
// 遍历链表中的每个组  
ShaderGroup *group = groupList.GetFirst();  
while (group)  
{  
Shader *shader = group->GetShader();  
 
RenderableObjectList *objList = group->GetRenderableObjectList();  
 
// 遍历相同Shader的每个对象  
RenderableObject *obj = objList->GetFirst();  
while (obj)  
{  
// 获取shader的pass数  
int iNumPasses = shader->GetPassNum();  
for (int i = 0; i < iNumPasses; i)  
{  
// 配置shader第i个pass的渲染状态  
shader->ApplyPass( i );  
 
// 渲染对象  
obj->Render();  
}  
 
obj = objList->GetNext();  
}  
 
group = groupList->GetNext();  
}

以pass为单位渲染

// 渲染状态组链表，由场景管理程式填充  
ShaderGroupList groupList;  
 
……  
 
for (int i = 0; i < MAX_PASSES_NUM; i)  
{  
// 遍历链表中的每个组  
ShaderGroup *group = groupList.GetFirst();  
while (group)  
{  
Shader *shader = group->GetShader();  
 
 
// 假如shader的pass数小于循环次数，跳过此shader  
int iNumPasses = shader->GetPassNum();  
if (i >= iNumPasses)  
{  
group = groupList->GetNext();  
continue;  
}  
 
// 配置shader第i个pass的渲染状态  
shader->ApplyPass(i);  
 
RenderableObjectList *objList = group->GetRenderableObjectList();  
 
// 遍历相同Shader的每个对象  
RenderableObject *obj = objList->GetFirst();  
while (obj)  
{  
obj->Render();  
 
obj = objList->GetNext();  
}  
 
group = groupList->GetNext();  
}  
}

　　这两种方式各有什么优缺点呢？

　　以对象为单位渲染，渲染一个对象的第一个pass后，马上紧接着渲染这个对象的第二个pass，而每个pass的顶点和索引数据是相同的，因此第一个 pass将顶点和索引数据送入显卡后，显卡Cache中已有了这个对象顶点和索引数据，后续pass不必重新将顶点和索引数据拷到显卡，因此速度会很快。而问题是每个pass的渲染状态都不同，这使得实际上每次渲染都要配置新的渲染状态，会产生大量的多余渲染状态转换。

　　以pass为单位渲染则正好相反，以Shader分组，相同Shader的对象一起渲染，能够只在这组开始时配置一次渲染状态，相比以对象为单位，大大减少了渲染状态转换。可是每次渲染的对象不同，因此每次都要将对象的顶点和索引数据拷贝到显卡，会消耗不少时间。
　　可见想减少渲染状态转换就要频繁拷贝顶点索引数据，而想减少拷贝顶点索引数据又不得不增加渲染状态转换。鱼和熊掌不可兼得 :-(
　　由于硬件条件和场景数据的情况比较复杂，具体哪种方法效率较高并没有定式，两种方法都有人使用，具体选用那种方法需要在实际环境测试后才能知道。

　多光源问题
待续……

　阴影问题
待续……

渲染脚本
　　现在很多图像程式都会自己定义一种脚本文档来描述Shader。

　　比如较早的OGRE（Object-oriented Graphics Rendering Engine，面向对象图像渲染引擎）的Material脚本，Quake3的Shader脚本，连同刚问世不久的Direct3D的Effect File，nVIDIA的CgFX脚本（文档格式和Direct3D Effect File兼容），ATI RenderMonkey使用的xml格式的脚本。OGRE Material和Quake3 Shader这两种脚本比较有历史了，不支持可编程渲染管线。而后面三种比较新的脚本都支持可编程渲染管线。

   脚本特性范例
   OGRE Material 封装各种渲染状态，不支持可编程渲染管线 >>>>
   Quake3 Shader 封装渲染状态，支持一些特效，不支持可编程渲染管线 >>>>
   Direct3D Effect File 封装渲染状态，支持multipass，支持可编程渲染管线 >>>>
   nVIDIA CgFX脚本封装渲染状态，支持multipass，支持可编程渲染管线 >>>>
   ATI RenderMonkey脚本封装渲染状态，支持multipass，支持可编程渲染管线 >>>>

　　使用脚本来控制渲染有很多好处：
能够很方便的修改一个物体的外观而不需重新编写或编译程式
能够用外围工具以所见即所得的方式来创建、修改脚本文档（类似ATI RenderMonkey的工作方式），便于美工、关卡设计人员设定对象外观，建立外围工具和图像引擎的联系
能够在渲染时将相同外观属性及渲染状态的对象（也就是Shader相同的对象）归为一组，然后分组渲染，对每组对象只需要在渲染前配置一次渲染状态，大大减少了多余的状态转换

(SLegend)

使用OpenGL绘制一颗围棋子	使用OpenGL绘制漂亮的围棋子
opengl es 设置颜色的代码	关于Direct3D11里汉字显示的一些思考
OpenGLES 显示 yuv	OpenGL性能优化
OpenGL综合知识---Frame Buffer	OpenGL综合知识 --- Memory类型和数据传递
计算机3D图形简述	OpenGL ES教程VI之纹理贴图(原文对照)

搜索

热门标签:

渲染状态管理