DE69624636T2 - Verfahren und Vorrichtung zur geometrischen Komprimierung von dreidimensionelen Grafiken - Google Patents
Verfahren und Vorrichtung zur geometrischen Komprimierung von dreidimensionelen GrafikenInfo
- Publication number
- DE69624636T2 DE69624636T2 DE69624636T DE69624636T DE69624636T2 DE 69624636 T2 DE69624636 T2 DE 69624636T2 DE 69624636 T DE69624636 T DE 69624636T DE 69624636 T DE69624636 T DE 69624636T DE 69624636 T2 DE69624636 T2 DE 69624636T2
- Authority
- DE
- Germany
- Prior art keywords
- information
- bits
- normal
- data
- compression
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 230000006835 compression Effects 0.000 title claims description 114
- 238000007906 compression Methods 0.000 title claims description 113
- 238000000034 method Methods 0.000 title claims description 48
- 239000003086 colorant Substances 0.000 claims description 25
- 238000013139 quantization Methods 0.000 claims description 23
- 238000012545 processing Methods 0.000 claims description 13
- 239000013598 vector Substances 0.000 claims description 4
- 239000000463 material Substances 0.000 claims 2
- 239000000872 buffer Substances 0.000 description 58
- 230000006837 decompression Effects 0.000 description 36
- 238000010586 diagram Methods 0.000 description 13
- 239000000203 mixture Substances 0.000 description 12
- 238000004422 calculation algorithm Methods 0.000 description 11
- 230000008901 benefit Effects 0.000 description 9
- 238000009826 distribution Methods 0.000 description 9
- 238000009877 rendering Methods 0.000 description 9
- 238000013507 mapping Methods 0.000 description 8
- 230000002829 reductive effect Effects 0.000 description 8
- 230000008569 process Effects 0.000 description 7
- 230000009466 transformation Effects 0.000 description 6
- 241000282376 Panthera tigris Species 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 5
- 230000000694 effects Effects 0.000 description 5
- 239000011159 matrix material Substances 0.000 description 4
- 230000009467 reduction Effects 0.000 description 4
- 238000012546 transfer Methods 0.000 description 4
- 230000000007 visual effect Effects 0.000 description 4
- 238000013459 approach Methods 0.000 description 3
- 238000011960 computer-aided design Methods 0.000 description 3
- 238000012360 testing method Methods 0.000 description 3
- 230000001133 acceleration Effects 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 2
- 238000006243 chemical reaction Methods 0.000 description 2
- 230000000295 complement effect Effects 0.000 description 2
- 239000002131 composite material Substances 0.000 description 2
- 238000013144 data compression Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 230000010076 replication Effects 0.000 description 2
- 238000000844 transformation Methods 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 101100284258 Euplotes crassus H2B2 gene Proteins 0.000 description 1
- 241000238631 Hexapoda Species 0.000 description 1
- 241000406668 Loxodonta cyclotis Species 0.000 description 1
- 101100338264 Saccharomyces cerevisiae (strain ATCC 204508 / S288c) HTB2 gene Proteins 0.000 description 1
- 241000271897 Viperidae Species 0.000 description 1
- 238000007792 addition Methods 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000000052 comparative effect Effects 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000006073 displacement reaction Methods 0.000 description 1
- 238000002474 experimental method Methods 0.000 description 1
- QUSSPXNPULRXKG-UHFFFAOYSA-N galleon Natural products O1C(=CC=2)C(OC)=CC=2CCCCC(=O)CCC2=CC=C(O)C1=C2 QUSSPXNPULRXKG-UHFFFAOYSA-N 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 230000001788 irregular Effects 0.000 description 1
- 230000009191 jumping Effects 0.000 description 1
- 239000004579 marble Substances 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000010606 normalization Methods 0.000 description 1
- 238000010422 painting Methods 0.000 description 1
- 230000036961 partial effect Effects 0.000 description 1
- 239000002245 particle Substances 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000010937 topological data analysis Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T9/00—Image coding
- G06T9/001—Model-based coding, e.g. wire frame
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Image Generation (AREA)
- Compression, Expansion, Code Conversion, And Decoders (AREA)
- Processing Or Creating Images (AREA)
- Apparatus For Radiation Diagnosis (AREA)
Description
- Die vorliegende Erfindung betrifft im allgemeinen die Komprimierung von dreidimensionalen graphischen Daten und insbesondere Verfahren und Vorrichtungen, die verlustbehaftete hohe Komprimierungsraten für die dreidimensionale Geometriekomprimierung zur Verfügung stellen.
- Moderne dreidimensionale Computergraphiken verwenden extensiv Geometrie, um dreidimensionale Objekte zu beschreiben, unter Verwendung einer Vielfalt von graphischen Darstellungstechniken. Computergraphiken finden eine breite Verwendung in Anwendungen, die von CAD-Programmen (rechnerunterstütztes Zeichnen und Konstruieren) bis zu Videospielen mit virtueller Realität reichen. Komplexe ebene Oberflächen von Objekten können prägnant dargestellt werden durch Abstraktionen von hohem Niveau, wie zum Beispiel ausgeschnittene, nicht gleichförmige rationale Splins ("NURBs"), und häufig kann eine detaillierte Oberflächengeometrie unter Verwendung von Texturabbildungen dargestellt werden. Das Hinzufügen von mehr Realismus erfordert jedoch unverarbeitete Geometrie, üblicherweise in der Form von Dreiecken. Position, Farbe und Normalenkomponenten dieser Dreiecke werden typischerweise als Gleitkommazahlen dargestellt, und das Beschreiben eines isolierten Dreiecks kann bis zu 100 Bytes Speicherplatz erfordern.
- Verständlicherweise ist ein erheblicher Raum notwendig für die Abspeicherung von dreidimensionalen Computergraphikobjekten, zum Beispiel auf einer Computerfestplatte oder einer CD-ROM (Nurlese-Speicher in Form einer kompakten Scheibe). In ähnlicher Weise ist eine beachtliche Zeit notwendig, die Übertragung solcher Objekte, zum Beispiel über ein Netzwerk oder von der Platte zu dem Hauptspeicher.
- Geometrische Kompression ist ein allgemeiner Platz-Zeit-Kompromiß und bietet bei jedem Niveau die Vorteile einer Speicher/Zwischenverbindungshierarchie. Ein ähnliches Systemproblem existiert für die Speicherung und Übertragung von zweidimensionalen Pixelbilden. Eine Vielzahl von mit Verlust behafteten und verlustfreien Komprimierungs- und Dekomprimierungstechniken wurden für zweidimensionale Pixelbilder entwickelt mit dem Resultat einer Verringerung des Speicherplatzes und der Übertragungszeit. Unglücklicherweise beinhaltet der Stand der Technik keine Komprimierungs-/Dekomprimierungstechniken, die für dreidimensionale Geometrie, die über die Polygonreduktionstechniken hinausgehen, geeignet sind. Die Dissertation mit dem Titel "Compressing the X Graphics Protocol" von John Danskin, Princeton University, 1994 beschreibt jedoch die Komprimierung für zweidimensionale Geometrie.
- Geeignete Komprimierung kann die Menge der Geometrie, die in dem schnellen Hauptspeicher eines Computersystems cachegespeichert oder gespeichert werden kann stark vergrößern.
- JP-A-07192146 betrifft ein Formdatenkomprimierungsverfahren. Es ist aus dem englischsprachigen Text des äquivalenten US-Patentes (US-5,740,281) zu entnehmen, daß das Verfahren von Fig. 4 dieses Dokumentes beinhaltet: (i) die Partitionierung der Formdaten in Gruppen (Schritt 32); (ii) das Auswählen eines Quantisierungskoordinatensystems für eine Gruppe von Merkmalspunkten, zum Beispiel kartesische Koordinaten, Zylinder- oder Kugelkoordinaten (Schritt 34); (iii) Auswählen einer Quantisierungspräzision (Schritt 35); (iv) Quantisierung der Merkmalspunkte und (v) Wiederholen dieser Schritte für Normalenvektoren (Schritt 38-41).
- In verteilten Netzwerkanwendungen kann die Komprimierung helfen, gemeinsam genutzte Anzeigeumgebungen mit virtueller Realität ("VR") durch starke Reduzierung der Übertragungszeit möglich zu machen.
- Das größte Softwarepaket für Maschinencomputer unterstütztes Design ("MCAD") und viele Pakete für die Animationsmodellierung verwenden konstruktive Sterometrie ("CSG") und Freiform-NURBS, um Geometrie zu konstruieren und darzustellen. Unter Verwendung solcher Techniken werden Regionen von ebenen Oberflächen mit einem hohen Detailgrad mit resultierenden ausgeschnittenen Polynomoberflächen dargestellt. Für die Hardwaredarstellung werden diese Oberflächen vor der Übertragung zu der Darstellungshardware typischerweise vorher mosaikartig in Dreiecke aufgeteilt unter Verwendung von Software. Solche vorherige mosaikartige Software-Darstellung wird sogar auf Hardware durchgeführt, die eine Form der NURBS Hardwaredarstellung unterstützt.
- Viele Vorteile, die mit der geometrischen SURBS-Darstellung verknüpft sind, sind jedoch mit anderen Aufgaben als die Echtzeitdarstellung verbunden. Diese Nichtdarstellungsaufgaben beinhalten die Repräsentation für die Bearbeitung, den Austausch und die physikalische Analyse, wie zum Beispiel die Simulation von turbulentem Fluß. Die genaue Darstellung von ausgeschnittenen Kurven für NURBS ist sehr datenintensiv und als Komprimierungstechnik können ausgeschnittene NURBS nicht viel kompakter sein als vorher mosaikförmig aufgeteilte Dreiecke, zumindest bei typischen Mosaikdarstellungsdichten. Schließlich werden nicht alle Objekte kompakt durch NURBS dargestellt. Obgleich viele mechanische Objekt, wie zum Beispiel Motorhauben von Automobilen und Jetturbinenschaufeln große, ebene Bereiche haben, bei denen NURBS-Darstellungen von Vorteil sein können, haben viele Objekte keine solchen Flächen und eignen sich nicht für solche Darstellungen. Während NURBS viele Anwendungen bei der Modellierung von Objekten haben, werden somit komprimierte Dreiecke für viele Klassen von Anwendungsobjekten weit kompakter sein.
- Die photorealistische Stapeldarstellung hat lange eine extensiven Gebrauch von Texturabbildungstechniken gemacht, um feine geometrische Details kompakt darzustellen. Solche Techniken können die Farbtexturabbildung, die Normalenbumpabbildung und Verrückungsabbildungen bzw. - zuordnungen beinhalten. Die Texturabbildung arbeitet recht gut bei großen Objekten in dem fernen Hintergrund, zum Beispiel Wolken am Himmel, Gebäuden in der Ferne. Bei näheren Abständen arbeiten Texturen am besten bei dreidimensionalen Objekten, die hauptsächlich flach sind, zum Beispiel Reklametafeln, Gemälde, Teppiche, Marmorwänden und dergleichen. Kürzlich hat die Darstellungshardware damit begonnen, Texturabbildung zu unterstützen und Maschinen für die Echtzeitdarstellung können ebenso diese Techniken anwenden.
- Texturabbildung führt jedoch zu einem wahrnehmbaren Qualitätsverlust für nahe Objekte, die nicht flach sind. Eine Teillösung ist das "Signboard" (Schild), bei dem ein texturiertes Polygon sich immer dreht, um zu dem Beobachter zu zeigen. Nahe Texturen werden jedoch einfach als flach wahrgenommen, wenn sie in Stereo gesehen werden, insbesondere in kopfverfolgtem VR-Stereo. In diesen Beispielen würde selbst eine Polygonaldarstellung eines nahen Objektes mit weniger Details, jedoch völlig dreidimensional, viel realistischer sein.
- Die polyedrische Darstellung von Geometrie wurde lange auf dem Gebiet der dreidimensionalen Rastercomputergraphik unterstützt. In dieser Darstellung wird eine willkürliche Geometrie ausgedrückt und spezifiziert typischerweise durch eine Liste von Eckpunkten bzw. Vertices, Kanten und Flächen. Wie von J. Foley et al. in "Computer Graphics: Principles and Practice", 2. Auflage, Addison-Wesley, 1990, bemerkt wurde, wurden solche Darstellungen als Flügel-Kantendatenstrukturen hauptsächlich konstruiert, um das Editieren der Geometrie während der Anzeige zu unterstützen. Reste dieser Darstellungen überleben heutzutage als Austauschformate, zum Beispiel Wellenfront- OBJ. Obgleich theoretisch kompakt, wird einige Kompaktheit geopfert für die Lesbarkeit durch Verwendung von ASCII-Datendarstellung in Austauschfiles. Unglücklicherweise können wenige, wenn überhaupt, welche dieser Formate direkt als Zeichen befehle zu der Darstellungshardware übermittelt werden.
- Eine andere historische Spur in solchen Formaten ist die Unterstützung von N-seitigen Polygonen, eine allgemeine Grundform, die frühe Darstellungshardware akzeptieren konnte. Schnellere Darstellungshardware vom heutige Tage unterstellt jedoch, daß alle Polygongeometrie in Dreiecke reduziert wird, bevor sie zu der Hardware übermittelt werden. Bei Polygonen mit mehr als drei Seiten kann nicht allgemein garantiert werden, daß sie entweder planar oder konvex sind. Wenn vier Seiten als Darstellungsgrundeinheit akzeptiert werden, ist zu akzeptieren, daß sie willkürlich in ein Dreieckspaar aufgespalten werden, bevor sie dargestellt werden.
- Moderne Graphiksprachen spezifizieren typischerweise binäre Formate für die Darstellung von Sammlungen von dreidimensionalen Dreiecken, üblicherweise als Anordnungen von Eckpunktdatenstrukturen. Somit sind PHIGS PLUS, PEX, XGL und vorgeschlagene Erweiterungen zu OpenGL von dieser Formatform und werden den Speicherplatz, der von der ausführbaren Geometrie eingenommen wird, definieren.
- Es ist im Stand der Technik bekannt, Dreiecke in "Zickzack" oder "Stern" Streifen zu isolieren oder zu verketten. Beispielsweise definieren Iris-GL, XGL und PEX 5.2 eine Form von generalisierten Dreiecksstreifen, die von einer zickzack- zu einer sternartigen Verkettung auf einer Eckpunkt per Eckpunkt Basis umschalten kann, jedoch auf Kosten eines zusätzlichen Kopfzeilenwortes (Header) je Eckpunkt in XGL und PEX. Ein Restartcode erlaubt mehrere getrennte Streifen aus Dreiecken innerhalb eines Arrays von Eckpunkten zu spezifizieren.
- In diesen Sprachen können alle Eckpunktkomponenten (Positionen, Farben, Normale) durch 32-Bit IEEE Gleitkommazahlen einfacher Genauigkeit und 64-Bit Zahlen doppelter Genauigkeit spezifiziert werden. Die XGL, IrisGL und OpenGL Formate stellen ebenso die 32-Bit Ganzzahlunterstützung zur Verfügung. Die IrisGL und OpenGL Formate unterstützen Eckpunktpositionskomponenteneingaben als 16-Bit Ganzzahlen und Normalen und Farben können irgendeine von diesen sein oder auch 8-Bit Komponenten. In der Praxis können Positionen, Farben und Normalen zu wesentlich geringer als 32-Bit quantisiert werden (IEEE Gleitkomma mit einfacher Präzision) mit geringem Verlust in der visuellen Qualität. Solch ein Bitabschälen kann in kommerzieller dreidimensionaler Graphikhardware verwendet werden, vorausgesetzt, daß eine geeignete numerische Analyseunterstützung vorhanden ist.
- Zusammenfassend besteht daher ein Bedarf für eine graphische Komprimierung, die dreidimensionale Dreiecke komprimieren kann, und deren Format direkt als Zeichenbefehle in die Darstellungshardware geleitet werden kann. Vorzugsweise sollte solch eine Komprimierung leicht implementierbar sein unter Verwendung von Echtzeithardware und sollte die Dekomprimierung unter Verwendung von Software oder Hardware erlauben.
- Aspekte der Erfindung sind in den begleitenden Patentansprüchen ausgeführt. Bevorzugte und weitere Merkmale der Erfindung sind in den abhängigen Ansprüchen ausgeführt.
- Gemäß einer Ausführungsform der vorliegenden Erfindung wird die Geometrie als erstes als generalisiertes Dreiecksgitter dargestellt, dessen Struktur es erlaubt, daß jedes Beispiel eines Eckpunktes in einem linearen Strom vorzugsweise einen Durchschnitt bzw. Mittelwert zwischen 1/3 Dreieck und 2 Dreiecken spezifiziert. Einzelne Positionen, Farben und Normalen werden quantisiert mit einer Komprimierung mit variabler Länge, die auf einzelne Positionen, Farben und Normalen angewendet wird. Quantisierte Werte sind mittels Deltakompression zwischen Nachbarn codiert, um Eckpunktdurchlaufordnungen zur Verfügung zu stellen, und Gitterpufferreferenzen werden erzeugt. Histogramme von Deltapositionen, Deltanormalen und Deltafarben werden erzeugt, nach denen Huffman- Anzeigercodes variabler Länge sowie auch Deltapositionen, Deltanormale und Deltafarben erzeugt werden. Der komprimierte Ausgangsbinärstrom beinhaltet die Ausgangs-Huffman-Tabelleninitialisierungen, geordnete Eckpunktdurchläufe, Ausgangsanzeiger und die Deltapositionen, Deltanormalen und Deltafarben.
- Die Dekomprimierung kehrt diesen Prozeß um. Der dekomprimierte Strom aus Dreiecksdaten kann dann zu einer traditionellen Darstellungspipeline geleitet werden, wo er in der vollen Gleitkommagenauigkeit verarbeitet werden kann, um danach angezeigt oder auf andere Weise verwendet werden zu können.
- Andere Merkmale und Vorteile der Erfindung werden deutlich anhand der folgenden Beschreibung, in der die bevorzugten Ausführungsformen beispielhaft in Verbindung mit den begleitenden Zeichnungen im Detail ausgeführt worden sind. Es zeigen:
- Fig. 1 zeigt ein generalisiertes Netzwerk, über das dreidimensionale Geometrie, die komprimiert wurde, übertragen werden kann und dekomprimiert werden kann für die Ansicht durch den Benutzer,
- Fig. 2 zeigt eine generalisierte Dreiecksgitterdatenstruktur und eine generalisierte Gitterpufferdarstellung der Oberflächengeometrie gemäß einer Ausführungsform der vorliegenden Erfindung,
- Fig. 3 stellt die sechsfache Vorzeichenbit- und die achtfache Oktantsymmetrie in einer Einheitskugel dar, die verwendet wird, um die achtundvierzigfache Reduktion in der Nachschlagtabellengröße zur Verfügung zu stellen, gemäß der vorliegenden Ausführungsform,
- Fig. 4A stellt ein Vertexkommando in einem Befehlssatz für die geometrische Komprimierung dar gemäß der vorliegenden Ausführungsform,
- Fig. 4B stellt ein Normalenkommando in einem Befehlssatz für die geometrische Komprimierung dar gemäß der vorliegenden Ausführungsform,
- Fig. 4C stellt ein Farbkommando in einem Befehlssatz für die geometrische Komprimierung dar gemäß der vorliegenden Ausführungsform,
- Fig. 4D stellt ein Gitterpufferreferenzkommando in einem Befehlssatz für die geometrische Komprimierung dar gemäß der vorliegenden Ausführungsform,
- Fig. 4E stellt einen Zustandseinstellbefehl in einem Befehlssatz für die geometrische Komprimierung dar gemäß der vorliegenden Ausführungsform,
- Fig. 4F stellt einen Tabelleneinstellkommandobefehl in einem Befehlssatz für die geometrische Komprimierung dar gemäß der vorliegenden Ausführungsform,
- Fig. 4G stellt einen Durchleitkommandobefehl in einem Befehlssatz für die geometrische Komprimierung dar gemäß der vorliegenden Ausführungsform,
- Fig. 4H stellt einen No-Op-Kommandobefehl variabler Länge in einem Befehlssatz für die geometrische Komprimierung dar gemäß der vorliegenden Ausführungsform,
- Fig. 4I stellt eine Anzeiger- und Deltapositionsdatenstruktur dar gemäß der vorliegenden Ausführungsform,
- Fig. 4J-1 und 4J-2 stellen alternative Anzeiger- und Delta-Normaldatenstrukturen dar gemäß der vorliegenden Ausführungsform,
- Fig. 4K stellt eine Anzeiger- und Delta-Farbendatenstruktur dar gemäß der vorliegenden Ausführungsform,
- Fig. 5 ist ein Flußdiagramm mit Verfahrensschritten in einem geometrischen Komprimierungsalgorithmus gemäß der vorliegenden Ausführungsform,
- Fig. 6 ist ein Blockdiagramm einer Dekomprimierungshardware, die für die Verwendung mit der vorliegenden Erfindung geeignet ist,
- Fig. 7A-7L stellen Objekte dar, die unter unterschiedlichen Bedingungen mit der vorliegenden Ausführungsform komprimiert wurden,
- Fig. 8 ist ein detailliertes Gesamtblockdiagramm einer Dekomprimierungseinheit, die für die Dekomprimierung von Daten geeignet ist, die entsprechend einer Ausführungsform der vorliegenden Erfindung komprimiert wurden,
- Fig. 9 ist ein detailliertes Blockdiagramm des Eingangsblockes, der in Fig. 8 gezeigt ist,
- Fig. 10 ist ein detailliertes Blockdiagramm der Barrelschiebereinheit, die in Fig. 8 gezeigt ist,
- Fig. 11 ist ein detailliertes Blockdiagramm der Positions-/Farbverarbeitungseinheit, die in Fig. 8 gezeigt ist,
- Fig. 12A ist ein detailliertes Blockdiagramm der Normalen-Prozessoreinheit, die in Fig. 8 gezeigt ist,
- Fig. 12B ist ein detailliertes Blockdiagramm, das die Decoder-, Falt- und ROM-Nachschlagkomponenten zeigt, die mit der Normalen-Prozessoreinheit von Fig. 12A verbunden sind,
- Fig. 13 ist ein Blockdiagramm, das die Schnittstellen zu einem Gitterpuffer zeigt, wie in Fig. 11 und/oder Fig. 12A gezeigt ist,
- Fig. 14A stellt Schnittstellen zu Huffman-Tabellen dar,
- Fig. 14B stellt ein bevorzugtes Format für den Eintrag der Huffman-Tabellendaten dar,
- Fig. 15A stellt einen Vertexbefehl dar,
- Fig. 15B stellt Datenformate für Punktkomponenten dar,
- Fig. 15C stellt das Format für den Normaleneinstellbefehl dar,
- Fig. 15D stellt den Farbeinstellbefehl dar,
- Fig. 15E stellt den Befehl für die Gitterpufferreferenz dar,
- Fig. 15F stellt einen Zustandseinstellbefehl dar,
- Fig. 15G stellt einen Tabelleneinstellbefehl dar,
- Fig. 15H stellt einen Durchlaßbefehl dar,
- Fig. 15I stellt einen NOP-Befehl variabler Länge dar und
- Fig. 15J stellt einen Sprungbefehl 8 dar.
- Ein Graphikkomprimierer gemäß einer Ausführungsform der vorliegenden Erfindung kann verwendet werden, um den Platz zu reduzieren, der benötigt wird, um dreidimensionale graphische Objekte zu speichern, zum Beispiel auf einer CD-ROM oder dergleichen, sowie auch um die Zeit zu reduzieren, die benötigt wird, um ein komprimiertes dreidimensionales graphisches Objekt beispielweise über ein Netzwerk zu übertragen. Bevor die dreidimensionale Graphikkomprimierung an sich beschrieben wird, wird die Gesamtumgebung, in der die vorliegende Erfindung ausgeführt werden kann, unter Bezug auf Fig. 1 beschrieben.
- Fig. 1 stellt ein generalisiertes Netzwerk dar, mit dem dreidimensionale Komprimierung gemäß der vorliegenden Erfindung mit Vorteil verwendet werden kann, um Speicherplatz zu verringern und die Zeit zu verringern, um komprimierte dreidimensionale graphische Objekte zu übertragen. Selbstverständlich könnte die dreidimensionale Graphikkomprimierung gemäß der vorliegenden Erfindung ebenso in anderen Umgebungen verwendet werden, zum Beispiel um die Anforderungen, um dreidimensionale Graphiken auf CD-ROMs zu speichern, zu reduzieren, um Daten in Echtzeit zu komprimieren, beispielsweise in einer interaktiven Fernsehumgebung.
- Wie in Fig. 1 gezeigt ist, kann eine Quelle von dreidimensionalen graphischen Daten 10 mit einem Server oder Codierersystem 20 verbunden sein, dessen verarbeiteter und komprimierter Ausgang über ein oder mehrere Netzwerke 30 mit einem oder mehreren Zielclients oder Decodersystemen 40 verbunden ist. Das Netzwerk kann homogen, heterogen oder punkt-zu-punktförmig sein.
- Der Server 20 beinhaltet eine zentrale Verarbeitungseinheit 50, die die zentrale Prozessoreinheit an sich ("CPU") 60 mit verknüpftem Hauptspeicher 70, einem Gitterpuffer 80, einem Speicherabschnitt 90, der vorzugsweise einen Algorithmus enthält, der verwendet wird, um die Komprimierung gemäß der vorliegenden Erfindung zu implementieren, und einem Bereich von Nurlesespeicher ("ROM") 100. Die Komprimierung gemäß der vorliegenden Erfindung kann teilweise oder insgesamt in der Hardware im Gegensatz zu der Software ausgeführt werden.
- Der Server 20 beinhaltet ebenso eine dreidimensionale graphische Komprimierungseinheit 60, deren komprimierte Ausgangsdaten durch eine Disk-Layout-Einheit 70 für das Ablegen auf der Ablageplatteneinheit 80 angeordnet ist, die ein oder mehrere CD-ROMs beinhalten kann. Der Server kommuniziert über das Netzwerk (die Netzwerke) 30 über eine Netzwerkinterfaceeinheit 110. Fachleute werden erkennen, daß der Server 20 einen Mechanismus beinhalten kann für die Vermittlung zwischen einer Mehrzahl von Client-Decoderanfragen für komprimierte Daten.
- Es versteht sich, daß die komprimierten dreidimensionalen Graphikdaten auf der Videodisk oder CD-ROM 80 nicht über ein Netzwerk übertragen werden müssen. Die Disk oder CD-ROM 80 kann beispielsweise zu einem Benutzer Verschicht werden, der wünscht auf die hierauf abgelegten kom primierten dreidimensionalen Graphikinformationen zuzugreifen. Wenn sie jedoch beispielsweise über ein Netzwerk übertragen werden, wird die Übertragungszeit in vorteilhafter Weise reduziert, da die Komprimierung die Bitgröße des zu übertragenden Files wesentlich reduziert. Die verlustbehaftete Komprimierung von dreidimensionalen geometrischen Daten gemäß der vorliegenden Erfindung kann Verhältnisse von 6 : 1 bis 10 : 1 erzeugen mit einem geringen Verlust in der angezeigten Objektqualität. Weiterhin solch eine Komprimierung zu relativ geringen Kosten in dreidimensionale Darstellungsechtzeithardware eingefügt werden oder kann statt dessen implementiert werden unter Verwendung von ausschließlich Softwaretechniken.
- In einer Netzwerkumgebung beinhaltet das Decodersystem (die Decodersysteme) 40 an dem Empfangsende ein Zentralverarbeitungssystem 150, das eine CPU 160, Speicher 170, wovon ein Abschnitt 180 die Dekomprimierungssoftware enthalten kann, und ROM 190 beinhaltet. Dreidimensionale Graphiken, die mit einer Ausführungsform der vorliegenden Erfindung komprimiert wurden, können unter Verwendung von Software, Hardware oder einer Kombination hieraus mit Vorteil dekomprimiert werden.
- Der Decoder 40 beinhaltet weiterhin eine Netzwerkschnittstelleneinheit 120, eine Einheit 130, die dreidimensionale Graphikdaten dekomprimiert, und deren Ausgang mit einer dreidimensionalen Graphikdarstellungseinheit 140 verbunden ist. Das (die) somit dekomprimierten dreidimensionalen Graphikbild(er) kann (können) dann mit einem Viewer 200 gekoppelt sein oder mit einem anderen System, das die dekomprimierten Graphiken erfordert. Natürlich kann die Einheit 40 eine Einzeleinheit sein, in die die dreidimensionalen Graphikdaten, die gemäß einer Ausführungsform der vorliegenden Erfindung vorkomprimiert wurden, für die Dekomprimierung eingekoppelt werden können. Die Einheit 40 kann beispielsweise einen Computer oder eine Workstation umfassen.
- Die Patentanmeldung EP-A-0 757 333 des Anmelders, die an demselben Tag wie die vorliegende Anmeldung eingereicht wurde, mit dem Titel "Method and Apparatus for Decompression of compressed geometric three-dimensional Graphics Data" zeigt ein bevorzugtes Verfahren und System für die Dekomprimierung von Daten, die gemäß einer Ausführungsform der vorliegenden Erfindung komprimiert wurden. Die Dekomprimierung kann mit Hilfe eines Software implementierten Dekompressionsalgorithmus implementiert werden, obgleich die Dekomprimierung ebenso teilweise oder vollständig mittels Hardware implementiert werden könnte.
- Der Betrieb der dreidimensionalen Graphikkomprimierungseinheit 60 wird nun beschrieben. In der vorliegenden Ausführungsform wandelt die erste Stufe der geometrischen Komprimierung Dreiecksdaten in eine effiziente lineare Streifenform, nämlich ein generalisiertes Dreiecksgitter um. Für eine gegebene feste Kapazität des Speichermediums 80, ist eine Dreiecksgitterdatenstruktur eine nahezu optimale Darstellung von Dreiecksdaten. In der Ausführungsform können dreidimensionale graphische Objekte als dreidimensionale Dreiecksdaten dargestellt werden, deren Format nach der Umwandlung veranlaßt, daß jeder lineare Streifenvertex im Mittel zwischen etwa 1/3 Dreiecke bis etwa 2 Dreiecke spezifiziert.
- Weiterhin erlaubt eine generalisierte Dreiecksstreifenstruktur die kompakte Darstellung der Geometrie, während eine lineare Datenstruktur beibehalten wird. Anders ausgedrückt, kann die komprimierte Geometrie durch einen einzelnen monotonen Scan über die Vertexarraydatenstruktur extrahiert werden. Dieses Merkmal ist von Vorteil für Hardwareimplementierungen mit Pipeline.
- Fig. 2 stellt eine generalisierte Dreiecksgitterdatenstruktur und eine generalisierte Gitterpufferdarstellung der Oberflächengeometrie dar. Solch eine Gitterdatenstruktur kann verwendet werden bei der dreidimensionalen geometrischen Komprimierung, obgleich durch das Sichbeschränken auf lineare Streifen ein generalisiertes Dreiecksstreifenformat einen möglichen Faktor von zwei im Platzbedarf verschwendet. Die in Fig. 2 gezeigte Geometrie kann beispielsweise durch einen Dreiecksstreifen repräsentiert werden, jedoch werden viele innere Eckpunkte zweimal in dem Streifen erscheinen.
- In Fig. 2 kann ein generalisierter Dreiecksstreifen wie folgt definiert werden, wobei R Restart bezeichnet, O ersetze Ältesten bezeichnet, M ersetze Mittleren bezeichnet und ein führender Buchstabe P das Schieben in dem Gitterpuffer bezeichnet. Die Zahl, die einem Großbuchstaben folgt, ist eine Eckpunktnummer und eine negative Zahl ist die Gitterpufferreferenz, in der -1 den zuletzt verschobenen Eckpunkt bezeichnet.
- R6, O1, O7, O2, O3, M4, M8, O5, O9, O10, M11
- M17, M16, M9, O15, O8, O7, M14, O13, M6,
- O12, M18, M19, M20, M14, O21, O15, O22, O16,
- O23, O17, O24, M30, M29, M28, M22, O21, M20,
- M27, O26, M19, O25, O18
- Unter Verwendung derselben Nomenklatur kann ein generalisiertes Dreiecksgitter wie folgt definiert werden:
- R6p, O1, O7p, O2, O3, M4, M8p, O5, O9p, O10,
- M11, M17p, M16p, M-3, O15p, O-5, O6, M14p,
- O13p, M9, O12, M18p, M19p, M20p, M-5, O21p, O-7, O22p, O-9, O23, O-10,
- O-7, M30, M29, M28, M-1, O-2, M-3, M27, O26, M-4, O25, O-5
- Es wird bemerkt, daß eine Vertexreferenz mit Vorteil beachtlich kompakter (zum Beispiel durch weniger Bits dargestellt werden) als eine vollständige Vertexspezifikation sein kann.
- Die geometrische Komprimierung gemäß der Erfindung verschiebt explizit alte Eckpunkte (zum Beispiel Eckpunkte mit einem führenden Buchstaben "p" wie oben) in eine Warteschlange, die mit dem Gitterpufferspeicher 80 verknüpft ist (siehe Fig. 1). Auf diese alten Eckpunkte wird später explizit Bezug genommen, wenn der alte Eckpunkt wieder gewünscht ist. Dieser Ansatz stellt eine Feinkontrolle zur Verfügung, die irreguläre Gitter von nahezu jeder Form unterstützt. Der Pufferspeicher 80 hat in der Praxis eine endliche Länge und in der bevorzugten Ausführungsform wird eine maximale feste Warteschlangenlänge von 16 verwendet, was einen 4-Bit-Index erfordert. Der Begriff "Gitterpuffer", wie er hier verwendet wird, soll sich auf diese Warteschlange beziehen und der Ausdruck "generalisiertes Dreiecksgitter" bezieht sich auf eine Kombination von generalisierten Dreiecksstreifen und Gitterpufferreferenzen.
- Die feste Größe des Gitterpuffers 80 erfordert, daß alle Tesselatoren(Mosaikerzeuger)/Re-Strippers für komprimierte Geometrie, alle Läufe, die länger als sechzehn eindeutige Bezugnahmen sind, abbrechen. Da Geometriekomprimierung typischerweise nicht direkt auf dem Benutzerniveau programmiert wird, sondern immer durch hochentwickelte Tesselatoren/Neuformatierer, ist dies jedoch keine schwerwiegende Beschränkung. Sechzehn alte Eckpunkte können tatsächlich erlauben, daß die Respezifizierung von bis zu etwa 94% der redundanten Geometrie verhindert wird.
- Fig. 2 ist ebenso ein Beispiel einer allgemeinen Gitterpufferdarstellung der Oberflächengeometrie. Die geometrische Komprimierungssprache unterstützt die vier Eckpunktersetzungscodes der generalisierten Dreiecksstreifen, nämlich: ersetze ältester, ersetze mittlerster, restart im Uhrzeigersinn und restart entgegen dem Uhrzeigersinn. Weiterhin addiert die Sprache ein zusätzliches Bit in jede Eckpunktkopfzeile, um anzuzeigen, ob oder ob nicht dieses Vertex in den Gitterpufferspeicher verschoben werden sollte. In der bevorzugten Ausführungsform hat das Gitterpufferreferenzkommando ein 4-Bit-Feld, um anzuzeigen, auf welches altes Vertex erneut Bezug genommen werden sollte, zusammen mit den 2-Bit-Punktersetzungscodes. Gitterpufferreferenzkommandos enthalten kein Gitterpufferverschiebungsbit; alte Eckpunkte können nur einmal recycelt werden.
- In der Praxis bestehen Geometrien selten nur aus Positionsdaten. Im allgemeinen werden eine Normale und/oder eine Farbe und/oder Texturabbildungskoordinaten ebenso je Vertex spezifiziert. Dementsprechend enthalten in der bevorzugten Ausführungsform die Einträge in den Gitterpuffer 80 Speicher für alle verknüpften Informationen je Vertex, die ausdrücklich Normalen- und Farbe- und/oder Texturabbildungskoordinaten beinhalten.
- Für die maximale Speicherplatzeffizienz wird, wenn ein Vertex in den Datenstrom spezifiziert wird, die Normalen und/oder Farbinformation je Vertex vorzugsweise direkt mit der Positionsinformation gebündelt. Solche eine Bündelung wird vorzugsweise durch zwei Zustandbits gesteuert: Bündel von Normalen mit Vertices (BNV) und Bündel von Farben mit Vertices (BCV). Fig. 4E stellt eine Be fehlsstruktur dar, die unter anderem Bits aufweist. Wenn ein Vertex in den Gitterpuffer verschoben wird, steuern diese Bits, ob seine gebündelte Normale und/oder Farbe ebenso verschoben wird.
- Es sollte erwähnt werden, daß die Komprimierung gemäß der vorliegenden Erfindung nicht auf Dreiecke begrenzt ist und daß Vektoren und Punkte ebenso komprimiert werden können. Die Linien sind beispielsweise eine Untergruppe von Dreiecken, in denen die Ersetzungsbits MOVE und DRAW sind. Ein Ausgangsvertex ist dann ein Vertex, der einen Endpunkt einer Linie darstellt, deren anderer Vertex der unmittelbar zuvor ausgelassene Vertex ist. Für Punkte sind die Ersetzungsbits DRAW und ein Ausgangsvertex ist der Vertex.
- Wenn die CPU 52 ein Gitterpufferreferenzkommando ausführt, wird dieser Prozeß umgekehrt. D. h. die zwei Bits spezifizieren, ob eine Normale und/oder Farbe vererbt werden sollte oder von dem Gitterpufferspeicher 80 gelesen werden sollte oder von der gegenwärtigen Normale oder der gegenwärtigen Farbe erhalten werden sollte. Die Software 58 beinhaltet vorzugsweise explizite Befehle für das Einstellen dieser zwei gegenwärtigen Werte. Eine Ausnahme von dieser Regel existiert jedoch, wenn ein explizites "Setze gegenwärtige Normale"-Kommando von einer Gitterpufferreferenz gefolgt wird mit einem aktiven BNV-Zustandbit. In dieser Situation überschreibt letzteres die Gitterpuffernormale, um die kompakte Darstellung von harten Kanten in den Oberflächenfarben zu gestatten.
- Zwei zusätzliche Zustandbits steuern die Interpretation von Normalen und Farben, wenn der Strom aus Vertices in Dreiecke konvertiert wird. Ein Bit für die Replikation von Normalen über dem Dreieck (RNT) zeigt an, daß die Normale in dem Endvertex, das ein Dreieck komplettiert, über das gesamte Dreieck repliziert werden soll. Ein Bit für die Replikation von Farben über das Dreieck (RCT) wird analog definiert, wie in der Befehlsstruktur von Fig. 4E gezeigt ist.
- Die Komprimierung von xyz Positionen des Bildes wird nun beschrieben. Die Verwendung des 8- Bitexponenten, der mit dem 32-Bit IEEE Gleitkommazahlen verknüpft ist, erlaubt es, daß Positionen in der Größe von subatomaren Teilchen zu Milliarden von Lichtjahren reichen. Für irgendein gegebenes mosaikartig aufgeteiltes Objekt wird jedoch der Exponent tatsächlich nur einmal durch eine gegenwärtige Modelliermatrix spezifiziert und die Objektgeometrie wird effektiv innerhalb eines gegebenen Modellraumes beschrieben unter Verwendung nur einer 24-Bit-Festpunktmantisse. In vielen Fällen werden weit weniger Bits für die visuelle Aufnahme benötigt. Somit unterstützt die geometrische Komprimierungssprache der Anmelderin die variable Quantisierung von Positionsdaten bis hinunter auf 1 Bit.
- Im anderen System haben empirische visuelle Test sowie auch Betrachtungen von Halbleiterhardwareimplementierung angezeigt, daß nicht mehr als 16-Bit Präzision pro Positionskomponente für nahezu alle Fälle notwendig ist.
- Angenommen, daß jedoch die Position und Skalierung des lokalen Modellraumes je Objekt durch volle 32 Bit oder 64 Bit Gleitkommakoordinaten spezifiziert werden. Unter Verwendung von ausreichender numerischer Sorgfalt können mehrere solcher Modellräume zusammen kombiniert werden, um nahtlose geometrische Koordinatensysteme zu bilden mit einer positionalen Präzision von viel größer als 16 Bit.
- Die meiste Geometrie ist lokal. Somit ist innerhalb eines 16 Bit (oder weniger) Modellraumes für jedes Objekt die Differenz (Δ) zwischen benachbarten Vertices in dem generalisierten Gitterpufferstrom wahrscheinlich geringer als 16 Bit in der Signifikanz. Wenn gewünscht, kann man ein Histogramm konstruieren, das die Bitlängen von benachbarten Positions-Δ's in einer Geometriedatenseite darstellt und basierend auf diesem Histogramm einen variablen Längencode zuweisen, um die Vertices kompakt darzustellen. Wie beschrieben werden wird, wird vorzugsweise angepaßte Huffman-Codierung verwendet, um die positionalen Δ's in der Geometriekomprimierung zu codieren.
- Die Komprimierung von rot-blau-grün-alpha ("RGBA") Farben wird nun beschrieben. Farbdaten werden in ähnlicher Weise behandelt wie Positionen, jedoch mit einer kleineren maximalen Genauigkeit. Somit werden RGBα Farbdaten zuerst in 12-Bit-Bruchteilkomponenten ohne Vorzeichen quantisiert, die absolute lineare Reflektivitätswerte sind (in denen 1,0 100% Reflektivität darstellt). Ein zusätzlicher Parameter erlaubt es, daß Farbdaten effektiv quantisiert werden auf irgendeine Größe von weniger als 12-Bit. Beispielsweise können Farben alle innerhalb eines 5-5-5 RGB Farbraumes sein, wie in Fig. 4C gezeigt ist. Das optionale α-Feld wird gesteuert durch ein Color-α-Present- Zustandsbit ("CAP") gesteuert, das in Fig. 4E gezeigt ist. Auf dem endgültig dargestellten Bild werden einzelne Pixelfarben immer noch zwischen den quantisierten Vertexfarben interpoliert und sind typischerweise auch dem Lighting bzw. Beleuchten ausgesetzt.
- Als Ausführungsentscheidung wurde entschieden, dieselbe Δ-Codierung für die Farbkomponenten und für Positionen zu verwenden. Das Gebiet der Farbdatenkomprimierung ist dort, wo geometrische Komprimierung und traditionelle Bildkomprimierung auf die einfachsten Probleme treffen. Viele fortgeschrittene Bildkomprimierungstechniken werden jedoch für die geometrische Farbkomprimierung, aufgrund der Differenz in der Brennweite, vermieden.
- Beispielsweise verläßt sich der JPEG-Bildkomprimierungsstandard auf Annahmen über die Ansicht der dekomprimierten Daten, die für die geometrische Komprimierung nicht gemacht werden können. Beispielsweise ist in einer Bildkomprimierung vorher bekannt, daß die Pixel in einer perfekt rechtwinkligen Anordnung erscheinen und daß, wenn sie betrachtete werden, jedes Pixel einen schmalen Bereich von Sehwinkeln schneidet. Im Gegensatz dazu ist bei der geometrischen Komprimierung die Verbindung zwischen dem Betrachter und der gerasterten Geometrie nicht vorhersehbar.
- Es ist bei der Bildkomprimierung bekannt, daß die Raumfrequenz der auf dem Auge des Betrachters dargestellten Pixel wahrscheinlich größer ist als die Farbsehschärfe des menschlichen visuellen System. Aus diesem Grund werden Farben im allgemeinen in den YUV-Raum umgewandelt, so daß die UV-Farbkomponenten mit einer niedrigeren Raumfrequenz dargestellt werden können als die Y (Intensität)-Komponente. Üblicherweise werden digitale Bits, die subgesampelte UV-Komponenten darstellen, auf zwei oder mehrere Pixel aufgeteilt. Die geometrische Komprimierung kann jedoch hiervon nicht profitieren, da es keine feste Anzeigeskalierung der Geometrie relativ zu dem Auge des Betrachters gibt. Weiterhin gibt es, wenn komprimierte Dreiecksvertices mit vier bis acht oder mehreren anderen Vertices in dem generalisierten Dreiecksgitter verbunden sind, keinen konsistenten Weg des Teiles der "Hälfte" der Farbinformation über die Vertices.
- Ähnliche Argumente treffen auf die raffinierteren Transformationen zu, die in der traditionellen Bildkomprimierung verwendet werden, wie zum Beispiel die diskrete Kosinustransformation. Diese Transformationen nehmen eine reguläre (rechtwinklige) Abfrage von Pixelwerten an und erfordern eine große Menge von wahlfreiem Zugriff während der Dekomprimierung.
- Es ist im Stand der Technik bekannt, Pseudofarbennachschlagtabellen zu verwenden, solche Tabellen würden jedoch eine feste maximale Größe erfordern und würden eine relativ teure Resource für die Echtzeitverarbeitung darstellen. Während Pseudofarbindizes zu einem leicht höheren Komprimierungsverhältnis für bestimmte Szenen führen könnten, ist das RGB-Modell generalisierter und beachtlich kostengünstiger zu implementieren.
- In dem RGB-Modell, das in der vorliegenden Ausführungsform verwendet wird, werden RGB-Werte als lineare Reflexionswerte dargestellt. Wenn alle Effekte des Lightings bzw. des Beleuchtens vorher bekannt wären, könnten theoretisch ein oder zwei Darstellungsbits fallen gelassen werden, wenn die RGB-Komponenten in einem nicht-linearen oder einem wahrnehmbar linearen Raum (manchmal auch als gammakorrigierter Raum bezeichnet) dargestellt worden wären. In der Praxis tendieren die Belichtungseffekte dazu, nicht vorhersagbar zu sein, und die Umwandlung während der Übertragung von dem nicht-linearen Licht zu dem linearen Licht würde beachtliche Hardwareresourcen erfordern.
- Die Komprimierung von Oberflächennormalen wird nun beschrieben. Traditionell wurden 96-Bit- Normalen (drei 32-Bit IEEE Gleitkommazahlen) verwendet bei den Berechnungen, um 8-Bit- Farbintensitäten zu bestimmen. Theoretisch könnten 96 Bits von Information verwendet werden, um 2&sup9;&sup6; unterschiedliche Normalen darzustellen, die gleichmäßig über die Oberfläche einer Einheitskugel verteilt sind. Die resultierende extrem hohe Genauigkeit stellt eine Normale dar, die sich in alle Richtungen alle 2&supmin;&sup4;&sup6; Radiant erstreckt.
- Jedoch sind für IEEE gleitkommanormalisierte Normalen die Exponentenbits effektiv unbenutzt. Unter der Nebenbedingung Nx² + Ny² + Nz² = 1 muß zumindest Nx, Ny oder Nz in dem Bereich von 0,5 bis 1,0 sein. Während der Darstellung wird diese Normale durch eine zusammengesetzte Modellorientierungsmatrix transformiert:
- N'x = Nx·T0,0 + Ny·T0,1 + Nz·T0,2
- N'y = Nx·T1,0 + Ny·T1,1 + Nz·T1,2
- N'z = Nx·T2,0 + Ny·T2,1 + Nz·T2,2
- Unter der Annahme einer typischen Implementierung, in der das Lighting in Weltkoordinaten durchgeführt wird, ist die Sichttransformation nicht in der Verarbeitung von Normalen involviert. Wenn die Normalen vorher normalisiert wurden, wird, um die redundante Renormalisierung der Normale zu verhindern, die zusammengesetzte Modelltransformationsmatrix T typischerweise vorher normalisiert, um jede Skalierungsveränderung herauszuteilen. Somit ist:
- T²0,0 + T²1,0 + T²2,0 = 1, usw.
- Während der Normaltransformation schneidet die Gleitkommaarithmetikhardware effektiv alle zusätzlichen Argumente auf die Genauigkeit der größten Komponente ab. Das Ergebnis ist, das für eine normalisierte Normale, die eine Transformation durch eine Skalierung, die die Modellorientierungsmatrix beibehält, erfährt, die numerische Genauigkeit des transformierten Normalwertes in allen außer ein paar speziellen Fällen auf nicht mehr als eine 24-Bit Festpunktgenauigkeit reduziert wird.
- Zum Vergleich würden selbst 24 Bit Normalkomponenten immer noch eine höhere Winkelgenäuigkeit zur Verfügung stellen als das reparierte Hubble-Weltraumteleskop. In der Praxis werden manche Systeme verwendet, die nur 16 Bit-Normalkomponenten verwenden. In empirischen Tests mit 16-Bit Normalkomponenten hat die Anmelderin bestimmt, daß Ergebnisse von einer Winkeldichte von 0,01 Radianten zwischen den Normalen visuell nicht von feineren Darstellungen unterscheidbar waren. Dies waren etwa 100.000 über eine Einheitskugel verteilte Normalen. Im geradlinigen Raum erfordern diese Normalen immer noch eine höhere Darstellungsgenauigkeit und in der Praxis werden 16 Bit Komponenten, die ein Vorzeichenbit und ein Schutzbit beinhalten, ausgewählt. Dies erfordert immer noch 48 Bits, um eine Normale darzustellen, da jedoch nur 100000 spezifische Normalen von Interesse sind, könnte theoretisch ein einzelner 17 Bit-Index jede dieser Normalen symbolisieren.
- Die Verwendung von Normalen als Indizes und die zur Verfügung gestellten resultierenden Vorteile werden nun beschrieben. Ein Verfahren der Umwandlung eines Indexes einer Normalen auf der Einheitskugel zurück in einen Nx, Ny, Nz-Wert erfolgt mit einer Nachschlagtabelle, wobei die Tabelle vielleicht in den Speicher 70 geladen wird. Obgleich die Tabellengröße potentiell groß ist, kann die notwendige Größe wesentlich reduziert werden durch Ausnutzen einer 48-fachen Symmetrie, die in der Einheitskugel präsent ist.
- Genauer gesagt ist, wie in der Fig. 3 gezeigt ist, die Einheitskugel bis auf die Vorzeichenbits in den acht Quadranten symmetrisch. Durch Zulassen, daß drei der Normalen-Darstellungsbits die drei Vorzeichenbits der XYZ-Komponenten einer Normalen sind, ist es nur notwendig, ein Achtel der Einheitskugel darzustellen.
- Wie in Fig. 3 gezeigt ist, kann jeder Oktant der Einheitskugel kann in sechs identische Komponenten aufgeteilt werden durch Falten um die Ebenen X = Y, X = Z und Y = Z. Die sechs möglichen Sextanten werden mit weiteren drei Bits codiert, so daß nur noch 1/48 der Kugel darzustellen ist.
- Die Verwendung der oben erwähnten Symmetrie reduziert die Größe der Nachschlagtabelle um einen Faktor von 8 · 6 = 48. Anstelle des Abiegens von 100.000 Einträgen muß die Nachschlagtabelle nur etwa 2.000 Einträge ablegen, was eine Größe ist, die klein genug ist, um auf einer On-Chip ROM-Nachschlagtabelle zu sein, die vielleicht innerhalb des ROM 59 abgelegt ist (siehe Fig. 1). Die Indexierung in der Nachschlagtabelle erfordert 11 Adreßbits, die, wenn sie zu den vorher beschriebenen zwei 3-Bitfeldern addiert werden, zu einem 17-Bitfeld führt, um alle drei Normalkomponenten zu beschreiben.
- Das Darstellen eines endlichen Satz von Einheitsnormalen ist äquivalent zu der Positionierung von Punkten auf der Oberfläche der Einheitskugel. Obgleich keine perfekt gleiche Winkeldichteverteilung für eine große Anzahl von Punkten existiert, gibt es viele nahezu optimale Verteilungen. Ein Verteilung, die den oben beschriebenen Typ der 48-fachen Symmetrie hat, könnte theoretisch für die Dekompressionsnachschlagtabelle verwendet werden, die mit der dreidimensionalen Geometriedekomprimierungseinheit 130 verknüpft ist (siehe Fig. 1).
- Verschiedene zusätzliche Beschränkungen erfordern jedoch eine andere Wahl der Codierung. Als erstes wird eine skalierbare Dichteverteilung gewünscht, zum Beispiel eine Verteilung, in der das Einstellen von mehr Adreßbits niedriger Ordnung auf "null" in der Nachschlagtabelle immer noch zu einer ziemlich gleichmäßigen Normaldichte auf der Einheitskugel führt. Anderenfalls würde für jede Codierungsdichte ein unterschiedliche Nachschlagtabelle notwendig sein. Zweitens ist eine Δ- codierbare Verteilung gewünscht, in der in der Geometrie statistisch benachbarte Vertices Normalen haben, die nahe beieinander auf der Oberfläche der Einheitssphäre sind. Nahe gelegene Orte auf dem zweidimensionalen Raum der Einheitskugeloberfläche sind meistens kurz und bündig durch einen zweidimensionalen Offset codiert. Es ist wünschenswert, eine Verteilung zu haben, in der solch eine Metrik existiert. Schließlich sind, obgleich Berechnungskosten, die mit dem normalen Codierprozeß verknüpft sind, nicht von entscheidender Wichtigkeit sind, Verteilungen mit niedrigeren Codierungskosten immer noch bevorzugt.
- Aus diesen Gründen verwendet die Ausführungsform eine Verteilung mit einem regulären Gitter in dem Winkelraum innerhalb eines Sextanten der Einheitskugel. Als solches werden alle Normalen innerhalb eines Sextanten mit Vorteil anstatt durch einen monolithischen 11-Bit-Index mit zwei orthogonalen 6-Bit-Winkeladressen dargestellt. Diese Konfiguration revidiert dann die vorherige Bitsumme auf 18-Bits. Wie dies für Positionen und Farben der Fall war, können, wenn eine stärkere Quantisierung der Normalen akzeptierbar ist, diese 6-Bit-Indices auf weniger Bits reduziert werden und somit können absolute Normalen unter Verwendung von irgendeiner Zahl von 18 bis hinunter zu 6-Bit dargestellt werden. Wie oben beschrieben wurde, ist dieser Raum vorzugsweise Δ-codiert, um die Anzahl von Bits, die für die Hochqualitätsdarstellung der Normalen erforderlich ist, weiter zu reduzieren.
- Nun wird die Parametisierung der Normalencodierungsparametrisierung beschrieben. Punkte auf einer Einheitskugel werden parametrisiert unter Verwendung von Kugelkoordinaten der Winkel θ und Φ, wobei θ der Winkel um die Y-Achse und Φ der Längswinkel von der Y = 0 Ebene ist. Die Gleichung (1) regelt die Abbildung zwischen rechtwinkligen und Kugelkoordinaten wie folgt:
- x = cosθ·cosΦ y = sinΦ z = sinθ·cosΦ (1)
- Punkte auf der Kugel werden als erstes durch den Oktanten gefaltet und dann durch die Sortierungsordnung von xyz in einem der sechs Sextanten gefaltet. Jegliche Tabellencodierung erfolgt in dem positiven Oktanten in dem Bereich, der von den Halbräumen begrenzt ist:
- x ≥ z z ≥ y y ≥ 0
- Wie in Fig. 3 gezeigt ist, läuft der beschriebene dreieckförmige Ausschnitt von 0 bis π/4 Radiant in θ und von 0 bis zu einem Maximum von 0,6154709 Radiant in Φ.
- Quantisierte Winkel werden durch zwei n-Bit-Ganzzahlen n und n dargestellt, wobei n in dem Bereich zwischen 0 bis 6 liegt. Für ein gegebenes n lautet die Beziehung zwischen den Indizes θ und Φ
- Die Gleichungen (2) zeigen wie Werte von n und n in Kugelkoordinaten θ und Φ umgewandelt werden können, die wiederum in geradlinige Normalkoordinatenkomponenten über die Gleichung (1) umgewandelt werden können.
- Um den Prozeß umzukehren, zum Beispiel eine gegebene Normale N in n und n zu codieren, kann man nicht einfach die Gleichung (2) invertieren. Statt dessen muß N zunächst in den kanonischen Oktanten und Sextanten gefaltet werden, was zu N' führt. Dann muß N' mit allen quantisierten Normalen in den Sextanten skalar multipliziert werden. Für ein festes n definieren die Werte von n und n, die zu dem größten (nahe 1) Skalarprodukt führen, die geeignete Codierung von N. Andere effizientere Verfahren für das Finden der korrekten Werte von n und n existieren, beispielsweise das Indexieren durch die Tabelle, um Φ einzustellen und dann in θ zu springen.
- Unter diesen Umständen kann das komplette Bitformat von absoluten Normalen gegeben werden. Die höchsten drei Bits spezifizieren den Oktanten, die nächsten drei Bits den Sextanten und schließ- lich spezifizieren die zwei n-Bitfelder n und n. Das 3-Bit-Sextantfeld nimmt einen von sechs Werten an, deren binäre Codes in Fig. 3 gezeigt sind.
- Einige weitere Details sind angezeigt. Die drei Normalen an den Ecken des kanonischen Ausschnittes werden mehrfach dargestellt, nämlich 6, 8 und 12 mal. Durch Einsetzen der zwei nicht verwendeten Werte des Sextantenfeldes, können diese Normalen einzigartig als 26 spezielle Normale codiert werden.
- Diese Darstellung der Normalen ist für die Δ-Codierung offen, zumindest innerhalb eines Sextanten, dies kann, obgleich mit einiger zusätzlicher Arbeit verbunden, erweitert werden auf Sextanten, die sich eine gemeinsame Kante teilen. Der Δ-Code zwischen zwei Normalen ist einfach die Differenz in n und n, nämlich Δ n und Δ n
- Im folgenden wird die Verwendung von Komprimierungsanzeigern durch die Anmelderin beschrieben. Viele Techniken sind bekannt für die minimale Darstellung von Bit-Feldern variabler Länge, jedoch für die Geometriekomprimierung gemäß der vorliegenden Erfindung wird eine Variation eines konventionellen Huffman-Algorithmus verwendet.
- Der Huffman-Komprimierungsalgorithmus nimmt einen Satz von darzustellenden Symbolen auf zusammen mit der Frequenz der Auftrittsstatistiken (zum Beispiel Histogramme) dieser Symbole. Hieraus werden Bitmuster mit variabler Länge, die eindeutig identifizierbar sind, erzeugt, die erlauben, daß diese Symbole mit einer nahezu minimalen Gesamtzahl von Bits dargestellt werden, unter der Annahme, daß Symbole bei den spezifizierten Frequenzen auftreten.
- Viele Komprimierungstechniken, einschließlich JPEG erzeugen eindeutige Symbole als Anzeiger, um die Länge eines Datenfeldes variabler Länge, das folgt, anzuzeigen. Dieses Datenfeld ist typischerweise ein Δ-Wert spezifischer Länge. Somit besteht der endgültige Binärstrom aus Anzeigersymbolen variabler Länge (selbstbeschreibender Länge), weil jedes mittelbar von einem Datenfeld gefolgt wird, dessen Länge verknüpft ist mit dem einmaligen Anzeigersymbol.
- In der vorliegenden Ausführungsform verwendet das Binärformat für die geometrische Komprimierung diese Technik, um die Position, die Normale und die Farbdatenfelder darzustellen. Für die geometrische Komprimierung steht diesen < Anzeiger, Daten> -Feldern ein konventionelleres Computerbefehlssatz op-Codefeld voraus. Diese Felder werden zusammen mit üblichen zusätzlichen Operandenbits als geometrische Befehle bezeichnet (siehe Fig. 4A-4K).
- Traditionell wird jedem zu komprimierenden Wert sein eigener verknüpfter Anzeiger zugewiesen, zum Beispiel ein xyz Δ-Position oder durch drei Anzeiger-Wertpaare dargestellt. Da jedoch die Δ xyz-Werte nicht unkorreliert sind, kann eine dichtere einfache Darstellung erzielt werden. Im allgemeinen zeigen die xyz Δ's statistisch gleichförmig in alle Raumrichtungen. Somit, wenn n die Anzahl von Bits ist, die benötigt wird, um das größte der Δ's darzustellen, dann erfordern die anderen zwei Δ-Werte statistisch im Mittel n-1,4 Bits für ihre Darstellung. Die bevorzugte Ausführungsform verwendet daher einen einzelnen Feldlängenanzeiger, um die Bitlänge von Δx, Δy und Δz anzuzeigen, obgleich auch eine andere Gestaltungsauswahl getroffen werden kann.
- Unglücklicherweise verhindert die Verwendung dieses Ansatzes das Ausnutzen des Vorteils einer anderen Huffman-Technik, um etwas weniger als ein weiteres Bit pro Komponente einzusparen. Die implementierte Ausführungsform gleicht diesen Nachteil jedoch dadurch aus, daß sie nicht zwei zusätzliche Anzeiger-Felder (für Δy und Δz) zu spezifizieren hat. Ein weiterer Vorteil ist, daß die Verwendung eines einzelnen Anzeiger-Feldes es einer Hardware-Dekomprimierungsmaschine erlaubt, alle drei Felder parallel zu dekomprimieren, sofern gewünscht wird.
- Ähnliche Argumente gelten für die Δ's der RGBα-Werte und entsprechend wird ein einzelner Feldlängenanzeiger verwendet, um die Bitlänge der R, G, B und, sofern vorhanden, α Felder anzuzeigen.
- Absolute und Δ-Normalen werden ebenso parametrisiert durch einen einzelnen Wert (n), der durch einen einzelnen Anzeiger spezifiziert werden kann. Um die Implementierung von Hardware hoher Geschwindigkeit und geringerer Kosten zu erleichtern, war die Länge des Huffman-Anzeigerfeldes auf 6 Bit, einen relativ kleinen Wert, begrenzt. Eine Anzeiger-Nachschlagtabelle mit 64 Einträgen erlaubt die Decodierung von Anzeigern in einem Taktzyklus. Eine Tabelle existiert für Positionen, eine andere Tabelle existiert für Normalen und noch eine andere Tabelle existiert für Farben (und optional ebenso für Texturkoordinaten). Jede Tabelle enthält die Länge des Anzeigerfeldes, die Länge des Datenfeldes (der Datenfelder), einen Datennormalisierungskoeffizienten und ein absolutes/relatives Bit.
- Für eine vernünftige Hardwareimplementierung muß eine zusätzliche Komplikation angesprochen werden. Wie oben beschrieben wurde, werden alle Befehle in einer 8-Bit-Kopfzeile und einem Körper variabler Länge beendet, wobei genügend Information in der Kopfzeile vorhanden ist, um die Körperlänge zu bestimmen. Die Kopfzeile eines Befehls muß jedoch in dem Datenstrom vor dem Körper des vorherigen Befehls plaziert sein, um der Hardware Zeit zu geben, die Kopfzeileninformation zu verarbeiten. Beispielsweise muß die Sequenz ... B0 H1B1 H2B2 H3 .... codiert werden als ... H1 B0 H2 B1 H3 B2 ... .
- Der Befehlssatz für die geometrische Komprimierung, der in der bevorzugten Ausführungsform verwendet wird, wird nun unter Bezug auf die Fig. 4A bis 4K beschrieben. Fig. 4A stellt ein Vertexkommando dar, das eine Huffman-komprimierte Δ-codierte Position sowie möglicherweise eine Normale und/oder Farbe spezifiziert, abhängig von den Bündelbits (BNV und BCV). Zwei zusätzliche Bits spezifizieren einen Vertexersetzungscode (REP) und ein anderer Bit steuert die Gitterpufferverschiebung dieses Vertex (MBP).
- Wie in Fig. 4B gezeigt ist, spezifiziert ein Normalenkommando eine neue gegenwärtige Normale und das Farbkommando, das in Fig. 4C gezeigt ist, stellt eine neue gegenwärtige Farbe dar. Das Normalenkommando und das Farbkommando verwenden jeweils die Huffman-Codierung der Δ- Wert.
- Die Gitterpufferreferenzkommandostruktur ist in Fig. 4D gezeigt. Das Gitterpufferreferenzkommando erlaubt es, auf irgendeines der sechzehn zuletzt verschobenen Vertices (und die verknüpften Normalen und/oder Farben) als das nächste Vertex Bezug zu nehmen. Wie weiter in Fig. 4B gezeigt ist, wird ebenso ein 2-Bit-Vertexersetzungscode ("REP") spezifiziert.
- Fig. 4E stellt den Zustandseinstellbefehl dar, der die fünf Zustandsbits: RNT, RCT, BNV, BCV und CAP aktualisiert.
- Fig. 4F stellt ein Tabelleneinstellkommando dar, das verwendet wird, um die Einträge einzustellen auf die Eintragswerte, die in einer der drei Huffman-Codierungstabellen (Position, Normale oder Farbe) spezifiziert sind.
- Fig. 4G stellt ein Durchleitkommando dar, das es zusätzlich erlaubt, daß ein Graphikzustand, der nicht direkt durch die geometrische Komprimierung gesteuert wird, in-line aktualisiert wird.
- Fig. 4H stellt ein no-op Kommando variabler Länge ("VNOP") dar, das es erlaubt, daß Felder innerhalb des Bitstroms an 32-Bit-Wortgrenzen ausgerichtet werden. Dies erlaubt es, daß ausgerichtete Felder während der Laufzeit durch die allgemeine CPU 52 effizient gepatcht bzw. korrigiert werden.
- Die Fig. 4I, 4J bzw. 4K stellen Anzeiger- und Δ-Positionsdatenstrukturen, Anzeiger- und Δ- Normalendatenstrukturen bzw. einen Anzeiger und die Δ-Farbdatenstruktur dar.
- Der Fachmann erkennt, daß auch andere Befehlssätze als die oben beschriebenen statt dessen verwendet werden können, um die vorliegende Erfindung zu implementieren.
- Das Verhältnis der Zeit, die für die Komprimierung erforderlich ist, relativ zu der Dekomprimierung ist eine wichtiges Maß für viele Formen der Komprimierung. In der Praxis ist es für die off-line Bildkomprimierung akzeptabel, daß sie vielleicht sechzigmal mehr Zeit als die Dekomprimierung benötigt, jedoch für die Echtzeitvideokonferenz sollte das Verhältnis eins sein.
- Die geometrische Komprimierung hat vorteilhafterweise nicht diese Echtzeitanforderung. Selbst wenn die Geometrie während der Übertragung konstruiert wird, erfordern die meisten Geometrie erzeugenden Techniken, zum Beispiel CSG, um Größenordnungen mehr Zeit als für die Anzeige der Geometrie benötigt wird. Ebenso werden in den meisten Anwendungen der geometrischen Komprimierung, im Gegensatz zu kontinuierlichen Bildern, die in Filmen gefunden werden, ein komprimiertes dreidimensionales Objekt für viele sequentielle Einzelbilder dargestellt, bevor es abgelegt wird. Sollte das dreidimensionale Objekt die Animation erfordern, wird die Animation typischerweise mit Modellmatrizen durchgeführt. Tatsächlich ist es für ein CD-basiertes Spiel wahrscheinlich, daß ein Objekt milliardenfach durch den Kundenbenutzer dekomprimiert wird, jedoch nur einmal von der verfassenden Firma komprimiert wird.
- Wie einige andere Kompressionssysteme können die geometrischen Kompressionsalgorithmen ein Kompromiß zwischen der Kompressionszeit und dem Kompressionsverhältnis eingehen. Für ein gegebenes Qualitätszielniveau, wenn die zulässige Zeit für die Komprimierung sich erhöht, erhöht sich das Kompressionsverhältnis, das durch ein geometrischen Kompressionssystem erreicht wird. Es gibt einen entsprechenden "Knopf" für die Qualität des resultierenden komprimierten dreidimensionalen Objektes und je niedriger der Qualitätsknopf ist, um so besser ist das erreichte Komprimierungsverhältnis.
- Es kann eine ästhetische und subjektive Beurteilung bei der geometrischen Komprimierung angewendet werden. Manche dreidimensionalen Objekte beginnen schlecht zu erscheinen, wenn die Zielquantisierung der Normalen und/oder Positionen leicht reduziert wird, wobei andere Objekte selbst mit einer großen Quantisierungsmenge visuell unverändert bleiben können. Kompression kann manchmal sichtbare Artefakte verursachen, jedoch in anderen Fällen veranlassen, daß das Objekt anders aussieht, nicht notwendigerweise in schlechterer Qualität. In einem Experiment, das von dem Anmelder durchgeführt wurde, beginnt ein Bild eines Elefanten tatsächlich realistischer zu erscheinen, mit mehr faltenartiger Haut, wenn die Bildnormalen stärker quantisiert werden. Nachdem ein Modell erzeugt und komprimiert wurde, kann es in eine Bibliothek eingefügt werden, um auf dem Systemlevel als dreidimensionales Clipart verwendet zu werden.
- Während viele Aspekte der geometrischen Komprimierung universell sind, wurde der oben beschriebene geometrische Kompressionsbefehlssatz etwas zugeschnitten, um die Hardware- Implementierungen mit niedrigen Kosten und hoher Geschwindigkeit zu erlauben (es versteht sich, daß ein Format für die geometrische Kompression, das lediglich für die Softwaredekomprimierung angepaßt ist, etwas anders sein würde). Der beschriebene geometrische Kompressionsbefehlssatz ist speziell der Hardwareimplementierung unterworfen, aufgrund der sequentiellen Ein-Durchgang- Verarbeitung, der begrenzten lokalen Speicheranforderungen, des Anzeigernachschlagens (im Gegensatz zu der konventionellen sequentiellen Hamming-Bit Verarbeitung) und der Verwendung von Verschiebungen, Additionen und Verweisen, um die meisten arithmetischen Schritte durchzuführen.
- Fig. 5 ist ein Flußdiagramm, das die Verfahrensschritte gemäß der vorliegenden Ausführungsform in einer geometrischen Komprimierungsalgorithmusroutine ausführt. Solch eine Routine kann in dem Speicher 80 abgelegt werden und unter der Steuerung der CPU 60 ausgeführt werden (siehe Fig. 1).
- In Schritt 200 wird ein Objekt durch eine explizite Gruppe von zu komprimierenden Dreiecken zusammen mit Quantisierungsschwellwerten für die Positionen, die Normalen und die Farben dargestellt. In Schritt 210 wird eine topologische Analyse der Konnektivität durchgeführt und harte Kanten werden in Normalen und/oder der Farbe markiert, falls solch eine Information nicht bereits präsent ist.
- In Schritt 220 wird die Vertexdurchquerungsordnung und die Gitterpufferpräferenzen erzeugt und in Schritt 230 werden Histogramme der Δ-Positionen, der Δ-Normalen und der Δ-Farben kreiert. In Schritt 240 werden getrennte Huffman-Anzeigercodes variabler Länge für die Δ-Positionen, die Δ- Normalen und die Δ-Farben, basierend auf den Histographen zugewiesen.
- In Schritt 250 wird ein binärer Ausgangsstrom erzeugt durch zunächst Ausgeben der Huffman- Tabelleninitialisierung, nachdem die Vertices in der Ordnung durchquert werden. Geeignete Anzeiger und Δ's werden für alle Werte ausgegeben.
- Der Anmelder hat einen Wellenfront OBJ-Formatkomprimierer implementiert, der die Kompression von Positionen und Normalen unterstützt und voll generalisierte Dreiecksstreifen erzeugt, hat jedoch noch keinen, ein vollständiges Gitter bildenden Algorithmus implementiert. Weitere Ausführungsformen werden die Geometrie mit variabler Genauigkeit untersuchen, einschließlich feinstrukturierter Aktualisierungen der Kompressionstabellen. Der vorliegende Komprimierer wendet Zeit dafür auf, geometrische Details zu berechnen, die dem Tesselator bereits bekannt sein und letzten Endes wird gehofft, die komprimierten geometrischen Daten direkt zu erzeugen. Jedoch kann selbst der gegenwärtige unoptimierte Zustand der Software des Anmelders in vielen Fällen etwa 3000 Dreiecke/Sekunde komprimieren.
- Es ist an dem Benutzerende natürlich wünschenswert, die komprimierten Daten zu dekomprimieren, und die oben angeführte Patentanmeldung beschreibt eine bevorzugte Art und Weise solch einer Dekomprimierung. Ein anwendbarer geometrischer Dekompressionsalgorithmus kann wie folgt ausgeführt sein.
- (1) Rufe den Rest des nächsten Befehls ab und die ersten acht Bits des folgenden Befehls,
- (2) Expandiere unter Verwendung der Zeigertabelle alle komprimierten Wertfelder auf volle Präzision,
- (3A) falls die Werte relativ sind, addiere sie zu gegenwärtigem Wert, anderenfalls ersetze sie,
- (3B) wenn auf Gitterpuffer Bezug genommen wird, greife auf alte Werte zurück,
- (3C) falls anderes Kommando, führe Verwaltung durch.
- (4) Falls Normale, leite Index durch ROM-Tabelle, um volle Werte zu erhalten.
- (5) Gebe Werte generalisierter Dreiecksstreifenform zu nächster Stufe aus.
- Der Anmelder hat einen Softwaredekomprimierer implementiert, der komprimierte Geometrie mit einer Rate von etwa 10.000 Dreiecken/Sekunde erfolgreich dekomprimiert. Hardwarekonstruktionen sind in der Entwicklung, ein vereinfachtes Blockdiagramm kann in Fig. 6 betrachtet werden. Die Rate der Hardwaredekomprimierung kann in dem Bereich von Dutzenden von Millionen von Dreiecken/Sekunde liegen.
- Vergleichende unkomprimierte und komprimierte Bildergebnisse sind in den Fig. 7A-7 und in Tabelle 1 unten gezeigt. Die Fig. 7A-7G stellen dasselbe Basisobjekt, einen Triceratop, dar, jedoch mit unterschiedlichen Quantisierungsschwellwerten auf Positionen und Normalen. Fig. 7A ist die ursprüngliche volle Gleitkommadarstellung unter Verwendung von 96 Bit-Positionen und 96 Bit-Normalen, die durch die Nomenklatur P96/N96 bezeichnet werden. Die Fig. 7B und 7C stel len die Effekte von der reinen positionalen Quantisierung P36/N96 bzw. P24/N96 dar, während die Fig. 7D und 7E nur die normale Quantisierung, P96/N18 und P96/N 12 darstellen. Die Fig. 5f und 5g zeigen eine kombinierte Quantisierung, P48/N18 und P30/N36.
- Die Fig. 7H bis 7L stellen quantisierte Resultate für unterschiedliche Objekte dar, einschließlich einer Galleone (P30/N12) eine Dodge Viper (P36/N14), zwei Ansichten eines 57er Chevy (P33/N13) und eines Insekt (P39/N15).
- Ohne in die Objekte hineinzuzoomen, hat die positionale Quantisierung weit oberhalb von 24 Bit im wesentlichen keinen signifikanten sichtbaren Effekt. Wenn die normale Quantisierung reduziert wird, werden die Positionen von spiegelnden Glanzpunkten auf den Oberflächen leicht versetzt. Es ist jedoch visuell nicht offensichtlich, daß solche Veränderungen eine Reduktion der Qualität darstellen, zumindest oberhalb von 12 Bits je Normale. Die Quantisierungsparameter wurden mit den Objekten fotografiert und ansonsten kann selbst der Anmelder nicht zwischen Original und den am stärksten komprimierten Versionen desselben Objektes unterscheiden.
- Die Tabelle 1 faßt die Kompression und andere Statistiken für die Objekte zusammen. Spalte 1 benennt das in Frage stehende Objekt, Spalte 2 stelle die Anzahl der Δ's dar und Spalte 3 die Δ- Streifenlänge. Die vierte Spalte stellt die Systemkopfzeile bzw. den Systemoverhead je Vertex dar (Overhead ist alles hinter den Positions-Anzeiger/Daten und den Normalen-Anzeiger/Daten). Die "xyz quant" Spalte bezeichnet die Quantisierungsschwellwerte und die sechste Spalte stellt die Anzahl von Bits/xyz dar. "Bits/tri", d. h. die neunte Spalte, stellt die Bits je Dreieck dar.
- Die Ergebnisse in Tabelle 1 sind gemessene tatsächliche Komprimierungsdaten, abgesehen von den geschätzten Gitterpufferergebnisse, die in Klammern gezeigt sind. Kein tatsächliches Gitterpufferergebnis war in dem Softwarekomprimierungsprototyp des Anmelders vorhanden, da bislang kein voller Verbindungsalgorithmus implementiert wurde. Die Abschätzung (in Klammern) nimmt ein 46%-iges Trefferverhältnis in dem Gitterpuffer an.
- In Tabelle 1 zeigt die ganz rechte Spalte die Komprimierungsverhältnisleistung, die über existierenden ausführbaren geometrischen Formaten erreicht wurde. Obgleich die Gesamtbytezahl der komprimierten Geometrie eine eindeutige Zahl ist, mußten bei dem Angeben eines Kompressionsverhältnisse einige Annahmen getroffen werden über die nicht-komprimierte ausführbare Darstellung des Objektes. Der Anmelder nahm optimierte generalisierte Dreiecksstreifen an, bei denen sowohl Positionen als auch die Normalen durch Gleitkommawerte dargestellt werden, um die "ursprüngliche Größe"-Daten für Tabelle 1 zu berechnen.
- Um den Effekt von reiner 16 Bit-Festpunkteinfachstreifendarstellung zu demonstrieren, zeigt Tabelle 1 ebenso Bytezahlen für den Mode von OpenGL. Wie gezeigt, wird die durchschnittliche Streifen länge auf den Bereich von 2-3 herabgesetzt. Nur wenige, falls überhaupt irgendwelche kommerziellen Produkte profitieren von generalisierten Dreieckstreifen und Tabelle 1 gibt somit die möglichen Einsparungen des Speicherplatzes deutlich zu niedrig an. TABELLE 1
- Während sicherlich eine statischer Variation zwischen den Objekten bezüglich der Komprimierungsverhältnisse besteht, können dennoch allgemeine Trends bemerkt werden. Bei der Komprimierung unter Verwendung der höchsten Qualitätseinstellung des Quantisierungsknopfes (P48/N18) betragen die Komprimierungsverhältnisse typischerweise etwa sechs. Wenn die Verhältnisse nahezu zehn erreichen, beginnen die meisten Objekte sichtbare Quantisierungsartefakte zu zeigen.
- Zusammenfassend kann die geometrische Komprimierung gemäß Ausführungsform der vorliegenden Erfindung dreidimensionale Dreiecksdaten mit einem Faktor von sechs bis zehnmal weniger Bits darstellen, als mit konventionellen Techniken erforderlich ist. Der geometrische Komprimierungsalgorithmus der Anmelderin kann in Echtzeithardware oder in Software implementiert werden. Für eine feste Anzahl von Dreiecken kann die Komprimierung die Gesamtbitgröße der Darstellung minimieren, die Qualitäts- und Implementierungskompromissen ausgesetzt ist. Das resultierende geometrisch komprimierte Bild erleidet nur geringe Verluste in der Objektqualität und kann dekomprimiert werden unter Verwendung von Software- oder Hardwareimplementierungen. Wenn dreidimensionale Darstellungshardware eine geometrische Dekomprimierungseinheit enthält, kann die Anwendungsgeometrie im Speicher in komprimiertem Format abgelegt werden. Weiterhin kann die Datenübertragung das komprimierte Format verwenden, wodurch die effektive Bandbreite für ein Graphikbeschleunigungssystem, einschließlich Anzeigeumgebungen mit gemeinsam genutzter virtueller Realität, verbessert wird. Die resultierende Komprimierung kann wesentlich die Geometrie, die im Hauptspeicher cachespeicherbar ist, erhöhen.
- Um ein besseres Verständnis der Rolle der vorliegenden Erfindung, insbesondere in einem Komprimierungs-Dekomprimierungssystem, zu unterstützen, wird nun die Dekomprimierung von Daten, die gemäß der vorliegenden Erfindung komprimiert wurden, detaillierter beschrieben. Die folgende Beschreibung der Dekomprimierung ist aus der vorher erwähnten Patentanmeldung der Anmelderin entnommen.
- Fig. 8 ist ein detailliertes Blockdiagramm der Dekomprimierungseinheit 130, die in Fig. 1 gezeigt ist. Wie in Fig. 8 gezeigt ist, beinhaltet die Einheit 130 eine Dekompressionseingangs-first-in-first- out-Register ("FIFO") 200, dessen Eingänge Steuersignale und einen Datenstrom von vorzugsweise 32 Bit oder 64 Bit beinhalten, dessen Signale und dessen Datenstrom vorzugsweise von einem Beschleunigungsanschlußdaten-FIFO ("APSF") in der Schnittstelleneinheit 120 kommt (siehe Fig. 1). Der APDF-Abschnitt der Schnittstelle 120 beinhaltet einen Controller, der die Größe des einkommenden Datenstroms der Einheit 130 signalisiert. Der FIFO 200 stellt eine Eingangsblockzustandsmaschine 220 und einem Eingangsblock 210, einer Zustandsmaschine 220 und eine Eingangsblockeinheit 210, die miteinander kommunizieren, zur Verfügung.
- Der Ausgang von dem Block 210 ist mit einer Kernverschiebungseinheit 240 und einem Huffman- Tabellensatz 230 verbunden, der Ausgang von der Huffman-Nachschlagetabelle ist mit der Zustandsmaschine 220 verbunden. Operationscode innerhalb der Zustandsmaschine 220 verarbeitet die Werte, die von den Huffman-Tabellen 230 zur Verfügung gestellt werden, und gibt Daten zu der Barrelverschiebungseinheit 240 aus. Die Zustandsmaschine 220 stellt ebenso einen Ausgang zu dem Datenpfadcontroller 260 zur Verfügung, der vorzugsweise ein 12-Bit breites Signal zu einer Anzeiger-Decoder-Einheit 294 ausgibt und ebenso Daten zu der Barrelverschiebungseinheit 240 und zu einem Normalprozessor 270 und zu einem Positions-/Farbprozessor 280 ausgibt.
- Die Barrelverschiebungseinheit 240 gibt zu dem Normalprozessor 270 und zu einem Positions- /Farbprozessor 280 aus. Die Ausgänge von den Prozessoren 270 und 280 werden im Multiplexverfahren durch die Ausgangsmultiplexereinheit 290 in ein vorzugsweise 48-Bit breites Signal übertragen, das einem Formatkonvertierer 292 zur Verfügung gestellt wird.
- Die Dekompressionseinheit 130 erzeugt einen vorzugsweise 12-Bit-Anzeiger, der zu dem Anzeigerdecoder 294 parallel mit entweder 32 Bits oder 48 Bits (für die Normalen) gesendet wird, die zu dem Formatkonvertierer 292 gesendet werden. Diese Datenströme stellen Befehle zur Verfügung, die eine Ausgabe für den Formatkonvertierer 292 erzeugen. Ein vorzugsweise 32 Bit Rücklesepfad wird verwendet, um den Zustand der Einheit zurückzulesen.
- Tabelle 2 unten zeigt Schnittstellensignale, die verwendet werden, um eine bevorzugte Ausführungsform der Dekompressionseinheit 130 zu implementieren: Tabelle 2
- Die Tabelle 3 unten zeigt Ausgangsdatenformate, die von der Einheit 130 zur Verfügung gestellt werden. Wie hier beschrieben wird, erzeugen Vertex, Gitterpufferreferenz und Durchleitbefehle Transaktionen von der Dekomprimierungseinheit 130. Vertex und Gitterpufferreferenzbefehle senden Daten zu dem Formatwandler und jeder erzeugt einen Header, der die Vertexersetzungspolicy bzw. -methode für den gegenwärtigen Vertex, gefolgt durch Komponentendaten, anzeigt. Jeder dieser Befehle erzeugt immer Positionsdaten und kann abhängig von dem Wert des Zustandsregisters Farb- oder Normalendaten enthalten. Alle drei der Normalenkomponente werden vorzugsweise parallel gesendet, wobei jede Positions- und Farbkomponente getrennt gesendet wird. Ein Durchleitbefehl sendet vorzugsweise 32 Bits von Daten zu dem Sammelpuffer. Tabelle 3
- Fig. 9 ist ein detailliertes Blockdiagramm des Eingangsblockes 210, der in Fig. 8 dargestellt ist. Ein vorzugsweise 64-Bit-Eingangsregister 300 empfängt Daten von dem APDF-Abschnitt der Interfaces 130 mit 32 Bits oder 64 Bits während der Zeit, in der es in das Register 300 geladen wird. Das Register 300 gibt vorzugsweise 32 Bits gleichzeitig über den Multiplexer 310 zu einem ersten Barrelverschieber 320 aus, dessen Ausgang durch ein Register 330 in eine Mischeinheit 340 geleitet wird. Der 64-Bit-Ausgang von der Mischeinheit 340 wird in das Datenregister 350 eingegeben, wobei ein Teil von dessen Ausgang als Eingang zu einem zweiten Barrelverschieber 360 zurückgegeben wird. Der Ausgang von dem zweiten Barrelverschieber 360 wird durch ein Register 370 geleitet und wird ebenso in die Mischeinheit 340 eingegeben. Der erste Barrelverschieber 320 richtet Daten mit dem hinteren Ende des bitausgerichteten Datenstroms aus, der von dem Datenregister 350 über den zweiten Barrelverschieber 360 wiederverwendet wird. Der zweite Barrelverschieber 360 schiebt die verwendeten Bits aus dem Datenregister 350.
- Fig. 10 ist ein detailliertes Blockdiagramm der Barrelverschiebereinheit 240, die in Fig. 8 gezeigt ist. Im Überblick expandiert die Barrelverschiebungseinheit 240 die variable Längenposition, die Farbe und die Normalindexkomponenten auf ihre Festpunktpräzisionen. Daten in die Einheit 240 von der Einheit 210 und/oder 220 werden in ein Register 400 eingegeben, dessen Ausgang als definierender Operationscode und/oder als Dateneinheiten 410, 420, 430, 440, 450 und 460 gezeigt sind, die in eine Multiplexereinheit 470 eingegeben werden.
- Der Eingang A der Multiplexereinheit 470 wird für die X-Komponente des Vertexbefehls verwendet, der Eingang B wird für den normalen Einstellbefehl und die erste Komponente der Farbeinstellbefehle verwendet und der Eingang C wird für die verbleibenden Komponenten des Vertex und der Farbeinstellbefehle verwendet. Die Einheit 240 beinhaltet weiterhin ein Barrellinksschieberegister 480, der derart angeschlossen ist, daß es die tag_len Daten empfängt und zu dem Register 490 ausgibt, dessen Ausgang wiederum in ein Barrelrechtsschieberegister 500 eingegeben wird, das derart angeschlossen ist, daß es die data_len Daten empfängt. Das Register 500 gibt an eine Maskeneinheit 510 aus, die derart angeschlossen ist, daß sie die Schiebedaten empfängt und deren Ausgang mit dem Register 520 verbunden ist, das v_data ausgibt. Der Ausgang des Datenblockes 460 ist mit einem Register 530 gekoppelt, dessen Ausgang mit einem zweiten Register 540 gekoppelt ist, das pt_data ausgibt.
- Eine geeignete Tabelle innerhalb der Huffman-Tabellen 230 (siehe Fig. 8) stellt Werte für tag-len, data_len zur Verfügung und verschiebt sie in die Einheiten 480, 500 bzw. 510. Die Barrellinksschiebeeinheit 480 verschiebt die Eingangsdaten um 0 bis 6 Bits nach links (tag-len), wodurch der Huffman-Anzeiger rausgeschoben wird. Im Gegensatz dazu verschiebt das Barrelrechtsschieberegister 500 die Daten um 0 bis 16 Bits (16 - data_len) nach rechts und das Vorzeichen erweitert die Daten, somit werden die Daten in ihre volle Größe gebracht. Die Maskeneinheit 510 deckt die unteren "verschiebe"-Bits ab, um die Daten auf das korrekte Quantisierungniveau festzuklemmen.
- Fig. 11 stellt in größerem Blockdiagrammdetail die Positions-/Farbprozessoreinheit 280 dar, die in Fig. 8 gezeigt ist. Die Prozessoreinheit 280 erzeugt die Endposition oder die Farbkomponentenwerte. Wie in den Fig. 8 und 10 gezeigt ist, empfängt die Prozessoreinheit 280 einen vorzugsweise 16 Bit-Wert (v_data) von der Barrelverschiebungseinheit 240, genauer gesagt, von der darin angeordneten Maskeneinheit 510.
- Wenn das abs_rel Bit von der Huffman-Tabelle 230 auf relativ eingestellt ist, werden die einkommenden Daten durch die Kombiniereinheit 600 zu den geeigneten gegenwärtig gespeicherten Daten addiert. Der neue Wert wird durch den Multiplexer 610 geleitet und wird zurück in das Register 620 gespeichert und wird entlang des Ausgangsmultiplexers 290 gesendet, der in Fig. 8 gezeigt ist. Wenn jedoch das abs_rel-Bit auf absolut gesetzt ist, dann umgehen die einkommenden Daten den Addierer 600 und werden in dem Register 620 gehalten und werden ebenso zu dem Ausgangsmultiplexer 290 ausgesendet.
- Wie in Fig. 11 gezeigt ist, beinhaltet die Positions-/Farbverarbeitungseinheit 280 weiterhin einen Positions-/Farbgitterpuffer 630, der derart angeschlossen ist, daß er den Eingang zum Register 620 empfängt. Der Ausgang von dem Gitterpuffer 630 ist mit den Multiplexergates, gemeinsam als 640 bezeichnet, verbunden, dessen Ausgänge die gegenwärtigen Werte von x, y, z, r, g, b und α darstellen. Eine Registereinstellung, gemeinsam als 650 gezeigt, stellt diese gegenwärtigen Werte dem Eingang eines Multiplexers 660 zur Verfügung, dessen Ausgang mit dem Addierer 600 verbunden ist. Die Prozessoreinheit 280 beinhaltet weiterhin ein Register 670, das von der Barrelschiebeeinheit 240 pt_data empfängt und ausgibt.
- Wie in Fig. 8 gezeigt ist, gibt die Normalenprozessoreinheit 270 ebenso Daten zu dem Ausgangsmultiplexer 290 aus. Fig. 12A stellt im Detail die Untereinheiten dar, die die Normalenprozessoreinheit 270 aufweist. Wie in der Fig. 8 und Fig. 10 zu sehen ist, empfängt die Normalenprozessoreinheit 270 einen 18 Bit-Normalenindex als drei getrennte Komponenten: Sextant/Oktant, u und v oder decodierte Δu und Δv Komponenten von der Maskeneinheit 510 in der Barrelverschiebungs einheit 240. Wenn der Wert ein Δ-Wert ist (relativ), werden Δu und Δv zu den gegenwärtigen u und v-Werten mittels entsprechenden Addierern 710 addiert. Die Zwischenwerte werden gespeichert und ebenso zu einer Falteinheit 800 weitergeleitet, die mit der Decoder-Falt-ROM-Einheit 272 (siehe Fig. 12B) verknüpft ist.
- Wie in Fig. 12A gezeigt ist, beinhaltet die Normalenprozessoreinheit 270 weiterhin Register 712, 714, 716, 718, 720, 722, 724, 726, die entsprechende Oktant-, Sextant-, u- und v-Werte, curr_oct, curr_sect, curr_u und curr_v-Werte halten. Ebenso sind in der Einheit 270 Multiplexer 740, 742, 744, 746, 748, 750, 752, 754, 756, 758 und 760 1er Ergänzungseinheiten 770, 772, Latch-Flipflopeinheiten 780, 782, 784 für das Halten der jeweiligen v-, u- und uv-Information, weitere Addierer 790, 792 und einen Normalengitterpuffer 794, der derart angeschlossen ist, daß er die curr_normal Eingangskomponenten empfängt, enthalten.
- Unter Bezug auf die Fig. 12A und 12B werden die u- und v-Werte für einen absoluten Bezug direkt zu der Falteinheit 800 geleitet. Die Oktant- und Sextantabschnitte des Indexes werden zu dem Decoder 810 innerhalb der Einheit 272 gesendet. Der Decoder 810 steuert den Multiplexer 820 (der die Konstanten auswählt), sowie auch die Multiplexer 840, 842, 844, 860, 862, 864, die die Komponenten umordnen und die Vorzeichen invertieren (unter Verwendung von 2er Ergänzungseinheiten 850,852,854).
- Die Falteinheit 800 verwendet die u- und v-Komponenten des Normalenindexes von der Einheit 270, um die Adresse in der Normalennachschlagtabelle 830 zu berechnen. Die Oktant- und Sextant- Felder von der Einheit 270 treiben einen Decoder 800C an, der das Vorzeichen und die Anordnung des Ausgangs der Komponenten von der ROM-Nachschlagtabelle 830 bestimmt. Der Decoder 810 handhabt ebenso spezielle Fälle der Normalen, die nicht in der Normalen-ROM-Nachschlagtabelle 830 beinhaltet sind.
- Fig. 13 stellt Schnittstellen zu einem Gitterpuffer dar, wie in Fig. 11 und/oder Fig. 12A gezeigt. Vorzugsweise wird ein Gitterpuffer 794 als ein Registerfile und als ein Zeiger auf den gegenwärtigen Ort implementiert. Daten werden an der Position des Zeigers auf den gegenwärtigen Ort in den Gitterpuffer FIFO eingegeben. Es ist jedoch der wahlfreie Zugriff auf irgendeinen der 16 Orte erlaubt, wenn die Daten aus dem FIFO ausgelesen werden, durch Weiterindizieren dieses Zeigers: address = (curr_loc_ptr-index) mod 16.
- Fig. 14A stellt Schnittstellen zu Huffman-Tabellen, zum Beispiel den Tabellen 230 in Fig. 8 dar. Huffman-Tabellen werden verwendet, um die Huffman-Anzeiger, die den komprimierten Daten vorhergehen, zu decodieren. Drei Huffman-Tabellen werden verwendet: eine für die Position, für die Farbe und für die Normalendaten, wobei jede Tabelle vorzugsweise 64 Einträge hält.
- Fig. 14B stellt ein bevorzugtes Format für den Eintrag der Positions- und Farbdaten in den Huffman-Tabellen dar, während Fig. 14C das bevorzugte Format für Normalentabelleneinträge darstellt. Das Befehlsformat für das Laden der Huffman-Tabellen in den komprimierten Datenstrom wird später beschrieben.
- Verschiedene Befehle erzeugen Daten für den Formatkonvertierer 292, der in Fig. 8 gezeigt ist, und geeignete Anzeiger müssen für diese Daten erzeugt werden, so daß der Formatkonvertierer die Daten korrekt verarbeiten kann. Tabelle 4 unten zeigt Anzeiger, die für die verschiedenen Datenkomponenten erzeugt wurden. Die Komponenten, die zwei Anzeiger zeigen, können das Startbit einstellen und der zweite Anzeiger zeigt den Wert mit den eingestellten Startbit. Tabelle 4
- Die Eingangsblockzustandsmaschine 220 (siehe Fig. 8) beinhaltet ein vorzugsweise 6 Bit- Zustandsregister, das Informationen über den Verarbeitungszustand der Dekomprimierungseinheit hält. Vorzugsweise werden die folgenden Zustandsbits definiert:
- Bit 5: tex - Texturwerte anstelle von Farbwerten
- Bit 4: rnt - Repliziere Normale je Vertex
- Bit 3: rct - Repliziere Farbe je Vertex
- Bit 2: bnv - Normale gebündelt mit Vertex
- Bit 1: bcv - Farbe gebündelt mit Vertex
- Bit 0: cap - Farbe beinhaltet alpha (α)
- Die Positions-/Farbprozessoreinheit 280 (Siehe Fig. 8 und 11) beinhaltet vorzugsweise drei 16- Bitregister, curr_x, curr_y und curr_z, die die gegenwärtigen Positionskomponenten X, Y und Z enthalten und nur durch Vertex-Befehle aktualisiert werden.
- Die Normalprozessoreinheit 270 (siehe Fig. 8 und 12A) beinhaltet vorzugsweise drei 6- Bitregister, curr_oct, curr_sext, curr_u, curr_v, die die gegenwärtige Normale enthalten. Das erste Register hält die 3 Bit-Sextant- und Oktantfelder und die verbleibenden zwei Register enthalten die u- und v-Koordinaten für die Normale. Diese Werte werden geschrieben unter Verwendung des NormaleneEinstellbefehls oder sie werden durch den Vertex-Befehl aktualisiert, wenn das bnv-Bit in dem Zustandsregister gesetzt ist.
- Der Positions-/Farbprozessor 280 beinhaltet weiterhin vorzugsweise vier 16-Bitregister, curr_r, curr_g, curr_b, curr_a, die die gegenwärtigen Farbkomponenten, rot, grün, blau und alpha (α) enthalten. Diese Komponenten werden eingestellt unter Verwendung des Farbeinstellbefehls oder sie werden durch den Vertex-Befehl aktualisiert, wenn das bcv-Bit in dem Zustandsregister eingestellt ist. Vorzugsweise ist alpha nur gültig, wenn das cap-Bit in dem Zustandsregister gesetzt ist. Das Testbit wird eingestellt, wenn die Texturkomponenten verarbeitet werden, wobei in diesem Fall nur rot und grün gültig sind.
- Ein bevorzugter Befehlssatz, der die Dekomprimierung von gemäß der vorliegenden Erfindung komprimierten Daten implementiert, wird nun beschrieben. Fig. 15A stellt das Vertex-Befehlsformat dar, wobei ein Befehl, der die Huffman-Codierung mit variabler Länge verwendet, dargestellt ist, um ein Vertex zu repräsentieren. Die Positionsinformation ist immer in diesem Befehl vorhanden.
- (REP) Die Vertex-Ersetzungspolicy lautet wie folgt:
- 00 - Neustart in Uhrzeigerrichtung
- 01 - Neustart in Gegenuhrzeigerrichtung
- 10 - Ersetze Mitte
- 11 - Ersetze ältestes
- (M) - Gitterpufferverschiebung:
- 0 - keine Verschiebung
- 1 - Verschiebung
- Unter Bezug auf Fig. 15A bestehen die Positionsdaten aus einem Huffman-Anzeiger variabler Länge (0 bis 6 Bits), gefolgt von drei Datenfeldern von gleicher Länge für die X, Y und Z-Komponenten, die entweder Δ-Werte oder absolute Werte sind. Das data_len-Feld für den Eintrag in der Positions- Huffman-Tabelle gibt die Länge an von jedem der X-, Y- und Z-Felder, der tag_len Eintrag gibt die Länge des Anzeigers und der abs_rel Eintrag gibt an, ob die Daten absolute Daten sind oder relativ zu dem vorherigen Vertex sind. Der Shift- bzw. Verschiebeeintrag von der Huffman-Tabelle gibt den Quantisierungslevel (Anzahl der führenden Nullen) für die Daten an.
- Wenn das bnv-Bit in dem Zustandsregister gesetzt ist, wird eine Normale aufgenommen. Die codierte Normale hat einen Huffman-Anzeiger, gefolgt von entweder zwei Datenfeldern variabler Länge für Δu und Δv oder von einem Feld fester Länge für den Sextanten und Oktanten (6 Bits), gefolgt von zwei Feldern variabler Länge für u und v. Die vorherige Codierung ist für Δ-Codierungen von Normalen, während die letzte Codierung für absolute Codierungen ist. Die data_len, tag_len, abs_rel und Shiftfelder von der normalen Huffman-Tabelle werden in ähnlicher Weise wie Einträge von der Positionstabelle verwendet.
- Fig. 15B stellt Datenformate der Vertex-Komponente dar. Wenn das bcv-Bit in dem Zustandsregister gesetzt ist, wird Farbe in den Vertex aufgenommen. Die Farbe wird ähnlich zu der Position codiert unter Verwendung von drei oder vier Feldern, wie jedoch die Felder verwendet werden, wird durch die Anzeigertabelle bestimmt. Falls absolut angezeigt wird, dann werden X, Y, Z, R, G, B Daten verwendet. Absolute Normalen werden mit Sextant- und Oktantfeldern verwendet. Wenn jedoch die Anzeigertabelle relativ anzeigt, werden Δ-Normalen verwendet und es ist ausreichend, Breiten- und Längendaten zu senden (zum Beispiel θ und Φ, ebenso hier als u und v bezeichnet).
- Weiterhin unter Bezug auf Fig. 15B folgen auf einen Huffman-Anzeiger drei Felder gleicher Länge für R, G und B. Das cap-Bit in dem Zustandsregister zeigt an, ob ein zusätzliches Feld für α beinhaltet ist. Die data_len, tag_len, abs_rel und Shift-Felder von der Farb-Huffman-Tabelle werden in ähnlicher Weise verwendet wie die Einträge von der Positions- und Normalentabelle.
- Die Zustände des Vertex-Befehlssatzes sind wie folgt:
- 1. Sperren bzw. Halten des nächsten Operationscodes; Ausgabe X, verschiebe Barrelrechtsschiebeeinheit 500 (siehe Fig. 10) um ptag_len + pdata_len - pquant + 2.
- 2. Mischen; Ausgabe Header.
- 3. Ausgabe Y, verschiebe Barrelrechtsschiebeeinheit 500 (siehe Fig. 10) um pdata_len - pquant.
- 4. Mische.
- 5. Ausgabe Z, verschiebe Barelrechtsschiebeeinheit 500 (siehe Fig. 10) um pdata_len - pquant.
- 6. Mische.
- a. Falls (bnv)
- i. wenn (absolute Normale) gehe zu 7,
- ii. sonst gehe zu 9./*relative Normale*/
- b. sonst, wenn (rnt), gehe zu 21,
- c. sonst, wenn (bcv), gehe zu 13,
- d. sonst, wenn (red), gehe zu 22,
- e. sonst, mische, verzweige zu nächstem Befehl.
- 7. Sperre nächsten Operationscode; Ausgabe Sextant/Oktant; verschiebe Kernrechtsschiebeeinheit 500 (siehe Fig. 19) um ntag_len + 6.
- 8. Vermische.
- 9. Ausgabe U.
- a. wenn (absolute Normale), verschiebe Barrelrechtsschiebeeinheit 500 (siehe Fig. 10) um ndata_len - nquant.
- b. sonst/*relative Normale*/, verriegele nächsten Operationscode; verschiebe Bs2 um ntag_len + ndata_len - nquant
- 10. Vermische.
- 11. Ausgabe V.
- 12. Vermische.
- a. wenn (bcv) gehe zu 13,
- b. sonst, wenn (rct), gehe zu 22,
- c. sonst, vermische; verzweige zu nächstem Befehl.
- 13. Verriegele nächsten Operationscode, Ausgabe R, verschiebe Barrelrechtsschiebeeinheit 500 (Sihe Fig. 10) um ctag_len + cdata_len - cquant.
- 14. Vermische.
- 15. Ausgabe G; verschiebe Barrelrechtsschiebeeinheit 500 (siehe Fig. 10) um cdata_len - cquant.
- 16. Vermische; wenn (tex), verzweige zu nächstem Befehl.
- 17. Ausgabe P; verschiebe Barrelrechtsschiebeeinheit 500 (siehe Fig. 10) um cdata:len - cquant.
- 18. Vermische; wenn (~cap), verzweige zu nächstem Befehl.
- 19. Ausgabe A; verschiebe Barrelrechtsschiebeeinheit 500 (siehe Fig. 10) um cdata:len - cquant.
- 20. Vermische; verzweige zu nächstem Befehl.
- 21. Ausgabe curr_normal.
- a. wenn (bcv), Gehe zu 13,
- b: sonst, wenn (rct), gehe zu 22,
- c. sonst vermische; verzweige zu nächstem Befehl.
- 22. Ausgabe curr_r.
- 23. Ausgabe curr_g. Wenn (tex), vermische; verzweige zu nächstem Befehl.
- 24. Ausgabe curr_b. Wenn (~cap), vermische; verzweige zu nächstem Befehl.
- 25. Ausgabe curr_a. vermische, verzweige zu nächstem Befehl.
- Fig. 15C stellt das Format für den Normaleneinstellbefehl dar. Der Normaleneinstellbefehl stellt den Wert des gegenwärtigen Normalenregisters ein. Die Normalendaten werden codiert in ähnlicher Weise wie die Normalendaten in dem Vertex-Befehl, der hier beschrieben wird. Die Zustände des Normaleneinstellbefehls sind wie folgt:
- Wenn (absolute Normale)
- 1. Verriegele nächsten Operationscode; Ausgabe Sextant/Oktant; verschiebe Barrelrechtsschiebeeinheit 500 (siehe Fig. 10) um ntag_len + 8.
- 2. Vermische.
- 3. Ausgabe U; verschiebe Barrelrechtsschiebeeinheit 500 (siehe Fig. 10) um ndata_len - nquant.
- 4. Vermische.
- 5. Ausgabe V, verschiebe Barrelrechtsschiebeeinheit 500 (siehe Fig. 10) um ndata_len + nquant.
- 6. Vermische; verzweige zu nächstem Befehl.
- sonst/*relative Normale*/
- 1. Verriegele nächsten Operationscode; Ausgabe dU, verschiebe Barrelrechtsschiebeeinheit 500 (siehe Fig. 10) um n_tag_len + ndata_len + nquant.
- 2. Vermische.
- 3. Ausgabe dV; verschiebe Barrelrechtsschiebeeinheit 500 (siehe Fig. 10) um ndata_len - nquant.
- 4. Vermische; verzweige zu nächstem Befehl.
- Fig. 15 stellt den Farbeinstellbefehl dar, wobei der Befehl den Wert der gegenwärtigen Farbregister einstellt. Die Codierung der Farbdaten ist ähnlich zu der Codierung der Farbdaten in dem Vertex- Befehl. Die Zustände des Farbeinstellbefehls sind wie folgt:
- 1. Verriegele nächsten Operationscode; Ausgabe R, verschiebe Barrelrechtsschiebeeinheit 500 (siehe Fig. 10) um ctag_len + cdata_len - cquant + 2.
- 2. Vermische.
- 3. Ausgabe G; verschiebe Barrelrechtsschiebeeinheit 500 (siehe Fig. 10) um cdata_len - cquant.
- 4. Vermische. Falls (tex), verzweige zu nächsten Befehl.
- 5. Ausgabe B, verschiebe Barrelrechtsschiebeeinheit 500 (siehe Fig. 10) um cdata_len - cquant.
- 6. Vermische. Falls (~cap), verzweige zu nächstem Befehl.
- 7. Ausgabe A; verschiebe Barrelrechtsschiebeeinheit 500 (siehe Fig. 10) um cdata_len - cquant.
- 8. Vermische; verzweige zu nächstem Befehl.
- Fig. 15E ist ein bevorzugtes Format für den Gitterpufferreferenzbefehl. Dieser Befehl veranlaßt, daß Daten von einem Eintrag in den Gitterpuffer nach außen zu dem Formatumwandler als nächses Vertex gesendet werden. Unter Bezug auf Fig. 15E zeigt der Index den Eintrag an, der von dem Gitterpuffer zu senden ist. Der neueste Eintrag in dem Gitterpuffer hat den Index 0 und der älteste hat den Index 15. REP, die oben beschriebene Ersetzungspolicy für den Vertex-Befehl, ist die gleiche wie die für den Gitterpufferreferenzbefehl verwendete. Die Zustände für den Gitterpufferreferenzbefehl sind wie folgt:
- 1. Verriegele nächsten Operationscode; Ausgabe Header; verschiebe Barrelrechtsschiebeeinheit 500 (siehe Fig. 10) um 9.
- 2. Ausgabe X von Gitterpuffer.
- 3. Ausgabe Y von Gitterpuffer.
- 4. Ausgabe Z von Gitterpuffer.
- a. Falls (bnv oder rnt), gehe zu 5,
- b. sonst, falls (bcv oder rct), gehe zu 6,
- c. sonst, vermische; verzweige zu nächstem Befehl.
- 5. Falls (bvn), gebe Normale von Gitterpuffer aus, sonst falls (rnt), gebe curr-Normal aus.
- a. Falls (bnv oder rct), gehe zu 6,
- b. sonst vermische; verzweige zu nächstem Befehl.
- 6. Falls (bcv) Ausgabe R von Gitterpuffer, sonst falls (rct) Ausgabe curr_r.
- 7. Falls (bcv) Ausgabe G von Gitterpuffer, sonst falls (rct) Ausgabe curr_g. Falls (tex), vermische; verzweige zu nächstem Befehl.
- 8. Falls (bcv), Ausgabe B von Gitterpuffer, sonst falls (rct) Ausgabe curr_b. Falls (~cap), vermische; verzweige zu nächstem Befehl.
- 9. Falls (bcv), Ausgabe A von Gitterpuffer, sonst falls (rct) Ausgabe curr_a. Vermische; verzweige zu nächstem Befehl.
- Fig. 15F stelle den Zustandseinstellbefehl dar, der die Bits des Zustandsregisters der Dekomprimierungseinheit einstellt. Die Zustände für den Zustandseinstellbefehl sind wie folgt:
- 1. Verriegele nächsten Operationscode; verschiebe Barrelverschieber 2 um 11 Bits.
- 2. Vermische; verzweige Befehl.
- Fig. 15G stellt den Tabelleneinstellbefehl dar, der die Huffman-Tabelleneinträge einstellt. Die Tabellenauswahl erfolgt wie folgt:
- 00 - Positionstabelle
- 01 - Farbtabelle
- 10 - Normalentabelle
- 11 - undefiniert.
- Die Anzeigerlänge wird von der Adresse abgeleitet. Die neun Bits in dem Eintragsfeld entsprechen dem absoluten/relativen Bit, der Datenlänge und den Verschiebungsgrößen-Feldern der Huffman- Tabelleneinträgen. (Das bevorzugte Format der Huffman-Tabelleneinträge wurde hier vorher bechrieben.) Die Zustände des Tabelleneinstellbefehls sind wie folgt:
- 1. Verriegele nächsten Operationscode; sende Adresse und Eintrag zu Huffman- Tabellen; verschiebe Barrelrechtsschiebeeinheit 500 (siehe Fig. 10) um 23.
- 2. Vermische; verzweige zu nächstem Befehl.
- Tabelle 5 unten zeigt die bevorzugten Huffman-Tabellenfüllcodes. Tabelle 5
- Fig. 15H stellt den Durchleitbefehl dar, der es erlaubt, daß Durchleitdaten in dem komprimierten Datenstrom codiert werden. Die Länge des Befehls beträgt vorzugsweise 64-Bit. Die Ausrichtung nachfolgender Durchleitbefehle auf eine 64-Bitgrenze erlaubt das Patching bzw. das Korrigieren von Durchleitdaten in dem codierten Strom. Die Zustände für den Durchleitbefehl sind wie folgt:
- 1. Verriegele nächsten Operationscode; lese Adresse, verschiebe Barrelrechtsschiebeeinheit 500 (siehe Fig. 10) um 32 Bits.
- 2. Vermische,
- 3. Ausgabe Daten, verschiebe Barrelrechtsschiebeeinheit 500 (siehe figur 10) um 32 Bits.
- 4. Vermische; verzweige zu nächstem Befehl.
- Fig. 15I stellt den NOP-Befehl variabler Länge ("VNOP") dar, der eine variable Anzahl von 0 Bits in dem Datenstrom codiert. Der 5-Bitcount, der in in Fig. 15I gezeigt ist, bezeichnet die Anzahl von 0 Bits, die folgen. Dieser Befehl wird implizit verwendet für den Start des Datenstroms. Dieser Befehl kann ebenso verwendet werden, um den Datenstrom auf 32 Bit oder 64 Bit-Grenzen aufzufüllen oder Regionen zu codieren für das spätere Patching bzw. Korrigieren. Die Zustände für diesen Befehl sind:
- 1. Verriegele nächsten Operationscode; lese Count bzw. Zähler; Barrelrechtsschiebeeinheit 500 (siehe Fig. 10) um 13 Bits;
- 2. Vermische.
- 3. Barrelrechtsschiebeeinheit liest "count"-Positionen,
- 4. Vermische; verzweige zu nächstem Befehl.
- Fig. 15J zeigt den Skip-8-Befehl (Auslaßbefehl), dessen Zustände wie folgt sind.
- 1. Verriegele nächsten Operationscode; verschiebe Barrelrechtschiebeeinheit 500 (siehe Fig. 10) um 16 Bits,
- 2. Vermische; verzweige zu nächstem Befehl.
- Es versteht sich, daß es von Vorteil sein kann, die Bandbreitenerfordernisse zwischen Vorrichtungen zu reduzieren durch Nicht-Dekomprimieren eines Datenstroms an einem einzelnen Punkt in einem Dekomprimierungssystem. Es versteht sich, daß die parallele Dekomprimierung eines Datenstroms implementiert werden kann durch zur Verfügung stellen eines zusätzlichen Kommandos, das über die Ankunft einer gegebenen Anzahl von Datenworten, die parallel verarbeitet werden können, informiert. Die Anwesenheit von solchen parallelen Möglichkeiten kann durch die Anwesenheit von Markierungsbits erkannt werden, mit deren Auftreten die angegebene Anzahl von Datenworten zu anderen Prozessoren innerhalb des Systems hin- und hergeschickt werden können für die parallele Dekomprimierung. Weiterhin ist es dann zulässig, über die gegebene Anzahl von Worten in dem Datenstrom zu springen, um bei den nächsten Daten anzukommen, die nicht für die Parallelverarbeitung geeignet sind.
- Weiterhin kann ebenso die Morphing-Fähigkeit implementiert werden, um jedes abrupte Wahrnehmungsgap in der Betrachtung eines dekomprimierten dreidimensionalen Objektes zu eliminieren. Es ist innerhalb des dekomprimierten Datenstroms möglich, Vertices als lineare zu spezifizieren oder andere Interpolationen von Vertices zu spezifizieren, die tatsächlich vorhanden sind oder vorher dekomprimiert wurden. Angenommen, daß beispielsweise das dreidimensionale Objekt ein Tiger ist. In einem weiten Abstand sind keine Zähne in dem Mund des Tigers vorhanden, doch bei nahem Abstand sind Zähne vorhanden. Das Ergebnis ist ein nahtloser Übergang, so daß, wenn der Abstand zu dem Tiger sich verringert, die Zähne wachsen, wobei kein plötzlicher Übergang zwischen einem zahnlosen Tiger und einem gezahnten Tiger gesehen wird.
- Modifikationen und Variationen können an den offenbarten Ausführungsformen vorgenommen werden, ohne von dem Gegenstand und dem Geist der Erfindung abzuweichen, wie er durch die folgenden Ansprüche definiert wird.
Claims (18)
1. Komprimierungsverfahren, bei welchem ein dreidimensionales Objekt (10), dessen
Oberfläche Oberflächeneigenschaften definiert, welche zumindest eine Eigenschaft umfassen,
welche aus der Gruppe ausgewählt wird, die besteht aus (i) der Position, (ii) Normalen, (iii)
Farben, (iv) Texturplankoordinaten und (v) Materialoberflächeneigenschaften des Objektes, in
Form von dreidimensionalen, triangulären Daten wiedergeben wird, die eine Mehrzahl von
Dreiecken definieren, welche Knoten (1-30) haben, wobei das Verfahren aufweist:
(a) Umwandeln der Dreiecksdaten in ein Dreiecksstreifenformat,
(b) Quantisieren einzelner Oberflächeneigenschaften,
(c) Anwenden einer Deltalkomprimierung variabler Länge auf benachbarte
Oberflächeneigenschaften, und
(d) Bereitstellen eines Datenstromes, welcher das dreidimensionale Objekt als Sammlung
von Daten wiedergibt, die in Schritt (a), in Schritt (b) und in Schritt (c) erzeugt wurden.
2. Verfahren nach Anspruch 1, wobei in Schritt (a) das Dreiecksstreifenformat zumindest eine
Formateigenschaft hat, die ausgewählt wird aus der Gruppe, welche besteht aus (i) das
Dreiecksstreifenformat definiert ein verallgemeinertes Dreiecksgitter, und (ii) das
Dreiecksstreifenformat bewirkt, dass jeder darin enthaltene Knoten im Durchschnitt eine Anzahl von
Dreiecken angibt, die zwischen 1/3 und 2 liegt.
3. Verfahren nach einem der vorstehenden Ansprüche, wobei das Objekt zumindest eine
Eigenschaft hat, die ausgewählt wird aus der Gruppe, die besteht aus (i) Eigenschaften der
Position des Objektes werden als geradlinige x-, y-, z-Koordinaten wiedergeben, (ii)
Eigenschaften der Farbe des Objektes werden wiedergeben als solche, die zumindest rote, grüne,
blaue und Alpha-Komponenten haben, wobei die Farbe zumindest eine Farbe umfaßt, die
aus der Gruppe ausgewählt wird, die besteht aus (a) einer Strahlungsfarbe, (b) einer
Umgebungsfarbe, (c) einer diffusen Farbe und (d) einer spiegelnden Farbe, und (iii) Eigenschaften
von Normalen der Gegenstände werden wiedergeben durch geradlinige Nx-, Ny-, und Nz-
Vektorkoeffizienten.
4. Verfahren nach einem der vorstehenden Ansprüche, wobei jede der Normalen durch einen
einzigen Index in einer Tabelle vordefinierter normierter Normalen wiedergeben ist.
5. Verfahren nach Anspruch 4, wobei der Index zumindest eine Eigenschaft hat, die
ausgewählt wird aus der Gruppe, welche besteht aus (i) der Index weist Bits einer
Indexwiederga
be auf, die geradlinige Wiedergabevorzeichenbits einer wiederzugebenden Normalen
aufweist, (ii) der Index umfaßt zumindest ein Bit, welches mögliche Faltungen einer absoluten
Größe einer geradlinigen Wiedergabe der Normalen spezifiziert, die durch zumindest eine
Faltungsebene x = y, x = z, y = z repräsentiert wird, so daß eine gefaltete Normale mit Sicherheit
auf einer bekannten Seite der Faltungsebene ist, (iii) der Index umfaßt Bits, welche
Längeninformationen und Breiteninformationen der Normalen umfaßt, (iv) der Index ist so definiert,
daß er Bits von Oktanteninformationen, Bits von Sextanteninformationen und zusätzliche
Informationsfelder über Länge und Breite der gefalteten Normalen umfaßt, (v) der Index
umfaßt Bits, welche Längeninformationen und Breiteninformationen der Normalen umfassen
und umfaßt weiterhin Bits von Oktanteninformationen, Bits von Sextanteninformationen und
zusätzliche Informationsfelder über Länge und Breite der gefalteten Normalen, (vi) der Index
ist so definiert, daß er drei Bits von Oktanteninformationen, drei Bits von
Sextanteninformationen und zwei zusätzliche Felder von Informationen über Länge und Breite der gefalteten
Normalen hat, und (vii) der Index umfaßt Bits, welche Längeninformationen und
Breiteninformationen der Normalen repräsentiert, und weiterhin drei Bits von Oktanteninformationen,
drei Bits von Sextanteninformationen und zwei zusätzliche Informationsfelder über Länge
und Breite der gefalteten Normalen.
6. Verfahren nach Anspruch 4 oder 5, wobei in irgendeiner Wiedergabe des Index ein
Unterschied zwischen zwei Normalenindizes allein durch Unterschiede zwischen Längen- und
Breiteninformationen der Normalen Indizes wiedergegeben wird, wenn andere Komponenten
der Wiedergabe im Übrigen identisch sind, und
wobei selbst dann, wenn andere Informationen geographisch benachbart jedoch nicht
identisch sind, ein Unterschreiten und/oder Überschreiten von Längen- und
Breitendifferenzinformationen wiedergeben kann, wie andere Komponenten der Wiedergabe zu modifizieren
sind.
7. Verfahren nach einem der vorstehenden Ansprüche, wobei Schritt (c) zumindest teilweise
unter Verwendung einer Vorgehensweise ausgeführt wird, die aus der Gruppe ausgewählt
wird, welche besteht aus (i) Huffman Komprimierungsvorgang, (ii) einer Variante eines
Huffman Komprimierungsvorganges, (iii) einer arithmetischen Codierung und (iv) einer Variante
der arithmetischen Codierung.
8. Verfahren nach irgendeinem der vorstehenden Ansprüche, wobei die
Oberflächeneigenschaften, aufweiche die Deltakompression variabler Länge in Schritt (c) angewendet wird, in
Schritt (b) quantisiert wurden.
9. Verfahren nach einem der Ansprüche 1 bis 7, wobei die Oberflächeneigenschaften, auf
welche die Deltakompression variabler Länge in Schritt (c) angewendet wird, nicht quantisiert
sind.
10. System welches mit einem Computersystem (20) verwendbar ist, das eine zentrale
Prozessoreinheit (CPU) (60) und einen Speicher (70) aufweist, der mit der CPU verbunden ist, für
das komprimieren von Daten, die ein dreidimensionales Objekt (10) wiedergeben, dessen
Oberfläche Oberflächeneigenschaften definiert, die zumindest eine Eigenschaft umfassen,
welche ausgewählt wird aus der Gruppe, die besteht aus (i) einer Position, (ii) Normalen, (iii)
Farben, (iv) Texturplankoordinaten bzw. Texturabbildungskoordinaten und (v)
Materialoberflächeneigenschaften des Objektes, wobei das Objekt in Form von dreidimensionalen
Dreiecksdaten wiedergegeben wird, die eine Mehrzahl von Dreiecken definieren, welche Knoten
(1-30) haben, wobei das System aufweist:
eine erste Einheit, die so programmiert ist, daß sie die Dreiecksdaten in ein
Dreiecksstreifenformat umwandelt,
eine Quantisierungseinheit, die einzelne der Oberflächeneigenschaften quantisiert,
eine Komprimierungseinheit, die eine Deltakompression variabler Länge auf benachbarte der
Oberflächeneigenschaften anwendet, und
einen Datenstromgenerator, der einen Datenstrom liefert, welcher das dreidimensionale
Objekt als eine Sammlung von Daten wiedergibt, die durch die erste Einheit, die
Quantisierungseinheit und die Komprimierungseinheit erzeugt wurden.
11. System nach Anspruch 10, wobei das Dreiecksstreifenformat zumindest eine
Formateigenschaft hat, die ausgewählt ist aus der Gruppe, welche besteht aus (i) das
Dreiecksstreifenformat definiert ein verallgemeinertes Dreiecksgitter, und (ii) das Dreiecksstreifenformat
bewirkt, daß jeder darin vorhandene Knoten in Durchschnitt eine Anzahl von Dreiecken
spezifiziert, die von 1/3 bis 2 reicht.
12. System nach Anspruch 10 oder 11, wobei Eigenschaften des Objektes zumindest eine
Eigenschaft haben, die ausgewählt ist aus der Gruppe, welche besteht aus (i) Eigenschaften
der Position des Objektes werden als geradlinige x-, y-, z-Koordinaten wiedergegeben,
(ii) Eigenschaften der Farbe des Objektes werden wiedergegeben als solche, die zumindest
rote, grüne, blaue und Alpha-Komponenten haben, wobei die Farbe zumindest eine Farbe
umfaßt, die ausgewählt wird aus der Gruppe, welche besteht aus (i) Strahlungsfarbe,
(ii) Umgebungsfarbe, (iii) diffuse Farbe und (iv) spiegelnde Farbe, und (iii) Eigenschaften von
Normalen des Objektes werden wiedergegeben durch geradlinige Nx-, Ny- und Nz-
Vektorkoeffizienten.
13. System nach Anspruch 10, 11 oder 12, wobei jede der Normalen durch einen einzigen Index
in einer Tabelle von vordefinierten, normierten Normalen wiedergeben wird.
14. System nach Anspruch 13, wobei in irgendeiner Wiedergabe des Index ein Unterschied
zwischen zwei Normalenindizes allein durch Unterschiede zwischen Längen- und
Breiteninformationen der Normalenindizes wiedergegeben werden kann, wenn andere Komponenten
der Wiedergabe im Übrigen identisch sind, und
wobei selbst dann, wenn andere Informationen geographisch benachbart jedoch nicht
identisch sind, ein Unterschreiten und/oder Überschreiten von Längen- und Breitendifferenz
Informationen wiedergeben kann, wie andere Komponenten der Wiedergabe zu modifizieren
sind.
15. System nach einem der Ansprüche 10 bis 14, wobei der Index zumindest eine Eigenschaft
hat, die ausgewählt wird aus der Gruppe, die besteht aus (i) der Index umfaßt Bits einer
Indexwiedergabe, welche geradlinige Wiedergabevorzeichenbits einer wiederzugebenden
Normalen aufweist, (ii) der Index umfaßt zumindest ein Bit, welches mögliche Faltungen
einer absoluten Größe einer geradlinigen Wiedergabe der wiederzugebenden Normalen
spezifiziert durch zumindest eine Faltungsebene x = y, x = z, y = z, so daß eine gefaltete Normale mit
Sicherheit auf einer bekannten Seite der Faltungsebene liegt, (iii) der Index umfaßt Bits,
welche Längeninformationen und Breiteninformationen der Normalen repräsentieren, (iv) der
Index ist so definiert, daß er Bits von Oktanteninformationen, Bits von Sextanteninformationen
und zusätzliche Informationsfelder über Länge und Breite der gefalteten Normalen aufweist,
(v) der Index umfaßt Bits, welche Längeninformationen und Breiteninformationen der
Normalen repräsentieren und umfaßt weiterhin Bits von Oktanteninformationen, Bits von
Sextanteninformationen und zusätzliche Informationsfelder über Länge und Breite der gefalteten
Normalen, (vi) der Index ist so definiert, daß er drei Bits von Oktanteninformationen, drei Bits
von Sextanteninformationen und zwei zusätzliche Informationsfelder über Länge und Breite
der gefalteten Normalen umfaßt, und (vii) der Index umfaßt Bits, welche
Längeninformationen und Breiteninformationen der Normalen repräsentieren, und umfaßt weiterhin drei Bits
von Oktanteninformationen, drei Bits von Sextanteninformationen und zwei zusätzliche
Informationsfelder über Länge und Breite der gefalteten Normalen.
16. System nach einem der Ansprüche 10 bis 15, wobei die Komprimierungseinheit zumindest
teilweise eine Prozedur verwendet, die ausgewählt wir aus der Gruppe, die besteht aus
(i) einem Huffman Komprimierungsvorgang, (ii) einer Variante eines Huffman
Komprimierungsvorganges, (iii) einer arithmetischen Codierung und (iv) einer Variante der
arithmetischen Codierung.
17. System nach einem der Ansprüche 10 bis 16, wobei die Komprimierungseinheit in der Lage
ist, die Deltakompression variabler Länge auf die Oberflächeneigenschaften im Anschluß an
die Quantisierung durch die Quantisierungseinheit durchzuführen.
18. System nach einem der Ansprüche 10 bis 16, wobei die Komprimierungseinheit so
betreibbar ist, daß sie die Deltakompression variabler Länge auf unquantisierte
Oberflächeneigenschaften anwenden kann.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/511,294 US5793371A (en) | 1995-08-04 | 1995-08-04 | Method and apparatus for geometric compression of three-dimensional graphics data |
Publications (2)
Publication Number | Publication Date |
---|---|
DE69624636D1 DE69624636D1 (de) | 2002-12-12 |
DE69624636T2 true DE69624636T2 (de) | 2003-07-24 |
Family
ID=24034288
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE69635623T Expired - Fee Related DE69635623T2 (de) | 1995-08-04 | 1996-08-05 | System und Verfahren zur Kompression und Dekompression von Daten |
DE69635624T Expired - Fee Related DE69635624T2 (de) | 1995-08-04 | 1996-08-05 | System und Verfahren zur Kompression und Dekompression von Daten |
DE69624636T Expired - Fee Related DE69624636T2 (de) | 1995-08-04 | 1996-08-05 | Verfahren und Vorrichtung zur geometrischen Komprimierung von dreidimensionelen Grafiken |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE69635623T Expired - Fee Related DE69635623T2 (de) | 1995-08-04 | 1996-08-05 | System und Verfahren zur Kompression und Dekompression von Daten |
DE69635624T Expired - Fee Related DE69635624T2 (de) | 1995-08-04 | 1996-08-05 | System und Verfahren zur Kompression und Dekompression von Daten |
Country Status (4)
Country | Link |
---|---|
US (7) | US5793371A (de) |
EP (3) | EP0957451B1 (de) |
JP (1) | JP3212885B2 (de) |
DE (3) | DE69635623T2 (de) |
Families Citing this family (323)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5805933A (en) * | 1994-12-28 | 1998-09-08 | Canon Kabushiki Kaisha | Image processing apparatus, image processing method and network system |
DE19507564A1 (de) * | 1995-03-03 | 1996-09-05 | Delphi Systemsimulation Gmbh | Verfahren zur Mustererkennung und Verfahren zum Erstellen eines n-dimensionalen Objektes |
US5793371A (en) | 1995-08-04 | 1998-08-11 | Sun Microsystems, Inc. | Method and apparatus for geometric compression of three-dimensional graphics data |
US6215500B1 (en) | 1995-08-04 | 2001-04-10 | Sun Microsystems, Inc. | Compression of three-dimensional geometry data representing a regularly tiled surface portion of a graphical object |
US6747644B1 (en) | 1995-08-04 | 2004-06-08 | Sun Microsystems, Inc. | Decompression of surface normals in three-dimensional graphics data |
US6018353A (en) * | 1995-08-04 | 2000-01-25 | Sun Microsystems, Inc. | Three-dimensional graphics accelerator with an improved vertex buffer for more efficient vertex processing |
US6256041B1 (en) | 1995-08-04 | 2001-07-03 | Sun Microsystems, Inc. | Decompression of three-dimensional geometry data representing a regularly tiled surface portion of a graphical object |
US5842004A (en) * | 1995-08-04 | 1998-11-24 | Sun Microsystems, Inc. | Method and apparatus for decompression of compressed geometric three-dimensional graphics data |
US6525722B1 (en) * | 1995-08-04 | 2003-02-25 | Sun Microsystems, Inc. | Geometry compression for regular and irregular mesh structures |
FR2740888B1 (fr) * | 1995-11-03 | 1997-11-28 | Thomson Csf | Procede de generation dynamique d'images synthetiques a niveau de detail automatique, et dispositif de mise en oeuvre |
US5923329A (en) * | 1996-06-24 | 1999-07-13 | National Research Council Of Canada | Method of grid generation about or within a 3 dimensional object |
KR100203266B1 (ko) * | 1996-07-09 | 1999-06-15 | 윤종용 | 윤곽선복호화장치 |
US5959631A (en) * | 1996-08-28 | 1999-09-28 | Hewlett-Packard Company | Hardware and software for the visualization of three-dimensional data sets |
US6088484A (en) * | 1996-11-08 | 2000-07-11 | Hughes Electronics Corporation | Downloading of personalization layers for symbolically compressed objects |
AU744329B2 (en) * | 1997-04-30 | 2002-02-21 | Canon Kabushiki Kaisha | Data normalization circuit and method |
US6707463B1 (en) | 1997-04-30 | 2004-03-16 | Canon Kabushiki Kaisha | Data normalization technique |
US6259456B1 (en) | 1997-04-30 | 2001-07-10 | Canon Kabushiki Kaisha | Data normalization techniques |
US6094199A (en) * | 1997-05-23 | 2000-07-25 | University Of Washington | 3D objects morphing employing skeletons indicating symmetric differences to define intermediate objects used in morphing |
US6137836A (en) * | 1997-05-28 | 2000-10-24 | Nokia Mobile Phones Limited | Communication of pictorial data by encoded primitive component pictures |
US5990894A (en) * | 1997-06-16 | 1999-11-23 | Sun Microsystems, Inc. | Method for implementing the power function DP and computer graphics system employing the same |
KR19990002045A (ko) * | 1997-06-18 | 1999-01-15 | 양승택 | 예측 잉여신호 벡터 양자화를 이용한 3차원 그래픽 모델의 정점 위치 다단계 압축 방법 |
EP0889440B9 (de) * | 1997-06-30 | 2004-03-17 | Sun Microsystems, Inc. | Verfahren und Vorrichtung zur geometrischen Komprimierung von dreimensionalen Grafiken |
US6118452A (en) * | 1997-08-05 | 2000-09-12 | Hewlett-Packard Company | Fragment visibility pretest system and methodology for improved performance of a graphics system |
JP3630934B2 (ja) | 1997-08-29 | 2005-03-23 | 三洋電機株式会社 | テクスチャ記録方法 |
JP3732317B2 (ja) * | 1997-09-17 | 2006-01-05 | 株式会社ソニー・コンピュータエンタテインメント | 情報処理装置および方法、並びに伝送媒体 |
US6191791B1 (en) * | 1997-09-30 | 2001-02-20 | Hewlett-Packard Company | Methods for high precision, memory efficient surface normal compression and expansion |
US6064394A (en) * | 1997-10-31 | 2000-05-16 | Autodesk, Inc. | Texture mapping using a plane normal to a selected triangle and using a (U,V) origin thereof to preserve texture size upon surface scaling |
JP3863652B2 (ja) * | 1997-12-19 | 2006-12-27 | テキサス インスツルメンツ インコーポレイテツド | 可変長コードの整列化装置 |
US6028607A (en) * | 1998-01-15 | 2000-02-22 | Sun Microsystems, Inc. | Method of producing a sequence of triangles from a vertex raster with and without half resolution edges while decompressing a compressed geometry stream |
US7190362B1 (en) * | 1998-01-20 | 2007-03-13 | Nicholas Baker | System and method for organizing data for a 3-dimensional graphics pipeline |
US6263496B1 (en) | 1998-02-03 | 2001-07-17 | Amazing Media, Inc. | Self modifying scene graph |
US6243856B1 (en) | 1998-02-03 | 2001-06-05 | Amazing Media, Inc. | System and method for encoding a scene graph |
US6496186B1 (en) | 1998-02-17 | 2002-12-17 | Sun Microsystems, Inc. | Graphics system having a super-sampled sample buffer with generation of output pixels using selective adjustment of filtering for reduced artifacts |
US6717578B1 (en) * | 1998-02-17 | 2004-04-06 | Sun Microsystems, Inc. | Graphics system with a variable-resolution sample buffer |
WO1999041706A1 (en) | 1998-02-17 | 1999-08-19 | Sun Microsystems, Inc. | Graphics system with variable resolution super-sampling |
US6483504B1 (en) | 1998-02-17 | 2002-11-19 | Sun Microsystems, Inc. | Graphics system having a super sampled-sample buffer with efficient storage of sample position information |
US6624823B2 (en) | 1998-02-17 | 2003-09-23 | Sun Microsystems, Inc. | Graphics system configured to determine triangle orientation by octant identification and slope comparison |
US6167159A (en) * | 1998-04-30 | 2000-12-26 | Virtue Ltd. | Triangle mesh compression |
JPH11331700A (ja) * | 1998-05-15 | 1999-11-30 | Sony Corp | 画像処理装置および画像処理方法 |
US6055000A (en) * | 1998-05-28 | 2000-04-25 | Snk Corporation | Storage memory for images |
US6337684B1 (en) * | 1998-05-29 | 2002-01-08 | Hewlett-Packard Company | Surface normal compression/decompression storing two vector components |
EP1086412A4 (de) | 1998-06-08 | 2008-05-07 | Microsoft Corp | Komprimierung von zeitabhängige geometrie |
US6650327B1 (en) * | 1998-06-16 | 2003-11-18 | Silicon Graphics, Inc. | Display system having floating point rasterization and floating point framebuffering |
US6243081B1 (en) * | 1998-07-31 | 2001-06-05 | Hewlett-Packard Company | Data structure for efficient retrieval of compressed texture data from a memory system |
KR100294926B1 (ko) * | 1998-08-29 | 2001-07-12 | 윤종용 | 점진적인 삼차원 메쉬 정보의 부호화/복호화 방법 및 장치 |
JP2000115558A (ja) * | 1998-10-08 | 2000-04-21 | Mitsubishi Electric Corp | 色特性記述装置および色管理装置および画像変換装置ならびに色補正方法 |
US6304275B1 (en) * | 1998-10-31 | 2001-10-16 | Hewlett-Packard Company | Memory efficient surface normal decompression |
US6175369B1 (en) * | 1998-10-31 | 2001-01-16 | Hewlett-Packard Company | High performance surface normal decompression |
JP2000165641A (ja) * | 1998-11-24 | 2000-06-16 | Matsushita Electric Ind Co Ltd | 画像処理方法,画像処理装置およびデータ記憶媒体 |
KR100294928B1 (ko) * | 1998-11-28 | 2001-07-12 | 윤종용 | 2차원 또는 3차원 메쉬정보 중의 특성정보 부호화장치 및 그방법 |
US6075901A (en) * | 1998-12-04 | 2000-06-13 | France Telecom | Method and system for predictive encoding of arrays of data |
US6204854B1 (en) * | 1998-12-04 | 2001-03-20 | France Telecom | Method and system for encoding rotations and normals in 3D generated scenes |
US6624761B2 (en) * | 1998-12-11 | 2003-09-23 | Realtime Data, Llc | Content independent data compression method and system |
JP2002535791A (ja) * | 1999-01-27 | 2002-10-22 | エンバヤ インコーポレイテッド | 三角形網目のプログレッシブ圧縮 |
US6417861B1 (en) | 1999-02-17 | 2002-07-09 | Sun Microsystems, Inc. | Graphics system with programmable sample positions |
US6604158B1 (en) * | 1999-03-11 | 2003-08-05 | Realtime Data, Llc | System and methods for accelerated data storage and retrieval |
US6601104B1 (en) | 1999-03-11 | 2003-07-29 | Realtime Data Llc | System and methods for accelerated data storage and retrieval |
US6429867B1 (en) | 1999-03-15 | 2002-08-06 | Sun Microsystems, Inc. | System and method for generating and playback of three-dimensional movies |
US6356457B1 (en) | 1999-06-07 | 2002-03-12 | Sun Microsystems, Inc. | Circuit card support mechanism and method |
US6459429B1 (en) | 1999-06-14 | 2002-10-01 | Sun Microsystems, Inc. | Segmenting compressed graphics data for parallel decompression and rendering |
US7071935B1 (en) | 1999-06-14 | 2006-07-04 | Sun Microsystems, Inc. | Graphics system with just-in-time decompression of compressed graphics data |
US6628277B1 (en) | 1999-06-14 | 2003-09-30 | Sun Microsystems, Inc. | Decompression of three-dimensional graphics data using mesh buffer references to reduce redundancy of processing |
US6577769B1 (en) | 1999-09-18 | 2003-06-10 | Wildtangent, Inc. | Data compression through adaptive data size reduction |
US6512515B1 (en) | 1999-09-18 | 2003-01-28 | Wildtangent | Data compression through motion and geometric relation estimation functions |
US6628836B1 (en) | 1999-10-05 | 2003-09-30 | Hewlett-Packard Development Company, L.P. | Sort middle, screen space, graphics geometry compression through redundancy elimination |
US6393154B1 (en) | 1999-11-18 | 2002-05-21 | Quikcat.Com, Inc. | Method and apparatus for digital image compression using a dynamical system |
US7031538B2 (en) * | 1999-12-17 | 2006-04-18 | Level Set Systems, Inc. | Method and apparatus for feature-based quantization and compression of data |
US6748457B2 (en) * | 2000-02-03 | 2004-06-08 | Realtime Data, Llc | Data storewidth accelerator |
US20030191876A1 (en) * | 2000-02-03 | 2003-10-09 | Fallon James J. | Data storewidth accelerator |
JP3753584B2 (ja) * | 2000-02-15 | 2006-03-08 | 富士通株式会社 | 画像処理装置 |
US6724385B2 (en) | 2000-03-08 | 2004-04-20 | Sony Computer Entertainment Inc. | Method of replaying game, recording medium, program, and entertainment system |
US7053906B2 (en) * | 2000-03-08 | 2006-05-30 | Sony Computer Entertainment Inc. | Texture mapping method, recording medium, program, and program executing apparatus |
US6525725B1 (en) * | 2000-03-15 | 2003-02-25 | Sun Microsystems, Inc. | Morphing decompression in a graphics system |
US6426755B1 (en) | 2000-05-16 | 2002-07-30 | Sun Microsystems, Inc. | Graphics system using sample tags for blur |
US6956576B1 (en) | 2000-05-16 | 2005-10-18 | Sun Microsystems, Inc. | Graphics system using sample masks for motion blur, depth of field, and transparency |
US7062087B1 (en) | 2000-05-16 | 2006-06-13 | International Busniness Machines Corporation | System and method for optimizing color compression using transparency control bits |
US7167259B2 (en) | 2000-05-16 | 2007-01-23 | International Business Machines Corporation | System and method for merging line work objects using tokenization and selective compression |
IL136233A (en) | 2000-05-18 | 2009-05-04 | Whitmaps Us Foundation Llc | Method and system for retrieving map data via a communication network |
WO2001093525A2 (en) * | 2000-05-26 | 2001-12-06 | Citrix Systems, Inc. | Method and system for efficiently reducing graphical display data for transmission over a low bandwidth transport protocol mechanism |
GB0013764D0 (en) * | 2000-06-07 | 2000-07-26 | Koninkl Philips Electronics Nv | Animated graphic image generation and coding |
AU2001268702A1 (en) | 2000-06-22 | 2002-01-02 | Auckland Uniservices Limited | Non-linear morphing of faces and their dynamics |
KR100382106B1 (ko) * | 2000-07-12 | 2003-05-01 | 학교법인연세대학교 | Mpeg 기반 3d그래픽 가속기 |
JP3530125B2 (ja) | 2000-09-27 | 2004-05-24 | 彰 川中 | 構造化ポリゴン・メッシュ・データの形成方法および装置、記憶媒体 |
US8692695B2 (en) | 2000-10-03 | 2014-04-08 | Realtime Data, Llc | Methods for encoding and decoding data |
US9143546B2 (en) * | 2000-10-03 | 2015-09-22 | Realtime Data Llc | System and method for data feed acceleration and encryption |
US7417568B2 (en) * | 2000-10-03 | 2008-08-26 | Realtime Data Llc | System and method for data feed acceleration and encryption |
US7689621B1 (en) * | 2000-11-06 | 2010-03-30 | Navteq North America, Llc | Multi-dimensional spatial index for a geographic database |
US6897977B1 (en) * | 2000-11-20 | 2005-05-24 | Hall Aluminum Llc | Lossy method for compressing pictures and video |
US6618831B2 (en) * | 2000-12-21 | 2003-09-09 | Intel Corporation | Increasing performance with memory compression |
US7587520B1 (en) | 2001-01-24 | 2009-09-08 | 3Dlabs Inc. Ltd. | Image display system with visual server |
US7386046B2 (en) | 2001-02-13 | 2008-06-10 | Realtime Data Llc | Bandwidth sensitive data compression and decompression |
CA2372969C (en) * | 2001-02-28 | 2008-09-16 | Samsung Electronics Co., Ltd. | Encoding method and apparatus of deformation information of 3d object |
US7392287B2 (en) * | 2001-03-27 | 2008-06-24 | Hemisphere Ii Investment Lp | Method and apparatus for sharing information using a handheld device |
ES2228910T3 (es) * | 2001-07-04 | 2005-04-16 | Okyz | Metodo y sistema de exportacion de datos asociados a entidades geometricas bidimensionales o tridimensionales. |
US7564460B2 (en) | 2001-07-16 | 2009-07-21 | Microsoft Corporation | Systems and methods for providing intermediate targets in a graphics system |
US6941516B2 (en) * | 2001-08-06 | 2005-09-06 | Apple Computer, Inc. | Object movie exporter |
US6961803B1 (en) * | 2001-08-08 | 2005-11-01 | Pasternak Solutions Llc | Sliced crossbar architecture with no inter-slice communication |
KR100420860B1 (ko) * | 2001-08-13 | 2004-03-02 | 학교법인연세대학교 | 가중치 벡터합을 이용한 3차원 그래픽 데이터의 위상 압축방법 |
TW580642B (en) * | 2001-08-23 | 2004-03-21 | Ulead Systems Inc | Processing method using 2-dimension graphics to draw 3-dimension objects |
WO2003021970A1 (en) * | 2001-09-04 | 2003-03-13 | Faroudja Cognition Systems, Inc. | Low bandwidth video compression |
US6931367B2 (en) * | 2001-11-29 | 2005-08-16 | Faurecia Exhaust Systems, Inc. | Optimal rib design method for exhaust components |
US7158961B1 (en) * | 2001-12-31 | 2007-01-02 | Google, Inc. | Methods and apparatus for estimating similarity |
US6816161B2 (en) * | 2002-01-30 | 2004-11-09 | Sun Microsystems, Inc. | Vertex assembly buffer and primitive launch buffer |
US6847369B2 (en) * | 2002-01-30 | 2005-01-25 | Sun Microsystems, Inc. | Optimized packing of loose data in a graphics queue |
US7266254B2 (en) * | 2002-02-13 | 2007-09-04 | Canon Kabushiki Kaisha | Data processing apparatus, image processing apparatus, and method therefor |
US6995769B2 (en) * | 2002-03-21 | 2006-02-07 | Hewlett-Packard Development Company, L.P. | Systems and methods for compressing rasterization setup data within a sort middle graphics architecture |
US7219352B2 (en) | 2002-04-15 | 2007-05-15 | Microsoft Corporation | Methods and apparatuses for facilitating processing of interlaced video images for progressive video displays |
US7451457B2 (en) * | 2002-04-15 | 2008-11-11 | Microsoft Corporation | Facilitating interaction between video renderers and graphics device drivers |
JP4718763B2 (ja) * | 2002-04-15 | 2011-07-06 | マイクロソフト コーポレーション | ビデオ・レンダラーとグラフィックス・デバイス・ドライバの間の相互作用を促進すること |
US7230616B2 (en) * | 2002-07-31 | 2007-06-12 | International Business Machines Corporation | Bi-level iso-surface compression |
US20050131660A1 (en) * | 2002-09-06 | 2005-06-16 | Joseph Yadegar | Method for content driven image compression |
US8019788B1 (en) * | 2002-09-30 | 2011-09-13 | Siemens Product Lifecycle Management Software Inc. | Data compression and file segmentation in directmodel JT datastores |
US20060126718A1 (en) * | 2002-10-01 | 2006-06-15 | Avocent Corporation | Video compression encoder |
US7321623B2 (en) * | 2002-10-01 | 2008-01-22 | Avocent Corporation | Video compression system |
US6816169B2 (en) * | 2002-10-09 | 2004-11-09 | Evans & Sutherland Computer Corporation | System and method for run-time integration of an inset geometry into a background geometry |
WO2004036504A1 (en) * | 2002-10-15 | 2004-04-29 | Nokia Corporation | Three dimensional image processing |
US7254696B2 (en) * | 2002-12-12 | 2007-08-07 | Alacritech, Inc. | Functional-level instruction-set computer architecture for processing application-layer content-service requests such as file-access requests |
US7136891B2 (en) * | 2002-12-12 | 2006-11-14 | International Business Machines Corporation | Arithmetic and relational operations |
US20040174364A1 (en) * | 2003-03-03 | 2004-09-09 | Shehane Patrick D. | Rendering patterned lines in a graphics system |
KR20040085470A (ko) * | 2003-03-31 | 2004-10-08 | 삼성전자주식회사 | 색변환장치 및 색변환방법 |
US7266479B2 (en) * | 2003-06-18 | 2007-09-04 | Cadence Designs Systems, Inc. | System and method for high-order accurate device model approximation |
JP2007531078A (ja) * | 2003-07-16 | 2007-11-01 | ハンヤン ハク ウォン カンパニー,リミテッド | 3次元メッシュ情報の符号化及び復号化方法並びにその装置 |
US8218624B2 (en) * | 2003-07-18 | 2012-07-10 | Microsoft Corporation | Fractional quantization step sizes for high bit rates |
US7580584B2 (en) * | 2003-07-18 | 2009-08-25 | Microsoft Corporation | Adaptive multiple quantization |
US7602851B2 (en) * | 2003-07-18 | 2009-10-13 | Microsoft Corporation | Intelligent differential quantization of video coding |
US10554985B2 (en) | 2003-07-18 | 2020-02-04 | Microsoft Technology Licensing, Llc | DC coefficient signaling at small quantization step sizes |
US7738554B2 (en) | 2003-07-18 | 2010-06-15 | Microsoft Corporation | DC coefficient signaling at small quantization step sizes |
US20050017968A1 (en) * | 2003-07-21 | 2005-01-27 | Stephan Wurmlin | Differential stream of point samples for real-time 3D video |
US9560371B2 (en) * | 2003-07-30 | 2017-01-31 | Avocent Corporation | Video compression system |
US7643675B2 (en) * | 2003-08-01 | 2010-01-05 | Microsoft Corporation | Strategies for processing image information using a color information data structure |
US7158668B2 (en) * | 2003-08-01 | 2007-01-02 | Microsoft Corporation | Image processing using linear light values and other image processing improvements |
US7002586B2 (en) * | 2003-08-29 | 2006-02-21 | Sun Microsystems, Inc. | Method and apparatus for vertex splitting in a graphics system |
US6897871B1 (en) * | 2003-11-20 | 2005-05-24 | Ati Technologies Inc. | Graphics processing architecture employing a unified shader |
US7432925B2 (en) * | 2003-11-21 | 2008-10-07 | International Business Machines Corporation | Techniques for representing 3D scenes using fixed point data |
JP2005184232A (ja) * | 2003-12-17 | 2005-07-07 | Sony Corp | 符号化装置、プログラム、およびデータ処理方法 |
SE526226C2 (sv) * | 2003-12-19 | 2005-08-02 | Ericsson Telefon Ab L M | Bildbehandling |
SE0401850D0 (sv) * | 2003-12-19 | 2004-07-08 | Ericsson Telefon Ab L M | Image processing |
US9081681B1 (en) * | 2003-12-19 | 2015-07-14 | Nvidia Corporation | Method and system for implementing compressed normal maps |
US7460737B2 (en) | 2004-02-12 | 2008-12-02 | Hoshiko Llc | Method and apparatus for photograph finding |
KR20060047436A (ko) * | 2004-04-23 | 2006-05-18 | 니혼 소아 가부시키가이샤 | 2차원 및 3차원 도형의 데이터를 컴퓨터의 메모리에기록하는 데이터 구조, 프로그램 및 기록 매체 |
US7801383B2 (en) * | 2004-05-15 | 2010-09-21 | Microsoft Corporation | Embedded scalar quantizers with arbitrary dead-zone ratios |
US7529418B2 (en) * | 2004-05-20 | 2009-05-05 | Hewlett-Packard Development Company, L.P. | Geometry and view assisted transmission of graphics image streams |
US8316068B2 (en) * | 2004-06-04 | 2012-11-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Memory compression |
US7457461B2 (en) * | 2004-06-25 | 2008-11-25 | Avocent Corporation | Video compression noise immunity |
US7327365B2 (en) * | 2004-07-23 | 2008-02-05 | Microsoft Corporation | Shell texture functions |
US7885955B2 (en) | 2005-08-23 | 2011-02-08 | Ricoh Co. Ltd. | Shared document annotation |
US8868555B2 (en) * | 2006-07-31 | 2014-10-21 | Ricoh Co., Ltd. | Computation of a recongnizability score (quality predictor) for image retrieval |
US7812986B2 (en) * | 2005-08-23 | 2010-10-12 | Ricoh Co. Ltd. | System and methods for use of voice mail and email in a mixed media environment |
US8332401B2 (en) | 2004-10-01 | 2012-12-11 | Ricoh Co., Ltd | Method and system for position-based image matching in a mixed media environment |
US8335789B2 (en) | 2004-10-01 | 2012-12-18 | Ricoh Co., Ltd. | Method and system for document fingerprint matching in a mixed media environment |
US9384619B2 (en) | 2006-07-31 | 2016-07-05 | Ricoh Co., Ltd. | Searching media content for objects specified using identifiers |
US8086038B2 (en) | 2007-07-11 | 2011-12-27 | Ricoh Co., Ltd. | Invisible junction features for patch recognition |
US8989431B1 (en) | 2007-07-11 | 2015-03-24 | Ricoh Co., Ltd. | Ad hoc paper-based networking with mixed media reality |
US9171202B2 (en) | 2005-08-23 | 2015-10-27 | Ricoh Co., Ltd. | Data organization and access for mixed media document system |
US8176054B2 (en) * | 2007-07-12 | 2012-05-08 | Ricoh Co. Ltd | Retrieving electronic documents by converting them to synthetic text |
US8156427B2 (en) | 2005-08-23 | 2012-04-10 | Ricoh Co. Ltd. | User interface for mixed media reality |
US8521737B2 (en) | 2004-10-01 | 2013-08-27 | Ricoh Co., Ltd. | Method and system for multi-tier image matching in a mixed media environment |
US9405751B2 (en) | 2005-08-23 | 2016-08-02 | Ricoh Co., Ltd. | Database for mixed media document system |
US8510283B2 (en) | 2006-07-31 | 2013-08-13 | Ricoh Co., Ltd. | Automatic adaption of an image recognition system to image capture devices |
US8144921B2 (en) | 2007-07-11 | 2012-03-27 | Ricoh Co., Ltd. | Information retrieval using invisible junctions and geometric constraints |
US8276088B2 (en) * | 2007-07-11 | 2012-09-25 | Ricoh Co., Ltd. | User interface for three-dimensional navigation |
US8156116B2 (en) | 2006-07-31 | 2012-04-10 | Ricoh Co., Ltd | Dynamic presentation of targeted information in a mixed media reality recognition system |
US8825682B2 (en) | 2006-07-31 | 2014-09-02 | Ricoh Co., Ltd. | Architecture for mixed media reality retrieval of locations and registration of images |
US8856108B2 (en) | 2006-07-31 | 2014-10-07 | Ricoh Co., Ltd. | Combining results of image retrieval processes |
US8949287B2 (en) | 2005-08-23 | 2015-02-03 | Ricoh Co., Ltd. | Embedding hot spots in imaged documents |
US7702673B2 (en) | 2004-10-01 | 2010-04-20 | Ricoh Co., Ltd. | System and methods for creation and use of a mixed media environment |
US7970171B2 (en) | 2007-01-18 | 2011-06-28 | Ricoh Co., Ltd. | Synthetic image and video generation from ground truth data |
US9530050B1 (en) | 2007-07-11 | 2016-12-27 | Ricoh Co., Ltd. | Document annotation sharing |
US8369655B2 (en) | 2006-07-31 | 2013-02-05 | Ricoh Co., Ltd. | Mixed media reality recognition using multiple specialized indexes |
US7991778B2 (en) * | 2005-08-23 | 2011-08-02 | Ricoh Co., Ltd. | Triggering actions with captured input in a mixed media environment |
US8385589B2 (en) | 2008-05-15 | 2013-02-26 | Berna Erol | Web-based content detection in images, extraction and recognition |
US8195659B2 (en) | 2005-08-23 | 2012-06-05 | Ricoh Co. Ltd. | Integration and use of mixed media documents |
US8005831B2 (en) | 2005-08-23 | 2011-08-23 | Ricoh Co., Ltd. | System and methods for creation and use of a mixed media environment with geographic location information |
US8600989B2 (en) | 2004-10-01 | 2013-12-03 | Ricoh Co., Ltd. | Method and system for image matching in a mixed media environment |
US7920759B2 (en) | 2005-08-23 | 2011-04-05 | Ricoh Co. Ltd. | Triggering applications for distributed action execution and use of mixed media recognition as a control input |
US8184155B2 (en) | 2007-07-11 | 2012-05-22 | Ricoh Co. Ltd. | Recognition and tracking using invisible junctions |
US9373029B2 (en) | 2007-07-11 | 2016-06-21 | Ricoh Co., Ltd. | Invisible junction feature recognition for document security or annotation |
US7334116B2 (en) * | 2004-10-06 | 2008-02-19 | Sony Computer Entertainment Inc. | Bit manipulation on data in a bitstream that is stored in a memory having an address boundary length |
US8078656B1 (en) | 2004-11-16 | 2011-12-13 | Nvidia Corporation | Data decompression with extra precision |
US7961195B1 (en) | 2004-11-16 | 2011-06-14 | Nvidia Corporation | Two component texture map compression |
US7702875B1 (en) | 2004-11-18 | 2010-04-20 | Sun Microsystems, Inc. | System and method for memory compression |
US7928988B1 (en) | 2004-11-19 | 2011-04-19 | Nvidia Corporation | Method and system for texture block swapping memory management |
US7916149B1 (en) * | 2005-01-04 | 2011-03-29 | Nvidia Corporation | Block linear memory ordering of texture data |
KR100668714B1 (ko) * | 2005-01-14 | 2007-01-16 | 한국전자통신연구원 | 효과적인 텍스처 매핑을 위한 3차원 메쉬 정보의 텍스처좌표 부호화 및 복호화 방법 |
WO2006116045A2 (en) * | 2005-04-22 | 2006-11-02 | Altrix Logic, Inc. | Variable precision processor |
CN101189017B (zh) * | 2005-05-02 | 2013-04-03 | 奥古露丝创新科学公司 | 在牙科应用中使用氧化还原电位水溶液的方法 |
US8422546B2 (en) | 2005-05-25 | 2013-04-16 | Microsoft Corporation | Adaptive video encoding using a perceptual model |
KR100740249B1 (ko) * | 2005-10-19 | 2007-07-18 | (주) 인텍플러스 | 영상 측정 장치 및 그 방법 |
US7555570B2 (en) | 2006-02-17 | 2009-06-30 | Avocent Huntsville Corporation | Device and method for configuring a target device |
US8718147B2 (en) * | 2006-02-17 | 2014-05-06 | Avocent Huntsville Corporation | Video compression algorithm |
US8503536B2 (en) * | 2006-04-07 | 2013-08-06 | Microsoft Corporation | Quantization adjustments for DC shift artifacts |
US8059721B2 (en) | 2006-04-07 | 2011-11-15 | Microsoft Corporation | Estimating sample-domain distortion in the transform domain with rounding compensation |
US7974340B2 (en) * | 2006-04-07 | 2011-07-05 | Microsoft Corporation | Adaptive B-picture quantization control |
US8130828B2 (en) | 2006-04-07 | 2012-03-06 | Microsoft Corporation | Adjusting quantization to preserve non-zero AC coefficients |
US7995649B2 (en) | 2006-04-07 | 2011-08-09 | Microsoft Corporation | Quantization adjustment based on texture level |
US7787691B2 (en) * | 2006-04-11 | 2010-08-31 | Telefonaktiebolaget Lm Ericsson (Publ) | High quality image processing |
WO2007127452A2 (en) * | 2006-04-28 | 2007-11-08 | Avocent Corporation | Dvc delta commands |
US7639249B2 (en) * | 2006-05-05 | 2009-12-29 | Microsoft Corporation | Direct inset beveling of geometric figures |
US8711925B2 (en) * | 2006-05-05 | 2014-04-29 | Microsoft Corporation | Flexible quantization |
US8207965B2 (en) * | 2006-07-11 | 2012-06-26 | Adobe Systems Incorporated | Rewritable compression of triangulated data |
US8031957B1 (en) * | 2006-07-11 | 2011-10-04 | Adobe Systems Incorporated | Rewritable lossy compression of graphical data |
US8073263B2 (en) | 2006-07-31 | 2011-12-06 | Ricoh Co., Ltd. | Multi-classifier selection and monitoring for MMR-based image recognition |
US9176984B2 (en) | 2006-07-31 | 2015-11-03 | Ricoh Co., Ltd | Mixed media reality retrieval of differentially-weighted links |
US8676810B2 (en) | 2006-07-31 | 2014-03-18 | Ricoh Co., Ltd. | Multiple index mixed media reality recognition using unequal priority indexes |
US9020966B2 (en) | 2006-07-31 | 2015-04-28 | Ricoh Co., Ltd. | Client device for interacting with a mixed media reality recognition system |
US8201076B2 (en) | 2006-07-31 | 2012-06-12 | Ricoh Co., Ltd. | Capturing symbolic information from documents upon printing |
US9063952B2 (en) | 2006-07-31 | 2015-06-23 | Ricoh Co., Ltd. | Mixed media reality recognition with image tracking |
US8489987B2 (en) | 2006-07-31 | 2013-07-16 | Ricoh Co., Ltd. | Monitoring and analyzing creation and usage of visual content using image and hotspot interaction |
US8594441B1 (en) | 2006-09-12 | 2013-11-26 | Nvidia Corporation | Compressing image-based data using luminance |
JP4932504B2 (ja) * | 2007-01-18 | 2012-05-16 | 富士フイルム株式会社 | 画像処理方法、装置及びプログラム並びに撮像装置 |
US8238424B2 (en) * | 2007-02-09 | 2012-08-07 | Microsoft Corporation | Complexity-based adaptive preprocessing for multiple-pass video compression |
US7460038B2 (en) | 2007-03-12 | 2008-12-02 | Citrix Systems, Inc. | Systems and methods of clustered sharing of compression histories |
US7865585B2 (en) | 2007-03-12 | 2011-01-04 | Citrix Systems, Inc. | Systems and methods for providing dynamic ad hoc proxy-cache hierarchies |
US7532134B2 (en) | 2007-03-12 | 2009-05-12 | Citrix Systems, Inc. | Systems and methods for sharing compression histories between multiple devices |
US8255570B2 (en) | 2007-03-12 | 2012-08-28 | Citrix Systems, Inc. | Systems and methods of compression history expiration and synchronization |
US7619545B2 (en) | 2007-03-12 | 2009-11-17 | Citrix Systems, Inc. | Systems and methods of using application and protocol specific parsing for compression |
US7827237B2 (en) * | 2007-03-12 | 2010-11-02 | Citrix Systems, Inc. | Systems and methods for identifying long matches of data in a compression history |
US8498335B2 (en) * | 2007-03-26 | 2013-07-30 | Microsoft Corporation | Adaptive deadzone size adjustment in quantization |
US20080240594A1 (en) * | 2007-03-29 | 2008-10-02 | Elena Guschina | Compression of triangle stripped data |
US8243797B2 (en) * | 2007-03-30 | 2012-08-14 | Microsoft Corporation | Regions of interest for quality adjustments |
US8031937B2 (en) * | 2007-04-04 | 2011-10-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Frame buffer compression and decompression method for graphics rendering |
US8442337B2 (en) * | 2007-04-18 | 2013-05-14 | Microsoft Corporation | Encoding adjustments for animation content |
US8331438B2 (en) | 2007-06-05 | 2012-12-11 | Microsoft Corporation | Adaptive selection of picture-level quantization parameters for predicted video pictures |
US8724895B2 (en) * | 2007-07-23 | 2014-05-13 | Nvidia Corporation | Techniques for reducing color artifacts in digital images |
US8189933B2 (en) | 2008-03-31 | 2012-05-29 | Microsoft Corporation | Classifying and controlling encoding quality for textured, dark smooth and smooth video content |
FR2929778B1 (fr) * | 2008-04-07 | 2012-05-04 | Canon Kk | Procedes et dispositifs de codage et de decodage binaire iteratif pour documents de type xml. |
US8493381B1 (en) * | 2008-04-14 | 2013-07-23 | Google Inc. | Methods and systems for geometry compression |
US8532438B2 (en) * | 2008-05-09 | 2013-09-10 | Empire Technology Development Llc | Matching images with shape descriptors |
US8502832B2 (en) * | 2008-05-30 | 2013-08-06 | Advanced Micro Devices, Inc. | Floating point texture filtering using unsigned linear interpolators and block normalizations |
US8558836B2 (en) * | 2008-05-30 | 2013-10-15 | Advanced Micro Devices, Inc. | Scalable and unified compute system |
US8897359B2 (en) | 2008-06-03 | 2014-11-25 | Microsoft Corporation | Adaptive quantization for enhancement layer video coding |
US8351715B1 (en) * | 2008-07-08 | 2013-01-08 | Lockheed Martin Corporation | Systems and processes for translating, compressing and storing solid-state model data |
US8264524B1 (en) * | 2008-09-17 | 2012-09-11 | Grandeye Limited | System for streaming multiple regions deriving from a wide-angle camera |
WO2010042578A1 (en) | 2008-10-08 | 2010-04-15 | Citrix Systems, Inc. | Systems and methods for real-time endpoint application flow control with network structure component |
US8373718B2 (en) * | 2008-12-10 | 2013-02-12 | Nvidia Corporation | Method and system for color enhancement with color volume adjustment and variable shift along luminance axis |
US8610732B2 (en) * | 2008-12-11 | 2013-12-17 | Nvidia Corporation | System and method for video memory usage for general system application |
US8325601B2 (en) * | 2009-05-08 | 2012-12-04 | Canon Kabushiki Kaisha | Reliable network streaming of a single data stream over multiple physical interfaces |
US8880716B2 (en) * | 2009-05-08 | 2014-11-04 | Canon Kabushiki Kaisha | Network streaming of a single data stream simultaneously over multiple physical interfaces |
US8396960B2 (en) * | 2009-05-08 | 2013-03-12 | Canon Kabushiki Kaisha | Efficient network utilization using multiple physical interfaces |
EP2261859A1 (de) | 2009-06-10 | 2010-12-15 | Thomson Licensing | Verfahren zur Kodierung/Dekodierung eines dreidimensionalen Maschenmodells, das eine oder mehrere Komponenten umfasst |
KR101715962B1 (ko) * | 2009-06-23 | 2017-03-13 | 톰슨 라이센싱 | 반복된 패턴을 갖는 3d 메시의 압축 |
US8385660B2 (en) | 2009-06-24 | 2013-02-26 | Ricoh Co., Ltd. | Mixed media reality indexing and retrieval for repeated content |
US8098247B2 (en) * | 2009-09-24 | 2012-01-17 | Crucs Holdings, Llc | Systems and methods for geometric data compression and encryption |
JP2011082878A (ja) * | 2009-10-09 | 2011-04-21 | Sony Corp | 符号化装置、復号装置、情報処理システム、符号化方法およびプログラム |
US8773430B2 (en) * | 2009-12-09 | 2014-07-08 | Thomson Licensing | Method for distinguishing a 3D image from a 2D image and for identifying the presence of a 3D image format by feature correspondence determination |
EP2529356A1 (de) * | 2010-01-25 | 2012-12-05 | Thomson Licensing | Verfahren zur codierung der normalen eines 3d-mesh-modells, verfahren zur decodierung der normalen eines 3d-mesh-modells, codierer und decodierer |
US8525835B1 (en) | 2010-02-24 | 2013-09-03 | The Boeing Company | Spatial data compression using implicit geometry |
EP2387004B1 (de) | 2010-05-11 | 2016-12-14 | Dassault Systèmes | Verlustfreie Kompression einer strukturierten Menge von Fließkommazahlen, insbesondere für CAD-Systeme |
US8356109B2 (en) | 2010-05-13 | 2013-01-15 | Canon Kabushiki Kaisha | Network streaming of a video stream over multiple communication channels |
US8566376B2 (en) * | 2010-07-30 | 2013-10-22 | Chevron U.S.A. Inc. | System and method for data compression using a field programmable gate array |
GB2483282B (en) * | 2010-09-03 | 2017-09-13 | Advanced Risc Mach Ltd | Data compression and decompression using relative and absolute delta values |
US9300321B2 (en) | 2010-11-05 | 2016-03-29 | University of Maribor | Light detection and ranging (LiDAR)data compression and decompression methods and apparatus |
JP6327435B2 (ja) * | 2011-03-03 | 2018-05-23 | サン パテント トラスト | 画像符号化方法、画像復号方法、画像符号化装置、及び、画像復号装置 |
JP2012221187A (ja) * | 2011-04-08 | 2012-11-12 | Fujitsu Ltd | 演算回路、演算処理装置、及び演算回路の制御方法 |
US9058331B2 (en) | 2011-07-27 | 2015-06-16 | Ricoh Co., Ltd. | Generating a conversation in a social network based on visual search results |
US20130106887A1 (en) * | 2011-10-31 | 2013-05-02 | Christopher Tremblay | Texture generation using a transformation matrix |
US8831366B1 (en) * | 2011-11-11 | 2014-09-09 | Google Inc. | Encoding and compressing three-dimensional (3D) object data models |
JP6019215B2 (ja) | 2012-04-18 | 2016-11-02 | トムソン ライセンシングThomson Licensing | 回転された3次元(3d)コンポーネントのための頂点補正方法及び装置 |
CN103425806A (zh) * | 2012-05-17 | 2013-12-04 | 鸿富锦精密工业(深圳)有限公司 | 三次元编程产品模拟系统及方法 |
US10068153B2 (en) * | 2012-08-21 | 2018-09-04 | Cognex Corporation | Trainable handheld optical character recognition systems and methods |
AU2013372617B2 (en) * | 2013-01-10 | 2019-07-04 | Interdigital Vc Holdings, Inc. | Method and apparatus for vertex error correction |
SI24693A (sl) | 2014-03-31 | 2015-10-30 | Univerza V Mariboru | Postopek za progresivno brezizgubno stiskanje podatkov, pridobljenih s prostorskimi laserskimi prebirniki |
GB2526598B (en) * | 2014-05-29 | 2018-11-28 | Imagination Tech Ltd | Allocation of primitives to primitive blocks |
US9734595B2 (en) | 2014-09-24 | 2017-08-15 | University of Maribor | Method and apparatus for near-lossless compression and decompression of 3D meshes and point clouds |
US9396409B2 (en) | 2014-09-29 | 2016-07-19 | At&T Intellectual Property I, L.P. | Object based image processing |
US9747648B2 (en) * | 2015-01-20 | 2017-08-29 | Kuo-Chun Fang | Systems and methods for publishing data on social media websites |
GB201503125D0 (en) * | 2015-02-25 | 2015-04-08 | Advanced Risc Mach Ltd | Graphics processing systems |
US9590655B2 (en) | 2015-03-27 | 2017-03-07 | Microsoft Technology Licensing, Llc | Scalable high-bandwidth architecture for lossless compression |
GB2540981B (en) * | 2015-08-03 | 2017-11-15 | Advanced Risc Mach Ltd | Graphics processing |
WO2017163106A1 (en) * | 2016-03-23 | 2017-09-28 | Phatak Amar | Method for lossless compression and regeneration of digital design data |
US9813659B1 (en) | 2016-05-11 | 2017-11-07 | Drone Racing League, Inc. | Diversity receiver |
US9971507B2 (en) * | 2016-06-27 | 2018-05-15 | Disney Enterprises, Inc. | Systems and methods for reducing storage requirement for storing information defining a virtual space |
US10313673B2 (en) | 2016-10-19 | 2019-06-04 | Google Llc | Methods and apparatus to encode and/or decode normals of geometric representations of surfaces |
US10733766B2 (en) * | 2016-10-19 | 2020-08-04 | Google, Llc | Methods and apparatus to encode and/or decode normals of geometric representations of surfaces |
US10347034B2 (en) * | 2016-11-11 | 2019-07-09 | Autodesk, Inc. | Out-of-core point rendering with dynamic shapes |
US10430975B2 (en) | 2016-11-17 | 2019-10-01 | Google Llc | Advanced k-D tree encoding for point clouds by most significant axis selection |
US10496336B2 (en) | 2016-11-17 | 2019-12-03 | Google Llc | K-D tree encoding for point clouds using deviations |
US9787321B1 (en) | 2016-11-17 | 2017-10-10 | Google Inc. | Point cloud data compression using a space-filling curve |
GB2556634B (en) | 2016-11-18 | 2020-05-27 | Advanced Risc Mach Ltd | Graphics processing systems |
US10460418B2 (en) | 2017-02-10 | 2019-10-29 | Microsoft Technology Licensing, Llc | Buffer index format and compression |
US10553035B2 (en) | 2017-06-02 | 2020-02-04 | Google Llc | Valence based implicit traversal for improved compression of triangular meshes |
US10950042B2 (en) | 2017-06-02 | 2021-03-16 | Google Llc | Guided traversal in compression of triangular meshes |
US11176288B2 (en) * | 2017-08-25 | 2021-11-16 | Microsoft Technology Licensing, Llc | Separation plane compression |
US10861196B2 (en) | 2017-09-14 | 2020-12-08 | Apple Inc. | Point cloud compression |
US10897269B2 (en) | 2017-09-14 | 2021-01-19 | Apple Inc. | Hierarchical point cloud compression |
US11818401B2 (en) | 2017-09-14 | 2023-11-14 | Apple Inc. | Point cloud geometry compression using octrees and binary arithmetic encoding with adaptive look-up tables |
US10737781B2 (en) | 2017-09-14 | 2020-08-11 | Drone Racing League, Inc. | Three-dimensional pathway tracking system |
US10909725B2 (en) | 2017-09-18 | 2021-02-02 | Apple Inc. | Point cloud compression |
US11113845B2 (en) | 2017-09-18 | 2021-09-07 | Apple Inc. | Point cloud compression using non-cubic projections and masks |
US10607373B2 (en) | 2017-11-22 | 2020-03-31 | Apple Inc. | Point cloud compression with closed-loop color conversion |
US11010928B2 (en) | 2018-04-10 | 2021-05-18 | Apple Inc. | Adaptive distance based point cloud compression |
US10909726B2 (en) | 2018-04-10 | 2021-02-02 | Apple Inc. | Point cloud compression |
US10909727B2 (en) | 2018-04-10 | 2021-02-02 | Apple Inc. | Hierarchical point cloud compression with smoothing |
US10939129B2 (en) | 2018-04-10 | 2021-03-02 | Apple Inc. | Point cloud compression |
CN108763767B (zh) * | 2018-05-30 | 2022-04-22 | 中国舰船研究设计中心 | 面向vr引擎的大数据量igs工业模型polygon转换方法 |
US11017566B1 (en) | 2018-07-02 | 2021-05-25 | Apple Inc. | Point cloud compression with adaptive filtering |
US11202098B2 (en) | 2018-07-05 | 2021-12-14 | Apple Inc. | Point cloud compression with multi-resolution video encoding |
US11012713B2 (en) | 2018-07-12 | 2021-05-18 | Apple Inc. | Bit stream structure for compressed point cloud data |
US10891758B2 (en) | 2018-07-23 | 2021-01-12 | Google Llc | Geometry encoder |
US11367224B2 (en) | 2018-10-02 | 2022-06-21 | Apple Inc. | Occupancy map block-to-patch information compression |
US10762667B2 (en) | 2018-11-30 | 2020-09-01 | Point Cloud Compression, B.V. | Method and apparatus for compression of point cloud data |
CN109785421B (zh) * | 2018-12-06 | 2022-09-23 | 武汉天际航信息科技股份有限公司 | 一种基于空地影像组合的纹理映射方法及系统 |
US11057564B2 (en) | 2019-03-28 | 2021-07-06 | Apple Inc. | Multiple layer flexure for supporting a moving image sensor |
US11711544B2 (en) | 2019-07-02 | 2023-07-25 | Apple Inc. | Point cloud compression with supplemental information messages |
US11450030B2 (en) | 2019-09-24 | 2022-09-20 | Apple Inc. | Three-dimensional mesh compression using a video encoder |
US11562507B2 (en) | 2019-09-27 | 2023-01-24 | Apple Inc. | Point cloud compression using video encoding with time consistent patches |
US11627314B2 (en) | 2019-09-27 | 2023-04-11 | Apple Inc. | Video-based point cloud compression with non-normative smoothing |
US11538196B2 (en) | 2019-10-02 | 2022-12-27 | Apple Inc. | Predictive coding for point cloud compression |
US11895307B2 (en) | 2019-10-04 | 2024-02-06 | Apple Inc. | Block-based predictive coding for point cloud compression |
US11194833B2 (en) * | 2019-10-28 | 2021-12-07 | Charbel Gerges El Gemayel | Interchange data format system and method |
US11798196B2 (en) | 2020-01-08 | 2023-10-24 | Apple Inc. | Video-based point cloud compression with predicted patches |
US11475605B2 (en) | 2020-01-09 | 2022-10-18 | Apple Inc. | Geometry encoding of duplicate points |
WO2021186034A1 (en) * | 2020-03-20 | 2021-09-23 | 3Shape A/S | Storage, rendering, and display of information of meshes through tessellation with serialized values |
US11636237B2 (en) * | 2020-04-30 | 2023-04-25 | The Boeing Company | Compressing binary geometry files for structural products |
US11250629B2 (en) * | 2020-05-22 | 2022-02-15 | Seek Xr, Llc | Systems and methods for optimizing a model file |
US12014527B2 (en) * | 2020-06-22 | 2024-06-18 | Advanced Micro Devices, Inc. | Delta triplet index compression |
US11620768B2 (en) | 2020-06-24 | 2023-04-04 | Apple Inc. | Point cloud geometry compression using octrees with multiple scan orders |
US11615557B2 (en) | 2020-06-24 | 2023-03-28 | Apple Inc. | Point cloud compression using octrees with slicing |
US12056420B1 (en) * | 2020-07-06 | 2024-08-06 | Ansys, Inc. | Methods and systems for identifying, filtering and classifying contact-pairs |
US11948338B1 (en) | 2021-03-29 | 2024-04-02 | Apple Inc. | 3D volumetric content encoding using 2D videos and simplified 3D meshes |
US11948339B2 (en) * | 2021-06-04 | 2024-04-02 | Apple Inc. | Encoding and decoding visual content |
US20230334714A1 (en) * | 2022-04-15 | 2023-10-19 | Tencent America LLC | Coding of boundary uv2xyz index for mesh compression |
CN117350915B (zh) * | 2023-12-04 | 2024-03-26 | 深流微智能科技(深圳)有限公司 | 一种图元装配调度方法、系统及设备 |
Family Cites Families (39)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS61131990A (ja) * | 1984-11-30 | 1986-06-19 | Sony Corp | ビデオテツクス画像作成装置 |
US4930092A (en) | 1987-01-20 | 1990-05-29 | Auto-Trol Technology Corporation | Polygon display apparatus and method |
CA1309519C (en) * | 1987-03-17 | 1992-10-27 | Antonio Cantoni | Transfer of messages in a multiplexed system |
US5010553A (en) | 1988-12-05 | 1991-04-23 | Compuquest, Inc. | High speed, error-free data transmission system and method |
US5142635A (en) | 1989-04-07 | 1992-08-25 | Intel Corporation | Method and circuitry for performing multiple stack operations in succession in a pipelined digital computer |
US5216726A (en) * | 1990-03-23 | 1993-06-01 | United Silicon Structures, Inc. | Data compression process |
US5280547A (en) | 1990-06-08 | 1994-01-18 | Xerox Corporation | Dense aggregative hierarhical techniques for data analysis |
US5231676A (en) | 1990-06-08 | 1993-07-27 | Xerox Corporation | Hierarchical operations on border attribute data for image regions |
JP2770598B2 (ja) | 1990-06-13 | 1998-07-02 | 株式会社日立製作所 | 図形表示方法およびその装置 |
JPH04346922A (ja) * | 1991-05-24 | 1992-12-02 | Doujin Iyaku Kako Kk | 貼付剤 |
US5260693A (en) * | 1991-10-11 | 1993-11-09 | Spacelabs Medical, Inc. | Method and system for lossless and adaptive data compression and decompression |
FI88841C (fi) * | 1991-10-30 | 1993-07-12 | Nokia Telecommunications Oy | Foerfarande foer att behandla dataoeverfoeringsramar av vaexlande laengd med en kanalstyrenhet och foer att placera desamma till ett cykliskt buffertminne |
US5295235A (en) * | 1992-02-14 | 1994-03-15 | Steve Newman | Polygon engine for updating computer graphic display employing compressed bit map data |
GB2269289B (en) * | 1992-07-13 | 1995-10-25 | Sony Broadcast & Communication | Serial data decoding |
CA2094524A1 (en) * | 1992-07-30 | 1994-01-31 | Ephraim Feig | Digital image processor for color image compression |
US5475388A (en) * | 1992-08-17 | 1995-12-12 | Ricoh Corporation | Method and apparatus for using finite state machines to perform channel modulation and error correction and entropy coding |
EP0594304B1 (de) * | 1992-10-20 | 2000-06-07 | Network Computing Devices, Inc. | Opcode abhängige Komprimierung für ein Window-System. |
US5537551A (en) | 1992-11-18 | 1996-07-16 | Denenberg; Jeffrey N. | Data compression method for use in a computerized informational and transactional network |
US5457779A (en) | 1993-01-15 | 1995-10-10 | Silicon Graphics, Inc. | System for accessing graphic data in a SIMD processing environment |
US5546477A (en) | 1993-03-30 | 1996-08-13 | Klics, Inc. | Data compression and decompression |
US5392393A (en) * | 1993-06-04 | 1995-02-21 | Sun Microsystems, Inc. | Architecture for a high performance three dimensional graphics accelerator |
EP0627682B1 (de) | 1993-06-04 | 1999-05-26 | Sun Microsystems, Inc. | Gleitkommaprozessor für einen hochleistungsfähigen dreidimensionalen Graphikbeschleuniger |
US5408605A (en) | 1993-06-04 | 1995-04-18 | Sun Microsystems, Inc. | Command preprocessor for a high performance three dimensional graphics accelerator |
US5363107A (en) * | 1993-07-16 | 1994-11-08 | Massachusetts Institute Of Technology | Storage and transmission of compressed weather maps and the like |
US5408597A (en) * | 1993-07-29 | 1995-04-18 | Digital Equipment Corporation | Method and apparatus for schematic routing |
US5533148A (en) | 1993-09-30 | 1996-07-02 | International Business Machines Corporation | Method for restructuring physical design images into hierarchical data models |
US5613102A (en) * | 1993-11-30 | 1997-03-18 | Lucent Technologies Inc. | Method of compressing data for use in performing VLSI mask layout verification |
JP2812168B2 (ja) * | 1993-12-27 | 1998-10-22 | 松下電器産業株式会社 | 形状データ圧縮方法および形状データ伸長方法 |
US5867602A (en) * | 1994-09-21 | 1999-02-02 | Ricoh Corporation | Reversible wavelet transform and embedded codestream manipulation |
US5798762A (en) * | 1995-05-10 | 1998-08-25 | Cagent Technologies, Inc. | Controlling a real-time rendering engine using a list-based control mechanism |
FR2735267B1 (fr) * | 1995-06-08 | 1999-04-30 | Hewlett Packard Co | Systeme et procede de convertisseur de balayage de triangles a tampons de trame entrelaces en deux dimensions |
US5793371A (en) | 1995-08-04 | 1998-08-11 | Sun Microsystems, Inc. | Method and apparatus for geometric compression of three-dimensional graphics data |
US5842004A (en) | 1995-08-04 | 1998-11-24 | Sun Microsystems, Inc. | Method and apparatus for decompression of compressed geometric three-dimensional graphics data |
US5801711A (en) | 1995-08-08 | 1998-09-01 | Hewlett Packard Company | Polyline and triangle strip data management techniques for enhancing performance of computer graphics system |
US5740067A (en) * | 1995-10-19 | 1998-04-14 | International Business Machines Corporation | Method for clock skew cost calculation |
US5694531A (en) * | 1995-11-02 | 1997-12-02 | Infinite Pictures | Method and apparatus for simulating movement in multidimensional space with polygonal projections |
US5736987A (en) * | 1996-03-19 | 1998-04-07 | Microsoft Corporation | Compression of graphic data normals |
US5760716A (en) * | 1996-08-21 | 1998-06-02 | Autodesk, Inc. | Vector data compression |
US5751865A (en) | 1996-09-26 | 1998-05-12 | Xerox Corporation | Method and apparatus for image rotation with reduced memory using JPEG compression |
-
1995
- 1995-08-04 US US08/511,294 patent/US5793371A/en not_active Expired - Lifetime
-
1996
- 1996-07-01 US US08/673,060 patent/US5870094A/en not_active Expired - Lifetime
- 1996-08-05 DE DE69635623T patent/DE69635623T2/de not_active Expired - Fee Related
- 1996-08-05 DE DE69635624T patent/DE69635624T2/de not_active Expired - Fee Related
- 1996-08-05 EP EP99114937A patent/EP0957451B1/de not_active Expired - Lifetime
- 1996-08-05 JP JP23711596A patent/JP3212885B2/ja not_active Expired - Lifetime
- 1996-08-05 EP EP99114936A patent/EP0957450B1/de not_active Expired - Lifetime
- 1996-08-05 DE DE69624636T patent/DE69624636T2/de not_active Expired - Fee Related
- 1996-08-05 EP EP96305773A patent/EP0757332B1/de not_active Expired - Lifetime
-
1997
- 1997-10-16 US US08/951,651 patent/US5905502A/en not_active Expired - Lifetime
- 1997-11-04 US US08/963,863 patent/US6603470B1/en not_active Expired - Lifetime
- 1997-11-04 US US08/964,165 patent/US5867167A/en not_active Expired - Lifetime
- 1997-11-25 US US08/977,794 patent/US6239805B1/en not_active Expired - Lifetime
-
2001
- 2001-03-19 US US09/812,477 patent/US6532012B2/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
EP0757332A2 (de) | 1997-02-05 |
EP0957451B1 (de) | 2005-12-21 |
EP0757332B1 (de) | 2002-11-06 |
DE69635624D1 (de) | 2006-01-26 |
US5793371A (en) | 1998-08-11 |
US5870094A (en) | 1999-02-09 |
EP0957450A3 (de) | 1999-12-01 |
US20020050992A1 (en) | 2002-05-02 |
US5867167A (en) | 1999-02-02 |
EP0957451A3 (de) | 2000-01-05 |
US5905502A (en) | 1999-05-18 |
EP0957450A2 (de) | 1999-11-17 |
DE69635623D1 (de) | 2006-01-26 |
EP0757332A3 (de) | 1997-05-14 |
EP0957450B1 (de) | 2005-12-21 |
DE69624636D1 (de) | 2002-12-12 |
US6239805B1 (en) | 2001-05-29 |
EP0957451A2 (de) | 1999-11-17 |
JP3212885B2 (ja) | 2001-09-25 |
US6532012B2 (en) | 2003-03-11 |
JPH09171568A (ja) | 1997-06-30 |
DE69635624T2 (de) | 2006-06-22 |
DE69635623T2 (de) | 2006-06-22 |
US6603470B1 (en) | 2003-08-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE69624636T2 (de) | Verfahren und Vorrichtung zur geometrischen Komprimierung von dreidimensionelen Grafiken | |
DE69624637T2 (de) | 3D-Bilddekodierung | |
DE60001418T2 (de) | Geometrische komprimierung von dreidimensionalen grafiken | |
US6747644B1 (en) | Decompression of surface normals in three-dimensional graphics data | |
Deering | Geometry compression | |
DE60004827T2 (de) | Segmentierung von komprimierten graphischen daten zur parallelen dekomprimierung und darstellung | |
DE19920214C2 (de) | Verfahren und Einrichtung zum Konvertieren einer Zahl zwischen einem Gleitkommaformat und einem Ganzzahlformat | |
DE112022003721T5 (de) | Mikro-netze, eine strukturierte geometrie für computergrafik | |
Fu et al. | Image compression technique |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8364 | No opposition during term of opposition | ||
8339 | Ceased/non-payment of the annual fee |