FR2786590A1

FR2786590A1 - Procede et dispositif de codage/decodage a maillage tridimensionnel pour resilience vis-a-vis des erreurs et rendu incremental

Info

Publication number: FR2786590A1
Application number: FR9914938A
Authority: FR
Inventors: Sung Jin Kim; Mun Sup Song; Euee Seon Jang; Mahn Jin Han; Seok Yoon Jung; Yang Seock Seo
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 1998-12-01
Filing date: 1999-11-26
Publication date: 2000-06-02
Anticipated expiration: 2019-11-26
Also published as: FR2786590B1; JP3361492B2; US6577310B1; JP2000194843A; NL1013639C2; NL1013639A1

Abstract

Procédé de codage et de décodage de données de maillage tridimensionnel (3D) progressif et résilient vis-à-vis des erreurs utilisé dans les domaines du codage hybride synthétique et naturel du groupe des experts en images animées de type 4 (MPEG-4 SNHC), du langage de modélisation de réalité virtuelle (VRML), et analogues. Lors d'une transmission d'objets en 3D composés de données de maillage en 3D, il est très important de restaurer de façon progressive et résiliente vis-à-vis des erreurs les données transmises tout comme de coder de manière efficace les données de maillage 3D. Dans la restauration progressive, dans l'éventualité où une erreur de transmission de données est générée, la restauration partielle des données transmises est autorisée. Ainsi, il est possible de minimiser la quantité de données de maillage devant être retransmises et le temps d'attente d'un utilisateur. Le procédé de restauration progressif qui est résistant à de telles erreurs de transmission peut être efficacement appliqué dans des communications sans fil ou des communications à faible taux de transmission. Dans le procédé de codage et de décodage progressif et résilient vis-à-vis des erreurs, la connectivité, la géométrie et la photométrie nécessaires pour coder progressivement des données de maillage en 3D sont construites et ensuite codées/ décodées, permettant de ce fait la construction incrémentale et la résilience aux erreurs.

Description

PROCEDE ET DISPOSITIF DE CODAGE/DECODAGE A MAILLAGE
TRIDIMENSIONNEL POUR RESILIENCE VIS-A-VIS DES ERREURS ET
RENDU INCREMENTAL
La présente invention se rapporte à un procédé progressif et à un dispositif de codage/décodage de données de maillage tridimensionnel (3D) caractérisés par leur résilience vis-à-vis des erreurs et leur construction incrémentale, utilisés dans les domaines du codage hybride synthétique et naturel du groupe des experts en images animées de type 4 (MPEG-4 SNHC), du langage de modélisation de réalité virtuelle (VRML), et analogues.

Lors d'une transmission d'objets tridimensionnels composés de données de maillage tridimensionnel, il est très important de restaurer de façon incrémentale et résilient vis-à-vis des erreurs les données transmises tout comme de coder de manière efficace les données de maillage tridimensionnel. Dans l'éventualité où une erreur de données est générée du fait d'une erreur de trajet de transmission, une restauration progressive permet aux données transmises d'être partiellement restaurées et minimise la quantité de données de maillage devant être transmises. Une restauration résilient vis-à-vis des erreurs permet aux données transmises d'être restaurées indépendamment en unités des données transmises, sans considération de la présence d'erreurs générées dans une unité spécifique des données transmises, ce qui a pour effet l'amélioration de l'efficacité de restauration de données et la réduction des temps d'attente d'un usager. Le procédé de restauration progressive et résilient aux erreurs qui est robuste à de telles erreurs de trajet de communication peut être utilisé de manière efficace dans des communications sans fil et dans des communications à faible vitesse de transmission. Les buts de la présente invention sont de construire la connectivité, la géométrie

et la photométrie nécessaires pour coder des données de maillage en 3D progressivement et procurer la résilience vis-à-vis des erreurs de données, et de proposer un procédé de codage/décodage de celles-ci.

Dans le processus de codage classique de données de maillage tridimensionnel, étant donné que les données de maillage sont entièrement codées, il est pratiquement impossible de restaurer partiellement des données avant qu'un flux binaire soit reçu dans sa totalité. De même, du fait des erreurs de trajet de transmission générées durant une transmission, même si seule une partie des données est endommagée, le flux binaire de données entier doit être reçu de nouveau. Par exemple, la norme ISO/IEC JTC1/SC29/WG11 MPEG98/W23C1, le "MPEG-4 SNHC Vérification Model 9. 0" proposé par IBN Corp. est couramment adopté en tant que technologie de codage de maillage en 3D MPEG-4 SNHC.

Dans le MPEG-4 SNHC, un codage de maillage est conçu sur la base d'un VRML. Dans le VRML, un maillage est décrit sous une forme de noeuds appelée Ensemble-de-FacettesIndexées. L'une des principales technologies destinées à coder des données de maillage est une chirurgie topologique proposée par IBM Corp. Conformément à cette technologie, il est admis que tout maillage donné est topologiquement identique à une sphère. Puis, le maillage est découpé le long d'une arête de coupe donnée de manière à générer un graphe développé des triangles ayant une structure arborescente binaire. Ici, l'arête de coupe définie pour couper le maillage est configurée de manière à connecter les sommets du maillage, c'est-à-dire qu'elle est conçue comme une structure arborescente présentant une boucle.

L'arête de coupe est appelée graphe développé de sommets.

De cette manière, deux structures arborescentes, c'est-àdire le graphe développé des triangles et le graphe développé des sommets, sont codées/décodées, restaurant de

ce fait le maillage original sans perte.

Conformément au MPEG-4 SNHC, bien que l'on puisse trouver de nombreux Ensembles-de-Facettes-Indexées dans un fichier VRML, une compression est généralement réalisée sur l'unité de l'un des Ensembles-de-Facettes-Indexées.

Cependant, il est permis de former un seul Ensemble-deFacettes-Indexées par plusieurs composantes reliées.

En règle générale, lors d'un traitement rapide de graphes, une modélisation peut être réalisée sous la forme d'unités de triangles. Ces triangles ne sont pas formés de manière aléatoire mais sont de préférence reliés entre eux en formant des bandes ou des faisceaux. De même, plus les symboles sont représentés de manière répétitive, meilleure est la compressibilité. A cette fin, un maillage formé par une longue bande unique de triangles est proposé par IBM Corp. en vue d'un traitement de graphe rapide et d'une meilleure compressibilité.

Les figures 1A à 1F représentent un processus classique destiné à générer un graphe développé des sommets et un graphe développé des triangles, dans un exemple de maillage en triangles. Les figures 1A et 1D représentent un procédé de découpage d'un maillage le long d'arêtes de coupe, représentées par un trait épais. La figure 1B représente le format général des arêtes de coupe. La figure lE représente la configuration des arêtes et des sommets produits par la découpe le long des arêtes de coupe représentées sur la figure 1B. La figure 1C représente un graphe développé des sommets réalisé en connectant des sommets faisant référence à des points de coupe. La figure 1F représente un graphe développé des triangles défini comme une bande qui est un ensemble de triangles reliés obtenu par découpage du maillage le long du graphe développé des sommets. De même, si le graphe développé des triangles est généré par le procédé représenté sur les figures 1A à 1F, la longueur de l'un des deux parcours de

branches du graphe développé des triangles devient considérablement plus court que l'autre.

Les figures 2A à 2D représentent un exemple d'une technique de chirurgie topologique appliquée aux données de maillage réelles. Dans un graphe développé des sommets, une branche peut se ramifier en plusieurs branches. La figure 3 représente un exemple d'un graphe développé des sommets possédant une boucle, dans lequel un parcours de sommets revient à l'emplacement de l'un des sommets précédents.

Etant donné qu'un maillage peut être formé de nombreuses composantes reliées, chaque composante reliée formant le maillage génère une paire formée d'un graphe développé des sommets représenté sur la figure 1F et d'un graphe développé des triangles représenté sur la figure 1C. Par conséquent, si seul un Ensemble-de-Facettes-Indexées est codé, plusieurs paires de graphes développés des triangles et de graphes développés des sommets peuvent être obtenues.

Le procédé destiné à restaurer les données codées à l'aide du procédé de technologie chirurgicale topologique décrit ci-dessus est le suivant :
1. Une boucle de liaison est générée par l'utilisation d'un graphe développé des sommets.

2. Lorsque le troisième sommet d'un triangle dont les branches se séparent pour former une arborescence développée des triangles, dénommé sommet Y, le sommet Y est calculé en utilisant les flux binaires de l'arborescence développée des triangles, et des jeux de triangles ou polygones possédant la connectivité en forme de bande sont générés. Ici, les triangles ou polygones sont générés par utilisation d'un bit de progression des triangles du graphe développé des triangles.

3. Les maillages sont restaurés en accord avec la géométrie topologique en utilisant les données de maillage d'une structure arborescente construite à travers les étapes 1 et 2.

Une compression sans perte qui utilise un codage arithmétique du graphe développé des sommets et du graphe développé des triangles a été proposée par IBM Corp.

Cependant, conformément à ce procédé, en vue de reconstruire la structure originale, tous les flux binaires doivent être entrés et les problèmes suivants apparaissent :
1. Etant donné que tous les flux binaires doivent être entrés en vue de décoder les données de maillage, dans l'éventualité d'une erreur de transmission tous les flux binaires doivent être de nouveau transmis.

2. Dans le cas où le volume des données compressées est important, par comparaison avec la largeur de bande, un long moment est nécessaire à la transmission complète des données et un utilisateur doit attendre durant tout ce temps. De façon à réduire le temps d'attente de l'usager, les maillages doivent être partiellement restaurés et rendus en utilisant les données transmises. Toutefois, avec les technologies actuelles, le nombre de triangles qui peuvent être restaurés est faible, comparé à la quantité de bits transmis, en regard de la structure de flux binaires.

Afin de surmonter les inconvénients de la technologie classique, les fonctions suivantes doivent être satisfaites :
1. Les données de maillage doivent être partagées selon une taille d'unité effective en vue de la largeur de bande d'un trajet de transmission ou des caractéristiques d'un décodeur, et la résilience vis-à-vis des erreurs doit être permise de façon que les flux binaires possédant la taille d'unité soient restaurés et rendus par le décodeur.

2. Les procédés de codage/décodage incrémental doivent être autorisés de façon que la restauration et le rendu partiels d'une partie seulement des données en cours de réception soit possible.

Une mise en #uvre de ces deux fonctions, tout en

maintenant la structure de base du procédé classique proposé par IBM Corp., dépend d'un traitement efficace de la boucle de liaison et du sommet Y, comme cela est représenté sur la figure 4. Sur la figure 1F, les points 10, 14 et 18 sont des sommets Y. De façon à calculer un sommet Y, un des deux parcours de triangles de branches au moins doit être traité. En d'autres termes, pour des triangles à l'intérieur d'un parcours de triangles, des index pour les trois sommets de chaque triangle peuvent être déterminés grâce à l'utilisation de la configuration de bits de progression et de la boucle de liaison.

Cependant, en vue de déterminer les index des sommets Y qui sont les troisièmes sommets des triangles d'embranchement, tous les flux binaires destinés à l'un des deux parcours de triangles se trouvant à proximité des triangles d'embranchement doivent être reçus. Par conséquent, les triangles se trouvant à proximité des triangles d'embranchement ne peuvent pas être restaurés pour être affichés jusqu'à ce que les flux binaires ultérieurs soient reçus. Ce problème ne survient pas dans le procédé classique proposé par IBM Corp., qui se fonde sur la supposition que tous les flux binaires sont reçus dans le décodeur. Cependant, en vue de restaurer et d'afficher des triangles de façon incrémentale, ce problème doit être résolu.

Les définitions des termes utilisés dans la technique apparentée à l'invention seront décrites comme suit.

# Maillage polygonal : un maillage polygonal est défini par les coordonnées (géométrie) dans un espace en 3D de sommets, la relation (connectivité) entre les faces respectives et les sommets formant les faces, et les informations de photométrie telle que couleur, normal ou texture, qui n'affectent pas la structure géométrique d'un maillage mais affecte l'apparence d'un maillage.

# Face : une face est un jeu d'index de sommet et un coin

est une paire (face, sommet) de jeux. Une face simple est un jeu d'index de sommet dans lequel différents index forment une face. Dans cette invention, seul un maillage polygonal constitué de faces simples sera traité.

. Arête: une arête est une paire d'index de sommet. Si une arête apparaît sur une face seulement dans un maillage polygonal, l'arête est définie comme une arête "de limite".

Si une seule et même arête apparaît sur plusieurs faces, l'arête est définie comme une arête "singulière". Si une arête apparaît sur deux faces voisines seulement, l'arête est définie comme une arête "interne". L'arête de limite et l'arête interne sont définies comme "ordinaires".

# Graphe double : un point est défini à l'intérieur de chaque face d'un maillage et ensuite les points définis audessus et passant à travers l'arête interne entre faces voisines sont reliés pour être définis comme un graphe double. La figure 5A illustre un maillage polygonal et la figure 53 est un graphe double du maillage polygonal représenté sur la figure 5A.

# Largage de modélisation de réalité virtuelle (VRML) : le VRML est un format standard graphique conçu pour la description et la transmission d'un espace virtuel sur Internet.

Groupe des experts en images animées (MPEG) : le MPEG est un groupe servant à mettre en #uvre des activités de normalisation internationale pour la normalisation des formats de compression afin de transmettre une variété de supports tels que la vidéo.

# Maillage : un maillage est une représentation d'un objet structuré sous forme de plusieurs polygones.

# Noeud : un noeud est un sommet dans un graphe développé des sommets ou une unité de description minimale utilisée dans le VRML.

# Chirurgie topologique : la chirurgie topologique est un procédé de codage de maillage proposé par IBM Corp. dans

lequel un maillage est découpé le long d'un trajet donné en vue de faire prendre au maillage la forme de bandes.

# Graphe développé des sommets : un graphe développé des sommets est un trajet servant à découper un maillage en chirurgie topologique.

# Graphe développé de triangles : un arbre développé de triangles est un arbre binaire en forme de bande en triangles produite en coupant une maille le long du graphe développé des sommets.

# vlast : vlast indique si le parcours en cours est ou non la dernière branche. Si le parcours en cours est la dernière branche, la valeur du vlast est 1 et sinon elle est 0.

# vleaf : vleaf indique si le parcours des sommets en cours se termine par une feuille ou une branche. Si le parcours des sommets en cours se termine par une feuille, la valeur du vleaf est 1 sinon elle est 0. vrun : un vrun est un ensemble de sommets et d'extrémités connectés avec une branche ou un vleaf. vlength est la longueur d'un parcours de sommets. départ-de-boucle : la feuille d'un parcours de sommets peut rencontrer un autre parcours de sommets de manière à former une boucle. Dans un tel cas, le départ de la boucle est indiqué par un départ-de-boucle.

# fin-de-boucle : dans le cas où la feuille d'un parcours de sommets forme une boucle, l'extrémité de la boucle est indiquée par une fin-de-boucle.

# matrice-de-boucle : une matrice-de-boucle indique la connectivité entre le départ-de-boucle et la fin-de-boucle et c'est un jeu d'index reliant les arêtes de la fin-deboucle au départ-de-boucle.

# trun : trun est un ensemble de triangles consécutifs et leur extrémité est un triangle feuille ou un triangle d'embranchement.

# tleaf : tleaf indique si le parcours d'un triangle se

termine par un triangle feuille ou par un triangle d'embranchement. Si le parcours d'un triangle se termine par un triangle feuille, la valeur de tleaf est 1 sinon elle est 0.

# tmarching : tmarching décrit l'aspect de progression des triangles. Si une bande présente une arête sur sa limite droite, la valeur de tmarching est de 1. Si une bande présente une arête sur sa limite gauche, la valeur de tmarching est de 0.

# polygonedge : polygonedge indique si une arête actuelle est donnée à partir du modèle de maillage original ou insérée pour représenter le polygone sous la forme d'un ensemble de triangles. Si une arête en course est donnée à partir du modèle de maillage original, la valeur de polygonedge est 1 sinon elle est 0.

# triangulated : triangulated indique la présence d'un polygone dans la maille.

# nvertices : nvertices indique le nombre de sommets.

# nloops : nloops indique le nombre de boucles. nvedges : nvedges indique la grandeur d'un vrun. nvleaves : nvleaves indique le nombre de feuilles dans un graphe développé des sommets.

# bitspernvedges : bitspernvedges indique le nombre de bits utilisés pour nvedges.

# simple : si des boucles sont présentes dans un graphe développé des sommets, la valeur de simple est 0, et sinon 1.

# ntriangles : ntriangles indique le nombre de triangles dans un graphe développé de triangles.

# ntbranches : ntbranches indique le nombre de triangles partant en branches dans un graphe développé de triangles.

# nmarchingtrans et nmarchingkeepleft sont des modèles statistiques pour la compression de Tmarching.

# npolytrans et nkeeppoly sont des modèles statistiques pour la compression de Polygonedge.

La figure 6 est un schéma synoptique sous forme de blocs conceptuel d'un procédé de codage d'informations de maillage tridimensionnel (3D). Sur la figure 6, un objet maillé en 3D 100 est divisé en informations de connexion, de géométrie et de photométrie, et codé grâce à une partie de codage 101 incluant un codeur de connexion 102, un codeur de géométrie 103 et un codeur de photométrie 112.

Ici, des informations de structure en sommets 105 sont transmises depuis le codeur de connexion 102 au codeur de géométrie 103. Les informations compressées par le codeur de connexion 102, le codeur de géométrie 103 et le codeur de photométrie 112 sont combinées en un flux binaire et le flux binaire est compressé en flux binaire compressé 111 par un codeur d'entropie 104.

Le flux binaire compressé 111 est entré dans une partie de décodage 112. En d'autres termes, le flux binaire compressé 111 est décompressé et divisé en informations de connexion, de géométrie et de photométrie via un décodeur d'entropie 106, pour être ensuite décodé par un décodeur de connexion 107, un décodeur de géométrie 108 et un décodeur de photométrie 113, respectivement. De manière analogue à la partie de codage 101, des informations de structure en sommets 109 sont transmises du décodeur de connexion 107 au décodeur de géométrie 108. Un objet maillé tridimensionnel décodé 110 peut être construit en utilisant les informations de connexion, de géométrie et de photométrie décodées.

Comme cela est représenté sur la figure 6, un maillage en 3D peut être transmis sous la forme d'un flux binaire compressé sur un trajet de communication. Cependant, étant donné que le procédé de compression de données MPEG classique utilise le codeur d'entropie 104, le procédé est vulnérable à des erreurs de transmission générées sur le trajet de communication. Par conséquent, la présente invention propose une technologie pour résoudre les

problèmes d'erreurs de transmission et restaurer progressivement des données de maillage en 3D en utilisant la connectivité, la géométrie et d'autres informations transmises.

Afin de résoudre les problèmes ci-dessus, un but de la présente invention est de proposer un procédé destiné à coder/décoder progressivement des informations de maillage en 3D, par lequel une charge de réseau et un temps de transmission peuvent être réduits en retransmettant seulement une partie dans laquelle une erreur de transmission a été générée ou en restaurant les données indépendamment de la partie possédant une erreur de transmission, une augmentation du nombre de bits générés due à une restauration d'erreur dépendante des couches du réseau peut être minimisée, et l'information de maillage en 3D peut être restaurée progressivement en utilisant la connectivité, la géométrie et la photométrie de la partie transmise.

En conséquence, pour atteindre les objectifs cidessus, il est proposé un procédé de codage d'un objet maillé (OM) tridimensionnel (3D) comprenant les étapes consistant à (a) diviser l'OM 3D polygonal en une ou plusieurs composantes reliées, (b) générer un graphe de sommets et un arbre triangles/données triangles pour chacune des composantes reliées et (c) reconstruire le graphe de sommets et l'arbre triangles/données triangles constituant la composante reliée en conformité avec les couches de base d'objet maillé (CBOM), chacune étant susceptible d'être décodée indépendamment pour les composantes reliées respectives et codée de la même manière.

Selon un autre aspect de l'invention, il est proposé un procédé progressif et résilient vis-à-vis des erreurs de codage d'un objet maillé (OM) tridimensionnel (3D) polygonal comprenant les étapes consistant à (a) diviser

l'OM 3D polygonal en une ou plusieurs composantes reliées, (b) générer un graphe de sommets et une paire d'arbres triangles/données triangles pour chacune des composantes reliées et (c) coder le graphe de sommets et l'arbre triangles/données triangles constituant les composantes reliées en conformité avec les couches de base d'objet maillé (CBOM), chacune possédant un type fixe de flux binaires capable d'être décodé indépendamment pour les composantes reliées respectives.

Selon la présente invention, il est également proposé un procédé progressif et résilient vis-à-vis des erreurs de codage d'un objet maillé (OM) tridimensionnel (3D) polygonal comprenant les étapes consistant à (a) diviser l'OM 3D polygonal en une ou plusieurs composantes reliées, (b) générer un graphe de sommets et une paire d'arbres triangles/données triangles pour chacune des composantes reliées et (c) coder le graphe de sommets et l'arbre triangles/données triangles constituant les composantes reliées en conformité avec les couches de base d'objet maillé (CBOM), chacune possédant un type variable de flux binaire en accord avec les propriétés d'informations à coder, capable d'être indépendamment décodé pour les composantes reliées respectives.

Selon un autre aspect de l'invention, il est proposé un procédé progressif et résilient vis-à-vis des erreurs de codage d'un objet maillé (OM) tridimensionnel (3D) polygonal comprenant les étapes consistant à (a) diviser l'OM 3D polygonal en une ou plusieurs composantes reliées, (b) générer un graphe de sommets et une paire d'arbres triangles/données triangles pour chacune des composantes reliées, (c) coder le graphe de sommets constituant les composantes reliées, et (d) construire l'arbre triangles/données triangles comme composantes reliées virtuellement et coder celles-ci en additionnant les paires de bits virtuels aux partitions de données obtenues en

divisant l'arbre triangles/données triangles.

Afin d'atteindre le but ci-dessus de la présente invention, dans le codage d'un objet maillé (OM) tridimensionnel (3D) triangle pour construction incrémentale et résilience vis-à-vis des erreurs, il est proposé un procédé de partition de l'OM 3D triangle en partitions devant être mises en paquets, le procédé incluant les étapes consistant à (a) calculer les quantités de génération de bits totales des triangles pendant que les triangles contenus dans un arbre triangles sont traversés en séquences, (b) cumuler les quantités de génération de bits totales calculées à l'étape (a), et (c) si la valeur cumulée de l'étape (b) est plus petite que le produit d'une taille de paquet et d'une ration de paquet, exécuter de façon répétitive les étapes (a) et (b) sur le triangle traversé suivant contenu dans l'arbre triangles, et sinon les arbres triangles/données triangles des triangles traversés sont divisés en partitions pour être mises en paquets.

La présente invention propose aussi un procédé progressif et résilient vis-à-vis des erreurs de codage d'un objet maillé (OM) tridimensionnel (3D) polygonal comprenant les étapes consistant à (a) diviser les flux binaires d'entrée en unités de couches de base d'objet maillé (CBOM), (b) déterminer un type de partition des CBOM, (c) si un graphe de sommets est contenu dans les CBOM, décoder le graphe de sommets afin de générer une table de boucle englobante, (d) si l'arbre triangles/données triangles est contenu dans les CBOM, décoder l'arbre triangles/données triangles pour générer l'OM 3D, et (e) exécuter de façon répétitive les étapes (a) à (d) pour générer un OM 3D.

Selon un autre aspect de la présente invention, il est proposé un procédé progressif et résilient vis-à-vis des erreurs de codage d'un objet maillé (OM) tridimensionnel

(3D) polygonal comprenant les étapes consistant à (a) diviser les flux binaires d'entrée en unités de couches de base d'objet maillé (CBOM), (b) déterminer un type de partition des CBOM, (c) si un graphe de sommets est contenu dans les CBOM, décoder le graphe de sommets afin de générer une table de boucle englobante, (d) si l'arbre triangles/données triangles est contenu dans les CBOM, décoder l'arbre triangles/données triangles en unités de composantes reliées pour générer un OM 3D triangle, et (e) si les composantes reliées à l'étape (d) sont des composantes reliées virtuelles, exécuter de façon répétitive les étapes (a) à (d), et sinon compléter la génération d'un OM 3D triangle.

Les buts ci-dessus et les avantages de la présente invention deviendront plusapparents en décrivant en détails un mode de réalisation préféré de celle-ci en faisant référence aux dessins en annexe dans lesquels :
Les figures 1A à 1F illustre un procédé classique de génération d'un graphe développé de sommets et un graphe développé de triangles dans un exemple de maillage triangulaire ;
Les figures 2A à 2D illustrent un exemple de chirurgie topologique ;
La figure 3 illustre un exemple de graphe développé de sommets possédant une boucle ;
La figure 4 illustre la formation d'une boucle englobante dans une chirurgie topologique ;
Les figures 5A et 5B illustrent un maillage polygonal et un exemple d'un graphe double de celui-ci ;
La figure 6 est un diagramme conceptuel d'un procédé de codage d'informations de maillage tridimensionnel (3D) ;
La figure 7 est un diagramme conceptuel d'une représentation d'information d'objet maillé (OM) 3D ;
Les figures 8A et 8B illustrent des exemples d'objet maillé (OM) 3D et de couche de base d'objet maillé

(CBOM) ;
La figure 9 est un diagramme conceptuel montrant la relation entre une paire d'arbre triangles et de données de triangles dans un index de boucle englobante ;
Les figures 10A à 10C sont des diagrammes conceptuels de codage utilisant l'information d'orientation ;
Les figures 11A et 11B sont des diagrammes pour comparer les ordres de codage dépendant de la présence d'information d'orientation ;
Les figures 12A à 121 illustrent un procédé fixe de partition de données ;
Les figures 13A et 13B sont des diagrammes conceptuels de partition de données ;
Les figures 14A à 14D illustrent un procédé de partition de données variable ;
Les figures 15A à 15D illustrent les partitions qui sont effectuées par le procédé de partition de données variable ;
La figure 16 illustre une partition de données dans une branche principale ;
La figure 17 illustre une partition de données utilisant le moyen tt ;
Les figures 18A à 18C illustrent un procédé de formation de composantes reliées virtuelles ;
La figure 19 illustre un exemple de transformation d'un polygone maillé en triangle maillé ;
Les figures 20A à 20E illustrent des exemples de partition en maillage polygonal et syntaxes de celui-ci ;
La figure 21 illustre un procédé d'indexage d'une boucle englobante et un procédé de codage de l'information d'en-tête des partitions produites ici ;
La figure 22 illustre une partition de données comprenant une boucle englobante ;
Les figures 23A et 23B illustrent des procédés de définition d'index de boucle englobante ;

Les figures 24A à 24E illustrent des procédés de codage de géométrie ;
Les figures 25A et 25B illustrent les syntaxes pour disposer les données telles que géométrie, couleur, information normale ou texCoord ; et
La figure 26 est un diagramme conceptuel d'un procédé de codage de géométrie.

Pour le traitement progressif d'un objet maillé 3D, dans la présente invention, une nouvelle structure de maille représentée sur la figure 7 est proposée. Ainsi que représenté sur la figure 7, un objet maillé 3D (OM) peut être divisé en plusieurs composantes reliées ou non reliées. Les composantes contenues dans l'objet maillé 3D peuvent être reconstruites comme plusieurs couches d'objet maillé (COM). Ici, chaque COM contient une ou plusieurs couches de base d'objet maillé (CBOM). La COM contient les connectivité, géométrie et photométrie nécessaires à sa propre restauration. En d'autres termes, l'OM est défini comme l'unité d'un objet maillé 3D à coder et il est divisé en plusieurs couches selon une qualité d'image variable et des fonctions de données de maillage. Chaque couche est définie comme une couche d'objet maillé (COM). De même, lorsqu'un objet maillé 3D est formé de plusieurs unités de données de maillage indépendantes non reliées (c'est-àdire, composantes reliées), les unités de données de maillage indépendantes sont combinées ou divisées en fonction de la taille de données à coder ou autres caractéristiques, ce qui est défini comme une couche de base d'objet maillé.

Les figures 8A et 8B illustrent un objet maillé 3D et des couches de base d'objet maillé (CBOM).

Dans la nouvelle structure de maillage ci-dessus décrite, un procédé de détermination de l'index d'une boucle englobante, dans laquelle est prise en compte un sommet Y, est nécessaire pour exécuter efficacement la

restauration/le rendu progressif. De façon à restaurer un maillage triangle, ainsi que représenté sur la figure 9, des index de boucle englobante de points de départ des limites droite et gauche sont donnés dans une partition de paire d'arbres triangles (tt) et de données triangles (td). Sur la figure 9, la référence alphabétique m indique un index de départ droit, n indique un caractère de départ gauche, et une flèche centrale indique l'ordre des triangles codés. Ici, sur la base de la direction de progression, la limite positionnée sur la droite de la bande triangle est une limite droite, la limite positionnée sur la gauche de la bande triangle est une limite gauche, et le triangle ombré est un triangle d'embranchement. De façon à déterminer les index de boucle englobante des triangles respectifs de la paire tt/td, l'information suivante est en outre nécessaire.

Triangle avant triangle d'embranchement.

Ainsi que représenté sur la figure 9, dans le cas de triangles avant un triangle d'embranchement, les index de la boucle englobante augmentent de un dans la limite gauche et décroissent de un dans la limite droite. Ainsi, lorsqu'un bit de parcours est décodé, trois sommets du triangle peuvent être immédiatement restaurés.

Triangle d'embranchement
Sur la figure 9, un triangle d'embranchement est composé de trois sommets b[m-3], b[m-10] et b[n+2].

Toutefois, si l'information de triangle de la branche droite dans le triangle d'embranchement, c'est-à-dire l'information sur le nombre de triangles, n'est pas reçue, il n'est pas possible de connaître l'index m-10 dans la boucle englobante du troisième sommet, c'est-à-dire sommet Y. Ainsi, de façon à déterminer l'index du sommet Y, l'information sur le nombre de triangles dans l'une des branches latérales doit être reçue. De façon à connaître le nombre de branches sur un côté, l'information sur le

