一:一些废话
好久没更新了,一方面是年底了,对于做销售的人来说,利用这段时间出出差,拜访拜访经销商以及KA客户,目的是确定明年的销售指标,晕。另一个更重要的原因是竟然把密码忘记了,没办法进入我的博客。前天整理东西时候竟然发现写密码的那张纸了,内心狂喜,哈哈!!
本来想接上次的,写一些关于渲染器方面的东西,但是因为整个渲染器是依赖与BSP进行操作的,而且QUAKE中的碰撞检测也是依赖与BSP树的,因此先写一些关于BSP树方面的基础东西,以利于大家有个比较具体的印象,希望能够写的比较通俗易懂吧。
事实上,前天我写了将近500字的BSP编译器的分析的文章,发现好象如果直接写编译器这个核心东西,可能需要一些关于QUAKE的BSP的相关理论的和基础的东西,特别是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各个元素还是下次再写把,发现写东西还真是很费脑子的拉,今天就先到这里了.