• About
    • Resume
A Game Developer also plays some guitar

Category Archives: Ok Computer

This is only about computer, computer science.

日积月累: Uncopyable & Uninheritable in C++

November 13, 2009 4:45 pm / 7 Comments / Benny Chen

如何在C++中阻止复制和继承呢,我做了个整理。

Uncopyable
有些类需要禁止被复制或者赋值,这需要显示的禁掉它们的拷贝构造和赋值函数。
摘自《Effective C++》Item 6: Explicitly disallow the use of compiler-generated functions you do not want

class Uncopyable 
{
protected:                                   // allow construction
    Uncopyable() {}                       // and destruction of
    ~Uncopyable() {}                     // derived objects...

private:
    Uncopyable(const Uncopyable&);             // ...but prevent copying
    Uncopyable& operator=(const Uncopyable&);
};

class UncopyableExample: private Uncopyable 
{ 
    // THIS CLASS IS UNCOPYABLE
}; 

Uninheritable
Java提供了final关键字用来阻止被继承,而在C++中没有这个关键字,但阻止继承的类在C++中是同样可能的。
摘自:http://www.csse.monash.edu.au/~damian/Idioms/Topics/04.SB.NoInherit/html/text.html

template <class OnlyFriend>
class Uninheritable
{
    friend class OnlyFriend;
    Uninheritable(void) {}
};

class NotABase : virtual public Uninheritable< NotABase >
{
    // WHATEVER
};

class NotADerived: public NotABase
{
    // THIS CLASS GENERATES A COMPILER ERROR
    NotADerived(){}
};
Posted in: C++, Talking in Code / Tagged: C++, 禁止复制, 禁止继承

Unproject

July 30, 2009 11:19 am / 1 Comment / Benny Chen

Unproject即反投影,将一个坐标从投影空间中反投影到视图空间。对于Project操作,很容易,直接用投影矩阵乘以视图空间的坐标即可,即:

posProj = posView * matrixProj

其中设posView = (x, y, z, 1)是视图空间的某一位置点的坐标,posProj = (x’, y’, z’, w’)为投影空间中该点的坐标,matrixProj为投影矩阵。我们知道,因为投影矩阵的特殊性,有w’ = z,即视图空间的深度值存储在投影空间的w值中,这样posPorj的xyz坐标值在除以了w值之后,就有了近大远小的透视效果。注意:只有在除以了w值之后才会有,x’/w’,y’/w’∈[-1,1]且z’/w’∈[0,1],即在那个所谓的半个正方体中了。

那么对于Unproject操作呢,是不是直接posView = posProj * inverse( matrixProj )就可以了呢,如果知道x’y’z’w’值,当然是正确,但关键问题是,大多数情况下,我们所知道的只是x’/w’,y’/w’以及z’/w’的值。

DX提供了一个函数D3DXVec3Unproject,可以做反投影,不过它只能在C++代码里使用(shader里没法使用),而且需要注意的是,这个函数是对屏幕空间的坐标进行的反投影(所以这个函数还需要传入一个viewport参数),务必不要将投影空间的坐标作为参数传递给这个函数。

我需要写一个自己的反投影函数,不妨从上面的这个公式推导:posProj = posView * matrixProj,因为我们现在已知的是x’/w’,y’/w’以及z’/w’的值,不妨设posProj’ = (x’/w’, y’/w’, z’/w’, 1 ),所以这个公式改为:posProj’ * w’ = posView * matrixProj。

因为一般投影矩阵是像这样一种形式:

projmatrix

于是有拆分posProj’ * w’ = posView * matrixProj后,有:

posProj’.x * w’ = posView.x * xScale;
posProj’.y * w’ = posView.y * yScale;
posProj’.z * w’ = posView.z * Q – Q*zn;
w’ = posView.z

上面构成一个方程组,解这个方程组,可得:

posView.z = Q*zn / ( Q – posProj’.z )
posView.x = posView.z * posProj’.x / xScale
posView.y = posView.z * posProj’.y / yScale

