3d Game Walkman

每個人物2000多個多邊形吧，我這邊繪制基本上不是瓶頸，用了分組批量繪制，很省，計算骨骼放在其他核心上，用了無鎖模式，不干擾主繪制線程，但如果是單核cpu估計會很慘

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

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

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

目前在這個基礎(chǔ)之上還實現(xiàn)了換裝，也就是更換蒙皮骨骼部件的功能，主蒙皮的骨架計算影響到次級副部件的子骨架這樣的功能，很快我差不多能實現(xiàn)蒙皮部件換裝，批量繪制，物件綁定插槽編輯，動作標簽編輯，動作融合設(shè)置，等等...一個復(fù)雜的蒙皮配置系統(tǒng)了，應(yīng)該會比OGRE那套復(fù)雜的多

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

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

設(shè)定好閥值是不會出現(xiàn)裂縫的，我現(xiàn)在引擎正在用dx10重構(gòu)，地形這部分我現(xiàn)在重新整理，已經(jīng)有了很好的提升方法，我目前在考慮9宮之外的tile整體lod輸出，9宮格內(nèi)的按block lod 輸出，9宮之外的tile加載的數(shù)據(jù)非常少，可視距離可以擴展2到三圍tile的范圍，這樣能夠花較少的代價看到更多更遠的地形細節(jié)，也就是看的更遠，這部分提升空間蠻大的。

我的窗口向來都設(shè)置這個顏色，比較清涼養(yǎng)眼

6個月太短了，我搞了三年半了，完全靠自學(xué)進步同樣緩慢，很多地方也還很欠缺，就是有計劃的去修煉提高，欲速則不達

就是個細致活，多畫畫圖，找找規(guī)律，自然就能發(fā)現(xiàn)其中的拓撲結(jié)構(gòu)了，就是用程序生成索引，然后緩存索引，別無它法，完全避免重復(fù)無謂的lock,unlock

當然是用程序來生成索引了，我現(xiàn)在已經(jīng)改用17x17的規(guī)格了,33x33有點大了

這個很容易的，只要做好地形編輯器，讓地形刷子能精確控制邊界的貼圖過渡的問題,剛好這部分最近正好在重構(gòu)，混合部分我打算采用改進的“非線性”混合，能大大提高混合精度，待重構(gòu)完成，其具體做法，我不久之后會發(fā)布到博客上，敬請留意

其實看看那些藝術(shù)照和生活照的區(qū)別，就是暈光蒙蒙的效果，對比也顯得強烈，看少了還不錯，看多了，就不爽了，感覺不真實

有的人會說，如果不是藝術(shù)照下的MM都很迷人就是極品了。
扯的有點遠了 : )

不會啊，我用著沒問題，很久沒搞過newton了，早改physx了
不過physx的例子也用的GL，跟渲染引擎沒關(guān)系，你只要關(guān)心物理方面的結(jié)構(gòu)就行了，看東最開始的例子，然后憑理解在dx里面寫，都差不多

MFC都用習(xí)慣了，是陳舊了點，不知道為什么沒有后續(xù)支持來升級UI庫，可能這就是真正挨罵的原因吧，
WxWidget 好像也是很龐大的哦，里面的例子很多，確實很吸引人

這片文章很老了，但確實是好文章，過去就是看了該文來寫A*的。

同意2樓，共享資源傳統(tǒng)的方式最好使用共享鎖和排他鎖，分而治之，可以參考讀寫鎖的實現(xiàn)方法win32下單進程內(nèi)建議使用用戶模式，interlock系列函數(shù)足以

鎖無關(guān)數(shù)據(jù)結(jié)構(gòu)我還沒找到很好的解決方案

全部是網(wǎng)上找的資料，GEM系列書上有介紹過，資料很零碎，具體上面的狀態(tài)機封裝形式還要結(jié)合腳本引擎，才能真正發(fā)揮它的威力，我已經(jīng)這么做了，總之，就是一句話：很好很強大 o(∩_∩)o...

我用的是directx，模型采用自己的格式用的是shader和固定管線兩個版本都支持

囧...

我明白，如果是vector<Entity*>的方式，根本不用去討論該去用vector還是queue，重排就重排了，指針不會變
但如果是vector<Entity> 的形式情況就不同了

這樣的類別的集合確實就不該直接去引用集合中元素的地址，這不是一個好的習(xí)慣。

