IT博客-平民程序 - linghuye's blog-随笔分类-3D图形学研究

星际争霸2 Beta客户端资源分析

linghuye — Mon, 22 Feb 2010 14:35:00 GMT

星际争霸2 Beta测试开始了,下载下来,没有帐号玩不了,于是开始琢磨客户端资源.

又看到熟悉的MPQ打包文件,很顺利地打开Battle.net\Battle.net.MPQ.
里面是战网的界面资源,界面用的是Scaleform的gfx格式文件,在SWF目录下,显然StarCraft2采用了Scaleform的界面解决方案.接着用2.2版本的ScaleformSDK尝试打开,报告格式不兼容,失败.
配合Scaleform使用的是png格式的图像文件.
简体中文版的汉化文字已经做好了,在Battle.net.MPQ\i18n\zhCN\String\*.xml里面.

Mods目录下是主要的资源文件,除了MPQ出现了*.SC2Assets/*.SC2Data/*.SC2Locale文件.
其中*.SC2Locale是文本文件,直接用记事本打开.
*.SC2Assets/*.SC2Data用UltraEdit打开后,发现还是MPQ文件,于是直接加个.mpq后缀就用MyWarCraftStudio打开看到里面的内容了.
Core.SC2Mod\Base.SC2Data里有个Shaders目录,大量的.fx文件,嘿嘿,FX Shader! 比较眼熟的有HDR/DeferredLight/VSSkinning/VSShadow/PSShadow/PSSSAO/PSParallax/PSPostProcess等.嗯,那OpenGL也是用这些shader吗?
Core.SC2Mod\Base.SC2Data]\UI里是游戏界面,用的Flash文件,
有一些*.galaxy文件,不知道做什么用的.

Mods\Liberty.SC2Mod\base.SC2Assets是最大的打包文件,打开后发现大量的*.m3格式文件,这就是星际2的模型文件了.纹理这次直接使用的DDS文件,直接看.
另外还有一种与m3共存的m3h格式的文件,是xml格式的文本文件,记录了那些可以灵活配置的模型数据,比如Socket绑点.

Mods\Liberty.SC2Mod\Base.SC2Data里的GameData目录是游戏逻辑相关大量配置文件.

Support/Version目录下是一些dll,看出星际2用VS2005开发的,用fmod音效底层,icudt42.dll/icuin42.dll/icuuc42.dll不知道是什么库.baselineCache.bin有几十兆,好像是预编译好的shader文件.

打开SC2.exe文件,找到几个hkpXXX,那就是使用了Havok物理引擎了.

看来只要把m3和m3h格式搞清楚,再用里面的Fx Shader一渲染就差不多了.

linghuye 2010-02-22 22:35 发表评论

DX10残留的固定流水线的渲染状态备忘

linghuye — Sun, 29 Nov 2009 15:16:00 GMT

D3D10_BLEND_DESC -> CreateBlendState -> ID3D10BlendState
D3D10_DEPTH_STENCIL_DESC -> CreateDepthStencilState-> ID3D10DepthStencilState
D3D10_RASTERIZER_DESC -> CreateRasterizerState -> ID3D10RasterizerState

struct D3D10_BLEND_DESC
{
    BOOL AlphaToCoverageEnable;
    BOOL BlendEnable[8];
    D3D10_BLEND SrcBlend;
    D3D10_BLEND DestBlend;
    D3D10_BLEND_OP BlendOp;
    D3D10_BLEND SrcBlendAlpha;
    D3D10_BLEND DestBlendAlpha;
    D3D10_BLEND_OP BlendOpAlpha;
    UINT8 RenderTargetWriteMask[8];
};

struct D3D10_DEPTH_STENCIL_DESC
{
    BOOL DepthEnable;
    D3D10_DEPTH_WRITE_MASK DepthWriteMask;
    D3D10_COMPARISON_FUNC DepthFunc;
    BOOL StencilEnable;
    UINT8 StencilReadMask;
    UINT8 StencilWriteMask;
    D3D10_DEPTH_STENCILOP_DESC FrontFace;
    D3D10_DEPTH_STENCILOP_DESC BackFace;
};

struct D3D10_RASTERIZER_DESC
{
    D3D10_FILL_MODE FillMode;
    D3D10_CULL_MODE CullMode;
    BOOL FrontCounterClockwise;
    INT DepthBias;
    FLOAT DepthBiasClamp;
    FLOAT SlopeScaledDepthBias;
    BOOL DepthClipEnable;
    BOOL ScissorEnable;
    BOOL MultisampleEnable;
    BOOL AntialiasedLineEnable;
};

linghuye 2009-11-29 23:16 发表评论

阅读一款3D引擎的方法备忘

linghuye — Sun, 29 Nov 2009 14:15:00 GMT

要带着引擎系统所共有的问题去阅读,不要被具体引擎的实现思路牵着走,要思考这个引擎如何实现或绕过(如不考虑低端机)这些必然要面临的问题.

首先,最重要的必须,在Debug模式下调试起来一个主场景程序,然后沿着代码流走几遍,在代码里闲逛,生成第一印象,留意基础工具设施类(如字符串内存管理),大约3小时.
然后带着如下每一个问题(不分先后)去走流程,走逻辑,弄清引擎的业务处理方法.

1.SetStreamSource,SetIndices,DrawIndexedPrimitive的调用是在哪里(哪个cpp哪个类的哪个函数),整个工程有几个DrawIndexedPrimitve,DrawPrimitveUp,DrawXXX,被统一管理了吗,还是零零散散地分布在各个cpp各个类?

2.纹理资源是如何管理的?句柄,ID,指针? 按使用时间,按使用计数? 模型顶点资源是如何管理的,是否有Buffer分配上的优化(比如顶点缓冲整合)? 渲染的实例数据如何管理,如何与资源概念区分的? 纯3D资源如Shader/RenderTarget是如何管理的?

3.场景管理是怎样搭建的,如何包含区分节点实例数据和资源数据?镜头是如何被各模块访问的?剔除不可见物件的代码行在哪里?兼容各种算法吗,使用了具体的算法是什么?不论使用何种算法,场景管理模块是否提供了清晰的需求定义接口?

4.骨骼动画是在哪里计算的,具体到顶点乘以矩阵是在哪个cpp的哪个代码行里?Socket实现在哪里?如果有高级动画系统,骨架在哪里,有什么功能?动作融合的矩阵间过渡代码在哪一行?

5.异步数据加载是怎样做的,在哪个cpp里,由哪个模块管理?各个资源的加载读取cpp代码行在哪里?

6.渲染管线如何为ShadowMap提供深度图,如何为CubeMap,水面反射提供场景RenderTarget?如何管理固定流水线状态RasterState的?

7.材质管理系统是如何运作的(通常都是technique + multipass),如何并入管线的,如何从理论上保证可以实现各式各样的效果的?如何抽象兼容固定和可编程流水线的? 如果是抽象管理的,如何抽象掉不同的technique下的不同的数据?管线里是否有独立的后期效果,还是用材质表达出来?材质是否可以脚本化?材质是要分组的,排序的代码段在哪个cpp的哪里?

8.特效如粒子系统到最后是使用哪个DrawXXX画出来的? 粒子系统是动态公式计算(不要理会具体公式)还是帧动画?

9.界面2D Texture Draw是如何被支持的?文字渲染是如何被支持的,特别是如何支持中文的,字体资源如何被管理?是否使用Freetype,是否支持东亚文字?

10.物理系统的接口是如何定义引擎的需求的?或者就是乱糟糟地直接用上.

linghuye 2009-11-29 22:15 发表评论

高斯模糊备忘

linghuye — Sat, 04 Jul 2009 07:58:00 GMT

http://theinstructionlimit.com/?p=14
这篇对高斯模糊的基本数学原理和实际实现讲解得非常清楚,应该算是对高斯模糊讲解最好的文章了.

linghuye 2009-07-04 15:58 发表评论

解决颠倒成像过程中遇到的几个问题

linghuye — Tue, 30 Jun 2009 13:19:00 GMT

如何上下颠倒一个场景的成像?
我的第一个念头是想把镜头上下颠倒(Up向量取负)即可,后来想想不对,镜头上下颠倒后,世界也左右颠倒了.
然后想可以在投影矩阵上搞鬼,因为经过正常投影矩阵作用后的顶点的y值分布在[-1,1]之间,所以对y取负,就可以使画面颠倒呈现(而且对上层毫无影响).如果使用可编程流水线,只要在VertexShader里将输出的gl_Position的y值取负即可.如果使用固定流水线,需要将正常的投影矩阵左乘(DX是右乘)一个Scale(1.0f, -1.0f, 1.0)矩阵即可,也可以直接将正常投影矩阵的第2行(DX是第2列)取负.
实作后,果然画面正确地上下颠倒了.但是发现,从VS到PS的法线的插值结果不对了,图像化PS中的法线值后呈现的颜色和无颠倒的图像颜色完全不同,似乎前后颠倒了,如下:
void main()
{
   gl_Position = ftransform();
   gl_Position.y = -gl_Position.y;

    // 将顶点法线传入PS
    gl_TexCoord[0] = vec4(gl_Normal, 1.0);
}
void main()
{
    // 将法线值显示出来
    gl_FragData[0] = gl_TexCoord[0];
}
根据Perspective-Correct Interpolation的数学原理,深度值倒数是线性插值的,而从VS到PS的数值是根据深度值倒数做的插值:

研究公式后,觉得y值取负理应不会影响到z值的正确计算,z值不变,整个插值的结果应该是不变的,茫然不知所以.
今天突然想到,y值取负后,所有三角形成像颠倒了,三角形的顶点顺序也逆反了,原来逆时针的变成了顺时针,影响了GL_CULL_FACE,输出的画面会呈现前后颠倒的假象,实作下果然如此,修改了CULL_MODE后,终于得到想要的画面了.

其实,我想说,搞图形学,你不懂数学原理能行吗?

Reference:
Mathematics for 3D Game Programming and Computer Graphics

linghuye 2009-06-30 21:19 发表评论

glOrtho矩阵的问题

linghuye — Sun, 28 Jun 2009 04:21:00 GMT

1.MSDN中给出的glOrtho矩阵数学表达式是不符合实践的,是误导的.

2.很多网站上的glOrtho数学表达式是错误的,查资料时要注意.

3.正确的表达式应该是 http://www.opengl.org/sdk/docs/man/xhtml/glOrtho.xml

4.注意在传入参数时,far/near是正数,但实际的含义是指-far,-near,因为OpenGL是右手坐标系,镜头空间的+Z指向观察者,-Z才指向世界深处.

linghuye 2009-06-28 12:21 发表评论

Galaxy Texture Demo

linghuye — Tue, 14 Apr 2009 15:00:00 GMT

Pixel Shader实现Galaxy效果,ShaderX2中使用cg实现.此Demo使用glsl和hlsl实现.
http://www.cnitblog.com/Files/linghuye/GalaxyTexture.rar

按Enter键切换galaxy模式,按小键盘数字键切换变换速度.

References:
ShaderX2: Galaxy Texture

linghuye 2009-04-14 23:00 发表评论

向量在另一个向量上的投影

linghuye — Thu, 19 Mar 2009 06:16:00 GMT

若v向量为单位向量,则结果为 uv向量的点积 * v向量.
即: 某个方向力u, 在v方向上的分量.

为备忘转载自: http://www.cnblogs.com/wswqwps/archive/2008/10/25/1319349.html

linghuye 2009-03-19 14:16 发表评论

图像边缘检测Demo

linghuye — Sun, 08 Feb 2009 08:27:00 GMT

DestinyMatrix底层实现下的图像边缘检测shader. OpenGL&DirectX实现.
Shader源码改编于 Advanced Image Processing with DirectX 9 Pixel Shaders

http://www.cnitblog.com/Files/linghuye/EdgeDetection.rar
http://www.cnitblog.com/Files/linghuye/RobertsCross.rar

linghuye 2009-02-08 16:27 发表评论

ScaleformDemo

linghuye — Tue, 03 Feb 2009 13:01:00 GMT

实验整合Scaleform与我的DestinyMatrix引擎,写的Demo,仅作测试.
http://www.cnitblog.com/Files/linghuye/ScaleformDemo2.rar

linghuye 2009-02-03 21:01 发表评论

GL_ALPHA/GL_LUMINANCE/GL_INTENSITY之差别

linghuye — Sat, 23 Aug 2008 10:35:00 GMT

The difference between the three single-component texture formats, GL_ALPHA, GL_LUMINANCE and GL_INTENSITY, is in the way the four-component RGBA color vector is generated. If the value for a given texel is X, then the RGBA color vector generated is:

    * GL_ALPHA: RGBA = (0, 0, 0, X)

    * GL_LUMINANCE: RGBA = (X, X, X, 1)

    * GL_INTENSITY: RGBA = (X, X, X, X)

In other words, if we interpret the alpha as transparency, GL_ALPHA would represent a completely black texture with varying transparency, GL_LUMINANCE is an opaque texture with varying color (a grayscale image), and GL_INTENSITY is a combination where both the color and alpha channel is varying.

一个很隐晦的错误:
glTexImage2D(GL_TEXTURE_2D, 0, GL_ALPHA, nWidth, nHeight, 0, GL_ALPHA, GL_UNSIGNED_BYTE, data);
可以确定当前2D纹理是有效的,data图像数据是正确的,但最终得到的纹理显示出来的图像竟然是错误的?
查出之前有一个glPixelStorei是错误根源, 当前的GL_PACK_ALIGNMENT,GL_UNPACK_ALIGNMENT,GL_UNPACK_ROW_LENGTH值会影响外部data最终到达纹理的方式,特别是GL_UNPACK_ROW_LENGTH!!!

Reference:
http://www.gamedev.net/community/forums/topic.asp?topic_id=307568

linghuye 2008-08-23 18:35 发表评论

OpenGL3.0标准发布

linghuye — Thu, 14 Aug 2008 14:12:00 GMT

等了这么久,OpenGL3.0标准终于发布了.还没仔细看spec,据Gamedev上的反应说,OpenGL3.0没有如之前承诺的基于对象概念重写接口,而仍只是常规的添加新函数功能而已.

"开发者社区对此非常愤怒，认为OpenGL3.0其实是OpenGL2.2，许多开发者表示要迁移到DX10上。"

OpenGL在Windows平台上的游戏开发是越来越式微了.我想过去,只有两种游戏开发商会用OpenGL,一是Carmack这种超级大牛人,二是暴雪这种要通吃苹果操作系统的开发商.
对于我这种小程序员,也就写写工具,做做Demo用的着,并且有希望在手机平台上搞搞OpenGL.嘿嘿,幸亏为了养家糊口,我对很有钱途的DirectX也很熟.上班我用DirectX,下班我搞OpenGL,并且到现在还没有人格分裂.我享受着OpenGL给我的自由(我不用强迫装Vista系统就能试验只有DX10才有的功能),同时又能用DirectX赚着钞票,这是理想和现实完美结合的典范.
其实,我想说的是,我对OpenGL很失望.

补: 把文档看了一遍,果然,就是加了很多新功能,OpenGL3.0依然100%兼容旧代码,不需要如之前传闻的说接口升级.只是额外加了个Deprecation Model,就是创建一个只向前兼容的OpenGL context,在这个Context下,一些老旧的接口被废弃了.这个完完全全是个商业妥协的过渡式的解决方案.

标准文档:
www.khronos.org/opengl

linghuye 2008-08-14 22:12 发表评论

WoW Physics in Havok

linghuye — Wed, 06 Aug 2008 14:00:00 GMT

1.这是魔兽世界莫高雷在Havok物理世界调试器中的建模,使用的是魔兽的地形高度图数据和模型物理PolygonSoup数据,黄色胶囊表示运动的人物.
2.物理引擎有个大问题,难以稳定,一个数值的错误很可能导致整个物理世界的崩溃.按持续性物理的原则,帧率的变化会影响物理世界的稳定,我相信这对游戏程序调试会造成很大的困难.
3.在图中规模的世界场景中,实际场景渲染时,Havok引擎在我的E6300 Intel双核CPU上运作十分地流畅,几乎没有没有降低原来的渲染帧率.当然MMORPG的碰撞规模是非常少的,仅仅是人物对世界静态场景的碰撞,至多推几个箱子而已,但是要求的碰撞和碰撞反应逻辑是非常高的,不能是小儿科的,没有实用价值的,拿几个箱子啊,圆球啊,凸面体等的演示,只有像魔兽世界这样完全不规则的模型才测试得出一个物理引擎的效率和稳定性.
4.Havok支持物理模型的Scale,Phyx目前没有这个非常关键的特性.
5.我个人认为,总的说来,当前,不管Havok还是Phyx在都不是一般的难用(至少不如图形API简易好用).对这些基于动力学的物理引擎而言,他们过于死板,过于遵守物理定律，过于霸道.当我需要一些不符合物理学的运动和物体时(比如瞬间改变物体的速度,改变人物在跳跃时的空中轨迹),要绕过或骗过引擎是非常困难的,这通常使引擎变得不稳定.其实我需要实现的不过是人物行走在全3D环境中而已,我要的不是真实的物理世界,而在Havok引擎里实现这么简单的东西需要绕很多弯,基本上要把整个物理引擎的每个概念都要学过一遍,这是物理引擎不成熟的表现.
6.另外,Havok的Demo框架完全是Havok写Demo的程序员偷懒的结果,因为有框架,他们可以简易地写出多个Demo逻辑,但我不需要他们的这些繁杂甚至实现诡异的Demo框架,我不希望去理解这些自以为精妙的框架.因为实际应用中我有我的框架,公司有公司的框架,没有人会为了一个物理引擎去把自己的框架都换掉.程序框架更多程度上是一种卖弄似的垃圾. 我需要简单的独立的Demo,不要基于任何其他第3方的东西,能够让我迅速理解调用运作流程和每个API的简单作用.而Havok的文档完全是程序员在写代码时的注释,不够详细,缺少很多必要的说明.所以在遇到问题时,不要指望文档,唯一的方法是去看复杂的Demo的代码,去猜Demo的代码到底是什么意思,去对比自己的实现哪里跟Demo程序不符.
7.目前,我个人的实践感受上,Havok要比Phyx好得多。Phyx有几个我非常讨厌的限制,PolygonSoup数据需要被预处理(Cooked),不支持Scale变换,CharacterController不够灵活.

Reference:
http://softwarecommunity.intel.com/isn/Community/en-US/forums/2508/ShowForum.aspx

linghuye 2008-08-06 22:00 发表评论

Havok物理引擎学习笔记

linghuye — Sat, 02 Aug 2008 03:27:00 GMT

1.Every Havok simulation can have one or more Havok worlds - instances of the class hkpWorld. The hkpWorld acts as a container for the physical objects in your simulation, and is also used to step the simulation forward in time.

2.当前Havok5.5版本,因为需要对应的Debug版本的动态运行库的manifest,当前Havok5.5版本必须使用Vs2005 SP1编译,否则无法运行Debug版调试.

3.HavokVisualDebugger是个非常非常好的调试工具,我们只要在自己的代码中调用Havok API构建抽象的物理世界,抽象的物体,即给出物理世界的数据,就能直接通过hkVisualDebugger接口的socket连接发送世界数据到HavokVisualDebugger宿主程序,并在其可视化物理场景视图中显示出来.在我的实践过程中,它可视化出了WoW的物理场景,让我方便清晰地看到传给Havok的数据是否确实反映到了物理世界中,在调用API时物体是否按我的意愿运行,结果是否正常.而且HavokVisualDebugger可以可视化地看到Havok的物理概念体,使抽象的概念体现到视图.Phyx引擎如果没有这种调试工具,是比不上Havok的.

11.工具里的FitCameraToWorld,好用.

4.hkpWorldObject -> hkpEntity -> hkpRigidBody

5.If you create an hkpRigidBody as fixed or keyframed you cannot make it dynamic later during the simulation (using hkpRigidBody::setMotionType() ), but you can make a dynamic hkpRigidBody fixed or keyframed during simulation and switch back.

6.A keyframed object is treated by the simulation as if it had infinite mass - however, unlike a fixed object, you can move a keyframed object around, if you set a velocity for it, it will move at that velocity. To turn a movable object into a keyframed object, you call its setMotionType(hkpMotion::MotionType) method, setting the value to hkpMotion::MOTION_KEYFRAMED.

7.stepDeltaTime()不能传0.0,否则崩溃.

8.Phantom的概念: An hkpPhantom has no physical presence in the simulation and is used to maintain a list of entities (and other phantoms) that overlap with it. The most common application of an hkpPhantom is to detect entities entering and leaving certain volumes of the hkpWorld, perhaps causing a scripted cinematic sequence to be played or a nearby AI character to be alerted to your presence.

9.物理引擎碰撞检测都有Broadphase和Narrowphase概念(如Phyx,SOLID),而Havok也是如此.即碰撞检测分2个阶段,第1个阶段是快速的世界物体AABB式检测,使用扫描线算法快速排除在AABB上不相交的物体,得出可能相交的物体对,然后送入Narrowphase阶段.

10.While Havok is a continuous physics engine, the character controller is effectively discrete in its simulation approach. Although this is fast, and means that characters can be stepped independently of the physics engine, and at lower frequencies, this can also lead to some accuracy problems.

11.You can use filters to disable or enable collisions between objects. If collisions are disabled between two objects, no collision agents are created for the pair, and they can move into or through each other.

linghuye 2008-08-02 11:27 发表评论

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 calls that may incur glFinish

linghuye — Wed, 19 Mar 2008 02:37:00 GMT

1.SwapBuffers, glGetXXX.
2.当前绑定了GL_ELEMENT_ARRAY_BUFFER_ARB,调用glDrawArrays后导致glFinish,妈的,这显卡驱动是什么逻辑.
3.使用了Fraps测试帧数,导致SwapBuffers调用glFinish.
4.OpenGL中判断使用glCullFace(GL_FRONT_AND_BACK), glEnable(GL_CULL_FACE)时帧率是否变化,可以断定是否存在像素填充率问题.

linghuye 2008-03-19 10:37 发表评论

Geometry Instance

linghuye — Mon, 17 Mar 2008 13:11:00 GMT

DirectX9.0C直接支持Geometry Instance,通过D3DDECLUSAGE_TEXCOORD多层纹理坐标流,将Instance Data数据传送到GPU,技巧在于:
pd3dDevice->SetStreamSourceFreq(0, (D3DSTREAMSOURCE_INDEXEDDATA | g_numInstancesToDraw));
pd3dDevice->SetStreamSource(0, g_VB_Geometry, 0, D3DXGetDeclVertexSize(g_VBDecl_Geometry, 0));

pd3dDevice->SetStreamSourceFreq(1, (D3DSTREAMSOURCE_INSTANCEDATA | 1));
pd3dDevice->SetStreamSource(1, g_VB_InstanceData, 0, D3DXGetDeclVertexSize( g_VBDecl_InstanceData, 1));

Stream1中的顶点数据,每g_numInstancesToDraw个顶点处理后递进一个,相当于每Instance递进一次.在HLSL中将Stream1中的数据流还原出来.

OpenGL当前不直接支持Geometry Instance,但是注意到
1.OpenGL的glDrawElements簇函数的消耗比DX的DrawIndexedPrimitives小得多.
2.OpenGL有一项DirectX所没有的能力,设置当前全局顶点数据,如glColor3f,glTexCoord,glMultiTexCoord,而且此类函数的单个调用在Driver和hardware上的消耗都极小,所以可以用glMultiTexCoord传递顶点数据到shader,而不是使用glUniformMatrix4fvARB或glLoadMatrix传递变换矩阵,此类设置GPU寄存器的函数,或者说是改变Vertex shader当前的全局处理状态的函数,很显然将等待当前GPU正在执行的Vertex process完成后才能返回,CPU将等待GPU.

The technique does not scale well to complex mesh rendering techniques like skinning; there
are not enough vertex attributes to store all of the bone transforms for each instance.
但,无论Directx9.0c或OpenGL2.1都无法传递几十个骨骼矩阵这么庞大的顶点数据单位格式(注意是一个顶点数据单位格式,OpenGL没有那么多层的glMultiTexCoord, DirectX没有那么大的顶点声明能容纳几十个矩阵),所以都无法完成带骨骼动画的Geometry Instance,只能是静态物体,或使用CPU作骨骼计算. DX10好像可以,没有显卡,没实践过.

CPU和GPU是并行结构,若使得两者完全并行运行,效率将最大化.若一方为了线性逻辑而不得不去等待另一方,效率将降低,这就好像两个线程间需要同步的数据或逻辑越多,效率就越低下.

Reference:
http://developer.download.nvidia.com/SDK/9.5/Samples/DEMOS/Direct3D9/src/HLSL_Instancing/docs/HLSL_Instancing.pdf
http://developer.download.nvidia.com/SDK/9.5/Samples/DEMOS/OpenGL/src/glsl_pseudo_instancing/docs/glsl_pseudo_instancing.pdf

linghuye 2008-03-17 21:11 发表评论

多人骨骼动画测试用例及多线程显卡驱动程序下的优化问题

linghuye — Tue, 11 Mar 2008 14:04:00 GMT

测试1. 渲染1008个Wow的Cat动画模型,每个Cat有346个面,28根骨骼,只需1次Batch.

	OpenGL	DirectX
P4 2.8G Geforce7950GT	36	30
Core2 1.8G ATI1650XT	33	40
AMD64 1.8G Geforce6150	19	11

测试2 渲染175个Wow的Orc动画模型,每个Orc有1260个面,53根骨骼,需要分10次Batch,但使用同一个顶点Buffer,顶点数 2728 , 面数分别为 726, 22, 8, 66, 16, 13, 116, 34, 114, 142. 兽人模型体现了真实的游戏需求, Cat模型过于理想化.

	OpenGL	DirectX
P4 2.8G Geforce7950GT	27	30
Core2 1.8G ATI650XT	36	56
AMD64 1.8G Geforce6150	23	16.5

/**********************************************************************************************
1.HLSL下1008个cat的例子,使用float3x4 M*V比float4x3 V * M 慢2帧.
2.矩阵从4x4改为4x3后,帧率只提高了1帧,可能GPU不是瓶颈,传送4x4和传送4x3矩阵到寄存器效率相差不多.
3.OpenGL的实现在7950GT下目前有严重问题,竟然比DX低了8-10帧,WHY! 在N卡上OpenGL实现绝对要比DirectX快, 查SwapBuffers不明消耗15ms,未决! TNND,原来是Fraps对OpenGL测帧不准,反而拖慢了SwapBuffers,实际测试后OpenGL比DirectX高出6,7帧,这才正常.
4.ATI显卡对OpenGL支持得差是出名的, 在ATI显卡上DirectX比OpenGL快很正常,OpenGL主要慢在Shader计算上,而且其GLSL的代码和HLSL一模一样, M$和ATI有黑幕.
5.对兽人渲染排序材质后,DirectX提高2帧,OpenGL不变.
6.使用GPUPerfStudio在ATI 1650下做测试,发现OpenGL实现时呈现GPU瓶颈,而DirectX实现时呈现CPU瓶颈. 两者的逻辑层实现是统一的,OpenGL的GPU瓶颈在Vertex processing上,但是简化Skin Vertex Shader处理后未见效率提升,似乎瓶颈不是在Vertex shader上.这样只可能在顶点数量上,但顶点数仅有308,且DirectX模式一样的顶点却高出10帧,OpenGL下Vertex cache有问题,或者每次渲染都传送更新了顶点流?VBO有问题?未决!
7.优化了数次后,没有达到预期目标,感觉相当沮丧.
**********************************************************************************************/

