Efficient end-to-end edge breaking implementation

Abstract

Example embodiments provide encoding and decoding methods and apparatuses for encoding of grid data. In an example embodiment, connectivity data of a grid is encoded as an ordered sequence of symbols using an edge breaking technique. Some embodiments provide for pre-processing and post-processing of non-manifold grids to allow for efficient encoding of such grids as one or more manifold grids. Some embodiments provide techniques for efficient coding of attributes per vertex and / or per triangle of a grid. Some embodiments provide arithmetic coding techniques that are intactly adapted to efficiently encode grid connectivity and / or attribute data.

Description

[0001] Cross-references This application claims priority to European Patent Application No. 23305505.2, filed on April 6, 2023, and European Patent Application No. 23305941.9, filed on June 14, 2023, both of which are incorporated herein by reference in their entirety. Background Technology

[0002] This disclosure relates to systems and methods for encoding and decoding meshes based on edgebreaker techniques. Edgebreakers are techniques capable of efficiently encoding the connectivity of triangular meshes. In its most straightforward implementation, a mesh encoded using edgebreakers is represented by an ordered series of symbols C, L, E, R, and S, referred to as the "CLERS" sequence. Generally, starting with an initial triangle, these symbols describe the different ways to attach new triangles, thus providing information about whether or how different edges of the new triangles connect to one or more existing triangles. Edgebreaker techniques are described in more detail, for example, in the following sources: •J. Rossignac, "3D compression made simple: Edgebreaker withZipandWrap on a corner-table," in Proceedings International Conference on Shape Modeling and Applications Genova, Italy, 2001. Describes decoding in the forward direction using a corner table (CT) representation of a grid, which yields a very compact algorithm. •H. Lopes, G. Tavares, J. Rossignac, A. Szymczak and A. Safonova, "Edgebreaker: a simple compression for surfaces with handles.," in ACM Symposium on Solid Modeling and Applications,, Saarbrucken, 2002. • J. Rossignac, "Edgebreaker: Connectivity compression for trianglemeshes," GVU center, Georgia Institute of Technology, 1999. Describes decoding using half-edge representation in the forward direction. •J. Rossigniac, "Course on triangle meshes and corner table," 2006. •M. Isenburg and J. Snoeyink, "Spirale Reversi: Reverse decoding of the Edgebreaker encoding," Computational Geometry , vol. 20, pp. 39-52, 2001. Describes the "spiral inversion" technique, which uses half-side representation but performs decoding in an inverted manner, resulting in faster decoding at O(n).

[0003] Following the call to the proposed MPEG V-Mesh (now renamed V-DMC), the solution proposed by Apple was selected as the basis for the MPEG V-Mesh Test Model (TM). This proposal is described in K. Mammou, J. Kim, A. Tourapis and D. Podborski, "m59281 - [V-CG] Apple's Dynamic Mesh Coding CfPResponse," Apple Inc, 2022. In this disclosure... Figure 1 and Figure 2 The document provides a summary diagram outlining the proposal.

[0004] For some frames, the test model uses a static mesh encoder to encode a base mesh, which is then subdivided to obtain an approximation of the original mesh. Currently, the V-Mesh test model uses a GoogleDraco implementation of an edgebreaker-based mesh encoder to encode the base mesh. Specifically, this implementation uses methods such as those described in M. Isenburg and J. Snoeyink, "Spirale Reversi: Reverse decoding of the edgebreaker encoding." Computational Geometry The “spiral inversion” version of the broken edge described in , vol. 20, pp. 39-52, 2001.

[0005] While edge-breaking encoding provides an efficient way to encode the connectivity of a basic mesh, it has certain limitations. For example, edge-breaking encoding alone is only effective for manifold surfaces without "holes" or "handles." Additional processing is required to bring such non-manifold surfaces to a format that can be encoded using edge-breaking techniques. Furthermore, edge-breaking encoding alone only encodes the connectivity of the mesh. The CLERS sequence itself does not encode additional properties of the mesh, such as vertex positions and any other attributes of the vertices (such as color, normal direction, UV coordinates, etc.). Summary of the Invention

[0006] Some example implementations support meshes with multiple connected components. In one example implementation, a method includes: encoding a first connected component of the mesh using edge breaking coding; identifying uncoded corners in the mesh after encoding the first connected component; and using the identified uncoded corners as entry corners to encode a second connected component of the mesh.

[0007] In some embodiments, this method may be performed as follows: identifying at least one non-manifold edge in the mesh; copying vertices along the non-manifold edge to separate the non-manifold edge into at least two manifold edges; stitching two of the at least two manifold edges together; and after stitching the two of the at least two manifold edges together, encoding the mesh using edge breaking encoding.

[0008] An example encoding method includes: identifying at least one non-manifold edge in a mesh, the non-manifold edge being defined by a parent vertex; preprocessing the mesh by copying the parent vertex along the non-manifold edge to separate the non-manifold edge into at least two manifold edges, each manifold edge being defined by a child vertex, each child vertex being copied from a corresponding parent vertex; encoding the preprocessed mesh into a bitstream using edge breaking encoding; and providing information identifying the parent vertex of the child vertex in the bitstream.

[0009] An example decoding method includes: obtaining information from a bitstream defining a plurality of connected components of a nonmanifold mesh with broken edge encoding; obtaining information from the bitstream associating child vertices with parent vertices; at least partially decoding at least two of the connected components, each of the connected components having a child vertex associated with a corresponding parent vertex; and deduplicating the child vertices to reconstruct the nonmanifold mesh.

[0010] An example encoding method includes: preprocessing a mesh with holes by creating virtual vertices connected to each vertex along the perimeter of the holes; encoding the preprocessed mesh in a bitstream using edge-breaking encoding; encoding information identifying the virtual vertices in the bitstream; and encoding at least one attribute for each of a plurality of vertices in the preprocessed mesh, wherein the attribute is not encoded for the virtual vertex.

[0011] An example decoding method includes: obtaining information encoding a grid from a bitstream; obtaining information identifying at least one virtual vertex in the grid from the bitstream; and decoding attribute information for a plurality of vertices in the grid from the bitstream, wherein the attribute information is not decoded for the at least one virtual vertex.

[0012] In some such embodiments, decoding attribute information for multiple vertices includes predicting attribute information for multiple vertices, wherein no attribute information is predicted for virtual points. The decoder may remove virtual points.

[0013] An example mesh encoding method includes: encoding the connectivity of a mesh; entropy encoding a first table of starting point positions of vertices in the mesh; and entropy encoding a second table of point residuals of vertices in the mesh separately.

[0014] An example mesh decoding method includes: decoding information indicating the connectivity of the mesh; performing entropy decoding on a first table of starting point positions of vertices in the mesh; and separately performing entropy decoding on a second table of point residuals of vertices in the mesh.

[0015] An example mesh encoding method includes: obtaining information defining a mesh having multiple connected components (CCs), each vertex in a CC having a unique global range index; for each CC, shifting the index of a vertex in the CC from the global range index to a CC range index; and using the CC range index to encode each of the CCs.

[0016] An example mesh decoding method includes: obtaining information encoding a plurality of connected components (CCs), each vertex in a CC having a corresponding CC range index; decoding each of the CCs; and for each vertex, shifting the vertex's index from the CC range index to a global range index.

[0017] An example of a grid encoding method includes: obtaining information describing a grid having multiple triangles, each triangle having an attribute; encoding the grid as an ordered sequence of symbols in edge-breaking encoding, each of the triangles corresponding to an associated symbol; and encoding the attributes of the triangles, wherein the attribute of the current triangle is encoded using predictions based solely on the attributes of at least one triangle preceding the current triangle in the ordered sequence of symbols. For example, the attribute of each triangle may be encoded as an incremental value relative to the previous triangle in the sequence (serving as the value of the predicted attribute of the previous triangle).

[0018] A grid decoding method according to some embodiments includes: obtaining an ordered sequence of symbols representing a grid with broken edges encoded of a plurality of triangles, each triangle having an attribute; decoding the grid; and decoding the attribute of the triangle, wherein the attribute of the current triangle is decoded using predictions based solely on the attributes of at least one triangle preceding the current triangle in the ordered sequence of symbols. Attached Figure Description

[0019] Figure 1 This is a functional block diagram of an example grid coding system.

[0020] Figure 2 This is a functional block diagram of an example grid decoding system.

[0021] Figure 3 An example of a broken edge mesh codec according to some embodiments is illustrated.

[0022] Figure 4 This is a flowchart of the encoding process according to some embodiments.

[0023] Figure 5 This is a flowchart of the decoding process according to some embodiments.

[0024] Figure 6 The diagram illustrates an example of a corner table data structure.

[0025] Figure 7 An example of an extended corner table is shown to support UV coordinate and normal vector attributes.

[0026] Figure 8 The diagram illustrates the extended corner table data structure used in memory for the algorithm.

[0027] Figure 9 The example coding entry point process is illustrated.

[0028] Figure 10 The diagram illustrates a sample process called preProcess, which performs input model transformation, cleaning, filling, and quantization.

[0029] Figure 11 The diagram illustrates the encoding process, which includes edge-breaking topology encoding and attribute prediction.

[0030] Figure 12 The example process, startCompression, is illustrated.

[0031] Figure 13 illustrates the process compressRec.

[0032] Figure 14 The diagram illustrates the process checkHandle (check handle).

[0033] Figure 15 The example decoding entry point process is illustrated.

[0034] Figure 16 illustrates the process initDecompression, which allocates memory to store the decompressed output and initializes other tag tables.

[0035] Figure 17 illustrates the example process startDecompression.

[0036] Figure 18 The diagram illustrates the declaration of connectivityCompression.

[0037] Figure 19 illustrates the example process decompressConnectivity.

[0038] Figure 20 An example of the CheckHandle procedure used to support shifting is illustrated.

[0039] Figure 21 The diagram illustrates the declaration of attributesDecompression.

[0040] Figure 22 illustrates an example of the process DecompressVertices.

[0041] Figure 23-26 The diagram illustrates an example of the process decompressUvWithSeparateIndex (decompressing a Uv with a separate index), including the declaration A ( Figure 24 ), Declaration B ( Figure 25 ) and declaration C ( Figure 26 ).

[0042] Figure 27An example of the postProcess procedure is illustrated, which transforms the reconstructed CT mesh into an indexed face set when removing virtual points and optionally recreates the nonmanifold using lossless encoding.

[0043] Figure 28 The diagram illustrates the side-by-side preProcess and postProcess processes.

[0044] Figure 29A and 29B The diagram illustrates a mesh with non-manifold vertices. Figure 29C The illustration shows an example technique for fixing a problem by splitting vertices.

[0045] Figure 30 The illustration shows how to repair two of the three surfaces generated by replicating non-manifold vertices by re-stitching.

[0046] Figures 31A-31D The illustration depicts filtering of a non-manifold surface according to some embodiments. The example technique may be referred to as cutting and re-stitching.

[0047] Figure 32 The illustration shows an example vertex copying phase.

[0048] Figure 33 The illustration shows an example preprocessing operation for re-stitching using a table of matching counterparts.

[0049] Figures 34A-34B Examples of the processes deduplicateVertices and processDuplicate are illustrated.

[0050] Figure 35 The illustration shows an example of a process for regenerating a non-manifold surface by deduplicating some vertices.

[0051] Figure 36 The illustration shows a process in an example embodiment where holes in a surface are filled with virtual vertices and virtual triangles.

[0052] Figure 37 The illustration shows an example of a C++ procedure for filling all the holes in a grid described as a corner table (O, V, OT, OTC).

[0053] Figures 38A-38C The illustration shows an example of a C++ procedure for filling a single hole in a grid described as a corner table (O, V, OT, OTC).

[0054] Figures 39A-39BThe illustration shows attribute prediction using a main index table that leverages processes such as encodeAttributes.

[0055] Figure 40 The illustration shows an example of the assertion isCornerVertexDummy (which is a corner vertex dummy).

[0056] Figure 41 The diagram illustrates the decoding process for the corresponding attributes (decodeAttributes).

[0057] Figure 42 illustrates an example of the process posEncodeWithPrediction (using prediction for position encoding).

[0058] Figure 43A The illustration shows a corner according to some embodiments. c A strategy for predicting multiple parallelograms of locations and filtering virtual points.

[0059] Figure 43B The illustration shows a corner according to some embodiments. c The strategy of minimum stretching prediction of UV coordinates and virtual point filtering.

[0060] Figures 44A-44B The diagram illustrates an example of the process posDecodeWithPrediction (decoding using the predicted position).

[0061] Figures 45A-45B The diagram illustrates an example of the process uvEncodeWithPrediction (encoding with predicted uvs).

[0062] Figures 46A-46B The illustration shows an example of declaring predictUV. dvec2 and dvec3 are double-precision vectors.

[0063] Figure 47A The illustration shows how to handle UV seams using only the primary index table.

[0064] Figure 47B The diagram illustrates the processing of UVs using a separate index table and its application to corners. c The separate index for predicting UV coordinates for corners c p The selection strategy.

[0065] Figures 48A-48B The diagram illustrates an example of the process encodeSeparateIndexAttributes.

[0066] Figures 48A-49BThe diagram illustrates an example of the process decodeSeparateIndexAttributes.

[0067] Figure 50 The illustration shows an example of the process save.

[0068] Figure 51 The illustration shows an example of pseudocode used to control the Dirac encoder for the CLERS table.

[0069] Figure 52 Illustrations are provided in some embodiments that reproduce a portion of the encoding principles used for motion vectors.

[0070] Figure 53 The illustration shows an example offset / shift for ExpGolomb encoding.

[0071] Figure 54 The illustration shows examples of code using an arithmetic encoding context for some embodiments.

[0072] Figure 55 The compression performance of the encoding method described in this article is illustrated.

[0073] Figure 56 This is a block diagram of an example system that implements various aspects and embodiments.

[0074] Figure 57 The illustration shows an example implementation of one embodiment of virtual index removal.

[0075] Figure 58 The illustration shows an example implementation of another, more efficient, embodiment of virtual index removal.

[0076] Figures 59A-59B The illustration shows the example process encodePerFaceAttributes.

[0077] Figure 60 The illustration shows an example of Dirac AC entropy encoding for the material ID of each face.

[0078] Figures 61A-61C The illustration shows an example of the search order for corner [0] = c (the operation is repeated for corner [1] = cn and then for corner [2] = cp). Figure 61A The diagram illustrates the face for which the ID will be encoded, along with the L, R, and F neighboring triangles. (The three neighboring triangles are always present because dummy points are used to fill the holes.) Figure 61B The diagram illustrates the search in the neighborhood loop along the first direction on R, R1, R2, etc. Figure 61CThe diagram illustrates the subsequent search in another direction. Detailed Implementation

[0079] Overview of Example Implementations Edge breaking (EB) is a technique used to encode and decode the topology (connectivity and handles) of a mesh (collectively referred to as "coding"). It is the core of the algorithm and proposes to use a predictor for the position of the vertex to generate some entropy-encoded efficient data.

[0080] Some embodiments of this disclosure provide a fully end-to-end extended version of EB. Some embodiments include full low-level and higher-level syntax for bitstreams.

[0081] The example implementation provides support for topology coding (connectivity and handles) and geometry with incremental coding.

[0082] Some implementations provide mesh cleaning for non-manifold removal (preprocessing on CT).

[0083] Some implementations provide support for holes and boundaries through "virtual" dummy points.

[0084] Some implementations include a lossless mode that reconstructs the mesh using the difference in "connectivity" during decoding when needed.

[0085] Some implementations provide support for multiple connected components (CCs).

[0086] Some implementations include support for texture coordinates encoded using a unique index table or a separate index table.

[0087] Some embodiments include multi-parallelogram and stretch prediction. Some of these embodiments further provide support for virtual points and separate index tables when needed.

[0088] Some embodiments include Dirac and / or RANS arithmetic encoders (AC). Some of these embodiments use specific binarization schemes and arithmetic coding contexts as described herein for use with Dirac coding.

[0089] Some embodiments include support for pre-quantized input grids in addition to support for input grid quantization.

[0090] Some implementations include support for identifiers or colors for each face.

[0091] Some implementations provide optimizations for attribute prediction and encoding for each facet.

[0092] Figure 3The illustration shows an example of a broken-edge mesh codec according to some embodiments. The top row is the encoding row, and the bottom row is the decoding row. Figure 3 As illustrated in the figures, the example embodiments include some or all of the following. During encoding, preprocessing 302 can be used to clean up potential connectivity issues (non-manifold edges and vertices) that may exist on the input mesh. This cleanup is performed because the edge-breaking algorithm itself does not work on meshes with such connectivity issues. In some embodiments, cleaning up non-manifold edges and vertices involves copying multiple points. Some embodiments track those copied vertices during decoding to merge those vertices. This makes it possible to reduce the number of points in the decoded mesh, but requires sending some additional information in the bitstream. In some embodiments, the preprocessing 302 further includes adding some dummy points to fill potential holes on the surface, since the edge-breaking algorithm does not handle holes alone. The example embodiments operate to fill holes before encoding and recreate holes after decoding. The example embodiments use “virtual” dummy points and generate and encode dummy triangles attached to these dummy points, but the 3D positions of those points are not encoded or decoded. In some embodiments, vertex attributes are quantized if needed. Those attributes can be provided to the already quantized encoder.

[0093] The example implementation uses a modified version of the edge-breaking algorithm that generates the CLERS table (a table consisting of symbols 'C', 'L', 'E', 'R', and 'S') to encode the connectivity of mesh AT 304. This stage also generates some tables in memory for the attribute prediction stage. Then, starting from position 1, vertex attributes are predicted at 306. Finally, other attributes are predicted based on position prediction, in the case of texture UV coordinates. Configuration and metadata are also provided in the bitstream, with the CLERS table, some other connectivity, and all attribute prediction residuals entropy-encoded and added to the bitstream at 310.

[0094] In the example decoding method, entropy decoding is performed on all entropy-encoded sub-bitstreams at 312. At 314, we reconstruct mesh connectivity using the CLERS table and an edge-breaking algorithm. We also add additional information to manage handles that describe the topology. At 316, we use the mesh connectivity and a minimal set of vertex positions expressed in 3D coordinates to predict the positions of all other per-vertex nodes. We then apply attribute residuals to correct the predictions and obtain the reconstructed vertex positions. At 316, additional attributes are decoded, potentially depending on the decoded positions, with respect to UV coordinates. The connectivity of attributes using a separate index table is reconstructed using the binary seam information of each entropy-encoded edge.

[0095] In the post-processing stage at 320, we remove the dummy triangles, optionally recreate the nonmanifold problem if the encoder is configured to perform lossless encoding, and optionally dequantize the vertex attributes if the model is quantized by the encoder.

[0096] Figure 4 This is a flowchart of the encoding process according to some embodiments.

[0097] Figure 5 This is a flowchart of the decoding process according to some embodiments.

[0098] Extended corner table In J. Rossignac, "3D compression made simple: Edgebreaker withZipandWrap on a corner-table," in Proceedings International Conference on Shape Modeling and Applications The corner table data structure for representing meshes is described in Genova, Italy, 2001 and further described in J. Rossigniac, "Course on triangle meshes and corner table," 2006.

[0099] Figure 6 The diagram illustrates a portion of a triangular mesh, stored as in a corner table (also known as an OV table). For each corner index c in the corner table, cv=3 identifies the index of the vertex at which the corner is located. Index ct=0 is the index of the triangle containing corner c. Within this triangle, index cn=0 identifies the next corner (in the counter-clockwise direction), and cp=1 identifies the previous corner. Index co identifies the corner opposite corner c. For example, in... Figure 6 In the table, corner co=5 is opposite to corner c=2 (and vice versa). Index cl identifies the corner to the left of corner c, and index cr identifies the corner to the right of corner c. Corner records can be made in a corner table with entries including the following: Figure 6 The connectivity shown: Corner Index Vertex Index Relative Corner Index 0 1 7 1 2 8 2 3 5 3 2 9 4 1 6 5 4 2

[0100] The "corner index" column does not need to be stored in the table because it corresponds to the position of each row within the table. The triangular index for each corner can be calculated as follows: ct = INT (c / 3).

