C++博客-永远也不完美的程序-文章分类-图形编程

（转）多线程渲染(Multithreaded- rendering)3D引擎实例分析 : FlagshipEngine

魔鬼螳螂 — Wed, 02 Mar 2011 10:43:00 GMT

1. 开篇：关于FlagshipEngine

首先要感谢旗舰工作室的倒掉，让我可以名正言顺的使用FlagshipEngine这个名字，话说这个实验引擎，当初只是我的大学毕业设计，工作之后实在太忙，写写停停，进度缓慢，到今天也只能算V0.001，其特性主要有以下三点：

一、多线程

多核CPU 早已普及，但3D引擎却迟迟不能享受到其好处，还仅仅停留在资源异步加载，音频独立线程等不疼不痒的应用，就在一年前吧，公司的牛人们为了优化骨骼动画和粒子计算煞费苦心，这两样计算，特别是在无法控制同屏资源的网络游戏中，对CPU资源的占用非常可观，自然也拖累了游戏帧数，于是我便有了将逻辑计算与渲染分离的想法。

FlagshipEngine实现了一套没有线程同步的双线程结构，可以做到骨骼动画、粒子计算、光源移动等逻辑计算分离到一个单独的线程运行，完全不影响渲染帧数。

二、shader渲染器

DX10已经放弃了固定管线，那么我们也没理由再留恋它，完全基于shader的渲染器实现起来更加清晰简洁，并且易于扩展，目前FlagshipEngine已经实现了DX9和DX10两个渲染器，可以方便的添加特效。

三、统一剪裁

场景组织和剪裁永远是3D引擎的核心功能，视锥、四叉树、BSP 、Portal如何选择，如何统一是个难题，我的做法是将所有的剪裁都抽象成剪裁面，并用压栈和出栈的方式，递归的对场景进行剪裁，另外我们还可以对大块实体绑定简单模型的遮挡体，使用边缘检测算法生成遮挡剪裁面，实现遮挡剪裁。

这套机制还没有经过严格的测试，有待进一步的验证。

2. 3D引擎多线程：资源异步加载

资源异步加载恐怕是3D引擎中应用最为广泛的多线程技术了，特别是在无缝地图的网络游戏中，尤为重要，公司3D引擎的资源加载部分采用了硬盘->内存->显存两级加载的模式，超时卸载也分两级，这样虽然实际效果不错，但代码非常繁琐，在FlagshipEngine中，我设法将其进行了一定程度的简化。

首先我们需要定义一个Resource基类，它大致上是这样的：

class _DLL_Export Resource : public Base
{
public:
      Resource();
      virtual ~Resource();

      // 是否过期
      bool             IsOutOfDate();

public:
      // 是否就绪
      virtual bool IsReady();

      // 读取资源
      virtual bool Load();

      // 释放资源
      virtual bool Release();

      // 缓存资源
      virtual bool Cache ();

      // 释放缓存
      virtual void UnCache();

protected:
      // 加载标记
      bool          m_bLoad;

      // 完成标记
      bool          m_bReady;

private:

};

在实际游戏中，加载资源的范围大于视野，当摄像机移动到单元格边缘(必须有一定的缓冲区)，就应将新的单元格中的对象加入到资源加载队列中，唤醒资源加载线程调用Load接口进行加载，完成后将该资源的加载标记设为true。而通过可视剪裁所得到的最终可视实体，则需要调用Cache接口构建图像API所需对象，当Load和Cache都完成后IsReady才会返回true，这时该资源才能开始被渲染。

卸载方面，在加载新的单元同时，卸载身后旧的单元，对单元内所有资源调用Release，Load/Release带有引用计数，仍被引用的资源不会被卸载。当某一资源长时间没有被看见，则超时，调用UnCache释放VertexBuffer等资源。

为了实现超时卸载功能，我们需要一个ResourceManager类，每帧检查几个已Cache的资源，看起是否超时，另外也需对已加载的资源进行分类管理，注册其资源别名（可以为其文件名），提供查找资源的接口。

另外为了方便使用，我们需要一个模板句柄类ResHandle，设置该资源的别名，其内部调用ResourceManange的查找方法，看此资源是否已存在，如不存在则new一个新的，GetImpliment则返回该资源对象，之后可以将该资源添加到实体中，而无需关心其是否已被加载，代码如下：

template
class _DLL_Export ResHandle
{
public:
      ResHandle() { m_pResource = NULL; }
      virtual ~ResHandle() {}

      // 设置资源路径
      void          SetPath( wstring szPath )
      {
         Resource * pResource = ResourceManager::GetSingleton()->GetResource( Key( szPath ) );
         if ( pResource != NULL )
         {
            m_pResource = (T *) pResource;
         }
         else
         {
            m_pResource = new T;
            m_pResource->SetPath( szPath );
            ResourceManager::GetSingleton()->AddResource( m_pResource );
         }
      }

      // 模板实体类指针
      T *          GetImpliment() { return (T *) m_pResource; }
      T *          operator-> () { return (T *) m_pResource; }

protected:
      // 模板实体类指针
      Resource *    m_pResource;

private:

};

3.  3D引擎多线程：渲染与逻辑分离

目前的3D引擎的渲染帧和逻辑帧都是在一个线程上运行的，在网络游戏中大量玩家聚集，繁重的骨骼动画计算和粒子计算极大的拖累了渲染帧数，有两种有效措施：

1、控制同屏显示人数，但玩家体验不好

2、帧数低于某值时减少动画Tick频率，但带来的问题是动画不连贯。

如果考虑使用多线程优化，最容易想到的就是采用平行分解模式，将骨骼动画计算和粒子计算写成两个for循环，然后用OpenMP将其多线程化，但事实上这样并不会提高多少效率，这两者计算仍然要阻滞渲染帧，线程的创建也有一定的消耗。于是我想到了一种极端的解决方案，采用任务分解模式，将渲染和逻辑完全分离到两个线程去，互不影响，当然这样线程同步会是大问题，毕竟线程的数量和BUG的数量是成正比的。

我们首先来分析下这两个线程分别需要做什么工作，需要那些数据。渲染线程需要获取实体的位置、材质等信息，并交给GPU 渲染，逻辑线程需要更新实体的位置、材质、骨骼动画等数据，很显然一个写入一个读取，这为我们实现一个没有线程同步的多线程3D渲染系统提供了可能。

为了让读取和写入不需要Lock，我们需要为每一份数据设计一个带有冗余缓存的结构，读取线程读取的是上次写入完成的副本，而写入线程则向新的副本写入数据，并在完成后置上最新标记，置标记的操作为原子操作即可。以Vector为例，这个结构大致是这样的：

struct VectorData
{
      Vector4f m_pVector[DATACENTER_CACHE];
      int       m_iIndex;

      VectorData()
{
         memset( m_pVector, 0, DATACENTER_CACHE * sizeof(Vector4f) );
         m_iIndex = 0;
      }

      void Write( Vector4f& rVector )
{
         int iNewIndex = m_iIndex == DATACENTER_CACHE - 1 ? 0 : m_iIndex + 1;
         m_pVector[iNewIndex] = rVector;
         m_iIndex = iNewIndex;
      }

      Vector4f& Read()
  {
         return m_pVector[m_iIndex];
      }
};

当然我们可以用模板来写这个结构，让其适用于int，float，matrix等多种数据类型，余下的工作就简单了，将所有有共享数据的类的成员变量都定义为以上这种数据类型，例如我们可以定义：

      SharedData  m_matWorld;

在渲染线程中调用pDevice->SetWorldMatrix( m_matWorld.Read() );

在逻辑线程中调用m_matWorld.Write( matNewWorld );


需要注意的是，这种方案并非绝对健壮，当渲染线程极慢且逻辑线程极快的情况下，有可能写入了超过了DATACENTER_CACHE次，而读取却尚未完成，那么数据就乱套了，当然真要出现了这种情况，游戏早已经是没法玩了，我测试的结果是渲染帧小于1帧，逻辑帧大于10000帧，尚未出现问题。

FlagshipEngine采用了这一设想，实际Demo测试结果是，计算25个角色的骨骼动画，从静止到开始奔跑，单线程的情况下，帧数下降了 20%～30%，而使用多线程的情况下，帧数完全没有变化！

4.  3D引擎多线程：框架

现在我们已经有了三个可独立工作的线程：资源加载线程、逻辑线程、渲染线程，下一步我们需要决定它们如何在实际的项目中相互配合，也就是所谓的应用程序框架了，该框架需要解决以下两个问题

