Patent Description:
Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description which may not otherwise qualify as prior art at the time of filing, are neither expressly or impliedly admitted as prior art against the present disclosure.

A head-mountable display (HMD) is one example of a head-mountable apparatus for use in a virtual reality system in which an HMD wearer views a virtual environment. In an HMD, an image or video display device is provided which may be worn on the head or as part of a helmet. Either one eye or both eyes are provided with small electronic display devices.

It has been proposed to provide detection arrangements for detecting a relative location of one device (such as an HMD) from another device, by using a camera on the one device to detect images of one or more markers, for example on the other device.

Although the original development of HMDs and virtual reality was perhaps driven by the military and professional applications of these devices, HMDs are becoming more popular for use by casual users in, for example, computer game or domestic computing applications.

Previously proposed arrangements are disclosed in <CIT>, <CIT>, and <CIT>.

This disclosure is defined by claim <NUM>. Further respective aspects and features of the disclosure are defined in the appended claims.

Referring now to <FIG>, a user <NUM> is wearing an HMD <NUM> (as an example of a generic head-mountable apparatus or virtual reality apparatus). The HMD comprises a frame <NUM>, in this example formed of a rear strap and a top strap, and a display portion <NUM>.

Note that the HMD of <FIG> may comprise further features, to be described below in connection with other drawings, but which are not shown in <FIG> for clarity of this initial explanation.

The HMD of <FIG> completely (or at least substantially completely) obscures the user's view of the surrounding environment. All that the user can see is the pair of images displayed within the HMD.

The HMD has associated headphone audio transducers or earpieces <NUM> which fit into the user's left and right ears <NUM>. The earpieces <NUM> replay an audio signal provided from an external source, which may be the same as the video signal source which provides the video signal for display to the user's eyes. A boom microphone <NUM> is mounted on the HMD so as to extend towards the user's mouth.

The combination of the fact that the user can see only what is displayed by the HMD and, subject to the limitations of the noise blocking or active cancellation properties of the earpieces and associated electronics, can hear only what is provided via the earpieces, mean that this HMD may be considered as a so-called "full immersion" HMD. Note however that in some embodiments the HMD is not a full immersion HMD, and may provide at least some facility for the user to see and/or hear the user's surroundings. This could be by providing some degree of transparency or partial transparency in the display arrangements, and/or by projecting a view of the outside (captured using a camera, for example a camera mounted on the HMD) via the HMD's displays, and/or by allowing the transmission of ambient sound past the earpieces and/or by providing a microphone to generate an input sound signal (for transmission to the earpieces) dependent upon the ambient sound.

A front-facing camera <NUM> may capture images to the front of the HMD, in use. A Bluetooth® antenna <NUM> may provide communication facilities or may simply be arranged as a directional antenna to allow a detection of the direction of a nearby Bluetooth transmitter.

In operation, a video signal is provided for display by the HMD. This could be provided by an external video signal source <NUM> such as a video games machine or data processing apparatus (such as a personal computer), in which case the signals could be transmitted to the HMD by a wired or a wireless connection <NUM>. Examples of suitable wireless connections include Bluetooth® connections. Audio signals for the earpieces <NUM> can be carried by the same connection. Similarly, any control signals passed from the HMD to the video (audio) signal source may be carried by the same connection. Furthermore, a power supply <NUM> (including one or more batteries and/or being connectable to a mains power outlet) may be linked by a cable <NUM> to the HMD. Note that the power supply <NUM> and the video signal source <NUM> may be separate units or may be embodied as the same physical unit. There may be separate cables for power and video (and indeed for audio) signal supply, or these may be combined for carriage on a single cable (for example, using separate conductors, as in a USB cable, or in a similar way to a "power over Ethernet" arrangement in which data is carried as a balanced signal and power as direct current, over the same collection of physical wires). The video and/or audio signal may be carried by, for example, an optical fibre cable. In other embodiments, at least part of the functionality associated with generating image and/or audio signals for presentation to the user may be carried out by circuitry and/or processing forming part of the HMD itself. A power supply may be provided as part of the HMD itself.

Some embodiments of the disclosure are applicable to an HMD having at least one electrical and/or optical cable linking the HMD to another device, such as a power supply and/or a video (and/or audio) signal source. So, embodiments of the disclosure can include, for example:.

If one or more cables are used, the physical position at which the cable <NUM> and/or <NUM> enters or joins the HMD is not particularly important from a technical point of view. Aesthetically, and to avoid the cable(s) brushing the user's face in operation, it would normally be the case that the cable(s) would enter or join the HMD at the side or back of the HMD (relative to the orientation of the user's head when worn in normal operation). Accordingly, the position of the cables <NUM>, <NUM> relative to the HMD in <FIG> should be treated merely as a schematic representation.

Accordingly, the arrangement of <FIG> provides an example of a head-mountable display system comprising a frame to be mounted onto an observer's head, the frame defining one or two eye display positions which, in use, are positioned in front of a respective eye of the observer and a display element mounted with respect to each of the eye display positions, the display element providing a virtual image of a video display of a video signal from a video signal source to that eye of the observer.

