IT博客-平民程序 - linghuye's blog-随笔分类-我的3D引擎－DestinyMatrix

glSwapBuffer阻塞的几点猜测

linghuye — Tue, 01 Jul 2008 01:22:00 GMT

1.当前理论帧率远大于60帧,但垂直同步被打开,SwapBuffer阻塞以保证垂直同步.这个是低级错误.
2.整个场景画面或画面中的一块的渲染像素层叠覆盖过多,像素填充率瓶颈.这个很少发生,在高端显卡上这一般不是瓶颈.
3.调用OpenGL废指令过多,造成命令缓冲庞大,glSwapBuffer等待指令完成.
4.在一轮Render中,对上百个GL_ELEMENT_ARRAY_BUFFER_ARB作glBufferSubData时,Nvidia显卡下出现,原因不确定,估计VBO的使用导致了的同步问题,替换为直接使用内存指针后正常.

Reference:
http://www.gamedev.net/community/forums/topic.asp?topic_id=306224&whichpage=1?
http://developer.apple.com/graphicsimaging/opengl/optimizingdata.html
http://www.gamedev.net/community/forums/topic.asp?topic_id=338336

linghuye 2008-07-01 09:22 发表评论

OpenGL/DirectX渲染技巧集

linghuye — Thu, 08 Feb 2007 12:01:00 GMT

1.树叶/动物嘴上的牙齿,胡须/身上的鬃毛,形状曲折复杂,若直接用三角形带构建会大大增加物体的三角形数,所以应使用少量的三角形加Alpha纹理来实现.过滤了Alpha的纹理可以描绘出曲折的形状边缘.
2.怪物眼睛发光,那是用了额外附着的不透明的纹理三角片,很可能还是billboard.
3.该GL_CULL_FACE的地方应该Cull Face,以提升效率.
4.BLEND_MODULATE_2X使盔甲呈现高亮, BLEND_ADDITIVE_ALPHA增加加物体细节.
5.WoW的登录界面就是个m2 + xml + lua,一个模型搞定一个界面.
6.在3D空间中画一个中间镂空的平面边形(由三角形Mesh拼接而成),纹理使用全黑,SrcBlend=ZERO,DstBlend=ONE,这样渲染后,在画面上完全没有起变化,但是DepthBuffer起变化了,画过的地方已经出现了深度值,人物走到这地方会出现被透明的墙挡住的效果.

linghuye 2007-02-08 20:01 发表评论

DrawIndexedPrimitiveUP这个函数

linghuye — Fri, 02 Feb 2007 16:07:00 GMT

最近被DrawIndexedPrimitiveUP这个函数搞崩了好几次,甚至连显卡的Blue Screen Of Death也出来凑热闹了,所以需要总结一下它崩溃的可能原因,理清下头绪:
1.与OpenGL的glXXXPointer一样,如果指针内存错误,崩溃是肯定的,这种bug比较好找.
DirectX的原因更复杂:
2.DrawIndexedPrimitiveUP不直接崩溃,而是在Present的时候崩溃.可能SetIndices的索引缓冲指针是野指针,LPDIRECT3DVERTEXDECLARATION9是野指针.

解决方法:使用Debug Runtime排除所有异常调用,这对显卡驱动程序蓝屏崩溃或异常现象的调试十分有效,如:
Direct3D9: Decl Validator: X249: (Element Error) (Decl Element [5]) Declaration can't map to fixed function FVF because blendweight must use D3DDECLTYPE_FLOAT1/2/3/4.
Direct3D9: (ERROR) :DrawIndexedPrimitive failed.

3.又发现一种DrawIndexedPrimitiveUP错误,当错误地把索引个数作为第2个参数传入(实际上第2个参数应该是顶点个数), 导致程序在运行一段不定时间,随机地,可能地,花屏了.此时DX8报告一个驱动程序的错误:
Direct3D8: (ERROR) :Driver not handled in DrawPrimitives2
Direct3D8: (ERROR) :Driver returned error: DDERR_INVALIDPARAMS
Direct3D8: (ERROR) :Driver failed command batch. Attempting to reset device state. The device may now be in an unstable state and the application may experience an access violation.

