DE69632157T2

DE69632157T2 - Kompression und -kodierung eines 3D Maschennetzes

Info

Publication number: DE69632157T2
Application number: DE69632157T
Authority: DE
Inventors: Michael F. Los Altos Deering; Aaron S. Palo Alto Wynn
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1995-08-04
Filing date: 1996-08-05
Publication date: 2004-08-05
Anticipated expiration: 2016-08-06
Also published as: DE69635588D1; EP0757333A2; DE69632157D1; US6088034A; JPH09326041A; EP0964364A3; US6028610A; US5842004A; EP0964364B1; US6522327B2; EP0964364A2; EP0959431B1; US5933153A; US6307557B1; DE69624637T2; JP3884509B2; EP0757333B1; DE69624637D1; US20010050682A1; EP0959431A3

Description

Die vorliegende Erfindung betrifft im allgemeinen die Dekomprimierung von graphischen Daten und insbesondere Verfahren und Vorrichtungen, die komprimierte dreidimensionale geometrische Daten dekomprimieren.
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.
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 Zeichenbefehle 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.
Komprimierte, geometrische Daten, die dreidimensionale geometrische Daten beinhalten, müssen jedoch dekomprimiert werden, um nützlich zu sein. Das Patent des vorliegenden Anmelders, das under der Nummer EP-A-0757332 veröffentlicht worden ist und den Titel, "METHOD AND APPARATUS FOR GEOMETRIC COMPRESSION OF THREE-DIMENSIONAL GRAPHICS DATA" trägt, zeigt zum Beispiel solch eine Komprimierung.
Es besteht somit ein Bedarf für ein Verfahren und eine Vorrichtung für die Dekomprimierung dreidimensionaler Geometrie, die komprimiert wurde. Vorzugsweise erfolgt die Dekomprimierung derart, daß die Ausgangsdaten direkt zu der Darstellungshardware als Zeichenbefehl geleitet werden können. Schließlich sollte die Dekomprimierung von dreidimensionaler Geometrie unter Verwendung von Hardware, Software oder eine Kombination hieraus implementierbar sein.
Bill Fleming: "Sun breaks the bottlenecks. Sun Microsystems uses an all-hardware graphics engine that combines performance with economy" Byte, Bd. 8, Nr. 11, 1 November 1993. Auf den Seiten 218, 222, 224 werden Verbesserungen am Sun Microsystems SparcStation 3-D Grafikteilsystem beschrieben, das die Fließbandverarbeitung sowie die Gleitkommabeschleunigung benutzt, um die 3-D Grafikdarstellung schneller zu machen.
Aspekte der Erfindung sind in den begleitenden unabhängigen Patentansprüchen ausgeführt. Bevorzugte und weitere Merkmale der Erfindung sind in den abhängigen Ansprüchen ausgeführt. Verschiedene Kombinationen bestehend aus den Merkmalen der abhängigen Ansprüchen können, wie notwendig, in Verbindung mit den Merkmalen der unabhängigen Ansprüche verwirklicht werden.
Für die Dekomprimierung gemäß einer Ausführungsform der vorliegenden Erfindung wird die dreidimensionale Geometrie als erstes als generalisiertes Dreiecksgitter dargestellt, was es erlaubt, daß jedes Beispiel eines Eckpunktes in einem linearen Strom, 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 solcher komprimierter dreidimensionaler Geometriedaten kann in Hardware, Software oder einer Kombination aus diesen implementiert werden. Die Dekomprimierungseinheit beinhaltet ein Eingangs-FIFO, das komprimierte Datenbits und ein Signal, das die Größe der ankommenden Daten mitteilt, empfängt. Die FIFO-Ausgänge sind mit einer Eingangsblockzustandsmaschine und einem Eingangsblock gekoppelt. Die Ausgänge von dem Eingangsblock in der Eingangsblockzustandmaschine sind mit einer Verschiebungseinheit verbunden. Der Eingangsblockausgang wird ebenso in Huffman-Tabellen eingegeben, die zu der Zustandsmaschine ausgeben. Der Zustandsmaschinenausgang ist ebenso mit einem Datenpfadkontroller verbunden, dessen Ausgang mit einem Anzeigedecoder und einem Normalprozessor verbunden ist, der den Ausgang von der Barrelverschiebungseinheit bzw. Barrel-Shifter-Einheit empfängt. Die Dekomprimierungseinheit beinhaltet ebenso einen Positions-/Farbprozessor, der den Ausgang von der Barrelverschiebungseinheit empfängt. Die Ausgänge von dem Normalprozessor und dem Positions-/Farbprozessor werden im Multiplex-Verfahren zu einem Formatumwandler übertragen.
Für Befehle in dem Datenstrom, die einen Ausgang zu dem Formatkonvertierer erzeugen, erzeugt die Dekomprimierungseinheit einen 12 Bit-Anzeiger, der zu dem Anzeigerdecoder parallel mit den Bits für die Normalen, die zu dem Formatwandler gesendet werden, gesendet wird. Ein Rücklesepfad wird verwendet, um den internen Zustand der Dekomprimierungseinheit zurückzulesen. Die Dekomprimiereinheit führt die folgenden Prozeduren aus:

