HK1174711B - Push actuation of interface controls - Google Patents

Description

Press initiation of interface controls

Technical Field

The invention relates to a starting technology of an interface control.

Background

Computer technology allows humans to interact with computers in a variety of ways. One such interaction may occur when a human initiates a button on a user interface of a computing device using various input devices, such as a mouse, track pad, and game controller.

Disclosure of Invention

The three-dimensional position of the user's hand in world space may be translated into a screen space cursor position for the user interface. As the user moves the hand in world space, the cursor moves around on the user interface. A button of the user interface may be actuated when the hand moves the cursor such that the depth of the cursor changes by at least a threshold amount when the cursor overlays the button, regardless of the initial depth of the cursor on the user interface.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.

Drawings

FIG. 1 illustrates a depth image analysis system viewing an observed scene according to an embodiment of the present invention.

FIG. 2 somewhat schematically illustrates a human target modeled with example skeletal data in an observed scene.

FIG. 3 shows an example of hand movement in world space that results in corresponding screen space cursor movement.

FIG. 4 illustrates example cursor movements of a button that launches a user interface.

FIG. 5 shows a cursor velocity vector for an example cursor movement.

FIG. 6 illustrates an example sequence of changes in cursor speed in response to cursor movement.

FIG. 7 schematically illustrates a computing system according to an embodiment of the invention.

Detailed Description

A depth image analysis system, such as a 3D vision computing system, may include a depth camera capable of viewing one or more game players or other computer users. As the depth camera captures images of a game player or other computer user within an observed scene, those images may be interpreted and modeled with one or more virtual skeletons. Various aspects of the modeled skeleton may be used as input commands to a user interface. For example, the computing system may be able to determine whether the player is attempting to press a button of the user interface based on the modeled hand movements of the player.

FIG. 1 shows a non-limiting example of a depth image analysis system 10. In particular, FIG. 1 shows a gaming system 12, which gaming system 12 may be used to play a variety of different games, play one or more different media types, and/or control or manipulate non-gaming applications and/or operating systems. FIG. 1 also shows a display device 14, such as a television or computer monitor, that may be used to present game visuals to game players. As one example, display device 14 may be used to visually present a virtual avatar 16 that human target 18 controls with its movements. The depth-image analysis system 10 may include a capture device, such as a depth camera 22 that visually monitors or tracks the human target 18 within an observed scene 24. Depth camera 22 is discussed in more detail with reference to FIG. 7.

Human target 18 is shown here as a game player within observed scene 24. Human target 18 is tracked by depth camera 22 such that movements of human target 18 may be interpreted by gaming system 12 as controls that may be used to affect the game being executed by gaming system 12. In other words, human target 18 may use his or her movements to control the game. Movement of human target 18 may be interpreted as essentially any type of game control. Certain movements of human target 18 may be interpreted as controls for purposes other than controlling virtual avatar 16. As a non-limiting example, movement of human target 18 may be interpreted as a user interface control, such as a control for pressing a virtual button of a virtual user interface displayed by display device 14.

Depth camera 22 may also be used to interpret target movement as operating system and/or application controls outside the realm of gaming. Substantially any controllable aspect of the operating system and/or application may be controlled by movement of human target 18. The scenario illustrated in FIG. 1 is provided as an example, but is not meant to be limiting in any way. Rather, the illustrated scenario is intended to demonstrate a general concept that may be applied to a wide variety of different applications without departing from the scope of the present disclosure.

The methods and processes described herein may be incorporated into a variety of different types of computing systems. FIG. 1 shows a non-limiting example in the form of a gaming system 12, a display device 14, and a depth camera 22. In general, the depth image analysis system may include a computing system 160 shown in simplified form in FIG. 7, which computing system 160 will be discussed in more detail below.

FIG. 2 illustrates a simplified processing pipeline in which human target 18 in observed scene 24 is modeled as a virtual skeleton 38, which virtual skeleton 38 may be used to draw virtual avatar 16 on display device 14 and/or as control input to control games, applications, and/or other aspects of the operating system. It is to be understood that the processing pipeline may include additional steps and/or alternative steps than those depicted in fig. 2 without departing from the scope of the present invention.