parcours du triangle dans la paire tt/td est nécessaire. Sur la figure 9, si le nombre de triangles des banches droites est p, le nombre de sommets utilisés peut être facilement déduit comme suit : [Formule 1]
Nombre de sommets utilisés dans une branche latérale = p + 2.

Par exemple, sur la figure 9, les index de la boucle englobante du troisième sommet, par exemple sommet Y, du triangle d'embranchement, peuvent être déterminés en utilisant le fait que l'index du sommet sur la limite droite est m - 3 et que le nombre de triangles dans la branche est 6, comme suit :
Index du sommet Y= (m-3)-(6+2-1)=m-3-7=m-10.

Triangles dans la branche partant du triangle d'embranchement
Dans le cas où le sommet Y est fourni, les triangles respectifs peuvent être restaurés et rendus de la même manière que dans le cas où le triangle précédant un triangle d'embranchement est traité. Toutefois, si le sommet Y du triangle d'embranchement n'est pas déterminé, les index des sommets du triangle ne peuvent pas être déterminés. Ceci parce que les index des sommets positionnés sur la limite gauche ne peuvent pas être déterminés si le sommet Y de la branche droite représentée sur la figure 9 n'est pas déterminé.

Ainsi que décrit ci-dessus, pour une restauration et un rendu progressifs, les sommets Y doivent être effectivement déterminés. Par conséquent, dans la présente invention, un procédé permettant une restauration et un rendu progressifs en résolvant le problème du sommet Y survenant au triangle d'embranchement est proposé.

De même, dans la présente invention, pour la résilience vis-à-vis des erreurs, lors de la partition des données de maillage par rapport à la largeur de bande du

trajet de transmission ou des caractéristiques d'un décodeur, deux procédés, c'est-à-dire, un procédé de partition fixe et un procédé de partition variable, sont utilisés. La restauration et le rendu indépendants des données divisées seront décrits ci-dessous. Ici, alors que le procédé de partition fixe utilise un procédé de partition identique pour tous les modèles donnés, le procédé de partition variable utilise différents procédés de partition selon le type de flux binaire couvert par la partition de données, c'est-à-dire graphe de sommets, arbres triangles, données triangles et semblables.

<Procédé de codage progressif avec sommet Y pris en considération>
Dans la topologie chirurgicale classique, l'ordre de codage est fixé par rapport à toutes les paires de tt/td.

Selon ce procédé, de façon à améliorer seulement la performance de rendu progressif, les informations contenant les index et le nombre total de tous les sommets Y générés dans les données de maillage sont transmises à un décodeur avec les flux binaires. Toutefois, ce procédé est indésirable vis à vis de l'efficacité de codage. Par conséquent, un procédé de codage plus efficace pouvant satisfaire les deux besoins, c'est-à-dire un effet de rendu progressif' et une haute efficacité de codage, est nécessaire.

En chirurgie topologique, le rendu progressif basé sur la restauration de polygones ne peut pas être atteint efficacement parce que la différence des longueurs d'arbres dépendants est grande, et la détermination efficace de l'index du sommet Y du triangle d'embranchement pour lequel l'arbre dépendant a des données de grande taille ne peut pas être obtenue. Par conséquent, si les longueurs d'arbres dépendants sont différentes, c'est-à-dire si les tailles de deux branches d'embranchement ne sont pas uniformes, il est plus efficace de coder d'abord la plus petite branche en

vue de la détermination de sommet Y et du rendu. Ici, si les données sont obtenues par la chirurgie topologique montrée sur les figures 2A à 2D, le nombre de triangles d'une branche latérale peut être plus petit que celui de l'autre branche latérale. Par conséquent, un procédé de détermination de l'ordre de traversée sur la base de triangles d'embranchement en offrant les informations d'orientation en fonction de la taille des arbres dépendants, qui n'est pas défini dans la chirurgie topologique, est proposé dans la présente invention. En d'autres termes, si l'information d'orientation est "1", l'ordre de traversée est le même que celui donné initialement. Par conséquent, la branche gauche (ou droite) est visitée en premier. Autrement, si l'information d'orientation est "0", la branche droite (ou gauche) est visitée en premier pour être codée. Par conséquent, les effets de décodage et rendu progressifs peuvent être améliorés par transmission de l'information d'orientation à un codeur. De même, comme l'information d'orientation permet à un arbre de maillage arbitraire d'être divisé en un arbre principal et en un arbre dépendant, une partition de données plus efficace peut être réalisée tout en conservant la connectivité.

Les figures 10A à 10C illustrent un exemple de codage utilisant l'information d'orientation, dans lequel des triangles ombrés sont des triangles d'embranchement présents à la branche principale et possédant l'information d'orientation, les lignes à l'intérieur de l'arbre de maillage binaire indiquent une branche principale possédant des arbres dépendants, et des lignes à l'extérieur de l'arbre de maillage binaire indiquent l'ordre de traversée dans un arbre dépendant, c'est-à-dire une direction de cartographie des index de la boucle englobante dans un décodeur. Ici, les directions de cartographie des index de la boucle englobante, telles que représentées sur la figure

10A, peuvent être déterminées pour être identiques à l'information d'orientation de chaque arbre dépendant. Au contraire, les directions de cartographie des index de la boucle englobante peuvent toutes être définies comme horaires ou anti-horaires, sans relation avec de l'information d'orientation de chaque arbre indépendant. En supposant que le nombre de triangles à l'intérieur de l'arbre dépendant devant être restauré soit t, les formules de calcul des valeurs de sommet Y différent selon l'information d'orientation comme suit.

Dans le cas de codage de la branche droite en premier (c'est-à-dire, quand la valeur d'orientation est 1)
Si l'index du sommet d'un triangle d'embranchement dans la limite droite de la boucle englobante est p, l'index de sommet Y est comme suit :
Position de sommet Y = p-t-1.

Dans le cas de codage de la branche gauche en premier (c'est-à-dire, quand la valeur d'orientation est 0)
Si l'index de sommet du triangle d'embranchement sur la limite gauche de la boucle englobante est q, l'index de sommet Y est comme suit :
Position de sommet Y = q+t+1.

Sur les figures 1C3 et 10C, la référence alphabétique "tr" indique un parcours de triangle, "tl" indique une information tleaf, "to" indique une information d'orientation et "tr." indique une information de progression. La figure 10B montre la disposition d'information d'orientation dans un parcours de triangle et la figure 10C montre la disposition d'information d'orientation dans des données triangles. La disposition représentée sur la figure 10B peut aisément être mise en #uvre. La disposition représentée sur la figure 10C permet le rendu immédiatement après que les données de triangles soient restaurées, réduisant de ce fait le temps de retard, et consomme peu de capacité de mémoire dans l'architecture

d'un décodeur par comparaison avec celle représentée sur la figure 10B, de ce fait réduisant le coût.

La figure 11A montre l'ordre de traversée en chirurgie topologique classique, et la figure 11B montre l'ordre de traversée en accord avec les tailles des branches de l'un ou l'autre des côtés des triangles d'embranchement. Les figures 11A et 11B sont des diagrammes servant à montrer la fonction de l'information d'orientation. Un procédé de détermination de l'information d'orientation sera maintenant décrit.

<Codage progressif avec résilience vis-à-vis des erreurs prise en considération>
Dans l'éventualité de perte de données due à des erreurs dans un trajet de transmission de données ou dans un flux binaire généré dans une partie de codage, une partie de décodage doit traiter efficacement le problème.

Ainsi, les données de maillage à coder sont divisées en unités significatives, c'est-à-dire partitions de couches de base d'objet maillé, pour former des partitions, et ensuite les partitions de données sont transmises à l'unité de traitement en ayant une taille prédéterminée (abrégée sous "paquet" ci-dessous). En d'autres termes, un paquet est une gerbe de bits arrangés selon un format spécifique et a une longueur prédéterminée. Si les données possédant une grande longueur sont transmises via un trajet de transmission, le trajet de transmission qui est utilisé par une pluralité d'utilisateurs peut être congestionné. Ainsi, les unités de données transmises sont tenues d'avoir une longueur prédéterminée de façon qu'une pluralité d'utilisateurs puisse se partager le trajet de transmission ayant une capacité limitée. Un paquet est obtenu en liant des flux de données à coder, tandis qu'une partition est obtenue en divisant l'information originelle à coder (maillage) en unités appropriées. Il y a lieu de prendre en considération pendant la partition la possibilité pour les

erreurs générées sur le trajet de transmission d'être traitées efficacement lors de la restauration des données d'un côté récepteur. En d'autres termes, si toutes les mailles sont divisées en parties significatives, les partitions de données sans une erreur peuvent être parfaitement restaurées du côté récepteur, alors que seul le flux binaire possédant une erreur est endommagé jusqu'à ne pas être restauré. Ici, les parties significatives font référence aux parties respectives reliées à une autre dans le traitement d'une image d'animal, par exemple, bras, jambes, corps, etc. Dans la partition, la taille de partition de données n'est pas fixée à un niveau spécifique, contrairement au paquet. Dans la présente invention, des procédés de partition variés sont proposés de façon que les données puissent être restaurées efficacement du côté récepteur même si les données reçues comportent une erreur.

Diviser les données à coder d'une telle manière présente les avantages suivants :
En retransmettant seulement les données possédant une erreur, la charge d'un réseau et le temps d'attente d'un utilisateur peuvent être réduits.

Si l'indépendance parmi les unités de données divisées est assurée, la restauration du maillage et le rendu sont permis en utilisant les données sans erreur, réduisant ainsi le retard de décodage du à l'erreur.

Même si les données de maillage ne sont pas entièrement reçues, les données en cours de réception peuvent être progressivement restaurées et rendues.

Par comparaison avec les procédés de codage selon lesquels l'indépendance parmi les unités de données n'est pas assurée, la capacité de restauration de maillage est élevée parce que les données ne possédant aucune erreur ne sont pas retransmises. Egalement, même dans le cas de retransmission, l'efficacité de retransmission (le temps

d'attente pour décodage) est améliorée.

<Procédé de partition fixe>
Les figures 12A à 121 illustrent un procédé de partition de données fixes, dans lequel la référence alphabétique 'sc' indique un code de départ représentant la position de départ de partition en flux binaires de maillage mis en paquets, 'id' indique un marqueur de partition qui est représenté par code départ CBOM 3D et mobl~id (identificateur COM), respectivement, dans la présente invention. 'vg~id' (identificateur~graphe~sommet) indique un marqueur utilisé pour spécifier le graphe de sommets correspondant à la paire tt/td en cours à restaurer, lorsque plusieurs unités de données de graphe de sommets sont tenues d'être traitées dans les données de maillage construites par plusieurs composantes reliées. Selon la syntaxe de la présente invention, 'vg id' est marqué par codap~vg~id (codap~identificateur~graphe~sommet). L'index de visite 'vi' indique un marqueur représentant index~liaison d'un triangle racine d'une partition, et inclut index~gauche et index~droit, comme cela est représenté sur la figure 4, qui sont indiqués par codap~index~gauche et codap~index~droit, respectivement, dans la syntaxe de la présente invention.

'bp' indique un marqueur représentant prédiction limite et détermine le procédé de codage de géométrie, couleur, normal et textCoord. En d'autres termes, une valeur de 1 indique un procédé de codage dans lequel le codage chevauchant des sommets précédemment codés est autorisé. Une valeur de 0 signifie que les sommets sont codés sans recouvrement. 'bp' est indiqué par codap~prédiction~limite dans la syntaxe de la présente invention. 'lbl' est un marqueur permettant de calculer les index de sommet Y d'un triangle d'embranchement utilisant les données de partition en courses par le décodeur seulement dans le cas où la partition en cours se termine au triangle d'embranchement et indique la taille globale d'un arbre dépendant arbitraire relié au triangle

d'embranchement 'lbl' est indiqué par codap~longueur~branche dans la syntaxe de la présente invention. 'vg' indique un graphe de sommets, 'tt' indique un arbre triangles, et 'td' indique des données triangles 'Ivg' est un marqueur à un bit défini pour représenter la présence de composantes reliées devant être restaurées dans une partition. Si vg devant être restauré prochainement est présent, la valeur de 'Ivg' est 0 ; autrement, elle est '1'. 'Itg' est un marqueur à un bit défini pour représenter la présence de composantes reliées devant être restaurées dans une partition ou la présence d'arbres dépendants. Une valeur 0 représente la présence de composantes reliées, et une valeur 1 représente l'absence de composantes reliées. Un procédé de partition fixe utilise un procédé de partition identique à travers les données de maillage fournies globales en utilisant seulement un format arbitraire parmi les formats de flux binaires décrits sur les figures 12A à 121 selon les champs d'application.

En vue de construction, la figure 12A montre que les données de maillage globales sont traitées dans un ordre de codage pour former une partition, la figure 12B montre que les données de maillage globales sont formées comme une partition, alors que les données de graphe de sommets et les paires tt/td sont séparées, et la figure 12C montre qu'une partition est formée d'une composante reliée comme unité minimum. La figure 12D montre que plusieurs graphes de sommet constituant les données de maillage sont collectés pour former une partition, les paires tt/td correspondant aux graphes de sommets étant collectées pour constituer une partition. La figure 12E montre que plusieurs graphes de sommets constituant des données de maillage sont collectés pour former une partition et que les paires tt/td constituent plusieurs partitions par rapport aux tailles de partitions. La figure 12F montre que les graphes de sommets et les paires tt/td sont séparés et sont formés en tant qu'unités séparées en unités de

composantes reliées. La figure 12G montre que plusieurs graphes de sommets constituant les données de maillage sont fournis comme des partitions séparées et les paires tt/td correspondent à chaque graphe de sommets constituent plusieurs partitions selon la taille des partitions. La figure 12H montre que le graphe de sommets constituant chaque composante reliée est d'abord formé en tant qu'une partition et la paire tt/td correspondante est ensuite formée en tant que partition. La figure 121 montre que les données de graphe de sommets de chaque composante reliée sont codées en une partition et la paire tt/td correspondante est séparée en partitions selon les tailles des partitions.

En vue de la fonction, les procédés de partition représentés sur les figures 12A à 121 seront maintenant décrits. Les procédés représentés sur les figures 12A et 12B sont utilisés dans le cas où une résilience vis-à-vis de l'erreur n'est pas prévue ou lorsqu'il n'y a pas de restriction au trajet de transmission ou aux performances d'un décodeur. Selon le procédé représenté sur la figure 12A, le coût de traitement est réduit et l'efficacité de rendu est améliorée. Toutefois, selon ce procédé, le coût impliqué par la retransmission de données en cas d'une erreur de données augmente. Les procédés représentés sur les figures 12C, 12D, 12F et 12H peuvent assurer l'indépendance des partitions. Toutefois, selon ces procédés, il est difficile de les adapter à un paquet ayant une taille spécifique. En d'autres termes, si la partition est plus petite que le paquet lors de la retransmission de données chargées dans un paquet ayant une taille spécifique, les données factices correspondant à la différence de taille entre la partition et le paquet doivent être prévues en plus. Au contraire, si la partition est plus grande que la taille du paquet, les données ne peuvent pas être mises dans un paquet, les données doivent

être traitées séparément et des données additionnelles doivent être prévues par le décodeur. Par conséquent, l'efficacité de codage globale est diminuée et la complexité et le coût augmentent. Dans les procédés représentés sur les figures 12E, 12G et 121, les données de graphe de sommets pour la connectivité des mailles sont traitées de la même manière que décrit ci-dessus. Toutefois, la paire tt/td pour le type de construction d'un triangle dans une maille peut être traitée séparément en accord avec la taille de partition, tout en assurant l'indépendance de celle-ci. Les données incluant vg~id, vi et bp sont prévues en plus aux partitions de la paire tt/td. Ici, vg~id spécifie le graphe de sommets correspondant à la paire tt/td à restaurer, et il est utilisé lorsque les graphes de sommets sont traités collectivement, ainsi que montré sur les figures 12D à 12G. vi spécifie les valeurs index~gauche et index~droit d'un triangle de départ de chaque partition, et il est prévu pour restaurer la partition en cours indépendamment de la précédente partition même si la précédente partition ne peut être restaurée à cause d'erreurs. De même, bp est un marqueur à un bit pour définir un procédé de codage de géométrie, couleur, normal ou texCoord de sommets pour chaque partition dans la paire tt/td. Dans les procédés montrés sur les figures 12E, 12G et 121, lbl est utilisé sélectivement seulement lors de la partition des extrémités d'un triangle d'embranchement. Si la paire tt/td peut être codée en unités de composantes reliées, ainsi que représenté sur les figures 12A à 12D, 12F et 12H, la valeur de bp est réglée sur 'l', un codage chevauchant des sommets précédemment codés étant autorisé. Si la paire tt/td est divisée en plusieurs parties constituant une composante reliée arbitrairement, ainsi que représenté sur les figures 12E, 12G et 121, bp est défini indépendamment pour chaque partition devant être restaurée.

Itg est codé sélectivement. C'est-à-dire, si la position en cours est la dernière d'une branche latérale de la paire tt/td, Itg est codé en 'l' ; sinon, il est codé en '0'. Ceci est déterminé en utilisant les index de visite comme suit : [Formule 2] index~droit - index~gauche - 1 = le nombre de triangles dans la partition en cours.

Si la formule ci-dessus est satisfaite, ce qui signifie que l'extrémité de la branche est atteinte, Itg est codé en 'l'.

Maintenant, des procédés de partition de données pour procurer les constructions décrites ci-dessus seront décrits.

1. Procédé de partition de données en unités de composantes reliées
Ce procédé est représenté sur les figures 12C et 12H et peut être facilement mis en #uvre. Si la différence de taille entre composantes reliées n'est pas grande, ce procédé est efficace. Toutefois, si les tailles de données de composantes reliées ne sont pas uniformes et que la différence entre elles est grande, des bits redondants sont générés, qui détériorent l'efficacité de codage. De même, si la taille d'une composante reliée est grande, l'efficacité est diminuée et les données ne peuvent pas être mises en paquets afin d'avoir une taille prédéterminée. Par conséquent, ce procédé peut être adopté seulement lorsqu'il n'y a aucune restriction dans le trajet de transmission et dans les performances d'un décodeur. Les procédés présentés sur les figures 12A, 12B, 12D et 12F présentent aussi ces désavantages.

2. Procédé de partition pour combiner de petites composantes reliées.

Si beaucoup de composantes dont les tailles sont petites sont contenues à l'intérieur d'un modèle, le

procédé de partition décrit ci-dessus n'est pas efficace. Ainsi, comme cela est représenté sur les figures 12A et 12B, il est souhaitable que les composantes reliées dont les tailles sont petites, soient reliées dans une composante jusqu'à ce que chaque partition présentant une taille prédéterminée soit obtenue. En conformité avec ce procédé, il est nécessaire de fournir vg~id pour définir la paire de tt/td correspondant à un graphe de sommets spécifique comme les informations d'en-tête d'une partition.

3. Procédé de partition pour combiner de grandes composantes reliées
Le premier procédé de partition peut être utilisé en codant de grandes composantes reliées seulement sous des environnements restrictifs. Afin de surmonter cette limitation, la présente invention propose un procédé de codage général par lequel une grande composante peut être divisée tandis que l'on satisfait à la fois à la flexibilité dans la taille de partition et à l'indépendance des partitions. Les figures 12E, 12G et 121 représentent des procédés de codage dans lesquels seulement la paire tt/td provenant d'une grande composante reliée arbitraire est divisée en plusieurs partitions pour être ensuite codée. La figure 12E représente une modification du procédé représenté sur la figure 12H. Les procédés représentés sur les figures 12E et 12G présentent un désavantage en ce que le coût augmente du fait que la totalité des données de graphe de sommets doit être mémorisée dans un décodeur. De même, le procédé représenté sur la figure 12E est pauvre en vue de l'efficacité de codage de petites composantes reliées.

De même, selon ce procédé, vg~id pour définir la paire tt/td correspondant à un graphe de sommets spécifique, vi pour définir l'index de boucle englobante d'un triangle de départ d'une partition, et bp pour indiquer un procédé de

codage des données incluant la géométrie, couleur, normal et texCoord, doivent de plus être définis dans l'information d'en-tête de partition. Toutefois, selon ce procédé, les données de maillage peuvent être facilement protégées des erreurs de données indépendamment les unes des autres. De même, la perte de codage qui est provoquée par la partition peut être réduite.

De plus, la figure 13A montre la structure de flux binaires lorsque les paires tt/td sont séparées, des lignes en pointillés y indiquant des positions séparées, illustrant la relation entre arbre triangles et données triangles. La figure 13B illustre un procédé de partition de données utilisant les procédés de partition décrits cidessus. Bien que l'information 'id' ne soit pas représentée sur la figure 13B pour des raisons de commodité, elle doit venir après le code de départ. 'vg' indique des données de graphe de sommets, 'tt/td' indique une paire d'arbre triangles/données triangles, et 'cc' indique une composante reliée. Sur la figure 13B, l'index n indique le nombre de composantes reliées (CC) et n' indique le nombre de composantes reformatées dans le cas de reformatage selon les tailles de composantes reliées. Le reformatage est effectué de la manière suivante.

1. Reconstruction de composantes reliées (étape 251)
Les petites composantes reliées sont combinées pour être incluses dans la gamme d'une taille de partition de données prédéterminée. Ainsi que montré sur la figure 13B, des composantes reliées CC1 et CC2 sont combinées pour former une composante reformatée CC'1. Les composantes reliées plus grandes qu'une taille prédéterminée sont divisées en petites composantes. Sur la figure 13B, la troisième composante reliée CC3 est divisée en plusieurs composantes CC'2, ..., CC'k.

2. Génération de graphes de sommets et de paires d'arbre triangles/données triangles (étape 252)

Les vgs et paires tt/td sont générés pour les composantes reformatées respectives.

3. Réarrangement des vg et paires tt/td (étape 253)
Les vgs et paires tt/td générés à l'étape 252 sont réarrangés séparément.

4. Partition de l'information vg (étape 254)
L'information vg réarrangée à l'étape 253 est divisée en unités d'information possédant une taille prédéterminée.

5. Partition de l'information de paire tt/td (étape 255)
L'information de paire tt/td générée à l'étape 253 est divisée en unités d'information possédant une taille prédéterminée.

Le procédé de partition fixe est désavantageux eu égard à la complexité du système et au coût puisqu'un décodeur séparé convenant à chacun des procédés représentés sur les figures 12A à 121 est nécessaire. Par conséquent, la présente invention propose un procédé de partition variable par lequel des flux binaires, basés sur les procédés décrits ci-dessus, peuvent être décodés de façon adaptative en utilisant un décodeur unique.

<Procédé de partition variable>
Dans le procédé de partition variable, contrairement au procédé de partition fixe, l'information pt (type de partition), c'est-à-dire l'information pour définir le type de partition de la partition en cours est fournie en plus.

Ainsi, les partitions sont classées en quatre types, ainsi que représenté sur les figures 14A à 14D. pt défini dans la présente invention est dépendant de la valeur de sc, et la relation entre sc et pt est résumée sur le tableau 1.

Tableau 1. Relation entre sc et pt

<tb>
<tb> Valeur <SEP> de <SEP> bit <SEP> Signification
<tb> 0000 <SEP> 0000 <SEP> 0011 <SEP> 0001 <SEP> Un <SEP> ou <SEP> plus <SEP> de <SEP> vgs <SEP> sont <SEP> contenus <SEP> et <SEP> les
<tb> données <SEP> vg <SEP> sont <SEP> utilisées <SEP> dans <SEP> une <SEP> ou
<tb> plus <SEP> autres <SEP> partitions <SEP> de <SEP> données
<tb> 0000 <SEP> 0000 <SEP> 0011 <SEP> 0011 <SEP> Seulement <SEP> des <SEP> données <SEP> tt/td <SEP> sont
<tb> contenues. <SEP> Dans <SEP> le <SEP> cas <SEP> de <SEP> restauration
<tb> des <SEP> données, <SEP> vg~id <SEP> pour <SEP> adapter <SEP> une
<tb> paire <SEP> tt/td <SEP> à <SEP> un <SEP> vg <SEP> arbitraire, <SEP> vi
<tb> (index <SEP> de <SEP> visite) <SEP> qui <SEP> est <SEP> le <SEP> point <SEP> de
<tb> départ <SEP> d'une <SEP> bande <SEP> triangle, <SEP> et <SEP> bp
<tb> (prédiction <SEP> de <SEP> frontière) <SEP> sont
<tb> contenus <SEP> dans <SEP> une <SEP> information <SEP> d'entête.
<tb>

0000 <SEP> 0000 <SEP> 0011 <SEP> 0100 <SEP> vg, <SEP> tt <SEP> et <SEP> td <SEP> constituent <SEP> une <SEP> partition
<tb> de <SEP> données, <SEP> et <SEP> vg <SEP> est <SEP> utilisé <SEP> dans <SEP> une
<tb> autre <SEP> ou <SEP> plusieurs <SEP> autres <SEP> partitions
<tb> de <SEP> données
<tb>

Pour exécuter la partition variable de données en vue de compenser la complexité et le coût du système, ce qui suit doit être pris en considération.

Un code de départ ne peut pas être inséré sélectivement. En d'autres termes, un décodeur exécute une opération de décodage sans savoir dans quel mode le flux binaire en cours est codé. Ainsi, dans le cas où le code de départ est fourni sélectivement en accord avec un mode de codage, seuls les flux binaires limités sont restaurés.

Dans quelques cas, diverses sortes de décodeurs doivent être fournies. En conséquence, le coût et la complexité peuvent augmenter. De façon à exécuter le décodage indépendamment du mode de codage d'un encodeur, le système de syntaxe variable doit être exclus.

Dans le cas d'utilisation d'un type de codage

spécifique, des informations non nécessaires peuvent être fournies en conformité avec les caractéristiques de données de maillage ou d'un décodeur, ce qui diminue l'efficacité de codage.

Les figures 14A à 14D illustrent quatre types de modules de syntaxe pour supporter le procédé de partition variable. La figure 14C montre la syntaxe pour procure d façon adaptable vg~id et Itg, comme défini sur les figures 12A à 121. En d'autres termes, si un vg seulement est contenu dans la syntaxe représentée sur la figure 14B, la relation entre vg et la paire tt/td peut être identifiée pendant la restauration. Ainsi, vg~id n'est pas nécessairement donné. Itg est fourni seulement lorsque la paire tt/td correspond à la fin d'une branche latérale de la paire tt/td globale, et la formule de détermination est exprimée de ce fait dans la formule (2). La figure 14A montre la structure dans le type de partition 0 où une partition est constituée d'un nombre arbitraire de composantes reliées. La figure 14B montre la structure dans le type de partition 1 où une partition est constituée d'un nombre arbitraire de vg's. La figure 14C montre la structure dans le type de partition 2 où une partition est constituée de seulement une paire tt/td correspondant à une composante reliée, et la figure 14D montre la structure dans le type de partition 3 où une partition est constituée de vg et de la paire tt/td correspondant à la composante reliée en cours. Par conséquent, la combinaison de ces structures de syntaxes peut supporter tous types de structures de syntaxes, excepté celle représentée sur la figure 12B. En d'autres termes, la structure représentée sur la figure 12A peut être implémentée dans le type de partition 0, et la structure représentée sur la figure 121 peut être implémentée par combinaison du type de partition 1 et du type de partition 2. Par conséquent, dans la présente invention, pour les composantes reliées plus

petites que les paquets, plusieurs composantes reliées sont collectées en une partition pour être codées dans le type de partition 0, en tenant compte de l'efficacité de codage.

Les plus grandes composantes reliées sont codées dans les types de partition 1 et 2 ou dans les types de partition 2 et 3. De même, en considération du trajet de transmission ou des performances d'un décodeur, des structures de syntaxes diverses combinées de façons diverses peuvent être fournies.

Les figures 15A à 15D illustrent un exemple de procédé de partition variable. Sur la figure 15A, puisque ccl et cc3 sont de petites mailles, elles sont traitées par chaque composante reliée, avec une partition définie en type de partition 0 ou 3. Puisque cc4 est une grande maille, la paire tt/td est divisée en plusieurs parties pour être traitée en une combinaison du type de partition 3 et du type de partition 2. De même, la cc4 peut être traitée en une combinaison du type de partition 1 et du type de partition 2 ainsi que représenté sur la figure 15B. De même, comme cela est représenté sur la figure 15C, en vue d'augmenter l'efficacité de codage, les données de maillage peuvent être changées en une autre structure combinée. La figure 15C montre le cas où les données de maillage de ccl à cc3 sont définies dans le type de partition 0. En vue de représenter les données de maillage globales, les structures montrées sur les figures 15C et 15A ou les figures 15C et 15B peuvent être combinées. Toutefois, de façon à procurer la structure représentée sur la figure 15C, les conditions pour déterminer la dernière composante reliée sont nécessaires. Dans le procédé classique, pour déterminer la dernière composante reliée, un marqueur à un bit de last cc (dernière~cc) est utilisé. Une valeur de 1 représente la dernière composante reliée. Par conséquent, selon la présente invention, la présence d'une composante reliée devant être restaurée peut être déterminée en

utilisant Itg dont la fonction est similaire à last~cc et à information pt à l'intérieur de sc comme suit : si(Itg==l) si(pt==0){ si(next-2~bytes()==sc) La cc couramment restaurée est la dernière cc dans la partition ; sinon La cc couramment restaurée est la dernière partition à être restaurée ; }sinon La cc couramment restaurée est la dernière cc dans une partition ; }sinon La cc couramment restaurée n'est pas la dernière cc dans une partition ; où next~2~bytes() est la fonction pour lire seulement deux octets en avance parmi les flux binaires dans un décodeur. La figure 15D montre un exemple dans les types de partition 1,2 et 3. Comme montré dans l'exemple décrit ci- dessus, le procédé de partition variable possède une excellente adaptabilité pour coder les environnements et il est meilleur que le procédé de partition fixe en vue de l'efficacité de codage et du coût.

<Procédé de partition de la paire tt/td>
Dans la présente invention, la partition de la paire tt/td est fondamentalement exécutée à la position correspondante après les données triangles d'une branche latérale d'un triangle d'embranchement survenant en premier à la fin de la précédente partition, c'est à dire la branche principale, qui est représentée sur la figure 16.