(1) Abrufen des Restes des nächsten Befehls und der ersten 8 Bits des folgenden Befehls,
(2) Skalieren jedes komprimierten Wertfeldes unter Verwendung der Anzeigertabelle auf volle Präzision,
(3A) wenn die Werte relativ sind, Addition zu dem gegenwärtigen Wert, andernfalls ersetzen,
(3B) falls Gitterpufferreferenz, zugreifen auf alte Werte,
(3C) falls anderer Befehl, Durchführen der Verwaltung,
(4) falls Normale, leite Index durch ROM-Tabelle, um volle Werte zu erhalten,
(5) Ausgeben der Werte in generalisierter Dreiecksstreifenform zu der nächsten Stufe.

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:
1 zeigt ein generalisiertes Netzwerk, über das komprimierte dreidimensionale Geometrie für die Dekomprimierung an dem Empfangsende gemäß der vorliegenden Erfindung übertragen werden kann,
2 zeigt eine generalisierte Dreiecksgitterdatenstruktur und eine generalisierte Gitterpufferdarstellung der Oberflächengeometrie,
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,
4A stellt ein Vertexkommando in einem Befehlssatz für die geometrische Komprimierung dar,
4B stellt ein Normalenkommando in einem Befehlssatz für die geometrische Komprimierung dar,
4C stellt ein Farbkommando in einem Befehlssatz für die geometrische Komprimierung dar,
4D stellt ein Gitterpufferreferenzkommando in einem Befehlssatz für die geometrische Komprimierung dar,
4E stellt einen Zustandseinstellbefehl in einem Befehlssatz für die geometrische Komprimierung dar,
4F stellt einen Tabelleneinstellkommandobefehl in einem Befehlssatz für die geometrische Komprimierung dar,
4G stellt einen Durchleitkommandobefehl in einem Befehlssatz für die geometrische Komprimierung dar,
4H stellt einen No-Op-Kommandobefehl variabler Länge in einem Befehlssatz für die geometrische Komprimierung dar,
4I stellt eine Anzeiger- und Deltapositionsdatenstruktur dar,
4J-1 und 4J-2 stellen alternative Anzeiger- und Delta-Normaldatenstrukturen dar,
4K stellt eine Anzeiger- und Delta-Farbendatenstruktur dar,
5 ist ein Flußdiagramm mit Verfahrensschritten in einem geometrischen Komprimierungsalgorithmus,
6 ist ein vereinfachtes Blockdiagramm einer Ausführungsform der Dekomprimierungshardware gemäß der vorliegenden Erfindung,
7A–7L stellen Objekte dar, die unter unterschiedlichen Bedingungen komprimiert wurden,
8 ist ein detailliertes Gesamtblockdiagramm einer Ausführungsform einer Dekomprimierungseinheit gemäß der vorliegenden Erfindung,
9 ist ein detailliertes Blockdiagramm des Eingangsblockes, der in 8 gezeigt ist,
10 ist ein detailliertes Blockdiagramm der Barrelschiebereinheit, die in 8 gezeigt ist,
11 ist ein detailliertes Blockdiagramm der Positions-/Farbverarbeitungseinheit, die in 8 gezeigt ist,
12A ist ein detailliertes Blockdiagramm der Normalen-Prozessoreinheit, die in 8 gezeigt ist,
12B ist ein detailliertes Blockdiagramm, das die Decoder-, Falt- und ROM-Nachschlagkomponenten zeigt, die mit der Normalen-Prozessoreinheit von 12A verbunden sind,
13 ist ein Blockdiagramm, das die Schnittstellen zu einem Gitterpuffer zeigt, wie in 11 und/oder 12A gezeigt ist,
14A stellt Schnittstellen zu Huffman-Tabellen gemäß der vorliegenden Ausführungsform dar,
14B stellt ein bevorzugtes Format für den Eintrag der Huffman-Tabellendaten dar gemäß der vorliegenden Ausführungsform,
15A stellt einen Vertexbefehl gemäß der vorliegenden Ausführungsform dar,
15B stellt Datenformate für Punktkomponenten gemäß der vorliegenden Ausführungsform dar,
15C stellt das Format für den Normaleneinstellbefehl gemäß der vorliegenden Ausführungsform dar,
15D stellt den Farbeinstellbefehl dar gemäß der vorliegenden Ausführungsform,
15E stellt den Befehl für die Gitterpufferreferenz dar gemäß der vorliegenden Ausführungsform,
15F stellt einen Zustandseinstellbefehl gemäß der vorliegenden Ausführungsform dar,
15G stellt einen Tabelleneinstellbefehl gemäß der vorliegenden Ausführungsform dar,
15H stellt einen Durchlaßbefehl gemäß der vorliegenden Ausführungsform dar,
15I stellt einen NOP-Befehl variabler Länge gemäß der vorliegenden Ausführungsform dar und
15J stellt einen Sprungbefehl 8 gemäß der vorliegenden Ausführungsform dar.
Ein Graphikdekomprimierer gemäß einer Ausführungsform der vorliegenden Erfindung dekomprimiert dreidimensionale graphische Objekt. Die dreidimensionale Komprimierung solcher Geometrien erlaubt mit Vorteil eine Reduktion der Zeit, die benötigt wird, um die komprimierte dreidimensionale Geometrie zu übertragen, zum Beispiel über ein Netzwerk, sowie die Reduktion des Speicherplatzen, in dem die Geometrie gespeichert werden kann, zum Beispiel auf einer CD-ROM oder dergleichen.
Vor der Beschreibung der Dekomprimierung von komprimierten dreidimensionalen Graphiken wird unter Bezug auf 1 die gesamte Umgebung, in der die vorliegende Erfindung praktiziert werden kann, beschrieben.
1 stellt ein generalisiertes Netzwerk dar, über das dreidimensionale komprimierte geometrische Daten übertragen werden können unter Verwendung von Software, Hardware oder einer Kombination von diesen, die am Empfangsende dekomprimiert werden können. Natürlich kann die Dekomprimierung von dreidimensionaler graphischer Komprimierung gemäß der vorliegenden Erfindung auf komprimierten Daten praktiziert werden, die auf anderem Wege als über ein Netzwerk präsentiert werden, zum Beispiel komprimierte Daten, die in einem Speicher abgelegt sind, auf einer CD-ROM oder dergleichen.
Wie in 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 eine zentrale Prozessoreinheit an sich („CPU") 60 mit verknüpftem Hauptspeicher 70, einem Gitterpuffer 80, einem Speicherabschnitt 90, der einen Komprimierungsalgorithmus enthalten kann, und einen Bereich von Nurlesespeicher („ROM") 100 beinhaltet. Alternativ dazu kann die Komprimierung entsprechend ausgeführt werden teilweise oder vollständig in der Hardware im Gegensatz zu der Software. 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.
Wie in der Patentanmeldung EP-A-0 757 332 des Anmelders beschrieben, die an demselben Tag wie die vorliegende Anmeldung eingereicht wurde, mit dem Titel „Method and Apparatus for Geometric Compression of three-dimensional Graphics Data", kann die verlustbehaftete Komprimierung von dreidimensionalen geometrischen Daten Verhältnisse von 6 : 1 bis 10 : 1 produzieren mit einem geringen Verlust in der angezeigten Objektqualität. Die folgenden Abschnitte dieser Spezifikation werden die Komprimierung beschreiben, wie sie in der oben erwähnten Patentanmeldung ausgeführt sind, um ein besseres Verständnis der Dekomprimierung gemäß der vorliegenden Erfindung zu erleichtern.
In einer Netzwerkumgebung beinhaltet ein Decodersystem (Decodersysteme) 40 an dem Empfangsende eine Netzwerkinterfaceeinheit 120, eine Einheit 130, entsprechend der vorliegenden Ausführungsform, die dreidimensionale graphische Daten dekomprimiert und deren Ausgang mit einer Darstellungseinheit 140 für dreidimensionale Graphik verbunden ist. Das System 40 weist weiterhin ein zentrales Verarbeitungssystem 150 auf, das eine CPU 160, einen Speicher 170, von dem ein Ab schnitt 180 Dekompressionssoftware beinhalten kann, und ein ROM 190 beinhaltet. Komprimierte dreidimensionale Graphik kann mit Vorteil unter Verwendung von Software, Hardware oder einer Kombination von beiden dekomprimiert werden. Der dekomprimierte Ausgang von dem Decoder 40 kann weiterhin mit einem Viewer 200 oder mit einem anderen System, das die dekomprimierte Graphik erfordert, verbunden sein. Natürlich kann die Einheit 40 eine Einzeleinheit sein, in die die vorkomprimierte dreidimensionale Graphik von dem Speicher 82, Platten oder CD-ROM 84 oder dergleichen für die Dekomprimierung eingekoppelt werden. Die Einheit 40 kann beispielsweise einen Computer oder eine Workstation aufweisen.
Angenommen, daß die Einheit 60 für die Komprimierung dreidimensionaler Graphik funktioniert, wie in der oben erwähnten Patentanmeldung der Anmelderin beschrieben wird, werden zuerst Dreiecksdaten in ein generalisiertes Dreiecksgitter umgewandelt. Für eine gegebene feste Kapazität des Speichermediums 80 ist eine Dreiecksgitterdatenstruktur eine nahezu optimale Darstellung von Dreiecksdaten. In der bevorzugten Ausführungsform kann ein dreidimensionales graphisches Objekt als dreidimensionale Dreiecksdaten dargestellt werden, deren Format nach der Umwandlung veranlaßt, daß jeder lineare Streifeneckpunkt bzw. Vertex im Mittel von etwa 1/3 Dreiecken bis etwa 2 Dreiecke spezifiziert. Weiterhin erlaubt solch eine Dreiecksstreifenstruktur die Extraktion der komprimierten Geometrie durch einen einzelnen monotonen Scan über die Vertexarray-Datenstruktur.
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 2 gezeigte Geometrie kann beispielsweise durch einen Dreiecksstreifen repräsentiert werden, jedoch werden viele innere Eckpunkte zweimal in dem Streifen erscheinen.
In 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 dreidimensionale geometrische Komprimierung 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 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 eine endliche Länge und in der Praxis wird eine maximale feste Warteschlangenlänge von 16 verwendet, was einen 4-Bit-Index erfordert. In Bezug auf die Komprimierung von dreidimensionalen Graphiken soll sich der Begriff „Gitterpuffer" 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.
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 einer 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 auf Positionsdaten und es werden im allgemeinen eine Normale und/oder eine Farbe und/oder Texturabbildungskoordinaten ebenso wie Vertex spezifiziert. Dementsprechend enthalten 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). 4E stellt eine Befehlsstruktur 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 Kompressionstechnik, die in der oben erwähnten Patentanmeldung beschrieben wurde, 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 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 gege benes 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 und die geometrische Komprimierungssprache unterstützt vorzugsweise 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 4C gezeigt ist. Das optionale α-Feld wird gesteuert durch ein Color-α-Present-Zustandsbit („CAP") gesteuert, das in 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.
In der Praxis kann dieselbe Δ-Codierung für die Farbkomponenten und für Positionen verwendet werden. Das Gebiet der Farbdatenkomprimierung ist dort, wo geometrische Komprimierung und traditionelle Bildkomprimierung auf die einfachsten Probleme treffen. Viele fortgeschrittene Bildkom primierungstechniken können jedoch vermieden werden für die geometrische Farbkomprimierung, aufgrund der Differenz in der Brennweite.
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 einem RGB-Modell 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 werden 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⁹⁶ 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^–46 Radiant erstreckt.
Jedoch sind für IEEE gleitkommanormalisierte Normalen die Exponentenbits effektiv unbenutzt. Unter der Nebenbedingung N_x ² + N_y ² + N_z ² = 1 muß zumindest N_x, N_y oder N_z 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: T2 0,0 + T2 1,0 + T2 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 Winkelgenauigkeit zur Verfügung stellen als das reparierte Hubble-Weltraumteleskop und der Praxis verwenden manche Systeme nur 16 Bit-Normalkomponenten. In empirischen Tests mit 16-Bit Normalkomponenten sind Ergebnisse von einer Winkeldichte von 0,01 Radianten zwischen den Normalen (zum Beispiel etwa 100000 Normalen, die über eine Einheitskugel verteilt sind) visuell nicht von feineren Darstellungen unterscheidbar. Im geradlinigen Raum erfordern diese Normalen immer noch eine höhere Darstellungsgenauigkeit und in der Praxis stellen 16 Bit Komponenten, die ein Vorzeichenbit und ein Schutzbit beinhalten, eine gute Messungswahl dar. 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 N_x, N_y, N_z-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 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. 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 Ablegens 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 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 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.
Die Komprimierung gemäß der oben erwähnten Patentanmeldung verbindet 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 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 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.
In der oben beschriebenen Patentanmeldung werden Komprimierungsanzeiger verwendet mit einer Variation eines konventionellen Huffman-Algorithmus. Der Huffman-Komprimierungsalgorithmus nimmt einen Satz von darzustellenden Symbolen auf zusammen mit der Frequenz der Auftrittsstati stiken (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 erwähnten Patentanmeldung 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 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. In der Praxis kann ein einzelner Feldlängenanzeiger verwendet werden, um die Bitlänge von Δx, Δy und Δz anzuzeigen.
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, kann die Länge des Huffman-Anzeigenfeldes auf 6 Bit, einen relativ kleinen Wert, begrenzt werden. Eine Anzeiger-Nachschlagtabelle mit 64 Einträgern 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 oben erwähnten Patentanmeldung beschrieben ist, wird nun unter Bezug auf die 4A bis 4K beschrieben. 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 4B gezeigt ist, spezifiziert ein Normalenkommando eine neue gegenwärtige Normale und das Farbkommando, das in 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 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 4B gezeigt ist, wird ebenso ein 2-Bit-Vertexersetzungscode („REP") spezifiziert.
4E stellt den Zustandseinstellbefehl dar, der die fünf Zustandsbits: RNT, RCT, BNV, BCV und CAP aktualisiert.
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.
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.
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 4I, 4J-1 und 4J-2 bzw. 4K stellen Anzeiger- und Δ-Positionsdatenstrukturen, Anzeiger- und Δ-Normalendatenstrukturen bzw. einen Anzeiger und die Δ-Farbdatenstruktur dar. In den 4I und 4K werden entweder die absoluten Werte von x, y, z verwendet oder die Δ-Werte von x, y und z werden verwendet.
Natürlich können andere Befehlssätze statt dessen verwendet werden, um dreidimensionale Geometrie zu komprimieren.
Das Verhältnis der Zeit, die erforderlich ist für die Komprimierung relativ zu der Dekomprimierung, kann wichtig sein. 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 1 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.
5 ist ein Flußdiagramm, das die Verfahrensschritte in einer geometrischen Komprimierungsalgorithmusroutine ausführt, die in der oben erwähnten Patentanmeldung beschrieben wurden, mit der die vorliegende Dekomprimierungserfindung verwendet werden kann. Solch eine Routine kann in dem Speicher 80 abgelegt werden und unter der Steuerung der CPU 60 ausgeführt werden (siehe 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 Gitterpufterprä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 gegenwärtige 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.
Die vorliegende Erfindung ist auf die Dekomprimierung dreidimensionaler komprimierter Geometrie an dem Benutzerende von 1 gerichtet. Eine anwendbare geometrische Dekomprimierungstechnik gemäß der vorliegenden Erfindung kann kurz und allgemein wie folgt ausgeführt werden:

(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.

In der bevorzugten Ausführungsform dekomprimiert eine Softwareausführung des Dekomprimierers des Anmelders komprimierte geometrische Daten mit einer Rate von etwa 10000 Dreiecken/Sekunde. Ein vereinfachtes Gesamtblockdiagramm der Dekomprimierung gemäß der vorliegenden Erfindung ist in 6 gezeigt. Eine Hardwareimplementierung des Dekomprimierers gemäß der vorliegenden Erfindung kann dekomprimieren in dem Bereich von Dutzenden von Millionen von Dreiecken/Sekunde, wobei die Rate wesentlich expandiert werden kann.
Vor der Beschreibung der Dekomprimierung ist es nützlich, unkomprimierte und komprimierte Bildergebnisse, wie in den 7A–7L und in Tabelle 1 unten gezeigte, zu untersuchen und zu vergleichen. Die 7A–7G stellen dasselbe Basisobjekt, einen Triceratop, dar, jedoch mit unterschiedlichen Quantisierungsschwellwerten auf Positionen und Normalen. 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 7B und 7C stellen die Effekte von der reinen positionalen Quantisierung P36/N96 bzw. P24/N96 dar, während die 7D und 7E nur die normale Quantisierung, P96/N18 und P96/N12 darstellen. Die 7F und 7G zeigen eine kombinierte Quantisierung, P48/N18 und P30/N36.
Die 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 Streifenlä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.
Es versteht sich aus dem vorhergehenden, daß ein dreidimensionaler geometrische Kompressionsalgorithmus in Echtzeit-Hardware oder in Software implementiert werden kann. Bedeutsamerweise kann, wenn dreidimensionale Darstellungshardware eine geometrische Dekomprimierungseinheit gemäß der vorliegenden Erfindung enthält, Applikationsgeometrie in dem Speicher in komprimiertem Format gelegt werden. Weiterhin kann die Datenübertragung das komprimierte Format verwenden, wodurch die effektive Bandbreite für ein Graphikbeschleunigersystem einschließlich gemeinsam genutzten Umgebungen mit der Anzeige von virtueller Realität, verbessert wird. Die resultierende Kompression kann die Menge der Geometrie, die in dem Hauptspeicher cachegespeichert werden kann, wesentlich erhöhen.
8 ist ein detailliertes Blockdiagramm der Dekomprimierungseinheit 130, die in 1 gezeigt ist. Wie in 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 1). Der APDD-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 die Dekompressionseinheit 130 in der bevorzugten Ausführungsform zu implementieren:
Tabelle 2
Die Tabelle 3 unten zeigt Ausgangsdatenformate, die in der bevorzugten Ausführungsform 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
9 ist ein detailliertes Blockdiagramm des Eingangsblockes 210, der in 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.
10 ist ein detailliertes Blockdiagramm der Barrelverschiebereinheit 240, die in 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 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.
11 stellt in größerem Blockdiagrammdetail die Positions-/Farbprozessoreinheit 280 dar, die in 8 gezeigt ist. Die Prozessoreinheit 280 erzeugt die Endposition oder die Farbkomponentenwerte. Wie in den 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 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 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 8 gezeigt ist, gibt die Normalenprozessoreinheit 270 ebenso Daten zu dem Ausgangsmultiplexer 290 aus. 12A stellt im Detail die Untereinheiten dar, die die Normalenprozessoreinheit 270 aufweist. Wie in der 8 und 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 12B) verknüpft ist.
Wie in 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 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.
13 stellt Schnittstellen zu einem Gitterpuffer dar, wie in 11 und/oder 12A gezeigt. In der bevorzugten Ausführungsform 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.
14A stellt Schnittstellen zu Huffman-Tabellen, zum Beispiel den Tabellen 230 in 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.
14B stellt ein bevorzugtes Format für den Eintrag der Positions- und Farbdaten in den Huffman-Tabellen dar, während 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 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 8) beinhaltet ein vorzugsweise 6 Bit-Zustandsregister, das Informationen über den Verarbeitungszustand der Dekomprimierungseinheit hält. In der bevorzugten Ausführungsform 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 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 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. In der bevorzugten Ausführungsform 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.
Der Befehlssatz, der die Dekomprimierung gemäß der vorliegenden Erfindung implementiert, wird nun beschrieben. 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 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.
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 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 10) um ptag_len + pdata_len – pquant + 2.
2. Mischen; Ausgabe Header.
3. Ausgabe Y, verschiebe Barrelrechtsschiebeeinheit 500 (siehe 10) um pdata_len – pquant.
4. Mische.
5. Ausgabe Z, verschiebe Barelrechtsschiebeeinheit 500 (siehe 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 (rcd), gehe zu 22,
e. sonst, mische, verzweige zu nächstem Befehl.
7. Sperre nächsten Operationscode; Ausgabe Sextant/Oktant; verschiebe Kernrechtsschiebeeinheit 500 (siehe 19) um ntag_len + 6.
8. Vermische.
9. Ausgabe U.
a. wenn (absolute Normale), verschiebe Barrelrechtsschiebeeinheit 500 (siehe 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 10) um ctag_len + cdata_len – cquant.
14. Vermische.
15. Ausgabe G; verschiebe Barrelrechtsschiebeeinheit 500 (siehe 10) um cdata_len – cquant.
16. Vermische; wenn (tex), verzweige zu nächstem Befehl.
17. Ausgabe P; verschiebe Barrelrechtsschiebeeinheit 500 (siehe 10) um cdata:len – cquant.
18. Vermische; wenn (~cap), verzweige zu nächstem Befehl.
19. Ausgabe A; verschiebe Barrelrechtsschiebeeinheit 500 (siehe 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.

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 10) um ntag_len + 8.
2. Vermische.
3. Ausgabe U; verschiebe Barrelrechtsschiebeeinheit 500 (siehe 10) um ndata_len – nquant.
4. Vermische.
5. Ausgabe V, verschiebe Barrelrechtsschiebeeinheit 500 (siehe 10) um ndata_len + nquant.
6. Vermische; verzweige zu nächstem Befehl.

1. Verriegele nächsten Operationscode; Ausgabe dU, verschiebe Barrelrechtsschiebeeinheit 500 (siehe 10) um n_tag_len + ndata_len + nquant.
2. Vermische.
3. Ausgabe dV; verschiebe Barrelrechtsschiebeeinheit 500 (siehe 10) um ndata len – nquant.
4. Vermische; verzweige zu nächstem Befehl.

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 10) um ctag_len + cdata_len – cquant + 2.
2. Vermische.
3. Ausgabe G; verschiebe Barrelrechtsschiebeeinheit 500 (siehe 10) um cdata_len – cquant.
4. Vermische. Falls (tex), verzweige zu nächsten Befehl.
5. Ausgabe B, verschiebe Barrelrechtsschiebeeinheit 500 (siehe 10) um cdata_len – cquant.
6. Vermische. Falls (~cap), verzweige zu nächstem Befehl.
7. Ausgabe A; verschiebe Barrelrechtsschiebeeinheit 500 (siehe 10) um cdata_len – cquant.
8. Vermische; verzweige zu nächstem Befehl.

15E ist das bevorzugte 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 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 Gitterpufterreferenzbefehl verwendete. Die Zustände für den Gitterpufterreferenzbefehl sind wie folgt:

1. Verriegele nächsten Operationscode; Ausgabe Header; verschiebe Barrelrechtsschiebeeinheit 500 (siehe 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 Gitterpufffer, sonst falls (rct) Ausgabe curr_a. Vermische; verzweige zu nächstem Befehl.

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.

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 10) um 23.
2. Vermische; verzweige zu nächstem Befehl.

Tabelle 5 zeigt die bevorzugten Huffman-Tabellenfüllcodes.
Tabelle 5
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 10) um 32 Bits.
2. Vermische.
3. Ausgabe Daten, verschiebe Barrelrechtsschiebeeinheit 500 (siehe 10) um 32 Bits.
4. Vermische; verzweige zu nächstem Befehl.

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 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 10) um 13 Bits;
2. Vermische.
3. Barrelrechtsschiebeeinheit liest „count"-Positionen, 4. Vermische; verzweige zu nächstem Befehl.