首先，资源读取线程可以简单设计为一个循环等待的线程结构，每隔一段时间检查加载队列中是否有内容，如果有则进行加载工作，如果没有则继续等待一段时间。这种方式虽然简单清晰，但却存在问题，如果等待时间设得过长，则加载会产生延迟，如果设得过短，则该线程被唤醒的次数过于频繁，会耗费很多不必要的CPU 时间。

然后，主线程是逻辑线程还是渲染线程？因为逻辑线程需要处理键盘鼠标等输入设备的消息，所以我起初将逻辑线程设为主线程，而渲染线程另外创建，但实际发现，帧数很不正常，估计与WM_PAINT消息有关，有待进一步验证。于是掉转过来，帧数正常了，但带来了一个新的问题，逻辑线程如何处理键盘鼠标消息？


对于第一个问题，有两种解决方案：

第一，我们可以创建一个Event，资源读取线程使用WaitForSingleObject等待着个Event，当渲染线程向加载队列添加新的需加载的资源后，将这个Event设为Signal，将资源读取线程唤醒，为了安全，我们仍需要在渲染线程向加载队列添加元素，以及资源加载线程从加载队列读取元素时对操作过程加锁。

第二，使用在渲染线程调用PostThreadMessage，将资源加载的请求以消息的形式发送到资源价值线程，并在wParam中传递该资源对象的指针，资源加载线程调用WaitMessage进行等待，收到消息后即被唤醒，这种解决方案完全不需要加锁。

对于第二个问题，我们同样可以用PostThreadMessage来解决，在主线程的WndProc中，将逻辑线程需要处理的消息发送出去，逻辑线程收到后进行相关处理。

需要注意的是，我们必须搞清楚线程是在何时创建消息队列的，微软如是说：

The thread to which the message is posted must have created a message queue, or else the call to PostThreadMessage fails. Use one of the following methods to handle this situation.

Call PostThreadMessage. If it fails, call the Sleep function and call PostThreadMessage again. Repeat until PostThreadMessage succeeds.
Create an event object, then create the thread. Use the WaitForSingleObject function to wait for the event to be set to the signaled state before calling PostThreadMessage. In the thread to which the message will be posted, call PeekMessage as shown here to force the system to create the message queue.
PeekMessage(&msg, NULL, WM_USER, WM_USER, PM_NOREMOVE)
Set the event, to indicate that the thread is ready to receive posted messages.

看来，我们只需要在线程初始化时调一句PeekMessage(&msg, NULL, WM_USER, WM_USER, PM_NOREMOVE)就可以了，然后在主线程中如此这般：

switch ( uMsg )
      {
      case WM_PAINT:
         {
            hdc = BeginPaint(hWnd, &ps);
            EndPaint(hWnd, &ps);
         }
         break;
      case WM_DESTROY:
         {
            m_pLogic->StopThread();
            WaitForSingleObject( m_pLogic->GetThreadHandle(), INFINITE );
            PostQuitMessage(0);
         }
         break;
      default:
         {
            if ( IsLogicMsg( uMsg ) )
            {
                  PostThreadMessage( m_pLogic->GetThreadID(), uMsg, wParam, lParam );
            }
            else
            {
                  return DefWindowProc( hWnd, uMsg, wParam, lParam );
            }
         }
         break;
      }


在逻辑线程中这般如此：

MSG msg;
      while ( m_bRunning )
      {
         if ( PeekMessage( &msg, NULL, 0, 0, PM_NOREMOVE ) )
         {
            if ( ! GetMessageW( &msg, NULL, 0, 0 ) )
            {
                  return (int) msg.wParam;
            }

            MessageProc( msg.message, msg.wParam, msg.lParam );
         }

         LogicTick();
      }

完成！

5.  3D引擎多线程：逻辑操作

在实际游戏中，逻辑线程需要对渲染对象做许多操作，比如添加与删除，改变渲染对象的属性等等，而由于在先前的设计中，逻辑线程与渲染线程相互独立，如果只是改变某一共享数据，没有问题，但如果操作影响到了场景结构，例如实体的添加与删除，则必须进行线程同步，这又违背了FlagshipEngine的设计初衷——避免繁重的逻辑计算影响渲染速度。

解决办法其实在上一篇中已经提到了，仍然是利用天然的同步机制——Windows消息，添加实体时，逻辑线程只是new了一个Entity对象，设置这个对象的初始共享数据，比如位置信息，同时向渲染线程发送一条WM_ADDENTITY的自定义消息，将Entity指针作为wParam传递。渲染线程接受到消息后调用Entity的UpdateScene方法，更新Entity在场景树中的位置，并加载资源。

删除也是一样，逻辑线程向渲染线程发送WM_DELETEENTITY消息，并不再使用该Entity指针，渲染对象则处理改消息，将此Entity从场景中删除并卸载资源。

这里有一个非常危险的情况，前面一篇提到，资源加载也是通过消息传递实现的，同样是传递的资源指针，如果逻辑线程添加了一个Entity，还没加载就删掉了它，则资源加载线程会拿到一个过期指针，一切就结束了。。。

解决这一问题，最稳妥的方法是消息的wParam并不传递指针，而是传递该Entity或资源的唯一ID，这样的话即使ID过期，也可轻松忽略掉这条消息，坏处是每次消息处理都的从全局的map 里检查是否存在此ID对应的Entity或资源，这可是笔不小的开销。

第二种方案，我们仍然传递指针，只是在接受到WM_DELETEENTITY消息时，检查该Entity是否已经加载完成，如果没有完成，则重新将此消息加入消息队列，下个渲染帧再次判断。

FlagshipEngine的多线程设计大致就是如此了。

6.  DX11 与多线程渲染

前几天突然想起新的DXSDK应该早出了，去微软网站一看，好么。。。2008 Dec版早出了，这次火星了，下载完后居然发现包坏掉了，于是重下。。。还是坏掉！第三次也不行，折腾了一下午，最后放弃了，还好貌似只有Sample的最后一点点没解压开，没什么大碍。

本来只是以为自己只是火星了而已，装好一看，完。。。彻底冥王星了，DX11的Preview版出了！真是又激动又懊悔，粗略看了看，新特性真是太令人激动了，主要有以下几点：

一、SM5.0 从类C变成类C++了，有类有继承有虚函数，太夸张了。。。

二、支持Shader动态 Link，DX9里面就有个 FragmentLinker，不太好用，DX10直接取消了，这次变本加厉的又回来了！

三、渲染的多线程支持，我重点来谈谈这个

DX11提供了一个新的接口：
ID3D11DeviceContext，取代了以前Device接口所有与渲染相关的功能，有两个类型：immediate和deferred，前者和现在的效果一样，收到渲染指令就立即执行，而后者则会将命令缓存起来，由用户决定何时执行。

在例子MultithreadedRendering11中，渲染了三面带反射的镜子和一个人物模型，Sample创建了四个Context，三个 deferred用于镜子反射表面的渲染，一个immediate用于最终场景，Sample创建了三个线程，渲染帧开始时，首先并行的执行三个镜子反射的渲染，完成后，在主线程顺序执行三个Context，然后用immediate的Context渲染最终场景。

由这个例子，我们来展望一下美好的未来：所有的渲染表面都可以并行执行，比如水面、镜子、甚至Shadow Map，并行的进行场景剪裁，使得多核 CPU的使用更有效率。

DX11预计在今年年底推出，于Windows7捆绑，到那时，四核CPU应该已经普及了吧。。。

7.  多Pass渲染体系与多线程渲染的矛盾

最近为了实现多光源和多阴影的渲染，把渲染系统改成了多Pass的，对每一个可见光源进行一次光照、ShadowMap和最终阴影的渲染，虽然这样等于是把整个场景重复渲染了很多次，但为了实现灵活的实时光照系统，这似乎是唯一的办法了。

但实践后发现，阴影和光照会随着骨骼动画的播放而闪烁，甚至镜头的移动也会造成闪烁，究其原因，还是逻辑线程和渲染线程的同步问题，由于对场景内的同一个物体渲染了多次，而逻辑线程又在不停的更新摄像机和骨骼动画数据，导致了两Pass渲染取到的数据很可能不一致，造成了光照和阴影的闪烁。

所以共享数据结构必须做一些修改，在多Pass渲染开始前进行一次备份，渲染中只取备份数据，这样就保证了多次渲染的数据一致性了

也就是加这么两个简单的set和get方法，在渲染相关数据读取时调用get，逻辑相关时调用read