<FIG> shows just one example of an HMD. Other formats are possible: for example an HMD could use a frame more similar to that associated with conventional eyeglasses, namely a substantially horizontal leg extending back from the display portion to the top rear of the user's ear, possibly curling down behind the ear. In other (not full immersion) examples, the user's view of the external environment may not in fact be entirely obscured; the displayed images could be arranged so as to be superposed (from the user's point of view) over the external environment. An example of such an arrangement will be described below with reference to <FIG>.

In the example of <FIG>, a separate respective display is provided for each of the user's eyes. A schematic plan view of how this is achieved is provided as <FIG>, which illustrates the positions <NUM> of the user's eyes and the relative position <NUM> of the user's nose. The display portion <NUM>, in schematic form, comprises an exterior shield <NUM> to mask ambient light from the user's eyes and an internal shield <NUM> which prevents one eye from seeing the display intended for the other eye. The combination of the user's face, the exterior shield <NUM> and the interior shield <NUM> form two compartments <NUM>, one for each eye. In each of the compartments there is provided a display element <NUM> and one or more optical elements <NUM>. The way in which the display element and the optical element(s) cooperate to provide a display to the user will be described with reference to <FIG>.

Referring to <FIG>, the display element <NUM> generates a displayed image which is (in this example) refracted by the optical elements <NUM> (shown schematically as a convex lens but which could include compound lenses or other elements) so as to generate a virtual image <NUM> which appears to the user to be larger than and significantly further away than the real image generated by the display element <NUM>. As an example, the virtual image may have an apparent image size (image diagonal) of more than <NUM> and may be disposed at a distance of more than <NUM> from the user's eye (or from the frame of the HMD). In general terms, depending on the purpose of the HMD, it is desirable to have the virtual image disposed a significant distance from the user. For example, if the HMD is for viewing movies or the like, it is desirable that the user's eyes are relaxed during such viewing, which requires a distance (to the virtual image) of at least several metres. In <FIG>, solid lines (such as the line <NUM>) are used to denote real optical rays, whereas broken lines (such as the line <NUM>) are used to denote virtual rays.

An alternative arrangement is shown in <FIG>. This arrangement may be used where it is desired that the user's view of the external environment is not entirely obscured. However, it is also applicable to HMDs in which the user's external view is wholly obscured. In the arrangement of <FIG>, the display element <NUM> and optical elements <NUM> cooperate to provide an image which is projected onto a mirror <NUM>, which deflects the image towards the user's eye position <NUM>. The user perceives a virtual image to be located at a position <NUM> which is in front of the user and at a suitable distance from the user.

In the case of an HMD in which the user's view of the external surroundings is entirely obscured, the mirror <NUM> can be a substantially <NUM>% reflective mirror. The arrangement of <FIG> then has the advantage that the display element and optical elements can be located closer to the centre of gravity of the user's head and to the side of the user's eyes, which can produce a less bulky HMD for the user to wear. Alternatively, if the HMD is designed not to completely obscure the user's view of the external environment, the mirror <NUM> can be made partially reflective so that the user sees the external environment, through the mirror <NUM>, with the virtual image superposed over the real external environment.

In the case where separate respective displays are provided for each of the user's eyes, it is possible to display stereoscopic images. An example of a pair of stereoscopic images for display to the left and right eyes is shown in <FIG>. The images exhibit a lateral displacement relative to one another, with the displacement of image features depending upon the (real or simulated) lateral separation of the cameras by which the images were captured, the angular convergence of the cameras and the (real or simulated) distance of each image feature from the camera position.

Note that the lateral displacements in <FIG> could in fact be the other way round, which is to say that the left eye image as drawn could in fact be the right eye image, and the right eye image as drawn could in fact be the left eye image. This is because some stereoscopic displays tend to shift objects to the right in the right eye image and to the left in the left eye image, so as to simulate the idea that the user is looking through a stereoscopic window onto the scene beyond. However, some HMDs use the arrangement shown in <FIG> because this gives the impression to the user that the user is viewing the scene through a pair of binoculars. The choice between these two arrangements is at the discretion of the system designer.

In some situations, an HMD may be used simply to view movies and the like. In this case, there is no change required to the apparent viewpoint of the displayed images as the user turns the user's head, for example from side to side. In other uses, however, such as those associated with virtual reality (VR) or augmented reality (AR) systems, the user's viewpoint needs to track movements with respect to a real or virtual space in which the user is located.

<FIG> schematically illustrates an example virtual reality system and in particular shows a user wearing an HMD connected to a Sony® PlayStation ® games console <NUM> as an example of a base device. The games console <NUM> is connected to a mains power supply <NUM> and (optionally) to a main display screen (not shown). A cable, acting as the cables <NUM>, <NUM> discussed above (and so acting as both power supply and signal cables), links the HMD <NUM> to the games console <NUM> and is, for example, plugged into a USB socket <NUM> on the console <NUM>. Note that in the present embodiments, a single physical cable is provided which fulfils the functions of the cables <NUM>, <NUM>.

The video displays in the HMD <NUM> are arranged to display images generated by the games console <NUM>, and the earpieces <NUM> in the HMD <NUM> are arranged to reproduce audio signals generated by the games console <NUM>. Note that if a USB type cable is used, these signals will be in digital form when they reach the HMD <NUM>, such that the HMD <NUM> comprises a digital to analogue converter (DAC) to convert at least the audio signals back into an analogue form for reproduction.

Images from the camera <NUM> mounted on the HMD <NUM> are passed back to the games console <NUM> via the cable <NUM>, <NUM>. Similarly, if motion or other sensors are provided at the HMD <NUM>, signals from those sensors may be at least partially processed at the HMD <NUM> and/or may be at least partially processed at the games console <NUM>. The use and processing of such signals will be described further below.

The USB connection from the games console <NUM> also provides power to the HMD <NUM>, according to the USB standard.

<FIG> also shows a separate display <NUM> such as a television or other openly viewable display (by which it is meant that viewers other than the HMD wearer may see images displayed by the display <NUM>) and a camera <NUM>, which may be (for example) directed towards the user (such as the HMD wearer) during operation of the apparatus. An example of a suitable camera is the PlayStation Eye camera, although more generally a generic "webcam", connected to the console <NUM> by a wired (such as a USB) or wireless (such as WiFi or Bluetooth) connection.

The display <NUM> may be arranged (under the control of the games console) to provide the function of a so-called "social screen". It is noted that playing a computer game using an HMD can be very engaging for the wearer of the HMD but less so for other people in the vicinity (particularly if they are not themselves also wearing HMDs). To provide an improved experience for a group of users, where the number of HMDs in operation is fewer than the number of users, images can be displayed on a social screen. The images displayed on the social screen may be substantially similar to those displayed to the user wearing the HMD, so that viewers of the social screen see (and in some cases hear) the virtual environment (or a subset, version or representation of it) as seen and heard by the HMD wearer. In other examples, the social screen could display other material such as information relating to the HMD wearer's current progress through the ongoing computer game. For example, the HMD wearer could see the game environment from a first person viewpoint whereas the social screen could provide a third person view of activities and movement of the HMD wearer's avatar, or an overview of a larger portion of the virtual environment. In these examples, an image generator (for example, a part of the functionality of the games console) is configured to generate some of the virtual environment images for display by a display separate to the head mountable display.

In <FIG> the user is wearing one or two so-called haptic gloves <NUM>. These can include actuators to provide haptic feedback to the user, for example under the control of processing carried out by the console <NUM>. They may also provide configuration and/or location sensing as discussed below.

Note that other haptic interfaces can be used, providing one or more actuators and/or one or more sensors. For example, a so-called haptics suit may be worn by the user. Haptic shoes may include one or more actuators and one or more sensors. Or the user could stand on or hold a haptic interface device. The one or more actuators associated with these devices may have different respective frequency responses and available amplitudes of vibration. Therefore in example arrangements to be discussed below the haptic generator can be responsive to attributes defining one or capabilities of the haptic interface. In some examples, an attribute defines a frequency response of the haptic interface. In some examples, an attribute defines a maximum amplitude which may be represented by the haptic interface.

<FIG> schematically illustrates a similar arrangement (another example of a virtual reality system) in which the games console is connected (by a wired or wireless link) to a so-called "break out box" acting as a base or intermediate device <NUM>, to which the HMD <NUM> is connected by a cabled link <NUM>, <NUM>. The breakout box has various functions in this regard. One function is to provide a location, near to the user, for some user controls relating to the operation of the HMD, such as (for example) one or more of a power control, a brightness control, an input source selector, a volume control and the like. Another function is to provide a local power supply for the HMD (if one is needed according to the embodiment being discussed). Another function is to provide a local cable anchoring point. In this last function, it is not envisaged that the break-out box <NUM> is fixed to the ground or to a piece of furniture, but rather than having a very long trailing cable from the games console <NUM>, the break-out box provides a locally weighted point so that the cable <NUM>, <NUM> linking the HMD <NUM> to the break-out box will tend to move around the position of the break-out box. This can improve user safety and comfort by avoiding the use of very long trailing cables.

In <FIG>, the user is also shown holding a pair of hand-held controller <NUM> which may be, for example, Sony® Move® controllers which communicate wirelessly with the games console <NUM> to control (or to contribute to the control of) game operations relating to a currently executed game program. the user may also be wearing one or two haptic gloves as discussed in connection with <FIG>.

It will be appreciated that the localisation of processing in the various techniques described in this application can be varied without changing the overall effect, given that an HMD may form part of a set or cohort of interconnected devices (that is to say, interconnected for the purposes of data or signal transfer, but not necessarily connected by a physical cable). So, processing which is described as taking place "at" one device, such as at the HMD, could be devolved to another device such as the games console (base device) or the break-out box. Processing tasks can be shared amongst devices. Source signals, on which the processing is to take place, could be distributed to another device, or the processing results from the processing of those source signals could be sent to another device, as required. So any references to processing taking place at a particular device should be understood in this context. Similarly, where an interaction between two devices is basically symmetrical, for example where a camera or sensor on one device detects a signal or feature of the other device, it will be understood that unless the context prohibits this, the two devices could be interchanged without any loss of functionality.

As mentioned above, in some uses of the HMD, such as those associated with virtual reality (VR) or augmented reality (AR) systems, the user's viewpoint needs to track movements with respect to a real or virtual space in which the user is located.

This tracking is carried out by detecting motion of the HMD and varying the apparent viewpoint of the displayed images so that the apparent viewpoint tracks the motion.

<FIG> schematically illustrates the effect of a user head movement in a VR or AR system.

Referring to <FIG>, a virtual environment is represented by a (virtual) spherical shell <NUM> around a user. This provides an example of a virtual display screen (VDS). Because of the need to represent this arrangement on a two-dimensional paper drawing, the shell is represented by a part of a circle, at a distance from the user equivalent to the separation of the displayed virtual image from the user. A user is initially at a first position <NUM> and is directed towards a portion <NUM> of the virtual environment. It is this portion <NUM> which is represented in the images displayed on the display elements <NUM> of the user's HMD. It can be seen from the drawing that the VDS subsists in three dimensional space (in a virtual sense) around the position in space of the HMD wearer, such that the HMD wearer sees a current portion of VDS according to the HMD orientation.

Consider the situation in which the user then moves his head to a new position and/or orientation <NUM>. In order to maintain the correct sense of the virtual reality or augmented reality display, the displayed portion of the virtual environment also moves so that, at the end of the movement, a new portion <NUM> is displayed by the HMD.

So, in this arrangement, the apparent viewpoint within the virtual environment moves with the head movement. If the head rotates to the right side, for example, as shown in <FIG>, the apparent viewpoint also moves to the right from the user's point of view. If the situation is considered from the aspect of a displayed object, such as a displayed object <NUM>, this will effectively move in the opposite direction to the head movement. So, if the head movement is to the right, the apparent viewpoint moves to the right but an object such as the displayed object <NUM> which is stationary in the virtual environment will move towards the left of the displayed image and eventually will disappear off the left-hand side of the displayed image, for the simple reason that the displayed portion of the virtual environment has moved to the right whereas the displayed object <NUM> has not moved in the virtual environment.

<FIG> schematically illustrated HMDs with motion sensing. The two drawings are in a similar format to that shown in <FIG>. That is to say, the drawings are schematic plan views of an HMD, in which the display element <NUM> and optical elements <NUM> are represented by a simple box shape. Many features of <FIG> are not shown, for clarity of the diagrams. Both drawings show examples of HMDs with a motion detector for detecting motion of the observer's head.

In <FIG>, a forward-facing camera <NUM> is provided on the front of the HMD. This may be the same camera as the camera <NUM> discussed above, or may be an additional camera. This does not necessarily provide images for display to the user (although it could do so in an augmented reality arrangement). Instead, its primary purpose in the present embodiments is to allow motion sensing. A technique for using images captured by the camera <NUM> for motion sensing will be described below in connection with <FIG>. In these arrangements, the motion detector comprises a camera mounted so as to move with the frame; and an image comparator operable to compare successive images captured by the camera so as to detect inter-image motion.

<FIG> makes use of a hardware motion detector <NUM>. This can be mounted anywhere within or on the HMD. Examples of suitable hardware motion detectors are piezoelectric accelerometers or optical fibre gyroscopes. It will of course be appreciated that both hardware motion detection and camera-based motion detection can be used in the same device, in which case one sensing arrangement could be used as a backup when the other one is unavailable, or one sensing arrangement (such as the camera) could provide data for changing the apparent viewpoint of the displayed images, whereas the other (such as an accelerometer) could provide data for image stabilisation.

<FIG> schematically illustrates one example of motion detection using the camera <NUM> of <FIG>.

The camera <NUM> is a video camera, capturing images at an image capture rate of, for example, <NUM> images per second. As each image is captured, it is passed to an image store <NUM> for storage and is also compared, by an image comparator <NUM>, with a preceding image retrieved from the image store. The comparison uses known block matching techniques (so-called "optical flow" detection) to establish whether substantially the whole image has moved since the time at which the preceding image was captured. Localised motion might indicate moving objects within the field of view of the camera <NUM>, but global motion of substantially the whole image would tend to indicate motion of the camera rather than of individual features in the captured scene, and in the present case because the camera is mounted on the HMD, motion of the camera corresponds to motion of the HMD and in turn to motion of the user's head.

The displacement between one image and the next, as detected by the image comparator <NUM>, is converted to a signal indicative of motion by a motion detector <NUM>. If required, the motion signal is converted by to a position signal by an integrator <NUM>.

As mentioned above, as an alternative to, or in addition to, the detection of motion by detecting inter-image motion between images captured by a video camera associated with the HMD, the HMD can detect head motion using a mechanical or solid state detector <NUM> such as an accelerometer. This can in fact give a faster response in respect of the indication of motion, given that the response time of the video-based system is at best the reciprocal of the image capture rate. In some instances, therefore, the detector <NUM> can be better suited for use with higher frequency motion detection. However, in other instances, for example if a high image rate camera is used (such as a <NUM> capture rate camera), a camera-based system may be more appropriate. In terms of <FIG>, the detector <NUM> could take the place of the camera <NUM>, the image store <NUM> and the comparator <NUM>, so as to provide an input directly to the motion detector <NUM>. Or the detector <NUM> could take the place of the motion detector <NUM> as well, directly providing an output signal indicative of physical motion.

Other position or motion detecting techniques are of course possible. For example, a mechanical arrangement by which the HMD is linked by a moveable pantograph arm to a fixed point (for example, on a data processing device or on a piece of furniture) may be used, with position and orientation sensors detecting changes in the deflection of the pantograph arm. In other embodiments, a system of one or more transmitters and receivers, mounted on the HMD and on a fixed point, can be used to allow detection of the position and orientation of the HMD by triangulation techniques. For example, the HMD could carry one or more directional transmitters, and an array of receivers associated with known or fixed points could detect the relative signals from the one or more transmitters. Or the transmitters could be fixed and the receivers could be on the HMD. Examples of transmitters and receivers include infra-red transducers, ultrasonic transducers and radio frequency transducers. The radio frequency transducers could have a dual purpose, in that they could also form part of a radio frequency data link to and/or from the HMD, such as a Bluetooth® link.

<FIG> schematically illustrates image processing carried out in response to a detected position or change in position of the HMD.

As mentioned above in connection with <FIG>, in some applications such as virtual reality and augmented reality arrangements, the apparent viewpoint of the video being displayed to the user of the HMD is changed in response to a change in actual position or orientation of the user's head.

With reference to <FIG>, this is achieved by a motion sensor <NUM> (such as the arrangement of <FIG> and/or the motion detector <NUM> of <FIG>) supplying data indicative of motion and/or current position to a required image position detector <NUM>, which translates the actual position of the HMD into data defining the required image for display. An image generator <NUM> accesses image data stored in an image store <NUM> if required, and generates the required images from the appropriate viewpoint for display by the HMD. The external video signal source can provide the functionality of the image generator <NUM> and act as a controller to compensate for the lower frequency component of motion of the observer's head by changing the viewpoint of the displayed image so as to move the displayed image in the opposite direction to that of the detected motion so as to change the apparent viewpoint of the observer in the direction of the detected motion.

In the context of the motion detection and image display arrangements shown in <FIG> and described above, <FIG> schematically represent respective sample images. These images might be displayed as part of the ongoing progress of a computer games program being executed by the computer games apparatus described above. The images represent the viewpoint of an HMD wearer. Although the HMD wearer would (in at least some examples) see the images as a three-dimensional representation, for example one which may be represented by a pair of left and right images, a single representation is shown in <FIG> for clarity.

In each case, a point <NUM> at the centre of the representation of the displayed image indicates a current viewpoint of the HMD. That is to say, the HMD is assumed to be currently pointing centrally with respect to the currently displayed images, so that a displacement of the HMD to one side will cause the displayed images to be rotated or displaced as shown in <FIG>, for example, so that different image content is displayed with respect to the prevailing viewpoint of the HMD.

Therefore, the arrangements discussed above are arranged to generate a representation of a virtual environment. This may include images indicative of the virtual environment, for example with respect to a user's current location and orientation in the virtual environment, and/or audio features (such as sounds) which again may be localised (by the use of stereo and/or binaural representations via the earpieces <NUM>, for example) in the virtual environment, for example relative to the user's current location and orientation in the virtual environment.

<FIG> schematically illustrate examples of head motion. The head motion may be in response to the respective displayed image as explained below.

The head motion represented by <FIG> can be real head motion in the case of the arrangements of <FIG> described above, or simulated head motion in the case of the arrangements to be described below.

Referring to <FIG>, the example image <NUM> includes an image feature <NUM>, shown schematically in this representation as a doorway. This is an example of a virtual environment feature. Another example is a sound at a particular perceived location in the virtual environment. In response to this image feature, the user is assumed to undertake head motion from a starting orientation <NUM> in a direction <NUM> towards a target location or viewpoint <NUM>, so as to look towards the doorway <NUM>. For example, although not shown in <FIG>, looking towards the doorway may trigger the games machine to cause the user to pass through that doorway in the virtual environment being displayed to the user, and so move into a different area of the virtual environment.

Another example is shown schematically in <FIG>, in which a control display <NUM>, for example representing an "activate menu" command, is displayed. From a starting position <NUM>, the user moving the HMD so as to direct the viewpoint to the HMD to a target location <NUM>, for example by a route <NUM>, causes the viewpoint of the HMD to be directed at the control display <NUM> and the menu to be activated.

<FIG> schematically represent such a menu when activated, in which a plurality of menu items <NUM> are displayed. Here, the user might be expected to start from a starting position <NUM> and direct the prevailing viewpoint of the HMD towards one or more of a range <NUM> of locations, for example via a route <NUM>, so as to select one of the menu items <NUM>.

In <FIG>, a schematic road <NUM> is displayed. If the user wishes to pass along the road <NUM> in the displayed virtual environment, the user might start from a starting position <NUM>, move towards a first target location <NUM> on the road <NUM> and then move along the road by a path <NUM>.

<FIG> schematically illustrate examples in which an avatar <NUM> is displayed, for example of a co-member of the user's team in a cooperative game or an enemy in, for example, a first person game. The user might be expected to start from a starting position <NUM> and move towards a target location <NUM>, for example by a path <NUM>, so as to look directly at the avatar <NUM>.

As mentioned above, the example arrangements of <FIG> represent situations which could arise within game play in a computer games system. When such a computer system is operated, it is desirable that the user enjoys the gameplay experience but is not subjected to unreasonable or excessive requirements for head motion in order to enjoy that experience. If the user was subjected to a requirement for excessive or unreasonable head motion in order to play the game (or carry out another data processing function in the case of a different type of data processing apparatus) this could lead to pain or discomfort on the part of the user and potentially decrease the popularity of the game program. So, in order to avoid this, it can be useful to undertake so-called quality control (QC) testing.

QC testing can encompass many aspects of the operation of a game program, for example checking that the game narrative flows appropriately depending on different user ability or choices made by the user during gameplay. But in the present context, QC testing can be carried out to assess whether the extent of head motion required by the user to execute the gameplay is perceived to be excessive.

One way to conduct QC testing is to employ one or more QC testing users, equip each such QC testing user with a HMD and a games machine, and have the QC testing user(s) play the game multiple times, wearing the HMD. However, in the case of investigating the question of whether excessive head motion is involved, this would be a subjective report by the QC testing users, and acquiring this information could be time consuming and potentially expensive. Therefore, according to embodiments of the present disclosure, QC testing to detect the extent of required head motion can be carried out automatically, without even the need for at least in some examples for a physical HMD to be used. Techniques by which this can be achieved will be discussed below.

<FIG> schematically illustrates an example games machine <NUM> and HMD <NUM> of the type discussed above.

The games machine <NUM>, shown in simplified form for clarity of the present explanation, comprises a game engine <NUM>, a display generator <NUM> and an operation detector <NUM>. The HMD, again shown in simplified form for clarity of the present explanation, comprises one or more displays <NUM>, such as one display for each of the user's eyes, and a motion detector <NUM>, such as a motion detector of one or more of the types discussed above, to detect motion of the HMD in use. The display generator <NUM> provides images <NUM> generated by the games machine <NUM> to the displays <NUM> and the motion detector <NUM> provides signals <NUM> indicative of detected motion to the operation detector <NUM> which in turn controls, at least to an extent, the operation of the games engine <NUM>.

Various examples will be discussed below of arrangements to simulate the signals <NUM> which would, in the case of conventional use of an HMD, be provided by the motion detector <NUM>, for example in response to one or more image features of images <NUM> generated by the games machine <NUM> as an example of a data processing apparatus. <FIG> provides one such example of motion signal generation apparatus comprising a detector (<NUM> - to be described below) to detect one or more image features of images generated by a data processing apparatus such as the games machine <NUM>, and a generator (<NUM> - to be described below), responsive to an image location of the one or more detected image features and to a current simulated orientation of a head mountable display (HMD), to generate a motion signal (<NUM> - to be described below) to simulate head motion by the wearer of the HMD, so that the generator is configured to provide the generated motion signal to the data processing apparatus.

<FIG> provides an example of a system comprising testing apparatus; and data processing apparatus such as the games machine <NUM> to provide generated images to the detector in response to the generated motion signal provided by the generator.

Turning to <FIG> in detail, a testing apparatus <NUM>, as an example of motion signal generation apparatus, comprises a controller <NUM> to control operation of the apparatus <NUM>, an image analyser <NUM> to perform image analysis operations on the images <NUM> generated by the games machine <NUM>, a control signal generator to generate simulated head motion signals (in other words, simulated versions of the signal <NUM> of <FIG>) in response to image features detected by the image analyser <NUM> and a simulated motion detector <NUM> to generate an output <NUM> indicative of one or more properties of the motion signals simulated by the control signal generator <NUM>.

In operation, the image analyser <NUM> detects one or more image features of the type shown in <FIG>. For example a database may be maintained by the image analyser <NUM> and stored in memory <NUM> for example, defining image features, potentially according to the following schematic example:.

The image analyser <NUM> detects the presence of one or more of the image features along with its location within a current image, and provides data <NUM> to the control signal generator <NUM> indicative of that detection. An example of an instance of the data <NUM> is shown below:.

The control signal generator <NUM> is responsive to the image location of the one or more detected image features and also a current simulated orientation of the HMD (which may be a central orientation such as that shown in <FIG>) to generate the signal <NUM>. The signal <NUM>, or a version of it, is passed to the simulated motion detector <NUM>.

<FIG> schematically illustrates an example of the control signal generator <NUM>, in which, from the signal <NUM>, a destination location detector <NUM> detects a destination or target location or orientation which the simulated HMD wearer will look at next. Assuming that the detected destination or target orientation is different to the current orientation of the HMD, a transition, represented by simulated head motion, between the current orientation and the target orientation is required. However, to simulate a real user, the transition between the current orientation and the target orientation does not take place instantaneously. Instead, the transition takes place at a transition speed consistent with achievable and realistic physical movement of the user's head in real life. The transition speed is controlled by a transition speed controller <NUM>.

The transition speed controller <NUM> can, in some examples, set a constant transition speed (for example, in degrees per second), but in other examples the transition speed controller <NUM> can apply a transition speed dependent upon the nature of the detected image feature which prompted the transition, subject in some examples to a maximum transition speed (in which case the generator is responsive to data defining a maximum rate of movement of the wearer of the HMD). For example, if the detected image feature is in a first category of image features, as indicated by the table given above, then the transition is deemed to be non-urgent for the purposes of the simulation and a first, lower, transition speed is used. In a second category of image feature as set out in the table given above, the transition is deemed to be urgent and a second, higher, transition speed is selected by the transition speed controller. So, in some examples, the transition speed controller can operate without a dependence on the signal <NUM>; but in other examples its operation can be dependent upon data defining the detected image feature forming part of the image signal <NUM>. Therefore, in examples, the detector is configured to derive the data defining the maximum rate of movement of the wearer of the HMD in response to the detected image features.

The transition speed and the destination are provided to a motion control signal generator <NUM>. This is also responsive to data stored by a memory <NUM> defining a current simulated location or orientation of the HMD, and, as indicated by the bidirectional arrow <NUM>, the motion control signal generator <NUM> is operable to update the current simulated location stored in the memory <NUM> in response to the generation of the signal <NUM> indicating simulated motion of the HMD.

In the example of <FIG>, the signal <NUM> is also supplied to the simulated motion detector <NUM>.

<FIG> schematically illustrates a simulated motion detector such as the simulated motion detector <NUM>, which is responsive, for example, to the signal <NUM> generated by the control signal generator <NUM>. This provides an example having a motion detector to detect at least one indicator of the extent of the simulated motion represented by the motion signal. The motion detector may comprise or be associated with a comparator to compare the detected indicator with a threshold value. The one or more indicators may comprise either or both of: a cumulative simulated head motion; and a peak displacement of the simulated head motion.

The example shown in <FIG> comprises a cumulative motion detector <NUM> and a peak motion detector <NUM>.

The cumulative motion detector <NUM> detects, over the course of gameplay or another period, the total head motion required of the user according to the simulated gameplay performed by the apparatus <NUM>. This can be expressed as, for example, a cumulative absolute number of degrees of head motion, such that any transition from one viewpoint to another (in either direction) is treated as a positive number of degrees of arc, and the cumulative total arc is established for the period of gameplay. This total <NUM> can be provided as an output <NUM> of the simulated motion detector <NUM> and/or can be compared by a comparator <NUM> with a threshold <NUM> to generate another signal <NUM> indicative of whether the threshold <NUM> has been exceeded.

The peak motion detector <NUM> detects one or both of: a peak transition speed set by the transition speed controller <NUM> and/or a peak arc traversed in a single transition. The detected peak information can be provided as an output <NUM> forming part of the output <NUM> of the simulated motion detector <NUM> and/or can be compared with a threshold <NUM> by a comparator <NUM> to generate and output <NUM> indicative of whether the threshold <NUM> was exceeded.

<FIG> schematically illustrates an example of the image analyser <NUM> of <FIG>.

A feature detector <NUM> is responsive to feature data stored in a memory <NUM>, such as the memory <NUM> of <FIG>, and a target location generator <NUM> (which may also be responsive to the feature data <NUM>) generates an output <NUM> (which may correspond to the output <NUM> discussed above) indicative of the location of detected features.

The target location generator and the destination location detector <NUM> of <FIG> may cooperate so that, between their respective functions, an appropriate target location is identified. It is not technically important from the point of view of the overall disclosure whether the selection of a particular target location is carried out by the image analyser <NUM> or the control signal generator <NUM> of <FIG>.

In some examples, the image analyser <NUM> acts as an example of a detector configured to detect a control display (such as the activate menu display <NUM> and/or the menu items <NUM> discussed above) in the images <NUM> generated by a data processing apparatus <NUM>, in which case the control signal generator <NUM> is configured to generate the motion signal <NUM> to simulate head motion of the wearer of the HMD towards the control display. In other examples, the image analyser <NUM> provides an example of an image detector configured to detect a predetermined feature, of a set of one or more predetermined features (such as those defined by the feature data in the memory <NUM>) in the images <NUM> generated by a data processing apparatus <NUM>. In this case, the control signal generator <NUM> is configured to generate the motion signal <NUM> to simulate head motion by the wearer of the HMD towards the detected predetermined feature. So, in this type of example, arrangements such as those shown in <FIG> are envisaged.

<FIG> shows another example of an image analyser which could be used in place of the image analyser <NUM>, in which a set of data defining which features should be looked at by the simulated HMD wearer is not required. Instead, random or pseudorandom locations are selected and their effect on the displayed images is detected.

In <FIG>, the images <NUM> are provided to a feature detector <NUM>. A random location detector <NUM> detects one or both of: random locations for the simulated HMD wearer to orientate the HMD towards; and/or random ones of detected features as detected by the feature detector <NUM>. The random location generator <NUM> therefore may be dependent upon data <NUM> received from the feature detector or may operate independently of the feature detector. The random locations are stored in a location store <NUM>. A target location generator <NUM> generates target locations which are provided as data <NUM> to the control signal generator. In response to simulated head motion to the target location identified by the target location generator <NUM> the feature detector <NUM> detects a change in the images <NUM> and/or in the detectable features within the images <NUM>. If such a change is detected, then the location set by the target location generator <NUM> is deemed to be a useful location and its entry in the location store <NUM> is marked as such. Examples illustrating the use of this technique will be described below with reference to <FIG>.

This provides an example in which the generator is configured to generate the motion signal to simulate successive instances of random or pseudorandom head motion by the wearer of the HMD; and the detector is configured to detect a change in the images generated by a data processing apparatus in response to an instance of simulated random or pseudorandom head motion.

In <FIG>, showing another example of an image analyser, a feature detector <NUM> refers to a so-called script file <NUM> containing script data indicative of a gameplay path through the current game software. An example of such a script file is shown below:.

The script file therefore tells the feature detector <NUM> the next feature which the feature detectors <NUM> should attempt to detect, and when it does so, it provides information to the target location generator <NUM> indicative of that detected feature. The feature detector <NUM> then moves on to attempting to detect the next feature in the order defined by the script file <NUM>.

This provides an example in which the detector is configured to detect a predetermined feature, of a set of one or more predetermined features, in the images generated by a data processing apparatus; and the generator is configured to generate the motion signal to simulate an instance of head motion by the wearer of the HMD according to data associating the set of predetermined features with respective instances of simulated head motion. In other words the instances of head motion do not have to be to look towards the detected feature.

<FIG> schematically illustrate respective example images, which for the purposes of this explanation are similar to the image of 12a showing a doorway <NUM>. With reference to <FIG>, the random location generator is shown schematically as generating three successive random locations for destinations or targets of HMD motion, indicated by an "X" notation and shown at positions <NUM>, <NUM>, <NUM> in <FIG>. Since none of these random locations overlaps the doorway <NUM>, transitioning the simulated HMD to be directed toward those locations does not cause the doorway to be opened by the games machine. A fourth random location <NUM> in <FIG> does happen to overlie the doorway <NUM> and so causes the doorway to be opened within the virtual world such that the user passes through the doorway in the virtual world into an example room <NUM> shown in the image of <FIG>.

Returning to <FIG>, for each of the random locations <NUM>, <NUM>, <NUM> the feature detector <NUM> detects that no images changes take place in the features present in the image based upon HMD motion being simulated to each of those random locations (other than a simple translation of the displayed image). However, in response to the location <NUM>, the image does change into that of the room <NUM> and so the location <NUM> is stored in the location store <NUM>.

The random locations used during this process do not contribute to the cumulative or peak motion detected by the simulated motion detector <NUM>, but transitions between the locations stored in the location store <NUM> and associated with useful transitions such as the location <NUM> do contribute to the cumulative and/or peak motions detections.

<FIG> schematically illustrates another example of a games machine <NUM> and a HMD <NUM>. The games machine <NUM> is similar to the games machine <NUM> except that the display generator <NUM> not only provides images to the HMD but also provides images to a separate so-called social screen <NUM> as discussed above. Once again, the images <NUM> provided to the HMD are displayed by one or more displays of the HMD and a motion signal <NUM> indicative of HMD motion is provided to an operation detector <NUM> of the games machine <NUM>.

<FIG> schematically illustrates another example of a games machine and a motion signal generation apparatus. Here, the games machine <NUM> is as shown in <FIG>, providing images to the social screen <NUM>. In the present case, however, the images <NUM> are not used, but instead in a motion signal generation apparatus <NUM>, one or more user controls are provided so that a user, observing the social screen <NUM>, can indicate by the user controls where the simulated HMD wearer should next look based on successive target locations <NUM> provided by the user controls <NUM>, a control signal generator <NUM> generates signals <NUM> to simulate the signals <NUM> of <FIG> and a simulated motion detector <NUM> generates an output <NUM> indicative of one or more properties of the simulated HMD motion. This provides an example in which the detector comprises a user control detector to detect operation of a user control indicating the one or more image features.

In another example, shown in <FIG>, a games machine <NUM> comprises a QC controller module <NUM> which interacts with the game engine <NUM> to control and/or detect parts of its operation. In doing so, the QC controller can provide a signal <NUM> to a target motion detector <NUM> of motion signal apparatus <NUM> indicative of locations which the HMD wearer is expected to look at in use (as an example of a test controller to generate information indicative of image features of the generated images). A control signal generator <NUM> operates as discussed above to generate signalled motion signals <NUM>, which can be analysed by the simulated motion detector <NUM> to generate an output <NUM> indicative of properties of those simulated motion signals.

<FIG> schematically illustrates the operation of the QC controller <NUM> in which a game progress detector <NUM> interacts with the game engine <NUM> according to information stored in a script file <NUM>. An example of such a script file is shown below:.

<FIG> is a schematic flowchart illustrating a method comprising:.

In some examples the detecting step <NUM> comprises detecting one or more audio features of an audio signal generated by the data processing apparatus; and
the generating step <NUM> is responsive to a location in the virtual environment of the one or more detected audio features and to a current simulated orientation of a head mountable display (HMD), to generate the motion signal to simulate head motion by a wearer of the HMD.

<FIG> is similar to <FIG> and schematically illustrates a testing apparatus having an example games machine <NUM>. The games machine <NUM>, again shown in simplified form for clarity of the present explanation, comprises a game engine <NUM>, an audio generator <NUM> and an operation detector <NUM>. The audio generator (which would typically operate in addition to a display generator, not shown in <FIG>) generates audio signals indicative or representative of the virtual environment. The audio signals <NUM> would, in normal operation, be provided to the earpieces <NUM> and/or to a social screen loudspeaker, for example via respective amplifiers. In the present example, they are analysed for audio features and their location. The audio signals are stereophonic, binaural or the like so that when replayed to the user wearing an HMD, they have an associated apparent location in the virtual environment. Testing apparatus <NUM>, as a further example of motion signal generation apparatus, comprises a controller <NUM> to control operation of the apparatus <NUM>, an audio analyser <NUM> to perform audio analysis operations on the audio signals <NUM> generated by the games machine <NUM>, a control signal generator <NUM> to generate simulated head motion signals (in other words, simulated versions of the signal <NUM> of <FIG>) in response to audio features detected by the audio analyser <NUM> and a simulated motion detector <NUM> to generate an output <NUM> indicative of one or more properties of the motion signals simulated by the control signal generator <NUM>.

In operation, the audio analyser <NUM> detects one or more audio features occurring during gameplay. These may be from a predetermined set of audio features. For example a database may be maintained by the audio analyser <NUM> and stored in memory <NUM> for example, defining detectable properties of audio features such as gunshots, shouts, dog barks or the like.

The audio analyser <NUM> detects the presence of one or more of the image features along with its location within the virtual environment, and provides data <NUM> to the control signal generator <NUM> indicative of that detection. The location in the virtual environment may be a location relative to the listener position. the audio analyser may establish or detect that location by analysis of the audio signal, for example by correlation and phase / amplitude detection of left and right audio signals using known localisation techniques.

Sounds in the predetermined list can be detected by their audio properties, such as their frequency distribution, attack, sustain and decay properties. For example a gunshot is assumed to have taken place if a particular set of attack-sustain-decay and frequency distribution (within margins or boundaries) are detected. If another sound (not generated as a representation of a gunshot) also happens to have those same properties and is erroneously detected as a gunshot, this is not in fact a problem because the aim of the system is to simulate the way that the user might turn towards the source of the gunshot to see what has happened. Another sound which is confusingly similar to a gunshot would probably have the same subjective effect on the user, and so it is in fact a useful outcome that it is also detected as a gunshot.

Another example of a predetermined sound is a human voice.

Rather than having a set of different predetermined sounds and individual detections, the set can in fact represent one set of parameters, for example that the sound has at least a certain attack, so that it is considered a sudden sound that the user is likely to look round towards.

For example, a sound, such as a sound in the predetermined list, occurring behind and to the left of the listener position would be deemed by the control signal generator to prompt head motion in a leftwards direction. The further the sound is behind the user, the further the head will turn. Similar considerations can apply to sounds above, to the right or below the user. For example, for a sound location at a particular azimuth angle Θ relative to the user's forward direction and a particular altitude angle Φ relative to the user's horizontal position, the control signal generator can act in an example as follows:.

For example, f(Θ) could be <NUM>° + (Θ - <NUM>°) / <NUM>.

In another example, f(Θ) could be <NUM>° + (Θ - <NUM>°)n, where n is for example <NUM>.

Similarly, in an example, g(Φ) could be <NUM>° + (Φ - <NUM>°) / <NUM>.

In another example, g(Φ) could be <NUM>° + (Φ - <NUM>°)n, where n is for example <NUM>.

The functions f and g can be the same as one another or different. The value given in the above equations as <NUM>° could be expressed as a variable selectable as a parameter and could be different for the two functions f and g.

The control signal generator <NUM> is therefore responsive to the environment location of the one or more detected audio features and also a current simulated orientation of the HMD (which may be a central orientation such as that shown in <FIG>) to generate the signal <NUM>. The signal <NUM>, or a version of it, is passed to the simulated motion detector <NUM>.

<FIG> schematically illustrates an example of the audio analyser <NUM> of <FIG>.

An audio feature detector <NUM> is responsive to feature data stored in a memory <NUM>, such as the memory <NUM> of <FIG>, and a target location generator <NUM> (which may also be responsive to the feature data <NUM>) generates an output <NUM> (which may correspond to the output <NUM> discussed above) indicative of the location of detected audio features, for example by phase / amplitude analysis of the left and right audio signals.

<FIG> shows another example of an audio analyser which could be used in place of the audio analyser <NUM>, in which a set of data defining which features should be looked at by the simulated HMD wearer is not required. Instead, random or pseudorandom locations are selected and their effect on the displayed images is detected.

In <FIG>, the audio signal <NUM> is provided to an audio feature detector <NUM>. A random location detector <NUM> detects one or both of: random locations for the simulated HMD wearer to orientate the HMD towards; and/or random ones of detected audio feature locations as detected by the audio feature detector <NUM>. The random location generator <NUM> therefore may be dependent upon data <NUM> received from the audio feature detector or may operate independently of the audio feature detector. The random locations are stored in a location store <NUM>. A target location generator <NUM> generates target locations which are provided as data <NUM> to the control signal generator. In response to simulated head motion to the target location identified by the target location generator <NUM> the audio feature detector <NUM> detects a change in the audio signal <NUM>. If such a change is detected, then the location set by the target location generator <NUM> is deemed to be a useful location and its entry in the location store <NUM> is marked as such.

Note that the audio feature detection arrangements and the image feature detection arrangements discussed above may be used together, so that head motion is simulated towards an image feature or an audio feature, whichever is detected.

<FIG> therefore provide examples of motion signal generation apparatus comprising:.

In examples, the detector <NUM> is configured to detect one or more audio features of an audio signal generated by the data processing apparatus; and.

the generator <NUM> is responsive to a location in the virtual environment of the one or more detected audio features and to a current simulated orientation of a head mountable display (HMD), to generate the motion signal to simulate head motion by a wearer of the HMD.

It will be appreciated that example embodiments can be implemented by computer software operating on a general purpose computing system such as a games machine. In these examples, computer software, which when executed by a computer, causes the computer to carry out any of the methods discussed above is considered as an embodiment of the present disclosure. Similarly, embodiments of the disclosure are provided by a non-transitory, machine-readable storage medium which stores such computer software.

Claim 1:
A system comprising a motion signal generation apparatus and a data processing apparatus,
wherein the motion signal generation apparatus comprises:
a detector (<NUM>) to detect one or more features of a virtual environment generated by a data processing apparatus; and
a generator (<NUM>), responsive to an environment location of the one or more detected features and to a current simulated orientation of a head mountable display (HMD), to generate a motion signal to simulate head motion by a simulated wearer of the HMD, wherein the generator is configured to provide the generated motion signal to the data processing apparatus,
wherein the data processing apparatus is configured to provide generated images to the detector in response to the generated motion signal provided by the generator, and
wherein the generated motion signal indicates simulated motion of the HMD.