Node visibility triggers in augmented reality scene description

Abstract

A method, device and data stream are provided for adapting conditions under which the visibility of an object triggers or does not trigger an action in an augmented reality application. A visibility trigger is activated when an object described in a node linked to the trigger is visible from a given camera's viewpoint. To adapt and specialize the criteria of the visibility trigger, additional information is set at the node level. This information depends on the nature and / or size of the object geometry and the nature and / or size of the geometry of other nodes considered for the object visibility estimation.

Description

[Technical field]

[0001] The present principles generally relate to the field of augmented reality scene description and augmented reality rendering. 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. The scene description can also carry scene-level data that describes how the user can interact with the scene objects during the runtime of the immersive XR experience. However, there is no XR system that can take an XR scene description that includes node-level metadata that describes how the visibility of scene objects is handled at runtime when events relate to visibility and / or occlusion of real or virtual objects, and how these interactions can be updated during the runtime of the XR application. 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 that includes obtaining a description of an augmented reality scene, the description including a scene graph linking nodes and a trigger. The trigger is associated with a first node of the scene graph that describes a camera and a second node of the scene graph that describes a first object. The second node includes first information indicating whether the first object needs to be visible by the camera to activate the trigger. The method further includes triggering an action on a node of the scene graph when the first information is true.

[0006] The first information may be a Boolean value indicating the percentage of the first object that needs to be visible to activate the trigger, or whether the object needs to be completely visible to activate the trigger. The second node may include second information indicating a list of second objects that should be ignored (or conversely, considered) when estimating the visibility of the first object. The second node may also include third information providing a simplified mesh to use instead of the mesh of the object to estimate the visibility of the object.

[0007] The present principles also relate to an augmented reality rendering device comprising a memory associated with a processor configured to perform the above method.

[0008] The present principles also relate to a data stream carrying data representing a description of an augmented reality scene, the description including a scene graph linking nodes and a trigger, the trigger being associated with a first node of the scene graph describing a camera and a second node of the scene graph describing a first object, the second node including first information indicating whether the first object needs to be visible by the camera to activate the trigger.

[0009] The first information may be a Boolean value indicating the percentage of the first object that needs to be visible to activate the trigger, or whether the object needs to be completely visible to activate the trigger. The second node may include second information indicating a list of second objects that should be ignored (or conversely, considered) when estimating the visibility of the first object. The second node may also include third information providing a simplified mesh to use instead of the mesh of the object to estimate the visibility of the object. [Brief description of the drawings]

[0010] 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:

[0011] [Figure 1] 1 illustrates an exemplary graph of an augmented reality scene description in accordance with present principles. [Diagram 2] 1 illustrates a non-limiting example of an augmented reality scene description that includes behavior data stored at the scene level that describes how a user can interact with scene objects described at the node level during runtime of an immersive XR experience. [Diagram 3] 1 illustrates an exemplary architecture of an XR processing engine that may be configured to perform a method in accordance with present principles. [Figure 4] 1 illustrates an example of one embodiment of a syntax for a data stream for encoding an augmented reality scene description according to the present principles. [Figure 5A] Showing different cases regarding the visibility of objects in an XR scene. [Figure 5B] Showing different cases regarding the visibility of objects in an XR scene. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0013] 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 " / ".

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

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

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

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

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

[0019] FIG. 1 shows an exemplary graph 10 of an augmented 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 12, e.g., an animation of a car. The scene description is organized as an array of nodes 10. 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. Node 103 is a child of node 102 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 10 also contains nodes that are descriptions of spatial relationships between real and virtual objects.

[0020] XR applications are diverse 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 the 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.

[0021] 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, an audio file may start playing when a user enters an area close to a church (either real or virtually rendered in an augmented reality environment). In another example, an advertising jingle file may be played when a 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 sensors detect 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.

[0022] XR applications can also augment the real environment with video content instead: 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 the virtual objects.