至此反投影完毕。

反投影一般比较常见的是在鼠标拾取(picking)的例子中,而那里投影空间的点取的是近屏幕上的点(posProj’.z = 0),因为这样上面的公式就会得到一个比较简化的特例:

posView.z = zn
posView.x = posProj’.x * zn / xScale
posView.y = posProj’.y * zn / yScale

Posted in: Computer Graphics / Tagged: D3DXVec3Unproject, unproject, 投影矩阵, 投影空间, 视图空间

顶点法线

July 23, 2009 4:27 pm / 2 Comments / Benny Chen

本来以为前一段时间写的3d max导出插件已经没有什么大的问题了,但有没有问题,完善不完善,真不是凭感觉就OK的,必须有足够广泛的测试用例测试后,才能够证明。

这不,最近开始研究并写一些光线跟踪的例子了,这当然离不开模型的法线,于是在进行当中我就发现,我的导出插件所导出的法线是不完善的。

在原来的插件中,我让顶点的法线就直接等于其所在的三角形面的面法线(多个面共享1个顶点,则会导出多个顶点,这些顶点位置相同法线不同),但对于光照模型,面法线只能支持到Lambert,为了支持Gouraud, Phong等其他模型,则必须使用顶点法线(为什么?稍后解释)。

这里提出了顶点法线和面法线,首先需要清楚的理解并区分这两个概念。

面法线很容易理解,即垂直于三角形面的一条法线。那顶点法线又从何而来呢,严格的从法线的定义上来说,其实顶点是不存在法线的,那为何又有顶点法线这个概念的。让顶点也拥有法线,是为了在光照计算时,能够在多面体的表面获得一种平滑的效果。

更具体的说,如果不使用顶点法线(就像我的3dmax导出插件原来就直接让顶点法线等于其面法线一样),一个三角形面的三个顶点的光照计算按照其所在面的面法线来计算,因为三个顶点的法线相同,则与光照方向求点积之后的结果也相同,这样三个顶点将会获得相同的光照效果,之后,光栅化再怎么插值,整个表面也都只是一种光秃秃的效果。(如图1)

而如果使用顶点法线,同一个面的三个顶点的法线就不一定相同了,这样通过光栅化后,就能在多面体的表面获得一种平滑过渡的光照效果。(如图2)

于是,弄清楚了这个后,我需要再次修改我的3dmax导出插件了,需要计算并生成新的顶点法线。那顶点法线该如何计算呢,对于这个我在这里就不详述,Max Wagner的《Generating Vertex Normals》这篇文章说的很详细清楚,从最简单的到逐步优化的生成算法一一都有介绍,可以去google找一下。

而3dmax的SDK开发文档里对顶点法线的计算也有介绍,3dmax提供了一个smoothing group的概念,这对于像立方体盒子这种表面并不是平滑过渡的模型,计算它们的法线将会带来很大的帮助。Wagner的文章里也说了,对于像立方体这样的模型,顶点法线不能简单的等于(共享该顶点的面的)面法线的平均值,因为这些面之间的过渡并不平滑。按照3dmax的概念,这些面不属于同一个smoothing group。何为smoothing group,这是3dmax根据表面之间的平滑过度情况,进行的分组。比如立方体,因为6个面之间两两都是相互不平滑的,所以一共会有6个smoothing group。每个面所属的平滑组的ID,程序员是可以直接读出的。

下面这两张图,是我在修改前和修改后的光照效果,对比很明显。

lambert 图1:基于面法线的光照

gouraud图2:基于顶点法线的光照

Posted in: Computer Graphics / Tagged: 面法线, 顶点法线

诡异的画面

July 16, 2009 5:55 pm / Leave a Comment / Benny Chen

对shader文件做了一些修改,但还只是简单的渲染一个带纹理的盒子。出来的结果居然是这样的诡异,荧光闪闪,还带着雪花满盒子飘……

雪花bug

