平民程序 - linghuye's blog

2005.3.22
1.开始制定开发计划
2.总结先前累计的若干基本功能模块.

2005.4.8
1.基本场景建立,4叉树+ROAM地形,多重纹理AlphaMap,物体模型分布,水面,天空.

2005.4.11
1.今天随便看了一下HL2分析的文章,觉得HL2的MaterialSystem非常好,非常对我的脾胃,决定采用.

2005.4.14
1.加入最简单的室内场景.
2.开始研究HL2的MateiaSystem,并移植入DestinyMatrix,当前的主要任务是建立MaterialSystem.

2005.5.3
1.这两个星期忙于现实工作,所以一直在思考引擎实现框架的设计问题,各大模块之间的责任和协作到底如何,思绪渺渺.

较之,HL2于大局架构把握上层次更高,游戏引擎/渲染系统(MaterialSystem)/底层渲染API实现(ShaderAPI),通观全局,层次分明,接口手法也很符合规范.但,HL2的具体实现实在够乱,接口的具体语义逻辑实在牵强,不够平民化,调用环节过多,我想它没能完成OpenGL的实现,也跟它在逻辑语义抽象上的局限性有关.特别她把渲染状态管理放在API实现层,有DX的实现,那Opengl怎么实现DXX的概念,可能是未完成的版本.相较其他引擎,明显的看出它作为商业级的产物,架构,编译速度,代码更符合现实程序实践.

OpenSceneGraph的在接口逻辑设计上比HL2清晰,Geometry,Material,StateSet的语义逻辑更明确,更灵活,具有极强的伸缩性,但它没有大局架构,没有API和总体层次间的隔离机制,我估计效率也不太好,几个Demo都很慢,而且是为VR设计的,而不是游戏.

Torque的结构实在是不敢恭维,网络,脚本,图形,场景管理代码一起堆,客户端和服务端代码一起堆,编辑器和引擎代码一起堆,是个高大全的产物,实际结果确实是高大全,直接就用脚本写服务器和客户端了.她的总体设计目标和思路都与其他引擎不同,她想直接用以别人作游戏.不过她的场景图的算法思路很好,网络实现也很强,效率不错.

Ogre号称面向对象,而我却以为是肤浅的面向对象,基本上没有接口语义概念,除了一堆的Singleton Manager就看不到其他设计模式了,依靠强制的C++技法来实现,如C++单体类,C++跨DLL继承等手法,在概念抽象上比较强硬,如Material就来个Techniche数组,Techniche就来个Pass数组,简单的用一个类包装一个观念,实际上没能很好地抽象出其中的关键逻辑.为了达到它可扩展的目的,连场景图算法都丢进去了,有必要吗?

2005.5.16
推翻原来的设计,采用HL2引擎的3层结构,借鉴OpenSceneGraph的操作手法,统一了渲染逻辑,为渲染状态的管理打下了基础.
接下来开始深入剖析渲染状态的表达,并增强渲染逻辑的广泛适用性.然后采用OpenSceneGraph的算法进行管理.

2005.5.17
开始编写场景图DmSceneGraph,渲染状态封装DmStateSet,以及场景图与渲染状态之间的树型关系维护,进一步统一IRenderCraft的接口.

2005.5.19
不切实际!如何将多种场景管理算法融合进一个SceneGraph呢?然后才是渲染状态排序实现.谁能告诉我是对还是错,只是命运的折磨不住地困扰着我,sigh.

1.glActiveTextureARB的Active不能理解为激活,使发生作用!!!
应理解为选择(Select)某纹理单元(Texture Unit),即表示后续的glEnable(GL_TEXTURE_2D);glBindTexture(GL_TEXTURE_2D, texture);作用于此所选的纹理单元.而glEnable(GL_TEXTURE_2D)才是真正激活纹理单元的调用.

