Patent Application
20140368537
Mixed reality is a technology that allows holographic, or virtual, imagery to be mixed with a real world physical environment. A see-through, head mounted, mixed reality display device may be worn by a user to view the mixed imagery of real objects and virtual objects displayed in the user's field of view. A user may further interact with virtual objects, for example by performing hand, head or voice gestures to move the objects, alter their appearance or simply view them. Where there are multiple users, each may view a virtual object in the scene from their own perspective. However, where virtual objects are interactive in some way, multiple users interacting concurrently may make the system cumbersome to use.
Embodiments of the present technology relate to a system and method for multi-user interaction with virtual objects, also referred to herein as holograms. A system for creating a mixed reality environment in general includes a see-through, head mounted display device worn by each user and coupled to one or more processing units. The processing units in cooperation with the head mounted display unit(s) are able to display virtual objects, viewable by each user from their own perspective. The processing units in cooperation with the head mounted display unit(s) are also able to detect user interaction with virtual objects via gestures performed by one or more users.
In accordance with aspects of the present technology, certain virtual objects may be designated as shared, so that multiple users can view those shared virtual objects and multiple users can collaborate together in interacting with the shared virtual objects. Other virtual objects may be designated as private to a particular user. A private virtual object may be visible to a single user. In embodiments, private virtual objects may be provided for a variety of purposes, but private virtual objects of respective users may facilitate the users' collaborative interaction with one or more shared virtual objects.
In an example, the present technology relates to a system for presenting a mixed reality experience, the system comprising: a first display device including a display unit for displaying virtual objects including a shared virtual object and a private virtual object; and a computing system operatively coupled to the first display device and a second display device, the computing system generating the shared and private virtual objects for display on the first display device, and the computing system generating the shared but not the private virtual object for display on a second display device.
In a further example, the present technology relates to a system for presenting a mixed reality experience, the system comprising: a first display device including a display unit for displaying virtual objects; a second display device including a display unit for displaying virtual objects; and a computing system operatively coupled to the first and second display devices, the computing system generating a shared virtual object for display on the first and second display devices from state data defining the shared virtual object, the computing system further generating a first private virtual object for display on the first display device and not the second display device, and a second private virtual object for display on the second display device and not the first display device, the computing system receiving an interaction changing the state data and the display of the shared virtual object on both the first and second display devices.
In another example, the present technology relates to a method for presenting a mixed reality experience, the method comprising: (a) displaying a shared virtual object to a first display device and a second display device, the shared virtual object defined by state data that is the same for the first and second display devices; (b) displaying a first private virtual object to the first display device; (c) displaying a second private virtual object to the second display device; (d) receiving an interaction with one of the first and second private virtual objects; and (e) affecting a change in the shared virtual object based on the interaction with one of the first and second private virtual objects received in said step (d).
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 as an aid in determining the scope of the claimed subject matter.
Embodiments of the present technology will now be described with reference to
A head mounted display device may include a display element. The display element is to a degree transparent so that a user can look through the display element at real world objects within the user's field of view (FOV). The display element also provides the ability to project virtual images into the FOV of the user such that the virtual images may also appear alongside the real world objects. The system automatically tracks where the user is looking so that the system can determine where to insert the virtual image in the FOV of the user. Once the system knows where to project the virtual image, the image is projected using the display element.
In embodiments, the hub computing system and one or more of the processing units may cooperate to build a model of the environment including the x, y, z Cartesian positions of all users, real world objects and virtual three-dimensional objects in the room or other environment. The positions of each head mounted display device worn by the users in the environment may be calibrated to the model of the environment and to each other. This allows the system to determine each user's line of sight and FOV of the environment. Thus, a virtual image may be displayed to each user, but the system determines the display of the virtual image from each user's perspective, adjusting the virtual image for parallax and any occlusions from or by other objects in the environment. The model of the environment, referred to herein as a scene map, as well as all tracking of the user's FOV and objects in the environment may be generated by the hub and mobile processing unit working in tandem or individually.
As explained below, one or more users may choose to interact with shared or private virtual objects appearing within the user's FOV. As used herein, the term “interact” encompasses both physical interaction and verbal interaction of a user with a virtual object. Physical interaction includes a user performing a predefined gesture using his or her fingers, hand, head and/or other body part(s) recognized by the mixed reality system as a user-request for the system to perform a predefined action. Such predefined gestures may include but are not limited to pointing at, grabbing, and pushing virtual objects. Such predefined gestures may further include interaction with a virtual control object such as a virtual remote control or keyboard.
A user may also physically interact with a virtual object with his or her eyes. In some instances, eye gaze data identifies where a user is focusing in the FOV, and can thus identify that a user is looking at a particular virtual object. Sustained eye gaze, or a blink or blink sequence, may thus be a physical interaction whereby a user selects one or more virtual objects.
As used herein, a user simply looking at a virtual object, such as viewing content in a shared virtual object, is a further example of physical interaction of a user with a virtual object.
A user may alternatively or additionally interact with virtual objects using verbal gestures, such as for example a spoken word or phrase recognized by the mixed reality system as a user request for the system to perform a predefined action. Verbal gestures may be used in conjunction with physical gestures to interact with one or more virtual objects in the mixed reality environment.
As a user moves around within a mixed reality environment, virtual objects may remain world locked or body locked. World locked virtual objects are those that remain in a fixed position in Cartesian space. Users may move nearer to, farther from or around such world locked virtual objects and view them from different perspectives. In embodiments, shared virtual objects may be world locked.
On the other hand, body locked virtual objects are those that move with a particular user. As one example, body locked virtual objects may remain in a fixed position with respect to a user's head. In embodiments, private virtual object may be body locked. In further examples, virtual objects such private virtual objects may be a hybrid world locked/body locked virtual object. Such hybrid virtual objects are described for example in U.S. patent application Ser. No. 13/921,116 entitled “Hybrid World/Body Locked HUD on an HMD,” filed Jun. 18, 2013.
Head mounted display device 2, which in one embodiment is in the shape of glasses, is worn on the head of a user so that the user can see through a display and thereby have an actual direct view of the space in front of the user. The use of the term “actual direct view” refers to the ability to see the real world objects directly with the human eye, rather than seeing created image representations of the objects. For example, looking through glass at a room allows a user to have an actual direct view of the room, while viewing a video of a room on a television is not an actual direct view of the room. More details of the head mounted display device 2 are provided below.
The processing unit 4 may include much of the computing power used to operate head mounted display device 2. In embodiments, the processing unit 4 communicates wirelessly (e.g., WiFi, Bluetooth, infra-red, or other wireless communication means) to one or more hub computing systems 12. As explained hereinafter, hub computing system 12 may be provided remotely from the processing unit 4, so that the hub computing system 12 and processing unit 4 communicate via a wireless network such as a LAN or WAN. In further embodiments, the hub computing system 12 may be omitted to provide a mobile mixed reality experience using the head mounted display devices 2 and processing units 4.
Hub computing system 12 may be a computer, a gaming system or console, or the like. According to an example embodiment, the hub computing system 12 may include hardware components and/or software components such that hub computing system 12 may be used to execute applications such as gaming applications, non-gaming applications, or the like. In one embodiment, hub computing system 12 may include a processor such as a standardized processor, a specialized processor, a microprocessor, or the like that may execute instructions stored on a processor readable storage device for performing the processes described herein.
Hub computing system 12 further includes a capture device 20 for capturing image data from portions of a scene within its FOV. As used herein, a scene is the environment in which the users move around, which environment is captured within the FOV of the capture device 20 and/or the FOV of each head mounted display device 2.
Hub computing system 12 may be connected to an audiovisual device 16 such as a television, a monitor, a high-definition television (HDTV), or the like that may provide game or application visuals. In one example, audiovisual device 16 includes internal speakers. In other embodiments, audiovisual device 16 and hub computing system 12 may be connected to external speakers 22.
The hub computing system 12, together with the head mounted display device 2 and processing unit 4, may provide a mixed reality experience where one or more virtual images, such as virtual object 21 in
A portion of the frame of head mounted display device 2 will surround a display (that includes one or more lenses). In order to show the components of head mounted display device 2, a portion of the frame surrounding the display is not depicted. The display includes a light-guide optical element 115, opacity filter 114, see-through lens 116 and see-through lens 118. In one embodiment, opacity filter 114 is behind and aligned with see-through lens 116, light-guide optical element 115 is behind and aligned with opacity filter 114, and see-through lens 118 is behind and aligned with light-guide optical element 115. See-through lenses 116 and 118 are standard lenses used in eye glasses and can be made to any prescription (including no prescription). Light-guide optical element 115 channels artificial light to the eye. More details of opacity filter 114 and light-guide optical element 115 are provided in U.S. Published Patent Application No. 2012/0127284, entitled, “Head-Mounted Display Device Which Provides Surround Video,” which application published on May 24, 2012.
Control circuits 136 provide various electronics that support the other components of head mounted display device 2. More details of control circuits 136 are provided below with respect to
Microdisplay 120 projects an image through lens 122. There are different image generation technologies that can be used to implement microdisplay 120. For example, microdisplay 120 can be implemented in using a transmissive projection technology where the light source is modulated by optically active material, backlit with white light. These technologies are usually implemented using LCD type displays with powerful backlights and high optical energy densities. Microdisplay 120 can also be implemented using a reflective technology for which external light is reflected and modulated by an optically active material. The illumination is forward lit by either a white source or RGB source, depending on the technology. Digital light processing (DLP), liquid crystal on silicon (LCOS) and Mirasol® display technology from Qualcomm, Inc. are all examples of reflective technologies which are efficient as most energy is reflected away from the modulated structure and may be used in the present system. Additionally, microdisplay 120 can be implemented using an emissive technology where light is generated by the display. For example, a PicoP™ display engine from Microvision, Inc. emits a laser signal with a micro mirror steering either onto a tiny screen that acts as a transmissive element or beamed directly into the eye (e.g., laser).
Light-guide optical element 115 transmits light from microdisplay 120 to the eye 140 of the user wearing head mounted display device 2. Light-guide optical element 115 also allows light from in front of the head mounted display device 2 to be transmitted through light-guide optical element 115 to eye 140, as depicted by arrow 142, thereby allowing the user to have an actual direct view of the space in front of head mounted display device 2 in addition to receiving a virtual image from microdisplay 120. Thus, the walls of light-guide optical element 115 are see-through. Light-guide optical element 115 includes a first reflecting surface 124 (e.g., a mirror or other surface). Light from microdisplay 120 passes through lens 122 and becomes incident on reflecting surface 124. The reflecting surface 124 reflects the incident light from the microdisplay 120 such that light is trapped inside a planar substrate comprising light-guide optical element 115 by internal reflection. After several reflections off the surfaces of the substrate, the trapped light waves reach an array of selectively reflecting surfaces 126. Note that one of the five surfaces is labeled 126 to prevent over-crowding of the drawing. Reflecting surfaces 126 couple the light waves incident upon those reflecting surfaces out of the substrate into the eye 140 of the user. More details of a light-guide optical element can be found in United States Patent Publication No. 2008/0285140, entitled “Substrate-Guided Optical Devices,” published on Nov. 20, 2008.
Head mounted display device 2 also includes a system for tracking the position of the user's eyes. As will be explained below, the system will track the user's position and orientation so that the system can determine the FOV of the user. However, a human will not perceive everything in front of them. Instead, a user's eyes will be directed at a subset of the environment. Therefore, in one embodiment, the system will include technology for tracking the position of the user's eyes in order to refine the measurement of the FOV of the user. For example, head mounted display device 2 includes eye tracking assembly 134 (
In one embodiment, the system will use four IR LEDs and four IR photo detectors in rectangular arrangement so that there is one IR LED and IR photo detector at each corner of the lens of head mounted display device 2. Light from the LEDs reflect off the eyes. The amount of infrared light detected at each of the four IR photo detectors determines the pupil direction. That is, the amount of white versus black in the eye will determine the amount of light reflected off the eye for that particular photo detector. Thus, the photo detector will have a measure of the amount of white or black in the eye. From the four samples, the system can determine the direction of the eye.
Another alternative is to use four infrared LEDs as discussed above, but one infrared CCD on the side of the lens of head mounted display device 2. The CCD will use a small mirror and/or lens (fish eye) such that the CCD can image up to 75% of the visible eye from the glasses frame. The CCD will then sense an image and use computer vision to find the image, much like as discussed above. Thus, although
Another embodiment for tracking the direction of the eyes is based on charge tracking. This concept is based on the observation that a retina carries a measurable positive charge and the cornea has a negative charge. Sensors are mounted by the user's ears (near earphones 130) to detect the electrical potential while the eyes move around and effectively read out what the eyes are doing in real time. Other embodiments for tracking eyes can also be used.
Some of the components of
In one embodiment, all of the components of control circuit 200 are in communication with each other via dedicated lines or one or more buses. In another embodiment, each of the components of control circuit 200 is in communication with processor 210. Camera interface 216 provides an interface to the two room-facing cameras 112 and stores images received from the room-facing cameras in camera buffer 218. Display driver 220 will drive microdisplay 120. Display formatter 222 provides information, about the virtual image being displayed on microdisplay 120, to opacity control circuit 224, which controls opacity filter 114. Timing generator 226 is used to provide timing data for the system. Display out interface 228 is a buffer for providing images from room-facing cameras 112 to the processing unit 4. Display in interface 230 is a buffer for receiving images such as a virtual image to be displayed on microdisplay 120. Display out interface 228 and display in interface 230 communicate with band interface 232 which is an interface to processing unit 4.
Power management circuit 202 includes voltage regulator 234, eye tracking illumination driver 236, audio DAC and amplifier 238, microphone preamplifier and audio ADC 240, temperature sensor interface 242 and clock generator 244. Voltage regulator 234 receives power from processing unit 4 via band interface 232 and provides that power to the other components of head mounted display device 2. Eye tracking illumination driver 236 provides the IR light source for eye tracking illumination 134A, as described above. Audio DAC and amplifier 238 output audio information to the earphones 130. Microphone preamplifier and audio ADC 240 provides an interface for microphone 110. Temperature sensor interface 242 is an interface for temperature sensor 138. Power management circuit 202 also provides power and receives data back from three axis magnetometer 132A, three axis gyro 132B and three axis accelerometer 132C.
Power management circuit 306 includes clock generator 360, analog to digital converter 362, battery charger 364, voltage regulator 366, head mounted display power source 376, and temperature sensor interface 372 in communication with temperature sensor 374 (possibly located on the wrist band of processing unit 4). Analog to digital converter 362 is used to monitor the battery voltage, the temperature sensor and control the battery charging function. Voltage regulator 366 is in communication with battery 368 for supplying power to the system. Battery charger 364 is used to charge battery 368 (via voltage regulator 366) upon receiving power from charging jack 370. HMD power source 376 provides power to the head mounted display device 2.
As shown in
Camera component 423 may include an infra-red (IR) light component 425, a three-dimensional (3-D) camera 426, and an RGB (visual image) camera 428 that may be used to capture the depth image of a scene. For example, in time-of-flight analysis, the IR light component 425 of the capture device 20 may emit an infrared light onto the scene and may then use sensors (in some embodiments, including sensors not shown) to detect the backscattered light from the surface of one or more targets and objects in the scene using, for example, the 3-D camera 426 and/or the RGB camera 428.
In an example embodiment, the capture device 20 may further include a processor 432 that may be in communication with the image camera component 423. Processor 432 may include a standardized processor, a specialized processor, a microprocessor, or the like that may execute instructions including, for example, instructions for receiving a depth image, generating the appropriate data format (e.g., frame) and transmitting the data to hub computing system 12.
Capture device 20 may further include a memory 434 that may store the instructions that are executed by processor 432, images or frames of images captured by the 3-D camera and/or RGB camera, or any other suitable information, images, or the like. According to an example embodiment, memory 434 may include random access memory (RAM), read only memory (ROM), cache, flash memory, a hard disk, or any other suitable storage component. As shown in
Capture device 20 is in communication with hub computing system 12 via a communication link 436. The communication link 436 may be a wired connection including, for example, a USB connection, a Firewire connection, an Ethernet cable connection, or the like and/or a wireless connection such as a wireless 802.11b, g, a, or n connection. According to one embodiment, hub computing system 12 may provide a clock to capture device 20 that may be used to determine when to capture, for example, a scene via the communication link 436. Additionally, the capture device 20 provides the depth information and visual (e.g., RGB) images captured by, for example, the 3-D camera 426 and/or the RGB camera 428 to hub computing system 12 via the communication link 436. In one embodiment, the depth images and visual images are transmitted at 30 frames per second; however, other frame rates can be used. Hub computing system 12 may then create and use a model, depth information, and captured images to, for example, control an application such as a game or word processor and/or animate an avatar or on-screen character.
The above-described hub computing system 12, together with the head mounted display device 2 and processing unit 4, are able to insert a virtual three-dimensional object into the FOV of one or more users so that the virtual three-dimensional object augments and/or replaces the view of the real world. In one embodiment, head mounted display device 2, processing unit 4 and hub computing system 12 work together as each of the devices includes a subset of sensors that are used to obtain the data to determine where, when and how to insert the virtual three-dimensional object. In one embodiment, the calculations that determine where, when and how to insert a virtual three-dimensional object are performed by the hub computing system 12 and processing unit 4 working in tandem with each other. However, in further embodiments, all calculations may be performed by the hub computing system 12 working alone or the processing unit(s) 4 working alone. In other embodiments, at least some of the calculations can be performed by the head mounted display device 2.
The hub 12 may further include a skeletal tracking module 450 for recognizing and tracking users within the FOV of another user. A wide variety of skeletal tracking techniques exist, but some such techniques are disclosed in U.S. Pat. No. 8,437,506 entitled, “System For Fast, Probabilistic Skeletal Tracking,” issued May 7, 2013. Hub 12 may further include a gesture recognition engine 454 for recognizing gestures performed by a user. More information about gesture recognition engine 454 can be found in U.S. Patent Publication 2010/0199230, “Gesture Recognizer System Architecture,” filed on Apr. 13, 2009.
In one example embodiment, hub computing system 12 and processing units 4 work together to create the scene map or model of the environment that the one or more users are in and track various moving objects in that environment. In addition, hub computing system 12 and/or processing unit 4 track the FOV of a head mounted display device 2 worn by a user 18 by tracking the position and orientation of the head mounted display device 2. Sensor information obtained by head mounted display device 2 is transmitted to processing unit 4. In one example, that information is transmitted to the hub computing system 12 which updates the scene model and transmits it back to the processing unit. The processing unit 4 then uses additional sensor information it receives from head mounted display device 2 to refine the FOV of the user and provide instructions to head mounted display device 2 on where, when and how to insert virtual objects. Based on sensor information from cameras in the capture device 20 and head mounted display device(s) 2, the scene model and the tracking information may be periodically updated between hub computing system 12 and processing unit 4 in a closed loop feedback system as explained below.
A graphics processing unit (GPU) 508 and a video encoder/video codec (coder/decoder) 514 form a video processing pipeline for high speed and high resolution graphics processing. Data is carried from the graphics processing unit 508 to the video encoder/video codec 514 via a bus. The video processing pipeline outputs data to an A/V (audio/video) port 540 for transmission to a television or other display. A memory controller 510 is connected to the GPU 508 to facilitate processor access to various types of memory 512, such as, but not limited to, a RAM (Random Access Memory).
The multimedia console 500 includes an I/O controller 520, a system management controller 522, an audio processing unit 523, a network interface 524, a first USB host controller 526, a second USB controller 528 and a front panel I/O subassembly 530 that are preferably implemented on a module 518. The USB controllers 526 and 528 serve as hosts for peripheral controllers 542(1)-542(2), a wireless adapter 548, and an external memory device 546 (e.g., flash memory, external CD/DVD ROM drive, removable media, etc.). The network interface 524 and/or wireless adapter 548 provide access to a network (e.g., the Internet, home network, etc.) and may be any of a wide variety of various wired or wireless adapter components including an Ethernet card, a modem, a Bluetooth module, a cable modem, and the like.
System memory 543 is provided to store application data that is loaded during the boot process. A media drive 544 is provided and may comprise a DVD/CD drive, Blu-Ray drive, hard disk drive, or other removable media drive, etc. The media drive 544 may be internal or external to the multimedia console 500. Application data may be accessed via the media drive 544 for execution, playback, etc. by the multimedia console 500. The media drive 544 is connected to the I/O controller 520 via a bus, such as a Serial ATA bus or other high speed connection (e.g., IEEE 1394).
The system management controller 522 provides a variety of service functions related to assuring availability of the multimedia console 500. The audio processing unit 523 and an audio codec 532 form a corresponding audio processing pipeline with high fidelity and stereo processing. Audio data is carried between the audio processing unit 523 and the audio codec 532 via a communication link. The audio processing pipeline outputs data to the A/V port 540 for reproduction by an external audio user or device having audio capabilities.
The front panel I/O subassembly 530 supports the functionality of the power button 550 and the eject button 552, as well as any LEDs (light emitting diodes) or other indicators exposed on the outer surface of the multimedia console 500. A system power supply module 536 provides power to the components of the multimedia console 500. A fan 538 cools the circuitry within the multimedia console 500.
The CPU 501, GPU 508, memory controller 510, and various other components within the multimedia console 500 are interconnected via one or more buses, including serial and parallel buses, a memory bus, a peripheral bus, and a processor or local bus using any of a variety of bus architectures. By way of example, such architectures can include a Peripheral Component Interconnects (PCI) bus, PCI-Express bus, etc.
When the multimedia console 500 is powered on, application data may be loaded from the system memory 543 into memory 512 and/or caches 502, 504 and executed on the CPU 501. The application may present a graphical user interface that provides a consistent user experience when navigating to different media types available on the multimedia console 500. In operation, applications and/or other media contained within the media drive 544 may be launched or played from the media drive 544 to provide additional functionalities to the multimedia console 500.
The multimedia console 500 may be operated as a standalone system by simply connecting the system to a television or other display. In this standalone mode, the multimedia console 500 allows one or more users to interact with the system, watch movies, or listen to music. However, with the integration of broadband connectivity made available through the network interface 524 or the wireless adapter 548, the multimedia console 500 may further be operated as a participant in a larger network community. Additionally, multimedia console 500 can communicate with processing unit 4 via wireless adaptor 548.
Optional input devices (e.g., controllers 542(1) and 542(2)) are shared by gaming applications and system applications. The input devices are not reserved resources, but are to be switched between system applications and the gaming application such that each will have a focus of the device. The application manager preferably controls the switching of input stream, without knowing the gaming application's knowledge and a driver maintains state information regarding focus switches. Capture device 20 may define additional input devices for the console 500 via USB controller 526 or other interface. In other embodiments, hub computing system 12 can be implemented using other hardware architectures. No one hardware architecture is required.
The head mounted display devices 2 and processing units 4 (together referred to at times as the mobile display device) shown in
In another embodiment, a system could include multiple hubs 12, with each hub including one or more mobile display devices. The hubs can communicate with each other directly or via the Internet (or other networks). Such an embodiment is disclosed in U.S. patent application Ser. No. 12/905,952 to Flaks et al., entitled “Fusing Virtual Content Into Real Content,” filed Oct. 15, 2010.
Moreover, in further embodiments, the hub 12 may be omitted altogether. One benefit of such an embodiment is that the mixed reality experience of the present system becomes fully mobile, and may be used in both indoor or outdoor settings. In such an embodiment, all functions performed by the hub 12 in the description that follows may alternatively be performed by one of the processing units 4, some of the processing units 4 working in tandem, or all of the processing units 4 working in tandem. In such an embodiment, the respective mobile display devices 2 perform all functions of system 10, including generating and updating state data, a scene map, each user's view of the scene map, all texture and rendering information, video and audio data, and other information to perform the operations described herein. The embodiments described below with respect to the flowchart of
The shared virtual object 460 is visible to and shared between various users, two users 18a, 18b in the example of
The shared virtual object may be defined by state data, including for example the appearance, content, position in three dimensional space, the degree to which the object is interactive or some of these attributes. The state data may change from time to time, for example when a shared virtual object is moved, the content is changed or it is interacted with in some way. Users 18a, 18b (and other users if present) may each receive the same state data for shared virtual objects 460, and each may receive the same updates to the state data. Accordingly, the users may see the same shared virtual object(s), though from their own perspective, and the users may each see the same changes as they are made to the shared virtual object 460 by one or more of the users and/or a software application controlling the shared virtual object 460.
As one of many examples, the shared virtual object 460 shown in
The content displayed on each virtual display slate 464 may be a wide variety of content, including static content such as photographs, illustrations, text and graphics, or dynamic content such as video. A virtual display slate 464 may further act as a computer monitor, so that the content 466 may be email, web pages, games or any other content presented on a monitor. A software application running on hub 12 may determine the content to be displayed on virtual display slates 464. Alternatively or additionally, users may add, alter or remove content 466 from the virtual display slates 464
Each user 18a, 18b may walk around the virtual carousel to view the different content 466 on the different display slates 464. As explained in greater detail below, the positions of each respective display slate 464 is known in the three dimensional space of the scene, and the FOV of each head mounted display device 2 is known. Thus, each head mounted display is able to determine where the user is looking, what display slate(s) 464 are within that user's FOV, and how the content 466 appears on those display slate(s) 464.
It is a feature of the present technology that users may collaborate together on shared virtual objects, for example using their own private virtual objects (explained below). In the example of
In some embodiments, a user may be able to interact with the content 466 in shared virtual object 460 to remove, add and/or alter displayed content. Once content is altered by a user or a software application controlling the shared virtual object 460, those alterations would be visible to each user 18a, 18b.
In embodiments, each user may have the same ability to view and interact with shared virtual objects. In further embodiments, different users may have different permission policies defining the degree to which the different users may interact with the shared virtual object 460. Permission policies may be defined by a software application presenting the shared virtual object 460 and/or by one or more users. As an example, one of the users 18a, 18b may be presenting a slide show or other presentation to the other user(s). In such an example, the user presenting the slide show may have the ability to rotate the virtual carousel while the other user(s) may not.
It is also conceivable that certain portions of the shared virtual content be visible to some users but not others, depending on the definitions in the users' permissions policies. Again, these permission policies may be defined by a software application presenting the shared virtual object 460 and/or by one or more users. Continuing with the slide show example, the user presenting the slide show may have notes on the slide show that are visible to the presenter, not others. The description of a slide show is just an example, and there may be a wide variety of other scenarios where different users have different permissions to view and/or interact with the shared virtual object(s) 460.
In addition to shared virtual objects, the present technology may include private virtual objects 462. User 18a has a private virtual object 462a and user 18b has a private virtual object 462b. In an example including additional users, each such additional user may have his or her own private virtual object 462. A user may have more than one private virtual object 462 in further embodiments.
Unlike shared virtual objects, private virtual objects 462 may just be visible to a user with which a private virtual object 462 is associated. Thus, the private virtual object 462a may be visible to user 18a but not 18b. The private virtual object 462b may be visible to user 18b but not 18a. Moreover, in embodiments, state data generated for, by or relating to a user's private virtual object 462 is not shared among multiple users.
It is conceivable that state data for a private virtual object be shared among more than one user, and that a private virtual object be visible to more than one user, in further embodiments. The sharing of state data and the ability of a user 18 to see another's private virtual object 462 may be defined in a permission policy for that user. As above, that permission policy may be set by an application presenting the private virtual object(s) 462 and/or one or more of the users 18.
Private virtual objects 462 may be provided for a wide variety of purposes, and may be in a wide variety of forms or include a wide variety of content. In one example, a private virtual object 462 may be used to interact with the shared virtual object 460. In the example of
The private virtual objects 468 may enable interaction with the shared virtual objects 460 in a wide variety of manners. In general, interactions with a user's private virtual object 468 may be defined by a software application controlling the private virtual object 468. When a user interacts with his or her private virtual object 468 in a defined manner, the software application may affect an associated change in or interaction on the shared virtual object 460. In the example of
Using the private virtual objects 468, it may happen that the interactions of different users with a shared object 460 may conflict with each other. For example, in the example of
Private virtual objects 468 may have uses other than for the interaction with the shared virtual object 460. Private virtual objects 468 may be used to display a variety of information and content to a user which is kept private to that user.
The shared virtual object(s) may be in any of a variety of forms and/or present any of a variety of different content.
In embodiments, the shared virtual object 460 and private virtual objects 462 may be provided to facilitate collaboration between users on the shared virtual object 460. In the example shown in
For example, the users 18 may be working together to create a painting, picture or other image. Each user may have a private virtual object 462a, 462b which they can interact with and add content to the shared virtual object 460. In further embodiments, the shared virtual object 460 may be broken down into different regions, with each user adding content to an assigned region via their private virtual object 462.
In the examples of
In embodiments described above, the shared virtual object 460 and private virtual objects 462 are separated in space. They need not be in further embodiments.
As noted above, in embodiments, all users 18 may view and collaborate on a single, common shared virtual object 460. The shared virtual object 460 may be positioned in a default position in three-dimensional space so which may be initially set by a software application providing the shared virtual object 460 or one or more of the users. Thereafter, the shared virtual object 460 may remain stationary in three-dimensional space, or it may be movable by one or more of the users 18 and/or a software application providing the shared virtual object 460.
Where one of the users 18 has control of the shared virtual object 460, for example as defined in the permissions policies of the respective users, it is conceivable that the shared virtual object 460 be body locked to the user having control of the shared virtual object 460. In such an embodiment, the shared virtual object 460 may move with the controlling user 18, and the remaining users 18 may move with the controlling user 18 to maintain their view of the shared virtual object 460.
In a further embodiment shown in
In general, the system generates a scene map having x, y, z coordinates of the environment and objects in the environment such as users, real world objects and virtual objects. As noted above, the shared virtual object(s) 460 and private virtual object(s) 462 may be virtually placed in the environment for example by an application running on hub computing system 12 or by one or more users 18. The system also tracks the FOV of each user. While all users may possibly be viewing the same aspects of the scene, they are viewing them from different perspectives. Thus, the system generates each person's FOV of the scene to adjust for parallax and occlusion of virtual or real world objects, which may again be different for each user.
For a given frame of image data, a user's view may include one or more real and/or virtual objects. As a user turns his/her head, for example left to right or up and down, the relative position of real world objects in the user's FOV inherently moves within the user's FOV. For example, plant 23 in
However, the display of virtual objects to a user as the user moves his head is a more difficult problem. In an example where a user is looking at a world locked virtual object in his FOV, if the user moves his head left to move the FOV left, the display of the virtual object needs to be shifted to the right by an amount of the user's FOV shift, so that the net effect is that the virtual object remains stationary within the FOV. A system for properly displaying world and body locked virtual objects is explained below with respect to the flowchart of
The system for presenting mixed reality to one or more users 18 may be configured in step 600. For example, a user 18 or operator of the system may specify the virtual objects that are to be presented, including for example the shared virtual object(s) 460. The users may also configure the contents the shared virtual object(s) 460 and/or of their own private virtual object(s) 462, as well as how, when and where they are to be presented.
In steps 604 and 630, hub 12 and processing unit 4 gather data from the scene. For the hub 12, this may be image and audio data sensed by the depth camera 426 and RGB camera 428 of capture device 20. For the processing unit 4, this may be image data sensed in step 656 by the head mounted display device 2, and in particular, by the cameras 112, the eye tracking assemblies 134 and the IMU 132. The data gathered by the head mounted display device 2 is sent to the processing unit 4 in step 656. The processing unit 4 processes this data, as well as sending it to the hub 12 in step 630.
In step 608, the hub 12 performs various setup operations that allow the hub 12 to coordinate the image data of its capture device 20 and the one or more processing units 4. In particular, even if the position of the capture device 20 is known with respect to a scene (which it may not be), the cameras on the head mounted display devices 2 are moving around in the scene. Therefore, in embodiments, the positions and time capture of each of the imaging cameras need to be calibrated to the scene, each other and the hub 12. Further details of step 608 are now described with reference to the flowchart of
One operation of step 608 includes determining clock offsets of the various imaging devices in the system 10 in a step 670. In particular, in order to coordinate the image data from each of the cameras in the system, it may be confirmed that the image data being coordinated is from the same time. Details relating to determining clock offsets and synching of image data are disclosed in U.S. patent application Ser. No. 12/772,802, entitled “Heterogeneous Image Sensor Synchronization,” filed May 3, 2010, and U.S. patent application Ser. No. 12/792,961, entitled “Synthesis Of Information From Multiple Audiovisual Sources,” filed Jun. 3, 2010. In general, the image data from capture device 20 and the image data coming in from the one or more processing units 4 are time stamped off a single master clock in hub 12. Using the time stamps for all such data for a given frame, as well as the known resolution for each of the cameras, the hub 12 determines the time offsets for each of the imaging cameras in the system. From this, the hub 12 may determine the differences between, and an adjustment to, the images received from each camera.
The hub 12 may select a reference time stamp from one of the cameras' received frame. The hub 12 may then add time to or subtract time from the received image data from all other cameras to synch to the reference time stamp. It is appreciated that a variety of other operations may be used for determining time offsets and/or synchronizing the different cameras together for the calibration process. The determination of time offsets may be performed once, upon initial receipt of image data from all the cameras. Alternatively, it may be performed periodically, such as for example each frame or some number of frames.
Step 608 further includes the operation of calibrating the positions of all cameras with respect to each other in the x, y, z Cartesian space of the scene. Once this information is known, the hub 12 and/or the one or more processing units 4 is able to form a scene map or model identify the geometry of the scene and the geometry and positions of objects (including users) within the scene. In calibrating the image data of all cameras to each other, depth and/or RGB data may be used. Technology for calibrating camera views using RGB information alone is described for example in U.S. Patent Publication No. 2007/0110338, entitled “Navigating Images Using Image Based Geometric Alignment and Object Based Controls,” published May 17, 2007.
The imaging cameras in system 10 may each have some lens distortion which needs to be corrected for in order to calibrate the images from different cameras. Once all image data from the various cameras in the system is received in steps 604 and 630, the image data may be adjusted to account for lens distortion for the various cameras in step 674. The distortion of a given camera (depth or RGB) may be a known property provided by the camera manufacturer. If not, algorithms are known for calculating a camera's distortion, including for example imaging an object of known dimensions such as a checker board pattern at different locations within a camera's FOV. The deviations in the camera view coordinates of points in that image will be the result of camera lens distortion. Once the degree of lens distortion is known, distortion may be corrected by known inverse matrix transformations that result in a uniform camera view map of points in a point cloud for a given camera.
The hub 12 may next translate the distortion-corrected image data points captured by each camera from the camera view to an orthogonal 3-D world view in step 678. This orthogonal 3-D world view is a point cloud map of all image data captured by capture device 20 and the head mounted display device cameras in an orthogonal x, y, z Cartesian coordinate system. The matrix transformation equations for translating camera view to an orthogonal 3-D world view are known. See, for example, David H. Eberly, “3d Game Engine Design: A Practical Approach To Real-Time Computer Graphics,” Morgan Kaufman Publishers (2000). See also, U.S. patent application Ser. No. 12/792,961, mentioned above.
Each camera in system 10 may construct an orthogonal 3-D world view in step 678. The x, y, z world coordinates of data points from a given camera are still from the perspective of that camera at the conclusion of step 678, and not yet correlated to the x, y, z world coordinates of data points from other cameras in the system 10. The next step is to translate the various orthogonal 3-D world views of the different cameras into a single overall 3-D world view shared by all cameras in system 10.
To accomplish this, embodiments of the hub 12 may next look for key-point discontinuities, or cues, in the point clouds of the world views of the respective cameras in step 682, and then identifies cues that are the same between different point clouds of different cameras in step 684. Once the hub 12 is able to determine that two world views of two different cameras include the same cues, the hub 12 is able to determine the position, orientation and focal length of the two cameras with respect to each other and the cues in step 688. In embodiments, not all cameras in system 10 will share the same common cues. However, as long as a first and second camera have shared cues, and at least one of those cameras has a shared view with a third camera, the hub 12 is able to determine the positions, orientations and focal lengths of the first, second and third cameras relative to each other and a single, overall 3-D world view. The same is true for additional cameras in the system.
Various known algorithms exist for identifying cues from an image point cloud. Such algorithms are set forth for example in Mikolajczyk, K., and Schmid, C., “A Performance Evaluation of Local Descriptors,” IEEE Transactions on Pattern Analysis & Machine Intelligence, 27, 10, 1615-1630. (2005). A further method of detecting cues with image data is the Scale-Invariant Feature Transform (SIFT) algorithm. The SIFT algorithm is described for example in U.S. Pat. No. 6,711,293, entitled, “Method and Apparatus for Identifying Scale Invariant Features in an Image and Use of Same for Locating an Object in an Image,” issued Mar. 23, 2004. Another cue detector method is the Maximally Stable Extremal Regions (MSER) algorithm. The MSER algorithm is described for example in the paper by J. Matas, O. Chum, M. Urba, and T. Pajdla, “Robust Wide Baseline Stereo From Maximally Stable Extremal Regions,” Proc. of British Machine Vision Conference, pages 384-396 (2002).
In step 684, cues which are shared between point clouds from two or more cameras are identified. Conceptually, where a first set of vectors exist between a first camera and a set of cues in the first camera's Cartesian coordinate system, and a second set of vectors exist between a second camera and that same set of cues in the second camera's Cartesian coordinate system, the two systems may be resolved with respect to each other into a single Cartesian coordinate system including both cameras. A number of known techniques exist for finding shared cues between point clouds from two or more cameras. Such techniques are shown for example in Arya, S., Mount, D. M., Netanyahu, N. S., Silverman, R., and Wu, A. Y., “An Optimal Algorithm For Approximate Nearest Neighbor Searching Fixed Dimensions,” Journal of the ACM 45, 6, 891-923 (1998). Other techniques can be used instead of, or in addition to, the approximate nearest neighbor solution of Arya et al., mentioned above, including but not limited to hashing or context-sensitive hashing.
Where the point clouds from two different cameras share a large enough number of matched cues, a matrix correlating the two point clouds together may be estimated, for example by Random Sampling Consensus (RANSAC), or a variety of other estimation techniques. Matches that are outliers to the recovered fundamental matrix may then be removed. After finding a set of assumed, geometrically consistent matches between a pair of point clouds, the matches may be organized into a set of tracks for the respective point clouds, where a track is a set of mutually matching cues between point clouds. A first track in the set may contain a projection of each common cue in the first point cloud. A second track in the set may contain a projection of each common cue in the second point cloud. The point clouds from different cameras may then be resolved into a single point cloud in a single orthogonal 3-D real world view.
The positions and orientations of all cameras are calibrated with respect to this single point cloud and single orthogonal 3-D real world view. In order to resolve the various point clouds together, the projections of the cues in the set of tracks for two point clouds are analyzed. From these projections, the hub 12 can determine the perspective of a first camera with respect to the cues, and can also determine the perspective of a second camera with respect to the cues. From that, the hub 12 can resolve the point clouds into an estimate of a single point cloud and single orthogonal 3-D real world view containing the cues and other data points from both point clouds.
This process is repeated for any other cameras, until the single orthogonal 3-D real world view includes all cameras. Once this is done, the hub 12 can determine the relative positions and orientations of the cameras relative to the single orthogonal 3-D real world view and each other. The hub 12 can further determine the focal length of each camera with respect to the single orthogonal 3-D real world view.
Once the system is calibrated in step 608, a scene map may be developed in step 610 identifying the geometry of the scene as well as the geometry and positions of objects within the scene. In embodiments, the scene map generated in a given frame may include the x, y and z positions of all users, real world objects and virtual objects in the scene. This information may be obtained during the image data gathering steps 604, 630 and 656 and is calibrated together in step 608.
At least the capture device 20 includes a depth camera for determining the depth of the scene (to the extent it may be bounded by walls, etc.) as well as the depth position of objects within the scene. As explained below, the scene map is used in positioning virtual objects within the scene, as well as displaying virtual three-dimensional objects with the proper occlusion (a virtual three-dimensional object may be occluded, or a virtual three-dimensional object may occlude, a real world object or another virtual three-dimensional object).
The system 10 may include multiple depth image cameras to obtain all of the depth images from a scene, or a single depth image camera, such as for example depth image camera 426 of capture device 20 may be sufficient to capture all depth images from a scene. An analogous method for determining a scene map within an unknown environment is known as simultaneous localization and mapping (SLAM). One example of SLAM is disclosed in U.S. Pat. No. 7,774,158, entitled “Systems and Methods for Landmark Generation for Visual Simultaneous Localization and Mapping,” issued Aug. 10, 2010.
In step 612, the system may detect and track moving objects such as humans moving in the room, and update the scene map based on the positions of moving objects. This includes the use of skeletal models of the users within the scene as described above.
In step 614, the hub determines the x, y and z position, the orientation and the FOV of the head mounted display devices 2 of the various users 18. Further details of step 614 are now described with respect to the flowchart of
In step 700, the calibrated image data for the scene is analyzed at the hub to determine both the user head position and a face unit vector looking straight out from a user's face. The head position is identified in the skeletal model. The face unit vector may be determined by defining a plane of the user's face from the skeletal model, and taking a vector perpendicular to that plane. This plane may be identified by determining a position of a user's eyes, nose, mouth, ears or other facial features. The face unit vector may be used to define the user's head orientation and, in examples, may be considered the center of the FOV for the user. The face unit vector may also or alternatively be identified from the camera image data returned from the cameras 112 on head mounted display device 2. In particular, based on what the cameras 112 on head mounted display device 2 see, the associated processing unit 4 and/or hub 12 is able to determine the face unit vector representing a user's head orientation.
In step 704, the position and orientation of a user's head may also or alternatively be determined from analysis of the position and orientation of the user's head from an earlier time (either earlier in the frame or from a prior frame), and then using the inertial information from the IMU 132 to update the position and orientation of a user's head. Information from the IMU 132 may provide accurate kinematic data for a user's head, but the IMU typically does not provide absolute position information regarding a user's head. This absolute position information, also referred to as “ground truth,” may be provided from the image data obtained from capture device 20, the cameras on the head mounted display device 2 for the subject user and/or from the head mounted display device(s) 2 of other users.
In embodiments, the position and orientation of a user's head may be determined by steps 700 and 704 acting in tandem. In further embodiments, one or the other of steps 700 and 704 may be used to determine head position and orientation of a user's head.
It may happen that a user is not looking straight ahead. Therefore, in addition to identifying user head position and orientation, the hub may further consider the position of the user's eyes in his head. This information may be provided by the eye tracking assembly 134 described above. The eye tracking assembly is able to identify a position of the user's eyes, which can be represented as an eye unit vector showing the left, right, up and/or down deviation from a position where the user's eyes are centered and looking straight ahead (i.e., the face unit vector). A face unit vector may be adjusted to the eye unit vector to define where the user is looking.
In step 710, the FOV of the user may next be determined. The range of view of a user of a head mounted display device 2 may be predefined based on the up, down, left and right peripheral vision of a hypothetical user. In order to ensure that the FOV calculated for a given user includes objects that a particular user may be able to see at the extents of the FOV, this hypothetical user may be taken as one having a maximum possible peripheral vision. Some predetermined extra FOV may be added to this to ensure that enough data is captured for a given user in embodiments.
The FOV for the user at a given instant may then be calculated by taking the range of view and centering it around the face unit vector, adjusted by any deviation of the eye unit vector. In addition to defining what a user is looking at in a given instant, this determination of a user's FOV is also useful for determining what a user cannot see. As explained below, limiting processing of virtual objects to those areas that a particular user can see improves processing speed and reduces latency.
In the embodiment described above, the hub 12 calculates the FOV of the one or more users in the scene. In further embodiments, the processing unit 4 for a user may share in this task. For example, once user head position and eye orientation are estimated, this information may be sent to the processing unit which can update the position, orientation, etc. based on more recent data as to head position (from IMU 132) and eye position (from eye tracking assembly 134).
Returning now to
In step 714, the hub may determine whether one or more virtual objects have been interacted with or moved. If so, the hub determines the new appearance and/or position of the affected virtual object in three-dimensional space. As noted above, different gestures may have defined effects on virtual objects in the scene. As one example, a user may interact with their private virtual object 462, which in turn affects some interaction with the shared virtual object 460. These interactions are sensed in step 714, and the effects of these interactions on both the private virtual object 462 and the shared virtual object(s) 460 are implemented in step 718.
In step 722, the hub 12 checks whether a moved or interacted with is a virtual object 460 shared by multiple users. If so, the hub updates the appearance and/or position of the virtual object 460 in the shared state data in step 726 for each user sharing the virtual object 460. In particular, as discussed above, multiple users may share the same state data for shared virtual objects 460 to facilitate collaboration on a virtual object between multiple users. Where there is a single copy shared among multiple users, a change in appearance or position of the single copy is stored in the state data for the shared virtual object that is provided to each of the multiple users. Alternately, multiple users may have multiple copies of a shared virtual object 460. In this instance, a change in appearance of the shared virtual object may be stored in the state data for the shared virtual object that is provided to each of the multiple users.
However, a change in position may just be reflected in the copy of the shared virtual object that was moved, and not the others copies of the shared virtual object. In other words, a change in the position of one copy of the shared virtual object may not be reflected in other copies of the shared virtual object 460. In an alternative embodiment, where there are multiple copies of a shared virtual object, a change in one copy may be implemented across all copies of the shared virtual object 460 so that each maintains the same state data as to appearance and position.
Once the positions and appearances of virtual objects are set as described in
The processing steps 600 through 626 are described above by way of example. It is understood that one or more of these steps may be omitted in further embodiments, the steps may be performed in differing order, or additional steps may be added. The processing steps 604 through 618 may be computationally expensive but the powerful hub 12 may perform these steps several times in a 60 Hertz frame. In further embodiments, one or more of the steps 604 through 618 may alternatively or additionally be performed by one or more of the processing units 4. Moreover, while
The operation of the processing unit 4 and head mounted display device 2 will now be explained with reference to steps 630 through 658. The following description is of a single processing unit 4 and head mounted display device 2. However, the following description may apply to each processing unit 4 and display device 2 in the system.
As noted above, in an initial step 656, the head mounted display device 2 generates image and IMU data, which is sent to the hub 12 via the processing unit 4 in step 630. While the hub 12 is processing the image data, the processing unit 4 is also processing the image data, as well as performing steps in preparation for rendering an image.
In step 634, the processing unit 4 may cull the rendering operations so that just those virtual objects which could possibly appear within the final FOV of the head mounted display device 2 are rendered. The positions of other virtual objects may still be tracked, but they are not rendered. It is also conceivable that, in further embodiments, step 634 may be skipped altogether and the whole image is rendered.
The processing unit 4 may next perform a rendering setup step 638 where setup rendering operations are performed using the scene map and FOV received in step 626. Once virtual object data is received, the processing unit may perform rendering setup operations in step 638 for the virtual objects which are to be rendered in the FOV. The setup rendering operations in step 638 may include common rendering tasks associated with the virtual object(s) to be displayed in the final FOV. These rendering tasks may include for example, shadow map generation, lighting, and animation. In embodiments, the rendering setup step 638 may further include a compilation of likely draw information such as vertex buffers, textures and states for virtual objects to be displayed in the predicted final FOV.
Using the information received from the hub 12 in step 626, the processing unit 4 may next determine occlusions and shading in the user's FOV in step 644. In particular, the screen map has x, y and z positions of all objects in the scene, including moving and non-moving objects and the virtual objects. Knowing the location of a user and their line of sight to objects in the FOV, the processing unit 4 may then determine whether a virtual object partially or fully occludes the user's view of a real world object. Additionally, the processing unit 4 may determine whether a real world object partially or fully occludes the user's view of a virtual object. Occlusions are user-specific. A virtual object may block or be blocked in the view of a first user, but not a second user. Accordingly, occlusion determinations may be performed in the processing unit 4 of each user. However, it is understood that occlusion determinations may additionally or alternatively be performed by the hub 12.
In step 646, the GPU 322 of processing unit 4 may next render an image to be displayed to the user. Portions of the rendering operations may have already been performed in the rendering setup step 638 and periodically updated. Further details of step 646 are described U.S. Patent Publication No. 2012/0105473, entitled, “Low-Latency Fusing of Virtual And Real Content.”
In step 650, the processing unit 4 checks whether it is time to send a rendered image to the head mounted display device 2, or whether there is still time for further refinement of the image using more recent position feedback data from the hub 12 and/or head mounted display device 2. In a system using a 60 Hertz frame refresh rate, a single frame may be about 16 ms.
If it is time to display the frame in step 650, the composite image is sent to microdisplay 120. At this time, the control data for the opacity filter is also transmitted from processing unit 4 to head mounted display device 2 to control opacity filter 114. The head mounted display may then display the image to the user in step 658.
On the other hand, where it is not yet time to send a frame of image data to be displayed in step 650, the processing unit may loop back for more updated data to further refine the predictions of the final FOV and the final positions of objects in the FOV. In particular, if there is still time in step 650, the processing unit 4 may return to step 608 to get more recent sensor data from the hub 12, and may return to step 656 to get more recent sensor data from the head mounted display device 2.
The processing steps 630 through 652 are described above by way of example. It is understood that one or more of these steps may be omitted in further embodiments, the steps may be performed in differing order, or additional steps may be added.
Moreover, the flowchart of the processing unit steps in
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims. It is intended that the scope of the invention be defined by the claims appended hereto.
