动画骨骼模型文件格式fbx

前言

2011年的时候集中轰击了五款3D模型格式（obj、3ds、md2、md3、md5），那时候其实主要是从渲染方式和模型动画方式的进化角度来选择的，尤其是ID Tech的md系列，让这个世界的模型动画观念从最简单的“帧动画”到当前主流的“骨骼动画”进化。但是，即便是拥有骨骼动画的md5格式，也已经是将近10年前的诞生物了，那么这10年来，3d模型格式到底有没有发生了什么变化？——我们将从当今主流的格式略窥一二。

作为开场前口水话，先来说一说实时渲染领域上的3d模型的些许历史罢。上世纪90年代初，由游戏产业带动的娱乐化三维实时渲染开始兴起，那时候的模型也只停留在非常简陋的阶段，甚至没必要专门的存储手段，更别谈什么模型动画了。但是随后当人们发现硬件和技术（值得一提的是，OpenGL也在此时应运而生）逐渐可以支持更复杂的静态模型数据的实时渲染时，存储问题也正式被重视。在没有一个统一标准的情况下，那些以往用于工业建模设计上的交换格式（简化版本），例如Autodesk 3DS Max下的.3ds和Wavefront软件下的.obj，就被选为最具代表性的两种主流静态模型格式了，情况甚至延续至今。

随着90年代中后期视频游戏的爆发式发展，模型中的动画也自然变成需求的一部分，而引领动画技术快速发展的一个重要角色，就是前面说到的ID Software公司下的ID Tech系列引擎。包括至今被众多游戏制作者崇拜着的约翰·卡马克所策动的Doom系列和经典的C/S架构游戏Quake系列，ID Tech在世纪交换期可谓聚集式吸引了视频游戏领域的众眼球。在这众系列引擎中，也隐含着模型动画方式的进化：

md（或者称md1），推测应该是ID Tech 1（1996）所使用的模型格式或概念，是否包含动画信息尚不可知，但是它必然是后来此系列模型格式的基石；
md2，始于ID Tech 2（1997），真正地把动画中的“各帧模型”合并到一个模型中，利用帧数据（结合Morphing技术）还原动画，简单而数据量巨大；
md3，始于ID Tech 3 （1999），虽仍以帧数据还原动画，但同时引入了骨骼这一概念，把模型分为下身、上身、头和武器这几部分，通过骨骼节点连接，下身节点带动上身移动和旋转，以此类推——相当于加入了一条短骨骼，有效地降低数据冗余度，各部分的动画可以各种组合；
md4，草稿式的模型格式，它的存在印证着新千年初始期，ID Tech人员对更高效模型格式和渲染技术的探寻，但也只停留在概念阶段而被略去——但也有其他人实现了这一概念（mdr格式），也存在别的发展分支（mdl格式）；
md5，始于ID Tech 4（2004），从03年完善到05年，是真正的支持骨骼动画、顶点蒙皮渲染的模型格式，随着著名的Doom3游戏进入大众的视线。
随着新世代显卡的发展、各种商业非商业实时渲染引擎的出现和发展，骨骼动画被引入为主流的模型动画标准，至今仍为主流技术。这10年来，随着ID Tech的沉默（最新的ID Tech 5已不如往日辉煌）和各路人马的强大和异军突起，业界也有巨头期盼着制作出某种更通用的（被更多模型制作工具支持或转换，可被各方人员交换和重用的）模型格式标准，这其中就包括Autodesk、Microsoft和与我们OpenGL标准息息相关Khronos委员会。

