Proximity triggering in scene description.

Abstract

In one implementation, we propose to extend the scene description by specifying a proximity criterion at the node level for proximity triggering. For example, the scene description extension at the node level includes one or more of: (1) two weight parameters indicating the importance of proximity to the node, (2) a simplified mesh attached to the node mesh for the proximity calculation and / or a reference to a proximity frustum defining the capture volume, (3) a Boolean parameter indicating whether occlusion is considered, (4) a Boolean parameter indicating whether geospatial coordinates are used, and (5) geospatial coordinates.

Description

[Technical field]

[0001] The present embodiments relate generally to extended reality scene description and extended reality scene rendering. [Background technology]

[0002] 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 (e.g., such as those proposed by Khronos / glTF and its extensions defined by, e.g., MPEG scene description format or 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. The scene description can also carry scene-level data that describes how the user can interact with the scene objects at runtime of the immersive XR experience. Summary of the Invention

[0003] According to one embodiment, a method is provided that includes obtaining at least one parameter at a node level from a description of an extended reality scene, the parameter being used to indicate that an object corresponding to the node is in a state of proximity to another object corresponding to another node, and initiating a trigger for an action in response to the object being in a state of proximity to the other object.

[0004] According to another embodiment, an apparatus is provided that includes one or more processors and at least one memory coupled to the one or more processors, wherein the one or more processors are configured to obtain, from a description of the extended reality scene, at least one parameter at a node level used to indicate that an object corresponding to the node is in a state of proximity to another object corresponding to another node, and to initiate a trigger for an action in response to the object being in a state of proximity to the other object.

[0005] One or more embodiments also provide a computer program comprising instructions that, when executed by one or more processors, cause the one or more processors to perform a method according to any of the embodiments described herein. One or more of the present embodiments also provide a computer-readable storage medium having stored thereon instructions for processing a scene description according to the methods described herein.

[0006] One or more embodiments also provide a computer-readable storage medium that stores video data generated by the methods described herein. One or more embodiments also provide methods and apparatus for transmitting or receiving video data generated by the methods described herein. [Brief description of the drawings]

[0007] [Figure 1] FIG. 1 illustrates an example architecture of an XR processing engine. [Diagram 2]FIG. 2 shows an example of the syntax of a data stream for encoding an extended reality scene description. [Diagram 3] FIG. 3 shows an example graph of an extended reality scene description. [Figure 4] FIG. 4 shows an example of an extended reality scene description that includes behavior data stored at the scene level that describes how a user can interact with the scene objects described at the node level during runtime of an immersive XR experience. [Diagram 5] FIG. 5 illustrates proximity triggering at the scene level. [Figure 6] FIG. 6 illustrates occlusion. [Figure 7] FIG. 7 illustrates a proximity frustum. [Figure 8] FIG. 8 illustrates a proximity trigger (untriggered) with a frustum. [Figure 9] FIG. 9 illustrates another proximity trigger (untriggered) with a frustum. [Figure 10] FIG. 10 illustrates a proximity trigger (triggered) with a frustum. [Figure 11] FIG. 11 illustrates a proximity trigger with a specific mesh. [Figure 12] FIG. 12 illustrates that the thresholds min and max are scaled. [Figure 13] FIG. 13 illustrates how a glTF file is parsed and processed at runtime according to one embodiment. [Figure 14] FIG. 14 illustrates a method for processing glTF files at runtime with occlusion according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] Various XR applications may apply to different contexts and real or virtual environments. For example, in an industrial XR application, a virtual 3D content item (e.g., engine part A) is displayed when a reference object (engine part B) 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.

[0009] For example, in an XR application for interior design, a 3D model of a piece of furniture is displayed when a given image from a catalog is detected in the input camera view. The 3D content is positioned in the real world at a position and scale defined relative to the detected reference image. In another application, some audio file may start playing when the user enters an area close to a church (either real or virtually rendered in an extended reality environment). In another example, an advertising jingle file may be played when the user sees a given can of soda water in the real environment. In an outdoor gaming application, different virtual characters may appear depending on the semantics of the scenery observed by the user. For example, a bird character is suitable for a tree, so if the XR device's sensor detects a real object described by the semantic label "tree", a bird flying around the tree may be added. In a companion application implemented by smart glasses, a car noise may be emitted in the user's headset when a car is detected in the field of view of the user camera to alert the user to a potential danger. Furthermore, the sound may be spatialized to make it come from the direction where the car was detected.

[0010] XR applications can also augment the real environment with video content instead: the video is displayed on a rendering device, and the 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 the virtual objects.

[0011] 1 shows an example architecture of an XR processing engine 130 that can be configured to implement the methods described herein. Devices according to the architecture of FIG. 1 are linked with other devices via their bus 131 and / or via I / O interfaces 136.

[0012] Device 130 includes the following elements linked together by a data and address bus 131: a microprocessor 132 (or CPU), for example a DSP (or Digital Signal Processor); -ROM (or read only memory) 133; RAM (or Random Access Memory) 134; and a storage interface 135; and an I / O interface 136 for receiving data to be transmitted from an application; - a power source, for example a battery (not shown in FIG. 1);

[0013] According to one example, the power source is external to the device. In each of the mentioned memories, the word "register" used in this specification may correspond to a small capacity 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 133 includes at least the programs and parameters. The ROM 133 can store algorithms and instructions for performing the techniques according to the present principles. When switched on, the CPU 132 uploads the program in the RAM and executes the corresponding instructions.

[0014] The RAM 134 contains, in registers, the programs executed by the CPU 132 and uploaded after switching on the device 130, the input data in the registers, intermediate data for different states of the methods in the registers, and other variables used for the execution of the methods in the registers.

[0015] Device 130 is linked, for example, via bus 131 to a set of sensors 137 and a set of rendering devices 138. Sensors 137 may be, for example, 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. Rendering devices 138 may be, for example, a display, a speaker, a vibrator, heat, a fan, etc.

[0016] According to an embodiment, the device 130 is configured to perform a method according to the present principles, and -Mobile devices, -Communication devices, -Gaming devices, - a tablet (or tablet computer), -Laptop, -Still camera, - Camcorder, belonging to the set including.

[0017] In XR applications, scene descriptions are used to combine an explicit, easily parsed description of the scene structure with some binary representation of the media content. FIG. 2 shows an example of a syntax for a data stream encoding an extended reality scene description. FIG. 2 shows an example structure 210 of an XR scene description. The structure is in a container that organizes the stream in separate elements of the syntax. The structure may include a header section 220, which 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 syntax elements 230 and syntax elements 240. The syntax elements 230 include data representing the media content items described in the nodes of the scene graph associated with the virtual elements. Images, meshes, and other raw data may be compressed according to a compression method. The syntax elements 240 are part of the payload of the data stream and include data encoding the scene description as described by the present principles.

[0018] FIG. 3 shows an exemplary graph 310 of an extended reality scene description. In this example, the scene graph includes descriptions of real objects, e.g., a "flat horizontal surface" (which can be a table or a road), and descriptions of virtual objects 312, e.g., an animation of a car. The scene description is organized as an array 310 of nodes. Nodes can be linked to child nodes to form a scene structure 311. Nodes can carry descriptions of real objects (e.g., semantic descriptions) or descriptions of virtual objects. In the example of FIG. 3, node 301 describes a virtual camera located in the 3D volume of the XR application. Node 302 describes a virtual car and includes an index of a representation of the car, e.g., an index in an array of 3D meshes. Node 303 is a child of node 302 and includes a description of one wheel of the car. Similarly, it includes an index into the 3D mesh of the wheel. Since the scale, location, and orientation of the objects are described in the scene nodes, the same 3D mesh may be used for several objects in the 3D scene. The scene graph 310 also contains nodes that are descriptions of spatial relationships between real and virtual objects.

[0019] In time-based media streaming, the scene description itself can evolve in time to provide associated virtual content for each sequence in the media stream. For example, for advertising purposes, a virtual bottle can be displayed on a table during a video sequence in which people are sitting around the table. This kind of behavior can be achieved by relying on the framework defined in the scene descriptions of MPEG media documents.

[0020] While the MPEG-I description framework ensures that timed media and the corresponding associated virtual content are always available, it does not describe how a user can interact with scene objects at runtime in an immersive XR experience.

[0021] In our previous work, a solution is proposed to extend the time-evolving scene description by adding "behavior" data. These behaviors are associated with predefined virtual objects and enable runtime interactivity on those predefined virtual objects for user-specific XR experiences. These behaviors are also time-evolving and are updated through the existing scene description update mechanism.

[0022] FIG. 4 shows an example of an extended reality scene description including behavior data stored at the scene level that describes how a user can interact with scene objects described at the node level at runtime of an immersive XR experience. When an XR application is started, media content items (e.g., meshes of virtual objects visible from a camera) are loaded, rendered, buffered, and displayed when triggered. For example, when a plane is detected in the real environment by a sensor, the application displays the buffered media content items as described in the associated scene node. Timing is managed by the application according to the features detected in the real environment and animation timing. It is also possible that a node of the scene graph does not contain a description and only plays the role of a parent node to its child nodes. FIG. 4 shows the relationship between behaviors included in the scene description at the scene level and the nodes that are components of the scene graph. Behaviors 410 are associated with predefined virtual objects and enable runtime interactivity on the predefined virtual objects for a user-specific XR experience. Behaviors 410 are also time-evolving and updated through a scene description update mechanism.

[0023] The behavior is, a trigger 420, which defines the conditions that must be met for activation; - trigger control parameters, which define the logical operations between the defined triggers; - an action 430 to be processed when the trigger is fired; - action control parameters, which define the order in which related actions are executed; a priority number that allows the selection of the behavior with the highest priority in case of a conflict between several behaviors on the same virtual object at the same time, - an optional interrupt action that specifies how to terminate this behavior when it is no longer defined in a newly received scene update, e.g. the behavior is no longer defined if the associated object does not belong to the new scene or if the behavior is no longer relevant to this current media (e.g. audio or video) sequence.

[0024] Behaviors 410 are performed at the scene level. Triggers are linked to nodes and to the nodes' child nodes. In the example of FIG. 4, trigger 1 is linked to nodes 1, 2, and 8. Trigger 1 is linked to node 31 because node 31 is a child of node 1. Trigger 1 is also linked to node 14 as a child of node 8. Trigger 2 is linked to node 1. In fact, the same node may be linked to several triggers. Trigger n is linked to nodes 5, 6, and 7. A behavior may include several triggers. For example, a first behavior may be activated by trigger 1 and (AND) trigger 2, where "AND" is the trigger control parameter of the first behavior. A behavior may have several actions. For example, a first behavior may first perform action m and then action 1, where "first and then" is the action control parameter of the first behavior. A second behavior may be activated by trigger n, where for example, it may first perform action 1 and then action 2.

[0025] Different formats can be used to represent the node tree. For example, the MPEG-I scene description framework using the Khronos glTF extension mechanism can be used for the node tree. In this example, the interactivity extension can be applied at the glTF scene level and is called MPEG_scene_interactivity. The corresponding semantics are provided in Table 1, where an "M" in the "Usage" column indicates that the field is mandatory in the XR scene description format and an "O" indicates that the field is optional.

[0026] [Table 1]

[0027] In this example, the items in the array for field "triggers" are defined according to Table 2.

[0028] [Table 2]

[0029] As can be seen from the example in Table 2, proximity can be handled by a proximity trigger at the scene level with attributes distanceLowerLimit and distanceUpperLimit.

[0030] Figure 5 illustrates a scene where U (530) is a node associated with a user (camera), T (540) is a trigger, and the ellipse (550) is a node of interest (within the trigger's range and included in the trigger's set of "nodes"). Also shown in Figure 5 is a circle (510) of radius distanceUpperLimit and a circle (520) of radius distanceLowerLimit from the node of interest (550). In this example, the distance from node 530 to node 550 is between distanceUpperLimit and distanceLowerLimit, so the trigger is fired.