glActiveTextureARB(GL_TEXTURE0_ARB);  // 选择TEXTURE0为设置目标
glEnable(GL_TEXTURE_2D);        // 激活TEXTURE0单元
glBindTexture(GL_TEXTURE_2D, texture); // 为TEXTURE0单元绑定texture纹理图像
 
glActiveTextureARB(GL_TEXTURE1_ARB);  // 选择TEXTURE1为设置目标
glDisable(GL_TEXTURE_2D);        // 关闭禁用TEXTURE1单元
 
glDrawArrays(GL_TRIANGLE_STRIP, 0, NUM_STRIP_VERTICE); // 由于TEXTURE1单元被关闭,执行此Pass渲染时只有TEXTURE0单元发生了作用。

如果,
glActiveTextureARB(GL_TEXTURE1_ARB);  // 选择TEXTURE1为设置目标
glEnable(GL_TEXTURE_2D);        // 激活TEXTURE1单元
glBindTexture(GL_TEXTURE_2D, alphaTex); // 为TEXTURE1单元绑定alphaTex纹理图像
此时由于有2个纹理单元被激活,glDrawArrays调用将Blend两个纹理单元形成最终的画面.

2.要设置纹理单元的纹理顶点数组,不能使用glActiveTextureARB,而应该使用glClientActiveTextureARB,如:
glClientActiveTextureARB(GL_TEXTURE0_ARB);
glTexCoordPointer(2, GL_FLOAT, 0, tp0);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);

3.使用多重纹理一般都必须激活glEnable(GL_BLEND);glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

4.关闭多重纹理:禁用所有非GL_TEXTURE0_ARB层纹理,最后激活GL_TEXTURE0_ARB纹理
glActiveTextureARB(GL_TEXTURE1_ARB);
glDisable(GL_TEXTURE_2D);
glActiveTextureARB(GL_TEXTURE0_ARB);
glEnable(GL_TEXTURE_2D);

5.特别需要小心的是:既不能在glActiveTextureARB状态下使用glTexCoordPointer设置当前纹理单元的纹理坐标数组指针,更不能在glClientActiveTextureARB状态下设置当前纹理单元的非Client属性,即此时调用的glEnable(GL_TEXTURE_2D);glBindTexture(GL_TEXTURE_2D, tex);均为无效操作.
glEnableClientState必须进入glClientActiveTextureARB状态后设置才对纹理单元有效,在外部所作设置修改不了纹理单元的设置.

Reference:
http://tfpsly.planet-d.net/english/3d/multitexturing.html

// 创建
glGenBuffersARB(1, &m_bufCoordsDetail);    // 创建硬件缓冲句柄.
glBindBufferARB(GL_ARRAY_BUFFER_ARB, m_bufCoordsDetail); // 选择当前要起作用的硬件缓冲.
glBufferDataARB(GL_ARRAY_BUFFER_ARB, sizeof(vec2_type) * BLOCK_HEIGHT_DATA_COUNT, m_coordsDetailTerrain, GL_STATIC_DRAW_ARB); // 为硬件缓冲赋予顶点数据

// 使用
glClientActiveTextureARB(GL_TEXTURE0_ARB);  // 选择TEXTURE0纹理单元
glEnableClientState(GL_TEXTURE_COORD_ARRAY);  // 激活纹理单元TEXTURE0的纹理顶点数组功能
glBindBufferARB(GL_ARRAY_BUFFER_ARB, m_bufCoordsDetail);// 选择当前起作用的硬件顶点缓冲
glTexCoordPointer(2, GL_FLOAT, 0, 0);   // 设置TEXTURE0纹理单元的纹理顶点数组为m_bufCoordsDetail所存储的顶点缓冲.

// 删除
glDeleteBuffersARB(1, &m_bufCoordsDetail);

// 关闭对当前顶点硬件缓冲的使用(如需要使用直接本地内存中的顶点数组).
glBindBufferARB(GL_ARRAY_BUFFER_ARB, 0);


References:
http://dev.gameres.com/Program/Visual/3D/vbo.htm