template
struct SharedData
{
      T       m_pData[DATACENTER_CACHE];
      T       m_kCloneData;
      int    m_iIndex;

      SharedData()
   {
         ZeroMemory( m_pData, DATACENTER_CACHE * sizeof(T) );
         m_iIndex = 0;
      }

      void Write( T& rData )
   {
         int iNewIndex = m_iIndex == DATACENTER_CACHE - 1 ? 0 : m_iIndex + 1;
         m_pData[iNewIndex] = rData;
         m_iIndex = iNewIndex;
      }

      T& Read()
   {
         return m_pVector[m_iIndex];
      }

      void Set()
   {
         m_kCloneData = Read();
      }

      T&    Get()
   {
         return m_kCloneData;
      }
};

8.  几种多线程3D引擎架构的比较

首先我们得明确3D引擎使用多线程的目的所在：
1、在CPU上进行的逻辑计算（比如骨骼动画粒子发射等）不影响渲染速度
2、较差的GPU渲染速度的低下不影响逻辑速度


第一个目标已经很明确了，我来解释下需要达到第二个目标的原因：许多动作游戏的逻辑判定是基于帧的，所以在渲染较慢的情况下，逻辑不能跳帧，而仍然需要严格执行才能保证游戏逻辑的正确性，这就导致了游戏速度的放慢，而实际上个人认为渲染保持15帧以上就已经可以正常进行游戏了。

在较差的GPU上跑《鬼泣4》《刺客信条》《波斯王子4》简直就像是慢镜头一样，完全没法玩。而实际上CPU跑满帧是没有问题的，如果能把逻辑帧和渲染帧彻底分离，即使渲染帧达不到要求，但CPU仍能正确的执行游戏逻辑，就可以解决动作游戏对GPU要求过高的问题。


我们先来看多线程Ogre的两种架构，第一种是middle-level multithread

如上图所示，每个需渲染的实体被复制成了两份，主线程和渲染线程交替更新和渲染同一个实体的两个备份，并在一帧结束时同步，这种解决方案达到了第一个目标而并没有达到第二个目标，同时两份实体的维护也相对复杂，并且没法为更多核数的CPU进行扩展优化。

第二种Ogre多线程的方法是 low-level multithread

如图，将D3D对象复制两份，同样是在帧结束时同步并交换，和上面的优缺点类似。两种多线程Ogre的解决方案都是在引擎层完成的，对上层应用透明，对于用户而言无需考虑多线程细节，这点是非常不错的。

接下来我们来看SIGGRAPH2008上，id soft提出的多线程3D引擎的方案

这里是已PS3的引擎结构为例的，与PC有较大的差别，其中SPU是Cell芯片的8个协处理器，拥有强大的并行能力，id的解决方案在SPU上进行了诸如骨骼动画、形变动画、顶点和索引缓存的压缩、Progressive Mesh的计算等诸多内容，同时与PPU上的物理计算RSX上的渲染工作交错进行，最大化的利用了PS3的硬件结构，最终的游戏产品《Rage》很快就会面世了！

最后是我的解决方案

特点是逻辑完全分离，无需同步，虽然成功的达到了文章开始提出的两个目标，但对于引擎的使用者必须考虑多线程的诸多问题，各种计算需放在哪个线程，如何在两个线程间交互，都需要深入思考，所以要应用到实际的游戏制作，恐怕还有很长的一段路要走。

结合目前的架构和上面看到的几种多线程架构，同时也为了迎接DX11的到来，我准备将我的方案进一步改进成如下所示

场景剪裁与提交渲染交替进行，并在渲染帧末进行一次同步，而多个渲染表面的场景剪裁可再并行执行。

图片多，文字少，需更详细资料请自行google，本文就此结束！

from http://www.cppblog.com/flagship/category/9250.html

魔鬼螳螂 2011-03-02 18:43 发表评论

Dx 10 与 Dx 9 的一些技术区别(转)

魔鬼螳螂 — Fri, 11 Feb 2011 06:47:00 GMT

本文件来自：http://blog.csdn.net/codeboycjy/archive/2009/11/29/4900467.aspx

引言：
DX10发布已经有一段时间了，网上可以查到很多关于Dx9与10的区别的文章。但是大多数都是从玩家角度考虑的。只是展示一下Dx9和Dx10分别渲染出的图片，并且Dx9所渲染的图片经常会缩水很多，目的就是为了展示出Dx10的强大。给大多数人的理解就是，DX10能做出比Dx9好很多的画面。我并不否认Dx10比Dx9优化了很多，但是随便展示出两张图片进行对比，其实意义也不是特别的大。因为我们不知道帧率的对比。而且虽然很多新的技术在Dx9 里面没有，但是还是有一部分可以用其他方法模拟出来的，只是效率上有所下降。

本文简单介绍了DX10和DX9的一些技术上的区别。从程序员的角度看DX10比DX9优势的地方。适合对于Dx有一定了解的朋友。

正文：
在Windows 98的年代里，GDI和DirectX是完全独立的两个接口。GDI（Graphical Device Interface）是专门用于二维图形显示的接口，封装了一些基本的功能，效率相对DirectX来说要低一些。而DirectX是专门用于游戏开发领域的，它允许用户通过这个接口直接与硬件交互。但是这两个接口之间的交互是非常受限制的，主要原因就是由于底层的驱动架构：

我们看到，在这个驱动模型里面，底层的硬件驱动都是独立的两部分。直到Windows Vista的发布，微软更新了底层的驱动模型

在这个新的驱动架构下，所有的图形接口都是基于DirectX Runtime的。这就为GDI和DirectX交互提供了可能，这也是Vista能够提供更好的用户界面体验的一个重要原因。DirectX9为了向下兼容，所以不得不做一些妥协的工作。例如当VRAM的占用超出了一定界限的时候，Dx9会发出error，而这并不是因为驱动无法提供更多的VRAM。事实上，底层驱动完全可以提供几乎无限的VRAM，但是为了向下兼容其他比较旧的显卡，因为这些卡在这里面可能会出现问题，所以Dx9还会出现Error。由于这种向下兼容的被迫妥协，不免使得Dx9在Vista下的表现不能完全利用底层的优势。对于Dx熟悉的朋友可能会注意到，在Dx9与Dx10之间，有一版Dx 9Ex。这一个版本的Dx是不能在XP下运行的，因为它更多的利用了新的驱动模型的优势，需要新的驱动模型才可以支持。而XP下的驱动模型还是上面的模型。Dx10是完全建立在新的驱动模型下面的全新的接口，它在Vista下可以完全发挥底层设计的优势。但是也同样需要WDDM的支持，这就是DX10不能在XP下运行的最主要的原因了。

简单从底层介绍了一下Dx9与Dx10的区别（希望了解更深入的朋友，可以查看DX SDK里面的Graphics APIs in Windows那篇文章）。那么下面我来介绍一下从编程接口角度看，DX10为我们带来了一些什么样的变化：

完全的可编程管线：
在DX10里面，是没有固定管线的。如果程序员想用这个接口渲染图形的话，就必须自己写Shader脚本来实现图元的现实。事实上，在大多数次时代的三维游戏中，几乎很少有单纯的固定管线渲染的图元了。因为Phong模型的表现力毕竟还很有限，只通过diffuse, specular等一些简单的属性描述出的东西很难让人信服。可能唯一大量需要固定管线的部分就是二维图形UI部分了。如果UI不是特别复杂，只是渲染二维图片的话，固定管线的功能也就很方便了。不过实现一个模拟固定管线的Shader脚本也并不是什么麻烦事情，所以即使Dx10没有固定管线，也对程序员来说，也不是什么损失了。

完全的HLSL脚本编写：
对于早期的可编程管线有了解的朋友，可能会想起来，在Dx8的时候是可以用类汇编语言来编写Shader脚本的。在Dx9可以用两者任意一个来编写Shader了。但是在DX10里面，是不可以用汇编来写shader脚本的。

Shader Model 4.0：
在Dx10里的Shader是基于Shader Model 4.0的。具体细节我不是很清楚，但是SM 4.0有更多的指令数。如果实现个多光源的效果，可能在SM2.0里面只能做到8个（当然不排除能做更多个），是因为指令数目是有限制的。那么在新的 SM4.0里面，肯定是可以实现更多的光源数目了。当然这只是一个例子而已，而且多光源技术也不是什么先进的东西，很多场景中都被延迟光照所取代了。