http://linghuye.googlepages.com/RenderCraftPerf.7z

References:
http://developer.nvidia.com/object/multi-thread-gdc-2006.html
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=235486#Post235486
http://ati.amd.com/developer/gdc/PerformanceTuning.pdf

linghuye 2008-03-11 22:04 发表评论

Displacement Map Demo

linghuye — Wed, 05 Mar 2008 11:59:00 GMT

Displace map demo, OpenGL和DirectX实现, 基于Vertex texture fetch.

1.Displacement Map用到的主要技巧是Vertex Texture Fetch.
2.ATI不支持Vertex Texture Fetch,所以只能用NVidia显卡跑此Demo.
3.Vertex Texture Fetch确实很慢,至少目前不适用.

http://www.cnitblog.com/Files/linghuye/DisplaceMapDemo.rar

linghuye 2008-03-05 19:59 发表评论

HDR Demo

linghuye — Fri, 29 Feb 2008 15:31:00 GMT

HDR Demo,测试RenderCraft,有OpenGL和DirectX实现.

Ported from the HDR demo in .

http://linghuye.googlepages.com/HDR.7z

linghuye 2008-02-29 23:31 发表评论

优化!优化!优化!

linghuye — Sun, 24 Feb 2008 13:03:00 GMT

原则
1.以目前计算机的发展阶段而言, 游戏总是CPU Limited.
2.渲染 Batch, Batch, Batch
3.尽力减少图形API调用次数.
4.Minimize data swithing, such as SetStreamSource and SetIndices. Maximize FVF sharing.