Ogre的Manager真是多啊,就象个官僚公司,干事的没几个,一堆的Manager,个个丫还都是Singleton.说自己是Singleton却又public构造函数,让人来new它.在第1次被new的时候,偷偷地将this赋给静态成员ms_Singleton,第2次new它就要assert喊冤了,当然这都是叫Singleton的模板基类的那个构造函数干的(典型的小人行径,见不得光).Manager一多,本来不复杂的事,也变得复杂了.

1.LogManager
a.全局单体LogManager组合Log指针Map集合,控制有多个Log对象,1个Log对象表达对一个Log文件的输入(老一套).
b.同时LogManager维护1个当前默认主事的Log对象mDefaultLog,以展现Log对象功能而隐藏自己实际是个Manager的身份(邀功自赏,其心可诛).
c.维护一个监控者接口LogListener列表,以履行作为一个Manager受外部监督的职责(实为推清责任).

2.DynLibManager
a.全局单体DynLibManager组合DynLib*指针Map集合,控制多个DynLib对象,1个Dynlib表达对动态库的装载和卸载(典型的官僚主义,人浮于事,这点屁事都要有Manager).

3.ResourceGroupManager
  a.全局单体ResourceGroupManager组合ResourceManager指针Map?Manager的Manager,靠,好大的官)
  b.一上任就安插了个亲信Manager,建立个叫General的ResourceManager.

4.SceneManagerEnumerator
  a.连它都是系统单体,一个迭代器,小人得志啊,不说了,它可管着一堆SceneManager,惹不起.
  b.一开始就安排了什么事都作不了的SceneManager(基类)作默认SceneManager,大事小事都是它,室内室外一手包.

5.一堆中层干部,一堆的MaterialManager,MeshManager,ParticleSystemManager,SkeletonManager......,都是Singleton,有的还是ResourceManager的门生,一开始都干了2件事.
a.定名分:向ResourceGroupManager注册说自己是某方面的Manager,_registerResourceManager.
b.要资源:向ResourceGroupManager要求控制对某种脚本的解析_registerScriptLoader(就是瓜分资源).
c.有个OverlayManager,ArchiveManager最牛,手下还有几个工厂给它干活,无非是自己作不了,又推给下级.

6.一堆插件外劳,开始加载,这些外劳到系统中来当然要注册.

7.透明实体mTransparentObjects按z序排序,不透明实体按material分组.

8.我一开始认为Materail是个很聪明的概念,后来才发现上当受骗了,它管理了mTechniques数组,而Techniche管理了mPasses数组(Multipass render),最后实质的内容在Pass类中,Pass类表达了一个渲染的环境.由于这个官僚系统实在太官僚,所以按对象每次渲染是不可接受的(跨部门合作太多,相互扯皮),渲染状态切换频繁,效率极低,透明渲染z序混乱.所以需要按Materail分组和z轴分序,而RenderSystem的最重要方法接受RenderOperation参数.

9.Pass和RenderOperation是两位最能干的劳动人民,都是受人管制的对象,整个系统的灵魂和核心,Pass封装了最重要的渲染状态(即进行glDrawXXX时管线所处的状态,着色系统),RenderOperation封装了带纹理几何渲染操作(glDrawElements几何系统),两者构成一个完整的渲染.即,先,调用SceneManager的setPass(在其中其仍将调用RenderSystem以设置管线状态),再,调用RenderSystem的_render.

10.SceneManager的虚方法_findVisibleObjects是场景管理的核心,由它将Renderable分组,分透明和不透明分送入不同的渲染队列,Renderable组合RenderOperation和Pass(但出头的都是Materail),然后SceneManager对之排序,整理,送入RenderSystem渲染.

11.SceneManager的_renderScene是基本渲染核心,它完成若干任务
   a.帧动画驱动_applySceneAnimations
   b.场景图更新_updateSceneGraph
   c.渲染队列更新,_findVisibleObjects更新主场景,_queueOverlaysForRendering更新上层主界面,_queueSkiesForRendering更新天空盒,最后_renderVisibleObjects.

