Ogre2.1 Hlms与渲染流程
每桢场景流程
一 所有场景更新,场景更新包含的内容如下。
- 场景动画 _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中就每桢计算一次,去掉无效的更新与计算,并且这上面每步都能高效利用多线程,具体过程请看我上篇 Ogre2.0 全新功能打造新3D引擎 。
二 场景对应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上面的注释中的一段。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
四 渲染承接上面Cull的数据(第二步)开始渲染(RenderPhase02)。
- mAutoParamDataSource信息填充 这个我记的是Ogre1.x中的着色器参数更新与RTSS需要的,Ogre2.1中应该不需要这个了。
- Forward3D的生成,主要过程参见前篇文章,全局多光源。
- 渲染通道开始渲染,参见RenderQueue。
这部分主要就是渲染通道中的数据,渲染通道相对于Ogre1.x来说改动主要集中在线程通道与hash排序,这样在渲染中,能自动InstanceBatch并且减少渲染切换状态。
HLMS如何插入渲染流程
HLMS在这个过程中做了啥,首先我们先看下相关概念。
在前面 Ogre2.0 全新功能打造新3D引擎 中简单介绍了下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.
三 每桢渲染时。
这段因为和 Ogre2.1结合OpenGL3+高效渲染 里有多重复的逻辑,在这就没多说明,如果这里看不明白,请转到这篇里有针对这个地方更为详细的说明。
首先摄像机执行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。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
一般来说,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。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
CB_SET_CONSTANT_BUFFER_PS U0设定PassBuffer,代码同上。
CB_SET_TEXTURE_BUFFER_VS T0 增加一个TBO,用来保存模型矩阵。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
- 设定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来看相应源码。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
CB_SET_CONSTANT_BUFFER_VS U2 InstanceBuffer,常见指示MaterialBuffer中的索引。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
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的合成器解析。