[0101] Therefore, corners 0, 1, and 2 are all within the triangle with index 0; corners 3, 4, and 5 are all within the triangle with index 1; and so on. The additional relationships between entries in the corner table can be expressed as follows: cn = 3c.t + (c+1) MOD 3 cp = cnn cl = cpo cr = cno.

[0102] In some embodiments, an additional table may be used to store the position coordinates of each vertex.

[0103] Figure 7 The illustration shows an example of an extended corner table, as used in some embodiments, to support UV coordinate and normal attributes using separate index tables TC / OTC and N / ON, respectively. Texture coordinates and normals can be stored in two additional separate tables.

[0104] Example implementations extend the corner table data structure to support other attributes, with or without secondary attribute indexes, such as... Figure 7 The illustration shows an example embodiment where, in the absence of a separate index for dereferencing UV coordinate attributes, a UV coordinate table is included alongside the position table. The UV coordinate table is then dereferencing using V with respect to position. Alternatively, some embodiments also add two tables, TC and OTC, to encode (dereferencing) the connectivity of UV coordinates. TC is used to store UV coordinate indices and OTC is used to store relative corners for UV connectivity. The same principle can be applied to add support for per-vertex normals (N / ON / normal_vectors) or per-vertex colors (C / OC / colors).

[0105] Figure 8 An extended corner table data structure that can be used in memory in an example embodiment is schematically illustrated. Figure 17 depicts a more flexible use of separate tables for each row of the table.

[0106] Figure 8 This summarizes the data structure we use to store all the information in our extended corner table. This scheme can be extended for any per-vertex attribute type to use or not use a dedicated index table modeled using pairs (index table / relative table). In this implementation, the ID of each face is included in the table.

[0107] Overview of the encoding process In this chapter, we present some advanced procedures to better understand the structure and flow of the example coding process.

[0108] exist Figure 9 The example encoding entry point process is described. It consists of three steps: preprocessing the input grid, encoding its broken edges, and finally entropy encoding and storing it in the bitstream.

[0109] Figure 10 The diagram illustrates a sample process, preProcess, used to perform input model transformation, cleaning, padding, and quantization. The characteristics of this process will be provided in further detail below. Edge-breaking encoding is introduced here for a global understanding before its introduction below. Further details will be provided below. Figure 25 The save process described in the text.

[0110] Figure 11 The diagram illustrates the process of encoding, including edge breaking topology encoding and attribute prediction. Features described in particular detail in this paper are shown in bold. The process first initializes some data structures, primarily allocating some tables for labeling attributes or triangles and a table G_est for storing the (predicted) estimates of location attributes. It then runs the edge breaking algorithm on each connected component (CC) of the mesh. To do this, we add a while loop to the process and manage some starting indices for the handles we update for each new component. After encoding a CC, we run the process findRestartCorner to check if there are any unlabeled corners (i.e., not yet encoded) in the MC table that we can use as entry corners for encoding new CCs.

[0111] Some example implementations support meshes with multiple connected components. In one example implementation, the method includes: encoding a first connected component of the mesh using edge breaking encoding; identifying uncoded corners in the mesh after encoding the first connected component; and using the identified uncoded corners as entry corners to encode a second connected component of the mesh.

[0112] Figure 12 The example procedure `startCompression` is illustrated. Features described in particular detail in this paper are shown in bold. This procedure is the starting point for the actual edge-breaking algorithm used to encode the CC. It encodes the first triangle and then begins the recursive encoding of the CC. The method involves recording the processed corners into a table named `processedCorners` (Processed Corners). This table is later used to dispose of attributes related to the SeparateIndexAttributes table. We also add a concrete procedure `encodeSeparateIndexAttributes` at the end of the procedure to encode / predict attributes with the SeparateIndexAttributes table. This final procedure utilizes the `processedCorners` table to perform its processing.

[0113] The `encodeAttributes`, `encodeSeparateIndexAttributes`, and `encodePerFaceAttributes` procedures are described in further detail below. They essentially perform attribute predictions and store the results on some tables that will subsequently be entropy-encoded. Note now that, for a given corner, the `encodeAttributes` procedure computes a prediction for the attribute using the primary index table.

[0114] Figure 13 illustrates the process compressRec. The table oClers is the output table of CLERS symbols. Features described in particular detail in this paper are shown in bold. This process is the core edge-breaking algorithm used for encoding CC. Processed corners are added to a table named processedCorners.

[0115] Figure 14 The diagram illustrates the process checkHandle.

[0116] In light of the above description of how to construct the CLERS and handle tables at the encoding stage, the following description provides an example embodiment for reconstructing the mesh topology from those tables to recreate the corner tables during decoding.

[0117] Overview of the decoding process Figure 15 The example decoding entry point process is illustrated. Features described in particular detail in this paper are shown in bold. The process comprises several steps, which respectively perform syntax parsing and arithmetic decoding of the input bitstream, edge-breaking decoding using a corner table, and some post-processing on the corner table to produce the final mesh in the index face set data structure. In this section, we will only design the edge-breaking decoding process (initDecompression and startDecompression) and the subprocesses related to topology decoding. Parsing and entropy decoding will be described in further detail below.

[0118] Figure 16 illustrates the process `initDecompression`, which allocates memory for storing the decompressed output and initializes other tag tables. Features described in particular detail herein are shown in bold. During `initDecompression`, the "start" point is where no predictions exist; therefore, its attributes are stored in a separate table containing global values ​​(`sVertices`, `sUVCoords`). Correspondingly, the predicted attributes are stored in the other input tables `iVertices` and `iUVCoords`. These tables will be described further below.

[0119] This section describes example tables (V, O, TC, OTC, D, M, U, MTC, and duplicatedIndexRemapping) used for topology decoding. Values ​​for initializing O, TC, OTC, and D are recorded because those conditions are used to allow for proper execution of the algorithm later. Example embodiments include tables for disposing of texture coordinate attributes (which in some embodiments are expanded in the same way for per-vertex normals and colors), attributes regarding the separation index table (see the hasSeparateUvIndex declaration), and finally, a deduplication remapping table. We also add the disposal of virtual points.

[0120] Figure 17 illustrates the example procedure startDecompression. Features described in particular detail herein are shown in bold. The startDecompression procedure, which begins decoding, is called after the initDecompression initialization phase.

[0121] The example embodiment provides the handling of CCs using offsets. Then, for each CC, after the connectivityDecompression and attributesDecompression stages, the vertex index and UV coordinate index are shifted back to make them valid in the global index space. In some embodiments, this process can also be extended to any other attribute type. The example embodiment further includes deduplication post-processing, which will be described in further detail below.

[0122] Decoding Connectivity Recursion Figure 18 The diagram illustrates the declaration `connectivityCompression`. Features described in particular detail herein are shown in bold. Figure 18 The `connectivityDecompression` declaration presented in the code can be inserted appropriately into the pseudocode in Figure 17, thus accessing the establishment variable. The declaration is executed for each CC. Within this logic block, the algorithm uses methods such as those described in H. Lopes, G. Tavares, J. Rossignac, A. Szymczak and A. Safonova, "Edgebreaker: a simple compression for surfaces with handles." ACM Symposium on Solid Modeling and ApplicationsTechniques similar to those described in Saarbrucken, 2002, are used to initialize the relative corners of the CC handle. An example embodiment further adds the first corner (index 0) to the processedCorners table. We finally reconstruct the connectivity of the first triangle and begin the connectivity decompression recursion described with reference to Figure 19.

[0123] Figure 19 illustrates the example process decompressConnectivity. Features particularly detailed herein are shown in bold. In the example embodiment, the decompressConnectivity process supports shifting to manage CCs, and the process includes a history of processed corners. The process further provides support for relative corners to use, for example, as described in H. Lopes, G. Tavares, J. Rossignac, A. Szymczak and A. Safonova, "Edgebreaker: asimple compression for surfaces with handles," in ACM Symposium on Solid Modeling and Applications The technique described in Saarbrucken, 2002, is used to support handles.

[0124] Figure 20 The diagram illustrates an example of the CheckHandle procedure used to support shifting. The compression process utilizes shifted tables O and G (code not shown here).

[0125] At the end of the connectivityDecompression statement (see Figure 17), the connectivity is reconstructed and can be used with the predicted attribute residuals that were previously entropy decoded to reconstruct / estimate the attributes. This next step is described in the following sections.

[0126] Decoding attribute recursion Figure 21 The diagram illustrates the declaration of `attributesCompression`. The `attributesDecompression` declaration can be inserted appropriately into the pseudocode in Figure 17, thus accessing the set variables. The declaration is executed for each CC. In this logic block, we first use `decodeAttributes` to reconstruct the attributes of the first triangle, and then recursively reconstruct the attributes of the other triangles by calling `decompressVertices`. This first step only applies to attributes that use the main index table.

[0127] In the second recursion, we optionally reconstruct the attributes dereferenced by the auxiliary index table. These are implemented after the first recursion has terminated before being processed, as they depend on its output data. The presented code illustrates the second step for UV coordinates, calling the `decompressUvWithSeparateIndex` procedure. In some embodiments, extensions to other types of per-vertex attributes, such as per-vertex normals or colors, are also performed. The prediction scheme at lower levels is adjusted accordingly.

[0128] Some embodiments further include a third recursion, in which the properties of each face are reconstructed, as described in further detail below.

[0129] Figure 22 illustrates an example of the DecompressVertices procedure. The procedure uses a shifted table to handle CCs. It recursively traverses a triangular tree and reconstructs attributes when necessary by calling the decodeAttributes procedure.

[0130] Figure 23 The diagram illustrates an example of the process decompressUvWithSeparateIndex. It differs from decompressVertices in that it handles texture seams using the auxiliary index tables TC and OTC.

[0131] The process is broken down into three successive declarations: declaration A, in Figure 24 As shown in the diagram; statement B, in Figure 25 As shown in; and statement C, in Figure 26 The table is shown below. Each of these loops over processedCorners. In some embodiments, such as in the decompressVertices process, the order of the corners is implicitly found, in which case the processedCorners table may not be necessary. However, the table is shown in this example for ease of coding and interpretation.

[0132] refer to Figure 24 Using the iSeams table (which originates from the bitstream), the recursion of declaration A first assigns the code in [0, -1, -2] to each corner of the OTC table to identify whether they are on a seam or whether the UV coordinates will be the same on each side of the edge. In the first case, a different UV index is used for each side of the edge. Note that the example embodiment also skips the final virtual point inside this loop. Reconstructing the entire relative table OTC is not necessary (in the sense of connectivity with respect to table O); the table can be used solely to store the code for declaration B.

[0133] refer to Figure 25In the second pass, the recursion of declaration B utilizes the code from pass A to assign UV coordinate indices to those corners by oscillating around them. This pass populates table TC with UV indices. During the loop, corners that have already been visited or associated with virtual points are skipped.

[0134] In the final reading, refer to Figure 26 The recursion from declaration C uses the TC and MTC tables to calculate the final UV coordinates, marking the UV coordinates that have been processed. If the bitstream was encoded without prediction (cfg.uvPred=none), the values ​​of table iUVcoords are copied as is into the UV table using a CC shift. Otherwise, the UV coordinates are predicted using the uvSepDecodeWithPredictionExt procedure as described below.

[0135] Post-decoding processing At the end of the startDecompression process, such as Figure 15 As described, connectivity and attributes are decoded. In some embodiments, additional post-processing steps are performed to complete the mesh. Figure 27 The postProcess procedure is described below. The following section compares it with the preProcess procedure (see...). Figure 28 The different parts of the process are described symmetrically.

[0136] Figure 27 An example of the postProcess procedure is illustrated, which converts the reconstructed CT mesh into an indexed face set when removing virtual points and optionally recreates the nonmanifold using lossless encoding.

[0137] The example preprocessing and postprocessing steps are shown in more detail in the following sections.

[0138] Preprocessing and postprocessing In some embodiments, preprocessing is performed to convert some standard indexed face set meshes into a corner table representation for efficient use by edge-breaking algorithms optimized to run on corner tables. Indexed face set meshes are also called face-vertex meshes. These are those traditionally stored as ".obj", ".ply", or other common file formats that store triangle meshes. The face-vertex representation is also a representation ingested by the graphics hardware used for rendering. The conversion to a corner table can be performed using known techniques. However, during the conversion to a CT representation, the example embodiment also performs filtering of non-manifold vertices and edges, as described below. The example embodiment also introduces dummy points and dummy faces to fill the final holes in the input mesh, as described below. Symmetrically, during decoding, the final dummy points are removed, and non-manifold connectivity is recreated in lossless mode. Figure 28An overview of example preprocessing and postprocessing is presented side-by-side. The quantization and dequantization processes can be performed using standard uniform quantization mechanisms. In some embodiments, quantization and dequantization are not performed, such as in embodiments where a pre-quantized mesh (e.g., a mesh with all integer properties) is encoded.

[0139] Figure 28 The diagram illustrates the side-by-side preProcess and postProcess processes. Figure 10 and 27 The notes and explanatory text provide additional details about preprocessing and postprocessing, respectively. In some embodiments, optional actions for deduplication are also performed during preprocessing within the fixNonManifold process.

[0140] Non-manifold filtration Some meshes derived from, for example, 3D reconstructions from scanners may have some “incorrect” connectivity in the sense that they do not possess a manifold topology that can be processed using standard broken-edge encoding. For example, a surface described by triangles may be non-manifold at some vertices or edges and thus subject to, for example, Figure 9 and 10 The processing is shown in the diagram. The purpose of filtering is to fix those problems to allow broken edge encoding. In some embodiments, this is done by copying the selected vertices, so that triangles sharing non-manifold edges or vertices no longer share the same edges or vertices.

[0141] Figure 29A and 29B The diagram illustrates a mesh with non-manifold vertices. Non-manifold vertices are indicated using dashed ellipses.

[0142] Figure 29C The illustration shows an example technique for fixing a problem by splitting vertices.

[0143] exist Figure 29A In the example (e.g., indexes in the vertex table) i 1) A vertex is shared by two triangles, but those triangles do not share any edges (therefore, the vertex is non-manifold). An example implementation addresses this non-manifold problem by copying the shared vertex to create a new vertex with the same 3D position and properties; this new vertex is added to the vertex table and serves as its index. i n In this case, a face description refers to... i 1 and the second page describes referring to i n (Regarding visibility, in) Figure 29C Lieutenant General Top i 1 and i nThe illustration shows slightly different positions after splitting, but it should be understood that, as indicated in the attribute table, the vertices... i 1 and i n The positions can be the same after splitting. After processing, the faces are no longer connected, therefore, there is no non-manifold problem. In this example, it will result in two connected components (CC), each consisting of only one triangle (a "connected component" is a set of triangles for which there is always a path of connectivity to other triangles in that component). By completing this copy, we see that we can generate multiple connected components.

[0144] When the scheme used to repair non-manifold vertices is applied to non-manifold edges, some surface continuity issues may arise. (Reference) Figure 30 A single non-manifold edge is shared by three triangles. If we duplicate the vertices of the non-manifold edge, the faces will no longer be connected. If faces T1 and T2 are part of a larger connected component, this will introduce "cracks" into the mesh surface. Furthermore, duplicating all those vertices introduces more vertex data to encode. Figure 30 As illustrated in the diagram, in an example embodiment, a re-stitching method can be performed to re-add two of the three surfaces generated by copying non-manifold vertices. (For clarity, the copied vertices are illustrated with slightly different positions, although the splitting and stitching process does not change the positional properties of the vertices.) Because Figure 30 The stitching process shown in the diagram stitches surfaces T1 and T3 together into a single manifold surface, while T2 remains a separate manifold surface.

[0145] Figures 31A-31D The illustration depicts filtration of a non-manifold surface according to some embodiments. Example techniques may be referred to as cutting and re-stitching. Figure 31A As shown, triangle connectivity on non-manifold edge 3102 is cut by resetting the relative corners to -2 (or to another predetermined value if appropriate). Vertices are duplicated as needed, such as... Figure 31B As shown in the dashed ellipse, only the vertices of the top triangle are copied (for illustration, the copied vertices are shown at a slightly offset position, although the positional properties of those vertices may not actually have been changed by the copying process). Figure 31C As shown, the process begins from the visited corner. c Swing to the right and left. (Example) Figure 31D As shown, when the left vertex index lv equal to the index of the right vertex rv and o 1 = o When 2 = -2, re-stitch the relative corners.

[0146] Some example implementations perform a vertex copy operation to remove one or more non-manifold edges. A preprocessing step is then performed, which, where possible, repairs newly introduced holes through a re-stitching process. This reduces or eliminates the need to address specific situations during the remainder of the process, simplifying edge breaking implementation and reducing the number of virtual points, UV seams (since geometric seams necessarily introduce texture seams), and their impact on edge breaking.

[0147] In some embodiments, this method may be performed as follows: identifying at least one non-manifold edge in the mesh; copying vertices along the non-manifold edge to separate the non-manifold edge into at least two manifold edges; stitching two of the at least two manifold edges together; and after stitching the two of the at least two manifold edges together, encoding the mesh using edge breaking encoding.