15J zeigt den Skip-8-Befehl (Auslaßbefehl), dessen Zustände wie folgt sind.

1. Verriegele nächsten Operationscode; verschiebe Barrelrechtschiebeeinheit 500 (siehe 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. Eine Ausführungsform der vorliegenden Erfindung kann die parallele Dekomprimierung eines Datenstroms durch zur Verfügung stellen eines zusätzlichen Kommandos bereitstellen, das über die Ankunft einer gegebenen Anzahl von Datenworten, die parallel verarbeitet werden können, informiert. Eine Ausführungsform der vorliegenden Erfindung kann die Anwesenheit von solchen parallelen Möglichkeiten durch die Anwesenheit von Markierungsbits erkennen und veranlassen, daß die angegebene Anzahl von Datenworten, die zu anderen Prozessoren innerhalb des Systems hin- und hergeschickt werden sollen für die parallele Dekomprimierung, erkannt werden. 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.
Eine Ausführungsform der vorliegenden Erfindung kann ebenso die Morphing-Fähigkeit zur Verfügung stellen, 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. Die vorliegende Erfindung kann einen nahtlosen Übergang zur Verfügung stellen, 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.
Veränderungen und Variationen können an den offenbarten Ausführungsformen vorgenommen werden, ohne von dem Schutzbereich der begleitenden Patentansprüche abzuweichen.

Claims

Verfahren für die Komprimierung von 3-D-Geometriedaten, die Information enthalten, die eine Mehrzahl von Vertices beschreiben, wobei das Verfahren aufweist: Empfangen der 3-D-Geometriedaten und Codieren der 3-D-Geometriedaten in einen komprimierten Datenstrom, wobei das Codieren aufweist: Gliedern einer ersten Untergruppe der Vertices in einen ersten Streifen aus geometrischen Rundelementen und Darstellen des ersten Streifens mit einer ersten Mehrzahl von Befehlen, die verwendbar sind, um während der Dekomprimierung eine Mehrzahl von geometrischen Grundelementen aus dem ersten Streifen zusammenzusetzen, wobei ausgewählte Befehle der ersten Mehrzahl von Befehlen spezifizieren, daß ausgewählte Vertices in einem Maschen- bzw. Netzpufferspeicher gespeichert werden für die Verwendung bei der Bildung von nachfolgenden geometrischen Grundelementen, die von der ersten Mehrzahl von Befehlen spezifiziert werden, wobei der Netzpufferspeicher eine Anzahl von Speicherorten beinhaltet, die derart konfiguriert sind, daß sie Vertexparameter, die ausgewählten Vertices entsprechen, speichern, wobei die 3-D-Geometriedaten eine Gesamtzahl von Vertices haben, die wesentlich größer als die Anzahl von Speicherplätzen ist.
Verfahren nach Anspruch 1, wobei die erste Mehrzahl von Befehlen verwendbar ist, um den ersten Streifen von geometrischen Grundelementen zu dekomprimieren und auf einem Anzeigeschirm darzustellen.
Verfahren nach Anspruch 1 oder 2, wobei die Darstellung das Codieren eines ersten geometrischen Grundelements mit einer ersten Untergruppe der ersten Mehrzahl von Befehlen beinhaltet, wobei das erste geometrische Grundelement ein erstes Vertex beinhaltet.
Verfahren nach Anspruch 3, wobei das Codieren des ersten geometrischen Grundelementes das Bestimmen beinhaltet, daß das erste Vertex geeignet ist für die Speicherung in dem Netzpufferspeicher, wobei das Bestimmen das Identifizieren, daß das erste Vertex ebenso in einem zweiten geometrischen Grundelement innerhalb des ersten Streifens von geometrischen Grundelementen, das einem ersten geometrischen Grundelement nachfolgt, enthalten ist, beinhaltet, und wobei das Bestimmen weiterhin beinhaltet das Identifizieren, daß der erste Streifen aus geometrischen Grundelementen zumindest ein geometrisches Grundele ment zwischen dem ersten geometrischen Grundelement und dem zweiten geometrischen Grundelement enthält, das den ersten Vertex nicht enthält.
Verfahren nach Anspruch 4, wobei die erste Untergruppe der ersten Mehrzahl von Befehlen einen ersten Befehl enthält, der spezifiziert, daß das erste Vertex bei der Bildung des ersten geometrischen Grundelementes verwendet wird.
Verfahren nach Anspruch 5, wobei die erste Mehrzahl von Befehlen weiterhin spezifiziert, daß während der Dekomprimierung die Vertexparameter des ersten Vertex mit Ausführung des ersten Befehls in dem Netzpufferspeicher abgelegt werden.
Verfahren nach Anspruch 6, wobei das Darstellen das Codieren des zweiten geometrischen Grundelementes mit einer zweiten Untergruppe der ersten Mehrzahl von Befehlen beinhaltet, wobei die zweite Untergruppe der ersten Mehrzahl von Befehlen einen zweiten Befehl beinhaltet, der spezifiziert, daß Vertexparameter, die dem ersten Vertex entsprechen, die in dem Netzpufferspeicher abgelegt wurden, während der Dekomprimierung bei der Bildung des zweiten geometrischen Grundelementes verwendet werden.
Verfahren nach Anspruch 6 oder 7, wobei die Vertexparameter des ersten Vertex ausgewählt werden aus der Gruppe die besteht aus: (i) Position, (ii) Normalen, (iii) Farben, (iv) Texturabbildungskoordinaten und (v) Oberflächenmaterialeigenschaften.
Verfahren nach Anspruch 8, wobei der Netzpufferspeicher implementiert wird als ein Stapel von Speicherplätzen und wobei der erste Befehl ausführbar ist, um die Vertexparameter des ersten Vertex während der Dekomprimierung oben auf den Stapel zu schieben.
System für die Komprimierung von 3-D-Geometriedaten, die Information beinhalten, die Vertices einer Mehrzahl von geometrischen Grundelementen beschreiben, wobei das System aufweist: eine zentrale Verarbeitungseinheit (CPU) und einen Speicher, der mit der CPU verbunden ist, wobei der Speicher die 3-D-Geometriedaten und ein Komprimierungsprogramm, das für die Darstellung der 3-D-Geometriedaten in einem komprimierten Format ausführbar ist, beinhaltet, wobei die CPU derart konfiguriert ist, daß sie das Komprimierungsprogramm ausführt, um die 3-D-Geometrie in dem komprimierten Format darzustellen, wobei das Komprimierungsprogramm ausführbar ist, um eine erste Untergruppe der Vertices der Mehrzahl von geometrischen Grundelementen in einen ersten Streifen aus geometrischen Grundelementen zu gliedern, und wobei das Komprimierungsprogramm weiterhin ausführbar ist, um den ersten Streifen von geometrischen Grundelementen mit einer Mehrzahl von Befehlen darzustellen, die verwendbar sind, um die geometrischen Grundelementen des ersten Streifens aus geometrischen Grundelementen während der Dekomprimierung zusammenzusetzen, wobei ausgewählte Befehle der Mehrzahl von Befehlen spezifizieren, daß ausgewählte Vertices, die in den geometrischen Grundelementen des ersten geometrischen Streifens beinhaltet sind, in einem Netzpufferspeicher abgelegt werden für die Verwendung bei der Bildung von geometrischen Grundelementen, die von nachfolgenden Befehlen der Mehrzahl von Befehlen spezifiziert werden, und wobei der Netzpufferspeicher eine Mehrzahl von Speicherstellen beinhaltet, die derart konfiguriert sind, daß sie die Vertexparameter, die den ausgewählten Vertices entsprechen, speichern, und wobei eine Anzahl der Mehrzahl von Speicherstellen wesentlich kleiner als eine Gesamtzahl von Vertices in den 3-D-Geometriedaten ist.
System nach Anspruch 10, wobei die Mehrzahl von Befehlen verwendbar ist, um den ersten Streifen von geometrischen Grundelementen zu dekomprimieren und auf einem Anzeigeschirm dazustellen.
System nach Anspruch 10 oder 11, wobei das Ausführen des Komprimierungsprogrammes das Codieren eines ersten geometrischen Grundelementes mit einer ersten Untergruppe der Mehrzahl von Befehlen beinhaltet, wobei das erste geometrische Grundelement ein erstes Vertex enthält.
System nach Anspruch 12, wobei das Ausführen des Komprimierungsprogramms das Bestimmen beinhaltet, daß das erste Vertex für die Speicherung in dem Netzpufferspeicher geeignet ist, wobei das Bestimmen das Identifizieren beinhaltet, daß das erste Vertex ebenso in einem zweiten geometrischen Grundelement innerhalb des ersten Streifens aus geometrischen Grundelementen, das dem ersten geometrischen Grundelement nachfolgt, enthalten ist, und wobei das Bestimmen weiterhin das Identifizieren beinhaltet, daß der erste Streifen aus geometrischen Grundelementen zumindest ein geometrisches Grundelement zwischen dem ersten geometrischen Grundelement und dem zweiten geometrischen Grundelement, welches den ersten Vertex nicht beinhaltet, beinhaltet.
System nach Anspruch 13, wobei die erste Untergruppe der Mehrzahl von Befehlen einen ersten Befehl beinhaltet, der spezifiziert, daß das erste Vertex bei der Bildung des ersten geometrischen Grundelementes verwendet wird.
System nach Anspruch 14, wobei das Ausführen des ersten Befehls weiterhin spezifiziert, daß Vertexparameter des ersten Vertex während der Dekomprimierung bei der Ausführung des ersten Befehls in dem Netzpufferspeicher abgelegt werden.
System nach Anspruch 13, 14 oder 15, wobei die Ausführung des Komprimierungsprogramms das Codieren des zweiten geometrischen Grundelementes mit einer zweiten Untergruppe der Mehrzahl von Befehlen beinhaltet, wobei die zweite Untergruppe der Mehrzahl von Befehlen einen zweiten Befehl beinhaltet, der spezifiziert, daß Vertexparameter entsprechend dem ersten Vertex, die in dem Netzpufferspeicher abgelegt sind, bei der Bildung des zweiten geometrischen Grundelementes während der Dekomprimierung verwendet werden.
System nach Anspruch 14 oder 15 oder Anspruch 16, soweit abhängig von Anspruch 14, wobei der Netzpufferspeicher als ein Stapel aus Speicherstellen implementiert wird und wobei der erste Befehl ausführbar ist, um während der Dekomprimierung die Vertexparameter des ersten Vertex oben in den Stapel zu schieben.
System oder Verfahren nach einem der vorherigen Ansprüche, wobei die Mehrzahl von geometrischen Grundelementen Dreiecke sind.
Verfahren für die Dekomprimierung komprimierter 3-D-Geometriedaten, die einem 3-D-Graphikobjekt entsprechen, wobei das Verfahren aufweist: Empfangen der komprimierten 3-D-Geometriedaten, wobei die komprimierten 3-D-Geometriedaten eine Mehrzahl von Befehlen mit Vertexparameterinformation beinhalten, wobei die Befehle eine Mehrzahl von Vertices auf dem 3-D-Graphikobjekt beschreiben, wobei eine erste Untergruppe der Befehle zumindest einen Teil der Vertexparameterinformation explizit in einen Netzpufferspeicher schiebt, und das Zusammensetzen der Vertices, die von den Befehlen und der entsprechenden Vertexparameterinformation beschrieben werden, in eine Mehrzahl von geometrischen Grundelementen, wobei zumindest ein Teil der Vertexparameterinformation, die explizit in den Netzpufferspeicher verschoben wurde, wieder verwendet wird.
Verfahren nach Anspruch 19, wobei eine zweite Untergruppe der Befehle es explizit unterläßt irgendeine der entsprechenden Vertexparameterinformation in den Netzpufferspeicher zu schieben, und wobei eine dritte Untergruppe der Befehle explizit die Vertexparameterinformation liest, die in den Netzpufferspeicher verschoben wurden.
Verfahren nach Anspruch 20, bei dem sich ein oder mehrere von der ersten, der zweiten und der dritten Untergruppe der Befehle überschneiden.
Verfahren nach Anspruch 20 oder 21, wobei zumindest ein Teil der Information, die explizit in den Netzpufferspeicher verschoben wurde, für Vertices wieder verwendet werden, die durch zumindest ein graphisches Grundelement voneinander getrennt sind.
Verfahren nach Anspruch 20, 21 oder 22, wobei der Netzpufferspeicher eine vorbestimmte Maximalanzahl von Speicherstellen aufweist, wobei die vorbestimmte Maximalzahl wesentlich geringer als die Anzahl von Vertices in den 3-D-Geometriedaten ist.
Verfahren nach einem der Ansprüche 19 bis 23, wobei die Mehrzahl von Vertices verwendbar sind, um eine Mehrzahl von geometrischen Grundelementen zu bilden, um eine Oberfläche des dreidimensionalen graphischen Objektes darzustellen, wobei die Mehrzahl von Befehlen einen ersten Befehl beinhaltet, und wobei das Aufbauen bzw. Zusammensetzen die Verwendung des ersten Befehls beinhaltet, um zu spezifizieren, daß ein erstes Vertex der Mehrzahl von Vertices bei der Bildung eines ersten geometrischen Grundelementes zu verwenden ist, und wobei der erste Befehl weiterhin spezifiziert, daß zumindest ein Teil der Vertexparameterinformation, die zu diesen Vertex korrespondiert, in dem Netzpufferspeicher für die spätere Verwendung bei der Bildung eines zweiten geometrischen Grundelementes abzulegen ist, wobei es zumindest ein dazwischenliegendes geometrisches Grundelement zwischen dem ersten und dem zweiten geometrischen Grundelement gibt.
Verfahren nach Anspruch 24, wobei die Mehrzahl von Befehlen einen zweiten Befehl beinhaltet, der spezifiziert, daß die Vertexparameterinformation, die in dem Netzpufferspeicher abgelegt ist und zu dem ersten Vertex korrespondiert, bei dem Aufbau des zweiten geometrischen Grundelementes zu verwenden ist und wobei das Aufbauen von ausgewählten Grundelementen der Mehrzahl von geometrischen Grundelementen weiterhin das Verwenden des zweiten Befehls beinhaltet, um das zweite geometrische Grundelement zu bilden, das den ersten Vertex enthält.
Verfahren nach Anspruch 25, wobei die Mehrzahl der geometrischen Grundelemente eine Mehrzahl von Dreiecksgrundelementen ist und wobei das Aufbauen von ausgewählten geometrischen Grundelementen aus der Mehrzahl von geometrischen Grundelementen das Bilden von jedem der Mehrzahl von Dreiecksgrundelementen unter Verwendung eines gegenwärtigen Satzes von Vertices beinhaltet, wobei jeder der gegenwärtigen Sätze von Vertices durch die Mehrzahl von Befehlen spezifiziert wird, und wobei der gegenwärtige Satz von Vertices einen gegenwärtigen ältesten Vertexwert, einen gegenwärtigen mittlersten Vertexwert und einen gegenwärtigen neuesten Vertexwert beinhaltet.
Verfahren nach Anspruch 26, wobei das Aufbauen von ausgewählten Grundelementen der Mehrzahl von geometrischen Grundelementen für ein nächstes Dreiecksgrundelement weiterhin beinhaltet, das Bestimmen, welcher Vertex des gegenwärtigen Satzes von Vertices zu ersetzen ist für die Bildung des nächsten Dreiecksgrundelementes durch Verwendung eines Ersetzungscodes, der in einem gegenwärtigen Befehl der Mehrzahl von Befehlen beinhaltet ist.
Verfahren nach Anspruch 27, wobei das Zusammensetzen weiterhin beinhaltet eines der folgenden: (i) Ersetzen des gegenwärtig ältesten Vertexwertes durch den gegenwärtig mittlersten Vertexwert, den gegenwärtig mittlersten Vertexwert durch den neuesten Vertexwert und den neuesten Vertexwert durch einen Vertexwert, der in dem gegenwärtigen Befehl spezifiziert wird, in Antwort auf den Ersetzungscode des gegenwärtigen Befehls, der die Ersetzung des gegenwärtig ältesten Vertexwertes spezifiziert, oder (ii) unverändertes Belassen des gegenwärtig ältesten Vertexwertes, Ersetzen des gegenwärtig mittlersten Vertexwertes durch den neuesten Vertex und Ersetzen des neuesten Vertexwertes durch einen Vertexwert, der in dem gegenwärtigen Befehl spezifiziert ist, in Antwort auf den Ersetzungscode des gegenwärtigen Befehls, der die Ersetzung des mittlersten Vertexwertes spezifiziert.
Verfahren nach einem der Ansprüche 25 bis 28, wobei der Netzpufferspeicher als ein Stapel implementiert wird, und wobei Befehle, die auf Vertexparameterinformation Bezug nehmen, die in dem Netzpufferspeicher abgelegt sind, einen Offset innerhalb des Stapels beinhalten.
Verfahren nach einem der Ansprüche 19 bis 29, wobei die komprimierten 3-D-Geometriedaten einen dritten Befehl beinhalten, der die Ausführung von einem oder mehreren nachfolgenden Befehlen veranlaßt, um ein oder mehrere der folgenden Punkte zu beinhalten: Speichern der Farbinformation mit der Vertexparameterinformation in dem Netzpufferspeicher, Speichern der normalen Information mit der Vertexparameterinformation in dem Netzpufferspeicher, Abrufen der Farbinformation von dem Netzpufferspeicher, Abrufen der normalen Information von dem Netzpufterspeicher, Verwenden der Farbinformation, die von dem Netzpufferspeicher abgerufen wurde, oder Verwenden der normalen Information, die von dem Netzpufterspeicher abgerufen wurde.
Verfahren nach einem der Ansprüche 19 bis 30, wobei die Vertexparameterinformation aus der Gruppe ausgewählt wird, die besteht aus: (i) Positionswerten, (ii) Farbwerten, (iii) Normalen-Werte, (iv) Texturabbildungskoordinaten und (v) Oberflächenmaterialeigenschaften.
Verfahren nach einem der Ansprüche 19 bis 31, wobei die Vertexparameterinformation in einem Format codiert wird, das aus der Gruppe ausgewählt wird, die besteht aus: (i) Absolutwerten und (ii) deltacodierten Werten.
Computersystem für die Dekomprimierung von komprimierten 3-D-Geometriedaten, wobei die komprimierten 3-D-Geometriedaten eine Mehrzahl von Befehlen beinhalten, die eine Mehrzahl von Vertices beschreiben, wobei die Mehrzahl von Vertices verwendbar sind, um eine Mehrzahl von geometrischen Grundelementen zu bilden, um eine Oberfläche eines dreidimensionalen graphischen Objektes darzustellen, wobei das Computersystem aufweist: eine Eingabeeinheit, die derart konfiguriert ist, daß sie einen ersten Befehl der Mehrzahl von Befehlen empfängt, wobei der erste Befehl ein oder mehrere Vertexparameterwerte eines ersten Vertex der Mehrzahl von Vertices beinhaltet, eine Dekomprimierungseinheit, die mit der Eingabeeinheit verbunden ist, wobei die Dekomprimierungseinheit derart konfiguriert ist, daß sie ein erstes geometrisches Grundelement in Antwort auf den Empfang einer ersten Untergruppe der Mehrzahl von Befehlen, die den ersten Befehl beinhaltet, bildet, einen Netzpufferspeicher, der mit der Dekomprimierungseinheit verbunden ist, wobei der Netzpufterspeicher eine feste Maximalzahl von Speicherstellen hat, die konfiguriert sind, um Vertexparameterwerte entsprechend ausgewählter der Mehrzahl von Vertices zu speichern, und wobei die feste Maximalzahl wesentlich kleiner als die Anzahl der Mehrzahl von Vertices ist, wobei der erste Befehl weiterhin beinhaltet eine Anzeige, daß der eine oder die mehreren Vertexparameterwerte des ersten Vertex in dem Netzpufferspeicher für die spätere Verwendung bei der Bildung von nachfolgender geometrischer Grundelemente, die das erste Vertex aufweisen und auf ein oder mehrere geometrische Grundelemente folgen, die nicht das erste Vertex aufweisen, abgelegt werden, und wobei die Dekomprimierungseinheit derart konfiguriert ist, daß sie den einen oder die mehreren Vertexparameterwerte des ersten Vertex, der in dem Netzpufterspeicher gespeichert ist, bei der Bildung des zweiten geometrischen Grundelementes verwendet in Antwort auf eine Netzpufferspeicherreferenz zu dem ersten Vertex, die in dem zweiten Befehl beinhaltet ist.
Computersystem nach Anspruch 33, bei dem die Dekomprimierungseinheit derart konfiguriert ist, daß sie ein zweites geometrisches Grundelement in Antwort auf das Empfangen eines zweiten Befehles von der Eingabeeinheit zusammensetzt, und wobei die Dekomprimierungseinheit derart konfiguriert ist, daß sie den einen oder die mehreren Vertexparameterwerte des ersten Vertexes, die in dem Netzpufferspeicher abgelegt sind, benützt bei der Bildung des zweiten geometrischen Grundelementes in Antwort auf eine Netzpufterspeicherreferenz auf das erste Vertex, die in dem zweiten Befehl beinhaltet ist.
Computersystem nach Anspruch 34, wobei das zweite geometrische Grundelement von dem ersten geometrischen Grundelement durch zumindest ein geometrisches Grundelement getrennt ist.
Computersystem nach Anspruch 33, 34 oder 35, wobei der Netzpufferspeicher als ein Stapel implementiert wird und wobei die Dekomprimierungseinheit derart konfiguriert ist, daß sie den einen oder die mehreren Vertexparameterwerte des ersten Vertexes in die oberste Stelle des Stapels schiebt in Antwort auf den Empfang des ersten Befehls.
Computersystem nach Anspruch 36, wobei in Antwort auf den Empfang des zweiten Befehls die Dekomprimierungseinheit derart konfiguriert ist, daß sie auf den Netzpufferspeicher Bezug nimmt durch Bereitstellen eines Adreßabstandswertes in den Stapel.
Computersystem nach Anspruch 16 oder 37, wobei die Vertexparameter des ersten Vertex aus der Gruppe ausgewählt werden, die besteht aus: (i) Position, (ii) Normalen, (iii) Farben, (iv) Texturabbildungskoordinaten und (v) Oberflächenmaterialeigenschaften.
Computersoftwareprogramm, das auf einem Trägermedium verkörpert ist, wobei das Softwareprogramm eine Mehrzahl von Befehlen aufweist, wobei die Mehrzahl von Befehlen derart konfiguriert ist, daß sie das Verfahren nach einem der Ansprüche 1 bis 9 oder der Ansprüche 19 bis 32 implementiert, und wobei das Trägermedium ein computerlesbares Medium oder ein Übertragungsmedium ist.
System nach einem der Ansprüche 10 bis 18 oder 33 bis 38, das weiterhin aufweist eine Einrichtung für das Ausführen eines Verfahrens nach einem der Ansprüche 1 bis 9 oder 19 bis 32.