La raison pour diviser la paire tt/td à la branche principale est la suivante. Ainsi que décrit ci-dessus, si les index de sommets Y ne sont pas déterminés, la restauration et le rendu d'un triangle venant après le triangle d'embranchement correspondant ne peuvent pas être obtenus. Toutefois, ce procédé peut provoquer de l'inefficacité en conformité avec l'ordre de traversée initial et le type réel de paire tt/td. C'est à dire, dans

le cas où la branche gauche (ou droite) est codée en premier, si la branche gauche d'un triangle d'embranchement de la paire tt/td est très grande, elle est encore plus grande que le paquet. Ainsi, la détermination des index de sommets Y ne peut pas être faite jusqu'à ce que davantage d'informations venant après le triangle d'embranchement, c'est à dire, les informations sur le nombre de triangles d'une branche, soient traitées.

Par conséquent, la présente invention propose trois procédés efficaces de partition des données de maillage.

Dans la présente invention, une ou plusieurs partitions peuvent être contenues dans un paquet. Toutefois, dans ce chapitre, la description sera faite sur la base qu'une partition seulement est contenue dans un paquet.

Un premier procédé de partition de données est d'exécuter la partition en réglant une allocation de paquet, taux~t, pour une taille de paquet, cible (300 de la figure 17). Une quantité moyenne de génération de bits de tt à coder en unités de composantes reliées, c'est à dire moyen~tt, est obtenue, et ensuite la partition est exécutée à l'intérieur de la gamme dans laquelle une allocation de paquet prédéterminée, taux~t, est remplie. Sur la figure 17, moyen~t est une quantité moyenne de bits de tt calculée pour chaque composante reliée, td~biti est une quantité de génération de bits des données en excluant vg et tt, après que le i-ème triangle soit codé, cur~bits est une somme obtenue en additionnant tous les bits générés à partir du premier jusqu'au i-ème triangles du paquet, c'est à dire moyen-t + td bitsi. Par conséquent, si cur~bits est plus grand que ou égal à taux t * cible (étape 330), la partition est effectuée pour codage (étape 340). Sinon, le (i+1)-ème triangle est codé (étape 350). Le procédé décrit ci-dessus est répété jusqu'à ce que toutes les mailles aient été codées, achevant ainsi la partition.

Ici, le procédé de détermination de la partition aux

triangles d'embranchement sur la branche principale doit être pris en considération. C'est à dire, en supposant que la position de partition est fondamentalement définie seulement à la branche principale pour résoudre le problème de sommet Y, il est nécessaire de déterminer si un arbre dépendant sélectionné pour être décodé en suivant le triangle d'embranchement par les informations d'orientation est inclus dans le paquet qui inclut le triangle d'embranchement. A cette fin, dans la présente invention, un arbre à coder dépendant est codé à l'avance. En d'autres termes, si le paquet est complètement rempli avec les données codées alors que l'arbre dépendant est codé, la supposition de partition à la branche principale est enfreinte. Ainsi, comme représenté sur la figure 18C, la partition est faite au précédent triangle d'embranchement.

Si la quantité totale de génération de bits, obtenue jusqu'à ce que l'arbre dépendant soit codé, est plus petite que la taille du paquet, ainsi que représenté sur les figures 18A ou 18B, l'arbre dépendant est inclus dans le paquet pour être ensuite codé.

Un second procédé est d'exécuter la partition quand le prochain triangle à coder est un triangle d'embranchement et quand il est déterminé que la somme de la quantité de génération de bits prédite d'un arbre d'embranchement dépendant et la quantité de bits générée à la partition en cours excède la taille du paquet, bien que taux t ne soit pas encore atteint. Ceci sera maintenant décrit en détail.

1. Le nombre de bits codés dans la première partition de chaque composante reliée, bit en cours, est mémorisée.

2. Même si un bit cible n'est pas encore atteint, si le prochain triangle est un triangle d'embranchement, la taille de l'arbre dépendant du triangle suivant, nst, est obtenue.

3. Le nombre de sommets de triangles codés jusqu'ici dans la partition en cours, ng~en~cours, est obtenu.

4. Si cur~ng+nst > ng, la partition est exécutée comme suit.

(1) Si la quantité de bits prédite à générer à l'arbre dépendant est plus grande que la taille du paquet, la partition est exécutée jusqu'au prochain triangle d'embranchement inclus. C'est à dire, si nst+2>ng, la partition est exécutée jusqu'au prochain triangle d'embranchement inclus, comme représenté sur la figure 18C.

(2) Sinon, la partition est exécutée au triangle en cours.

Un troisième procédé est de coder en avance une unité de paquet d'une maille devant être codée ensuite afin de calculer le nombre de triangles dans le cas où les besoins en taille de paquet sont satisfaits, et ensuit de construire les flux binaires des unités de paquets réelles en utilisant les informations sur le nombre de triangles.

Le procédé décrit ci-dessus pour déterminer si l'arbre dépendant doit ou non être inclus dans un paquet est également appliqué à ce procédé.

Dans la partition de maillage utilisant ce procédé, les deux points suivants doivent de plus être considérés.

Tout d'abord, un retard du temps de décodage est généré à cause du calcul de sommet Y. Deuxièmement, l'indépendance parmi les données divisées doit être considérée. Dans la présente invention, le retard est minimisé en établissant une composante reliée virtuelle comme il sera décrit ultérieurement, et le problème d'indépendance est résolu en définissant les informations d'orientation, les informations d'index de boucle englobante et les informations d'arête de polygone dans les unités de paquets.

<Procédé de traitement de sommet Y utilisant une composante reliée virtuelle>
Afin de traiter les sommets Y tout en maintenant l'indépendance parmi les données divisées de paires tt/td,

deux procédés sont utilisés. Le procédé le plus simple est de transmettre la longueur des données divisées et les informations de sommet Y à un décodeur. L'autre procédé est de définir les données divisées en tant que composantes reliées virtuelles en conformité avec les caractéristiques des paires tt/td. Conformément au premier procédé, Puisque les longueurs de toutes les mailles et les longueurs des mailles divisées sont connues au moment du décodage, la structure d'une maille devant être restaurée peut être prédite. De même, comme les informations de sommet Y sont connues, le rendu progressif peut être obtenu. Toutefois, l'efficacité de codage peut être diminuée à cause des données supplémentaires.

Conformément au second procédé dans lequel des composantes virtuelles sont définies, les composantes reliées de paires tt/td sent définies comme les nombres de branches et feuilles, comme exprimé dans la formule suivante (3). Les composantes reliées virtuelles peuvent être construites en définissant des bits virtuels dans les données de maillage divisées de façon à satisfaire la formule (3). Ici, la position de départ de la partition est établie pour survenir seulement au cours de la branche principale de l'arbre binaire ; ceci afin de faciliter le traitement de sommet Y. Par exemple, si la partition est effectuée à une position autre que la branche principale, le problème de sommet Y décrit ci-dessus est généré, de sorte que des informations additionnelles de traitement de sommet Y sont nécessaires, ou bien la restauration ou le rendu ne peuvent pas être exécutés indépendamment pour chaque partition.

[Formule 3] nombre de branches + 1 = nombre de feuilles
Des bits virtuels peuvent être définis dans deux cas :
1. Lorsque la partition se termine à un parcours ou feuille

Afin de satisfaire la formule (3), une paire de bits virtuels de (1, 1) est ajoutée à (trun, tleaf).

2. Lorsque la partition se termine à une branche
Afin de satisfaire la formule (3), deux paires de bits virtuels de (1,1) sont ajoutées à (trun, tleaf).

De même, lorsque la partition se termine à une branche et que les données de géométrie, couleur, normal et texCoord sont traitées pour chaque sommet, les données de géométrie, couleur, normal et texCoord pour le dernier triangle qui est un triangle d'embranchement ne sont pas codées. Ceci parce qu'un triangle d'embranchement peut être restauré par les index de sommet Y déterminés par les informations d'index d'un triangle immédiatement avant la partition dans la partition en cours et un triangle racine de la partition devant être codée ensuite. Toutefois, si une erreur est générée à la partition devant être codée ensuite, le dernier triangle d'embranchement de la partition en cours ne peut pas être restauré. Ce problème peut être résolu en transmettant les données de taille totale (lbl) de l'un des arbres dépendants de chacune des branches des triangles d'embranchement à un décodeur en les incluant de la même manière dans les données de paire tt/td. Ceci parce qu'il est possible de calculer les index de sommet Y du triangle d'embranchement en utilisant la valeur lbl avant que les prochaines partitions soient restaurées. Dans le cas d'exécution du codage par face ou coin, puisque le codage n'est pas dépendant des données d'index de sommet Y, le codage est exécuté pour l'un ou l'autre cas. Les figures 18A à 18C sont des schémas conceptuels de composantes reliées virtuelles. La figure 18A représente un triangle virtuel dans le cas où la partition survient à une feuille, la figure 18B représente un triangle virtuel dans le cas où la partition se termine à un parcours, et la figure 18C représente un triangle virtuel dans le cas où la partition se termine à une

branche définie comme un triangle(s) virtuel(s) indiqué par #.

Sur la figure 18A, si la partition survient dans un état où un triangle feuille vient immédiatement après le triangle d'embranchement, la structure arborescente représentée sur la figure 18A devient la même que celle représentée sur la figure 18C. Dans ce cas, le décodeur ne peut pas discriminer les structures représentées sur les figures 18A et 18C. Ainsi, dans un codeur, la partition ne doit pas survenir à un triangle feuille venant immédiatement après le triangle d'embranchement, excepté la fin d'une branche arbre. En agissant ainsi, le décodeur peut exécuter le décodage par rapport à tous les triangles sans informations pour discriminer les structures représentées sur les figures 18A et 18C.

Ainsi, le problème de la mise en paquets, impossible dans le cas d'un grand arbre dépendant avec la supposition de base que la partition est effectuée seulement à la branche principale, peut être résolu en construisant l'arbre dépendant de plusieurs composantes reliées virtuelles dépendantes.

Maintenant, un procédé de détermination de bits virtuels, dans le cas d'exécution de codage en formant la composante reliée virtuelle d'une telle manière, va être décrit.

1. Détermination de la présence de bits virtuels dans un parcours ou une feuille.

Si la formule 4 est satisfaite, un bit virtuel est présent. Sinon, un bit virtuel n'est pas présent. Si le troisième triangle du dernier parmi les triangles codés n'est pas un triangle d'embranchement, ainsi que représenté sur les figures 18A et 18B, et que la formule 4 est satisfaite, il est déterminé que seules les données virtuelles d'une paire de (1,1) sont générées dans (trun, tleaf) et les données td ne sont pas décodées pour le

triangle virtuel.

[Formule 4] index droit-index gauche > nombre total de triangles générés quand seulement tt de la partition en cours est restauré.

2. Détermination de la présence de bits virtuels dans une branche.

Si la partition survient à un triangle d'embranchement, comme représenté sur la figure 18C, deux triangles feuilles virtuels sont ajoutés. Ainsi, si le troisième triangle de la fin des données tt est un triangle d'embranchement et que la formule 4 est satisfaite, les données de bit virtuel de deux paires de (1, 1) sont présentes dans (trun, tleaf). Ensuite, les données td des deux derniers triangles feuilles ne sont pas décodées.

<Partition de données dans un maillage polygonal>
En chirurgie topologique, pour coder les données de maillage composées de polygones, les données de polygones sont d'abord reconstruites comme triangles. La figure 19 montre un exemple de reconstruction de données de maillage polygonal en données de maillage triangle, dans lequel des lignes continues indiquent des arêtes réelles des données de maillage polygonal d'origine, et des lignes en pointillés indiquent des arêtes virtuelles ajoutées pour diviser le maillage polygonal en triangles. Pour que le décodeur restaure les triangles divisés en polygones d'origine, les informations pour enlever les arêtes virtuelles doivent être transmises au décodeur. Ceci est appelé informations d'arête de polygone. Si une partie des informations d'arête de polygone est envoyée par triangle, une valeur de 1 signifie une arête réelle, et une valeur de 0 signifie une arête virtuelle.

De façon classique, après conversion des polygones contenus dans les données de maillage en données de maillage triangles, les informations d'arête de polygone

pour tous les triangles excepté le premier triangle sont générées. Ici, le codeur établit le premier triangle comme une arête réelle, et le décodeur établit les informations d'arête de polygone du premier triangle comme 1 et exécute la restauration.

Toutefois, dans le cas où la partition de données doit être exécutée à l'intérieur d'un polygone autre qu'un triangle, les données de maillage peuvent être restaurées par le procédé conventionnel. Conformément à cela, la partition en données de maillage se limite à satisfaire les besoins de taille de paquet, abaissant par cela l'efficacité de codage.

Par conséquent, afin de résoudre les problèmes et désavantages décrits ci-dessus, il est nécessaire de définir les informations d'arête de polygone définies dans une partition pour le premier triangle de la partition dans le cas où la partition débute à une arête virtuelle. Sur les figures 20D et 20E, la référence alphabétique 'tt' indique une information de parcours de triangle, 'tm' indique une information de progression, 'pe' indique une information d'arête de polygone, les index indiquent l'ordre de tm et pe correspondant à tt, et 'n' indique le nombre de triangles. La figure 20D montre les syntaxes dans le cas de partition d'un maillage polygonal aux arêtes réelles correspondant à la figure 20C, et la figure 20E montre les syntaxes dans le cas de partition d'un maillage polygonal aux arêtes virtuelles, correspondant à la figure 20B.

La présente invention est basée sur le fait que la partition de données est exécutée à une arête réelle, et procure les syntaxes qui permettent la restauration même quand la partition de données a lieu à l'intérieur d'un polygone.

Les arêtes de polygone dans chaque partition sont traitées sur la base d'informations 'pt' ou informations

'triangulated' (triangulées) et 'polygon~edge' (arête de polygone) comme suit.

1. Procédé de traitement d'arête de polygone basé sur Pt (1) Lorsque pt = 0, la valeur d'arête de la première arête de polygone à l'intérieur d'une partition n'est pas codée ; et (2) Seulement lorsque pt = 2 et un ou plusieurs polygones sont présents dans une partition, c'est à dire triangulated = 0, la valeur d'arête de la première arête de polygone à l'intérieur d'une partition est codée.

2. Procédé de traitement d'arête de polygone basé sur les informations triangulées et d'arête de polygone.

(1) Lorsque la partition à une arête réelle est permise, la valeur de la première arête de polygone à l'intérieur d'une partition n'est pas codée ; et (2) Lorsque la partition à une arête virtuelle est permise, la valeur de la première arête de polygone à l'intérieur d'une partition est codée.

Ici, la discrimination entre l'arête réelle et l'arête virtuelle dans un polygone arbitraire est faite dans les conditions suivantes : si (triangulated==l) arête réelle sinon si (polygon~edge==0) arête virtuelle sinon arête réelle
Par conséquent, le décodeur décode la première valeur polygon~edge inconditionnellement lorsque triangulated=0.

Ensuite, une valeur de 0 est définie comme la valeur de la première arête de polygone, et une valeur de 1 est définie comme la valeur de la seconde arête de polygone.

L'information triangulée est 0 si un ou plusieurs polygones sont présents dans les données de maillage à l'intérieur d'une partition ; sinon, elle est 1, afin de construire une information à un bit en unités de partitions.

<Partition de données basée sur les informations d'orientation>
La nécessité décrite ci-dessus et le procédé de définition des informations d'orientation sont également applicables à la partition de données. Toutefois, puisque la partition est autorisée même à un arbre dépendant dans le cas d'utilisation de composantes reliées virtuelles, comme décrit ci-dessus, il n'est pas possible de déterminer si la maille de la partition en cours devant être restaurée est reliée à une branche principale ou à une sous branche lorsque la partition précédente ne peut pas être restaurée à cause d'une erreur de données. Ainsi, une erreur dans le calcul de l'index de boucle englobante peut être générée et la restauration et le rendu ne peuvent pas être réalisés.

Par conséquent, dans la présente invention, les informations d'orientation sont définies dans la composante reliée virtuelle de la même manière que la composante reliée réelle, réalisant par ceci la restauration et le rendu indépendants à l'intérieur de la composante reliée virtuelle.

<Partition de données incluant les informations de boucle englobante>
Puisque les index de la géométrie des sommets réels sont cartographiés dans les informations de boucle englobante, les valeurs de coordonnées réelles des sommets d'un triangle peuvent être identifiées par cartographie en utilisant les index de boucle englobante. Par conséquent, dans l'éventualité où une partition comportant une erreur n'est pas retransmise avec succès, comme représenté sur la figure 9, il n'est pas possible de restaurer les partitions devant être restaurées ensuite car les informations d'index de boucle englobante pour un triangle de départ dans une partition ne sont pas connues. Pour éviter une telle inefficacité, les partitions de données respectives doivent être restaurées ou rendues indépendamment. A cette fin, les

positions de départ de la boucle englobante, à partir de laquelle les partitions de données respectives commencent, doivent être données.

Durant la restauration dans la partie décodage, vg est utilisé pour mémoriser les valeurs des sommets respectifs de triangles devant être restaurés ensuite dans un tableau de boucle englobante. Ici, le sommet du triangle suivant peut être déterminé en augmentant/diminuant de 1 l'index de la table de boucle englobante de la valeur d'index d'un triangle qui est à une position de départ, ainsi que représenté sur la figure 21. Ainsi, si les index des sommets du premier triangle dans la boucle englobante sont déterminés, les sommets des triangles restants à restaurer ensuite peuvent être déterminés en augmentant/diminuant de 1 l'index de boucle englobante du premier triangle. Par conséquent, dans la présente invention, seuls les index de boucle englobante des sommets du premier triangle d'une partition sont donnés à la partition correspondante, assurant par ceci l'indépendance des partitions respectives. De même, vi est défini dans la présente invention est composé de deux sortes d'informations d'index, c'est à dire left index (index gauche) et right~index (index droit), et la construction de flux binaires est montrée sur la figure 22. Sur la figure 22, la référence alphabétique L indique l'index du premier sommet dans la boucle englobante de la limite gauche d'une bande triangle, et R indique l'index du premier sommet dans la boucle englobante de la limite droite d'une bande triangle.

Lorsque les flux binaires sont reçus en séquence d'un support de mémorisation tel qu'un disque compact, puisque les index de boucle englobante sont dans une gamme allant de 0 à un niveau à l'intérieur d'une taille prédéterminée pour chaque composante reliée, les index donnés pour la partie en-tête de la partition doivent être codés dans une valeur qui est dans cette gamme, qui est autorisée car la

boucle englobante correspond exactement à la paire tt/td et qu'une paire tt/td est toujours codée après un vg. Toutefois, conformément aux caractéristiques des moyens de transmission, l'ordre d'émission et l'ordre de réception peuvent être différents à cause d'un retard de transmission. De même, la perte de flux binaires peut arriver. Dans de tels cas, comme il n'y a pas de garantie que le vg correspondant à la paire tt/td soit reçu correctement, un index différent de l'index précédent peut être donné.

La figure 21 illustre la relation entre une boucle englobante et des paires tt/td dans le cas de plusieurs composantes reliées. Ici, la première colonne montre des exemples d'indexage indépendant de chaque composante reliée dans la boucle englobante et la seconde colonne montre des exemples d'indexage de la dernière valeur de la boucle englobante précédente continuellement incrémentée, dans la boucle englobante.

Les figures 23A et 23B illustrent un procédé de codage des informations des index de départ d'une partition, dans lequel ni représente la taille de la boucle englobante de la première composante reliée et n2 représente la taille de la boucle englobante de la deuxième composante reliée. Dans ce cas, pour la partition de la seconde composante reliée, les informations d'index sont données à l'en-tête par deux procédés comme représenté sur les figures 23A et 23B. La figure 23A illustre les informations d'en-tête d'une partition dans le cas d'indexage de boucle englobante pour chaque composante reliée, et la figure 23B illustre les informations d'en-tête d'une partition dans le cas d'indexage de boucle englobante pour les modèles globaux.

<Partition de données basée sur la géométrie>
Jusqu'à maintenant, la présente invention a été décrite sur la base de la connectivité d'un modèle dans une partition de données. Maintenant, un procédé pour assurer

l'indépendance entre partitions de géométrie et augmentant l'efficacité de codage sera décrit. Durant la partition de données, si les sommets des triangles respectifs touchent ceux d'un triangle contenu dans la partition précédente, les informations sur le fait que la géométrie a déjà été codée ou non sont nécessaires, ce qui est défini par un marqueur 'visited' (visité). Une valeur de 1 indique que la géométrie a déjà été codée, et une valeur de 0 indique que la géométrie n'a pas encore été codée. Généralement, la géométrie utilisée à la fois pour la partition précédente et pour la partition en cours apparaît à la limite de deux partitions. Dans le cas où la partition en cours est codée, la géométrie apparaissant à la frontière de la partition précédente est définie telle que visited=2. A cet égard, le procédé de codage de géométrie dans la partition de données est classé comme suit.

Premièrement, ainsi que montré sur la figure 24A, parmi les informations de géométrie incluses dans la partition en cours, seules les informations non visitées dans la partition précédente sont codées dans la partition en cours.

Deuxièmement, ainsi que montré sur la figure 24B, les informations sur la limite codée dans la partition précédente sont aussi codées dans la partition en cours, restaurant par ceci la géométrie dans la partition en cours indépendamment de la partition précédente.

Troisièmement, ainsi que montré sur la figure 24C, parmi les données codées dans les partitions précédentes, seule la géométrie reliée à plusieurs géométries apparaissant également dans la partition en cours est codée dans la partition en cours.

Quatrièmement, ainsi que représenté sur la figure 24D, puisque la géométrie se chevauchant et apparaissant à la fois dans la partition précédente et dans la partition en cours apparaît généralement consécutivement dans la limite

d'une bande triangle, une moitié des données se chevauchant sont codées dans la partition précédente et l'autre moitié dans la partition en cours.

Sur les figures 24A à 24D, les cercles ombrés indiquent la géométrie codée seulement dans la partition précédente, les cercles noirs indiquent la géométrie codée à la fois dans la partition précédente et dans la partition en cours, les cercles blancs indiquent le géométrie codée dans la partition en cours, et les lignes noires pleines indiquent les limites entre partitions.

Toutefois, les procédés décrits ci-dessus ont les résultats suivants.

Bien que le premier procédé puisse être facilement mis en place, la quantité de données environnantes qui peuvent être utilisées pour la prédiction afin de coder la géométrie est plus petite que celle de l'autre procédé, ce qui abaisse la précision de la géométrie.

Le deuxième procédé est meilleur que le premier procédé, en vue de la précision de la géométrie. Toutefois, selon ce procédé, puisque la géométrie apparaissant sur la limite est chevauchante et codée dans deux partitions, l'efficacité de codage est réduite.

Le troisième procédé peut réduire une perte de géométrie tout en maintenant un niveau de compression approprié. Toutefois, selon le troisième procédé, puisque la caractéristique de la connectivité doit être connue, il est difficile de mettre en place ce procédé et la complexité s'accroît.

Dans le quatrième procédé, bien que le désavantage du deuxième procédé puisse être résolu, un retard de rendu est généré. En d'autres termes, les premier, deuxième et troisième procédés permettent la restauration et le rendu par eux-mêmes, et le quatrième procédé permet le rendu en générant des valeurs omises dans la partition en cours par une interpolation utilisant la géométrie environnante, ou

bien nécessite un temps d'attente pour la prochaine partition.

Le premier ou le deuxième procédé sont utilisés de façon adaptée dans la partition de données réelle. En d'autres termes, en considération de l'efficacité de codage et de l'indépendance entre partitions, comme les informations traversantes de la partition dont les positions de départ et de fin de partition sont placées à une branche principale peuvent être exactement connues à partir des partitions précédemment codées, la partition est divisée selon le premier procédé. Dans l'éventualité où la partition précédente ne peut pas être restaurée à cause d'une erreur générée dans la partition précédente, comme les informations traversantes de la partition dont les positions de départ et de fin de partition sont placées à un arbre dépendant ne peuvent pas être connues, la partition est divisée selon le deuxième procédé. Dans la présente invention, le procédé de codage de géométrie est fourni aux informations d'en-tête de chaque partition. Dans le cas où seuls le premier et second procédés sont adoptés de façon adaptée, une valeur de 0 de marqueur de prédiction de limite à un bit signifie que le premier procédé est utilisé en codant la géométrie d'une partition de données.

Une valeur de 1 signifie que le deuxième procédé est utilisé en codant la géométrie d'une partition de données.

La figure 24E montre la syntaxe de la structure dans laquelle le marqueur de prédiction de limite est contenu dans les informations d'en-tête.

<Procédé de codage prédictif de géométrie>
Un procédé de codage prédictif d'un maillage vise à l'amélioration de l'efficacité de codage en prédisant la géométrie d'un sommet arbitraire, c'est à dire d, en utilisant la géométrie de trois sommets a, b et c d'un triangle avoisinant précédemment codé, c'est à dire d', et en codant la différence entre une valeur estimée et une

valeur réelle. Un tel procédé de codage prédictif peut être exprimé par la formule 5.

[Formule 5] d' = f(a, b, c)
Les procédés de prédiction de la géométrie sont différents en fonction de la prédiction de limite. Il en est ainsi parce que l'utilisation ou la non utilisation de trois sommets d'un triangle avoisinant utilisé pour la prédiction est différente en fonction du procédé de prédiction de limite et ainsi la restauration indépendante de partitions ne peut pas être assurée pour chaque procédé.

Par conséquent, dans la présente invention, lorsque la valeur de la prédiction de limite est établie sur '1', c'est à dire lorsque le chevauchement est autorisé, le procédé de codage prédictif est utilisé conventionnellement en utilisant seulement les informations visitées des sommets avoisinants. Sinon, lorsque la valeur de prédiction de limite est établie à '0', c'est à dire lorsque le chevauchement n'est pas autorisé et que le codage prédictif doit être effectué en utilisant seulement la géométrie dans une partition, le procédé de codage prédictif est exécuté ainsi qu'exprimé dans la formule 6 : [Formule 6] si aucun a, b, et c ne peut être utilisé, d' = 0 sinon si seulement un des a, b, et c peut être utilisé, d' = t sinon si seulement deux des a, b, et c peuvent être utilisés, { si les distances entre deux sommets tl et t2 et d sont 1, d'= (tl+t2)/2 sinon si la distance entre seulement un sommet tl et d est 1, d' = tl sinon d' = t2 } sinon d' = f(a, b, c)

où t indique un sommet arbitraire disponible parmi les trois sommets a, b, et c et tl et t2 indiquent deux sommets disponibles parmi les trois sommets a, b, et c.

<Procédé de construction et de traitement de flux binaires de géométrie et photométrie>
Les informations de géométrie et les informations de photométrie incluant les coordonnées de couleur, normal et texture sont codées comme suit. Premièrement, ainsi que montré sur la figure 25A, les informations de propriété relatives sont codées pour chaque bit de progression d'un triangle. Conformément à ce procédé, lorsque les informations de bits de progression et d'arête polygonale sont restaurées, les triangles peuvent être immédiatement rendus. Alternativement, ainsi que représenté sur la figure 25B, les propriétés respectives peuvent être codées séparément. La figure 26 est un organigramme pour coder la photométrie réelle en utilisant le système de syntaxe cidessus. Ainsi que représenté sur la figure 26, la géométrie est codée en combinant les procédés représentés sur les figures 24A ou 24B, en utilisant le système de syntaxe représenté sur la figure 25A.

La figure 26 est un organigramme de codage d'un modèle 3D polygonal en unités de partitions.

1. Un procédé de prédiction de limite est déterminé (étape 401). En d'autres termes, il est déterminé si le codage doit être exécuté par le procédé représenté par la figure 24A ou celui représenté par la figure 24B.

2. Le premier triangle apparaissant dans une partition, le triangle racine, est codé (étape 402).

3. La géométrie racine est codée (étape 403).

4. Si le prochain triangle existe (étape 404), la routine va au prochain triangle (étape 405) et ensuite va au prochain sommet (étape 406).

5. Il est déterminé si chaque sommet du triangle est traversé dans la partition précédente (étape 407). Si le

codage n'est pas exécuté dans la partition précédente, il est déterminé si le codage est exécuté dans la partition en cours (étape 409). Sinon, le sommet est codé (étape 410).

6. Si le sommet est codé dans la partition précédente, ou bien si la valeur de prédiction de limite est 1 (étape 408), il est déterminé si le sommet est visité (étape 409).

Sinon, le codage du sommet est exécuté (étape 410).

7. Les étapes 405 à 410 sont répétées jusqu'au dernier triangle de la partition en cours.

Maintenant, la syntaxe de codage pour mettre en #uvre le maillage en 3D progressif et la résilience aux erreurs sera décrit.

Le flux binaire comprimé pour un maillage polygonal 3D est composé d'un bloc de données d'en-tête avec des informations globales, suivi d'une séquence de blocs de données de composantes reliées, chacun associé avec une composante reliée du maillaae.

*En-tête <SEP> Données <SEP> CC <SEP> #1 <SEP> ... <SEP> Données <SEP> CC <SEP> #nCC
<tb> Maillage <SEP> 3D
<tb>

Si un maillage en 3D est codé en mode de résilience aux erreurs, les blocs de données de composantes reliées sont groupés ou divisés en partitions. ~~~~~~

<tb>
<tb> Partition <SEP> #1 <SEP> Partition <SEP> #2 <SEP> ... <SEP> Partition <SEP> #nPT
<tb>

Chaque bloc de données de composantes reliées est composé de trois enregistrements, le graphe de sommets, l'enregistrement d'arbre triangle, et l'enregistrement de données triangles

<tb>
<tb> @
<tb> Graphe <SEP> de <SEP> Sommets <SEP> Arbre <SEP> Triangle <SEP> Données <SEP> Triangle
<tb>

L'enregistrement d'arbre triangles contient la structure d'un arbre triangles d'ensemble qui relie tous les triangles des composantes reliées correspondantes formant un polygone simple. Le maillage polygonal est

représenté sous une forme triangulée dans le flux binaire, qui contient également les informations nécessaires pour reconstruire les faces originelles. L'enregistrement de graphe de sommets contient les informations nécessaires pour suturer des paires d'arêtes de limite du polygone simple afin de reconstruire la connectivité de composantes reliées originelles. La connectivité est classée en informations globales (pour chaque composante reliée) et en informations locales (pour chaque triangle). Les informations globales sont mémorisées dans les enregistrements de Graphe de Sommets et d'Arbre Triangles.

Les informations locales sont mémorisées dans l'enregistrement de Données Triangles.

Les données triangles sont disposées sur une base par triangle, dans laquelle l'arrangement des triangles est déterminé par la transversale de l'arbre triangles.

Données <SEP> pour <SEP> Données <SEP> pour... <SEP> Données <SEP> pour
<tb> triangle <SEP> #1 <SEP> triangle <SEP> #2 <SEP> triangle <SEP> #n
<tb>

Les données pour un triangle donné sont organisées comme suit .

<tb>
<tb> motif <SEP> de <SEP> td~orien- <SEP> arête <SEP> coord <SEP> normal <SEP> couleur <SEP> texCoord
<tb> progression <SEP> tation <SEP> polygone <SEP> ~~~ <SEP> ~~~~~
<tb>

Motif de progression, td~orientation, et arête~polygone constituent la connectivité par triangle. Les autres champs contiennent des informations destinées à reconstruire les coordonnées de sommets (coord) et, facultativement, des informations concernant normal, couleur et coordonnée texture (texCoord).

Syntaxe visuelle de flux binaire en langage c++
Objet maillé 3D

3D~Mesh~Object

<tb>
<tb> 3D~Mesh~Object() <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> 3D~MO~start~code <SEP> 16 <SEP> uimsbf
<tb> 3D~Mesh~Object~Header <SEP> ()
<tb> do <SEP> {
<tb> 3D~Mesh~Object~ <SEP> ()
<tb>

}while(nextbits bytealigned

<tb>
<tb> () <SEP> == <SEP> 3D~MOL~start~code
<tb> }
<tb>
3D~Mesh~Object~Header

3D Mesh~Object~Header () ::0. of bits Mnemonic

<tb>
<tb> ccw <SEP> bslbf
<tb> convex <SEP> bslbf
<tb> solid <SEP> bslbf
<tb> creaseAngle <SEP> uimsbf
<tb> coord~header <SEP> ()
<tb> normal~header <SEP> ()
<tb> color~header <SEP> ()
<tb> texCoord~header <SEP> ()
<tb> cgd~data <SEP> 1 <SEP> bslbf
<tb> if <SEP> (cgd~data=='1')
<tb> cgd~header <SEP> ()
<tb>
<tb>
3D~Mesh~Object~Layer

<tb>
<tb> 3D~Mesh~Object~Layer <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> 3D~MOL~start~code <SEP> 16 <SEP> uimsbf
<tb> mol <SEP> id <SEP> 3 <SEP> uimsbf
<tb> if <SEP> (cgd~data=='1') <SEP> {
<tb> cgd~n~vertices <SEP> 24 <SEP> uimsbf
<tb> cgd~n~triangles <SEP> 24 <SEP> uimsbf
<tb> cgd~n~edges <SEP> 24 <SEP> uimsVf
<tb> }
<tb>

<tb>
<tb> if <SEP> (mol~id==0)
<tb> 3D~Mesh~Object~Base~Layer()
<tb> else
<tb>

3D Mesh Object Refinement Layer() }~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3D~Mesh~Object~Base~Layer

