TriSoup triangle voxelization enhancements

Abstract

TriSoup triangles may be used to model point clouds. Some points may be missed when modeling point clouds using TriSoup triangles. The missed points may be recovered by identifying points that fall within the thickness of the TriSoup triangle (e.g., the volumetric region above and below the TriSoup triangle). The recovered points found within the thickness of the TriSoup triangle may be voxelized to ensure continuity of triangle-based modeling between TriSoup triangles.

Description

[Background technology]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 439,274, filed January 16, 2023. The above-referenced application is incorporated herein by reference in its entirety.

[0002] An object or scene can be described using volumetric visual data consisting of a series of points. The points can be stored in a point cloud format, which includes a collection of points in three-dimensional space. Because point clouds can be very large in data size, transmitting and processing point cloud data can require data compression schemes specifically designed for the unique characteristics of point cloud data. Summary of the Invention

[0003] The following summary provides a simplified overview of certain features. It is not an extensive overview and is not intended to identify key or critical elements.

[0004] Modeling the geometry of points may use a set of triangles as a local model (e.g., Triangle Soup method). Triangles may be voxelized by determining which voxels lie within the triangle. For example, rays may be used to determine whether a voxel lies within the triangle. During voxelization, occupied voxels may be missed in models that approximate occupied voxels. To provide continuity for triangles used in this TriSoup modeling method, it may be necessary to quantize the vertices of the triangle. Additional rays may be used to determine voxels at vertices that may be missed by using a single ray. However, as the number of rays increases, rendering speed may be reduced. A single ray and vector may be used to determine voxels within the thickness around the triangle without a corresponding decrease in rendering speed associated with using multiple rays. Voxels may be determined by adding and / or subtracting vectors to the intersection between the triangle and the ray.

[0005] These and other features and advantages are described in more detail below. [Brief explanation of the drawings]

[0006] Some examples of various embodiments of the present disclosure are described herein with reference to the drawings.

[0007] [Figure 1] 1 illustrates an exemplary point cloud encoding system. [Figure 2] 1 shows an exemplary Morton order. [Figure 3] 1 illustrates an exemplary scan order. [Figure 4] 1 shows an exemplary neighborhood of a cuboid with occupied bits already coded. [Figure 5] We present an example of a dynamic reduction function (DR) that can be used in Optimal Binary Coders with Dynamic Update on the Fly (OBUF). [Figure 6] 10 illustrates an exemplary method for encoding cuboid occupancy using dynamic OBUFs. [Figure 7] An example of an occupied rectangular parallelepiped is shown below. [Figure 8A] 1 shows an exemplary cuboid corresponding to a TriSoup node. [Figure 8B] 1 shows an exemplary refinement to the TriSoup model. [Figure 9] An example of voxelization is shown below. [Figure 10A] Here is an example of approximating a TriSoup triangle of occupied voxels. [Figure 10B] Here is an example of approximating a TriSoup triangle of occupied voxels. [Figure 11] Here are some examples of barycentric coordinates of points relative to a TriSoup triangle: [Figure 12A] An example of the halo method is shown. [Figure 12B] An example of the halo method is shown. [Figure 13] Here is an example of the halo method used for TriSoup triangles. [Figure 14] An example of a method for emitting a fine beam of light will be described. [Figure 15] An example using the halo method and the fine beam projection method is given. [Figure 16] Here is an example of how TriSoup can enhance the voxelization of triangles. [Figure 17] Here is an example of how TriSoup can enhance the voxelization of triangles. [Figure 18A] 1 illustrates an exemplary method for encoding a point cloud from a TriSoup triangle. [Figure 18B] 1 illustrates an exemplary method for encoding a point cloud from a TriSoup triangle. [Figure 19] FIG. 1 shows a block diagram of an exemplary computer system in which examples of the present disclosure may be implemented. [Figure 20] 1 illustrates exemplary elements of a computing device that may be used to implement any of the various devices described herein. DETAILED DESCRIPTION OF THE INVENTION

[0008] The accompanying drawings and description provide examples. It should be understood that the embodiments shown in the drawings and / or description are non-exclusive and that the features shown and described may be practiced in other embodiments. Examples are provided for the operation of a point cloud or point cloud sequence encoding or decoding system. More specifically, the techniques disclosed herein may relate to point cloud compression for use in encoding and / or decoding devices and / or systems.

[0009] At least some visual data may describe an object or scene using a series of points. Each point may include a two-dimensional (x and y) position and one or more optional attributes, such as color. Volumetric visual data may add another positional dimension to this visual data. For example, volumetric visual data may describe an object or scene using a series of points, each of which may include a three-dimensional (x, y, and z) position and one or more optional attributes, such as color, reflectance, timestamp, etc. Volumetric visual data may, for example, provide a more immersive way to experience the visual data than at least some visual data. For example, an object or scene described by volumetric visual data may be viewable from any angle(s), whereas at least some visual data is generally viewable only from the angle at which it was captured or rendered.

[0010] Volumetric visual data can be used in many applications, including augmented reality (AR), virtual reality (VR), and mixed reality (MR). Scattered volumetric visual data can be used in the automotive industry for the representation of three-dimensional (3D) maps (e.g., cartography) or as input to advanced driver assistance systems. For advanced driver assistance systems, volumetric visual data can typically be input to driving decision algorithms. Volumetric visual data can be used to store valuable objects in digital form. In applications for preserving cultural heritage, the goal can be to preserve representations of objects that may be threatened by natural disasters. For example, statues, vases, and temples can be scanned in their entirety and stored as volumetric visual data with billions of samples. This use case for volumetric visual data can be particularly relevant for valuable objects in locations where earthquakes, tsunamis, and typhoons occur frequently. Volumetric visual data can take the form of volumetric frames. A volumetric frame can describe an object or scene captured at a specific time instance. Volumetric visual data may take the form of a sequence of volumetric frames (called a volumetric sequence or volumetric video), which may describe an object or scene captured at multiple different instances in time.

[0011] Volumetric visual data can be stored in various formats. A point cloud is one format for storing volumetric visual data. A point cloud can include a collection of points in 3D space. Each point in the point cloud can include geometric information that can indicate the point's location in 3D space. For example, the geometric information can indicate the point's location in 3D space using, for example, three Cartesian coordinates (x, y, and z) and / or using spherical coordinates (r, phi, theta) (e.g., when acquired by a rotational sensor). The locations of points in a point cloud can be quantified according to spatial precision. The spatial precision can be the same or different in each dimension. A quantization process can generate a grid in 3D space. One or more points residing within each subgrid volume can be mapped to subgrid center coordinates called voxels. A voxel can be considered a 3D extension of a pixel corresponding to a 2D image grid coordinate. A point in a point cloud can include one or more types of attribute information. The attribute information can indicate characteristics of the point's visual appearance. For example, the attribute information may indicate the texture (e.g., color) of the point, the material type of the point, transparency information of the point, reflectance information of the point, a normal vector to the surface of the point, the velocity of the point, the acceleration at the point, a timestamp indicating when the point was captured, or a modality (e.g., running, walking, or flying) indicating how the point was captured. Points in the point cloud may include light field data in the form of multiple view-dependent texture information. The light field data may be another type of arbitrary attribute information.

[0012] The points in the point cloud may describe an object or scene. For example, the points in the point cloud may describe the exterior surface and / or interior structure of the object or scene. The object or scene may be synthetically generated by a computer. The object or scene may be generated from capturing a real-world object or scene. Geometry information of a real-world object or scene may be obtained by 3D scanning and / or photogrammetry. 3D scanning may include different types of scanning, such as laser scanning, structured light scanning, and / or modulated light scanning. 3D scanning may obtain the geometry information. 3D scanning may obtain the geometry information, for example, by moving one or more laser heads, structured light cameras, and / or modulated light cameras relative to the object or scene being scanned. Photogrammetry may obtain the geometry information. Photogrammetry may obtain the geometry information, for example, by triangulating the same features or points in different spatially shifted 2D photographs. Point cloud data may take the form of a point cloud frame. A point cloud frame may describe an object or scene captured at a particular time instance. Point cloud data may take the form of a sequence of point cloud frames, which may be referred to as a point cloud sequence or a point cloud video, which may describe an object or scene captured at multiple different instances of time.

[0013] The data size of a point cloud frame or point cloud sequence may be excessive (e.g., too large) for storage and / or transmission in many applications. For example, a single point cloud may include more than one million points, or even more than one billion points. Each point may include geometric information and one or more types of attribute information. The geometric information for each point may include, for example, three Cartesian coordinates (x, y, and z) and / or spherical coordinates (r, phi, theta), each of which may be represented using at least 10 bits per component or a total of 30 bits. The attribute information for each point may include texture corresponding to multiple (e.g., three) color components (e.g., R, G, and B color components). Each color component may be represented using, for example, 8 to 10 bits per component or a total of 24 to 30 bits. For example, a single point may include at least 54 bits of information, with at least 30 bits of geometric information and at least 24 bits of texture. If a point cloud frame contains 1 million such points, each point cloud frame may require 54 million bits or 54 megabits to represent. For a dynamic point cloud that changes over time, a data rate of 1.32 gigabits per second may be required to transmit (e.g., transmit) the points of a point cloud sequence at a frame rate of 30 frames per second. The raw representation of a point cloud may require a large amount of data, and practical deployment of point cloud-based technologies may require compression techniques that enable the storage and distribution of point clouds at a reasonable cost.

[0014] Encoding may be used to compress and / or reduce the data size of a point cloud frame or point cloud sequence to provide more efficient storage and / or transmission. Decoding may be used to decompress a compressed point cloud frame or point cloud sequence for display and / or other forms of consumption (e.g., by a machine learning-based device, a neural network-based device, an artificial intelligence-based device, or other types of machine-based processing algorithms and / or devices). Compression of the point cloud may be lossy (introducing differences to the original data) for distribution to and visualization by an end user, for example, on AR or VR glasses or any other 3D-enabled device. Lossy compression may enable high compression ratios but may imply a trade-off between compression and visual quality perceived by the end user. Other frameworks, such as those for medical applications or autonomous driving, may require lossless compression to avoid, for example, transmitting (e.g., transmitting) and altering the results of decisions made based on analysis of the decompressed point cloud frames.

[0015] 1 illustrates an exemplary point cloud encoding (e.g., encoding and / or decoding) system 100. The point cloud encoding system 100 may include a source device 102, a transmission medium 104, and a destination device 106. The source device 102 may encode a point cloud sequence 108 into a bitstream 110 for more efficient storage and / or transmission. The source device 102 may store and / or transmit (e.g., transmit) the bitstream 110 to the destination device 106 via the transmission medium 104. The destination device 106 may decode the bitstream 110 to display the point cloud sequence 108 or for other forms of consumption (e.g., further analysis, storage, etc.). The destination device 106 may receive the bitstream 110 from the source device 102 via the storage medium or transmission medium 104. The source device 102 and the destination device 106 may include any number of different devices. The source device 102 and the destination device 106 may include, for example, a cluster of interconnected computer systems acting as a seamless pool of resources (also called a cloud of computers or cloud computing), a server, a desktop computer, a laptop computer, a tablet computer, a smartphone, a wearable device, a television, a camera, a video game console, a set-top box, a video streaming device, a vehicle (e.g., an autonomous vehicle), or a head-mounted display. The head-mounted display may allow a user to view a VR, AR, or MR scene and, for example, adjust the view of the scene based on the user's head movements. The head-mounted display may be connected (tethered) to a processing device (e.g., a server, desktop computer, set-top box, or video game console) or may be completely self-contained.

[0016] The source device 102 may include a point cloud source 112, an encoder 114, and an output interface 116. The source device 102 may include, for example, the point cloud source 112, the encoder 114, and the output interface 116 for encoding the point cloud sequence 108 into a bitstream 110. The point cloud source 112 may provide (or generate) the point cloud sequence 108, for example, from the capture of natural and / or synthetically generated scenes. The synthetically generated scenes may be scenes including computer-generated graphics. The point cloud source 112 may include one or more point cloud capture devices, a point cloud archive containing previously captured natural and / or synthetically generated scenes, a point cloud feed interface for receiving captured natural and / or synthetically generated scenes from a point cloud content provider, and / or a processor for generating the synthesized point cloud scene. The point cloud capture device may include, for example, one or more laser scanning devices, structured light scanning devices, modulated light scanning devices, and / or passive scanning devices.

[0017] A point cloud sequence 108 may include a series of point cloud frames 124 (e.g., the example shown in FIG. 1 ). A point cloud frame may describe an object or scene captured at a particular time instance. The point cloud sequence 108 may achieve the impression of motion by sequentially presenting the point cloud frames 124 of the point cloud sequence 108 using a constant or variable time. A point cloud frame may include a collection of points (e.g., voxels) 126 in 3D space. Each point 126 may include geometric shape information that may indicate the point's location in 3D space. The geometric shape information may indicate the point's location in 3D space using, for example, three Cartesian coordinates (x, y, and z). One or more of the points 126 may include one or more types of attribute information. The attribute information may indicate characteristics of the point's visual appearance. For example, the attribute information may indicate, for example, the texture (e.g., color) of the point, the material type of the point, transparency information of the point, reflectance information of the point, a normal vector relative to the surface of the point, the velocity of the point, the acceleration at the point, a timestamp indicating when the point was captured, a modality indicating how the point was captured (e.g., running, walking, or flying), etc. One or more of the points 126 may include light field data, for example, in the form of multiple view-dependent texture information. The light field data may be any other type of attribute information. The color attribute information of one or more of the points 126 may include a luminance value and two color difference values. The luminance value may represent the luminance (e.g., luma component, Y) of the point. The color difference values ​​may represent the blue and red components (e.g., chroma components, Cb and Cr) of the point, respectively, separate from its brightness. The other color attribute values ​​may be represented, for example, based on a different color scheme (e.g., RGB or monochrome color scheme).

