Proximity triggers in scene description

Abstract

In one implementation, we propose to enhance scene description by specifying a proximity criterion of a node level for proximity triggering. For example, scene description enhancements at a node level include one or more of the following: (1) two weight parameters indicative of proximity importance with the node, (2) references to a simplified grid attached to a node grid, for proximity calculation, and / or references to a proximity frustum defining a capture volume, (3) Boolean parameters indicative of whether occlusion is considered, (4) Boolean parameters indicative of whether occlusion is considered, and (5) Boolean parameters indicative of whether occlusion is considered. (4) Boolean parameters indicating whether to use geospatial coordinates, and (5) geospatial coordinates.

Description

Technical Field

[0001] The present embodiment generally relates to extended reality scene description and extended reality scene presentation. Background Art

[0002] Extended Reality (XR) is a technology that enables interactive experiences in which the real world environment and / or video content is augmented by virtual content that can be defined across multiple sensory modalities (including vision, hearing, touch, etc.). During the runtime of the application, virtual content (e.g., 3D content or audio / video files) is rendered in real time in a manner consistent with the user context (environment, perspective, device, etc.). Scene graphs (such as the scene graph proposed by Khronos / glTF and its extensions defined in, for example, the MPEG scene description format or Apple / USDZ) are one possible way to represent the content to be rendered. They combine, on the one hand, a declarative description of the scene structure linking real environment objects and virtual objects, and on the other hand, a binary representation of the virtual content. The scene description framework ensures that timed media and corresponding related virtual content are available at any time during application rendering. The scene description can also carry data at the scene level that describes how the user can interact with the scene objects at runtime for an immersive XR experience. Summary of the invention

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

[0004] According to another embodiment, a device is provided, comprising 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 at least a node-level parameter from a description of an extended reality scene, the parameter being used to indicate that an object corresponding to a node is close to another object corresponding to another node; and activate a trigger for an action in response to the object being close to the other object.

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

[0006] One or more embodiments further provide a computer-readable storage medium on which video data generated according to the above method is stored. One or more embodiments further provide a method and apparatus for transmitting or receiving video data generated according to the method described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 An example architecture of an XR processing engine is shown.

[0008] Figure 2 An example of the syntax of a data stream encoding an augmented reality scene description is shown.

[0009] Figure 3 An example diagram of an extended reality scene description is shown.

[0010] Figure 4 An example of an extended reality scene description is shown, including behavioral data stored at the scene level that describes how a user can interact with scene objects described at the node level at runtime for an immersive XR experience.

[0011] Figure 5 Illustration of a scene-level proximity trigger.

[0012] Figure 6 The diagram illustrates occlusion.

[0013] Figure 7 An approximation to a frustum is illustrated.

[0014] Figure 8 A proximity trigger with a frustum is illustrated (not triggered).

[0015] Fig. 9 Another proximity trigger having a frustum is illustrated (not triggered).

[0016] Fig.10 A proximity trigger (triggered) having a frustum is illustrated.

[0017] Fig.11 A proximity trigger with a specific grid is illustrated.

[0018] Fig.12 It is illustrated that the threshold minimum value (min) and maximum value (max) are scaled.

[0019] Fig.13 A method for parsing and processing a glTF file at runtime according to an embodiment is illustrated.

[0020] Fig.14A method of processing a glTF file at runtime in the presence of occlusion is illustrated according to one embodiment. DETAILED DESCRIPTION

[0021] Various XR applications can be applied to different scenarios and real or virtual environments. For example, in an industrial XR application, when a camera mounted on a head-mounted display device detects a reference object (engine part B) in the real environment, a virtual 3D content item (e.g., engine part A) is displayed. The 3D content item is positioned in the real world, and its position and scale are defined relative to the detected reference object.

[0022] For example, in an XR application for interior design, when a given image from a catalog is detected in the input camera view, a 3D model of furniture is displayed. The 3D content item is positioned in the real world, and its position and scale are defined relative to the detected reference image. In another application, when the user enters an area near a church (real or virtually presented in the extended reality environment), some audio files may start playing. In another example, when the user sees a can of a given soda in the real environment, an advertising song file can be played. In an outdoor gaming application, various virtual characters may appear depending on the semantics of the scenery observed by the user. For example, a bird character is suitable for trees, so if the sensor of the XR device detects a real object described by the semantic label "tree", birds flying around the tree can be added. In a companion application implemented by smart glasses, when a car is detected in the field of view of the user's camera, the car noise may be activated in the user's headphones to warn him of potential danger. In addition, the sound can be spatialized so that it arrives from the direction where the car was detected.