[0148] In some embodiments, the non-manifold filtering stage ( Figures 31A-31D (As illustrated) The following occurs during preprocessing. The mesh is filtered for non-manifold surfaces. Triangle connectivity of the non-manifold surface is cut by resetting the O-table for some corners, setting the O-value to -2 at the appropriate corners. Vertices are copied if necessary. Triangle connectivity is re-stitched by modifying the O-table as appropriate. Filtering of non-manifold surfaces can be performed using known techniques, such as those used in the Google Draco system. In the example embodiment, a "re-stitching" phase is performed to reconnect some triangles. This also allows the non-manifold surface to be recreated without lossy encoding. The example embodiment further includes a phase for copying vertices. Figure 32 The “copying vertices” phase is described in bold. Features described in particular detail herein are shown in bold. These bolded features include those for handling deduplication for the lossless mode and those for re-stitching. In summary, the example embodiment tracks the indices of added vertices (for the lossless case) and stores a table of corner pairs to “re-stitch” those at the end of the process in the final pass, such as... Figure 31C and Figure 33 As shown in the image. Figure 33 The illustration shows an example preprocessing operation for re-stitching using a table of matching counterparts.

[0149] Non-manifold filtration, non-destructive case In some embodiments, lossless encoding of the input mesh is performed to accurately reproduce connectivity, including non-manifold problems. As shown in the previous section, the example embodiment tracks the inserted (copied) vertices and the original vertices (here referred to as the parent vertices of the inserted vertices) in a table during preprocessing. Some data representing those copies is provided in the bitstream and then used during decoding (at several stages) to reconstruct accurate connectivity if needed.

[0150] The availability of lossless modes for connectivity, as described in this paper, offers at least two advantages. First, it allows for fully lossless encoding modes for both connectivity and attributes. Second, in some cases, lossless encoding of meshes allows for higher encoding gains, even when lossy encoding is used overall for the mesh (e.g., for attributes). These gains can be the result of avoiding vertex duplication during the subdivision process of encoding and then using it for translation encoding. Lossless encoding of meshes can also enhance motion encoding.

[0151] Example encoding methods include: identifying at least one non-manifold edge in a mesh, the non-manifold edge being defined by a parent vertex; preprocessing the mesh by copying the parent vertex along the non-manifold edge to separate the non-manifold edge into at least two manifold edges, each manifold edge being defined by a child vertex, each child vertex being copied from the corresponding parent vertex; encoding the preprocessed mesh into a bitstream using edge breaking encoding; and providing information in the bitstream that identifies the parent vertex of the child vertex.

[0152] Example decoding methods include: obtaining information from a bitstream defining multiple connected components of a nonmanifold mesh with broken edge encoding; obtaining information from the bitstream associating child vertices with parent vertices; at least partially decoding at least two of the connected components, each of which has a child vertex associated with its corresponding parent vertex; and deduplicating the child vertices to reconstruct the nonmanifold mesh.

[0153] During the encoding phase, when positions are copied (possibly recursively) via non-manifold filtering, the example embodiment tracks vertices with the same original parent vertex. A unique identifier (e.g., varying from 1 to the final number of added vertices) is assigned to each vertex index associated with a copied vertex. This information can be stored, for example, in a duplicatesMap, where each entry associates this identifier with the index of the copied vertex. To populate the duplicatesMap, when a vertex is added to the map, it is determined whether the parent vertex is already in the map. In one case, the parent vertex is already in the map and associated with the unique identifier. In the alternative case, both the parent vertex and the added vertex are added to the map, thus associating those with a new identifier (which could be the current number of split vertices).

[0154] The number of split vertices is the number of original position indices copied during the process. The total number of entries in the duplicatesMap at the end of the process is (number of split vertices + number of added vertices).

[0155] When using the primary index table (see...) Figure 37During attribute encoding, when traversing the topology, upon encountering a split or added vertex, registration is performed between the processed corner index and the corresponding unique split vertex index. Some embodiments use the following: an `oDuplicateSymbolIdx` array storing the processed corner index; and an `oDuplicateSplitVertexIdx` array storing the unique split vertex index. As the `processedCorners` array is updated for each triangle (rather than for the first two vertices of any connected component), some embodiments additionally store a Boolean value indicating whether a copied vertex exists on the first two vertices of the first triangle of any connected component. Example embodiments thus additionally use a Boolean array named `oDuplicatesOnStart` of size (2 * connected components).

[0156] Example implementation: Then, the bitstream is signaled to notify some or all of the following information: The size of the oDuplicateSymbolIdx array = number of split vertices + number of added vertices. • An integer array of size oDuplicateSymbolIdx. (Of course, this feature or any other software implementation feature described herein may be given a name other than that used in this disclosure. For example, the integer array oDuplicateSymbolIdx may alternatively have a name such as perDuplicateProcessCornerIndices). Some embodiments allow up to three copies associated with the first processed corner index of any connected component (for each of the three vertices of the first triangle in those triangles, there is one corner). In some embodiments, this may be incrementally encoded and inserted as a variable unsigned integer. • An integer array of size oDuplicateSymbolIdx, which provides a unique value for each vertex group (including the original parent vertex) copied from the split parent vertex, is encoded as a variable such as an unsigned integer. • A Boolean array of size 2 * (number of connected components), which can be encoded using Dirac arithmetic coding as follows: ○ For a variable unsigned integer dup01_encoded_size, dup01_encoded_size is the size in bytes of dup01Buffer (2*nbCC bits before encoding) containing AC-encoded markers used to signal copying at position 0 or 1 in each CC. ○ Contains dup01_encoded_size bytes of encoded buffer.

[0157] Alternatively or additionally, the example embodiments signal some or all of the following information in the bitstream: • A boolean value indicating whether the vertex is copied for each “encodeAttributes” location procedure call. Then, a Boolean value is used to indicate that this is the first occurrence of the value. • If it is not the first time it appears, the index of the parent split vertex in the table of basic split vertices.

[0158] In some embodiments, the information is arithmetically encoded. This scheme can be used to reduce the amount of information encoded in the stream when there are many splits (which will have to be verified). Alternatively, the Boolean array (a) can be encoded only for the CCs containing the copied vertices, thereby adding another level of indirection where the first bit string should define which CCs include the copied vertices, but reducing the size of array (a) which potentially removes ranges with constant false values.

[0159] In some embodiments, it is determined which encoding method yields the minimum bitstream, the selected method is used to encode the grid, and the indication of the method used is signaled in the bitstream.

[0160] In some embodiments, to prevent the copied location from being encoded twice or more, the process returns from `encodeAttributes` in response to determining that the copied vertex has been processed, without calculating the associated residuals. The corresponding function is also performed in the decoder. This embodiment is particularly useful for improving performance in cases with meshes having many splits.

[0161] When using this deduplication option, the positional topology of the input mesh is reproduced losslessly after encoding / decoding. In some embodiments, the same technique is used to achieve attribute deduplication.

[0162] On the decoder side, the decoder obtains data such as iDuplicatesOnStart, iDuplicateSymbolIdx, iDuplicateSplitVertexIdx, and cornerIndex (which can be alternatively referred to as currentDuplicateIndex or any other arbitrary name).

[0163] During decoding (see Figure 17), updates are performed inside the `deduplicateVertices` process (see Figure 34), and the index of the processed corner is updated (an offset is added for each CC as processedCorners are cleared after each CC). The decoder can then check whether the current corner is associated with a copied vertex (including additional checks for the first two vertices of each CC, or using a replacement technique). The decoder then assigns a single index to each of the copied vertices during the `processDuplicate` process. Figures 34A-34B The diagram illustrates examples of the processes `deduplicateVertices` and `processDuplicate`. When first called using a given split vertex index, the current vertex index is associated with the split vertex index. In subsequent calls using the given split vertex index, the registered index corresponding to the first occurrence of the copied vertex is used instead of the copied index. This data is used to regenerate the nonmanifold by deduplicating some vertices before converting the CT to an indexed face set. Figure 35 An example of this process is illustrated in the diagram.

[0164] Virtual points for a grid with boundaries Figure 36 The illustration shows the process in an example embodiment, where virtual vertices and virtual triangles are used to fill holes in the surface of a mesh. The virtual points are given indices from a vertex table. i n The mesh on the left includes a central hole. As shown on the right, this is achieved by adding vertices. i n And spread out in a fan shape to fill the hole.

[0165] One known method for handling bounded meshes (also known as meshes with holes) is to fill each hole with dummy points and connect the new vertex to the boundary of the hole using a sector of triangles. The mesh is then encoded / decoded as if the holes did not exist. Some data expressing which points are dummy is encoded in the bitstream, so the points and their associated dummy triangles (from the sectors) can be removed after decoding. In this technique, dummy points are typically encoded using pseudo-attribute values ​​(usually from interpolation).

[0166] In the exemplary embodiments of this disclosure, the process of filling holes with virtual points is performed after non-manifold filtering because non-manifold filtering itself may introduce holes in the surface. Furthermore, the exemplary embodiments track the index of the virtual points and do not encode the attributes of the virtual points (e.g., position, UV coordinates, color, etc.). Therefore, the exemplary embodiments do not use pseudo-attributes of virtual points when predicting the attributes of non-virtual points.

[0167] In the example implementation, the virtual triangle is encoded, but the attributes of the virtual points (position, UV coordinates, etc.) are not encoded. The interpolated attributes are not used to compute the prediction. Instead, some embodiments track the virtual point index and skip those during prediction.

[0168] Example encoding methods include: preprocessing a mesh with holes by creating virtual vertices connected to each vertex along the perimeter of the holes; encoding the preprocessed mesh in a bitstream using edge-breaking encoding; encoding information identifying the virtual vertices in the bitstream; and encoding at least one attribute for each of a plurality of vertices in the preprocessed mesh, wherein the attribute is not encoded for virtual vertices.

[0169] Example decoding methods include: obtaining information encoding the mesh from a bitstream; obtaining information identifying at least one virtual vertex in the mesh from the bitstream; and decoding attribute information for multiple vertices in the mesh from the bitstream, wherein the attribute information is not decoded for the at least one virtual vertex.

[0170] In some such embodiments, decoding attribute information for multiple vertices includes predicting attribute information for multiple vertices, wherein the attribute information is predicted without regard to virtual points. The decoder may remove virtual points.

[0171] The example embodiments are capable of handling meshes with and without a separate UV coordinate index table. Some encoders (such as the VDMC encoder) use a basic mesh with a separate index table, and the geometry consists of a small number of closed meshes (which eventually have holes, but are closed most of the time) rather than mesh patches. Therefore, in some embodiments, the economy of not encoding the first boundary is not significant.

[0172] Regarding the handling of "virtual" points, example procedures for handling virtual points according to some embodiments are provided below. Figure 35 and 36 To depict.

[0173] In embodiments where attributes use a primary index table, the preprocessing includes filling gaps by adding new corners and triangles to the corner table, and establishing connectivity. A table of indexes for virtual vertices, along with additional optional attributes in some additional position and attribute tables (this attribute data is only used to fill gaps; the example embodiment uses 0), is stored in memory. During connectivity encoding / decoding using broken edges, connectivity, including virtual triangles, is used as is. For better prediction of other vertices and for data economy in the bitstream, this table is used to skip virtual point attributes during attribute prediction during encoding and decoding.

[0174] In an embodiment where attributes use separate index tables, different processing is performed on the corner tables. This embodiment does not recreate connectivity; instead, it initializes new TC elements with -1 and new OTCs with -(boundary index + 4), so that each added corner has attribute tables TC and OTC marked as special elements, which can be treated like seams. (Figure 47 illustrates an example of a texture seam).

[0175] Figure 37 The illustration shows an example of a C++ procedure for filling all the holes in a grid described as a corner table (O, V, OT, OTC).

[0176] Figures 38A-38C The illustration shows an example of a C++ procedure for filling a single hole in a grid described as a corner table (O, V, OT, OTC).

[0177] In the example embodiment, the table of virtual point indices is encoded in the bitstream. See, for example, the syntax element DATA_DUMMY_POINT_COUNT in Table 4 below and the syntax element DATA_DUMMY_POINTS_TABLE in Table 5 below. However, the attributes associated with the virtual points are not encoded.

[0178] During post-processing, after the mesh decoding is complete, the example embodiment uses virtual point indexing to remove virtual points and attached virtual triangles. The output of the process thus matches the original mesh in terms of boundaries. This processing can be performed during the code conversion into the final indexed face set representation.

[0179] The vertex index is updated, thereby removing references to virtual vertices and shifting subsequent indices accordingly.

[0180] exist Figure 57 The diagram illustrates an example implementation of this technique. The complexity of this implementation is `dummy_count * numofTriangles`. This processing can be costly when the model has a large number of triangles and dummy vertices. In such cases, it might be preferable to first define the mapping function using a list of dummy position indices and then apply the remapping when it's recorded which triangles should not be included in the decoded mesh. (For example, a boolean false value could be assigned to a triangle that includes at least one dummy vertex, and the triangle would then be discarded).

[0181] Encoding and decoding of attributes for each vertex To compute predictions, example embodiments use multi-parallelogram prediction for geometry, as described in D. Cohen-Or, R. Cohen and R. Irony, “Multi-way geometry encoding,” The School of Computer Science, Tel-Aviv University, Tel-Aviv, 2002, and M. Isenburg and P. Alliez, “Compressing polygon mesh geometry with parallelogram prediction.” IEEE Visualization As described in [reference 1], no. doi: 10.1109 / VISUAL.2002.1183768, pp. 141-146, 2002. Example embodiments use minimum stretching prediction for UV coordinates, as in IM and SJ, "Compressing Texture Coordinates with Selective Linear Predictions," [reference 2]. Computer Graphics International As described in Tokyo, Japan, 2003.

[0182] The example embodiments further provide procedures for disposing of virtual points to fill holes and disposing of an optional separate index table for UV coordinates. The described techniques can be further used to support the prediction of other attributes, such as per-vertex normals, per-vertex color, or any other per-vertex attribute.

[0183] Some embodiments provide prediction methods for handling virtual points and separating index tables (and thus, UV seams).

[0184] In some embodiments, the prediction of attributes using a primary index table is determined by, for example, Figures 39A-39B The `encodeAttributes` process, as presented in the code, is implemented in this way. This process is called several times during edge-breaking encoding. Its corresponding decoding process, `decodeAttributes`, is... Figure 41 Depicting. Similarly, this process is called several times during edge-breaking decoding.

[0185] Figure 40 The illustration shows an example of the assertion isCornerVertexDummy. During encoding, all virtual points are at the end of the vertex table, which is not the case during decoding.

[0186] Location residual coding Figure 42 illustrates an example of the process posEncodeWithPrediction.

[0187] The example implementation stores the global coordinates of the starting point and the residuals of other points in a separate table to obtain better entropy coding.

[0188] Example mesh encoding methods include: encoding the connectivity of the mesh; entropy encoding a first table of the starting positions of vertices in the mesh; and entropy encoding a second table of the point residuals of vertices in the mesh separately.

[0189] The example mesh decoding method includes: decoding information indicating the connectivity of the mesh; performing entropy decoding on a first table of the starting positions of vertices in the mesh; and performing entropy decoding separately on a second table of the point residuals of vertices in the mesh.

[0190] Some example implementations extend the multi-parallelogram method to handle virtual point cases in order to prevent erroneous predictions for parallelograms involving virtual points.

[0191] Some example implementations extend predictive decoding to support multiple connected components by using table shifting.

[0192] Example mesh encoding methods include: obtaining information defining a mesh with multiple connected components (CCs), each vertex in a CC having a unique global range index; for each CC, shifting the index of the vertices in the CC from the global range index to the CC range index; and using the CC range index to encode each one in the CC.

[0193] The example mesh decoding method includes: obtaining information encoding multiple connected components (CCs), each vertex in a CC having a corresponding CC range index; decoding each of the CCs; and for each vertex, shifting the vertex's index from the CC range index to the global range index.

[0194] At the encoding stage, example methods include: calculating corners in the encoding chain. c and the vertex index to which it is attached v Location prediction, for example using... Figure 40 The method illustrated in the diagram. During the prediction of the corner, we are confident that its associated triangular sector is always complete and that each of its corners has a valid relative corner, because the example embodiment uses virtual points to fill the holes (even a single triangle will become a cone composed of 4 triangles in terms of connectivity).

[0195] Figure 43A The illustration shows a corner according to some embodiments. c A strategy for predicting multiple parallelograms of locations and filtering virtual points.

[0196] Figure 43B The illustration shows a corner according to some embodiments. c The strategy of minimum stretching prediction of UV coordinates and virtual point filtering.

[0197] In the first step, the process checks the corners to be encoded. c Is it attached to a virtual vertex (if so, then skip the corner encoding) or are we targeting the first vertex of the chain? v = 0 is used for prediction (then we use global coordinates and not use prediction to...) v (The position is encoded). In the latter case, the process stores the position in a specific table (table sVertices) dedicated to entropy encoding of the starting vertex. Storing those in a different specific table (table oVertices) than the prediction allows for better entropy encoding of those tables.

[0198] Otherwise, in the second step, we test whether the vertex is the second or third vertex. v = 1 or v = 2). In this case, instead of performing a prediction, we use incremental encoding of the vertices at the previous corner and append the results to the table of predicted vertices; oVertices.push_back(G[V[c]] - G[V[OV.p(c)]]).

[0199] Otherwise, for a given corner c The processing of multiple parallelograms involves performing a search around its vertices in the first loop to use relative corners (see...). Figure 41 This is used to calculate and sum the predictions for each parallelogram. It is used to calculate from the sibling corners. altC Predicting corners c Parallelograms only altC.o , altC.n and altC.p The prediction is only valid if the vertices have already been processed by connectivity recursion (which calls prediction). To test this, we use a vertex label table. M Its elements are set to true for vertices that have been visited cyclically by connectivity encoding. Then, the tests during prediction are ((M[V[O[altC]]]>0) and (M[V[OV.p(altC)]]>0) and (M[V[OV.n(altC)]]>0))).

[0200] We expand on this to test whether altC.o , altC.n and altC.pThe corner is not attached to the dummy point (using the isCornerVertexDummy assertion). In summary, we only use corners for parallelogram prediction if the data is available (the parallelogram vertices are not dummy vertices and have been visited, thus available during decoding). altC At the end of the loop, we predict and divide by the number of valid parallelograms found, round the result, and finally use the result to calculate the residual (by position prediction) appended at the end of the output vertex table; oVertices.push_back(G[V[c]] - predPos).

[0201] If no valid parallelogram is found, then we go to the previous corner. c If it is a virtual point, it falls back to using G[V[OV.n(c)]] as the incremental encoding for prediction; otherwise, it falls back to using G[V[OV.p(c)]] as the incremental encoding for prediction.

[0202] At the end of the edge-breaking encoding process, the two tables sVertices and oVertices are then entropy-encoded and stored in the bitstream.

[0203] During decoding, Figures 42A-42B The example depicts the reconstruction of the vertex positions at corners. The process is the same as that used for encoding, and follows the same order for vertex and fan extrapolation. The resulting prediction is therefore equivalent to the encoded prediction. Note that for decoding, we use tables. D To quickly determine if a vertex is a virtual vertex. (Table) D It is initialized by the process initDecompression (see Figure 16). Also note that during predictive decoding, we use table shifting to handle CC (this is not the case during predictive encoding).

[0204] Figures 44A-44B The diagram illustrates an example of the process posDecodeWithPrediction. Table D indicates whether each vertex is a virtual vertex.

[0205] Residual encoding of UV coordinates using the primary index table. The predictive encoding of UV coordinates using the primary index table is extended in the same manner as for location. The difference for some embodiments is that minimum stretching is used for prediction instead of multiple parallelograms, and instead of summing the predictions (which are not multiple), we stop and compute minimum stretching on the first valid (in the sense of prediction) neighbor in the triangular sector, as shown in example... Figure 41 As shown in Figure 43, an example uvEncodeWithPrediction process is illustrated. Figures 44A-44BExample prediction statements are depicted in the text.

[0206] Figures 45A-45B The diagram illustrates an example of the uvEncodeWithPrediction process.

[0207] Figures 46A-46B The illustration shows an example of declaring predictUV. dvec2 and dvec3 are double-precision vectors.

[0208] exist Figures 44A-44B As can be seen in the predictUV process, we have one branch using prediction and two other paths using backoff. The scheme is based on using geometry to make a first choice, and then performing minimum stretch UV prediction or backoff to the increment in the case of dummy vertices on the vertex chain, or otherwise performing an averaging of the previous and next corner UVs. Note that in the case of the minimum stretch choice, the example embodiment stores the prediction residuals (in the table oUVCoords) and the orientation bits used during decoding (in the table orientations). Correspondingly, the two other paths do not store orientation information.

[0209] Regarding position, decoding is symmetrical. The example embodiment uses table shifting for the handling of CC, and we use the same logic as for position. Input iUV The extracted value is iUV = iUVCoords[startVertex + V[c] -uvSvalueIdx - uvSkipNum]; which includes the CC offset startVertex, the initial value uvSvalueIdx in the separation table, and uvSkips in the case of virtual points. This extracted value... iUV It can be an increment (in the case of v=1 or v=2) or otherwise a residual. The example embodiment then performs the same prediction or backoff as in UV encoding and computes back to the final UV with respect to the following position: UV[v] = predUV + iUV, where predUV is the predicted UV or backoff.

[0210] Residual encoding of UV coordinates using different index tables When the model utilizes a separate index table for UV coordinates, the example implementation (which, in addition to the separate table for the initial UV, multiple CCs, and virtual points) handles potential UV seams during prediction. Without using a separate index table, the positions of vertices located on the boundaries of the UV patch are copied, and the mesh contains at least as many CCs as the UV patch. This is why we treated UVs as locations in previous chapters; they have the same structure. Correspondingly, in the example implementation using a separate index table for UV coordinates, it is possible to have a more "compact" geometry without CCs specific to the UV and to handle the UV patch boundaries using a separate UV index table. The edge chains on the mesh where the UV coordinates differ on each side can be referred to as UV seams.

[0211] Figure 47A The illustration shows how to handle UV seams using only the primary index table. The copied locations (illustrated using dashed ellipses) have different UV coordinates. Figure 47B The diagram illustrates the processing of UVs using a separate index table and its application to corners. c The separate index for predicting UV coordinates for corners c p The selection strategy. Dashed lines represent UV seams, and the vertices of the seams can have the same position and different UV coordinates for different sides of the seam.

[0212] Some example implementations extend the UV predictor search strategy to support UV seams. In some such implementations, this is done by storing specific code in TC and OTC tables to guide the algorithm.

[0213] The example implementation performs a search strategy for effectively predicted corners, such as... Figures 45A-45B As described in the text. In this scheme, virtual points are implicitly handled, thus only checking whether sibling corners already have reconstructed UV coordinates. This is used to find the UV coordinates for corners. c Effective UV predictor c p The strategy is: at the seams and corners c The search is performed within the sector on the same side of the triangle, for which the maximum value of the UV coordinates has already been predicted. An example implementation selects the first corner with two predicted UVs, or the first corner with one predicted UV if none are found, and otherwise none are predicted. For the search, we can first turn left and then right, or vice versa; it doesn't matter, but we need to use the same order during decoding. Figure 46 illustrates an example of the detailed process used to perform this work using `encodeSeparateIndexAttributes`.