没有CAPS：
在Dx9里面，程序员经常会查询那些功能是被硬件所支持的，哪些是不能的。而在Dx10里面，CAPS的概念就被移除了。一块显卡或者支持DX10的所有特性，或者干脆就不是块DX10显卡。那么意味着程序员可以使用DX10的一切功能而不需要在这之前查询当前硬件是否支持这项功能。

Geometry Shader:
GS是DX10新推出的一个概念。它是在VS和PS之间的一个GPU Kernel类型，负责接收由VS处理后的顶点，然后可以生成新的顶点，重新做处理。举一个简单的例子，粒子系统，假设有1k个粒子。那么每帧实际需要从 CPU传输到GPU的数据是1K*4，因为每个粒子由四个顶点组成。而这些数据是要走PCIE总线的，这个总线的带宽的效率远远不及GPU On Chip Memory的。如果有了GS，我们完全可以只传输每个粒子的中心，然后GS由粒子中心信息生成新的顶点。那么这样以来，就可以省下四倍的传输。当然这只是一个简单的例子而已，而且即使在DX9上渲染粒子系统，粒子的更新如果用GPU来处理的话，完全可以不传输每个粒子的信息。

Shader脚本开始支持整型数据：
在DX9里面，实际上Shader中是没有整数的概念的。即使在VS或者PS里面声明一个int，其实硬件通过float的转换来处理的。在DX10里面，是有对于整数的支持的。可以对整数进行位运算等操作，这些都是在硬件上实现的。输入的纹理的数据类型也可以是整型的。

贴两张网上对比Dx9和Dx10的效果图吧，^_^。

左边的两张是Dx9的右边是Dx10的。

DX10有了这些变化后，可以方便程序员进行开发。但不是说DX10可以做到的东西，DX9就完全做不到，只不过是DX10的效率更高一些。我们看上面的对比图，其实如果做一个fake的光照效果，左下角的图完全可以用DX9模拟出来（个人感觉只是右边加上了点后处理特效而已）。举另一个例子来说，用 DX10做阴影效果，Shadow Volumn可以在GPU端利用GS来生成，然后用Stream-out功能把生成的资源再利用，从而做出这个效果。但是我们也同样在DX9上看到了 Shadow Volumn的Demo。其实效果是差不多的，主要区别在于前者利用了GPU去生成Shadow Volumn，这个任务本身就是一个并行的过程，GPU处理要优于CPU处理。而且渲染是在GPU端进行的，如果利用CPU生成的数据，就必须把数据通过 PCIE传输到显卡上，这些也是很耗时的过程。当然，如果实在要用DX9在GPU端生成Shadow Volumn，还可以通过CUDA，OpenCL等一些通用计算接口来帮助处理。但是这样会给程序很大限制，因为AMD和Nvidia有各自不同的解决方案，如果你用了其中一家的，就很难在另一家的卡上Work（OpenCL除外）。

基本上就介绍这些内容吧，我了解的还很少，很多东西是查资料的。如果有什么错误的地方，欢迎和我交流。^_^

魔鬼螳螂 2011-02-11 14:47 发表评论

shader复杂与深入：Normal Map（法线贴图）2

魔鬼螳螂 — Mon, 29 Nov 2010 09:58:00 GMT

在前文中我尽可能地把我所理解Normal Map原理总结了一下，本续篇将从实践部分继续开始，各位看官尽情拍砖。——ZwqXin.com
上篇见：[shader复习与深入：Normal Map(法线贴图)Ⅰ]
1. 怎样获得顶点的TBN
其实我觉得这个是实践部分最麻烦的地方。OpenGL提供了诸如glNormal、normal-vbo之类的接口设置顶点的法线，然后在shader中以gl_Normal等方式取得顶点法线数据，但是没有提供切线和副法线的。当然两者只要其一就足够了（另一者可通过叉乘和左/右手定则获得）。因为要把TBN导入shader，干脆就设置attribute变量，记录每个顶点的切线。切线一般就是相邻顶点的差向量了（其实这有时候是非常繁重的工作）。
如果是通常的3DS模型的话，顶点法线是共顶点的面的面法线的加权，这样法线就不一定垂直于某个面，即与切线不垂直。但只要它们还是近似垂直的，上篇提及的Gram-Schmidt 算法应该可以处理。或者在shader中，把法线与切线叉乘出副法线，再用法线与副法线叉乘得新的切线，也能确保两两垂直。这样之前的TBN矩阵的转置矩阵就能直接作为其逆矩阵，完成向量从模型坐标系往切线空间坐标系的变换了。
问题不只这样。对于一些模型，共享顶点的三角面片面法线差角太大，这时候计算出的该顶点法线和切线就可能带来麻烦。在橙书（OpenGL Shading Language）中，谈及了切线必须是一致的（consistently），面片相邻的顶点切线不应该差距太大。但若相邻面片夹角太大，得到的该顶点法线就可能与“共享该顶点的面片”上的其他顶点的法线差异很大，从而切线也会相差很大，直接导致光向量等在这两顶点的切线空间差异很大，插值的各个针对像素的光向量方向差异很大，与像素法线点乘的cos也会差异得很明显（而现实中一般的凹凸面漫反射光线不会有太大方向差异）。解决方法是把该出了问题的顶点拆成两个（原地拷贝，3DS模型就不用了- -），一个面片用一个，其法线只受所属的面片的面法线决定（这样最后会形成突出的边缘，但夹角大的面片之间实际上就应该会是有这样的效果吧）。
另一个问题，我们向shader传入顶点法线切线，希望副法线由两者叉乘得出。但既然叉乘就有个方向问题（结果可以有两个方向，AXB与BXA是不一样的，我以前弄shadow volume就曾被它这种特性作弄过）。AXB改成BXA实际上会导致凹凸感反向，原来凹的变凸了，原来凸的变凹了（要仔细比对，不然会有首因效应）。一般就用N X T吧，因为基本上都是这个顺序的，结果也符合原Normal Map。
2. GLSL 1.2 Shader实现代码
没什么好说的，就是前面算法翻译成GLSL。
Vertex Shader：

// vertex shader
uniform vec3 lightpos; //传入光源的模型坐标吧
uniform vec4 eyepos;

varying vec3 lightdir;
varying vec3 halfvec;
varying vec3 norm;
varying vec3 eyedir;

attribute vec3 rm_Tangent;

void main(void)
{
   vec4 pos = gl_ModelViewMatrix * gl_Vertex;
   pos = pos / pos.w;

//把光源和眼睛从模型空间转换到视图空间
   vec4 vlightPos = (gl_ModelViewMatrix * vec4(lightpos, 1.0));
   vec4 veyePos   = (gl_ModelViewMatrix * eyepos);

   lightdir = normalize(vlightPos.xyz - pos.xyz);
   vec3 eyedir = normalize(veyePos.xyz - pos.xyz);

//模型空间下的TBN
   norm = normalize(gl_NormalMatrix * gl_Normal);

   vec3 vtangent = normalize(gl_NormalMatrix * rm_Tangent);

   vec3 vbinormal = cross(norm,vtangent);

   //将光源向量和视线向量转换到TBN切线空间
   lightdir.x = dot(vtangent, lightdir);
   lightdir.y = dot(vbinormal, lightdir);
   lightdir.z = dot(norm     , lightdir);
   lightdir = normalize(lightdir);

   eyedir.x = dot(vtangent, eyedir);
   eyedir.y = dot(vbinormal, eyedir);
   eyedir.z = dot(norm     , eyedir);
   eyedir = normalize(eyedir);

   halfvec = normalize(lightdir + eyedir);

   gl_FrontColor = gl_Color;

   gl_TexCoord[0] = gl_MultiTexCoord0;

   gl_Position = ftransform();
}
// vertex shaderuniform vec3 lightpos; //传入光源的模型坐标吧uniform vec4 eyepos;varying vec3 lightdir;varying vec3 halfvec;varying vec3 norm;varying vec3 eyedir;attribute vec3 rm_Tangent;void main(void){   vec4 pos = gl_ModelViewMatrix * gl_Vertex;   pos = pos / pos.w;   //把光源和眼睛从模型空间转换到视图空间   vec4 vlightPos = (gl_ModelViewMatrix * vec4(lightpos, 1.0));   vec4 veyePos   = (gl_ModelViewMatrix * eyepos);      lightdir = normalize(vlightPos.xyz - pos.xyz);   vec3 eyedir = normalize(veyePos.xyz - pos.xyz);     //模型空间下的TBN   norm = normalize(gl_NormalMatrix * gl_Normal);   vec3 vtangent = normalize(gl_NormalMatrix * rm_Tangent);   vec3 vbinormal = cross(norm,vtangent);      //将光源向量和视线向量转换到TBN切线空间   lightdir.x = dot(vtangent, lightdir);   lightdir.y = dot(vbinormal, lightdir);    lightdir.z = dot(norm     , lightdir);   lightdir = normalize(lightdir);      eyedir.x = dot(vtangent, eyedir);   eyedir.y = dot(vbinormal, eyedir);   eyedir.z = dot(norm     , eyedir);   eyedir = normalize(eyedir);      halfvec = normalize(lightdir + eyedir);   gl_FrontColor = gl_Color;      gl_TexCoord[0] = gl_MultiTexCoord0;      gl_Position = ftransform();}
传入的lightPos，eyePos，gl_Vertex，gl_Normal，rm_Tangent是其模型坐标系下的坐标、向量，乘以ModelView矩阵（法线切线乘以ModelView矩阵的转置逆矩阵）到了视图空间（vlightPos，veyePos，pos，norm, vtangent）；在视图空间它们已经有了“世界”的概念了，因此可以平等地相互影响（在各自封闭的模型空间是享受不了的），可以作各种点乘叉乘加减乘除计算。
注意，lightPos，eyePos虽说是在其各自模型坐标系下定义的，但不对它们弄什么平移旋转缩放操作的话，其模型矩阵就是一单位阵，此时其“世界坐标 == 模型坐标”。所以这时我可以当它是在世界空间定义的坐标（实际上一般我们都会在世界空间定义这两个点）。（注意，前提是不对它们做模型变换。）
从以上量得到光源向量、视线向量后（它们在视图空间），N、T叉乘得B（注意它们现在都在视图空间），通过TBN矩阵逆矩阵把两向量变换到当前顶点的切线空间，交给光栅去插值。
对以上有不理解的朋友，可能是没看上篇：[shader复习与深入：Normal Map(法线贴图)Ⅰ]
fragment shader：

