月下的博客

自從以前看了clayman的博客后，就很想把自己代碼里dx的effect框架替代掉。如今實(shí)習(xí)結(jié)束正好有短暫的自由時(shí)間，所以就ogre的material開(kāi)刀吧。

  山寨代碼也是有學(xué)問(wèn)的，如果你想搞明白這些代碼的含義的話(huà)，最后之前就對(duì)這些已經(jīng)有了一定的使用經(jīng)歷和認(rèn)知，第一步先得自己想一下material系統(tǒng)的組成：
material應(yīng)該包含的：1Material->n Techinque->(n Pass + extra params)->(n TextureUnit + m or 0 shaderUnit + n RenderStates（部分）),Pass里的TextureUnit又包含了這一組texture的相關(guān)信息和設(shè)置，TexcoordSet, AddressMode, FilterSetting等等， ShaderUnit則是對(duì)應(yīng)于vs，fs以及新的gs，普通點(diǎn)也就最多兩組。shaderUnit包含了具體的shader和其shaderParams，為何要把shader和shaderParams分開(kāi)呢，不說(shuō)設(shè)計(jì)優(yōu)雅的考慮，簡(jiǎn)單的說(shuō)就是方便，很多時(shí)候params可能會(huì)需要共享，譬如shaderA里用到mvpMat，和eyePos， diffuse,specular,可能shaderB也只用到這些，但是兩個(gè)shader的內(nèi)部計(jì)算并不相同。到此我們只分析了作為程序中的材質(zhì)的結(jié)構(gòu)，還需要考慮如果編寫(xiě)一個(gè)類(lèi)似fx格式的material script，這也是另外一個(gè)大頭，簡(jiǎn)單的說(shuō)就是要做個(gè)腳本解釋?zhuān)缓蠼oshader參數(shù)加上語(yǔ)義，減少大部分需要手動(dòng)更新的shaderParams。鑒于我如今還沒(méi)把這塊扒完，等下次再寫(xiě)這塊吧。


   當(dāng)你至少能閉著眼睛想透這些了，那就可以開(kāi)始看ogre的material system了，先說(shuō)句題外話(huà)，我讀ogre的代碼其實(shí)讀挺久了。一直覺(jué)得很難讀，開(kāi)始覺(jué)得是自己水平不夠，但后來(lái)實(shí)習(xí)才發(fā)現(xiàn)很多人都有這想法，甚至wolfgang對(duì)此也有批評(píng)，而自己曾經(jīng)寫(xiě)了個(gè)olong引擎，接觸過(guò)ipad編程的人應(yīng)該對(duì)這些代碼都比較熟悉～ogre里用了大量的設(shè)計(jì)模式，使得整個(gè)渲染流程從不同類(lèi)里跳來(lái)跳去（SceneMgr這塊看著最累了。。其實(shí)有很多地方看著都很累。。）個(gè)人覺(jué)得應(yīng)該把render從SceneMgr里抽離出來(lái)做個(gè)RenderMgr，（記住這里的RenderMgr的概念和ogre的RenderSystem，后者是提供底層渲染API的接口，而前者是管理renderData并最終遞交給RenderSystem，以前也見(jiàn)有別人博客講過(guò)這個(gè)問(wèn)題）讓SceneMgr專(zhuān)門(mén)管理Scene。。
  打住打住。。我是來(lái)寫(xiě)material的。。咳咳。。相當(dāng)于渲染來(lái)說(shuō)，ogre的material system還是相當(dāng)易讀的，也是因?yàn)檫@些模塊相互關(guān)系幾乎都是單向的，我們開(kāi)始編寫(xiě)的時(shí)候可以先不考慮Technique，就是直接1 Material->n Pass->...當(dāng)然甚至你都可以把multi pass去掉,就等同于1個(gè)pass，當(dāng)然由于pass都代碼實(shí)際也沒(méi)多少，我們還是加上好了。

原始渲染的偽代碼就是：

 1for each pass
 2{
 3  setRenderStates(like alphe belnd, depth..)
 4  for each texture unit
 5    setTexSettings();
 6  if(hasVertexShader())
 7  {
 8    bindVertexShader();
 9    setShaderParams(vs);
10  }
11  if(hasFragmentShader())
12  {
13    bindFragmentShader();
14    setShaderParams(fs);
15  }
16  drawPrimitives();
17}

加入的RenderQueue也是一樣，只是pass和對(duì)應(yīng)的renderData我們是從renderqueue里取。

看到這里你會(huì)覺(jué)得，嘿，很簡(jiǎn)單嘛，但如果你看了ogre里關(guān)于shader參數(shù)的細(xì)節(jié)，你就知道這塊還是比較復(fù)雜的。我們剛只說(shuō)了一個(gè)運(yùn)行過(guò)程，而建立params到constant registers的關(guān)系，以及如何編寫(xiě)autoConstants的代碼都是魔鬼的細(xì)節(jié)～～對(duì)于dx，我們可以簡(jiǎn)單點(diǎn)，直接使用ID3DXConstantTable，它提供了set接口。但ogre則是直接從ID3DXConstantTable中解析參數(shù)。

   設(shè)計(jì)這塊的時(shí)候，腦子里先要對(duì)我整個(gè)過(guò)程有個(gè)清晰的認(rèn)識(shí)：一方面是從shader里（我們這里假設(shè)是hlsl，asm先不考慮）,另一方面則是解析參數(shù)讀入材質(zhì)腳本里定義的參數(shù)（named，autoNamed，或者index），最后將兩者對(duì)應(yīng)上。