[0023] XR applications can also augment video content instead of the real environment. The video is displayed on a rendering device, and when a timed event is detected in the video, the virtual objects described in the node tree are overlaid. In this scenario, the node tree only includes virtual object descriptions.

[0024] Figure 1 1 shows an example architecture of an XR processing engine 130 that can be configured to implement the methods described herein. Figure 1 The devices of the architecture are linked to other devices via their buses 131 and / or via I / O interfaces 136 .

[0025] The device 130 comprises the following elements linked together by a data and address bus 131: - a microprocessor 132 (or CPU), which is for example a DSP (or digital signal processor); - ROM (or read-only memory) 133; - RAM (or random access memory) 134; - Storage interface 135; - I / O interface 136 for receiving data to be transmitted from an application; and -power supply( Figure 1 not shown), such as batteries.

[0026] According to an example, the power supply is external to the device. In each of the memories mentioned, the term "register" used in the specification may correspond to an area of ​​small capacity (a few bits) or a very large area (e.g., an entire program or a large amount of received or decoded data). ROM 133 includes at least programs and parameters. ROM 133 may store algorithms and instructions for executing the technology according to the present principles. When turned on, CPU 132 uploads the program in RAM and executes the corresponding instructions.

[0027] The RAM 134 includes in registers a program executed by the CPU 132 and uploaded after the device 130 is turned on, input data in registers, intermediate data in different states of the method in registers, and other variables used to execute the method in registers.

[0028] Device 130 is linked to a set of sensors 137 and a set of presentation devices 138, for example, via bus 131. Sensor 137 may be, for example, a camera, a microphone, a temperature sensor, an inertial measurement unit, a GPS, a humidity sensor, an IR or UV light sensor, or a wind sensor. Presentation device 138 may be, for example, a display, a speaker, a vibrator, a heater, a fan, etc.

[0029] According to an example, the device 130 is configured to implement a method according to the present principles and belongs to the set comprising: -mobile device; -communication equipment; -Gaming equipment; - Tablet (or tablet computer); - Laptop; -Still picture camera; - Video camera.

[0030] In XR applications, scene description is used to combine an explicit and easily parseable description of the scene structure with some binary representation of the media content. Figure 2 An example of the syntax of a data stream encoding an augmented reality scene description is shown. Figure 2An example structure 210 of an XR scene description is shown. The structure is contained in a container that organizes the stream in independent syntax elements. The structure may include a header portion 220, which is a set of data common to each syntax element of the stream. For example, the header portion includes some metadata about the syntax elements that describes the properties and roles of each of the syntax elements. The structure also includes a payload that includes syntax elements 230 and syntax elements 240. Syntax element 230 includes data representing a media content item described in a node of a scene graph associated with a virtual element. Images, meshes, and other raw data may have been compressed according to a compression method. Syntax element 240 is part of the payload of the data stream and includes data for encoding the scene description as described in the present principles.

[0031] Figure 3 An example graph 310 of an extended reality scene description is shown. In this example, the scene graph may include descriptions of real objects, such as a "flat horizontal surface" (which may be a table or a road), and descriptions of virtual objects 312, such as an animation of a car. The scene description is organized as an array of nodes 310. Nodes may be linked to child nodes to form a scene structure 311. Nodes may carry descriptions of real objects (e.g., semantic descriptions) or descriptions of virtual objects. Figure 3 In the example of , 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 to a representation of the car, such as an index into a 3D grid array. Node 303 is a child of node 302 and includes a description of one wheel of the car. In the same way, it includes an index to the 3D mesh of the wheel. The same 3D mesh can be used for several objects in the 3D scene, since the scale, position, and orientation of the objects are described in the scene nodes. The scene graph 310 also includes nodes that are descriptions of the spatial relationships between real objects and virtual objects.

[0032] In time-based media streaming, the scene description itself can evolve over time to provide relevant virtual content for each sequence of 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 a table. This behavior can be achieved by relying on a framework defined in the scene description of an MPEG media document.

