置頂隨筆
#
一：一些廢話
好久沒更新了，一方面是年底了，對(duì)于做銷售的人來(lái)說(shuō)，利用這段時(shí)間出出差，拜訪拜訪經(jīng)銷商以及KA客戶，目的是確定明年的銷售指標(biāo)，暈。另一個(gè)更重要的原因是竟然把密碼忘記了，沒辦法進(jìn)入我的博客。前天整理東西時(shí)候竟然發(fā)現(xiàn)寫密碼的那張紙了，內(nèi)心狂喜，哈哈！！
本來(lái)想接上次的，寫一些關(guān)于渲染器方面的東西，但是因?yàn)檎麄€(gè)渲染器是依賴與BSP進(jìn)行操作的，而且QUAKE中的碰撞檢測(cè)也是依賴與BSP樹的，因此先寫一些關(guān)于BSP樹方面的基礎(chǔ)東西，以利于大家有個(gè)比較具體的印象，希望能夠?qū)懙谋容^通俗易懂吧。
事實(shí)上，前天我寫了將近500字的BSP編譯器的分析的文章，發(fā)現(xiàn)好象如果直接寫編譯器這個(gè)核心東西，可能需要一些關(guān)于QUAKE的BSP的相關(guān)理論的和基礎(chǔ)的東西，特別是QQ上有個(gè)朋友和我說(shuō)，他研究QUAKE2的渲染器代碼已經(jīng)很久了，但是有些函數(shù)看了半年還是看不懂，哈哈，其實(shí)這和我以前的感覺一樣。為什么呢，因?yàn)閷?shí)在網(wǎng)絡(luò)資料很少，如果你不從Q3MAP這個(gè)源代碼以及關(guān)卡編輯器產(chǎn)生的結(jié)果數(shù)據(jù)和GAME.DLL模塊中以SP_開頭的函數(shù)進(jìn)行分析的話，BSP永遠(yuǎn)都是一知半解的，那是因?yàn)椴恢?span>BSP生成的原理，所以很多東西都看不懂。所以決定了，先從結(jié)果推導(dǎo)BSP的編譯原理，當(dāng)然我想這是一個(gè)非常大的代碼分析，基本上最起碼可以寫15000字以上的文章了，呵呵，反正現(xiàn)在有的是時(shí)間，就慢慢寫吧
二：分析生成BSP后的文件結(jié)構(gòu)：
BSP事實(shí)上分為三個(gè)部分，第一部分是關(guān)卡編輯器生成.map的文件格式（Q3RADIANT），第二部分是通過Q3MAP將.map的文件格式編譯成.BSP格式,對(duì)于BSP文件而言,我們可以將BSP格式的文件數(shù)據(jù)分成兩個(gè)大類,即用于渲染用的數(shù)據(jù)和用于碰撞檢測(cè)的數(shù)據(jù)(QUAKE3里面稱為CLIPMAP),至于編譯過程就是一個(gè)流水線式的操作,要進(jìn)行多次步驟產(chǎn)生結(jié)果. 第三部分是操作BSP,關(guān)于BSP的操作,以后我慢慢來(lái)寫,事實(shí)上是非常非常重要的和好玩的東東.
在這里我只想簡(jiǎn)單說(shuō)一下為什么BSP的文件格式里面包含渲染數(shù)據(jù)和物理碰撞數(shù)據(jù),那是因?yàn)?span>QUAKE3的渲染部分和物理碰撞部分是分離的，這樣的好處是渲染部分是客戶端進(jìn)行調(diào)用的,服務(wù)器端不需要用到渲染模塊,然而碰撞檢測(cè)卻是服務(wù)器端和客戶端都要用到的,所以分離以后就具有很大的靈活性. 事實(shí)上服務(wù)器是上帝,定義一切規(guī)則和進(jìn)行物理動(dòng)力學(xué)的計(jì)算,而客戶端使用碰撞檢測(cè)是為了進(jìn)行同步服務(wù)器,進(jìn)行客戶端預(yù)測(cè)使用的,這是一個(gè)網(wǎng)絡(luò)端編程的概念,以后進(jìn)行C/S架構(gòu)分析再說(shuō)吧
三: BSP文件結(jié)構(gòu)代碼
typedef struct {
int fileofs, filelen;
} lump_t;
typedef struct {
int ident;
int version;
lump_t lumps[HEADER_LUMPS];
} dheader_t;//
typedef struct {
char shader[MAX_QPATH];
int surfaceFlags;//絕對(duì)經(jīng)典的東西，還是和q3map一起說(shuō)比較有趣，
int contentFlags;//絕對(duì)經(jīng)典的東西，還是和q3map一起說(shuō)比較有趣
} dshader_t; // lump1
// planes x^1 is allways the opposite of plane x
typedef struct {
float normal[3];
float dist;
} dplane_t; // lump2
typedef struct {
int planeNum;
int children[2]; // negative numbers are -(leafs+1), not nodes
int mins[3]; // for frustom culling
int maxs[3];
} dnode_t; // lump3
typedef struct {
int cluster; // -1 = opaque cluster (do I still store these?)
int area;
int mins[3]; // for frustum culling
int maxs[3];
int firstLeafSurface;
int numLeafSurfaces;
//用于碰撞檢測(cè)，不用于渲染模塊
int firstLeafBrush;
int numLeafBrushes;
} dleaf_t; // lump4
int leafsurfaces; // lump5
int leafbrushes; //lump6
typedef struct {
float mins[3], maxs[3];
int firstSurface, numSurfaces;
//下面的變量用于碰撞檢測(cè)用
int firstBrush, numBrushes;
} dmodel_t;// lump7
typedef struct {
int firstSide;
int numSides;
int shaderNum; // the shader that determines the contents flags
} dbrush_t;// lump8
typedef struct {
int planeNum; // positive plane side faces out of the leaf
int shaderNum;
} dbrushside_t;// lump9
typedef struct {
vec3_t xyz;
float st[2];
float lightmap[2];
vec3_t normal;
byte color[4];
} drawVert_t;// lump10
int drawIndexes; // lump11
typedef struct {
char shader[MAX_QPATH];
int brushNum;
int visibleSide; // the brush side that ray tests need to clip against (-1 == none)
} dfog_t;// lump12
//對(duì)表面類型進(jìn)行總結(jié)，具體見下面
typedef enum {
MST_BAD,
MST_PLANAR,//很重要的，說(shuō)明該表面是一個(gè)世界的靜態(tài)表面，例如墻面，地板等，可以通
//過brushside計(jì)算出來(lái)
MST_PATCH,//二次貝塞爾表面，要進(jìn)行相應(yīng)三角型化，要求速度的話，可以使用前向差分
//算法，二次貝塞爾使用9個(gè)控制點(diǎn)插值計(jì)算
MST_TRIANGLE_SOUP,//用于BMODEL的表面，可以進(jìn)行三角形扇或帶化或頂點(diǎn)索引三角形
//如果要了解具體算法，可以參考一些計(jì)算幾何的算法，如果有足夠
//深厚的功力，建議參考nvstriper相關(guān)代碼，還有關(guān)于計(jì)算幾何或
//拓拔方面的知識(shí)，網(wǎng)絡(luò)上有一個(gè)很好的庫(kù)ttl，里面有篇實(shí)現(xiàn)的論
//文，關(guān)于gmap概念以及使用半邊結(jié)構(gòu)進(jìn)行各種拓拔查找以及修改，
//絕對(duì)經(jīng)典的東西
MST_FLARE //實(shí)際上就是公告版，因該都會(huì)使用吧
} mapSurfaceType_t;
typedef struct {
int shaderNum;//索引指向shaderlump
int fogNum;//索引指向foglump
int surfaceType;// mapSurfaceType_t,具體說(shuō)明見上
int firstVert;//索引指向drawVert_tlump
int numVerts;
int firstIndex;//索引指向頂點(diǎn)索引lump
int numIndexes;
//下面一些變量和靜態(tài)lightmap相關(guān)，事實(shí)上現(xiàn)在的圖形硬件足夠快，靜態(tài)光照?qǐng)D相關(guān)算
//法已有沒落的趨勢(shì)，事實(shí)上現(xiàn)在比較先進(jìn)的引擎都是全動(dòng)態(tài)光照，通過BSP進(jìn)行場(chǎng)景管理
//可以非常高效的實(shí)現(xiàn)，使渲染效果大幅度提高。這部分是我最感興趣的部分，以后有機(jī)會(huì)
//可以探討一下，但是必須要對(duì)BSP相關(guān)操作有非常的了解才可以深入
int lightmapNum;
int lightmapX, lightmapY;
int lightmapWidth, lightmapHeight;
vec3_t lightmapOrigin;
vec3_t lightmapVecs[3]; // for patches, [0] and [1] are lodbounds
//下面兩個(gè)變量用于貝塞爾曲面
int patchWidth;
int patchHeight;
} dsurface_t;// lump13
byte lightBytes; // lump14
byte lightgridData;// lump15
byte visBytes;// lump16
這里我列出bsp文件格式的各個(gè)lump，除了entity這個(gè)比較特別的lump，這個(gè)留到q3map再說(shuō)，是比較特別一個(gè)東東。還有就是具體表面，bmodel以及著名的brush/side等之間的關(guān)系，以及shader各個(gè)元素還是下次再寫把，發(fā)現(xiàn)寫東西還真是很費(fèi)腦子的拉，今天就先到這里了.
本來(lái)想直接進(jìn)入quake源碼分析，但發(fā)現(xiàn)如果沒有好的寫作框架，就憑QUAKE引擎這么大的代碼群，真的很難寫的，所以決定先搭一個(gè)分析框架，定義好各個(gè)章節(jié)，爭(zhēng)取在本周內(nèi)全部完成該工作，然后從下個(gè)禮拜開始就往分析框架里面填寫內(nèi)容了！哈哈！！
聲明：1。本人從未進(jìn)入程序員行列，只是喜好才寫這些文章的，所以在文章寫作過程中，有任何技術(shù)性的錯(cuò)誤，以及沒有甬道正確的術(shù)語(yǔ)，請(qǐng)見諒（因?yàn)楹芏鄎uake中的術(shù)語(yǔ)都是我自己定義的）
2。在整體的分析過程中，并不一定按照目錄所定義好的順序來(lái)寫的，想到什么就寫什么，這就是博客的精神把！！整個(gè)目錄框架是分析的思路，可能會(huì)改變。
3。在目錄各個(gè)章節(jié)都是主題的定義，我會(huì)在空閑時(shí)間慢慢的填進(jìn)去的，希望能夠最終堅(jiān)持下來(lái)形成一整套關(guān)于quake系列比較系統(tǒng)的文擋。
4。 本人的目的是在中國(guó)形成一個(gè)比較活躍的以quake為基礎(chǔ)的社群，希望更多的人了解quake的精神，我想在中國(guó)研究quake引擎的人應(yīng)該很多，高手更是不少，但是在中國(guó)的網(wǎng)絡(luò)上卻看不到系統(tǒng)的quake源碼分析，不知道為什么？？所以由本人，一個(gè)不在程序員序列的圖形學(xué)愛好者來(lái)稍微引導(dǎo)一下。由于本人不屬于程序員，因此也更本沒有所謂違反某個(gè)軟件公司的知識(shí)產(chǎn)權(quán)，具有更大的靈活性，希望其他地方的各個(gè)quake高手進(jìn)行完善與修整本人所寫的東東。
5。 本人渴望與從事游戲行業(yè)的程序員進(jìn)行交流。由于本人的生活圈子與程序員根本不搭界，所以沒有機(jī)會(huì)和從事游戲設(shè)計(jì)的人員進(jìn)行交流，很郁悶啊。很想了解一下現(xiàn)在的圖形學(xué)在中國(guó)處于什么狀態(tài)，各個(gè)游戲公司底層的引擎是自己開發(fā)的還是使用開源的或則是購(gòu)買世界著名的游戲引擎。希望能有機(jī)會(huì)與各位交流，本人的qq號(hào)碼是47178234，本人生活在上海，如果有上海的高手，我們可以多多交流，時(shí)而可以face to face的交流拉，以增加對(duì)程序員生活的真正了解！！
目錄：
第一章：QUAKE引擎的整體框架結(jié)構(gòu)：
1．引擎和API的精確定義
2．整個(gè)quake引擎是基于C/S模式
3．各個(gè)模塊間的關(guān)系圖
4．客戶端如何與服務(wù)器端相連接（網(wǎng)絡(luò)消息的傳遞與響應(yīng)以及客戶端數(shù)據(jù)庫(kù)的產(chǎn)生）
5．當(dāng)客戶端連接到服務(wù)器后如何進(jìn)入游戲狀態(tài)的流程（即玩家的產(chǎn)生）
6．當(dāng)客戶端死亡后重生的流程
7．簡(jiǎn)要說(shuō)明進(jìn)入游戲狀態(tài)后一幀運(yùn)行的流程，包括各個(gè)模塊函數(shù)調(diào)用的示意圖
第二章：渲染器(refresh模塊)
1. 兩個(gè)重要的由外部操作的結(jié)構(gòu)(refEntity_t和refdef_t)以及這些結(jié)構(gòu)各個(gè)值域的詳細(xì)解釋
2．渲染器模塊導(dǎo)出函數(shù)（API）的分類以及作用(以quake3-1.32b原代碼為準(zhǔn))
A：渲染數(shù)據(jù)資源管理函數(shù)集（12個(gè)函數(shù)，資源包括BSP世界數(shù)據(jù)，模型數(shù)據(jù)，shader數(shù)據(jù)，skin數(shù)據(jù)，vis數(shù)據(jù)以及字體）
B：設(shè)置渲染命令流水線的函數(shù)集（4個(gè)函數(shù)）
C：場(chǎng)景管理以及渲染的函數(shù)集（7個(gè)函數(shù)）
D：其他函數(shù)集（6個(gè)函數(shù)）總計(jì)29個(gè)導(dǎo)出函數(shù)
3．Quake3 渲染器的整體結(jié)構(gòu)：
A：QUAKE3渲染器是以OPENGL為基礎(chǔ)并支持雙處理器并行運(yùn)算的
B：QUAKE3渲染器在渲染過程中可以分為前端部分和后端部分（圖解），他們是如何協(xié)調(diào)起來(lái)的。
C: QUAKE3是如何支持雙處理器并行進(jìn)行渲染
4．對(duì)quake3模型系統(tǒng)的擴(kuò)展（使用MD5模型格式以及skm模型格式）
A: 為什么不用MD3模型
B：MD5&SKM骨骼模型的格式分析
C：骨骼動(dòng)畫的原理以及應(yīng)用
（1） 骨骼動(dòng)畫的分類（boneoffset類型和vertexoffset類型的詳解以及各自的優(yōu)缺點(diǎn)）
（2） 詳細(xì)分析骨骼動(dòng)畫數(shù)學(xué)原理
（3） 在定義骨骼動(dòng)畫的時(shí)候需要詳細(xì)考慮的一些問題以及目的，不同的目的會(huì)有不同的編碼方式
（4） 重點(diǎn)分析SKM骨骼動(dòng)畫在warsow游戲中的運(yùn)用以及編碼方式
（5） 骨骼動(dòng)畫的CPU實(shí)現(xiàn)和GPU實(shí)現(xiàn)的優(yōu)缺點(diǎn)分析以及如何平衡各自的優(yōu)缺點(diǎn)
（6） 附我的計(jì)劃：市面上公開格式的骨骼動(dòng)畫事實(shí)上在渲染原理上基本差別不是很大，因此在學(xué)習(xí)骨骼動(dòng)畫的過程中，感受很多啊，現(xiàn)在本人正在進(jìn)行系統(tǒng)設(shè)計(jì)，根據(jù)骨骼動(dòng)畫的原理，參考相關(guān)資料，提煉出一條骨骼動(dòng)畫統(tǒng)一渲染流水線。完成后公開源代碼。系統(tǒng)設(shè)計(jì)的要求是
（A） 可以直接并入quake3引擎的多核渲染流水線
（B） 使用CPU實(shí)現(xiàn)的，以SIMD為基礎(chǔ)數(shù)學(xué)運(yùn)算（因?yàn)?span lang=EN-US>CPU實(shí)現(xiàn)進(jìn)行轉(zhuǎn)化后可以直接獲得頂點(diǎn)數(shù)據(jù)再進(jìn)行陰影系統(tǒng)的繪制，而GPU數(shù)據(jù)的取回比較麻煩，再說(shuō)本人也沒有支持D3D10版本的GPU，無(wú)法使用新增加的stream output statge以及幾何shader）
（C） 能夠在運(yùn)行過程中人工控制各個(gè)骨頭的運(yùn)動(dòng)
（D） 使用統(tǒng)一的骨骼動(dòng)畫渲染流水線，使模型與數(shù)據(jù)相分離,并且將陰影系統(tǒng)并入該渲染流水線。
5．BSP文件格式以及QUAKE3 SHADER文件格式
今天就寫到目錄的前兩章，計(jì)劃在本周內(nèi)將所有章節(jié)全部定義出來(lái)，然后再填寫各個(gè)小節(jié)的內(nèi)容
2008年1月27日
#
一：一些廢話
好久沒更新了，一方面是年底了，對(duì)于做銷售的人來(lái)說(shuō)，利用這段時(shí)間出出差，拜訪拜訪經(jīng)銷商以及KA客戶，目的是確定明年的銷售指標(biāo)，暈。另一個(gè)更重要的原因是竟然把密碼忘記了，沒辦法進(jìn)入我的博客。前天整理東西時(shí)候竟然發(fā)現(xiàn)寫密碼的那張紙了，內(nèi)心狂喜，哈哈！！
本來(lái)想接上次的，寫一些關(guān)于渲染器方面的東西，但是因?yàn)檎麄€(gè)渲染器是依賴與BSP進(jìn)行操作的，而且QUAKE中的碰撞檢測(cè)也是依賴與BSP樹的，因此先寫一些關(guān)于BSP樹方面的基礎(chǔ)東西，以利于大家有個(gè)比較具體的印象，希望能夠?qū)懙谋容^通俗易懂吧。
事實(shí)上，前天我寫了將近500字的BSP編譯器的分析的文章，發(fā)現(xiàn)好象如果直接寫編譯器這個(gè)核心東西，可能需要一些關(guān)于QUAKE的BSP的相關(guān)理論的和基礎(chǔ)的東西，特別是QQ上有個(gè)朋友和我說(shuō)，他研究QUAKE2的渲染器代碼已經(jīng)很久了，但是有些函數(shù)看了半年還是看不懂，哈哈，其實(shí)這和我以前的感覺一樣。為什么呢，因?yàn)閷?shí)在網(wǎng)絡(luò)資料很少，如果你不從Q3MAP這個(gè)源代碼以及關(guān)卡編輯器產(chǎn)生的結(jié)果數(shù)據(jù)和GAME.DLL模塊中以SP_開頭的函數(shù)進(jìn)行分析的話，BSP永遠(yuǎn)都是一知半解的，那是因?yàn)椴恢?span>BSP生成的原理，所以很多東西都看不懂。所以決定了，先從結(jié)果推導(dǎo)BSP的編譯原理，當(dāng)然我想這是一個(gè)非常大的代碼分析，基本上最起碼可以寫15000字以上的文章了，呵呵，反正現(xiàn)在有的是時(shí)間，就慢慢寫吧
二：分析生成BSP后的文件結(jié)構(gòu)：
BSP事實(shí)上分為三個(gè)部分，第一部分是關(guān)卡編輯器生成.map的文件格式（Q3RADIANT），第二部分是通過Q3MAP將.map的文件格式編譯成.BSP格式,對(duì)于BSP文件而言,我們可以將BSP格式的文件數(shù)據(jù)分成兩個(gè)大類,即用于渲染用的數(shù)據(jù)和用于碰撞檢測(cè)的數(shù)據(jù)(QUAKE3里面稱為CLIPMAP),至于編譯過程就是一個(gè)流水線式的操作,要進(jìn)行多次步驟產(chǎn)生結(jié)果. 第三部分是操作BSP,關(guān)于BSP的操作,以后我慢慢來(lái)寫,事實(shí)上是非常非常重要的和好玩的東東.
在這里我只想簡(jiǎn)單說(shuō)一下為什么BSP的文件格式里面包含渲染數(shù)據(jù)和物理碰撞數(shù)據(jù),那是因?yàn)?span>QUAKE3的渲染部分和物理碰撞部分是分離的，這樣的好處是渲染部分是客戶端進(jìn)行調(diào)用的,服務(wù)器端不需要用到渲染模塊,然而碰撞檢測(cè)卻是服務(wù)器端和客戶端都要用到的,所以分離以后就具有很大的靈活性. 事實(shí)上服務(wù)器是上帝,定義一切規(guī)則和進(jìn)行物理動(dòng)力學(xué)的計(jì)算,而客戶端使用碰撞檢測(cè)是為了進(jìn)行同步服務(wù)器,進(jìn)行客戶端預(yù)測(cè)使用的,這是一個(gè)網(wǎng)絡(luò)端編程的概念,以后進(jìn)行C/S架構(gòu)分析再說(shuō)吧
三: BSP文件結(jié)構(gòu)代碼
typedef struct {
int fileofs, filelen;
} lump_t;
typedef struct {
int ident;
int version;
lump_t lumps[HEADER_LUMPS];
} dheader_t;//
typedef struct {
char shader[MAX_QPATH];
int surfaceFlags;//絕對(duì)經(jīng)典的東西，還是和q3map一起說(shuō)比較有趣，
int contentFlags;//絕對(duì)經(jīng)典的東西，還是和q3map一起說(shuō)比較有趣
} dshader_t; // lump1
// planes x^1 is allways the opposite of plane x
typedef struct {
float normal[3];
float dist;
} dplane_t; // lump2
typedef struct {
int planeNum;
int children[2]; // negative numbers are -(leafs+1), not nodes
int mins[3]; // for frustom culling
int maxs[3];
} dnode_t; // lump3
typedef struct {
int cluster; // -1 = opaque cluster (do I still store these?)
int area;
int mins[3]; // for frustum culling
int maxs[3];
int firstLeafSurface;
int numLeafSurfaces;
//用于碰撞檢測(cè)，不用于渲染模塊
int firstLeafBrush;
int numLeafBrushes;
} dleaf_t; // lump4
int leafsurfaces; // lump5
int leafbrushes; //lump6
typedef struct {
float mins[3], maxs[3];
int firstSurface, numSurfaces;
//下面的變量用于碰撞檢測(cè)用
int firstBrush, numBrushes;
} dmodel_t;// lump7
typedef struct {
int firstSide;
int numSides;
int shaderNum; // the shader that determines the contents flags
} dbrush_t;// lump8
typedef struct {
int planeNum; // positive plane side faces out of the leaf
int shaderNum;
} dbrushside_t;// lump9
typedef struct {
vec3_t xyz;
float st[2];
float lightmap[2];
vec3_t normal;
byte color[4];
} drawVert_t;// lump10
int drawIndexes; // lump11
typedef struct {
char shader[MAX_QPATH];
int brushNum;
int visibleSide; // the brush side that ray tests need to clip against (-1 == none)
} dfog_t;// lump12
//對(duì)表面類型進(jìn)行總結(jié)，具體見下面
typedef enum {
MST_BAD,
MST_PLANAR,//很重要的，說(shuō)明該表面是一個(gè)世界的靜態(tài)表面，例如墻面，地板等，可以通
//過brushside計(jì)算出來(lái)
MST_PATCH,//二次貝塞爾表面，要進(jìn)行相應(yīng)三角型化，要求速度的話，可以使用前向差分
//算法，二次貝塞爾使用9個(gè)控制點(diǎn)插值計(jì)算
MST_TRIANGLE_SOUP,//用于BMODEL的表面，可以進(jìn)行三角形扇或帶化或頂點(diǎn)索引三角形
//如果要了解具體算法，可以參考一些計(jì)算幾何的算法，如果有足夠
//深厚的功力，建議參考nvstriper相關(guān)代碼，還有關(guān)于計(jì)算幾何或
//拓拔方面的知識(shí)，網(wǎng)絡(luò)上有一個(gè)很好的庫(kù)ttl，里面有篇實(shí)現(xiàn)的論
//文，關(guān)于gmap概念以及使用半邊結(jié)構(gòu)進(jìn)行各種拓拔查找以及修改，
//絕對(duì)經(jīng)典的東西
MST_FLARE //實(shí)際上就是公告版，因該都會(huì)使用吧
} mapSurfaceType_t;
typedef struct {
int shaderNum;//索引指向shaderlump
int fogNum;//索引指向foglump
int surfaceType;// mapSurfaceType_t,具體說(shuō)明見上
int firstVert;//索引指向drawVert_tlump
int numVerts;
int firstIndex;//索引指向頂點(diǎn)索引lump
int numIndexes;
//下面一些變量和靜態(tài)lightmap相關(guān)，事實(shí)上現(xiàn)在的圖形硬件足夠快，靜態(tài)光照?qǐng)D相關(guān)算
//法已有沒落的趨勢(shì)，事實(shí)上現(xiàn)在比較先進(jìn)的引擎都是全動(dòng)態(tài)光照，通過BSP進(jìn)行場(chǎng)景管理
//可以非常高效的實(shí)現(xiàn)，使渲染效果大幅度提高。這部分是我最感興趣的部分，以后有機(jī)會(huì)
//可以探討一下，但是必須要對(duì)BSP相關(guān)操作有非常的了解才可以深入
int lightmapNum;
int lightmapX, lightmapY;
int lightmapWidth, lightmapHeight;
vec3_t lightmapOrigin;
vec3_t lightmapVecs[3]; // for patches, [0] and [1] are lodbounds
//下面兩個(gè)變量用于貝塞爾曲面
int patchWidth;
int patchHeight;
} dsurface_t;// lump13
byte lightBytes; // lump14
byte lightgridData;// lump15
byte visBytes;// lump16
這里我列出bsp文件格式的各個(gè)lump，除了entity這個(gè)比較特別的lump，這個(gè)留到q3map再說(shuō)，是比較特別一個(gè)東東。還有就是具體表面，bmodel以及著名的brush/side等之間的關(guān)系，以及shader各個(gè)元素還是下次再寫把，發(fā)現(xiàn)寫東西還真是很費(fèi)腦子的拉，今天就先到這里了.
2007年11月20日
#
本來(lái)想直接進(jìn)入quake源碼分析，但發(fā)現(xiàn)如果沒有好的寫作框架，就憑QUAKE引擎這么大的代碼群，真的很難寫的，所以決定先搭一個(gè)分析框架，定義好各個(gè)章節(jié)，爭(zhēng)取在本周內(nèi)全部完成該工作，然后從下個(gè)禮拜開始就往分析框架里面填寫內(nèi)容了！哈哈！！
聲明：1。本人從未進(jìn)入程序員行列，只是喜好才寫這些文章的，所以在文章寫作過程中，有任何技術(shù)性的錯(cuò)誤，以及沒有甬道正確的術(shù)語(yǔ)，請(qǐng)見諒（因?yàn)楹芏鄎uake中的術(shù)語(yǔ)都是我自己定義的）
2。在整體的分析過程中，并不一定按照目錄所定義好的順序來(lái)寫的，想到什么就寫什么，這就是博客的精神把！！整個(gè)目錄框架是分析的思路，可能會(huì)改變。
3。在目錄各個(gè)章節(jié)都是主題的定義，我會(huì)在空閑時(shí)間慢慢的填進(jìn)去的，希望能夠最終堅(jiān)持下來(lái)形成一整套關(guān)于quake系列比較系統(tǒng)的文擋。
4。 本人的目的是在中國(guó)形成一個(gè)比較活躍的以quake為基礎(chǔ)的社群，希望更多的人了解quake的精神，我想在中國(guó)研究quake引擎的人應(yīng)該很多，高手更是不少，但是在中國(guó)的網(wǎng)絡(luò)上卻看不到系統(tǒng)的quake源碼分析，不知道為什么？？所以由本人，一個(gè)不在程序員序列的圖形學(xué)愛好者來(lái)稍微引導(dǎo)一下。由于本人不屬于程序員，因此也更本沒有所謂違反某個(gè)軟件公司的知識(shí)產(chǎn)權(quán)，具有更大的靈活性，希望其他地方的各個(gè)quake高手進(jìn)行完善與修整本人所寫的東東。
5。 本人渴望與從事游戲行業(yè)的程序員進(jìn)行交流。由于本人的生活圈子與程序員根本不搭界，所以沒有機(jī)會(huì)和從事游戲設(shè)計(jì)的人員進(jìn)行交流，很郁悶啊。很想了解一下現(xiàn)在的圖形學(xué)在中國(guó)處于什么狀態(tài)，各個(gè)游戲公司底層的引擎是自己開發(fā)的還是使用開源的或則是購(gòu)買世界著名的游戲引擎。希望能有機(jī)會(huì)與各位交流，本人的qq號(hào)碼是47178234，本人生活在上海，如果有上海的高手，我們可以多多交流，時(shí)而可以face to face的交流拉，以增加對(duì)程序員生活的真正了解！！
目錄：
第一章：QUAKE引擎的整體框架結(jié)構(gòu)：
1．引擎和API的精確定義
2．整個(gè)quake引擎是基于C/S模式
3．各個(gè)模塊間的關(guān)系圖
4．客戶端如何與服務(wù)器端相連接（網(wǎng)絡(luò)消息的傳遞與響應(yīng)以及客戶端數(shù)據(jù)庫(kù)的產(chǎn)生）
5．當(dāng)客戶端連接到服務(wù)器后如何進(jìn)入游戲狀態(tài)的流程（即玩家的產(chǎn)生）
6．當(dāng)客戶端死亡后重生的流程
7．簡(jiǎn)要說(shuō)明進(jìn)入游戲狀態(tài)后一幀運(yùn)行的流程，包括各個(gè)模塊函數(shù)調(diào)用的示意圖
第二章：渲染器(refresh模塊)
1. 兩個(gè)重要的由外部操作的結(jié)構(gòu)(refEntity_t和refdef_t)以及這些結(jié)構(gòu)各個(gè)值域的詳細(xì)解釋
2．渲染器模塊導(dǎo)出函數(shù)（API）的分類以及作用(以quake3-1.32b原代碼為準(zhǔn))
A：渲染數(shù)據(jù)資源管理函數(shù)集（12個(gè)函數(shù)，資源包括BSP世界數(shù)據(jù)，模型數(shù)據(jù)，shader數(shù)據(jù)，skin數(shù)據(jù)，vis數(shù)據(jù)以及字體）
B：設(shè)置渲染命令流水線的函數(shù)集（4個(gè)函數(shù)）
C：場(chǎng)景管理以及渲染的函數(shù)集（7個(gè)函數(shù)）
D：其他函數(shù)集（6個(gè)函數(shù)）總計(jì)29個(gè)導(dǎo)出函數(shù)
3．Quake3 渲染器的整體結(jié)構(gòu)：
A：QUAKE3渲染器是以OPENGL為基礎(chǔ)并支持雙處理器并行運(yùn)算的
B：QUAKE3渲染器在渲染過程中可以分為前端部分和后端部分（圖解），他們是如何協(xié)調(diào)起來(lái)的。
C: QUAKE3是如何支持雙處理器并行進(jìn)行渲染
4．對(duì)quake3模型系統(tǒng)的擴(kuò)展（使用MD5模型格式以及skm模型格式）
A: 為什么不用MD3模型
B：MD5&SKM骨骼模型的格式分析
C：骨骼動(dòng)畫的原理以及應(yīng)用
（1） 骨骼動(dòng)畫的分類（boneoffset類型和vertexoffset類型的詳解以及各自的優(yōu)缺點(diǎn)）
（2） 詳細(xì)分析骨骼動(dòng)畫數(shù)學(xué)原理
（3） 在定義骨骼動(dòng)畫的時(shí)候需要詳細(xì)考慮的一些問題以及目的，不同的目的會(huì)有不同的編碼方式
（4） 重點(diǎn)分析SKM骨骼動(dòng)畫在warsow游戲中的運(yùn)用以及編碼方式
（5） 骨骼動(dòng)畫的CPU實(shí)現(xiàn)和GPU實(shí)現(xiàn)的優(yōu)缺點(diǎn)分析以及如何平衡各自的優(yōu)缺點(diǎn)
（6） 附我的計(jì)劃：市面上公開格式的骨骼動(dòng)畫事實(shí)上在渲染原理上基本差別不是很大，因此在學(xué)習(xí)骨骼動(dòng)畫的過程中，感受很多啊，現(xiàn)在本人正在進(jìn)行系統(tǒng)設(shè)計(jì)，根據(jù)骨骼動(dòng)畫的原理，參考相關(guān)資料，提煉出一條骨骼動(dòng)畫統(tǒng)一渲染流水線。完成后公開源代碼。系統(tǒng)設(shè)計(jì)的要求是
（A） 可以直接并入quake3引擎的多核渲染流水線
（B） 使用CPU實(shí)現(xiàn)的，以SIMD為基礎(chǔ)數(shù)學(xué)運(yùn)算（因?yàn)?span lang=EN-US>CPU實(shí)現(xiàn)進(jìn)行轉(zhuǎn)化后可以直接獲得頂點(diǎn)數(shù)據(jù)再進(jìn)行陰影系統(tǒng)的繪制，而GPU數(shù)據(jù)的取回比較麻煩，再說(shuō)本人也沒有支持D3D10版本的GPU，無(wú)法使用新增加的stream output statge以及幾何shader）
（C） 能夠在運(yùn)行過程中人工控制各個(gè)骨頭的運(yùn)動(dòng)
（D） 使用統(tǒng)一的骨骼動(dòng)畫渲染流水線，使模型與數(shù)據(jù)相分離,并且將陰影系統(tǒng)并入該渲染流水線。
5．BSP文件格式以及QUAKE3 SHADER文件格式
今天就寫到目錄的前兩章，計(jì)劃在本周內(nèi)將所有章節(jié)全部定義出來(lái)，然后再填寫各個(gè)小節(jié)的內(nèi)容
2007年11月19日
#
QUAKE系列引擎以及基于QUAKE擴(kuò)展引擎的源代碼全面分析(一)
前言：
一：研究quake系列引擎斷斷續(xù)續(xù)也已經(jīng)兩年有余了，一直想寫點(diǎn)什么，但是真的到了那一步，又發(fā)現(xiàn)其實(shí)很難下筆，原因有三：1 文筆不流暢，特別是技術(shù)性技巧的缺乏，概念難以精確定義，無(wú)法想內(nèi)心的真實(shí)表達(dá)轉(zhuǎn)換為文字，郁悶啊！！2 QUAKE系列引擎的龐大結(jié)構(gòu)以及各個(gè)模塊的協(xié)作關(guān)系，真的想寫的時(shí)候不知道如何組織，導(dǎo)致思路極其紊亂。3 對(duì)于QUAKE系列的深?yuàn)W部分，列如bsp的編譯程序部分的源碼還未完全理解，這是整個(gè)QUAKE引擎的核心部分，這是QUAKE系列引擎最核心的部分，可以說(shuō)，整個(gè)QUAKE系列引擎就是圍繞這張圖推進(jìn)的。雖然BSP的生成確實(shí)是一個(gè)非常非常難的難點(diǎn)，好在使用起BSP來(lái)相對(duì)比較簡(jiǎn)單，即使不知道如何生成，但至少可以靈活使用，偉大的慷慨的卡馬克。
二：QUAKE系列的引擎源碼分析涉及到的引擎包括如下幾個(gè)：
1 QUAKE1 及其基于 QUAKE1框架的擴(kuò)展引擎DARKPLACES
2 QUAKE2 及其基于 QUAKE2 框架的擴(kuò)展引擎 QFUSION
3 QUAKE3及其基于 QUAKE3 框架的擴(kuò)展引擎 XREAL/EVQ3
三：為什么要使用上述的擴(kuò)展引擎？
1 QUAKE系列引擎畢竟時(shí)間久遠(yuǎn)，現(xiàn)代硬件技術(shù)的發(fā)展以及渲染方面的新概念，新技術(shù)的出現(xiàn)，一些擴(kuò)展引擎更加貼近當(dāng)今世界技術(shù)發(fā)展的潮流。例如這三個(gè)引擎都增加了GLSL進(jìn)行相應(yīng)的擴(kuò)展。
2 這些擴(kuò)展引擎都是非常著名的開源項(xiàng)目，資料比較多，而且都有相應(yīng)使用這些擴(kuò)展引擎作成的游戲，可以觀看到游戲?qū)崟r(shí)效果。
例如基于DARKPLACES引擎的游戲—NEXUIZ，渲染效果極其驚人啊！！！
基于 QFUSION 引擎的游戲-----WARSOW
基于 XREAL/EVQ3引擎的游戲-----REVOLUTION
3 對(duì)上述三個(gè)擴(kuò)展引擎的感受
A:DARKPLACES使用QUAKE1的框架結(jié)構(gòu)，重寫了全部的渲染模塊，網(wǎng)絡(luò)協(xié)議以及傳輸模塊,支持DOOM3類型的光影特效，根據(jù)我的感覺，應(yīng)該是渲染效果最好的開源的項(xiàng)目，使用到了相當(dāng)多的特效（DOOM3光影特效=Stencil Shadow Volume, Per Pixel Lighting, NormalizationCubeMap, 2D+1D Attenuation Texturing, and Light Projection Filtering）.該引擎可以使用著名的QUAKEC進(jìn)行服務(wù)器端游戲邏輯的開發(fā)（相當(dāng)于QUAKE3中的GAME.DLL模塊）,同時(shí)相對(duì)于QUAKE1的QUAKEC內(nèi)置函數(shù),該引擎擴(kuò)展了相當(dāng)多的服務(wù)器端QUAKEC函數(shù).更漂亮的是他同時(shí)擴(kuò)展了客戶端邏輯部分的函數(shù),通過這些函數(shù)可以編寫客戶端游戲邏輯(相當(dāng)于QUAKE3中的CGAME.DLL模塊,但不完全等同).事實(shí)上本人是非常喜歡QUAKEC的編碼方式,簡(jiǎn)練而強(qiáng)大.
B:QFUSION引擎最大的特點(diǎn)是他的邏輯結(jié)構(gòu)非常清晰,他所擴(kuò)展的骨骼動(dòng)畫系統(tǒng)是其最大的特點(diǎn).本人的感覺是極其漂亮(當(dāng)然每個(gè)人的觀點(diǎn)不同,這只是本人的觀點(diǎn)罷了).他使用了skm骨骼動(dòng)畫文件格式.正是通過該引擎的骨骼動(dòng)畫系統(tǒng),讓本人完全掌握整個(gè)骨骼動(dòng)畫的精髓,真是收益非淺啊!!!而且整個(gè)游戲邏輯端非常清晰,在代碼分析時(shí)候主要以該引擎作為原代碼基礎(chǔ).
C:xreal/evq3整體框架與quake3變化不大,但是最重要的一點(diǎn)是,本人最喜歡的渲染器結(jié)構(gòu)是quake3的render.dll,簡(jiǎn)直是太完美了,quake3的渲染器可以使用雙處理器,為了支持雙處理器的運(yùn)作,quake3自己實(shí)現(xiàn)了一條渲染命令流水線,及其完美,收益非淺啊!!!!又要說(shuō)一句非常重要的話了,偉大的慷慨的卡馬克.而引xreal/evq3擎完美的保留了quake3的渲染器框架結(jié)構(gòu)同時(shí)擴(kuò)展了較多的功能,光影特效足夠強(qiáng)大.增加了md5骨骼模型的渲染.在以后渲染器代碼分析時(shí)候,主要以該擴(kuò)展引擎為基礎(chǔ)結(jié)合darkplaces引擎的相關(guān)技術(shù).
總體而言, quake系列引擎的整體架構(gòu)非常漂亮,是學(xué)習(xí)的好材料,并且從quake1到quake3,整體邏輯端代碼變化不大, 真正比較有突破性的是渲染引擎.本人在學(xué)習(xí)quake引擎過程中常常敬佩卡馬克的想象力,api函數(shù)是如此之簡(jiǎn)潔,整體框架是如此之完美,面向?qū)ο蟮?/span>c寫得如此之漂亮,通過quake引擎,可以學(xué)到游戲設(shè)計(jì)的各個(gè)概念以及各個(gè)模塊,外部工具是如何完美的結(jié)合起來(lái),這一點(diǎn)是非常非常重要的.
2007年11月1日
#
本人第一次寫博客，內(nèi)心誠(chéng)惶誠(chéng)恐。
首先，介紹一下自己吧。
1 一個(gè)老男人--今年31歲
2 一個(gè)從未進(jìn)入編程行業(yè)的老男人--有一份與編程相差十萬(wàn)八千里的工作，程序設(shè)計(jì)僅是個(gè)人愛好
3 一個(gè)對(duì)計(jì)算機(jī)圖形學(xué)以及QUAKE系列引擎有著特殊摯愛的老男人--計(jì)算機(jī)圖形學(xué)是OPENGL，D3D實(shí) 現(xiàn)的基礎(chǔ)，而QUAKE系列引擎則對(duì)當(dāng)今世界的3D游戲以及引擎發(fā)展有著深遠(yuǎn)的影響，由于卡馬克的無(wú)私奉獻(xiàn)， 讓我們有機(jī)會(huì)領(lǐng)略，了解3D世界的無(wú)限美麗。
其次，關(guān)于本人博客的內(nèi)容定位
1 關(guān)注OPENGL的軟件實(shí)現(xiàn)以及應(yīng)用
2 跟蹤計(jì)算機(jī)圖形學(xué)底層方面的相關(guān)內(nèi)容
3 交流3D的核心基礎(chǔ)----3D數(shù)學(xué)以及流水線管道相關(guān)內(nèi)容
4 探討一些開源的優(yōu)秀的3D引擎--例如OGRE，IRRLICHT，NEBULA等
5 當(dāng)然最核心的是共同研究QUAKE系列引擎的架構(gòu)，源代碼，MOD以及擴(kuò)展。
最后，一個(gè)疑問
在GOOGLE上發(fā)現(xiàn)國(guó)外對(duì)QUAKE的研究有非常多的網(wǎng)站，但為什么在中國(guó)卻見不到幾個(gè)啊？
根據(jù)我對(duì)QUAKE系列的不算專業(yè)的研究，感覺QUAKE系列引擎是個(gè)巨大的寶庫(kù)，可以學(xué)習(xí)到非常多的先進(jìn)技術(shù)和理念，每一個(gè)模塊都可以獨(dú)立出來(lái)成為非常優(yōu)秀的項(xiàng)目。
這是我第一次寫播客，不知道寫什么，所以想到什么寫什么。上述的內(nèi)容是我現(xiàn)今最感興趣的方面，而且也非常龐大，希望有時(shí)間能夠慢慢的和大家進(jìn)行交流，探討甚至是爭(zhēng)論。
對(duì)了，還有一件事情需要說(shuō)明：
本人文筆較差，以前一直想寫，但是真的要寫技術(shù)性文章時(shí)候發(fā)現(xiàn)無(wú)從下筆，因?yàn)榘l(fā)現(xiàn)很難把一些技術(shù)問題清晰明了的用文章表達(dá)出來(lái)，郁悶！！！所以以后寫得不好，就多諒了