GB2552510A - Mesh partitioning and merging methods - Google Patents
Mesh partitioning and merging methods Download PDFInfo
- Publication number
- GB2552510A GB2552510A GB1612934.8A GB201612934A GB2552510A GB 2552510 A GB2552510 A GB 2552510A GB 201612934 A GB201612934 A GB 201612934A GB 2552510 A GB2552510 A GB 2552510A
- Authority
- GB
- United Kingdom
- Prior art keywords
- vertices
- partition
- partitioning
- file
- mesh
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000638 solvent extraction Methods 0.000 title claims abstract description 186
- 238000000034 method Methods 0.000 title claims abstract description 93
- 238000005192 partition Methods 0.000 claims abstract description 314
- 230000006837 decompression Effects 0.000 claims abstract description 15
- 230000006835 compression Effects 0.000 abstract description 31
- 238000007906 compression Methods 0.000 abstract description 31
- 102100029325 ATP-dependent DNA helicase PIF1 Human genes 0.000 description 6
- 101001125884 Autographa californica nuclear polyhedrosis virus Per os infectivity factor 1 Proteins 0.000 description 6
- 101001125842 Homo sapiens ATP-dependent DNA helicase PIF1 Proteins 0.000 description 6
- 238000004891 communication Methods 0.000 description 6
- 238000012545 processing Methods 0.000 description 6
- 238000013139 quantization Methods 0.000 description 5
- 239000007787 solid Substances 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 239000003086 colorant Substances 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012805 post-processing Methods 0.000 description 2
- 238000007781 pre-processing Methods 0.000 description 2
- 238000010146 3D printing Methods 0.000 description 1
- 101001125878 Autographa californica nuclear polyhedrosis virus Per os infectivity factor 2 Proteins 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000003116 impacting effect Effects 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T17/00—Three dimensional [3D] modelling, e.g. data description of 3D objects
- G06T17/20—Finite element generation, e.g. wire-frame surface description, tesselation
- G06T17/205—Re-meshing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T19/00—Manipulating 3D models or images for computer graphics
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T9/00—Image coding
- G06T9/001—Model-based coding, e.g. wire frame
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer Graphics (AREA)
- Software Systems (AREA)
- Multimedia (AREA)
- Geometry (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Image Generation (AREA)
Abstract
A mesh data file (300), comprising vertices (V0-V19) and faces (F1-F26) describing an object (e.g. 3D object or scene) for encoding is partitioned (e.g. by line 303) into at least a first (301) and second (302) adjacent partition data files. The first comprises a first sub-set of vertices and faces not affected by the partitioning (302 in fig. 3B) and a second sub-set of vertices (305-1 in fig. 3B) duplicated with the second partition. The second file comprises a third sub-set of vertices and faces not affected by the partitioning (309 in fig. 3C), and a fourth sub-set of vertices redundant with the first partition (305-2 in fig. 3C). Splitting extremely large meshes into such smaller meshes reduces the memory required for mesh compression/decompression. The duplication of vertices affected by the partitioning avoids the need to process for missing connectivities, and allows each partition to be compressed and decompressed individually. Removal of duplicated vertices when merging is optional as the amount of such redundant vertices is negligible with respect to the total number of vertices. Partitioning and encoding may be performed by an encoder (fig. 4), while decompression and merging may be performed by a decoder (fig. 5).
Description
(71) Applicant(s):
Canon Kabushiki Kaisha
30-2 Shimomaruko 3-chome, Ohta-ku,
Tokyo 1468501, Japan (72) Inventor(s):
Patrice Onno Guillaume Laroche Christophe Gisquet (74) Agent and/or Address for Service:
Santarelli
49, avenue des Champs-Elysees, Paris 75008,
France (including Overseas Departments and Territori es) (51) INT CL:
G06T17/20 (2006.01) G06T19/00 (2011.01) (56) Documents Cited:
Zhang Z. et al., Automatic Segmentation Technique for Triangular Meshes, 2011, Transactions of the Japan Society for Computational Engineering and Science, pages 1-7 (58) Field of Search:
INT CL G06T
Other: Online: WPI, EPODOC, Inspec (54) Title of the Invention: Mesh partitioning and merging methods Abstract Title: Mesh Partitioning and Merging Methods (57) A mesh data file (300), comprising vertices (V0-V19) and faces (F1-F26) describing an object (e.g. 3D object or scene) for encoding is partitioned (e.g. by line 303) into at least a first (301) and second (302) adjacent partition data files. The first comprises a first sub-set of vertices and faces not affected by the partitioning (302 in fig. 3B) and a second sub-set of vertices (305-1 in fig. 3B) duplicated with the second partition. The second file comprises a third sub-set of vertices and faces not affected by the partitioning (309 in fig. 3C), and a fourth sub-set of vertices redundant with the first partition (305-2 in fig. 3C). Splitting extremely large meshes into such smaller meshes reduces the memory required for mesh compression/decompression. The duplication of vertices affected by the partitioning avoids the need to process for missing connectivities, and allows each partition to be compressed and decompressed individually. Removal of duplicated vertices when merging is optional as the amount of such redundant vertices is negligible with respect to the total number of vertices. Partitioning and encoding may be performed by an encoder (fig. 4), while decompression and merging may be performed by a decoder (fig. 5).
1/18
Fig. 1
2/18
ο co ο
ΕΟ
CO
Ο
ΙΌ
Ο ο
co ο
<Ν ο
Fig. 2Α
3/18
LU
| ,—. | 44—44 | ,—. | CO | 03 | O | X— | ||||||||||||||
| z-—s | 4—4 | 4—4 | ^r | 4—4 | co | E- | t— | CN | CN | |||||||||||
| T— | CO | 4—4 | CN | CO | T— | Lf) | X— | T— | LL | LL | LL | LL | ||||||||
| LL, | Z—-s | ,—v | ,—v | Z—s | Z—s | E- | LL | Z—s | o | — | — | — | LL | — | LL | LL | ' | |||
| c ' | CN | co | xT | Lf3 | CD | LL | CD | y— | y— | LL | LL | — | LL | -—' | — | Lf3 | CO | |||
| LL^ | LL^ | LL^ | LL^ | LL^ | LL^ | LL^ | LL | CO | o | |||||||||||
| A | CN | CO | ρ- | Lf3 | O | o | CD | 03 | E- | E- O | CN | CN | 03 CO | co | ^r | ^r | E- | CO | LO | |
| co | CO | CO | co | ω | E- | E- | 1— | CO | CO | 03 | 5— | O | 1— | i— | *— | 1— | o | o | CN | CN |
| o | 5- | CN | co | Lf3 | Lf) | 5- | CD | CD | 03 | CO | co | CO | CD | 03 | ||||||
| ,co | co | CO | co | co | co | CO | CO | co | CO | CO | CO | CO | co | co | CO | CO | co | CO | CO | CO |
ω
Φ o
TO c
x'
Φ
-t—»
Φ >
o
CN
| O | X | X >4 N | |
| Φ | Μ—» -t—» -t—» | ||
| -c | 05 05 05 | ||
| o | Φ | O O O | |
| ω | > | 4—4—4— | |
| co | -t—» | ||
| -t—» | C | t t t | |
| CO | CD | φ φ Φ | |
| E | CL CL CL | ||
| CD | O O O i_ i_ i_ | ||
| CL | LJ M— | CD | CL CL CL |
CO
CN
Φ
O
Φ
4— -t—» c
Φ
E φ
φ _C
O =3
4—» ω
Φ
CL
O
| 44—4. | 44—44 | 44—44 | 44—44 | 44—44 | 44—44 | 44—44 | O | ,_. | CO | ^r | |||||
| CD | 4—4 | 4—4 | CN | co | LO | co | r-- | 00 | CD | t— | X— | CN | t— | T— | |
| D | o | 1— | > | > | > | > | > | > | > | > | > | > | > | > | |
| CO | > | > | > | ||||||||||||
| CD | o | o | o | o | o | o | o | o | o | o | o | o | |||
| _C I | o | o | CN | o | sf | o | ^r | o | CD | CN | co | 03 | O | E- | |
| 1 ”7T | co | CN | Lf) | CD | if) | Lf) | ^r | ^r | CO | CO | co | CN | CN | CN | CN |
| c | CN | ^r | ^r | Lf) | CO | o | E- | ^r | E- | CD | CD | O | CN | CO | o |
| CD | CN | E- | T— | CN | sf | CD | CN | T— | CO | Lf) | E- | 03 | CN | Lf) |
18 0(V15) 3 13 15 16(F22)
16 0(V16) 3 13 16 14(F23)
19 0(V17) 3 15 18 19(F24)
10 0(V18) 3 15 19 16(F25)
3 0(V19) I 3 14 16 17 (F26)
X m
CM
CD
4/18 o
co
300 ο
co co o
co
CM o
co
Fig. 3A
5/18
LL ο
oo ο
EO
CO o
CO
O
O
CN
6/18
301 χ
ο co ο
rο co ο
ιό ο
ο co ο
<Ν ο
Fig. 3C
7/18
LL ο
co ο
ro co o
CO
O ^r o
co o
CM
8/18
PIF1
01: redundancy location: top 02: bounding box: 2:70 ; 3:60 ; 0:0 03: data: raw
04: partitioning type: 2Y 05: Y, 3, 29, 10, 3, 29, FF1 06: Y, 32, 60, 10, 19, 60, FF2
FF1 ply format ascii 1.0 element vertex 10 property float x property float y property float z element face 7 property list uchar int vertex_indices end header
28 0 (V0)
29 0(V11)
22 0(V12)
27 0 (V13)
24 0 (V14)
18 0(V15)
16 0(V16)
19 0(V17)
10 0(V18)
3 0(V19)
12 18 15(F20) 3 12 15 13(F21) 3 13 15 16(F22) 3 13 16 14(F23) 3 15 18 19(F24) 3 15 19 16(F25) 3 14 16 17 (F26)
Fig. 3E
FF2 ply format ascii 1.0 element vertex 16 property float x property float y property float z element face 19 property list uchar int vertex_indices end header
28 0 (V0)
42 0 (V1)
52 0(V2)
60 0 (V3)
54 0 (V4)
50 0 (V5)
44 0 (V6)
40 0 (V7)
36 0 (V8)
32 0 (V9)
33 0(V10)
29 0 (V11)
22 0(V12)
27 0(V13)
24 0 (V14)
19 0(V17)
1 0 8 (F1)
2 16 (F2)
3 2 6 (F3)
4 3 6 (F4)
4 6 7 (F5)
4 7 5 (F6)
357 10 (F7)
5 10 11 (F8)
6 18 (F9)
8 9(F10) 3679(F11)
9 10(F12) 380 12 (F13)
8 12 13(F14) 398 13(F15)
9 13 14(F16)
9 14 10 (F17)
10 14 17 (F18) 3 10 11 17(F19)
9/18
400
403-N 417
10/18 co m
D ω
-t—' o
E -c
-£3 CZ) CZ) Φ o
Φ or
T w
ω
co o
in m
0)
Ll
502-N
11/18
ο ο
υό)
ο ο
CD
CD
0)
Ll
12/18 co ο
co ο
co ο
r-
Fig. 8A
13/18 x
Fig. 8B
14/18 x
LL
15/18 x
Fig. 8D
16/18
co
CZ)
Φ o
TO £=
CZ)
Φ o
TO £=
| 03 | |||||||||||||
| O | X | X | N | _c o | CO CN | ||||||||
| — | Φ -£ | -t—» 03 | -t—» 03 | -t—» 03 | Φ | =3 | 77 | S' | rZ | LL | |||
| o co | Φ > | O M— | O M— | O M— | O 03 M— | ω | <D Ό | > | > | > | > | r- | |
| 03 | CO | co | |||||||||||
| I ‘ | £= | -e | -e | -e | £= | -e | CD | 0 | O | 0 | 0 | ||
| 03 | Φ | φ | φ | φ | Φ | φ | _C I | CD | co | 0 | — | ||
| E | CL | CL | CL | E | CL | 1 | CN | CN | |||||
| z-\ | φ | O | O | O | φ | o | GJ c | O | 0 | 0 | CN | ||
| CL | GJ M— | φ | CL | CL | CL | φ | CL | CD | E- | Lf) | CO | co |
CQ σ>
0)
Ll format ascii 1.0 element vertex 8 x >Μ—' Μ—'
03 Ο Ο
Μ— Μ— φ φ CL CL Ο Ο
L. L.
CL CL
| 03 | ,_. | ,_. | ,_. | ,_. | ,_. | ,_. | |||||||||||
| N | CO | _c | O | T— | CN | co | Lf) | ||||||||||
| 0 | CN | CN | CN | CN | CN | CN | |||||||||||
| -I—» co | Φ | =3 | S' | s | S' | S' | LL | LL | LL | LL | LL | LL | |||||
| Γ) | O | ω | CD Ό | CN | T“ | Oi | IO | O | CO | O) | co | ||||||
| G/ L^_ | 03 | 0 | > | > | > | > | > | 'ί | |||||||||
| * 1 | >, | CO | > | > | > | — | — | — | — | — | — | ||||||
| -1—' | £= | CD | 0 | 0 | 0 | 0 | 0 | CO | IO | 10 | CO | co | O) | ||||
| Φ | Φ | Φ | _C 1 | 0 | O | E- | CO | co | 0 | 0 | — | — | — | — | — | — | |
| CL | E | CL | 1 | co | CN | CN | CN | Τ- | X— | co | CN | CN | 0 | 0 | 10 | 10 | |
| O | φ | O | GJ c | CN | CN | CO | 0 | Ο | 0 | CN | — | — | — | — | — | — | |
| CL | φ | CL | CD | CN | CD | CN | Lf) | CN | CO | CO | CO | co | co | co | co |
Ε
Ο ο
Ο Ο _Ω . — CO
CN
LL
0_ £=
Ο
Μ—»
Ο
Ο
Ο
Ε<Si
X ο
X
CN >“
CN
Ο £=
ΤΟ £= =3
ΤΟ
Φ
CD C
ΤΟ £= =3 Ο 03 -Ω ΤΟ .5= 03
Ο) φ
Μ—»
CD Ο C — ο
.2 CN
Μ—» '£ co 03 . _ Ο- >^r υ_ CO LL LL
LL O
- EO Lf) O
CN CO . o CN ECO . O CN
X X co LL Lf) Ll LL _ ll o . Eo . Lf) CO - co CN . . CO o oo co - o . 00 N CD CN V- . CO . CN CO O - -XX o
co
CN
CO <
σ>
0)
Ll
5-CNco^-iOcor^cocno
OOOOOOOOO-503
17/18
ply FF5 format ascii 1.0 element vertex 12 property float x property float y property float z element face 12 property list uchar int vertex_indices end header
28 0 (VO)
42 0 (V1)
52 0(V2)
60 0 (V3)
54 0 (V4)
44 0 (V6)
40 0 (V7)
36 0(V8)
32 0 (V9)
22 0(V12)
27 0(V13) 50 24 0(V14)
08 1 (F1)
16 2 (F2)
2 6 3 (F3)
3 6 4 (F4)
4 6 7 (F5)
18 6 (F9)
68 9(F10) 3697(F11)
80 12(F13)
81213(F14) 3 8 13 9(F15)
9 13 14(F16)
Fig. 9C ply format ascii 1.0 element vertex 8 property float x property float y property float z element face 7
FF6 property list uchar int vertex_indices end_header
54 0 (V4)
50 0 (V5)
40 0 (V7)
32 0 (V9)
33 0 (V10)
29 0(V11)
24 0 (V14)
19 0(V17)
4 7 5 (F6)
357 10(F7)
5 10 11 (F8)
9 10 7(F12)
9 14 10(F17)
10 14 17 (F18)
10 17 11 (F19)
18/18 y
or o
| m | co | r^- | 00 |
| o | o | o | o |
| o | o | o | o |
| Τ- | CM | CO | |
| Ο | O | O | o |
| o | O | o | o |
MESH PARTITIONING AND MERGING METHODS
FIELD OF THE INVENTION
The present invention relates to methods of partitioning an object data file into a plurality of data files, encoding the plurality of data files, decoding the plurality of data files, and merging the plurality of data files to obtain an object data file.
BACKGROUND OF THE INVENTION
Figure 1 shows a three-dimensional 3D mesh M, used to represent a threedimensional object or scene, such as for video games, animated videos, threedimensional printing, and so forth. The mesh M comprises a plurality of vertices V, edges E, and faces F. The edges E connect two vertices V, and the faces F are polygons formed between three or more vertices V, comprising three or more edges E. In general, the faces F are in the form of triangles, but higher-level polygons such as quadrilaterals may also be present. The edges E and faces F represent the relationship between vertices V, also called connectivity or connection information, while the positions of the vertices V in space are called geometry. A mesh M may also contain isolated vertices IV, as well as other data such as vertex normals, face normals, vertex colors, face colors, face texture, and so forth.
The mesh M may therefore comprise a large amount of data, in particular as the numbers of vertices V and faces F increase, in order to more finely represent the object. The data may need to be partitioned into smaller files and/or be compressed due to memory constraints, as some meshes are too large to fit into the memory of small computers or handheld devices.
A first technique, as proposed by Ho et al. in the paper “Compressing large polygon models”, partitions a mesh of an object into several partitions, each of which is then individually compressed by means of an “in-core process” implementing the Edgebreaker compression algorithm, developed by Rossignac. Each compressed partition is thus independent of the others. The connectivity is compressed and then additional symbols are generated so that the missing parts (corresponding to loss of connectivity between vertices after partitioning) may be “stitched” together during the compression and the decompression processes. The missing connectivity information is thus appended as additional information so that the connections between two adjacent meshes may be recovered to reconstruct the full object at the decoder side.
Out-of-core schemes were designed to compress large meshes by dynamically loading and unloading different portions of the mesh depending on the currently processed region of the mesh.
A second technique, as proposed by Isenburg et al. in the paper “Out-of-core compression for gigantic polygon meshes”, uses an out-of-core mesh data structure, built on a segmentation of an input mesh, for the compression of large polygon meshes. Clusters of individual partitions are compressed together with a streaming approach and are fully dependent on each other.
It may therefore be desired to allow very large meshes to be compressed without having to load the entire mesh into the memory, which is particularly useful when the compression is performed on a device having a limited amount of memory.
SUMMARY OF THE INVENTION
The present invention has been devised to address at least one of the foregoing concerns, in particular to allow the compression of very large meshes without having to load the entire mesh into the memory.
Embodiments of the invention relate to a method of partitioning a mesh data file into a set of at least two adjacent partition data files, the mesh data file describing an object for encoding and comprising a plurality of vertices and any faces comprising the vertices, the method comprising the steps of:
- partitioning the mesh data file so as to create at least a first partition and a second partition, the two partitions being adjacent to one another, and
- generating at least a first partition data file and a second partition data file, the first partition data file comprising:
- a first sub-set of vertices belonging only to the first partition, not affected by the partitioning, and faces comprising the first sub-set of vertices, and
- a second sub-set of vertices duplicated with the second partition, affected by the partitioning, and faces comprising the second sub-set of vertices; and the second partition data file comprising:
- a third sub-set of vertices belonging only to the second partition, not affected by the partitioning, and faces comprising the third sub-set of vertices, and
- a fourth sub-set of vertices redundant with the first partition, affected by the partitioning;
wherein a duplicate vertex is one that is connected to an edge between two vertices that is affected by the partitioning and is situated on the opposite side of the partitioning as the other vertices of the partition data file, and wherein a redundant vertex is one that is one that is connected to an edge between two vertices that is affected by the partitioning and is situated on the same side of the partitioning as the other vertices of the partition data file.
Such a method of partitioning a mesh allows smaller, independent submeshes to be created for processing, requiring less memory space and computing power.
According to one embodiment, the step of generating a partition data file further comprises creating a file format representation of the partition.
According to one embodiment, the file format representation of the partition comprises at least one of:
- a number of vertices comprised within the partition, the number of vertices comprising the vertices not affected by the partitioning and the duplicate vertices if any;
- vertex properties, comprising at least the location of each vertex;
- a number of faces; and
- face properties, wherein a face comprises vertices of the file format representation.
Such a file format representation may be exploited to help determine the number of duplicate vertices for easier removal later.
According to one embodiment, the method further comprises a step of creating a partitioning information file describing the file format representations of the set of adjacent partition data files, the partitioning information file comprising at least one of:
- an indication of the partition comprising the duplicate vertices;
- a number of partitions;
- a location of the partitions; and
- characteristics of each partition.
Such a partitioning information file may be used to more easily located duplicate vertices, as well as aid in the merging of the partitions at a later time.
According to one embodiment, the characteristics of each partition comprise at least one of:
- coordinates of a distinct bounding box comprising all vertices within the partition;
- a number of vertices within the partition;
- coordinates of a complete bounding box comprising all vertices within the partition and any duplicate vertices; and
- an associated file format representation of the partition.
According to one embodiment, a comparison of the coordinates of the distinct bounding box and the complete bounding box indicate an overlapping region comprising any duplicate vertices.
Such a comparison facilitates the process of removing duplicate vertices at a later time.
According to one embodiment, a comparison of the number of vertices within the partition indicated by the partitioning information file and the number of vertices within the partition indicated by the file format representation of the partition indicate the number of duplicate vertices.
Such a comparison facilitates the process of removing duplicate vertices at a later time.
According to one embodiment, the partitioning step is performed according to partitioning parameters indicating at least one of:
- the axis along which the partitioning is to be performed;
- the order of partitioning along a plurality of axes; and
- the number of partitions to be obtained.
The various possibilities for partitioning a mesh provide adaptability of the method.
According to one embodiment, the partitioning parameters further indicate the type of partitioning to be performed, the type of partitioning comprising at least one of:
- partitioning the mesh data file with respect to spatial criteria;
- partitioning the mesh data file so that a partition contains a given number of vertices;
- partitioning the mesh data file so that the partitions comprise equal or substantially equal numbers of vertices; or
- partitioning the mesh data file so that a minimum number of edges between vertices are transected.
The various possibilities for the type of partitioning allow the mesh to be partitioned according to specific needs.
According to one embodiment, the partitioning step further comprises the steps of:
- determining a mesh bounding box by determining the minimum and maximum coordinate values of the vertices;
- cutting connections between adjacent partitions;
- identifying connections between adjacent partitions and the vertices associated with the identified connections; and
- adding the identified connections to one of the partition data files.
According to one embodiment, the method further comprises, after determining the mesh bounding box, a step of computing the density of vertices along each concerned axis of the mesh when the partitioning should respect a given number of vertices per partition.
According to one embodiment, the step of cutting connections comprises a step of partitioning the mesh data file into a plurality of intermediate mesh files, without considering faces formed between affected vertices, by performing the steps of:
- distributing the vertices with respect to the partitioning,
- dividing the vertices of the original object into two distinct groups,
- renumbering the vertices as necessary, and
- adjusting the face properties accordingly.
Embodiments of the invention also relate to a method of encoding a mesh data file, the method comprising the steps of:
- receiving a mesh data file to be partitioned on input,
- receiving partition parameters on input,
- partitioning the mesh data file into at least a first partition data file and a second partition data file according to an embodiment of the invention,
- encoding each partition data file as a coded partition, and
- supplying on output at least one output file comprising the coded partitions.
The partitions may thus be encoded individually, requiring less memory space and computing power.
According to one embodiment, the partitioning step further comprises a step of creating a file format representation of the partition.
According to one embodiment, the method further comprises a step of supplying on output a partitioning information file describing the file format representations of the set of adjacent partitions.
Embodiments of the invention also relate to a method of merging a set of at least two adjacent partition data files into a mesh data file, the adjacent partitions having been partitioned according to an embodiment of the invention, the method comprising the steps of:
- receiving the set of at least a first partition data file and a second partition data file on input;
- merging the partitions; and
- supplying on output a reconstructed mesh data file.
According to one embodiment, the method further comprises a step of receiving a partitioning information file supplied by the encoding method, and wherein the step of merging the partitions is performed based on information comprised in the partitioning information file.
According to one embodiment, the method further comprises a step of removing any duplicate vertices from the mesh data file.
The removal of duplicate vertices reduces the memory needed to store the mesh.
According to one embodiment, the step of removing any duplicate vertices comprises the steps of:
- modifying the number of vertices in a header information according to a vertex number indicated in the partitioning information file; and
- removing the duplicate vertices, the number of which corresponds to the difference between the sum of vertices of the set of partition data files and the number of vertices in the partitioning information file.
According to one embodiment, the step of removing the duplicate vertices comprises a step of sorting all the vertices of the mesh data file in a given order and then eliminating duplicate vertices.
According to one embodiment, the step of removing the duplicate vertices comprises using an overlapping region information provided by the partitioning information file, which provides information about the location of the duplicate vertices.
According to one embodiment, the method further comprises the steps of:
- identifying the type of partitioning, so that the order of merging of the files may be determined;
- identifying the adjacent partitions for the reconstruction of the mesh data file;
- receiving the adjacent partitions; and
- merging the adjacent partitions into a single file,
According to one embodiment, the step of merging the adjacent partitions into a single file comprises the steps of:
- updating a header information concerning the number of vertices and connections;
- merging vertex information of the partitions;
- renumbering the vertices as needed;
- merging face properties of the partitions; and
- adjusting the face properties as needed, based on the renumbered vertices.
Embodiments of the invention also relate to a method of decoding a mesh data file encoded according to an embodiment of the invention, comprising the steps of:
- receiving an output file from an encoder comprising coded partitions;
- decoding the coded partitions to obtain a set of adjacent partition data files; and
- merging the set of adjacent partition data files according to an embodiment of the invention.
According to one embodiment, the receiving step further comprises dividing the file into coded partitions.
According to one embodiment, the decoding step further comprises decoding the coded partitions according to decompression parameters determined by a partitioning information file supplied to the decoder.
Embodiments of the invention also relate to an encoder configured to implement the steps of the method according to an embodiment of the invention.
Embodiments of the invention also relate to a decoder configured to implement the steps of the method according to an embodiment of the invention.
Embodiments of the invention also relate to a non-transitory computer readable medium storing a program which when executed by a microprocessor or computer system in a device cause the device to perform the method according to an embodiment of the invention.
BRIEF DESCRIPTION OF THE DRAWINGS
Other particularities and advantages of the invention will also emerge from the following description, illustrated by the accompanying drawings, in which:
- Figure 1, previously described, shows a three-dimensional 3D mesh comprising vertices, edges, and faces;
- Figures 2 (2A, 2B) show a simplified mesh and its accompanying file format representation;
- Figures 3 (3A, 3B, 3C, 3D, 3E) show the mesh of Figure 2A after partitioning along one axis into two partitions, and a partitioning information file and the accompanying partition files, according to one embodiment;
- Figure 4 schematically shows the partitioning of a mesh into several partitions and the compression of the partitions by means of an encoder according to one embodiment;
- Figure 5 schematically shows the decompression of the partitions and the merging of the partitions into a mesh by means of a decoder according to one embodiment;
- Figure 6 is a flowchart of a mesh partitioning method performed by an encoder according to one embodiment,
- Figure 7 is a flowchart of a mesh merge method performed by a decoder according to one embodiment,
- Figures 8 (8A, 8B, 8C, 8D) show the mesh of Figure 2A after partitioning along two axes into four partitions according to one embodiment;
- Figures 9 (9A, 9B, 9C) show the partitioning information file and the file format representations of the four partitions of the Figures 8; and
- Figure 10 schematically illustrates a device configured to implement at least one embodiment of the present invention.
DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION
Embodiments of the invention relate in general to “splitting” or “partitioning” large meshes into smaller meshes, reducing the amount of memory necessary for compression and decompression of the mesh. It particular applies to three-dimensional 3D objects, but may also be applied to two-dimensional 2D objects, an object being represented by a mesh.
In contrast with the first technique described above (Ho et al.), the present invention introduces a redundancy at the geometry level, by duplicating some vertices affected by the partitioning so as to avoid having to implement a particular processing for the missing connectivity as in the first technique, and allowing each partition to be compressed and decompressed individually, in contrast with the second technique.
It may be noted that the majority of the memory space used for compression is used to store the mesh itself. For example, in SC3DMC “Scalable Complexity 3D Mesh Coding” (one of the most state-of-the-art 3D mesh compressors), the memory used by the encoder is directly proportional to the number of vertices of the mesh. More than 18
GB of memory may be needed for compressing a mesh, which may be unreasonable for a small device.
A pre-processing method is used to divide an original mesh into N (N being an integer being greater than or equal to two) smaller independent sub-meshes (by “independent” it is meant that other sub-meshes are not needed to compress or decompress a given sub-mesh), with duplicate and redundant vertices at the boundaries of adjacent sub-meshes, so as to preserve all the faces of the original mesh during the partitioning. Each sub-mesh may then be individually compressed, such that the full mesh does not need to be loaded into the memory for compression. The N sub-meshes may be processed in parallel if the system allows, or else serially.
A post-processing method is then used to reconstruct the original mesh from the N independent sub-meshes, by decompressing if necessary the N sub-meshes and then merging the N sub-meshes and optionally removing any duplicate/redundant vertices. In general, the amount of duplicate/redundant vertices is negligible (with respect to the total number of vertices) for very large meshes and does not significantly affect the compression performance, yet offers the flexibility of selecting any compression scheme.
In summary, the present invention enables large objects to be compressed without significantly impacting the overall compression rate. The introduced duplications/redundancies do not increase significantly the amount of data to process. In addition, these pre- and post- processing methods can be used with any compression engine, in contrast with other proposed methods which are in general completely dependent on the compression/decompression method.
Figures 2 (2A, 2B) show a simplified mesh 200 and its accompanying file format representation FFO (or “mesh data file”).
Figure 2A shows a mesh 200 comprising 20 vertices (V0 to V19) and 26 faces (F1 to F26). For reasons of simplicity and representation, the mesh is shown in a two-dimensional 2D plane but it could represent a 3D object using the three dimensions of the space and the invention is therefore not limited to such representation and can be applied to any object having two or three dimensions. The bounding box 201 encompasses all the vertices of the mesh, the extreme vertices along each axis, thus stretching between the vertices V0 and V11 along the x-axis, and between the vertices V19 and V3 along the y-axis.
Figure 2B shows the file format representation FFO of the mesh 200 shown in Figure 2A. The file format FFO is of PLY format with ASCII representation, comprising header information HI, vertex information VI, and face information FI.
The header information HI provides the structure of the file, including the type (PLY), the format of the data (format ascii 1.0), the number of vertex elements (element vertex 20), the vertex properties (property float x, property float y, property float z), the number of face elements (element face 26), the face properties (property list uchar int vertexjndices), and the end of the header information “end_header”.
The vertex properties relate to the vertex information VI, here the components for each vertex. Here, the mesh is a three-dimensional mesh, thus the components are X, Y, Z, providing vertex coordinates (X, Y, Z) for each vertex. It may be noted that while integers are used here for simplicity, the coordinates may equally be real numbers (comprising a fractional portion).
The face properties relate to the face information FI, here a first unsigned character (uchar) representing the number of edges NE (3, 4, or more) followed by a vertex list VL comprising the vertex indices Vi. The vertex indices Vi correspond to the index of the line of the coordinates, starting at line 0 at the top of the vertex information VI section. The order of the vertex indices Vi in the vertex list VL is generally defined by convention, in a clockwise or counter-clockwise manner, so that the normal of the face may be determined. A counter-clockwise manner has been chosen here.
It may be noted that the information in parentheses, such as (V0) or (F1), is normally not included in the file format representation, but is included here for reference with respect to Figure 2A, to more easily correlate the two figures. Furthermore, the PLY format is a common file format for representing objects and their attributes, but other types of file formats may be used in the framework of the present invention to represent an object.
Figures 3 (3A, 3B, 3C, 3D, 3E) show a mesh 300 (corresponding to the mesh 200 of Figure 2A) after partitioning along one axis into two partitions and the accompanying partition files, according to one embodiment.
Figure 3A shows the mesh 300 partitioned into a distinct top partition 301 and a distinct bottom partition 302 by a single horizontal partitioning line 303, here at the mid-point (Y = 30) of the mesh. It should be noted here that though reference is made to a “partitioning line”, the partitioning is not strictly speaking a line, but rather an arbitrary division between two partitions. A line is simply used here for better visual understanding of the partitioning of the object.
Each distinct partition 301, 302 is defined by a bounding box stretching from the extreme vertices along each axis on the side of the partitioning line 303. The distinct top partition 301 is thus defined as stretching between the vertices V1 and V5 along the x-axis (the extremities along the x-axis), and between the vertices V9 and V3 along the y-axis. Likewise, the distinct bottom partition 302 is thus defined as stretching between the vertices V0 and V11 along the x-axis, and between the vertices V19 and V11 along the y-axis.
As some edges E (shown as dashed lines 304) are transected by the partitioning line 303, information regarding the faces F comprising at least one transected edge 304 would be lost by an independent compression of each partition 301, 302. Thus, in this case, if divided into distinct partitions, the faces F1, F8, F13, F14, F15, F16, F17, F18, F19 will not be included.
It has been chosen here to include this face information somewhere as “additional face information”, either included with the bottom partition (as shown in relation with Figure 3B) or with the top partition (as shown in relation with Figures 3C, 3D, 3E).
To this end, a top overlapping region 305-1 (shaded box) may be associated with the bottom partition 302 as shown in Figure 3B or a bottom overlapping region 305-2 (shaded box) may be associated with the top partition 301 as shown in Figure 3C, depending on the implementation as described below. An overlapping region 305-1, 305-2 extends from the extreme vertex of the distinct vertices on the side of the partitioning line 303 associated with the partition in question to the extreme vertex connected to a transected edge 304 (that is to say, all dashed lines) on the opposite side of the partitioning line 303. That is to say, if the overlapping region is to be associated with the bottom partition 302, then it extends from below the partitioning line 303 to the extreme vertex on the opposite side of the partitioning line 303 (n the top partition 301), and vice versa. Duplicate vertices 306 and redundant vertices 307 are also present, as will now be described in further detail.
Figure 3B thus shows the bottom partition 302 according to a first embodiment, wherein it has been decided to keep the top overlapping region 305-1, such that the partition information concerning the top overlapping region 305-1 is included with or appended to the bottom partition 302. Thus, the overlapping region 305-1 stretches between the vertex V11 (the first vertex along the Y direction below the partitioning line 303) and the vertex V5 along the y-axis, since the vertex V5 is the extreme vertex connected to a transected edge 304. A complete bounding box encompasses a distinct partition and an overlapping region if present, thus here a complete bounding box 308 (solid box) encompasses the distinct bottom partition 302 and the overlapping region 305-1.
Duplicate vertices 306 (white or open circles) are vertices that are connected to a transected edge 304 AND are arranged on the opposite side of the partitioning line 303, thus within an overlapping region. These duplicate vertices 306 and the face information FI concerning the faces comprising at least one duplicate vertex (that is to say, a face comprising at least one transected edge 304), will be included in the file format describing the bottom partition 302.
Figure 3C shows the top partition 301 according to a second embodiment, wherein it has been decided to keep the bottom overlapping region 305-2, such that the partition information concerning the overlapping region 305-2 (shaded box) is included with or appended to the top partition 301. Thus, the overlapping region 305-2 stretches between the vertex V9 (the first vertex along the Y direction above the partitioning line 303) and the vertex V17 along the y-axis, since the vertex V17 is the extreme vertex connected to a transected edge 304. A complete bounding box 309 (solid box) encompasses the distinct top partition 301 and the bottom overlapping region 305-2.
Duplicate vertices 306 (white or open circles) and the face information FI concerning the faces comprising at least one duplicate vertex (that is to say, a face comprising at least one transected edge 304), will be included in the file format describing the top partition 301.
The file format representation of Figure 3C is shown in Figure 3E as file format representation FF2 and comprises information relating to the top partition 301, that is to say all vertices (V1, V2, V3, V4, V5, V6, V7, V8, V9, V10) above the partitioning line 303 and not affected by the partitioning, as well as the faces (F2, F3, F4, F5, F6, F7, F9, F10, F11, F12) above the partitioning line 303 and also not affected by the partitioning due to not comprising a transected edge 304. These vertices may be considered as a first sub-set of vertices with related face information. The file format representation further comprises information relating to the overlapping region 305-2, that is to say the duplicate vertices 306 (V0, V11, V12, V13, V14, V17) on the opposite side of the partitioning line 303 and the faces (F1, F8, F13, F14, F15, F16, F17, F18, F19) affected by the partitioning. These vertices may be considered as a second subset of vertices with related face information.
Information concerning the faces (F20, F21, F22, F23, F26) comprising at least one duplicate vertex 306 (VO, V11, V12, V13, V14, V17) but not affected by the partitioning (transected by the partitioning line 303) are not included, as they will be included in the file format representation of the bottom partition 302.
The choice of which overlapping region 305-1, 305-2 to implement may depend on several factors, such as the number of vertices and faces included in the overlapping region, the number of vertices to be duplicated, the dimensions of the overlapping region, and so forth. It may be noted that while other vertices may be included in an overlapping region, if they are not connected to a transected edge 304, they will not be duplicated. For example, in the case of Figure 3B with reference to Figure 3A, the vertices V6, V7 (not shown) fall within the overlapping region 305-1 but would not be duplicated. For the case of Figure 3C with reference to Figure 3A, there are no vertices falling within the overlapping region 305-2 but not connected to a transected edge 304.
Figure 3D shows the bottom partition 302 according to the second embodiment of Figure 3C, wherein the overlapping region has been associated with the top partition 301 and is thus not shown here. The bottom partition 302 thus comprises redundant vertices 307 (grey or shaded circles), which correspond to the duplicate vertices 306 of Figure 3C. These same vertices are thus considered here to be redundant as they have already been duplicated in relation with another partition. A complete bounding box 310 (solid box) encompasses the distinct bottom partition 302, thus stretches between vertices V0 and V11 along the x-axis and between vertices V19 and V11 along the y-axis. It may be noted that the bounding boxes 302, 310 are here the same (shown slightly shifted with respect to each other for clarity) since there is no overlapping region in this case.
The file format representation of Figure 3D is shown in Figure 3E as file format representation FF1 and comprises information relating to the bottom partition 302, that is to say all vertices (V15, V16, V18, V19) below the partitioning line 303 and not affected by the partitioning, as well as the faces (F20, F21, F22, F23, F24, F25, F26) below the partitioning line 303 and also not affected by the partitioning due to not comprising a transected edge 304. These vertices may be considered as third sub-set of vertices with related face information. The file format representation further comprises the redundant vertices 307 (V0, V11, V12, V13, V14, V17), that is to say the vertices affected by the partitioning and on the same side of the partition, being duplicated in the adjacent (top) partition. These vertices may be considered as a fourth sub-set of vertices, but no face information is related with these redundant vertices, as the relevant face information has been included with the second sub-set of vertices (duplicate vertices 306). It should be noted that the vertices VO, V11 are shown as isolated vertices IV, as described in relation with Figure 1. Their connectivity information (faces F1, F8, F13, F19) having been described in relation with the top partition 301, it is not necessary to include them as connected points, as edges (the edge between V0 and V12, and the edge between V11 and V17) are not defined in the file format representations.
It may further be noted that while the first, second, third, and fourth sub-sets of vertices are listed above separately, they may be interleaved within the file format representations, as will be shown in reference with Figure 3E. Furthermore, the vertices would be renamed in the files FF1, FF2, for consistency with the file format. The same references have been kept here for the sake of comprehension.
Figure 3E shows the partitioning information file PIF1, as well as the file format representations FF1, FF2 referenced by the partitioning information file.
The partitioning information file PIF1 here comprises six lines only, as the partitioning is fairly simple.
Line 01 indicates the “redundancy location”, that is to say, which partition comprises the duplicate vertices 306. Here, the information concerning the duplicate vertices is included with the top partition 301, so the redundancy location is indicated as being the top partition.
Line 02 indicates the limits of the bounding box 201 (shown in Figure 2A), in X, Y, and Z coordinates, that is to say, the minimum and maximum coordinates of the vertices in each direction.
Line 03 indicates the type of data, either raw or compressed. In the case of raw data, the filenames (as shown in lines 05, 06) correspond to meshes represented according to the PLY file format, and no decoding process is necessary before reconstruction of the object.
Line 04 indicates the partitioning type, that is to say, the number of partitions and along what axis or axes. In this case, there are two partitions along the y-axis, hence 2Y.
Line 05 indicates the characteristics of the bottom partition 302, that is to say the Y coordinates (3, 29) of the distinct bounding box 302, the total number of vertices (10) within the distinct bottom partition 302 (thus including the redundant vertices 307), the Y coordinates (3, 29) of the complete bounding box 310 (here, there is no overlapping region, so the coordinates are the same), and the associated PLY file represented by FF1.
Line 06 indicates the characteristics of the top partition 301, that is to say the Y coordinates (32, 60) of the distinct bounding box 301, the total number (10) of vertices within the distinct top partition 301 (thus not including the duplicate vertices 306), the Y coordinates (19, 60) of the complete bounding box 309, and the associated PLY file represented by FF2.
The difference between the coordinates (from y=32 to y=60 and from y=19 to y=60) of line 06 may be used to deduce that the region from y=19 to y=32 comprises the duplicate vertices. In an alternative embodiment, the overlapping region itself is defined in the file PIF1, for example from y=19 to y=32.
The file format representations FF1, FF2 comprise the header information HI, as previously described in relation with Figure 2B, followed by the vertex information VI and the face information FI (references not shown). It should be noted that in general, to be compliant with the definition of the PLY file format, faces are defined by vertex indices Vi present in the file. As for example the file format FF1 has ten vertices, the listed faces should only have vertex indices ranging from 0 to 9. However, it may be noted here that the vertex information is essentially the same as that of Figure 2B, with the exception that certain vertices should be renumbered (shown in bold), to compensate for the missing vertices (V1 to V10). The face information is then changed in consequence, to take into the account the renumbered vertices. The vertex values listed in the face information FI that would be changed are also shown in bold. In the file formats FF1, FF2, the vertices have not been renumbered, and consequently the face information has not been changed, to avoid confusion.
It may be further noted that while line 06 of the partitioning information file PIF1 indicates a total of 10 vertices, the corresponding file FF2 lists 16 vertices. The difference (16 - 10 = 6) corresponds to the number of duplicate vertices 306. It may therefore be deduced that the top partition comprises six duplicate vertices 306. In contrast, line 05 of the partitioning information file indicates a total of 10 vertices, and the corresponding file FF1 also lists 10 vertices. It may therefore also be deduced that the bottom partition does not comprise duplicate vertices 306.
Figure 4 schematically shows the partitioning of a mesh into several partitions and the compression of the partitions by means of an encoder 400 according to one embodiment.
The encoder 400 comprises a controller 401, a mesh partitioner 402, and a plurality N of mesh encoders 403-n (n being an index from 1 to N, N being greater than or equal to 2).
The controller 401 enables partition parameters 411 to be set, either by means of a user interface or automatically, and the supplies partition parameters 411 to the mesh partitioner 402. The partition parameters 411 may indicate the axis along which the partitioning is to be performed by the mesh partitioner 402, such as along a single axis (X, Y, Z) or along a first axis and then one or both of the other axes, etc. The partition parameters 411 may also indicate the number N of partitions to be obtained, which may be done according to different criteria as follows:
- the partitioning may be performed with respect to spatial criteria, such that a fixed size is selected for each partition, such as at the middle of the total mesh height, as shown above in relation with Figures 3;
- the partitioning may be performed so that a partition contains a given number of vertices,
- the partitioning may be performed so that the partitions comprise equal, ‘approximately equal’ or ‘substantially equal’ numbers of vertices, by evaluating the number of the vertices per partition if cut along a particular axis. By approximately or substantially equal it is intended to indicate that the numbers of vertices within the different partitions are within for example 10% of each other, this amount varying according to the application. This manner of partitioning may be advantageous for the purposes of compressing a 3D object since the memory used by most 3D mesh compression schemes depends on the number of vertices per partition. This criterion is particularly adapted to some 3D compression engines such as SC3DMC since the memory used is proportional to the number of vertices of a mesh, as described above. By controlling the number of vertices per partition, the amount of memory for the compression of each partition may be controlled; or
- the partitioning may be performed so that a minimum number of edge cuts is performed, by selecting a partitioning line that transects the least amount of edges.
The mesh partitioner 402 thus receives the partition parameters 411 on input, as well as the mesh to be partitioned, original mesh file 412, in the form of a file format representation. The mesh partitioner 402 then partitions the original mesh file 412 into N mesh partition files 413-n (Mesh Partition 1... Mesh Partition N), as indicated by the partition parameters 411. It may be noted that the original mesh file 412 can correspond to the file FFO of Figure 2B and the mesh partition files 413-n can correspond to the files FF1, FF2 as described in relation with Figure 3E, for example.
The mesh partitions 413-n may then be supplied to the N mesh encoders 403-n, which may be, for example, the SC3DMC standard produced by the MPEG standardization body.
The controller 401 also enables certain compression parameters to be set for compression of the partitions, such as a quantization parameter indicating the number of bits to represent each vertex, as well as the prediction method; in general, the parameters needed for the compression of a mesh. In the case where the mesh is partitioned into several sub-meshes which compose the whole mesh, the quantization grid should be exactly the same for each independent partition so that when the reconstruction is applied there is no shift in the grid of the vertices. The controller 401 ensures that the correct quantization grid is used for all the sub-meshes and supplies compression parameters 414 to the mesh encoders 403-n.
The controller 401 may also supply a partitioning information file 415 that will be sent with coded partitions to the decoder. The partitioning information file 415 (as provided above as PIF1 in relation with Figure 3E) provides information about the partitioning and provides a list of the resulting compressed or raw files, allowing the decoding and reconstruction of the mesh to be performed in an efficient manner.
Though advantageous, the partitioning information file 415 is not mandatory, as the decompression of the files and the reconstruction of the mesh is still possible without such information. However, the overlapping region corresponding to the duplicate vertices will not be identified as such, requiring a time consuming and complex operation to identify the overlapping region, identify and remove the duplicate vertices.
The mesh encoders 403-n supply on output coded partitions 416-n. The coded partitions may then either be grouped together with the partitioning information file 415 and sent as one file to the decoder, be grouped together into one file and sent with the partitioning information file 415 as a separate file to the decoder, sent individually with the partitioning information file 415 as N+1 separate files to the decoder, or any other combination possible, depending on size of the files, etc. An output file(s) 417 is thus supplied on output to a decoder.
Figure 5 schematically shows the decompression of the partitions and the merging of the partitions by means of a decoder 500 into a single mesh.
The decoder 500 comprises a controller 501, a plurality N of mesh decoders 502-n (n being an index from 1 to N, N being greater than or equal to 2), and a mesh merger 503.
The output file(s) 417 supplied by the encoder 400 is received on input of the decoder 500 as an input file(s) 511. If the input file already comprises the individual coded partitions 416-n, then the coded partitions 416-n are simply supplied on input to the corresponding mesh decoders 502-n. Otherwise, the input file(s) are broken up into the coded partitions 416-n before they are supplied to the mesh decoders 502-n.
The partitioning information file 415 (if present) is supplied to the controller 501, which then supplies decompression parameters 512 to the mesh decoders 502-n. The mesh decoders 502-n supply on output the mesh partitions 413-n to the mesh merger 503. The mesh merger 503 then merges the mesh partitions 413-n, preferably removes any duplicate vertices, and supplies on output a reconstructed mesh file 513, which may be considered as the same or essentially the same as the original mesh file 412 depending on the quantization parameter used to quantize each vertex.
The mesh partitioner 402 and/or mesh merger 503 may be programmed FPGA (“Field-programmable gate array”) or ASIC (“Application-Specific Integrated Circuit”).
Figure 6 is a flowchart of a mesh partitioning method 600 performed by an encoder according to one embodiment, more specifically implemented by the mesh partitioner 402 of the encoder 400 as shown in Figure 4. The method 600 comprises the steps 601 to 607.
In step 601, the mesh partitioner 402 receives the original mesh file 412 (corresponding to mesh 200 of Figure 2A, and more particularly the file format FFO of Figure 2B).
In step 602, the mesh partitioner 402 determines the bounding box (201) of the mesh by parsing the list of the number of vertices in the original PLY file to determine the minimum and maximum coordinate values for the three axes: OX, OY and OZ. For example, for the mesh shown in Figure 2A, the bounding boxes along the three axes are as follows: min_x = 2, max_x = 70, min_y = 3, max_y = 60, min_z = 0, max_z = 0.
In step 603, the mesh partitioner 402 computes the density of vertices along each concerned axis, here OX, OY, and OZ. (That is to say, if the mesh is only two dimensions, the density along the third dimension is not necessary.) This step may be optional when the partitioning is done accordingly to a spatial partitioning, and is preferred when the partitioning needs to respect a given number of vertices per partition. To compute the density along each axis, a histogram may be established, representing the number of vertices per spatial segment. For example, each axis is divided into a significant number of small segments so as to define a pseudo-density function, and the number of vertices per segment is counted.
In step 604, the mesh partitioner 402 cuts the connectivities between adjacent partitions, by partitioning the original mesh file 412 into N intermediate mesh partition files, similar to the file formats FF1 and FF2 but without considering the overlapping regions. With reference to the example shown in Figures 3, the two intermediate mesh files are created by distributing the vertices with respect to the partitioning line 303. The vertices of the original mesh file are thus divided into two distinct groups, renumbered as necessary, and the numbering of the faces is adjusted accordingly. The faces F transected by the partitioning line 303 are not taken into consideration at this stage.
In step 605, the mesh partitioner 402 identifies the vertices and connectivities between adjacent partitions, that is to say, the missing faces (those transected by the partitioning line) of the original mesh 412 not represented in one of the N intermediate files are identified.
In step 606, the mesh partitioner 402 duplicates the identified vertices and adds the duplicate vertices and the associated faces to one of the N intermediate files, as determined by convention (for example, always the first file, always the one with the fewer number of vertices in order to more evenly distribute the information, etc.). The vertices to be duplicated and the associated faces are thus introduced into one of the N intermediate files. In general, the list of duplicate vertices is introduced at the end of the vertex information VI and before the face information FI (as shown in Figure 2B), so as to not modify more than necessary the numbering of the vertices for the existing faces. The new faces are then added at the end of the face information FI, taking into account the numbering of the duplicate vertices.
In step 607, the mesh partitioner 402 supplies on output the N mesh partition files 413-n.
It may be noted that while reference has been made above to the “original mesh” 412, the original mesh in question may not be the entire mesh, as the entire mesh may consist of millions of vertices and faces. In that case, successive partitioning and compressing of the entire mesh file can be performed as needed.
Furthermore, if the original mesh does not need to be compressed and decompressed, then the mesh encoders 403-n and mesh decoders 502-n can be bypassed, with the object partitions being supplied directly on output from the object partitioner 402 of the encoder 400 and on input to the object merger 503 of the decoder 500.
Figure 7 is a flowchart of a mesh merge method 700 performed by a decoder according to one embodiment, more specifically implemented by the mesh merger 503 of the decoder 500 as shown in Figure 5. The method 700 comprises the steps 701 to 707. The merge method 700 is essentially the reverse operation of the partitioning method 600, in order to reconstruct the original mesh 412, or a version thereof, from the sub-meshes. The main goal of the mesh merger 503 is thus to group or merge the different files together and, optionally, to remove any duplicate vertices which are not necessary for the reconstruction/representation of the object.
If the mesh partitions were compressed by the encoder 400 after the partitioning operation, a decompression step is to be performed by the decoder 500 before the merge method 700 is performed.
The merging method described below is based on the information included in the partitioning information file 415, which comprises all the necessary information to merge the N mesh partition files. It also comprises information helpful for efficiently removing any duplicate vertices that appear in the merged file, thereby significantly reducing the processing time necessary for the decoder 500, in particular the mesh merger 503.
In step 701, the mesh merger 503 receives the partitioning information file
415.
In step 702, the mesh merger 503 identifies the partitioning type, according to the partitioning information (for example that the original mesh 412 was partitioned into two horizontal partitions as in the present case), so that the order of merging the files may be determined.
In step 703, the mesh merger 503 identifies the adjacent partitions for the merging.
In step 704, the mesh merger 503 receives the N mesh partitions 413-n.
In step 705, the mesh merger 503 merges the N mesh partitions 413-n into a single file, for example by merging two or more PLY files into a single file, updating the header information HI concerning the number of vertices V and faces F, merging the vertex information VI of the two or more files, renumbering the vertices as needed, and merging the face information FI of the two or more files, with renumbering of the faces as needed, based on the modified vertices.
In step 706 (optional), the mesh merger 503 removes the duplicate vertices from the merged file, in order to obtain a more compact file. The removal of the duplicate vertices comprises the following steps:
- modifying the number of vertices in the header information HI, according to the vertex number indicated in the partitioning information file 415. For example, when considering the example of Figure 3E, the partitioning information file indicates 20 vertices (the sum of the number of vertices indicates in lines 05 and 06); and
- removing the duplicate vertices, the number of which corresponds to the difference between the sum of the files FF1, FF2 (16 + 10 = 26) and the sum of vertices (20) as above, indicating that (26 - 20 = 6) vertices are duplicates and need to be removed. In this example, it is relatively quick to remove the six duplicate vertices, but for a large file with a large number of duplicate vertices, removing the duplicate vertices can be quite long and fastidious since the duplicate vertices can be located anywhere in the file, necessitating a line-by-line comparison of coordinate values.
To solve this issue, at least two solutions can be used. A first solution consists in sorting all the vertex coordinate values in a given order (increasing or decreasing) and then eliminating duplicate vertices, which should be close together in the list. The main drawback of this solution is that an additional step of reordering the face numbers is needed and can be difficult to perform since it is needed to store the new position of each vertex in the ordered list.
A second solution is to rely on the overlapping region information given in the partitioning information file, which provides information about the location of the duplicate vertices (either the difference between the coordinates such as described above in relation with line 06 of Figure 3E, or defining the overlapping region itself).
In step 707, the mesh merger 503 supplies on output the reconstructed mesh file 513. If no compression was used to encode the mesh, the reconstructed mesh file 513 corresponds to the original mesh file 412. If however compression was used, the reconstructed mesh 513 may differ slightly from the original mesh 412, as some information may have been lost due to the compression stage.
Figures 8 (8A, 8B, 8C, 8D) show a mesh 800 (corresponding to the mesh 200 of Figure 2A) partitioned into four partitions according to one embodiment: a top-left partition 801 (Figure 8A), a top-right partition 802 (Figure 8B), a bottom-left partition 803 (Figure 8C), and a bottom-right partition 804 (Figure 8D).
These partitions are the result of a two-stage partitioning process. In the first stage, the mesh 200 of Figure 2A is partitioned along the horizontal partitioning line 303, here situated at y=30 as previously, thus producing the partitions 301, 302 as described in relation with Figures 3. In the second stage, the partitions 301, 302 (with the duplicate/redundant vertex information and face information) are then each partitioned along a vertical partitioning line 805, here situated at x=35, creating transected edges 806. More specifically, the partitioning of the top partition 301 provides the top-left partition 801 and the top-right partition 802, and the partitioning of the bottom partition 302 provides the bottom-left partition 803 and the bottom-right partition 804.
Furthermore, overlapping regions 807-3, 807-4 are associated with respectively the top-left partition 801 and the bottom-left partition 803, and the partitions comprise duplicate vertices 808 (open or white circles) and redundant vertices 809 (grey circles).
Figure 8A shows the top-left partition 801, wherein the partition information concerning the overlapping region 807-3 (shaded box) is included with or appended to the top-left partition 801. A distinct bounding box 801 encompasses the vertices (V0, V1, V2, V3, V6, V8, V12, V13) to the left of the partitioning line 805, and a complete bounding box 810 encompasses all vertices, including the duplicate vertices 808 (V4, V7, V9, V14) of the overlapping region 807-3.
Figure 8B shows the top-right partition 802 according to the above embodiment, wherein the overlapping region 807-3 has been associated with the topleft partition 801 and is thus not shown here. The top-right partition 802 thus comprises redundant vertices 809 (V4, V7, V9, V14), here redundant with the top-left, bottom-left, and bottom-right partitions. A complete bounding box 811 encompasses the distinct top-right partition 802, the two bounding boxes 802, 811 being the same here as the information concerning the overlapping region 807-3 is included with that of the top-left partition 801.
Figure 8C shows the bottom-left partition 803, wherein the partition information concerning the overlapping region 807-4 (shaded box) is included with or appended to the bottom-left partition 803. A distinct bounding box 803 encompasses the vertices (V0, V12, V13, V15, V18, V19) to the left of the partitioning line 805, and a complete bounding box 812 encompasses all vertices, including the duplicate vertices 808 (V14, V16).
Figure 8D shows the bottom-right partition 804 according to the above embodiment, wherein the overlapping region 807-4 has been associated with the bottom-left partition 803 and is thus not shown here. The bottom-right partition 804 thus comprises redundant vertices 809 (V14, V16), here redundant with the top-left, topright, and bottom-left partitions. A complete bounding box 813 encompasses the distinct bottom-right partition 804, the two bounding boxes 804, 813 being the same here as the information concerning the overlapping region 807-4 is included with that of the bottom-left partition 803.
On one hand, it may be noted that some vertices are duplicated more than twice, such as vertex V14, which is present in all four partitions 801, 802, 803, 804, as it falls within the overlapping region 305-2 of Figure 3C, and within the overlapping regions 807-3, 807-4 of Figures 8A and 8C.
Furthermore, it may be noted that through this partition method there is no duplication of faces. The total number of faces (6+1 + 12 + 7 = 26) of the four partitions 801, 802, 803, 804 is the same as that of the original file (26).
Figures 9 (9A, 9B, 9C) show the partitioning information file PIF2, the file format representations of the bottom partition (FF3, FF4), and the top partition (FF5, FF6) respectively of the Figures 8.
As described in relation with Figure 3E, line 01 indicates the “redundancy locations”, that is to say, which partition comprises the duplicate vertices 808. Here, the overlapping region is associated with the “top” partition 301 for the first partitioning, so the redundancy location is indicated as being the top portion. For the second partitioning along the X axis performed according to the line 805, the redundant information is associated to the right part corresponding to the “bottom” part of the X axis.
Line 02 indicates the limits of the bounding box, in X, Y, and Z coordinates, that is to say, the minimum and maximum coordinates of the vertices in each direction, which is the same as that of Figure 3D, the total mesh being unchanged.
Line 03 indicates the type of data, either raw or encoded. In the case of raw data, the filenames (as shown in lines 05, 06) correspond to meshes represented according to the PLY file format, and no decoding process is necessary before merging and reconstruction of the mesh.
Line 04 indicates the partitioning type, that is to say, the number of partitions and along what axis or axes. In this case, there are two partitions along the y-axis, followed by two partitions along the x-axis, hence 2Y, 2X.
Line 05 indicates the characteristics of the bottom partition 302, that is to say the Y coordinates (3, 29) of the distinct bounding box 302, the total number (10) of bottom vertices (thus including the redundant vertices 307) below the partitioning line 303, the Y coordinates (3, 29) of the complete bounding box 310 (here, there is no overlapping, so the coordinates are the same). It is not necessary to include the file format representation FF1, since the information contained therein can be construed from the sub-files FF3, FF4.
The bottom partition 302 defined in line 05 is then further divided into the vertical partitions, the bottom-left partition 803 and the bottom-right partition 804.
Line 06 indicates the characteristics of the bottom-left partition 803, that is to say the X coordinates (2, 32) of the distinct bounding box 812, the total number (6) of vertices within the distinct bottom-left partition (thus not including the duplicate vertices
808) , the X coordinates (2, 50) of the complete bounding box 812, and the associated file format representation FF3 shown in Figure 9B.
Line 07 indicates the characteristics of the bottom-right partition 804, that is to say the X coordinates (40, 70) of the distinct bounding box 804, the total number (4) of vertices within the distinct bottom-right partition (thus including the redundant vertices
809) , the X coordinates (40, 70) of the complete bounding box 813 (here, there is no overlapping, so the coordinates are the same), and the associated file format representation FF4 shown in Figure 9B.
Line 08 indicates the characteristics of the top partition 301, that is to say the Y coordinates (32, 60) of the distinct bounding box 301, the total number (10) of top vertices (thus not including the duplicate vertices 306) above the partitioning line 303, and the Y coordinates (19, 60) of the complete bounding box 309.
The top partition 301 defined in line 08 is then further divided into the vertical partitions, the top-left partition 801 and the top-right partition 802.
Line 09 indicates the characteristics of the top-left partition 801, that is to say the X coordinates (2, 28) of the distinct bounding box 801, the total number (8) of vertices within the distinct top-left partition (thus not including the duplicate vertices 808), the X coordinates (2, 50) of the complete bounding box 810, and the associated file format representation FF5 shown in Figure 9C.
Line 10 indicates the characteristics of the top-right partition 802, that is to say the X coordinates (36, 70) of the distinct bounding box 802, the total number (8) of vertices within the distinct top-right partition (thus including the redundant vertices 809), the X coordinates (36, 70) of the complete bounding box 811 (here, there is no overlapping, so the coordinates are the same), and the file format representation FF6 shown in Figure 9C.
Figures 9B and 9C will not be described in detail here, as their contents follow that of Figures 2B and 3D. However, as previously described in relation with Figure 3E, to be compliant with the definition of the PLY file format, faces are defined by vertex indices present in the file. However, it may be noted here that the vertex information is essentially the same as that of Figure 2B, to avoid confusion, with the exception that certain vertices should be renumbered (shown in bold), to compensate for the missing vertices, with the connectivity information changed in consequence, to take into the account the renumbered vertices. The vertex values listed in the connectivity information that would be changed are also shown in bold.
Further, by comparison of the vertex elements of file formats FF3, FF4 it may be seen that there are two duplicate vertices (V14, V16) between the two files, and by comparison of the vertex elements of file formats FF5, FF6 it may be seen that there are four duplicate vertices (V4, V7, V9, V14) between the two files.
Figure 10 schematically illustrates a device 1000 configured to implement at least one embodiment of the present invention. The device 1000 may preferably be a device such as a micro-computer, a workstation or a handheld device.
The device 1000 comprises:
- a central processing unit CPU 1001 such as a microprocessor;
- a read only memory ROM 1002 for storing computer programs for implementing embodiments of the invention;
- a random access memory RAM 1003 for storing the executable code of methods according to embodiments of the invention;
- at least one communication interface COM 1004 (optional) connected to a communication network over which data may be transmitted;
- a disk drive DDR 1005 (optional) for reading data from and writing data to a non-transitory computer readable medium CRM 1010 (such as a disk, CDROM, USB key, memory card and the like);
- a display DIS 1006 (optional) for displaying data and/or serving as a graphical interface with a user;
- an input device INP 1007 (optional) such as a keyboard or mouse;
- a digital camera CAM 1008 (optional); and
- a communication bus 1009 interconnecting the various elements.
Preferably the communication bus 1009 provides communication and interoperability between the various elements included in the device 1000 or connected thereto. The representation of the bus is not limiting and in particular the central processing unit CPU 1001 is operable to communicate instructions to any element of the device 1000 directly or by means of another element of the device 1000.
The computer readable medium CRM 1010 is an information storage means that can be read by a microcomputer or by a microprocessor, integrated or not into the device, optionally removable and adapted to store one or more programs whose execution enables a method according to an embodiment of the invention to be implemented.
Furthermore, the executable code may optionally be stored either in the read only memory ROM 1002, or received by means of the communication interface 1004, in order to be stored in one of the storage means of the device 1000 before being executed.
The central processing unit 1001 is preferably adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, which instructions are stored in one of the aforementioned storage means.
On powering up, the program or programs that are stored in a non-volatile memory, for example in the read only memory 1002, are transferred into the random access memory 1003, which then contains the executable code of the program or programs, as well as registers for storing the variables and parameters necessary for implementing the invention.
In a preferred embodiment, the device is a programmable apparatus which uses software to implement the invention. However, alternatively, the present invention may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC).
The coding performances of SC3DMC, with the same quantization parameters and grid, have been compared for several meshes (from approximately 300,000 vertices and 650,000 faces to 14,000,000 vertices and 28,000,000 faces) partitioned into 27 partitions (3 partitions along each axis X, Y, Z) and the same meshes not partitioned. In general, a small positive percent increase (up to 1.1 to 3.8%) was observed for the coding of the partitioned meshes according to embodiments of the present invention, indicating an increase of file size (lower compression performance). The coding performance is thus not greatly affected, and for the largest mesh, the partitioning provided a slight gain in coding performance (-0.2%) An average loss of 1.6% was therefore observed, which is relatively small in comparison with the large benefit of being able to process huge meshes, and by using any compression/decompression method. The present invention may thus be implemented without size limitations on the meshes.
Although the present invention has been described hereinabove with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications which lie within the scope of the present invention will be apparent to a person skilled in the art. In particular different features from different embodiments may be interchanged, where appropriate. Many further modifications and variations will suggest themselves to those versed in the art upon making reference to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the invention as determined by the appended claims.
Claims (29)
1. A method of partitioning a mesh data file into a set of at least two adjacent partition data files, the mesh data file describing an object for encoding and comprising a plurality of vertices and any faces comprising the vertices, the method comprising the steps of:
- partitioning the mesh data file so as to create at least a first partition and a second partition, the two partitions being adjacent to one another, and
- generating at least a first partition data file and a second partition data file, the first partition data file comprising:
- a first sub-set of vertices belonging only to the first partition, not affected by the partitioning, and faces comprising the first sub-set of vertices, and
- a second sub-set of vertices duplicated with the second partition, affected by the partitioning, and faces comprising the second sub-set of vertices; and the second partition data file comprising:
- a third sub-set of vertices belonging only to the second partition, not affected by the partitioning, and faces comprising the third sub-set of vertices, and
- a fourth sub-set of vertices redundant with the first partition, affected by the partitioning;
wherein a duplicate vertex is one that is connected to an edge between two vertices that is affected by the partitioning and is situated on the opposite side of the partitioning as the other vertices of the partition data file, and wherein a redundant vertex is one that is one that is connected to an edge between two vertices that is affected by the partitioning and is situated on the same side of the partitioning as the other vertices of the partition data file.
2. The method according to claim 1, wherein the step of generating a partition data file further comprises creating a file format representation of the partition.
3. The method according to claim 2, wherein the file format representation of the partition comprises at least one of:
- a number of vertices comprised within the partition, the number of vertices comprising the vertices not affected by the partitioning and the duplicate vertices if any;
- vertex properties, comprising at least the location of each vertex;
- a number of faces; and
- face properties, wherein a face comprises vertices of the file format representation.
4. The method according to one of claims 1 to 3, further comprising a step of creating a partitioning information file describing the file format representations of the set of adjacent partition data files, the partitioning information file comprising at least one of:
- an indication of the partition comprising the duplicate vertices;
- a number of partitions;
- a location of the partitions; and
- characteristics of each partition.
5. The method according to claim 4, wherein the characteristics of each partition comprise at least one of:
- coordinates of a distinct bounding box comprising all vertices within the partition;
- a number of vertices within the partition;
- coordinates of a complete bounding box comprising all vertices within the partition and any duplicate vertices; and
- an associated file format representation of the partition.
6. The method according to claim 5, wherein a comparison of the coordinates of the distinct bounding box and the complete bounding box indicate an overlapping region comprising any duplicate vertices.
7. The method according to claim 5, wherein a comparison of the number of vertices within the partition indicated by the partitioning information file and the number of vertices within the partition indicated by the file format representation of the partition indicate the number of duplicate vertices.
8. The method according to one of claims 1 to 7, wherein the partitioning step is performed according to partitioning parameters indicating at least one of:
- the axis along which the partitioning is to be performed;
- the order of partitioning along a plurality of axes; and
- the number of partitions to be obtained.
9. The method according to claim 8, wherein the partitioning parameters further indicate the type of partitioning to be performed, the type of partitioning comprising at least one of:
- partitioning the mesh data file with respect to spatial criteria;
- partitioning the mesh data file so that a partition contains a given number of vertices;
- partitioning the mesh data file so that the partitions comprise equal or substantially equal numbers of vertices; or
- partitioning the mesh data file so that a minimum number of edges between vertices are transected.
10. The method according to claim 1, wherein the partitioning step further comprises the steps of:
- determining a mesh bounding box by determining the minimum and maximum coordinate values of the vertices;
- cutting connections between adjacent partitions;
- identifying connections between adjacent partitions and the vertices associated with the identified connections; and
- adding the identified connections to one of the partition data files.
11. The method according to claim 10, further comprising, after determining the mesh bounding box, a step of computing the density of vertices along each concerned axis of the mesh when the partitioning should respect a given number of vertices per partition.
12. The method according to claim 10, wherein the step of cutting connections comprises a step of partitioning the mesh data file into a plurality of intermediate mesh files, without considering faces formed between affected vertices, by performing the steps of:
- distributing the vertices with respect to the partitioning,
- dividing the vertices of the original object into two distinct groups,
- renumbering the vertices as necessary, and
- adjusting the face properties accordingly.
13. A method of encoding a mesh data file, the method comprising the steps of:
- receiving a mesh data file to be partitioned on input,
- receiving partition parameters on input,
- partitioning the mesh data file into at least a first partition data file and a second partition data file according to the method of one of claims 1 to 12,
- encoding each partition data file as a coded partition, and
- supplying on output at least one output file comprising the coded partitions.
14. The method according to claim 13, wherein the partitioning step further comprises a step of creating a file format representation of the partition.
15. The method according to claim 14, further comprising a step of supplying on output a partitioning information file describing the file format representations of the set of adjacent partitions.
16. A method of merging a set of at least two adjacent partition data files into a mesh data file, the adjacent partitions having been partitioned according to the method of one of claims 1 to 12, the method comprising the steps of
- receiving the set of at least a first partition data file and a second partition data file on input;
- merging the partitions; and
- supplying on output a reconstructed mesh data file.
17. The method according to claim 16, further comprising a step of receiving a partitioning information file supplied by the encoding method, and wherein the step of merging the partitions is performed based on information comprised in the partitioning information file.
18. The method according to one of claim 16 or 17, further comprising a step of removing any duplicate vertices from the mesh data file.
19. The method according to claim 18, wherein the step of removing any duplicate vertices comprises the steps of:
- modifying the number of vertices in a header information according to a vertex number indicated in the partitioning information file; and
- removing the duplicate vertices, the number of which corresponds to the difference between the sum of vertices of the set of partition data files and the number of vertices in the partitioning information file.
20. The method according to claim 19, wherein the step of removing the duplicate vertices comprises a step of sorting all the vertices of the mesh data file in a given order and then eliminating duplicate vertices.
21. The method according to claim 19, wherein the step of removing the duplicate vertices comprises using an overlapping region information provided by the partitioning information file, which provides information about the location of the duplicate vertices.
22. The method according to claim 17, further comprising the steps of:
- identifying the type of partitioning, so that the order of merging of the files may be determined;
- identifying the adjacent partitions for the reconstruction of the mesh data file;
- receiving the adjacent partitions; and
- merging the adjacent partitions into a single file,
23. The method according to claim 22, wherein the step of merging the adjacent partitions into a single file comprises the steps of:
- updating a header information concerning the number of vertices and connections;
- merging vertex information of the partitions;
- renumbering the vertices as needed;
- merging face properties of the partitions; and
- adjusting the face properties as needed, based on the renumbered vertices.
24. A method of decoding a mesh data file encoded according to one of claims 13 to 15, comprising the steps of:
- receiving an output file from an encoder comprising coded partitions;
- decoding the coded partitions to obtain a set of adjacent partition data files; and
- merging the set of adjacent partition data files according to one of claims 16 to 23.
25. The method according to claim 24, wherein the receiving step further comprises dividing the file into coded partitions.
26. The method according to one of claims 24 or 25, wherein the decoding 10 step further comprises decoding the coded partitions according to decompression parameters determined by a partitioning information file supplied to the decoder.
27. An encoder configured to implement the steps of the method according to one of claims 1 to 15.
28. A decoder configured to implement the steps of the method according to one of claims 16 to 26.
29. A non-transitory computer readable medium storing a program which 20 when executed by a microprocessor or computer system in a device cause the device to perform the method according to one of claims 1 to 26.
Intellectual
Property
Office
Application No: GB 1612934.8 Examiner: Mr Iwan Thomas
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB201612934A GB2552510B (en) | 2016-07-26 | 2016-07-26 | Mesh partitioning and merging methods |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB201612934A GB2552510B (en) | 2016-07-26 | 2016-07-26 | Mesh partitioning and merging methods |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| GB201612934D0 GB201612934D0 (en) | 2016-09-07 |
| GB2552510A true GB2552510A (en) | 2018-01-31 |
| GB2552510B GB2552510B (en) | 2020-01-01 |
Family
ID=56894571
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| GB201612934A Expired - Fee Related GB2552510B (en) | 2016-07-26 | 2016-07-26 | Mesh partitioning and merging methods |
Country Status (1)
| Country | Link |
|---|---|
| GB (1) | GB2552510B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2024083043A1 (en) * | 2022-10-19 | 2024-04-25 | 维沃移动通信有限公司 | Grid coding method and apparatus, communication device, and readable storage medium |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113240786B (en) * | 2021-05-10 | 2023-06-13 | 北京奇艺世纪科技有限公司 | Video point cloud rendering method and device, electronic equipment and storage medium |
| CN114329058B (en) * | 2021-12-29 | 2023-05-16 | 重庆紫光华山智安科技有限公司 | Image file gathering method and device and electronic equipment |
| CN116934880A (en) * | 2022-04-08 | 2023-10-24 | 维沃移动通信有限公司 | Encoding and decoding methods, devices and equipment |
-
2016
- 2016-07-26 GB GB201612934A patent/GB2552510B/en not_active Expired - Fee Related
Non-Patent Citations (1)
| Title |
|---|
| Zhang Z. et al., "Automatic Segmentation Technique for Triangular Meshes", 2011, Transactions of the Japan Society for Computational Engineering and Science, pages 1-7 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2024083043A1 (en) * | 2022-10-19 | 2024-04-25 | 维沃移动通信有限公司 | Grid coding method and apparatus, communication device, and readable storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| GB2552510B (en) | 2020-01-01 |
| GB201612934D0 (en) | 2016-09-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10552987B2 (en) | Encoding and decoding of texture mapping data in textured 3D mesh models | |
| GB2552510A (en) | Mesh partitioning and merging methods | |
| JP4452242B2 (en) | Progressive 3D mesh information encoding / decoding method and apparatus | |
| US10798389B2 (en) | Method and apparatus for content-aware point cloud compression using HEVC tiles | |
| CN106548498B (en) | Method and apparatus for processing compressed textures | |
| JP2022539411A (en) | Point cloud encoding method, point cloud decoding method, encoder, decoder and computer storage medium | |
| JP4808771B2 (en) | Apparatus and method for encoding and decoding three-dimensional mesh information | |
| CN110383696B (en) | Method and apparatus for encoding and decoding super-pixel boundaries | |
| CN116997935A (en) | Block compression for grid compression | |
| US20220180567A1 (en) | Method and apparatus for point cloud coding | |
| Derzapf et al. | Dependency‐free parallel progressive meshes | |
| WO2023172703A1 (en) | Geometry point cloud coding | |
| CN116940965A (en) | Slice time aligned decoding for trellis compression | |
| JP6517922B2 (en) | Extension to MPEG / SC3DMC standard polygon mesh | |
| KR102313555B1 (en) | System and method for 3D Model compression and decompression based on 3D Mesh | |
| JP2022187683A (en) | Data compression/decompression system and method | |
| JP3938054B2 (en) | Computer-readable storage medium on which data having an image data structure is recorded, image recording method, apparatus, and program | |
| KR20230137234A (en) | Method and Apparatus for Mesh Compression Using Octree-based Trisoup Coding | |
| Bajaj et al. | Compression and coding of large cad models | |
| US20230410374A1 (en) | Method and apparatus for mesh compression using point cloud coding | |
| Bordignon et al. | Point set compression through BSP quantization | |
| US20230156222A1 (en) | Grid-based patch generation for video-based point cloud coding | |
| KR20230135646A (en) | Encoding patch temporal alignment for mesh compression. | |
| Antonijevic | Compression of Sequential Voxel Data for Sequence-based Animation | |
| KR20240001126A (en) | Information processing devices and methods |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PCNP | Patent ceased through non-payment of renewal fee |
Effective date: 20230726 |