[0033] While the MPEG-I Scene Description Framework ensures that timed media and the corresponding related virtual content are available at any time, there is no description of how users can interact with scene objects at runtime for an immersive XR experience.

[0034] In our previous work, we proposed a solution to enhance scene descriptions that evolve over time by adding “behavior” data. These behaviors are associated with predefined virtual objects, on which runtime interactivity is allowed for user-specific XR experiences. These behaviors also evolve over time and are updated via the existing scene description update mechanism.

[0035] Figure 4 An example of an extended reality scene description is shown, including behavioral data stored at the scene level that describes how a user can interact with scene objects described at the node level at runtime for an immersive XR experience. When the XR application is launched, media content items (such as meshes of virtual objects visible from the camera) are loaded, rendered, and buffered so that they are displayed when triggered. For example, when a sensor detects a planar surface in the real environment, the application displays the buffered media content items as described in the relevant scene node. Timing is managed by the application based on the features detected in the real environment and the timing of the animation. The nodes of the scene graph may also not include descriptions and only play the role of parents of child nodes. Figure 4 The relationship between behaviors included in the scene description at the scene level and nodes as components of the scene graph is shown. Behaviors 410 are associated with predefined virtual objects, on which runtime interactivity is allowed for user-specific XR experiences. Behaviors 410 also evolve over time and are updated through the scene description update mechanism.

[0036] Behaviors include: - a trigger 420, defining the conditions to be met for its activation; - Trigger control parameters, which define the logical operations between defined triggers; - Actions to be performed when the trigger is activated 430; -Action control parameters, which define the execution order of related actions; - Priority numbering, so that when several behaviors on the same virtual object compete simultaneously, the behavior with the highest priority can be selected; - An optional interrupt action that specifies how to terminate the behavior when it is no longer defined in a newly received scene update; for example if the associated object does not belong to the new scene, or if the behavior is no longer relevant to the current media (e.g. audio or video) sequence.

[0037] Behavior 410 occurs at the scene level. Triggers are linked to nodes and their descendants. Figure 4In the example, trigger 1 is linked to nodes 1, 2 and 8. Since node 31 is a child of node 1, trigger 1 is linked to node 31. Trigger 1 is also linked to node 14, which is 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" trigger 2, "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 perform action 1, "first, then" is the action control parameter of the first behavior. For example, a second behavior may be activated by trigger n, and first perform action 1, and then perform action 2.

[0038] Different formats may be used to represent the node tree. For example, the MPEG-I Scene Description Framework using the Khronos glTF extension mechanism may be used for the node tree. In this example, the interactivity extension may be applicable 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.

[0039] Table 1 In this example, the entries of the array for the field "Trigger" are defined according to Table 2.

[0040] Table 2 As can be seen from the example in Table 2, proximity can be handled by proximity triggers at the scene level using the attributes distanceLowerLimit and distanceUpperLimit.

[0041] Figure 5 A scenario is illustrated where U (530) is a node associated with a user (camera), T (540) is a trigger, and ellipses (550) are related nodes (within the scope of the trigger, included in the trigger's collection "nodes"). Figure 5A circle (510) with a radius of distanceUpperLimit and a circle (520) with a radius of distanceLowerLimit from the relevant node (550) are also shown in FIG. In this example, because the distance from node 530 to node 550 is between distanceUpperLimit and distanceLowerLimit, the trigger is activated.

[0042] In another embodiment, node "U" may be a node of a scene. The application is responsible for checking the threshold minimum and threshold maximum values ​​on the node to determine whether to activate the trigger at runtime.

[0043] The proximity criteria will be calculated between the user (e.g. camera) and the node under consideration. The behavior occurs at the scene level. With this mechanism, a collection of nodes is considered to calculate the activation of the trigger. Using Table 2 as an example, for example, the distance between the "node" in the field "trigger" and the node "user" is calculated, and the distance is compared with distanceLowerLimit and distanceUpperLimit. If the distance is within distanceLowerLimit and distanceUpperLimit, then the trigger is activated. However, in this general mechanism of proximity triggers, the parameters are defined at the scene level, and therefore the same proximity calculation is used for each node.

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

[0045] There may be different solutions to manage occlusions (objects between the user and the target) during calculation, for example by adding visibility triggers, or adding collections of nodes in the property list that are not considered during calculation (for example in Figure 6 In this case, we do not consider rectangle 660).

[0046] Figure 6 A scene is shown, where U (630) is a node associated with a user, ellipse (650) is a related node, and node 660 is between nodes 630 and 650 (there is occlusion). Figure 6 Also shown in is a circle (610) of radius distanceUpperLimit and a circle (620) of radius distanceLowerLimit from the relevant node (650).In this example, in the case of occlusion, we must decide whether to consider the obstacle when calculating the distance.

[0047] The present disclosure provides a solution for specializing the proximity criteria of any node for scene description. In one embodiment, we propose to enhance scene description by specializing the node-level proximity criteria for dedicated proximity triggers. For example, the node-level scene description enhancement includes one or more of the following parameters: Parameters specifying 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 grid to indicate the capture volume. Alternatively, the capture volume may be selected using two weight parameters indicating the importance of proximity to the nodes. The weights may be set by the designer of the scene, e.g. depending on the size of the objects. In another example, the weights of nodes close to a car may be different than those of nodes close to a dog, and they may also depend on the nature of the nodes.

[0048] A Boolean parameter indicating whether occlusions are taken into account.

[0049] A Boolean parameter indicating whether to use geospatial coordinates.

[0050] Geospatial coordinates, if used. Geospatial coordinates are absolute position references and are primarily used in outdoor applications. For example, MPEG defines the representation of geographic coordinates: The node-level information covers the node's descendant nodes (if any).

[0051] In the following, the proposed enhancements are described using the MPEG-I Scene Description Framework with the Khronos glTF extension mechanism to support additional scene description features. However, the present principles can be applied to other existing or upcoming descriptions of XR scenes.

[0052] The "MPEG_node_proximity_trigger" extension is defined at the node level. When a node carries this extension, specific attributes are used to compute the trigger. The semantics of the MPEG_node_proximity_trigger at the node level is provided in Table 3.

[0053] Table 3 The most efficient placement for defining geospatial coordinates is at the scene level, but alternative placements (eg, at the node level) are also contemplated.

[0054] Weight attribute The parameters distanceLowerLimit and distanceUpperLimit are defined at the scene level. Therefore, the same value is applied to the set of nodes handled by the trigger (property "nodes"). Using the weight property, it is 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) This is useful if the designer wants to give different weights to nodes, for example to take size into account. The same result can be achieved by setting the trigger per node at the scene level.

[0055] Close to frustum We propose to add frustum to activate proximity triggers, e.g. Figure 7 As shown. The frustum is defined by four parameters, namely, the near plane (710), the far plane (720), the field of view, and the aspect ratio. The axis (730) allows the frustum to be positioned in space. The eye is positioned at the center of mass of the object.

[0056] Using this method, it is possible to capture the frustum ( Figure 7 The part of the pyramid between the near and far planes in the scene. By default, the far plane (720) is set at distanceUpperLimit defined at the scene level, and the near plane (710) is set at 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 the axis (730).

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

[0058] Figure 8 The case of a trigger with a frustum is illustrated, where node U (830) is the node associated with the user and node 850 is the related node. Because U (830) is outside the frustum (810), the trigger is not activated.

[0059] Fig. 9Another case of a trigger with a frustum is illustrated, where node U (930) is a node associated with the user and node 950 is a related node. Because U (930) is outside the frustum (top view, 910), the trigger is not activated.

[0060] Fig.10 Another case of a trigger with a frustum is illustrated, where node U (1030) is a node associated with a user and node 1050 is a related node. Because U (1030) is inside the frustum (top view, 1010), the trigger (1040) is activated.

[0061] Fig.11 Another case of a trigger with a grid is illustrated, where node U (1130) is a node associated with a user and node 1150 is a related node. Because U (1130) is inside the grid (1110), the trigger (1140) is activated.

[0062] Fig.12 The example of a trigger with weights is shown, where node U (1230) is a node associated with a user and node 1250 is a related node. Fig.12 Also shown is a circle (1210) with a radius of distanceUpperLimit and a circle (1220) with a radius of distanceLowerLimit from the relevant node (1250). Fig.12 Another related node (1280) with a weighted distance is also illustrated. Fig.12 Also shown in FIG. 1 are a circle (1260) of radius (distanceUpperLimit*upper_distance_weight) and a circle (1270) of radius (distanceLowerLimit*lower_distance_weight) from the related node (1280). In this example, weights are applied to the parameters of the second related node (1280), and the radius of the circles (1260, 1270) is less than the radius of the circles (1210, 1220) because the values ​​of upper_distance_weight and lower_distance_weight are set to less than 1. In this example, we consider nodes 1250 and 1280 to be in the set "nodes" of the trigger. Because U is between circles (1260, 1270) and (1210, 1220), the trigger (1240) is activated.

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

[0064] Table 4

[0065] At the scene level: - A single interactive behavior is defined and consists of: A proximity trigger (“type”: PROXIMITY) ■"distanceLowerLimit": 0 ■"distanceUpperLimit": 5 ■Nodes to be considered under this trigger: Node0, Node1 ("Node": [0,1]) Activate Action ○Behavior ■ A collection of triggers and actions, in this case one trigger and one action.

[0066] At the node level: - First node Node0: has extensions (trigger capabilities) at scene level and node level. For this case, select the frustum and check for occlusion (allow_occlusion = true) ○ allow_occlusion (true): We take occlusion into account (only test visible nodes) ○ geospatial_coordinates (false): Do not use geospatial coordinates ○ "geometric_ROI" (frustum): Use a frustum (defined by FOV, aspect_ratio, near and far planes). The orientation of the frustum is given by the axes - The second node Node1: only has the extension (trigger capability) at the scene level - Third node Node2: no expansion (no trigger capability) because it is not a node to be considered by the trigger.

[0067] Another syntax example of the proximity extension in MPEG-I scene description is provided in Table 5.

[0068] Table 5

[0069] At the scene level: - A single interactive behavior is defined and consists of: A proximity trigger (“type”: PROXIMITY) ■"distanceLowerLimit": 0 ■"distanceUpperLimit": 5 ■Nodes to be considered under this trigger: Node0, Node1 ("Node": [0,1]) Activate Action ○ Behavior: A collection of triggers and actions, in this case one trigger and one action.

[0070] At the node level: - First node Node0: has extension at the node level (trigger capability) In this case, select Weights and check Occlusion (allow_occlusion = true), select geo_coordinates ○ allow_occlusion (true): We take occlusion into account (only test visible nodes) ○ geospatial_coordinates (true): Use geospatial coordinates (to indicate the location of the node) ○ "geometric_ROI" (WEIGHT): applies a scaling factor to the distance defined at the scene level - Second node Node1: has an extension at the node level to also use geo_coordinates ○ allow_occlusion (true): We take occlusion into account (only test visible nodes) ○ geospatial_coordinates (true): use geospatial coordinates (mandatory in this case) ○ “geometric_ROI” (WEIGHT): Applies a scaling factor to the distance defined at the scene level.

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

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

[0073] To check for existence in the frustum, we loop through each plane of the frustum and compute the signed distance from the centroid to that plane - the location of the centroid.

[0074] A specific grid may be provided that defines the volume used for trigger calculations. The grid is not necessarily centered on the relevant node geometry. To check for existence in a specific grid (e.g. a polyhedron), it is possible to check if the projection of the user's centroid satisfies all hyperplanes defining the polyhedron.

[0075] When applying weights, multiply the upper and lower distances by this value. This helps account for the size of the nodes.

[0076] Fig.13 A method for parsing and processing a glTF file at runtime according to an embodiment is illustrated. First, the glTF file is processed. In particular, the scene level proximity trigger is analyzed (1310), and the nodes to be considered are identified (1320). Then, the extension at the node level is checked (1330). If present, the parameters for the trigger will be the parameters defined at the node level (1350). Otherwise, the scene level information is used as the parameters of the trigger (1340).

[0077] At runtime, for each relevant node, the proximity criteria associated with the trigger parameters are checked (1360). Depending on the parameters, the trigger may be activated. In particular, if the proximity criteria are met, the trigger is activated (1370) and the associated action is initiated (1380). Monitoring of the proximity criteria continues during runtime as nodes and users may move around.

[0078] Fig.13 The diagram shows how proximity parameters are processed on the receiver side. On the sender side, proximity parameters are generated based on the generation of a glTF file. The scene creator previously defined the behavior, and the glTF file can be generated manually or automatically. The parameters are then sent. The parameters can be encoded (e.g. using JSON format) before sending.

[0079] Fig.14 A method of processing a glTF file at runtime considering both proximity and occlusion according to an embodiment is illustrated. If the parameter allow_occlusion is present (1410), occlusion is considered when initiating the associated action (1420).

[0080] 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.

[0081] Various methods are described herein, and each method in the method includes one or more steps or actions for realizing the described method.Unless specific steps or action order are needed to correctly operate the method, the order and / or use of specific steps and / or actions can be modified or combined.Additionally, in various embodiments, terms such as "first", "second" can be used to modify elements, components, steps, operations, etc., such as, for example, "first decoding" and "second decoding".Unless specifically required, using such terms does not mean that the modified operation is sorted.Therefore, in this example, the first decoding does not need to be performed before the second decoding, and can occur before, during, or in a time period overlapping with the second decoding, for example, the second decoding.

[0082] The implementations and aspects described herein can be implemented in, for example, methods or processes, devices, software programs, data streams, or signals. Even if only discussed in the context of a single form of an implementation (e.g., discussed only as a method), the implementation of the features discussed can also be implemented in other forms (e.g., devices or programs). A device can be implemented in, for example, appropriate hardware, software, and firmware. These methods can be implemented in, for example, a device, 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. The processor also includes a communication device, such as a computer, a cellular phone, a portable / personal digital assistant ("PDA"), and other devices that facilitate information communication between end users.

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

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

[0085] Further, the present application may refer to "accessing" various pieces of 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.

[0086] Additionally, the present application may refer to "receiving" various pieces of information. Like "accessing," receiving 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). Further, during operation, "receiving" is generally involved in some way, such as storing information, processing information, transmitting information, moving information, copying information, erasing information, calculating information, determining information, predicting information, or estimating information.

[0087] It is to be appreciated that use of any of the following “ / ,” “and / or,” and “at least one of,” (e.g., in the case of “A / B,” “A and / or B,” and “at least one of A and B”) is intended to encompass selection of only the first listed option (A), or only the second listed option (B), or both options (A and B). As further examples, in the case of “A, B, and / or C” and “at least one of A, B, and C,” such wording is intended to encompass selection of only the first listed option (A), or only the second listed option (B), or only the third listed option (C), or only the first listed option and the second listed option (A and B), or only the first listed option and the third listed option (A and C), or only the second listed option and the third listed option (B and C), or all three options (A and B and C). This may be extended to as many items as listed, as will be apparent to one of ordinary skill in the art and related arts.

[0088] As will be apparent to one of ordinary skill in the art, implementations may generate various signals formatted to carry information that may be stored or transmitted, for example. The information may include, for example, instructions for executing the 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. For example, such a signal may be formatted as an electromagnetic wave (e.g., using a radio frequency portion of a spectrum) or as a baseband signal. Formatting may include, for example, encoding a data stream and modulating a carrier with the encoded data stream. The information carried by the signal may be, for example, analog or digital information. As is well known, a signal may be transmitted over a variety of different wired or wireless links. The signal may be stored on a processor readable medium.

Claims

1. A method comprising: Obtaining at least a node-level parameter from a description of an augmented reality scene, the parameter being used to indicate that an object corresponding to a node is close to another object corresponding to another node; as well as In response to the object being in proximity to the other object, a trigger for an action is activated.

2. A method comprising: generating, in a description of an extended reality scene, a parameter at at least a node level to indicate that an object corresponding to a node is in proximity to another object corresponding to another node, wherein the proximity is used to activate a trigger for an action; as well as The description of the augmented reality scene is transmitted. The method according to claim 1 , wherein the node is associated with a user.

4. The method according to any one of claims 1 to 3, wherein the description of the extended reality scene comprises: an upper limit on the distance between the node and the other node at the scene level; as well as A first scaling factor at the node level corresponding to the upper limit.

5. The method according to any one of claims 1 to 4, wherein the description comprises: a lower bound on a distance between the node and the other node at a scene level; as well as A second scaling factor at the node level corresponding to the lower limit.

6. The method according to any one of claims 1 to 5, wherein the description comprises: One or more parameters of a volume are specified, wherein in response to the node being inside the volume, the node is considered to be proximate to the other node. The method of claim 6 , wherein the volume is specified based on a grid 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.

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

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

11. An apparatus comprising 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 perform the method of any one of claims 1 to 10.

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

Images