12.渲染队列RenderQueue,维护std::map<RenderQueueGroupID, RenderQueueGroup*>对象,以表达其内部的多个方面(世界,前景,背景)的渲染分队列.RenderQueueGroup再往下分std::map<ushort, RenderPriorityGroup*, std::less<ushort> >,以表达其(如前景)内部按ushort优先级维护渲染分队列.RenderPriorityGroup维护一个mTransparentPasses,若干个SolidRenderablePassMap.

我的3D游戏引擎 DestinyMatrix,简称DM.

1.对3D基础的建立相对稳固，有了足够的数据和学习参考资料。

2.目前最重要的是场景图的建立,然后是光照特效系统。

3.由于整个体系太过庞大复杂，而且毫无经验，从头写一定失败不可行，应该画瓢照搬Ogre的体系和代码编写.

4.具体实现:Resource文件格式实现,UI界面系统，Script脚本系统，RenderSystem系统使用现有自己写好的一套。

5.骨骼动画,地形,纹理,BSP场景使用Blizz的数据格式。

6.特效，粒子系统先采用Ogre的实现。

This texture map is used for Rayne's head. One single texture map goes all the way around one
half of her head, from her nose to the middle of the back of her head. The artist has purposefully
designed the texture so that it can be "wrapped" around the model. The other half of her head is
mapped using the same texture, only it is mirrored for the other half.
Notice that the texture doesn't have to wrap "continuously" around the geometry in one piece.
Since each triangle can be mapped independently, different areas of the texture may be mapped
onto different portions of the model arbitrarily. For example, the "teeth" objects that you see in the
corners of the texture map are just that; Rayne has fangs, which can be seen when she opens her
mouth. Of course, if a "continuous" mapping is not used, the vertices will have to be duplicated at
the texture "seams" if the texture mapping coordinates are stored at the vertex level. (They usually
are.)
Notice that we have chosen to place the origin of texture mapping space in the upper left-hand
coordinate, which mimics the way the texture is accessed in hardware. More "academic" literature
places the origin in the lower left-hand coordinate.
As we have mentioned, each vertex is assigned a set of u,v coordinates in the texture map. In
this way, the texture is "pinned down" to the surface of the mesh. To render a pixel from the middle
of a triangle, we compute interpolated u,v mapping coordinates corresponding to the pixel (similar
to Gouraud shading) and then fetch the textel at these u,v coordinates.

1.每个物理实体有2个主要方面: 
    a.物理空间布局 (IVP_SurfaceManager and IVP_Compact_Surface)，即形状.
    b.物理性质:(IVP_Real_Object and IVP_Core),质量,摩擦系数,弹性等.

2.IVP_Compact_Surface描述物理基本的空间布局信息,
一个IVP_Compact_Surface可以被多个物理实体共享.
一个物理实体只能有一个IVP_Compact_Surface.

3.每个物理实体都有自己唯一的 IVP_Core,描述了自己的物理属性.

4.有两种基本的物体:多面体和球体.

5.Surface Managers只是抽象接口,定义多面体的布局信息,IVP_Compact_Surface_Polygon是它的一个针对IVP_Compact_Surfaces的实现,它还提供 IVP_Real_Object接口.

6.Compact Surfaces只是一段紧凑的内存块(所以它需要Surface Managers来描述它)

7.Compact Surfaces可定义凹凸的形状,它又由Ledge组成,一个Ledge描述构成空间形状的一个凸包（所以若物体本身即是凸体,则它只需由一个Ledge组成,若是凹体,则由多个凸包组成.

8.你可以用IVP_SurfaceBuilder_Ledge_Soup将多个Ledge组合成一个Compact Surfaces.

9.IVP物理引擎使用3种坐标系统
  a.物体自身坐标系统（同OpenGL系统)