//fragment shader
uniform float shiness;
uniform vec4 ambient, diffuse, specular;

uniform sampler2D bumptex;
uniform sampler2D basetex;

float amb = 0.2;
float diff = 0.2;
float spec = 0.6;

varying vec3 lightdir;
varying vec3 halfvec;
varying vec3 norm;
varying vec3 eyedir;

void main(void)
{
   vec3 vlightdir = normalize(lightdir);
   vec3 veyedir = normalize(eyedir);

   vec3 vnorm =   normalize(norm);
   vec3 vhalfvec = normalize(halfvec);

   vec4 baseCol = texture2D(basetex, gl_TexCoord[0].xy);

   //Normal Map里的像素normal定义于该像素的切线空间
   vec3 tbnnorm = texture2D(bumptex, gl_TexCoord[0].xy).xyz;

   tbnnorm = normalize((tbnnorm - vec3(0.5))* 2.0);

   float diffusefract = max( dot(lightdir,tbnnorm) , 0.0);
   float specularfract = max( dot(vhalfvec,tbnnorm) , 0.0);

   if(specularfract > 0.0){
   specularfract = pow(specularfract, shiness);
   }

   gl_FragColor = vec4(amb * ambient.xyz * baseCol.xyz
                 + diff * diffuse.xyz * diffusefract * baseCol.xyz
                 + spec * specular.xyz * specularfract ,1.0);
}
//fragment shaderuniform float shiness;uniform vec4 ambient, diffuse, specular;uniform sampler2D bumptex;uniform sampler2D basetex;float amb = 0.2;float diff = 0.2;float spec = 0.6;varying vec3 lightdir;varying vec3 halfvec;varying vec3 norm;varying vec3 eyedir;void main(void){   vec3 vlightdir = normalize(lightdir);   vec3 veyedir = normalize(eyedir);   vec3 vnorm =   normalize(norm);   vec3 vhalfvec = normalize(halfvec);        vec4 baseCol = texture2D(basetex, gl_TexCoord[0].xy);       //Normal Map里的像素normal定义于该像素的切线空间   vec3 tbnnorm = texture2D(bumptex, gl_TexCoord[0].xy).xyz;      tbnnorm = normalize((tbnnorm - vec3(0.5))* 2.0);       float diffusefract = max( dot(lightdir,tbnnorm) , 0.0);    float specularfract = max( dot(vhalfvec,tbnnorm) , 0.0);      if(specularfract > 0.0){   specularfract = pow(specularfract, shiness);   }      gl_FragColor = vec4(amb * ambient.xyz * baseCol.xyz                 + diff * diffuse.xyz * diffusefract * baseCol.xyz                 + spec * specular.xyz * specularfract ,1.0);}
注意把normal map里的normal由(0,1)映射回(-1,1)。baseCol得到的是基底纹理的像素颜色。其余部分就是per pixel lighting的东西了。[Shader快速复习：Per Pixel Lighting(逐像素光照)]

(上为底纹理和法线纹理，下为它们与某破壁模型合作的效果，纹理from planetpixelemporium.com)

(我想是游戏最常用的用途：砖墙。我想是最常用的NormalMap,from NEHE)

(自己把墙壁BaseMap放入Photoshop的normalMapFilter里弄的NormalMap，呃.....)

本文来源于ZwqXin http://www.zwqxin.com/ , 转载请注明
原文地址：http://www.zwqxin.com/archives/shaderglsl/review-normal-map-bump-map-2.html

魔鬼螳螂 2010-11-29 17:58 发表评论

shader复杂与深入：Normal Map（法线贴图）1

魔鬼螳螂 — Mon, 29 Nov 2010 09:53:00 GMT

转自：http://www.zwqxin.com/archives/shaderglsl/review-normal-map-bump-map.html
Normal Map法线贴图，想必每个学习计算机图形学的人都不陌生。今天在这里按我的理解总结一下，作为复习，也作为深入学习吧。——ZwqXin.com
自从看完那本《数学在计算机图形学上的应用》后，一直想好好地真正实践一次法线贴图/凹凸贴图呢（以前是根据橙书弄了一下罢了）。昨天偶尔看到篇涉及BumpMap的文，正好觉得是个机会，便在网上狂找相关资料——果然，越看越觉得自己还有很多理论的地方需要弄明白呢。
说起Normal Map（法线贴图），就会想起Bump Map（凹凸贴图）。Bump Mapping是Blin大师在1978年提出的图形学算法，目的是以低代价给予计算机几何体以更丰富的表面信息（高模盖低模）。30年来，这项技术不断延展，尤其是计算机图形学成熟以后，相继出现了不少算法变体，90年代末的Normal Map解放了必须自行计算纹理像素法线的痛苦，新世纪以来相继又出现了Parallax Mapping, Relief Mapping等技术。抛开那些无聊的概念区分，它们的本体还是Bump Map，目的也是一致的。
1. 传统的Bump Map
如果你对纯净的Bump Map有兴趣，A Practical and Robust Bump-mapping Technique for Today's GPU应该是值得一看的论文。说Today，其实是GDC 2000的事情了，但对于传统的Bump Map的理论是很丰富的，我是没精力看完它啦……
那时候的Bump Map须要我们计算纹理图上每个像素的法线信息，简单的还可能做到，对复杂的纹理要搞清面光背光份量简直要命，于是就用Height Map，在一张高度图上记录每个像素对应的纹理位置的高度信息（这个比较容易办到，NEHE22也是这类）。看上去就是一张地形网格——这样的话，计算每个像素点的法线就不那么难了。XY方向相邻像素的高度相减就是两条正交的切向量，叉乘外加左/右手定则就获得法线。或者更精确点，用八邻域弄个边缘检测算子（sobel、拉普拉斯之类）[图像处理里的空间域滤波]，或者应用斜坡法([水效果Ⅲ - 抖动波] )来求切线、法线。

