Abstract:
An authoring system for assigning geo-spatial position to sensory-effect data is disclosed. The sensory-effect data can include one or more of the group of alpha numeric data, image data, sound data, smell data, temperature data, humidity data, wind data, pressure date and light data. The alphanumeric data may comprise computer readable code for, in use, instructing the system to control presentation of the sound, image, smell, humidity, wind, pressure, or light data to an exposee. The authoring system may comprise a user interface on which the geo-space is represented, the interface being arranged in a manner such as to enable, in use, a user to assign the geo-spatial position to the data by placing and manipulating markers on the interface. The authoring system preferably comprises means for defining relationships between markers. The relationship may be one or more of defining a marker as a parent of, and/or a child of, and/or a grandparent of, and/or a grandchild of another marker, whereby respective markers inherit a functionality of their respective parent and/or grandparent.

Description:
FIELD OF THE INVENTION  
         [0001]    The present invention relates broadly to an authoring system which can be utilised to create a landscape data file for presentation to an exposee.  
         BACKGROUND OF THE INVENTION  
         [0002]    Traditional virtual reality systems aim to provide an exposee with the experience of a completely artificially constructed landscape, ie a virtual reality. Virtual reality systems have so far been dominated by visual considerations. In keeping with the concept of creating a completely artificial environment, such virtual reality systems typically seek to eliminate any real or geo-spatial experience for the exposee.  
           [0003]    In having that aim, it may be said that such systems neglect the beneficial experiences that result from being exposed to a real environment, and rather put the entire emphasis and burden on the ability of the system to attempt to recreate an ever more realistic, yet artificial, environment.  
         SUMMARY OF THE INVENTION  
         [0004]    In accordance with a first aspect of the present invention there is provided an authoring system for assigning a geo-spatial position to sensory-effect data, said authoring system comprising an author interface for displaying a representation of a real geo-space, sourcing means for sourcing sensory-effect data and assigning means for enabling an author to assign said sensory effect data to a location within the representation corresponding to a real location within the geo-space at which delivery of the sensory-effect data is to be effected.  
           [0005]    In one embodiment the authoring system further comprises trigger assigning means enabling the author to assign a trigger condition to said sensory-effect data, said trigger condition controlling the delivery of said sensory-effect data at said real location. Preferably the authoring system further comprises trigger condition meeting means enabling the author to satisfy a trigger condition within the representation to cause a representation of sensory-effect data associated with said trigger condition to be delivered at said interface.  
           [0006]    Preferably, the sensory-effect data comprises one or more of the group of alpha numeric data, image data, sound data, smell data, temperature data, humidity data, wind data, pressure date and light data.  
           [0007]    The alphanumeric data may comprise computer readable code for, in use, instructing the system to control presentation of the sound, image, smell, humidity, wind, pressure, or light data to an exposee.  
           [0008]    The authoring system may comprise a user interface on which the geo-space is represented, the interface being arranged in a manner such as to enable, in use, a user to assign the geo-spatial position to the data by placing and manipulating markers on the interface.  
           [0009]    The authoring system preferably comprises means for defining relationships between markers. The relationship may be one or more of defining a marker as a parent of, and/or a child of, and/or a grandparent of, and/or a grandchild of another marker, whereby respective markers inherit a functionality of their respective parent and/or grandparent.  
           [0010]    The functionality of respective markers may comprise one or more of the group of a trigger marker, a motion marker, a sound marker, an image marker, an exposee marker representing the location of an exposee within the geo-space and position marker.  
           [0011]    The trigger marker is advantageously arranged in a manner such that, in use, an associated event is triggered depending on the exposee entering a triggering zone of the trigger marker. The triggering zone may be of a circular shape. The triggering zone may alternatively be of any defined shape.  
           [0012]    The motion marker may be arranged in a manner such that, upon being triggered by an associated triggering marker, a source of data for presentation to the exposee is being moved along predetermined paths. Alternatively, the motion marker may be arranged in a manner such that, upon being triggered by the associated triggering marker, the source of the data for presentation to the exposee is being attached to the exposee, whereby the movement of the source follows that of the exposee.  
           [0013]    The motion marker may be arranged in a manner such that it provides its own triggering functionality.  
           [0014]    The position marker may be arranged in a manner such that its movement within the geo-space represented on the user interface is dependant upon positioning data externally provided to the authoring system. The positioning data may be provided to the authoring system by way of a global positioning system (GPS).  
           [0015]    The position marker may further or alternatively be arranged in a manner such that, in use, its orientation within the geo-space represented on the user interface is dependant upon orientation data externally provided to the authoring system. The orientation data may be provided, in use, by way of sensor means carried by the exposee.  
           [0016]    The authoring system may be arranged to transfer the sensory-effect data having the geo-spatial position assigned to it to a rendering tool via a data carrier means comprising one or more of the group of a computer network, a portable data carrier, or a wireless data carrier for effecting the presentation of the sensory-effect data to the or an exposee.  
           [0017]    The authoring system may further comprise a rendering tool for effecting the presentation of the sensory-effect data to the exposee.  
           [0018]    Advantageously, the authoring system is arranged in a manner such that, in use, the effecting of the presentation of the sensory-effect data to the exposee can be manipulated in real-time by the user.  
           [0019]    In accordance with a second aspect of the present invention there is provided a rendering tool arranged, in use, to effect presentation of sensory-effect data received from the authoring tool of the first aspect.  
           [0020]    The invention may alternatively be defined as providing an authoring tool comprising means for creating a data stream which is a combination of data representing a real geo-space and data representing a sensory effect.  
           [0021]    The invention may alternatively be defined as providing an authoring tool adapted to create a data stream useable by a presentation means to present a sensory effect to an exposee who uses moves through a real geo-space, said data stream comprising a combination of data representing said real geo-space, and data representing a sensory effect which is assigned to a geo-spatial location in said representation of said real geo-space.  
           [0022]    In at least the preferred embodiments, the present invention seeks to provide a system in which the benefits of both virtual and actual reality can be combined so as to provide a more rewarding experience for the exposee.  
           [0023]    In one further aspect the present invention provides a method of assigning a geo-spatial position to sensory effect data comprising the steps of displaying a representation of a real geo-space at an author interface, sourcing sensory-effect data, and assigning said sensory-effect data to a location within the representation corresponding to a real location within the geo-space at which delivery of the sensory-effect data is to be effected.  
           [0024]    In one further aspect the present invention provides a method of enabling an author to assign a geo-spatial position to sensory-effect data comprising the steps of providing an author interface for displaying a representation of a real geo-space, providing sourcing means for sourcing sensory-effect data, and providing assigning means for enabling an author to assign said sensory effect data to a location within the representation corresponding to a real location within the geo-space at which delivery of the sensory-effect data is to be effected. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0025]    Preferred forms of the present invention will now be described, by way of example only, with reference to the accompanying drawings.  
         [0026]    [0026]FIG. 1 shows an authoring tool user interface embodying the present invention;  
         [0027]    [0027]FIG. 2 shows a map and sound layers populated embodying the present invention;  
         [0028]    [0028]FIG. 3 shows sound object properties embodying the present invention;  
         [0029]    [0029]FIG. 4 shows an example of sound objects embodying the present invention;  
         [0030]    [0030]FIG. 5 shows an object inheritance embodying the present invention;  
         [0031]    [0031]FIG. 6 shows trigger object properties embodying the present invention;  
         [0032]    [0032]FIG. 7 shows sound source properties embodying the present invention;  
         [0033]    [0033]FIG. 8 shows script mover properties embodying the present invention;  
         [0034]    [0034]FIG. 9 shows an authoring tool user interface embodying the present invention;  
         [0035]    [0035]FIG. 10 shows listener properties embodying the present invention;  
         [0036]    [0036]FIG. 11 a property sheet for a keyboard mover embodying the present invention;  
         [0037]    [0037]FIG. 12 shows multiple threads embodying the present invention;  
         [0038]    [0038]FIG. 13 shows an example C++ class hierarchy embodying the present invention.  
         [0039]    [0039]FIG. 14 shows an example of a scenario illustrating the working of one embodiment of the present invention;  
         [0040]    [0040]FIG. 15 shows an example of a scenario illustrating the working of another embodiment of the present invention; and  
         [0041]    [0041]FIG. 16 shows an example of an environment in which the preferred embodiment operates. 
     
    
     DETAILED DESCRIPTION OF THE EMBODIMENTS  
       [0042]    The authoring tool of the preferred embodiment allows sounds to be positioned in space, and for various sound behaviours to be specified. The authoring tool generates a Sonic Landscapes Scene (SLS) file as its output.  
         [0043]    A rendering tool reads the SLS file, and generates a binaural feed to the user in response to GPS (user location) and compass (user head orientation) information. The user has the impression that a Sonic Landscape has been overlayed on real space.  
         [0044]    The tools are sufficiently integrated to allow the author to interactively modify a Sonic Landscapes Scene while listening to the changes. Diagrams of the user interface and property sheets are included for clarity. These should not be considered prescriptive.  
         [0045]    As is shown in FIG. 1, the authoring tool defines a two dimensional scene  10 , viewed from above, and allows it to be annotated with sounds, sound behaviours and bitmaps. The resulting sonic landscapes scene is stored in an .sls file.  
         [0046]    The scene  10  is composed of two layers: a map layer, and a sound layer. FIG. 1 shows an example user interface only. The map layer (imported as a bitmap file) depicts a residential area to be annotated. The authoring tool overlays a 1 m grid.  
         [0047]    [0047]FIG. 2 shows a listener object  12  and a sound source object  14  in the sound layer. In this example the listener object  12  is represented with a square, and the sound source object  14  with a circle. An arrow  13  shows which direction the listener object  12  is facing.  
         [0048]    The author can move the listener object  12  and sound source object  14  using the mouse. Double clicking on the sound source object  14  reveals a property sheet. Examples of property sheets  30 ,  32 ,  34  and  36  are shown in FIG. 3. The property sheets  30 ,  32 ,  34 ,  36  are able to name the sound source, specify when the sound source is played, and what sound is played.  
         [0049]    Generally sound source objects are set to trigger when the listener object  12  approaches, and to switch off when the listener object  12  moves away.  
         [0050]    As well as sound source objects and listener objects, a number of other objects can be provided, some of which are defined and illustrated in FIG. 4.  
         [0051]    A trigger object  40  generate triggers when a listener approaches or moves away (square).  
         [0052]    Script mover objects  42  follow a defined trajectory when triggered (square).  
         [0053]    Keyboard mover objects 44  have position and orientation, and are moved using the cursor arrow keys (↑ moves forwards, ↓ moves backwards, ← moves left, and → moves right). These objects may be utilised to simulate movement of a “test” exposee.  
         [0054]    Compass mover  46  objects can be used to input head orientation information into the rendering tool, and GPS mover objects  48  can be used to input user position information into the rendering tool.  
         [0055]    Bitmap objects (not shown) allow a bitmap to be displayed and re-sized in either the Map or Sound layers. It is ignored by the rendering tool, but may be useful in the authoring tool. Most commonly the bitmap object is used to display a map in the map layer.  
         [0056]    The exemplified sonic landscape scene  52  in FIG. 4 shows a number of objects in a typical arrangement. The listener  54  orientation is input using the compass mover  46 , and the listener object  54  position is input using the GPS mover  48 . The trigger  40  activates as the listener  54  approaches, and this causes the sound source  56  to start playing, and the script mover  42  to start moving.  
         [0057]    A origin point  49  is defined within the sonic landscape scene  52 , and acts as an internal reference point for the assignment of the geo-spatial data to the respective objects.  
         [0058]    Inheritance  
         [0059]    Inheritance is an important concept in the Sonic Landscapes Scene of the preferred embodiment. Objects may either exist independently, or as children of other objects. An object may have any number of children, but can have only one parent. An object inherits some of the characteristics of its parent. The most important characteristics are position and orientation. Thus if a parent moves, all children move by the same amount. A child inherits the orientation of its parent, unless it has an orientation of its own.  
         [0060]    Inheritance has many uses. In FIG. 4, for example, the sound source  56  is a child of the script mover  42 . When the script mover  42  is triggered and starts to move, the sound source  56  follows the same trajectory (technically, the position of a child relative to its parent is fixed).  
         [0061]    Also in FIG. 4, the listener  54  is a child of the compass mover  46 , which in turn is a child of the GPS mover  48 . The listener  54  inherits its position and orientation from the compass mover  46 . The compass mover  46  has its own sense of orientation (derived from external hardware with the help of the rendering tool), and inherits position from the GPS mover  48  (which gets its position from external hardware with the help of the rendering tool).  
         [0062]    The net effect is that the listener position can input by the GPS hardware, and the listener orientation can be input by the compass hardware.  
         [0063]    [0063]FIG. 5 shows that if the compass mover  46  is selected, a line  58  is drawn to its parent (GPS mover  48 ), and a line  59  is drawn to its child (listener  54 ). This allows the author to check family relationships.  
         [0064]    The advantage of an inheritance model is that complex behaviours can be built up using different family trees. For example, several different script mover objects can be made children of each other, and the trajectory of the lowest child is the sum of the trajectories of all its parents.  
         [0065]    Triggering  
         [0066]    Triggers activate sound source and script mover objects. A trigger has an ID, and can be generated using a trigger object.  
         [0067]    [0067]FIG. 6 shows the property sheets  60 ,  61  for the trigger object  40  in FIG. 4. When the listener  54  in FIG. 4 moves within 2 m of the trigger object  40 , it generates trigger ID MY_SOUND_ON ( 62 , FIG. 6). When the listener then moves over 8 m away, it generates trigger ID MY_SOUND_OFF ( 64 , FIG. 6).  
         [0068]    The trigger object  40  simply generates trigger IDs  62 ,  64 . It is up to other objects to respond to them.  
         [0069]    Both the script mover  42  and the sound source  56  in FIG. 4 respond to trigger ID&#39;s generated by the trigger object  40 . FIG. 7 shows the configuration of the sound source  56 . It is set to play 5 seconds after trigger ID MY_SOUND_ON ( 72 ), and stops playing 10 seconds after trigger ID MY_SOUND_OFF ( 74 ).  
         [0070]    The effect for the user is that the commentary starts to play from the house  41  (FIG. 4) when they approach the trigger object  40 , and stops as they walk away. The commentary will only play twice  73 , even if the user keeps returning to the trigger object  40 .  
         [0071]    [0071]FIG. 8 shows the property sheets  80 ,  81 ,  82 ,  83  for the script mover  42  of FIG. 4. The settings for trigger response are the same as for the sound source  56 , meaning that the script mover  42  moves at the same time as the sound source  56  plays. Notice how the trajectory is described using a .loc file  84  which can contain a series of location values, and the speed of the trajectory is specified using the time step parameter  86 .  
         [0072]    Both the sound source sheets (FIG. 3) and the script mover sheets (FIG. 8) contain a trigger generation property page  88  similar to the trigger object. In fact, both the sound sources and the script movers can act like trigger objects. This allows the author to quickly create sounds that trigger when the listener approaches, without having to create a specific trigger object for each sound.  
         [0073]    User Interface  
         [0074]    [0074]FIG. 9 shows some of the user interface features of the authoring tool. Right clicking on the sonic landscapes scene  90  generates a pop-up menu  92  that allows objects to be added and deleted, as well as inheritance relationships to be altered. All these options are repeated in the menus.  
         [0075]    The FLIP button  94  on the toolbar  96  brings the Map layer to the foreground and hides the sound layer. The map layer can now be edited (normally it does not respond to mouse input).  
         [0076]    Other controls (not shown in FIG. 9) can be Stop/Play/Pause buttons on the toolbar, which control the playing of sounds and other sound behaviours. These are used to control the rendering tool.  
         [0077]    The user may zoom in and out of a sonic landscape using the mouse wheel.  
         [0078]    Preview  
         [0079]    The authoring tool of the preferred embodiment is closely integrated with a rendering tool, which allows the user to listen to changes to the sonic landscapes scene as they are made. The author can simulate the effect of the listener moving through the scene by dragging the listener icon with the mouse, or making the listener a child of a keyboard mover object.  
         [0080]    Object Reference  
         [0081]    This section gives a more detailed description of each of the object types definable as part of the preferred embodiment.  
         [0082]    Listener  
         [0083]    Defines the listener position. It is often made a child of the keyboard mover, compass mover or GPS mover discussed below. The property sheet  100  is shown in FIG. 10.  
         [0084]    Sound Source  
         [0085]    Defines the sound sources in the sonic landscapes scene. The property sheet is shown in FIG. 3. A number of options can be included for volume  300 , roll off characteristics  302 , looping etc.  
         [0086]    Several pre-specified roll-off models are based on two ellipses with no output occurring outside the outer ellipse and a constant output inside the inner ellipse. A log roll-off can be provided between the two. Further modified alternatives including Low Pass filtering to model the absorptive properties of air, to give a sense of distance could, for example, be provided.  
         [0087]    Ideally it is possible to specify an arbitrary period of silence (pre roll)  304  before each file is rendered.  
         [0088]    If a sound object receives an exit trigger event while playing, it plays the current sound file to completion, and then stops.  
         [0089]    Sound Stack  
         [0090]    A sound stack can be provided which is similar to a sound source, but contains a number of sound files that can loop and stack in various ways. For example:  
         [0091]    1 Have lists of sound files that play either in sequence or in a random order until all content has played.  
         [0092]    2 Lists can either play once or loop.  
         [0093]    3 If a sound object receives an exit trigger event while playing, it plays the current sound file to completion, and then stops.  
         [0094]    4 Looped/stacked sounds remember their status, and resume if a subsequent trigger activation event is received.  
         [0095]    Trigger  
         [0096]    A trigger responds to approaching listeners by generating trigger ID&#39;s. It is used to trigger sound sources and other behaviours as discussed previously. The property sheets  60 ,  61  are shown in FIG. 6, and the behaviour has been described above:  
         [0097]    1 Triggers can be configured to generate events when a listener approaches, moves away, or both. The events that each trigger produces has a text to trigger ID  
         [0098]    2 Two concentric circles can be used define a trigger&#39;s approach/exit area.  
         [0099]    3 Complex triggering behaviours can be achieved using multiple triggers. For example, a sound source may receive an activation trigger ID from one trigger object, and a deactivation trigger ID from another trigger object.  
         [0100]    Polygon Trigger  
         [0101]    A polygon trigger is similar to a trigger, except the trigger approach/exit area can be defined using two arbitrary polygons.  
         [0102]    Script Mover  
         [0103]    A script mover moves along a defined trajectory described by a .loc script file  84  the format of this file can consist of a series of location points. The property sheet is shown in FIG. 8. The speed of the trajectory is defined by the time step parameter  86 .  
         [0104]    The .loc script file  84  can describe the trajectory as a list of vertices, and the script mover moves along straight lines between the vertices. The position can be interpolated, and time step can be the time in ms to travel between two vertices.  
         [0105]    A script mover can be a child of a listener, and by attaching sound sources as children, these can be made to move relative to the listener.  
         [0106]    Keyboard Mover  
         [0107]    The keyboard mover moves under the control of the keyboard, and is a useful tool for the author in testing scenarios. The property sheet  110  is shown in FIG. 11.  
         [0108]    Compass Mover  
         [0109]    The compass mover is used to input user head orientation information into the rendering tool. The property sheet allows for configuration of the compass hardware (dependent on the specific compass being used).  
         [0110]    GPS Mover  
         [0111]    The GPS mover is used to input user position information into the rendering tool. The property sheet allows: configuration of the GPS hardware, including initialisation commands (dependent on the specific GPS receiver being used); and entering of the GPS coordinates of the sonic landscapes scene origin.  
         [0112]    Bitmap  
         [0113]    Allows a bitmap to be displayed and re-sized in either the map or sound layers. It is ignored by the rendering tool, but may be useful in the authoring tool. Most commonly the bitmap object is used to display a map in the map layer.  
         [0114]    Theme Zone  
         [0115]    The theme zone object defines a region where a number of sounds are randomly positioned and looped to generate a sonic ambience, without the author needing to precisely specify which sound is played where the main features can include:  
         [0116]    1 When in a theme zone, a ‘server’ places sound content at random positions around the listener. Each content item remains stationary while playing.  
         [0117]    2 Zone areas can be defined by an arbitrary polygon.  
         [0118]    3 A defined number of sounds can be played at any one time. When a sound finishes a new sound is served.  
         [0119]    4 All sounds in a theme zone have the same roll-off characteristics.  
         [0120]    5 When the listener leaves the zone no new sounds are served. Existing sounds play until they finish.  
         [0121]    Other Objects Can Be Provided Including:  
         [0122]    1 Triggering trigger events based on time: absolute, or relative to start.  
         [0123]    2 System messages e.g. ‘Your batteries are flat—go home.’ 
         [0124]    3 Sleep mode/loiter mode e.g. the system prompts the user to keep moving.  
         [0125]    4 If no sound sources are present, a site wide theme zone is played.  
         [0126]    Rendering Tool  
         [0127]    The rendering tool renders the sounds and sound behaviours, and manages the GPS/compass input and output. It has a stop, play, and pause control, which allows the renderer to be reset for a new user. No specific constraints are placed on the implementation—which is largely dependent on the hardware being used.  
         [0128]    Software Structure  
         [0129]    This section is not prescriptive, and contains an example implementation of a combined authoring/rendering tool using Microsoft Visual C++ and MFC on a PC platform.  
         [0130]    Threading  
         [0131]    Three interacting threads are provided for the real time interactive operation of the system. These be defined as follows, with reference to FIG. 12:  
         [0132]    1 The GUI thread  120  controls the user interface, editing, and serialisation. This is where the authoring tool component of the software operates.  
         [0133]    2 The behaviour thread  122  is where the Rendering Tool component of the software operates. It determines when a sound is to play; manages the triggering architecture; and realises other sound behaviours, such as the script mover object.  
         [0134]    3 The virtualiser thread  124  performs binaural rendering of sounds under the control of the Behaviour Thread.  
         [0135]    The three threads  120 - 124  operate in an ordered priority sequence with virtualiser thread  124  having the highest priority, followed by behavious thread  122  and GUI thread  120 .  
         [0136]    Turning now to FIG. 16, there is illustrated schematically the example environment in which the authoring tool and rendering engine operate. The three threads  120 - 124  run within the authoring/rendering engine  161  and output a listeners position and location of active sound sources to a spatialization system  162  which also takes as its input a series of streamed audio sources  163  corresponding to the location of active sound sources. The spatialization system  162  binauralizes the streamed audio so as to locate it at a predetermined position around the listener in accordance with the difference between the listener&#39;s position and the location of active sound sources.  
         [0137]    The spatialization system  162  system can take many forms. For example, U.S. Standard application Ser. No. 08/893,848 which claims priority from Australian Provisional Application No. PO0996, both the contents of which are specifically incorporated by cross reference, discloses a system for rendering a B-formatted sound source in a head tracked environment at a particular location relative to a listener. Hence, if the audio tracks are stored in a B-format then such a system, suitably adapted, can be used to render the audio tracks. One example of where such a system is suitable is where the B-format part of the rendering to be done centrally, and the headtracking part (which is applied to the B-format signal to generate headphone signal) is done locally. B-field calculation can be expensive and may be done centrally. However, central computation incurs communication delays, and this may have the effect of introducing latency in position. The headtracking can be done locally because this is very sensitive to latency. Alternatively, Patent Cooperation Treaty Patent PCT/AU99/00242 discloses a system for headtracked processing for headtracked playback of audio and, in particular, in the presence of head movements. Such a system could be used as the rendering engine by rendering the audio track to a predetermined format (e.g. Dolby 5.1 channel surround) so as to have a predetermined location relative to a listener, and, in turn, utilising the system described in the PCT application to then provide for the localisation of an audio signal in the presence of head movements.  
         [0138]    In the further alternative, Patent Cooperation Treaty Patent PCT/AU99/00002 discloses a system for rendering audio such as Dolby 5.1 channel surround to a listener over headphones with suitable computational modifications. By locating a sound around a listener utilising panning of the sound source between virtual speakers and subsequently rendering the speakers utilising the aforementioned disclosure, it is again possible to spatialize a sound source around a listener.  
         [0139]    Obviously, other known techniques for spatializing sound over headphones could be utilised.  
         [0140]    Class Hierarchy  
         [0141]    Each object type is implemented using a C++ class. An example class hierarchy  130  is shown in FIG. 13. Each CSL objects contain methods for both the GUI Control process (used by the authoring tool), and the behaviour process (used by the rendering tool). The virtualiser is treated as a separate entity that is accessed by the behaviour thread via an audio API:  
         [0142]    1 CSLObject  132  is the base class, and contains much of the infrastructure required by the MFC document/view architecture. This class also implements the inheritance model described above.  
         [0143]    2 CSLPoint  134  and CSLRect  136  derive from CSLObject  132  and include methods for point objects (such as a sound source) and objects that cover an area (such as triggers).  
         [0144]    3 CSLScene  138  is a special case, and embodies the whole sonic landscapes Scene. All independent objects in a sonic landscapes scene are in fact children of a CSLScene.  
         [0145]    4 All other objects can be derived from CSLRect  136  and CSLPoint  134 , and contain member functions and variables to implement GUI and rendering functionality.  
         [0146]    Although, the skilled programmer would maintain a high degree of flexibility over the software design, example CSLObject member functions and variables are listed below:  
                             TABLE 1                           CSLObject Member Functions                Thread           Member Function   Usage   Explanation               AbsToRel   GUI +   Converts a position from absolute coordinates to           Behaviour   coordinates relative to an object&#39;s parent.       AddChild   GUI   Adds a child to the object. The behaviour thread               must be frozen using LockFlushBehaveThread               before this is called.       AddChildrenTo   GUI   Adds a child to a third party object. The behaviour               thread must be frozen using               LockFlushBehaveThread before this is called.       AddPropPages   GUI   Called to display the property page for an object               when it is double clicked in the GUI.       AddToParent   GUI   Informs a object who its parent is.       Behave   Behaviour   This is the main function called in the behaviour               thread. An object responds by realising it&#39;s               programmed behaviour e.g. a CSLScriptMover               will move an increment along its trajectory.               Behave is passed a reference to a CTrigState               object. This is used to communicate trigger ID               events between objects.       ChildToParent   GUI   Converts a position from coordinates relative to               the object&#39;s parent (child coordinate system) to               coordinates relative to the object&#39;s grand parent               (parent coordinate system).       Draw   GUI   Draws the GUI representation of the object into the               View. Called by CSLView       DrawLinks   GUI   Draws lines from the object to all its next of kin (i.e.               parent and children).       EnclosedByBitmap   GUI   Determines whether a given region is completely               enclosed by a bitmap. This is used to reduce               flicker when redrawing. For example, if an object is               invalidated, it is not necessary to paint the               invalidation region with the background colour if a               bitmap will be drawn into this region anyway.       GetAbsOrient   GUI +   Returns the object&#39;s absolute orientation e.g. for a           Behaviour   CSLListenter this is the direction the listener is               facing. The absolute orientation is the sum of the               relative orientation of itself, and all its ancestors.       GetAbsPos   GUI +   Returns the objects position in absolute world           Behaviour   coordinates (meters). This must be calculated               since an object only normally stores its position in               coordinates relative to its parent.       GetDeepBound   GUI   The deep bound is the bound in world coordinates               of the object and all its children. This corresponds               to a bounding rectangle (in meters) which               encloses the object and all its descendents.       GetDoc   GUI   Returns a pointer to the document the object               belongs to. The resulting pointer is generally used               to pass redraw hints to the document&#39;s Views.       GetExtraBoundLPDeep   GUI   Returns the bound of the object and its               descendents in logical coordinates. This               corresponds to the displayed size which is a               function of the physical size (meters), the current               zoom factor, and the extra size required to display               the object as an icon.       GetExtraBoundLPShallow   GUI   Returns the bound of the object in logical               coordinates. This corresponds to the displayed               size of the object, which is a function of its physical               size (meters), the current zoom factor, and the               extra size required to display the object as an icon.       GetHandleText   GUI   Returns a text string containing the object&#39;s               position. The View presents this information in the               main application window status panel.       GetKeyStatus   GUI +   Returns the status of the keyboard cursor keys.           Behaviour   Used by CSLKeyMover, to control the object&#39;s               position and orientation using the keyboard.       GetMoveHandle   GUI   Returns a flag indicating how the object will               respond to attempts to move it using the mouse.       GetOrient   GUI +   Returns the object&#39;s relative orientation. For           Behaviour   example, the bearing a CSLCompassMover               object reads from the digital compass hardware.       GetPos   GUI +   Returns the object&#39;s position relative to its parent.           Behaviour       GetSLMainWnd   GUI   Returns a pointer to the application&#39;s main               window. Used by the Behaviour thread to post               redraw hints to the GUI thread. These hints are               captured by CMainFrame.       HasParent   GUI   Checks to see whether a third party object is a               parent of this object.       HitTest   GUI   Determines whether the object should report itself               selected in response to a user mouse click.       InvalidateBehaveFlag   GUI +   Called to invalidate the object&#39;s behaviour flag.           Behaviour   The behaviour flag, mt_bBehaveInvalid, tells the               Behaviour Thread that an object&#39;s position or               orientation has been modified by the GUI thread.       InvalidateDeep   GUI   Invalidates the object&#39;s deep bound. This area is               then redrawn by the view.       InvalidateExpandedDeep   GUI   Invalidates an inflated version of the object&#39;s deep               bound. Used when the object has been moved in               the Behaviour thread, and the invalidation region               must be the superset of the old and the new               positions.       InvalidateLinksDeep   GUI   Invalidates the object&#39;s deep bound, and if               necessary, the line between the object and its               parent.       InvalidateLPDeep   GUI   Invalidates the object&#39;s deep bound. This area is               then redrawn by the view.       InvalidateLPShallow   GUI   Invalidates the object&#39;s shallow bound—which               does not include the object&#39;s descendents.       InvalidateMove   GUI   Invalidates an inflated version of the object&#39;s deep               bound. Used when the object has been moved in               the Behaviour thread, and the invalidation region               must be the superset of the old and the new               positions.       InvalidateParentDeep   GUI   Invalidates the deep bound of the object&#39;s parent.       InvalidateShallow   GUI   Invalidates the object&#39;s shallow bound. This does               not include the object&#39;s descendents.       KillAllChildren   GUI   Deletes all the object&#39;s descendents. The               behaviour thread must be frozen using               LockFlushBehaveThread before this is called.       MoveHandle   GUI   Instructs the object to move, and supplies a flag               specifying how the object is to move. The flag has               usually been previously extracted from the object               using GetMoveHandle.       Properties   GUI   Displays the object&#39;s properties. This is called by               the View after the user has double clicked on the               object. Note that the Behaviour thread is frozen               using LockFlushBehaveThread before this is               called.       RelToAbs   GUI +   Converts a position from coordinates relative to           Behaviour   the object&#39;s parent to absolute coordinates.       RemoveChild   GUI   Removes a third party object from the object&#39;s list               of children. Note that the Behaviour thread is               frozen using LockFlushBehaveThread before               this is called.       RemoveFromParent   GUI   Removes an third party object from the parent&#39;s               list of children. Note that the Behaviour thread is               frozen using LockFlushBehaveThread before               this is called.       Serialize   GUI   Serializes the object&#39;s state and the state of all it&#39;s               descendents.       SetAbsPos   GUI +   Sets the position of the object in absolute           Behaviour   coordinates.       SetComment   GUI   Sets the object&#39;s comment field.       SetName   GUI   Sets the object&#39;s name.       SetPos   GUI +   Sets the position of the object in coordinates           Behaviour   relative to the object&#39;s parent.       ShowLinksTo   GUI   Determines whether to draw links to the object&#39;s               children. Is used to prevent the drawing of links to               the scene node, CSLScene.       Update   GUI   Used to send a redraw hint to all the views that               belong to the object&#39;s document.       UpdateDeepBound   GUI   Tells the object to recalculate its deep bound. For               example, this is called if one of the object&#39;s               children has been moved.       UpdateShallowBound   GUI   Tells the object to recalculate its shallow bound.               For example, this is called if the object&#39;s size has               been changed.       UsePropPages   GUI   Called after an object&#39;s properties have been               changed this function applies the changes to the               object&#39;s internal state.                  
 
         [0147]    [0147]                             TABLE 2                           CSLObject Member Variables                Thread           Member Variable   Usage   Notes               m_colDraw   GUI   Stores the colour the object should be drawn in.       m_frDeepBound   GUI   Stores the object&#39;s deep bound.       m_frShallowBound   GUI   Stores the object&#39;s shallow bound.       m_listChild   GUI +   Stores the object&#39;s list of children. Note: this list is           Behaviour   not thread safe. Thread synchronisation is               achieved by: only altering this list in the GUI               thread; and ensuring the Behaviour thread is first               frozen using LockFlushBehaveThread.       m_pParent   GUI +   This is accessed in both threads, but only modified           Behaviour   in the GUI thread when the Behaviour thread is               frozen using LockFlushBehav Thread.       m_propObject   GUI   This is used to create the object&#39;s property window               which is displayed when the object is double               clicked in the GUI.       m_sComment   GUI   Stores the object&#39;s comment.       m_sName   GUI   Stores the object&#39;s name.       mt_bBehaveInvalid   GUI +   An important multi threaded flag used by the GUI           Behaviour   thread to indicate to the Behaviour Thread that an               object&#39;s position or orientation has changed. For               example, is a listener&#39;s position is changed in the               GUI thread (by using the mouse) the flag is set,               and the Behaviour thread responds by informing               the virtualiser thread of the change.                    
         [0148]    It should be noted that there are a limited number of variables are designed to be simultaneously read and written to by the GUI and behaviour threads. These are identified with the mt_prefix e.g. mt_fpPos. These variables are only ever accessed through thread safe access functions e.g. SetPos, SetOrient, SetRectPos, SetRotateKey, SetMoveKey, and InvalidateBehaveFlag.  
         [0149]    Some member functions are called (by the GUI thread) when the Behaviour Thread has been stopped using CSLDoc::LockFlushBehaveThread. Examples are Serialize, AddChild, AddChildrenTo and UsePropPages. This simplifies the multi-threaded design of these functions.  
         [0150]    The behaviour thread is invoked using CSLDoc::InitBehaveThread and its top level is CSLDoc::BehaveThreadFunc. To simplify the multi-threaded design of the software, the behaviour thread only accesses a limited number of variables. More complicated operations are achieved by posting messages to the GUI thread using ::PostMessage. For example, when CSLCompassMover detects a new compass orientation this can be stored directly (in the behaviour thread) using SetOrient. However all the GUI redrawing is performed in the GUI thread in response to a HINT_SLOBJECT_NEWORIENT hint.  
         [0151]    The system can use three types of coordinates: world coordinates, logical coordinates and device coordinates. World coordinates correspond to real sizes in meters. Logical coordinates are an intermediate coordinate system that is independent of display medium device coordinates are specific to the display medium, and are generally in pixels. Two common device media used by SLEdit are the computer screen and the printed page.  
         [0152]    In the following, two example scenarios illustrating the working of preferred embodiments of the present invention will be described with reference to FIGS. 14 and 15.  
         [0153]    Turning initially to FIG. 14, there is illustrated a person  200  walking along a shop-front window  202 . The person is carrying a mobile phone  204 . The owner of the shop associated with the shop-front window  202  has created a sonic landscape scene data, more particularly a special offer voice message to be presented to the person  200  whilst walking within a predetermined area  206  in front of the shop-front window  202 .  
         [0154]    In this scenario, the mobile phone  204  comprises a global positioning system (GPS) system  208  by way of which the position of the phone  204  can be traced by a rendering tool subscriber system  201  to which the owner of the shop associated with the shop-front window  202  has submitted the created sonic landscape scene data. Accordingly, once the person  200  (i.e. the mobile phone  204 ) enters into the area  206 , which has been defined within a geo-space on an authoring tool  203  under operation by the subscriber rendering tool, the special offer voice message is automatically presented to the person  200  through an automated call to the mobile phone  204  of the person  200 .  
         [0155]    Turning now to FIG. 15, in another scenario, a person  300  walks around a park  302 . The person  300  is carrying a combined authoring and rendering tool  304 . At a particular landmark  306 , the person  300  decides to leave a voice tag to effect the playing of a voice message associated with the landmark  306  to another person  308 , who in turn also carries a combined authoring and rendering tool  304 . The relevant sonic landscape scene data created by person  300  is communicated to a server  312  via wireless communication.  
         [0156]    The authoring and rendering tools  304  comprise a speaker, through which the voice tag created for the particular landmark  306  by person  300  can be displayed to the person  308 . When the person  308  (or any other person carrying a suitable authoring and rendering tool  304 ) enters a created triggering zone  310  around the landmark  306 , the authoring and rendering tool  304  will retrieve the stored sonic landscape scene data from the server  312 , and the voice tag is then displayed to the person  308  through the speaker of the authoring and rendering tool  304 . Each of the authoring and rendering tools  304  incorporates a GPS unit to facilitate obtaining and processing of the relevant positioning data.  
         [0157]    It will be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the present invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.  
         [0158]    For example, it will be appreciated that whilst in the preferred embodiment an authoring tool and rendering tool for creation of an audio landscape has been described, the present invention is not limited to an audio landscape. Rather, the present invention readily extends to the creation of a visual landscape, ie to the assigning of geo-spatial position to eg image data for presentation to an exposee. Furthermore, the present invention extends to creating any presentation susceptible to being sensed by an exposee, including eg to smells, to temperature, to humidity, to wind, to pressure, and to light.  
         [0159]    In the claims that follow and in the summary of the invention, except where the context requires otherwise due to express language or necessary implication, the word “comprising” is used in the sense of “including”, ie the features specified may be associated with further features in various embodiments of the invention.