0.類(lèi)型解釋
看過(guò)OgreGpuProgramParams.cpp/h的人都知道：GpuConstantDefinition，GpuNamedConstants，GpuLogicalIndexUse，GpuSharedParameters，GpuSharedParametersUsage，一堆的struct和class。。其實(shí)按照我們上面這個(gè)思路逐步加斷點(diǎn)分析，代碼也沒(méi)那么繁瑣。暫時(shí)不看GpuSharedParameters這塊，大概看下GpuConstantDefinition,重點(diǎn)變成員是physicalIndex和logicalIndex，前者的解釋是buffer中的起始地址，每個(gè)GpuProgramParameters里都包含了vector<int>和vector<float>兩個(gè)buffer,他們存儲(chǔ)了shader變量的值，而physicalIndex就是對(duì)應(yīng)vector的索引。而logicalIndex則是我們后面將hlsl編譯成asm后這些變量所綁定的寄存器id，而由于constant reg的size都是4，即一個(gè)register為4個(gè)float的大小，所以這些logicalIndex則不一定連續(xù)，譬如第一個(gè)uniform為float1那么第二個(gè)uniform的logicalIndex雖然是1，但實(shí)際跨過(guò)了4個(gè)float，而實(shí)際內(nèi)存中我們的float（int同） buffer里，兩個(gè)變量之間的則就空了3個(gè)float，這就是physicalIndex的作用，所以我們還需要建立一個(gè)從logicalIndex到physicalIndex的map，也就是兩個(gè)GpuLogicalBuffersStructPtr對(duì)象（這兩個(gè)對(duì)象和GpuNamedConstantsPtr在GpuProgram類(lèi)和GpuProgramParameters是共享的，都是sharedPtr）

1.解析shader的變量
   我們從再具體的讀取代碼來(lái)看，假設(shè)我們已經(jīng)從腳本里讀入了對(duì)應(yīng)的shader，經(jīng)過(guò)一堆調(diào)用后（略。。）在D3D9HLSLProgram的函數(shù)buildConstantDefinitions->processParamElement將每個(gè)參數(shù)的registerIndex,physicalIndex, type(原子類(lèi)型，即float, int,),size都寫(xiě)入GpuLogicalBuffersStructPtr和GpuNamedConstantsPtr對(duì)象里（后者當(dāng)然是只有highLevelShader里才有），并會(huì)為這個(gè)定義同樣在插入帶下標(biāo)的一對(duì)鍵值，以便于如果我們傳入的參數(shù)是數(shù)組（譬如float4x4[5]），則在程序里可以通過(guò)數(shù)組下標(biāo)訪問(wèn)對(duì)應(yīng)的數(shù)組變量。再constantDef建立好之后，將GpuNamedConstantsPtr傳入到GpuProgramParameters對(duì)象里，然后向其中的兩個(gè)vector添加上述對(duì)象大小的空間，在將兩個(gè)LogicalToPhysicalMap的指針也傳到shaderParams里，這樣整個(gè)GpuProgramParameters幾乎就完工了。

2.解析材質(zhì)里定義的params，并將其與前者對(duì)應(yīng)上
  如今就差再把material script定義的param解析出來(lái)并與之前shader里的變量進(jìn)行對(duì)應(yīng)。材質(zhì)腳本讀出的每個(gè)變量的信息包含了param類(lèi)型（named，auto_named，index，auto_index），name,type(float,int..),autoType(auto的才有)，初始值等。我們根據(jù)其autoType在全局變量AutoConstantDictionary中查找是否有定義，然后調(diào)用set[Named]AutoConstant，在這里我們?cè)跁?huì)在我們之前從hlsl里解析出的GpuNamedConstantsPtr里查找是否有該名字的變量（畢竟shader里的變量才是最終有用的，甚至由于編譯器優(yōu)化的關(guān)系，由于shader編寫(xiě)者可能定義了一個(gè)變量而未實(shí)際使用，在編譯shader后，這個(gè)變量實(shí)際是會(huì)被省略的，這樣在GpuNamedConstantsPtr也就找不到了）然后調(diào)用_setRawAutoConstant將這個(gè)變量加入到這個(gè)GpuProgramParameters對(duì)象所持有的autoConstant中。

（ps：關(guān)于_getFloatConstantLogicalIndexUse的用途我沒(méi)看懂，為何需要去在mFloatLogicalToPhysical里去查找這個(gè)logicalIndex是否存在呢，我覺(jué)得如果走到這一步肯定shader里肯定就是定義了的，因?yàn)檫@個(gè)logicalIndex是由mNamedConstants里取出，我覺(jué)得是沒(méi)必要的。。）

3，更新autoParamsbuffer并最終在DP前進(jìn)行更新

把上面的過(guò)程看懂了，下面就很好理解了。GpuProgramParameters::_updateAutoParams里就是對(duì)GpuProgramParameters對(duì)象所持有的autoConstant值進(jìn)行更新，當(dāng)然這是我們只是對(duì)GpuProgramParameters持有的buffer里的值做更新，最終在文章開(kāi)頭的偽代碼中的setShaderParams（ogre里叫bindGpuProgramParamters）而這里的更新就輕而易舉了，我們遍歷logicalToPhysicalMap對(duì)每個(gè)param取出對(duì)應(yīng)的logicalIndex，dataPointer，vector4ofCount，然后調(diào)用SetVertex/PixelShaderConstantF/I即可。

呼。。終于把這塊寫(xiě)完了。。上述只是一個(gè)實(shí)現(xiàn)自己的material的基本思路。關(guān)于優(yōu)化的話(huà)，我開(kāi)頭推薦的clayman的文章里有很多敘述。關(guān)于怎么寫(xiě)ogre script translator，等下一篇再說(shuō)。。