As shown in FIG. 2, human target 18 and the rest of observed scene 24 may be imaged by a capture device, such as depth camera 22. The depth camera may determine, for each pixel, a depth of a surface in the observed scene relative to the depth camera. Substantially any depth finding (depthfinding) technique may be used without departing from the scope of the present disclosure. Example depth finding techniques are discussed in more detail with reference to FIG. 7.

The depth information determined for each pixel may be used to generate a depth map 36. Such a depth map may take the form of substantially any suitable data structure, including but not limited to a matrix including depth values for each pixel of the observed scene. In fig. 2, depth map 36 is schematically illustrated as a pixelated grid of the outline of human target 18. This illustration is for the purpose of simplicity of understanding and not for the purpose of technical accuracy. It will be appreciated that the depth map generally includes depth information for all pixels (not just the pixels that image human target 18), and that the perspective of depth camera 22 does not result in the profile depicted in FIG. 2.

Virtual skeleton 38 may be derived from depth map 36 to provide a machine-readable representation of human target 18. In other words, virtual skeleton 38 is derived from depth map 36 to model human target 18. Virtual skeleton 38 may be derived from the depth map in any suitable manner. In some embodiments, one or more skeleton-fitting algorithms may be applied to the depth map. The present invention is compatible with substantially any skeletal modeling technique.