认识:
1.DX API消耗Top5: SetPixelShaderConstant() SetPixeShader() SetVertexShaderConstant() SetVertexShader() SetTexture()

经验:
1. 过大过多的纹理造成带宽瓶颈,而顶点数据流量一般不足以产生瓶颈.
2.25k batches/s @ 100% 1GHz CPU, 即在PentiumD 2.8G上,令CPU满负荷运转,要保持30FPS,每帧只能渲染25000 * 2.8 / 30 = 2333个batch.经我测试,这只是在最理想状态下,渲染每个大于1000面的静态物体时的数据. 但若渲染的是小于大约130个面的静态物体,可渲染的batch比这高很多,大约2倍左右甚至更高,此时据文档说是CPU在负责计算顶点. 然后,如果渲染的是生物,按GPU计算骨骼运动的标准,最耗的是CPU骨骼层次矩阵计算和SetVertexShaderConst函数,两者都直接和骨骼数量成正比,即骨骼越多可渲染的batch越少.
3.对MMORPG游戏而言,瓶颈总是在CPU上,总是在骨架动作计算和渲染提交Batch次数上.

25k batches/s @ 100% 1GHz CPU

References:
http://ati.amd.com/developer/gdc/2006/GDC06-Advanced_D3D_Tutorial_Day-Huddy-Optimization.pdf
http://developer.download.nvidia.com/GPU_Programming_Guide/GPU_Programming_Guide.pdf
http://developer.nvidia.com/docs/IO/8230/BatchBatchBatch.ppt
http://download.nvidia.com/developer/presentations/GDC_2004/Dx9Optimization.pdf
http://developer.nvidia.com/object/gdc_d3dperf.html