[0018] The encoder 114 may encode the point cloud sequence 108 into a bitstream 110. To encode the point cloud sequence 108, the encoder 114 may use one or more lossless or lossy compression techniques to reduce redundant information in the point cloud sequence 108. To encode the point cloud sequence 108, the encoder 114 may use one or more prediction techniques to reduce redundant information in the point cloud sequence 108. Redundant information is information that can be predicted at the decoder 120 and may not need to be sent (e.g., transmitted) to the decoder 120 for accurate decoding of the point cloud sequence 108. For example, the Motion Picture Expert Group (MPEG) introduced the Geometry-Based Point Cloud Compression (G-PCC) standard (ISO / IEC Standard 23090-9: Geometry-Based Point Cloud Compression). G-PCC specifies encoded bitstream syntax and semantics for transmission and / or storage of compressed point cloud frames, as well as decoder operations for reconstructing compressed point cloud frames from the bitstream. During the standardization of G-PCC, reference software (ISO / IEC Standard 23090-21: Reference Software for G-PCC) was developed to encode the geometric shape and attribute information of a point cloud frame. To encode the geometric shape information of a point cloud frame, the G-PCC reference software encoder may perform voxelization. The G-PCC reference software encoder may perform voxelization, for example, by quantifying the positions of points within a point cloud. Quantifying the positions of points within a point cloud may generate a grid in 3D space. The G-PCC reference software encoder may map points to the center coordinates of sub-grid volumes (e.g., voxels) within which their quantized positions reside. The G-PCC reference software encoder may perform geometric shape analysis using an occupancy tree to compress the geometric shape information. The G-PCC reference software encoder may entropy encode the results of the geometric shape analysis to further compress the geometric shape information.To encode the point cloud attribute information, the G-PCC reference software encoder may use transform tools such as a region-adaptive hierarchical transform (RAHT), a predictive transform, and / or a lifting transform. The lifting transform may be built on top of the predictive transform. The lifting transform may include an additional update / lifting step. The lifting transform and the predictive transform may also be referred to as a predictive / lifting transform or a "pred lift." The encoder 114 may operate in the same or similar manner as the encoder provided by the G-PCC reference software.

[0019] The output interface 116 may be configured to write and / or store the bitstream 110 on the transmission medium 104. The bitstream 110 may be sent (e.g., transmitted) to the destination device 106. Additionally or alternatively, the output interface 116 may be configured to send (e.g., transmit), upload, and / or stream the bitstream 110 to the destination device 106 via the transmission medium 104. The output interface 116 may include a wired and / or wireless transmitter configured to send (e.g., transmit), upload, and / or stream the bitstream 110 according to one or more proprietary, open source, and / or standardized communication protocols. The one or more proprietary, open source, and / or standardized communication protocols may include, for example, Digital Video Broadcasting (DVB) standards, Advanced Television Systems Committee (ATSC) standards, Integrated Services Digital Broadcasting (ISDB) standards, Data Over Cable Service Interface Specification (DOCSIS) standards, 3rd Generation Partnership Project (3GPP®) standards, Institute of Electrical and Electronics Engineers (IEEE) standards, Internet Protocol (IP) standards, Wireless Application Protocol (WAP) standards, and / or any other communication protocols.

[0020] Transmission medium 104 may include wireless, wired, and / or computer-readable media. For example, transmission medium 104 may include one or more wires, cables, air interfaces, optical disks, flash memory, and / or magnetic memory. Additionally or alternatively, transmission medium 104 may include one or more networks (e.g., the Internet) or file servers configured to store and / or transmit (e.g., transmit) encoded video data.

[0021] The destination device 106 may decode the bitstream 110 into a point cloud sequence 108 for display or other consumption. The destination device 106 may include one or more of an input interface 118, a decoder 120, and / or a point cloud display 122. The input interface 118 may be configured to read the bitstream 110 stored on the transmission medium 104. The bitstream 110 may be stored on the transmission medium 104 by the source device 102. Additionally or alternatively, the input interface 118 may be configured to receive, download, and / or stream the bitstream 110 from the source device 102 over the transmission medium 104. The input interface 118 may include a wired and / or wireless receiver configured to receive, download, and / or stream the bitstream 110 according to one or more proprietary, open source, standardized communication protocols, and / or any other communication protocol. Examples of protocols include the Digital Video Broadcasting (DVB) standard, the Advanced Television Systems Committee (ATSC) standard, the Integrated Services Digital Broadcasting (ISDB) standard, the Data Over Cable Service Interface Specification (DOCSIS) standard, the 3rd Generation Partnership Project (3GPP®) standard, the Institute of Electrical and Electronics Engineers (IEEE) standard, the Internet Protocol (IP) standard, and the Wireless Application Protocol (WAP) standard.

[0022] The decoder 120 may decode the point cloud sequence 108 from the encoded bitstream 110. For example, the decoder 120 may operate in the same or similar manner as the decoder provided by the G-PCC reference software. The decoder 120 may decode a point cloud sequence that approximates the point cloud sequence 108. The decoder 120 may decode a point cloud sequence that approximates the point cloud sequence 108 due to, for example, lossy compression of the point cloud sequence 108 by the encoder 114 and / or errors introduced into the encoded bitstream 110 when transmission to, for example, the destination device 106 occurred.

[0023] The point cloud display 122 may display the point cloud sequence 108 to a user. The point cloud display 122 may include, for example, a cathode ray tube (CRT) display, a liquid crystal display (LCD), a plasma display, a light emitting diode (LED) display, a 3D display, a holographic display, a head-mounted display, or any other display device suitable for displaying the point cloud sequence 108.

[0024] The point cloud encoding (e.g., encoding / decoding) system 100 is presented by way of example and not limitation. Point cloud encoding systems other than the point cloud encoding system 100 and / or modified versions of the point cloud encoding system 100 may implement the methods and processes as described herein. For example, the point cloud encoding system 100 may include other components and / or arrangements. The point cloud source 112 may be external to the source device 102, for example. The point cloud display device 122 may be external to the destination device 106, for example, or may be omitted entirely (e.g., if the point cloud sequence 108 is intended for consumption by a machine and / or a storage device). The source device 102 may further comprise, for example, a point cloud decoder. The destination device 106 may comprise, for example, a point cloud encoder. For example, the source device 102 may be configured to further receive an encoded bitstream from the destination device 106. Receiving the encoded bitstream from the destination device 106 may support bidirectional point cloud transmission between the devices.

[0025] As described herein, the encoder may quantify the location of points within a point cloud according to spatial precision, which may be the same or different in each dimension of the points. The quantization process may generate a grid in 3D space. The encoder may map any point that resides within each subgrid volume to a subgrid center coordinate, called a voxel or volume pixel. A voxel may be considered a 3D extension of a pixel that corresponds to a 2D image grid coordinate.

[0026] The encoder may represent or encode the voxelized point cloud. The encoder may represent or encode the voxelized point cloud using, for example, an occupancy tree. For example, the encoder may divide an initial volume or cuboid containing the voxelized point cloud into sub-cuboids. The initial volume or cuboid may be referred to as a bounding box. The cuboid may be, for example, a cube. The encoder may recursively divide each sub-cuboid that contains at least one point of the point cloud. The encoder may not further divide a sub-cuboid that does not contain at least one point of the point cloud. A sub-cuboid that contains at least one point of the point cloud may be referred to as an occupied sub-cuboid. A sub-cuboid that does not contain at least one point of the point cloud may be referred to as an unoccupied sub-cuboid. The encoder may divide an occupied sub-cuboid into, for example, two sub-cuboids (to form a binary tree), four sub-cuboids (to form a quadtree), or eight sub-cuboids (to form an octree). The encoder may split the occupied sub-cuboid to obtain further sub-cuboids. The sub-cuboids may have the same size and shape at a given depth level of the occupancy tree. For example, the sub-cuboids may have the same size and shape at a given depth level of the occupancy tree if the encoder splits the occupied sub-cuboid along a plane that passes through the center of the edges of the sub-cuboid.

[0027] The initial volume or cuboid containing the voxelized point cloud may correspond to the root node of the occupancy tree. Each occupied subcuboid split from the initial volume may correspond to a node (of the root node) at a second level of the occupancy tree. Each occupied subcuboid split from an occupied subcuboid at the second level may correspond to a node at a third level of the occupancy tree (the node off the occupied subcuboid at the second level from which it was split). The occupancy tree structure may continue to be formed in this manner for each recursive splitting iteration, for example, until some maximum depth level of the occupancy tree is reached or until each occupied subcuboid has a volume corresponding to one voxel.

[0028] Each non-leaf node in the occupancy tree may include or be associated with an occupancy word that represents the occupancy state of the cuboid corresponding to the node. For example, a node in the occupancy tree corresponding to a cuboid divided into eight sub-cuboids may include or be associated with a one-byte occupancy word. Each bit (called an occupancy bit) of the one-byte occupancy word may represent or indicate the occupancy of a different one of the eight sub-cuboids. Each occupied sub-cuboid may be represented or indicated by a binary "1" in the one-byte occupancy word. Each unoccupied sub-cuboid may be represented or indicated by a binary "0" in the one-byte occupancy word. Occupied and unoccupied sub-cuboids may be represented or indicated by opposite one-bit binary values ​​in the one-byte occupancy word (e.g., a binary "0" representing or indicating an occupied sub-cuboid and a binary "1" representing or indicating an unoccupied sub-cuboid).

[0029] Each bit of the occupancy word may represent or indicate the occupancy of a different one of the eight sub-rectangles. Each bit of the occupancy word may represent or indicate the occupancy of a different one of the eight sub-rectangles, for example, according to the so-called Morton order. For example, the least significant bit of the occupancy word may represent or indicate the occupancy of, for example, a first sub-rectangle of the eight sub-rectangles, for example, according to Morton order. The second least significant bit of the occupancy word may represent or indicate the occupancy of, for example, a second sub-rectangle of the eight sub-rectangles, for example, according to Morton order, etc.

[0030] 2 shows an exemplary Morton order. More specifically, FIG. 2 shows the Morton order of eight sub-rectangles 202-216 divided from a rectangular prism 200. The sub-rectangles 202-216 may be labeled based on their Morton order, for example, with the child node 202 being first in the Morton order and the child node 216 being last in the Morton order. The Morton order for the sub-rectangles 202-216 may be a local lexicographic order in xyz.

[0031] The voxelized point cloud geometry may be represented by and determined from the initial volumes and occupancy words of the nodes in the occupancy tree. The encoder may send (e.g., transmit) the initial volumes and occupancy words of the nodes in the occupancy tree in a bitstream to a decoder to reconstruct the point cloud. The encoder may entropy encode the occupancy words. For example, the encoder may entropy encode the occupancy words before sending (e.g., transmitting) the initial volumes and occupancy words of the nodes in the occupancy tree. The encoder may encode occupancy bits of the occupancy words of the nodes corresponding to the cuboid. For example, the encoder may encode occupancy bits of the occupancy words of the nodes corresponding to the cuboid based on one or more occupancy bits of the occupancy words of other nodes corresponding to cuboids that are adjacent to or spatially close to the cuboid of the occupancy bits being encoded.

[0032] The encoder and / or decoder may encode (e.g., encode and / or decode) occupied bits of consecutive occupied words in scan order. Scan order may also be referred to as scanning order. For example, the encoder and / or decoder may scan the occupation tree in breadth-first order. All occupied words of nodes at a given depth (e.g., level) in the occupation tree may be scanned. All occupied words of nodes at a given depth (e.g., level) in the occupation tree may be scanned before scanning occupied words of nodes at the next depth (e.g., level). Within a given depth, the encoder and / or decoder may scan occupied words of nodes in Morton order. Within a given node, the encoder and / or decoder may also scan occupied bits of occupied words of the node in Morton order.

[0033] FIG. 3 illustrates an exemplary scan order. FIG. 3 illustrates an example scan order (e.g., breadth-first order as described herein) of an occupancy tree 300. More specifically, FIG. 3 illustrates an exemplary scan order of the first three levels of the occupancy tree 300. In FIG. 3, a cuboid (e.g., cube) 302 corresponding to the root node of the occupancy tree 300 may be divided into eight sub-cuboids (e.g., sub-cubes). Two sub-cuboids 304 and 306 of the eight sub-cuboids may be occupied. The other six sub-cuboids of the eight sub-cuboids may be unoccupied. According to Morton order, the first 8-bit occupancy word (e.g., occW 1,1 ) can be constructed to represent the occupation word of the root node. The first 8 bits of the occupation word (e.g., occW 1,1 ) may represent or indicate the occupation of a subcube of the eight subcubes in the Morton order. For example, the first 8-bit occupation word occW 1,1 The least significant occupancy bit of the first 8-bit occupancy word occW represents or may indicate the occupancy of the first of the 8 sub-cuboids in Morton order. 1,1 The second least significant occupied bit of may represent or indicate the occupancy of the second of the eight sub-cuboids in Morton order.