Virtual skeleton 38 may include a plurality of joints, each joint corresponding to a portion of a human target. In FIG. 2, virtual skeleton 38 is shown as a line drawing of fifteen joints. This illustration is for the purpose of simplicity of understanding and not for the purpose of technical accuracy. A virtual skeleton according to the present invention may include substantially any number of joints, each of which may be associated with substantially any number of parameters (e.g., three-dimensional joint positions, joint rotations, body positions of corresponding body parts (e.g., hand open, hand closed, etc.). It should be appreciated that the virtual skeleton may take the form of a data structure as follows: the data structure includes one or more parameters for each of a plurality of skeletal joints (e.g., a joint matrix containing an x-position, a y-position, a z-position, and a rotation for each joint). In some embodiments, other types of virtual skeletons may be used (e.g., a wireframe, a set of shape primitives, etc.).

As shown in FIG. 2, virtual avatar 16 may be presented on display device 14 as a visual representation of virtual skeleton 38. Because virtual skeleton 38 models human target 18, and the rendering of virtual avatar 16 is based on virtual skeleton 38, virtual avatar 16 serves as a viewable digital representation of human target 18. Thus, movement of virtual avatar 16 on display device 14 reflects movement of human target 18.

In some embodiments, only portions of the virtual avatar will be presented on display device 14. As one non-limiting example, display device 14 may present a first-person perspective of human target 18, and thus may present portions of the virtual avatar that are viewable through the virtual eyes of the virtual avatar (e.g., outstretched hands holding a steering wheel, outstretched arms holding a rifle, outstretched hands grasping a virtual object in a three-dimensional virtual world, etc.).

Although virtual avatar 16 is used as an example aspect of a game that may be controlled by the movement of a human target via the skeletal modeling of a depth map, this is not intended to be limiting. The human target may be modeled with a virtual skeleton, and the virtual skeleton may be used to control aspects of a game or other application other than a virtual avatar. For example, movement of the human target may control a game or other application even if the virtual avatar is not rendered to the display device.

Instead of displaying an avatar of the human target, a cursor may be displayed. FIG. 3 shows an example in which the position of the hand 42 in world space 40 is used to control the position of the cursor 52 in screen space 50. Movement of a hand of a human target may be tracked based on one or more depth images of a world space scene including the human target.

The movement of the hand 42 in the world space 40 is tracked over time in an interaction region 44 that moves as human targets move around in the world space 40. The location and orientation of the interaction zone 44 may be based on the location and orientation of the human target. As a non-limiting example, the location and orientation of the interaction zone 44 may be based on the relative position of the head of the human target. For example, the position and orientation of the interaction zone 44 may be adjusted as the position of the head of the human target changes. However, in alternative embodiments, the location and orientation of the interaction zone 44 may vary with the relative position of one or more selectable body parts of the human target, such as the chest or shoulders. Thus, as the human target moves around in world space (e.g., steps forward, steps backward, turns left, turns right), the interaction zone 44 is re-aligned accordingly with respect to the human target.

The movement of the hand 42 in world space 40 tracked in the interaction region 44 may be translated into a corresponding movement of the cursor 52 in screen space 50. That is, the world space position 46 of the hand 42 may be translated into a screen space cursor position 56 of a user interface 60 displayed by the computing system. In the depicted example, hand 42 is from t₀To t from an initial hand position (hand depicted in dashed lines) of₁Movement of the final hand position (hand depicted in solid lines) causes a corresponding movement of the cursor 52 from the initial cursor position (cursor depicted in dashed lines) to the final cursor position (cursor depicted in solid lines).

The user interface 60 may include one or more control features that may be activated or selected by predefined hand movements. These features may include: such as knobs, dials, buttons, menus, etc. In the depicted example, the user interface 60 includes a button 62, which button 62 is actuatable by hand movement that occurs when the cursor 52 is covering the button 62 in the screen space 50.

A front view of cursor movement is depicted at 70. This view shows movement in the x-y plane of the screen space, but does not show movement in the z plane of the screen space. In the depicted example, this hand movement moves the cursor to a final cursor position where the cursor 52 overlays the button 62.

At any given time, the position of the cursor may be defined by x-y-z coordinates, where the x coordinate indicates the horizontal position of the cursor, the y coordinate indicates the vertical position of the cursor, and the z coordinate indicates the depth of the cursor. The button 62 may have an actuation perimeter 64 in the x-y plane of the screen space. The actuation perimeter 64 may or may not correspond to the display perimeter of the button. If the x-y coordinates of the cursor 52 are within the actuation perimeter 64 of the button 62, the cursor 52 may be considered to be covering the button 62 regardless of the z-axis coordinates of the cursor relative to the button.

In one example, where the cursor 52 is defined by an irregular shape, at least one x-y coordinate of the cursor 52 may be necessary to cover the actuation perimeter 64 of the button 62. The cursor 52 may be at a different depth in the screen space 50 than the button (e.g., before the button or remote from the button), however the cursor 52 may actuate the button 62 as long as the x-y coordinates of the cursor 52 cover the actuation perimeter 64 of the button 62.

FIG. 4 illustrates example cursor movements that result in cursor actuation. In particular, a side view 80 of this cursor movement is depicted. Thus, this view 80 shows movement in the y-z plane of the screen space, but does not show movement in the x plane of the screen space. At t₁Here, the cursor 52 is at an initial cursor position (cursor depicted in dashed lines) with the cursor 52 overlying the button 62. At t₂At this point, movement of the hand in world space moves the cursor 52 to a subsequent cursor position (the cursor depicted in solid lines). The button 62 is actuated in response to movement of the hand in world space that changes the cursor position by at least a depth threshold (Δ Z) along the Z-axis, regardless of the initial Z-axis position of the cursor 52. In other words, the hand is atMovement in world space "presses" the cursor by at least the depth threshold (Δ Z), thereby actuating the button 62.

In one example, the depth (i.e., z-coordinate) of the cursor may be sampled when the cursor first covers the button. This depth may be used as a reference for determining whether a compression motion has occurred (i.e., a zero compression value). That is, the change in the z-coordinate of the cursor 52 is measured from this reference value. The depth change may be calculated as a distance traveled along the z-axis, for example.

The button 62 may be actuated in response to a relative change in the z-coordinate of the cursor 52, regardless of the absolute z-coordinate of the cursor 52 at the initial and final positions. Thus, the button 62 may be actuated even if the cursor 52 does not reach the depth of the button 62. In other words, the button 62 is actuated regardless of whether the cursor 52 is moved or "pressed" from an initial position in front of the button to a final position in front of the button, or moved or "pressed" from an initial position in front of the button to a final position in front of the button.

As shown in FIG. 5, the cursor may have normalized (normalized) vector components (V, respectively) that may be represented by each along the x-y-z axis_x、V_yAnd V_z) The characterized cursor speed 120. The depth threshold for button actuation may be set based on absolute cursor speed, absolute cursor speed along a particular axis, and/or normalized cursor speed along a particular axis (i.e., speed on one axis relative to one or more other axes). In other words, the speed of the pressing movement may determine how far the cursor has to be pressed for button actuation. As one example, the depth threshold may be decreased as the z-axis component of the cursor speed increases. Likewise, the depth threshold may be increased as the z-axis component of the cursor velocity decreases. In other words, to activate the button, the cursor may be pressed a small distance when the hand is moving quickly, and a large distance when the hand is moving slowly. This allows both a shorter, sharper "tap" and a longer, slower press to initiate a pressA button.