linghuye 2008-02-24 21:03 发表评论

Render To Vertex Buffer理解和使用

linghuye — Tue, 05 Feb 2008 02:42:00 GMT

It simply adds two new targets to which buffer objects can be bound: GL_PIXEL_PACK_BUFFER and GL_PIXEL_UNPACK_BUFFER. When a buffer object is bound to the GL_PIXEL_PACK_BUFFER target, commands such as glReadPixels pack (write) their data into a buffer object. When a buffer object is bound to the GL_PIXEL_UNPACK_BUFFER target, commands such as glDrawPixels and glTexImage2D unpack (read) their data from a buffer object.

A buffer initially filled with vertex data can be bound to one of the pixel buffer targets and used for pixel operations and vice versa. You would render an image using some shader and read back the data from the color buffer into a PBO using glReadPixels(), and the use this buffer as a source for vertex data.

Reference:
More OpenGL Game Programming

linghuye 2008-02-05 10:42 发表评论

Deferred Shader Demo

linghuye — Sun, 03 Feb 2008 14:37:00 GMT

Deferred Shader测试,OpenGL & DirectX兼容实现,在Geforce6150上仍有问题.

实现注意点:
1.Nvidia的GL_NV_float_buffer扩展,使用GL_FLOAT_RGBA32_NV格式创建浮点纹理,必须配合GL_TEXTURE_RECTANGLE_NV纹理目标,不能使用GL_TEXTURE_2D纹理目标.