2. 制作NormalMap
但是这样还是挺麻烦的，既然都动用额外的贴图了，何不把这些与实现无关的预处理——作为结果的法线信息——都放进纹理里呢？这就是Normal Map的思想起源。但是，谁来做这样的一张法线图呢？敲定美工了。每个像素的RGB分别存储该像素对应法线的XYZ分量，只要把法线的分量由（-1，1）映射成（0，255）就可了。观察一张法线图，以蓝色为主，是因为朝向图面外的法线（0，0，1）都被编码成（0，0，127）了（读入OpenGL后即(0,0,0.5)），而图上越红的地方表明法线越向右，越绿的地方表明法线越向上，就可以理解了。总体来说，就是一张紫蓝色的图。怎么做这样的图呢？当然最好是有一个工具，输入原图和高度图后执行上述的算法得出新图了，事实上已经有很多这类工具了（譬如比较著名的photoshop的NV插件Normal Map Filter，甚至不用高度channel也可[效果- -]），以下几篇文章有详细介绍，有兴趣的可以看一看：
Tutorial On Normal Mapping （PHOTOSHOP [ENGLISH]）
怎样用PhotoShop创建Bump Map图像（PHOTOSHOP [CHINESE]）
Nvidia Normal Map 插件参数之详解 (PHOTOSHOP [翻译])
GIMP normalmap plugin (GIMP [ENG]）
关于NormalMap制作的原理，更详细的可参考此文：Normalmap原理及去除接缝
3. 切线空间(Tangent Space)
其实这个概念前文已经提及了。每个像素根据高度图生成的三轴坐标系，就是被称为切线空间坐标系的东西，每个像素人手一个。可见Normal Map里面每个像素的法线就是定义在这个切线空间的。注意，这些法线是属于像素的，而不是顶点，我们平时用的法线是顶点法线，是定义在模型坐标系的[乱弹OpenGL中的矩阵变换(上)] ，定义于所属物件的唯一的局部坐标系原点之上。而这些像素法线定义于切线坐标系，其原点就在该像素上，切线副法线在法线的垂直平面上。

（表面依然是平的，但通过搅动法线，使进入我们眼睛的光线强度不一，模拟出凹凸面漫反射的特点。图from GDNet）
应用这些像素法线的目的无非是计算出该像素的OutPut颜色：col = baseColor * (amb + diffuse) + specular。这些都应该在像素着色器（fragment shader）里进行，因为我们要做的是针对每个像素的处理[Shader快速复习：Per Pixel Lighting(逐像素光照)] 。其中需要用到像素法线的是diffuse和specular（以前是用通过顶点法线线性插值而来的normal），法线分别与光线向量、半向量作点乘得到对应因子。这个因子是个夹角cos而已，所以只要满足像素法线与两个向量单位化并在同一坐标系下（而无论是哪个坐标系），夹角就是一定的。这样看来，两个选择：
1. 把像素法线都从各自的切线空间转到视图空间来，再点乘；
2.把光线向量、半向量从视图空间转到像素各自的切空间来，再点乘。
很多文章一口咬定就是第2种好，原因是第1种要变换N个量；第2种只变换2个量。仔细分析，其实两种选择变换的次数是一样的，都是2*N。说第2种好，是因为：
第1种必须在fragment shader里进行，对象是从Normal Map读出的像素法线和经过线性插值而来的两个向量，它们不是同一坐标系的，按描述应该是各像素法线乘以各自一个的变换矩阵，转到视图空间来，但确实没有其他的可提供构筑这个矩阵的信息了，若有可能应该就是另外的varying变量传入了；
第2种可以选择在vertex shader里进行，但是能不能就在这里变换到切线空间呢？假设可以，那么得到的针对顶点的数值在光栅化-线性插值后能否满足呢？
要回答这个问题，还得考虑像素的切线空间和顶点的切线空间之间的关系。是的，顶点法线也可以变换到切线空间，但这有什么用呢？一步一步来吧。先考虑切线空间在OpenGL世界里的次元位置：

(from paulsprojects)
为什么是紧挨模型坐标系呢？其实想想也能理解，在上面谈及切线坐标系的时候，并没有广阔的“世界”这个概念。只针对每个像素/顶点，无疑是比模型坐标系更狭隘的“世界观”，所以那个位置是适合的（箭头方向无所谓，坐标系之间是可以相互转换的）。其实对于某个具体的物体上的像素/顶点，你可以考虑那是把模型空间的原点平移到该像素/顶点上，各模型坐标系方向轴向量一起经过旋转，使Z轴与像素/顶点的法线重合，XY轴分别与像素/顶点的切线副法线重合——这只是一个仿射变换而已，如同模型/世界/视图空间之间的变换一样。
如果你记得图形学书上关于世界/视图空间的变换矩阵的构建的话，就更容易理解这样的形式了。从切线空间到模型空间的变换矩阵（TBN矩阵MTBN）为：

其中T，B，N是定义在模型空间的该像素/顶点的“切/副法/法向量”。稍微检验一下，考虑某个三角面上的某个顶点，其法线充当切线空间的Z轴，在切线空间中表示为（0，0，1），在OpenGL里解释为一个列向量（0，0，1）T，用上面的矩阵MTBN左乘该向量，得到（Nx，Ny，Nz）T，正是该向量在模型空间的表示。其他两轴同理。说明该矩阵把切线空间的坐标系统转换到模型空间了（一切变换都是在变换坐标系[乱弹OpenGL中的矩阵变换(上)] ）。当然这是特例说明，但确实这个矩阵包含仿射矩阵里的旋转元素了（它只包含旋转，不设置平移，是因为我们只需要它来变换向量，向量是可以任意平移的，若要弄完整的4X4矩阵，第4列平移列就是该顶点模型坐标）。具体推导也不难，随便Google一下"tangent space"就出来一堆了，而且都是基本一样的推导过程，推一个：Tangent Space。
其逆变换（矩阵MTBN-1）就可以把向量从模型空间变换到对应顶点的切线空间了。如果你确保T，B，N两两垂直，这个正交矩阵的逆矩阵就是其转置矩阵，这很理想。但万一你不确保这点（涉及到具体应用，很多问题的，后面会说），就保证它们大致满足三叉状，用所谓的Gram-Schmidt 算法矫正：
T′ = T − (N · T)N
B′ = B − (N · B)N − (T′ · B)T′
反正最后得到的是这样的形式——用它左乘光源向量和半向量，就得到对应于该顶点切线空间的光源向量和半向量了：
T′x
B′x
NxT′y
B′y
NyT′z
B′z
Nz

为什么是顶点？因为这是你唯一能取得其切线/副法线/法线的东西了。这也是之前说的选择1不行的原因，在那张Normal Map里面已经没有任何法线副法线的确实信息了（只知道它们在法线垂直平面上），即使能通过别的方法取得（起码要增加传入数据），那要在fragment shader里每像素人手又计算一个矩阵，这就又是一个“计算量”（不是次数）的问题。所以还是用选择2吧，也就是上面矩阵MTBN-1的讨论。
选择2的第一个问题现在很清楚了：是可以的。只要取得顶点的切线/副法线/法线数据就能建立矩阵并变换光源向量和半向量，但结果是针对顶点的，我们需要的是针对像素的。光栅化线性插值这两个向量，就是对应像素的值，但这对吗？直觉上不对，但结果显示这样做没有不妥（或者说不会与真实所须差太多）。一般文章都没有直接透视这个问题，其实考虑一个矩形平面就露馅了，它四个顶点的TBN一致，变换得的光源向量也该一致，插值后得光源向量也该一致，但NormalMap中的像素有各自不同的切线空间系统，光源向量不该一致的呃（虽则同向光源、不同法线足够形成凹凸效果）。所以我对选择2的第二个问题保持疑问，有道深者请为鄙人指点迷津！
反正即使计算两向量夹角的计算可能会有偏差，也不会太离谱，问题到此结束。至于有的文章提及对diffuse的计算，光源向量插值后不须再归一化的问题（我尝试过，整体会变暗一点），就不深入了。注意我们在vertex shader里变换到切线空间的是模型空间下的光源向量和视线向量（半向量是它们的和），而一般这两个向量定义在视图空间，所以之前还要做一个视图空间->模型空间的变换（用ModelView矩阵的逆矩阵）。这是很多文章囫囵掉的一点。但如果你能取得视图空间下的顶点TBN，也不需。因为切线/副法线/法线若是被变换到视图空间，则上面的TBN矩阵MTBN就是把东西从该顶点的切线空间变换到视图空间（道理是一样的），MTBN-1就能把视图空间下的这两个向量变换到该顶点的切线空间（参见下篇的代码）。
最后的问题：怎么去取得模型空间下的顶点的切线，副法线，法线？连同shader实现代码一起，我会在下篇谈及，请留意了哦。

本文来源于ZwqXin http://www.zwqxin.com/ , 转载请注明
原文地址：http://www.zwqxin.com/archives/shaderglsl/review-normal-map-bump-map.html

魔鬼螳螂 2010-11-29 17:53 发表评论

Cascaded shadow map（转）

魔鬼螳螂 — Wed, 24 Nov 2010 02:20:00 GMT

摘要: 转自：http://class.gd/content/shadow-map%E9%98%B4%E5%BD%B1%E8%B4%B4%E5%9B%BE%E6%8A%80%E6%9C%AF%E4%B9%8B%E6%8E%A2%E2%85%A2本文来源：http://www.zwqxin.com/archives/opengl &n... 阅读全文

魔鬼螳螂 2010-11-24 10:20 发表评论

Light Pre Pass in XNA: Basic Implementation

魔鬼螳螂 — Sun, 15 Aug 2010 02:01:00 GMT

摘要: 转自：http://mquandt.com/blog/2009/12/light-pre-pass-in-xna-basic-implementation/ NOTE: This article is now obsolete. An up-to-date sample and article can be found at http://mquandt.com/blog/2010/03/lig... 阅读全文

魔鬼螳螂 2010-08-15 10:01 发表评论

一起学习Shadow mapping

魔鬼螳螂 — Sun, 21 Mar 2010 12:15:00 GMT

转自：http://www.cnblogs.com/cxrs/archive/2009/10/17/1585038.html
1、什么是Shadow Maping?
      Shadow Mapping是由Lance Williams于1978年在一篇名为"Casting curved shadows on curved surfaces"的文章中提出的，这篇文章是ShadowMap技术之根源。其实原理很简单，如果光源和目标点之间的连线没有任何物体阻挡的话，则目标点没有在阴影中;如果有物体遮挡，则目标点处在阴影中。而ShadowMap，就是一张记录了每个象素处用于比较遮挡关系信息的Texture.
      产生这个ShadowTexture的方法很简单，以SpotLight为例，把3D Camera放到光源的位置，把DepthTest打开，渲染场景，在PixShader中把每个象素的深度信息或者光源和此象素的距离信息写到RenderTarget上,由于DepthTest是打开的，保证了最终写到RenderTarget上的均是物体上未处在阴影中的点的深度值，实质完全可以等效为最终的DepthBuffer。
     得到这个ShowMap之后，如何最终生成阴影呢？在PixShader对每个pixel进行处理时，算出当前象素与灯当的距离Dc，与存在ShdowMap中的引像素的值Dz进行比较，如果Dc > Dz,则在阴影中，反之则被灯光照亮。
2、Shadowmap之HLSL的实现
    在Direct SDk中有ShadowMap的Sample，下面的Shader和Sample里面空全一样，只是加了一些注释便于理解。
    (1)生成ShadowMap的VS和PS

//-----------------------------------------------------------------------------
// Vertex Shader: VertShadow
void VertShadow( float4 Pos : POSITION,
                 float3 Normal : NORMAL,
                 out float4 oPos : POSITION,
                 out float2 Depth : TEXCOORD0 )
{
    //从模型坐标系变换到观察坐标系
    oPos = mul( Pos, g_mWorldView );
   //进行投影变换
   oPos = mul( oPos, g_mProj );
   //把投影坐标系的ZW值赋给Depth，作为PixelShader中的输出，这里的Z还是齐次坐标，这里不直接输出Z/W，我的理解是让Z和W都在Rasterizer中进行线性插
//值，这样可以增加最终生成的ShadowMap的精度。
    Depth.xy = oPos.zw;
}
//-----------------------------------------------------------------------------
// Pixel Shader: PixShadow
void PixShadow( float2 Depth : TEXCOORD0,
                out float4 Color : COLOR )
{
    // 把 z / w的值作为Color值输出，写到RenderTarget上，此时的RT formate是D3DFMT_R32F
   //把Z/W目的是把齐次坐标Z变换到三维空间的非齐次坐标，范围则是[-1,1]
    Color = Depth.x / Depth.y;
}

(2)用ShadowMap生成Shadow

//-----------------------------------------------------------------------------
// Vertex Shader: VertScene
// Desc: Process vertex for scene
//-----------------------------------------------------------------------------
void VertScene( float4 iPos : POSITION,
                float3 iNormal : NORMAL,
                float2 iTex : TEXCOORD0,
                out float4 oPos : POSITION,
                out float2 Tex : TEXCOORD0,
                out float4 vPos : TEXCOORD1,
                out float3 vNormal : TEXCOORD2,
                out float4 vPosLight : TEXCOORD3 )
{
    vPos = mul( iPos, g_mWorldView );
    oPos = mul( vPos, g_mProj );
    vNormal = mul( iNormal, (float3x3)g_mWorldView );
    Tex = iTex;
    //把当前顶点位置变换到以光源为Camera的投影空间，
    vPosLight = mul( vPos, g_mViewToLightProj );
}

//-----------------------------------------------------------------------------
// Pixel Shader: PixScene
// Desc: Process pixel (do per-pixel lighting) for enabled scene
//-----------------------------------------------------------------------------
float4 PixScene( float2 Tex : TEXCOORD0,
                 float4 vPos : TEXCOORD1,
                 float3 vNormal : TEXCOORD2,
                 float4 vPosLight : TEXCOORD3 ) : COLOR
{
    float4 Diffuse;

// 计算光源到当前象素方向向量并单位化
float3 vLight = normalize( float3( vPos - g_vLightPos ) );

    //  dot( vLight, g_vLightDir )为光源到当前象素方向向量和光的方向向量之间的夹角余旋值，由于是spotlight，因此必须要在spotlight可照射的范围内。因为角
    //度越小余旋值越大，因此这里是大于
    if( dot( vLight, g_vLightDir ) > g_fCosTheta )
    {
        // Pixel is in lit area. Find out if it's
        // in shadow using 2x2 percentage closest filtering

        //从投影空间坐标转化为纹理空间坐标，也就是找到投影空间中的点和纹理空间中的点的对应关系
       //除以w,xy坐标便处在(-1,1)的范围内，乘0.5加0.5，则变换到了(0,1)的范围，因texture space的u,v坐标是(0,1)的
        float2 ShadowTexC = 0.5 * vPosLight.xy / vPosLight.w + float2( 0.5, 0.5 );
       //在投影坐标系中，Y轴是向上的，而在纹理空间中Y轴向下，因此要作以下处理
        ShadowTexC.y = 1.0f - ShadowTexC.y;

        // 在texel space中对应的象素坐标
        float2 texelpos = SMAP_SIZE * ShadowTexC;

        // 取得小数部分
        float2 lerps = frac( texelpos );

        //这里使用的是2x2 percentage closest filtering,因此是采的邻近的四个点，判断它们是否在阴影中，
        float sourcevals[4];
        sourcevals[0] = (tex2D( g_samShadow, ShadowTexC ) + SHADOW_EPSILON < vPosLight.z / vPosLight.w)? 0.0f: 1.0f;
        sourcevals[1] = (tex2D( g_samShadow, ShadowTexC + float2(1.0/SMAP_SIZE, 0) ) + SHADOW_EPSILON < vPosLight.z / vPosLight.w)? 0.0f: 1.0f;
        sourcevals[2] = (tex2D( g_samShadow, ShadowTexC + float2(0, 1.0/SMAP_SIZE) ) + SHADOW_EPSILON < vPosLight.z / vPosLight.w)? 0.0f: 1.0f;
        sourcevals[3] = (tex2D( g_samShadow, ShadowTexC + float2(1.0/SMAP_SIZE, 1.0/SMAP_SIZE) ) + SHADOW_EPSILON < vPosLight.z / vPosLight.w)? 0.0f: 1.0f;

        // 用lerps
        float LightAmount = lerp( lerp( sourcevals[0], sourcevals[1], lerps.x ),
                                  lerp( sourcevals[2], sourcevals[3], lerps.x ),
                                  lerps.y );
        // 计算光照，如果完全在阴影中，则LightAmount为0，这里只计算了Diffuse color，没有高光
        Diffuse = ( saturate( dot( -vLight, normalize( vNormal ) ) ) * LightAmount * ( 1 - g_vLightAmbient ) + g_vLightAmbient )
                  * g_vMaterial;
    } else
    {
        Diffuse = g_vLightAmbient * g_vMaterial;
    }

return tex2D( g_samScene, Tex ) * Diffuse;
}

3、ShdowMap的优缺点
    优点：简单，不需要知道场景中Object的Geometry,不需要Stencil Buffer，每个灯光只需多渲染一个Pass。
    缺点：当ShadowMap分辨率不够高时，或灯光与物体隔得很近时，在边缘处会产生Aliasing，锯齿，因此，很多改进shadowMap的算法都围绕着如何消除锯齿作文章。
4、ShadowMap的改进
    关于ShadowMap的改进，又出了很多的paper和技术，比如：Percentage Shadow map, 使用bloom filter对ShadowMap进行模糊处理.以及siggraph 2002 中Marc Stamminger和 George Drettakis提出的Perspective Shadow map.以及Adaptive Shadow Map等等。

魔鬼螳螂 2010-03-21 20:15 发表评论

修改ETM,用Ogre实现《天龙八部》地形与部分场景详解（转）

魔鬼螳螂 — Tue, 16 Feb 2010 14:15:00 GMT

本文主要讲的是《天龙八部》游戏的地形和一部分场景的具体实现，使用C++, Ogre1.6，我摸索了段时间，可能方法用的并不是最好的，但好歹实现了。文章可能讲得有点罗嗦，很多简单的东西都讲了。我是修改了ETM（Editable Terrain Manager）实现的地形，其实单单实现天龙八部的地形场景等的载入根本不需要使用ETM，直接用Ogre的顶点->索引->纹理就可以搞定地形，但我要做的是可以实时编辑的，所以用了ETM，场景其由于很重要的粒子和model等部分我还没去看，所以等以后看了再详细写关于场景的部分，但这个Demo已经实现了基本的场景的载入。光，雾，环境，静态物等都能载入。

修改过的ETM和这个场景的Demo代码可以通过文章底下的链接下载。

Demo截图如下：（少林）

这个Demo比较简单，只能移动摄像机看看场景。

我研究这些的动机是当前在学校做一个网游项目，想做得类似于《Second Life》，苦于没有游戏美工，最近有马上要二期验收了，为了让游戏看上去光鲜一点，无奈之下只好借《天龙八部》的资源来用了。看了不少大牛的博客，将得感觉都有点不是很详细，只是大概把文件格式讲了一下而已，具体怎么实现说得不多（可能是觉得实现太容易，懒得多说了吧...）最主要的是，似乎没看到有人发完整的代码。

实际项目中用的程序代码我就不放出来了，场景部分差不多，只是多了个内建的编辑器，人物移动和网络通信部分等。

编辑器的截图晒一下，功能还不全 :-)