As another example, the depth threshold may be decreased as the normalized z-axis component of cursor velocity increases. Likewise, the depth threshold may be increased as the normalized z-axis component of cursor velocity decreases. In other words, less total pushing may be required to actuate the button when the cursor movement is more directly in the z-direction than when the cursor movement is less directly in the z-direction.

In some embodiments, when the cursor overlays a button in the user interface, the button may be actuated in response to movement of the hand in world space that moves the cursor position at a velocity having a normalized z-axis component equal to or greater than a z-axis velocity threshold. The activation may be based on a normalized z-axis component rather than an absolute z-axis velocity. This allows any hand movement that results in intentional movement of the cursor into the planar space to be treated as initiating a "push" movement regardless of the speed at which the cursor moves into the planar space.

The cursor speed at any given time may be tracked during movement of the cursor. FIG. 6 shows time (t)₀To t₂) An example of tracked cursor speed. Here, the sequential change in cursor velocity during cursor movement is represented by a change in the cursor velocity vector and its normalized x, y, and z-axis components. At t₀Here, the cursor has a cursor velocity 130, which cursor velocity 130 has a larger normalized x-axis component and a normalized y-axis component but a smaller normalized z-axis component. That is, the cursor may move faster and/or in a more pronounced manner in the x-y plane of the screen space than in the z direction of the screen space. In other words, the cursor moves faster on the screen surface than into (or out of) the screen surface.

At t₀And t₁In between, cursor movement in the x-y plane decreases and increases by a smaller amount along the z-axis. I.e. the movement of the cursor in the plane of the screen becomes slower. This results in t₁A cursor velocity vector 140 having a smaller normalized x-axis component and a normalizedThe y-axis component and a relatively larger normalized z-axis component (with t)₀Normalized component comparison of (a).

At t₁And t₂In between, cursor movement may experience sudden path changes. In the depicted example, the movement of the cursor on the screen is rapidly slowed, while the movement of the cursor into the screen is rapidly increased. This results in t₂A cursor velocity vector 150 having an even smaller normalized x-axis component and normalized y-axis component and, in fact, a larger normalized z-axis component (with t)₀And t₁Normalized component comparison of (a).

These cursor speeds may be considered along with one or more other parameters to infer whether the user tends to press a button. For example, the cursor speed before or after the cursor overlays a button may be analyzed to infer whether the user tends to press the button.

In some embodiments, the button may have an activation lock configured to reduce false positives that may occur when the user does not want to press the button. Thus, the boot lock can only be unlocked if the cursor path (i.e., the sequence of cursor speeds) satisfies the unlocking criteria. Thus, the button may have to be unlocked before the pressing action can be recognized and the button can be activated.

As one example, the unlocking criteria may include the x-y speed of the cursor decreasing by a deceleration threshold as the cursor approaches the button. In other words, the activation lock of the button may be unlocked in response to a significant decrease in cursor speed across the screen. The decrease in cursor speed in the x-y plane may be read when the cursor is within a threshold distance of the button. In this manner, the deceleration of the cursor's movement across the screen is effectively read as the intent of the user to select and possibly press a button while the cursor is in the vicinity of the button.