2.ATI的GL_ATI_texture_float扩展,使用GL_RGBA_FLOAT32_ATI格式创建浮点纹理,没有上述限制,只需使用一般的GL_TEXTURE_2D目标.

3.幸运的是Nvidia支持ATI的GL_ATI_texture_float扩展,然后发现还有个GL_RGBA32F_ARB == GL_RGBA_FLOAT32_ATI,所以正确的兼容的方案应该使用GL_ARB_texture_float扩展.

4.32浮点纹理不支持纹理过滤,必须将纹理过滤方式设置为GL_NEAREST,否则有可能使用软件模拟运行,速度奇慢无比.

5.起初使用float pack_2half(float2 v)来实现几何数据压缩,以能够存储顶点坐标和法线到FBO的纹理,pack_2half是PK2H指令的cg版本,NVidia的glsl也支持该指令,只是编译有warning,但ATI不支持该指令,编译报错,无法兼容,故转向使用GL_ARB_draw_buffers扩展.

6.GL_ARB_draw_buffers对应的OpenGL shader输出为gl_FragData[]数组,DirectX为COLOR0,COLOR1标识.

7.FBO + float texture,使用32位纹理时,7950GT奇慢无比,改用16位浮点后正常,原因未知.

8.DirectX下使用Float texture render target完成.

