the present invention will be described below by way of a preferred embodiment as an improvement over the aforementioned computer user interface systems , and implemented on an apple macintosh ® ( trademark of apple computer , inc .) computer system . it is to be noted , however , that this invention can be implemented on other types of computers and electronic systems . regardless of the manner in which the present invention is implemented , the basic operation of a computer system 800 embodying the present invention , including the software and electronics which allow it to be performed , are described with reference to the block diagram of fig8 wherein numeral 801 indicates a central processing unit ( cpu ) which controls the overall operation of the computer system , numeral 803 indicates a standard display device such as a cathode ray tube ( crt ) or liquid crystal display ( lcd ) screen , numeral 805 indicates an input device which may include both a standard keyboard and a pointer - controlling device such as a mouse as well as a microphone or other sound input device , numeral 807 indicates a memory device which stores programs according to which the cpu 801 carries out various predefined tasks , and numeral 809 indicates an output device which may include a loudspeaker for playing sound . when humans look around in the real world , they tend to turn their head through a limited arc of rotation . when that isn &# 39 ; t far enough , they start turning their bodies . if the point of interest is known to be farther away than a simple head - turn can accomplish , humans typically start turning their bodies sooner , but still lead body rotation with head rotation so that they can see what is coming . in traditional user interfaces for computer - based three - dimensional spaces , when the user wants to look to the right , the system provides a sequence of visual feedback similar to the column of display images shown in fig1 . in this sequence , the virtual camera is rotating to the right , with the result that the content of the display images shown is shifting to the left , with changes in perspective as appropriate . the display image sequence shown provides no clue as to whether it is the user &# 39 ; s virtual body or virtual head that is rotating : the sequence would be identical in either case . horizontal rotation is the simplest application of the present invention technique referred to herein as a motion - cueing view window . the sequence of display images shown in fig2 uses key frames ( representative display images ) in the interaction to demonstrate how the motion - cueing view window simulates the head - turn / body - turn process by sliding a view port ( the image area or window ) as well as changing the displayed image within the view port , thus reinforcing for the user the fact that their virtual body is also turning . one embodiment of the motion - cueing view window has three stages : the head - turn stage , the body - turn stage , and the recentering stage . when the user wants to look to the right , first the view port slides to the right , with the content of display images shown shifting to the left within it . this first stage , dubbed the head - turn stage , simulates the initial head - turn and can be seen in figure display images 2 ( a ) through 2 ( d ). one key to the head - turn stage is the synchronization between the view port sliding and the display image shifting within it . ideally , the sliding and shifting will be synchronized so that objects within the display image will appear to be fixed to the screen , with the view port appearing to pan over them , as shown in fig3 . note how the same part of the display image lies beneath the vertical line drawn through the display images in figure display images 3 ( a ) through 3 ( d ). once a prescribed view port slide limit is reached , the view port stops sliding right , but the content of the display images shown continues to shift left to reflect the body &# 39 ; s continued rotation to the right . this stage , dubbed the body - turn stage , simulates the user &# 39 ; s body turning and can be seen in figure display images 2 ( e ) through 2 ( h ). finally , when the user has reached the view in which they are interested ( the view port contains the desired display image ), turning stops and the view port slides back left to the center ( starting ) position . the display image remains fixed within the view port as the view port slides back to the center of the window . this stage , dubbed the recentering stage , simulates the body rotation catching up with the head &# 39 ; s lead rotation , and is shown in figure display images 2 ( i ) and 2 ( j ). note that the display image key frames shown in fig2 for each stage are for illustration only ; the number of images actually shown in each stage depends on the implementation , the rendering engine complexity , the overall system performance , the edge margin width and the user &# 39 ; s interactive input , among other possible factors . the example shown in fig2 works similarly for turning to the left : if the user wanted to look to the left , rather than to the right , the view port would slide leftward until it hit the prescribed limit , with the content of the display images shifting to the right within it . once the desired display image view had been reached , the view port would slide back to the center position ( by sliding right ). while the example above shows only one - dimensional left - right rotation , it is possible to use the motion - cueing view window in more than one - dimension . for many applications , only one - dimension is appropriate , because while it simplifies matters to lock the virtual head to the virtual body for horizontal rotation , there may be no reason to do so for vertical rotation . when a human being looks up in traditional three - dimensional space , their body is still pointed forward , rather than now being pointed upward , so it may be most appropriate to use the motion - cueing view window for horizontal view rotation yet not for vertical view rotation . in this case , the motion - cueing view window would be used for horizontal rotation , with a traditional rotation sequence like that shown in fig1 being used for vertical rotation . however , there are applications of the motion - cueing view window in two - dimensions useful for navigating in less constrained environments , such as underwater or in space . in virtual spaces simulating such environments , it may be desirable to unlock the head from the body in both directions of rotation . therefore , a two - dimensional motion - cueing view window ( one which slides up and down as well as left and right ) would be appropriate for these cases , as well as for others not specifically called out here . the three - stage implementation described above is only one embodiment of the motion - cueing view window . rather than having distinct head - turn and body - turn stages , the two stages can be combined . in an integrated head - turn / body - turn stage , the sliding of the view port is synchronized with the shifting of the display image content in a manner which conveys the combination of head - turning and body - turning . in fig3 the image content position was fixed relative to the screen , with the view port sliding over it , in order to convey a rotating head on a fixed body . fig4 shows key frames ( representative display images ) from the sequence of display images which would result if the model is simulating simultaneous head - and body - turning through the initial rotation . in figure display images 4 ( a ) through 4 ( c ), both head and body are rotating , dubbed the combined - turning stage . figure display images 4 ( d ) and ( e ) represent the body - turn stage , with only the body rotating , as indicated by display image movement only without further view port sliding . figure display images 4 ( g ) and ( h ) represent the familiar recentering stage wherein the view port returns to its center or starting position while holding the current display image constant therein . an important difference between fig4 and fig2 lies in their first stage . comparing fig5 and 3 demonstrates this difference . whereas in fig3 the display image content is fixed relative to the screen ( as shown by the white line ), fig5 shows how the display image content is shifting at a faster rate than the view port is sliding , reflecting the combined speed of both head and body rotation . note that the relative image shift ( the relative change between display images ) between the figure display images 5 ( a ), 5 ( b ) and 5 ( c ) ( the combined - turn stage ) is the same as the display image shift between the figure display images 5 ( c ) and 5 ( d ) ( the body - turn stage ). when fig4 is viewed interactively , the overall speed of rotation in figure display images 4 ( a ) through 4 ( e ) appears to be constant , because the increased speed of rotation through the combined - turning stage offsets the sliding of the view port . the head - turn stage and combined - turn stage are not the only ways in which head and body turning can be implemented using the motion - cueing view window . for instance , another embodiment of the motion - cueing view window allows the first few frames of rotation to occur within a fixed view port , in order to simplify stepping the image right and left . these fixed frames of rotation correspond to an eye movement stage , which can happen without moving the head or body . when eye movements are supported , the combined - turn stage is a particularly desirable embodiment of the motion - cueing view window . the actual speed of rotation of eye , head and body are all independent , and are implementation dependent . other embodiments of the motion - cueing view window are possible by creating further combinations of the view port sliding mechanism , and the eye - movement , head - turn , body - turn , combined - turn and recentering stages described above . there are a number of approaches to the controlling interface , of which we describe the two main variants : ` buttons ` and ` in - view ` interfaces . other variants can be produced through combinations of these main approaches . for simplicity , only interfaces for the one - dimensional rotation case will be described here . the simplest interface is to have distinct buttons apart from the view port . a two button case is shown in fig6 . note that the buttons can be shown on - screen , as illustrated , or could be located in an external hard interface ( e . g . a multiple button mouse , or game - oriented controller ). both cases are effectively the same . a button initiates looking in a particular direction ; in the preferred embodiment , the right arrow button looks to the right , and the left arrow button looks to the left . the view port slides to the right , with the display image shifting to the left as shown in fig2 when the view port hits the limit , it stops sliding , but the display image continues to shift to the left , as shown in fig2 . the view port slides back to the center position , with the display image fixed within it . the speed at which the view port slides , and the speed at which the display image shifts within it , may be held constant , or may depend on user actions other than the simple pressing of the button ( mouse movement after the button , an independent speed control , etc .). if the user releases the right arrow button while the view port is initially sliding to the right , the display image stops shifting and the view port slides back to the center position . if the user simply clicks the right arrow button ( doesn &# 39 ; t hold it down for very long ), the display image may shift within the view port , without the view port sliding at all . note that it is possible to combine the two buttons into a single button , with mouse movement of a cursor within the button providing further information . after the initial mouse down within the button , cursor position within the button controls the direction and possibly the movement rate . the motion - cueing view window reacts accordingly ( see in - view interface below for the type of feedback experienced ). another approach is to have the user control the rotation directly on the display image . in a simple on - screen joystick implementation , the user could control direction and rate of rotation . the user could click on the right half of the display image to look to the right , and on the left half of the display image to look to the left . the display image would appear to continue moving right or left as long as a control button is held down . position relative to the center of the display image could control speed of rotation . joystick implementations could also be implemented using external hardware controllers . a hybrid joystick implementation would allow the user to drag the view port left or right ( via a mouse or other direct manipulation controller ), as appropriate , and would change to a joystick mode once the view port limit was reached . to look to the right , the user would mouse down anywhere in the view port and drag the mouse to the right . as the user drags the mouse to the right , the view port slides to the right as well . the exact mapping ( 1 : 1 mouse pixel : view port pixel , some other linear mapping , or a non - linear mapping ) is implementation - dependent . as the view port slides to the right , the display image within it changes in synchronization as described above in &# 34 ; visual design .&# 34 ; once the view port reaches the right - most view port limit , the view port stops sliding . if the mouse is dragged farther to the right , the display image starts shifting within the view port . speed of rotation could be related to the degree of offset between the mouse &# 39 ; s current cursor position and its position when the right - most view port limit was reached . if the mouse is moved to the left of the mouse position at which the right - most view port limit was reached , the view port once again starts to track the mouse according to the mouse - view port mapping . the image within the view port changes in synchronization as described above in &# 34 ; visual design .&# 34 ; note that within a single interaction , the user can look both left and right of the starting display image view angle , simply by dragging the view port left of center , and then back through center , and then right of center . if the mouse button is released , the view port slides from its current position back to the center , with the display image fixed within it . using this interface , the user can look left and right in small increments by dragging the view port left and right , without getting to the body - turn stage of rotation . this type of interface could be combined with some buttons that provide step functionality . these buttons may be explicit external buttons , may be implicit buttons located in the margins at the left and right of the view port , or may be at the borders of the display image . fig7 shows how the various areas of the view port and its surroundings might be used . the interior ( a ) of the view port triggers the standard motion - cueing view window routines . mouse clicks in the interior do not directly control the display image view angle . the outermost edges or borders ( b ) of the view port trigger both the standard motion - cueing view window interaction routines on click and drag , but also trigger step functions on mouse click only . the right and left margins ( c ) act as step functions on mouse click , and as continuous rotate functions of the display image within the static view port ( like fig1 ) on mouse click and hold . mouse click and drag in these regions is not differentiated from mouse click and hold , other than possibly affecting the rate of rotation of the display images within the static view port . note that these interfaces only demonstrate the one - dimensional rotation case . in cases where two - dimensional rotation is required , the interfaces described above can be directly extended to work in two - dimensions . another extension would be to combine traditional vertical rotation with the one - dimensional motion - cueing view window described above . in the foregoing specification , the present invention has been described with reference to a specific exemplary embodiment and alternative embodiments thereof . it will , however , be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims . the specifications and drawings are , accordingly , to be regarded in an illustrative rather than a restrictive sense .