另:在试图安装现在的DirectX Debug Runtime时发现先前网上的资料或MSDN里都没谈到现在的安装方法:把Developer Runtime\x86里的dll复制到System32目录,然后再运行Utilities\Bin\x86\dxcpl.exe切换到Debug Rumtime模式.运行REF模式需要Debug Runtime环境!

Reference:
http://linghuye.googlepages.com/MyownlittleDirectXFAQ.mht

linghuye 2007-02-03 00:07 发表评论

MyWarCraftStudio 0.10.6337

linghuye — Sun, 28 Jan 2007 07:18:00 GMT

1.Update MyWarCraftStudio to 0.10.6337 for supporting Burning Crusade final formal client 2.0.6.6337.
2.It should be compatible with the normal 1.12 wow client.
3.I try to experiment DirectX rendering in this version. Change the Cnfg\MyWarCraftStudio.xml about to . Be aware of bugs.

http://www.cnitblog.com/Files/linghuye/MyWarCraftStudio_0.10.6337.rar
http://linghuye.googlepages.com/MyWarCraftStudio_0.10.6337.rar

linghuye 2007-01-28 15:18 发表评论

HLSL骨骼动画实现

linghuye — Mon, 22 Jan 2007 14:58:00 GMT

最近将我的DestinyMatrix图形接口用DirectX实现了一遍,过程中接口又进化了一次,现在可以像WoW一样选择使用那个API来渲染WoW的场景,觉得挺不错的.又用HLSL实现了一次骨骼动画:

struct VS_INPUT
{
    float3 position : POSITION;
    float2 texCoord    : TEXCOORD0;
    float4 weight     : BLENDWEIGHT;
    float4 bone        : BLENDINDICES;
};

struct VS_OUTPUT
{
    float4 position : POSITION;
    float2 texCoord : TEXCOORD0;
    float4 color     : COLOR;
};

uniform matrix modelViewProj;
uniform matrix boneMatrices[60];

void main(in VS_INPUT inVert, out VS_OUTPUT outVert)
{
    float4 blendVertex = float4(0.0f, 0.0f, 0.0f, 0.0f);
    float4 blendWeight = inVert.weight;
    int4 blendBone = int4(inVert.bone);

    for(int i = 0; i < 4; i++)
    {
        if(blendWeight.x > 0.0f)
        {
            blendVertex += mul(float4(inVert.position, 1.0f), boneMatrices[blendBone.x]) * blendWeight.x;
            blendBone = blendBone.yzwx;
            blendWeight = blendWeight.yzwx;
        }
    }

    outVert.position = mul(blendVertex, modelViewProj);
    outVert.texCoord = inVert.texCoord;
    outVert.color = float4(1.0, 1.0f, 1.0f, 1.0f);
}

