With our latest Unity Core Assets release, we’re excited to unveil full support for the Unity 5.4 beta, which features native support for the HTC Vive. This is the fourth release since the previous installment in this series, when we shared some background on the ground-up re-architecting of our hand data pipeline. Today we’re going to look under the surface and into the future.
As our Orion beta tracking evolves, we’ve continued behind the scenes to hammer on every aspect of our client-side data handling for performance and efficiency. We’re also actively refining developer-side workflows and expanding the features of our toolset for building hand-enabled VR experiences. And in some cases, we’re adding features to the Core Assets to support upcoming Unity Modules.
For this release, we focused on our HandPool class. This Unity MonoBehavior component not only manages the collection of hand models for the rest of the system, it defines much of the workflow for the way you add hands to your scene. This release brings some refinements but also a significant new feature – the ability to have multiple pairs of hand models and to easily enable or disable those pairs at runtime.
While working on demonstration projects here at Leap Motion, we’ve found ourselves wanting to use different sets of hands for a variety of reasons. For complex graphical representations, it might be helpful to have hand models that only provide shadows, or only provide glows in addition to the main hands. A superhero game could benefit from the flexibility of completely different iHandModel implementations for fire hands versus ice hands. And some experiences might benefit from different hands for different UI situations.
The HandPool component, located on the same GameObject as the LeapHandController and LeapServiceProvider components, now has an exposed Size value for our ModelPool’s list of ModelGroups. Setting this value allows you to define how many pairs of hands you’d like in your scene. If you change this number from 2 to 3, slots for another pair of models will appear. You can assign a name for your new model pair so you can refer to it at runtime.
As in previous versions of Core Assets, you can drag iHandModel prefabs from the Project window to be children of the LeapHandController GameObject in the Hierarchy window. When you do this, the iHandModel component in the model prefab receives a default Leap hand pose. Since all Leap hand models inherit from the iHandModel, class this means that each pair of hands will align with the others.
You can test this by adding two DebugHand prefabs to your LeapHandController. In the Inspector for each DebugHand, you can set the Handedness to Left and Right. Then drag these children into their new slots. For the iHandModels to align, just be sure that the local translations and rotations of your iHandModel’s transform are zeroed out.
We’ve also improved the DebugHand script to show the rotation basis for each Leap Bone. These are immediately visible in the Scene window, but there’s a trick that allows you to view them in the game window as well. If the Gizmos button at the top right of the Game window is enabled and you select the LeapHandController in the Hierarchy window, you can view collider-based physics hands as well as the new Debug hands.
Using the Debug hands in this way can be help for – wait for it – debugging your other hands to verify they’re lining up with Leap Motion data! We hope this will be a helpful workflow when you’re building your own iHandModel implementations.
The new multiple hands feature becomes even more powerful with the added ability to enable and disable pairs at runtime. In the Inspector, you can set the IsEnabled boolean value for each model pair. This will control whether those models are used when you Start your scene. But more importantly, you can enable and disable these pairs at runtime with HandPool’s EnableGroup() and DisableGroup() methods.
Here’s a simple script you can attach to the LeapHandController. It will allow you to use the keyboard to enable and disable groups:
using UnityEngine;
using System.Collections;
using Leap.Unity;
public class ToggleModelGroups : MonoBehaviour {
private HandPool handPool;
void Start() {
handPool = GetComponent<HandPool>();
}
void Update () {
if (Input.GetKeyDown(KeyCode.U)) {
handPool.DisableGroup("Graphics_Hands");
}
if (Input.GetKeyDown(KeyCode.I)) {
handPool.EnableGroup("Graphics_Hands");
}
}
}
Refactoring the HandPool class to support these new features while maintaining and improving encapsulation required some scrutiny and iteration. This work also allowed us to simplify the developer-facing UI we exposed in the Inspector. Where previous versions had the notion of a ModelCollection which populated our ModelPool at runtime, the new workflow is to add iHandModels directly to the HandPool simplifying the code and UI simultaneously.
To watch the ModelPool system at work and get a solid understanding of the system (like we did in the previous blog post), you can comment out the [HideInInspector] tag above the modeList variable on line 39 of HandPool.cs. Each pair of iHandModels is part of a ModelGroup class. Its modeList gets populated at runtime. When a new Leap Hand starts tracking, an iHandModel is removed from the modelList and returned to the modelList – and therefore the ModelPool – when that Leap Hand stops tracking.
Each model pair has a CanDuplicate boolean value that works in tandem with iHandModel’s public Handedness enum. When CanDuplicate is set to True, this provides some flexibility to the Leap Motion tracking by allowing more than one copy of a Right or Left iHandModel. This can allow hands to initialize slightly faster in some cases, but also lets you create scenes where you’d like other users to put their hands in as well. Setting this to False allows you to ensure that only one Right and Left hand will be used at any time, which is useful if you’re going to drive the hands of a character or avatar.
Finally, our further refactoring has allowed us to relax the requirement that HandPool receive only instances from the scene Hierarchy. Prefabs can once again be dragged directly from the Project window directly into HandPool’s iHandModel slots. While this removes our ability to visualize the hand in the Scene view during edit time, we’re striving to allow the most flexibility for all sorts of workflows.
These new features are already allowing us to experiment with and demonstrate new use cases. But more importantly, they’re immediately providing the basis for new Unity Modules currently under construction. These will unlock new features and workflows like hand models, the ability to create your own hand models, user interface assets to streamline the creation of wearable menus in VR, and more.
The post Redesigning Our Unity Core Assets Part II: New Features in 4.1.0 appeared first on Leap Motion Blog.