3D~Mesh~Ob3ect~Base~Layer ( ) No. of bits Mnemonic

<tb>
<tb> do{
<tb> 3D <SEP> MOBL <SEP> start <SEP> code <SEP> 16 <SEP> uimsbf
<tb> mobl <SEP> id <SEP> 8 <SEP> uimsbf
<tb> while(!bytealigned()
<tb> one-bit <SEP> 1 <SEP> bslbf
<tb> qf~start <SEP> () <SEP>
<tb> if(3D <SEP> MOBL <SEP> start <SEP> code <SEP>
<tb> =="partition~type~0") <SEP> {
<tb> do{
<tb> connected~component()
<tb> qf <SEP> décode <SEP> (last <SEP> comportent, <SEP> vlclbf
<tb> last~component~context)
<tb>

}while(last component=='0')

<tb>
<tb> }
<tb> else <SEP> if(3D~MOBL~start~code
<tb> =="partition~type~1") <SEP> {
<tb> vg~number=O
<tb> do{
<tb> vertex~graph()
<tb> vg~number++
<tb> qf~decode(codap~last~vg, <SEP> vlclbf
<tb> codap~last~vg~context)
<tb>

}while(codap last vg=='0')

<tb>
<tb> }
<tb> else <SEP> if <SEP> (3D~MOBL~start~code
<tb> =="partition~type~2") <SEP> {
<tb>

<tb>
<tb> if(vg~number <SEP> > <SEP> 1)
<tb> qf~decode(codap~vg~id, <SEP> vlclbf
<tb> codap~vg~id~context)
<tb>

qf decode(codap left bloop idx, vlclbf codap left bloop idx context) qf-decode(codap-right bloopidx, vlclbf codap right bloop idx context)

<tb>
<tb> qf~decode(codap~bdry~pred, <SEP> vlclbf
<tb> codap~bdry~pred~context)
<tb> triangle~tree()
<tb> triangle <SEP> data <SEP> ( <SEP> ) <SEP>
<tb> } <SEP> ~~~~ <SEP> ~~~~~
<tb> }while(nexbits <SEP> bytealigned <SEP>
<tb> ()==3D~MOBL~start~code)
<tb> }
<tb>
coord header

<tb>
<tb> coord~header <SEP> () <SEP> { <SEP> No. <SEP> or <SEP> bits <SEP> Mnemonic
<tb> coord-binding <SEP> 2 <SEP> uimsbf
<tb> coord~bbox <SEP> 1 <SEP> blsbf
<tb> if <SEP> (coord~bbox=='1') <SEP> {
<tb> coord~xnin <SEP> 32 <SEP> blsbf
<tb> coord-ymin <SEP> 32 <SEP> blsbf
<tb> coord <SEP> zmin <SEP> 32 <SEP> blsbf
<tb> coord~size <SEP> 32 <SEP> blsbf
<tb> }
<tb> coord~quant <SEP> 5 <SEP> uimsbf
<tb> coord~pred~type <SEP> 2 <SEP> uimsbf
<tb>

if(coord pred type---"tree prediction"II

<tb>
<tb> coord~pred~type
<tb>

=="parallelogram~predietion")

<tb>
<tb> coord-nlambda <SEP> 2 <SEP> uimsbf
<tb> for <SEP> (i=1;<coord~nalmbda; <SEP> i++)
<tb> coord <SEP> lambda <SEP> 4-35 <SEP> simbf
<tb>

<tb>
<tb> }
<tb>
normal header

<tb>
<tb> normal~header <SEP> () <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> normal~binding <SEP> 2 <SEP> uimsbf
<tb> if(normal <SEP> binding <SEP> !=not~bound") <SEP> {
<tb> normal <SEP> bbox <SEP> 1 <SEP> blsbf
<tb> normal~quant <SEP> 5 <SEP> uimsbf
<tb> normal~pred~type <SEP> 2 <SEP> uimsbf
<tb>

if (normalyred~type=="tree~prediction" Il

<tb>
<tb> normal~pred~type
<tb> "parallelogram~prediction")
<tb> normal <SEP> nlambda <SEP> 2 <SEP> uimsbf
<tb> for <SEP> (i=l;<normal~nlambda; <SEP> i++) <SEP> simsbf
<tb> normal <SEP> lambda <SEP> 4-35
<tb>

} color header

<tb>
<tb> color~header <SEP> () <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> color <SEP> binding <SEP> 2 <SEP> uimsbf
<tb>

if(color binding!="not bound"){

<tb>
<tb> color <SEP> bbox <SEP> 1 <SEP> blsbf
<tb> if <SEP> (color~bbox=='1') <SEP> {
<tb> color <SEP> rmin <SEP> 32 <SEP> blsbf
<tb> color~gmin <SEP> 32 <SEP> blsbf
<tb> color <SEP> bmin <SEP> 32 <SEP> blsbf
<tb> color <SEP> size <SEP> 32 <SEP> blsbf
<tb> }
<tb> color~quant <SEP> 5 <SEP> uimsbf
<tb> color~pred~type <SEP> 2 <SEP> uimsbf
<tb>

if(color~pred~type=="tree~prediction" Il

<tb>
<tb> color~pred~type
<tb> "parallelogram~prediction")
<tb> color <SEP> nlambda <SEP> 2 <SEP> uimsbf
<tb> for <SEP> (i=1 <SEP> ; <SEP> i<color~nlambda; <SEP> i++)
<tb> color <SEP> lambda <SEP> 4-35 <SEP> simsbf
<tb> }
<tb> }
<tb> }
<tb>
texCoord header

<tb>
<tb> texCoord <SEP> header <SEP> ( <SEP> ) <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> texCoord~binding <SEP> 2 <SEP> uimsbf
<tb>

if(texCoord binding!="not bound"){

<tb>
<tb> texCoord <SEP> bbox <SEP> 1 <SEP> blsbf
<tb>

if (texCoord bbox==' 1' )

<tb>
<tb> texCoord <SEP> umin <SEP> 32 <SEP> blsbf
<tb> texCoord <SEP> vmin <SEP> 32 <SEP> blsbf
<tb> texCoord <SEP> size <SEP> 32 <SEP> blsbf
<tb> }
<tb> texCoord <SEP> quant <SEP> 5 <SEP> uimsbf
<tb> texCoord~pred~type <SEP> 2 <SEP> uimsbf
<tb> if(texCoord~pred~type
<tb> =="tree~prediction"#
<tb> texCoord~pred~type <SEP> ==
<tb>

"parallelogram~predictionH)

<tb>
<tb> texCoord <SEP> nlambda <SEP> 2 <SEP> uimsbf
<tb>

for(i=l;i<texCoord nlambda; i++)

<tb>
<tb> texCoord <SEP> lambda <SEP> 4-35 <SEP> simsbf
<tb>

cgd header

<tb>
<tb> cgd~header <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> cgd <SEP> n <SEP> proj <SEP> surface <SEP> spheres <SEP> 4 <SEP> uimsbf
<tb>

if(cgd~n proj-surface spheres!=0){ ~~~~~~~~~~~~

<tb>
<tb> cgd~x~coord~center~point <SEP> 32 <SEP> ieeefl <SEP>
<tb> cgd <SEP> y <SEP> coord~center~point <SEP> 32 <SEP> ieeefl
<tb> cgd <SEP> z <SEP> coord~center~point <SEP> 32 <SEP> ieeefl
<tb> cgd~normalized~screen~distance~factor <SEP> 8 <SEP> uimsbf
<tb>

for ( 1=0 ; i≤cgd~n~pro j~sur f ace~spheres ; i++) {

<tb>
<tb> cgd~radius <SEP> 32 <SEP> ieeefl <SEP>
<tb> cgd~min~proj~surface <SEP> 32 <SEP> ieeefl <SEP>
<tb> cgd~n~proj~points <SEP> 8 <SEP> uimsbf <SEP>
<tb>

for(j=0;j≤cgd~n~proj~points; j++){

<tb>
<tb> cgd <SEP> sphere~point~coord <SEP> 11 <SEP> uimsbf
<tb> cgd~proj~surface <SEP> 32 <SEP> uimsbf
<tb> }
<tb> }
<tb> }
<tb> }
<tb>
connected~component

<tb>
<tb> connected~component <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> vertex~graph <SEP> ()
<tb> qf~decode <SEP> (has~stitches, <SEP> has~stiches~context) <SEP> vl <SEP> clbf <SEP>
<tb> if <SEP> (has~stitches=='1')
<tb> stitches <SEP> ()
<tb> triangle~tree <SEP> ()
<tb> triangle~data <SEP> () <SEP>
<tb> }
<tb>
vertex~graph

<tb>
<tb> vertex~graph <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> qf~decode <SEP> (vg~simple, <SEP> vg~simple~context) <SEP> vlclbf
<tb> dephth=0
<tb>

<tb>
<tb> code <SEP> last='l' <SEP>
<tb> openloops=0
<tb> do{
<tb> do{
<tb> if <SEP> (code~last=='1') <SEP> {
<tb> qf~decode(vg~last, <SEP> vg~last~context) <SEP> vlclbf
<tb> if{openloops>0){
<tb> qf~decode(vg~forward~run, <SEP> vlclbf
<tb> vg~forward~run~context)
<tb> if <SEP> (vg~forward~run=='0') <SEP> {
<tb> openloopif(openloops>0)
<tb> qf~decode <SEP> (vg~loop~index, <SEP> vlclbf
<tb> vg~loop~index~context)
<tb> Break
<tb>

} }

<tb>
<tb> qf~decode(vg~run~length, <SEP> vlclbf
<tb> vg~run~length~context)
<tb> qf~decode(vg~leaf, <SEP> vg <SEP> leaf <SEP> context) <SEP> vlclbf
<tb>

if(vg leaf=='l'&&vg simple=='0'){

<tb>
<tb> qf~decode <SEP> (vg~loop, <SEP> vg~loop~context) <SEP> vlclbf
<tb> if(vg~loop=='l')
<tb> openloops++
<tb> }
<tb> }while(0)
<tb>

if (vg~leaf l' &&vg last=' l' &&code last=' 1' ) depth-if (vg leaf=' 0' && (vg~last= ' 0 ' ! ! oode~last= ' 0 ' ) )

<tb>
<tb> depth++
<tb> code~last=vg~leaf
<tb> }while(depth <SEP> ≥0)
<tb> }
<tb>

stitches

<tb>
<tb> stitches <SEP> ( <SEP> ) <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> for <SEP> each <SEP> vertex <SEP> in <SEP> connecte~component <SEP> {
<tb> qf~decode(stitch~cmd, <SEP> stitch~cmd~context) <SEP> vlclbf
<tb> if <SEP> (stitch~cmd) <SEP>
<tb> qf~decode <SEP> (stitch~pop~or~get, <SEP> vlclbf
<tb> stitch~pop~or~get~context)
<tb>

if (stitch~pop~or~get== ' 1 ' ) qf - decode (sti tch J'OP, stitch~pop context) vlclbf

<tb>
<tb> qf~decode <SEP> ( <SEP> stitch~stitch~stack~index, <SEP> vlclbf
<tb> stitch <SEP> stitch <SEP> stack <SEP> index <SEP> context) <SEP>
<tb>

qf-decode(stitch~incr-length, vlclbf

<tb>
<tb> stitch~incr~length~context)
<tb> if <SEP> (stitch~incr~length!=0)
<tb> qf~decode <SEP> (stitch~incr~length~sign, <SEP> vlclbf
<tb> stitch~incr~length~sign~context)
<tb> qf~decode(stitch~push, <SEP> vlclbf
<tb> stitch~push~context)
<tb> if(total <SEP> length>0)
<tb>

qf decode(stitch reverse, vlclbf

<tb>
<tb> stitch~reverse~context)
<tb> }
<tb> else
<tb> qf~decode <SEP> (stitch~length, <SEP> vlclbf
<tb> stitch~length~context)
<tb>

} triangle tree

<tb>
<tb> triangle~tree <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> depth <SEP> = <SEP> 0
<tb> ntriangles <SEP> = <SEP> 0
<tb> branch <SEP> position <SEP> = <SEP> 0
<tb>

qf decode (tt nm length, tt- run ~lergth - cx:ntext) vlclbf

<tb>
<tb> ntriangles <SEP> += <SEP> tt~run~length()
<tb> qf~decode(tt~leaf, <SEP> tt~leaf~context) <SEP> vlclbf
<tb> if <SEP> (tt~leaf=='1') <SEP> {
<tb> depth--
<tb> }
<tb> else
<tb> branch~position <SEP> = <SEP> ntriangles
<tb> depth++
<tb> }
<tb> }while(depth <SEP> ≥0)
<tb>

if (3D~MOBL~start~code="partition~type~2" ) if (o::rl3p - right~blo::p - idx-o:d3p ~left - blccp ydx-

<tb>
<tb> l>ntriangles)
<tb> if(branch~position <SEP> ntriangles-2){
<tb> qf~decode(codap~branch~len, <SEP> vlclbf
<tb> codap~branch~len~context)
<tb> n~triangles-=2
<tb> }
<tb> else
<tb> n~triangles--
<tb> }
<tb> }
<tb>
triangle~data

<tb>
<tb> triangle <SEP> data <SEP> ( <SEP> ) <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> qf~decode <SEP> (triangulated, <SEP> triangulated <SEP> context) <SEP> vlclbf
<tb> depth <SEP> = <SEP> 0;
<tb> root~triangle()
<tb> for(i=l; <SEP> i<ntriangles; <SEP> i++) <SEP> {
<tb> triangle(i)
<tb> }
<tb>

root~triangle

<tb>
<tb> root~triangle <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> if(marching <SEP> triangle) <SEP>
<tb> qf~decode(marching~pattern, <SEP> vlclbf
<tb> marching~pattern~context[marching~pattern])
<tb> else{
<tb>

if ( 3D~MOBL~start~code=="partition type~2 " ) if(tt~leaf=='0'&&depth==O) qf decode(td orientation, vlclbf

<tb>
<tb> td~orientation~context)
<tb> if <SEP> (tt~leaf=='0')
<tb> depth++
<tb> else
<tb> depth--
<tb> } <SEP> HHH
<tb>

if ( 3D~MOBL~start~code="partition type~2 " )

<tb>
<tb> if(triangulated=='0')
<tb> qf~decode(polygon~edge, <SEP> vlclbf
<tb>

polygon~edge~context[polygon~edge] )

<tb>
<tb> root~coord <SEP> ()
<tb> root~normal <SEP> ()
<tb> root~color <SEP> ()
<tb> root~texCoord <SEP> ()
<tb> }
<tb>

<tb>
<tb> root~coord <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb>

if(3D~MOBL~start~code="partition type~2")

<tb>
<tb> if <SEP> (visited[vertex~index] <SEP> ==0) <SEP>
<tb> root~coord~sample()
<tb>

if(visited[vertex indexJ==0){

<tb>
<tb> coord~sample <SEP> ()
<tb> coord~sample()
<tb> }
<tb>

~~}

<tb>
<tb> else{
<tb> root~coord~sample <SEP> ()
<tb> coord~sample <SEP> ()
<tb> coord~sample <SEP> ()
<tb>

~~}

<tb>
<tb> root~normal <SEP> () <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> if(normal-binding <SEP> ! <SEP> ="not~bound") <SEP> {
<tb>

if (3D~M0BL~start~code="partition type~2") if(normal~binding != "bound per vertex"visited[vertex index) =0){ root normal sample;) if(normal binding!="bcund er face"&& (normal~binding != "bound~per~vertex" || visited [vertex~index]=0) )

<tb>
<tb> normal~sample <SEP> ()
<tb> normal~sample <SEP> ()
<tb> }
<tb> }
<tb> else <SEP> {
<tb> root~normal~sample <SEP> ()
<tb>

if !(norrnal~binding="bound~per~face")

<tb>
<tb> normal~sample <SEP> () <SEP>
<tb> normal~sample <SEP> () <SEP>
<tb> }
<tb> root~color <SEP> () <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> if(color-binding <SEP> !="not~bound")
<tb>

if (3D IBL start code--"partition type~2") {

<tb>
<tb> if(color~binding <SEP> !=
<tb>

"bound~per~vertex" !)visited[vertex~index]==0) {

<tb>
<tb> root~color~sample()
<tb> if <SEP> (color~binding <SEP> ! <SEP> ="bound~per~face"&& <SEP>
<tb> (color~binding <SEP> !=
<tb>

"bound~per~vertex" Il visited [vertex~index] =0) ) {

<tb>
<tb> color~sample <SEP> ()
<tb> color~sample <SEP> ()
<tb> }
<tb> }
<tb> else
<tb> root <SEP> color <SEP> sample() <SEP>
<tb>

if (color~binding!="bound~per~face") {

<tb>
<tb> color~sample()
<tb> color <SEP> sample <SEP> ( <SEP> ) <SEP>
<tb> }
<tb>

}

<tb>
<tb> root~texCoord <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> if(texCoord~binding <SEP> !="not~bound") <SEP> {
<tb>

if (3D MBL star-t-code"partition type 2") { if(texCoord~binding != "bound ~per ~vertex" Il visi ted [ vertex~index] =0) (

<tb>
<tb> root~texCoord~sample()
<tb> if(texCoord~binding <SEP> !=
<tb>

"bound~per~vertex" "visited [vertex index]=0) {

<tb>
<tb> texCoord~sample()
<tb> texCoord~sample()
<tb>

? ~~~ ~~~ }

<tb>
<tb> else{
<tb> root~texCoord~sample()
<tb> texCoord~sample()
<tb>

<tb>
<tb> texCoord~sample <SEP> ()
<tb> triangle
<tb> triangle <SEP> (){ <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> if(marching <SEP> triangle) <SEP>
<tb>

qf decode(marching pattern, vlclbf marchingattern context[marching pattern]) else{ if (3D MOBL-start-code== "partition type~2") if(tt leaf=='0'&&depth==0) qf decode(td orientation, vlclbf

<tb>
<tb> td~orientation~context)
<tb> if <SEP> (tt~leaf=='0')
<tb> depth++
<tb> else
<tb> depth-if(triangulated=='0')
<tb> qf~decode(polygon~edge, <SEP> vlclbf
<tb> polygon~edge~context[polygon~edge])
<tb> coord <SEP> ( <SEP> ) <SEP>
<tb> normal <SEP> ( <SEP> ) <SEP>
<tb> color <SEP> ( <SEP> ) <SEP>
<tb> texCoord <SEP> ()
<tb> }
<tb> coord <SEP> () <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> if <SEP> (3D~MOBL~start~code== <SEP> "partition <SEP> type~2")
<tb> if(visited[vertex <SEP> index]==0) <SEP>
<tb> if(no <SEP> ancestors) <SEP>
<tb> root~coord~sample <SEP> ()
<tb> Else
<tb> coord~sample()
<tb>

if(visited[vertex~index]==O)

<tb>
<tb> coord~sample <SEP> ()
<tb> }
<tb> }
<tb> normal <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> if <SEP> (normal~binding=="bound~j)er~vertex") <SEP>
<tb>

if (3D J'DBL - start- ccxie== "partition type 2") if(visited[vertex~index]==0)

<tb>
<tb> if(no <SEP> ancestors) <SEP>
<tb> root~normal <SEP> sample() <SEP>
<tb> else
<tb> normal~sample <SEP> ()
<tb> }
<tb> else{
<tb> if <SEP> (visited <SEP> [vertex~index] <SEP> ==0) <SEP>
<tb> normal~sample()
<tb> }
<tb>

}else if (norTIBl- binding== "boW1d J>8r ~face") { if (triangulated=' 1 ' ! ! 1 polygcn~edge== ' 1 ' ) ~~~~~ ~~~~~~~ nor;nal sample ( ) }else if (nomBl~binding== "boW1d~per ~corner") if(triangulated=='1'! polygon~edge=='1')

<tb>
<tb> normal~sample <SEP> ()
<tb> normal~sample <SEP> ()
<tb> }
<tb> normal~sample()
<tb> }
<tb> }
<tb> color(){ <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb>

if (color~binding=="bound~per~vertex")

if (3D NKBL start code=="partition type 2") {

<tb>
<tb> if(visited[vertex <SEP> index]==0) <SEP>
<tb> if(no <SEP> ancestors) <SEP>
<tb> root~color~sample <SEP> ()
<tb> Else
<tb> color~sample()
<tb> }
<tb> else{
<tb>

if(visited[vertex indexJ==0)

<tb>
<tb> color~sample <SEP> ()
<tb>

}else if(color binding="bound~per face"){

<tb>
<tb> if <SEP> (triangulated==' <SEP> l' <SEP> polygon~edge==' <SEP> 1 <SEP> ' <SEP> ) <SEP>
<tb> color~sample()
<tb>

}else if(color binding--"bound per corner")

<tb>
<tb> if <SEP> (triangulated== <SEP> ' <SEP> 1' <SEP> polygon~edge==' <SEP> 1 <SEP> ' <SEP> ) <SEP>
<tb> color~sample()
<tb> color~sample()
<tb> }
<tb> color <SEP> sample() <SEP>
<tb>

} texCoord ( ) No. of bits Mnemonic if (texCoord~binding="bound~per~vertex") if (3D NYJBL start code="partit~on type~2") if (visited[vertex index]==0)

<tb>
<tb> if <SEP> (no <SEP> ancestors) <SEP>
<tb> root <SEP> texCoord <SEP> sample() <SEP>
<tb> else
<tb> texCoord~sample()
<tb> }
<tb> else{
<tb> if <SEP> (visited[vertex <SEP> index]==0) <SEP>
<tb>

<tb>
<tb> texCoord~sample()
<tb> }
<tb>

}else if (texCoord~binding="bound~per~comer") { if (triangulated='1'! ! polygon~edge== '1')

<tb>
<tb> texCoord~sample()
<tb> texCoord~sample()
<tb> } <SEP> ~~~~~~~~
<tb> texCoord~sample()
<tb> }
<tb> }
<tb> root~coord~sample <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> for <SEP> (i=0; <SEP> i<3; <SEP> i++)
<tb> for <SEP> (j=0; <SEP> j<coord <SEP> quant; <SEP> j++)
<tb> qf~decode(coord~bit, <SEP> zero~context) <SEP> vlclbf
<tb> }
<tb> root~normal~sample <SEP> () <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> for <SEP> (i=0; <SEP> i<3; <SEP> i++)
<tb> for <SEP> (j=0; <SEP> j<normal~quant; <SEP> j++)
<tb> qf~decode <SEP> (normal~bit, <SEP> zero~context) <SEP> vlclbf
<tb>
<tb> root~color~sample <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> for <SEP> (i=0, <SEP> i<3; <SEP> i++)
<tb> for <SEP> (j=0; <SEP> j<color~quant; <SEP> j++)
<tb> qf~decode(color~bit, <SEP> zero~context) <SEP> vlclbf
<tb> } <SEP> ~~~
<tb> root~texCoord~sample <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> for <SEP> (i=0, <SEP> i<3; <SEP> i++)
<tb> for <SEP> (j=0; <SEP> j<texCoord~quant; <SEP> j++)
<tb> qf~decode(texCoord~bit, <SEP> zero~context) <SEP> vl <SEP> c <SEP> lbf <SEP>
<tb>

<tb>
<tb> }
<tb> coord <SEP> sample(){ <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> for <SEP> (i=0, <SEP> i<3; <SEP> i++){
<tb> j=0
<tb> do{
<tb> qf~decode(coord~leading~bit, <SEP> vlclbf
<tb>

coord~leading~bit~context[3*j+i])

}w"~'le ( j<ooord quant && ooord~leading~bit='0') if (coord leading bit=='l'){ qf~decocie(coord~sign~bit, zero~context ) vlclbf do{ qf - d2o:::d2 (o::x:>rcL trai1 ing~bit, zero~context) v 1 c lb f

<tb>
<tb> }while <SEP> (j<coord~quant)
<tb> }
<tb> }
<tb> }
<tb> normal~sample <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> for <SEP> (i=0, <SEP> i<l; <SEP> i++){
<tb> j=0
<tb> do{
<tb>

qf~decode(normal~leading~bit, vlclbf nOTImal~leading~bit~context[j))

<tb>
<tb> j++
<tb> }while <SEP> (j<normal~quant&&
<tb> normal~leading~bit=='0')
<tb>

if (normal leading bit=='l'){ qf~decode(normal~signj3it, zero~context) vlclbf

qf - d2o:::d2 (nomal- trailing- bit, zero context) v l c l b f

<tb>
<tb> }while <SEP> (j<normal~quant)
<tb> }
<tb>

<tb>
<tb> }
<tb> }
<tb> color~sample <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> for(i=0, <SEP> i<3; <SEP> i++){
<tb> j=0
<tb> do{
<tb> qf~decode <SEP> (color~leading~bit, <SEP> vlclbf
<tb> color~leading~bit~context[3*j+i])
<tb> j++
<tb> }while(j<color~quant <SEP> && <SEP> color~leading~bit=='0')
<tb> if <SEP> (color~leading~bit=='1') <SEP> {
<tb> qf~decode(color~sign~bit, <SEP> zero~context) <SEP> vlclbf
<tb> do{
<tb>

qf decode (color~trailing~bit, zero - context) v 1 c 1 b f

<tb>
<tb> }while <SEP> (j<color~quant)
<tb> }
<tb> } <SEP> ~~~~
<tb> }
<tb> texCoord~sample <SEP> () <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> for(i=0, <SEP> i<l; <SEP> i++) <SEP> {
<tb> j=0
<tb> do{
<tb> qf~decode(texCoord~leading~bit, <SEP> vlclbf
<tb>

texCoord~leading~bit~context[2*j+i])

<tb>
<tb> j++
<tb> }while <SEP> (j<texCoord~quant&&
<tb> texCoord <SEP> leading <SEP> bit=='0') <SEP>
<tb> if <SEP> (texCoord <SEP> leading <SEP> bit=='l'){ <SEP>
<tb> qf~decode <SEP> (texCoord~sign~bit, <SEP> zero~context) <SEP> vlclbf
<tb> do <SEP> {
<tb> qf~decode(texCoord~trailing~bit, <SEP> vlclbf
<tb> zero~context)
<tb>

<tb>
<tb> }while <SEP> (j<texCoord~quant)
<tb> 3D <SEP> Mesh <SEP> Object~Refinement~Layer
<tb> 3D <SEP> Mesh <SEP> Object~Refinement~Layer <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> do{
<tb> 3D <SEP> MORL <SEP> start <SEP> code <SEP> 16 <SEP> uimsbf
<tb> morl <SEP> id <SEP> 8 <SEP> uimsbf
<tb> connectivity~update <SEP> 2 <SEP> uimsbf
<tb> pre~smoothing <SEP> 1 <SEP> bslbf
<tb> if <SEP> (pre~smoothing=='l')
<tb> pre~smoothing~parameters <SEP> ()
<tb> post~smoothing <SEP> 1 <SEP> bslbf
<tb> if <SEP> (post~smoothing=='l')
<tb> post <SEP> smoothing <SEP> parameters() <SEP>
<tb> while <SEP> (!bytealigned())
<tb> one <SEP> bit <SEP> 1 <SEP> bslbf
<tb> qf~start <SEP> () <SEP>
<tb> if <SEP> (connectivity~update=="fs~update")
<tb> fs~pre~update <SEP> ()
<tb>

if (pre s=thincF='1'1 r:ost - sroothing==' 1 ' )

<tb>
<tb> smoothing <SEP> constraints() <SEP>
<tb> /*apply <SEP> pre <SEP> smoothing <SEP> step*/
<tb> if <SEP> (connectivity~update=="fs~update")
<tb> fs~post~update <SEP> ()
<tb>

if (conr.ectivity~update=="not updated")

<tb>
<tb> qf~decode <SEP> (other~update, <SEP> zero~context) <SEP> vlc <SEP> lbf <SEP>
<tb> if <SEP> (connectivity~update=="not~updated")
<tb> other~update=='1')
<tb> other~property~update()
<tb> /*apply <SEP> post <SEP> smoothing <SEP> step*/
<tb> }while
<tb>

(nextbits~bytealigned ( ) =3D~MDRL~start~code)

<tb>
<tb> }
<tb> pre~smoothing~parameters
<tb> pre~smoothing~parameters <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> pre~smoothing~n <SEP> 8 <SEP> uimsbf
<tb> pre~smoothing~lambda <SEP> 32 <SEP> ieeefl
<tb> pre~smoothing~mu <SEP> 32 <SEP> ieeefl
<tb>

}~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