shader的错误的确很难查找,尤其是在编译通过只剩下逻辑错误的时候。最后错误的原因却又是如此的简单,我把PS的返回值写成了float,而应该是float4,我不小心漏掉了4,于是造成了这样诡异却绚烂的艺术效果,留文以作纪念。

Posted in: Computer Graphics / Tagged: pixel shader

Some Tests

July 8, 2009 9:30 pm / Leave a Comment / Benny Chen

在最近的项目中,尝试进行了一些小实验,并记录了数据作为比较。实验机器的显卡是NVidia Geforce 8800 GT。

1. Skinning

skinning on CPU

                          skinning on CPU

skinning on GPU

                          skinning on GPU

从图中可以清晰的看出,对于骨骼蒙皮计算,CPU和GPU的差距可见一斑,GPU比CPU要快上10倍之多!这就是GPU并行计算的魅力!

2. Instancing & Stream Output

人物模型延用上面的这个模型(该模型差不多有1300个面),采用instancing技术渲染上千人(所有的Instance的动画在每一帧保持一致),并且实现了SO的版本,对它们的FPS进行比较。

Instancing without SO

   

     1,000 Instances              2,000 Instances             3,000 Instances

Instancing with SO

   

     1,000 Instances              2,000 Instances             3,000 Instances

因为所有的Instance的动画在每一帧都是一致的,所以如果不使用SO技术,则不得不对每个instance都需要进行一次蒙皮动画,这显然是一种浪费。Stream Output技术使得所有的Instance的蒙皮动画只需要执行一次,所以在效率上得到了一定的提高,如下表。

Number of Instances

FPS(Without SO)

FPS(With SO)

1,000

40

56

2,000

19

36

3,000

13

24

 3. Frustum Culling

换了一个低质量的模型(只有不到200个面),基本上万人级别是没有问题了,加上了Frustum Culling,则可以跑得更快!

使用3种方法实现了Frustum Culling,前两个都是基于CPU的,最后一个是基于GPU

  1. 顺序执行(最简单的对所有Instance遍历执行Frustum Culling算法)
  2. 四叉树(四叉树裁剪,我这里用四叉树用得有点牵强,因为人物不能移动且必须保持边长为2的N次方的阵型。这么简单的处理四叉树,只是为了做实验比较而已)
  3. GPU上的Frustum Culling(算法基本上跟1是一致的,只不过是在GPU上执行)

三个方法在同一个视角,使得它们截取和渲染的数量是一致的。总共65536个Instance,当前绘制都是15485个。

   

           顺序执行                              四叉树                             在GPU

效率比较如下表。

Current Rendering / Number of Instances
FPS
(Sequential Frustum Culling)
FPS
(Frustum Culling With Quad-tree)
FPS
(Frustum Culling on the GPU)
4388/16384 61 143 102
15485/65536 16 43 32

发现最快的是使用四叉树,而GPU的算法反而相对比较慢。原因很有可能是后者需要处理GPU和CPU的同步问题,在GPU进行Frustum Culling需要CPU从GPU读取Frustum Culling执行的结果(为了知道有多少个instance需要被渲染),在DX10的SDK文档里可清楚的写着,从GPU向CPU进行Map读取操作,是比较严重影响效率的,因为总有一方要停下来去等待另外一方的数据。

Posted in: Computer Graphics / Tagged: frustum culling, instancing, skinning

Get streaming output statistics

July 8, 2009 1:33 pm / Leave a Comment / Benny Chen

有时候需要知道stream output了多少个数据,这需要借助于DX10中的ID3D10Query,步骤如下:

  1. 创建D3D10_QUERY_DESC结构,设置D3D10_QUERY_DESC::Query为D3D10_QUERY_SO_STATISTICS,表明要调查的是SO的数据,设置D3D10_QUERY_DESC::MiscFlags为0;
  2. 通过ID3D10Device::CreateQuery()创建ID3D10Query;
  3. 用ID3D10Query::Begin()和ID3D10Query::End()函数包裹需要调查的SO代码;
  4. 通过ID3D10Query::GetData()获取SO的统计数据,填充在一个D3D10_QUERY_DATA_SO_STATISTICS

