• <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)絡(luò)引擎 — tonykee's Blog
            隨筆 - 45, 文章 - 0, 評(píng)論 - 309, 引用 - 0
            數(shù)據(jù)加載中……

            最近在對(duì)骨骼導(dǎo)出插件進(jìn)行重構(gòu),有了一些新的感悟

            最近嘗試把3dmax的physique骨骼系統(tǒng)導(dǎo)出插件重構(gòu)成了skin的方式,用了用skin感覺相比physique要強(qiáng)大的多,skin是max最老的蒙皮修改器,應(yīng)該比physique還要早把,但后續(xù)版本升級(jí)做的很強(qiáng)大,據(jù)說(shuō)和maya的方法差不多,physique修改器更新緩慢,而且用了一下確實(shí)是skin的修改器要好用一些,尤其對(duì)于蒙皮人物骨骼按部件進(jìn)行拆分方面,skin方式要方便很多,實(shí)現(xiàn)換裝系統(tǒng)也不是問(wèn)題,我最近正在實(shí)現(xiàn)一套比較好的部件裝配式的換裝系統(tǒng),大體的方法是把人物拆分,按需要進(jìn)行骨骼部件的組裝,比如手,腳,頭發(fā),身體,裙擺,都可以是獨(dú)立的骨架部件,然后組裝在一起,很多游戲其實(shí)都有這樣的功能,實(shí)現(xiàn)方法大同小異吧,不過(guò)我這里有點(diǎn)心得可以分享一下,人物的骨骼導(dǎo)出的時(shí)候不要圖方便只導(dǎo)出每塊骨頭的世界矩陣,而應(yīng)該導(dǎo)出這塊骨頭相對(duì)父骨節(jié)的矩陣,形成一顆顆子樹,這樣做在單副骨架上看似乎沒有什么大的優(yōu)勢(shì),還會(huì)帶來(lái)額外的計(jì)算量,但實(shí)際上要實(shí)現(xiàn)換裝,比如一個(gè)部件從一個(gè)形體直接配置到另外一個(gè)形體上的時(shí)候,優(yōu)勢(shì)就體現(xiàn)出來(lái)了,真的必須這么干啊,我想以后做一些外界作用力的物理效果的時(shí)候,父骨架的偏移影響到子骨架的計(jì)算,或反向IK計(jì)算,應(yīng)該也容易計(jì)算了(比如自由墜落的布娃系統(tǒng))當(dāng)然這是后話了,現(xiàn)在多做點(diǎn)這樣工作,以后擴(kuò)展起來(lái)會(huì)容易很多

            另外有個(gè)心得可以和大家分享一下,那就是關(guān)于骨骼矩陣的導(dǎo)出冗余數(shù)據(jù)的精簡(jiǎn)方法、其實(shí)做過(guò)蒙皮的人應(yīng)該會(huì)知道,一套完整的骨骼動(dòng)畫的數(shù)據(jù)量最大的并不是頂點(diǎn)的數(shù)據(jù),那個(gè)數(shù)量基本固定的,不會(huì)隨動(dòng)作的增長(zhǎng)而變大,真正龐大的是骨骼的關(guān)鍵幀導(dǎo)出數(shù)據(jù)
            來(lái)個(gè)簡(jiǎn)單的計(jì)算,如果一個(gè)蒙皮角色的總骨骼有100根,1000幀的動(dòng)畫
            那么占用的空間= 100 * 1000 * sizeof(D3DXMATRIX)  = 100 *1000 * 64Bytes  差不多占了6MB多的容量,一般一個(gè)角色的動(dòng)畫多達(dá)幾千到上萬(wàn)幀的,那么這個(gè)數(shù)量的增長(zhǎng)是很龐大的,也許你會(huì)覺得這幾MB到10多MB的數(shù)據(jù)量不算什么,現(xiàn)在內(nèi)存不都是幾個(gè)G了嗎?但你要想想,現(xiàn)在游戲卡的現(xiàn)象不在于你cpu多塊,內(nèi)存多大,很大部分愿意是磁盤io讀取慢了,這才是瓶頸,這些年計(jì)算機(jī)的速度是提升了很多倍可就是硬盤的讀寫速度沒什么變化啊,同屏幾十個(gè)不同的角色,如果不預(yù)加載,用實(shí)時(shí)加載,那么一加載起來(lái)動(dòng)不動(dòng)就是幾十MB的數(shù)據(jù),不管什么機(jī)器,再怎么多線程優(yōu)化也一樣卡,即使單機(jī)都會(huì)卡
             
            所以需要想辦法來(lái)壓縮精簡(jiǎn)這些數(shù)據(jù),其實(shí)壓縮的思路并不復(fù)雜,我們的骨骼矩陣一般都用的是線性差值計(jì)算的,max在打上關(guān)鍵幀的時(shí)候也基本上是線性差值的,這樣就好辦了,線性差值的數(shù)據(jù)過(guò)渡一般都有一個(gè)特點(diǎn),那就是比較“平滑”,很多數(shù)據(jù)變化幅度不大的情況下前一幀和后一幀的矩陣平均值剛好等于當(dāng)前幀的矩陣值,就利用這個(gè)特性我們就能過(guò)濾掉相當(dāng)大數(shù)量級(jí)的矩陣了

            以下的算法針對(duì)于連續(xù)線性變換的數(shù)據(jù)精簡(jiǎn)壓縮都是有用的,不僅僅只針對(duì)于矩陣,我在下面的例子里面用的是整數(shù),思路清楚以后換成矩陣就好了


            #include "stdafx.h"
            #include <WTypes.h>
            #include <vector>
            #include <map>
            #include <assert.h>
            using namespace std;

             

            struct  Idinfo
            {
             int id;     //原數(shù)據(jù)索引
             int id0;   //等比區(qū)間索引上界索引
             int id1;   //等比區(qū)間索引下界索引
             BOOL GetValue(map<int,int> & imap, int& val)
             {
              if(id == id0 && id == id1)
              {
               map<int, int>::iterator it0 = imap.find(id0);
               assert(it0 != imap.end());
               val = it0->second;
               return TRUE;
              }
              else if(id > id0 && id < id1)
              {
               map<int, int>::iterator it0 = imap.find(id0);
               map<int, int>::iterator it1 = imap.find(id1);
               assert(it0 != imap.end());
               assert(it1 != imap.end());
               int v0 = it0->second;
               int v1 = it1->second;
               val = v0 + ((v1 - v0) / (id1 - id0)) * (id - id0);
               return TRUE;
              }
              return FALSE;
             }
            };


            int _tmain(int argc, _TCHAR* argv[])
            {
             vector<int> arr; //假設(shè)這里面放的就是線性變換的數(shù)據(jù)
             arr.push_back(2);
             arr.push_back(4);
             arr.push_back(6);
             arr.push_back(8);
             arr.push_back(15);
             arr.push_back(16);
             arr.push_back(17);
             arr.push_back(18);
             arr.push_back(19);
             arr.push_back(20);

             map<int,int,less<int>> imap; //把非等比變化的數(shù)據(jù)導(dǎo)出(自動(dòng)按原索引排序的)
             int sz = (int)arr.size();
             for(int i = 0; i < sz; ++i)
             {
              if(i == 0 || i == sz - 1)
              {
               imap.insert(pair<int, int>(i, arr[i])); //頭尾不過(guò)濾,一定要保留的
              }
              else
              {
               if(arr[i] != (arr[i - 1] + arr[i + 1]) / 2) //過(guò)濾掉前后等比的數(shù)據(jù),
                                                                        //提示一下,如果是浮點(diǎn)數(shù)建議不要這樣比較,浮點(diǎn)數(shù)有誤差的,建議有個(gè)0.0001的容差,視情況而定
               {
                imap.insert(pair<int, int>(i, arr[i]));
               }
              }
             }

             vector<Idinfo> vecIds;  //計(jì)算每個(gè)數(shù)據(jù)的索引描述

             for(int i = 0; i < sz; ++i)
             {
              map<int,int>::iterator it = imap.find(i);

              BOOL _lowBoundFind =  FALSE;
              BOOL _highBoneFind = FALSE;
              Idinfo idInfo;
              idInfo.id = i;
              for(it = imap.begin();it != imap.end(); ++it)
              {
               int id = it->first;
               if(i == id)
               {
                idInfo.id0 = id;
                idInfo.id1 = id;
                _lowBoundFind = TRUE;
                _highBoneFind = TRUE;
               }

               if(i > id)
               {
                idInfo.id0 = id;
                _lowBoundFind = TRUE;
               }

               if(i < id)
               {
                idInfo.id1 = id;
                _highBoneFind = TRUE;
               }

               if(_lowBoundFind && _highBoneFind)
               {
                vecIds.push_back(idInfo);
                break;
               }
              }
             }

             //檢驗(yàn)一下能否把原線性隊(duì)列的數(shù)據(jù)完全還原出來(lái)
             for(vector<Idinfo>::iterator it = vecIds.begin(); it < vecIds.end(); ++it)
             {
              Idinfo & idInfo = *it;
              int id = 0;
              if(idInfo.GetValue(imap, id))
              {
               printf("%d \r\n", id);
              }
             }

             return 0;
            }


            //可以看到,我們實(shí)際導(dǎo)出的是imap就夠了,vecIds可以計(jì)算出來(lái)的,也就是說(shuō)只需要imap就能確定arr集合的每一個(gè)元素了
            上面的例子可以看到10個(gè)元素“壓縮”成了4個(gè)元素,數(shù)據(jù)變化越平滑,壓縮的數(shù)據(jù)量將會(huì)越大

            posted on 2010-10-17 23:51 李侃 閱讀(3593) 評(píng)論(7)  編輯 收藏 引用 所屬分類: 設(shè)計(jì)思路

            評(píng)論

            # re: 最近在對(duì)骨骼導(dǎo)出插件進(jìn)行重構(gòu),有了一些新的感悟[未登錄]  回復(fù)  更多評(píng)論   

            "如果一個(gè)蒙皮角色的總骨骼有100根,1000幀的動(dòng)畫那么占用的空間= 100 * 1000 * sizeof(D3DXMATRIX) = 100 *1000 * 64Bytes 差不多占了6MB多的容量,一般一個(gè)角色的動(dòng)畫多達(dá)幾千到上萬(wàn)幀的,....."
            難道動(dòng)畫沒關(guān)鍵幀插值?為啥每幀都有一個(gè)矩陣?
            2010-10-18 13:50 | kaka

            # re: 最近在對(duì)骨骼導(dǎo)出插件進(jìn)行重構(gòu),有了一些新的感悟  回復(fù)  更多評(píng)論   

            樓主的骨骼動(dòng)畫數(shù)據(jù)可能是通過(guò)采集獲得的,沒有做成關(guān)鍵幀。
            2010-10-18 20:49 | wimdys

            # re: 最近在對(duì)骨骼導(dǎo)出插件進(jìn)行重構(gòu),有了一些新的感悟  回復(fù)  更多評(píng)論   

            今天看了一下max的api,關(guān)鍵幀運(yùn)動(dòng)插值計(jì)算有TCB, BEZIER,和LINEAR三種方式,還要根據(jù)IKeyControl來(lái)獲取旋轉(zhuǎn)、平移、和縮放的x,y,z三個(gè)分量的關(guān)鍵幀控制器,可以說(shuō)相當(dāng)于有9組控制器,通過(guò)這些控制器來(lái)得到運(yùn)動(dòng)軌跡曲線上標(biāo)注的關(guān)鍵幀,三種插值得到的運(yùn)動(dòng)軌跡的變化是不一樣的,前兩個(gè)是曲線,最后一個(gè)是直線,這里面基本意思是看明白了,我決定把這通過(guò)IKeyControl得到的關(guān)鍵幀,和前面提到的幀壓縮算法結(jié)合起來(lái)再來(lái)試驗(yàn)一下效果,但不打算使用TCB和BEZIER兩種計(jì)算方法,這兩種差值算法還要折騰曲線方程,過(guò)于復(fù)雜了,還是打算使用LINEAR線性差值的方式,我想缺點(diǎn)就是動(dòng)作也許會(huì)沒那么平滑吧,就好像行車轉(zhuǎn)彎的時(shí)候按直線轉(zhuǎn)和按弧線轉(zhuǎn),肯定是弧線自然一些,但代價(jià)似乎也不小吧,主要是計(jì)算插值的曲線方程不太容易搞
            2010-10-19 20:14 | 李侃

            # re: 最近在對(duì)骨骼導(dǎo)出插件進(jìn)行重構(gòu),有了一些新的感悟  回復(fù)  更多評(píng)論   

            @李侃
            建議樓主如果是導(dǎo)出關(guān)鍵幀數(shù)據(jù)的話還是用IGAME吧!!用IGame導(dǎo)出關(guān)鍵幀非常方便的哦!!!
            2010-10-23 01:29 | G++

            # re: 最近在對(duì)骨骼導(dǎo)出插件進(jìn)行重構(gòu),有了一些新的感悟  回復(fù)  更多評(píng)論   

            已經(jīng)搞定了,還真是不容易,拋棄矩陣,那玩意根本就不能直接拿來(lái)做線性插值,因?yàn)樾D(zhuǎn)的產(chǎn)生是有弧度的,直接這個(gè)矩陣來(lái)做差值一定會(huì)結(jié)果變成直線位移而嚴(yán)重失真,應(yīng)該用每個(gè)骨骼原點(diǎn)自身的四元素旋轉(zhuǎn)和自身位移和骨骼的世界原點(diǎn)這三個(gè)數(shù)據(jù)來(lái)做,回頭我會(huì)寫一篇具體實(shí)現(xiàn)方法的文章,現(xiàn)在任意時(shí)間的任意頂點(diǎn)的位置經(jīng)過(guò)我的關(guān)鍵幀插值計(jì)算,已經(jīng)和3dmax完全能對(duì)應(yīng)上無(wú)誤差了
            2010-10-24 12:30 | 李侃

            # re: 最近在對(duì)骨骼導(dǎo)出插件進(jìn)行重構(gòu),有了一些新的感悟  回復(fù)  更多評(píng)論   

            對(duì)動(dòng)作進(jìn)行采樣,然后用一定的算法從采樣數(shù)據(jù)中提出關(guān)鍵幀。

            因?yàn)镸ax中的關(guān)鍵幀插值算法比較復(fù)雜(看曲線編輯器)。

            一種幀壓縮算法:
            《Ogre的skeleton數(shù)據(jù)的壓縮》Azure Product
            http://www.azure.com.cn/?id=430
            2010-10-27 20:25 | funcman

            # re: 最近在對(duì)骨骼導(dǎo)出插件進(jìn)行重構(gòu),有了一些新的感悟  回復(fù)  更多評(píng)論   

            Max中的關(guān)鍵幀插值算法的確是比較復(fù)雜,可吃透它意義非同凡響啊

            之前看過(guò)這篇文章,那個(gè)幀壓縮算法我已經(jīng)不需要了,我已經(jīng)成功模擬實(shí)現(xiàn)了max的關(guān)鍵幀的差值算法,通過(guò)這個(gè)把星期的分析把曲線上的數(shù)據(jù)統(tǒng)統(tǒng)解出來(lái)而且吃透了,通過(guò)我的計(jì)算,目前是LINEAR這種方式,任意時(shí)間得到的各頂點(diǎn)的位置和max的一模一樣,這樣下來(lái)根本不用去做什么幀壓縮了,max的動(dòng)畫曲線上有多少個(gè)節(jié)點(diǎn)我就導(dǎo)出多少個(gè)數(shù)據(jù)(導(dǎo)出的數(shù)據(jù)超乎想象的少,打個(gè)比方兩點(diǎn)是一條直線,這條直線多長(zhǎng),我不用關(guān)心,因?yàn)橹本€上的任意一點(diǎn)我能計(jì)算出來(lái),我只需要這兩個(gè)關(guān)鍵點(diǎn)就好了,這才是真正的“關(guān)鍵幀”數(shù)據(jù)插值計(jì)算啊),而且這其中的意義不光在幀數(shù)據(jù)的剔除(過(guò)去的認(rèn)識(shí)很膚淺,骨骼動(dòng)畫不能光是“播放”的),不同動(dòng)畫集動(dòng)作之間的自動(dòng)融合的問(wèn)題用固定的幀數(shù)據(jù)去播放是無(wú)法解決的,想象一下一個(gè)動(dòng)作沒播完,而打斷去播放下一個(gè)動(dòng)作,這兩個(gè)動(dòng)作怎么去自動(dòng)連貫起來(lái)呢?如果要做到自動(dòng)連貫起來(lái),那么過(guò)渡幀的數(shù)據(jù)是要用通過(guò)關(guān)鍵幀插值來(lái)融合計(jì)算的,這能大大豐富動(dòng)作的連貫和動(dòng)作組合的復(fù)雜度,通過(guò)研究和實(shí)現(xiàn)max的插值算法以后正好能很好的解決這個(gè)問(wèn)題

            我導(dǎo)出的數(shù)據(jù)僅僅只有各骨骼關(guān)鍵幀的旋轉(zhuǎn)四元數(shù)(連位移都不需要,我發(fā)現(xiàn)骨骼的移動(dòng)全部是上層旋轉(zhuǎn)帶動(dòng)的,如果不考慮縮放,那么也骨骼根本沒有自身的位移量,看曲線一目了然的),另外還有蒙皮姿勢(shì)的各骨骼初始位置,和蒙皮姿勢(shì)的Mesh各頂點(diǎn),另外還有材質(zhì)等數(shù)據(jù),這些數(shù)據(jù)足以

            目前在這個(gè)基礎(chǔ)之上還實(shí)現(xiàn)了換裝,也就是更換蒙皮骨骼部件的功能,主蒙皮的骨架計(jì)算影響到次級(jí)副部件的子骨架這樣的功能,很快我差不多能實(shí)現(xiàn)蒙皮部件換裝,批量繪制,物件綁定插槽編輯,動(dòng)作標(biāo)簽編輯,動(dòng)作融合設(shè)置,等等...一個(gè)復(fù)雜的蒙皮配置系統(tǒng)了,應(yīng)該會(huì)比OGRE那套復(fù)雜的多
            2010-10-27 21:44 | 李侃
            久久久久久久免费视频| 国产精品美女久久久网AV| 久久WWW免费人成—看片| 国产亚洲精久久久久久无码| 亚洲精品无码久久久久久| 亚洲精品无码久久不卡| 亚洲а∨天堂久久精品9966| 久久本道久久综合伊人| 久久精品女人天堂AV麻| 久久亚洲2019中文字幕| 久久久久女教师免费一区| 亚洲欧美久久久久9999| 中文国产成人精品久久亚洲精品AⅤ无码精品 | 亚洲va中文字幕无码久久| 久久91精品国产91| 久久WWW免费人成一看片| 色综合久久无码中文字幕| 久久精品a亚洲国产v高清不卡| 97久久久久人妻精品专区| 91精品国产高清久久久久久国产嫩草 | 久久99国内精品自在现线| 久久99国产精品尤物| 国产精品青草久久久久婷婷| 国产精品热久久毛片| 亚洲国产高清精品线久久| 久久天天躁夜夜躁狠狠 | 伊人久久大香线蕉av不卡| 一本色道久久综合亚洲精品| 国产精品女同久久久久电影院| 精品久久久久久国产三级| 久久久久亚洲AV无码专区首JN | 久久精品国产精品亜洲毛片| 热99RE久久精品这里都是精品免费| 亚洲AV无码1区2区久久| 99久久精品免费| 精品久久久中文字幕人妻| 91久久精品国产91性色也| 久久久久久久久久久久久久| 中文字幕一区二区三区久久网站| 久久久精品人妻一区二区三区蜜桃| 青青国产成人久久91网|