看了ogitor的**後, 自己又實踐了一把, 結合n3中學到的一些技巧, 在編輯器中得到了驗證.
雖說做的是場景編輯器, 但是其它編輯器也可以用的, 畢竟思想都差不多.
對於乙個編輯器, 通常是由乙個個的"實體"組成, 或者叫"物件". 而"物件"又是由各種"屬性"所組成.
以場景編輯器為例, 我們通常會涉及以下操作:
可以看到, 除了地形之外, 其它的操作都差不多. 如果把地形把塊對待, 每個地形塊做為乙個"物件", 高度和紋理編輯當成屬性編輯, 那麼上面都可以看成是同一種編輯方式了. 還有"擺"的這個操作, 其實本質上了也是物件的位置變換這個屬性的變化.
由此可以得出:編輯器的一切操作都是屬性編輯
實體不用說了, 相信每個引擎都有model/light/sound之類的物件類.
那麼怎麼去定義乙個屬性呢?
簡單的來說, 乙個屬性是乙個《名稱, 值》的配對, 物件就是這些屬性的乙個集合體. 以點光源為例, 它一般有這麼幾個屬性:
實際應用中我使用了fourcc代替string來索引屬性, 這樣可以用map做快速的訪問. 更高階的實現可以參見n3的attribute模組.
下面說說使用屬性抽象的好處:
編輯操作
因為物件都是由屬性組成的, 所以所有的編輯物件都可以抽象成一種, 那麼只需要實現一種編輯方式就可以適用於所有的物件
因為操作是與具體物件相關性不大, 所以擴充套件新的物件型別對結構的影響很小
檔案讀寫
物件是屬性組成, 那麼只需要把屬性儲存下來即可.
增刪屬性不用改動檔案格式, 連版本號都省了
undo/redo
對於建立/刪除操作, 備份該物件所有屬性.
對於屬性更改操作, 備份當前編輯屬性.
undo/redo只不過是把屬性進行還原而已
介面顯示
屬性可以與propertygrid良好的結合. 對於mfc的propertygrid正好可以用fourcc的uint值做為id. 擴充套件一下很容易把屬性顯示做成自適應的, 而不依賴於具體**實現.
考慮與.net的property反射機制相結合(待驗證)
再考查一下wpf下的繫結機制與屬性相結合會產生什麼效果~
基於屬性的編輯器框架
看了ogitor的 後,自己又實踐了一把,結合n3中學到的一些技巧,在編輯器中得到了驗證.雖說做的是場景編輯器,但是其它編輯器也可以用的,畢竟思想都差不多.對於乙個編輯器,通常是由乙個個的 實體 組成,或者叫 物件 而 物件 又是由各種 屬性 所組成.以場景編輯器為例,我們通常會涉及以下操作 可以看...
基於Ogitor的編輯器
1 介面美化 漢化 ogitor本身的漢化只是介面一小部分,內部不支援中文,內部使用中文會顯示亂碼 2 模仿3dmax和cryengine的lod輔助網格,網格捕捉。3 與現實對應的座標系對映,正交檢視下的精確定位 ogitor中不是正交投影,僅僅是鎖定鏡頭方向,所以不能精確定位 4 完全模仿3dm...
基於Ogitor的編輯器
1 介面美化 漢化 ogitor本身的漢化只是介面一小部分,內部不支援中文,內部使用中文會顯示亂碼 2 模仿3dmax和cryengine的lod輔助網格,網格捕捉。3 與現實對應的座標系對映,正交檢視下的精確定位 ogitor中不是正交投影,僅僅是鎖定鏡頭方向,所以不能精確定位 4 完全模仿3dm...