[0023] FIG. 2 illustrates a non-limiting example of an augmented 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 the timing of animations. 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. 2 illustrates the relationship between behaviors included in the scene description at the scene level and the nodes that are constituents of the scene graph. The behaviors 20 are associated with predefined virtual objects for which runtime interactivity is allowed for a user-specific XR experience. The behaviors 20 are also time-evolving and updated through a scene description update mechanism.

[0024] A behavior includes triggers 21, which define the conditions to be met for its activation. A behavior also includes trigger control parameters that define the logical operations between the defined triggers. A behavior also includes actions 22 that are processed when a trigger is activated. A behavior also includes action control parameters that define the order of execution of the related actions, and a priority number that allows the selection of the behavior with the highest priority in case of conflict between several behaviors on the same virtual object at the same time. An optional interrupt action can be added to a behavior, which specifies how this behavior is terminated when it is no longer defined in a newly received scene update. For example, a behavior is no longer defined if the object involved 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.

[0025] Actions 20 are performed at the scene level. Triggers are linked to nodes and their child nodes. In the example of FIG. 2, 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 14. 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 and may, for example, first perform action 1 and then action 2.

[0026] The activation of a trigger is controlled by the state of the node to which the trigger is linked. A visibility trigger at the scene level is defined by two attributes: the camera node and a node describing the object. [Table 1]

[0027] Since triggers are defined at the scene level, the criteria used to activate a trigger are the same for all nodes.

[0028] However, this general mechanism has a drawback for visibility triggers: a visibility trigger is activated when the object described in the node linked to the trigger is visible from a given camera's point of view. In the example of Figure 2, trigger n is activated if nodes 5 and 7 are visible from the camera described by node 6. The actions associated with trigger n are then executed in the order they are described.

[0029] According to the present principles, additional information is set at the node level to tailor and specialize visibility trigger criteria. For example, an XR scene author may need to define node-specific visibility criteria depending on: - the nature and / or size of the object geometry associated with that node. Full or partial visibility criteria are introduced. For example, full or partial visibility criteria may be different for a virtual mouse, a humanoid, an elephant, a tree, or a building. - the nature and / or size of the geometry of other nodes that are taken into account for the visibility calculation of that node. The creator of the virtual scene can define which other nodes are relevant for estimating the visibility of the object described by a given node. For example, a humanoid can still be considered as fully visible even if a small object (a mouse) causes an occlusion.

[0030] Figures 5A and 5B show different cases regarding the visibility of objects in an XR scene. In these examples, a visibility trigger is linked to a virtual camera 51 that captures the scene that is visible within a frustum 52. In Figure 5A, a sphere 53 is completely outside the frustum and is therefore not visible from the camera's point of view. A cube 54 is partially visible since part 54a of it belongs to the space defined by the frustum and part 54b of it is outside this space. In Figure 5B, a cube 54 completely belongs to the frustum but is only partially visible since a sphere 55 is in front of the cube 54 from the camera's point of view.

[0031] In accordance with the present principles, these visibility conditions are met by using information stored in the node describing cube 54. The following notation is given within the MPEG-I Scene Description framework using the Khronos gLTf extension mechanism to indicate additional scene description features. It is understood that the present principles may be adapted to other existing or future formats of XR scene descriptions.

[0032] The scene description is extended by specializing the visibility criteria at the node level for a given visibility trigger. This scene description extension at the node level includes a parameter indicating how full or partial the visibility of an object should be. It also includes an array of indices of nodes whose geometry is ignored for visibility trigger activation. If not indicated, the array is empty. Optionally, it may include a reference to a simplified mesh (e.g., bounding box) for the object mesh that is used for visibility calculations.

[0033] In this context, the "MPEG_Node_Visibility_Trigger" extension is defined at the node level. The semantics of MPEG_Node_Visibility_Trigger at the node level are provided in the table below. [Table 2]

[0034] Here, an "M" in the "Use" column means that this field is mandatory in an XR scene description format according to the present principles, a "D" means that a default value will be used by the rendering if not present in the scene description, and an "O" means that the field is optional.

