基於屬性的編輯器框架

看了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...