9.DirectX实现下,7950GT的显卡最新驱动169.21竟然不支持Float texture render target,CheckDeviceFormat失败,晕倒.

10.Geforce 6150下OpenGL模式跑的很慢,DirectX模式CheckDeviceFormat成功,但有问题.

http://www.cnitblog.com/Files/linghuye/DeferShaderDemo.rar

linghuye 2008-02-03 22:37 发表评论

图形硬件算法器

linghuye — Tue, 29 Jan 2008 13:12:00 GMT

Stencil Buffer可用作计数器和分支逻辑器.
DepthBuffer可用作大小比较器
GL_EYE_PLANE可以执行当前ModelView矩阵的逆矩阵,并保存下来使用.

linghuye 2008-01-29 21:12 发表评论

3D游戏鼠标控制的方式

linghuye — Tue, 29 Jan 2008 13:11:00 GMT

右键点击目标点
1.无论人物行进方向如何变化,镜头方向不变,并保持对准人物.
2.人物行进方向变化时,保持镜头锁定到人物后方,呈第3人称视角.
3.智能方式,人物行进方向变化时,镜头适时地缓慢地变换到第3人称视角.
4.点击行进不进行寻路,直线行走,遇障碍停下.

linghuye 2008-01-29 21:11 发表评论

GLSL/HLSL易犯错误和注意点

