http://www.cnblogs.com/kfqcome/archive/2011/08/15/2139727.html
自从以前看了clayman的博客后,就很想把自己代码里dx的effect框架替代掉。如今实习结束正好有短暂的自由时间,所以就ogre的material开刀吧。
山寨代码也是有学问的,如果你想搞明白这些代码的含义的话,最后之前就对这些已经有了一定的使用经历和认知,第一步先得自己想一下material系统的组成:
material应该包含的:1Material->n Techinque->(n Pass + extra params)->(n TextureUnit + m or 0 shaderUnit + n RenderStates(部分)),Pass里的TextureUnit又包含了这一组texture的相关信息和设置,TexcoordSet, AddressMode, FilterSetting等等,ShaderUnit则是对应于vs,fs以及新的gs,普通点也就最多两组。shaderUnit包含了具体的shader和其shaderParams,为何要把shader和shaderParams分开呢,不说设计优雅的考虑,简单的说就是方便,很多时候params可能会需要共享,譬如shaderA里用到mvpMat,和eyePos, diffuse,specular,可能shaderB也只用到这些,但是两个shader的内部计算并不相同。到此我们只分析了作为程序中的材质的结构,还需要考虑如果编写一个类似fx格式的material script,这也是另外一个大头,简单的说就是要做个脚本解释,然后给shader参数加上语义,减少大部分需要手动更新的shaderParams。鉴于我如今还没把这块扒完,等下次再写这块吧。
当你至少能闭着眼睛想透这些了,那就可以开始看ogre的material system了,先说句题外话,我读ogre的代码其实读挺久了。一直觉得很难读,开始觉得是自己水平不够,但后来实习才发现很多人都有这想法,甚至wolfgang对此也有批评,而自己曾经写了个olong引擎,接触过ipad编程的人应该对这些代码都比较熟悉~ogre里用了大量的设计模式,使得整个渲染流程从不同类里跳来跳去(SceneMgr这块看着最累了。。其实有很多地方看着都很累。。)个人觉得应该把render从SceneMgr里抽离出来做个RenderMgr,(记住这里的RenderMgr的概念和ogre的RenderSystem,后者是提供底层渲染API的接口,而前者是管理renderData并最终递交给RenderSystem,以前也见有别人博客讲过这个问题)让SceneMgr专门管理Scene。。
打住打住。。我是来写material的。。咳咳。。相当于渲染来说,ogre的material system还是相当易读的,也是因为这些模块相互关系几乎都是单向的,我们开始编写的时候可以先不考虑Technique,就是直接1 Material->n Pass->...当然甚至你都可以把multi pass去掉,就等同于1个pass,当然由于pass都代码实际也没多少,我们还是加上好了。
原始渲染的伪代码就是:
![](https://i-blog.csdnimg.cn/blog_migrate/cbef093dcc044b2793832001e2365e43.gif)
2
![](https://i-blog.csdnimg.cn/blog_migrate/2f88ce130b654eb5dc6788e02dbcfc90.gif)
3
![](https://i-blog.csdnimg.cn/blog_migrate/df37983f39daa189b8c814e01a6a9011.gif)
4
![](https://i-blog.csdnimg.cn/blog_migrate/df37983f39daa189b8c814e01a6a9011.gif)
5
![](https://i-blog.csdnimg.cn/blog_migrate/df37983f39daa189b8c814e01a6a9011.gif)
6
![](https://i-blog.csdnimg.cn/blog_migrate/df37983f39daa189b8c814e01a6a9011.gif)
7
![](https://i-blog.csdnimg.cn/blog_migrate/f70a0fde2b51b7dd92a70e712e540cf6.gif)
8
![](https://i-blog.csdnimg.cn/blog_migrate/df37983f39daa189b8c814e01a6a9011.gif)
9
![](https://i-blog.csdnimg.cn/blog_migrate/df37983f39daa189b8c814e01a6a9011.gif)
10
![](https://i-blog.csdnimg.cn/blog_migrate/4a5daaec04350a363f186a4d2c5ed6ce.gif)
11
![](https://i-blog.csdnimg.cn/blog_migrate/df37983f39daa189b8c814e01a6a9011.gif)
12
![](https://i-blog.csdnimg.cn/blog_migrate/f70a0fde2b51b7dd92a70e712e540cf6.gif)
13
![](https://i-blog.csdnimg.cn/blog_migrate/df37983f39daa189b8c814e01a6a9011.gif)
14
![](https://i-blog.csdnimg.cn/blog_migrate/df37983f39daa189b8c814e01a6a9011.gif)
15
![](https://i-blog.csdnimg.cn/blog_migrate/4a5daaec04350a363f186a4d2c5ed6ce.gif)
16
![](https://i-blog.csdnimg.cn/blog_migrate/df37983f39daa189b8c814e01a6a9011.gif)
17
![](https://i-blog.csdnimg.cn/blog_migrate/0ac3a2d53663ec01c7f7225264eeefae.gif)
加入的RenderQueue也是一样,只是pass和对应的renderData我们是从renderqueue里取。
看到这里你会觉得,嘿,很简单嘛,但如果你看了ogre里关于shader参数的细节,你就知道这块还是比较复杂的。我们刚只说了一个运行过程,而建立params到constant registers的关系,以及如何编写autoConstants的代码都是魔鬼的细节~~对于dx,我们可以简单点,直接使用ID3DXConstantTable,它提供了set接口。但ogre则是直接从ID3DXConstantTable中解析参数。
设计这块的时候,脑子里先要对我整个过程有个清晰的认识:一方面是从shader里(我们这里假设是hlsl,asm先不考虑),另一方面则是解析参数读入材质脚本里定义的参数(named,autoNamed,或者index),最后将两者对应上。
0.类型解释
看过OgreGpuProgramParams.cpp/h的人都知道:GpuConstantDefinition,GpuNamedConstants,GpuLogicalIndexUse,GpuSharedParameters,GpuSharedParametersUsage,一堆的struct和class。。其实按照我们上面这个思路逐步加断点分析,代码也没那么繁琐。暂时不看GpuSharedParameters这块,大概看下GpuConstantDefinition,重点变成员是physicalIndex和logicalIndex,前者的解释是buffer中的起始地址,每个GpuProgramParameters里都包含了vector<int>和vector<float>两个buffer,他们存储了shader变量的值,而physicalIndex就是对应vector的索引。而logicalIndex则是我们后面将hlsl编译成asm后这些变量所绑定的寄存器id,而由于constant reg的size都是4,即一个register为4个float的大小,所以这些logicalIndex则不一定连续,譬如第一个uniform为float1那么第二个uniform的logicalIndex虽然是1,但实际跨过了4个float,而实际内存中我们的float(int同) buffer里,两个变量之间的则就空了3个float,这就是physicalIndex的作用,所以我们还需要建立一个从logicalIndex到physicalIndex的map,也就是两个GpuLogicalBuffersStructPtr对象(这两个对象和GpuNamedConstantsPtr在GpuProgram类和GpuProgramParameters是共享的,都是sharedPtr)
1.解析shader的变量
我们从再具体的读取代码来看,假设我们已经从脚本里读入了对应的shader,经过一堆调用后(略。。)在D3D9HLSLProgram的函数buildConstantDefinitions->processParamElement将每个参数的registerIndex,physicalIndex, type(原子类型,即float, int,),size都写入GpuLogicalBuffersStructPtr和GpuNamedConstantsPtr对象里(后者当然是只有highLevelShader里才有),并会为这个定义同样在插入带下标的一对键值,以便于如果我们传入的参数是数组(譬如float4x4[5]),则在程序里可以通过数组下标访问对应的数组变量。再constantDef建立好之后,将GpuNamedConstantsPtr传入到GpuProgramParameters对象里,然后向其中的两个vector添加上述对象大小的空间,在将两个LogicalToPhysicalMap的指针也传到shaderParams里,这样整个GpuProgramParameters几乎就完工了。
2.解析材质里定义的params,并将其与前者对应上
如今就差再把material script定义的param解析出来并与之前shader里的变量进行对应。材质脚本读出的每个变量的信息包含了param类型(named,auto_named,index,auto_index),name,type(float,int..),autoType(auto的才有),初始值等。我们根据其autoType在全局变量AutoConstantDictionary中查找是否有定义,然后调用set[Named]AutoConstant,在这里我们在会在我们之前从hlsl里解析出的GpuNamedConstantsPtr里查找是否有该名字的变量(毕竟shader里的变量才是最终有用的,甚至由于编译器优化的关系,由于shader编写者可能定义了一个变量而未实际使用,在编译shader后,这个变量实际是会被省略的,这样在GpuNamedConstantsPtr也就找不到了)然后调用_setRawAutoConstant将这个变量加入到这个GpuProgramParameters对象所持有的autoConstant中。
(ps:关于_getFloatConstantLogicalIndexUse的用途我没看懂,为何需要去在mFloatLogicalToPhysical里去查找这个logicalIndex是否存在呢,我觉得如果走到这一步肯定shader里肯定就是定义了的,因为这个logicalIndex是由mNamedConstants里取出,我觉得是没必要的。。)
3,更新autoParamsbuffer并最终在DP前进行更新
把上面的过程看懂了,下面就很好理解了。GpuProgramParameters::_updateAutoParams里就是对GpuProgramParameters对象所持有的autoConstant值进行更新,当然这是我们只是对GpuProgramParameters持有的buffer里的值做更新,最终在文章开头的伪代码中的setShaderParams(ogre里叫bindGpuProgramParamters)而这里的更新就轻而易举了,我们遍历logicalToPhysicalMap对每个param取出对应的logicalIndex,dataPointer,vector4ofCount,然后调用SetVertex/PixelShaderConstantF/I即可。
呼。。终于把这块写完了。。上述只是一个实现自己的material的基本思路。关于优化的话,我开头推荐的clayman的文章里有很多叙述。关于怎么写ogre script translator,等下一篇再说。。