主要是：我的序列化存儲層只能支持 集合<entity>的形式
不支持 集合<Entity*>的形式，想引用從文件讀取的集合數(shù)據(jù)又不想做太多的拷貝，迫于無賴。

只好回頭再想想看有沒有更好的折中方案了。

后面的部分是我摘錄網(wǎng)上的文章，覺得好像也沒什么不妥
當然了如果元素被移除了，這樣去訪問那會是危險的。

我試了試，似乎erase中間的元素以后，各元素的地址依然穩(wěn)定，vc自帶的的deque 是這樣的，不知道其他版本的deque會不會也是這樣？

我已經(jīng)深深的愛上deque了 ^^

我現(xiàn)在討論的不是迭代，任何集合都能迭代，光用一個iterator去遍歷，任何集合都沒有差別了。那一個vector就夠了還要list和deque做什么？

我現(xiàn)在討論的是它們的內(nèi)部結(jié)構(gòu)的差別，根據(jù)不同的場景而要用出這些集合的差別才是真道理，樓上看清楚，我現(xiàn)在就是想在外部指針去引用集合內(nèi)部的元素，就是不想每次訪問的時候都去迭代，集合如果只增不減的情況下，用deque是穩(wěn)定的,而vector是不穩(wěn)定的，vector存在空間重排，deque不存在空間重排，這是我要闡述的觀點

那DLL里面的版本號呢？功能模塊的DLL都是編譯器生成的，你要在每個DLL里面再附加資源信息嗎？我覺得有點繁瑣了。何況如果每個文件都去解析里面的版本號的數(shù)據(jù)，速度是會很慢的，不僅繁瑣，而且更難控制。
不過一些版本控制軟件的卻是加了版本號的，但也是有版本索引文件去記錄這些版本，但絕對沒有要求一定要在源文件中去加版本號。所以時間要素控制版本是高效便宜的做法

我是在
http://www.codeproject.com/
好久以前的找的，別人對MFC擴展的控件，

/2/3 /
/1/ ?/

?號的部分的級別顯然應(yīng)該是2，觀測點因該在1點半的方位，前面敘述過，而且實踐檢驗過，通過設(shè)定好的閥值，相鄰的block級別不可能相差超過1的

各種級別和邊的補縫形態(tài)索引的確是要計算的，但用過了不要浪費，我定義了一個cache，四條邊的補縫形態(tài)以及除了四條邊以外中間的形態(tài)都放入了緩存，緩存找不到的時候就計算，然后加入緩存，最終緩存能把所有形態(tài)填充到緩存，就不再需要計算lod形態(tài)了，我采用的就是這樣的算法，能很有效的避免lock unlock，另外這點內(nèi)存上的開銷在空間上幾乎是一次性的開銷，其實非常的小，不必在意的。

lod影響的因素如果考慮起伏分布，的確是個高級話題，暫且還沒考慮這些要求，但如果做個地理信息系統(tǒng)的時候，確實就很有必要了。

過年回家上次網(wǎng)不容易
lod級別我用的是最簡單的 觀測點到block中心距離×閥值(一個小數(shù)) 來確定的，相當于運用一個策略鉗制一個LOD當量在可用級別范圍內(nèi)，傳統(tǒng)的方式都是這樣做的，當然要做的更復(fù)雜，不能光靠距離來決定lod級別，比如起伏大的地形用高的級別，平坦的地域用低的級別，這可以說是另一個高級話題了

這帖子快一年了，回頭看看，還真是感觸頗多啊
后來我還是自己寫了一套序列化的庫，完全支持stl + zlib字節(jié)壓縮的的序列化庫，最終還是沒有采用結(jié)構(gòu)體的方式

自己寫的這套庫工作了很久了，也是我的IO和網(wǎng)絡(luò)流的底層，用起來還是很方便的，足夠了

3dMax里面一組面可以成為一個mesh，每個房間的面是一組mesh，是手工拆分好的，沒有按照自動拆分portal的方式來做，那樣太變態(tài)了，還是手工來的準確和靈活

偶現(xiàn)在用physx了，很久沒用過newton了，physx那里面的矩陣和dx的到是不一樣

跟VS里面的?？看翱谝粯拥男Ч?懸浮狀態(tài)調(diào)整大小不影響渲染窗口大小,鉚釘鉚上以后調(diào)整大小影響全屏的渲染窗口大小