示例代码如下:

// 创建ID3D10Query
ID3D10Query *d3dQuery;
D3D10_QUERY_DESC d3dQueryDesc;
d3dQueryDesc.Query = D3D10_QUERY_SO_STATISTICS;
d3dQueryDesc.MiscFlags = 0;
m_pD3DDevice->CreateQuery( &d3dQueryDesc, &d3dQuery );

// ...... ......

// 统计SO信息
d3dQuery->Begin();
// ......draw something with SO......
d3dQuery->End();

// ......最好在这里放置一些代码,填置CPU的空闲......

// 获取SO信息
D3D10_QUERY_DATA_SO_STATISTICS soData;
while ( S_OK != d3dQuery->GetData( ( void* )&soData, sizeof( soData ), 0 ) );

值得注意的是,GetData一定要用while包裹,因为ID3D10Query从GPU获取数据是异步的(ID3D10Query继承自ID3D10Asynchronous)。这也是为什么最好能在GetData之前放置一些代码,因为CPU要等待GPU的数据,不如让CPU先去做些其他的事情,不要把CPU浪费在毫无意义的while循环等待上。

Posted in: Computer Graphics / Tagged: D3D10_QUERY_SO_STATISTICS, ID3D10Query, stream output

ConstructGSWithSO

July 1, 2009 5:07 pm / 1 Comment / Benny Chen

如果要使用SO(Stream Output),则在shader中必须使用ConstructGSWithSO函数来构造SO的GS,ConstructGSWithSO有两个参数。

  • VertexShader/GeometryShader – shader变量,因为SO的数据可以来自GS,也可以来自VS(如果GS为NULL),所以该参数可以是一个VertexShader,也可以是一个GeometryShader。(shader变量一般通过CompileShader函数获得)
  • Semantics – 描述SO的数据的semantic,该semantic须与上一个参数(shader变量)的shader函数的输出相一致。这个参数的格式要求比较变态,所以举例子说明比较好。

现有一个VS如下,需要SO它的输出数据:

struct VSInput
{
    ……(略)
};
struct VSOutput
{
    float3 pos : POSITION;
    float2 tex : TEXCOORD;
};
VSOutput VS VSInput
{
    VSOutput o;
    ……(略)
    return o;
}

那么ConstructGSWithSO函数应该这么写:

GeometryShader gsSkinningSO = ConstructGSWithSO( CompileShader( vs_4_0, VSSkinning_SO() ), “POSITION.xyz; TEXCOORD.xy” );

看粗体部分的第二个参数,首先是双引号的字符串形式的,双引号内逐个列出了VSOutput的semantic,每个semantic同时要用.xyz,.xy这样的形式标明出它的维数(特别注意,如果只是一个float或uint的一维数据,同样也需要用.x来标出它是一维的!)。各个semantic之间用分号隔开,但注意,最后一个semantic后面不需要加分号(不然创建shader失败!)。

Posted in: Computer Graphics / Tagged: ConstructGSWithSO, DX10

关于对std::vector的遍历

June 30, 2009 11:40 pm / 1 Comment / Benny Chen

static

上图是通过Instancing渲染了10000个低精度模型(低于200个面),有skin动画,但是人物没有AI。在实验室Geforce 8800GT的显卡上fps可以跑到80帧。

接着,我给人群加上点简单的AI,每个人物进行向一个目标点移动,于是我在每帧更新的时候添加了如下的这些代码。代码中,MeshInstance是instance的类,对应于一个人物实例,Move是移动人物实例的简单AI函数。对于所有的Instancing数据,我使用一个vector列表存储——m_vpInstancingData。代码通过vector的iterator(迭代器)遍历所有的instance,对每个instance执行Move函数。

for( vector< MeshInstance* >::iterator i = m_vpInstancingData.begin(); i != m_vpInstancingData.end(); i ++ )
{
    ( *i )->Move();
}