[0035] The visibilityFull field indicates the required percentage of the visible part of the object to activate the trigger. By default, the object must be fully visible. The author of the XR scene may decide that the visibility condition is satisfied if only 50 percent of the object (e.g., a building) or 80 percent of the object (e.g., a table) is visible. For example, the cube 54 in FIG. 5A may be considered to be visible from the camera 51 depending on the value of its node's visibilityFull field. In a variant, the visibilityFull field is a Boolean. A true value indicates that the object must belong entirely to the frustum, and a false value indicates that the trigger is activated if at least a part of the object is visible from the camera. In another variant, the visibilityFull field is an integer indicating the number of mesh primitives (e.g., faces, e.g., triangles) that must be visible to activate the visibility trigger.

[0036] The visibilityNodesIgnored field is an array of indices of nodes that describe objects that should be ignored with respect to the visibility conditions of the considered objects. In the example of FIG. 5B, the visibilityNodesIgnored field of the node of the cube 54 may contain the indices of the nodes of the sphere 55. In this example, the mesh of the sphere 55 is ignored for determining the visibility of the cube 54, which is considered to be fully visible. By default, the visibilityNodesIgnored field is an empty array indicating that all objects in the scene should be considered for determining the visibility. In a variant, the visibilityNodesConsidered field is used instead of the visibilityNodesIgnored field. The visibilityNodesConsidered field is an array that lists the indices of nodes that should be considered for determining whether the object is fully visible.

[0037] During runtime, the application iterates over each behavior of the scene description. According to the present principles, if a node containing attributes defined according to the present principles is associated with a visibility trigger of the behavior, these attributes are used to evaluate whether the object described by the node is fully visible by the camera associated with the visibility trigger. To evaluate the visibility of an object, the application can use either rasterization, ray tracing, or a hybrid technique. Rasterization and ray tracing are processes used to calculate visibility problems. Rasterization techniques project objects (from a 3D representation to a 2D representation using the projection mode of the camera) onto a plane determined according to the parameters of the camera, as described, for example, on the website "https: / / www.scratchapixel.com / lessons / 3d-basic-rendering / rasterization-practical-implementation". Ray tracing works by tracing a path from a virtual eye through each pixel of a virtual screen and calculating the color of the object that is visible through it, as described, for example, on the website "https: / / en.wikipedia.org / wiki / Ray_tracing_(graphics)".

[0038] If a simplified mesh is provided in a node, it shall be used to calculate visibility instead of the node mesh. When a bounding box is available to the application, it is possible to take it into account instead of the node mesh to calculate visibility, if a simplified mesh is provided in the scene description. If a node according to the present principles has children, a recursive calculation is performed on the children's meshes. The "visibilityFull" value is propagated to the child nodes for visibility calculation. If an extension is present on a node, the associated parent and children of this node are not allowed to support the extension.

[0039] 3 shows an example architecture of an XR processing engine 30 that may be configured to execute the methods described herein. Devices according to the architecture of FIG. 3 are linked with other devices via their bus 31 and / or via I / O interfaces 36.

[0040] 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); - a 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.

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

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

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

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

[0045] By way of example, device 30 is configured to carry out methods according to the present principles and belongs to the set including a mobile device, a communications device, a gaming device, a tablet (or tablet computer), a laptop, a still camera, and a video camera.

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

[0047] An example of this node-level visibility extension to an MPEG-I scene description is provided below, where the fields introduced by the present principles are in bold. [Table 3] [Table 4] [Table 5]

Claims

1. 1. A method comprising: a description of an augmented reality scene, said description comprising: A scene graph that links the nodes; a trigger, a first node of said scene graph describing a camera; - obtaining a description that describes a first object and is associated with a second node of the scene graph, the description including a trigger, the trigger including first information indicating how visible the first object needs to be by the camera in order to activate the trigger; - triggering an action on a node of the scene graph when a condition of the first information is satisfied.

