Collision Management in Augmented Reality Scene Description
Patent Information
- Application Number
- JP2024553593
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2022-03-14
- Filing Date
- 2023-03-06
- Publication Date
- 2025-03-13
Smart Images
Figure 2025507120000001_ABST
Abstract
Description
[Technical field]
[0001] The present principles relate generally to the field of augmented reality scene description and augmented reality rendering. In particular, the present principles relate to describing management of collisions between objects of a scene. This document is also understood in the context of formatting and playback of augmented reality applications when rendered on an end user device, such as a mobile device or a Head-Mounted Display (HMD). [Background technology]
[0002] This section is intended to introduce the reader to various aspects of art that may be related to various aspects of the present principles that are described and / or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present principles. As such, it should be understood that these statements are to be read in this light, and not as admissions of prior art.
[0003] Extended reality (XR) is a technology that enables interactive experiences in which real-world environments and / or video content are augmented by virtual content that may be defined across multiple sensory modalities, including vision, hearing, touch, etc. During the runtime of an application, virtual content (e.g., 3D content or audio / video files) is rendered in real-time in a manner that is consistent with the user context (environment, viewpoint, device, etc.). Scene graphs (such as those proposed by Khronos / gLTF, and such as the MPEG scene description format or its extensions defined by Apple / USDZ) are a possible way to represent the rendered content. They combine a declarative description of the scene structure linking real-world objects and virtual objects on the one hand, and a binary representation of the virtual content on the other. The scene description framework ensures that the timed media and the corresponding related virtual content are available at all times during the rendering of the application. Scene descriptions can also carry scene-level data that describes how scene objects can interact during the runtime of an immersive XR experience. Managing collisions between objects (real and / or virtual objects, the user being a real object) requires the use of physics engines, which are memory and processing resource intensive. Existing XR scene description formats lack a mechanism to exploit different kinds of collision behaviors for memory and processing resource management. Summary of the Invention
[0004] The following presents a simplified summary of the present principles to provide a basic understanding of some aspects of the present principles. This summary is not an extensive overview of the present principles. It is not intended to identify key or critical elements of the present principles. The following summary merely presents some aspects of the present principles in a simplified form as a prelude to the more detailed description provided below.
[0005] The present principles relate to a method for starting an augmented reality application that uses a physics engine. The method includes obtaining a description of an augmented reality scene. According to the present principles, the description includes a scene graph, and at least two nodes of the scene graph include collision information. The scene graph includes at least two such nodes, since a collision occurs between at least two objects described in such nodes. The collision information includes a first Boolean value indicating whether the object described in the node is static or not, mesh information, a second Boolean value indicating whether the physics of the object described in the node are simulated or not, and, provided that the second Boolean value is true, physics parameters and material information. The method then includes, for a node of the scene graph that includes the collision information, initializing a physics engine for collision detection using the first Boolean value and the mesh information. Provided that the second Boolean value is true, the method further includes initializing a physics engine for physics simulation using the physics parameters and material information. Once the physics engine is initialized with a configuration and parameters that allow saving memory and processing resources, the augmented reality application is started.
[0006] The present principles also relate to an augmented reality rendering device comprising a memory associated with a processor configured to perform the above method.
[0007] The present principles also relate to a data stream carrying data representing a description of an augmented reality scene, the description comprising: -A scene graph that links the nodes; at least two nodes of a scene graph comprising collision information, the collision information comprising: a first Boolean value indicating whether the object described in the node is static or not, and a second Boolean value indicating whether to simulate mesh information and physical properties of the object described in the node; ·Physical body parameters and material information, provided that the second Boolean value is true. [Brief description of the drawings]
[0008] The present disclosure will be better understood, and other particular features and advantages will become apparent, on reading the following description, in which reference is made to the accompanying drawings, in which: [Figure 1] FIG. 1 illustrates an exemplary graph of an augmented reality scene description in accordance with the present principles. [Diagram 2] FIG. 2 shows a non-limiting example of an augmented reality scene that includes real and virtual objects. [Diagram 3] FIG. 3 illustrates an example architecture of an XR processing engine that may be configured to implement the method described in connection with FIG. 5 in accordance with the present principles. [Figure 4] FIG. 4 illustrates an example of one embodiment of the syntax of a data stream for encoding an augmented reality scene description in accordance with the present principles. [Diagram 5] FIG. 5 illustrates a method for initiating an augmented reality application involving a collision event in accordance with the present principles. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0009] The present principles are described more fully below with reference to the accompanying drawings, in which examples of the present principles are shown. However, the present principles may be embodied in many alternative forms and should not be construed as being limited to the embodiments set forth herein. Thus, while the present principles are susceptible to various modifications and alternative forms, specific examples thereof are shown by way of example in the drawings and are described in detail herein. However, it is to be understood that there is no intention to limit the present principles to the particular forms disclosed, but on the contrary, the present disclosure is intended to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present principles as defined by the appended claims.
[0010] The terms used herein are for the purpose of describing particular embodiments only and are not intended to limit the present principles. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms unless the context clearly indicates otherwise. It will be further understood that as used herein, the terms "comprises," "comprising," "includes," and / or "including" specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. Furthermore, when an element is referred to as "responsive to" or "connected to" another element, it may be directly responsive to or connected to the other element, or intervening elements may be present. In contrast, when an element is referred to as "directly responsive to" or "directly connected to" another element, there are no intervening elements. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items, and may be abbreviated as " / ".
[0011] In this specification, terms such as first, second, etc. may be used to describe various elements, but it is understood that these elements should not be limited by these terms. These terms are used only to distinguish one element from another element. For example, a first element can be called a second element, and similarly, a second element can be called a first element without departing from the teachings of the present principles.
[0012] Some of the figures include arrows on communication paths to indicate a primary direction of communication, however, it should be understood that communication may occur in the opposite direction to that depicted arrow.
[0013] Some examples are described with reference to block diagrams and operational flowcharts, in which each block represents circuit elements, modules, or portions of code, each block including one or more executable instructions for implementing a specified logical function. It should also be noted that in other implementations, the functions noted in the blocks may occur out of the order noted. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may be executed in the reverse order, depending on the functionality involved.
[0014] The use of "by one example" or "in one example" herein means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one implementation of the present principles. The appearances of the phrases "by one example" or "in one example" in various places in the specification are not necessarily all referring to the same example, and are not necessarily mutually exclusive of other examples in separate or alternative embodiments.
[0015] Reference signs appearing in the claims are merely illustrative and shall have no limiting effect on the scope of the claims. Although not expressly described, the embodiments and variations may be used in any combination or subcombination.
[0016] FIG. 1 shows an exemplary graph 10 of an augmented reality scene description. In this example, the scene graph may include descriptions of real objects, e.g., a "flat horizontal surface" (which may be a table or a road), and descriptions of virtual objects 12, e.g., an animation of a car. The scene description is organized as an array 10 of nodes. Nodes can be linked to child nodes to form a scene structure 11. Nodes can carry descriptions of real objects (e.g., semantic descriptions) or descriptions of virtual objects. In the example of FIG. 1, node 101 describes a virtual camera located in the 3D volume of the XR application. Node 102 describes a virtual car and includes an index of a representation of the car, e.g., an index in an array of 3D meshes. The scene description may include multiple arrays that include descriptions of various aspects of the scene, e.g., an array that includes instructions for several animations, an array that includes meshes of several objects, or an array that includes material descriptions. Node 103 is a child of node 102 and includes a description of one wheel of the car. Similarly, it includes an index to the 3D mesh of the wheel. The same 3D mesh may be used for several objects in a 3D scene because the scale, location and orientation of the objects are described in the scene nodes. The scene graph 10 also contains nodes that are descriptions of the spatial relationships between real and virtual objects.
[0017] XR applications are varied and may apply to different contexts and real or virtual environments. For example, in an industrial XR application, a virtual 3D content item (e.g., part A of an engine) is displayed when a reference object (part B of an engine) in the real environment is detected by a camera mounted on a head-mounted display device. The 3D content item is positioned in the real world at a position and scale defined relative to the detected reference object. Similarly, actions on virtual objects may be performed when a collision between real or virtual objects is detected, i.e., between two real objects, two virtual objects, or one real object and one virtual object.
[0018] For example, in an XR application for interior design, the color of the displayed virtual furniture changes when the user touches a virtual control object or when the user touches a real table. In another application, some audio files may start playing when two moving displayed virtual objects collide. In another example, an advertising jingle file may play when a user grabs a given soda can in the real environment. However, detecting collisions (or contacts) between real or virtual objects and rendering realistic reactions of the virtual objects requires the use of physics engines, which are memory and processing resource intensive. Therefore, in order to optimize the use of physics engines, it is important to have a scene description that accurately describes different kinds of behaviors linked to collisions. Such an XR scene description format is provided herein in accordance with the present principles.
[0019] XR applications may augment the real environment with video content rather than the real world. The video is displayed on a rendering device, and virtual objects described in the node tree are overlaid when timed events are detected in the video. In such a context, the node tree only contains descriptions of virtual objects.
[0020] Figure 2 shows a non-limiting example of an augmented reality scene 20 including real and virtual objects 21-25. The XR scene description may include behavior data at the scene level. Behavior is associated with virtual objects enabling run-time interactivity for a user-specific XR experience. As with all elements of the XR scene description, behavior is time-evolving and is updated by the scene description update mechanism.
[0021] The behavior is described at the scene level in the scene description, a trigger, which defines the conditions that must be met for its activation; - trigger control parameters that define the logical operations between triggers for the application of actions; - an action to be processed when the trigger is fired according to the trigger control parameters; action control parameters that define the order in which the actions are executed; a priority number that allows the selection of the behavior with the highest priority in case of simultaneous conflicts between several behaviors on the same virtual object; - an optional interrupt action that specifies how to terminate this behavior when it is no longer defined in the scene description update, e.g., when the object involved does not belong to the new scene or when the behavior is no longer relevant to this current media (e.g. audio or video) sequence.
[0022] In such a scene description, collisions are handled at the scene level by collision triggers, which are activated when a collision is detected between two objects described by two nodes referenced in the description.
[0023] In the example scenario of the scene in FIG. - The objects described by nodes 21, 22 and 24 are collision capable nodes. Therefore, they must be managed by a physics simulation engine. They can be referenced by collision triggers. According to the present principles, the XR scene description identifies this first category of objects so that the rendering device can instantiate a physics engine for collision detection and physics simulation. - Node 23 objects are also collidable nodes, but behave as "ghost" objects, whose movement is not managed by a physics simulation engine. Typically, another object (such as 21 or 22) can pass through an object described by node 23 without physical interaction. For a scene author, it is useful to be able to introduce this kind of object into a scene. Indeed, node 23 objects only require a physics engine for collision detection and do not require the use of physics simulation for themselves and other objects, saving memory and processing resources of the XR rendering device. According to the present principles, the XR scene description identifies this second category of objects, so that the rendering device can instantiate a physics engine only for collision detection. Ghost objects can be referenced by collision triggers. - The object of node 25 is a solid object, but the scene is constructed by the content creator in such a way that this object does not collide with another object in every possible development of the scenario. For example, it may be an object that is visible but far away from the volume of interaction, and no moving object can approach it. For the scene creator, it is useful to be able to introduce this kind of object into the scene. In fact, the object of node 25 does not require the use of a physics engine at all, saving memory and processing resources of the XR rendering device. According to the present principles, the XR scene description identifies this third category of object, and thus the rendering device can prevent the object from being managed by the physics engine.
[0024] The example scenario of Figure 2 may include the following behaviors: A first behavior includes a single trigger that is activated by a collision between objects at nodes 21 and 22. When this single trigger is activated, for example, the object at node 25 turns red. A second behavior includes a single trigger that is activated by a collision between objects at nodes 21 and 23 (i.e., ghost objects). When this single trigger is activated, for example, the object at node 25 turns green.
[0025] In accordance with the present principles, complementary to the scene level behavior, node level information indicates whether a node is a collidable node. Possible semantics of this information are shown in the table below. In this embodiment, the physical material parameters are provided as a reference to the physical material array described above. In another embodiment, the physical material parameters may be written to the node.
[0026] [Table 1]
[0027] The collider mesh is a mesh (which may be a simplified mesh) used for collision detection. For example, a box, sphere or capsule can be used to accelerate collision detection. The fields "useGravity" and "mass" are physics parameters. Advanced parameters may be envisaged to further control the physics simulation, such as a "freeze rotation" boolean indicating if the physics simulation should modify the rotation of the object, a "maximum angular velocity" value limiting the angular velocity in radians / second, and / or a "maximum depenetration velocity" value limiting the speed of the object when going out of a collision state.
[0028] A physical material (described in an array of physical material items or directly at the node level) may include the following parameters:
[0029] [Table 2]
[0030] The parameters of a given node for collision detection according to the present principles apply to the children of this given node, therefore the parents and children of a given node do not contain the fields listed in the first table above.
[0031] In the exemplary scenario of FIG. 2, nodes 21, 22, 23, and 24 contain the information listed in the first table according to the present principles, making them collision-capable nodes. Thus, they can be referenced by two collision triggers. Each of these nodes has its specific physics parameters defined according to the present principles. For example, node 23 has an allowOverlap boolean that is true, allowing its overlap by any other object to allow for "ghost" behavior. Node 24 has a useGravity boolean that is false, allowing for ground plane behavior in the physics simulation (ground does not fall). A gravity acceleration vector defines the direction and force of gravity and shall be defined for the physics simulation. The gravity acceleration vector is expressed in meters per second per second. The default value may be earth gravity (0.0,-9.81,0.0), where y is the vertical axis. In a first embodiment, the gravity vector is defined at the scene level. In another embodiment, the gravity vector is defined at the node level (e.g., allowing for scenarios where different objects do not fall at the same speed, to simulate friction at low processing resource cost). According to the present principles, having collision parameters at the scene level allows for defining additional parameters, such as default values for some physics parameters.
[0032] Fig. 3 shows an example architecture of an XR processing engine 30 that may be configured to implement the method described in relation to Fig. 5. The devices according to the architecture of Fig. 3 are linked with other devices via their bus 31 and / or via I / O interfaces 36.
[0033] The device 30 includes the following elements coupled together by a data and address bus 31: a microprocessor 32 (or CPU), for example a DSP (or Digital Signal Processor); - ROM (or read only memory) 33; a RAM (or Random Access Memory) 34; a storage interface 35; an I / O interface 36 for receiving data to be transmitted from an application; - a power source, e.g. a battery, which is not shown in FIG.
[0034] According to one example, the power source is external to the device. In each of the mentioned memories, the word "register" used herein may correspond to a small volume area (a few bits) or a very large area (e.g., the entire program or a large amount of received or decoded data). The ROM 33 includes at least the programs and parameters. The ROM 33 can store algorithms and instructions for performing the techniques according to the present principles. When switched on, the CPU 32 uploads the program in the RAM and executes the corresponding instructions.
[0035] The RAM 34 contains, in registers, the programs executed by the CPU 32 and uploaded after switching on the device 30, the input data in registers, intermediate data for different states of the methods in registers, and other variables used for the execution of the methods in registers.
[0036] The implementations described herein may be realized in, for example, a method or process, an apparatus, a computer program product, a data stream, or a signal. Even if discussed in the context of only a single form of implementation (e.g., discussed only as a method or device), the implementation of the discussed features may also be implemented in other forms (e.g., a program). The apparatus may be implemented in, for example, appropriate hardware, software, and firmware. The method may be performed in an apparatus such as a processor, which generally refers to a processing device, including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. Processors also include communication devices, such as, for example, computers, cellular phones, portable / personal digital assistants ("PDAs"), and other devices that facilitate communication of information between end users.
[0037] The device 30 is linked, for example, via a bus 31 to a set of sensors 37 and a set of rendering devices 38. The sensors 37 may for example be a camera, a microphone, a temperature sensor, an inertial measurement unit, a GPS, a humidity measurement sensor, an IR or UV light sensor, or a wind sensor. The rendering devices 38 may for example be a display, a speaker, a vibrator, heat, a fan, etc.
[0038] According to an embodiment, the device 30 is configured to implement the method according to the present principles described in relation to FIG. -Mobile devices, -Communication devices, -Gaming devices, - a tablet (or tablet computer), -Laptop, -Still camera, -Video camera, The present invention belongs to a set including:
[0039] FIG. 4 shows an example of an embodiment of a syntax for a data stream encoding an augmented reality scene description according to the present principles. FIG. 4 shows an exemplary structure 4 of an XR scene description. The structure consists of containers that organize the stream in independent elements of the syntax. The structure may include a header section 41 that is a set of data common to all syntax elements of the stream. For example, the header section includes some of the metadata about the syntax elements, explaining the nature and role of each of them. The structure also includes a payload that includes a syntax element 42 and a syntax element 43. The syntax element 42 includes data representing the media content item described in the node of the scene graph associated with the virtual element. Images, meshes, and other raw data may be compressed according to a compression method. The syntax element 43 is part of the payload of the data stream and includes data encoding the scene description as described according to the present principles.
[0040] FIG. 5 illustrates a method 50 for starting an augmented reality application including a collision event according to the present principles. In step 51, a scene description is obtained. According to the present principles, the scene description includes behavior information including collision triggers at the scene level. According to the present principles, the nodes of the scene graph of the scene description may include collision information as described in the first table of this document in connection with FIG. 2. The scene description may include physics parameters (e.g., gravity parameters) at the scene level. In step 52, the physics engine of the application is started and initialized with these physics parameters. In step 53, the scene graph of the scene description is analyzed to distinguish three categories of nodes. Nodes that do not include collision information according to the present principles are not linked to the physics engine, i.e., the physics engine does not manage the simulation of their collisions and their physical properties. Nodes that include collision information according to the present principles are linked to the physics engine for management of collisions in step 53. For each of these nodes, the physics engine is initialized with a Boolean value indicating whether the object is movable or always stationary, and a mesh (e.g., stored in a mesh array and referenced by an index in the collision information of the node) that is used to detect collisions. Additional parameters included in the collision information of a given node can be used to initialize the collision detection features of the physics engine. In step 54, nodes of the scene graph with collision information having a Boolean value (herein referred to as "allowOverlap") indicating whether the object should be considered by the physics simulation set to true are linked to the physics engine for the physics simulation features of the physics engine. For such nodes, the physics engine is initialized with the physics parameters included in the collision information of the node (e.g., "useGravity" Boolean, mass or velocity parameters) and material descriptions (which may be stored in a material table or described in the node). In step 55, once the physics engine has been initialized with only the relevant object properties, the XR application is started.
[0041] An example syntax for the scene description of FIG. 2 is provided below as an extension to the MPEG-I scene description.
[0042] At the scene level, a single interactivity behavior is defined, consisting of one collision trigger between the first and second nodes, and an activate action that enables the third node. A lunar gravitational acceleration vector (0,-1.625,0) is defined. At the node level, the first node is a collidable dynamic (i.e., static=false) object that uses physics simulation with an associated physics material that corresponds to the first material in the material array. The second node is a collidable static object without physics simulation (i.e., allowOverlap=true). The third node is a non-collidable object that is ignored by the physics engine. At the material level, the first material has the physics parameters of springiness (0.8) and roughness (0.1).
[0043] [Table 3-1]
[0044] [Table 3-2]
[0045] [Table 3-3]
[0046] [Table 3-4]
[0047] The implementations described herein may be realized, for example, in a method or process, an apparatus, a computer program product, a data stream, or a signal. Even if discussed only in the context of a single form of implementation (e.g., discussed only as a method or device), the implementation of the discussed features may also be implemented in other forms (e.g., a program). The apparatus may be implemented, for example, in appropriate hardware, software, and firmware. The method may be performed in an apparatus such as a processor, which generally refers to a processing device, including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. Processors also include communication devices, such as, for example, smartphones, tablets, computers, mobile phones, handheld / personal digital assistants ("PDAs"), and other devices that facilitate communication of information between end users.
[0048] Implementations of the various processes and features described herein may be embodied in a variety of different equipment or applications, particularly equipment or applications associated with, for example, data encoding, data decoding, view generation, texture processing, and other processing of images and associated texture and / or depth information. Examples of such equipment include encoders, decoders, post-processors that process output from decoders, pre-processors that provide input to encoders, video coders, video decoders, video codecs, web servers, set-top boxes, laptops, personal computers, mobile phones, PDAs, and other communication devices. As should be clear, the equipment may be mobile and installed in a mobile vehicle.
[0049] In addition, the method may be implemented by instructions executed by a processor, and such instructions (and / or data values produced by the implementation) may be stored on a processor-readable medium, such as, for example, an integrated circuit, a software carrier, or other storage device, such as, for example, a hard disk, a compact diskette ("CD"), an optical disk (such as, for example, a DVD, often referred to as a digital versatile disk or digital video disk), a random access memory ("RAM"), or a read-only memory ("ROM"). The instructions may form an application program tangibly embodied on the processor-readable medium. The instructions may be, for example, hardware, firmware, software, or a combination. The instructions may be found, for example, in an operating system, a separate application, or a combination of the two. Thus, a processor may be characterized as both, for example, a device configured to execute a process and a device that includes a processor-readable medium (such as a storage device) having instructions for executing a process. Furthermore, the processor-readable medium may store data values produced by the implementation in addition to or in place of instructions.
[0050] As will be apparent to one of ordinary skill in the art, implementations may result in a variety of signals formatted to carry information that may be, for example, stored or transmitted. Information may include, for example, instructions for performing a method or data generated by one of the described implementations. For example, a signal may be formatted to carry as data rules for writing or reading syntax of the described embodiments, or to carry as data the actual syntax values written by the described embodiments. Such a signal may be formatted, for example, as an electromagnetic wave (e.g., using the radio frequency portion of the spectrum) or as a baseband signal. Formatting may include, for example, encoding a data stream and modulating a carrier wave with the encoded data stream. The information that the signal carries may be, for example, analog or digital information. The signal may be transmitted by a variety of different wired or wireless links, as is well known. The signal may be stored in a processor-readable medium.
[0051] A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made. For example, elements of different implementations can be combined, supplemented, modified, or deleted to produce other implementations. In addition, those skilled in the art will understand that other structures and processes can be substituted for those disclosed, and the resulting implementations perform at least substantially the same functions in at least substantially the same manner to achieve at least substantially the same results as the disclosed implementations. Thus, these and other implementations are contemplated by the present application.
Claims
1. 1. A method for initiating an augmented reality application using a physics engine, comprising: - obtaining a description of an augmented reality scene comprising a scene graph linking nodes, at least two nodes of said scene graph comprising collision information, said collision information comprising: a first Boolean value indicating whether the object described in the node is static or not, mesh information and a second Boolean value indicating whether to simulate physical properties of the object described in the node; - obtaining, if the second Boolean value is true, physical body parameters and material information; - for a node of the scene graph containing collision information, initializing the physics engine for collision detection using the first Boolean value and the mesh information, and, if the second Boolean value is true, initializing the physics engine for physics property simulation using the physical body parameters and the material information; - starting said augmented reality application; The method includes:
2. The method of claim 1 , wherein the mesh information is an index into a mesh table of the description.
3. The method of claim 1 , wherein the material information is an index into a material table of the description.
4. The method of claim 1 , wherein the material information is described in the collision information.
5. 1. A device for initiating an augmented reality application using a physics engine, the device comprising: a memory; and a processor, the processor comprising: - obtaining a description of an augmented reality scene comprising a scene graph linking nodes, at least two nodes of said scene graph comprising collision information, said collision information comprising: a first Boolean value indicating whether the object described in the node is static or not, mesh information and a second Boolean value indicating whether to simulate physical properties of the object described in the node; - obtaining, if the second Boolean value is true, physical body parameters and material information; - for a node of the scene graph containing collision information, initializing the physics engine for collision detection using the first Boolean value and the mesh information, and, if the second Boolean value is true, initializing the physics engine for physics property simulation using the physical body parameters and the material information; - starting said augmented reality application; A device that is configured to:
6. The device of claim 5 , wherein the mesh information is an index into a mesh table of the description.
7. The device of claim 5 , wherein the material information is an index into a material table of the description.
8. The device of claim 5 , wherein the material information is included in the collision information.
9. 1. A data stream carrying data representing a description of an augmented reality scene, said description comprising: - a scene graph linking the nodes; at least two nodes of said scene graph containing collision information, said collision information comprising: a first Boolean value indicating whether the object described in the node is static or not, mesh information and a second Boolean value indicating whether to simulate physical properties of the object described in the node; - physical body parameters and material information, provided that the second Boolean value is true; A data stream including:
10. 10. The data stream of claim 9, wherein the mesh information is an index into a mesh table of the description.
11. 10. The data stream of claim 9, wherein the material information is an index into a material table of the description.
12. The data stream of claim 9 , wherein the material information is described in the collision information.