我的無限大是指：想要多大就多大，也就是說無論多大就可以。

我已經(jīng)實現(xiàn)了從一頭走到另一頭走1天也走不到頭的地形，無論多大運行速度都不受影響，場景所有數(shù)據(jù)全部實時動態(tài)加載和釋放，而且已經(jīng)研發(fā)了配套的地圖編輯器，全部采用可視化編輯的支持

目前地形編輯器已經(jīng)很好的支持室外場景編輯
室內(nèi)場景也整合到了地形上，正在完善

所有的已經(jīng)全部按計劃實現(xiàn)了，目前在做符合游戲引擎要求的進一步完善
比如AI所需要的數(shù)據(jù)設(shè)置等等一些東西，地貌的渲染部分是下一個階段的目標

另外：我只搞3D

俺用模版庫寫了一個支持STL容器的Serializer ，內(nèi)部可選擇用zip壓縮字節(jié)，以及加密解密字節(jié)，已經(jīng)用了很久了，感覺很爽

每個tile是獨立的blendmap，而且我用了兩層，其實完全可以考慮只用一層，就混6張，每個通道0－127 一個圖128-255一個圖， 127的色階基本也夠用，以前見有人這么搞過，后來想想也沒必要節(jié)約這點資源了。

這部分做了改進
http://www.shnenglu.com/tonykee/archive/2008/10/25/64982.html
呵呵，已非昔比了

boost是很好，可有些龐大，目前并不打算使用
我已經(jīng)加入了fastdelegate，這個短小精悍，足以解決我的問題了。

fastdelegate 還可以，去研究一把

做了一點點調(diào)整，這個應(yīng)該就是了

不算太復(fù)雜，SDK里面很多文檔和例子可以參考，我目前只簡單弄了弄靜態(tài)模型的導(dǎo)出，動畫方面的模型導(dǎo)出還沒做深入的研究，另外導(dǎo)出格式自定義的流格式，對串化需要做深入的研究，否則只有xml了

我還是使用了以前的方案，沒有放在OnIdle里面
這個函數(shù)在優(yōu)先級別太低了。

原先看了游戲精粹2介紹的就是這樣的索引形勢，沒什么詭異的??？

初識A*算法

f(n) = g(n) + h(n)

　　其中f(n)是節(jié)點n的估價函數(shù)，g(n)實在狀態(tài)空間中從初始節(jié)點到n節(jié)點的實際代價，h(n)是從n到目標節(jié)點最佳路徑的估計代價。在這里主要是h(n)體現(xiàn)了搜索的啟發(fā)信息，因為g(n)是已知的。如果說詳細點，g(n)代表了搜索的廣度的優(yōu)先趨勢。但是當h(n)>>g(n)時，可以省略g(n),而提高效率。

主要是看了這段介紹

是啊，H做了判定，G沒有考慮，需要改進一下評估函數(shù)

我現(xiàn)在決定選擇luaplus和C++連接了，那樣方便很多
否則全手工調(diào)用那些棧真的很煩

收下了，感謝你，鄰居

剛下了physX，里面的布料效果很吸引人，沒有物理顯卡，跑的也還算流暢。
文檔很齊全，看來是得認真考慮考慮了

給你看另外一個東西
http://www.cnbeta.com/articles/57171.htm

你覺得這個大家伙怎么樣？夠成熟吧

呵呵，這個我知道，只是覺得phyx太過商業(yè)化了，而且需要那個什么物理卡，真不知道沒有那物理卡性能會怎么樣？

GL現(xiàn)在已經(jīng)不再是問題，我在試著用dx做第三個例子。
newton的物理引擎的api 函數(shù)真的很繁多，要想用好他們，不是那么容易的事情，還有一些物理知識也有些生疏，這樣看來掌握好也不是一兩天的事情了。

計劃把sdk里面提供的12個例子全部看完先。

目前練習(xí)完前兩個例子的感覺是，newton的封裝很優(yōu)雅，非常注意回調(diào)函數(shù)的使用，狀態(tài)監(jiān)聽能夠運用自如，大大增強了其靈活性，另外newton的文檔也是比較規(guī)范的，每個案例都有配套的指南，是很好的教程

準備研究研究newton。

渲染方面學(xué)的不好，見笑了。