linghuye — Tue, 29 Jan 2008 12:30:00 GMT

我的blog里有许多此类笔记,主要是记录写程序时犯下的错误.有相当多的错误,我都是一犯再犯,而且每次都因这种小错耽误时间而骂自己是猪,所以很有必要记录下来,以备查找.作程序的要懂得积累经验,并书面化,抽象化.

渲染API容易出错,根源于其本质是个状态机,作一个渲染时,几十上百个状态都必须设置正确,才能得到正确的图像,这就很容易出点小差错.
1.GLSL的vec4有3种分量形式xyzw/rgba/stpq, 注意到的r分量是指颜色r分量, 习惯上的纹理坐标分量strq的r由于和颜色r冲突,改作p.

2.Global Amibient也要乘以材质Material.

3.HLSL没有shadow2DProj函数, GLSL的shadow2DProj返回的是深度比较的结果1.0或0.0的4元组,不是深度值!且要记住,shadow2DProj受到固定流水中纹理GL_TEXTURE_COMPARE_MODE/GL_TEXTURE_COMPARE_FUNC的影响,要使用shadow2DProj必须打开深度纹理比较模式.

4.HLSL允许如vec4向下强转为vec3这种隐式转换. GLSL语法上不允许,但实践上N卡出warning仍可以编译运行,A卡直接报错无法运行.

5.DirectX的shader调试状态和硬件实际运行状态的结果有很大区别,不能全信.

6.设置   glEnable(GL_COLOR_MATERIAL);
              glColorMaterial(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE);
在shader中, A卡的glFrontMaterial.diffuse不会跟踪设置为当前顶点色,而N卡正确.

7.GLSL: N卡可以使用vec3 temp = { 1.0, 0.0, 1.0}; 这种形式的构造, A卡报错.
   HLSL: 都可以使用float3 temp = { 1.0, 0.0, 1.0};形式.

8.HLSL的mul接受mul(vec, matrix)或mul(matrix, vec),要注意通常HLSL要依DirectX计算(V * M)使用mul(vec, matrix)的形式.
特别需要小心的是,vec如果是float3,前后行列不等,违反HLSL规范,但shader编译也不报错,直接当成float4(vec, 0)处理,而不是当成float4(vec, 1).即mul(float3, matrix)中的float3被当成向量,而不是顶点.

