• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            3D游戲之神-——約翰.卡馬克

            常用鏈接

            統計

            最新評論

            QUAKE系列引擎以及基于QUAKE擴展引擎的源代碼全面分析(三) --bsp文件格式分析1

             

            一:一些廢話  
               
            好久沒更新了,一方面是年底了,對于做銷售的人來說,利用這段時間出出差,拜訪拜訪經銷商以及KA客戶,目的是確定明年的銷售指標,暈。另一個更重要的原因是竟然把密碼忘記了,沒辦法進入我的博客。前天整理東西時候竟然發現寫密碼的那張紙了,內心狂喜,哈哈!!
                
            本來想接上次的,寫一些關于渲染器方面的東西,但是因為整個渲染器是依賴與BSP進行操作的,而且QUAKE中的碰撞檢測也是依賴與BSP樹的,因此先寫一些關于BSP樹方面的基礎東西,以利于大家有個比較具體的印象,希望能夠寫的比較通俗易懂吧。
                
            事實上,前天我寫了將近500字的BSP編譯器的分析的文章,發現好象如果直接寫編譯器這個核心東西,可能需要一些關于QUAKEBSP的相關理論的和基礎的東西,特別是QQ上有個朋友和我說,他研究QUAKE2的渲染器代碼已經很久了,但是有些函數看了半年還是看不懂,哈哈,其實這和我以前的感覺一樣。為什么呢,因為實在網絡資料很少,如果你不從Q3MAP這個源代碼以及關卡編輯器產生的結果數據和GAME.DLL模塊中以SP_開頭的函數進行分析的話,BSP永遠都是一知半解的,那是因為不知道BSP生成的原理,所以很多東西都看不懂。所以決定了,先從結果推導BSP的編譯原理,當然我想這是一個非常大的代碼分析,基本上最起碼可以寫15000字以上的文章了,呵呵,反正現在有的是時間,就慢慢寫吧
            二:分析生成BSP后的文件結構:
                 BSP
            事實上分為三個部分,第一部分是關卡編輯器生成.map的文件格式(Q3RADIANT),第二部分是通過Q3MAP.map的文件格式編譯成.BSP格式,對于BSP文件而言,我們可以將BSP格式的文件數據分成兩個大類,即用于渲染用的數據和用于碰撞檢測的數據(QUAKE3里面稱為CLIPMAP),至于編譯過程就是一個流水線式的操作,要進行多次步驟產生結果. 第三部分是操作BSP,關于BSP的操作,以后我慢慢來寫,事實上是非常非常重要的和好玩的東東.
               
            在這里我只想簡單說一下為什么BSP的文件格式里面包含渲染數據和物理碰撞數據,那是因為QUAKE3的渲染部分和物理碰撞部分是分離的,這樣的好處是渲染部分是客戶端進行調用的,服務器端不需要用到渲染模塊,然而碰撞檢測卻是服務器端和客戶端都要用到的,所以分離以后就具有很大的靈活性事實上服務器是上帝,定義一切規則和進行物理動力學的計算,而客戶端使用碰撞檢測是為了進行同步服務器,進行客戶端預測使用的,這是一個網絡端編程的概念,以后進行C/S架構分析再說吧
            : BSP文件結構代碼

             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;//
            絕對經典的東西,還是和q3map一起說比較有趣,
             int   contentFlags;//
            絕對經典的東西,還是和q3map一起說比較有趣
            } 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;
             //
            用于碰撞檢測,不用于渲染模塊
             int   firstLeafBrush;
             int   numLeafBrushes;
            } dleaf_t; //                lump4

            int leafsurfaces; // lump5
            int leafbrushes; //lump6

            typedef struct {
             float          mins[3], maxs[3];
             int   firstSurface, numSurfaces;

            //下面的變量用于碰撞檢測用
             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

            //對表面類型進行總結,具體見下面

            typedef enum {
             MST_BAD,
             MST_PLANAR,//
            很重要的,說明該表面是一個世界的靜態表面,例如墻面,地板等,可以通

            //brushside計算出來
             MST_PATCH,//
            二次貝塞爾表面,要進行相應三角型化,要求速度的話,可以使用前向差分

            //算法,二次貝塞爾使用9個控制點插值計算
             MST_TRIANGLE_SOUP,//
            用于BMODEL的表面,可以進行三角形扇或帶化或頂點索引三角形

            //如果要了解具體算法,可以參考一些計算幾何的算法,如果有足夠

            //深厚的功力,建議參考nvstriper相關代碼,還有關于計算幾何或

            //拓拔方面的知識,網絡上有一個很好的庫ttl,里面有篇實現的論

            //文,關于gmap概念以及使用半邊結構進行各種拓拔查找以及修改,

            //絕對經典的東西
             MST_FLARE //
            實際上就是公告版,因該都會使用吧
            } mapSurfaceType_t;

            typedef struct {
             int   shaderNum;//
            索引指向shaderlump
             int   fogNum;//
            索引指向foglump
             int   surfaceType;// mapSurfaceType_t,
            具體說明見上

             int   firstVert;//索引指向drawVert_tlump
             int   numVerts;

             int   firstIndex;//索引指向頂點索引lump
             int   numIndexes;

            //下面一些變量和靜態lightmap相關,事實上現在的圖形硬件足夠快,靜態光照圖相關算

            //法已有沒落的趨勢,事實上現在比較先進的引擎都是全動態光照,通過BSP進行場景管理

            //可以非常高效的實現,使渲染效果大幅度提高。這部分是我最感興趣的部分,以后有機會

            //可以探討一下,但是必須要對BSP相關操作有非常的了解才可以深入

             int   lightmapNum;
             int   lightmapX, lightmapY;
             int   lightmapWidth, lightmapHeight;

             vec3_t          lightmapOrigin;
             vec3_t          lightmapVecs[3];   // for patches, [0] and [1] are lodbounds

            //下面兩個變量用于貝塞爾曲面

             int   patchWidth;
             int   patchHeight;
            } dsurface_t;//       lump13

            byte lightBytes; //        lump14

            byte lightgridData;//      lump15

            byte visBytes;//          lump16

             

            這里我列出bsp文件格式的各個lump,除了entity這個比較特別的lump,這個留到q3map再說,是比較特別一個東東。還有就是具體表面,bmodel以及著名的brush/side等之間的關系,以及shader各個元素還是下次再寫把,發現寫東西還真是很費腦子的拉,今天就先到這里了.

            posted on 2008-01-27 21:48 落魄江湖 閱讀(5482) 評論(7)  編輯 收藏 引用

            評論

            # re: QUAKE系列引擎以及基于QUAKE擴展引擎的源代碼全面分析(三) --bsp文件格式分析1 2008-01-28 15:33

            寫的很不錯,期待更核心的內容。
            提個建議:如果能從模塊的角度先分析Quake的大結構,我想更能讓別人好理解。
            我是學生,近來都一直在看Quake3 1.32b,雖然看不透,但還是學了不少東西。  回復  更多評論   

            # re: QUAKE系列引擎以及基于QUAKE擴展引擎的源代碼全面分析(三) --bsp文件格式分析1 2008-01-29 21:42 LOGOS

            今天的lump的介紹有點簡單,只是貼代碼,有種一筆帶過的感覺  回復  更多評論   

            # re: QUAKE系列引擎以及基于QUAKE擴展引擎的源代碼全面分析(三) --bsp文件格式分析1 2008-02-01 10:04 daids

            終于更新了啊  回復  更多評論   

            # re: QUAKE系列引擎以及基于QUAKE擴展引擎的源代碼全面分析(三) --bsp文件格式分析1 2008-03-05 17:20 lovebird

            為什么不按照當初自己設定的思路一步一步分析呢?  回復  更多評論   

            # re: QUAKE系列引擎以及基于QUAKE擴展引擎的源代碼全面分析(三) --bsp文件格式分析1 2008-04-04 17:11 stevevan

            支持你!期待更新  回復  更多評論   

            # re: QUAKE系列引擎以及基于QUAKE擴展引擎的源代碼全面分析(三) --bsp文件格式分析1 2008-04-14 16:40 dfsd


            [url=http://blog.0dfsdfo.cn]搜索引擎優化博客[/url]
              回復  更多評論   

            # re: QUAKE系列引擎以及基于QUAKE擴展引擎的源代碼全面分析(三) --bsp文件格式分析1 2008-08-05 00:03 aBC

            呵呵,終于寫不下去了吧  回復  更多評論   

            久久精品国产91久久麻豆自制 | 精品一区二区久久久久久久网站| 久久婷婷五月综合成人D啪| 亚洲精品无码久久久久去q| 久久国产高清字幕中文| 少妇久久久久久被弄到高潮| 伊人久久一区二区三区无码| 久久综合久久自在自线精品自| 国产亚洲综合久久系列| 亚洲第一永久AV网站久久精品男人的天堂AV | 国产精品9999久久久久| 久久精品国产清自在天天线| 国产亚洲精久久久久久无码77777 国产亚洲精品久久久久秋霞 | 久久婷婷是五月综合色狠狠| 久久精品天天中文字幕人妻| 波多野结衣久久一区二区| 热久久国产精品| 久久久无码精品亚洲日韩按摩| 久久综合亚洲色HEZYO国产| 久久综合狠狠色综合伊人| 久久免费的精品国产V∧| 久久综合色老色| 中文字幕精品久久| 欧美久久亚洲精品| 精品久久人人做人人爽综合| 亚洲国产天堂久久综合网站| 99久久婷婷免费国产综合精品| 日产精品久久久一区二区| 漂亮人妻被中出中文字幕久久 | 少妇久久久久久被弄高潮| 久久亚洲国产成人影院网站 | 亚洲精品蜜桃久久久久久| 理论片午午伦夜理片久久| 国内精品伊人久久久久影院对白 | 久久综合丁香激情久久| 久久精品成人免费看| 久久不射电影网| 国产免费福利体检区久久| 狠狠综合久久综合中文88| 久久亚洲2019中文字幕| 综合久久一区二区三区|