這篇文章介紹了一下wpf的資料繫結，這是一種做法。
回顧一下，資料繫結主要的幾個組成部分：
源資料池和源屬性。
目標資料池和目標屬性。
binding：配置哪些源的改變，會使得哪些目標發生改變。
前面也大概介紹了資料繫結基本需要解決的工作：
源資料必須發布通知，這個通知應該由binding來獲取。
binding獲取到通知後，根據配置，決定哪些目標屬性將要發生更改，並修改目標屬性。
不同的實現，注意的主要問題，源資料和目標資料是一般沒有什麼問題的，最多就是collection如何處理，這個沒有任何麻煩應該。
接下來的主要的麻煩應該是在binding該放到哪兒。有侵入式和非侵入式兩種，侵入式的話，就是繫結融合在介面庫本身來做，要求重寫一套自己的介面庫。非侵入式則可以允許在第三方庫的基礎上來開發。侵入式有侵入式的優勢，非侵入式有非侵入式的優勢，這就需要根據情況來靈活選擇了。
wpf的實現基本上可以理解為侵入式的，如果乙個模組本身是這麼做的，最大的好處就是可以把繫結的複雜度降到最低，對使用者而言很簡單，同時繫結本身可以跟ui樹很好的整合到一起，對於relative等的描述的處理會變的非常簡單，也更加靈活。非侵入式則可能對於開發者更容易理解，但是對使用者的要求相對來說就高一些，因為使用者必須更加明白繫結的概念和意義，同時非侵入式一般都會面臨著源既可以是某個ui元素，也可以不是，這樣繫結一般來說必須實現多套。但兩者除了這些細枝末節的之外，基本上概念上還是統一的。
言歸正傳，我們來看ue3的資料繫結做法：
ue3的資料繫結實現了兩份，gfx融合進來前有一部分，gfx融合進來後又不一樣了。之前的那個本來還想提一下，不過實在是有點麻煩，gfx融合進來後改動的簡單很多，也很方便理解，是乙個非常標準的非侵入式的做法，所以就順著這個思路說下去好了。
基本上ue3的資料繫結就是按照後面這個提煉出來的公式來做的，這應該也是最簡單不過的資料繫結了。
1 idatastore負責捕獲資料的更改，並將其傳送到subscriber。
2 所有的binding都記錄在某個ui系統中，乙個ui系統包含一到多個頁面，這些頁面由第三方ui庫來提供，ui system負責這些ui庫的一些維護和邏輯工作。
3 ui系統實現了乙個subscriber，監聽資料更改，一旦資料更改，subscriber將根據修改了誰來決定觸發哪些個binding來修改目標。
4 binding裡記錄了目標元素的路徑，接收到修改指令後，真正地向目標flash元素設定新值。
很簡單的實現。其實跟的深了，有很多外延的處理，不過大體的思路和原理就是這樣的了。
但這樣的更改只能發生在data store和ui 元素之間，像wpf那樣，元素與元素間呢？
還有乙個widgetbindings來處理這個功能，這個跟前面的沒有太大的不同，乙個binding，兩種實現，就不展開了，有興趣自己看看就行了。
ue3這種實現方式的幾個特點：
非侵入式地與第三方庫進行互動（gfx）。
需要在這些第三方庫外面包裝乙個「ui系統」這樣的東西，用它來管理所有的繫結。
第三方庫本身的繫結，也是基本上非侵入式的進行修改。
這樣，即便不再使用gfx，換做cegui，這套系統稍微修改就能投入新的介面庫中。甚至可能連binding的資料本身也不需要大的修改，做乙個版本相容就可以直接用到新的體系裡面。
首先，任何乙個介面庫肯定都有設定某個ui元素的方法，從data store到ui元素這條路是絕對沒有任何問題的。唯一有麻煩的是從ui介面庫回到data store，以及ui介面庫元素之間的繫結。只要介面庫敢給value改變的通知、那麼後面這個就也不是任何問題。接下來更多的麻煩就在於很多細節問題了：如何使之可編輯，如果第三方庫本身提供了編輯器，如何融合binding的編輯進入這個編輯器等等。
採用這種非侵入式的方式，對於開發者而言，比起wpf容易理解多了。
最後再列舉一下資料繫結的幾個優勢：
2 繫結使得style、template這樣的東西變得很方便。介面元素的background、foreground均來自不同的繫結，這樣很方便就能實現style了。
3 繫結使得不同元素間的通訊變得簡單，數值的更改可能直接影響到進度條元素，而進度條元素的更改又有可能使得另外乙個元素被啟用。例如，血量降低了，顯示血量數字的textbox會自動更新、顯示血條百分比的image也會自動更新，如果有心，甚至可以設定在低於30%後，「介面邊緣發紅」這個介面元素得以開始它的動畫。而在mfc裡，這個東西要麼得手寫，要麼得求助doc-view，都顯得太麻煩。
4 繫結的編輯，使得開發者不得不把精力花在工具的提供上，而不再是功能完了就了事兒。……好吧，我承認這條是充數的，乙個優秀的程式設計師本身就應該考慮功能之外的那些東西，系統如何使用，如何投放，如何編輯……
不過無論如何，只要有了資料繫結這個思路，根據自己所面對的情況，就可以靈活地運用和安排這些元件，完成自己的目的了。
更重要的是——實現一套這個東西，真的很容易很容易。
後記：其實之前對ue3繫結的印象多來自於之前舊版的資料繫結系統，gfx融合後一直對新的繫結這塊兒的修改沒有怎麼看，今天一看，算了，舊版的別再寫了，新版的又清晰有強大，何苦再自找麻煩呢。
本來還準備再寫寫自己的那套東西的，還是算了，因為採用的跟gfx這套差不了多少。所想達到的目的也是一樣，就是繫結本身與具體的介面庫脫離。
見到以及聽說現在還有不少專案是通過堆程式設計師，用類似於mfc和wxwidget那樣的方式去完成自己的ui介面，再好一點的無非也就是用**代替了繼承，黑箱代替了白箱，但從根本上沒有解決問題。而這樣的開發模式實在太累，而且速度太慢，隨著遊戲競爭壓力的增加，傳統方式引發的問題實在太多太多。
對於已經可以通過自己完成的編輯器來鋪介面量的人們來說，資料繫結的優勢也是很明顯的：介面的使用者所需關注的只是介面本身的邏輯，乙個優秀的介面庫直接可以通過編輯器來完成這點。程式設計師只需要安排好所有的繫結就可以投入到別的工作，介面本身完全可以獨立於任何程式設計師而完成。
真心希望資料繫結能夠幫著大家優化自己的介面製作流程。
UE3 光照 陰影
對於建立高水準環境而言，關卡中幾何體的照明方式起著至關重要的作用。人類眼睛和腦袋希望光源能夠通過特定方式與表面進行互動，填充乙個房間或投射陰影。任何背離這條原則的東西都可能會破壞使用者的帶入感體驗。虛幻引擎 3 的光照系統是非常靈活的，可以協調地使用所有不同的光源和陰影型別，為所有遊戲建立剛好合適的...
UE3 距離場陰影
文件變更記錄 由 daniel wright 建立。請檢視技術部落格檢視關於 主定向光源 dominant directional light 的更多資訊。距離場陰影是基於一篇最近在經過 alpha 測試的放大功能 作者 valve software 上的 實現的。它的原理是使用到最近陰影過渡的距離...
UE3自定義命令列
由於ue3的功能不能以lib或者dll的方式提供出來，如果要使用ue3的某部分功能，啟動ue3的exe程式是必須的。所以我們會需要用到命令列。commandlet是命令列的基類，自定義命令列需要繼承這個基類。eg.exportscene.uc class exportscene extends co...