At t in FIG. 6₁An example of a lock-initiating cursor movement of an unlockable button is depicted. Cursor at t₁Can be compared at t₀Closer to the button. The cursor is pressed at its approachThe button is moved more slowly. Cursor speed at t₁The normalized x-axis component and the normalized y-axis component decrease of (a) is read as the user's intent to select the button and thus the actuation lock is unlocked. When at t₁After unlocking the starting lock, may then be initiated at time t₂The button is actuated.

As another example, the unlocking criteria may include a normalized decrease in the z-axis component when the cursor is within a threshold x-y distance of the button. In other words, the activation lock of the button may be unlocked in response to a significant increase in the speed of the cursor entering the screen. In this manner, the acceleration of the cursor's movement into the screen is effectively read as the user's intent to press the button when the cursor is in the vicinity of the button.

If the activation lock is unlocked, the button may be activated in response to hand movement in world space that moves the cursor position at a velocity having a normalized z-axis component equal to or greater than the z-axis velocity threshold.

In some embodiments, the methods and processes described above may be bundled into a computing system comprising one or more computers. In particular, the methods and processes described herein may be implemented as a computer application, computer service, computer API, computer library, and/or other computer program product.

FIG. 7 schematically illustrates a non-limiting computing system 160 that can perform one or more of the above-described methods and processes. Computing system 160 is shown in simplified form. It should be understood that substantially any computer architecture may be used without departing from the scope of this disclosure. In different embodiments, the computing system 160 may take the form of a mainframe computer, server computer, desktop computer, laptop computer, tablet computer, home entertainment computer, network computing device, mobile communication device, gaming device, and the like.

Computing system 160 may include a logic subsystem 162, a data-holding subsystem 164, a display subsystem 166, and/or a capture device 168. The computing system may optionally include components not shown in fig. 7, and/or some of the components shown in fig. 7 may be peripheral components that are not integrated into the computing system.

Logic subsystem 162 may include one or more physical devices configured to execute one or more instructions. For example, the logic subsystem may be configured to execute one or more instructions that are part of one or more applications, services, programs, routines, libraries, objects, components, data structures, or other logical constructs. Such instructions may be implemented to perform a task, implement a data type, transform the state of one or more devices, or otherwise arrive at a desired result.

The logic subsystem may include one or more processors configured to execute software instructions. Additionally or alternatively, the logic subsystem may include one or more hardware or firmware logic machines configured to execute hardware or firmware instructions. The processors of the logic subsystem may be single-core or multi-core, and the programs executing thereon may be configured for parallel or distributed processing. The logic subsystem may optionally include individual components that are distributed throughout two or more devices, which may be remotely located and/or configured for coordinated processing. One or more aspects of the logic subsystem may be virtualized and executed by remotely accessible networked computing devices configured in a cloud computing configuration.

Data-holding subsystem 164 may include one or more physical, non-transitory devices configured to hold data and/or instructions executable by the logic subsystem to implement the herein described methods and processes. In implementing such methods and processes, the state of data-holding subsystem 164 may be transformed (e.g., to hold different data).

Data-holding subsystem 164 may include removable media and/or built-in devices. Data-holding subsystem 164 may include optical memory devices (e.g., CD, DVD, HD-DVD, Blu-ray disc, etc.), semiconductor memory devices (e.g., RAM, EPROM, EEPROM, etc.) and/or magnetic memory devices (e.g., hard disk drive, floppy disk drive, tape drive, MRAM, etc.), among others. Data-holding subsystem 164 may include devices with one or more of the following characteristics: volatile, nonvolatile, dynamic, static, read/write, read-only, random access, sequential access, location addressable, file addressable, and content addressable. In some embodiments, logic subsystem 162 and data-holding subsystem 164 may be integrated into one or more common devices, such as an application specific integrated circuit or a system on a chip.