[0214] In some embodiments, such as Figures 47A-47B As illustrated, decoding performs the same processing (using a shifted table) to recover the predicted values ​​and then the final UV coordinates. Note that if it's an isSeam table, this stage is not specifically used because it's one of the few valid TC and OTC tables used during edge-breaking decoding to create disposal separation indexes. At this stage, the TC table is used to find the UV index for each corner, and the OTC table is used to detect UV seams. The example embodiment uses -4 in the OTC during encoding and -1 in the OTC during decoding. This is because values ​​between 0 and -4 are used for other purposes.

[0215] Figures 48A-48B The diagram illustrates an example of the process encodeSeparateIndexAttributes.

[0216] Figures 48A-49B The diagram illustrates an example of the process decodeSeparateIndexAttributes.

[0217] Prediction of attributes for each face Some example embodiments encode and decode the color or ID of each face. In some such embodiments, the attributes of each face are encoded according to the order of the faces in the CLERS table. Each symbol in the table corresponds to a triangle. Whenever we encode / decode a new triangle (performing T=0 or T++), the example embodiments operate to perform connectivity encoding (see...). Figure 12 and 13) and connectivity decoding (see Figure 18 During steps 1 and 19), the attributes of each face are directly encoded. Then, example embodiments include adding the encoded triangle attributes to a table at these steps. Some embodiments directly add values ​​(color, ID, ...) to a dedicated table, for example, by performing incremental encoding using the previous triangle in the table. Some embodiments use a separate table to handle the starting triangle, similar to the technique described herein for encoding the attributes of each vertex at the starting vertex. This embodiment can have more efficient entropy encoding.

[0218] The example implementation uses a sequence of triangles in the order of the CLERS table to encode incremental values ​​for each triangle's color (e.g., 8-bit RGB) or integer (e.g., group identifier, subdivision depth). Depending on the type of attribute, the same strategy can be used to devise some more complex predictions.

[0219] Examples of mesh encoding methods include: obtaining information describing a mesh with multiple triangles, each triangle having attributes; encoding the mesh as an ordered sequence of symbols in edge-breaking encoding, where each triangle corresponds to one associated with a symbol; and encoding the attributes of the triangles, where the attribute of the current triangle is encoded using predictions based solely on the attributes of at least one triangle preceding the current triangle in the ordered sequence of symbols. For example, the attribute of each triangle could be encoded as an increment value relative to the previous triangle in the sequence (serving as the value of the predicted attribute of the previous triangle).

[0220] A grid decoding method according to some embodiments includes: obtaining an ordered sequence of symbols representing a grid with broken edges encoded of multiple triangles, each triangle having an attribute; decoding the grid; and decoding the attribute of the triangle, wherein the attribute of the current triangle is decoded using predictions based solely on the attributes of at least one triangle preceding the current triangle in the ordered sequence of symbols.

[0221] Predicting the attributes of each vertex can be particularly useful for mesh coding systems that handle group-specific adaptive subdivisions of each triangle. For example, each triangle of a basic mesh might receive an integer specifying the number of subdivisions it should receive to reconstruct the complete mesh.

[0222] Some embodiments implement a technique for encoding the ID (e.g., material ID) for each facet (here referred to as variant A). Figures 59A-59B An example of code for implementing variant A is provided. In this embodiment, for each corner processed during the traversal of defining the new triangle, the following action can be performed: • Determine whether the current corner is a defined real face or a virtual face (if one of its corners is associated with a virtual vertex, then the face is virtual). • Determine if the current Id is equal to the previously encoded Id, and the result of the comparison is stored in a Boolean vector `faceIdEqualToPrevious`, the final size of which is the number of triangles in the input mesh (before adding dummy vertices). If the current Id is equal to the previously encoded Id, then no further encoding of the current Id is required. However, if the current Id is not equal to the previous Id, the following steps are performed for the encoding of the current Id: • Determine whether any of the faces opposite each corner of the current face has been encoded. The current triangle is defined by the following three corners: currentCorner, ov.n(currentCorner), and ov.p(currentCorner). The "opposite triangle" is defined as the triangle containing ov.O(currentCorner), the "right triangle" is the triangle containing ov.O[ov.n(currentCorner)], and the "left triangle" is the triangle containing ov.O[ov.p(currentCorner)]. • For each of those triangles (opposite to each of the corners of the current triangle defined by the corner index, such as...) Figures 61A-61C As shown in the diagram, if it has not yet been encoded, the loop is first executed through the face containing currentCorner=ov.O[ov.n(currentCorner)], stopping when a face that has already been encoded is found, until the face under consideration is not the current face for which we have encoded the Id value. If no previously encoded face is found, we restart and loop in the other direction, i.e., through the face containing currentCorner=ov.O[ov.p(currentCorner)]. For each corner corresponding to the actual face, this yields three boolean values ​​(decodedRight, decodedLeft, decodedFacing), and for those values ​​that are true, we know the corresponding face ID value (faceIdRight, faceIdLeft, faceIdFacing) that has been encoded. When the boolean value is false, the corresponding faceIdRight / Left / Facing value can be set to an invalid value (e.g., -1 if we only consider id values ​​>= 0). Then, perform the following procedure: if (decodedRight) faceIdIsRight.push_back(faceIdRight == currentFaceId); if (!decodedRight || (faceIdRight!= currentFaceId)) { if ((decodedLeft)&&(faceIdLeft != faceIdRight)) faceIdIsLeft.push_back(faceIdLeft == currentFaceId); if (!decodedLeft || (faceIdLeft!= currentFaceId)) { if ( (decodedForward) &&(faceIdForward!= faceIdRight)&&(faceIdForward!= faceIdLeft)) faceIdIsForward.push_back(faceIdForward == faceIdForward); if (!decodedForward || (faceIdForward!= currentFaceId)) notPredictedFaceId.push_back(currentFaceId); } } • This face can then be marked as coded. The process yields four Boolean vectors (faceIdEqualToPrevious, faceIdIsRight, faceIdIsLeft, faceIdIsFacing) and a vector containing unpredicted values ​​(notPredictedFaceId).

[0223] Figures 61A-61C The illustration shows an example of the search order for corner [0] = c (the operation is repeated for corner [1] = cn and then for corner [2] = cp). Figure 61A The diagram illustrates the face for which the ID will be encoded, along with the L, R, and F neighboring triangles. (The three neighboring triangles are always present because dummy points are used to fill the holes.) Figure 61B The diagram illustrates the search in the neighborhood loop along the first direction on R, R1, R2, etc. Figure 61C The diagram illustrates the subsequent search in another direction.

[0224] Some embodiments implement a replaceable technique (here referred to as variant B) for encoding the ID of each face. This technique can be implemented as follows: • Store information indicating whether the current id is equal to the previous id in the first vector of boolean values. If they are not equal, the absolute value of the current Id or the difference compared to the previous Id is stored in a second vector of integer values.

[0225] Some embodiments implement a replaceable technique (here referred to as variant C) for encoding the ID of each face. This technique can be implemented as follows: • Store information indicating whether the current id is equal to the previous id in the first vector of boolean values. If they are not equal, information indicating whether the current id is equal to the most recently encoded id that is different from the previous id will be stored in a second vector of boolean values. If they are not equal, the absolute value of the current Id or the difference compared to the previous Id is stored in a third vector of integer values.

[0226] Using a larger number of recently used values ​​and encoded indices pointing to those values ​​instead of absolute values ​​can be implemented in some embodiments, but it is unlikely to result in improved efficiency.

[0227] For at least some sample sets of meshes processed in the VDMC context, the alternatives (B and C) are less efficient than A, but are still simpler to implement and faster to execute.

[0228] exist Figures 59A-59B The diagram illustrates an example of code used to perform encoding using alternative scheme A. (This is similar to...) Figures 59A-59B The encoding shown in the diagram is performed in a similar manner to the decoding using an alternative scheme A (e.g., utilizing the process decodePerFaceAttributes).

[0229] In some embodiments, the mesh encoding method includes: obtaining information describing a mesh having a plurality of triangles, each triangle having an attribute (such as an ID); encoding the mesh as an ordered sequence of symbols in edge-breaking encoding, each triangle corresponding to one of the associated symbols; and encoding the attributes of the triangles, the attributes of the current triangle being encoded using predictions based on the attributes of at least one triangle adjacent to the current triangle in the mesh (such as the left, right, opposite, and / or the previous triangle).

[0230] In some such embodiments, encoding the properties of a triangle includes encoding multiple Boolean vectors (such as faceIdEqualToPrevious, faceIdIsRight, faceIdIsLeft, and / or faceIdIsFacing vectors) that, for at least multiple triangles, collectively indicate the corresponding triangle from which the respective properties are predicted.

[0231] As described in more detail below, arithmetic encoding of these multiple Boolean vectors can also be performed.

[0232] In some embodiments, the grid decoding method includes: obtaining an ordered sequence of symbols representing a grid with multiple triangles, each triangle having an attribute; decoding the grid; and decoding the attribute of a triangle, wherein the attribute of the current triangle is decoded using a prediction based on the attribute of at least one triangle adjacent to the current triangle in the grid.

[0233] In some such embodiments, decoding the properties of a triangle involves encoding multiple Boolean vectors (such as faceIdEqualToPrevious, faceIdIsRight, faceIdIsLeft, and / or faceIdIsFacing vectors) that, for at least a plurality of triangles, collectively indicate the corresponding triangle from which the respective properties are predicted.

[0234] As described in more detail below, arithmetic decoding of these multiple Boolean vectors can also be performed.

[0235] Entropy coding Figure 50 This diagram illustrates an example of a process save, which relates to entropy encoding and syntax writing. In the bitstream (see...) Figures 48A-48B During the creation of the payload, the example implementation first writes some metadata in the header, then saves the topology payload, and finally saves the attribute (location, UV coordinates) payload. For both the topology and attributes, some tables are entropy encoded before saving. Example entropy encoding is described in this section.

[0236] The example implementation supports two or more different arithmetic encoders, such as those described in J. Duda, "Asymmetric numeral systems: entropy coding combining speed of Huffman coding with compression rate of arithmetic coding," Arxiv. 1311.2540 The Dirac or RANS codes described in 2014. For some data, one or the other of these codecs can provide better compression. We also found that for some other tables, depending on the model being compressed, one or the other is better at compression. The example implementations provide more than one arithmetic codec implementation guided by a number of options. Table 6 below summarizes which arithmetic encoders are available for some implementations for each type of data. The following sections further detail the configuration / binarization for some data tables, depending on the type of arithmetic encoding used.

[0237] Arithmetic coding of CLERS table When encoding a non-binary sequence of CLERS symbols representing a topology code used to reconstruct the topology of a grid traversed using an edge-breaking algorithm, one or more of the following schemes may be used.

[0238] The choice of the preferred binarization process and the choice of the probabilistic model for the relevant bin can depend on the specific properties of the sequence of symbols to be encoded, conditioned on the number of symbols (related to the number of faces in the grid) and the topology of the grid (e.g., the regularity of the structure of the grid under consideration, which may affect global symbol statistics and the interrelationships between successive symbols).

[0239] Depending on the expected statistical distribution of the symbols, some implementations assign variable-length codes to a set of symbols (e.g., for a basic broken edge, 5 symbols 'C', 'L', 'E', 'R', 'S'). A known choice is to assign {'C', 0, 1 bit}, {'S', 1, 3 bits}, {'L', 3, 3 bits}, {'R', 5, 3 bits}, and {'E', 7, 3 bits}.

[0240] C = 000 S = 001 L = 011 R = 101 E = 111.

[0241] In some embodiments, when encoding using RANS, the CLERS table, which consists of these codes, is provided to the encoder as is.

[0242] In some embodiments, when using Dirac encoding, it is possible to use several contexts (ctx) for encoding. Some such embodiments use ctx0 to encode b0, ctx1 to encode b1 and ctx2 to encode b2, and when b0=0, then the two subsequent bits do not need to be encoded.

[0243] In some embodiments, the context is selected for each bin based on the value of the previous bin for the current symbol, and also based on the value of the preceding symbol. This is useful for CLERS sequences because of the strong correlation between successive symbols.

[0244] The example embodiment uses a global 5-bit (32 possible values) state defined using two previously defined symbol values. Alternative embodiments use simplified or extended state definitions.

[0245] In some embodiments, one of the 32 bit_0 contexts is selected for encoding the first bit that defines whether the symbol is 'C'. If the symbol is not 'C', the second bit is encoded using one of the 32 contexts modeled for the value of bit_1. Then, depending on the value of bit_1, two sets of the 32 contexts are used to encode bit_2. Finally, the global state is updated, taking into account the most recently encoded symbol. In our current implementation, the state has 3 bits for the most recent value plus bits 0 and 3 from the previous value, that is, 5 bits for 32 states. Not all of those states are necessarily used in practice: using a simple mapping, we would instantiate only 20 contexts as 5 values ​​for the current symbol × 4 possible states retained from the previous symbol, which is 20 possible states. Then, in this example, the total number of contexts used would be 20 × 4 = 80 (4 represents bit_0, bit_1, bit_2IFbit_1is0, bit_2IFbit_1is1).

[0246] When the number of symbols is small, using many contexts can prove inefficient. Therefore, based on the number of symbols to be encoded, the example embodiment operates to adjust the number of global states to be used. For example, instead of using 32 bits of global state (where 5 × 4 = 20 are useful states), the example embodiment can limit it to 3 bits or 5 global states when capturing only the value of the most recent symbol.

[0247] In a variant, the example embodiment operates to test multiple combinations, encodes the selected combination, and encodes information indicating the selected combination in the bitstream.

[0248] Some implementations operate to define a scheme in which more and more states are gradually used (bootstrapping) so that when the model is transformed based on, for example, the number of encoded symbols or other factors, the appropriate state values ​​are copied to the uninitialized state, such as the specific triggers based on the state values, statistics on the input values ​​(e.g., the variance of the probabilistic encoded bits), etc.

[0249] exist Figure 51 The document provides an example of pseudocode for controlling the Dirac encoder targeting the CLERS table.

[0250] In a grid decoding method according to an example embodiment, a bit stream comprising an entropy-encoded CLERS table representing the connectivity of connected components of a grid is obtained. Entropy decoding is performed on bit sequences from the CLERS table, wherein the bit sequences represent symbol sequences including at least one recently decoded symbol. Entropy decoding is performed on the current bit from the CLERS table, wherein the current bit is decoded using a context determined at least partially based on the at least one recently decoded symbol (e.g., based on two recently decoded symbols). A grid decoding apparatus according to some embodiments includes one or more processors configured to perform this method.

[0251] In some embodiments, the context is determined not only by the most recently decoded symbol, but also by the most recently decoded bit in the bit sequence. In some embodiments, the context is further based on the two most recently decoded bits in the bit sequence.

[0252] In a lattice coding method according to some embodiments, a CLERS table is obtained, wherein the CLERS table represents the connectivity of at least one connected component of a lattice. A bit sequence representing at least a portion of the CLERS table is encoded, wherein the bit sequence representing a sequence of symbols from the CLERS table includes at least one recently encoded symbol. Entropy coding includes entropy coding of the current bit in the CLERS table, wherein the current bit is encoded using a context determined at least partially based on the at least one recently encoded symbol (e.g., based on two recently encoded symbols).

[0253] In some embodiments, the context is further based at least in part on the most recently encoded bit in the bit sequence. In some embodiments, the context is further based on the two most recently encoded bits in the bit sequence.

[0254] In some embodiments, the number of contexts used to decode bits of the CLERS table is determined based on the number of symbols in the CLERS table. In some such embodiments, the number of contexts is determined based on whether the number of symbols in the CLERS table is greater than a threshold (e.g., a threshold of 3000 symbols, among other possibilities as an option). When the number of symbols is less than the threshold, a first number of contexts is used, and when the number of symbols is greater than the threshold, a second number of contexts, greater than the first number, is used. As an example, among other possibilities, the first number could be 5 and the second number could be 20.

[0255] AC encoding of attribute residuals When encoding vertex attributes such as position or texture coordinates, the example implementation operates to predict those values ​​and then encodes only the residuals. Absolute reference values ​​can be encoded separately to avoid degrading the performance of the arithmetic encoder by disrupting statistics.

[0256] When using RANS for encoding, the example implementation provides the encoder with a table consisting of these residuals as is.

[0257] In some embodiments, when using Dirac for encoding, some control over the context can be performed. An example embodiment uses an encoding scheme based on a Dirac arithmetic encoder for arithmetic encoding of motion vectors. Figure 52 The code shown in the figure provides an illustration of a portion of the encoding principles used for motion vectors in some embodiments.

[0258] Using this scheme, to encode triples of signed integer values ​​(one per coordinate in a 3D location), the example embodiment uses 51 contexts. For each value, we first use a first context to encode whether the value is 0 as a bit. If the value is not null, we use a second context to encode the sign as a bit. Then, we use a third context to encode whether the absolute value of the value to be encoded is 1 as a bit. If the absolute value of the value to be encoded is greater than 1, then 2 × 7 contexts are used to perform expGolomb encoding on the absolute value of the value to be encoded minus 1, where 7 represents the exponent (prefix) part and 7 represents the suffix part. This is just an example, and different configurations can be used in other embodiments. In some embodiments, offset or shifted values ​​are used in conjunction with expGolomb encoding. This encoding scheme can allow for better compression with a high probability distribution of values ​​-1 to +1, and adjust to distributions that do not conform to the ideal distribution ideally handled by expGolomb encoding. Figure 53 The example code shown for ExpGolomb encoding provides more details about the example offsets / shifts.

[0259] This modeling may not be optimal for the distribution of location or other attribute residuals. Therefore, some embodiments use more sophisticated modeling to achieve better results.

[0260] Some example embodiments continue as follows (the given dimension values ​​are merely examples). In some embodiments, the threshold before falling back to expGolomb encoding has been expanded (this is set via a bias parameter). In example embodiments: 1. Encode a bit to signal whether the value is 0. 2. Then, if it's not 0, the symbol is encoded as a single bit. We leave that for later. newvalue = abs ( initial value ) – 1. Encode. 3. Then, use a code with a maximum length bias (e.g., a simple code) to encode newvalue < bias, repeating 0 and 1 repeatedly when the bit count equals the value to be encoded, and stopping after the bias value. 4. Then, if the last bit transmitted is 0, and the value >= bias, we use biased exp - golomb coding to encode ( newvalue - bias ).

[0261] The context in step 3 can be conditioned on the fact that the previously encoded values have an absolute value smaller than the bias. Their number may be limited such that it can be any value from 1 to the bias. In Figure 54 a schematic example of the code for some embodiments is depicted. In this embodiment, the performance is affected by the loop order per component / per residual. Depending on the predictor used and the kind of data, an optimal order can be chosen (preferably using our parallelogram predictor to loop through the values assigned to one component before going to another component for a location), preferably going through the components for texture coordinates and stretch minimization prediction first. If the state is replicated per component, there is no such ambiguity, but the performance / complexity may be affected.

[0262] In some embodiments, a mesh coding method includes: obtaining attribute information representing prediction residuals of attributes of vertices of a triangular mesh. Entropy encoding the attribute residuals in a bitstream, wherein for at least one attribute of at least one vertex, the entropy encoding includes: encoding a first bit indicating whether the residual is 0; encoding a second bit indicating the sign of the residual; and encoding a bit sequence, wherein the absolute value of the residual is determined at least in part based on the length of the sequence.

[0263] In some embodiments of a mesh decoding method, obtaining attribute information from a bitstream, wherein the attribute information represents prediction residuals of attributes of vertices of a triangular mesh. Performing entropy decoding of the attribute residuals. For at least one attribute of at least one vertex, the entropy decoding includes: decoding a first bit indicating whether the residual is 0; decoding a second bit indicating the sign of the residual; decoding a bit sequence, wherein the absolute value of the residual is determined at least in part based on the length of the sequence; and reconstructing the attribute of the vertex at least in part based on the determined residual.

