這幾天把場(chǎng)景的渲染進(jìn)行了重構(gòu),把揀選出來(lái)的模型按類型進(jìn)行了分組，然后安裝組進(jìn)行渲染，最大程度的減少了pass的數(shù)量，另外加入了全場(chǎng)景的PSSM (Parallel-Split Shadow Maps for Large-scale Virtual Environments)，場(chǎng)景的視錐view分成了3個(gè)部分，每個(gè)部分是1024的shadowmap，對(duì)陰影進(jìn)行了 3x3 PCF Filtering 的采樣，鋸齒感不那么強(qiáng)了，有了一定的優(yōu)化，目前還沒(méi)有加入高斯模糊，暫時(shí)不想再做更高的開(kāi)銷了，目前已經(jīng)很好支持pssm和非pssm兩種模式的渲染了，開(kāi)關(guān)陰影都很自由，渲染效率基本滿意。當(dāng)然開(kāi)和關(guān)陰影的效率差不多有40%的差異,這只是初略的測(cè)試，不過(guò)還有很多優(yōu)化的地方，有些物體不需要影子，（比如花草的影子可以關(guān)閉，遠(yuǎn)距離樹(shù)木關(guān)閉影子等等...優(yōu)化）我想效率提升的余地還是很大的。

上個(gè)圖看看效果

     摘要:   閱讀全文

總的來(lái)說(shuō)，和JIT即時(shí)編譯機(jī)制有相通之處，就是一個(gè)創(chuàng)建時(shí)間的比較

 

首先要明白：客戶端的文件如果是最新的，那么創(chuàng)建時(shí)間肯定晚于服務(wù)器上文件的創(chuàng)建時(shí)間，反之客戶端的文件就是舊的需要更新了，但是為了提高更新效率，并不是一個(gè)個(gè)和服務(wù)器上的文件做對(duì)比

而是建立一個(gè)文件列表索引文件，里面記錄服務(wù)器上的“最新版”所有文件的創(chuàng)建時(shí)間，首先更新本地的索引文件，如果更新了，說(shuō)明服務(wù)器上的文件列表有更新，然后和本地做對(duì)比，整理一份需要更新或新建的文件列表清單，然后主動(dòng)連接服務(wù)器進(jìn)行下載，全部完成以后，在索引文件進(jìn)行記錄，更新完一個(gè)就記錄一個(gè)ok，這樣方便“斷點(diǎn)續(xù)傳”，所有都更新完成，全部是ok了，就證明本地都是最新的了，不過(guò)這里面有個(gè)小問(wèn)題是值得注意的，本地文件的創(chuàng)建時(shí)間不能是本地計(jì)算機(jī)的時(shí)間，應(yīng)該下載完以后，修改成服務(wù)器的當(dāng)前時(shí)間，（比如如果本地時(shí)間設(shè)置到了一年以前）那本地的列表可能永遠(yuǎn)都是舊的，每次都要更新，這是可怕的。

通過(guò)這個(gè)文件列表索引，能大大提高更新效率，而且也能做好版本的控制。

另外，更新服務(wù)器一般和游戲服務(wù)器分離，大致思路就是這樣

打包和網(wǎng)絡(luò)傳輸方面，自己封裝一套序列化和反序列化的IO流協(xié)議就可以了，游戲里面這些都必須是最基本的功能了

當(dāng)然，這套思路還有一些不完善的地方，比如更新正在運(yùn)行的exe或一些內(nèi)存保護(hù)的DLL，是比較麻煩的事情,需要盡量避免

     摘要:   閱讀全文

主要是物理攻擊，魔法攻擊（火球術(shù)），怪物的被攻擊后鎖定攻擊者自動(dòng)追逐的簡(jiǎn)單AI(當(dāng)然，還沒(méi)完全完善)，這些動(dòng)作之間的協(xié)調(diào)性都經(jīng)過(guò)了調(diào)試，利用我的骨骼插件加動(dòng)作協(xié)調(diào)的代碼基本都比較流暢了，這其中最難的其實(shí)還是動(dòng)作之間的切換邏輯，還有物理碰撞部分，我整個(gè)碰撞大量使用到了physx里面的trigger shape，加入了攻擊速度的運(yùn)算，總之還是相當(dāng)復(fù)雜的。下一步準(zhǔn)備把這些動(dòng)作的操作完全集成到lua腳本中去，用狀態(tài)機(jī)來(lái)協(xié)調(diào)這寫動(dòng)作，實(shí)現(xiàn)動(dòng)作控制部分與引擎的分離

     摘要:   閱讀全文

