不知道有人遇到了沒。u3的terrain系統，在層數高於5層後，一定會出現乙個bug——6層時，當你開始對第1、2層的過渡進行塗抹時，就一定會發現，整個地形以統一的alpha給第2層和第1層來了個過渡，無論你怎麼刷，這個alpha都不會變。
跟蹤資源，發現兩張weight map都在，第一張描述了2-3、3-4、4-5、5-6四層，第二張描述了1-2。資源這裡沒問題，跟蹤遊戲流程，資料直到提交到渲染執行緒之前，都是對的，alpha map的生成完全沒有問題。
那麼問題在**呢？
用pix跟蹤，發現是6層後，因為u3使用了兩張weight map權重圖，來描述各層混合，問題就發生在這裡：用於描述第1、2層之間alpha的圖，也就是第二張weight map不翼而飛！只留下了乙個白白的紋理。在u3中，當紋理資源不存在時，會自動給入一張白色紋理，以提醒使用者注意修正。
根據這個資訊，重新跟蹤流程，發現資料層的weight map是存下來的，兩張，資料都對，提交到渲染執行緒後，渲染的shader compiler做了一件事，根據當前用到了哪張，而提交哪張。這流程都是對的，因為比如我只塗抹了1-2，也就是只用了第二張weight map，那麼第1張就根本不應該被提交，否則白浪費了乙個shader resource stage。只有我既塗抹了1-2，也塗抹了3-4時，兩張weight map才應該被提交。
問題是，這裡，當只塗抹了1-2時，從傳入的表中居然查不到這張weight map！！！！傳入的表只有一張weight map，是第一張，搜第二張當然就搜不到了！
地形資料的表裡明明是兩張，為什麼傳給渲染執行緒就只剩一張了呢？
跟了跟，發現資料在從地形資料到渲染執行緒的過程中，中間包了一層，就是這層搞出了問題——把第二張根據乙個叫做mask的變數給丟棄了……這點讓人很無語，因為mask這個描述的是使用者使用了哪幾層，而在這個例子中，使用的應該是1-2這兩層，那麼，應該是保留第二張啊，為什麼要丟棄呢？！
而且，後面渲染執行緒裡既然去查表了，你這裡就把表完全拷貝過去不就完了嗎？幹嘛要隨隨便便丟棄幾層？不給自己找麻煩麼？
於是修改了這裡，不在根據mask丟棄了，所有的weight map完全保留！
編譯，除錯——問題解決！
下來以後想了一下，極有可能這個系統是由三個人在維護的，乙個人a做了資料層，沒問題。乙個人b做了渲染層，也沒問題。其實，做中間那一層的這個人c，其實除了乙個小bug外，你還真不能說他的立意是錯的。
專案開發中經常能夠遇到這樣的問題，很可怕，每個系統都沒有大問題，配合到一起就是問題。介面一看都對，資料一看也沒錯啊，放到一起就是bug。
看來，有時候，單單的介面安全也不安全了。 : o
U3Terrain的乙個BUG及修正
不知道有人遇到了沒。u3的terrain系統，在層數高於5層後，一定會出現乙個bug 6層時，當你開始對第1 2層的過渡進行塗抹時，就一定會發現，整個地形以統一的alpha給第2層和第1層來了個過渡，無論你怎麼刷，這個alpha都不會變。跟蹤資源，發現兩張weight map都在，第一張描述了2 3...
微軟的乙個BUG
各位,我不知道我的這個發現屬不屬於微軟的乙個bug round 1.225,2 1.23 round 1.245,2 1.25 round 1.265,2 1.26 round 1.285,2 1.28 按照技術文章上說的,vb中round 函式屬於四捨五入函式,但實際執行當中,其實round 函式...
乙個微妙的bug
都知道不同型別運算元進行運算時，發生的轉換，資料型別一般朝著浮點度更高，長度更長的方向轉換，但signed 向unsigned 轉換得多多注意了，有如下 includeint a define cd sizeof a sizeof int sizeof 還回值為unsigned int main 最...