fbx，[WIKI]源于Kaydara的FilmBox（后改为现称的MotionBuilder）软件（1996），后来被Autodesk收购，但是这个模型格式依然被一直发展，直至今天它还是“最”跟得上潮流的格式——鉴于Autodesk已经无法给3ds格式更好的动画信息支持了，现在fbx才是它的主打，也因为有个强大的爹，这个格式被广泛的建模软件和游戏引擎支持，也有引擎（像那个Xxity3D）把它作为主要支持的导入模型的；
x，这是Microsoft弄出来的模型格式，随着DirectX的SDK一起升级，后来也成为了骨骼动画的代表模型格式之一，这是微软为了把DX塑造成完整的自生态开发系统而采取的常见行为，虽然格式本身是开放的，但可见对Direct3D是无条件支持的（甚至有内置函数可以直接读取），这里我就不过多阐述了，因长期没更新，所以业界使用率没比md5更广泛得了去哪，常见于D3D的例子Demo；
dae，[WIKI]也称Collada模型，是非盈利性组织Khronos负责维护的开放性三维模型格式（现已成为 ISO标准之一），应该说跟OpenGL是同一级别的，作为一个标准，其目的自然是能被各方支持了，而毕竟Autodesk有自己的利益考虑，所以远没有像fbx那样完美的支持，但这不妨碍它现在还是能够与封闭的fbx分庭抗礼的主要模型格式。
除了以上说的这些，其实还有很多模型格式，除了那些纯粹地用来保存建模软件的阶段结果的(.max、.blender之类)的，还有沿袭式地用于VR领域的(.vrml和.x3d之类)，以及一些特定为某些游戏引擎所用的模型格式(像那Xxre的.Xxremesh和那Xxrlicht的Xxrmesh)。而本文主要还是聚焦于当前最流行的Fbx和Dae，切入正题。（在此希望不太懂顶点蒙皮原理的同学先自己学习下或者参考上面链接中的MD5模型导入的两文，不然看本文肯定觉得不知所云。）

FBX

如前所述，fbx是一种封闭的模型格式，这不仅说它通常作为二进制文件出现，而且是目前只能使用Autodesk提供的FBX SDK来操控这种文件。事实上，无论是3DS Max还是其SDK内置的Converter工具，都可以把其转换成ASCII的文本格式，虽然看上去有点JSON的样子，可事实上是全自给的“仅供观赏”的数据堆，也没有spec，通常也不会有人使用这种方式输出模型。好了，看来是必须借助其SDK了，所以首先要做的一件不太让人愉快的事情：加入这个SDK的库(lib&dll)。现在我用的是最新的fbxsdk-2013.3，下文仅就这版本兼容的模型而言。（注意，在预处理器选项中加入FBXSDK_NEW_API和FBXSDK_SHARED，如果你不想编译器抱怨一大堆的话。）

这里首先说一下，对于Fbx（其实下文的Dae也是一样的），它保存的最大集合是一个Scene（场景），跟很多的游戏引擎所使用的概念是一致的，就是用场景节点树来组织成一个场景。以前的3ds[3DS文件结构的初步认识] 虽然也是树状地组织数据，但它是把不同类型数据堆抽象成节点，而Fbx/Dae则是纯粹地表述场景节点。所以对于后者们来说，即使把场景中多个物体/模型保存到同一个模型文件里，也是可以的，只不过是不同名字的节点而已，甚至把灯光、相机也可以抽象成节点而已。当然，对于我们编程者来说，一个模型文件仅仅对应一个模型是最自然的。所以接下来我只会谈及抽取模型和动画本身信息（事实上动画信息并非必须的——fbx和dae文件在没有动画或骨骼信息时，也就是静态模型了），不相关的部分则不涉及也不关心。

注意

当我们加载骨骼动画fbx文件格式时，经常看到和fbx一起导出的文件.meta,其实只需要fbx就可以，不需要meta文件格式

FbxScene *pScene = FbxScene::Create(pFbxManager, "ImporterScene");  
  
pSdkImporter->Import(pScene);  
  
PrepareAnimationInfo((Scene*)pScene);  
  
FbxNode *pRootNode = pScene->GetRootNode();  
  
if (pRootNode)  
{  
    for (int i = 0; i < pRootNode->GetChildCount(); ++i)  
    {  
        FbxNode *pNode = pRootNode->GetChild(i);  
  
        ProcessNode((Node*)pNode, szResDirectory);  
    }  
}  
  
SetupJointKeyFrameInfo();  

参考

http://www.zwqxin.com/archives/opengl/model-fbx-dae-format-import-animation.html