[0264] In some embodiments, the bit sequence ends in a predetermined stop bit. For example, the bit sequence can be zero or more "0" bits, terminated by a "1" bit serving as a stop bit. Or, the bit sequence can be zero or more "1" bits, terminated by a "C" bit serving as a stop bit. In some cases, the absolute value of the residual is determined as the length of the sequence.

[0265] In some embodiments, entropy decoding further includes decoding the codeword using exponential Golomb coding, wherein the absolute value of the residual is determined at least in part based on the codeword. In some such embodiments, the codeword is decoded in response to determining that the bit sequence has a predetermined maximum length and does not end in a predetermined stop bit. In some such embodiments, the absolute value of the residual is determined as the sum of the value represented by the codeword and the bias value.

[0266] The values ​​of a vertex's attributes can be reconstructed by obtaining predictions of the vertex's attributes and adding the determined residual values ​​to the attribute predictions. Attributes can be, for example, UV coordinates, position coordinates, or another attribute type.

[0267] Entropy encoding of material properties or other properties on each face In some embodiments, when encoding faceID or materialID attributes that are assigned to share common values ​​among adjacent triangles with large spans using encoding schemes such as those detailed above, the following scheme can be used to arithmetically encode the array of values ​​defined by the encoding process. The encoding / prediction process yields: • Four Boolean vectors: faceIdEqualToPrevious, faceIdIsRight, faceIdIsLeft, and faceIdIsFacing. • A vector notPredictedFaceId containing unpredicted values.

[0268] The four Boolean vectors are arithmetically encoded using four separate contexts.

[0269] The vector containing the unsigned faceId values ​​is encoded using exponential Golomb coding, along with the number of contexts used to encode the suffix and prefix parts. These numbers can be adjusted to balance the complexity / performance tradeoffs, taking into account the range of faceId values. As an example, both prefix and suffix coding can use as many contexts as the number of bits used to represent the entire set of Id values. For values ​​varying from 0 to 255, we could decide to use 8 contexts for both.

[0270] In some embodiments, exponential Golomb encoding may use optimized “shift” parameters as in the previous examples.

[0271] In some embodiments where the input surface ID or material ID value is not unsigned, additional parameters can be added to shift the range of values ​​so that the shifted values ​​are all positive. Alternatively, some embodiments use the following formula or any similar bijective transformation that converts the ID range to positive values ​​to shift the values ​​to a positive range: y = 2x, if x >= 0, y = -2*x – 1, if x < 0.

[0272] In some embodiments, the five vectors can be encoded separately to obtain five encoded byte arrays.

[0273] In some embodiments, the number of elements encoded into each of those vectors (original vector size) can be signaled. The size of the encoded byte array allows for decoding of each of them in parallel.

[0274] In some alternative embodiments, multiple contexts are used to encode all information into a single byte array and the decoding is performed progressively, thereby appropriately selecting the context by performing context selection during the decoding process, which mirrors the selection at the encoding stage.

[0275] exist Figure 60 The diagram illustrates an example of Dirac AC entropy encoding used to encode the material ID for each face.

[0276] In a mesh decoding method according to some embodiments, a CLERS table representing the topology of a triangular mesh is obtained from a bitstream. The topology of the triangular mesh is reconstructed from the CLERS table. Ordered attribute information representing the attributes of corresponding faces in the triangular mesh is obtained from the bitstream. The ordered attribute information is decoded to determine the attribute value of the corresponding face for each face.

[0277] In some embodiments of the mesh encoding method, information describing the topology of the triangular mesh is obtained, and information indicating the attribute values ​​of the corresponding face for each face in the triangular mesh is obtained. The CLERS table representing the edge encoding of the topology is encoded in the bitstream. Attribute information indicating the attribute values ​​of the corresponding face for each face is encoded in the bitstream.

[0278] In some embodiments, the ordered attribute information includes at least a first vector, which includes entries for each of a plurality of faces, each entry in the first vector being a Boolean value indicating whether the attribute value corresponding to that face is the same as the attribute value of the most recently decoded face.

[0279] In some embodiments, the ordered attribute information further includes at least a second vector comprising entries for each of a plurality of faces, each entry in the second vector being a Boolean value indicating whether the attribute corresponding to that face is the same as the attribute value of an adjacent face in a first direction from the current face. In some such embodiments, the second vector includes entries only for faces that do not have the attribute value determined by the first vector.

[0280] In some embodiments, the ordered attribute information further includes at least a third vector, which includes entries for each of a plurality of faces, each entry in the third vector being a Boolean value indicating whether the attribute corresponding to that face is the same as the attribute value of an adjacent face in a second direction from the current face. In some such embodiments, the third vector includes entries only for faces that do not have attribute values ​​determined by the first or second vector.

[0281] In some embodiments, the ordered attribute information further includes at least a fourth vector comprising entries for each of a plurality of faces, each entry in the fourth vector being a Boolean value indicating whether the attribute corresponding to that face is the same as the attribute value of the adjacent face in the third direction from the face above. In some such embodiments, the fourth vector includes entries only for faces that do not have attribute values ​​determined by the first, second, or third vectors.

[0282] In some embodiments, the ordered attribute information further includes at least a fifth vector, which includes entries for each of the plurality of faces, each entry in the fourth vector including a corresponding attribute value. In some such embodiments, the fifth vector includes entries only for faces that do not have attribute values ​​determined by the first, second, third, or fourth vectors.

[0283] In some embodiments, the first direction is to the right, the second direction is to the left, and the third direction is forward, for example, relative to an orientation scheme known to both the encoder and the decoder. However, different embodiments may arrange these directions in different ways.

[0284] In some embodiments, different vectors may be entropy-encoded using different contexts. In one example, a first context is used to entropy-encode a first vector, and a second context, different from the first context, is used to entropy-encode a second vector. In another example, a first context is used to entropy-encode a first vector, a second context, different from the first context, is used to entropy-encode a second vector, and a fifth context, different from both the first and second contexts, is used to entropy-encode a fifth vector.

[0285] In some embodiments, the attribute value for each face is an integer value. In some embodiments, the attribute value for each face is a face ID value. In some embodiments, the attribute value for each face identifies the color. In some embodiments, the attribute value for each face identifies the material.

[0286] Example low-level syntax This section describes the syntax used in some example implementations.

[0287] The syntax of example bitstream structures is shown in Table 1. CFG_INFO DATA_HEADER DATA _TOPOLOGY DATA_ATTRIBUTES Table 1.

[0288] Table 2 shows example attribute bitstreams (DATA_ATTRIBUTES) according to some embodiments. Location UV coordinates [optional] Normal vector [optional] Color [optional] Table 2.

[0289] Table 3 shows example configuration information bitstreams (CFG_INFO) according to some embodiments. name value size CFG_CODEC_TYPE In [Forward] 2b CFG_ENCODING_TYPE In [Ascii, binary] 1b CFG_POS_PRED Location prediction modes in [none, para, mpara] 2b CFG_UV_PRED UV coordinate prediction mode in [none, para, stretch] 2b CFG_PRED_CODER The arithmetic encoder in [dirac, dirac_alt, rans] is used to encode the prediction. 2b CFG_TOPO_CODER The arithmetic encoder in [dirac, rans] used to encode the CLERS table. 2b CFG_INT_ATTR Use internal quantification (false) or not (true). 1b CFG_QP The position quantization range in [7,16] 8b CFG_QT UV coordinate quantization range in [7,16] 8b CFG_QN The normal vector quantization range in [7,16] 8b CFG_QC Color quantization range in [7,8] 1b CFG_SEPARATE_UV_INDEX This is true if a separate index table is used for YV coordinates. 1b Wait, for NORMALS, then COLORS per vertex… CFG_DEDUPLICATE_POS The value is true if information is added to achieve vertex position deduplication. 1b Table 3.

[0290] Table 4 shows example data header information bitstreams (DATA_HEADER) according to some embodiments. Table 4.

[0291] Table 5 presents example data topology bitstreams (DATA_TOPOLOGY) according to some embodiments. Table 5.

[0292] Table 6 illustrates examples of data location attribute bitstreams according to some embodiments. Table 6.

[0293] Table 7 illustrates example UV coordinate attribute bitstreams according to some embodiments. Table 7.

[0294] Example extended syntax Appendix A provides example extended syntax that may be used in some embodiments. The syntax elements and their associated semantics described in Appendix A are provided by way of example only. Variations and extensions of the syntax elements described in Appendix A are contemplated in this disclosure.

[0295] performance The performance of an example embodiment of overall compression as described herein in the context of V-DMC is compared with comparable compression using GoogleDraco. See the results, which show a graph illustrating the compression gain for basic trellis coding. Figure 55 The compression performance of the coding method described herein, compared to Google Draco, for encoding the basic grid in V-DMC is illustrated. Results for each CTC test sequence are averaged over 300 frames. PSNR is not presented because it is unaffected. The results show an overall average gain of 5.4% compared to the Draco rate.

[0296] Example system hardware Can use such as Figure 56 The system is an example embodiment of an encoder and / or decoder (collectively referred to as an encoder) configured to implement the embodiments described herein. Figure 56 This is a block diagram illustrating examples of systems implementing various aspects and embodiments. System 1000 may be embodied as a device including the various components described below and configured to perform one or more of the aspects described in this document. Examples of such devices include, but are not limited to, various electronic devices such as personal computers, laptop computers, smartphones, tablet computers, digital multimedia set-top boxes, digital television receivers, personal video recording systems, networked home appliances, and servers. Elements of system 1000 may be embodied individually or in combination in a single integrated circuit (IC), multiple ICs, and / or discrete components. For example, in at least one embodiment, the processing and encoder / decoder elements of system 1000 are distributed across multiple ICs and / or discrete components. In various embodiments, system 1000 is communicatively coupled to one or more other systems or other electronic devices via, for example, a communication bus or through dedicated input and / or output ports. In various embodiments, system 1000 is configured to implement one or more of the aspects described in this document.

[0297] System 1000 includes: at least one processor 1010 configured to execute instructions loaded therein for implementing various aspects, such as those described in this document. Processor 1010 may include embedded memory, input / output interfaces, and various other circuitry as known in the art. System 1000 includes at least one memory 1020 (e.g., a volatile memory device and / or a non-volatile memory device), and system 1000 includes: a storage device 1040 that may include non-volatile memory and / or volatile memory, including but not limited to electrically erasable programmable read-only memory (EEPROM), read-only memory (ROM), programmable read-only memory (PROM), random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, disk drives, and / or optical disk drives. Storage device 1040 may include internal storage devices, attached storage devices (including removable and non-removable storage devices), and / or network-accessible storage devices, as non-limiting examples.

[0298] System 1000 includes an encoder / decoder module 1030 configured to, for example, process data to provide encoded or decoded video, and the encoder / decoder module 1030 may include its own processor and memory. The encoder / decoder module 1030 represents one or more modules that may be included in a device to perform encoding and / or decoding functions. It is well known that a device may include one or both encoding and decoding modules. Alternatively, the encoder / decoder module 1030 may be implemented as a separate element of system 1000, or may be incorporated into processor 1010 as a combination of hardware and software, as is known to those skilled in the art.

[0299] Program code to be loaded onto processor 1010 or encoder / decoder 1030 to execute the various aspects described herein may be stored in storage device 1040 and subsequently loaded onto memory 1020 for execution by processor 1010. According to various embodiments, one or more of processor 1010, memory 1020, storage device 1040, and encoder / decoder module 1030 may store one or more items of various kinds during execution of the processes described herein. Such stored items may include, but are not limited to, input video, decoded video or portions of decoded video, bitstreams, matrices, variables, and intermediate or final results from processing equations, formulas, operations, and operational logic.

[0300] In some embodiments, the memory within processor 1010 and / or encoder / decoder module 1030 is used to store instructions and provide working memory for processing required during encoding or decoding. However, in other embodiments, external memory (e.g., processor 1010 or encoder / decoder module 1030) is used for one or more of these functions. External memory may be memory 1020 and / or storage device 1040, such as volatile memory and / or non-volatile flash memory. In several embodiments, external non-volatile flash memory is used to store, for example, the operating system of a television. In at least one embodiment, a fast external dynamic volatile memory, such as RAM, is used as working memory for video encoding and decoding operations such as MPEG-2 (MPEG stands for Moving Picture Experts Group; MPEG-2 is also known as ISO / IEC 13818, and 13818-1 is also known as H.222, and 13818-2 is also known as H.262), HEVC (HEVC stands for High Efficiency Video Coding, also known as H.265 and MPEG-H Part 2), or VVC (Universal Video Coding: a new standard being developed by the Joint Video Experts Team JVET)).

[0301] Input to the components of system 1000 can be provided through various input devices as indicated in box 1130. Such input devices include, but are not limited to: (i) a radio frequency (RF) section that receives, for example, RF signals transmitted over the air by a broadcaster; (ii) component (COMP) input terminals (or a collection of COMP input terminals); (iii) a universal serial bus (USB) input terminal; and / or (iv) a high-definition multimedia interface (HDMI) input terminal. Figure 1 Other examples not shown in C include composite video.

[0302] In various embodiments, the input device of block 1130 has associated corresponding input processing elements as known in the art. For example, the RF section may be associated with elements suitable for: (i) selecting a desired frequency (also referred to as selecting a signal or limiting a signal to a frequency band); (ii) down-converting the selected signal; (iii) further limiting the frequency band to a narrower band to select, for example, a signal band that may be referred to as a channel in some embodiments; (iv) demodulating the down-converted and band-limited signal; (v) performing error correction; and (vi) demultiplexing to select the desired stream of data packets. The RF section in various embodiments includes one or more elements to perform these functions, such as frequency selectors, signal selectors, band limiters, channel selectors, filters, downconverters, demodulators, error correctors, and demultiplexers. The RF section may include a tuner that performs various of these functions, including, for example, down-converting a received signal to a lower frequency (e.g., intermediate frequency or near-baseband frequency) or to baseband. In one set-top box embodiment, the RF section and its associated input processing elements receive RF signals transmitted over a wired (e.g., cable) medium and perform frequency selection by filtering, down-converting, and filtering again to the desired frequency band. Various embodiments rearrange the order of the components described above (and others), remove some of these components, and / or add other components that perform similar or different functions. Adding components may include inserting components between existing components, such as, for example, inserting amplifiers and analog-to-digital converters. In various embodiments, the RF section includes an antenna.

[0303] Additionally, the USB and / or HDMI endpoints may include corresponding interface processors for connecting the system 1000 to other electronic devices across USB and / or HDMI connections. It should be understood that various aspects of input processing, such as Reed-Solomon error correction, can be implemented, for example, within a separate input processing IC or, if necessary, within the processor 1010. Similarly, aspects of USB or HDMI interface processing can be implemented, either within a separate interface IC or, if necessary, within the processor 1010. The demodulated, error-corrected, and demultiplexed stream is provided to various processing elements, including, for example, the processor 1010 and encoder / decoder 1030, which operate in conjunction with memory and storage elements to process the data stream as needed for presentation on an output device.

[0304] Various components of the system 1000 can be provided within an integrated housing, in which the various components can be interconnected and data can be transmitted therebetween using a suitable connection arrangement 1140, such as an internal bus as known in the art, including inter-IC (I2C) bus, wiring and printed circuit board.

[0305] System 1000 includes a communication interface 1050, which enables communication with other devices via a communication channel 1060. The communication interface 1050 may include, but is not limited to, a transceiver configured to transmit and receive data on the communication channel 1060. The communication interface 1050 may include, but is not limited to, a modem or network interface card (NIC), and the communication channel 1060 may be implemented over, for example, wired and / or wireless media.

[0306] In various embodiments, a wireless network such as Wi-Fi (e.g., IEEE 802.11 (IEEE refers to the Institute of Electrical and Electronics Engineers)) is used to stream or otherwise provide data to system 1000. In these embodiments, the Wi-Fi signal is received on a communication channel 1060 and a communication interface 1050 adapted for Wi-Fi communication. The communication channel 1060 in these embodiments is typically connected to an access point or router that provides access to external networks, including the Internet, to allow streaming applications and other over-the-top communications. Other embodiments use a set-top box that delivers data over an HDMI connection in input box 1130 to provide streaming data to system 1000. Still other embodiments use an RF connection in input box 1130 to provide streaming data to system 1000. As indicated above, various embodiments provide data in a non-streaming manner. Additionally, various embodiments use wireless networks other than Wi-Fi, such as cellular networks or Bluetooth networks.

[0307] System 1000 can provide output signals to various output devices, including display 1100, speaker 1110, and other peripheral devices 1120. Display 1100 in various embodiments includes one or more of the following: for example, a touchscreen display, an organic light-emitting diode (OLED) display, a curved display, and / or a foldable display. Display 1100 can be used in televisions, tablets, laptops, cellular phones (mobile phones), or other devices. Display 1100 can also be integrated with other components (e.g., as in smartphones) or separate (e.g., an external monitor for a laptop). In various examples of embodiments, other peripheral devices 1120 include one or more of a standalone digital video disc (or digital multifunction disc) (DVR, for both terms), a disc player, a stereo system, and / or a lighting system. Various embodiments use one or more peripheral devices 1120 that provide functionality based on the output of system 1000. For example, a disc player performs the function of playing the output of system 1000.

[0308] In various embodiments, signaling such as AV is used to transmit control signals between system 1000 and display 1100, speaker 1110, or other peripheral devices 1120. Device-to-device control links, consumer electronics control (CEC), or other communication protocols are implemented with or without user intervention. Output devices can be communicatively coupled to system 1000 via dedicated connections through corresponding interfaces 1070, 1080, and 1090. Alternatively, output devices can be connected to system 1000 via communication interface 1050 using communication channel 1060. Display 1100 and speaker 1110 can be integrated into a single unit with other components of system 1000 in electronic devices such as, for example, televisions. In various embodiments, display interface 1070 includes a display driver, such as, for example, a timing controller (TCon) chip.

[0309] Display 1100 and speaker 1110 can alternatively be separated from one or more other components, for example, if the RF section of input 1130 is part of a separate set-top box. In various embodiments where display 1100 and speaker 1110 are external components, output signals can be provided via dedicated output connections, including, for example, HDMI ports, USB ports, or COMP outputs.

[0310] The embodiments may be implemented by computer software implemented by processor 1010, or by hardware, or by a combination of hardware and software. As a non-limiting example, the embodiments may be implemented by one or more integrated circuits. As a non-limiting example, memory 1020 may be of any type suitable for the technical environment and may be implemented using any suitable data storage technology, such as optical memory devices, magnetic memory devices, semiconductor-based memory devices, fixed memory, and removable memory. As a non-limiting example, processor 1010 may be of any type suitable for the technical environment and may encompass one or more of microprocessors, general-purpose computers, special-purpose computers, and processors based on multi-core architectures.

[0311] Additional Examples A mesh encoding method according to some embodiments includes: encoding a first connected component of a mesh using edge breaking encoding; identifying unencoded corners in the mesh after encoding the first connected component of the mesh; and using the identified unencoded corners as entry corners to encode a second connected component of the mesh.

[0312] A mesh encoding method according to some embodiments includes: identifying at least one non-manifold edge in a mesh; copying vertices along the non-manifold edge to separate the non-manifold edge into at least two manifold edges; stitching two of the at least two manifold edges together; and encoding the mesh using edge breaking encoding after stitching the two of the at least two manifold edges together.

[0313] An example encoding method according to some embodiments includes: identifying at least one non-manifold edge in a mesh, the non-manifold edge being defined by a parent vertex; preprocessing the mesh by copying the parent vertex along the non-manifold edge to separate the non-manifold edge into at least two manifold edges, each manifold edge being defined by a child vertex, each child vertex being copied from a corresponding parent vertex; encoding the preprocessed mesh into a bitstream using edge breaking encoding; and providing information identifying the parent vertex of the child vertex in the bitstream.

