• 注册
  • 关于作者
    企业认证:趣记站长
    关注 6 粉丝 4 喜欢 9 内容 992
    江西省·南昌市
    聊天 送礼
    • 查看作者
    • 渲染状态管理

      文档简介:  

        提高3D图形程序的性能是个很大的课题。图形程序的优化大致可以分成两大任务,一是要有好的场景管理程序,能快速剔除不可见多边形,并根据对象距相机远近选择合适的细节(LOD);二是要有好的渲染程序,能快速渲染送入渲染管线的可见多边形。   

        我们知道,使用OpenGL或Direct3D渲染图形时,首先要设置渲染状态,渲染状态用于控制渲染器的渲染行为。应用程序可以通过改变渲染状态来控制OpenGL或Direct3D的渲染行为。比如设置Vertex/Fragment Program、绑定纹理、打开深度测试、设置雾效等。  

        改变渲染状态对于显卡而言是比较耗时的操作,而如果能合理管理渲染状态,避免多余的状态切换,将明显提升图形程序性能。这篇文章将讨论渲染状态的管理。  

      文档目录:  

        基本思想  

        实际问题  

        渲染脚本  

      文档内容:  

      基本思想  

        我们考虑一个典型的游戏场景,包含人、动物、植物、建筑、交通工具、武器等。稍微分析一下就会发现,实际上场景里很多对象的渲染状态是一样的,比如所有的人和动物的渲染状态一般都一样,所有的植物渲染状态也一样,同样建筑、交通工具、武器也是如此。我们可以把具有相同的渲染状态的对象归为一组,然后分组渲染,对每组对象只需要在渲染前设置一次渲染状态,并且还可以保存当前的渲染状态,设置渲染状态时只需改变和当前状态不一样的状态。这样可以大大减少多余的状态切换。下面的代码段演示了这种方法:  

         

      // 渲染状态组链表,由场景管理程序填充  

      RenderStateGroupList groupList;  

      // 当前渲染状态  

      RenderState curState;  

      ……  

      // 遍历链表中的每个组  

      RenderStateGroup *group = groupList.GetFirst();  

      while ( group != NULL )  

      {   

           // 设置该组的渲染状态  

           RenderState *state = group->GetRenderState();  

           state->ApplyRenderState( curState );  

           // 该渲染状态组的对象链表  

           RenderableObjectList *objList = group->GetRenderableObjectList();  

           // 遍历对象链表的每个对象  

           RenderableObject *obj = objList->GetFirst();  

           while ( obj != NULL )  

           {  

               // 渲染对象  

               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,

      游戏引擎剖析(二)
      利用Directshow开发源Filter,DShow中实现抓图的几种方法,角色扮演游戏引擎的设计原理,关于飞机射击类游戏的设计原理,游戏引擎剖析(十一),游戏引擎剖析(十),游戏引擎剖析(九),游戏引擎剖析(八),游戏引擎剖析(七),游戏引擎剖析(六),游戏引擎剖析(五),游戏引擎剖析(四),游戏引擎剖析(三),游戏引擎剖析(二),游戏引擎剖析(一),渲染状态管理,对2D游戏引擎设计的一些思考,游戏引擎演化史,网络游戏外挂编写初级教程,j2me游戏开发实例讲解
      游戏开发

      渲染一次就是一个pass。比如做逐像素凹凸光照,需要计算环境光、漫射光凹凸效果、高光凹凸效果,在NV20显卡上只需要1个pass,而在NV10显卡上则需要3个pass。Shader应该支持多道渲染,即一个Shader应该分别包含每个pass的渲染状态。  

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

        以对象为单位渲染   

         

      // 渲染状态组链表,由场景管理程序填充  

      ShaderGroupList groupList;  

      ……  

      // 遍历链表中的每个组  

      ShaderGroup *group = groupList.GetFirst();  

      while ( group != NULL )  

      {   

           Shader *shader = group->GetShader();  

         

           RenderableObjectList *objList = group->GetRenderableObjectList();  

           // 遍历相同Shader的每个对象  

           RenderableObject *obj = objList->GetFirst();  

           while ( obj != NULL )  

           {  

               // 获取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 != NULL )

      {

      Shader *shader = group->GetShader();  

               int iNumPasses = shader->GetPassNum();  

               // 如果shader的pass数小于循环次数,跳过此shader  

               if( i >= iNumPasses )  

               {  

                   group = groupList->GetNext();  

                   continue;  

               }  

               // 设置shader第i个pass的渲染状态  

               shader->ApplyPass( i );  

               RenderableObjectList *objList =   

                   group->GetRenderableObjectList();  

         

               // 遍历相同Shader的每个对象  

               RenderableObject *obj = objList->GetFirst();  

               while ( obj != NULL )  

               {  

                   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相同的对象)归为一组,然后分组渲染,对每组对象只需要在渲染前设置一次渲染状态,大大减少了多余的状态切换  

      游戏引擎剖析(一)
      利用Directshow开发源Filter,DShow中实现抓图的几种方法,角色扮演游戏引擎的设计原理,关于飞机射击类游戏的设计原理,游戏引擎剖析(十一),游戏引擎剖析(十),游戏引擎剖析(九),游戏引擎剖析(八),游戏引擎剖析(七),游戏引擎剖析(六),游戏引擎剖析(五),游戏引擎剖析(四),游戏引擎剖析(三),游戏引擎剖析(二),游戏引擎剖析(一),渲染状态管理,对2D游戏引擎设计的一些思考,游戏引擎演化史,网络游戏外挂编写初级教程,j2me游戏开发实例讲解
      游戏开发

    • 0
    • 0
    • 0
    • 57
    • 单栏布局 侧栏位置: