本文翻译自James Ashley个人的博客，他曾经是微软Kinect团队的MVP，原文地址在这里：Why the Kinect for Windows Sensor Costs $249.99?，第一次翻译这么长的东西，难免生涩。转载请注明出处，谢谢。
起因源于本人刚刚头脑一热在京东上搞了个Kinect for Windows，拿到手却发现和原来Xbox 360上的Kinect在硬件上似乎没太大差别，能看到的检测距离的改善以及半身骨架识别，脸部识别等貌似都是软件的升级。贵了一倍(<1000 vs. 1920)却只是软件升级，感觉有点坑爹。于是在网上找到了这篇文章，给想入手Kinect for Windows的朋友一个参考。结论似乎是，开发者用老的（便宜的）Kinect就可以了，而249的价格是指望将来大卖时赚用户的钱的。稍后我会确认一下，Xbox版Kinect在PC上是否具备新Kinect硬件的全部功能。
另外，有兴趣可以看我之前的相关文章Kinect Demo for Grandpa SDK。
以下是翻译的内容：
Read more…
下载Grandpa SDK 0.82 for Windows
去Grandpa主页
主要修改：
- DemoCamera类添加震动功能
- CameraDemo添加摄像机震动功能演示
- 添加Ragdoll功能演示
- 添加KinectDemo
- 添加极限性能演示CrowdDemo
微软刚发布了Kinect for Windows SDK，玩了两天，捣鼓出一个Demo
这一版SDK貌似只支持全身骨架识别，所以还不太适合pc游戏，因为要求的距离太远，还得站着玩，屏幕都看不清了
期待面部表情和手势识别的官方支持
应用了开源的tokamak物理引擎，如果换成别的物理引擎应该也不会有太大差别。调整参数花了一些时间，例如每个部位的尺寸大小，质量，关节方向，角度限制等等。比较麻烦的是躯干，因为其他的rigid body比如胳膊，腿什么的都是和骨骼一一对应的，但是躯干上一般会有好几节脊椎。目前只用一整个rigid body表示躯干，所以一旦进入ragdoll状态，后背的弯曲程度就不能再改变了，否则肩关节看起来就会“脱臼”。
ragdoll还是需要一个好用的编辑器才能大规模应用。
下载Grandpa SDK 0.81 for Windows
访问Grandpa主页
主要修改：
- 添加通用样条曲线采样器，支持float, Vector2, Vector3, Vector4, Quaternion等数据类型的样条插值
- 完善DemoCamera类，支持左手系或右手系坐标，支持z轴向上或y向上
- 添加摄像机动画演示工程CameraDemo
- 整理完善数学库
下载Grandpa SDK 0.8 for Windows
访问Grandpa主页
主要修改:
- 添加Viewer(模型查看器)工程
- cpu蒙皮效率提升约35%
- Vector4现在派生于Vector3，Vector3派生于Vector2
- 支持动画随模型一起加载( 默认为第一次播放时加载）
- 支持attachment模型和主体模型动画同步
- 提高Xml加载效率
- 加入DemoCamera类，替换原来的DXUTCamera
- IModel接口分解为IPartFunctions，IAnimationFunctions和ILodFunctions
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…