10幾年前的神作。
畫面的bloom是錯誤的。整個畫面泛白。而且畫面模糊。看起來很不舒服。
而且還不能關掉。
render tanget 要設浮點數。 不然只是rgb255, bloom 計算會超過255. 導致畫面就是整個模糊。
然後做 High-Dynamic Range。
終於做出讓人舒服的bloom
The Wind Waker HD 的bloom
這年頭已經沒人在寫3D了。
10幾年前的神作。
畫面的bloom是錯誤的。整個畫面泛白。而且畫面模糊。看起來很不舒服。
而且還不能關掉。
render tanget 要設浮點數。 不然只是rgb255, bloom 計算會超過255. 導致畫面就是整個模糊。
然後做 High-Dynamic Range。
10幾年前的神作。
畫面的bloom是錯誤的。整個畫面泛白。而且畫面模糊。看起來很不舒服。
而且還不能關掉。
render tanget 要設浮點數。 不然只是rgb255, bloom 計算會超過255. 導致畫面就是整個模糊。
然後做 High-Dynamic Range。
Unity android遊戲 10秒內進入遊戲畫面
Unity android遊戲 10秒內進入遊戲畫面
https://play.google.com/store/apps/details?id=com.houpito.Billiard3D
機器: MediaTek MT6589, 1.2GHz.
還是手機比較好， 速度比較快?
明明這個問題就很嚴重，用java開發的android 大約3秒就可到讀取的畫面。
Unity開發的android，要到自己的讀取畫面， 第一次要30秒， 在怎麼優化，也要25秒，
這能賣嗎?
網路除了幾篇大陸的文章有討論到開機速度問題， 但是卻是用java的做法，做甚麼模擬...
這樣只是欺騙的方法， 而且java我已不會。
------
unity只要建一個簡單的gamobject 建一個球的mesh ， 在android 看到畫面，
我的機器是25~30秒, 誇張到不可思議。
我解決方法很簡單， 也很複雜， 就是gameobject 盡量少， 少到只剩下camera跟光源.
還有Script 裡的 Start() Awake() 也少到只要一行code。就好。
這樣的遊戲， gameobject 只有這樣， 全部用code去create()
void Awake()
{
Application.targetFrameRate = 60;
}
void Start()
{
m_screen = eScreen.Loading;
}
然後在 void Update() , 自己載入資料。 秀出loading.
速度 還是要看程式複雜度。
-------------------------------------------------------------------------
unity只要建一個簡單的gamobject 建一個球的mesh ， 在android 看到畫面，
我的機器是25~30秒, 誇張到不可思議。
如果只是建一個簡單的Quad, 速度可以到5秒秀出。
真不知為何差異這麼大。
-----------
unity還有要命的檔案大小問題: 上面圖形+code+Admob 大約5mb.
整個安裝檔apk 卻是12.8mb, 安裝完的大小要到4xmb.
這個問題真是要命。
為何不做靜態鏈結， 一堆dll根本浪費空間。
這個目前我沒辦法解決。
https://play.google.com/store/apps/details?id=com.houpito.Billiard3D
機器: MediaTek MT6589, 1.2GHz.
還是手機比較好， 速度比較快?
明明這個問題就很嚴重，用java開發的android 大約3秒就可到讀取的畫面。
Unity開發的android，要到自己的讀取畫面， 第一次要30秒， 在怎麼優化，也要25秒，
這能賣嗎?
網路除了幾篇大陸的文章有討論到開機速度問題， 但是卻是用java的做法，做甚麼模擬...
這樣只是欺騙的方法， 而且java我已不會。
------
unity只要建一個簡單的gamobject 建一個球的mesh ， 在android 看到畫面，
我的機器是25~30秒, 誇張到不可思議。
我解決方法很簡單， 也很複雜， 就是gameobject 盡量少， 少到只剩下camera跟光源.
還有Script 裡的 Start() Awake() 也少到只要一行code。就好。
這樣的遊戲， gameobject 只有這樣， 全部用code去create()
void Awake()
{
Application.targetFrameRate = 60;
}
void Start()
{
m_screen = eScreen.Loading;
}
然後在 void Update() , 自己載入資料。 秀出loading.
速度 還是要看程式複雜度。
-------------------------------------------------------------------------
unity只要建一個簡單的gamobject 建一個球的mesh ， 在android 看到畫面，
我的機器是25~30秒, 誇張到不可思議。
如果只是建一個簡單的Quad, 速度可以到5秒秀出。
真不知為何差異這麼大。
-----------
unity還有要命的檔案大小問題: 上面圖形+code+Admob 大約5mb.
整個安裝檔apk 卻是12.8mb, 安裝完的大小要到4xmb.
這個問題真是要命。
為何不做靜態鏈結， 一堆dll根本浪費空間。
這個目前我沒辦法解決。
為何一堆人連比例尺都不懂?
數學的數字是沒有單位， 1可以是 1公斤， 1 塊錢， 1顆蘋果。
兩個人溝通好單位就行。
紅色的都沒有單位， 那就兩個約定是公尺就好。 x=13.892 就是 13.892m. 就是這樣。
如果要做12公分就是0.12
這就是最簡單的方法， 又不是所有的軟體都會有單位， 所以只需要數字就好。
又不是 你是台灣用公尺， 另一個人在美國用 英吋。 才需要定單位轉換。
obj的檔案 完全沒有單位， 如果要單位 就是依照原來定的 -79.94121就是-79.94121公尺
以前自己做的， 用了一個很奇怪的比例: 180公分=16單位。 10幾年前自己亂定。 反正所有的東西都是相對人眼下去測量的，所以就定人物高度180cm, 為什麼是16單位? 不知道 反正是直覺， 10幾年前 也沒太多資訊可以參考。
也都沒問題， 這種奇怪的比例， 根本很難看數字計算， 當然就建個立方體，高度16單位，
告訴美術這是人180公分， 房子 ..樹.. 都是用這個比例去估。
回來的模型， 最多在簡單調一下騎樓的高度而已。
兩個人溝通好單位就行。
紅色的都沒有單位， 那就兩個約定是公尺就好。 x=13.892 就是 13.892m. 就是這樣。
如果要做12公分就是0.12
這就是最簡單的方法， 又不是所有的軟體都會有單位， 所以只需要數字就好。
又不是 你是台灣用公尺， 另一個人在美國用 英吋。 才需要定單位轉換。
obj的檔案 完全沒有單位， 如果要單位 就是依照原來定的 -79.94121就是-79.94121公尺
以前自己做的， 用了一個很奇怪的比例: 180公分=16單位。 10幾年前自己亂定。 反正所有的東西都是相對人眼下去測量的，所以就定人物高度180cm, 為什麼是16單位? 不知道 反正是直覺， 10幾年前 也沒太多資訊可以參考。
也都沒問題， 這種奇怪的比例， 根本很難看數字計算， 當然就建個立方體，高度16單位，
告訴美術這是人180公分， 房子 ..樹.. 都是用這個比例去估。
回來的模型， 最多在簡單調一下騎樓的高度而已。
一分鐘學會Unity
經過幾個月的實做，終於了解Unity怎麼運作的。 很多Unity的教學都沒有把基本的觀念說得清楚。常會變的瞎子摸象。
1. Unity一開始執行(按上面的>三角形箭頭)
2.Unity會將 Hierarchy下的這些物件(GameObject)先產生(這是空的)。
3.例如Cube的物件，右邊Inspector 有Cube(Mesh Filter)，這是一個component.
產生Cube後也會同時產生這個Cube(Mesh Filter)的component.
這個 Mesh Component 是掛在Cube這個GameObject.
4.產生Box Collinder 這個 component.
5.產生Mesh Render 這個 component.
6.你寫的script C# , Unity並無法執行到， 必須加一個動作， 就是把Script 加到Cube.
當作是 Cube的component. 這樣Unity才會進入你的code執行。
Unity的原理就只有這樣而已， 其他的就是單純的寫code(查api)。
Unity: Graphics.DrawMesh()
用Unity最不習慣的就是 一切都是gameobject, 連要畫個 mesh也要object.
gameobject.transform. 一堆.transform相關的函數........
根本沒必要..
兩個相同的mesh,用gameobject, 要存兩分mesh，
多個不就更麻煩了? 還有 動態 產生mesh，又要複製go...
又要釋放..... mesh的資料 就是一次載入就好.
找了半天， 終於找到: Graphics.DrawMesh()， 只要寫在Update()就跟以前用c++ 迴圈一樣的寫法了。最主要是想畫很多個相同的mesh.
public static void DrawMesh(Mesh mesh, Matrix4x4 matrix, Material material, int layer, Camera camera = null, int submeshIndex = 0, MaterialPropertyBlock properties = null, bool castShadows = true, bool receiveShadows = true, bool useLightProbes = true);
好用的這個函數就夠了。
(Mesh mesh, Matrix4x4 matrix, Material material) 參數這幾個就夠了.
這就很像 一般用 d3d 自己會寫的render含數 會傳的參數。
unity 的 Matrix4x4 函數也很難用， 為何不直接照D3D的 Matrix函數就好?
學3D最重要的就是 Matrix,， 弄懂這個就夠了。
----------------------------------------------------------------
還有在 Update() , 直接把整個logic寫在裡面加上Graphics.DrawMesh().
速度會比事先算好gameboject的位置， 還慢。
所以 只執行一次的 logic, 變成要先算好位置， 存起來， 在Update()的 Graphics.DrawMesh(). 只畫位置。
所以這就是跑 script的缺點。
void Update () {
for (int i = 0; i < m_szRenderWin.Count; i++)
Graphics.DrawMesh(m_szRenderWin[i].mesh, m_szRenderWin[i].matrix/* Matrix4x4 */, m_Material, 0);
}
gameobject.transform. 一堆.transform相關的函數........
根本沒必要..
兩個相同的mesh,用gameobject, 要存兩分mesh，
多個不就更麻煩了? 還有 動態 產生mesh，又要複製go...
又要釋放..... mesh的資料 就是一次載入就好.
找了半天， 終於找到: Graphics.DrawMesh()， 只要寫在Update()就跟以前用c++ 迴圈一樣的寫法了。最主要是想畫很多個相同的mesh.
public static void DrawMesh(Mesh mesh, Matrix4x4 matrix, Material material, int layer, Camera camera = null, int submeshIndex = 0, MaterialPropertyBlock properties = null, bool castShadows = true, bool receiveShadows = true, bool useLightProbes = true);
好用的這個函數就夠了。
(Mesh mesh, Matrix4x4 matrix, Material material) 參數這幾個就夠了.
這就很像 一般用 d3d 自己會寫的render含數 會傳的參數。
unity 的 Matrix4x4 函數也很難用， 為何不直接照D3D的 Matrix函數就好?
學3D最重要的就是 Matrix,， 弄懂這個就夠了。
----------------------------------------------------------------
還有在 Update() , 直接把整個logic寫在裡面加上Graphics.DrawMesh().
速度會比事先算好gameboject的位置， 還慢。
所以 只執行一次的 logic, 變成要先算好位置， 存起來， 在Update()的 Graphics.DrawMesh(). 只畫位置。
所以這就是跑 script的缺點。
void Update () {
for (int i = 0; i < m_szRenderWin.Count; i++)
Graphics.DrawMesh(m_szRenderWin[i].mesh, m_szRenderWin[i].matrix/* Matrix4x4 */, m_Material, 0);
}
citywar圖形怎麼外包?
當我還有印象:紀錄一下citywar圖形怎麼外包。
一.全部圖形費用是4萬台幣。
二.大約外包10位美術人員(這裡面沒有一位見過面)
下面都是一個單位一個外包美術
1.房子A--->會這個的人相當少(所以美術多加強這種大型的建物技術)
2.房子B 樹 紅綠燈 路燈 停車場(這好像有一個團隊)
3.車子 人物x2 sniper
4.手槍 摩托車
5.加油站 (忘了)
6.UI,特效(會特效材質的也很少)
7.全部的人物動作-->會這個的人相當少
8.這最慘，本來天真，以為4000圓全部外包，結果時間到了只拿到完全不能用的圖形。
所以就改用: 只外包單一個模型(像上面)然後我自己組。
9.我也算的話，整個場景是我擺的，斑馬線....其他無聊的修圖bug。
時間可能超過半年 。
當初是想做一個完全商業化的遊戲，之後覺得這沒甚麼必要，可以省掉更多錢。
所以程式要圖的話 多花點時間上網找， 管他有版權沒版權，反正要商業化時在換掉，
可以省掉更多錢(應該可以省掉1半)。
圖形整體看起來沒多大衝突，我是直接抓一個街景內的物件，所以圖型參考是給照片。
圖形覺得應該建 一個 淡水馬偕故居 赤崁樓 這樣比較好。 有地標比較好。
一.全部圖形費用是4萬台幣。
二.大約外包10位美術人員(這裡面沒有一位見過面)
下面都是一個單位一個外包美術
1.房子A--->會這個的人相當少(所以美術多加強這種大型的建物技術)
2.房子B 樹 紅綠燈 路燈 停車場(這好像有一個團隊)
3.車子 人物x2 sniper
4.手槍 摩托車
5.加油站 (忘了)
6.UI,特效(會特效材質的也很少)
7.全部的人物動作-->會這個的人相當少
8.這最慘，本來天真，以為4000圓全部外包，結果時間到了只拿到完全不能用的圖形。
所以就改用: 只外包單一個模型(像上面)然後我自己組。
9.我也算的話，整個場景是我擺的，斑馬線....其他無聊的修圖bug。
時間可能超過半年 。
當初是想做一個完全商業化的遊戲，之後覺得這沒甚麼必要，可以省掉更多錢。
所以程式要圖的話 多花點時間上網找， 管他有版權沒版權，反正要商業化時在換掉，
可以省掉更多錢(應該可以省掉1半)。
圖形整體看起來沒多大衝突，我是直接抓一個街景內的物件，所以圖型參考是給照片。
圖形覺得應該建 一個 淡水馬偕故居 赤崁樓 這樣比較好。 有地標比較好。
程式語言就是最好的邏輯訓練
"邏輯"濫用指數可能是第一名，根本沒幾個人知道"邏輯"是甚麼。
談 邏輯沒多大意義，談甚麼樣的訓練可以培養邏輯？
很多教邏輯的課程 書 都很無聊 。 最接近邏輯的是 數學上的證明題。
缺點是答案都有了，真實的世界是不會先給答案的。
自從電腦出現後，所有的邏輯課程都變的一點意義都沒有了。
因為電腦程式語言就是把邏輯直接實現的 最好的科學。
int array[100]; //有100個隨機整數的數字，從這裡面挑出你想要的數字
1. N>=30 而且 N <= 80. //這樣怎麼寫？
if( N>=30 && N <= 80 ){ Push(N); }// 就這樣而已 跟若P則Q很像，但是更嚴謹
2. N<=30 或者 N >= 80.
if( N>=30 || N <= 80 ){ Push(N); }
3. N<=30 或者 N >= 80 而且是偶數
if( N>=30 || N <= 80 && N%2==0 ){ Push(N); }
我不大確定這個對不對。 不過我通常不會這麼寫。
if( N>=30 || N <= 80 )
{
if( N%2==0 ){ Push(N); }
}
多麼好的邏輯訓練。
談 邏輯沒多大意義，談甚麼樣的訓練可以培養邏輯？
很多教邏輯的課程 書 都很無聊 。 最接近邏輯的是 數學上的證明題。
缺點是答案都有了，真實的世界是不會先給答案的。
自從電腦出現後，所有的邏輯課程都變的一點意義都沒有了。
因為電腦程式語言就是把邏輯直接實現的 最好的科學。
int array[100]; //有100個隨機整數的數字，從這裡面挑出你想要的數字
1. N>=30 而且 N <= 80. //這樣怎麼寫？
if( N>=30 && N <= 80 ){ Push(N); }// 就這樣而已 跟若P則Q很像，但是更嚴謹
2. N<=30 或者 N >= 80.
if( N>=30 || N <= 80 ){ Push(N); }
3. N<=30 或者 N >= 80 而且是偶數
if( N>=30 || N <= 80 && N%2==0 ){ Push(N); }
我不大確定這個對不對。 不過我通常不會這麼寫。
if( N>=30 || N <= 80 )
{
if( N%2==0 ){ Push(N); }
}
多麼好的邏輯訓練。
C++跟JavaScipt
巴別塔（也譯作巴比倫塔，或意譯為通天塔），據《聖經·創世記》第11章記載，當時人類聯合起來興建希望塔頂通天能傳揚己名的高塔。為了阻止人類的計劃，上帝讓人類說不同的語言，使人類相互之間不能溝通，計劃因此失敗，人類自此各散東西。
這說明了目前程式語言混亂的情形。
程式語言就只分兩種，能編譯成機器碼，跟不能編譯成機器碼(script language)。
所以除了c++以外，你看到的幾乎都是script language。
java， c# ，VB也是 script language， 網頁用的也都是script language。
混亂的就是這 script language部分。
其實語言定義的愈嚴格，愈容易學。
C裡面的每個變數宣告，例如 int i; 就會直接表明這個變數佔了多少個byte，寫得很死，型態也清楚。不用懷疑。
javascipt： var i; 你根本不知道這個i是甚麼？ 字串？整數，......通通不曉得，多少個byte?不曉得。
javascript最後導致最佳化很困難。javascript 函數物件很多寫法都很混亂，很多種寫法。
不管是debug跟最佳化，最後就是個大麻煩。沒人會想用javascript寫超過10萬行的程式。
這種因為網頁興起的語言的特性本來就是如此， 簡單 方便入門， 網頁快速看到結果，
寫一行 javascript， 瀏覽器幫你做了幾百行的工作， script language看起來很神奇，
混亂的語言結果就是 巴別塔。
這說明了目前程式語言混亂的情形。
程式語言就只分兩種，能編譯成機器碼，跟不能編譯成機器碼(script language)。
所以除了c++以外，你看到的幾乎都是script language。
java， c# ，VB也是 script language， 網頁用的也都是script language。
混亂的就是這 script language部分。
其實語言定義的愈嚴格，愈容易學。
C裡面的每個變數宣告，例如 int i; 就會直接表明這個變數佔了多少個byte，寫得很死，型態也清楚。不用懷疑。
javascipt： var i; 你根本不知道這個i是甚麼？ 字串？整數，......通通不曉得，多少個byte?不曉得。
javascript最後導致最佳化很困難。javascript 函數物件很多寫法都很混亂，很多種寫法。
不管是debug跟最佳化，最後就是個大麻煩。沒人會想用javascript寫超過10萬行的程式。
這種因為網頁興起的語言的特性本來就是如此， 簡單 方便入門， 網頁快速看到結果，
寫一行 javascript， 瀏覽器幫你做了幾百行的工作， script language看起來很神奇，
混亂的語言結果就是 巴別塔。
接下來目標: 找不到目標
很多簡單的 都寫得差不多了, 剩下的就是很困難的.
更簡單說: 找不到code 改, 真的很難寫.
3D圖形 有很多的問題是發生在 寫出來後, 但是常會出現品質低落,
例如:camera 移動時, 特效的部分 會抖動.
例如: cascaded shadow, 當 camera移動時, 影子的邊緣 會抖動.
SSAO也是 camera移動的時候 會抖動.
還有 最簡單的 bloom, 當camera移動時, 會抖動.
(解決這些問題 花的心血 都比原來的特效高)
nVidia 就寫了很多關於 反鋸齒的文章....., 畫面的穩定性很重要.
MSAA、MLAA、FXAA.....
靜態的時候 會有鋸齒,當 camera移動時 鋸齒的部分就會抖動.
更簡單說: 找不到code 改, 真的很難寫.
3D圖形 有很多的問題是發生在 寫出來後, 但是常會出現品質低落,
例如:camera 移動時, 特效的部分 會抖動.
例如: cascaded shadow, 當 camera移動時, 影子的邊緣 會抖動.
SSAO也是 camera移動的時候 會抖動.
還有 最簡單的 bloom, 當camera移動時, 會抖動.
(解決這些問題 花的心血 都比原來的特效高)
nVidia 就寫了很多關於 反鋸齒的文章....., 畫面的穩定性很重要.
MSAA、MLAA、FXAA.....
靜態的時候 會有鋸齒,當 camera移動時 鋸齒的部分就會抖動.
發佈 citywar techdemo ver2.4 HDR + FBX
檔案下載 27 mb
https://app.box.com/s/v3l1us2rhpu2hnzictx9
增加 HDR + FBX
增加 新的3層 cascaded shadow, 跟簡單的blur
跟上一版相比, 速度少掉20張, memory 減少50mb.
因為 HDR的關係 很多 post process 的東西都怪怪的,
bloom 跟 star bloom 都重新改過, SSAO未改(效果不明顯了)
花大量的時間在整理code, 結果跑出一個怪bug, 又花了一天抓bug.
https://app.box.com/s/v3l1us2rhpu2hnzictx9
增加 HDR + FBX
增加 新的3層 cascaded shadow, 跟簡單的blur
跟上一版相比, 速度少掉20張, memory 減少50mb.
因為 HDR的關係 很多 post process 的東西都怪怪的,
bloom 跟 star bloom 都重新改過, SSAO未改(效果不明顯了)
花大量的時間在整理code, 結果跑出一個怪bug, 又花了一天抓bug.
FBX心得
使用 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這個 寶藏 還有很多可以挖掘的.
缺點大概就是沒增加什功能, 但還是值得的.
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這個 寶藏 還有很多可以挖掘的.
2014年遊戲程式員必須具備的能力
我都覺得 我快變成改 code專家.
就是把網路上的 source code 加入到自己的code.
2014年遊戲程式員必須具備的能力
1.debug 能力,多寫 code就對了. debug能力不行的 只會加深挫折感.
debug能力 = 時間 + 相關背景知識.
2.閱讀 修改 整合別人 source code的能力.
以現在3D的複雜程度而言, 真正有能力站在第一線研發 寫些新技術的,
大概就是3D卡廠商 遊戲廠商 或是學校教授 在這領域 的前幾名而已.
說得更明白點, 網路上 找不到相關的source code, 你有99.99%的機率 是做不出來的.
給你看paper也沒用, paper寫的太簡略 又寫的太複雜, 不如 code來的清楚.
==========
沒有甚麼好處, 意思是說, 投入1小時 只會有0.1的產出, 簡單說 這是沒有效率的學習方式.
效率是很重要的, 你的壽命有限, 效率不重要, 那要活幾百年 才夠用?
直接去寫套小軟體(小程式) 獲得的幫助 都比 ACM 好太多了.
ACM題目太雜, 一大堆題目 都沒有甚麼相關性,
1.再來 請問一下 那些 acm的code 可以重複使用嗎?
2.ACM能幫你建立甚麼相關的背景知識嗎? 有資料庫的知識? 有網路的背景知識?
有.....圖學的 背景知識?
就是把網路上的 source code 加入到自己的code.
2014年遊戲程式員必須具備的能力
1.debug 能力,多寫 code就對了. debug能力不行的 只會加深挫折感.
debug能力 = 時間 + 相關背景知識.
2.閱讀 修改 整合別人 source code的能力.
以現在3D的複雜程度而言, 真正有能力站在第一線研發 寫些新技術的,
大概就是3D卡廠商 遊戲廠商 或是學校教授 在這領域 的前幾名而已.
說得更明白點, 網路上 找不到相關的source code, 你有99.99%的機率 是做不出來的.
給你看paper也沒用, paper寫的太簡略 又寫的太複雜, 不如 code來的清楚.
==========
沒有甚麼好處, 意思是說, 投入1小時 只會有0.1的產出, 簡單說 這是沒有效率的學習方式.
效率是很重要的, 你的壽命有限, 效率不重要, 那要活幾百年 才夠用?
10年程式debug的技巧
http://pgamerart.blogspot.tw/2011/10/10debug.html
========直接去寫套小軟體(小程式) 獲得的幫助 都比 ACM 好太多了.
ACM題目太雜, 一大堆題目 都沒有甚麼相關性,
1.再來 請問一下 那些 acm的code 可以重複使用嗎?
2.ACM能幫你建立甚麼相關的背景知識嗎? 有資料庫的知識? 有網路的背景知識?
有.....圖學的 背景知識?
訂閱：
文章 (Atom)