[0314] An example decoding method according to some embodiments includes: obtaining information from a bitstream defining a plurality of connected components of a nonmanifold mesh with broken edge encoding; obtaining information from the bitstream associating child vertices with parent vertices; at least partially decoding at least two of the connected components, each of the connected components having a child vertex associated with a corresponding parent vertex; and deduplicating the child vertices to reconstruct the nonmanifold mesh.

[0315] A mesh encoding method according to some embodiments includes: preprocessing a mesh with holes by creating virtual vertices connected to each vertex along the perimeter of the holes; encoding the preprocessed mesh in a bitstream using edge breaking encoding; encoding information identifying the virtual vertices in the bitstream; and encoding at least one attribute for each of a plurality of vertices in the preprocessed mesh, wherein the attribute is not encoded for the virtual vertex.

[0316] A mesh decoding method according to some embodiments includes: obtaining information encoding a mesh from a bitstream; obtaining information identifying at least one virtual vertex in the mesh from the bitstream; and decoding attribute information for a plurality of vertices in the mesh from the bitstream, wherein the attribute information is not decoded for the at least one virtual vertex.

[0317] In some embodiments, decoding attribute information for multiple vertices includes: predicting attribute information for multiple vertices, wherein no attribute information is predicted for virtual points.

[0318] Some embodiments further include: removing virtual points.

[0319] A mesh encoding method according to some embodiments includes: encoding the connectivity of a mesh; entropy encoding a first table of starting point positions of vertices in the mesh; and entropy encoding a second table of point residuals of vertices in the mesh separately.

[0320] A mesh decoding method according to some embodiments includes: decoding information indicating the connectivity of a mesh; performing entropy decoding on a first table of starting point positions of vertices in the mesh; and performing entropy decoding separately on a second table of point residuals of vertices in the mesh.

[0321] A mesh encoding method according to some embodiments includes: obtaining information defining a mesh having multiple connected components (CCs), each vertex in a CC having a unique global range index; for each CC, shifting the index of a vertex in the CC from the global range index to a CC range index; and using the CC range index to encode each of the CCs.

[0322] A mesh decoding method according to some embodiments includes: obtaining information encoding a plurality of connected components (CCs), each vertex in a CC having a corresponding CC range index; decoding each of the CCs; and for each vertex, shifting the vertex's index from the CC range index to a global range index.

[0323] A mesh encoding method according to some embodiments includes: obtaining information describing a mesh having a plurality of triangles, each triangle having an attribute; encoding the mesh as an ordered sequence of symbols in edge breaking encoding, each of the triangles corresponding to an associated symbol; and encoding the attribute of the triangle, the attribute of the current triangle being encoded using predictions based solely on the attributes of at least one triangle preceding the current triangle in the ordered sequence of symbols.

[0324] The grid decoding method includes: obtaining an ordered sequence of symbols representing a grid with multiple triangles, each triangle having an attribute; decoding the grid; and decoding the attribute of the triangle, wherein the attribute of the current triangle is decoded using predictions based solely on the attributes of at least one triangle preceding the current triangle in the ordered sequence of symbols.

[0325] A mesh encoding method according to some embodiments includes: obtaining information describing a mesh having a plurality of triangles, each triangle having an attribute; encoding the mesh as an ordered sequence of symbols in edge breaking encoding, each of the triangles corresponding to an associated symbol; and encoding the attributes of the triangles, the attributes of the current triangle being encoded using predictions based on the attributes of at least one triangle in the mesh adjacent to the current triangle.

[0326] In some embodiments, encoding the properties of the triangles includes encoding a plurality of Boolean vectors that collectively indicate, for at least a plurality of triangles, the corresponding triangle from which the respective properties are predicted.

[0327] Some embodiments further include performing arithmetic encoding of the plurality of Boolean vectors.

[0328] In some embodiments, the attribute is an identifier.

[0329] A grid decoding method according to some embodiments includes: obtaining an ordered sequence of symbols representing a grid with broken edges encoding, each triangle having an attribute; decoding the grid; and decoding the attribute of the triangle, wherein the attribute of the current triangle is decoded using a prediction based on the attribute of at least one triangle in the grid adjacent to the current triangle.

[0330] In some embodiments, decoding the properties of the triangle includes decoding a plurality of Boolean vectors that collectively indicate, for at least a plurality of triangles, the corresponding triangle from which the respective properties are predicted.

[0331] In some embodiments, decoding the plurality of Boolean vectors includes arithmetic decoding of the plurality of Boolean vectors.

[0332] In some embodiments, the attribute is an identifier.

[0333] An apparatus according to some embodiments includes one or more processors, the apparatus being configured to perform any of the methods described herein.

[0334] An apparatus according to some embodiments includes at least one processor and a computer-readable medium storing instructions for performing any of the methods described herein.

[0335] Some embodiments include a computer-readable medium (e.g., a non-transient medium) storing instructions for performing any of the methods described herein.

[0336] Some embodiments include a computer-readable medium storing a grid encoded according to any of the methods described herein.

[0337] Some embodiments include signals that transmit a grid encoded according to any of the methods described herein.

[0338] Some example implementations provide a non-destructive mode that can reconstruct meshes using “poor” connectivity, allowing for the non-destructive re-creation of non-manifold surfaces where desired.

[0339] Some example implementations provide support for holes and boundaries by encoding “virtual” virtual points without encoding the attributes of the virtual points.

[0340] Some example implementations provide support for multiple connected components (CCs).

[0341] Some implementations provide extensions for geometries to predict multiple parallelograms to support virtual points.

[0342] Some embodiments add support for texture coordinates encoded using a unique index table and a separate index table. Some of these embodiments provide extensions to stretch prediction to support virtual points and separate index tables when needed.

[0343] Some embodiments provide specific binarization schemes and AC context handling for use with Dirac arithmetic coding.

[0344] Some implementations include support for attributes (identifiers or colors) for each face encoded using a chain of triangles.

[0345] Note that the various hardware elements in one or more of the described embodiments are referred to as “modules” that implement (i.e., perform, execute, etc.) the various functions described herein in conjunction with their respective modules. As used herein, a module includes hardware considered suitable for a given implementation by those skilled in the art (e.g., one or more processors, one or more microprocessors, one or more microcontrollers, one or more microchips, one or more application-specific integrated circuits (ASICs), one or more field-programmable gate arrays (FPGAs), one or more memory devices). Each described module may also include instructions executable to implement one or more functions described as being implemented by the respective module, and it should be noted that such instructions may take the form of hardware (i.e., hardwired) instructions, firmware instructions, software instructions, etc., or include hardware (i.e., hardwired) instructions, firmware instructions, software instructions, etc., and may be stored in one or more of any suitable non-transient computer-readable media (such as collectively referred to as RAM, ROM, etc.).

[0346] Although features and elements have been described above in specific combinations, those skilled in the art will appreciate that each feature or element may be used individually or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magnetic-optical media, and optical media (such as CD-ROMs and digital multifunction discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

[0347] Appendix A 1. Introduction A set of vertices can be a 3D location, a set of attached properties and associated connectivity (note that the location connectivity may not be the same as the per-attribute connectivity).

[0348] Attributes can be per-face or per-vertex. Depending on the face being considered, a vertex can have multiple attribute values, which can be shared across all faces. When attribute values ​​are not systematically shared across all faces, then attribute connectivity differs from vertex connectivity.

[0349] CLERS is a set of symbols used to describe the topology of (single-component) meshes. C = (add triangle without attachment), L = left, R = right, S = split, E = end. These symbols are sufficient to describe holes and handles, but are not applicable to non-manifold meshes.

[0350] Syntax and Semantics 2.1. Specification of Syntax Functions and Descriptors - ae(v): Semantic element of context-adaptive arithmetic entropy encoding. - vu(v): An unsigned integer using a variable number of bytes as groups of 8 bits. The parsing procedure for this descriptor is specified by the return value of the function read_bits(1) followed by readbits(7). A second value is appended to the resulting bit sequence, and the procedure iterates while the first value is equal to 1. Specifically, the parsing procedure for this descriptor is specified as follows: vu(v) { value = 0 do { continue = read_bits(1) partial_value = read_bits( 7 ) value = ( value<<7 ) | partial_value } while (continue) return value } - vi(v): ​​A signed integer using a variable number of bytes as groups of 8 bits. The parsing process for this descriptor is specified by the return value of the function read_bits(1) followed by readbits(7). A second value is appended to the resulting bit sequence, and the process iterates while the first value is equal to 1. Given that the syntax elements have been mapped to unsigned integers, the resulting bit sequence, interpreted as an unsigned integer, is assigned to the signed integer value by sorting those syntax elements in ascending order by their absolute values ​​and using the highest encoded value to represent a positive value for a given absolute value. Table A.1 provides the assignment rules. In particular, the parsing process for this descriptor is specified as follows: vi(v) { value = 0 do { continue = read_bits(1) partial_value = read_bits( 7 ) value = ( value<<7 ) | partial_value} while( continue ) is_positive = !( value&1 ) value = ( value>>1 ) if (is_positive) return value else return -(value + 1) }

[0351] Table A.1 – Assignment of Syntax Elements to CodeNum codeNum Syntax element value 0 0 1 −1 2 1 3 −2 4 2 5 -3 6 3 k <![CDATA[( (k + 1) / 2 ) * (−1) k ]]> Notice: Specify a limit on the number of bytes to avoid defining a very large value vu32(v) of up to 32 bits or 4 bytes. You can use up to 5 bytes to encode up to 32 bits, or up to 4 bytes to encode a value on 7*3+8=29 bits.

[0352] Grid syntax 2.2.1. General Mesh Encoding Syntax Notice: Here, the header information can be static for the entire sequence. mesh_coding() { descriptor mesh_coding_header() mesh_position_coding_payload() mesh_attributes_coding_payload() }

[0353] 2.2.2. Mesh-coded header syntax mesh_coding_header() { descriptor mesh_codec_type u(2) mesh_position_encoding_parameters() mesh_position_dequantize_parameters() mesh_attribute_count u(3) for( i=0; i<mesh_attribute_count; i++ ){ mesh_attribute_type[i] u(3) mesh_attribute_per_face[ i ] (†) u(1) if( !mesh_attribute_per_face[ i ]) (†) mesh_attribute_has_separate_index[ i ] (†) u(1) mesh_attribute_depth_minus1[ i ] (†) u(4) mesh_attribute_encoding_parameters (i) mesh_attribute_dequantize_parameters (i) } length_alignment() } In some embodiments, features marked with a dagger (†) may be excluded. The mesh_codec_type indicates the codec method selected by the identifier. Table A.2 describes a list of supported methods.

[0354] Table A.2 – Mesh Codec Types mesh_codec_type identifier Codec type 0 CODEC_TYPE_FORWARD positive 1..3 CODEC_TYPE_RESERVED Reserved Note – Forward traversal, which is only implemented in the current version, can be extended using, for example, reverse traversal or other advanced variants.

[0355] mesh_attribute_count indicates the number of encoded attributes.

[0356] `mesh_attribute_type[i]` indicates the attribute type of the i-th attribute, where i is in the range 0 to 7. Table A.3 describes a list of supported attributes.

[0357] Table A.3 – Mesh Attribute Types mesh_attribute_type [i] identifier Attribute type 0 MESH_ATTR_TEXCOORD Texture coordinates 1 MESH_ATTR_NORMAL normal 2 MESH_ATTR_COLOR color 3 MESH_ATTR_MATERIAL_ID Material ID 4 MESH_ATTR_GENERIC General 5..7 MESH_ATTR_RESERVED Reserved 8 MASH_ATTR_UNSPECIFIED not specified Note – Generic attributes will have the number of their components specified by the value of the corresponding mesh_attribute_generic_num_components_minus1[index]. Other attributes have a fixed number of components.

[0358] 2.2.3. Grid Position Encoding Parameter Syntax mesh_position_encoding_parameters() { descriptor mesh_position_depth_minus1 u(4) mesh_position_deduplicate u(1) mesh_clers_symbols_encoding_method ue(v) mesh_position_prediction_method ue(v) mesh_position_residuals_encoding_method ue(v) }

[0359] Increasing 1 to mesh_position_depth_minus1 specifies the number of bits used to represent the 3D position coordinates. Note – Use 1 to 16 bits to encode 3D position coordinates. However, use of very small depths, such as 1 bit or 2 bits, is extremely impractical.

[0360] A mesh_position_deduplicate value of 1 indicates that vertex deduplication is applied (in some embodiments and / or under some conditions, deduplication may not be applied). Note – Some example implementations use general size information at a lower level (i.e., the size of some information required for deduplication).

[0361] The mesh_clers_symbols_encoding_method specifies the method used to encode the mesh_clers_symbol[i]. Table A.4 describes a list of supported methods.

[0362] Table A.4 – Grid CLERS Symbol Encoding Method mesh_clers_symbols_encoding_method identifier Encoding method 0 MESH_CLERS_AC_DEFAULT default >1 MESH_CLERS_AC_RESERVED Reserved Note – we therefore use 1 bit, and only the default method is selectable. When other methods are added, they should provide significant gains so that the overhead of ue(v) encoding is negligible. The number of allowed encoding methods can then be expanded without restriction, without harming the bitstream size or performing parsing. The same scheme applies to all prediction and encoding method selections.

[0363] The mesh_position_prediction_method specifies the method used to predict vertex positions and compute the residual mesh_position_residual[i][j]. Table A.5 describes a list of supported methods.

[0364] Table A.5 – Grid Location Prediction Method mesh_position_prediction_method identifier Prediction methods 0 MESH_POSITION_MPARA Multiple parallelograms >1 MESH_POSITION_RESERVED Reserved

[0365] The mesh_position_residuals_encoding_method specifies the method used to encode the mesh_position_residual[i][j]. Table A.6 describes a list of supported methods.

[0366] Table A.6 – Grid Location Residual Coding Method mesh_position_residuals_encoding_method identifier Encoding method 0 MESH_POSITION_AC_DEFAULT default >1 MESH_POSITION_AC_RESERVED Reserved

[0367] 2.2.4. Syntax for Mesh Position Inverse Quantization Parameters mesh_position_dequantize_parameters() { descriptor mesh_position_dequantize u(1) if(mesh_position_dequantize) { for( i=0; i<3; i++ ){ mesh_position_min[i] fl(32) mesh_position_max[i] fl(32) } } }

[0368] A mesh_position_dequantize value of 1 indicates that bounding box information should be used to dequantize the decoded 3D position. A mesh_position_dequantize value of 0 indicates that the decoded attribute is a (quantized) unsigned integer.

[0369] `mesh_position_min[i]` specifies the minimum value of the i-th component after dequantization at the 3D position. The i-th component value of the quantized position is 0 and will be mapped to `mesh_position_min[i]` after dequantization. Note that mesh_position_min[i] and mesh_position_min[j] are defined as fl(32) values. fl(32) is defined and used in 23090-5 for the description of viewport camera parameters and viewport position.

[0370] `mesh_position_max[i]` specifies the maximum value of the i-th component after inverse quantization at the 3D position. mesh _position_depth_minus1 + 1 – The quantized position i-th component value of 1 will be mapped to mesh_position_max[i] after dequantization.

[0371] 2.2.5. Mesh Attribute Encoding Parameter Syntax mesh_attribute_encoding_parameters( index ) { descriptor mesh_attribute_per_face[ index ] u(1) if(!mesh_attribute_per_face[index]) mesh_attribute_has_separate_index[ index ] u(1) mesh_attribute_depth_minus1[index] u(4) mesh_attribute_prediction_method[ index ] ue(v) mesh_attribute_residuals_encoding_method[ index ] ue(v) }

[0372] A mesh_attribute_per_face[i] equal to 1 indicates that the i-th attribute has a value defined per face. A mesh_attribute_per_face[i] equal to 0 indicates that the i-th attribute has a value defined per vertex. Note – When an attribute is defined per face, there is no index ambiguity. When an attribute is defined per vertex, they can each have their own set of indices.

[0373] `mesh_attribute_has_separate_index[i]` specifies whether the i-th attribute is a specific index sequence to which it is attached. (When a separate index is not defined, any other attribute can be used as a reference if a position index is not used).

[0374] The increment of mesh_attribute_depth_minus1[i] by 1 specifies the number of bits used to represent the component of the i-th attribute.

[0375] `mesh_attribute_prediction_method[i]` specifies the method used to predict the value of the i-th attribute and compute the residual `mesh_attribute_residual[i][j][k]`. Table A.7 describes a list of supported methods for attributes with a `mesh_attribute_type` equal to `MESH_ATTR_TEXCOORD`, Table A.8 describes a list of supported methods for attributes with a `mesh_attribute_type` equal to `MESH_ATTR_NORMAL`, Table A.9 describes a list of supported methods for attributes with a `mesh_attribute_type` equal to `MESH_ATTR_COLOR`, Table A.10 describes a list of supported methods for attributes with a `mesh_attribute_type` equal to `MESH_ATTR_MATERIAL_ID`, and Table A.11 describes a list of supported methods for attributes with a `mesh_attribute_type` equal to `MESH_ATTR_GENERIC`.

[0376] Table A.7 – Mesh Attribute Prediction Methods for MESH_ATTR_TEXCOORD Type Attributes mesh_attribute_prediction_method identifier Prediction methods 0 MESH_TEXCOORD_STRETCH stretching >1 MESH_TEXCOORD_RESERVED Reserved

[0377] Table A.8 – Mesh Attribute Prediction Methods for MESH_ATTR_NORMAL Type Attributes mesh_attribute_prediction_method identifier Prediction methods 0 MESH_NORMAL_DEFAULT default >1 MESH_NORMAL_RESERVED Reserved

[0378] Table A.9 – Mesh Attribute Prediction Methods for MESH_ATTR_COLOR Type Attributes mesh_attribute_prediction_method identifier Prediction methods 0 MESH_COLOR_DEFAULT default >1 MESH_COLOR_RESERVED Reserved

[0379] Table A.10 – Mesh Attribute Prediction Methods for MESH_ATTR_MATERIAL_ID Type Attributes mesh_attribute_prediction_method identifier Prediction methods 0 MESH_MATERIALID_DEFAULT default >1 MESH_MATERIALID_RESERVED Reserved

[0380] Table A.11 – Mesh attribute prediction method for MESH_ATTR_GENERIC type attribute mesh_attribute_prediction_method identifier Prediction methods 0 MESH_GENERIC_DEFAUT default >1 MESH_GENERIC_RESERVED Reserved

[0381] `mesh_attribute_residuals_encoding_method[i]` specifies the method used to encode the values ​​in the `mesh_attribute_residual[i]` array. Table A.12 describes a list of supported methods for attributes of `mesh_attribute_type` that are equal to `MESH_ATTR_TEXCOORD`, Table A.13 describes a list of supported methods for attributes of `mesh_attribute_type` that are equal to `MESH_ATTR_NORMAL`, Table A.14 describes a list of supported methods for attributes of `mesh_attribute_type` that are equal to `MESH_ATTR_COLOR`, Table A.15 describes a list of supported methods for attributes of `mesh_attribute_type` that are equal to `MESH_ATTR_MATERIAL_ID`, and Table A.16 describes a list of supported methods for attributes of `mesh_attribute_type` that are equal to `MESH_ATTR_GENERIC`. Note – Although a default prediction method has been implemented for attributes of type MESH_ATTR_TEXCOORD and MESH_ATTR_MATERIAL_ID, a default prediction method must still be implemented for other attribute types.

[0382] Table A.12 – Attribute Residual Encoding Method for MESH_ATTR_TEXCOORD Type Attributes mesh_attribute_residuals_encoding_method identifier Encoding method 0 MESH_TEXCOORD_AC_DEFAULT default >1 MESH_TEXCOORD_AC_RESERVED Reserved

[0383] Table A.13 – Attribute Residual Encoding Method for MESH_ATTR_NORMAL Type Attributes mesh_attribute_residuals_encoding_method identifier Encoding method 0 MESH_NORMAL_AC_DEFAULT default >1 MESH_NORMAL_AC_RESERVED Reserved

[0384] Table A.14 – Attribute Residual Encoding Method for MESH_ATTR_COLOR Type Attributes mesh_attribute_residuals_encoding_method identifier Encoding method 0 MESH_COLOR_AC_DEFAULT default >1 MESH_COLOR_AC_RESERVED Reserved

[0385] Table A.15 – Attribute Residual Encoding Method for MESH_ATTR_MATERIAL_ID Type Attributes mesh_attribute_residuals_encoding_method identifier Encoding method 0 MESH_MATERIALID_AC_DEFAULT default >1 MESH_MATERIALID_AC_RESERVED Reserved

[0386] Table A.16 – Attribute Residual Encoding Method for MESH_ATTR_GENERIC Type Attributes mesh_attribute_residuals_encoding_method identifier Encoding method 0 MESH_GENERIC_AC_DEFAULT default >1 MESH_GENERIC_AC_RESERVED Reserved

[0387] 2.2.6. Syntax for Mesh Attribute Inverse Quantization Parameters Notice: In some embodiments, the loop can be revised for efficiency so that it is possible to align the fl(32) value. This embodiment can then loop over the attribute index to define mesh_attribute_dequantize[index] and mesh_attribute_num_components_minus1[index] and NumComponents[index], and then loop over the mesh_attribute_min and mesh_attribute_max values. mesh_attribute_dequantize_parameters( index ) { descriptor mesh_attribute_dequantize[index] u(1) if(mesh_attribute_dequantize[index]) if(mesh_attribute_type[index] == MESH_ATTR_TEXCOORD) NumComponents[index] = 2 else if(mesh_attribute_type[ index ] == MESH_ATTR_NORMAL ) NumComponents[index] = 3 else if(mesh_attribute_type[ index ] == MESH_ATTR_COLOR ) NumComponents[index] = 3 else if(mesh_attribute_type[ index ] == MATERIAL_ID ) NumComponents[index] = 1 else if(mesh_attribute_type[ index ] == GENERIC ) { mesh_attribute_num_components_minus1[index] u(2) NumComponents[index] = mesh_attribute_num_components_minus1[ index ]+1 } for( j=0; j<NumComponents[ index ]; j++ ){ mesh_attribute_min[ index ][ j ] fl(32) mesh_attribute_max[ index ][ j ] fl(32) } } } A mesh_attribute_dequantize[i] equal to 1 indicates that bounding box information should be used to dequantize the decoded attribute. A mesh_attribute_dequantize[i] equal to 0 indicates that the decoded attribute is a (quantized) unsigned integer.