[0031] In another embodiment, node "U" may be a node of the scene. The application is responsible for checking the min and max thresholds on the node to determine whether to fire the trigger at runtime.

[0032] The proximity criterion is calculated between the user (e.g. camera) and the node considered. The behavior is done at the scene level. In this mechanism, a set of nodes is considered to calculate the activation of a trigger. Using Table 2 as an example, for example, the distance between "nodes" in the field "triggers" and the node "User" is calculated and compared with distanceLowerLimit and distanceUpperLimit. If the distance is within the range of distanceLowerLimit and distanceUpperLimit, the trigger is activated. However, in this general mechanism for proximity triggers, the parameters are defined at the scene level, and therefore the same proximity calculation is used for each node.

[0033] However, the virtual scene creator may need to define node-specific proximity criteria depending on the nature and / or size of the object geometry associated with that node; for example, the proximity criteria may be different for large or small objects, or may take into account the approach angle.

[0034] There may be different solutions to manage occlusions (objects between the user and the target) during the calculation, for example by adding visibility triggers or by adding a set of nodes that are not taken into account during the calculation in the attribute list (for example, in FIG. 6, not taking rectangle 660 into account).

[0035] Figure 6 illustrates a scene where U (630) is a node associated with a user, the ellipse (650) is a node of interest, and node 660 is between nodes 630 and 650 (there is an occlusion). Also shown in Figure 6 are a circle (610) of radius distanceUpperLimit and a circle (620) of radius distanceLowerLimit from the node of interest (650). In this example, in case of occlusion, it must be determined whether or not the obstacle is taken into account when the distance is calculated.

[0036] This disclosure provides a solution for specializing the proximity criterion for any node of the scene description. In one embodiment, we propose to extend the scene description by specializing the proximity criterion at the node level for dedicated proximity triggering. For example, the scene description extension at the node level includes one or more of the following parameters: The parameter specifies the capture volume, i.e. the 3D volume used for proximity determination. The 3D volume may be specified as a proximity frustum or, more generally, using a mesh that represents the capture volume. Alternatively, the capture volume may be selected using two weight parameters that indicate the importance of proximity to the node. The weights may be set by the scene designer, for example, depending on the size of the object. In another example, the weight of a node close to a car may be different from the weight of a node close to a dog and may depend on the nature of the node. A boolean parameter indicating whether occlusion is taken into account or not. · A Boolean parameter indicating whether geospatial coordinates are used. Geospatial coordinates, if used. Geospatial coordinates are absolute position references and are primarily used for outdoor applications. For example, MPEG defines the representation of geographic coordinates as follows:

[0037] [Table 3] This node-level information includes the child nodes of this node, if any.

[0038] In the following, the proposed extensions are described using the MPEG-I scene description framework with the Khronos glTF extension mechanism to support additional scene description features, however the principles may be applied to other existing or future descriptions of XR scenes.

[0039] The "MPEG_node_proximity_trigger" extension is defined at the node level. When this extension is carried by a node, certain attributes are used for the calculation of the trigger. The semantics of MPEG_node_proximity_trigger at the node level are provided in Table 3 below.

[0040] [Table 4]

[0041] The most efficient location for defining geospatial coordinates is at the scene level, although alternative locations can be envisaged (eg, node level).

[0042] Weight Attribute The parameters distanceLowerLimit and distanceUpperLimit are defined at the scene level, so the same value applies to the set of nodes processed by the trigger (attribute "nodes"). The weight attribute makes it possible to apply a scaling factor to the distance parameters at the node level. distanceLowerLimit(node ​​level)=lower_distance_weight * distanceLowerLimit (scene level) distanceUpperLimit(node ​​level)=upper_distance_weight * distanceUpperLimit (scene level)

[0043] This is useful if a designer wants to give different weights to nodes, for example taking into account their size. The same result can be achieved by setting triggers per node at the scene level.

[0044] Proximity Frustum We propose to add a frustum to activate the proximity trigger, as illustrated in Figure 7. The frustum is defined by four parameters: near plane (710), far plane (720), field of view, and aspect ratio. The axis (730) allows the positioning of the frustum in space. The eye is located at the center of gravity of the object.