FIG. 7 also illustrates an aspect of the data-holding subsystem in the form of removable computer-readable storage media 170, which may be used to store and/or transfer data and/or instructions executable to implement the herein described methods and processes. The removable computer-readable storage medium 170 may take the form of, inter alia, a CD, DVD, HD-DVD, Blu-ray disc, EEPROM, and/or floppy disk.

As will be appreciated, data-holding subsystem 164 includes one or more aspects of physical, non-transitory devices. Rather, in some embodiments, aspects of the instructions described herein may propagate in a transient manner through a pure signal (e.g., an electromagnetic signal, an optical signal, etc.) that is not held by the physical device for at least a finite duration. In addition, data and/or other forms of information pertaining to the present invention may propagate through a pure signal.

The term "module" may be used to describe an aspect of computing system 160 that is implemented to perform one or more particular functions. In some cases, such a module may be instantiated via logic subsystem 162 executing instructions held by data-holding subsystem 164. It should be appreciated that different modules and/or engines may be instantiated from the same application, code block, object, routine, and/or function. Also, in some cases, the same module and/or engine may be instantiated by different applications, code blocks, objects, routines, and/or functions.

As described herein, computing system 160 includes a depth image analysis module 172, the depth image analysis module 172 configured to track a world space pose of a human in a fixed, world space coordinate system. The term "pose" refers to a position, orientation, physical arrangement, etc. of a human being. As described herein, the computing system 160 includes an interaction module 174, the interaction module 174 configured to establish a virtual interaction zone with a movable, interface space coordinate system that tracks humans and moves relative to a fixed, world space coordinate system. As described herein, the computing system 160 includes a transformation module 176, the transformation module 176 configured to transform a location defined in a fixed, world-space coordinate system to a location defined in a movable, interface-space coordinate system. Computing system 160 also includes a display module 178, the display module 178 configured to output display signals for displaying the interface element at desktop space coordinates corresponding to the position defined in the movable, interface space coordinate system.

Computing system 160 includes a user interface module 177, the module 177 configured to translate movement of a cursor in a user interface into an action involving an interface element. As a non-limiting example, user interface module 177 may analyze the movement of a cursor relative to buttons of the user interface to determine when to unlock and/or actuate the buttons.

Display subsystem 166 may be used to present a visual representation of data held by data-holding subsystem 164. As the herein described methods and processes change the data held by the data-holding subsystem, and thus transform the state of the data-holding subsystem, the state of display subsystem 166 may likewise be transformed to visually represent changes in the underlying data. As one non-limiting example, the target recognition, tracking, and analysis described herein may be reflected by display subsystem 166 in the form of an interface element (e.g., a cursor) that changes position in a virtual desktop in response to user movement in physical space. Display subsystem 166 may include one or more display devices using virtually any type of technology. These display devices may be combined in a shared enclosure with logic subsystem 162 and/or data-holding subsystem 164, or these display devices may be peripheral display devices, as shown in FIG. 1.

Computing system 160 also includes a capture device 168 configured to obtain depth images of one or more targets. Capture device 168 may be configured to capture video with depth information via any suitable technique (e.g., time-of-flight, structured light, stereo image, etc.). As such, capture device 168 may include a depth camera (such as depth camera 22 of FIG. 1), a video camera, a stereo camera, and/or other suitable capture devices.

For example, in time-of-flight analysis, the capture device 168 may emit infrared light toward the target and then use a sensor to detect the backscattered light from the surface of the target. In some cases, pulsed infrared light may be used, where the time between an outgoing light pulse and a corresponding incoming light pulse may be measured and used to determine a physical distance from the capture device to a particular location on the target. In some cases, the phase of the outgoing light wave may be compared to the phase of the incoming light wave to determine a phase shift, and the phase shift may be used to determine a physical distance from the capture device to a particular location on the target.

In another example, time-of-flight analysis may be used to indirectly determine a physical distance from the capture device to a particular location on the target by analyzing the intensity of the reflected beam of light over time via techniques such as shuttered light pulse imaging.

