Welcome back to the second installment in our four-part series where we review common usage patterns, technical issues, trade-offs, and pitfalls that are important to consider when implementing a VR interaction system.
The fundamental goal of any interaction system is that it’s as easy to learn as possible, with consistent rules so people can anticipate how to interact with anything in the virtual world regardless of any special behavior an object might have. When an accurate physical simulation is combined with logic that coordinates input, animation, and scripted behavior, the result is an experience where objects consistently behave as expected during player interactions.
Locomotion Objects
One of the more advanced forms of interactable objects are those that move the player. Scenarios that use these include grab handles in a zero-gravity environment, rock climbing, rope climbing ascenders, ice climbing axes, and even free climbing ambiguous surfaces. Unlike with most interactable objects, these interactions affect the locomotion system, which adds to the complexity.
Climbing Handles
Climbing handles are a good solution for climbing ladders, rock faces with marked holds, or other situations with discrete grips. Once the player has attached to a climbing handle, moving the motion controller will move their avatar in the same direction. While the basic form of a climbing handle is a simple grip point, the ideal implementation should support a set of line segments that will let the player connect anywhere along a visibly usable edge and provide controls for lateral movement along that edge.
Ropes
When the player moves a hand attached to a rope, they move along the line defined by the rope. The initial connection to the rope requires a distance check to the line, or possibly to a climbing tool called an ascender, which provides a clear attachment point for them to grab. When the player grips and pulls the motion controller, it moves them along the rope in the same direction.
Free Climbing
Free climbing is for climbing arbitrary surfaces, possibly with the use of climbing axes or similar tools. When the player places their hand onto a suitable surface, a material check or trigger volume will attach them to the surface and enable the locomotion behavior. While in this state, moving the attached hand will cause the player to move. Interesting variations of this include requiring specific motions to attach and release climbing axes or other climbing devices.
Held Objects
Carrying objects is the next major category of interaction. There are many side effects and potential design implications for being able to carry a physical object in VR. Simply picking an object up may require the object to match a specific orientation relative to the hand, like with a weapon, along with custom hand poses tuned for an object or class of objects. A more generalized system might use inverse kinematics on the fingers to determine the appropriate grip pose for an arbitrary object that doesn’t have a specific grip or hand pose defined for it. Setting an object down sounds simple enough, but releasing the object while it’s overlapping another object can cause unpredictable physics behavior. If the design supports attaching held objects onto other objects, as opposed to simply releasing them to the world, then the system must be prepared to transfer the attachment from one owner to another, potentially triggering animations for all related objects in the process.
It’s critically important to understand how an object is attached to the player because this affects how well the object will track hand positions and how the physics will behave. Both of these can substantially affect the design and feel of the game. The following sections will review common techniques for keeping objects attached to the player.
Teleporting Attachments
It’s possible to simply teleport the object where it needs to be and let the system resolve collisions as it may. This isn’t usually the best solution because it’s possible to push objects through walls or release objects while embedded within other objects, which can lead to unpredictable behavior from the physics engine. Teleported objects don’t have velocity by default, which means that objects that collide with a held item won’t respond to collision forces in a realistic manner. It’s usually a good idea to do something other than simply teleporting held objects into position every frame because of these issues.
Joint Attachments
Joints can be an effective way to attach objects, but they have their own issues to consider. One problem is that when the player tries to push an object through the environment or another fixed object, it becomes possible to force an object into an invalid location like the other side of a wall representing the edge of valid space. Making matters worse, objects will usually move erratically when this happens. Tuning the joint to break if forces are too large can help, but if the breaking force is too small, the object will routinely detach from the hand as the player gestures or bumps other objects. If it’s important to prevent held objects from entering invalid locations without knocking items out of players’ hands in the process, joint attachments are probably not the best choice. While this behavior can be improved with the use of spring joints and careful tuning of breaking values, it’s generally easier to use a different type of attachment.
Hierarchy Attachments
Placing the held object into the scene hierarchy under the hand will ensure the held object’s visual position precisely matches the hand. For the held object to maintain this relative position, it must be set to be kinematic and possibly non-colliding, neither of which is likely to be desired. Kinematic objects moved by a parent hierarchy behave much like teleported objects. These objects don’t respond to collisions and will force non-kinematic rigid bodies to move out of the way for them—with unpredictable results. This can lead to design-breaking problems when the player pushes dynamic objects into locations where kinematic objects leave them nowhere to go and they wind up pushed outside the map. Turning off collisions entirely can have similar results because when the player releases an object, it may not be in a valid location, which can cause the physics system to react unpredictably.
Position Matching Attachments
f a dynamic object’s position is updated every frame to move towards the hand position, this will trigger the appropriate collision response from any objects in the path of motion, and the held object will respond correctly to any fixed objects in the way. During the physics update, the position matching code will calculate linear and angular velocities to ensure that the object reaches the desired position after the update unless there’s something blocking the movement. This is often a good choice for updating held objects because they’ll move to the correct attachment point—or as close as possible—without violating collision rules.
Two-Handed Attachments
Some designs require the use of two attachment points for an object. Usually, one hand will have a firm grip on the object, while the other serves as a constraint target that drives the orientation of the held item. The object aligns to these two points as best it can, but a number of challenges arise from the fact that no physical object is actually present in the player’s hands to keep them fixed in the correct relative positions.
A pump shotgun is a typical example, where one hand is on the trigger grip and the other is on the pump grip. The user will trigger the pump action by moving the two hands together and then back out while maintaining both grips.
With many games, the weapon aligns to the vector created between the two hands. If the player’s hands exceed the limits of the constrained motion, then either the weapon switches to a one-handed behavior or the secondary hand remains in place on the weapon, even though the user doesn’t actually match the visual pose. In this case, it can be useful to render a ghosted version of the player’s hand, wherever it may be. This approach to aiming can feel unwieldy to some because there’s no physical object to help stabilize the two hands.
Another issue is how it should behave when the secondary hand moves too far away and detaches. When this happens, the weapon effectively becomes a one-handed weapon that will almost certainly need to reorient to match the primary grip. An alternative approach that minimizes these problems is to rely on the primary grip for both position and orientation, and use the secondary grip only for activating the pump or similar actions.
Coming Up Next
Stay tuned for our next installment, Releasing Objects, where we’ll discuss the nuances of releasing objects into the environment.