[0045] Using this approach, it is possible to capture objects within the frustum (the portion of the pyramid between the near and far planes in FIG. 7). By default, the far plane (720) is set to the distanceUpperLimit defined at the scene level, and the near plane (710) is set to the distanceLowerLimit. For added flexibility, it is possible to define the near and far planes at the node level. The "eye" of the frustum is set to the centroid of the node geometry. The proximity frustum is positioned relative to an axis (730).

[0046] For simplicity, in the examples below the frustum is represented as a triangle, with the near plane set to 0 and the far plane set to a fixed value.

[0047] 8 illustrates the case of a trigger with a frustum where node U (830) is a node associated with a user and node 850 is a node of interest. Since U (830) is outside the frustum (810), the trigger is not fired.

[0048] 9 illustrates another case of a trigger with a frustum, where node U (930) is the node associated with the user and node 950 is the node of interest. Since U (930) is outside the frustum (top view, 910), the trigger is not fired.

[0049] 10 illustrates another case of a trigger with a frustum, where node U (1030) is the node associated with the user and node 1050 is the node of interest. Because U (1030) is inside the frustum (top view, 1010), the trigger (1040) is fired.

[0050] 11 illustrates another case of a trigger with a mesh, where node U (1130) is the node associated with the user and node 1150 is the node of interest. Because U (1130) is inside the mesh (1110), trigger (1140) is fired.

