Grandpa从设计之初就定位于跨平台，渲染API无关的库。核心代码仅依赖c++标准库，理论上可以在任何平台，用任何（基本）符合c++标准的编译器编译。
但是这次还是碰到了一些问题，主要还是VC用的时间太长了，没有意识到某些特性实际上是非标准的，例如：
- hash_map头文件的位置不同。大家都知道该容器是非标准的，在vc下该头文件和其他容器在一起，而gcc下在ext子目录中
- gcc警告最后一行非空（也就是说源代码文件最后一个字符必须是回车，标准的确是这么规定的），vc不会警告
- vc允许只声明enum，gcc不允许
- gcc没有“安全版”（带_s）的字符串处理函数
另外，Mac OS X（以及Linux等其他Unix系的操作系统）是用utf-8表示unicode，而Windows则采用utf-16，这一点也引起了一些小麻烦。
还有一个很讨厌，gcc居然不认识utf-8的bom(ef,bb,bf)。导致我所有的源代码文件都要改为multibytes编码
好在这些都是小问题，花了不到一天时间就都解决了。
特别感谢张志鹏同学，帮我把原来基于d3d的Demo移植到了Opengl es上。
另外从今天开始，Grandpa SDK开放svn更新，地址为 Http://www.multi-crash.com/release
推荐使用TortoiseSVN。
上一篇遗留了一个问题没有说完，就是关于绝对变换和相对变换。我们的骨架一般是以树形结构存储的，一个骨骼会有一个父骨骼（根骨骼除外）和若干个子骨骼。所以对于骨骼的变换我们可以存储在模型空间中的绝对变换，也可以存储相对于其父骨骼的相对变换，二者是可以相互转换的。
用相对变换形式存储的好处主要是便于拆分成不同类型的变换从而使动画插值成为可能；而保存绝对变换的好处首先是效率较高，因为在蒙皮计算的时候我们真正需要的是骨骼的绝对变换，如果保存的是相对变换就需要根据骨骼的父子关系先计算出绝对变换矩阵，每块骨骼都多出一个矩阵乘法的开销。另外直接保存绝对变换还能避免因为逐层相对变换引起的累积误差。
言归正传，我们继续来看动画数据的压缩，前文已经把200k的数据压缩到60k左右，还有办法继续压缩吗？
用过Max（Maya和XSI不太熟悉，但想来也应该差不多，下文只讨论Max）的同学会发现，虽然我们的动画定的是30fps的标准，但是美术实际摆放的关键帧要远远低于这个密度，对于简单的动画，某些骨骼可能在两秒的时间内只有3～4个关键，其它时间的骨骼方位实际上是导出时Max自动插值得到的。于是小算盘就开始打了，既然我们保存的骨骼关键帧大部分都是Max自动生成的，那么我们能不能只保存真正由美术摆放的关键帧，剩下的也象Max所做的那样自动插值出来呢？如果可以的话，无疑将再次大幅减小动画文件的尺寸。
Read more…
这里说的骨骼动画数据，是指美术用Max，Maya或者XSI之类的3d工具制作的角色动画，通常要导出成引擎可以读取的特殊格式，为游戏所用。对于目前越来越强调动作感的网络游戏来说，动画资源占整个安装包尺寸的比例在不断上升，动画数据的压缩也在变得原来越重要，更不用说采用大量实时渲染过场动画的次世代Console游戏了。
每个引擎都有自己独特的动画文件格式，但里面的内容都大同小异。所谓动画，就是一系列关键帧的集合，每个关键帧可以描述了角色整个骨架的完整姿态信息，也就是每一块骨骼在3d空间中的位置和方向。
假设我们有一个包含50块骨骼的骨架，采用30fps的帧率，一个长度为两秒的动画需要占用多大的空间呢？我们来计算一下。我们知道空间的方位可以用一个矩阵来描述，一个矩阵包含4 x 4 = 16个浮点数，也就是64字节；我们有50块骨骼，那么每个关键帧就需要50 x 64 = 3200字节，另外关键帧还需要一个4字节的时间值，那么就是3204字节；两秒的30fps动画一共包含60个关键帧，于是可以算出最终的大小是3204 x 60 = 192240字节，不到200k的样子。这就是未经压缩的数据大小，当然这里忽略了一些诸如骨骼名字之类的信息，和我们要讨论的动画压缩关系不大，就不算在内了。
Read more…
September 13th, 2009
zero
解释一下标题，所谓高跟鞋问题是指女性3d角色的动画如何根据穿的是平底鞋或高跟鞋（甚至是任意高度的鞋跟）进行自动调整的问题。因为显而易见地，如果不做调整的话脚部的姿态不可能同时适应平底鞋和高跟鞋。而如果对角色的每个动作都分别制作平底鞋和高跟鞋两个版本的话无疑极大加重了美术的负担，况且高跟鞋的鞋跟还可以不止一个高度。
Read more…
Grandpa是一个精巧，高效而且功能强大的C++骨骼动画库。
非商业应用免费，商业应用请联系我。
转贴请注明出处。
去Grandpa主页了解详情