2. 2. The method of claim 1, wherein the first information is a percentage value indicating a portion of the first object that should be visible from the camera in order to activate the trigger, and the trigger is activated under the condition that at least the portion of the first object is visible by the camera.

3. 2. The method of claim 1, wherein the first information is a Boolean value, a true value indicating that the trigger is activated only if the first object is completely visible by the camera, and a false value indicating that the trigger is activated only if at least a portion of the first object is visible by the camera.

4. The method of claim 1 , wherein the first information is a numerical value indicating how many faces of a mesh representing the geometry of the first object must be visible to activate the trigger.

5. The method of any one of claims 1 to 4, wherein the second node includes second information indicating a list of third nodes describing second objects that should be ignored for the purposes of evaluating whether the first object is fully visible.

6. The method according to any one of claims 1 to 4, wherein the second node comprises second information indicating a list of third nodes describing second objects which should be taken into account for assessing whether the first object is fully visible.

7. The method according to any one of claims 1 to 6, wherein the second node includes third information indicating a mesh to use for evaluating whether the first object is fully visible.

8. 1. A device comprising a memory associated with a processor, the processor comprising: a description of an augmented reality scene, said description comprising: A scene graph that links the nodes; a trigger, a first node of said scene graph describing a camera; a trigger, the trigger being associated with a second node of the scene graph, the trigger describing a first object and including first information indicating how visible the first object needs to be by the camera to activate the trigger; a device configured to trigger an action on a node of said scene graph when a condition of said first information is satisfied;

9. 9. The device of claim 8, wherein the first information is a percentage value indicating a portion of the first object that should be visible from the camera in order to activate the trigger, and the trigger is activated under the condition that at least the portion of the first object is visible by the camera.

10. 9. The device of claim 8, wherein the first information is a Boolean value, a true value indicating that the trigger is activated only if the first object is completely visible by the camera and a false value indicating that the trigger is activated only if at least a portion of the first object is visible by the camera.

11. The device of claim 8 , wherein the first information is a numerical value indicating how many faces of a mesh representing the geometry of the first object must be visible to activate the trigger.

12. The device of any one of claims 8 to 11, wherein the second node includes second information indicating a list of third nodes describing second objects that should be ignored for the purposes of evaluating whether the first object is fully visible.

13. The device of any one of claims 8 to 11, wherein the second node includes second information indicating a list of third nodes describing second objects that should be taken into account for evaluating whether the first object is fully visible.

14. A device according to any one of claims 8 to 13, wherein the second node includes third information indicating a mesh to use for evaluating whether the first object is fully visible.

15. 1. A data stream carrying data representing a description of an augmented reality scene, said description comprising: - a scene graph that links the nodes; a trigger, a first node in the scene graph that describes a camera; a data stream including: a trigger that is associated with a second node of the scene graph, the second node describing a first object and including first information indicating how fully the first object needs to be visible by the camera in order to activate the trigger;

16. 16. The data stream of claim 15, wherein the first information is a percentage value indicating a portion of the first object that should be visible to the camera to activate the trigger.

17. 16. The data stream of claim 15, wherein the first information is a Boolean value, a true value indicating that the trigger is activated only if the first object is completely visible by the camera and a false value indicating that the trigger is activated only if at least a portion of the first object is visible by the camera.

18. 16. The data stream of claim 15, wherein the first information is a numerical value indicating how many faces of a mesh representing the geometry of the first object must be visible to activate the trigger.

19. 19. A data stream according to any one of claims 15 to 18, wherein the second node includes second information indicating a list of third nodes describing second objects that should be ignored for the purposes of assessing whether the first object is fully visible.

20. 19. A data stream according to any one of claims 15 to 18, wherein the second node comprises second information indicating a list of third nodes describing second objects which should be taken into account for assessing whether the first object is fully visible.

21. 21. A data stream according to any one of claims 15 to 20, wherein the second node includes third information indicating a mesh to use for evaluating whether the first object is fully visible.

Images