每桢场景流程
一 所有场景更新，场景更新包含的内容如下。
- 场景动画 _applySceneAnimations
- 所有节点数据 UPDATE_ALL_TRANSFORMS
- 骨骼动画 UPDATE_ALL_ANIMATIONS
- 所有模型的AABB。（ObjectData）UPDATE_ALL_BOUNDS
- 所有光源的AABB。 UPDATE_ALL_BOUNDS
- 生成光源列表。BUILD_LIGHT_LIST
如上这些部分Ogre1.x需要每次针对摄像机(RW与RTT)都重新来计算一次，在Ogre2.1中就每桢计算一次，去掉无效的更新与计算，并且这上面每步都能高效利用多线程，具体过程请看我上篇 。
二 场景对应workSpace->合成器节点(PassScene)->RenderTarget，因此下面这些和具体摄像机有关，其中主要是Cull当前模型进渲染通道。
- 更新当前场景所有模型（ObjectData）UPDATE_ALL_LODS
- 设置当前场景阴影节点。
- 当前场景当前摄像机的Cull(CullPhase01). CULL_FRUSTUM,如果模型可见，添加到渲染通道中。
这部分更新主要与当前摄像机有关，在RW中，数据保存给第四步
三 RW(正常渲染)开始渲染阴影节点，而RTT(光源贴图)直接跳过本段走第四步。
- 得到投射阴影的光源与对应的RTT.(PSSM中方向光源可以对应大于1个的RTT,一般用3个RTT).
- 渲染每个RTT.(在之前交换正常Cull模型列表，所有阴影RTT渲染完成后再交换回来)。
整个过程差不多如CompositorShadowNode上面的注释中的一段。
a normal rendering 四 渲染承接上面Cull的数据(第二步)开始渲染(RenderPhase02)。
- mAutoParamDataSource信息填充 这个我记的是Ogre1.x中的着色器参数更新与RTSS需要的，Ogre2.1中应该不需要这个了。
- Forward3D的生成，主要过程参见前篇文章，全局多光源。
- 渲染通道开始渲染，参见RenderQueue。
这部分主要就是渲染通道中的数据，渲染通道相对于Ogre1.x来说改动主要集中在线程通道与hash排序，这样在渲染中，能自动InstanceBatch并且减少渲染切换状态。
HLMS如何插入渲染流程
HLMS在这个过程中做了啥，首先我们先看下相关概念。
在前面 中简单介绍了下HLMS，其中有Macroblocks块，Blendblocks块，以及Datablock块，相当于一个模块化的Material.
Hlms后台有很多相关如(PBS,Unit)模版，对应在OgreMain中的Hlms类包含很多方法是用来解析hlms语法规则的函数，相关hlms语法见前链接中Ogre2.1中的移值手册，如@property, @end, @foreach, @counter, @value, @set[add,sub,mul,div,mod,min,max], @piece等。这些语法与常用的着色器算法构成Hlms的着色器模板代码。
RenderableCache:上面有个Renderable，但是不直接和Renderabl有关联，其实是这样的，里面二个字段，一个HlmsPropertyVec保存着材质属性的值组合(如有无切线,uv坐标个数,法线贴图,光照贴图等等)，还一个字段PiecesMap,简单点来说，HlmsPropertyVec里保存属性与对应int的值，int用来表示bool,个数啥的，对应hlms语法就是如@property,@foreach,@counter等，而PiecesMap用来保存属性与对应string的值，简单来说，就是上面hlms语法@piece,也可以说是代码片断，具体情况请看前面所说的Ogre2.1移植文档，和Renderable的隐藏关系就是HLMS要根据Renderable的HlmsDatablock生成HlmsPropertyVec和PiecesMap，所以具体来说，应该是HlmsDatablock的Cache。
HlmsCache前面讲解Ogre2.1高效渲染时有说，RenderableCache保存了生成着色器代码的模板变量，而HlmsCache保存根据RenderableCache生成的色器代码，其中hash不仅仅是Renderable的渲染属性组合，还包含了当前Hlms类型的渲染属性组合。
一 Ogre初始化，拿到HLMS资源时。
和Ogre1.x一样的是，在创建初始化窗口后，就开始加载资源，不同的是我们先需要像HlmsManager注册了几种Hlms类型，如PBS，Unit等。然后加载资源文件时，遇到如hlms Rocks pbs{}这种，首先开始解析其中的HlmsMacroblock,HlmsBlendlock这些数据，然后组成HlmsDatablock,这个可以这么理解，原来材质是Material->Technique->pass，现在除开着色器代码部分，如深度测试啥的全整合成一个HlmsDatablock，然后是生成HlmsPBS对应下的HlmsPbsDatablock的hash，然后添加到HlmsManager.
二 创建场景，添加模型进场景时。
和Ogre1.x类似的是，创建Entiy(Renderable),设置Material,在这变成创建Item(Renderable),然后设置HlmsDatablock,不同原来的直接把Renderable下关联Material完事，在Ogre2.1中，Hlms需要把当前Renderable放入Hlms调用calculateHashFor计算，这个过程大致可以看做首先是根据HlmsDatablock里所有渲染设置添加到Hlms里的mSetProperties，然后根据mSetProperties调用addRenderableCache生成上面所说的RenderableCache并添加到Hlms的列表中，并返回当前Hlms类型(假设是PBS)与当前RenderableCache在列表中位置组成的hash值，然后如上面生成阴影RTT时对应的RenderableCache与hash值，并返回正常渲染与阴影RTT的二个hash.
三 每桢渲染时。
这段因为和 里有多重复的逻辑，在这就没多说明，如果这里看不明白，请转到这篇里有针对这个地方更为详细的说明。
首先摄像机执行cull,如上面的cullPhase01这步，检查当前模型是否可见，如果可见，添加进渲染通道中，在通道中包装成QueuedRenderable[见上面链接]，这里复制其中一段，下面说明，检索所有可见的Renderable.根据Renderable的材质(在这是HlmsDatablock,非Ogre1.x中的pass)生成分段数hash(用于排序,其中先材质,再mesh),并把相关Renderable,分段数hash,对应的MovableObject包装成QueuedRenderable添加到线程渲染通道中,合并所有当前线程渲染通道到当前通道中.
如前面渲染流程中的renderPhase02这步，在渲染具体模型之前，针对每个Hlms类型(PBS,Unit等)初始化一个HlmsCache,具体包含如是否是使用前向渲染，如果使用，则把当前Forward3D里的属性填充到对应HlmsCache中的HlmsPropertyVec中，还有如光源个数，方向光，聚光灯，点光源的个数分别写入HlmsPropertyVec中。
然后开始渲染通道中的具体模型QueuedRenderable，与上面的HlmsCache(Hlms类型设置)根据Hlms::createShaderCacheEntry生成当前Renderable的HlmsCache。具体来说，根据renderableHash[见上面链接]找到对应的RenderableCache,把这个RenderableCache与HlmsCache(Hlms类型设置)里的HlmsPropertyVec组合起来，以及相应的PiecesMap放入对应模板(如PBS着色器模板)生成对应的着色器代码，所有着色器代码放入最终的HlmsCache，并根据相应hash[第二步中生成的hash]放入Hlms列表中，当后面有相同的hash进来后，直接取对应的HlmsCache，而不需要再生成一次着色器代码。
Ogre中的CommandList
最后，我们来看下RenderQueue::renderGL3做了啥，帮助我们理清内部commandlist显示组成，我们例子还是选定上链接中的这个例子,渲染模式用PBS，并去掉灯光与阴影影响。
简单来说，有一个4*4个模型,其中一条对角线上全是球形,余下全是立方体,其中偶数行使用材质Rocks,奇数行使用Marble.调用glDraw…(DrawCall)的次数只需要二次或四次,看硬件支持情况,如何做到的了,在Ogre2.1中,把如上16个模型添加进渲染通道时,会根据材质,模型等生成排序ID,如上顺序大致为Rocks[sphere0-0,sphere2-2,cube0-1,cube0-2,cube0-3,cube2-1…], Marble[sphere1-1,sphere3-3,cube1-2,cube1-3…].那么他们CommandList顺序以及各Command含义。
二者所用HLMS材质，Rocks与Marble。
Hlms 材质 一般来说，CommandList列表如下顺序，特殊情况在这不讨论，渲染模式用PBS，并去掉灯光与阴影影响。
CB_SET_MACROBLOCK 设定包含逐片断处理中的深度检查,还有剔除模型,显示模式。
CB_SET_BLENDBLOCK 设定如逐片断处理中的Alpha混合操作。
CB_SET_HLMS_BLOCK 对应上面的HlmsCache，绑定顶点，细分，几何，片断着色器。
- 如下每个模型进入fillBuffersFor，首先如果从别的渲染模式切换成PBS渲染模式，理解为每一桢就好，因为每桢是渲染完一个模式再开始渲染另一种。从如下的CB_SET_CONSTANT_BUFFER_VS 到CB_SET_TEXTURE的所有命令一般只会在第一个模型进入fillBuffersFor调用，其余模型只是更新worldMatBuf里的数据。
CB_SET_CONSTANT_BUFFER_VS U0设定PassBuffer，在顶点与着色器代码中如下。摄像机矩阵P，视图矩阵V。
View Code CB_SET_CONSTANT_BUFFER_PS U0设定PassBuffer，代码同上。
CB_SET_TEXTURE_BUFFER_VS T0 增加一个TBO，用来保存模型矩阵。
worldMatBuf - 设定worldMatBuf,简单来说，存足够多的模型矩阵，一般来说，每一桢，worldMatBuf只需要一次设置，后续DrawCall共用这个TBO，通过baseInstance与divisor定位每个DrawCll里的每个instance的每个模型。
- baseInstance：如上例子16个模型，模型的baseInstance也就是从0-15，其中Rocks材质时，前二个球同一实例，第一个球baseInstance为0，后面一个球只需要参数的Instance加1为2，然后6个立方体同一实例，重新添加一个参数，第一个立方体的baseInstance从2开始，后面的立方体只需要更新Instance参数为2到7。然后是Marble材质，如上前二个球同一实例，baseInstace从8开始，后面的球还是Instance为2，然后是立方体的baseInstace从10开始，后面的立方体只需要更新Instance参数为2到7。
CB_SET_CONSTANT_BUFFER_PS U1 设定MaterialBuffer，每个模型的PBS渲染属性，如Fresnel(菲涅尔系数), roughness(粗糙度)等,这个UBO保存了一个PBS的渲染属性结合的列表，结合类ConstBufferPoolUser来看相应源码。
MaterialBuf CB_SET_CONSTANT_BUFFER_VS U2 InstanceBuffer，常见指示MaterialBuffer中的索引。
InstanceBuffer CB_SET_CONSTANT_BUFFER_PS U2 InstanceBuffer，代码如上。每个模型会更新InstanceBuffer这里面的数据，一般在PS中更新。
CB_SET_TEXTURE_BUFFER_VS T0 因为要添加当前模型矩阵的数据，检查是否需要重新申请一个TBO，每桢第一次进来需要调用这个。
- 当材质变化，一般来说，这些要重新设置
CB_SET_TEXTURE 设定纹理如材质上面的Rocks_Diffuse.tga
CB_SET_TEXTURE 设定纹理如材质上面的Rocks_Normal.tga
CB_SET_TEXTURE 设定纹理如材质上面的Rocks_Spec.tga
CB_TEXTURE_DISABLE_FROM 设定当前激活纹理为0
CB_SET_VAO 顶点数据，位置，法线，索引等。
CB_SET_INDIRECT_BUFFER DrawCall参数，如上例子中，有8个模型用一个材质，那么这个参数记录了这8个模型的DrawCall参数。
- 在下面，一次绘制上面的Rocks材质下的八个模型
CB_DRAW_CALL_INDEXED_EMULATED 嗯，我这台电脑不支持Indirect draw,所以选择这个DrawCall函数，如本例中，Rocks材质有八个模型，其中二个是球，6个是立方体，如果支持Indirect draw,此命令为CB_DRAW_CALL_INDEXED，里面只包含一次DrawCall,而不技能Indirect下的CB_DRAW_CALL_INDEXED_EMULATED，里面包含了二次DrawCall.
- 开始绘制Marble材质下的八个模型。
CB_SET_HLMS_BLOCK 对应上面的HlmsCache，绑定顶点，细分，几何，片断着色器。
CB_SET_TEXTURE 设定纹理如材质上面的MRAMOR6X6.jpg
CB_SET_TEXTURE 设定纹理如材质上面的MRAMOR-bump.jpg
CB_TEXTURE_DISABLE_FROM 设定当前激活纹理为0
CB_SET_VAO 顶点数据，位置，法线，索引等。
CB_SET_INDIRECT_BUFFER DrawCall参数
- 同上面，一次绘制上面的Marble材质下的八个模型
CB_DRAW_CALL_INDEXED_EMULATED
简单来说，每桢进入PBS渲染，只有第一个模型调用fillBuffersFor来初始化相应UBO与TBO，后面的模型调用fillBuffersFor一般来说只是更新了存入模型矩阵的TBO里的数据以及保存材质索引的UBO中，当材质不同切换时，一般也只是重新绑定纹理，VBO，DrawCall参数，相应的状态切换如MACROBLOCK，BLENDBLOCK在这个例子只没有发生切换。
新的合成器看了下，虽然引入一些新的概念，但是基本的Pass概念一样，中间也没有用到Hlms,还是用的老材质做特效，这部分用Hlms也没意义，一是老的材质里在这直接写相应着色器代码要方便写，二是Hlms针对模型的DrawCall整合功能这里没用，这里特效是针对RTT与RW的像素修改融合。比较重要的如PassQuad与PassScene还是一样，一个RTT,一个RW，新增如PassDepthCopy可以用一些pre-depth的特效。其余都是一些组合，也就不重新来仔细说了，有兴趣的同学可以看我写的Ogre1.9的合成器解析。