9.不要在一行中写过于复杂的表达式, N卡没问题, A卡很烂,通常都编译不过.例如:
http://www.ozone3d.net/blogs/lab/?p=38

10.GLSL可以只有PixelShader, 没有Vertex Shader, HLSL不支持.
vs_3_0 shader executed in hardware vertex processing mode can only be paired with at least a ps_3_0 shader.

11.GLSL的1.2版本开始支持mat4x3这种non-square矩阵,要注意4x3是4列3行,而不是4行3列.

References:
http://jegx.ozone3d.net/index.php?entry=entry070529-094845

linghuye 2008-01-29 20:30 发表评论

Shadow Map Demo

linghuye — Mon, 28 Jan 2008 15:14:00 GMT

Shadow Map实现测试,RenderCraft图形底层, 兼容OpenGL和DirectX两种实现,其中OpenGL可以使用固定管线或Shader兼容实现.

DirectX的ShadowMap要比OpenGL晦涩而艰难的多,特别是Nvidia和ATI对Depth Texture的实现内部实现不统一.
Shadow Map是个丑陋的技术方案.

最近写些Demo,放上来,主要是为了测试我的RenderCraft 3D渲染底层的对各机器的兼容性,以及它们在OpenGL和DirectX渲染是否一致, 在固定流水线和可编程流水线间的兼容性等等, 这样我到每处有计算机的地方都下载下来运行测试一下. 每个Demo先写OpenGL的实现,同时设计好接口,因为基础图形学算法是一致的,移植到DirectX就是实现一下DX接口或相应的shader.

http://www.cnitblog.com/Files/linghuye/ShadowMapDemo.rar

linghuye 2008-01-28 23:14 发表评论

投影矩阵备忘

linghuye — Wed, 23 Jan 2008 14:01:00 GMT

投影矩阵(Project Matrix)本意是将不规则的视图体(View Volume)变换成一个单位立方体,但投射到屏幕时,Z被丢弃了,所以造成了2D投影的假象.注意这是错觉,实际概念应该是投射到单位立方体空间,是空间投射的概念.

需要注意的是,OpenGL最终投射到单位立方体[-1,-1,-1], [1, 1, 1],而DirectX则不是,它的投影矩阵将Z投射到[0, 1].

丢弃掉Z后,就得到[-1,-1],[1,1]的平面投射范围,为计算投射到的窗口屏幕坐标,将X,Y的值域,乘0.5,加0.5,映射到[0,1]值域,再分别乘窗口屏幕宽或高,才得到最终的窗口屏幕坐标.

经过OpenGL或DirectX的投射矩阵变换后的顶点,称作在Clip Space空间内,即单位立方体空间内.
为得到最终屏幕窗口坐标,将上述变换使用矩阵表达为:
0.5, 0, 0, 0.5,
0, 0.5, 0, 0.5,
0,   0, 0, 0,
0,   0, 0, 1
为得到OpenGL的投射立方体的矩阵为:
0.5, 0, 0, 0.5,
0, 0.5, 0, 0.5,
0,   0, 0.5, 0.5,
0,   0, 0, 1
为得到DirectX的投射立方体的矩阵为:
0.5, 0, 0, 0.5,
0, 0.5, 0, 0.5,
0,   0, 0, 0,
0,   0, 0, 1

投影矩阵前的顶点w总是为1, 正射投影矩阵后的顶点w还是为1, 但透视投影矩阵后的顶点w开始不为1.

linghuye 2008-01-23 22:01 发表评论

Shadow Volume Demo

linghuye — Wed, 16 Jan 2008 13:13:00 GMT

阴影体实现测试,RenderCraft图形底层, 兼容OpenGL和DirectX两种实现.

1.算法的本质是如何判断一个像素点代表的3D空间点是否在一个多面体内,用的是经典的直线穿越次数判断算法,即判断一个像素3D空间点是否在阴影体内,在于判断从视点到该点的连线穿越阴影体面的次数,算法映射到硬件模拟上,利用Stencil Buffer作计数器.
2.要保证算法的Robust,肯定要用ZFail算法,ZPass是靠不住的.使用shader实现后zpass优化也是没有必要的.
3.兼容支持Two side stencil的显卡,Nvidia是GL_EXT_stencil_two_side扩展, ATI是GL_ATI_separate_stencil扩展.
4.调试中最容易出现的问题是,出现半个阴影区,或阴影交叠处没有阴影,这是由于Shadow Volume没有封住Cap导致.
5.封Cap的问题: zfail只需要封住远平面.

对于shadow volume的frontface(既面对视点的这一面),如果depth test 的结果是pass,说明shadow volume的该front face是在场景物体之前,视线要到达场景物体必然需要穿过该face.
反之如果depth test 的结果是fail,说明shadow volume的该front face是在场景物体之后.

而对于shadow volume的back face(远离视点的一侧),如果depth test的结果是pass,说明shadow volume的该back face是在场景物体之前,视线要到达场景物体必然需要穿过该face.
反之如果depth test 的结果是fail,说明shadow volume的该back face是在场景物体之后.

The rendering of a vector (w = 0.0) in clip space would be semi-infinite.

http://www.cnitblog.com/Files/linghuye/ShadowVolumeDemo.rar

Reference:
ShaderX2

linghuye 2008-01-16 21:13 发表评论