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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

囧...

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

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

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

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

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

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

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

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

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

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

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

/2/3 /
/1/ ?/

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

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

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

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

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

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

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

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

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

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

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

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

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

另外：我只搞3D

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

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

這部分做了改進(jìn)
http://m.shnenglu.com/tonykee/archive/2008/10/25/64982.html
呵呵，已非昔比了

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

fastdelegate 還可以，去研究一把

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

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

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

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

初識A*算法

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

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

主要是看了這段介紹

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

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

收下了，感謝你，鄰居

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

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

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

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

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

計(jì)劃把sdk里面提供的12個(gè)例子全部看完先。

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

準(zhǔn)備研究研究newton。

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