言归正传，先简单地说一下载入一个天龙八部场景的大致过程：

读取.Scene文件
根据读取.Terrain文件
读取地砖大小() 地形大小(xsize, ysize)，缩放值()，地图中心坐标()。
读取所有要用的地形贴图（中各项）。
读取.gridinfo 文件，此文件中存放着每个格子对应的纹理坐标。
根据3，4，5步的信息用修改过的ETM创建Terrain。
读取lightmap, 是png格式的预处理的场景阴影图。
读取场景中的各种模型等，并插入到场景Root中。

(注：天龙八部的场景包含很多个文件，用“劒蚩”的资源提取工具提取出来，文件夹下的基本都是，但我暂时不考虑寻路，碰撞等，所以就地形来讲只研究.Terrain文件，.Gridinfo文件。资源提取的问题可访问http://www.cnitblog.com/sword/category/5167.htmlScene )

下面我分几个部分来具体讲如何实现天龙八部的场景Demo。

读取高度图

做地形首先肯定是要读取高度图，《天龙八部》的高度图是保存在.Heightmap文件中，读取的方法是跳过前面8个字节，读地形的width和height，然后读取width*height个float型数据，上面说到.Terrain文件中有地形大小(xsize, ysize)，缩放值()，地图中心坐标(

)，中有xyz 3个值(一般情况下是100,100,100)，分别是x,y,z轴的放大系数，用ETM创建地形的时候，直接用读取到的float型数据作为高度图数据，然后再用上面那些值作为参数，定义地形的大小，缩放值，和偏移。

这是读取高度图的代码,heightMapData是float型的数组，存放原始的高度图信息。

void TileTerrainInfo::LoadHightMap( const char* fileName, const char* type )
{
FILE* pf = fopen( fileName, "rb" );
fseek( pf, 8, SEEK_SET );
int height, width;
fread( &width, 4,1, pf );
fread( &height, 4,1, pf );
assert( height = this->height+1 );
assert( width == this->width+1 );
if( heightMapData )
delete []heightMapData;
heightMapData = new float[height*width];
for( int i = 0; i < height; ++i )
{
for( int j  = 0; j < width; ++j )
{
float data;
fread( &data, 4,1,pf );
heightMapData[i*width+j] = data;
}
}
fclose( pf );
}

材质文件的分析

我想先讲一下地形的材质，因为用别人的资源，首先要知道怎么用这些资源，一般情况下材质信息可以明显地反映出如何使用纹理资源（不排除有可能用代码动态生成材质）。

在每个.Terrain文件的最下面，有这些内容。

Vertex Shader Model	Minimum Constants Available	Constants Left Over	Bone Matrices Available
vs_1_1	96	12	28
vs_2_0	256	16	80
vs_2_x	256	16	80
vs_3_0	256	16	80

脚本	特性	范例
OGRE Material	封装各种渲染状态，不支持可编程渲染管线	>>>>
Quake3 Shader	封装渲染状态，支持一些特效，不支持可编程渲染管线	>>>>
Direct3D Effect File	封装渲染状态，支持multipass，支持可编程渲染管线	>>>>
nVIDIA CgFX脚本	封装渲染状态，支持multipass，支持可编程渲染管线	>>>>
ATI RenderMonkey脚本	封装渲染状态，支持multipass，支持可编程渲染管线	>>>>




The "Walk" pose. This is the first animation in the blending sequence. On the right, the active bones are highlighted in red.



The "Fire" pose. This is the second animation in the blending sequence. On the right, the active bones are highlighted in red.



The Final pose. Note that the active bones from the "Walk" pose are combined with the active bones from the "Fire" pose. The bones that aren't flagged as active between "Walk" and "Fire" are taken from "Fire".

C++博客-永远也不完美的程序-文章分类-图形编程

（转）多线程渲染(Multithreaded- rendering)3D引擎实例分析 : FlagshipEngine

Dx 10 与 Dx 9 的一些技术区别(转)

shader复杂与深入：Normal Map（法线贴图）2

shader复杂与深入：Normal Map（法线贴图）1

Cascaded shadow map（转）

Light Pre Pass in XNA: Basic Implementation

一起学习Shadow mapping

修改ETM,用Ogre实现《天龙八部》地形与部分场景详解（转）

读取高度图

材质文件的分析

地形纹理的实现

地形的顶点与索引

读取场景环境与模型

地形裂缝问题

骨骼动画导论（转）

理解骨骼动画

骨骼动画的优点

骨骼动画的原理

根关节

先说明,这篇文章由我翻译自Evan Pipho的<>一书的内关于骨骼动画第五章的内容,去掉了前面的说明和最后的Demo说明,包含了所有的理论内容,转载请注明出处,谢谢!

父关节和子关节

骨骼动画的关键帧

计算位置

将网格附着到骨骼

Ogre骨骼动画融合（转）

Skeletal Animation Blending（转）

2 Features

2.1 Skeletal Animation

2.2 Morph Targets

2.3 Subsets

2.4 Material Manager

2.5 Animation Blending

2.5.1 Additive Blending

2.5.2 Transitional Blending

2.6 File Compression

2.7 Common Exporter Framework

2.8 Software Development Kit

应用程序配置不正确，程序无法启动的问题小结（转）

Skinned Mesh原理解析和一个最简单的实现示例（转）

光与材质（转）

Skeletal Animation (Skinning)（转）

HLSL初级教程（转）

D3D性能优化（转）

渲染状态管理（转）

深入理解Direct3D9

MAX SDK的INode的变换矩阵,以及Object的一些常识

游戏程序中的骨骼插件（上）

渲染状态管理（转载）

渲染状态管理的问题

消耗时间问题

渲染状态分类

多道渲染（Multipass Rendering）

多光源问题

阴影问题

渲染脚本

Frustum culling

纹理（讲得比较详细的文章）

[转]3ds max sdk导出插件编写的心得

Effect Framework（转）

3DS Max 插件制作学习心得（转）

D3D状态

渲染状态

概述

取样器状态

取样状态

相关主题

纹理层状态

SetTextureStageState

看不明白的HLSL光照代码

FreeType2字体转换到D3D纹理

　消耗时间问题

　渲染状态分类

　多道渲染（Multipass Rendering）

　多光源问题

　阴影问题