[0388] Incrementing mesh_attribute_num_components_minus1[index] by 1 specifies the number of components of the index-th attribute when mesh_attribute_type[index] is equal to MESH_ATTR_GENERIC.

[0389] `mesh_attribute_min[index][j]` specifies the minimum value of the dequantized j-th component of the i-th attribute. A quantized j-th component value of the index-th attribute that is 0 will be mapped to `mesh_attribute_min[index][i]` after dequantization.

[0390] `mesh_attribute_max[index][j]` specifies the maximum value of the inversely quantized j-th component of the i-th attribute. mesh_attribute_depth_minus1[ index ] + 1 – The quantized index-th attribute j-th component value of 1 will be mapped to mesh_attribute_max[index][j] after dequantization.

[0391] 2.2.7. Mesh Position Encoding Payload Syntax Notice: When using arithmetic encoding (i.e., using the ae(v) descriptor), we generally specify the encoded length in bytes to enable parallel decoding; otherwise, sequential parsing will be required. mesh_position_coding_payload( ) { Descriptor mesh_vertex_count vu(v) mesh_clers_count vu(v) mesh_cc_count vu(v) mesh_dummy_vertex_count vu(v) for( i=0; i<mesh_dummy_vertices_count; i++ ){ mesh_dummy_index_delta[ i ] vu(v) } mesh_cc_with_handles_count vu(v) NumHandles = 0 for( i=0; i<mesh_cc_with_handles_count; i++ ){ mesh_handles_cc_offset[ i ] vu(v) mesh_handles_count[ i ] vu(v) NumHandles += mesh_handles_count[ i ] } for( i=0; i<NumHandles; i++ ){ mesh_handle_index_first_delta[ i ] vi(v) mesh_handle_index_second_delta[ i ] vi(v) } mesh_coded_handle_index_second_shift_size vu(v) for( i=0; i<NumHandles; i++ ){ mesh_handle_index_second_shift[ i ] ae(v) } length_alignment( ) mesh_coded_clers_symbols_size vu(v) for( i=0; i<mesh_clers_count; i++ ){ mesh_clers_symbol[ i ] ae(v) } length_alignment( ) for( i=0; i<mesh_cc_count; i++ ){ for( j=0; j<3; j++ ){ mesh_position_start_delta[ i ][ j ] (†) vi(v) mesh_position_start[ i ][ j ] u(v) } } length_alignment( ) mesh_coded_position_residuals_size vu(v) NumPredictedPositions = mesh_vertex_count - mesh_cc_count for( i=0; i<NumPredictedPositions; i++ ){ for( j=0; j<3; j++ ){ mesh_position_residual[ i ][ j ] ae(v) } } length_alignment( ) if( mesh_position_deduplicate ) mesh_position_deduplicate_information() }

[0392] In some embodiments, features marked with a dagger (†) may be excluded. Notice: Some embodiments provide splitting into topological payloads, and then per-attribute payloads, because each attribute, which includes a sequence of positions as syntactic elements, is quite similar.

[0393] Mesh_vertex_count specifies the number of vertices in the decoded mesh. Note - mesh_vertex_count does not include virtual points inserted during topology reconstruction and removed in subsequent mesh cleanup phases.

[0394] mesh_clers_count specifies the number of encoded CLERS symbols. Note – the first symbol in the symbol sequence for each per-connected component is not encoded. After topology reconstruction, the number of triangles is (mesh_clers_count + mesh_cc_count). After mesh cleanup, an unspecified number of triangles connected to virtual points are removed.

[0395] mesh_cc_count specifies the number of connected components included in the encoded mesh.

[0396] The mesh_dummy_vertex_count specifies the number of dummy vertices inserted to close holes in the reconstructed topology. Note that mesh_dummy_vertex_count >= mesh_cc_count. Some implementations include features to be encoded (mesh_dummy_vertex_count – mesh_cc_count).

[0397] `mesh_dummy_index_delta[i]` specifies the difference between the index of the i-th virtual point and the index of the (i-1)-th virtual point when i is greater than 0. When i is equal to 0, `mesh_dummy_index_delta[0]` specifies the value of the index of the first virtual point.

[0398] The mesh_cc_with_handles_count specifies the number of connected components with a non-zero handle count.

[0399] mesh_handles_count[i] specifies the number of handles included in the i-th connected component with a non-zero handle count.

[0400] `mesh_handles_cc_offset[i]` specifies the difference between the index of the i-th connected component with a non-zero handle count and the index of the (i-1)-th connected component with a non-zero handle count when i is greater than 0. When i is equal to 0, `mesh_handles_cc_offset[0]` specifies the index of the first connected component with a non-zero handle count.

[0401] `mesh_handle_index_first_delta[i]` specifies the difference between the triangle indices of the origin of the i-th handle and the origin of the (i-1)-th handle when i is greater than 0. When i is equal to 0, `mesh_handle_index_first_delta[0]` specifies the triangle index of the origin of the first handle.

[0402] `mesh_handle_index_second_delta[i]` specifies the difference between the triangle indices of the i-th handle destination and the (i-1)-th handle destination when i is greater than 0. When i equals 0, `mesh_handle_index_second_delta[0]` specifies the triangle index of the first handle destination.

[0403] The mesh_coded_handle_index_second_shift_size specifies the size in bytes of the arithmetically encoded sequence of mesh_handle_index_second_shift values, including the final byte alignment.

[0404] mesh_handle_index_second_shift[i] specifies the shift to be applied when calculating the corner index associated with the destination of the i-th handle. Note – Handle indices are relative to triangle / face indices because the relevant corner indices can be implicitly inferred. The corner index of the first handle conforms to (3 * T + 0). The corner index of the second handle conforms to (3 * T + 1) or (3 * T + 2). `mesh_handle_index_second_shift[i]` is used to distinguish between those two cases.

[0405] The mesh_coded_clers_symbols_size specifies the size in bytes of the arithmetically encoded sequence of CLERS symbols, including the final byte alignment. Note – Explicitly specifying mesh_coded_clers_symbols_size enables parsing and parallel decoding of CLERS symbols.

[0406] mesh_clers_symbol[i] specifies the value of the i-th CLERS symbol.

[0407] `mesh_position_start_delta[i][j]` specifies the difference between the value of the j-th component at the first position of the i-th connected component and the value of the j-th component at the first position of the (i-1)-th connected component when i is greater than 0. When i equals 0, `mesh_position_start_delta[0][j]` specifies the value of the j-th component at the first position of the first connected component. This feature can be excluded in some embodiments.

[0408] mesh_position_start[i][j] specifies the value of the j-th component at the first position of the i-th connected component, as an unsigned integer encoded using mesh_position_depth_minus1 + 1 bits. Note that using mesh_position_start_delta[i][j] and vi(v) allows for fast parsing, but using mesh_position_start[i][j] and u(v) is more compact in general. We will choose to use u(v) for encoding.

[0409] The mesh_coded_position_residuals_size specifies the size in bytes of the arithmetically encoded sequence of position residuals, including the final byte alignment. Note – Explicitly specifying mesh_coded_position_residuals_size enables parsing and parallel decoding of the (predicted) position residuals.

[0410] mesh_position_residual[i][j] specifies the value of the prediction residual associated with the j-th component of the i-th predicted position. Note – Some flexibility is added because the optimal cyclic ordering (e.g., per residual, then per component) may vary depending on the prediction method and the defined AC encoding scheme. This also applies to the attribute residual mesh_attribute_residual[i][j][k] in 2.2.9.

[0411] 2.2.8. Syntax for Deduplication of Grid Position Information Notice: In some embodiments, signaling at a higher level to avoid alignment costs may be preferred.

[0412] The `mesh_position_dedup_encoding_method` specifies the method used to encode the deduplication information. Table A.17 describes a list of supported methods. Note – We do not set the selection at the header level for each frame, because the optimal method may change frame by frame. We can also define a default method at a higher level, and select the default or point to a specific method there.

[0413] Table A.17 – Grid Location Deduplication Information Encoding Method mesh_position_deduplicate_method Identifier Deduplication method 0 MESH_POSITION_DEDUP_NONE None 1 MESH_POSITION_DEDUP_DEFAULT Default >1 MESH_POSITION_DEDUP_RESERVED Reserved The mesh_position_deduplicate_count specifies the number of vertices that are copied. Note – The number of vertices copied is the sum of the original number of vertices that were split and the number of vertices added during the copying process to repair the mesh manifold.

[0414] `mesh_position_deduplicate_idx[i]` specifies a common value for the copied vertices that share a common parent vertex. The value of `mesh_position_deduplicate_idx[i]` varies from 0 to the number of the original vertices that have been split minus 1.

[0415] The mesh_position_deduplicate_start_positions specifies the size of the mesh_position_start array. Note – the copied position can be placed at the first position of a connected component. In this case, the size of the first dimension of the mesh_position_start array can be smaller than the number of connected components. In some embodiments, this can be replaced with an incremental value, thereby counting the number of connected components whose starting value is not encoded.

[0416] mesh_position_is_duplicate_size[i] specifies the size in bytes of the arithmetically encoded sequence of the binary copy indicator mesh_position_is_duplicate_flag[i], including the final byte alignment.

[0417] The value of mesh_position_is_duplicate_flag[i] equal to 1 indicates that the i-th decoded vertex is the copied vertex.

[0418] 2.2.9. Mesh Attribute Encoding Payload Syntax Note: Length_alignment() was added to enable fast parsing, and to enable fast parsing of AC-encoded segments. NumComponents can be defined according to mesh_attribute_type[i] as in 2.2.6. mesh_attribute_coding_payload( ) { Descriptor for( i=0; i<mesh_attribute_count; i++ ){ / * here testing mesh_attribute_per_face_flag[ i ] is redundant as when set to 1 * / / * mesh_attribute_separate_index_flag should be set to its default value 0 * / if( !mesh_attribute_per_face_flag[ i ] && mesh_attribute_separate_index_flag[ i ]) { mesh_attribute_seams_ count[ i ] vu(v) mesh_coded_attribute_seams_ size[ i ] vu(v) for( j=0; j<mesh_attribute_seams_count[ i ]; j++ ){ mesh_attribute_seam[ i ][ j ] ae(v) } length_alignment( ) } if (mesh_attribute_separate_index_flag[ i ]){ mesh_attribute_start_count[ i ] vu(v) NumAttributeStart[i] = mesh_attribute_start_count[ i ] } else if (mesh_attribute_reference_index_plus1[ i ] > 0){ NumAttributeStart[i] = NumAttributeStart[mesh_attribute_reference_index_plus1[ i ] - 1] } else { NumAttributeStart[i] = NumPositionStart } for( j=0; j<mesh_attribute_start_count[ i ]; j++ ){ for( k=0; k<NumComponents[ i ]; k++ ){ mesh_attribute_start[ i ][ j ][ k ] u(v) } } length_alignment( ) mesh_attribute_residuals_count[ i ] vu(v) if( mesh attribute_residuals_count[ i ] ){ mesh_coded_attribute_residuals_size[ i ] vu(v) for( j=0; j<mesh_attribute_residuals_count[ i ]; j++ ){ for( k=0; k<NumComponents[ i ]; k++ ){ mesh_attribute_residual[ i ][ j ][ k ] ae(v) } } length_alignment( ) } if (mesh_attribute_separate_index_flag[ i ]) mesh_attribute_deduplicate_info( i ) / * extra data dependent on the selected prediction scheme * / AttributeType = mesh_attribute_type[ i ] AttributePredictionMethod = mesh_attribute_prediction_method[ i ] mesh_attribute_extra_data( i, AttributeType, AttributePredictionMethod ) } length_alignment( ) }

[0419] mesh_attribute_seams_count[i] specifies the size of the mesh_attribute_seams array for the i-th attribute.

[0420] mesh_coded_attribute_seams_size[i] specifies the size in bytes of the arithmetically encoded sequence of binary seam indicators mesh_attribute_seam[i][j], including the final byte alignment.

[0421] mesh_attribute_seam[i][j] specifies the value of the j-th binary seam indicator for the i-th attribute.

[0422] mesh_attribute_start_count[i] specifies the size of mesh_attribute_start_delta[i] which includes unpredicted attribute values.

[0423] `mesh_attribute_start_delta[i][j][k]` specifies the difference between the value of the k-th component of the j-th value that was not predicted for the i-th attribute when j is greater than 0, and the value of the k-th component of the (j-1)-th value that was not predicted for the i-th attribute. When j equals 0, `mesh_attribute_start_delta[i][0][k]` specifies the value of the k-th component of the j-th value that was not predicted for the i-th attribute. In some embodiments, this feature may be excluded.

[0424] mesh_attribute_start[i][j][k] specifies the value of the k-th component of the j-th value that was not predicted for the i-th attribute and the value of the k-th component as an unsigned integer encoded using mesh_attribute_depth_minus1[i]+1 bits.

[0425] mesh_coded_attribute_residuals_count[i] specifies the size of the mesh_attribute_residual[i] array containing the residual values ​​of the NumComponents[i] components for the i-th attribute.

[0426] mesh_coded_attribute_residuals_size[i] specifies the size in bytes of the arithmetically encoded sequence of the i-th attribute residual mesh_attribute_residual[i][j][k], including the final byte alignment.

[0427] mesh_attribute_residual[i][j][k] specifies the value of the prediction residual associated with the k-th component of the j-th predicted value of the i-th attribute.

[0428] 2.2.10. Syntax for Additional Attribute Data in Mesh mesh_attribute_extra_data( index, type, method ) { descriptor if( type == MESH_ATTR_TEXCOORD ) { if ( method == MESH_TEXCOORD_STRETCH ) mesh_texcoord_stretch_extra_data( index ) } else if(type == MESH_ATTR_NORMAL ) / * No extra data defined for specified prediction methods applied on normals * / else if(type == MESH_ATTR_COLOR ) / * No extra data defined for specified prediction methods applied on colors * / else if(type == MATERIAL_ID ) { if ( method == MESH_MATERIALID_DEFAULT ) mesh_materialid_default_extra_data( index ) } else if(type == GENERIC ) / * No extra data defined for specified prediction methods applied on generic* / }

[0429] 2.2.11. Syntax for stretching extra data in the texcoord mesh mesh_texcoord_stretch_extra_data( index ) { Descriptor mesh_texcoord_stretch_orientations_count[ index ] vu(v) if(mesh_texcoord_stretch_orientations_count>0 ){ mesh_coded_texcoord_stretch_orientations_size[ index] vu(v) for( j=0; j<mesh_texcoord_stretch_orientations_count[ index ]; j++ ){ mesh_texcoord_stretch_orientation[ index ][ j ] ae(v) } } length_alignment( ) }

[0430] `mesh_texcoord_stretch_orientations_count[i]` specifies the size of the array of orientation information `mesh_texcoord_stretch_orientations` used to predict texture coordinates when the `mesh_attribute_type` of the `i`th attribute is equal to `MESH_ATTR_TEXCOORD` and when the associated `mesh_attribute_prediction_method` is equal to `MESH_TEXCOORD_STRETCH`.

[0431] mesh_coded_texcoord_stretch_orientations_size[i] specifies the size in bytes of the arithmetically encoded sequence of orientations contained in the array mesh_texcoord_stretch_orientations[i], including the final byte alignment.

[0432] mesh_texcoord_stretch_orientation[i][j] specifies the value of the j-th orientation bit in the sequence used to generate the i-th attribute value from the arrays mesh_attribute_residual[i] and mesh_attribute_start[i].

[0433] 2.2.12. Default Additional Data Syntax for Mesh MaterialID mesh_materialid_default_extra_data( index ) { Descriptor mesh_materialid_default_equal_count[ index ] vu(v) mesh_materialid_default_left_count[ index ] vu(v) mesh_materialid_default_right_count[ index ] vu(v) mesh_materialid_default_facing_count[ index ] vu(v) if( mesh_materialid_default_equal_count[ index ]>0 ){ mesh_coded_materialid_default_equal_size[ index ] vu(v) for( j=0; j<mesh_materialid_default_equal_count[ index ]; j++ ){ mesh_ materialid_default_equal_flag[ index ][ j ] ae(v) } } if( mesh_materialid_default_left_count[ index ]>0 ){ mesh_coded_materialid_default_left_size[ index ] vu(v) for( j=0; j<mesh_materialid_default_left_count[ index ]; j++ ){ mesh_ materialid_default_left_flag[ index ][ j ] ae(v) } } if( mesh_materialid_default_right_count[ index ]>0 ){ mesh_coded_materialid_default_right_size[ index ] vu(v) for( j=0; j<mesh_materialid_default_right_count[ index ]; j++ ){ mesh_ materialid_default_right_flag[ index ][ j ] ae(v) } } if( mesh_materialid_default_facing_count[ index ]>0 ){ mesh_coded_materialid_default_facing_size[ index ] vu(v) for( j=0; j<mesh_materialid_default_facing_count[ index ]; j++ ){ mesh_ materialid_default_facing_flag[ index ][ j ] ae(v) } } length_alignment( ) }

[0434] mesh_materialid_default_equal_count[i] specifies the size of the array containing the boolean information mesh_materialid_default_equal_flag for predicting the material ID when the mesh_attribute_type of the i-th attribute is equal to MESH_ATTR_MATERIAL_ID and when the associated mesh_attribute_prediction_method is equal to MESH_MATERIALID_DEFAULT.

[0435] mesh_coded_materialid_default_equal_size[i] specifies the size in bytes of the arithmetically encoded sequence of Boolean values ​​contained in the array mesh_materialid_default_equal_flag[i], including the final byte alignment.

[0436] mesh_materialid_default_equal_flag[i][j] specifies the value of the j-th bit in the sequence used to generate the i-th attribute value from the arrays mesh_attribute_residual[i] and mesh_attribute_start[i].