<tb>
<tb> post~smoothing~parameters
<tb> post~smoothing~parameters <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> post <SEP> smoothing <SEP> n <SEP> 8 <SEP> uimsbf
<tb> post~smoothing~lambda <SEP> 32 <SEP> ieeefl
<tb> post~smoothing~mu <SEP> 32 <SEP> ieeefl
<tb> }
<tb> fs~pre~update
<tb> fs~pre~update <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> for <SEP> each <SEP> connected <SEP> component{
<tb> forest <SEP> () <SEP>
<tb> for <SEP> each <SEP> tree <SEP> in <SEP> forest{
<tb> triangle <SEP> tree() <SEP>
<tb> /*for <SEP> each <SEP> tree <SEP> loop <SEP> vertex <SEP> set
<tb> visited <SEP> [vertex~index] <SEP> = <SEP> '1' <SEP> */
<tb> triangle <SEP> data() <SEP>
<tb> forest <SEP> () <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> for <SEP> each <SEP> edge <SEP> in <SEP> connected <SEP> component
<tb> if <SEP> (creates <SEP> no <SEP> loop <SEP> in <SEP> forest)
<tb>

<tb>
<tb> qf~decode(pfs~forest~edge), <SEP> vlclbf
<tb> pfs <SEP> forest <SEP> edge <SEP> context) <SEP>
<tb> }
<tb> smoothing~constraints
<tb> smoothing~constraints <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb>

q decocle(snooth with-sharp~dges,zero-context) vlclbf

<tb>
<tb> if <SEP> (smooth~with~sharp~edges=='l')
<tb> sharp~edge~marks()
<tb>

qf~decode (smooth~with~fixed~vertices, vlclbf

<tb>
<tb> z ro <SEP> context) <SEP>
<tb> if <SEP> (smooth~with~fixed~vertices=='l')
<tb> fixed~vertex~marks <SEP> ()
<tb> }
<tb> sharp~edge~marks <SEP> () <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> for <SEP> each <SEP> edge
<tb> qf~decode(smooth~sharp~edge, <SEP> vlclbf
<tb> smooth~sharp~edge~context)
<tb>

}~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

<tb>
<tb> fixed~vertex~marks <SEP> () <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> for <SEP> each <SEP> vertex
<tb>

qf decode(smooth-fixed vertex, vlclbf

<tb>
<tb> smooth~fixed~vertex~context)
<tb> }
<tb> fs <SEP> post <SEP> update
<tb> fs <SEP> post <SEP> update <SEP> (){ <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> for <SEP> each <SEP> connected <SEP> component{
<tb> for <SEP> each <SEP> tree <SEP> in <SEP> forest
<tb> tree~loop~property~update()
<tb> }
<tb>

<tb>
<tb> tree~loop~property~update <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> loop~coord~update()
<tb> loop~normal~update()
<tb> loop~color~update()
<tb> loop~texCoord~update <SEP> ()
<tb> }
<tb> loop~coord~update <SEP> () <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> for <SEP> each <SEP> tree <SEP> loop <SEP> vertex
<tb> coord <SEP> sample() <SEP>
<tb> }
<tb> loop~normal~update <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb>

if(normal binding=="boundper vertex"){

<tb>
<tb> for <SEP> each <SEP> tree <SEP> loop <SEP> vertex
<tb> normal~sample <SEP> ()
<tb> }
<tb>

else if(nollTl3.1~binding ''toundyer~facetl) {

<tb>
<tb> for <SEP> each <SEP> tree <SEP> loop <SEP> face
<tb> normal~sample <SEP> ()
<tb> }
<tb>

else if (nollTl3.1~binding "roundyer ~corner")

<tb>
<tb> for <SEP> each <SEP> tree <SEP> loop <SEP> corner
<tb> normal~sample()
<tb>

}

<tb>
<tb> loop~color~update <SEP> () <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> if <SEP> (color~binding=="bound~per~vertex") <SEP>
<tb> for <SEP> each <SEP> tree <SEP> loop <SEP> vertex
<tb> color~sample <SEP> ()
<tb> }
<tb>

else if (color~binding="bound~per~face")

<tb>
<tb> color~sample()
<tb> }
<tb>

else if (color - binding="bound ~per - corner")

<tb>
<tb> for <SEP> each <SEP> tree <SEP> loop <SEP> corner
<tb> color~sample <SEP> ()
<tb> }
<tb> }
<tb> loop~texCoord~update <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb>

if (texCoord~binding="boundyer~vertex"){

<tb>
<tb> for <SEP> each <SEP> tree <SEP> loop <SEP> vertex
<tb> texCoord~sample <SEP> ()
<tb> }
<tb>

else if (texCtoordJoindijig==''bound~per~corner")

<tb>
<tb> for <SEP> each <SEP> tree <SEP> loop <SEP> corner
<tb> texCoord~sample()
<tb> }
<tb> }
<tb> other~property~update
<tb> other~property~update <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> other~coord~update()
<tb> other~normal~update()
<tb> other~color~update()
<tb> other~texCoord~update()
<tb> }
<tb> other~coord~update <SEP> () <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> for <SEP> each <SEP> vertex <SEP> in <SEP> mesh
<tb> if(vertex <SEP> is <SEP> not <SEP> a <SEP> tree <SEP> loop <SEP> vertex)
<tb> coord~sample() <SEP> ( <SEP> ) <SEP>
<tb>
<tb>

<tb>
<tb> other~normal~update <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb>

if (normal~binding="bound~per~vertex") {

<tb>
<tb> for <SEP> each <SEP> vertex <SEP> in <SEP> mesh
<tb> if(vertex <SEP> is <SEP> not <SEP> a <SEP> tree <SEP> loop <SEP> vertex)
<tb> normal~sample <SEP> ()
<tb> }
<tb>

else if (normal~binding="bound~per~face") {

<tb>
<tb> for <SEP> each <SEP> face <SEP> in <SEP> mesh
<tb> if(face <SEP> is <SEP> not <SEP> a <SEP> tree <SEP> loop <SEP> face)
<tb> normal~sample <SEP> ()
<tb> }
<tb> else
<tb>

if (normal~binding=="bound~per~corner")

<tb>
<tb> for <SEP> each <SEP> corner <SEP> in <SEP> mesh
<tb> if(corner <SEP> is <SEP> not <SEP> a <SEP> tree <SEP> loop <SEP> corner)
<tb> normal~sample <SEP> ()
<tb> other~color~update <SEP> () <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb> if <SEP> (color~binding="bound~per~vertex") <SEP>
<tb> for <SEP> each <SEP> vertex <SEP> in <SEP> mesh
<tb> if(vertex <SEP> is <SEP> not <SEP> a <SEP> tree <SEP> loop <SEP> vertex)
<tb> color <SEP> sample() <SEP>
<tb> }
<tb> else <SEP> if <SEP> (color~binding="bound~per~face") <SEP>
<tb> for <SEP> each <SEP> face <SEP> in <SEP> mesh
<tb> if(face <SEP> is <SEP> not <SEP> a <SEP> tree <SEP> loop <SEP> face)
<tb> color <SEP> sample() <SEP>
<tb> }
<tb>

