巴別塔（也譯作巴比倫塔，或意譯為通天塔），據《聖經·創世記》第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看起來很神奇，
混亂的語言結果就是 巴別塔。
接下來目標: 找不到目標
很多簡單的 都寫得差不多了, 剩下的就是很困難的.
更簡單說: 找不到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能幫你建立甚麼相關的背景知識嗎? 有資料庫的知識? 有網路的背景知識?
有.....圖學的 背景知識?
關於FBX 無法進入 debug mode的問題
綜合網路上的資訊
簡單創建一個可以執行的 vs2010 可以debug的程式
然後進入Properties 比較 成功的 跟 FBX 的sample 哪裡不一樣
修改fbx sdk sample 改成功的一樣就可
大約改的地方 有2個
1.C/C++ -->Gereral-->Debug Information Format -->Program Database For Edit And Continue (/ZI)
2. C/C++ -->Output Files --> Program Database File Name -->$(IntDir)vc$(PlatformToolsetVersion).pdb
"Generate Debug Info" to "Yes
Optimization" to "Disabled (/Od)"
然後 clear 重新 build
=====
fbx sdk sample 不管 build幾個例子 產生的.pdb大小都一樣 不到1mb
修改之後 .pdb 8mb 就表示正確了
簡單創建一個可以執行的 vs2010 可以debug的程式
然後進入Properties 比較 成功的 跟 FBX 的sample 哪裡不一樣
修改fbx sdk sample 改成功的一樣就可
大約改的地方 有2個
1.C/C++ -->Gereral-->Debug Information Format -->Program Database For Edit And Continue (/ZI)
2. C/C++ -->Output Files --> Program Database File Name -->$(IntDir)vc$(PlatformToolsetVersion).pdb
"Generate Debug Info" to "Yes
Optimization" to "Disabled (/Od)"
然後 clear 重新 build
=====
fbx sdk sample 不管 build幾個例子 產生的.pdb大小都一樣 不到1mb
修改之後 .pdb 8mb 就表示正確了
Citywar 3D Engine Techdemo 2.2 Release
Citywar 3D Engine Techdemo 2.2 Release
包含 BRDF 跟 Occlusion culling
https://app.box.com/s/lx09e86hxbuo9i9owkga(28mb)
使用方明如下: 按F4顯示對話盒.
包含 BRDF 跟 Occlusion culling
https://app.box.com/s/lx09e86hxbuo9i9owkga(28mb)
使用方明如下: 按F4顯示對話盒.
又整理了一些程式碼
shadowmap 的生成更快了, 速度又快了6,7張
空間切割讓 記憶體 更緊密了(大概少了800個new[] )
occlusino culling 的z值計算更正確 能cull更多的物體,(多15個左右物體), 可以速度沒增加
應該是 cpu的極限已經到了.
接下來的目標
接下來的目標:
該寫的特效都寫的差不多了, 反正網路上找不到code的,
那表示 也不用寫了, 因為根本不用幻想寫出來.
想寫植物動來動去的特效, 這似乎編輯器的部分比較多.
3D隨便一個特效 要寫到完整, 你認為要寫多久 ?
我看5~10年以上, 甚至20年.....
所以要知道 甚麼時候要停止.
3D程式目前就是走2,3步, 然後退一步. 寫些新的特效, 然後再把寫過的code整理.
1. 程式碼的整理 是相當重要的. 這也是一直持續在做的. 整理過的 code 威力會更強大.
2. 目前人物有點弱, 因為將來移植到dx11, 對.x file的支援將會沒有.
要用.FBX? 不是很清楚.
比較麻煩的事, 人物需要美工的配合, 才能有比較好的測試.
3.移植到dx11的事前準備?
用了大量D3DXMatrix, 這個要怎麼處理? 用SSE優化? 要怎麼處理?
雖然有XnaMath.h, 微軟的東西就是, 更新速度很快, 而且喜歡把以前的東西全部推翻
然後又要重寫.
4.移植到dx11的準備(搞不好會跳到dx12, 微軟應該會加速dx12的釋出)
g_pd3ddevice9->Clear(), 像這種dx9的移植到dx11都要改過.
為了移植, 又要把這種通通改成 Device::Clear(), 然後在Clear(){ dx11Device->Clear(); }
感覺就是又包一層, 有彈性 但是code的閱讀變困難了.
簡單的說 現在似乎到了要寫強大編輯器的時候, 只是 編輯器這種東西 可大可小.
不是很想寫, 就像不大想寫UI跟Particle, 這都是跟遊戲相關程度很大的.
跟遊戲的類型很有相關性. 簡單說 編輯器長的甚麼樣子 遊戲就會是甚麼樣子.
編輯器會有很多無聊的code, 亂七八糟的屬性設定.
編輯器的code就是那種 寫過一遍後 就不大想去整理 優化的.
========================
code的整理 我認為 這根本是藝術.
整理過後的code 一定要更短, 簡捷, 就是把多餘的脂肪 拿掉.
標準還是那樣: 更容易 閱讀 修改 擴充.
不是用更長的code 去取代更短的code, 結果功能都沒增加.
intel 的 software occlusion culling 我只寫了400行的 code就完成了.
(intel 那裏面的code 根本亂用繼承 亂用到亂七八糟的地步)
布料動畫的code,只寫了 720行就完成了.
該寫的特效都寫的差不多了, 反正網路上找不到code的,
那表示 也不用寫了, 因為根本不用幻想寫出來.
想寫植物動來動去的特效, 這似乎編輯器的部分比較多.
3D隨便一個特效 要寫到完整, 你認為要寫多久 ?
我看5~10年以上, 甚至20年.....
所以要知道 甚麼時候要停止.
3D程式目前就是走2,3步, 然後退一步. 寫些新的特效, 然後再把寫過的code整理.
1. 程式碼的整理 是相當重要的. 這也是一直持續在做的. 整理過的 code 威力會更強大.
2. 目前人物有點弱, 因為將來移植到dx11, 對.x file的支援將會沒有.
要用.FBX? 不是很清楚.
比較麻煩的事, 人物需要美工的配合, 才能有比較好的測試.
3.移植到dx11的事前準備?
用了大量D3DXMatrix, 這個要怎麼處理? 用SSE優化? 要怎麼處理?
雖然有XnaMath.h, 微軟的東西就是, 更新速度很快, 而且喜歡把以前的東西全部推翻
然後又要重寫.
4.移植到dx11的準備(搞不好會跳到dx12, 微軟應該會加速dx12的釋出)
g_pd3ddevice9->Clear(), 像這種dx9的移植到dx11都要改過.
為了移植, 又要把這種通通改成 Device::Clear(), 然後在Clear(){ dx11Device->Clear(); }
感覺就是又包一層, 有彈性 但是code的閱讀變困難了.
簡單的說 現在似乎到了要寫強大編輯器的時候, 只是 編輯器這種東西 可大可小.
不是很想寫, 就像不大想寫UI跟Particle, 這都是跟遊戲相關程度很大的.
跟遊戲的類型很有相關性. 簡單說 編輯器長的甚麼樣子 遊戲就會是甚麼樣子.
編輯器會有很多無聊的code, 亂七八糟的屬性設定.
編輯器的code就是那種 寫過一遍後 就不大想去整理 優化的.
========================
code的整理 我認為 這根本是藝術.
整理過後的code 一定要更短, 簡捷, 就是把多餘的脂肪 拿掉.
標準還是那樣: 更容易 閱讀 修改 擴充.
不是用更長的code 去取代更短的code, 結果功能都沒增加.
intel 的 software occlusion culling 我只寫了400行的 code就完成了.
(intel 那裏面的code 根本亂用繼承 亂用到亂七八糟的地步)
布料動畫的code,只寫了 720行就完成了.
Occlusion culling II
最後還是直接改 intel software occlusion cull 的code.
速度非常不錯.
經過BRDF的計算後, FPS只剩下65張, 經過cull後, 速度提升到 83張.
紅色圈起來的, 可以看到 被擋到後 render obj 只剩下 7個obj.
這個寫起來就很有成就感 花的時間少 效果又不錯
速度非常不錯.
經過BRDF的計算後, FPS只剩下65張, 經過cull後, 速度提升到 83張.
紅色圈起來的, 可以看到 被擋到後 render obj 只剩下 7個obj.
這個寫起來就很有成就感 花的時間少 效果又不錯
Occlusion culling
GPU把所有資料都輸出到 render target, 可惜的是 RT放在顯示卡的RAM.
cpu無取存取, 用GetRenderTargetData()速度很慢, 又要lock,導致效能低落.
沒想到 intel寫了一篇 software rasterizer occlusion culling
直接用cpu算,以為要賣cpu的, 沒想到很多遊戲 真的用cpu算Occlusion culling.
要把我10幾年前寫的software engine 拿出來用, 真是不可思議.
software rasterizer主要3個步驟
1.投影轉換到 screen space
2.切割
3.Fill, 計算z值
cpu無取存取, 用GetRenderTargetData()速度很慢, 又要lock,導致效能低落.
沒想到 intel寫了一篇 software rasterizer occlusion culling
直接用cpu算,以為要賣cpu的, 沒想到很多遊戲 真的用cpu算Occlusion culling.
要把我10幾年前寫的software engine 拿出來用, 真是不可思議.
software rasterizer主要3個步驟
1.投影轉換到 screen space
2.切割
3.Fill, 計算z值
Citywar 3D Engine Techdemo 2.0 Release
Citywar 3D Engine Techdemo 2.0 Release
包含 cloth 動畫 跟 GI, AO.
https://app.box.com/s/tnqhx6v5kvey1k1jczv9 (28mb)
使用方明如下: 按F4顯示對話盒.
包含 cloth 動畫 跟 GI, AO.
https://app.box.com/s/tnqhx6v5kvey1k1jczv9 (28mb)
使用方明如下: 按F4顯示對話盒.
用3ds max Render 出來的GI AO
應該沒有哪款遊戲可以做到即時GI.
GI困難的兩點: GI計算公式, 計算出來的資料要放在哪裡?
計算公式太難了, 弄不出來, 所以想到的方法 就是用 3ds max 幫忙計算.
本來想把資料放在 voxel, 但是資料太過龐大 而且不夠準確.
所以就放在lightmap.
困難點有兩個:
拆UV, 很難拆到完美, 要調整參數, 建模型 就需考慮進去.
D3DXUVAtlasCreate用這個下去算的. 又有接縫的問題.
3ds max的參數 影響很大, 很難設一組參數 然後對每個模型通用.
要針對每個模型去調整光線的亮度.
很多遊戲裡的一些場景亮度 都有過暗的情形發生, 那是因為光線的bounce 不夠多.
如果bounce設多一點 計算速度很慢.
GI困難的兩點: GI計算公式, 計算出來的資料要放在哪裡?
計算公式太難了, 弄不出來, 所以想到的方法 就是用 3ds max 幫忙計算.
本來想把資料放在 voxel, 但是資料太過龐大 而且不夠準確.
所以就放在lightmap.
困難點有兩個:
拆UV, 很難拆到完美, 要調整參數, 建模型 就需考慮進去.
D3DXUVAtlasCreate用這個下去算的. 又有接縫的問題.
3ds max的參數 影響很大, 很難設一組參數 然後對每個模型通用.
要針對每個模型去調整光線的亮度.
很多遊戲裡的一些場景亮度 都有過暗的情形發生, 那是因為光線的bounce 不夠多.
如果bounce設多一點 計算速度很慢.
訂閱：
文章 (Atom)