Oculus开发实战：为《Tiny Castles》实现60Hz手部追踪
高频手部追踪能够实现更好的手势检测和更低的延迟
（映维网 2021年05月07日）Oculus日前发布了全新的追踪模式：高频手部追踪（High Frequency Hand Tracking）。据介绍，手部追踪的频率将会从30Hz增加至60Hz，而且这一模式能够实现更好的手势检测和更低的延迟。在下面这篇博文中，团队介绍了如何在《Tiny Castles》中实现所述功能。下面是映维网的具体整理：
1.《Tiny Castles》是什么？
《Tiny Castles》是一款“动作益智游戏”，将手部追踪作为主要输入。它是由Facebook Reality Lab的Oculus Strike团队开发而成，主要用于测试只需双手交互的游戏体验。
在这款益智冒险游戏中，玩家扮演一个强大的神明角色，并通过战胜邪恶的力量来解救自己的信徒。从解决复杂的谜题和操作古老的机器，再到与各种微型敌人作战，玩家将需要利用双手克服各种独特的挑战。
游戏由5个关卡组成，并展示了为手部追踪而构建的各种交互。其中一个关卡是“游乐场”，它是体验所有游戏机制的最佳场所。
2.Hands API提供了什么？
Hands AP提供的是：不使用控制器的情况下在VR中呈现用户完整手部关节表示所需的信息。这包括：
- 手的位置和方向
- 手指的位置和方向
- 追踪置信度（高或低）
- 手的尺寸（即大小）
- 捏合（手指+拇指）力度信息
- UI光线投射的指针姿态
- 打开通用菜单或应用定义菜单的系统手势
利用Unity和Oculus集成，我们能够使用OVRCameraRig和OvrhandPrefact快速构建一个简单的手部追踪测试场景。
3.我们需要构建什么？
因为API不是一个应用程序，所以我们必须构建额外的系统。
3.1手部管理
尽管《Tiny Castles》是一个“以手为先”的应用程序，但我们同时希望提供一个同等的Touch控制器体验。为了实现这一点，我们创建了一个抽象的BaseHand类来定义我们的核心手部功能：
- 捏（食指+拇指）
- 抓取（用于近场交互）
- 指向
- 原力抓取（用于远场交互）
派生的TouchHand类（当控制器处于活动状态时使用）通过将按键映射到动画状态来实现所需的BaseHand功能。
派生的HandTrackingHand类（在手处于活动状态时使用）利用Hands API来实现所需的BaseHand功能，并公开了额外的手部追踪特定功能，如手势信息。
3.2 手部姿态识别
在《Tiny Castles》中，我们将手势定义为手指当前可见的位掩码，取决于指尖是否包含在手掌球体中。
这种紧凑的表示是我们的手部输入系统的基础，但需要以一定的保真度为代价。例如，我们的系统无法区分靠近或分开的可见手指。
3.3 手部动作识别
除了简单的手势识别，我们同时需要建立一个将手势和动作结合起来，以允许更复杂行为的系统。手势行为树是一个描述完成手势所需条件集的节点图。
这个数据驱动系统已证明非常具有价值，并且允许团队中的任何人在几乎没有代码支持的情况下尝试简单到复杂的手势。
3.4 游戏系统
为了支持游戏，我们需要加入额外的系统，如手部物理，玩家能力和NPC人工智能等。这是常见的商业VR游戏。
4.我们学到了什么？
第一点： 对一个用户有效并不一定对每个人都有效，所以对大量不同的用户进行测试是必不可少。
第二点： 要判断什么“感觉很好”，你需要大量的实验和迭代。使用诸如OVRHand和OVRSkeleton之类的high level Hand API类，开发者可以快速开始原型设计。但是，使用low level的OVRPlugin接口可以给开发者更多的控制。
第三点： 支持控制器可以方便地进行A/B比较。在构建自定义手部模型时，请使用与Hand API相同的rig，以避免需要重定传入数据。
第四点：捏合。
捏合是一种轻松的机制，因为Hands API中包含了支持。我们需要添加捏合时间的概念来确定手指（或一组手指）捏合的时间。这对于输入目的非常有用，因为捏合和按压控制器按钮并不完全相同。
第五点：抓取。
由于抓取的概念没有包含在Hand API中，因此与捏合相比，我们必须在这方面进行更多的实验。我们首先需要定义“抓取”的含义。这就产生了许多需要回答的问题，包括：
- 在张开手掌和紧闭拳头之间，抓取的阈值是什么？
- 你能用两个手指进行抓取吗？三个？四个？
- 一旦你抓到了什么东西，你怎么知道什么时候释放它？
- 你能同时抓和捏吗？
我们尝试了几种不同的抓取检测方法：
- 捏抓：由于捏合的数据是现成的，我们能够定义抓取为“用所有手指捏合”。检测工作正常，但它需要用户做出非直观的姿势来触发。
- 物理：使用OVRSkeleton中的physics capsule支持，这个方法相对容易实现。尽管一开始效果很好，但在实践中很难做到始终如一。用户的行为必须非常谨慎。因为手部追踪没有触觉反馈，所以我们遇到了一些常见的物理问题，比如过多地穿透一个对象会导致它意外地发射出去。
- 球形抓取：所述方法包括使用放置在手掌中的球体来确定指尖是否包含在球体内（并且为我们的手姿识别系统奠定了基础）。一般来说，检测效果很好。主要的挑战是确定球体的适当大小和位置。球体过大会导致“假阳性”抓取。球体太小则根本无法检测到抓取。球体的位置同样非常重要，因为用户不一定会以同样的方式闭合。
- 手指卷曲角：这个方法涉及测量手指相对于绑定姿势的角度。角度越大，手指越“卷”。对食指、中指、无名指和小指的检测效果良好。然而，拇指角度的检测有点问题，这取决于用户如何握拳。
- 接触式抓取：所述方法使用碰撞信息来确定手指何时与对象接触。一旦有足够的手指接触到一个对象，这个对象就会被抓取。我们发现很难在抓取和释放检测之间找到一种适合大范围对象和用户的平衡。
我们同时发现，当握持一个对象时，预定义和/或程序性手势不仅看起来更好，而且实际上更具沉浸感，即使用户的虚拟手部并不完全匹配真实手部。这也为我们的曲柄和杠杆机制奠定了基础。
第六点：原力抓取
我们发现精确选择远处的对象非常重要。《Tiny Castle》中的原力抓取目标选择系统使用圆锥体来确定潜在目标，并选择最接近圆锥体中心的目标。我们同时结合了瞄准辅助和目标保持技术。
当瞄准目标时，我们发现由于自身遮挡问题，使用更多的“钢铁侠”姿势（用户更多地用手掌进行指向）比“星球大战”姿势（将手指伸向目标）更可靠。
第七点：手部姿态
作为最佳实践，我们建议在短时间内进行姿势检测检查，以减少误报和瞬间数据不一致的发生。
第八点：手势动作
作为最佳实践，我们建议手势应该是不同动作的相对简短组合。另外，尽量避免与常见行为重叠的手势，以防止误报。例如，一个仅由拳头组成的手势会在不经意间不断触发。然而，不断握拳并朝自己收回的动作则可能不会。
第九点：金属手套
《Tiny Castle》使用一个定制的“金属手套”模型来代表玩家的双手。最初的设计是将所有用户界面构建到手套网格中，手套部分将有3-5个武器模块，可以将玩家的手转化为不同的武器或工具。
我们发现使用内置UI进行复杂的选择过于复杂和麻烦。为了简化这一点，我们切换成一个场景用一个特定的手势实现一个基本能力。
我们发现金属手套增加了玩家的沉浸感，并使我们避免了手部缩放（这将导致复杂的手部物理）。
将反向运动学添加到玩家虚拟前臂的护腕增加了一层沉浸感。
第十点：移动机制
手部追踪应用中的一个持续挑战是移动机制。《Tiny Castle》使用固定扭曲点，玩家只需使用一个简单的抓+拉手势即可。它感觉直观，自然，可靠。
但这种方法可能不适用于所有游戏。我们使用虚拟控制器和双手手势方法进行了一定的测试，每种方法都有不同的结果。不过，如果没有拇指摇杆和按钮，为游戏设计一个自由漫游移动标准可能会很有挑战性。游戏的Playground关卡包含一系列的移动机制示例。
第十一点：游戏设计
对于世界内交互，诸如曲柄和杠杆非常可靠，但位置是关键。
让玩家控制节奏的游戏或回合制的游戏可能非常适合今天的手部技术。
简单的手势（比如抓+拉）对激活游戏事件很有用。
即使是存在追踪问题，继续握持一个对象都可以避免玩家产生太大的挫败感。
Playground关卡最终成为了一个用于展示各种力学的优秀沙盒。
第十二点：UI
由于缺少触觉反馈，在用手部追踪来与UI交互和操作按键时，如果出现追踪抖动、自我遮挡和/或以上所有因素可能会令人感到非常沮丧。最有效的方法是给UI提供一定的碰撞器，以便虚拟手指实际与UI碰撞。这种“视觉触觉”，以及为UI交互添加声音有助于填补实际物理触觉的空白。另外，为了避免按下错误的按钮，可以实现一个进度条来提供反馈，从而避免用户的无意操作。
第十三点：音频
将听觉反馈添加到所有核心手部交互中能够提升体验的沉浸感，因为裸手交互通常没有触觉反馈。特别是，我们发现在抓取和释放机制中添加声音有助于在用户成功执行操作时增强其吸引力。我们同时增加了悬停音效，以让用户知道一个新的目标已被选中。
5.我们遇到了什么挑战？
在开发游戏的过程中，我们不得不处理一些所有实现手部追踪的开发者在某个时候都会遇到的挑战。
第一点：延迟
与控制器相比，目前的手部追踪数据具有更明显的延迟。这会令非常看重响应时间的情况变得复杂。使用手部物理同时可以增加感知延迟，但这对于《Tiny Castles》的游戏目的非常必要。
第二点：抖动
手保持相对静止时会有明显的抖动。
camera方向有助于感知抖动。例如，如果保持手不动并环顾四周，用户会注意到自己的手在轻微移动。
为了减少在《Tiny Castles》的抖动感，我们在手不是快速移动时进行自定义平滑。这有相当大的帮助，但在某些情况下会引入稍微更多的感知延迟。
第三点：低置信度追踪数据
有时，Hands API返回的数据的置信度很低。如何处理这种情况非常重要。按原样使用数据会导致手部行为不稳定。
对于《Tiny Castles》，当我们检测到低置信度数据时，我们会将手保持在最后一个已知的好姿势，然后交换材质，使手明显变红。在接收到高置信度数据之前，保持这一状态。我们发现这种方法可以帮助用户快速发现问题，并训练他们根据需要进行自我纠正。
第四点：遮挡
当camera看不到手指和/或手时，遮挡就会发生。当用户手部的虚拟表示与物理世界显著不同时，这可能会导致意外的结果。
遗憾的是，遮挡会出现在用户在第一次使用手部追踪时认为“直观”和“自然”的情况。
第五点：指向
用户通常很自然地倾向于以一种导致自遮挡的方式进行指向，其中用户的手臂或手背会遮挡手指。
第六点：伸手
就像指向一样，用户倾向于伸出手和手臂并导致自我遮挡。例如，伸手去捡地上的物品时。
按钮和UI菜单的放置应该考虑到自遮挡问题。
遮挡问题对《Tiny Castles》的设计决策影响最大。
第七点：追踪视场
对于Quest和Quest 2，当手处于摄像头视场范围内的追踪效果最好。遗憾的是，这往往不能保证发生，经常会出现手部离开摄像头视场范围的情况。
6.未来：高频手部追踪
我们在《Tiny Castles》观察到，高频手部追踪的感知延迟有所减少，同时显著提高了快速手部运动的追踪质量。不过，这项功能在抖动和遮挡方面没有明显的变化。
另外，开发者应该注意，启用高频手部追踪将导致最大CPU和GPU可用性的降低。