[0034] Each of the occupied subcubes (e.g., two occupied subcubes 304 and 306) may correspond to a node from the root node of the second-level occupancy tree 300. Each of the occupied subcubes (e.g., two occupied subcubes 304 and 306) may be further divided into eight subcubes. For example, one of the subcubes 308 of the eight subcubes divided from subcube 304 may be occupied, while the other seven subcubes may be unoccupied. Three of the eight subcubes divided from subcube 306, namely, subcubes 310, 312, and 314, may be occupied, while the other five subcubes of the eight subcubes divided from subcube 306 may be unoccupied. Two second 8-bit occupancy words occW 2,1 and occW 2,2may be constructed in this order to represent the occupancy words of the nodes corresponding to sub-cuboid 304 and sub-cuboid 306, respectively.

[0035] Each of the occupied sub-cuboids (e.g., four occupied sub-cuboids 308, 310, 312, and 314) may correspond to a node in the third-level occupancy tree 300. Each of the occupied sub-cuboids (e.g., four occupied sub-cuboids 308, 310, 312, and 314) may be further divided into a total of eight sub-cuboids or 32 sub-cuboids. For example, four third-level 8-bit occupied words occW 3,1 , occW 3,2 , occW 3,3 , and occW 3,4 may be constructed in this order to represent the occupancy words of the nodes corresponding to sub-cuboid 308, the occupancy words of the nodes corresponding to sub-cuboid 310, the occupancy words of the nodes corresponding to sub-cuboid 312, and the occupancy words of the nodes corresponding to sub-cuboid 314, respectively.

[0036] The occupancy words of the exemplary occupancy tree 300 may be entropy encoded (e.g., entropy encoded by an encoder and / or entropy decoded by a decoder) according to, for example, a scan order (e.g., Morton order) described herein. The occupancy words of the exemplary occupancy tree 300 may be entropy encoded (e.g., entropy encoded by an encoder and / or entropy decoded by a decoder) according to, for example, a scan order (e.g., Morton order) described herein. 1,1 ~occW 3,4The scan order described herein may be a breadth-first scan order. The occupied words of all nodes having the same depth (or level) as the current parent node may already be entropy encoded, for example, if the occupied words of the current child node belonging to the current parent node have been entropy encoded. For example, the occupied words of all nodes having the same depth (e.g., level) as the current child node and having a lower Morton order than the current child node may also already be entropy encoded. Some of the already encoded occupied words may be used to entropy encode the occupied words of the current child node. The already encoded occupied words of adjacent parent and child nodes may be used, for example, to entropy encode the occupied words of the current child node. The occupied bits of the occupied word having a lower Morton order than the particular occupied bit may also already be entropy coded and may be used to code the occupied bit of the occupied word of the current child node, for example, when the particular occupied bit of the occupied word of the current child node has been coded (e.g., entropy coded).

[0037] 4 illustrates exemplary neighborhoods of cuboids for entropy encoding the occupancy of a child cuboid. More specifically, FIG. 4 illustrates exemplary neighborhoods of cuboids with already-coded occupancy bits. The neighborhoods of cuboids with already-coded occupancy bits can be used to entropy encode the occupancy bits of a current child cuboid 400. The neighborhoods of cuboids with already-coded occupancy bits can be determined, for example, based on a scan order of an occupancy tree representing the geometry of the cuboids of FIG. 4 as discussed herein. For a current child cuboid, the cuboid neighbors may include one or more of: a cuboid close to the current child cuboid, a cuboid sharing a vertex with the current child cuboid, a cuboid sharing an edge with the current child cuboid, a cuboid sharing a face with the current child cuboid, a parent cuboid close to the current child cuboid, a parent cuboid sharing a vertex with the current child cuboid, a parent cuboid sharing an edge with the current child cuboid, a parent cuboid sharing a face with the current child cuboid, a parent cuboid close to the current parent cuboid, a parent cuboid sharing a vertex with the current parent cuboid, a parent cuboid sharing an edge with the current parent cuboid, a parent cuboid sharing a face with the current parent cuboid, etc. As shown in FIG. 4 , a current child cuboid 400 may belong to a current parent cuboid 402. According to the scan order of the occupancy words and occupancy bits of the nodes of the occupancy tree, the occupancy bits of the four child cuboids 404, 406, 408, and 410 belonging to the same current parent cuboid 402 may have already been coded. The occupancy bits of the child cuboid 412 of the preceding parent cuboid may have already been coded. The occupancy bits of the parent cuboid 414, whose occupancy bits have not yet been coded, may have already been coded. The occupancy bits of the current child cuboid 400 may be coded using the occupancy bits already coded of the cuboids 404, 406, 408, 410, 412, and 414.

[0038] The number (e.g., quantity) of possible occupancy configurations (e.g., sets of one or more occupancy words and / or occupancy bits) for the neighbors of the current child cuboid is 2 Nwhere N is the number (e.g., quantity) of cuboids in the neighborhood of the current child cuboid that have already coded occupancy bits. The neighborhood of the current child cuboid may include tens of cuboids. The neighborhood of the current child cuboid (e.g., tens of cuboids) may include 26 neighboring parent cuboids that share faces, edges, and / or vertices with the parent cuboid of the current child cuboid, as well as several neighboring child cuboids that also share faces, edges, or vertices with the current child cuboid and have already coded occupancy bits. The occupancy configuration of the neighborhood of the current child cuboid may be limited to a subset of neighboring cuboids or may have billions of possible occupancy configurations, making its direct use impractical. The encoder and / or decoder may use the occupancy configurations for the neighborhood of the current child cuboid to select a context (e.g., a probability model) from a set of contexts of a binary entropy coder (e.g., a binary arithmetic coder) that can code the occupancy bits of the current child cuboid. Context-based binary entropy coding may be similar to the context-adaptive binary arithmetic coder (CABAC) used in MPEG-H Part 2 (also known as High Efficiency Video Coding (HEVC)).

[0039] The encoder and / or decoder may use several methods to reduce the adjacent occupancy configuration of the current child cuboid to be encoded to a practical number (e.g., quantity) of reduced occupancy configurations. 6 That is, 64 occupancy configurations can be reduced to 9 occupancy configurations. Occupancy configurations can be reduced by using geometric invariants. The occupancy score of the current child cuboid is 2x the occupancy score of the 26 neighboring parent cuboids. 26 A score can be obtained from the occupancy configurations. The score can be further reduced to a ternary occupancy prediction (e.g., "predicted-occupied," "uncertain," or "predicted-unoccupied") by using a score threshold. The number (e.g., quantity) of nearby occupied child cuboids and the number (e.g., quantity) of nearby unoccupied child cuboids can be used instead of the individual occupancies of these child cuboids.

[0040] An encoder and / or decoder using / employing one or more of the methods described herein may reduce the number (e.g., quantity) of possible occupancy configurations for the neighbors of the current child cuboid to a more manageable number (e.g., several thousand). It has been observed that instead of directly associating the reduction in the number (e.g., quantity) of contexts (e.g., probability models) with the reduction in occupancy configurations, another mechanism, namely, OBUF (Optimal Binary Coders with Update on the Fly), may be used. The encoder and / or decoder may implement OBUF to limit the number (e.g., quantity) of contexts to a lower number (e.g., 32 contexts).

[0041] The OBUF may use a limited number (e.g., 32) of contexts (e.g., probability models). The number (e.g., quantity) of contexts in the OBUF may be a fixed number (e.g., a fixed quantity). The contexts used by the OBUF may be ordered and referenced by a context index (e.g., a context index ranging from 0 to 31), and a "1" may be encoded from the lowest to the highest hypothetical probability. A context index lookup table (LUT) may be initialized at the beginning of the point cloud encoding process. For example, the LUT may initially point to a context (e.g., having a context index of 15) that has the median hypothetical probability for encoding a "1" for all inputs. The LUT may initially point to a context that has the median hypothetical probability for encoding a "1" among the limited number (e.g., quantity) of contexts for all inputs. This LUT may take the occupancy configuration of the current child cuboid's neighbors as input and output a context index associated with the occupancy configuration. The LUT may have the same number of entries as the reduced occupancy configuration (e.g., approximately several thousand entries). Encoding the occupancy bit of the current child cuboid may include steps including, for example, determining a reduced occupancy configuration of the current child node based on the value of the encoded occupancy bit of the current child cuboid, obtaining a context index by using the reduced occupancy configuration as an entry into the LUT, encoding the occupancy bit of the current child cuboid by using the context pointed to (or indicated) by the context index, and updating the LUT entry corresponding to the reduced occupancy configuration. For example, if a binary "0" (e.g., indicating that the current child cuboid is unoccupied) is encoded, the LUT entry may be decreased to a lower context index value. For example, if a binary "1" (e.g., indicating that the current child cuboid is occupied) is encoded, the LUT entry may be increased to a higher context index value.The context index update process may be based, for example, on a theoretical model of optimal distribution for hypothetical probabilities associated with a limited number (e.g., quantity) of contexts. The hypothetical probabilities may be fixed by the model and may differ from the internal probabilities of the contexts, which may evolve, for example, when encoding bits of data. The evolution of the internal contexts may follow a well-known process similar to that of CABAC.

[0042] The encoder and / or decoder may implement a “dynamic OBUF” scheme. The “dynamic OBUF” scheme may, for example, enable the encoder and / or decoder to handle a much larger number (e.g., quantity) of occupancy configurations for the neighbors of the current child cuboid than a typical OBUF. Using a larger number (e.g., quantity) of occupancy configurations for the neighbors of the current child cuboid may result in improved compression performance and may keep complexity within a reasonable range. By using an occupancy tree compressed by an OBUF, the encoder and / or decoder may achieve lossless compression performance as good as 1 bit per point (bpp) for encoding dense point cloud geometry. The encoder and / or decoder may implement a dynamic OBUF to further reduce the bitrate, potentially by more than 25%, down to 0.7 bpp.

[0043] The OBUF may not take as input a wide variety of reduced occupancy configurations for the neighbors of the current child cuboid, potentially resulting in the loss of useful correlations. The OBUF may increase the size of the context index LUT to handle a greater variety of occupancy configurations as input than for the neighbors of the current child cuboid. Such an increase may dilute statistics and worsen compression performance. For example, if the LUT has millions of entries and the point cloud has hundreds of thousands of points, most entries may not be visited (e.g., looked up, accessed, etc.). Many entries may be visited only a few times, and their associated context indexes may not be updated enough times to reflect any meaningful correlation between occupancy configuration values ​​and the occupancy probability of the current child cuboid. A dynamic OBUF may be implemented to mitigate the dilution of statistics due to an increase in the number (e.g., quantity) of occupancy configurations for the neighbors of the current child cuboid. This mitigation may be achieved by “dynamic shrinking” of occupancy configurations in the dynamic OBUF.

[0044] A dynamic OBUF may add an additional step of shrinking the neighboring occupancy configurations of the current child cuboid before using the context index LUT, for example. This step may be called dynamic shrinking because it evolves based on, for example, the progress of the point cloud encoding, or more precisely, based on the occupancy configurations already visited (e.g., looked up in the LUT).

[0045] As discussed herein, many possible occupancy configurations for the neighbors of the current child cuboid may potentially be involved, but only a subset may be visited when point cloud encoding occurs. This subset may characterize the type of point cloud. For example, most of the visited occupancy configurations may indicate occupied neighboring cuboids of the current child cuboid, for example, when an AR or VR dense point cloud is encoded. On the other hand, most of the visited occupancy configurations may indicate only a few occupied neighboring cuboids of the current child cuboid, for example, when a sparse point cloud acquired by a sensor is encoded. The role of dynamic shrinking may be, for example, to obtain more accurate correlation based on the most frequently visited occupancy configurations while refraining from (e.g., actively reducing) other occupancy configurations that are much less frequently visited. Dynamic shrinking may be updated on the fly. Dynamic shrinking may be updated on the fly, for example, after each visit of an occupancy configuration (e.g., lookup in a LUT) when occupancy data encoding occurs.

[0046] 5 shows an example of a dynamic shrinking function DR that can be used in a dynamic OBUF. The dynamic shrinking function DR is a function of bit β of the occupancy configuration 500. j can be obtained by masking β=β1...β K It consists of K bits. The size of the mask can be reduced, for example, if the occupancy configuration is visited (e.g., looked up in a LUT) a certain number of times (e.g., a certain number). The initial dynamic reduction function DR 0 is a constant function DR for all occupancy configurations β 0 All bits may be masked for all occupancy configurations so that (β)=0. The dynamic reduction function is the function DR n Updated function from DR n+1 The dynamic shrinking function may evolve into, for example, a function DR n Updated function from DR n+1 The function can evolve to β'=DR n (β)=β1...β kn(β) where k n(β) 510 is the number of unmasked bits (e.g., quantity). 0 The initialization of k(β) may correspond to k0(β)=0, and the natural evolution of the shrinkage function for finer statistics is the increase in the number of unmasked bits (e.g., quantity) k n (β)≦k n+1 (β). The dynamic shrinkage function is k for all occupancy configurations β. n can be completely determined by the value of