else if (colorjoinding# "bound~per~corner")

<tb>
<tb> for <SEP> each <SEP> corner <SEP> in <SEP> mesh
<tb> if(corner <SEP> is <SEP> not <SEP> a <SEP> tree <SEP> loop <SEP> corner
<tb> color <SEP> sample() <SEP>
<tb>

<tb>
<tb> }
<tb> other~texCoord~update <SEP> () <SEP> { <SEP> No. <SEP> of <SEP> bits <SEP> Mnemonic
<tb>

if (texCoord~binding="bound~per~vertex")

<tb>
<tb> for <SEP> each <SEP> vertex <SEP> in <SEP> mesh
<tb> if(vertex <SEP> is <SEP> not <SEP> a <SEP> tree <SEP> loop <SEP> vertex)
<tb> texCoord~sample()
<tb> }
<tb>

else if(texCoord~binding "J:ound....P2r~comer") {

<tb>
<tb> for <SEP> each <SEP> corner <SEP> in <SEP> mesh
<tb> if(corner <SEP> is <SEP> not <SEP> a <SEP> tree <SEP> loop <SEP> corner)
<tb> texCoord~sample()
<tb> } <SEP> ZIZHZ
<tb>
Objet Maillé 3D Code~départ~OM : ceci est un code à 16 bits unique qui est utilisé dans un but de synchronisation. La valeur de ce code est toujours '0000 COOO 0010 0000'.

# Niveau~Objet~Maillé~3D code~départ~COM~3D : ceci est un code unique à 16 bits qui est utilisé dans un but de synchronisation. La valeur de ce code est toujours : '0000 0000 0011 0000' mol~id : cet entier à 8 bits sans signe spécifie un id unique pour la couche d'objet maillé. Une valeur de 0 indique une couche de base, et une valeur plus grande que 0 indique une couche d'affinage. Le premier Niveau Objet Maillé 3D immédiatement après un En- tête~Objet~Maillé~3D doit avoir mold~id = 0, et les Niveaux~Objet~Maillé~3D subséquents après le même Objet~Maillé~3D doivent avoir mold~id > 0. sommets~n~cgd : ceci est le nombre de sommets dans la résolution en course de la maille 3D.Utilisée pour supporter la dégradation élégante du calcul.

n triangles cgd: ceci est le nombre de sommets dans la résolution en course de la maille 3D. Utilisée pour supporter la dégradation élégante de calcul. n~arêtes~cgd : ceci est le nombre d'arêtes dans la résolution en course de la maille 3D. Utilisée pour supporter la dégradation élégante de calcul.

# Niveau~Base~Objet~Maillé~3D code~départ~CBOM~3D : ceci est un code de longueur 16 qui est utilisé dans un but de synchronisation. Il indique aussi trois types différents de partition pour résilience aux erreurs.

Tableau 2. Définition des informations du type de partition

<tb>
<tb> code <SEP> départ <SEP> CBOM <SEP> 3D <SEP> Type <SEP> partition <SEP> Signification
<tb> '0000 <SEP> 0000 <SEP> 0011 <SEP> 0001' <SEP> Partition~type~0 <SEP> Un <SEP> ou <SEP> plus <SEP> groupes <SEP> de
<tb> vg, <SEP> tt <SEP> et <SEP> dt
<tb> '0000 <SEP> 0000 <SEP> 0011 <SEP> 0011' <SEP> Partition <SEP> type <SEP> 1 <SEP> Un <SEP> ou <SEP> plus <SEP> vgs
<tb> '0000 <SEP> 0000 <SEP> 0011 <SEP> 0100' <SEP> Partition <SEP> type <SEP> 2 <SEP> Une <SEP> paire <SEP> de <SEP> tt <SEP> et <SEP> td
<tb>
id mobl : cet entier sans signe à 8 bits spécifie un id unique pour la composante d'objet maillé. un bit : cette valeur booléenne est toujours vraie. Ce bit unique est utilisé pour l'alignement d'octets. dernière~composante : cette valeur booléenne indique s'il y a davantage de composantes reliées devant être décodées. Si la dernière composante est '1', alors la dernière composante a été décodée. Sinon, il y a davantage de composantes devant être décodées. Ce champ est codé arithmétiquement. codap dernier vg : cette valeur booléenne indique si le vg en cours est le dernier dans la partition. La valeur est fausse s'il y a davantage de vg devant être décodés dans la partition.

identificateur~graphe~sommet: cet entier sans signe indique l'id du graphe de sommets correspondant à la paire tt/td en cours dans partition~type~2. La longueur de cette valeur est une valeur à échelle logarithmique du vg~number de vg décodé à partir du précédent partition~type~l. S'il y a seulement un vg dans le précédent partition~type~l, identificateur~graphe~sommet n'est pas utilisé.

Index boucle~englobante~gauche~codap : cet entier sans signe indique l'index de départ gauche, à l'intérieur de la table de boucle englobante d'une composante reliée, pour les triangles qui doivent être reconstruits dans une partition. La longueur de cette valeur est la valeur à échelle logarithmique de la taille de la table de boucle englobante.

Index~boucle~englobante~droite~codap : cet entier sans signe indique l'index de départ droit, à l'intérieur de la table de boucle englobante d'une composante reliée, pour les triangles qui doivent être reconstruits dans une partition. La longueur de cette valeur est la valeur à échelle logarithmique de la taille de la table de boucle englobante. codap~bdry~pred : cette marque booléenne indique comment prédire les informations de géométrie et de photométrie qui sont en commun dans deux ou plusieurs partitions. Si codap~bdry~pred est fil, le mode de prédiction de limite restreint est utilisé, sinon, le mode de prédiction de limite étendu est utilisé.

# En-tête~Objet~Maillé~3D ccw : cette valeur booléenne indique si l'agencement de sommets des faces décodées suit un ordre inverse de celui des aiguilles d'une montre. convexe : cette valeur booléenne indique si le modèle est convexe. solide : cette valeur booléenne indique si le modèle est massif.

creaseAngle : cet entier à 6 bits sans signe indique l'angle de pli.

# coord~header liaison~coord : cet entier à 2 bits sans signe indique la fixation des coordonnées de sommet au maillage en 3D. La seule valeur admissible pour liaison~coord est '01'. coord~bbox : cette valeur booléenne indique si une boite de limitation est fournie pour la géométrie. Si aucune boite de limitation n'est fournie, une boite de limitation par défaut est utilisée. coord~xmin, coord~ymin et ccord~zmin : ces valeurs à virgule flottante indiquent le coin inférieur gauche de la boite de limitation dans laquelle se trouve la géométrie. coord~size : cette valeur à virgule flottante indique la taille de la boite de limitation. coord~quant : cet entier à 5 bits sans signe indique l'étape de quantification utilisée pour la géométrie. coord~pred~type : cet entier à 2 bits sans signe indique le type de prédiction utilisé pour reconstruire les coordonnées de sommet du maillage. Le tableau 3 montre les valeurs admissibles pour ccord~pred~type.

Tableau 3. Valeurs admissibles pour coord~pred~type

<tb>
<tb> coord <SEP> pred <SEP> type <SEP> type <SEP> de <SEP> prédiction
<tb> 00 <SEP> pas <SEP> de <SEP> prédiction
<tb> 01 <SEP> interdit
<tb> 10 <SEP> prédiction <SEP> de <SEP> parallélogramme
<tb> 11 <SEP> réservé
<tb>
coord-nlambda : cet entier à 2 bits sans signe indique le nombre d'ascendants utilisés pour prédire la géométrie.

La seule valeur admissible de coord nlambda est 3. Le tableau 4 montre les valeurs admissibles en fonction de normal~pred~type.

Tableau 4. Valeurs admissibles pour coord-nlambda en fonction de coord~pred~type

<tb>
<tb> coord <SEP> pred <SEP> type <SEP> coord <SEP> nlambda
<tb> 00 <SEP> pas <SEP> codé
<tb> 10 <SEP> 3
<tb>
coord~lambda : cet entier sans signe indique le poids donné à un ascendant pour la prédiction. Le nombre de bits utilisés pour ce champ est égal à coord-quant+3. en-tête normal liaison~normale : cet entier à 2 bits sans signe indique la fixation des normales au maillage en 3D. Les valeurs admissibles sont décrites dans le tableau 5.

Tableau 5. Valeurs admissibles pour liaison~normale

<tb>
<tb> liaison <SEP> normale <SEP> fixation
<tb> 00 <SEP> non <SEP> lié
<tb> 01 <SEP> lien <SEP> par <SEP> sommet
<tb> 10 <SEP> lien <SEP> par <SEP> face
<tb> 11 <SEP> lien <SEP> par <SEP> sommet <SEP>
<tb>
normal bbox : cette valeur booléenne serait toujours fausse ('0') normal~quant : cet entier à 5 bits sans signe indique l'étape de quantification utilisé pour les normales. normal~pred~type : cet entier à 2 bits sans signe indique comment les valeurs normales sont prédites.

Tableau 6. Valeurs admissibles pour normal-pred~type

<tb>
<tb> coord <SEP> pred <SEP> type <SEP> ~~~ <SEP> type <SEP> de <SEP> prédiction
<tb> 00 <SEP> pas <SEP> de <SEP> prédiction
<tb> 01 <SEP> prédiction <SEP> d'arbre
<tb> 10 <SEP> prédiction <SEP> de <SEP> parallélogramme
<tb> 11 <SEP> réservé
<tb>

Tableau 7. Combinaisons admissibles pour liaison~normale et normal~pred~type

<tb>
<tb> liaison <SEP> normale <SEP> normal <SEP> pred <SEP> type <SEP>
<tb> 00 <SEP> non <SEP> codé
<tb> 01 <SEP> pas <SEP> de <SEP> prédiction, <SEP> prédiction
<tb> de <SEP> parallélogramme
<tb> 10 <SEP> pas <SEP> de <SEP> prédiction, <SEP> prédiction
<tb> d'arbre
<tb> 11 <SEP> pas <SEP> de <SEP> prédiction, <SEP> prédiction
<tb> d'arbre
<tb>
normal~nlambda : cet entier à 2 bits sans signe indique le nombre d'ascendants utilisés pour prédire les normales. Les valeurs admissibles de normal~nlambda sont 1, 2 et 3. Le tableau 8 montre les valeurs admissibles en fonction de normal~pred~type.

Tableau 8. Valeurs admissibles pour normal~nlambda en fonction de normal~pred~type

<tb>
<tb> normal <SEP> pred <SEP> type <SEP> normal <SEP> nlambda
<tb> pas <SEP> prédiction <SEP> pas <SEP> codé
<tb> prédiction <SEP> arbre <SEP> 1, <SEP> 2, <SEP> 3
<tb> Prédiction <SEP> parallélogramme <SEP> 3
<tb>
normal lambda . cet entier sans signe indique le poids donné à un ascendant pour la prédiction. Le nombre de bits utilisés pour ce champ est égal normal~quant+3. color header liaison~couleur : cet entier à 2 bits sans signe indique la fixation des couleurs au maillage en 3D. Les valeurs admissibles sont décrites dans le tableau 9.

Tableau 9. Valeurs admissibles pour color~binding

<tb>
<tb> liaison <SEP> couleur <SEP> fixation
<tb> 00 <SEP> non <SEP> lié
<tb> 01 <SEP> lien <SEP> par <SEP> sommet <SEP>
<tb> 10 <SEP> lien <SEP> par <SEP> face
<tb> 11 <SEP> lien <SEP> par <SEP> sommet
<tb>
color-bbox : cette valeur booléenne indique si une boite de limitation des couleurs est donnée. couleur rmin, couleur~gmin et couleur~bmin : ces 3 valeurs à virgule flottante donnent la position du coin inférieur gauche de la boite de limitation dans l'espace RGB. couleur size cette valeur à virgule flottante indique la taille de la boite de limitation. couleur~quant : cet entier à 5 bits sans signe indique l'étape de quantification utilisée pour les couleurs. type prédiction couleur . cet entier à 2 bits sans signe indique comment les couleurs sont prédites.

Tableau 10. Valeurs admissibles pour type~prédiction~couleur

<tb>
<tb> coord <SEP> pred <SEP> type <SEP> type <SEP> de <SEP> prédiction
<tb> 00 <SEP> pas <SEP> de <SEP> prédiction
<tb> 01 <SEP> prédiction <SEP> d'arbre
<tb> 10 <SEP> prédiction <SEP> de <SEP> parallélogramme
<tb> 11 <SEP> réservé
<tb>

Tableau 11. Valeurs admissibles pour liaison~couleur et type~prédiction~couleur

<tb>
<tb> liaison <SEP> couleur <SEP> type <SEP> couleur <SEP> pred <SEP>
<tb> non <SEP> lié <SEP> non <SEP> codé
<tb> lien~par~sommet <SEP> pas~prédiction,
<tb> prédiction <SEP> parallélogramme <SEP>
<tb> lien~par~face <SEP> pas~prédiction,
<tb> prédiction <SEP> arbre
<tb> lien~par~sommet <SEP> pas~prédiction,
<tb> prédiction <SEP> arbre
<tb>
couleur~nlambda : Cet entier à 2 bits sans signe indique le nombre d'ascendants utilisés pour prédire les couleurs. Les valeurs admissibles pour couleur~nlambda sont 1, 2 et 3. Le tableau 12 montre les valeurs admissibles en fonction de type~prédiction~couleur.

Tableau 12. Valeurs admissibles pour couleur~nlambda en fonction de type prédiction~couleur.

<tb>
<tb> type <SEP> prédiction <SEP> couleur <SEP> couleur <SEP> nlambda
<tb> pas <SEP> prédiction <SEP> pas <SEP> codé
<tb> prédiction <SEP> arbre <SEP> 1, <SEP> 2,3
<tb> prédiction <SEP> parallélogramme <SEP> 3
<tb>
couleur lambda :cet entier sans signe indique le poids donné à un ascendant pour la prédiction. Le nombre de bits utilisés pour ce champ est égal à couleur~quant+3. texCoord header liaison~coord~texture : cet entier à 2 bits sans signe indique les fixations des textures au maillage en 3D. Les valeurs admissibles sont décrites dans le tableau 13.

Tableau 13. Valeurs admissibles pour liaison coord texture

<tb>
<tb> liaison <SEP> coord <SEP> texture <SEP> fixation
<tb> 00 <SEP> pas <SEP> codé
<tb> 01 <SEP> lien <SEP> par <SEP> sommet
<tb> 10 <SEP> interdit
<tb> 11 <SEP> lien <SEP> par <SEP> sommet
<tb>
texCoord~bbox : cette valeur booléenne indique si une boite de limitation pour les cordonnées de texture est donnée. texCoord umin et texCoord~vmin : ces 2 valeurs à virgule flottante donnent la position de l'angle inférieur gauche de la boite de limitation dans l'espace 2D. texCoord size : cette valeur à virgule flottante donne la taille de la boite de limitation de texture. texCoord~quant :cet entier à 5 bits non signé indique l'étape de quantification utilisée pour les coordonnées de texture. texCoord~pred~type : cet entier à 2 bits sans signe indique comment les couleurs sont prédites. Le tableau 14 montre les valeurs admissibles pour texCoord~pred~type et le tableau 15 montre les valeurs admissibles en fonction de liaison coord texture.

Tableau 14. Valeurs admissibles pour texCoord~pred~type

<tb>
<tb> texCoord <SEP> pred <SEP> type <SEP> type <SEP> de <SEP> prédiction
<tb> 00 <SEP> pas <SEP> prédiction
<tb> 01 <SEP> interdit
<tb> 10 <SEP> prédiction <SEP> de <SEP> parallélogramme
<tb> 11 <SEP> réservé
<tb>

Tableau 15. Combinaisons admissibles de liaison coord texture et texCoord~pred~type

<tb>
<tb> liaison <SEP> coord <SEP> texture <SEP> texCoord <SEP> pred <SEP> type <SEP>
<tb> non <SEP> lié <SEP> pas <SEP> codé
<tb> lien~par~sommet <SEP> pas <SEP> de <SEP> prédiction, <SEP> prédiction
<tb> de <SEP> parallélogramme
<tb> lien~par~sommet <SEP> pas <SEP> de <SEP> prédiction, <SEP> prédiction
<tb> d'arbre
<tb>
texCoord~nlambda : cet entier à 2 bits sans signe indique le nombre d'ascendants utilisés pour prédire les coordonnées de texture. Les valeurs admissibles de texCoord~nlambda sont 1,2 et 3. Le tableau 16 montre les valeurs admissibles pour texCoord~nlambda en fonction de texCoord~pred~type
Tableau 16. Valeurs admissibles pour texCoord~nlambda en fonction de texCoord~pred~type

<tb>
<tb> texCoord <SEP> pred <SEP> type <SEP> texCoord <SEP> nlambda
<tb> pas <SEP> prédiction <SEP> pas <SEP> codé
<tb> prédiction <SEP> arbre <SEP> 1, <SEP> 2, <SEP> 3
<tb> prédiction <SEP> parallélogramme <SEP> 3
<tb>
texCoord~lambda : cet entier sans signe indique le poids donné à un ascendant pour la prédiction. Le nombre de bits utilisés pour ce champ est égal à texCoord-quant+3. en-tête~cgd cgd~n~proj~surface~spheres est le nombre de Sphères de Surface Projetée. De manière caractéristique, ce nombre est égal à 1. point~centre~coord~x~cgd est la coordonnée X du point de centre (de manière caractéristique, le centre de gravité de l'objet) sur la sphère de surface projetée. point~centre~coord~y~cgd est la coordonnée Y du point

de centre (de manière caractéristique, le centre de gravité de l'objet) sur la sphère de surface projetée. point~centre~coord~z~cgd est la coordonnée Z du point de centre (de manière caractéristique, le centre de gravité de l'objet) sur la sphère de surface projetée. facteur~distance~écran~normalisé~cgd indique où est placé l'écran virtuel, comparé au rayon de la sphère de surface projetée. La distance entre le point de centre de la sphère de surface projetée et l'écran virtuel est égale

à rayon~cgd (facteur distance écran normalisé cgd=1). Il convient de noter que rayon~cgd est spécifié pour chaque sphère de surface projetée, alors que facteur~distance~écran normalisé est spécifié une fois seulement. rayon~cgd est le rayon de la sphère de surface projetée. surface~proj~minimu~cgd est la valeur minimum de surface projetée sur la sphère de surface projetée correspondante. Cette valeur est souvent (mais pas nécessairement) égale à une des valeurs cgd~proj~surface. points~proj~n~cgd est le nombre de points de la sphère de surface projetée dans laquelle la surface projetée sera transmise. Pour tous les autres points, la surface projetée est déterminée par interpolation linéaire. points~proj~n~cgd est de manière caractéristique petite (par exemple, 20) pour la première sphère de surface projetée et très petite :par exemple 3) pour les sphères de surface projetée additionnelles. coord~point~sphère~cgd indique l'index de la position de point dans un octaèdre. cgd~proj~surface est la surface projetée au point spécifié par coord~point~sphère~cgd. graphe sommet vg~simple : cette valeur booléenne indique si le graphe de sommets en cours est simple. Un graphe de sommets

simple ne contient aucune boucle. Ce champ est codé arithmétiquement. dernier~graphe~sommet : cette valeur booléenne indique si le parcours en cours est le dernier parcours partant du sommet d'embranchement en cours. Ce champ n'est pas codé pour le premier parcours de chaque sommet d'embranchement, c'est à dire lorsque la variable skip~last est vraie.

Lorsqu'elle n'est pas codée, la valeur de dernier~graphe~sommet pour le sommet en cours est considérée comme fausse. Ce champ est codé arithmétiquement. parcours~avant~graphe~sommet : cette valeur booléenne indique si le parcours en cours est un nouveau parcours. Si ce n'est pas un nouveau parcours, il doit être un parcours précédemment traversé, indiquant une boucle dans le graphe.

Ce champ est codé arithmétiquement. index~boucle~graphe~sommet : cet entier sans signe indique l'index d'un parcours auquel la boucle en cours se relie. Sa représentation unaire est codée arithmétiquement.

Si la boucle ouverte variable est égale à index boucle graphe sommet, le '1' traînant dans la représentation unaire est omis.

Tableau 17. Représentation unaire du champ index~boucle~graphe~sommet.

<tb>
<tb> index <SEP> boucle <SEP> graphe <SEP> sommet <SEP> représentation <SEP> unaire
<tb> 0 <SEP> 1
<tb> 1 <SEP> 01
<tb> 2 <SEP> 001
<tb> 3 <SEP> 0001
<tb> 4 <SEP> 00001
<tb> 5 <SEP> 000001
<tb> 6 <SEP> 0000001
<tb> boucle <SEP> ouverte-1 <SEP> boucle <SEP> ouverte-1 <SEP> 0's
<tb>

longueur~parcours~graphe~sommet : cet entier sans signe indique la longueur du parcours de sommet en cours.

Sa représentation unaire est codée arithmétiquement.

Tableau 18. Représentation unaire du champ longueur~parcours~graphe~sommet.

<tb>
<tb> longueur~parcours <SEP> graphe~ <SEP> représentation <SEP> unaire
<tb> sommet
<tb> 1 <SEP> 1
<tb> 2 <SEP> 01
<tb> 3 <SEP> 001
<tb> 4 <SEP> 0001
<tb> 5 <SEP> 00001
<tb> 6 <SEP> 000001
<tb> 7 <SEP> 0000001
<tb> 8 <SEP> 00000001
<tb> n <SEP> n-1 <SEP> 0's <SEP> suivi <SEP> par <SEP> 1
<tb>
vg~feuille : cet indicateur booléen indique si le dernier sommet du parcours en cours est un sommet feuille.

Si ce n'est pas un sommet feuille, c'est un sommet d'embranchement. Ce champ est codé arithmétiquement. vg~boucle : cet indicateur booléen indique si la feuille du parcours en cours se relie à un sommet d'embranchement du graphe, indiquant une boucle. Ce champ est codé arithmétiquement. arbre triangle position branche . cette variable entière est utilisée pour mémoriser le dernier triangle d'embranchement dans une partition. longueur parcours feuille arbre triangle . cet entier sans signe indique la longueur du parcours de triangle en cours. Sa représentation unaire est codée arithmétiquement.

Tableau 19. Représentation unaire du champ longueur~parcours~feuille~arbre~triangle

<tb>
<tb> longueur <SEP> parcours-feuille- <SEP> représentation <SEP> unaire
<tb> arbre <SEP> triangle
<tb> 1 <SEP> 1
<tb> 2 <SEP> 01
<tb> 3 <SEP> 001
<tb> 4 <SEP> 0001
<tb> 5 <SEP> 00001
<tb> 6 <SEP> 000001
<tb> 7 <SEP> 0000001
<tb> 8 <SEP> 00000001
<tb> n <SEP> n-1 <SEP> 0's <SEP> suivi <SEP> par <SEP> 1
<tb>
feuille arbre triangle cet indicateur booléen indique si le dernier triangle du parcours en cours est un triangle feuille. Si ce n'est pas un triangle feuille, c'est un triangle d'embranchement. Ce champ est codé arithmétiquement. triangulated : cette valeur booléenne indique si la composante en cours contient seulement des triangles. Ce champ est codé arithmétiquement. triangle~progression : cette valeur booléenne est déterminée par la position du triangle dans l'arbre triangles. Si la valeur triangle~progression est 0, le triangle est un triangle feuille ou un triangle d'embranchement. Sinon, le triangle est un parcours. motif progression . cet indicateur booléen indique le motif de progression des arêtes à l'intérieur d'un parcours triangle. Un '0' représente une progression vers la gauche, et un 'l'une progression vers la droite. Ce champ est codé arithmétiquement. arête~polygone : cet indicateur booléen indique si la base du triangle en cours est une arête qui devrait être

conservée lors de la reconstruction de l'objet maillé 3D.

Si la base du triangle en cours ne doit pas être conservée, l'arête est laissée de côté. Ce champ est codé arithmétiquement. longueur~branche~codap : cet entier sans signe indique la longueur de la prochaine branche à traverser. La longueur de cette valeur est la valeur à échelle logarithmique de la taille de la table de boucle englobante. triangle td~orientation : cet indicateur à un bit informe le décodeur de l'ordre de traversée des paires tt/td à une branche. Ce champ est codé arithmétiquement. Le tableau 20 montre les valeurs admissibles pour td~orientation.

Tableau 20. Valeurs admissibles pour td~orientation.

<tb>
<tb> td <SEP> orientation <SEP> ordre <SEP> de <SEP> traversée
<tb> 0 <SEP> première <SEP> branche <SEP> droite
<tb> 1 <SEP> première <SEP> branche <SEP> gauche
<tb>
visited : cette variable indique si le sommet en cours a été ou non visité. Lorsque codap~bdry~pred est '1', visited est vrai pour les sommets visités dans la partition en cours. Toutefois, lorsque codap~bdry~pred est '0', visited est vrai pour les sommets visités dans les précédentes partitions aussi bien que dans la partition en cours. index~sommet : cette variable indique l'index du sommet en cours dans la matrice de sommet. no~ancestors : cette variable booléenne est vraie s'il n'y a pas d'aïeux à utiliser pour la prédiction du sommet en cours. bit coor : cette valeur booléenne indique la valeur d'un bit de géométrie. Ce champ est codé arithmétiquement.

bit~d'en-tête~coord : cette valeur booléenne indique la valeur d'un bit de géométrie d'en-tête. Ce champ est codé arithmétiquement. coord sign bit : cette valeur booléenne indique le signe d'un échantillon de géométrie. Ce champ est codé arithmétiquement. bit~traînant~coord : cette valeur booléenne indique la valeur d'un bit de géométrie traînant. Ce champ est codé arithmétiquement. bit normal : cette valeur booléenne indique la valeur d'un bit normal. Ce champ est codé arithmétiquement. bit~normal~menant : cette valeur booléenne indique la valeur d'un bit menant normal. Ce champ est codé arithmétiquement. signe~bit~normal : cette valeur booléenne indique le signe d'un échantillon normal. Ce champ est codé arithmétiquement. bit normal traînant , cette valeur booléenne indique la valeur d'un bit traînant normal. Ce champ est codé arithmétiquement. couleur bit : cette valeur booléenne indique la valeur d'un bit de couleur. Ce champ est codé arithmétiquement. bit~menant~couleur : cette valeur booléenne indique la valeur d'un bit menant de couleur. Ce champ est codé arithmétiquement. bit~signe~couleur : cette valeur booléenne indique le signe d'un échantillon de couleur. Ce champ est codé arithmétiquement. bit traînant couleur : cette valeur booléenne indique la valeur d'un bit traînant de couleur. Ce champ est codé arithmétiquement. bit~texCoord : cette valeur booléenne indique la valeur d'un bit de texture. Ce champ est codé arithmétiquement. bit~menant~texCoord : cette valeur booléenne indique

la valeur d'un bit menant de texture. Ce champ est codé arithmétiquement. bit~signe~texCoord : cette valeur booléenne indique le signe d'un échantillon de texture. Ce champ est codé arithmétiquement. bit~traînant~texCoord : cette valeur booléenne indique la valeur d'un bit traînant de texture. Ce champ est codé arithmétiquement.

Niveau~Affinage~Objet~Maillé~3D code~départ~MORL~3D : ceci est un code unique à 16 bits de longueur qui est utilisé pour la synchronisation.

La valeur de ce code est toujours '0000 0000 0011 0010'. morl id : cet entier à 8 bits sans signe spécifie une id unique pour la composante de partage de forêt. mise à jour connectivité : cette variable à 2 bits indique si l'opération de partage de forêt résulte ou non en un affinage de la connectivité du maillage.

Tableau 21. Valeurs pour mise~à~jour~connnectivité.

Mise <SEP> à <SEP> jour <SEP> connnectivité <SEP> Signification
<tb> 00 <SEP> pas <SEP> mise <SEP> à <SEP> jour
<tb> 01 <SEP> mise <SEP> à <SEP> jour <SEP> fs
<tb> 10réservé
<tb> 11 <SEP> réservé
<tb>
pré lissage cette valeur booléenne indique si l'opération de partage de forêt en cours utilise une étape de pré-lissage pour prédire globalement les positions de sommet . post-lissage : cette valeur booléenne indique si l'opération de partage de forêt en cours utilise une étape de post-lissage pour supprimer les artefacts de quantification. bit~bourrage : cette valeur booléenne est toujours vraie.

autre~mise~à~jour : cette valeur booléenne indique si les mises à jour pour les coordonnées de sommet et les propriétés associées aux faces et coins non incidentes à n'importe quel arbre de la forêt suivent dans le flux binaire ou non. paramètres pré lissage pré~lissage~n : cette valeur entière indique le nombre d'itérations du filtre de pré-lissage. pré~lissage~lambda : cette valeur à virgule flottante est le premier paramètre du filtre de pré-lissage. pré~lissage~mu : cette valeur à virgule flottante est le deuxième paramètre du filtre de pré-lissage. paramètres~post~lissage post~lissage~n : cette valeur entière indique le nombre d'itérations du filtre de post-lissage. post~lissage~lambda : cette valeur à virgule flottante est le premier paramètre du filtre de post-lissage. post~lissage~mu : cette valeur à virgule flottante est le deuxième paramètre du filtre de pré-lissage.

# fs~pre~mise~à~jour arête~forêt~pfs : cette valeur booléenne indique si une arête doit être ajoutée à la forêt construite jusqu'ici. contraintes lissage lissage~avec~arêtes~vives : cette valeur booléenne indique si des données sont incluses dans le flux binaire afin de marquer ou non les arêtes de discontinuité de lissage. Si lissage avec arêtes vives==0, aucune arête n'est marquée en tant qu'arête de discontinuité de lissage.

Si les arêtes de discontinuité de lissage sont marquées, alors à la fois les filtres de pré-lissage et de postlissage les prennent en compte. lissage~avec~sommets~fixés : cette valeur booléenne indique si des données sont incluses dans le flux binaire afin de marquer les sommets qui ne bougent pas pendant le

traitement de lissage. Si lissage avec arêtes vives==0, tous les sommets ne sont pas autorisés à bouger. Si des sommets fixes sont marqués, alors à la fois les filtres de pré-lisssage et de post-lissage les prennent en compte contexte~arête~vive~lissage : cette valeur booléenne indique si une arête correspondante est marquée comme une arête de discontinuité de lissage. lissage sommet fixé . cette valeur booléenne indique si un sommet correspondant est marqué comme un sommet fixé ou non.

En conformité avec la présente invention, premièrement, même si une erreur de transmission est générée, seule la partie présentant l'erreur est transmise à nouveau, réduisant de ce fait la charge de réseau et le temps de transmission. Deuxièmement, une partie sélectionnée des données peut être progressivement restaurée en utilisant la connectivité, la géométrie et la photométrie de celle-ci.

LEXIQUE

<tb>
<tb> /*apply <SEP> post <SEP> smoothing <SEP> step*/ <SEP> appliquer <SEP> l'étape <SEP> de
<tb> post-lissage
<tb> /*apply <SEP> pre <SEP> smoothing <SEP> step*/ <SEP> appliquer <SEP> l'étape <SEP> du
<tb> pré-lissage
<tb> /*for <SEP> each <SEP> tree <SEP> loop <SEP> vertex <SEP> set <SEP> pour <SEP> chaque <SEP> jeu <SEP> sommets
<tb> visited*/ <SEP> de <SEP> boucle <SEP> d'arbre <SEP> visité
<tb> 3D <SEP> Mesh <SEP> Object <SEP> objet <SEP> maillé <SEP> 3D
<tb> 3D~Mesh~Object~Base~Layer <SEP> niveau <SEP> base <SEP> objet <SEP> maillé
<tb> 3D
<tb> 3D <SEP> Mesh <SEP> Object <SEP> Header <SEP> en-tête <SEP> objet <SEP> maillé <SEP> 3D
<tb> 3D <SEP> Mesh <SEP> Object <SEP> Layer <SEP> niveau <SEP> objet <SEP> maillé <SEP> 3D
<tb>

3D~Mesh~Object~Refinement~Layer niveau affinage objet

<tb>
<tb> maillé <SEP> 3D
<tb> 3D <SEP> MO <SEP> start <SEP> code <SEP> code <SEP> départ <SEP> OM <SEP> 3D
<tb> 3D <SEP> MOBL <SEP> start <SEP> code <SEP> code <SEP> départ <SEP> CBOM <SEP> 3D
<tb> 3D <SEP> MOL <SEP> start <SEP> code <SEP> code <SEP> départ <SEP> COM <SEP> 3D
<tb> 3D <SEP> MORL <SEP> start <SEP> code <SEP> code <SEP> départ <SEP> CROM <SEP> 3D
<tb> bound <SEP> per <SEP> corner <SEP> lien <SEP> par <SEP> coin
<tb> bound <SEP> per <SEP> face <SEP> lien <SEP> par <SEP> face
<tb> bound <SEP> per <SEP> vertex <SEP> lien <SEP> par <SEP> sommet
<tb> branch <SEP> position <SEP> position <SEP> branche
<tb> Break <SEP> arrêt
<tb> bytealigned <SEP> octet <SEP> aligné
<tb> ccw
<tb> cgd <SEP> data <SEP> donnée <SEP> cgd
<tb> cgd <SEP> header <SEP> en-tête <SEP> cgd
<tb> cgd <SEP> min <SEP> proj <SEP> surface <SEP> surface <SEP> proj <SEP> minimum <SEP> cgd
<tb> cgd <SEP> n <SEP> rfhrd <SEP> rfhrd <SEP> n <SEP> cgd
<tb> cgd <SEP> n <SEP> proj <SEP> points <SEP> points <SEP> proj <SEP> nombre <SEP> cgd
<tb> cgd~n~proj~surface <SEP> surface <SEP> projetés <SEP> nombre
<tb> cgd
<tb>

<tb>
<tb> cgd~n~proj~surface~spheres <SEP> sphères <SEP> surface <SEP> proj <SEP> n
<tb> cgd
<tb> cgd <SEP> n <SEP> edges <SEP> n <SEP> arêtes <SEP> cgd
<tb> cgd <SEP> n <SEP> triangles <SEP> triangles <SEP> n <SEP> cgd
<tb> cgd <SEP> n <SEP> vertices <SEP> sommets <SEP> n <SEP> cgd
<tb>

cgd~normalized-screen-distance-fac facteur distance écran

<tb>
<tb> tor <SEP> normalisé <SEP> cgd
<tb> cgd <SEP> proj <SEP> surface <SEP> surface <SEP> proj <SEP> cgd
<tb> cgd <SEP> proj <SEP> surface <SEP> spheres <SEP> sphères <SEP> surface <SEP> proj <SEP> cgd
<tb> cgd <SEP> radius <SEP> rayon <SEP> cgd
<tb> cgd <SEP> sphere <SEP> point <SEP> coord <SEP> coord <SEP> point <SEP> sphère <SEP> cgd
<tb> cgd <SEP> x <SEP> coord <SEP> center <SEP> point <SEP> point <SEP> centre <SEP> coord <SEP> x <SEP> cgd
<tb> cgd <SEP> y <SEP> coord <SEP> center <SEP> point <SEP> point <SEP> centre <SEP> coord <SEP> y <SEP> cgd
<tb> cgd <SEP> z <SEP> coord <SEP> center <SEP> point <SEP> point <SEP> centre <SEP> coord <SEP> z <SEP> cgd
<tb> codap <SEP> branch <SEP> len <SEP> longueur <SEP> branche <SEP> codap
<tb> codap~branch~len~context <SEP> contexte <SEP> longueur
<tb> branche <SEP> codap
<tb> codap~last~vg <SEP> graphe <SEP> sommet <SEP> dernier
<tb> codap
<tb> codap~last~vg~context <SEP> contexte <SEP> graphe <SEP> sommet
<tb> dernier <SEP> codap
<tb> codap~left~bloop~idx <SEP> index <SEP> boucle <SEP> englobante
<tb> gauche <SEP> codap
<tb> codap~left~bloop~idx~context <SEP> contexte <SEP> index <SEP> boucle
<tb> englobante <SEP> gauche <SEP> codap
<tb> codap~right~bloop~idx <SEP> index <SEP> boucle <SEP> englobante
<tb> droite <SEP> codap
<tb> codap~right~bloop~idx~context <SEP> contexte <SEP> index <SEP> boucle
<tb> englobante <SEP> droite <SEP> codap
<tb> codap~vg~id <SEP> identificateur <SEP> graphe
<tb> sommet
<tb> codap~vg~id~context <SEP> contexte <SEP> identificateur
<tb> graphe <SEP> sommet
<tb> code <SEP> last <SEP> dernier <SEP> code
<tb>

<tb>
<tb> color <SEP> couleur
<tb> color <SEP> bbox <SEP> couleur <SEP> bbox
<tb> color <SEP> binding <SEP> liaison <SEP> couleur
<tb> color <SEP> bmin <SEP> couleur <SEP> bmin
<tb> color <SEP> gmin <SEP> couleur <SEP> gmin
<tb> color <SEP> header <SEP> en-tête <SEP> couleur
<tb> color <SEP> leading <SEP> bit <SEP> bit <SEP> menant <SEP> couleur
<tb> color~leading~bit~context <SEP> contexte <SEP> bit <SEP> menant
<tb> couleur
<tb> color <SEP> pred <SEP> type <SEP> type <SEP> prédiction <SEP> couleur
<tb> color <SEP> quant <SEP> couleur <SEP> quant
<tb> color <SEP> rmin <SEP> couleur <SEP> rmin
<tb> color <SEP> sample <SEP> échantillon <SEP> couleur
<tb> color <SEP> sign <SEP> bit <SEP> bit <SEP> signe <SEP> couleur
<tb> color <SEP> size <SEP> taille <SEP> couleur
<tb> color <SEP> trailing <SEP> bit <SEP> bit <SEP> menant <SEP> couleur
<tb> connected <SEP> component <SEP> composante <SEP> reliée
<tb> connectivity <SEP> update <SEP> mise <SEP> à <SEP> jour <SEP> connectivité
<tb> convex <SEP> convexe
<tb> coord <SEP> coord
<tb> coord <SEP> bbox <SEP> coord <SEP> bbox
<tb> coord <SEP> binding <SEP> liaison <SEP> coord
<tb> coord <SEP> bit <SEP> bit <SEP> coord
<tb> coord <SEP> header <SEP> en-tête <SEP> coord
<tb> coord <SEP> lambda <SEP> lambda <SEP> coord
<tb> coord~leading~bit~context <SEP> contexte <SEP> bit <SEP> menant
<tb> coord
<tb> coord <SEP> nlambda <SEP> nlambda <SEP> coord
<tb> coord <SEP> pred <SEP> type <SEP> type <SEP> prédiction <SEP> coord
<tb> coord <SEP> quant <SEP> coord <SEP> quant
<tb> coord <SEP> sample <SEP> échantillon <SEP> coord
<tb> coord <SEP> sign <SEP> bit <SEP> bit <SEP> sign <SEP> coord
<tb> coord <SEP> size <SEP> taille <SEP> coord
<tb> coord <SEP> trailing <SEP> bit <SEP> bit <SEP> traînant <SEP> coord
<tb>

<tb>
<tb> coord <SEP> xmin <SEP> coord <SEP> xmin
<tb> coord <SEP> ymin <SEP> coord <SEP> ymin
<tb> coord <SEP> zmin <SEP> coord <SEP> zmin
<tb> creaseAngle <SEP> pli <SEP> Angle
<tb> creates <SEP> no <SEP> loop <SEP> in <SEP> forest <SEP> créé <SEP> aucune <SEP> boucle <SEP> dans
<tb> forêt
<tb> depth <SEP> profondeur
<tb> do <SEP> faire
<tb> each <SEP> connected <SEP> component <SEP> chaque <SEP> composante <SEP> reliée
<tb> each <SEP> edge <SEP> chaque <SEP> arête
<tb> each <SEP> edge <SEP> in <SEP> connected <SEP> component <SEP> chaque <SEP> arête <SEP> dans
<tb> composante <SEP> reliée
<tb> each <SEP> tree <SEP> in <SEP> forest <SEP> chaque <SEP> arbre <SEP> dans <SEP> forêt
<tb> each <SEP> vertex <SEP> chaque <SEP> sommet
<tb> each <SEP> vertex <SEP> in <SEP> chaque <SEP> sommet <SEP> dans
<tb> else <SEP> sinon
<tb> fixed <SEP> vertex <SEP> marks <SEP> marques <SEP> sommet <SEP> fixé
<tb> for <SEP> pour
<tb> forest <SEP> forêt
<tb> fs <SEP> post <SEP> update <SEP> post-mise <SEP> à <SEP> jour <SEP> fs
<tb> fs <SEP> pre <SEP> update <SEP> pré-mise <SEP> à <SEP> jour <SEP> fs
<tb> fs <SEP> update <SEP> mise <SEP> à <SEP> jour <SEP> fs
<tb> has <SEP> stitches <SEP> a <SEP> sutures
<tb> has <SEP> stitches <SEP> context <SEP> contexte <SEP> a <SEP> sutures
<tb> if <SEP> si
<tb> last <SEP> component <SEP> dernière <SEP> composante
<tb> last~component~context <SEP> contexte <SEP> dernière
<tb> composante
<tb> loop <SEP> coord <SEP> update <SEP> mise <SEP> à <SEP> jour <SEP> coord <SEP> boucle
<tb> loop~normal~update <SEP> mise <SEP> à <SEP> jour <SEP> normal
<tb> boucle
<tb> marching <SEP> pattern <SEP> motif <SEP> progression
<tb> marching~pattern~context <SEP> contexte <SEP> motif
<tb> progression
<tb>

<tb>
<tb> marching <SEP> triangle <SEP> triangle <SEP> progression
<tb> Mnemonic <SEP> Mnémonique
<tb> mobl <SEP> id <SEP> identificateur <SEP> COM
<tb> mol <SEP> id <SEP> identificateur <SEP> CON
<tb> morl <SEP> id <SEP> identificateur <SEP> morl
<tb> nextbits~bytealigned <SEP> octets <SEP> alignés <SEP> prochains
<tb> bits
<tb> No. <SEP> of <SEP> bits <SEP> Nombre <SEP> de <SEP> bits
<tb> no <SEP> ancestors <SEP> pas <SEP> d'ascendants
<tb> normal <SEP> normal
<tb> normal <SEP> bbox <SEP> bbox <SEP> normal
<tb> normal <SEP> binding <SEP> liaison <SEP> normale
<tb> normal <SEP> bit <SEP> bit <SEP> normal
<tb> normal <SEP> header <SEP> en-tête <SEP> normal
<tb> normal <SEP> leading <SEP> bit <SEP> bit <SEP> menant <SEP> normal
<tb> normal~leading~bit~context <SEP> contexte <SEP> bit <SEP> menant
<tb> normal
<tb> normal <SEP> pred <SEP> type <SEP> type <SEP> prédiction <SEP> normal
<tb> normal <SEP> quant <SEP> quant <SEP> normal
<tb> normal <SEP> sample <SEP> échantillon <SEP> normal
<tb> normal <SEP> sign <SEP> bit <SEP> bit <SEP> signe <SEP> normal
<tb> normal <SEP> trailing <SEP> bit <SEP> bit <SEP> traînant <SEP> normal
<tb> not <SEP> bound <SEP> non <SEP> lien
<tb> ntriangles <SEP> nombre <SEP> triangles
<tb> one <SEP> bit <SEP> un <SEP> bit
<tb> openloop <SEP> boucle <SEP> ouverte
<tb> openloops <SEP> boucles <SEP> ouvertes
<tb> other~property~update <SEP> mise <SEP> à <SEP> jour <SEP> autres
<tb> propriétés
<tb> other <SEP> update <SEP> mise <SEP> à <SEP> jour <SEP> autres
<tb> parallelogram~prediction <SEP> prédiction
<tb> parallélogramme
<tb> partition <SEP> type <SEP> 0 <SEP> partition <SEP> type <SEP> 0
<tb> partition <SEP> type <SEP> 1 <SEP> partition <SEP> type <SEP> 1
<tb>

<tb>
<tb> partition <SEP> type <SEP> 2 <SEP> partition <SEP> type <SEP> 2
<tb> pfs <SEP> forest <SEP> edge <SEP> arête <SEP> forêt <SEP> pfs
<tb> pfs <SEP> forest <SEP> edge <SEP> context <SEP> contexte <SEP> arête <SEP> forêt <SEP> pfs
<tb> polygon <SEP> edge <SEP> arête <SEP> polygone
<tb> polygon <SEP> edge <SEP> context <SEP> contexte <SEP> arête <SEP> polygone
<tb> post <SEP> smoothing <SEP> post-lissage
<tb> post <SEP> smoothing <SEP> lambda <SEP> post-lissage <SEP> lambda
<tb> post <SEP> smoothing <SEP> mu <SEP> post-lissage <SEP> mu
<tb> post <SEP> smoothing <SEP> n <SEP> post-lissage <SEP> n
<tb> post <SEP> smoothing <SEP> parameters <SEP> paramètres <SEP> post-lissage
<tb> pre <SEP> smoothing <SEP> pré-lissage
<tb> pre <SEP> smoothing <SEP> lambda <SEP> pré-lissage <SEP> lambda
<tb> pre <SEP> smoothing <SEP> mu <SEP> pré-lissage <SEP> mu
<tb> pre <SEP> smoothing <SEP> n <SEP> pré-lissage <SEP> n
<tb> pre <SEP> smoothing <SEP> parameters <SEP> paramètres <SEP> pré-lissage
<tb> qf <SEP> decode <SEP> décode <SEP> qf
<tb> qf <SEP> start <SEP> départ <SEP> qf
<tb> qf <SEP> start <SEP> qf <SEP> départ
<tb> root <SEP> color <SEP> couleur <SEP> racine
<tb> root~color~sample <SEP> échantillon <SEP> couleur
<tb> racine
<tb> root <SEP> coord <SEP> coord <SEP> racine
<tb> root <SEP> coord <SEP> sample <SEP> échantillon <SEP> coord <SEP> racine
<tb> root <SEP> normal <SEP> normal <SEP> racine
<tb> root~normal~sample <SEP> échantillon <SEP> normal
<tb> racine
<tb> root <SEP> texCoord <SEP> coord <SEP> texture <SEP> racine
<tb> root~texCoord~sample <SEP> échantillon <SEP> texture
<tb> racine
<tb> root~textCoord~sample <SEP> échantillon <SEP> coord
<tb> texture <SEP> racine
<tb> root <SEP> triangle <SEP> triangle <SEP> racine
<tb> run~length~context <SEP> contexte <SEP> longueur
<tb> parcours
<tb>

<tb>
<tb> sharp <SEP> edge <SEP> marks <SEP> marques <SEP> arête <SEP> vive
<tb> smooth <SEP> fixed <SEP> vertex <SEP> lissage <SEP> sommet <SEP> fixé
<tb> smooth~fixed~vertex~context <SEP> contexte <SEP> lissage <SEP> sommet
<tb> fixé
<tb> smooth~sharp~edge <SEP> contexte <SEP> arête <SEP> vive
<tb> lissage
<tb> smooth~with~fixed~vertices <SEP> lissage <SEP> avec <SEP> sommets
<tb> fixés
<tb> smooth~with~sharp~edges <SEP> lissage <SEP> avec <SEP> arêtes
<tb> vives
<tb> smoothing <SEP> constraints <SEP> contraintes <SEP> lissage
<tb> solid <SEP> solide
<tb> stitch <SEP> cmd <SEP> cmd <SEP> suture
<tb> stitch <SEP> cmd <SEP> context <SEP> contexte <SEP> cmd <SEP> suture
<tb> stitch <SEP> incr <SEP> length <SEP> longueur <SEP> incr <SEP> suture
<tb> stitch~incr~length~context <SEP> contexte <SEP> longueur <SEP> incr
<tb> suture
<tb> stitch~incr~length~sign <SEP> sign <SEP> longueur <SEP> incr
<tb> suture
<tb> stitch~incr~length~sign~context <SEP> contexte <SEP> sign <SEP> longueur
<tb> incr <SEP> suture
<tb> stitch <SEP> length <SEP> longueur <SEP> suture
<tb> stitch <SEP> length <SEP> context <SEP> contexte <SEP> longueur <SEP> suture
<tb> stitch <SEP> pop <SEP> or <SEP> get <SEP> obtenir <SEP> ou <SEP> sauter <SEP> suture
<tb> stitch~pop~or~get~context <SEP> contexte <SEP> obtenir <SEP> ou
<tb> sauter <SEP> suture
<tb> stitch <SEP> push <SEP> pousser <SEP> suture
<tb> stitch <SEP> push <SEP> context <SEP> contexte <SEP> pousser <SEP> suture
<tb> stitch <SEP> reverse <SEP> renverser <SEP> suture
<tb> stitch <SEP> reverse <SEP> context <SEP> contexte <SEP> renverser
<tb> suture
<tb> stitch~stitch~stack~context <SEP> contexte <SEP> pile <SEP> suture
<tb> suture
<tb> stitch <SEP> stitch <SEP> stack <SEP> index <SEP> index <SEP> pile <SEP> suture <SEP> suture
<tb>

<tb>
<tb> stitches <SEP> sutures
<tb> td <SEP> orientation <SEP> orientation <SEP> données
<tb> triangles
<tb> td <SEP> orientation <SEP> context <SEP> contexte <SEP> orientation
<tb> donnéestriangles
<tb> texCoord <SEP> coord <SEP> texture
<tb> texCoord <SEP> bbox <SEP> bbox <SEP> coord <SEP> texture
<tb> texCoord <SEP> binding <SEP> liaison <SEP> coord <SEP> texture
<tb> texCoord <SEP> bit <SEP> bit <SEP> coord <SEP> texture
<tb> texCoord <SEP> header <SEP> en-tête <SEP> coord <SEP> texture
<tb> texCoord <SEP> lambda <SEP> coord <SEP> lambda <SEP> texture
<tb> texCoord <SEP> leading <SEP> bit <SEP> bit <SEP> menant <SEP> coord <SEP> texture
<tb> texCoord~leading~context <SEP> contexte <SEP> bit <SEP> menant
<tb> coord <SEP> texture
<tb> texCoord <SEP> nlambda <SEP> coord <SEP> nlambda <SEP> texture
<tb> texCoord~pred~type <SEP> type <SEP> prédiction <SEP> coord
<tb> texture
<tb> texCoord <SEP> quant <SEP> quant <SEP> coord <SEP> texture
<tb> texCoord <SEP> sign <SEP> bit <SEP> bit <SEP> signe <SEP> coord <SEP> texture
<tb> texCoord <SEP> size <SEP> taille <SEP> coord <SEP> texture <SEP>
<tb> texCoord <SEP> umin <SEP> coord <SEP> umin <SEP> texture
<tb> texCoord <SEP> vmin <SEP> coord <SEP> vmin <SEP> texture
<tb> textCoord~sample <SEP> échantillon <SEP> coord
<tb> texture
<tb> total <SEP> length <SEP> longueur <SEP> totale
<tb> tree~loop~property~update <SEP> mise <SEP> à <SEP> jour <SEP> propriété
<tb> boucle <SEP> arbre
<tb> tree <SEP> prédiction <SEP> prédiction <SEP> arbre
<tb> triangle <SEP> triangle
<tb> triangle <SEP> data <SEP> données <SEP> triangles
<tb> triangle <SEP> tree <SEP> arbre <SEP> triangles
<tb> triangulated <SEP> triangulé
<tb> triangulated <SEP> context <SEP> contexte <SEP> triangulé
<tb> tt <SEP> leaf <SEP> feuille <SEP> arbre <SEP> triangles
<tb>

<tb>
<tb> tt <SEP> leaf <SEP> context <SEP> contexte <SEP> feuille <SEP> arbre
<tb> triangles
<tb> tt~run~length <SEP> longueur <SEP> parcours
<tb> feuille <SEP> arbre <SEP> triangles
<tb> vertex <SEP> graph <SEP> graphe <SEP> sommet
<tb> vertex <SEP> index <SEP> index <SEP> sommet
<tb> vg~forward~run <SEP> parcours <SEP> avant <SEP> graphe
<tb> sommet
<tb> vg~forward~run~context <SEP> contexte <SEP> parcours <SEP> avant
<tb> graphe <SEP> sommet
<tb> vg <SEP> last <SEP> dernier <SEP> graphe <SEP> sommet
<tb> vg~last~context <SEP> contexte <SEP> dernier <SEP> graphe
<tb> sommet
<tb> vg <SEP> leaf <SEP> feuille <SEP> graphe <SEP> sommet
<tb> vg <SEP> leaf <SEP> context <SEP> contexte <SEP> feuille <SEP> graphe
<tb> sommet
<tb> vg <SEP> loop <SEP> boucle <SEP> graphe <SEP> sommet
<tb> vg <SEP> loop <SEP> context <SEP> contexte <SEP> boucle <SEP> graphe
<tb> sommet
<tb> vg~loop~index <SEP> index <SEP> boucle <SEP> graphe
<tb> sommet
<tb> vg~loop~index~context <SEP> contexte <SEP> index <SEP> boucle
<tb> graphe <SEP> sommet
<tb> vg <SEP> number <SEP> nombre <SEP> graphe <SEP> sommet
<tb> vg~run~length <SEP> longueur <SEP> parcours <SEP> graphe
<tb> sommet
<tb> vg~run~length~context <SEP> contexte <SEP> longueur
<tb> parcours <SEP> graphe <SEP> sommet
<tb> vg <SEP> simple <SEP> simple <SEP> graphe <SEP> sommet
<tb> vg~simple~context <SEP> contexte <SEP> simple <SEP> graphe
<tb> sommet
<tb> visited <SEP> visité
<tb> Visual <SEP> Bitstream <SEP> Syntax <SEP> Syntax <SEP> flux <SEP> de <SEP> bits
<tb> visuel
<tb>

<tb>
<tb> while <SEP> tant <SEP> que
<tb> zero <SEP> context <SEP> contexte <SEP> zéro
<tb> loop~color~update <SEP> mise <SEP> à <SEP> jour <SEP> couleur
<tb> boucle
<tb> loop~texCoord~update <SEP> mise <SEP> à <SEP> jour <SEP> texture
<tb> coord <SEP> boucle
<tb> each <SEP> tree <SEP> loop <SEP> vertex <SEP> chaque <SEP> sommet <SEP> de <SEP> boucle
<tb> d'arbre
<tb> each <SEP> tree <SEP> loop <SEP> face <SEP> chaque <SEP> face <SEP> de <SEP> boucle
<tb> d'arbre
<tb> each <SEP> tree <SEP> loop <SEP> corner <SEP> chaque <SEP> coin <SEP> de <SEP> boucle
<tb> d'arbre
<tb> other <SEP> coord <SEP> update <SEP> mise <SEP> à <SEP> jour <SEP> coord <SEP> autre
<tb> other <SEP> normal <SEP> update <SEP> mise <SEP> à <SEP> jour <SEP> normal <SEP> autre
<tb> other~color~update <SEP> mise <SEP> à <SEP> jour <SEP> couleur
<tb> autre
<tb> other~texCoord~update <SEP> mise <SEP> à <SEP> jour <SEP> coord
<tb> texture <SEP> autre
<tb> each <SEP> vertex <SEP> in <SEP> mesh <SEP> chaque <SEP> sommet <SEP> dans
<tb> maillage
<tb> vertex <SEP> is <SEP> not <SEP> a <SEP> tree <SEP> loop <SEP> vertex <SEP> sommet <SEP> n'est <SEP> pas <SEP> un
<tb> sommet <SEP> de <SEP> boucle
<tb> each <SEP> face <SEP> in <SEP> mesh <SEP> chaque <SEP> face <SEP> dans
<tb> maillage
<tb> face <SEP> is <SEP> not <SEP> a <SEP> tree <SEP> loop <SEP> face <SEP> face <SEP> n'est <SEP> pas <SEP> une <SEP> face
<tb> de <SEP> boucle <SEP> d'arbre
<tb> each <SEP> corner <SEP> in <SEP> mesh <SEP> chaque <SEP> coin <SEP> dans
<tb> maillage
<tb> corner <SEP> is <SEP> not <SEP> a <SEP> tree <SEP> loop <SEP> corner <SEP> coin <SEP> n'est <SEP> pas <SEP> un <SEP> coin
<tb> de <SEP> boucle <SEP> d'arbre
<tb>

En résumé, la présente invention concerne un procédé de codage d'un objet maillé (OM) tridimensionnel (3D) polygonal comprenant les étapes consistant à: (a) diviser l'OM 3D polygonal en une ou plusieurs composantes reliées ; (b) générer un graphe de sommets et un arbre triangles/données triangles pour chacune des composantes reliées ; et (c) reconstruire le graphe de sommets et l'arbre triangles/données triangles constituant la composante reliée en conformité avec les couches de base de l'objet maillé (CBOM), chacune étant susceptible d'être décodé indépendamment pour les composantes reliées respectives et ensuite codé de la même manière.

Dans un mode de réalisation de la présente invention, l'étape (a) comporte les étapes consistant à classifier l'OM 3D polygonal en une pluralité de couches d'objet maillé (COM) et de diviser l'OM 3D polygonal classifié en une ou plusieurs composantes reliées.

Dans un autre mode de réalisation, si l'arbre triangles/données triangles constituant les composantes reliées est tellement grand qu'il n'est pas conforme aux CBOM, l'arbre triangles/données triangles est divisé en partitions de données dont chacune est susceptible d'être décodée indépendamment en conformité avec les CBOM, et si l'information constituant une pluralité de composantes reliées est conforme aux CBOM, l'information constituant une pluralité de composantes reliées est collectée en une partition de données pour être ensuite codée en conformité avec les CBOM.

Selon un autre mode de réalisation de la présente

invention, les CBOM dans lesquelles l'arbre triangles/données triangles est codé inclut un marqueur d'orientation à un bit à la position où existe un triangle d'embranchement positionné à la branche principale de l'arbre triangles, et l'ordre de traversée des arbres dépendants suivants après le triangle d'embranchement est déterminé par l'orientation marquée dans le marqueur d'orientation.

Selon un autre mode de réalisation de la présente invention, le marqueur d'orientation (td~orientation) est déterminé par la taille d'information des arbres dépendants suivants après le triangle d'embranchement.

Selon un autre mode de réalisation de la présente invention, tous les arbres dépendants sont dans le même ordre de traversée.

Selon un autre mode de réalisation de la présente invention, l'ordre de traversée d'un triangle à l'intérieur des arbres dépendants correspond à la valeur du marqueur d'orientation (td~orientation).

Selon un autre mode de réalisation de la présente invention, les CBOM dans lesquelles l'arbre triangles/données triangles est codé inclut l'information de taille totale (longueur~branche~codap) d'un arbre dépendant placé à une branche latérale dans un triangle d'embranchement placé à la branche principale de l'arbre triangles, et les index de sommet Y sont déterminés par l'information de taille totale.

Selon un autre aspect de la présente invention, la présente invention concerne un procédé de codage progressif et résilient vis-à-vis des erreurs d'un objet maillé (OM)

tridimensionnel (3D) polygonal comprenant les étapes consistant à : (a) diviser l'OM 3D polygonal en une ou plusieurs composantes reliées ; (b) générer un graphe de sommets et une paire d'arbres triangles/données triangles pour chacune des composantes reliées ; et (c) coder le graphe de sommets et l'arbre triangles/données triangles constituant les composantes reliées en conformité avec les couches de base de l'objet maillé (CBOM), chacune possédant un type fixé de flux binaire susceptible d'être décodé indépendamment pour les composantes reliées respectives.

Selon un autre mode de réalisation de la présente invention, à l'étape (c), le graphe de sommets et l'arbre triangles/données triangles sont disposés séquentiellement en conformité avec toutes les composantes reliées constituant le maillage en 3D polygonal pour constituer une partition de données.

Selon un autre mode de réalisation de la présente invention, à l'étape (c), le graphe de sommets correspondant à toutes les composantes reliées constituant le maillage en 3D polygonal est disposé en premier et l'arbre triangles/données triangles correspondant à toutes les données reliées est ensuite arrangé pour constituer une partition de données.

Selon un autre mode de réalisation de la présente invention, les informations constituant les composantes reliées respectives sont construites comme des partitions de données indépendantes pour être codée ensuite.

Selon un autre mode de réalisation de la présente

invention, à l'étape (c), le graphe de sommets correspondant à toutes les composantes reliées constituant le maillage en 3D polygonal est construit comme une partition de données et l'arbre triangles/données triangles correspondant à toutes les composantes reliées est construit comme une autre partition, pour être codé ensuite.

Selon un autre mode de réalisation de la présente invention, à l'étape (c), le graphe de sommets correspondant à toutes les composantes reliées constituant le maillage en 3D polygonal est construit comme une partition de données et l'arbre triangles/données triangles correspondant à toutes les composantes reliées est construit comme des partitions de données indépendantes, l'arbre triangles/données triangles étant divisé en une pluralité de partitions de données susceptibles d'être décodées indépendamment, pour être ensuite codées.

Selon un autre mode de réalisation de la présente invention, à l'étape (c), les graphes de sommets correspondant aux composantes reliées respectives constituant le maillage en 3D polygonal sont construits indépendamment comme partitions de données et les arbres triangles/données triangles correspondant aux composantes reliées respectives sont constitués indépendamment comme partitions de données, pour être ensuite codés.

Selon un autre mode de réalisation de la présente invention, à l'étape (c), les graphes de sommets correspondant aux composantes reliées respectives sont construits comme partitions de données indépendantes pour être ensuite codés en premier, et l'arbre triangles/données triangles correspondant aux composantes reliées respectives est construit comme partitions de données indépendantes,

l'arbre triangles/données triangles d'une composante reliée plus grand que le paquet de transmission étant divisé en une pluralité de partitions de données susceptibles d'être décodées indépendamment, pour être ensuite codées en suivant.

Selon un autre mode de réalisation de la présente invention, à l'étape (c), une partition de données est construite par le graphe de sommets correspondant à une composante reliée, et une partition de données indépendante est construite par l'arbre triangles/données triangles correspondant à la composante reliée, pour être ensuite codée par les composantes reliées respectives.

Selon un autre mode de réalisation de la présente invention, à l'étape (c), une partition de données indépendante est construite pour le graphe de sommets correspondant à une composante reliée et une partition de données indépendante est construite pour l'arbre triangles/données triangles correspondant à une composante reliée pour être ensuite codée, l'arbre triangles/données triangles d'une composante relié plus grand que le paquet de transmission étant divisé en une pluralité de partitions de données séparées susceptibles d'être décodées indépendamment, pour être ensuite codées par les composantes reliées respectives.

Selon un autre aspect de la présente invention, la présente invention concerne un procédé de codage progressif et résilient vis-à-vis des erreurs d'un objet maillé (OM) tridimensionnel (3D) polygonal, comprenant les étapes consistant à : (a) diviser l'OM 3D polygonal en une ou plusieurs composantes reliées ; (b) générer un graphe de sommets et une paire d'arbres

triangles/données triangles pour chacune des composantes reliées ; et (c) coder le graphe de sommets et l'arbre triangles/données triangles constituant les composantes reliées en conformité avec les couches de base de l'objet maillé (CBOM), chacun possédant un type de flux binaire variable en accord avec les propriétés de l'information à coder, susceptible d'être indépendamment décodé pour les composantes reliées respectives.

Selon un autre mode de réalisation de la présente invention, à l'étape (c), la structure de flux binaires codés est représentée en utilisant quelques-uns des bits dans un code de départ de la partition de données comme un type de partition.

Selon un autre mode de réalisation de la présente invention, le type de partition inclut un type de partition 0 (partition~type~0), dans lequel l'information correspondant à une ou plusieurs des composantes reliées est collectée afin de construire une partition de données pour être ensuite codée.

Selon un autre mode de réalisation de la présente invention, la CBOM dans laquelle le type de partition 0 est codé inclut en outre une pluralité de bits indicatifs de la présence d'autres composantes reliées devant être codées après que les composantes reliées respectives aient été codées.

Selon un autre mode de réalisation de la présente invention, le type de partition inclut un premier type de partition (partition-type-1) dans lequel les informations de graphe de sommets correspondant à une ou plusieurs composantes reliées sont collectées pour construire une

partition de données pour être ensuite codées.

Selon un autre mode de réalisation de la présente invention, la CBOM dans laquelle le premier type de partition est codé inclut en outre une pluralité de bits indicatifs de la présence d'autres informations de graphe de sommets devant être codées après que les informations de graphe de sommets correspondant aux composantes reliées respectives aient été codées.

Selon un autre mode de réalisation de la présente invention, le type de partition inclut un deuxième type de partition (partition~type~2) dans lequel l'arbre triangles/données triangles est divisé en partitions de données pour être ensuite codé.

Selon un autre mode de réalisation de la présente invention, la CBOM dans laquelle le deuxième type de partition est codé inclut en outre un identificateur des informations de graphe de sommets (codap~vg~id) correspondant à l'arbre triangles/données triangles respectif dans les partitions de données respectives.

Selon un autre mode de réalisation de la présente invention, s'il y a seulement un graphe de sommets auquel il est fait référence par l'arbre triangles/données triangles, l'identificateur du graphe de sommets n'est pas codé.

Selon un autre mode de réalisation de la présente invention, la CBOM dans laquelle le deuxième type de partition est codé inclut en outre un index de départ ( Index~boucle~ englobante~gauche~codap, Index~boucle~englobante~droite~ codap) d'une table de boucle englobante pour une bande

triangles devant être restaurée.

Selon un autre mode de réalisation de la présente invention, la CBOM dans laquelle le deuxième type de partition est codé inclut en outre un marqueur de prédiction de limite (codap~bdry~pred) indiquant comment la géométrie et la photométrie partagées par deux partitions de données ou plus sont prédites.

Selon un autre mode de réalisation de la présente invention, le type de partition inclut un troisième type de partition (partition~type~3) dans lequel une composante reliée est construite comme une partition de données pour être ensuite codée.

Selon un autre aspect de la présente invention, dans le codage d'un objet maillé (OM) tridimensionnel (3D) triangles pour construction incrémentale et résilience vis- à-vis des erreurs, procédé pour diviser l'OM 3D triangle en partitions de données pour être mises en paquets, le procédé comprend les étapes consistant à : (a) calculer les quantités de génération de bits totales des triangles pendant que les triangles contenus dans un arbre triangles sont traversés en séquences ; (b) cumuler les quantités de génération de bits totales calculées à l'étape (a) ; et (c) si la valeur cumulée de l'étape (b) est plus petite que le produit d'une taille de paquet et d'une allocation du paquet, exécuter de façon répétitive les étapes (a) et (b) sur le triangle traversé suivant contenu dans l'arbre triangles, et sinon les arbres triangles/données triangles des triangles traversés sont divisés en partitions pour être mises en paquets.

Selon un autre mode de réalisation de la présente

invention, si le triangle traversé à l'étape (a) est un triangle d'embranchement, la méthode comprend en outre l'étape suivante : (d) si la somme obtenue en additionnant la valeur cumulée de l'étape (b) et la quantité de génération de bits obtenue en codant tous les triangles contenus dans des arbres dépendants déterminés par l'ordre de traversée est plus petite que la somme de la taille de paquet et de l'allocation du paquet, exécuter de façon répétitive les étapes (a) à (c), et sinon les arbres triangles/données triangles des triangles, traversés jusqu'à ce que le triangle d'embranchement soit atteint, sont divisés en partitions de données pour être mis en paquets.

Selon un autre mode de réalisation de la présente invention, si le triangle traversé à l'étape (a) est un triangle d'embranchement, la méthode comprend en outre l'étape suivante : (d) si la somme obtenue en additionnant la valeur cumulée de l'étape (b) et la quantité de génération de bits obtenue prévue par la taille des arbres dépendants déterminés par l'ordre de traversée est plus petite que la somme de la taille de paquet et de l'allocation du paquet, exécuter de façon répétitive les étapes (a) à (c), et sinon l'arbre triangles/données triangles des triangles traversés jusqu'à ce que le triangle d'embranchement soit atteint est divisé en partitions de données pour être mis en paquets.

Selon un autre aspect de la présente invention, la présente invention concerne un procédé de codage progressif et résilient vis-à-vis des erreurs d'un objet maillé (OM) tridimensionnel (3D) polygonal, comprenant les étapes consistant à : (a) diviser l'OM 3D polygonal en une ou plusieurs composantes reliées ;

(b) générer un graphe de sommets et une paire d'arbres triangles/données triangles pour chacune des composantes reliées ; et (c) coder le graphe de sommets constituant les composantes reliées ; et (d) construire l'arbre triangles/données triangles comme composantes virtuelles reliées et coder de la même manière en additionnant les paires de bits virtuels en partitions de données obtenues par partition de l'arbre triangles/données triangles.

Selon un autre mode de réalisation de la présente invention, la partition à l'étape (d) est exécutée seulement à l'embranchement principal de l'arbre triangles.

Selon un autre mode de réalisation de la présente invention, si la partition à l'étape (d) est exécutée à une branche ou feuille de l'arbre triangles, une composante reliée virtuelle est construite en additionnant une paire de (1, 1) à une paire de (trun, tleaf).

Selon un autre mode de réalisation de la présente invention, si la partition à l'étape (d) est exécutée à un triangle d'embranchement de l'arbre triangles, une composante reliée virtuelle est construite en additionnant deux paires de (1, 1) à une paire de (trun, tleaf).

Selon un autre mode de réalisation de la présente invention, le procédé de codage progressif et résilient vis-à-vis des erreurs, comprend en outre l'étape consistant à reconstruire l'OM 3D polygonal en un OM 3D triangle avant l'étape (a) .

Selon un autre mode de réalisation de la présente

invention, la partition à l'étape (d) est exécutée seulement à l'arête réelle d'un maillage polygonal, et l'information d'arête polygonale du premier triangle contenu dans une partition de données de l'arbre triangles/données triangles n'est pas codée.

Selon un autre mode de réalisation de la présente invention, la partition à l'étape (d) est exécutée seulement à l'arête réelle et l'arête virtuelle d'un maillage polygonal, l'information d'arête polygonale du premier triangle contenu dans un type 0 de partition de l'arbre triangles/données triangles n'est pas codée, et l'information d'arête polygonale du premier triangle contenue dans les types de partition restants est codée.

Selon un autre mode de réalisation de la présente invention, des marqueurs d'orientation à un bit sont contenus dans la partition de données pour les triangles d'embranchement respectifs positionnés à la branche principale, parmi tous les triangles d'embranchement présents à l'intérieur de la partition de données construite par les composantes reliées virtuellement.

Selon un autre mode de réalisation de la présente invention, l'en-tête de la partition de données formée en divisant l'arbre triangles/données triangles inclut un index de départ d'une table de boucle englobante de façon à être restaurée indépendamment des partitions de données précédemment restaurées.

Selon un autre mode de réalisation de la présente invention, l'index de départ est déterminé par les premiers index gauche et droit tracés dans la boucle englobante correspondant aux sommets de départ des triangles restaurés consécutivement dans la table de boucle englobante

correspondant à l'arbre triangles/données triangles, et les index de la boucle englobante sont définis pour être dans la gamme du nombre de sommets plus 2.

Selon un autre mode de réalisation de la présente invention, l'index de départ est déterminé par les premiers index gauche et droit tracés dans la boucle englobante correspondant aux sommets de départ des triangles restaurés consécutivement dans la table de boucle englobante correspondant à l'arbre triangles/données triangles, et les index de la boucle englobante sont déterminés en considération des données de maillage globales.

Selon un autre mode de réalisation de la présente invention, l'en-tête de la partition de données formée en divisant l'arbre triangles/données triangles inclut en outre un identificateur d'un graphe de sommets (codap~vg~id) correspondant à l'arbre triangles/données triangles.

Selon un autre mode de réalisation de la présente invention, l'en-tête de la partition de données formée en divisant l'arbre triangles/données triangles inclut en outre un marqueur de prédiction de limite (codap~bdry~pred) indiquant comment la géométrie et la photométrie partagées par la partition de données et la partition de données précédemment codées sont prédites.

Selon un autre mode de réalisation de la présente invention, si les positions de départ et de fin des partitions de données sont à la branche principale de l'arbre triangles, la géométrie et la photométrie partagées par la partition de données et la partition de données précédemment codée sont contenues dans une partition de données seulement, et si les positions de départ et de fin

de la partition de données sont à un arbre dépendant, il est déterminé si la géométrie et la photométrie partagées par la partition de données et la partition de données précédemment codée sont présentes ou non, si elles sont présentes, la géométrie et la photométrie sont contenues dans les deux partitions de données à la fois, et si elles ne sont pas présentes, la géométrie et la photométrie sont contenues dans une partition de données seulement.

Selon un autre mode de réalisation de la présente invention, les données de triangles contenues dans l'arbre triangles/ données triangles incluent la progression, la géométrie et la photométrie disposées pour chaque triangle constituant l'arbre triangles correspondant.

Selon un autre mode de réalisation de la présente invention, les données de triangles contenues dans l'arbre triangles/données triangles incluent la progression de tous les triangles constituant l'arbre triangles correspondant, la géométrie de tous les triangles et la photométrie de tous les triangles disposées en séquences.

Selon un autre aspect de la présente invention, la présente invention concerne un procédé de décodage progressif et résilient vis-à-vis des erreurs d'un objet maillé (OM) tridimensionnel (3D) polygonal, comprenant les étapes consistant à : (a) diviser les flux binaires d'entrée en unités de couches de base d'objet maillé (CBOM) ; (b) déterminer un type de partition des CBOM ; (c) si un graphe de sommets est contenu dans les CBOM, décoder le graphe de sommets afin de générer une table de boucle englobante ; (d) si l'arbre triangles/données triangles est contenu

dans les CBOM, décoder l'arbre triangles/données triangles pour générer l'OM 3D ; et (e) exécuter de façon répétitive les étapes (a) à (d) pour générer un OM 3D.

Selon un autre mode de réalisation de la présente invention, l'étape (a) comprend les étapes consistant à diviser les flux binaires entrants en unités d'OM 3D polygonaux, déterminer le type d'une couche d'objet maillé (COM) contenue dans l'OM 3D polygonal, et diviser les flux binaires dans la COM en unités de couche de base d'objet maillé (CBOM) si l'OM 3D est capable d'être décodé.

Selon un autre mode de réalisation de la présente invention, l'arbre triangles/données triangles est décodé à l'étape (d), l'ordre de décodage des arbres dépendants suivants après le triangle d'embranchement est déterminé par l'orientation marquée dans un marqueur d'orientation (td~orientation) dans le cas de décodage d'un triangle d'embranchement positionné à la branche principale de l'arbre triangles.

Selon un autre mode de réalisation de la présente invention, à l'étape (b), le type de partition est déterminé par la valeur du code de départ de la partition de données.

Selon un autre mode de réalisation de la présente invention, le type de partition inclut un type de partition 0 (partition~type~0) dans lequel les informations correspondant à une ou plusieurs composantes reliées sont collectées pour construire une partition de données pour être ensuite codées.

Selon un autre mode de réalisation de la présente invention, lorsque la CBOM du type de partition 0 est codée, il est déterminé si d'autres composantes reliées devant être codées sont présentes par un bit prédéterminé positionné après les composantes reliées respectives.

Selon un autre mode de réalisation de la présente invention, le type de partition inclut un premier type de partition (partition~type~l) dans lequel les informations de graphe de sommets correspondant à une ou plusieurs composantes reliées sont collectées pour construire une partition de données pour être ensuite codées.

Selon un autre mode de réalisation de la présente invention, lorsque la CBOM du premier type de partition est codée, il est déterminé si d'autres informations de graphe de sommets à coder sont présentes par un bit prédéterminé (codap~last~vg) positionné après les informations de graphe de sommets correspondant aux composantes reliées respectives.

Selon un autre mode de réalisation de la présente invention, lorsque la CBOM du deuxième type de partition est codée, l'information de graphe de sommets correspondant à l'arbre triangles/données triangles respectif est identifiée par un identificateur de graphe de sommets (codap~vg~id) positionné avant l'arbre triangles/données triangles.

Selon un autre mode de réalisation de la présente invention, lorsque la CBOM du deuxième type de partition est codée, si l'information de graphe de sommets correspondant à l'arbre triangles/données triangles respectif peut être identifiée de façon unique, il est déterminé que l'identificateur de graphe de sommets n'est pas positionné avant l'arbre triangles/données triangles.

Selon un autre mode de réalisation de la présente invention, la CBOM du deuxième type de partition est codée indépendamment de la partition de données précédentes par l'index de départ (Index boucle~englobante~gauche~codap, Index~boucle~englobante~droite~codap) de la table de boucle englobante positionnée avant l'arbre triangles/données triangles.

Selon un autre mode de réalisation de la présente invention, lorsque la CBOM du deuxième type de partition est codée, il est déterminé comment la géométrie et la photométrie partagées par les partitions de données précédemment décodées sont prédites par un marqueur de prédiction de limite positionné avant l'arbre triangles/données triangles.

Selon un autre mode de réalisation de la présente invention, le type de partition inclut un troisième type de partition (partition~type~3) dans lequel une composante

reliée est construite comme une partition de données.

Selon un autre mode de réalisation de la présente invention, lorsque l'arbre triangles/données triangles est décodé à l'étape (d), si un triangle d'embranchement positionné à la branche principale de l'arbre triangles est décodé, les index de sommets Y sont déterminés par l'information de taille totale (longueur~branche~codap) d'un arbre dépendant positionné à une branche latérale.

Selon un autre aspect de la présente invention, la présente invention concerne un procédé de décodage progressif et résilient vis-à-vis des erreurs d'un objet maillé (OM) tridimensionnel (3D) polygonal, comprenant les étapes consistant à : (a) diviser les flux binaires d'entrée en unités de couches de base d'objet maillé (CBOM) ; (b) déterminer un type de partition des CBOM ; (c) si un graphe de sommets est contenu dans les CBOM, décoder le graphe de sommets afin de générer une table de boucle englobante ; (d) si l'arbre triangles/données triangles est contenu dans les CBOM, décoder l'arbre triangles/données triangles en unités de composantes reliées pour générer un OM 3D données triangles ; et (e) si les composantes reliées à l'étape (d) sont des composantes reliées virtuelles, exécuter de façon répétitive les étapes (a) à (d), et sinon compléter la génération d'un OM 3D triangle.

Selon un autre mode de réalisation de la présente invention, la CBOM contenant l'arbre triangles/données triangles à l'étape (d) inclut un index de départ (Index boucle~englobante~gauche~codap, Index~boucle~englobante~ droite~codap) d'une table de boucle englobante de façon à

être restauré indépendamment des partitions de données précédemment restaurées.

Selon un autre mode de réalisation de la présente invention, l'index de départ est déterminé par les premiers index gauche et droit tracés dans la boucle englobante correspondant aux sommets de départ des triangles restaurés consécutivement dans la table de boucle englobante correspondant à l'arbre triangles/données triangles, et les index de la boucle englobante sont définis en considération de toutes les mailles.

Selon un autre mode de réalisation de la présente invention, l'index de départ est déterminé par les premiers index gauche et droit tracés dans la boucle englobante correspondant aux sommets de départ des triangles restaurés consécutivement dans la table de boucle englobante correspondant à l'arbre triangles/données triangles, et les index de la boucle englobante sont définis pour être dans la gamme du nombre de sommets plus 2.

Selon un autre mode de réalisation de la présente invention, à l'étape (d), si l'index droit-l'index gauche-1 (Index~boucle~englobante~droite~codap, Index~boucle~ englobante~gauche~codap-l) est plus grand que le nombre total de triangles générés lorsque seul l'arbre triangles de la CBOM est restauré, il est déterminé que les composantes reliées sont des composantes reliées virtuelles.

Selon un autre mode de réalisation de la présente invention, si le troisième triangle du dernier parmi les triangles décodés à l'étape (d) est un triangle d'embranchement, il est déterminé que deux des triangles virtuels existent dans une paire de (trun, tleaf) et sinon

il est déterminé qu'une paire de triangles virtuels existe dans une paire de (trun, tleaf), de façon que les données de triangle des triangles virtuels ne soient pas codées.

Selon un autre mode de réalisation de la présente invention, le procédé de décodage progressif et résilient vis-à-vis des erreurs, comprend en outre l'étape consistant à reconstruire l'OM 3D triangle en un OM 3D polygonal.

Selon un autre mode de réalisation de la présente invention, la partition pendant le codage est exécutée seulement à l'arête réelle de l'OM 3D polygonal et l'arête polygonale du premier triangle contenu dans la CBOM de l'arbre triangles/données triangles est déterminée pour être l'arête réelle sans décodage.

Selon un autre mode de réalisation de la présente invention, la partition pendant le codage est également exécutée à l'intérieur de l'OM 3D polygonal et l'arête polygonale du premier triangle contenu dans la CBOM de l'arbre triangles/données triangles est déterminée comme étant l'arête réelle sans décodage.

Selon un autre mode de réalisation de la présente invention, l'ordre de décodage des arbres dépendants suivants après le triangle d'embranchement est déterminé par l'orientation marquée dans un marqueur d'orientation (td~orientation) dans le cas de décodage d'un triangle d'embranchement, par rapport à tous les triangles d'embranchement positionnés à l'intérieur de la CBOM construite par les composantes reliées virtuelles.

Selon un autre mode de réalisation de la présente invention, la CBOM contenant l'arbre triangles/données triangles à l'étape (d) inclut un marqueur de prédiction de

limite (codap~bdry~pre) indiquant comment la géométrie et la photométrie partagées par deux CBOM ou plus sont prédites.

Selon un autre mode de réalisation de la présente invention, la valeur du marqueur de prédiction de limite est 0, et il est déterminé que la géométrie et la photométrie partagées par la CBOM en cours de décodage et la CBOM précédemment décodée ne sont pas contenues dans la CBOM en cours de décodage.

Selon un autre mode de réalisation de la présente invention, lorsque la géométrie est décodée en utilisant une valeur de prédiction prédite par trois ascendants visités précédemment dans la partition de données en cours et une valeur codée de celle-ci, la valeur de prédiction est établie sur 0 si aucune valeur d'ascendant n'est admissible, la valeur de prédiction est établie sur la valeur de l'ascendant si seulement une valeur d'ascendant est admissible, la valeur de prédiction est établie sur une valeur de moyenne arithmétique de deux valeurs d'ascendants admissibles si les deux valeurs d'ascendants sont admissibles et que les distances entre les deux valeurs et le sommet en cours sont 1, la valeur de prédiction est établie sur l'une ou l'autre des valeurs d'ascendants si seulement deux valeurs d'ascendants sont admissibles la distance entre l'une ou l'autre des valeurs et le sommet en cours est 1, et la valeur de prédiction est déterminée par une méthode de prédiction prédéterminée si trois valeurs d'ascendants sont toutes admissibles.

Selon un autre mode de réalisation de la présente invention, la valeur du marqueur de prédiction de limite est 1, il est déterminé que la géométrie et la photométrie partagées par la CBOM en cours de décodage et la CBOM

précédemment décodée sont également contenues dans la CBOM en cours de décodage.

Selon un autre mode de réalisation de la présente invention, lorsque la géométrie est décodée en utilisant une valeur de prédiction prédite par trois ascendants visités précédemment dans la partition de données en cours et une valeur codée de celle-ci, la valeur de prédiction est déterminée par une méthode de prédiction prédéterminée sur la supposition qu'aucun sommet n'a été visité dans les partitions de données précédentes.

Selon un autre mode de réalisation de la présente invention, les données triangles contenues dans l'arbre triangles/données triangles incluent la progression, la géométrie et la photométrie disposées pour chaque triangle constituant l'arbre triangles correspondant.

Selon un autre mode de réalisation de la présente invention, les données triangles contenues dans l'arbre triangles/données triangles incluent la progression de tous les triangles constituant l'arbre triangles correspondant, la géométrie de tous les triangles et la photométrie de tous les triangles disposées en séquences.

Claims

REVENDICATIONS

1. Procédé de codage d'un objet maillé (OM) tridimensionnel (3D) polygonal comprenant les étapes consistant à: (a) diviser l'OM 3D polygonal en une ou plusieurs composantes reliées ; (b) générer un graphe de sommets et un arbre triangles/données triangles pour chacune des composantes reliées ; et (c) reconstruire le graphe de sommets et l'arbre triangles/données triangles constituant la composante reliée en conformité avec les couches de base de l'objet maillé (CBOM), chacune étant susceptible d'être décodé indépendamment pour les composantes reliées respectives et ensuite codé de la même manière.

2. Procédé de codage selon la revendication 1, dans lequel l'étape (a) comporte les étapes consistant à classifier l'OM 3D polygonal en une pluralité de couches d'objet maillé (COM) et de diviser l'OM 3D polygonal classifié en une ou plusieurs composantes reliées.

3. Procédé de codage selon la revendication 1, dans lequel à l'étape (c), si l'arbre triangles/données triangles constituant les composantes reliées est tellement grand qu'il n'est pas conforme aux CBOM, l'arbre triangles/données triangles est divisé en partitions de données dont chacune est susceptible d'être décodée

indépendamment en conformité avec les CBOM, et si l'information constituant une pluralité de composantes reliées est conforme aux CBOM, l'information constituant une pluralité de composantes reliées est collectée en une partition de données pour être ensuite codée en conformité avec les CBOM.

4. Procédé de codage selon la revendication 1, dans lequel les CBOM dans lesquelles l'arbre triangles/données triangles est codé inclut un marqueur d'orientation à un bit à la position où existe un triangle d'embranchement positionné à la branche principale de l'arbre triangles, et l'ordre de traversée des arbres dépendants suivants après le triangle d'embranchement est déterminé par l'orientation marquée dans le marqueur d'orientation.

5. Procédé de codage selon la revendication 4, dans lequel le marqueur d'orientation (td~orientation) est déterminé par la taille d'information des arbres dépendants suivants après le triangle d'embranchement.

6. Procédé de codage selon la revendication 5, dans lequel tous les arbres dépendants sont dans le même ordre de traversée.

7. Procédé de codage selon la revendication 5, dans lequel l'ordre de traversée d'un triangle à l'intérieur des arbres dépendants correspond à la valeur du marqueur d'orientation (td~orientation).

8. Procédé de codage selon la revendication 1, dans lequel les CBOM dans lesquelles l'arbre triangles/données triangles est codé inclut l'information de taille totale (longueur~branche~codap) d'un arbre dépendant placé à une branche latérale dans un triangle d'embranchement placé à

la branche principale de l'arbre triangles, et les index de sommet Y sont déterminés par l'information de taille totale.

9. Procédé de codage selon l'une quelconque des revendications 1 à 8, polygonal comprenant en outre les étapes consistant à : (d) générer un graphe de sommets et une paire d'arbres triangles/données triangles pour chacune des composantes reliées ; et (e) coder le graphe de sommets et l'arbre triangles/données triangles constituant les composantes reliées en conformité avec les couches de base de l'objet maillé (CBOM), chacune possédant un type fixé de flux binaire susceptible d'être décodé indépendamment pour les composantes reliées respectives.

10. Procédé de codage selon la revendication 9, dans lequel, à l'étape (e), le graphe de sommets et l'arbre triangles/données triangles sont disposés séquentiellement en conformité avec toutes les composantes reliées constituant le maillage en 3D polygonal pour constituer une partition de données.

11. Procédé de codage selon la revendication 9, dans lequel, à l'étape (e), le graphe de sommets correspondant à toutes les composantes reliées constituant le maillage en 3D polygonal est disposé en premier et l'arbre triangles/données triangles correspondant à toutes les données reliées est ensuite arrangé pour constituer une partition de données.

12. Procédé de codage selon la revendication 9, dans lequel les informations constituant les composantes reliées respectives sont construites comme des partitions de

données indépendantes pour être codée ensuite.

13. Procédé de codage selon la revendication 9, dans lequel, à l'étape (d), le graphe de sommets correspondant à toutes les composantes reliées constituant le maillage en 3D polygonal est construit comme une partition de données et l'arbre triangles/données triangles correspondant à toutes les composantes reliées est construit comme une autre partition, pour être codé ensuite.

14. Procédé de codage selon la revendication 9, dans lequel, à l'étape (e), le graphe de sommets correspondant à toutes les composantes reliées constituant le maillage en 3D polygonal est construit comme une partition de données et l'arbre triangles/données triangles correspondant à toutes les composantes reliées est construit comme des partitions de données indépendantes, l'arbre triangles/données triangles étant divisé en une pluralité de partitions de données susceptibles d'être décodées indépendamment, pour être ensuite codées.

15. Procédé de codage selon la revendication 9, dans lequel, à l'étape (e), les graphes de sommets correspondant aux composantes reliées respectives constituant le maillage en 3D polygonal sont construits indépendamment comme partitions de données et les arbres triangles/données triangles correspondant aux composantes reliées respectives sont constitués indépendamment comme partitions de données, pour être ensuite codés.

16. Procédé de codage selon la revendication 9, dans lequel, à l'étape (e), les graphes de sommets correspondant aux composantes reliées respectives sont construits comme partitions de données indépendantes pour être ensuite codés en premier, et l'arbre triangles/données triangles

correspondant aux composantes reliées respectives est construit comme partitions de données indépendantes, l'arbre triangles/données triangles d'une composante reliée plus grand que le paquet de transmission étant divisé en une pluralité de partitions de données susceptibles d'être décodées indépendamment, pour être ensuite codées en suivant.

17. Procédé de codage selon la revendication 9, dans lequel, à l'étape (e), une partition de données est construite par le graphe de sommets correspondant à une composante reliée, et une partition de données indépendante est construite par l'arbre triangles/données triangles correspondant à la composante reliée, pour être ensuite codée par les composantes reliées respectives.

18. Procédé de codage selon la revendication 9, dans lequel, à l'étape (e), une partition de données indépendante est construite pour le graphe de sommets correspondant à une composante reliée et une partition de données indépendante est construite pour l'arbre triangles/données triangles correspondant à une composante reliée pour être ensuite codée, l'arbre triangles/données triangles d'une composante relié plus grand que le paquet de transmission étant divisé en une pluralité de partitions de données séparées susceptibles d'être décodées indépendamment, pour être ensuite codées par les composantes reliées respectives.

19. Procédé de codage selon l'une quelconque des revendications 1 à 8, comprenant en outre les étapes consistant à : (d) générer un graphe de sommets et une paire d'arbres triangles/données triangles pour chacune des composantes reliées ; et

(e) coder le graphe de sommets et l'arbre triangles/données triangles constituant les composantes reliées en conformité avec les couches de base de l'objet maillé (CBOM), chacun possédant un type de flux binaire variable en accord avec les propriétés de l'information à coder, susceptible d'être indépendamment décodé pour les composantes reliées respectives.

20. Procédé de codage selon la revendication 19, dans lequel, à l'étape (e), la structure de flux binaires codés est représentée en utilisant quelques-uns des bits dans un code de départ de la partition de données comme un type de partition.

21. Procédé de codage selon la revendication 20, dans lequel le type de partition inclut un type de partition 0 (partition~type~0), dans lequel l'information correspondant à une ou plusieurs des composantes reliées est collectée afin de construire une partition de données pour être ensuite codée.

22. Procédé de codage selon la revendication 21, dans lequel la CBOM dans laquelle le type de partition 0 est codé inclut en outre une pluralité de bits indicatifs de la présence d'autres composantes reliées devant être codées après que les composantes reliées respectives aient été codées.

23. Procédé de codage selon la revendication 20, dans lequel le type de partition inclut un premier type de partition (partition~type~1) dans lequel les informations de graphe de sommets correspondant à une ou plusieurs composantes reliées sont collectées pour construire une partition de données pour être ensuite codées.

24. Procédé de codage selon la revendication 23, dans lequel la CBOM dans laquelle le premier type de partition est codé inclut en outre une pluralité de bits indicatifs de la présence d'autres informations de graphe de sommets devant être codées après que les informations de graphe de sommets correspondant aux composantes reliées respectives aient été codées.

25. Procédé de codage selon la revendication 20, dans lequel le type de partition inclut un deuxième type de partition (partition~type~2) dans lequel l'arbre triangles/données triangles est divisé en partitions de données pour être ensuite codé.

26. Procédé de codage selon la revendication 25, dans lequel la CBOM dans laquelle le deuxième type de partition est codé inclut en outre un identificateur des informations de graphe de sommets (codap~vg~id) correspondant à l'arbre triangles/données triangles respectif dans les partitions de données respectives.

27. Procédé de codage selon la revendication 26, dans lequel s'il y a seulement un graphe de sommets auquel il est fait référence par l'arbre triangles/données triangles, l'identificateur du graphe de sommets n'est pas codé.

28. Procédé de codage selon la revendication 25, dans lequel la CBOM dans laquelle le deuxième type de partition est codé inclut en outre un index de départ (Index boucle

englobante~gauche~codap, Index boucle englobante droite- codap) d'une table de boucle englobante pour une bande triangles devant être restaurée.

29. Procédé de codage selon la revendication 25, dans lequel la CBOM dans laquelle le deuxième type de partition

est codé inclut en outre un marqueur de prédiction de limite (codap~bdry~pred) indiquant comment la géométrie et la photométrie partagées par deux partitions de données ou plus sont prédites.

30. Procédé de codage selon la revendication 20, dans lequel le type de partition inclut un troisième type de partition (partition~type~3) dans lequel une composante reliée est construite comme une partition de données pour être ensuite codée.

31. Procédé de codage selon l'une quelconque des revendications 1 à 8, caractérisé en ce que, dans le codage d'un objet maillé (OM) tridimensionnel (3D) triangles pour construction incrémentale et résilience vis-à-vis des erreurs, procédé pour diviser l'OM 3D triangle en partitions de données pour être mises en paquets, le procédé comprend en outre les étapes consistant à : (d) calculer les quantités de génération de bits totales des triangles pendant que les triangles contenus dans un arbre triangles sont traversés en séquences ; (e) cumuler les quantités de génération de bits totales calculées à l'étape (d) ; et (f) si la valeur cumulée de l'étape (e) est plus petite que le produit d'une taille de paquet et d'une allocation du paquet, exécuter de façon répétitive les étapes (d) et (e) sur le triangle traversé suivant contenu dans l'arbre triangles, et sinon les arbres triangles/données triangles des triangles traversés sont divisés en partitions pour être mises en paquets.

32. Procédé selon la revendication 31, dans laquelle si le triangle traversé à l'étape (d) est un triangle d'embranchement, la méthode comprend en outre l'étape suivante :

(g) si la somme obtenue en additionnant la valeur cumulée de l'étape (e) et la quantité de génération de bits obtenue en codant tous les triangles contenus dans des arbres dépendants déterminés par l'ordre de traversée est plus petite que la somme de la taille de paquet et de l'allocation du paquet, exécuter de façon répétitive les étapes (d) à (f), et sinon les arbres triangles/données triangles des triangles, traversés jusqu'à ce que le triangle d'embranchement soit atteint, sont divisés en partitions de données pour être mis en paquets.

33. Procédé selon la revendication 31, dans laquelle si le triangle traversé à l'étape (d) est un triangle d'embranchement, la méthode comprend en outre l'étape suivante : (g) si la somme obtenue en additionnant la valeur cumulée de l'étape (e) et la quantité de génération de bits obtenue prévue par la taille des arbres dépendants déterminés par l'ordre de traversée est plus petite que la somme de la taille de paquet et de l'allocation du paquet, exécuter de façon répétitive les étapes (d) à (f), et sinon l'arbre triangles/données triangles des triangles traversés jusqu'à ce que le triangle d'embranchement soit atteint est divisé en partitions de données pour être mis en paquets.

34. Procédé de codage d'un objet maillé (OM) tridimensionnel (3D) polygonal selon l'une quelconque des revendications 1 à 8, comprenant en outre les étapes consistant à : (d) générer un graphe de sommets et une paire d'arbres triangles/données triangles pour chacune des composantes reliées ; et (e) coder le graphe de sommets constituant les composantes reliées ; et (f) construire l'arbre triangles/données triangles

comme composantes virtuelles reliées et coder de la même manière en additionnant les paires de bits virtuels en partitions de données obtenues par partition de l'arbre triangles/données triangles.

35. Procédé de codage selon la revendication 34, dans laquelle la partition à l'étape (f) est exécutée seulement à l'embranchement principal de l'arbre triangles.

36. Procédé de codage selon la revendication 35, dans lequel si la partition à l'étape (f) est exécutée à une branche ou feuille de l'arbre triangles, une composante reliée virtuelle est construite en additionnant une paire de (1,1) à une paire de (trun, tleaf) .

37. Procédé de codage selon la revendication 35, dans lequel si la partition à l'étape (f) est exécutée à un triangle d'embranchement de l'arbre triangles, une composante reliée virtuelle est construite en additionnant deux paires de (1,1) à une paire de (trun, tleaf).

38. Procédé de codage selon la revendication 34, comprenant en outre l'étape consistant à reconstruire l'OM 3D polygonal en un OM 3D triangle avant l'étape (a).

39. Procédé de codage selon la revendication 38, dans lequel la partition à l'étape (f) est exécutée seulement à l'arête réelle d'un maillage polygonal, et l'information d'arête polygonale du premier triangle contenu dans une partition de données de l'arbre triangles/données triangles n'est pas codée.

40. Procédé de codage selon la revendication 38, dans lequel la partition à l'étape (f) est exécutée seulement à l'arête réelle et l'arête virtuelle d'un maillage

polygonal, l'information d'arête polygonale du premier triangle contenu dans un type 0 de partition de l'arbre triangles/données triangles n'est pas codée, et l'information d'arête polygonale du premier triangle contenue dans les types de partition restants est codée.

41. Procédé de codage selon la revendication 34, dans lequel des marqueurs d'orientation à un bit sont contenus dans la partition de données pour les triangles d'embranchement respectifs positionnés à la branche principale, parmi tous les triangles d'embranchement présents à l'intérieur de la partition de données construite par les composantes reliées virtuellement.

42. Procédé de codage selon la revendication 34, dans lequel l'en-tête de la partition de données formée en divisant l'arbre triangles/données triangles inclut un index de départ d'une table de boucle englobante de façon à être restaurée indépendamment des partitions de données précédemment restaurées.

43. Procédé de codage selon la revendication 42, dans lequel l'index de départ est déterminé par les premiers index gauche et droit tracés dans la boucle englobante correspondant aux sommets de départ des triangles restaurés consécutivement dans la table de boucle englobante correspondant à l'arbre triangles/données triangles, et les index de la boucle englobante sont définis pour être dans la gamme du nombre de sommets plus 2.

44. Procédé de codage selon la revendication 42, dans lequel l'index de départ est déterminé par les premiers index gauche et droit tracés dans la boucle englobante correspondant aux sommets de départ des triangles restaurés consécutivement dans la table de boucle englobante

correspondant à l'arbre triangles/données triangles, et les index de la boucle englobante sont déterminés en considération des données de maillage globales.

45. Procédé de codage selon la revendication 34, dans lequel l'en-tête de la partition de données formée en divisant l'arbre triangles/données triangles inclut en outre un identificateur d'un graphe de sommets (codap~vg~id) correspondant à l'arbre triangles/données triangles.

46. Procédé de codage selon la revendication 34, dans lequel l'en-tête de la partition de données formée en divisant l'arbre triangles/données triangles inclut en outre un marqueur de prédiction de limite (codap~bdry~pred) indiquant comment la géométrie et la photométrie partagées par la partition de données et la partition de données précédemment codées sont prédites.

47. Procédé de codage selon la revendication 34, dans lequel si les positions de départ et de fin des partitions de données sont à la branche principale de l'arbre triangles, la géométrie et la photométrie partagées par la partition de données et la partition de données précédemment codée sont contenues dans une partition de données seulement, et si les positions de départ et de fin de la partition de données sont à un arbre dépendant, il est déterminé si la géométrie et la photométrie partagées par la partition de données et la partition de données précédemment codée sont présentes ou non, si elles sont présentes, la géométrie et la photométrie sont contenues dans les deux partitions de données à la fois, et si elles ne sont pas présentes, la géométrie et la photométrie sont contenues dans une partition de données seulement.

48. Procédé de codage selon la revendication 34, dans lequel les données de triangles contenues dans l'arbre triangles/ données triangles incluent la progression, la géométrie et la photométrie disposées pour chaque triangle constituant l'arbre triangles correspondant.

49. Procédé de codage selon la revendication 34, dans lequel les données de triangles contenues dans l'arbre triangles/données triangles incluent la progression de tous les triangles constituant l'arbre triangles correspondant, la géométrie de tous les triangles et la photométrie de tous les triangles disposées en séquences.

50. Procédé de codage selon l'une quelconque des revendications 1 à 8, comportant en outre, un procédé de décodage progressif et résilient vis-à-vis des erreurs d'un objet maillé (OM) tridimensionnel (3D) polygonal, comprenant les étapes consistant à : (d) diviser les flux binaires d'entrée en unités de couches de base d'objet maillé (CBOM) ; (e) déterminer un type de partition des CBOM ; (f) si un graphe de sommets est contenu dans les CBOM, décoder le graphe de sommets afin de générer une table de boucle englobante ; (g) si l'arbre triangles/données triangles est contenu dans les CBOM, décoder l'arbre triangles/données triangles pour générer l'OM 3D ; et (h) exécuter de façon répétitive les étapes (a) à (d) pour générer un OM 3D.

51. Procédé de décodage selon la revendication 50, dans lequel l'étape (d) comprend les étapes consistant à diviser les flux binaires entrants en unités d'OM 3D polygonaux, déterminer le type d'une couche d'objet maillé

(COM) contenue dans l'OM 3D polygonal, et diviser les flux binaires dans la COM en unités de couche de base d'objet maillé (CBOM) si l'OM 3D est capable d'être décodé.

52. Procédé selon la revendication 50, dans lequel l'arbre triangles/données triangles est décodé à l'étape (g), l'ordre de décodage des arbres dépendants suivants après le triangle d'embranchement est déterminé par l'orientation marquée dans un marqueur d'orientation (td~orientation) dans le cas de décodage d'un triangle d'embranchement positionné à la branche principale de l'arbre triangles.

53. Procédé selon la revendication 52, dans lequel tous les arbres dépendants sont dans le même ordre de traversée.

54. Procédé selon la revendication 52, dans lequel l'ordre de traversée d'un triangle à l'intérieur des arbres dépendants correspond à la valeur du marqueur d'orientation (td~orientation) .

55. Procédé selon la revendication 52, dans lequel à l'étape (e), le type de partition est déterminé par la valeur du code de départ de la partition de données.

56. Procédé selon la revendication 55, dans lequel le type de partition inclut un type de partition 0 (partition~type~0) dans lequel les informations correspondant à une ou plusieurs composantes reliées sont collectées pour construire une partition de données pour être ensuite codées.

57. Procédé selon la revendication 56, dans lequel lorsque la CBOM du type de partition 0 est codée, il est

déterminé si d'autres composantes reliées devant être codées sont présentes par un bit prédéterminé positionné après les composantes reliées respectives.

58. Procédé selon la revendication 54, dans lequel le type de partition inclut un premier type de partition (partition~type~1) dans lequel les informations de graphe de sommets correspondant à une ou plusieurs composantes reliées sont collectées pour construire une partition de données pour être ensuite codées.

59. Procédé selon la revendication 58, dans lequel lorsque la CBOM du premier type de partition est codée, il est déterminé si d'autres informations de graphe de sommets à coder sont présentes par un bit prédéterminé (codap~last~vg) positionné après les informations de graphe de sommets correspondant aux composantes reliées respectives.

60. Procédé selon la revendication 55, dans lequel le type de partition inclut un deuxième type de partition (partition~type~2) dans lequel l'arbre triangles/données triangles est divisé en partitions de données pour être ensuite codé.

61. Procédé selon la revendication 60, dans lequel lorsque la CBOM du deuxième type de partition est codée, l'information de graphe de sommets correspondant à l'arbre triangles/données triangles respectif est identifiée par un identificateur de graphe de sommets (codap~vg~id) positionné avant l'arbre triangles/données triangles.

62. Procédé selon la revendication 60, dans lequel lorsque la CBOM du deuxième type de partition est codée, si l'information de graphe de sommets correspondant à l'arbre

triangles/données triangles respectif peut être identifiée de façon unique, il est déterminé que l'identificateur de graphe de sommets n'est pas positionné avant l'arbre triangles/données triangles.

63. Procédé selon la revendication 60, dans lequel la CBOM du deuxième type de partition est codée indépendamment de la partition de données précédentes par l'index de départ (Index boucle~englobante~gauche~codap, Index~boucle~ englobante~droite~codap) de la table de boucle englobante positionnée avant l'arbre triangles/données triangles.

64. Procédé selon la revendication 60, dans lequel lorsque la CBOM du deuxième type de partition est codée, il est déterminé comment la géométrie et la photométrie partagées par les partitions de données précédemment décodées sont prédites par un marqueur de prédiction de limite positionné avant l'arbre triangles/données triangles.

65. Procédé selon la revendication 55, dans lequel le type de partition inclut un troisième type de partition (partition~type~3) dans lequel une composante reliée est construite comme une partition de données.

66. Procédé selon la revendication 50, dans lequel lorsque l'arbre triangles/données triangles est décodé à l'étape (g), si un triangle d'embranchement positionné à la branche principale de l'arbre triangles est décodé, les index de sommets Y sont déterminés par l'information de taille totale (longueur~branche~codap) d'un arbre dépendant positionné à une branche latérale.

67. Procédé selon l'une quelconque des revendications 1 à 8, comportant en outre, un procédé de décodage

progressif et résilient vis-à-vis des erreurs d'un objet maillé (OM) tridimensionnel (3D) polygonal, comprenant les étapes consistant à : (d) diviser les flux binaires d'entrée en unités de couches de base d'objet maillé (CBOM) ; (e) déterminer un type de partition des CBOM ; (f) si un graphe de sommets est contenu dans les CBOM, décoder le graphe de sommets afin de générer une table de boucle englobante ; (g) si l'arbre triangles/données triangles est contenu dans les CBOM, décoder l'arbre triangles/données triangles en unités de composantes reliées pour générer un OM 3D données triangles ; et (h) si les composantes reliées à l'étape (d) sont des composantes reliées virtuelles, exécuter de façon répétitive les étapes (a) à (d), et sinon compléter la génération d'un OM 3D triangle.

68. Procédé selon la revendication 67, dans lequel la CBOM contenant l'arbre triangles/données triangles à l'étape (g) inclut un index de départ (Index boucle~englobante~gauche~codap, Index~boucle~englobante~ droite~codap) d'une table de boucle englobante de façon à être restauré indépendamment des partitions de données précédemment restaurées.

69. Procédé selon la revendication 68, dans lequel l'index de départ est déterminé par les premiers index gauche et droit tracés dans la boucle englobante correspondant aux sommets de départ des triangles restaurés consécutivement dans la table de boucle englobante correspondant à l'arbre triangles/données triangles, et les index de la boucle englobante sont définis en considération de toutes les mailles.

70. Procédé selon la revendication 68, dans lequel l'index de départ est déterminé par les premiers index gauche et droit tracés dans la boucle englobante correspondant aux sommets de départ des triangles restaurés consécutivement dans la table de boucle englobante correspondant à l'arbre triangles/données triangles, et les index de la boucle englobante sont définis pour être dans la gamme du nombre de sommets plus 2.

71. Procédé selon la revendication 68, dans lequel à l'étape (g), si l'index droit-l'index gauche-1 (Index~boucle~englobante~droite~codap, Index~boucle~ englobante~gauche~codap-1) est plus grand que le nombre total de triangles générés lorsque seul l'arbre triangles de la CBOM est restauré, il est déterminé que les composantes reliées sont des composantes reliées virtuelles.

72. Procédé selon la revendication 71, dans lequel si le troisième triangle du dernier parmi les triangles décodés à l'étape (g) est un triangle d'embranchement, il est déterminé que deux des triangles virtuels existent dans une paire de (trun, tleaf) et sinon il est déterminé qu'une paire de triangles virtuels existe dans une paire de (trun, tleaf), de façon que les données de triangle des triangles virtuels ne soient pas codées.

73. Procédé selon la revendication 68, comprenant en outre l'étape consistant à reconstruire l'OM 3D triangle en un OM 3D polygonal.

74. Procédé selon la revendication 73, dans lequel la partition pendant le codage est exécutée seulement à l'arête réelle de l'OM 3D polygonal et l'arête polygonale du premier triangle contenu dans la CBOM de l'arbre

triangles/données triangles est déterminée pour être l'arête réelle sans décodage.

75. Procédé selon la revendication 73, dans lequel la partition pendant le codage est également exécutée à l'intérieur de l'OM 3D polygonal et l'arête polygonale du premier triangle contenu dans la CBOM de l'arbre triangles/données triangles est déterminée comme étant l'arête réelle sans décodage.

76. Procédé selon la revendication 67, dans lequel l'ordre de décodage des arbres dépendants suivants après le triangle d'embranchement est déterminé par l'orientation marquée dans un marqueur d'orientation (td~orientation) dans le cas de décodage d'un triangle d'embranchement, par rapport à tous les triangles d'embranchement positionnés à l'intérieur de la CBOM construite par les composantes reliées virtuelles.

77. Procédé selon la revendication 67, dans lequel la CBOM contenant l'arbre triangles/données triangles à l'étape (g) inclut un marqueur de prédiction de limite (codap~bdry~pre) indiquant comment la géométrie et la photométrie partagées par deux CBOM ou plus sont prédites.

78. Procédé selon la revendication 77, dans lequel la valeur du marqueur de prédiction de limite est 0, et il est déterminé que la géométrie et la photométrie partagées par la CBOM en cours de décodage et la CBOM précédemment décodée ne sont pas contenues dans la CBOM en cours de décodage.

79. Procédé selon la revendication 78, dans lequel lorsque la géométrie est décodée en utilisant une valeur de prédiction prédite par trois ascendants visités

précédemment dans la partition de données en cours et une valeur codée de celle-ci, la valeur de prédiction est établie sur 0 si aucune valeur d'ascendant n'est admissible, la valeur de prédiction est établie sur la valeur de l'ascendant si seulement une valeur d'ascendant est admissible, la valeur de prédiction est établie sur une valeur de moyenne arithmétique de deux valeurs d'ascendants admissibles si les deux valeurs d'ascendants sont admissibles et que les distances entre les deux valeurs et le sommet en cours sont 1, la valeur de prédiction est établie sur l'une ou l'autre des valeurs d'ascendants si seulement deux valeurs d'ascendants sont admissibles la distance entre l'une ou l'autre des valeurs et le sommet en cours est 1, et la valeur de prédiction est déterminée par une méthode de prédiction prédéterminée si trois valeurs d'ascendants sont toutes admissibles.

80. Procédé selon la revendication 77, dans lequel la valeur du marqueur de prédiction de limite est 1, il est déterminé que la géométrie et la photométrie partagées par la CBOM en cours de décodage et la CBOM précédemment décodée sont également contenues dans la CBOM en cours de décodage.

81. Procédé selon la revendication 80, dans lequel lorsque la géométrie est décodée en utilisant une valeur de prédiction prédite par trois ascendants visités précédemment dans la partition de données en cours et une valeur codée de celle-ci, la valeur de prédiction est déterminée par une méthode de prédiction prédéterminée sur la supposition qu'aucun sommet n'a été visité dans les partitions de données précédentes.

82. Procédé selon la revendication 67, dans lequel les données triangles contenues dans l'arbre triangles/données

triangles incluent la progression, la géométrie et la photométrie disposées pour chaque triangle constituant l'arbre triangles correspondant.

83. Procédé selon la revendication 67, dans lequel les données triangles contenues dans l'arbre triangles/données triangles incluent la progression de tous les triangles constituant l'arbre triangles correspondant, la géométrie de tous les triangles et la photométrie de tous les triangles disposées en séquences.