• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            3d Game Walkman

            3d圖形渲染,網(wǎng)絡引擎 — tonykee's Blog
            隨筆 - 45, 文章 - 0, 評論 - 309, 引用 - 0
            數(shù)據(jù)加載中……

            新加入了PSSM全場景陰影

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

            上個圖看看效果

            posted @ 2009-06-17 23:53 李侃 閱讀(3633) | 評論 (11)編輯 收藏

            今天找到一個不得不用deque的理由

                 摘要:   閱讀全文

            posted @ 2009-05-24 13:25 李侃 閱讀(8295) | 評論 (15)編輯 收藏

            游戲資源在線更新的思路

            總的來說,和JIT即時編譯機制有相通之處,就是一個創(chuàng)建時間的比較

             

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

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

            通過這個文件列表索引,能大大提高更新效率,而且也能做好版本的控制。

            另外,更新服務器一般和游戲服務器分離,大致思路就是這樣

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

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

            posted @ 2009-05-08 23:27 李侃 閱讀(2371) | 評論 (9)編輯 收藏

            OO中對于23種設計模式的整理

                 摘要:   閱讀全文

            posted @ 2009-04-22 01:00 李侃 閱讀(7664) | 評論 (4)編輯 收藏

            最新的進展,完成一些客戶端的打怪的代碼

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

            posted @ 2009-03-18 13:48 李侃 閱讀(2029) | 評論 (3)編輯 收藏

            轉(zhuǎn)載—網(wǎng)絡游戲程序中解決加載卡頓的有效方法

                 摘要:   閱讀全文

            posted @ 2009-02-28 13:47 李侃 閱讀(1450) | 評論 (2)編輯 收藏

            這半個月把所有的Max導出插件全部集成了,新增加了骨骼導出插件

            這半個月的收獲太大了,終于可以宣布拋棄其他任何的mesh格式了,因為我完全擁有了自己的mesh格式

            主要分為三類
            1.普通的mesh
            2.室內(nèi)Portal 場景
            3.骨骼動畫
            這三個類別做了個簡單的整合,過兩天打算做成max工具面板的形式來導出,我想操作起來會更方便吧

            開發(fā)體會:
            ---------------------------------------
            這段時間全力在攻克骨骼動畫的導出,可真是不容易啊,找了很多資料,可以所是摸著石頭過河的
            把x格式研究了一遍又一遍,max sdk 快翻爛了,max sdk里面的東西簡直就可以“沒有天理”來形容
            國外的資料也查的快瘋掉,好歹摸索出來了

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

            總體上來說我的骨骼插件主要用的是Physique modifer 來支持動畫輸出的
            目前支持能 max原始的bone骨骼,以及bip骨骼
            原始的bone骨骼的IK還沒能導出,存在一點點誤差,不過bip骨骼運用的更多一些,已經(jīng)完美支持了
            所以IK計算的導出暫時也就放放了 (主要是IK的有些太復雜,還沒來得及搞懂 -_-! )
            Floating 骨骼也暫時放放,要完善的內(nèi)容其實也還是很多的

            有了Physique 修改器的經(jīng)驗,我想做個blend之類的morph動畫導出插件應該也沒問題了,比如面部表情什么的,以后有需要的時候再繼續(xù)吧

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

            明天打算把渲染的部分給搞出來,準備做個固定管線和   GPU  計算的 vertBlend shader   的兩個版本出來,這個很easy,預計明天上午就搞出來

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





            posted @ 2009-01-14 23:51 李侃 閱讀(3946) | 評論 (3)編輯 收藏

            新的進展,完成了室內(nèi)場景的導出以及和室外場景的整合

            新的進展,完成了室內(nèi)場景的導出,以及和室外場景的整合,動態(tài)加載和剪裁,以及物理部分都搞好了

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

            posted @ 2008-11-27 14:35 李侃 閱讀(1678) | 評論 (4)編輯 收藏

            今天對之前地形的貼圖部分進行了完善,每個Tile可選6張紋理,可視化編輯方便極了

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


            上圖

             

            下一步,把室內(nèi)和室外場景的編輯鏈接起來,而且全部應用物理引擎

            posted @ 2008-10-25 10:25 李侃 閱讀(3506) | 評論 (6)編輯 收藏

            模版函數(shù)指針,C++委托的實現(xiàn)-原創(chuàng)

                 摘要:   閱讀全文

            posted @ 2008-09-29 13:23 李侃 閱讀(6748) | 評論 (14)編輯 收藏

            僅列出標題
            共5頁: 1 2 3 4 5 
            久久成人精品| 蜜臀av性久久久久蜜臀aⅴ麻豆| 狠狠久久亚洲欧美专区| 情人伊人久久综合亚洲| 久久久中文字幕日本| 久久久久亚洲AV成人网人人网站| 亚洲愉拍99热成人精品热久久| 色欲久久久天天天综合网精品 | 热99RE久久精品这里都是精品免费 | 国产精品久久波多野结衣| 久久久久99精品成人片三人毛片 | 精品久久久久久久无码| 亚洲国产成人久久综合区| 国产精品久久久久久一区二区三区| 久久五月精品中文字幕| 少妇高潮惨叫久久久久久| 久久se精品一区精品二区国产 | 品成人欧美大片久久国产欧美... 品成人欧美大片久久国产欧美 | 99久久777色| 久久婷婷五月综合97色直播| 99久久综合狠狠综合久久止| 久久九九兔免费精品6| 久久99精品久久久久久齐齐| 91久久精一区二区三区大全| 亚洲国产另类久久久精品| 亚洲国产精品成人久久蜜臀| 精品久久久久久无码中文野结衣| 激情伊人五月天久久综合| 久久久午夜精品| 欧美成a人片免费看久久| 久久青草国产精品一区| 国产精品99久久久久久人| 亚洲中文字幕久久精品无码喷水| 性做久久久久久免费观看| 久久人妻少妇嫩草AV蜜桃| 日韩精品久久久久久| 99久久精品国产一区二区三区| 91久久精品91久久性色| 97久久香蕉国产线看观看| 色综合久久天天综合| 欧美亚洲另类久久综合|