使用 FBX 差不多了, 把原來使用的.ASE跟.X改成.FBX.
缺點大概就是沒增加什功能, 但還是值得的.
FBX SDK安裝完要1G, 只是一個讀檔案的sdk而已.
而且還有每年更新的 sdk? 不同年份的 .fbx版本
autodesk 看來很有雄心 發展 fbx,想成為標準.
-------------
fbx sdk 用的是很早以前 我在 bcb 6.0 那時 delphi 那種時期的framework
就是繼承 虛擬.......
這種架構 現在都已經落伍了. 改成component 就夠了.
另外就是 tree的node架構, 這算不錯, 第一次看到可以把tree的架構寫的這麼好的.
但是 因為是tree的架構, 所以所有的資訊 都塞在node裡面.
這也不是甚麼大問題
STL的部分 覺得沒甚麼必要 要自己弄一份, 這會讓整個SDK爆增,
整個 fbx sdk的 lib相當龐大, 讓程式complie 跟link ....都會變長.
debug 設定 也麻煩.
我根本不想在引擎裡直接跟 fbx sdk . lib綁在一起.
而是寫個轉檔程式, 轉成自己的格式 在用.
----------
接下來 最大的缺點, 也可以說是優點.
FBX檔案功能相當強大, 如果要深入了解 花的時間會很誇張.
而遊戲只是用到部分的功能, 即使如此 還是要了解其他的部分.
因為沒有FBX的檔案格式, 所以 所有的一切資料都必須靠 SDK的函數來抓取.
api這種東西 沒有完整的sample是沒用的.
也不會有人花時間去一個一個測api 功能.
而且誇張的是, SDK 的sample 跟網路上 找的sample code, 幾乎都不大一樣,
功能都做出來 可是大家寫的都不大一樣, 這就是 fbx sdk神奇的地方.
因為fbx只能靠api抓資料, 而又是tree的方式, 整個資料可用很多種api抓取.
因為api的函數相當多, 表示node A可以抓node B的資料,
node B也可以抓node A的資料.
這就是大家寫出來的 code都不一樣.
---------
只能說 這個時間點改fbx算是比較不錯, 因為網路上的資料變多了,
要是在3,4年前 改用FBX, 我看挫折感會很大.
-------
結論:
1.FBX的未來是 看好的, 畢竟autodesk全力的支援,
2.再來可以不管美工用哪種軟體, 這也是很大的優點. 程式也不用寫個別軟體的plugin
3.畢竟我才花一個用時間而已, 花的時間愈久 就會更熟悉fbx的功能,
fbx這個 寶藏 還有很多可以挖掘的.
沒有留言:
張貼留言