结果,加上这段代码之后,程序的效率居然骤降,如下图,fps只剩下44帧。这让我很是纳闷,因为在加上代码之前,CPU基本上是空闲的,因为所有的骨骼蒙皮+渲染全部都是GPU扛着,而在CPU加上一个10000次的for循环后,整体效率大打折扣。它的杀伤力有这么大么……CPU不太可能这么低能。

1

然后,我把(*i)->Move()这行代码注释掉了,仍然只有40多帧,即一个只是10000次的空for循环,仍然是效率的瓶颈,10000次的Move根本不是问题。

难道是迭代器在影响效率?于是把代码改成了下面这样,不用迭代器遍历vector,而直接使用数组形式访问vector来遍历。

for( int i = 0; i < NUM_INSTANCE; i ++ )
{
    m_vpInstancingData[i]->Move();
}

再次执行之后,fps又回归80帧!!

2

对于vector的遍历,一直以来一直都是通过迭代器遍历,但对于大型vector它居然会如此的影响效率,也是到今天才刚发现。但是STL的设计本来就是奔着方便高效的啊,迭代器不至于效率影响这么大吧,可能与Debug模式有关。于是,我做了一个小实验,代码如下。

#include <iostream>
#include <vector>
#include <time.h>

using std::vector;
using std::cout;
using std::endl;

#define MAX_NUM 1000000

int _tmain(int argc, _TCHAR* argv[])
{
    vector< int > vIntList;
    for ( int i = 0; i < MAX_NUM; i ++ )
    {
        vIntList.push_back( i );
    }

    clock_t start, end;
    double duration;

    start = clock();
    for ( vector< int >::iterator i = vIntList.begin(); i != vIntList.end(); i ++ )
    {
        ( *i ) ++;
    }
    end = clock();
    duration = ( double )( end - start ) / CLOCKS_PER_SEC;
    cout << duration << "seconds" << endl;

    start = clock();
    for ( int i = 0; i < MAX_NUM; i ++ )
    {
        vIntList[i]++;
    }
    end = clock();
    duration = ( double )( end - start ) / CLOCKS_PER_SEC;
    cout << duration << "seconds" << endl;

    return 0;
}

在Debug模式下执行的结果
debug

Release模式下
Release

可见,在Release版本中,它们几乎是一样快的。而在Debug版本中,可能因为迭代器需要额外的很多检查工作,所以比数组形式访问慢了很多很多……所以,对于采用哪种方式对vector进行遍历,效率怎样,如果最终是要发布为release版本的,那么这个问题大可不必担心。

Posted in: Computer Graphics, Some Experiences / Tagged: vector, 数组, 迭代器, 遍历

关于D3D10_MAPPED_TEXTURE2D的RowPitch

June 30, 2009 5:02 pm / Leave a Comment / Benny Chen

当对一个ID3D10Texture2D进行Map操作时,会遇到D3D10_MAPPED_TEXTURE2D结构。该结构有一个属性是UINT RowPitch,如果没有很好的理解这个属性的含义,Map操作的结果很有可能是不对的。

这是DX10 SDK文档对RowPitch的解释:

The pitch, or width, or physical size (in bytes), of one row of an uncompressed texture.

一个普通texture一行的字节总数就是它的RowPitch。但要特别注意的是:RowPitch并不就等于Texture2D的width乘以其每个纹元(texel)的字节数,即:

RowPitch ≠ width* sizeof (pixelFormat)

RowPitch总是大于等于后者,并且一般是等于一个2的n次幂。从上面也可以看出Pitch是以字节为单位,而width是以像素为单位的。

举例说明:

一个ID3D10Texture2D,创建它时所使用的D3D10_TEXTURE2D_DESC结构的Format属性是DXGI_FORMAT_R32G32B32A32_FLOAT,即一个纹元占16(4×4)个字节,Width属性是400,即每一行有400个纹元,则可计算每一行16 * 400 = 6400bytes。但如果对Texture2D进行Map操作时,可以发现,Map后所得到的D3D10_MAPPED_TEXTURE2D结构的RowPitch的值却是8192(是大于6400的最小的2的n次幂)。