In another example, capture device 168 may utilize structured light analysis to capture depth information. In such an analysis, patterned light (i.e., light displayed as a known pattern such as a grid pattern or a stripe pattern) may be projected onto a target. On the surface of the target, the pattern may become distorted, and such distortion of the pattern may be studied to determine a physical distance from the capture device to a particular location on the target.

In another example, a capture device may include two or more physically separated cameras that view a target from different angles to obtain visual stereo data. In these cases, the visual stereo data may be decomposed to generate a depth image.

In other embodiments, capture device 168 may utilize other techniques to measure and/or calculate depth values. Additionally, capture device 168 may organize the calculated depth information into "Z layers," i.e., layers perpendicular to a Z axis extending from the depth camera along its line of sight to the viewer.

In some embodiments, two or more cameras may be integrated into one integrated capture device. For example, a depth camera and a video camera (e.g., an RGB video camera) may be integrated into a common capture device. In some embodiments, two or more separate capture devices may be used in conjunction. For example, a depth camera and a separate camera may be used. When a camera is used, the camera may be used to provide: target tracking data, confirmation data to correct for target tracking, image capture, facial recognition, high precision tracking of a finger (or other small feature), light sensing, and/or other functions.

It is to be understood that at least some target analysis and tracking operations may be performed by the logic machine of one or more capture devices. The capture device may include one or more onboard processing units configured to perform one or more target analysis and/or tracking functions. The capture device may include firmware to help update such on-board processing logic.

Computing system 160 may optionally include one or more input devices, such as controller 180 and controller 182. The input device may be used to control the operation of the computing system. In the context of a game, input devices such as controller 180 and/or controller 182 may be used to control aspects of the game that are not controlled by the target recognition, tracking, and analysis methods and processes described herein. In certain embodiments, input devices such as controller 180 and/or controller 182 may include one or more of accelerometers, gyroscopes, infrared target/sensor systems, etc., which may be used to measure movement of the controllers in physical space. In some embodiments, the computing system may optionally include and/or utilize input gloves, keyboards, mice, trackpads, trackballs, touch screens, buttons, switches, dials, and/or other input devices. As will be appreciated, target recognition, tracking, and analysis may be used to control or augment aspects of a game or other application that are conventionally controlled by an input device, such as a game controller. In some embodiments, the target tracking described herein may be used as a complete replacement for other forms of user input, while in other embodiments, such target tracking may be used to supplement one or more other forms of user input.

Claims (4)

1. A computing system (12, 160) comprising:

a peripheral input configured to receive a depth image from a depth camera (22);

a display output configured to output a user interface (60) to a display device (14), the user interface (60) including a button (62);

a logic subsystem (162) operatively connected to the depth camera (22) via the peripheral input and operatively connected to the display device (14) via the display output; and

a data-holding subsystem (164) holding instructions executable by the logic subsystem (162) to:

receiving one or more depth images of a world space scene (24) including a human target (18) from the depth camera (22);

translating a world space position (46) of a hand (42) of the human target (18) into a screen space cursor position (56) of the user interface (60) such that movement of the hand (42) in world space (40) results in corresponding movement of a cursor (52) in screen space (50); and

activating the button (62) in response to movement of the hand (42) in world space (40) that changes the cursor position (56) along a z-axis by a depth threshold while the cursor (52) overlays the button (62) in the user interface (60), regardless of an initial z-axis position and a final z-axis position of the cursor (52);

wherein the cursor has a cursor speed, and wherein the data-holding subsystem holds instructions executable by the logic subsystem to adjust the depth threshold based on the cursor speed, and wherein the depth threshold is decreased as the normalized z-axis component of the cursor speed increases, and the depth threshold is increased as the normalized z-axis component of the cursor speed decreases.

2. The computing system of claim 1, wherein the button has a launch perimeter in an x-y plane, and wherein the cursor overlays the button if an x-y coordinate of the cursor is within the launch perimeter of the button.

3. The computing system of claim 1, wherein a location and an orientation of the interaction zone are based on a location and an orientation of the human target.

4. The computing system of claim 3, wherein the location and orientation of the interaction zone is based on a relative position of the head of the human target.