[0047] A visit to an occupied configuration (e.g., an instance of a lookup in the LUT) is performed for all dynamically reduced occupied configurations β'=DR n (β) can be tracked by a variable NV(β'). The corresponding number (e.g., quantity) of visits NV(β V ') is, for example, the occupied configuration β V After each instance of encoding the occupancy bits based on , the number (e.g., quantity) of visits NV(β V ') is the threshold th V If it is greater than NV(β V ')>th V Next, the number of unmasked bits (e.g., quantity) k n (β) is β V ' can be increased by 1 for every occupancy configuration that dynamically shrinks to '. This means that the dynamically reduced occupancy configuration β V ' into a dynamically reduced new two-occupancy configuration β defined by the following equation: 0 ' and β 1 ' corresponds to replacing it with '. β 0 '=β V '0=β V 1...β V kn(β) 0, and β 1 '=β V '1=β V 1...β V kn(β) 1 In other words, the number of unmasked bits (e.g., quantity) is DR n(β)=β V ', k for all occupancy configurations β n+1 (β)=k n (β)+1, which is an increase of 1. The number of visits (e.g., quantity) of the new dynamically reduced two-occupancy configuration may be initialized to zero. NV(β 0 ')=NV(β 1 ')=0 (I) At the beginning of encoding, an initial dynamic reduction function DR 0 The initial number (e.g., quantity) of visits may be set as follows: NV(DR 0 (β))=NV(0)=0 The evolution of NVs in dynamically reduced occupancy configurations can be fully defined.

[0048] The corresponding LUT entry LUT[β V '] is β V ' and two new entries LUT[β 0 '] and LUT[β 1 ']. The corresponding LUT entry LUT[β V '] is, for example, the dynamically reduced occupancy configuration β V ' is dynamically reduced to a new two-occupancy configuration β 0 ' and β 1 ', then β V Two new entries LUT[β 0 '] and LUT[β 1 '], LUT[β 0 ']=LUT[β 1 ']=LUT[β V '] (II) They are then evolved separately. The evolution of the coder index LUT on the dynamically reduced occupancy configuration can be fully defined.

[0049] Reduction Function DR n is the occupancy configuration β'=DR in which the leaf node 530 is reduced.n (β) is a set of growing binary trees T n 520. The initial tree can be modeled by 0=DR 0 There can be a single root node associated with (β). 0 ' and β 1 ' by β V The replacement of the dynamically reduced β 0 ' and β 1 ' and attach two new nodes associated with it, V ' to the leaf node associated with the tree T n It can be used to grow a tree. n+1 can be obtained by this growth. The number of visits (e.g., quantity), NV, and LUT of context indexes are defined on the leaf nodes and can evolve with the growth of the tree through equations (I) and (II).

[0050] A practical implementation of the dynamic OBUF is to use the arrays NV[β'] and LUT[β'] of context indices and the tree T n 520. An alternative to storing the tree is to store an array k of the number of unmasked bits (e.g., quantity). n [β] 510 can be stored.

[0051] A limitation for implementing a dynamic OBUF may be its memory footprint. In some applications, millions of occupied configurations are actually processed, and the approximately 20-bit β i Each bit β i may correspond to the occupancy of the neighboring cubes of the current child cube, or to the set of neighboring cubes of the current child cube.

[0052] The higher (e.g., more significant) bit β i (e.g., β0, β1, etc.) may be the first unmasked bit. i(e.g., β0, β1, etc.) may be, for example, the first bit that is not masked during the evolution of the dynamic shrinkage function DR. i The order of neighbor-based information placed in can affect compression performance. Neighboring information is ordered from higher (e.g., highest) priority to lower priority, and in this order, bit β i , may be ordered from higher weight to lower weight. The priority may be, from most important to least important, the occupancy of a set of close adjacent child cuboids, then the occupancy of close adjacent child cuboids, then the occupancy of close adjacent parent cuboids, then the occupancy of non-close adjacent child nodes, and finally the occupancy of non-close adjacent parent nodes. Neighboring nodes that share a face with the current child node may also have a higher priority than neighboring nodes that share an edge (but not a face) with the current child node. Neighboring nodes that share an edge with the current child node may have a higher priority than neighboring nodes that share only vertices with the current child node.

[0053] FIG. 6 illustrates an exemplary method for encoding the occupancy of a cuboid using a dynamic OBUF. More specifically, FIG. 6 illustrates an exemplary method for encoding the occupancy bits of a current child cuboid using a dynamic OBUF. One or more steps of FIG. 6 may be performed by an encoder and / or a decoder (e.g., the encoder 114 and / or the decoder 120 of FIG. 1). All or part of the flowchart may be implemented by a coder (e.g., the encoder 114 and / or the decoder 120 of FIG. 1), the exemplary computer system 2000 of FIG. 20, and / or the exemplary computing device 2130 of FIG. 21.

[0054] In step 602, the occupancy configuration (e.g., occupancy configuration β) of the current child cube may be determined. The occupancy configuration (e.g., occupancy configuration β) of the current child cuboid may be determined, for example, based on the occupancy bits of already-encoded cuboids adjacent to the current child cuboid. In step 604, the occupancy configuration (e.g., occupancy configuration β) may be dynamically reduced. The occupancy configuration may be dynamically reduced, for example, based on a dynamic reduction function DR nFor example, the occupancy configuration β can be dynamically reduced using the reduced occupancy configuration β′=DR n (β). In step 606, the context index may be looked up, for example, in a look-up table (LUT). For example, the encoder and / or decoder may look up the context index LUT[β'] in the LUT of the dynamic OBUF. In step 608, a context (e.g., a probability model) may be selected. For example, the context (e.g., a probability model) pointed to by the context index may be selected. In step 610, the occupancy of the current child cube may be entropy coded. For example, the occupancy bits of the current child cube may be entropy coded (e.g., arithmetic coded), for example, based on the context. The occupancy bits of the current child cube may be coded based on the occupancy bits of already coded cuboids adjacent to the current child cube.

[0055] Although not shown in Figure 6, the encoder and / or decoder may update the reduction function and / or update the context index. For example, the encoder and / or decoder may update the reduction function DR based on the occupancy bits of the current child cuboid. n DR n+1 and / or update the context index LUT[β']. The method of Figure 6 may be repeated for additional or all child cuboids of a parent cuboid corresponding to a node in the occupancy tree in a scan order, such as the scan order discussed herein with respect to Figure 3.

[0056] In general, occupancy trees are lossless compression techniques. Occupancy trees can be adapted to provide lossy compression, for example, by modifying the point cloud on the encoder side (e.g., downsampling, removing points, moving points, etc.). Lossy compression performance may be weak. Lossy compression can be a useful lossless compression technique for dense point clouds.

[0057] One approach to lossy compression for point cloud geometries may be to set the maximum depth of the occupancy tree to stop at a larger volume size (e.g., an N×N×N rectangular parallelepiped (e.g., cube), where N>1) instead of reaching a minimum volume size of one voxel. The geometry of the points belonging to each occupied leaf node associated with the larger volume may then be modeled. This approach may be particularly suitable for dense, smooth point clouds that can be locally modeled by a smooth function such as a plane or a polynomial. The encoding cost may be the cost of the occupancy tree plus the cost of a local model of each occupied leaf node.

[0058] A scheme for modeling the geometry of points belonging to each occupied leaf node associated with a volume size larger than one voxel may use a set of triangles as a local model. The scheme may be called a "TriSoup" scheme. TriSoup is an abbreviation for "triangle soup" because the connections between triangles may not be part of the model. An occupied leaf node in the occupation tree corresponding to a cuboid with a volume greater than one voxel may be referred to as a TriSoup node. An edge belonging to at least one cuboid corresponding to a TriSoup node may be referred to as a TriSoup edge. A TriSoup node stores an existence flag (s) for each TriSoup edge of its corresponding occupied cuboid. k ) TriSoup edge existence flag (s k ) is a TriSoup vertex (V k ) on a TriSoup edge. At most one TriSoup vertex (V k ) can exist on the TriSoup edge. Each vertex (V k ), the TriSoup node corresponding to the occupied cuboid is the vertex along the TriSoup edge (V k ) position (p k ).

[0059] In addition to the occupancy word of the occupancy tree, the encoder may entropy encode, for each TriSoup node in the occupancy tree, a TriSoup vertex presence flag and the position of each TriSoup edge belonging to the TriSoup node in the occupancy tree. The decoder may similarly entropy decode, in addition to the occupancy word of the occupancy tree, the TriSoup vertex presence flag and the position of each TriSoup edge and vertex along each TriSoup edge belonging to the TriSoup node in the occupancy tree.

[0060] FIG. 7 illustrates an example of an occupied cuboid (e.g., cube) 700. More specifically, FIG. 7 illustrates an example of an occupied cuboid (e.g., cube) 700 of size N×N×N (where N>1) corresponding to a TriSoup node in an occupancy tree. The occupied cuboid 700 may include edges (e.g., TriSoup edges 710-721). The TriSoup node corresponding to the occupied cuboid 700 stores an existence flag (s k ). For example, the existence flag for TriSoup edge 714 may indicate that TriSoup vertex V1 is on TriSoup edge 714. The existence flag for TriSoup edge 715 may indicate that TriSoup vertex V2 is on TriSoup edge 715. The existence flag for TriSoup edge 716 may indicate that TriSoup vertex V3 is on TriSoup edge 716. The existence flag for TriSoup edge 717 may indicate that TriSoup vertex V4 is on TriSoup edge 717. The existence flags for the remaining TriSoup edges may each indicate that the TriSoup vertex is not on the corresponding TriSoup edge. The TriSoup node corresponding to occupied cuboid 700 may include the location of each TriSoup vertex that is along one of its TriSoup edges 710-721. More specifically, the TriSoup node corresponding to occupied cuboid 700 may include position p1 of TriSoup vertex V1, position p2 of TriSoup vertex V2, position p3 of TriSoup vertex V3, and position p4 of TriSoup vertex V4. TriSoup vertices may be shared between TriSoup nodes along common TriSoup edges.

[0061] Existence flag (s k ) and existence flag (s k ) can indicate the existence of a vertex, the current TriSoup edge position (p k ) can be entropy coded. k ) and position (p k ) may be individually or collectively referred to as vertex information or TriSoup vertex information. k ), and existence flag (s k ) indicates the existence of a vertex, the current TriSoup edge position (p k ) can be entropy coded, for example, based on the already coded existence flags and the positions of the existence TriSoup vertices of the TriSoup edges adjacent to the current TriSoup edge. k ) and existence flag (s k ) can indicate the existence of a vertex, the current TriSoup edge position (p k ) may additionally or alternatively be entropy coded. The existence flag of the current TriSoup edge (s k ) and position (p k ) can additionally or alternatively be entropy coded, for example, based on the occupancy of the cuboids adjacent to the current TriSoup edge. Similar to the entropy coding of the occupancy bits of the occupancy tree, the neighbors (neighbor configuration β TS (also called) configuration β TS Obtain the reduced configuration β TS '=DR n (β TS ) can be dynamically reduced to the context index LUT[β TS '] may be obtained from the OBUF LUT. At least a portion of the vertex information of the current TriSoup edge may be entropy coded using the context (e.g., a probability model) pointed to by the context index.

[0062] The TriSoup vertex position (p k ) (if present) can be binarized. TriSoup vertex positions (p k ) (if present) may be binarized to entropy encode at least a portion of the vertex information of the current TriSoup edge, for example, using a binary entropy coder. b The number (e.g., quantity) of TriSoup vertices along a TriSoup edge of length N (p k ) can be set to quantify the length of a TriSoup edge. Nb The quantization interval can be divided evenly. By doing so, the TriSoup vertex position (p k ) can be individually encoded by a dynamic OBUF scheme. b Bit(p k j 、 j=1,...,N b ), and existence flags (s k ) can be represented by the bits corresponding to the neighbor configuration β TS , OBUF reduction function DR n , and the context index is a coded bit (e.g., presence flag (s k ), the highest bit (p k 1 ), the second highest bit (p k 2 )) coded bits (e.g., existence flags (s k ), the highest bit (p k1 ), the second highest bit (p k2 In practice, there may be several dynamic OBUF schemes, each of which may depend on the nature, characteristics, and / or properties of the vertex information (e.g., existence flags (s k ) or position bit (p k j )) is exclusive to this site.

[0063] 8A shows an exemplary rectangular parallelepiped (e.g., cube) 800 that corresponds to a TriSoup node. The rectangular parallelepiped 800 is a cube with TriSoup vertices Vk Within the cuboid 800, the TriSoup triangles may correspond to TriSoup nodes with a number K of TriSoup vertices V k A TriSoup triangle can be constructed from, for example, TriSoup vertices V if there are at least three (K≧3) TriSoup vertices on the TriSoup edges of the rectangular solid 800. k For example, with respect to FIG. 8A, there may be four TriSoup vertices and a TriSoup triangle may be constructed. A TriSoup triangle is constructed from TriSoup vertices V k The main direction can be determined and then the vertex V k can be ordered by rotating around this direction, and the following K TriSoup triangles can be constructed: V1V2C, V2V3C, ..., V K V1C. The main direction may be chosen from among three directions each parallel to an axis in 3D space, for example, to increase or maximize the 2D surface of the triangle if the triangle is projected along the main direction. In doing so, the main direction may be somewhat perpendicular to the local surface defined by the points of the point cloud belonging to the TriSoup node.

[0064] FIG. 8B shows an example fine-tuning for a TriSoup model. The TriSoup model can be fine-tuned by encoding the centroid residual value. The centroid residual value C res can be coded into the bitstream. res For example, use C+C instead of C as the pivot vertex of the triangle. res C+C as the pivot vertices of the triangle. res By using res may be closer to the points in the point cloud than the centroid C, lowering the reconstruction error and res The lower distortion can be achieved at the cost of a small increase in the bit rate required to encode the image.

[0065] FIG. 9 shows an example of voxelization. Voxelization may refer to the reconstruction of a decoded point cloud from a set of TriSoup triangles. Voxelization may be performed by ray tracing for each triangle individually. Voxelization may be performed by ray tracing for each triangle individually, for example, before removing overlapping points between voxelized triangles. As shown in FIG. 9, a ray 900 may be shot parallel to one of three axes in 3D space. The ray 900 may be projected along integer coordinate P start 905 (e.g., origin). The intersection point P, if any, of a ray 900 with a TriSoup triangle 901 belonging to a rectangular parallelepiped (e.g., cube) 902 corresponding to a TriSoup node. int 904 may be rounded to obtain the decoded point. int can be found using, for example, the Moller-Trumbore algorithm.

[0066] The TriSoup vertices of a TriSoup node may need to be quantized to certain allowable vertex positions to ensure continuity of triangle-based modeling between TriSoup nodes. As a result, TriSoup modeling that approximates occupied voxels within a TriSoup node may not match the occupied voxels determined to be within a TriSoup triangle with the quantized TriSoup vertices. Some voxels may be missed, for example, when voxelizing a TriSoup triangle. As described herein, techniques including a "halo" method and a "fine ray firing" method have been introduced to enhance the voxelization process to improve voxel reconnection between triangles.

[0067] Both the halo method and the fine ray firing method attempt to "recapture" missed voxels resulting from quantizing the vertices of TriSoup triangles by increasing the possible intersections between fired rays and triangles. While the halo method does not significantly increase complexity and processing cost, the fine ray firing method may significantly increase processing cost because multiple rays at non-integer coordinates (called fine rays) are additionally fired for each ray at integer coordinates to increase the likelihood of intersections between rays and TriSoup triangles. Not only does the processing cost increase significantly to implement the fine ray firing method, but the fine ray firing method may overlap with the halo method and reproduce some of the same missed voxels, which may reduce its effectiveness. Examples of the present disclosure include enhancing the voxelization process by adding one or more additional points near each determined point (e.g., intersection point) of a TriSoup triangle and quantizing or voxelizing the one or more additional points along with the determined point of the TriSoup triangle. One or more additional points may extend from the determined point, for example, in a direction not aligned with the plane of the TriSoup triangle. While this quantization process is less computationally intensive than the fine ray firing method, quantization of these one or more additional points may not be identified by the halo method, resulting in recapture of voxels that may be implemented using the halo method to enhance voxelization.

[0068] FIG. 10A illustrates an example of approximating a TriSoup triangle of occupied voxels. More specifically, FIG. 10A illustrates an example of a TriSoup method for approximating a triangle (e.g., triangle 1020) of an occupied voxel (e.g., occupied voxel 1030) within a cuboid corresponding to a TriSoup node. For ease of illustration, as shown in FIG. 10A, the boundary 1000 of the cuboid associated with the TriSoup node is depicted in two dimensions (2D) rather than three dimensions (3D) and is shown as 8x8 in size. The cuboid and associated TriSoup node may have a size of 8x8x8 (represented as 8x8 as shown in FIG. 10A) and may encompass points or voxels (e.g., voxel 1010) whose integral coordinates are between 0 and 7. Depending on the construction of the TriSoup node, the boundary 1000 of the TriSoup node may be located between voxels (e.g., with coordinates -0.5 to 7.5). The TriSoup method may approximate an occupied voxel 1030 of a point cloud by, for example, at least one triangle 1020 .

[0069] FIG. 10B shows an example of approximating a TriSoup triangle of an occupied voxel. More specifically, FIG. 10B shows an example of a TriSoup method for approximating a triangle (e.g., triangle 1050) determined for the cuboid shown in FIG. 10A. To ensure continuity of triangle-based modeling between TriSoup nodes, the approximated triangle 1020 shown in FIG. 10A can be modeled by a TriSoup triangle 1050 having at least one vertex V1, V2, and / or V3 belonging to the node boundary 1000 of the cuboid. The V of TriSoup triangle 1050 on node boundary 1000 imay be quantized to certain allowable vertex positions 1040 (e.g., belonging to a distinct set of dequantized positions) along the edges of the cuboid, depending on, for example, a quantization function. Modeling TriSoup triangle 1050 may lead to missing some voxels. For example, modeling TriSoup triangle 1050 may lead to missing voxels, such as voxel 1060b, which was represented and shown as voxel 1060a in FIG. 10A . The missed voxels (e.g., voxel 1060b) may not be recovered by a ray intersection with TriSoup triangle 1050, but may still correspond to points in the original point cloud.

[0070] The halo method, for example, has been introduced to capture some of these mixed voxels. The halo method may be based on the Moller-Trumbore algorithm, which may be used to voxelize TriSoup triangles by ray tracing, as described herein.

[0071] FIG. 11 shows example barycentric coordinates of a point relative to a TriSoup triangle. More specifically, FIG. 11 shows example barycentric coordinates (u, v, w) of a point 1102 (e.g., P) relative to a TriSoup triangle 1100 that are used by the Moller-Trumbore algorithm to determine whether a ray intersects the TriSoup triangle 1100. The vertices of the example TriSoup triangle 1100 shown in FIG. 11 are labeled A, B, and C. The Moller-Trumbore algorithm may determine the intersection between the ray and a plane defined by (or passing through) vertices A, B, and C. The intersection between the ray and the plane may be determined as point 1102, which may be uniquely represented, for example, as the sum of the following three vertices: P=uA+vB+wC where u+v+w=1. A convex polyhedron of three vertices A, B, and C (i.e., TriSoup triangle 1100) may be equal to the set of all points P, so that the barycentric coordinates u, v, and w can each be greater than or equal to zero, as follows: 0≦u, v, w Each of the barycentric coordinates u, v, and w determined by the Moller-Trumbore algorithm may be compared to 0, for example, to determine whether the ray intersects TriSoup triangle 1100. The ray may be determined not to intersect TriSoup triangle 1100, for example, if at least one of the barycentric coordinates is less than 0.

[0072] 12A and 12B illustrate an example of a halo method. More specifically, FIGS. 12A and 12B illustrate an example of a halo method in which one or more inequalities in barycentric coordinates u, v, and w are relaxed to allow for the identification of points within the "halo" of a TriSoup triangle (e.g., triangle 1200). As shown in FIG. 12A , relaxing the inequality 0≦u to the less constrained inequality −ε≦u for a fixed positive parameter ε may add a halo 1210 along side BC of TriSoup triangle 1200. The relaxation of the inequalities may allow for the determination and / or identification of one or more points (e.g., point 1212) within halo 1210 but outside TriSoup triangle 1200. 12B, relaxing all three inequalities 0≦u, v, w to the less constrained inequalities −ε≦u, v, w may result in a halo 1220 surrounding the perimeter of TriSoup triangle 1200. Relaxing all three inequalities may allow a point (e.g., point 1222) to be determined and / or identified.

[0073] In the Moller-Trumbore algorithm, the intersection of a ray with a plane containing a TriSoup triangle may be determined based on calculating the values ​​of u, v, and w. The intersection may be determined to be within a TriSoup triangle (e.g., within or on an edge of a TriSoup triangle) based, for example, on verifying that each of the barycentric coordinates u, v, and w are greater than or equal to 0 (e.g., 0≦u, v, w). The intersection may be determined to be outside the TriSoup triangle if it is not. The halo method may replace the inequality in the verification with −ε≦u, v, w so that the intersection may be confirmed to be within (or belong to) the TriSoup triangle extended by its halo. Thus, the halo method does not increase complexity and / or significantly increase processing requirements.

[0074] FIG. 13 shows an example of a halo method used on a TriSoup triangle. More specifically, FIG. 13 shows an example of a halo method used on a TriSoup triangle 1050 (e.g., TriSoup triangle 1050 as described herein with respect to FIG. 10B). By adding a halo 1310 to TriSoup triangle 1050, voxel 1060 (e.g., corresponding to missed voxel 1060B described herein with respect to FIG. 10B) may be captured by the halo. By adding a halo, better voxel continuity between TriSoup triangles may be obtained through the boundaries of TriSoup nodes, which may reduce holes (i.e., missed voxels). Additionally, a quantum geometric shape index, which represents the amount of error between the original point cloud and the modeled and / or decoded point cloud, may be reduced by adding a halo.

[0075] The voxelization process may, for example, use a ray triangle intersection algorithm (e.g., the Moller-Trumbore algorithm) that relies on ray firing to determine whether a ray intersects a TriSoup triangle. Using the ray triangle intersection algorithm, the point in the TriSoup triangle where the ray intersects the TriSoup triangle may also be determined. The ray may be fired from an integral coordinate that may correspond to the center of the voxel. A ray fired parallel to the coordinate axes of 3D space may intersect a TriSoup triangle only if, for example, the projection of the voxel's center along the ray direction belongs to the TriSoup triangle. That is, for example, a ray may be determined to intersect a TriSoup triangle if the intersection point corresponds to the voxel's center. However, the fired ray may miss a voxel that significantly intersects a TriSoup triangle in 3D space if the voxel's center does not intersect the TriSoup triangle. The fine ray firing method can be implemented with a halo method to further refine the voxelization of TriSoup triangles using ray triangle intersections.

[0076] FIG. 14 illustrates an example of a fine ray casting method. More specifically, FIG. 14 illustrates an example of a fine ray casting method for improving the ray casting method. Additional rays may be cast around each ray cast from integral coordinates, for example. A first ray may be cast along the ray direction from integral coordinate 1420, corresponding to the center of voxel 1410. The first ray may miss intersecting with TriSoup triangle 1400. Additional rays may be cast from coordinate 1430, for example, around the integral coordinate 1420 of the first ray. Multiple additional rays (e.g., eight fine rays) at non-integral coordinates around each ray (e.g., coordinate 1430) may be cast for each ray cast from an integral coordinate (e.g., integral coordinate 1420), for example. Thus, if a voxel whose center lies on the first ray intersects TriSoup triangle 1400 significantly, an intersection with TriSoup triangle 1400 may be obtained. For example, eight additional rays may be fired from coordinates 1430 located ±1 / 8 of the integral coordinate interval relative to the first ray's integral coordinate 1420. A voxel may be determined to "significantly" intersect with TriSoup triangle 1400, for example, based on the intersection between the voxel and TriSoup triangle 1400 being within a threshold amount (e.g., ±1 / 8) of the center of the voxel.

[0077] Because in the Moller-Trumbore algorithm, up to three inequality tests against 0 can be changed to inequality tests against -ε, the halo method as described herein does not add significant complexity to voxelization. The complexity of the Moller-Trumbore algorithm + halo method may not increase over using only the Moller-Trumbore algorithm, for example, for voxelization. In contrast, the fine ray firing method increases the number of fired rays and is computationally expensive. Because the benefits of the halo method and the fine ray firing method are not additive, the benefits of the fine ray firing method may be further reduced.

[0078] FIG. 15 illustrates an example of using the halo method and the fine ray casting method. More specifically, FIG. 15 illustrates an example of the overlapping effect of implementing both the halo method and the fine ray casting method. Voxelization of a TriSoup triangle 1500 may result in voxel 1510 being added to a list of decoded voxels of a decoded point cloud, for example, because voxel 1510 may be determined to belong to a halo 1520 around TriSoup triangle 1500. Additionally or alternatively, voxelization of a TriSoup triangle 1500 may result in voxel 1510 being added to a list of decoded voxels of a decoded point cloud, for example, because an extra ray 1530 cast relative to a first ray 1540 passing through the center of voxel 1510 may intersect with triangle 1500. Voxel 1510 may be added twice, for example, if both the halo method and the fine ray casting method are used. This overlapping effect can be caused by both methods of extending the points being voxelized along the plane of the TriSoup triangle 1500. Increasing the halo parameter ε and extending the distance of extra rays (e.g., fine rays) from the first ray can result in additional points being determined along the plane of the TriSoup triangle 1500, for example.

[0079] FIG. 16 illustrates an example of enhancing the voxelization of a TriSoup triangle. More specifically, FIG. 16 illustrates an example of enhancing the voxelization of a TriSoup triangle 1600 based on adding one or more points. The addition of one or more points may be based on points determined to be within the TriSoup triangle 1600. Enhancing the voxelization in this manner may be referred to as using (e.g., applying) the "thickness" of the TriSoup triangle method. The point may be, for example, an intersection between a ray 1620 and the TriSoup triangle 1600. The TriSoup triangle 1600 may belong to a cuboid 1610 corresponding to a TriSoup node. One or more points 1632 and / or 1634 may be determined based on a point 1630 within (e.g., within or on an edge of) the TriSoup triangle 1600, for example, as described herein. A point determined to be in a TriSoup triangle (e.g., TriSoup triangle 1600) may refer to a point that is within or on an edge of the TriSoup triangle. One or more of the points (e.g., point 1632 and / or point 1634) may be determined using point 1630, but may not be on the same plane as TriSoup triangle 1600 that contains point 1630, for example. As described herein, determining that one or more of these points (e.g., points 1632 and / or 1634) are voxelized may not increase processing complexity, and the fine ray firing method may be replaced and the halo method may be enhanced without redundancy effects.

[0080] Point 1630 is the intersection point P between ray 1620 and TriSoup triangle 1600 intThe ray 1620 may be emitted, for example, from an integral coordinate system in a direction that may be parallel to a coordinate axis in 3D space (e.g., the x-axis, y-axis, or z-axis). The ray 1620 may be emitted, for example, along one or more coordinate axes in 3D space. The ray may be emitted, for example, from one or more of the coordinate axes. The rays may be emitted in the order of the coordinate axes that are determined to be most perpendicular to the plane of the TriSoup triangle 1600. The ray (e.g., ray 1620) may be emitted, for example, from up to two of the three coordinate axes that are determined to be most perpendicular or most parallel to the normal of the TriSoup triangle (e.g., TriSoup triangle 1600).

[0081] As described herein, the intersection may be determined based on a calculation of barycentric coordinates (e.g., the Moller-Trumbore algorithm). Point 1630 may be voxelized (e.g., rounded and / or quantized to the nearest voxel along ray 1620) and / or added to a list of decoded points or voxels in the decoded point cloud. One or more points (e.g., point 1632 and / or point 1634) may be determined from point 1630. One or more points (e.g., point 1632 and / or point 1634) may be determined from point 1630, for example, based on the addition and / or subtraction of vectors having a magnitude equal to a value (e.g., thickness value τ). Point 1634

number

number

number

number

number

number

number

number

number

number

number

number

number

number

[0082] point

number

number

number

number

[0083] The value τ may be a predetermined value (e.g., 1 / 8 the size of a voxel). The value τ may be defined relative to the size of a voxel. The value τ may be a parameter (e.g., a "thickness" parameter) that may be determined by the encoder and signaled as an indication to the decoder.

[0084] One or two extension points may be determined. One or two extension points may be determined, for example, for each point (e.g., intersection point) determined in TriSoup triangle 1600. TriSoup triangle 1600 may be extended by two parallel planes of points, which may be considered equivalent to replacing TriSoup triangle 1600 with a prism of height 2τ. TriSoup triangle 1600 may be extended by two parallel planes of points, which may be considered equivalent to replacing TriSoup triangle 1600 with a prism of height 2τ, for example, by determining points of TriSoup triangle 1600 that are above or below a point of TriSoup triangle 1600 at a distance / value of τ. The prism may be extended by two parallel planes of points, which may be considered equivalent to replacing TriSoup triangle 1600 with a prism of height 2τ, for example, by determining points of TriSoup triangle 1600 that are above or below a point of TriSoup triangle 1600 at a distance / value of τ.

number

number

number

number

number

number

number

number

[0085] The fine ray firing method can be replaced by a method using the "thickness" of TriSoup triangles, as described herein. Figure 17 shows an example of enhancing the voxelization of TriSoup triangles. More specifically, Figure 17 shows an example of how using the "thickness" of TriSoup triangles method can achieve results similar to fine ray firing.

number

number

[0086] The parameters for the value τ and / or the base halo parameter ε may be predetermined. The parameters for the value τ and / or the base halo parameter ε may be fixed, for example, in the specifications of a codec. The parameters for the value τ and / or the base halo parameter ε may depend on the characteristics of the original point cloud. The parameters for the value τ and / or the base halo parameter ε may be determined by an encoder and / or transmitted to a decoder, for example. The parameters for the value τ and / or the base halo parameter ε may be encoded into a bitstream and / or decoded by a decoder.

[0087] The parameters for the value τ and / or the base halo parameters ε may be encoded into the bitstream, for example, at the constellation level (e.g., in a constellation parameter set [SPS]), the frame level (e.g., in a geometric parameter set [GPS]), and / or at a more local level. The parameters for the value τ and / or the base halo parameters ε may be encoded, for example, at a more local level, per slice or per brick in a geometric brick header (GBH).

[0088] The encoder may, for example, signal a startup flag indicating whether a proposed mechanism based on the value τ is to be implemented by the decoder when voxelizing a TriSoup triangle. The encoder may, for example, signal a startup flag indicating whether a proposed mechanism based on the value τ is not to be implemented by the decoder when voxelizing a TriSoup triangle. The startup flag may be encoded into the SPS, GPS, and / or GBH. The decoder may receive and / or decode the startup flag from the bitstream.

[0089] FIG. 18A illustrates an exemplary method for encoding (e.g., encoding and / or decoding) a point cloud from a TriSoup triangle. More specifically, FIG. 18A illustrates a flowchart 1800A of exemplary method steps for encoding a point cloud from a TriSoup triangle. One or more steps of the exemplary flowchart 1800A may be implemented by a decoder and / or encoder (e.g., decoder 120 and / or encoder 114 as described herein with respect to FIG. 1). In step 1802 of FIG. 18A, the decoder and / or encoder may determine a first point that may be within the TriSoup triangle. The first point may be in three-dimensional (3D) space. A point that is within the TriSoup triangle may include being on an edge of the TriSoup triangle or being within (e.g., inside) a TriSoup triangle bounded by the edges of the TriSoup triangle. A TriSoup triangle may have three vertices, at least two of which are along two TriSoup edges of a cube corresponding to a TriSoup node (e.g., as described herein with respect to Figures 8A, 8B, 9, and 16). Examples of TriSoup triangles are shown in 3D with respect to Figures 8A, 8B, 9, and 16.

[0090] The first point may be determined to be at a ray-triangle intersection. The first point may be determined to be at a ray-triangle intersection, for example, based on the use of a ray-casting or ray-tracing algorithm (e.g., the Moller-Trumbore algorithm). The first point may be determined to be within a TriSoup triangle, for example, based on determining that it is at an intersection between a TriSoup triangle and a ray that extends parallel to a coordinate axis of 3D space (e.g., one of the x-axis, y-axis, or z-axis of 3D space). The decoder and / or encoder may convert the coordinates of the three TriSoup vertices of the TriSoup triangle into barycentric coordinates, for example, to determine the intersection between the TriSoup triangle and the ray. The intersection may be determined, for example, based on using (e.g., applying) the Moller-Trumbore algorithm using the three vertices of the TriSoup triangle and the ray, as described herein with respect to FIG. 11. To determine the intersection between a TriSoup triangle and a ray extending parallel to the coordinate axis, a ray may be emitted or extended from the ray having the origin of the integral coordinates. The ray may be emitted or extended in a direction that may point toward the interior of a rectangular prism that contains the TriSoup triangle (e.g., to correspond to a TriSoup node).

[0091] The first point may be determined based on rasterization or a related method. Related methods may include, for example, a digital difference analyzer (DDA) algorithm or a Bresenham algorithm. The decoder and / or encoder may perform rasterization, for example, by converting the TriSoup triangle into a triangle in 2D space. The decoder and / or encoder may, for example, determine a 2D point (e.g., a pixel) that is within the 2D triangle (e.g., on an edge or within a 2D triangle bounded by an edge). The decoder and / or encoder may, for example, project the 2D point into 3D space to determine the first point after the decoder and / or encoder determine the 2D point. The first point in the TriSoup triangle may, for example, correspond to the 2D point projected into 3D space. The first point and / or the 2D point may be determined based on, for example, using a DDA algorithm, a Bresenham algorithm, etc.

[0092] In step 1804 of Figure 18A, the decoder and / or encoder may determine a second point. The second point may be determined, for example, as a point displaced from the first point by a vector having a magnitude equal to a value (e.g., τ). The second point may be outside the TriSoup triangle. The second point may not belong to the plane of the TriSoup triangle.

[0093] The point may be determined as the intersection between a ray and a TriSoup triangle (e.g., as described with respect to step 1802). The vector may be parallel to the ray, which may be parallel to a coordinate axis in 3D space. The vector may be perpendicular to the plane of the TriSoup triangle. This type of vector may be determined based on a rasterization approach. The vector may be used, for example, based on which the intersection is determined using ray tracing or ray casting.

[0094] The value (e.g., τ) may be predetermined. The value τ may be defined relative to the size of a voxel (e.g., 1 / 8, 1 / 4, 1 / 16, etc. of the size of a voxel). The value may be, for example, 1 / 8 of the size of a voxel to achieve performance similar to the fine ray firing method with reduced computational cost. The decoder and / or encoder may receive an indication (e.g., a syntax element) that may indicate the value.

[0095] In step 1806 of FIG. 18A , the decoder and / or encoder may voxelize the first point and the second point. The decoder and / or encoder may, for example, voxelize the first point and the second point to determine at least one voxel of the decoded point cloud. The first point and the second point may, for example, be voxelized to up to two voxels of the decoded point cloud. The at least one voxel may be up to two voxels of the decoded point cloud (e.g., two different voxels). Voxelizing the first point and the second point may include quantizing and / or rounding the first point and the second point to the first voxel and the second voxel, respectively.

[0096] Voxelizing the first point and the second point may include voxelizing the first point to determine a first voxel and voxelizing the second point to determine a second voxel. The at least one voxel may include at least one of the first voxel and / or the second voxel. The at least one voxel may include one of the first voxel or the second voxel, for example, when the first voxel and the second voxel are the same. The at least one voxel may include both the first voxel and the second voxel, for example, when the first voxel and the second voxel are different.

[0097] The first voxel (e.g., the corresponding first decoded voxelized point) and the second voxel (e.g., the corresponding second decoded voxelized point) may be added to a list of rendered voxels (e.g., decoded voxelized points). The decoder and / or encoder may remove duplicate voxels from the list of rendered voxels to represent the decoded point cloud if duplicates exist.

[0098] One or more additional points may be determined based on the first point determined in step 1802. A second point may be determined based on the first point, for example, by adding a vector to the first point. Similarly, a third point may be determined based on the first point, for example, by subtracting a vector from the first point (e.g., as described herein with respect to FIG. 16). The first point, second point, and third point may be voxelized. The first point, second point, and third point may be voxelized, for example, to determine at least one voxel of the decoded point cloud. The first point, second point, and third point may be voxelized, for example, for up to two voxels of the decoded point cloud.

[0099] The second point may be denoted as a point displaced from the first point by a value in a first direction of the vector. The decoder and / or encoder may determine a third point, denoted as a point displaced from the first point by a value in a second direction, which may be opposite to the first direction. The first point, the second point, and the third point may be voxelized to determine at least one voxel of the decoded point cloud. The first point, the second point, and the third point may be voxelized to up to two voxels of the decoded point cloud. The first direction and / or the second direction may be parallel to a coordinate axis in 3D space. The first direction and / or the second direction may be perpendicular to the plane of the TriSoup triangle (e.g., parallel to the normal of the TriSoup triangle).

[0100] The decoder and / or encoder may determine an intersection point between a TriSoup triangle and a ray extending parallel to a coordinate axis in 3D space (e.g., as described herein with respect to FIG. 16). The decoder and / or encoder may determine a point indicated by a vector as the intersection point, displaced parallel to the ray, and including a magnitude equal to a value. The value (e.g., the value τ) may be a predetermined value (e.g., 1 / 8 the size of a voxel). The value may be received from the bitstream and / or indicated by a decoded signal. The decoder and / or encoder may voxelize the intersection point and / or the second point to determine at least one voxel of a decoded point cloud. The at least one voxel may be up to two voxels of the decoded point cloud.

[0101] FIG. 18B illustrates an exemplary method for encoding (e.g., encoding and / or decoding) a point cloud from a TriSoup triangle. More specifically, FIG. 18B illustrates a flowchart 1800B of exemplary method steps for decoding a point cloud from a TriSoup triangle. One or more steps of the exemplary flowchart 1800B may be implemented by a decoder and / or encoder (e.g., decoder 120 and / or encoder 114 as described herein with respect to FIG. 1). Two or more additional points may be determined for each point determined in the TriSoup triangle, for example, as described herein with respect to FIG. 18A. In step 1812 of FIG. 18B, the decoder and / or encoder may determine a first point in 3D space that may be within the TriSoup triangle. The first point may be determined as the intersection between a ray parallel to a coordinate axis and the TriSoup triangle. In step 1814 of Figure 18B, the decoder and / or encoder may determine that the second point is a point displaced in a first direction by the vector magnitude value. The value may be a predetermined value and / or may be received as an indication in the bitstream. In step 1816 of Figure 18B, the decoder and / or encoder may determine that the third point is a point displaced in a second direction, which may be opposite to the first direction, by the vector magnitude value. In step 1818 of Figure 18B, the decoder and / or encoder may voxelize the first point, the second point, and the third point to determine at least one voxel of a decoded point cloud.

[0102] 18A and 18B may be described with respect to one determined point (e.g., intersection point) in a TriSoup triangle, but multiple such points in a TriSoup triangle may be determined by the decoder and / or encoder. A ray triangle intersection method may be used to determine intersection points between multiple rays and a TriSoup triangle. Additionally, FIGS. 18A and 18B may be described with respect to the extension and / or launch of rays in one coordinate axis, multiple rays may be launched from multiple coordinate axes and / or sets of coordinate axes, and multiple intersection points may be determined between multiple rays and a TriSoup triangle.

[0103] 19 illustrates an exemplary computer system on which embodiments of the present disclosure may be implemented. For example, the exemplary computer system 1900 illustrated in FIG. 19 may implement one or more of the methods described herein. For example, various devices and / or systems described herein (e.g., FIGS. 1, 2, and 3) may be implemented in the form of one or more computer systems 1900. Furthermore, each of the steps of the flowcharts illustrated in the present disclosure may be implemented on one or more computer systems 1900.

[0104] Computer system 1900 may include one or more processors, such as processor 1904. Processor 1904 may be a special purpose processor, a general purpose processor, a microprocessor, and / or a digital signal processor. Processor 1904 may be connected to a communications infrastructure 1902 (e.g., a bus or network). Computer system 1900 may also include main memory 1906 (e.g., random access memory (RAM)) and / or secondary memory 1908.

[0105] Secondary memory 1908 may include a hard disk drive 1910 and / or a removable storage drive 1912 (e.g., a magnetic tape drive, an optical disk drive, and / or the like). The removable storage drive 1912 may be read from and / or written to a removable storage unit 1916. The removable storage unit 1916 may include a magnetic tape, an optical disk, and / or the like. The removable storage unit 1916 may be read by and / or written to the removable storage drive 1912. The removable storage unit 1916 may include a computer-usable storage medium having computer software and / or data stored therein.

[0106] Secondary memory 1908 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 1900. Such means may include removable storage units 1918 and / or interfaces 1914. Examples of such means may include program cartridges and / or cartridge interfaces (such as video game devices), removable memory chips (such as erasable programmable read-only memories (EPROMs) or programmable read-only memories (PROMs)), and associated sockets, thumb drives, and USB ports, and / or other removable storage units 1918 and interfaces 1914 that may allow software and / or data to be transferred from removable storage units 1918 to computer system 1900.

[0107] Computer system 1900 may also include a communications interface 1920. Communications interface 1920 may allow software and data to be transferred between computer system 1900 and external devices. Examples of communications interface 1920 may include a modem, a network interface (e.g., an Ethernet card), a communications port, etc. The software and / or data transferred via communications interface 1920 may be in the form of signals, which may be electronic, electromagnetic, optical, and / or other signals that can be received by communications interface 1920. The signals may be provided to communications interface 1920 via communications path 1922. Communications path 1922 may transmit signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link, and / or any other communications channel.

[0108] Computer program medium and / or computer-readable medium may be used to refer to tangible storage media, such as removable storage units 1916 and 1918, or a hard disk installed in hard disk drive 1910. A computer program product may be a means for providing software to computer system 1900. Computer programs (which may also be called computer control logic) may be stored in main memory 1906 and / or secondary memory 1908. Computer programs may be received via communications interface 1920. Such computer programs, when executed, may enable computer system 1900 to implement the present disclosure as discussed herein. In particular, the computer programs, when executed, may enable processor 1904 to perform processes of the present disclosure, such as any of the methods described herein. Thus, such computer programs may represent controllers of computer system 1900.

[0109] Features of the present disclosure may be implemented in hardware using, for example, hardware components such as application specific integrated circuits (ASICs), gate arrays, etc. Implementation of a hardware state machine so as to perform the functions described herein will also be apparent to those skilled in the relevant art.

[0110] 20 illustrates exemplary elements of a computing device that may be used to implement any of the various devices described herein, including, for example, a source device (e.g., 102), an encoder (e.g., 200), a destination device (e.g., 106), a decoder (e.g., 300), and / or any computing device described herein. The computing device 2030 may include one or more processors 2031 that may execute instructions stored on random access memory (RAM) 2033, removable media 2034 (such as a universal serial bus (USB) drive, a compact disc (CD) or digital versatile disc (DVD), or a floppy disk drive), or any other desired storage medium. Instructions may also be stored on an attached (or internal) hard drive 2035. The computing device 2030 may also include a security processor (not shown) that may execute instructions of one or more computer programs to monitor processes running on the processor 2031 and any processes requesting access to any hardware and / or software components of the computing device 2030 (e.g., ROM 2032, RAM 2033, removable media 2034, hard drive 2035, device controller 2037, network interface 2039, GPS 2041, Bluetooth interface 2042, WiFi interface 2043, etc.). The computing device 2030 may include one or more output devices such as a display 2036 (e.g., a screen, display device, monitor, television, etc.) and may include one or more output device controllers 2037, such as a video processor. There may also be one or more user input devices 2038, such as a remote control, keyboard, mouse, touch screen, microphone, etc. The computing device 2030 may also include one or more network interfaces, such as a network interface 2039, which may be a wired interface, a wireless interface, or a combination of the two.The network interface 2039 may provide an interface for the computing device 2030 to communicate with a network 2040 (e.g., a RAN or any other network). The network interface 2039 may include a modem (e.g., a cable modem), and the external network 2040 may include a communications link, an external network, a home network, a provider's wireless, coaxial, fiber, or hybrid fiber / coaxial distribution system (e.g., a DOCSIS network), or any other desired network. Additionally, the computing device 2030 may include a location detection device such as a global positioning system (GPS) microprocessor 2041, which may be configured to receive and process global positioning signals and, with possible assistance from external servers and antennas, determine the geographic location of the computing device 2030.

[0111] While the example of FIG. 20 may be a hardware configuration, the components shown may be implemented as software. Changes may be made, as desired, to add, remove, combine, divide, etc., components of computing device 2030. Additionally, components may be implemented using basic computing devices and components, and the same components (e.g., processor 2031, ROM storage 2032, display 2036, etc.) may be used to implement any of the other computing devices and components described herein. For example, the various components described herein may be implemented using a computing device having components such as a processor that executes computer-executable instructions stored on a computer-readable medium, as shown in FIG. 20. Some or all of the entities described herein may be software-based and coexist on a common physical platform (e.g., a requesting entity may be a separate software process and program from a dependent entity, both of which may run as software on a common computing device).

[0112] Various features are highlighted below in sets of numbered clauses or paragraphs. These features are not to be construed as limiting the invention or inventive concept, but are provided merely as highlighting some of the features described herein, without implying the importance or relevance of any particular order of such features.

[0113] Clause 1. A method including determining a first point in three-dimensional (3D) space that is within a TriSoup triangle.

[0114] Clause 2. The method of clause 1, further comprising determining a second point displaced from the first point by a vector.

[0115] Clause 3. The method of clause 1 or 2, further comprising determining at least one voxel of a set of voxels representing the point cloud by voxelizing the first point and the second point.

[0116] Clause 4. The method of any one of clauses 1 to 3, wherein the point cloud comprises a decoded point cloud.

[0117] Clause 5. The method of any one of clauses 1 to 4, wherein the first point is associated with a point cloud video.

[0118] Clause 6. The method of any one of clauses 1 to 5, further comprising decoding the video, wherein the first point is associated with the point cloud video.

[0119] Clause 7. The method of any one of clauses 1 to 6, wherein the first point within a TriSoup triangle comprises a point on an edge of the TriSoup triangle or a point within the TriSoup triangle.

[0120] Clause 8. The method of any one of clauses 1 to 7, wherein the second point is outside the TriSoup triangle.

[0121] Clause 9. The method of any one of clauses 1 to 8, wherein a TriSoup triangle includes three vertices, at least two of which are along two TriSoup edges of a rectangular solid associated with the TriSoup node.

[0122] Clause 10. The method of any one of clauses 1 to 9, wherein determining a first point within a TriSoup triangle includes determining that the first point is at an intersection between the TriSoup triangle and a ray extending parallel to a coordinate axis in 3D space.

[0123] Clause 11. The method of any one of clauses 1 to 10, wherein the TriSoup triangle includes three vertices and the first point is determined using the Moller-Trumbore algorithm using the three vertices and rays of the TriSoup triangle.

[0124] Clause 12. The method of any one of clauses 1 to 11, wherein determining the first point includes converting the TriSoup triangle to a triangle in 2D space, determining a 2D point that is within the triangle, and projecting the 2D point into 3D space.

[0125] Clause 13. The method of any one of clauses 1 to 12, wherein determining at least one voxel includes voxelizing a first point to determine a first voxel and voxelizing a second point to determine a second voxel, wherein the at least one voxel includes at least one of the first voxel and the second voxel.

[0126] Clause 14. The method of any one of clauses 1 to 13, wherein the first point and the second point are voxelized into up to two voxels of the point cloud.

[0127] Clause 15. The method of any one of clauses 1 to 14, wherein the vector has a magnitude equal to a predetermined value.

[0128] Clause 16. The method of any one of clauses 1-15, further comprising receiving an indication of the value, wherein the vector has a magnitude equal to the value.

[0129] Clause 17. The method of any one of clauses 1 to 16, further comprising: determining a second point based on adding a vector to the first point; and determining a third point based on subtracting a vector from the first point; and voxelizing comprises voxelizing the first point, the second point, and the third point to determine at least one voxel of the point cloud.

[0130] Clause 18. A computing device comprising one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the wireless device to perform a method according to any one of clauses 1 to 17.

[0131] Clause 19. A system comprising: a computing device configured to perform the method of any one of clauses 1 to 17; and a base station configured to encode a point cloud.

[0132] Clause 20. A computer-readable medium storing instructions that, when executed, cause performance of the method of any one of clauses 1-17.

[0133] Clause 21. A method including determining a first point in three-dimensional (3D) space that is within a TriSoup triangle.

[0134] Clause 22. The method of clause 21, further comprising determining a second point displaced from the first point by a vector.

[0135] Clause 23. The method of clause 21 or 22, further comprising determining at least one voxel by voxelizing the first point and the second point.

[0136] Clause 24. The method of any one of clauses 21 to 23, wherein a set of voxels comprising at least one voxel represents a point cloud.

[0137] Clause 25. The method of any one of clauses 21 to 24, wherein the first point, the second point, and the third point are voxelized into a maximum of two voxels of the point cloud.

[0138] Clause 26. A method according to any one of clauses 21 to 25, wherein at least one voxel comprises one of the first voxel and the second voxel if the first voxel and the second voxel are the same, and comprises both the first voxel and the second voxel if the first voxel and the second voxel are different.

[0139] Clause 27. The method of any one of clauses 21 to 26, wherein the vector is perpendicular to a plane associated with the TriSoup triangle.

[0140] Clause 28. The method of any one of clauses 21 to 27, further comprising determining a second point based on adding a vector to the first point and determining a third point based on subtracting a vector from the first point, and wherein voxelizing comprises voxelizing the first point, the second point, and the third point to determine at least one voxel of the point cloud.

[0141] Clause 29. A wireless device comprising one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the computing device to perform a method according to any one of clauses 21 to 28.

[0142] Clause 30. A system comprising: a first computing device configured to perform the method of any one of clauses 21 to 28; and a second computing device configured to encode a point cloud.

[0143] Clause 31. A computer-readable medium storing instructions that, when executed, cause performance of the method of any one of clauses 21 to 28.

[0144] Clause 32. A method including determining a first point in three-dimensional (3D) space that is within a TriSoup triangle.

[0145] Clause 33. The method of clause 32, further comprising determining a second point displaced from the first point by a vector.

[0146] Clause 34. The method of clause 32 or 33, further comprising voxelizing the first point and the second point to determine at least one voxel of the decoded point cloud.

[0147] Clause 35. The method of any one of clauses 32 to 34, wherein a TriSoup triangle has three vertices.

[0148] Clause 36. The method of any one of clauses 32 to 35, wherein a TriSoup triangle belongs to a TriSoup node.

[0149] Clause 37. A method according to any one of clauses 32 to 36, wherein determining a first point inside a TriSoup triangle comprises determining that the first point is at an intersection between the TriSoup triangle and a ray extending parallel to a coordinate axis in 3D space.

[0150] Clause 38. The method according to clause 37, wherein the vector and the ray are parallel.

[0151] Clause 39. The method of any one of clauses 32 to 38, wherein the coordinate axes in the 3D space include an x-coordinate axis, a y-coordinate axis, and a z-coordinate axis.

[0152] Clause 40. The method of clause 37 or 38, wherein the ray extends in a direction toward the interior of a rectangular parallelepiped containing the TriSoup triangles.

[0153] Clause 41. A method according to any one of clauses 32 to 40, wherein voxelizing comprises voxelizing a first point to determine a first voxel and voxelizing a second point to determine a second voxel, wherein at least one voxel comprises at least one of the first voxel and the second voxel.

[0154] Clause 42. The method of clause 41, further comprising adding the first voxel and the second voxel to a list of rendered voxels; and removing one or more overlapping voxels from the list of rendered voxels.

[0155] Clause 43. A method according to any one of clauses 32 to 42, wherein voxelizing the first point and the second point comprises quantizing the first point and the second point into first voxels and second voxels, respectively.

[0156] Clause 44. The method of any one of clauses 32 to 43, wherein the vector has a magnitude equal to a predetermined value.

[0157] Clause 45. The method of any one of clauses 32 to 44, wherein the vector has a magnitude equal to a predetermined value.

[0158] Clause 46. The method of clause 45, wherein the value is 1 / 8 of the size of a voxel.

[0159] Clause 47. The method of clause 45, wherein the second point is displaced from the first point by a value in a first direction of the vector, and the method further includes determining a third point displaced from the first point by a value in a second direction opposite the first direction, and wherein voxelizing includes voxelizing the first point, the second point, and the third point to determine at least one voxel of the decoded point cloud.

[0160] Clause 48. The method of clause 47, wherein the first direction and the second direction are both parallel to a coordinate axis in 3D space.

[0161] Clause 49. The method of clause 47, wherein the first direction and the second direction are both perpendicular to the plane of the TriSoup triangle.

[0162] Clause 50. A computing device comprising one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the computing device to perform the method of any one of clauses 32 to 49.

[0163] Clause 51. A system comprising: a first computing device configured to perform the method of any one of clauses 32 to 49; and a second computing device configured to encode a point cloud.

[0164] Clause 52. A computer-readable medium storing instructions that, when executed, cause performance of the method of any one of clauses 32 to 49.

[0165] A computing device may perform a method including a number of operations. The computing device may determine a first point in three-dimensional (3D) space that may be within a TriSoup triangle. The computing device may determine a second point that may be displaced from the first point by a vector. The computing device may determine at least one voxel of a set of voxels representing a point cloud, for example, by voxelizing the first point and the second point. The point cloud may include a decoded point cloud. The first point may be associated with a point cloud video. The computing device may decode the video. The video may include a sequence of point clouds. The first point within the TriSoup triangle may include a point on an edge of the TriSoup triangle or a point within the TriSoup triangle. The second point may be outside the TriSoup triangle. The TriSoup triangle may include three vertices, and at least two of the three vertices may be along two TriSoup edges of a rectangular solid associated with the TriSoup node. Determining that the first point may be within a TriSoup triangle may include determining that the first point may be at an intersection between a TriSoup triangle and a ray extending parallel to a coordinate axis in 3D space. The TriSoup triangle may have three vertices. The first point may be determined using the Moller-Trumbore algorithm using the three vertices of the TriSoup triangle and the ray. Determining the first point may include converting the TriSoup triangle to a triangle in 2D space, determining 2D points that may be within the triangle, and projecting the 2D points into 3D space. Determining at least one voxel may include voxelizing the first point to determine a first voxel and voxelizing the second point to determine a second voxel, where the at least one voxel may include at least one of the first voxel and / or the second voxel. The first point and / or the second point may be voxelized for up to two voxels of the point cloud. The vector may have a magnitude equal to a predetermined value. The wireless device may receive an indication of the value, and the vector may have a magnitude equal to the value. The second point may be determined based on adding the vector to the first point.The computing device may further determine a third point based on subtracting the vector from the first point. Voxelizing may include voxelizing the first point, the second point, and the third point to determine, for example, at least one voxel of the point cloud. The computing device may include one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the computing device to perform the described methods, additional operations, and / or include additional elements. A system may include a first computing device configured to perform the described methods, additional operations, and / or include additional elements, and a second computing device configured to encode the point cloud. A computer-readable medium may store instructions that, when executed, cause the described methods, additional operations, and / or include additional elements.

[0166] A computing device may perform a method including a plurality of operations. The computing device may determine a first point in three-dimensional (3D) space, the first point being within a TriSoup triangle. The computing device may determine a second point displaced from the first point by a vector, and the computing device may determine at least one voxel by voxelizing the first point and the second point. A set of voxels including the at least one voxel may represent a point cloud. The first point, the second point, and the third point may be voxelized for up to two voxels of the point cloud. The at least one voxel may include one of the first voxel and the second voxel, for example, if the first voxel and the second voxel are the same. Alternatively, the at least one voxel may include both the first voxel and the second voxel, for example, if the first voxel and the second voxel are different. The vector may be perpendicular to a plane associated with the TriSoup triangle. The computing device may include one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the computing device to perform the described methods, additional operations, and / or include additional elements. The system may include a first computing device configured to perform the described methods, additional operations, and / or include additional elements, and a second computing device configured to encode the point cloud. A computer-readable medium may store instructions that, when executed, cause the described methods, additional operations, and / or include additional elements.

[0167] A computing device may perform a method including a plurality of operations. The computing device may determine a first point as an intersection between a TriSoup triangle and a ray that may extend parallel to a coordinate axis of three-dimensional (3D) space. The computing device may determine a second point that may be displaced from the first point by a vector that may be parallel to the ray. The computing device may determine at least one voxel of a set of voxels representing the encoded point cloud, for example, by voxelizing the first point and the second point. The intersection of the ray with the plane of the TriSoup triangle may be expressed as barycentric coordinates that may be referenced to the TriSoup triangle, and the first point may be determined based on the barycentric coordinates. The second point may be determined based on adding a vector to the first point, and the computing device may further determine a third point based on subtracting the vector from the first point. Determining the first point may be based on using one of a digital difference analyzer (DDA) algorithm or a Bresenham algorithm. The computing device may include one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the computing device to perform the described methods, additional operations, and / or include additional elements. A system may include a first computing device configured to perform the described methods, additional operations, and / or include additional elements, and a second computing device configured to encode the point cloud. A computer-readable medium may store instructions that, when executed, cause the described methods, additional operations, and / or include additional elements.

[0168] A computing device may perform a method including a number of operations. The computing device may determine a first point in three-dimensional (3D) space that may be inside a TriSoup triangle. The computing device may determine a second point displaced from the first point by a vector, and the computing device may determine at least one voxel of a decoded point cloud, for example, by voxelizing the first point and the second point. The TriSoup triangle may have three vertices. The TriSoup triangle may belong to a TriSoup node. The vector and the ray may be parallel. Coordinate axes that may be in the 3D space may include an x-coordinate axis, a y-coordinate axis, and a z-coordinate axis. The ray may be extended in a direction that may point toward the interior of a rectangular prism that includes the TriSoup triangle. The computing device may add the first voxel and the second voxel to a list of rendered voxels, and the computing device may remove one or more overlapping voxels from the list of rendered voxels. Voxelizing the first point and the second point may include quantizing the first point and the second point into a first voxel and a second voxel, respectively. The vector may have a magnitude that may be equal to a predetermined value. The value may be 1 / 8 the size of a voxel. The first direction and the second direction may both be parallel to a coordinate axis in 3D space. The first direction and the second direction may both be perpendicular to the plane of the TriSoup triangle. The computing device may include one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the computing device to perform the described methods, additional operations, and / or include additional elements. The system may include a first computing device configured to perform the described methods, additional operations, and / or include additional elements, and a second computing device configured to encode the point cloud. A computer-readable medium may store instructions that, when executed, cause the described methods, additional operations, and / or include additional elements.

[0169] One or more examples herein may be described as a process, which may be depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, and / or a block diagram. A flowchart may describe operations as a sequential process, but one or more operations may be performed in parallel or simultaneously. The order of operations shown may be rearranged. A process may terminate when its operations are completed, but may have additional steps not shown in the figures. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or the main function.

[0170] The operations described herein may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, program code or code segments (e.g., computer program product) to perform the necessary tasks may be stored on a computer-readable or machine-readable medium. A processor may perform the necessary tasks. Features of the present disclosure may be implemented in hardware using, for example, hardware components such as application-specific integrated circuits (ASICs) and gate arrays. Implementation of hardware state machines to perform the functions described herein will also be apparent to those skilled in the art.

[0171] One or more features described herein may be implemented in computer-usable data and / or computer-executable instructions, such as one or more program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor within a computer or other data processing device. Computer-executable instructions may be stored on one or more computer-readable media, such as hard disks, optical disks, removable storage media, solid-state memory, RAM, etc. The functionality of the program modules may be combined or distributed as desired. Functionality may be implemented in whole or in part in firmware or hardware equivalents, such as integrated circuits, field programmable gate arrays (FPGAs), etc. Certain data structures may be used to more efficiently implement one or more features described herein, and such data structures are contemplated within the scope of the computer-executable instructions and computer-usable data described herein. Computer-readable media may include, but are not limited to, portable or non-portable storage devices, optical storage devices, and various other media capable of storing, containing, or carrying instructions and / or data. Computer-readable media may include non-transitory media on which data may be stored and which do not include carrier waves and / or transitory electronic signals propagated via wireless or wired connections. Examples of non-transitory media include, but are not limited to, magnetic disks or tapes, optical storage media such as compact disks (CDs) or digital versatile disks (DVDs), flash memory, memory or memory devices. Computer-readable media may store code and / or machine-executable instructions, which may represent procedures, functions, subprograms, programs, routines, subroutines, modules, software packages, classes, or any combination of instructions, data structures, or program statements.A code segment may be coupled to another code segment or a hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

[0172] A non-transitory tangible computer-readable medium may include instructions executable by one or more processors configured to cause the operations described herein. An article of manufacture may include a non-transitory tangible computer-readable machine-accessible medium encoded with instructions to enable programmable hardware that causes a device (e.g., an encoder, decoder, transmitter, receiver, etc.) to perform the operations described herein. A device, or one or more devices, such as in a system, may include one or more processors, memory, interfaces, and / or the like.

[0173] Communications described herein may be determined, generated, sent, and / or received using any amount of messages, information elements, fields, parameters, values, indications, information, bits, and / or the like. While one or more examples may be described herein using any of the terms / phrases message, information element, field, parameter, value, indication, information, bit, and / or the like, those skilled in the art will understand that such communications may be implemented using any one or more of these terms, including other such terms. For example, one or more parameters, fields, and / or information elements (IEs) may include one or more information objects, values, and / or any other information. An information object may include one or more other objects. At least some (or all) parameters, fields, IEs, and / or the like may be used and may be interchangeable depending on the context. Where meanings or definitions are given, such meanings or definitions are controlling.

[0174] One or more elements of the examples described herein may be implemented as a module. A module may be an element that performs a defined function and / or has a defined interface to other elements. A module may be implemented in hardware, software in combination with hardware, firmware, wetware (e.g., hardware with biological components), or a combination thereof, all of which may be behaviorally equivalent. For example, a module may be implemented as a software routine written in a computer language configured to run on a hardware machine (e.g., C, C++, Fortran, Java, Basic, Matlab, etc.) or Simulink, Stateflow, GNU Octave, or LabVIEW MathScript. Additionally or alternatively, it may be possible to implement a module using physical hardware incorporating discrete or programmable analog, digital, and / or quantum hardware. Examples of programmable hardware include computers, microcontrollers, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and / or complex programmable logic devices (CPLDs). Computers, microcontrollers, and / or microprocessors may be programmed using languages ​​such as assembly, C, C++, etc. FPGAs, ASICs, and CPLDs are often programmed using hardware description languages ​​(HDLs) such as Verilog or Verilog Hardware Description Language (VHDL), which allow for the construction of connections between the less functional internal hardware modules of the programmable device. The techniques described above can be used in combination to achieve a functionally modular result.

[0175] One or more of the operations described herein may be conditional. For example, one or more operations may be performed if certain criteria are met, such as by a computing device, a communication device, an encoder, a decoder, a network, a combination of the above, and / or the like. Exemplary criteria may be based on one or more conditions of device configuration, traffic load, initial system setup, packet size, traffic characteristics, a combination of the above, and / or the like. Various examples may be used when one or more criteria are met. It may be possible to implement any part of the examples described herein in any order and based on any condition.

[0176] While examples are described above, features and / or steps of these examples may be combined, divided, omitted, rearranged, revised, and / or extended in any desired manner. Various changes, modifications, and improvements will readily occur to those skilled in the art. Such changes, modifications, and improvements, although not expressly described herein, are intended to be a part of this specification and are intended to be within the spirit and scope of the description herein. Accordingly, the foregoing description is by way of example only and not by way of limitation.

Claims

1. 1. A method comprising: Determining a first point in three-dimensional (3D) space that is within the TriSoup triangle; determining a second point displaced from the first point by a vector; and determining at least one voxel of a set of voxels representing a point cloud by voxelizing the first point and the second point.

2. The method of claim 1 , wherein the point cloud comprises a decoded point cloud.

3. The first point in the TriSoup triangle is on an edge of the TriSoup triangle, or The method of claim 1 , including points that lie within the TriSoup triangle.

4. The method of any one of claims 1 to 3, wherein the second point is outside the TriSoup triangle.

5. 5. The method of claim 1, wherein the TriSoup triangle comprises three vertices, at least two of which are along two TriSoup edges of a cuboid associated with the TriSoup node.

6. Determining the first point that is within the TriSoup triangle includes:

6. The method of claim 1, comprising determining that the first point is at an intersection between the TriSoup triangle and a ray extending parallel to a coordinate axis in the 3D space.

7. 7. The method of claim 1, wherein the TriSoup triangle includes three vertices, and the first point is determined using a Moller-Trumbore algorithm using the three vertices of the TriSoup triangle and the ray.

8. determining at least one voxel; voxelizing the first point to determine a first voxel; voxelizing the second points to determine second voxels; The method of any one of claims 1 to 7, wherein the at least one voxel comprises at least one of the first voxel and the second voxel.

9. The method of any one of claims 1 to 8, wherein the first point and the second point are voxelized into a maximum of two voxels of the point cloud.

10. The method according to any one of claims 1 to 9, wherein the vector has a magnitude equal to a predetermined value.

11. The method of any preceding claim, further comprising receiving an indication of a value, wherein the vector has a magnitude equal to the value.

12. the second point is determined based on adding the vector to the first point; determining a third point based on subtracting the vector from the first point; 12. The method of claim 1, wherein the voxelizing comprises voxelizing the first point, the second point, and the third point to determine the at least one voxel of the point cloud.

13. 1. A computing device, comprising: one or more processors; A computing device comprising: a memory storing instructions that, when executed, cause the computing device to perform the method of any one of claims 1 to 12.

14. 1. A system comprising: a first computing device configured to perform the method of any one of claims 1 to 12; a second computing device configured to encode the point cloud.

15. A computer readable medium storing instructions that, when executed, cause the method of any one of claims 1 to 12 to be performed.

Images