[0437] mesh_materialid_default_left_count[i] specifies the size of the array containing the boolean information mesh_materialid_default_left_flag used to predict the material ID when the mesh_attribute_type of the i-th attribute is equal to MESH_ATTR_MATERIAL_ID and when the associated mesh_attribute_prediction_method is equal to MESH_MATERIALID_DEFAULT.

[0438] mesh_coded_materialid_default_left_size[i] specifies the size in bytes of the arithmetically encoded sequence of boolean values ​​contained in the array mesh_materialid_default_left_flag[i], including the final byte alignment.

[0439] mesh_materialid_default_left_flag[i][j] specifies the value of the j-th bit in the sequence used to generate the i-th attribute value from the arrays mesh_attribute_residual[i] and mesh_attribute_start[i].

[0440] mesh_materialid_default_right_count[i] specifies the size of the array containing the boolean information mesh_materialid_default_right_flag used to predict the material ID when the mesh_attribute_type of the i-th attribute is equal to MESH_ATTR_MATERIAL_ID and when the associated mesh_attribute_prediction_method is equal to MESH_MATERIALID_DEFAULT.

[0441] mesh_coded_materialid_default_right_size[i] specifies the size in bytes of the arithmetically encoded sequence of Boolean values ​​contained in the array mesh_materialid_default_right_flag[i], including the final byte alignment.

[0442] mesh_materialid_default_right_flag[i][j] specifies the value of the j-th bit in the sequence used to generate the i-th attribute value from the arrays mesh_attribute_residual[i] and mesh_attribute_start[i].

[0443] mesh_materialid_default_facing_count[i] specifies the size of the array containing the boolean information mesh_materialid_default_facing_flag used to predict the material ID when the mesh_attribute_type of the i-th attribute is equal to MESH_ATTR_MATERIAL_ID and when the associated mesh_attribute_prediction_method is equal to MESH_MATERIALID_DEFAULT.

[0444] mesh_coded_materialid_default_facing_size[i] specifies the size in bytes of the arithmetically encoded sequence of boolean values ​​contained in the array mesh_materialid_default_facing_flag[i], including the final byte alignment.

[0445] mesh_materialid_default_facing_flag[i][j] specifies the value of the j-th bit in the sequence used to generate the i-th attribute value from the arrays mesh_attribute_residual[i] and mesh_attribute_start[i].

[0446] 2.2.13. Syntax for Deduplicating Grid Attributes The example implementation further includes a syntax element that provides deduplication information.

Claims

1. A mesh decoding method comprising: obtaining, from a bitstream, a crack-coded CLERS table representing a topology of a triangular mesh; reconstructing, from the CLERS table, the topology of the triangular mesh; obtaining, from the bitstream, ordered attribute information representing attributes of respective faces in the triangular mesh; and decoding the ordered attribute information to determine, for each of the faces, an attribute value of the respective face.

2. A mesh decoding apparatus comprising one or more processors configured to perform at least the following: obtaining, from a bitstream, a crack-coded CLERS table representing a topology of a triangular mesh; reconstructing, from the CLERS table, the topology of the triangular mesh; obtaining, from the bitstream, ordered attribute information representing attributes of respective faces in the triangular mesh; and decoding the ordered attribute information to determine, for each of the faces, an attribute value of the respective face.

3. The method of claim 1 or the apparatus of claim 2, wherein the ordered attribute information comprises at least a first vector comprising an entry for each of a plurality of faces, each entry in the first vector being a Boolean value indicating whether an attribute value of a respective current face is the same as an attribute value of a most recently decoded face.

4. The method of claim 1 or claim 3 when dependent on claim 1, or the apparatus of claim 2 or claim 3 when dependent on claim 2, wherein the ordered attribute information further comprises at least a second vector comprising an entry for each of a plurality of faces, each entry in the second vector being a Boolean value indicating whether an attribute of a respective current face is the same as an attribute value of a neighboring face from a first direction of the current face.

5. The method of claim 4 when dependent on claim 1, or the apparatus of claim 4 when dependent on claim 2, wherein the second vector comprises entries for only faces that do not have an attribute value determined by the first vector.

6. The method of claim 1 or claim 3-5 when dependent on claim 1, or the apparatus of claim 2 or claim 3-5 when dependent on claim 2, wherein the ordered attribute information further comprises at least a third vector comprising an entry for each of a plurality of faces, each entry in the third vector being a Boolean value indicating whether an attribute of a respective current face is the same as an attribute value of a neighboring face from a second direction of the current face.

7. The method of claim 6 when dependent on claim 1, or the apparatus of claim 6 when dependent on claim 2, wherein the third vector comprises entries for only faces that do not have an attribute value determined by the first vector or the second vector. ​ 8. The method of claim 1 or any of claims 3-7 when dependent on claim 1, or the apparatus of claim 2 or any of claims 3-7 when dependent on claim 2, wherein the ordered attribute information further comprises at least a fourth vector, the fourth vector comprising an entry for each of the plurality of faces, each entry in the fourth vector being a Boolean value indicating whether the attribute of the respective current face is the same as the attribute value of the neighboring face from the third direction of the current face.

9. The method of claim 8 when dependent on claim 1, or the apparatus of claim 8 when dependent on claim 2, wherein the fourth vector comprises entries for only the faces that do not have an attribute value determined by the first vector, the second vector, or the third vector.

10. The method of claim 1 or any of claims 3-9 when dependent on claim 1, or the apparatus of claim 2 or any of claims 3-9 when dependent on claim 2, wherein the ordered attribute information further comprises at least a fifth vector, the fifth vector comprising an entry for each of the plurality of faces, each entry in the fourth vector comprising an attribute value of the respective current face.

11. The method of claim 10 when dependent on claim 1, or the apparatus of claim 10 when dependent on claim 2, wherein the fifth vector comprises entries for only the faces that do not have an attribute value determined by the first vector, the second vector, the third vector, or the fourth vector.

12. The method of any of claims 4-11 when dependent on claim 1, or the apparatus of any of claims 4-11 when dependent on claim 2, wherein the first direction is a right direction, the second direction is a left direction, and the third direction is a front direction.

13. The method of any of claims 4-12 when dependent on claim 1, or the apparatus of any of claims 4-12 when dependent on claim 2, further comprising: entropy decoding the first vector from the bitstream using a first context; and entropy decoding at least the second vector from the bitstream using a second context different from the first context.

14. The method of any of claims 10-13 when dependent on claim 1, or the apparatus of any of claims 10-13 when dependent on claim 2, further comprising: entropy decoding the first vector from the bitstream using a first context; entropy decoding at least the second vector from the bitstream using a second context different from the first context; and entropy decoding the fifth vector from the bitstream using a fifth context different from the first and second contexts.

15. The method of claim 1 or any of claims 3-14 when dependent on claim 1, or the apparatus of claim 2 or any of claims 3-14 when dependent on claim 2, wherein the attribute value of each face is an integer value.

16. The method of claim 1 or any of claims 3-15 when dependent on claim 1 or the apparatus of claim 2 or any of claims 3-15 when dependent on claim 2, wherein the attribute value of each face is a face ID value.

17. The method of claim 1 or any of claims 3-16 when dependent on claim 1 or the apparatus of claim 2 or any of claims 3-16 when dependent on claim 2, wherein the attribute value of each face identifies a color.

18. The method of claim 1 or any of claims 3-17 when dependent on claim 1 or the apparatus of claim 2 or any of claims 3-17 when dependent on claim 2, wherein the attribute value of each face identifies a material.

19. A mesh encoding method comprising: obtaining information describing a topology of a triangular mesh; obtaining information indicating, for each face in the triangular mesh, an attribute value of the respective face; encoding, in a bitstream, a CLERS table representing a broken-edge encoding of the topology; and encoding, in the bitstream, attribute information indicating, for each of the faces, the attribute value of the respective face.

20. A mesh encoding apparatus comprising one or more processors configured to perform at least the following: obtaining information describing a topology of a triangular mesh; obtaining information indicating, for each face in the triangular mesh, an attribute value of the respective face; encoding, in a bitstream, a CLERS table representing a broken-edge encoding of the topology; and encoding, in the bitstream, attribute information indicating, for each of the faces, the attribute value of the respective face.

21. The method of claim 19 or the apparatus of claim 20, wherein the ordered attribute information comprises at least a first vector comprising an entry for each of a plurality of faces, each entry in the first vector being a Boolean value indicating whether the attribute value of the respective current face is the same as the attribute value of a most recently encoded face.

22. The method of claim 19 or any of claims 21 when dependent on claim 19 or the apparatus of claim 20 or any of claims 21 when dependent on claim 20, wherein the ordered attribute information further comprises at least a second vector comprising an entry for each of a plurality of faces, each entry in the second vector being a Boolean value indicating whether the attribute of the respective current face is the same as the attribute value of a neighboring face from a first direction of the current face.

23. The method of claim 22 when dependent on claim 19 or the apparatus of claim 22 when dependent on claim 20, wherein the second vector comprises an entry for only a face that does not have an attribute value determined by the first vector.

24. The method of claim 19 or 21-23 when dependent on claim 19, or the apparatus of claim 20 or 21-23 when dependent on claim 20, wherein the ordered attribute information further comprises at least a third vector, the third vector comprising an entry for each of the plurality of faces, each entry in the third vector being a Boolean value indicating whether the attribute of the respective current face is the same as the attribute value of an adjacent face from a second direction of the current face.

25. The method of claim 24 when dependent on claim 19, or the apparatus of claim 24 when dependent on claim 20, wherein the third vector comprises an entry for only a face that does not have an attribute value determined by the first vector or the second vector.

26. The method of claim 19 or 21-25 when dependent on claim 19, or the apparatus of claim 20 or 21-25 when dependent on claim 20, wherein the ordered attribute information further comprises at least a fourth vector, the fourth vector comprising an entry for each of the plurality of faces, each entry in the fourth vector being a Boolean value indicating whether the attribute of the respective current face is the same as the attribute value of an adjacent face from a third direction of the current face.

27. The method of claim 26 when dependent on claim 19, or the apparatus of claim 26 when dependent on claim 20, wherein the fourth vector comprises an entry for only a face that does not have an attribute value determined by the first vector, the second vector, or the third vector.

28. The method of claim 19 or 21-27 when dependent on claim 19, or the apparatus of claim 20 or 21-27 when dependent on claim 20, wherein the ordered attribute information further comprises at least a fifth vector, the fifth vector comprising an entry for each of the plurality of faces, each entry in the fourth vector comprising an attribute value of the respective current face.

29. The method of claim 28 when dependent on claim 19, or the apparatus of claim 28 when dependent on claim 20, wherein the fifth vector comprises an entry for only a face that does not have an attribute value determined by the first vector, the second vector, the third vector, or the fourth vector.

30. The method of any one of claims 22-29 when dependent on claim 19, or the apparatus of any one of claims 22-29 when dependent on claim 20, wherein the first direction is a right direction, the second direction is a left direction, and the third direction is a forward direction.

31. The method of any one of claims 22-30 when dependent on claim 19, or the apparatus of any one of claims 22-30 when dependent on claim 20, further comprising: entropy encoding the first vector from the bitstream using a first context; and entropy encode a first vector from the bitstream using a first context; 32. The method of any one of claims 28-30 when dependent on claim 19 or the apparatus of any one of claims 28-30 when dependent on claim 20, further comprising: entropy encode a first vector from the bitstream using a first context; entropy encode at least a second vector from the bitstream using at least a second context different from the first context; and entropy encode a fifth vector from the bitstream using a fifth context different from the first and second contexts.

33. The method of claim 19 or claim 21-32 when dependent on claim 19 or the apparatus of claim 20 or claim 21-32 when dependent on claim 20, wherein the attribute value of each face is an integer value.

34. The method of claim 19 or claim 21-33 when dependent on claim 19 or the apparatus of claim 20 or claim 21-33 when dependent on claim 20, wherein the attribute value of each face is a face ID value.

35. The method of claim 19 or claim 21-34 when dependent on claim 19 or the apparatus of claim 20 or claim 21-34 when dependent on claim 20, wherein the attribute value of each face identifies a color.

36. The method of claim 19 or claim 21-35 when dependent on claim 19 or the apparatus of claim 20 or claim 21-35 when dependent on claim 20, wherein the attribute value of each face identifies a material.

37. A mesh decoding method comprising: obtaining attribute information from a bitstream, the attribute information representing a predicted residual of an attribute of a vertex of a triangular mesh; and entropy decoding the attribute residual, wherein for at least one attribute of at least one vertex, the entropy decoding comprises: decoding a first bit indicating whether the residual is zero; decoding a second bit indicating a sign of the residual; decoding a sequence of bits, wherein an absolute value of the residual is determined based at least in part on a length of the sequence; and reconstructing the attribute of the vertex based at least in part on the determined residual.

38. A mesh decoding apparatus comprising one or more processors configured to at least perform the following: obtaining attribute information from the bitstream, the attribute information representing a prediction residual of an attribute of a vertex of the triangular mesh; and entropy decoding the attribute residual, wherein for at least one attribute of at least one vertex, the entropy decoding comprises: decoding a first bit indicating whether the residual is zero; decoding a second bit indicating a sign of the residual; decoding a sequence of bits, wherein an absolute value of the residual is determined based at least in part on a length of the sequence; and reconstructing the attribute of the vertex based at least in part on the determined residual.

39. The method of claim 37 or the apparatus of claim 38, wherein the sequence of bits ends in a predetermined stop bit and the absolute value of the residual is determined as the length of the sequence.

40. The method of claim 37 or claim 39 when dependent on claim 37 or the apparatus of claim 38 or claim 39 when dependent on claim 38, wherein for the at least one attribute, the entropy decoding further comprises decoding a codeword using exponential Golomb coding, wherein the absolute value of the residual value is determined based at least in part on the codeword.

41. The method of claim 40 when dependent on claim 37 or the apparatus of claim 40 when dependent on claim 38, wherein the codeword is decoded in response to determining that the bit sequence has a predetermined maximum length and does not end in a predetermined stop bit.

42. The method of claim 40 or 41 when dependent on claim 37 or the apparatus of claim 40 or 41 when dependent on claim 38, wherein the absolute value of the residual is determined as a sum of a value represented by the codeword and an offset value.

43. The method of claim 37 or claim 39-42 when dependent on claim 37 or the apparatus of claim 38 or claim 39-42 when dependent on claim 38, further comprising obtaining a prediction of an attribute of a vertex, wherein reconstructing the attribute comprises adding the determined residual value to the prediction of the attribute.

44. The method of claim 37 or claim 39-43 when dependent on claim 37 or the apparatus of claim 38 or claim 39-43 when dependent on claim 38, wherein the attribute comprises at least one position coordinate or at least one UV coordinate.

45. A method of mesh coding, comprising: obtaining attribute information representing a predicted residual of an attribute of a vertex of a triangular mesh; and entropy encoding the attribute residual in a bitstream, wherein for at least one attribute of at least one vertex, the entropy encoding comprises: encoding a first bit indicating whether the residual is zero; encoding a second bit indicating a sign of the residual; and encoding a bit sequence, wherein an absolute value of the residual is determined based at least in part on a length of the sequence.

46. An apparatus of mesh coding, comprising one or more processors configured to at least perform the following: obtaining attribute information representing a predicted residual of an attribute of a vertex of a triangular mesh; and obtaining attribute information, the attribute information representing a prediction residual of an attribute of a vertex of the triangular mesh; entropy encoding the attribute residual in a bitstream, wherein for at least one attribute of at least one vertex, the entropy encoding comprises: encoding a first bit indicating whether the residual is zero; encoding a second bit indicating a sign of the residual; and encoding a bit sequence, wherein an absolute value of the residual is determined based at least in part on a length of the sequence.

47. The method of claim 45 or the apparatus of claim 46, wherein the bit sequence ends in a predetermined stop bit and the absolute value of the residual is determined as the length of the sequence. ​ 48. The method of claim 45 or claim 47 when dependent on claim 45 or the apparatus of claim 46 or claim 47 when dependent on claim 46, wherein for the at least one attribute, the entropy encoding further comprises encoding a codeword using exponential Golomb encoding, wherein the codeword is determined based at least in part on the codeword.

49. The method of claim 48 when dependent on claim 45 or the apparatus of claim 48 when dependent on claim 46, wherein the codeword is encoded in response to determining that the bit sequence has a predetermined maximum length and does not end in a predetermined stop bit.

50. The method of claim 48 or 49 when dependent on claim 45 or the apparatus of claim 48 or 49 when dependent on claim 46, wherein a value represented by the codeword is determined based on a difference between an absolute value of a residual and a bias value.

51. The method of claim 45 or claim 47-50 when dependent on claim 45 or the apparatus of claim 46 or claim 47-50 when dependent on claim 46, further comprising obtaining a prediction of an attribute of a vertex, wherein the residual value is determined as a difference between the attribute and the prediction of the attribute.

52. The method of claim 45 or claim 47-51 when dependent on claim 45 or the apparatus of claim 46 or claim 47-51 when dependent on claim 46, wherein the attribute comprises at least one position coordinate or at least one UV coordinate.

53. A trellis decoding method comprising: obtaining a bitstream comprising an entropy encoded CLERS table representing connectivity of a connected component of a mesh; entropy decoding a bit sequence from the CLERS table, the bit sequence representing a sequence of symbols comprising at least one most recently decoded symbol; and entropy decoding a current bit from the CLERS table, wherein the current bit is decoded using a context determined based at least in part on the at least one most recently decoded symbol.

54. A trellis decoding apparatus comprising one or more processors configured to at least perform the following: obtaining a bitstream comprising an entropy encoded CLERS table representing connectivity of a connected component of a mesh; entropy decoding a bit sequence from the CLERS table, the bit sequence representing a sequence of symbols comprising at least one most recently decoded symbol; and entropy decoding a current bit from the CLERS table, wherein the current bit is decoded using a context determined based at least in part on the at least one most recently decoded symbol.

55. The method of claim 53 or the apparatus of claim 54, wherein the context is further based at least in part on a most recently decoded bit in the bit sequence.

56. The method of claim 53 or the apparatus of claim 54, wherein the context is further based on two most recently decoded bits in the bit sequence.

57. The method of claim 53 or the apparatus of claim 54, wherein a number of contexts used to decode bits of the CLERS table is determined based on a number of symbols in the CLERS table.

58. The method of claim 57 when dependent on claim 53 or the apparatus of claim 57 when dependent on claim 54, wherein the number of contexts is determined based on whether the number of symbols in the CLERS table is greater than a threshold, a first number of contexts is used when the number of symbols is less than the threshold, and a second number of contexts is used when the number of symbols is greater than the threshold, the second number being greater than the first number.

59. A trellis encoding method comprising: obtaining a CLERS table representing connectivity of a connected component of a trellis; entropy encoding a sequence of bits from the CLERS table, the sequence of bits representing a sequence of symbols including at least one most recently encoded symbol; and entropy encoding a current bit in the CLERS table, wherein the current bit is encoded using a context determined based at least in part on the at least one most recently encoded symbol.

60. A trellis encoding apparatus comprising one or more processors configured to perform at least the following: obtaining a CLERS table representing connectivity of a connected component of a trellis; entropy encoding a sequence of bits from the CLERS table, the sequence of bits representing a sequence of symbols including at least one most recently encoded symbol; and entropy encoding a current bit in the CLERS table, wherein the current bit is encoded using a context determined based at least in part on the at least one most recently encoded symbol.

61. The method of claim 59 or the apparatus of claim 60, wherein the context is further based at least in part on a most recently encoded bit in the sequence of bits.

62. The method of claim 59 or the apparatus of claim 60, wherein the context is further based on two most recently encoded bits in the sequence of bits.

63. The method of claim 59 or the apparatus of claim 60, wherein a number of contexts used to decode bits of the CLERS table is determined based on a number of symbols in the CLERS table.

64. The method of claim 63 when dependent on claim 59 or the apparatus of claim 63 when dependent on claim 60, wherein the number of contexts is determined based on whether the number of symbols in the CLERS table is greater than a threshold, a first number of contexts is used when the number of symbols is less than the threshold, and a second number of contexts is used when the number of symbols is greater than the threshold, the second number being greater than the first number.

Images