這半個(gè)月的收獲太大了，終于可以宣布拋棄其他任何的mesh格式了，因?yàn)槲彝耆珦碛辛俗约旱膍esh格式

主要分為三類
1.普通的mesh
2.室內(nèi)Portal 場(chǎng)景
3.骨骼動(dòng)畫(huà)
這三個(gè)類別做了個(gè)簡(jiǎn)單的整合，過(guò)兩天打算做成max工具面板的形式來(lái)導(dǎo)出，我想操作起來(lái)會(huì)更方便吧

開(kāi)發(fā)體會(huì)：
---------------------------------------
這段時(shí)間全力在攻克骨骼動(dòng)畫(huà)的導(dǎo)出，可真是不容易啊，找了很多資料，可以所是摸著石頭過(guò)河的
把x格式研究了一遍又一遍，max sdk 快翻爛了，max sdk里面的東西簡(jiǎn)直就可以“沒(méi)有天理”來(lái)形容
國(guó)外的資料也查的快瘋掉，好歹摸索出來(lái)了

目前的數(shù)據(jù)導(dǎo)出基本按照x格式的思路來(lái)組織，導(dǎo)出數(shù)據(jù)來(lái)計(jì)算的，拋棄了3dmax建議的骨骼空間本地頂點(diǎn)的插值計(jì)算方式
而采用了對(duì)原始蒙皮姿勢(shì)的mesh頂點(diǎn)直接按骨骼權(quán)重的方式進(jìn)行計(jì)算，就蒙皮姿勢(shì)的數(shù)據(jù)就讓我好找啊
原來(lái)還覺(jué)得x的格式太繁瑣復(fù)雜，現(xiàn)在回頭看看人家的數(shù)據(jù)組織的卻是非常的合理，導(dǎo)出的不僅僅只是動(dòng)畫(huà)
還可以用程序來(lái)控制里面的骨骼的變動(dòng)，和物理引擎的結(jié)合就方便了，比如做一個(gè)從懸崖上掉下來(lái)的人，這可不是動(dòng)畫(huà)能解決的啦
目前的結(jié)構(gòu)應(yīng)該可以完好的和物理引擎進(jìn)行整合，這將做為以后的研究了

總體上來(lái)說(shuō)我的骨骼插件主要用的是Physique modifer 來(lái)支持動(dòng)畫(huà)輸出的
目前支持能 max原始的bone骨骼，以及bip骨骼
原始的bone骨骼的IK還沒(méi)能導(dǎo)出，存在一點(diǎn)點(diǎn)誤差，不過(guò)bip骨骼運(yùn)用的更多一些，已經(jīng)完美支持了
所以IK計(jì)算的導(dǎo)出暫時(shí)也就放放了 (主要是IK的有些太復(fù)雜，還沒(méi)來(lái)得及搞懂 -_-! ）
Floating 骨骼也暫時(shí)放放，要完善的內(nèi)容其實(shí)也還是很多的

有了Physique 修改器的經(jīng)驗(yàn)，我想做個(gè)blend之類的morph動(dòng)畫(huà)導(dǎo)出插件應(yīng)該也沒(méi)問(wèn)題了，比如面部表情什么的，以后有需要的時(shí)候再繼續(xù)吧

現(xiàn)在有了完整的一套自己的模型格式，以后要擴(kuò)展，比如在mesh里加入粒子動(dòng)畫(huà)，甚至是邏輯數(shù)據(jù)都不成問(wèn)題了，根據(jù)需要去擴(kuò)展起來(lái)也相當(dāng)容易了

明天打算把渲染的部分給搞出來(lái)，準(zhǔn)備做個(gè)固定管線和   GPU  計(jì)算的 vertBlend shader   的兩個(gè)版本出來(lái)，這個(gè)很easy，預(yù)計(jì)明天上午就搞出來(lái)

還是老規(guī)矩，上圖

新的進(jìn)展，完成了室內(nèi)場(chǎng)景的導(dǎo)出，以及和室外場(chǎng)景的整合，動(dòng)態(tài)加載和剪裁，以及物理部分都搞好了

下一步，做室內(nèi)物品的編輯和室內(nèi)的尋路徑算法

過(guò)去這貼圖這塊做的很草率，整個(gè)大地形只有6張紋理，太單調(diào)，這兩天改成每個(gè)tile可選6張紋理，可視化編輯很方便，tile和tile銜接的不同通道紋理過(guò)渡都做的很自然了，主要是編輯器的編輯方式比較順手，這樣地貌就非常豐富了


上圖

 

下一步，把室內(nèi)和室外場(chǎng)景的編輯鏈接起來(lái)，而且全部應(yīng)用物理引擎

     摘要:   閱讀全文