3d Game Walkman

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

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

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

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

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

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

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

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

我的窗口向來都設置這個顏色，比較清涼養眼

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

就是個細致活，多畫畫圖，找找規律，自然就能發現其中的拓撲結構了，就是用程序生成索引，然后緩存索引，別無它法，完全避免重復無謂的lock,unlock

當然是用程序來生成索引了，我現在已經改用17x17的規格了,33x33有點大了

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

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

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

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

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

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

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

鎖無關數據結構我還沒找到很好的解決方案

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

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

囧...

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

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

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

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

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

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

我已經深深的愛上deque了 ^^

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

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

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

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

/2/3 /
/1/ ?/

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

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

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

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

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

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

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

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

跟VS里面的停靠窗口一樣的效果啊,懸浮狀態調整大小不影響渲染窗口大小,鉚釘鉚上以后調整大小影響全屏的渲染窗口大小

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

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

目前地形編輯器已經很好的支持室外場景編輯
室內場景也整合到了地形上，正在完善

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

另外：我只搞3D

俺用模版庫寫了一個支持STL容器的Serializer ，內部可選擇用zip壓縮字節，以及加密解密字節，已經用了很久了，感覺很爽

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

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

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

fastdelegate 還可以，去研究一把

做了一點點調整，這個應該就是了

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

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

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

初識A*算法

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

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

主要是看了這段介紹

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

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

收下了，感謝你，鄰居

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

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

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

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

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

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

目前練習完前兩個例子的感覺是，newton的封裝很優雅，非常注意回調函數的使用，狀態監聽能夠運用自如，大大增強了其靈活性，另外newton的文檔也是比較規范的，每個案例都有配套的指南，是很好的教程

準備研究研究newton。

渲染方面學的不好，見笑了。