[0051] FIG. 12 illustrates the case of a weighted trigger where node U (1230) is a node associated with a user and node 1250 is a node of interest. Also shown in FIG. 12 are a circle (1210) of radius distanceUpperLimit and a circle (1220) of radius distanceLowerLimit from the node of interest (1250). FIG. 12 also illustrates another node of interest (1280) with a weighted distance. In particular, FIG. 12 shows a circle (1210) of radius (distanceUpperLimit * Circle (1260) of upper_distance_weight and radius (distanceLowerLimit * Also shown is a circle (1270) with the radius of the circle (1210, 1220) and the radius of the circle (1260, 1270) being smaller than the radius of the circle (1210, 1220) because, in this example, weights have been applied to the parameters of the second node of interest (1280) and the values ​​of upper_distance_weight and lower_distance_weight are set to less than 1. In this example, consider that nodes 1250 and 1280 are in the set of triggers "nodes". Since U is between circles (1260, 1270) and (1210, 1220), trigger (1240) is fired.

[0052] An example of the syntax for such a proximity extension in an MPEG-I scene description is shown in Table 4. The fields introduced by the present method are in bold.

[0053] [Table 5-1]

[0054] [Table 5-2]

[0055] [Table 5-3]

[0056] At the scene level: - A single interactivity behavior is defined, consisting of: ○One proximity trigger ("type":proximity) "distanceLowerLimit":0 "distanceUpperLimit": 5 Nodes considered under this trigger: Node0, Node1 ("nodes":[0, 1]) Startup Actions ○ Behavior: A set of triggers and actions, in this case one trigger and one action

[0057] At the node level: - First node Node0: with scene level and node level extensions (trigger capabilities) In this case, a frustum is selected and occlusion is checked (allow_occlusion=true). allow_occlusion(true): Take occlusion into account (test only visible nodes) geospatial_coordinates(false): Do not use geospatial coordinates ○ "geometric_ROI" (FRUSTUM): Uses a frustum (defined by FOV, aspect_ratio, near plane, and far plane). The orientation of the frustum is given by the axis. - The second node, Node1: Only scene-level extension (trigger ability) - The third node Node2: No extension (no triggering capability) since it is not a node that should be taken into account by the trigger.

[0058] Another syntax example of the proximity extension in an MPEG-I scene description is shown in Table 5.

[0059] [Table 6-1]

[0060] [Table 6-2]

[0061] [Table 6-3]

[0062] At the scene level: - A single interactivity behavior is defined, consisting of: ○One proximity trigger ("type":proximity) "distanceLowerLimit":0 "distanceUpperLimit": 5 Nodes considered under this trigger: Node0, Node1 ("nodes":[0, 1]) Startup Actions ○ Behavior: A set of triggers and actions, in this case one trigger and one action

[0063] Node Level: - First node Node0: with extension at node level (trigger capability) In this case, weights are selected, occlusion is checked (allow_occlusion=true), and geo_coordinates are selected. allow_occlusion(true): Take occlusion into account (test visible nodes only) geospatial_coordinates(true): Geospatial coordinates are used (to indicate node positions) ○ "geometric_ROI" (WEIGHT): Applies a scaling factor to the distance defined at the scene level. - With extension at node level to also use second node Node1:geo_coordinates. allow_occlusion(true): Take occlusion into account (test visible nodes only) geospatial_coordinates(true): Geospatial coordinates are used (required in this case) ○ "geometric_ROI" (WEIGHT): Applies a scaling factor to the distance defined at the scene level.

[0064] Runtime Processing Model During runtime, the application iterates over each defined behavior (which can be defined at the scene level). If a "Proximity Extension" node is affected, the attributes listed in Table 3 are used to calculate the firing of the proximity trigger.

[0065] To calculate proximity at the scene level, the Euclidean distance from a node to the user's centroid can be used.

[0066] To check for existence inside the frustum, we loop through each plane of the frustum and calculate the signed distance of the centroid to this plane, the position of the centroid.

[0067] A specific mesh can be provided, which defines the volume used for the trigger calculation. This mesh does not necessarily have to be centered on the associated node geometry. To check for the presence of a specific mesh, e.g. a polyhedron, it is possible to check that the projection of the user's centroid satisfies all the hyperplanes that define the polyhedron.

[0068] When weights are applied, the sub-distance and the top-distance are multiplied by this value, which is useful to take into account the size of the node.

[0069] Figure 13 illustrates how a glTF file is parsed and processed at runtime, according to one embodiment. First, the glTF file is processed. In particular, scene-level proximity triggers are analyzed (1310) and nodes to be considered are identified (1320). Next, extensions at the node level are checked (1330). If present, the parameters used for the trigger are those defined at the node level (1350). If not, the scene-level information is used as the trigger's parameters (1340).

[0070] At runtime, for each node of interest, the proximity criterion associated with the trigger parameters is checked (1360). Depending on the parameters, a trigger may be activated. In particular, if the proximity criterion is satisfied, the trigger is activated (1370) and an associated action is initiated (1380). Monitoring of the proximity criterion continues during runtime as nodes and users may move around.

[0071] FIG. 13 illustrates how the proximity parameters are processed on the receiver side. On the sender side, the proximity parameters are generated based on the generation of a glTF file. Once the scene creator defines the behavior in advance, the glTF file can be generated manually or automatically. The parameters are then transmitted. The parameters can be encoded (e.g., using JSON format) before being transmitted.

[0072] 14 illustrates a method for processing glTF files at runtime that takes into account both proximity and occlusion, according to one embodiment. If the parameter allow_occlusion is present (1410), then occlusion is taken into account (1420) when starting the associated action.

[0073] Various numerical values ​​are used in this application. The specific values ​​are for illustrative purposes and the described aspects are not limited to these specific values.

[0074] Various methods are described herein, each of which includes one or more steps or acts for achieving the described method. The order and / or use of specific steps and / or acts may be modified or combined, unless a specific order of steps or acts is required for proper operation of the method. It should be noted that terms such as "first", "second", etc. may be used in various embodiments to modify elements, components, steps, operations, etc., such as, for example, "first decode" and "second decode". The use of such terms does not imply any ordering to the modified operations, unless specifically required. Thus, in this embodiment, the first decode need not be performed before the second decode, but may occur, for example, before, during, or during a period of overlap with the second decode.

[0075] The implementations and aspects described herein may be implemented, for example, in a method or process, an apparatus, a software program, a data stream, or a signal. Even if only discussed in the context of a single implementation (e.g., discussed only as a method), the implementation of the discussed features may also be implemented in other forms (e.g., an apparatus or a program). An apparatus may be implemented, for example, in appropriate hardware, software, and firmware. The method may be implemented, for example, in an apparatus, for example, a processor, which refers to processing devices in general, including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. Processors also include, for example, communication devices, such as computers, mobile phones, portable / personal digital assistants ("PDAs"), and other devices that facilitate communication of information between end users.

[0076] References to "one embodiment" or "an embodiment" or "one implementation" or "an implementation", as well as other variations thereof, mean that a particular feature, structure, characteristic, etc. described in connection with that embodiment is included in at least one embodiment. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" or "in one implementation" or "in an implementation", as well as other variations, appearing in various places throughout this application are not necessarily all referring to the same embodiment.

[0077] Additionally, the application may refer to "determining" various information. Determining information may include, for example, one or more of estimating information, calculating information, predicting information, or retrieving information from memory.

[0078] Additionally, the application may refer to "accessing" various information. Accessing information may include, for example, one or more of receiving information, retrieving information (e.g., from a memory), storing information, moving information, copying information, calculating information, determining information, predicting information, or estimating information.

[0079] Additionally, the application may refer to "receiving" various information. Receiving, like "accessing," is intended to be a broad term. Receiving information may include, for example, one or more of accessing information or retrieving information (e.g., from a memory). Furthermore, "receiving" typically involves in some manner an operation, such as storing information, processing information, transmitting information, moving information, copying information, erasing information, calculating information, determining information, predicting information, or estimating information.

[0080] For example, in the case of "A / B," "A and / or B," and "at least one of A and B," it should be understood that the use of any of the following " / ," "and / or," and "at least one of" is intended to encompass the selection of only the first enumerated alternative (A), or the selection of only the second enumerated alternative (B), or the selection of both alternatives (A and B). As a further example, in the case of "A, B, and / or C" and "at least one of A, B, and C," such language is intended to encompass the selection of only the first enumerated alternative (A), or the selection of only the second enumerated alternative (B), or the selection of only the third enumerated alternative (C), or the selection of only the first and second enumerated alternatives (A and B), or the selection of only the first and third enumerated alternatives (A and C), or the selection of only the second and third enumerated alternatives (B and C), or the selection of all three alternatives (A and B and C). This can be expanded as many times as the items listed, as would be apparent to one of ordinary skill in this and related arts.

[0081] As will be apparent to one of ordinary skill in the art, implementations may generate 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 a bit stream of the described embodiments. Such a signal may be formatted, for example, as an electromagnetic wave (e.g., using a 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 information 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.

Claims

1. 1. A method comprising: obtaining at least one parameter at a node level from a description of the extended reality scene, the parameter being used to indicate that an object corresponding to the node is in a state of proximity with another object corresponding to another node; and initiating a trigger for an action in response to the object being in proximity with the other object.

2. 1. A method comprising: generating at least one parameter at a node level to indicate that an object corresponding to the node is in a state of proximity with another object corresponding to another node in a description of the extended reality scene, the parameter being used to activate a trigger for an action; transmitting the description of the extended reality scene.

3. The method of claim 1 or 2, wherein the nodes are associated with users.

4. The description of the extended reality scene comprises: an upper bound on the distance between the node and the other node at the scene level; a first scaling factor corresponding to said upper limit at a node level.

5. The above description is a lower bound on the distance between the node and the other node at the scene level; A second scaling factor corresponding to the lower bound at a node level.

6. The above description is 6. A method according to claim 1, further comprising one or more parameters specifying a volume, the node being considered to be in proximity to the other node in response to the node being within the volume.

7. The method of claim 6 , wherein the volume is specified based on a mesh or a frustum.

8. The method according to any one of claims 1 to 7, wherein the description further comprises a parameter indicating whether occlusion is taken into account or not.

9. The method of claim 8 , wherein the trigger is fired only if the node is not occluded by the other node.

10. The method of any one of claims 1 to 9, wherein the description of the extended reality scene further comprises a parameter indicating that geospatial coordinates are used.

11. An apparatus comprising one or more processors and at least one memory coupled to said one or more processors, said one or more processors configured to execute a method according to any one of claims 1 to 10.

12. A non-transitory computer readable medium comprising instructions which, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 10.

Images