所以在进行Map操作时,需要针对RowPitch,而不要依赖定义texture时的width。

但是,在fx文件中对纹理进行采样的时候,针对的则是width,见如下fx代码。其中offset是相对于起点的偏移量,g_TexWidth是一个二维纹理的width,可见为了获得offset在纹理中的uv坐标,计算都是相对于width的,这时不用考虑pitch。

	
uint baseU = offset % g_TexWidth;
uint baseV = offset / g_TexWidth;
Posted in: Computer Graphics / Tagged: D3D10_MAPPED_TEXTURE2D, ID3D10Texture2D, RowPitch, width

std::bad_alloc?

June 29, 2009 5:34 pm / Leave a Comment / Benny Chen

今天遇到一诡异的Bug,在某段代码之后,只要一执行vector的push_back函数,就报出异常——std::bad_alloc。

bad_alloc?这一般是new申请内存不足而扔出的异常么,内存耗光?绝对不可能。

折腾了很久,最后发现的错误根源是如此的愚蠢。

对于类的一个成员变量 QuadNode *m_pChild[4],我对它的初始化居然是这样的:

ZeroMemory( m_pChild, sizeof( QuadNode ) * 4 );

很显然,sizeof( QuadNode )绝对是大错特错,因为m_pChild是一个指针数组,而不是QuadNode的数组。

其实这个错误不值得拿出来一说,只不过是Bug所表现出来的症状有些奇特,所以留文以作警示。

Posted in: Some Experiences

Post Navigation

← Older Posts
Newer Posts →

LinkedIn

Milan Petrovic

Categories

  • In My Life (25)
    • A Day in the Life (8)
    • English Learning (2)
    • Learn a Word (7)
    • Something In The Way (8)
  • Music Heaven (8)
    • Guitar (1)
    • In Concert (1)
    • Lyrics (3)
  • OK Computer (54)
    • 3D (3)
    • C++ (10)
    • Computer Graphics (15)
    • Game Programming (23)
    • iOS (6)
    • Linux (1)
    • Lua (9)
    • My Projects (3)
    • Some Experiences (9)
    • Talking in Code (2)
    • Unity (2)
  • Quotations (2)
  • Uncategorized (1)
  • Visca Barça (24)
    • FCB BJ (5)

Recent Posts

  • [译]优化你的手机游戏(没有延迟的,才是健康的)- 一篇给游戏美术设计师读的文章
  • 新浪微博API for MOAI
  • 稍后继续
  • Unity Developer ++
  • Another Thread @ Moai Forum
  • 1st Day of Golden Week
  • 为SyntaxHighlighter添加新语言
  • 基于Lua的State Pattern
  • Class Diagram of Pacman
  • 基于Moai的Pacman

Recent Comments

  • 约修亚_RK on 为SyntaxHighlighter添加新语言
  • 爱装的小男孩 on 小心DLL链接静态库时的内存错误
  • happyfire on Game Loop的几种实现方式
  • William on 新浪微博API for MOAI
  • Benny Chen on 新浪微博API for MOAI
  • your man on 新浪微博API for MOAI
  • 你家男人 on 稍后继续
  • 逍遥 on 关于对std::vector的遍历
  • papa on Unity Developer ++
  • T客网 ︱ Techpot » Blog Archive » iOS开发与OpenGL ES相关问题整理(1) on iOS开发与OpenGL ES相关问题整理(1)

Tags

2d 3D 3dsmax 3ds max air Apply architecture Asia tour barca Beijing bilbao binary search blocked bob boost bruce springsteen C++ capo CGContextDrawImage Champions League Change DLL DX10 eval exporter flash framework frustum culling game game engine iniesta ios linux lua Moai opengles pacman plug-in plugin 北京 导出插件 崩溃 巴萨 游戏引擎 踢球
© Copyright 2026 - A Game Developer
Infinity Theme by DesignCoral / WordPress