对比HLSL和GLSL,
1.OpenGL里的顶点属性attribute在DirectX里是通过SetStreamSource设置进去,感觉OpenGL的顶点attribute的思想更灵活.
2.为了实现接口,DirectX使用了多流模式与OpenGL的glXXXPointer保持思想上的兼容.
3.GLSL和Cg的顶点计算是标准数学的mul(mat, v),而HLSL是mul(v, mat),我调试了很久才发现：(
4.HLSL的modelViewProj需要外部程序使用LPD3DXCONSTANTTABLE设置Matrix变量,而GLSL是内置的变量不需要外部传入.

linghuye 2007-01-22 22:58 发表评论

身处何乡

linghuye — Fri, 20 Oct 2006 13:25:00 GMT

基于Portal的引擎如何知道当前人物处于哪个sector是个难决的问题.用google搜索了一下论坛,有两种方案:
一种主张跟踪人物位置,给定一个起始sector,而后时刻检查人物是否穿过某个portal平面,一旦穿过则更新当前人物的sector位置变量.
一种主张实时计算,需要附加的对sector进行划分的bsp树数据进行计算.

在程序逻辑上,我比较倾向第2种,因为其逻辑概念比较清晰简单,但其需要额外的数据制作,wmo数据的BSP树是普通的leafy bsp,而非solid leafy bsp,似乎不足以判断一个点是否在BSP整体空间内,而且不能适应2个sector相嵌套的情形,WoW的城内的建筑portal摆放随意性很大,似乎没什么限制.

而判断人物穿过portal,感觉上逻辑比较模糊,脆弱,不稳定.当人物一直在portal边上左右徘徊时,算法是否够强壮?人物初始化时,又通过什么手段得知其初始sector呢?人物从城外进入城内的瞬间,又如何知道进入哪个sector?

WoW使用了哪一种呢?至少穿越portal这方案还可以实现出来,Crystal Space也是这么干的,可惜大部分的资料根本不提这一问题.

linghuye 2006-10-20 21:25 发表评论

程序启动内存分析报告

linghuye — Tue, 21 Mar 2006 05:50:00 GMT

1.DM游戏程序进程Windows环境初始后3.7兆,考虑到使用了众多底层的初始化,且libavcodec.dll体积较大,正常.
2.启动OpenGL环境后激增到10.9兆,消耗7M内存,比较大,尚能接受.
   ChoosePixelFormat: 耗费1.1M
   wglCreateContext: 耗费0.5M
   wglMakeCurrent:    耗费5.3M
3.lua脚本环境,脚本执行后消耗不到500K,cool!
4.载入一般格式纹理消耗68M内存,达到78.5M内存消耗,不能容忍,必须使用压缩格式.
   a.对支持GL_ARB_texture_compression的显卡采用纹理压缩,启动时间变得稍微延长,尚能接受.
   消耗内存骤减至17M,达到28M内存消耗.
   b.glTexSubImage作用于压缩纹理时,对子块纹理的大小也有强制要求,虽然不需要2的n次方,但需要是4的整数倍,否则在不支持NPOT显卡上会失败,INVALID_OPERATION.后来测试发现,各种显卡的这个能力都很不稳定,甚至导致程序崩溃,另外纹理载入时间较长,所以使用预压缩的纹理是最终的解决方案.
5.载入一个大小的字体消耗4M内存,到82.6,再载入一个大小字体又4M内存,达86.7M,不能容忍.FTGL的实现对中文支持的纹理内存消耗上有重大设计问题.
    a.修改FTGL对中文支持中的错误,把中文当英文处理,结果分配了4096*1024的大纹理,浪费啊,改为512*512,消耗骤减至256k.
6.音效系统和声音文件消耗4M内存,尚可.
    a.需要优化
7.最终程序30M内存消耗.

linghuye 2006-03-21 13:50 发表评论

暂停所有程序技术研究,专心研究如何哄女朋友开心.

linghuye — Mon, 13 Mar 2006 04:51:00 GMT

恋爱症候群 - 黃舒駿
曲︰黃舒駿
詞︰黃舒駿

关于恋爱症候群的发生原因
至今仍然是最大的一个谜
不管性别年龄职业体重学历长相和血型
没有一个人可以免疫
有些专家学者研究后相信
恋爱是内分泌失调所引起
却有别人认为恋爱属于过滤性簿
像感冒无药可救但会自动痊愈
不管你同不同意
自古到今许多例子证明
恋爱不但是一种病态
它还可能是一种变态

一般发病后的初期反应
会开始改变一些生活习性
洗澡洗得特别干净刷牙刷得特别用力
半夜里突然爬起来弹钢琴
有人每天站在阳台对路人傻笑
有人突然疯疯癫癫突然很安静
有人一脸痴呆对著镜子咬著指甲打喷嚏
有人对小狗骂三字经

女人突然改变发型
男人开始每天练著哑铃
食欲不振歇斯底里四肢萎缩神经过敏发抖
抽筋都出现在这时期
随著病情越来越变本加厉
人会变得格外敏感勇敢和恶心
写的唱的说的都像天才诗人一般才华洋溢
愈肉麻愈觉得有趣

有人恋爱之后每天躲在厕所哭泣
有人开记者会宣布恋爱的消息
有人总是喜欢两个人躲在黑漆漆的地方
像做了不可告人的事情
每天忙著找人算命
挖空心思改变自己配合对方的习性
把每天都当作记念日
把自己当作记念品

每天漫无目的腻在一起
言不及意也决得好有趣
走著坐著躺著趴著都行影不离
像是两人三脚又像连体婴
心里想的只有爱你爱你爱你爱你
也不管家里米缸有没有米
也不管路上有人示威抗议
只管爱你
心里想的只有爱你爱你爱你爱你
也不管海峡两岸统一问题
也不管埃塞俄比亚多少难民
只管爱你

经过一段轰轰烈烈热恋时期
不久就会开始渐渐痊愈
两人开始互相厌倦互相攻击对方缺点
所有甜言蜜语都随风而去
然后开始从错觉和误解中清醒
惊讶自己为何如此不聪明
为了爱情不管一切
不顾父母朋友姐妹兄弟
开始感到后悔不已
然后开始感到疲惫沉闷气喘心悸牙痛头痛梦呓
然后是精神不济瞳孔放大脾气暴躁四肢麻痹
终于受不了要分离

虽然结果颇令人伤心
了解之后也没什么了不起
爱情终究是握不住的云
只是我想要告诉你

哦...
在我落寞的岁月里
你的温柔解脱我的孤寂
带给我深深的狂喜
如此颤动著我的心灵
轻轻诉说爱你爱你爱你爱你
不管是黑夜或是黎明
不管是梦中或是清醒
深深爱你
我要对你说爱你爱你爱你爱你
不管是黑夜或是黎明
不管是梦中或是清醒
深深爱你
多么幸福
让我遇见你
呜...

linghuye 2006-03-13 12:51 发表评论

Metoolkit物理引擎研究

linghuye — Sat, 11 Mar 2006 14:44:00 GMT

最近数月一直受困于实现wow中人物碰撞反应的问题,试过多种解决方案而一直不能解决,所以结论是在根本思路上有问题.
一个完整的碰撞反应效果需要一个完整的物理引擎,一个完整的物理引擎如一个完整的图像渲染管线,不是我现在的能力所能到达的.
前面的碰撞检测库实际上不能达到商业级应用标准,技术上还是太小儿科,所以只能依靠现有商业级的物理引擎.
三大物理引擎Ipion,Metoolkit,Havok GDK, Havok收购了Ipion,所以相信Havok的引擎现在是最好的,XBOX都使用其SDK.
Ipion在Halflife2泄漏代码中有,Metoolkit也google的到文档,看来要推倒原有设计重来,从Metoolkit开始.

linghuye 2006-03-11 22:44 发表评论

无缝世界场景加载的解决方案研究

linghuye — Sat, 31 Dec 2005 03:44:00 GMT

1.每帧评估周围MapArea的可见度,对即将可见的区域送入预加载线程逻辑,对必须可见的区域送入即时加载模块.
2.必须加载2*2,进入3/4距离处开始预加载,退出1距离处卸载,保证最大加载量为3*3.

a.DX是有多线程支持,OpenGL渲染RC与线程相关,跨线程加载使用图形资源,如何解决?
b.遇到更复杂的逻辑时,如何处理.
c.是否要预加载全部,还是分Terrain,Model,Wmo加载.
But it is just a design question.

linghuye 2005-12-31 11:44 发表评论

3D人物模型在TriangleMesh环境中行走跳跃的碰撞行为反应

linghuye — Wed, 28 Dec 2005 09:08:00 GMT

How general games solve this question?So difficult.

ODE作的是刚体动力学,似乎不适合作解决方案.

1.The easiest way to handle a collision is to simply stop and not allow the move when a collision is detected. On the other hand - that is not how the professionals do is it? No, we want fancy collision response like sliding along the walls, automatically climbing stairs and automatically bumping over smaller obstacles on the ground.

2.The penetration depth of a pair of intersecting objects is the shortest vector over which one object needs to be translated in order to bring the pair in touching contact.

3.Responses are managed in response tables. To each object on which a response is defined in a response table a response class is assigned. Responses are defined per pair of response classes, rather than per pair of objects. So, the response for a pair of objects is the response defined for their respective response classes.

1.Move our sphere as close as possible to the triangle we’re colliding with.
Lets call this position for “newPosition”.

2. Calculate the sliding plane based on this new position.

3. Project the original velocity vector to the sliding plane to get a new
destination.

4.Make a new velocity vector by subtracting the polygon intersection
point from the new destination point.

5.Recursively call the entire collision detection routine with the new position
and the new velocity vector.

Reference:
http://www.peroxide.dk/download/tutorials/tut10/pxdtut10.html
http://www.win.tue.nl/~gino/solid/gdc2001depth.pdf
http://www.gamasutra.com/features/20000330/bobic_01.htm
http://people.netfarm.it/~guyver1/Didattica/RTM/Lezioni/Lezione6/CollisionDetection_file/frame.html#slide0067.html

linghuye 2005-12-28 17:08 发表评论

PolygonSoup碰撞检测学习笔记

linghuye — Mon, 26 Dec 2005 14:59:00 GMT

解决PolygonSoup碰撞检测的成熟方案是使用层次BV树,根据BV的不同衍生出:AABB,OBB,K-dop三种方案.
在内存使用上: AABB -> OBB -> K-dop递增.在效率上则尚无定论,根据具体的应用环境不同而不同.

Opcode: 开源,完全免费,采用AABB树构造,内存耗用很小,支持复杂模型,起初想使用它,但发现其,基本上没有文档,Sample,1.3版本接口变动巨大,且无文档,自2003年来再无更新,最致命的是不支持Instance transform的Scale,AABBCollider没有Transform支持,而且是在看代码时发现的,吐血.主要设计目标是少的内存耗用,但速度也很快.为ODE,Tokamak,Crystal Space所用.

RAPID: 开源,免费,采用OBB构造,内存耗用巨大,学院派设计,最倒霉的库,因为其他每个库都拿它作比较,都说比它快.

SOLID: GPL开源,商业软件,采用AABB树构造,2005.4月出3.5版本,效率不错,内存耗用中等,在后面4.0会支持AABB数据压缩,有文档,接口简单,代码清晰.支持复杂模型,支持Instance transform的Scale,甚至支持各向不等缩放,支持Penetration Depth计算,cool.作者Gino van den Bergen是3D碰撞研究专家,著有:Collision Detection in Interactive 3D Environments一书,有e版.逻辑顺畅地集成入DM,效果不错,满足使用要求.不过其IndexBuffer是unsigned int,Matrix是DX风格的,但代码很清晰,很容易定制.
SOLID有个严重的Bug,必须确保DT_GetCommonPoint,DT_GetPenDepth,DT_GetClosestPair在检测Complex和Convex对象时,第一个参数必须是Complex对象,否则崩溃.因为SOLID的double dispatch实现有问题,不完整,没有Convex + Complex顺序的对应函数.

QuickCD: 开源,免费,K-dop树构造.

ColDet,支持复杂模型,也不支持Instance Transform的Scale.

Reference:
http://www.codercorner.com/Opcode.htm
http://www.dtecta.com/
http://www.cs.unc.edu/~geom/OBB/OBBT.html
http://www.ams.sunysb.edu/~jklosow/quickcd/QuickCD.html
http://photoneffect.com/coldet/
http://www.merl.com/projects/vclip/
http://www.q12.org/ode/ode.html

void DmModel::SetBoundPolygonSoup(uint32 nPolygonSoupVertices, vec3_type* pVertices, uint32 nTrianglePrims, uint16* pTrianglePrims)
{
    ASSERT(m_hSolidShape == NULL);

    if(nTrianglePrims == 0) return;
    if(nPolygonSoupVertices == 0) return;

    // Save polygon soup data for collision test!
    m_pPolygonSoupVertices = new vec3_type[nPolygonSoupVertices];
    memcpy(m_pPolygonSoupVertices, pVertices, sizeof(vec3_type) * nPolygonSoupVertices);

    // Build
    DT_VertexBaseHandle hVertexBase = DT_NewVertexBase(m_pPolygonSoupVertices, 0);
    m_hSolidShape = DT_NewComplexShape(hVertexBase);
    m_hSolidVertexBase = hVertexBase;

    // Define mesh triangles
    for(uint32 i = 0; i < nTrianglePrims; i += 3)
    {
        DT_VertexIndices(3, pTrianglePrims + i);
    }

    // End it
    DT_EndComplexShape();
}

void DmModelInstanceNode::BuildPhysics()
{
    // Setup Phisic stuffs
    DT_ShapeHandle hShape = (DT_ShapeHandle)m_pRefModelInstance->m_pRefModel->m_hSolidShape;
    if(hShape)
    {
        DT_ObjectHandle hObject = DT_CreateObject(NULL, hShape);
        DM_SetMatrixf(hObject, m_matTransform);
        m_hSolidObject = hObject;
    }
}

void DmGameCreature::BuildPhysics()
{
    ASSERT(m_hSolidObject == NULL);

    vec3_type vMin, vMax;
    getBoundBox(vMin, vMax);
    DT_ShapeHandle hShape = DT_NewBox(vMax.x - vMin.x, vMax.y - vMin.y, vMax.z - vMin.z);
    DT_ObjectHandle hObject = DT_CreateObject(NULL, hShape);

    m_hSolidShape = hShape;
    m_hSolidObject = hObject;
}

bool DmModelInstanceNode::TestCollision(HANDLE hSolidObject)
{
    if(!m_hSolidObject) return false;

    DT_ObjectHandle hTestObject = (DT_ObjectHandle)hSolidObject;
    DT_ObjectHandle hThisObject = (DT_ObjectHandle)m_hSolidObject;

    DT_Vector3 v;
    return (DT_GetCommonPoint(hThisObject, hTestObject, v) != 0);
}

linghuye 2005-12-26 22:59 发表评论

Horizon Occlusion Culling

linghuye — Mon, 28 Nov 2005 16:31:00 GMT

NND,图形学怎么有这么多的算法!一个接着一个,没完没了.一堆的论文要看,越学越难,越学越无知.看着国外的好书只能流口水,怎么赶得上人家的水平啊,做人的差距,咋就这么大呐,灰心寽.

1. How to walk through the elements in the scene in front-to-back ordering?
2. How to representation for the visibility occlusion horizon?
3. How give out a simplified representation of scene objects to be used for calculating occlusions with the horizon, ie, to test if the element is under the horizon?
4. How to add the visible elements' affection into horizon line?

Reference:
http://rivit.cs.byu.edu//a3dg/publications/horizonCullingVISFinal.pdf
http://www.cs.tau.ac.il/~dcor/online_papers/papers/visibility-survey-ieee.pdf
游戏编程精粹4,P424,翻译的极烂(把实数译成真正的值),原作者的代码也烂,书中说的这个容易,那个容易,一到具体代码就不行了,到处hack,连视点从前到后遍历都不能保证.
http://www.cs.lth.se/home/Tomas_Akenine_Moller/pubs/i3d2001.pdf
http://graphics.stanford.edu/courses/cs248-05/real-time-programming/moller-cs248-01-lecture.pdf
http://www.cs.sun.ac.za/~henri/advgfx.html

12.23
终于把水平线裁减算法的Bug解决了,开贴纪念.
主要是原游戏编程精粹4的水平线算法代码有无数的Bug,Demo控制高空镜头有意地避开一些Bug,强烈鄙视.

linghuye 2005-11-29 00:31 发表评论

场景裁减方案估计

linghuye — Fri, 25 Nov 2005 09:06:00 GMT

0.使用天空球包围整个世界,使用雾限制可控远景.
1.地形裁减:
1.使用四叉树算法对MapArea->AreaChunk逐层进行相对镜头的可见性裁减.
2.在1过程中,对镜头内的地形进行水平线扫描剔除.
2.然后镜头裁减完的区域必然是连续区域,对此连续区域作ROAM算法下的LOD处理,近细远粗.
2.模型裁减:
1.基于上述地形四叉树裁减下作基本的每一个模型的裁减,实践测试结果表明收益大于测试成本.
2.距离裁减:以镜头为中心画圆,处于远景雾外的模型不作渲染,模型进雾后会逐步显示,这样不会有poping缺陷.
3.不采用模型LOD,数据制作过于复杂,控制复杂,加大内存需求,也有poping缺陷,优点不明显.
4.在地形水平线裁减中剔除物体.
3.进入BSP室内场景后的裁减.

linghuye 2005-11-25 17:06 发表评论

DestinyMatrix开发手扎.2700

linghuye — Thu, 29 Sep 2005 03:12:00 GMT

场景图系统使得引擎实体从管理层中分离出来,实体不参加管理层的运作,也不带管理的数据.
对一个物质实体而言,其不存在可见性这一属性数据,可见性是由管理层控制的,即物质实体是唯物主义,场景图是唯心主义.

场景图是个宽松的,随意的管理层,其任务是为各种各样的SceneNode保持最基本的层次关系,这个层次关系可以用来实现从上到下的空间变换,渲染状态的最小化切换.

从ISceneNode派生出各方面的SceneNode,表达对自己管理的场景的理解,即一个ISceneNode从概念上就是个小场景图,但其算法是单一的,如4叉,8叉,BSP等,从而实现一个大场景图中包含应用各种算法的小场景图.
而最上层的场景图是一种由人力控制,排序,维护的场景图,它的节点是泛用容器节点类型,基本概念是可以在编辑器中显式地创建一个容器式的节点,并为节点加载内容场景.
万事万物都可以纳入场景图,因为它的上层是宽松的逻辑概念.

10.4 完成基本场景图程序设计.
11.4 笑傲江湖马戏团 :)
11.08,终于一个雏形诞生了,真正基于场景图,渲染API层完全隔离,采用统一的Material+Mesh渲染抽象,渲染状态切换最小化,骨骼动画框架,仿WoW游戏镜头控制.
12.12 地形算法整合清理,整合原先写成的UI,脚本模块,整合wmo加载和渲染模块,完善重新思考引擎的Mesh概念,加入基本的Shader以支持复杂光照模型.基本地平线剔除代码.多次代码重构.

linghuye 2005-09-29 11:12 发表评论

DestinyMatrix 开发手扎

linghuye — Sat, 13 Aug 2005 09:39:00 GMT

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.

linghuye 2005-08-13 17:39 发表评论

DestinyMatrix

linghuye — Sat, 13 Aug 2005 09:27:00 GMT

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

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

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

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

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

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

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

linghuye 2005-08-13 17:27 发表评论

IT博客-平民程序 - linghuye's blog-随笔分类-我的3D引擎 －DestinyMatrix