DE69635624T2

DE69635624T2 - System und Verfahren zur Kompression und Dekompression von Daten

Info

Publication number: DE69635624T2
Application number: DE69635624T
Authority: DE
Inventors: Michael F. Los Altos Deering
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1995-08-04
Filing date: 1996-08-05
Publication date: 2006-06-22
Anticipated expiration: 2016-08-06
Also published as: JPH09171568A; DE69624636T2; EP0957451A2; EP0757332B1; DE69624636D1; US5867167A; EP0957450A2; EP0957450B1; EP0957450A3; EP0957451A3; JP3212885B2; EP0757332A2; EP0757332A3; DE69635623T2; US6532012B2; EP0957451B1; US6239805B1; DE69635624D1; US6603470B1; US5793371A

Description

Die vorliegende Erfindung betrifft im allgemeinen die Komprimierung von dreidimensionalen graphischen Daten und insbesondere Verfahren und Vorrichtungen, die verlustbehaftete hohe Komprimierungsraten für die dreidimensionale Geometriekomprimierung zur Verfügung stellen.
Moderne dreidimensionale Computergraphiken verwenden extensiv Geometrie, um dreidimensionale Objekte zu beschreiben, unter Verwendung einer Vielfalt von graphischen Darstellungstechniken. Computergraphiken finden eine breite Verwendung in Anwendungen, die von CAD-Programmen (rechnerunterstütztes Zeichnen und Konstruieren) bis zu Videospielen mit virtueller Realität reichen. Komplexe ebene Oberflächen von Objekten können prägnant dargestellt werden durch Abstraktionen von hohem Niveau, wie zum Beispiel ausgeschnittene, nicht gleichförmige rationale Splins („NURBs"), und häufig kann eine detaillierte Oberflächengeometrie unter Verwendung von Texturabbildungen dargestellt werden. Das Hinzufügen von mehr Realismus erfordert jedoch unverarbeitete Geometrie, üblicherweise in der Form von Dreiecken. Position, Farbe und Normalenkomponenten dieser Dreiecke werden typischerweise als Gleitkommazahlen dargestellt, und das Beschreiben eines isolierten Dreiecks kann bis zu 100 Bytes Speicherplatz erfordern.
Verständlicherweise ist ein erheblicher Raum notwendig für die Abspeicherung von dreidimensionalen Computergraphikobjekten, zum Beispiel auf einer Computerfestplatte oder einer CD-ROM (Nurlese-Speicher in Form einer kompakten Scheibe). In ähnlicher Weise ist eine beachtliche Zeit notwendig, die Übertragung solcher Objekte, zum Beispiel über ein Netzwerk oder von der Platte zu dem Hauptspeicher.
Geometrische Kompression ist ein allgemeiner Platz-Zeit-Kompromiß und bietet bei jedem Niveau die Vorteile einer Speicher/Zwischenverbindungshierarchie. Ein ähnliches Systemproblem existiert für die Speicherung und Übertragung von zweidimensionalen Pixelbilden. Eine Vielzahl von mit Verlust behafteten und verlustfreien Komprimierungs- und Dekomprimierungstechniken wurden für zweidimensionale Pixelbilder entwickelt mit dem Resultat einer Verringerung des Speicherplatzes und der Übertragungszeit. Unglücklicherweise beinhaltet der Stand der Technik keine Komprimierungs-/Dekomprimierungstechniken, die für dreidimensionale Geometrie, die über die Polygonreduktionstechniken hinausgehen, geeignet sind. Die Dissertation mit dem Titel „Compressing the X Graphics Protocol" von John Danskin, Princeton University, 1994 beschreibt jedoch die Komprimierung für zweidimensionale Geometrie.
Geeignete Komprimierung kann die Menge der Geometrie, die in dem schnellen Hauptspeicher eines Computersystems cachegespeichert oder gespeichert werden kann stark vergrößern.
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, der 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 wahrge nommen, 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.
Zusammenfassend besteht daher ein Bedarf für eine graphische Komprimierung, die dreidimensionale Dreiecke komprimieren kann, und deren Format direkt als Zeichenbefehle in die Darstellungshardware geleitet werden kann. Vorzugsweise sollte solch eine Komprimierung leicht implementierbar sein unter Verwendung von Echtreithardware und sollte die Dekomprimierung unter Verwendung von Software oder Hardware erlauben.
„Using the Video Lookup Table for Reflectivity Calculations: Specific Techniques and Graphic Results" von Bass, DH, Computer Graphics and Image Processing, Bd. 17, S. 249–261 (1981) offenbart die Verwendung einer Video-Lookup-Tabelle (LUT) zum Bewirken schneller und flexibler Änderungen an einem Rastergrafikdisplay ohne Änderungen am Bildspeicherinhalt, zum Beispiel für Neubeleuchtungsberechnungen. Der Ansatz basiert auf der Beobachtung, dass, wenn die Position des Beobachters und die Oberflächenbeschaffenheit von Objekten in einer Szene konstant gehalten werden, die Helligkeitsberechnung an einem beliebigen Punkt auf dem Objekt als nur von der Oberfläche normal zu diesem Punkt und den Lichteigenschaften (Richtung, Helligkeit und Farbe) abhängig angesehen werden kann.
Aspekte der Erfindung sind in den beiliegenden Hauptansprüchen dargelegt. Bevorzugte sowie weitere Merkmale der Erfindung sind in den Unteransprüchen beschrieben. Je nach Bedarf können Merkmale der Unteransprüche mit Merkmalen der Hauptansprüche auf verschiedene Weisen kombiniert werden.
Gemäß einer Ausführungsform der vorliegenden Erfindung wird die Geometrie als erstes als generalisiertes Dreiecksgitter dargestellt, dessen Struktur es erlaubt, daß jedes Beispiel eines Eckpunktes in einem linearen Strom vorzugsweise einen Durchschnitt bzw. Mittelwert zwischen 1/3 Dreieck und 2 Dreiecken spezifiziert. Einzelne Positionen, Farben und Normalen werden quantisiert mit einer Komprimierung mit variabler Länge, die auf einzelne Positionen, Farben und Normalen angewendet wird. Quantisierte Werte sind mittels Deltakompression zwischen Nachbarn codiert, um Eckpunktdurchlaufordnungen zur Verfügung zu stellen, und Gitterpufferreferenzen werden erzeugt. Histogramme von Deltapositionen, Deltanormalen und Deltafarben werden erzeugt, nach denen Huffman-Anzeigercodes variabler Länge sowie auch Deltapositionen, Deltanormale und Deltafarben erzeugt werden. Der komprimierte Ausgangsbinärstrom beinhaltet die Ausgangs-Huffman-Tabelleninitialisierungen, geordnete Eckpunktdurchläufe, Ausgangsanzeiger und die Deltapositionen, Deltanormalen und Deltafarben.
Die Dekomprimierung kehrt diesen Prozeß um. Der dekomprimierte Strom aus Dreiecksdaten kann dann zu einer traditionellen Darstellungspipeline geleitet werden, wo er in der vollen Gleitkommagenauigkeit verarbeitet werden kann, um danach angezeigt oder auf andere Weise verwendet werden zu können.
Andere Merkmale und Vorteile der Erfindung werden deutlich anhand der folgenden Beschreibung, in der die bevorzugten Ausführungsformen beispielhaft in Verbindung mit den begleitenden Zeichnungen im Detail ausgeführt worden sind. Es zeigen:
Kurze Beschreibung der Figuren
1 zeigt ein generalisiertes Netzwerk, über das dreidimensionale Geometrie, die komprimiert wurde, übertragen werden kann und dekomprimiert werden kann für die Ansicht durch den Benutzer,
2 zeigt eine generalisierte Dreiecksgitterdatenstruktur und eine generalisierte Gitterpufferdarstellung der Oberflächengeometrie gemäß einer Ausführungsform der vorliegenden Erfindung,
3 stellt die sechsfache Vorzeichenbit- und die achtfache Oktantsymmetrie in einer Einheitskugel dar, die verwendet wird, um die achtundvierzigfache Reduktion in der Nachschlagtabellengröße zur Verfügung zu stellen, gemäß der vorliegenden Ausführungsform,
4A stellt ein Vertexkommando in einem Befehlssatz für die geometrische Komprimierung dar gemäß der vorliegenden Ausführungsform,
4B stellt ein Normalenkommando in einem Befehlssatz für die geometrische Komprimierung dar gemäß der vorliegenden Ausführungsform,
4C stellt ein Farbkommando in einem Befehlssatz für die geometrische Komprimierung dar gemäß der vorliegenden Ausführungsform,
4D stellt ein Gitterpufferreferenzkommando in einem Befehlssatz für die geometrische Komprimierung dar gemäß der vorliegenden Ausführungsform,
4E stellt einen Zustandseinstellbefehl in einem Befehlssatz für die geometrische Komprimierung dar gemäß der vorliegenden Ausführungsform,
4F stellt einen Tabelleneinstellkommandobefehl in einem Befehlssatz für die geometrische Komprimierung dar gemäß der vorliegenden Ausführungsform,
4G stellt einen Durchleitkommandobefehl in einem Befehlssatz für die geometrische Komprimierung dar gemäß der vorliegenden Ausführungsform,
4H stellt einen No-Op-Kommandobefehl variabler Länge in einem Befehlssatz für die geometrische Komprimierung dar gemäß der vorliegenden Ausführungsform,
4I stellt eine Anzeiger- und Deltapositionsdatenstruktur dar gemäß der vorliegenden Ausführungsform,
4J-1 und 4J-2 stellen alternative Anzeiger- und Delta-Normaldatenstrukturen dar gemäß der vorliegen den Ausführungsform,
4K stellt eine Anzeiger- und Delta-Farbendatenstruktur dar gemäß der vorliegenden Ausführungsform,
5 ist ein Flußdiagramm mit Verfahrensschritten in einem geometrischen Komprimierungsalgorithmus gemäß der vorliegenden Ausführungsform,
6 ist ein Blockdiagramm einer Dekomprimierungshardware, die für die Verwendung mit der vorliegenden Erfindung geeignet ist,
7A–7L stellen Objekte dar, die unter unterschiedlichen Bedingungen mit der vorliegenden Ausführungsform komprimiert wurden,
8 ist ein detailliertes Gesamtblockdiagramm einer Dekomprimierungseinheit, die für die Dekomprimierung von Daten geeignet ist, die entsprechend einer Ausführungsform der vorliegenden Erfindung komprimiert wurden,
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 dar,
14B stellt ein bevorzugtes Format für den Eintrag der Huffman-Tabellendaten dar,
15A stellt einen Vertexbefehl dar,
15B stellt Datenformate für Punktkomponenten dar,
15C stellt das Format für den Normaleneinstellbefehl dar,
15D stellt den Farbeinstellbefehl dar,
15E stellt den Befehl für die Gitterpufferreferenz dar,
15F stellt einen Zustandseinstellbefehl dar,
15G stellt einen Tabelleneinstellbefehl dar,
15H stellt einen Durchlaßbefehl dar,
15I stellt einen NOP-Befehl variabler Länge dar und
15J stellt einen Sprungbefehl 8 dar.
Ein Graphikkomprimierer gemäß einer Ausführungsform der vorliegenden Erfindung kann verwendet werden, um den Platz zu reduzieren, der benötigt wird, um dreidimensionale graphische Objekte zu speichern, zum Beispiel auf einer CD-ROM oder dergleichen, sowie auch um die Zeit zu reduzieren, die benötigt wird, um ein komprimiertes dreidimensionales graphisches Objekt beispielweise über ein Netzwerk zu übertragen. Bevor die dreidimensionale Graphikkomprimierung an sich beschrieben wird, wird die Gesamtumgebung, in der die vorliegende Erfindung ausgeführt werden kann, unter Bezug auf 1 beschrieben.
1 stellt ein generalisiertes Netzwerk dar, mit dem dreidimensionale Komprimierung gemäß der vorliegenden Erfindung mit Vorteil verwendet werden kann, um Speicherplatz zu verringern und die Zeit zu verringern, um komprimierte dreidimensionale graphische Objekte zu übertragen. Selbstverständlich könnte die dreidimensionale Graphikkomprimierung gemäß der vorliegenden Erfindung ebenso in anderen Umgebungen verwendet werden, zum Beispiel um die Anforderungen, um dreidimensionale Graphiken auf CD-ROMs zu speichern, zu reduzieren, um Daten in Echtzeit zu komprimieren, beispielsweise in einer interaktiven Fernsehumgebung.
Wie in 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 Nezewerke 30 mit einem oder mehreren Zielclients oder Decodersystemen 40 verbunden ist. Das Netzwerk kann homogen, heterogen oder punkt-zu-punktförmig sein.
Der Server 20 beinhaltet eine zentrale Verarbeitungseinheit 50, die die zentrale Prozessoreinheit an sich („CPU") 60 mit verknüpftem Hauptspeicher 70, einem Gitterpuffer 80, einem Speicherabschnitt 90, der vorzugsweise einen Algorithmus enthält, der verwendet wird, um die Komprimierung gemäß der vorliegenden Erfindung zu implementieren, und einem Bereich von Nurlesespeicher („ROM") 100. Die Komprimierung gemäß der vorliegenden Erfindung kann teilweise oder insgesamt in der Hardware im Gegensatz zu der Software ausgeführt werden.
Der Server 20 beinhaltet ebenso eine dreidimensionale graphische Komprimierungseinheit 60, deren komprimierte Ausgangsdaten durch eine Disk-Layout-Einheit 70 für das Ablegen auf der Ablageplatteneinheit 80 angeordnet ist, die ein oder mehrere CD-ROMs beinhalten kann. Der Server kommuniziert über das Netzwerk (die Netzwerke) 30 über eine Netzwerkinterfaceeinheit 110. Fachleute werden erkennen, daß der Server 20 einen Mechanismus beinhalten kann für die Vermittlung zwischen einer Mehrzahl von Client-Decoderanfragen für komprimierte Daten.
Es versteht sich, daß die komprimierten dreidimensionalen Graphikdaten auf der Videodisk oder CD-ROM 80 nicht über ein Netzwerk übertragen werden müssen. Die Disk oder CD-ROM 80 kann beispielsweise zu einem Benutzer verschicht werden, der wünscht auf die hierauf abgelegten kom primierten dreidimensionalen Graphikinformationen zuzugreifen. Wenn sie jedoch beispielsweise über ein Netzwerk übertragen werden, wird die Übertragungszeit in vorteilhafter Weise reduziert, da die Komprimierung die Bitgröße des zu übertragenden Files wesentlich reduziert. Die verlustbehaftete Komprimierung von dreidimensionalen geometrischen Daten gemäß der vorliegenden Erfindung kann Verhältnisse von 6:1 bis 10:1 erzeugen mit einem geringen Verlust in der angezeigten Objektqualität. Weiterhin solch eine Komprimierung zu relativ geringen Kosten in dreidimensionale Darstellungsechtreithardware eingefügt werden oder kann statt dessen implementiert werden unter Verwendung von ausschließlich Softwaretechniken.
In einer Netzwerkumgebung beinhaltet das Decodersystem (die Decodersysteme) 40 an dem Empfangsende ein Zentralverarbeitungssystem 150, das eine CPU 160, Speicher 170, wovon ein Abschnitt 180 die Dekomprimierungssoftware enthalten kann, und ROM 190 beinhaltet. Dreidimensionale Graphiken, die mit einer Ausführungsform der vorliegenden Erfindung komprimiert wurden, können unter Verwendung von Software, Hardware oder einer Kombination hieraus mit Vorteil dekomprimiert werden.
Der Decoder 40 beinhaltet weiterhin eine Netzwerkschnittstelleneinheit 120, eine Einheit 130, die dreidimensionale Graphikdaten dekomprimiert, und deren Ausgang mit einer dreidimensionalen Graphikdarstellungseinheit 140 verbunden ist. Das (die) somit dekomprimierten dreidimensionalen Graphikbild(er) kann (können) dann mit einem Viewer 200 gekoppelt sein oder mit einem anderen System, das die dekomprimierten Graphiken erfordert. Natürlich kann die Einheit 40 eine Einzeleinheit sein, in die die dreidimensionalen Graphikdaten, die gemäß einer Ausführungsform der vorliegenden Erfindung vorkomprimiert wurden, für die Dekomprimierung eingekoppelt werden können. Die Einheit 40 kann beispielsweise einen Computer oder eine Workstation umfassen.
Die Patentanmeldung EP-A-0 757 333 des Anmelders, die an demselben Tag wie die vorliegende Anmeldung eingereicht wurde, mit dem Titel „Method and Apparatus for Decompression of compressed geometric three-dimensional Graphics Data" zeigt ein bevorzugtes Verfahren und System für die Dekomprimierung von Daten, die gemäß einer Ausführungsform der vorliegenden Erfindung komprimiert wurden. Die Dekomprimierung kann mit Hilfe eines Software implementierten Dekompressionsalgorithmus implementiert werden, obgleich die Dekomprimierung ebenso teilweise oder vollständig mittels Hardware implementiert werden könnte.
Der Betrieb der dreidimensionalen Graphikkomprimierungseinheit 60 wird nun beschrieben. In der. vorliegenden Ausführungsform wandelt die erste Stufe der geometrischen Komprimierung Dreiecksdaten in eine effiziente lineare Streifenform, nämlich ein generalisiertes Dreiecksgitter um. Für eine gegebene feste Kapazität des Speichermediums 80, ist eine Dreiecksgitterdatenstruktur eine nahezu optimale Darstellung von Dreiecksdaten. In der Ausführungsform können dreidimensionale graphische Objekte als dreidimensionale Dreiecksdaten dargestellt werden, deren Format nach der Umwandlung veranlaßt, daß jeder lineare Streifenvertex im Mittel zwischen etwa 1/3 Dreiecke bis etwa 2 Dreiecke spezifiziert.
Weiterhin erlaubt eine generalisierte Dreiecksstreifenstruktur die kompakte Darstellung der Geometrie, während eine lineare Datenstruktur beibehalten wird. Anders ausgedrückt, kann die komprimierte Geometrie durch einen einzelnen monotonen Scan über die Vertexarraydatenstruktur extrahiert werden. Dieses Merkmal ist von Vorteil für Hardwareimplementierungen mit Pipeline.
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 geometrische Komprimierung gemäß der Erfindung verschiebt explizit alte Eckpunkte (zum Beispiel Eckpunkte mit einem führenden Buchstaben "p" wie oben) in eine Warteschlange, die mit dem Gitterpufferspeicher 80 verknüpft ist (siehe 1). Auf diese alten Eckpunkte wird später explizit Bezug genommen, wenn der alte Eckpunkt wieder gewünscht ist. Dieser Ansatz stellt eine Feinkontrolle zur Verfügung, die irreguläre Gitter von nahezu jeder Form unterstützt. Der Pufferspeicher 80 hat in der Praxis eine endliche Länge und in der bevorzugten Ausführungsform wird eine maximale feste Warteschlangenlänge von 16 verwendet, was einen 4-Bit-Index erfordert. Der Begriff „Gitterpuffer", wie er hier verwendet wird, soll sich auf diese Warteschlange beziehen und der Ausdruck „generalisiertes Dreiecksgitter" bezieht sich auf eine Kombination von generalisierten Dreiecksstreifen und Gitterpufferreferenzen.
Die feste Größe des Gitterpuffers 80 erfordert, daß alte 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 der bevorzugten Ausführungsform hat das Gitterpufferreferenzkommando ein 4-Bit-Feld, um anzuzeigen, auf welches altes Vertex erneut Bezug genommen werden sollte, zusammen mit den 2-Bit-Punktersetzungscodes. Gitterpufferreferenzkommandos enthalten kein Gitterpufferverschiebungsbit; alte Eckpunkte können nur einmal recycelt werden.
In der Praxis bestehen Geometrien selten nur aus Positionsdaten. Im allgemeinen werden eine Normale und/oder eine Farbe und/oder Texturabbildungskoordinaten ebenso je Vertex spezifiziert. Dementsprechend enthalten in der bevorzugten Ausführungsform die Einträge in den Gitterpuffer 80 Speicher für alle verknüpften Informationen je Vertex, die ausdrücklich Normalen- und Farbe- und/oder Texturabbildungskoordinaten beinhalten.
Für die maximale Speicherplatzeffizienz wird, wenn ein Vertex in den Datenstrom spezifiziert wird, die Normalen und/oder Farbinformation je Vertex vorzugsweise direkt mit der Positionsinformation gebündelt. Solche eine Bündelung wird vorzugsweise durch zwei Zustandbits gesteuert: Bündel von Normalen mit Vertices (BNV) und Bündel von Farben mit Vertices (BCV). 4E stellt eine Be fehlsstruktur dar, die unter anderem Bits aufweist, Wenn ein Vertex in den Gitterpuffer verschoben wird, steuern diese Bits, ob seine gebündelte Normale und/oder Farbe ebenso verschoben wird.
Es sollte erwähnt werden, daß die Komprimierung gemäß der vorliegenden Erfindung nicht auf Dreiecke begrenzt ist und daß Vektoren und Punkte ebenso komprimiert werden können. Die Linien sind beispielsweise eine Untergruppe von Dreiecken, in denen die Ersetzungsbits MOVE und DRAW sind. Ein Ausgangsvertex ist dann ein Vertex, der einen Endpunkt einer Linie darstellt, deren anderer Vertex der unmittelbar zuvor ausgelassene Vertex ist. Für Punkte sind die Ersetzungsbits DRAW und ein Ausgangsvertex ist der Vertex.
Wenn die CPU 52 ein Gitterpufferreferenzkommando ausführt, wird dieser Prozeß umgekehrt. D.h. die zwei Bits spezifizieren, ob eine Normale und/oder Farbe vererbt werden sollte oder von dem Gitterpufferspeicher 80 gelesen werden sollte oder von der gegenwärtigen Normale oder der gegenwärtigen Farbe erhalten werden sollte. Die Software 58 beinhaltet vorzugsweise explizite Befehle für das Einstellen dieser zwei gegenwärtigen Werte. Eine Ausnahme von dieser Regel existiert jedoch, wenn ein explizites „Setze gegenwärtige Normale"-Kommando von einer Gitterpufferreferenz gefolgt wird mit einem aktiven BNV-Zustandbit. In dieser Situation überschreibt letzteres die Gitterpuffernormale, um die kompakte Darstellung von harten Kanten in den Oberflächenfarben zu gestatten.
Zwei zusätzliche Zustandbits steuern die Interpretation von Normalen und Farben, wenn der Strom aus Vertices in Dreiecke konvertiert wird. Ein Bit für die Replikation von Normalen über dem Dreieck (RNT) zeigt an, daß die Normale in dem Endvertex, das ein Dreieck komplettiert, über das gesamte Dreieck repliziert werden soll. Ein Bit für die Replikation von Farben über das Dreieck (RCT) wird analog definiert, wie in der Befehlsstruktur von 4E gezeigt ist.
Die Komprimierung von xyz Positionen des Bildes wird nun beschrieben. Die Verwendung des 8-Bitexponenten, der mit dem 32-Bit IEEE Gleitkommazahlen verknüpft ist, erlaubt es, daß Positionen in der Größe von subatomaren Teilchen zu Milliarden von Lichtjahren reichen. Für irgendein gegebenes mosaikartig aufgeteiltes Objekt wird jedoch der Exponent tatsächlich nur einmal durch eine gegenwärtige Modelliermatrix spezifiziert und die Objektgeometrie wird effektiv innerhalb eines gegebenen Modellraumes beschrieben unter Verwendung nur einer 24-Bit-Festpunktmantisse. In vielen Fällen werden weit weniger Bits für die visuelle Aufnahme benötigt. Somit unterstützt die geometrische Komprimierungssprache der Anmelderin die variable Quantisierung von Positionsdaten bis hinunter auf 1 Bit.
Im anderen System haben empirische visuelle Test sowie auch Betrachtungen von Halbleiterhardwareimplementierung angezeigt, daß nicht mehr als 16-Bit Präzision pro Positionskomponente für nahezu alle Fälle notwendig ist.
Angenommen, daß jedoch die Position und Skalierung des lokalen Modellraumes je Objekt durch volle 32 Bit oder 64 Bit Gleitkommakoordinaten spezifiziert werden. Unter Verwendung von ausreichender numerischer Sorgfalt können mehrere solcher Modellräume zusammen kombiniert werden, um nahtlose geometrische Koordinatensysteme zu bilden mit einer positionalen Präzision von viel größer als 16 Bit.
Die meiste Geometrie ist lokal. Somit ist innerhalb eines 16 Bit (oder weniger) Modellraumes für jedes Objekt die Differenz (Δ) zwischen benachbarten Vertices in dem generalisierten Gitterpufferstrom wahrscheinlich geringer als 16 Bit in der Signifikanz. Wenn gewünscht, kann man ein Histogramm konstruieren, das die Bitlängen von benachbarten Positions-Δ's in einer Geometriedatenseite darstellt und basierend auf diesem Histogramm einen variablen Längencode zuweisen, um die Vertices kompakt darzustellen. Wie beschrieben werden wird, wird vorzugsweise angepaßte Huffman-Codierung verwendet, um die positionalen Δ's in der Geometriekomprimierung zu codieren.
Die Komprimierung von rot-blau-grün-alpha („RGBA") Farben wird nun beschrieben. Farbdaten werden in ähnlicher Weise behandelt wie Positionen, jedoch mit einer kleineren maximalen Genauigkeit. Somit werden RGBa 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.
Als Ausführungsentscheidung wurde entschieden, dieselbe Δ-Codierung für die Farbkomponenten und für Positionen zu verwenden. Das Gebiet der Farbdatenkomprimierung ist dort, wo geometrische Komprimierung und traditionelle Bildkomprimierung auf die einfachsten Probleme treffen. Viele fortgeschrittene Bildkomprimierungstechniken werden jedoch für die geometrische Farbkomprimierung, aufgrund der Differenz in der Brennweite, vermieden.
Beispielsweise verläßt sich der JPEG-Bildkomprimierungsstandard auf Annahmen über die Ansicht der dekomprimierten Daten, die für die geometrische Komprimierung nicht gemacht werden können. Beispielsweise ist in einer Bildkomprimierung vorher bekannt, daß die Pixel in einer perfekt rechtwinkligen Anordnung erscheinen und daß, wenn sie betrachtete werden, jedes Pixel einen schmalen Bereich von Sehwinkeln schneidet. Im Gegensatz dazu ist bei der geometrischen Komprimierung die Verbindung zwischen dem Betrachter und der gerasterten Geometrie nicht vorhersehbar.
Es ist bei der Bildkomprimierung bekannt, daß die Raumfrequenz der auf dem Auge des Betrachters dargestellten Pixel wahrscheinlich größer ist als die Farbsehschärfe des menschlichen visuellen System. Aus diesem Grund werden Farben im allgemeinen in den YUV-Raum umgewandelt, so daß die UV-Farbkomponenten mit einer niedrigeren Raumfrequenz dargestellt werden können als die Y (Intensität)-Komponente. Üblicherweise werden digitale Bits, die subgesampelte UV-Komponenten darstellen, auf zwei oder mehrere Pixel aufgeteilt. Die geometrische Komprimierung kann jedoch hiervon nicht profitieren, da es keine feste Anzeigeskalierung der Geometrie relativ zu dem Auge des Betrachters gibt. Weiterhin gibt es, wenn komprimierte Dreiecksvertices mit vier bis acht oder mehreren anderen Vertices in dem generalisierten Dreiecksgitter verbunden sind, keinen konsistenten Weg des Teiles der „Hälfte" der Farbinformation über die Vertices.
Ähnliche Argumente treffen auf die raffinierteren Transformationen zu, die in der traditionellen Bildkomprimierung verwendet werden, wie zum Beispiel die diskrete Kosinustransformation. Diese Transformationen nehmen eine reguläre (rechtwinklige) Abfrage von Pixelwerten an und erfordern eine große Menge von wahlfreiem Zugriff während der Dekomprimierung.
Es ist im Stand der Technik bekannt, Pseudofarbennachschlagtabellen zu verwenden, solche Tabellen würden jedoch eine feste maximale Größe erfordern und würden eine relativ teure Resource für die Echtzeitverarbeitung darstellen. Während Pseudofarbindizes zu einem leicht höheren Komprimierungsverhältnis für bestimmte Szenen führen könnten, ist das RGB-Modell generalisierter und beachtlich kostengünstiger zu implementieren.
In dem RGB-Modell, das in der vorliegenden Ausführungsform verwendet wird, werden RGB-Werte als lineare Reflexionswerte dargestellt. Wenn alle Effekte des Lightings bzw. des Beleuchtens vorher bekannt wären, könnten theoretisch ein oder zwei Darstellungsbits fallen gelassen werden, wenn die RGB-Komponenten in einem nicht-linearen oder einem wahrnehmbar linearen Raum (manchmal auch als gammakorrigierter Raum bezeichnet) dargestellt worden wären. In der Praxis tendieren die Belichtungseffekte dazu, nicht vorhersagbar zu sein, und die Umwandlung während der Übertragung von dem nicht-linearen Licht zu dem linearen Licht würde beachtliche Hardwareresourcen erfordern.
Die Komprimierung von Oberflächennormalen wird nun beschrieben. Traditionell wurden 96-Bit-Normalen (drei 32-Bit IEEE Gleitkommazahlen) verwendet bei den Berechnungen, um 8-Bit-Farbintensitäten zu bestimmen. Theoretisch könnten 96 Bits von Information verwendet werden, um 2⁹⁶ 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. In der Praxis werden manche Systeme verwendet, die nur 16 Bit-Normalkomponenten verwenden. In empirischen Tests mit 16-Bit Normalkomponenten hat die Anmelderin bestimmt, daß Ergebnisse von einer Winkeldichte von 0,01 Radianten zwischen den Normalen visuell nicht von feineren Darstellungen unterscheidbar waren. Dies waren etwa 100.000 über eine Einheitskugel verteilte Normalen. Im geradlinigen Raum erfordern diese Normalen immer noch eine höhere Darstellungsgenauigkeit und in der Praxis werden 16 Bit Komponenten, die ein Vorzeichenbit und ein Schutzbit beinhalten, ausgewählt. Dies erfordert immer noch 48 Bits, um eine Normale darzustellen, da jedoch nur 100000 spezifische Normalen von Interesse sind, könnte theoretisch ein einzelner 17 Bit-Index jede dieser Normalen symbolisieren.
Die Verwendung von Normalen als Indizes und die zur Verfügung gestellten resultierenden Vorteile werden nun beschrieben. Ein Verfahren der Umwandlung eines Indexes einer Normalen auf der Einheitskugel zurück in einen 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.
Wie in 3 gezeigt ist, kann jeder Oktant der Einheitskugel kann in sechs identische Komponenten aufgeteilt werden durch Falten um die Ebenen X = Y, X = Z und Y = Z. Die sechs möglichen Sextanten werden mit weiteren drei Bits codiert, so daß nur noch 1/48 der Kugel darzustellen ist.
Die Verwendung der oben erwähnten Symmetrie reduziert die Größe der Nachschlagtabelle um einen Faktor von 8 × 6 = 48. Anstelle des 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. Aus diesen Gründen verwendet die Ausführungsform eine Verteilung mit einem regulären Gitter in dem Winkelraum innerhalb eines Sextanten der Einheitskugel. Als solches werden alle Normalen innerhalb eines Sextanten mit Vorteil anstatt durch einen monolithischen 11-Bit-Index mit zwei orthogonalen 6-Bit-Winkeladressen dargestellt. Diese Konfiguration revidiert dann die vorherige Bitsumme auf 18-Bits. Wie dies für Positionen und Farben der Fall war, können, wenn eine stärkere Quantisierung der Normalen akzeptierbar ist, diese 6-Bit-Indices auf weniger Bits reduziert werden und somit können absolute Normalen unter Verwendung von irgendeiner Zahl von 18 bis hinunter zu 6-Bit dargestellt werden. Wie oben beschrieben wurde, ist dieser Raum vorzugsweise Δ-codiert, um die Anzahl von Bits, die für die Hochqualitätsdarstellung der Normalen erforderlich ist, weiter zu reduzieren.
Nun wird die Parametisierung der Normalencodierungsparametrisierung beschrieben. Punkte auf einer Einheitskugel werden parametrisiert unter Verwendung von Kugelkoordinaten der Winkel θ und Φ, wobei θ der Winkel um die Y-Achse und Φ der Längswinkel von der Y = 0 Ebene ist. Die Gleichung (1) regelt die Abbildung zwischen rechtwinkligen und Kugelkoordinaten wie folgt: x = cosθ·cosΦ y = sinΦ z = sinθ·cosΦ (1)
Punkte auf der Kugel werden als erstes durch den Oktanten gefaltet und dann durch die Sortierungsordnung von xyz in einem der sechs Sextanten gefaltet. Jegliche Tabellencodierung erfolgt in dem positiven Oktanten in dem Bereich, der von den Halbräumen begrenzt ist:
x ≥ z z ≥ y y ≥ 0
Wie in 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-Sextanffeld 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.
Im folgenden wird die Verwendung von Komprimierungsanzeigern durch die Anmelderin beschrieben. Viele Techniken sind bekannt für die minimale Darstellung von Bit-Feldern variabler Länge, jedoch für die Geometriekomprimierung gemäß der vorliegenden Erfindung wird eine Variation eines konventionellen Huffman-Algorithmus verwendet.
Der Huffman-Komprimienungsalgorithmus nimmt einen Satz von darzustellenden Symbolen auf zusammen mit der Frequenz der Auftrittsstatistiken (zum Beispiel Histogramme) dieser Symbole. Hieraus werden Bitmuster mit variabler Länge, die eindeutig identifizierbar sind, erzeugt, die erlauben, daß diese Symbole mit einer nahezu minimalen Gesamtzahl von Bits dargestellt werden, unter der Annahme, daß Symbole bei den spezifizierten Frequenzen auftreten.
Viele Komprimierungstechniken, einschließlich JPEG erzeugen eindeutige Symbole als Anzeiger, um die Länge eines Datenfeldes variabler Länge, das folgt, anzuzeigen. Dieses Datenfeld ist typischerweise ein Δ-Wert spezifischer Länge. Somit besteht der endgültige Binärstrom aus Anzeigersymbolen variabler Länge (selbstbeschreibender Länge), weil jedes mittelbar von einem Datenfeld gefolgt wird, dessen Länge verknüpft ist mit dem einmaligen Anzeigersymbol.
In der vorliegenden Ausführungsform verwendet das Binärformat für die geometrische Komprimierung diese Technik, um die Position, die Normale und die Farbdatenfelder darzustellen. Für die geometrische Komprimierung steht diesen <Anzeiger, Daten>-Feldern ein konvehtionelleres 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. Die bevorzugte Ausführungsform verwendet daher einen einzelnen Feldlängenanzeiger, um die Bitlänge von Δx, Δy und Δz anzuzeigen, obgleich auch eine andere Gestaltungsauswahl getroffen werden kann.
Unglücklicherweise verhindert die Verwendung dieses Ansatzes das Ausnutzen des Vorteils einer anderen Huffman-Technik, um etwas weniger als ein weiteres Bit pro Komponente einzusparen. Die implementierte Ausführungsform gleicht diesen Nachteil jedoch dadurch aus, daß sie nicht zwei zusätzliche Anzeiger-Felder (für Δy und Δz) zu spezifizieren hat. Ein weiterer Vorteil ist, daß die Verwendung eines einzelnen Anzeiger-Feldes es einer Hardware-Dekomprimierungsmaschine erlaubt, alle drei Felder parallel zu dekomprimieren, sofern gewünscht wird.
Ähnliche Argumente gelten für die Δ's der RGBα-Werte und entsprechend wird ein einzelner Feldlängenanzeiger verwendet, um die Bitlänge der R, G, B und, sofern vorhanden, α Felder anzuzeigen.
Absolute und Δ-Normalen werden ebenso parametrisiert durch einen einzelnen Wert (n), der durch einen einzelnen Anzeiger spezifiziert werden kann. Um die Implementierung von Hardware hoher Geschwindigkeit und geringerer Kosten zu erleichtern, war die Länge des Huffman-Anzeigerteldes auf 6 Bit, einen relativ kleinen Wert, begrenzt. Eine Anzeiger-Nachschlagtabelle mit 64 Einträgen erlaubt die Decodierung von Anzeigern in einem Taktzyklus. Eine Tabelle existiert für Positionen, eine andere Tabelle existiert für Normalen und noch eine andere Tabelle existiert für Farben (und optional ebenso für Texturkoordinaten). Jede Tabelle enthält die Länge des Anzeigerfeldes, die Länge des Datenfeldes (der Datenfelder), einen Datennormalisierungskoeffizienten und ein absolutes/relatives Bit.
Für eine vernünftige Hardwareimplementierung muß eine zusätzliche Komplikation angesprochen werden. Wie oben beschrieben wurde, werden alle Befehle in einer 8-Bit-Kopfzeile und einem Körper variabler Länge beendet, wobei genügend Information in der Kopfzeile vorhanden ist, um die Körperlänge zu bestimmen. Die Kopfzeile eines Befehls muß jedoch in dem Datenstrom vor dem Körper des vorherigen Befehls plaziert sein, um der Hardware Zeit zu geben, die Kopfzeileninformation zu verarbeiten. Beispielsweise muß die Sequenz ... B0 H1B1 H2B2 H3 .... codiert werden als ... H1 B0 H2 B1 H3 B2 ... .
Der Befehlssatz für die geometrische Komprimierung, der in der bevorzugten Ausführungsform verwendet wird, wird nun unter Bezug auf die 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 bzw. 4K stellen Anzeiger- und Δ-Positionsdatenstrukturen, Anzeiger- und Δ-Normalendatenstrukturen bzw. einen Anzeiger und die Δ-Farbdatenstruktur dar.
Der Fachmann erkennt, daß auch andere Befehlssätze als die oben beschriebenen statt dessen verwendet werden können, um die vorliegende Erfindung zu implementieren.
Das Verhältnis der Zeit, die für die Komprimierung erforderlich ist, relativ zu der Dekomprimierung ist eine wichtiges Maß für viele Formen der Komprimierung. In der Praxis ist es für die off-line Bildkomprimierung akzeptabel, daß sie vielleicht sechzigmal mehr Zeit als die Dekomprimierung benötigt, jedoch für die Echtzeitvideokonferenz sollte das Verhältnis eins sein.
Die geometrische Komprimierung hat vorteilhafterweise nicht diese Echtzeitanforderung. Selbst wenn die Geometrie während der Übertragung konstruiert wird, erfordern die meisten Geometrie erzeugenden Techniken, zum Beispiel CSG, um Größenordnungen mehr Zeit als für die Anzeige der Geometrie benötigt wird. Ebenso werden in den meisten Anwendungen der geometrischen Komprimierung, im Gegensatz zu kontinuierlichen Bildern, die in Filmen gefunden werden, ein komprimiertes dreidimensionales Objekt für viele sequentielle Einzelbilder dargestellt, bevor es abgelegt wird. Sollte das dreidimensionale Objekt die Animation erfordern, wird die Animation typischerweise mit Modellmatrizen durchgeführt. Tatsächlich ist es für ein CD-basiertes Spiel wahrscheinlich, daß ein Objekt milliardenfach durch den Kundenbenutzer dekomprimiert wird, jedoch nur einmal von der verfassenden Firma komprimiert wird.
Wie einige andere Kompressionssysteme können die geometrischen Kompressionsalgorithmen ein Kompromiß zwischen der Kompressionszeit und dem Kompressionsverhältnis eingehen. Für ein gegebenes Qualitätszielniveau, wenn die zulässige Zeit für die Komprimierung sich erhöht, erhöht sich das Kompressionsverhältnis, das durch ein geometrischen Kompressionssystem erreicht wird. Es gibt einen entsprechenden "Knopf" für die Qualität des resultierenden komprimierten dreidimensionalen Objektes und je niedriger der Qualitätsknopf ist, um so besser ist das erreichte Komprimierungsverhältnis.
Es kann eine ästhetische und subjektive Beurteilung bei der geometrischen Komprimierung angewendet werden. Manche dreidimensionalen Objekte beginnen schlecht zu erscheinen, wenn die Zielquantisierung der Normalen und/oder Positionen leicht reduziert wird, wobei andere Objekte selbst mit einer großen Quantisierungsmenge visuell unverändert bleiben können. Kompression kann manchmal sichtbare Artefakte verursachen, jedoch in anderen Fällen veranlassen, daß das Objekt anders aussieht, nicht notwendigerweise in schlechterer Qualität. In einem Experiment, das von dem Anmelder durchgeführt wurde, beginnt ein Bild eines Elefanten tatsächlich realistischer zu erscheinen, mit mehr faltenartiger Haut, wenn die Bildnormalen stärker quantisiert werden. Nachdem ein Modell erzeugt und komprimiert wurde, kann es in eine Bibliothek eingefügt werden, um auf dem Systemlevel als dreidimensionales Clipart verwendet zu werden.
Während viele Aspekte der geometrischen Komprimierung universell sind, wurde der oben beschriebene geometrische Kompressionsbefehlssatz etwas zugeschnitten, um die Hardware-Implementierungen mit niedrigen Kosten und hoher Geschwindigkeit zu erlauben (es versteht sich, daß ein Format für die geometrische Kompression, das lediglich für die Softwaredekomprimierung angepaßt ist, etwas anders sein würde). Der beschriebene geometrische Kompressionsbefehlssatz ist speziell der Hardwareimplementierung unterworfen, aufgrund der sequentiellen Ein-Durchgang-Verarbeitung, der begrenzten lokalen Speicheranforderungen, des Anzeigernachschlagens (im Gegensatz zu der konventionellen sequentiellen Hamming-Bit Verarbeitung) und der Verwendung von Verschiebungen, Additionen und Verweisen, um die meisten arithmetischen Schritte durchzuführen.
5 ist ein Flußdiagramm, das die Verfahrensschritte gemäß der vorliegenden Ausführungsform in einer geometrischen Komprimierungsalgorithmusroutine ausführt. Solch eine Routine kann in dem Speicher 80 abgelegt werden und unter der Steuerung der CPU 60 ausgeführt werden (siehe 1).
In Schritt 200 wird ein Objekt durch eine explizite Gruppe von zu komprimierenden Dreiecken zusammen mit Quantisierungsschwellwerten für die Positionen, die Normalen und die Farben dargestellt. In Schritt 210 wird eine topologische Analyse der Konnektivität durchgeführt und harte Kanten werden in Normalen und/oder der Farbe markiert, falls solch eine Information nicht bereits präsent ist.
In Schritt 220 wird die Vertexdurchquerungsordnung und die Gitterpufferpräferenzen erzeugt und in Schritt 230 werden Histogramme der Δ-Positionen, der Δ-Normalen und der Δ-Farben kreiert. In Schritt 240 werden getrennte Huffman-Anzeigercodes variabler Länge für die Δ-Positionen, die Δ-Normalen und die Δ-Farben, basierend auf den Histographen zugewiesen.
In Schritt 250 wird ein binärer Ausgangsstrom erzeugt durch zunächst Ausgeben der Huffman-Tabelleninitialisierung, nachdem die Vertices in der Ordnung durchquert werden. Geeignete Anzeiger und Δ's werden für alle Werte ausgegeben.
Der Anmelder hat einen Wellenfront OBJ-Formatkomprimierer implementiert, der die Kompression von Positionen und Normalen unterstützt und voll generalisierte Dreiecksstreifen erzeugt, hat jedoch noch keinen, ein vollständiges Gitter bildenden Algorithmus implementiert. Weitere Ausführungsformen werden die Geometrie mit variabler Genauigkeit untersuchen, einschließlich feinstrukturierter Aktualisierungen der Kompressionstabellen. Der vorliegende Komprimierer wendet Zeit dafür auf, geometrische Details zu berechnen, die dem Tesselator bereits bekannt sein und letzten Endes wird gehofft, die komprimierten geometrischen Daten direkt zu erzeugen. Jedoch kann selbst der gegenwärtige unoptimierte Zustand der Software des Anmelders in vielen Fällen etwa 3000 Dreiecke/Sekunde komprimieren.
Es ist an dem Benutzerende natürlich wünschenswert, die komprimierten Daten zu dekomprimieren, und die oben angeführte Patentanmeldung beschreibt eine bevorzugte Art und Weise solch einer Dekomprimierung. Ein anwendbarer geometrischer Dekompressionsalgorithmus kann wie folgt ausgeführt sein.

(1) Rufe den Rest des nächsten Befehls ab und die ersten acht Bits des folgenden Befehls,
(2) Expandiere unter Verwendung der Zeigertabelle alle komprimierten Wertfelder auf volle Präzision,
(3A) falls die Werte relativ sind, addiere sie zu gegenwärtigem Wert, anderenfalls ersetze sie,
(3B) wenn auf Gitterpuffer Bezug genommen wird, greife auf alte Werte zurück,
(3C) falls anderes Kommando, führe Verwaltung durch.
(4) Falls Normale, leite Index durch ROM-Tabelle, um volle Werte zu erhalten.
(5) Gebe Werte generalisierter Dreiecksstreifenform zu nächster Stufe aus.

Der Anmelder hat einen Softwaredekomprimierer implementiert, der komprimierte Geometrie mit einer Rate von etwa 10.000 Dreiecken/Sekunde erfolgreich dekomprimiert. Hardwarekonstruktionen sind in der Entwicklung, ein vereinfachtes Blockdiagramm kann in 6 betrachtet werden. Die Rate der Hardwaredekomprimierung kann in dem Bereich von Dutzenden von Millionen von Dreiecken/Sekunde liegen.
Vergleichende unkomprimierte und komprimierte Bildergebnisse sind in den 7A–7 und in Tabelle 1 unten gezeigt. 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 stel len 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 5f und 5g zeigen eine kombinierte Quantisierung, P48/N18 und P30/M36.
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 Streifen länge auf den Bereich von 2–3 herabgesetzt. Nur wenige, falls überhaupt irgendwelche kommerziellen Produkte profitieren von generalisierten Dreieckstreifen und Tabelle 1 gibt somit die möglichen Einsparungen des Speicherplatzes deutlich zu niedrig an.
TABELLE 1
Während sicherlich eine statischer Variation zwischen den Objekten bezüglich der Komprimierungsverhältnisse besteht, können dennoch allgemeine Trends bemerkt werden. Bei der Komprimierung unter Verwendung der höchsten Qualitätseinstellung des Quantisierungsknopfes (P48/N18) betragen die Komprimierungsverhältnisse typischerweise etwa sechs. Wenn die Verhältnisse nahezu zehn erreichen, beginnen die meisten Objekte sichtbare Quantisierungsartefakte zu zeigen.
Zusammenfassend kann die geometrische Komprimierung gemäß Ausführungsform der vorliegenden Erfindung dreidimensionale Dreiecksdaten mit einem Faktor von sechs bis zehnmal weniger Bits darstellen, als mit konventionellen Techniken erforderlich ist. Der geometrische Komprimierungsalgorithmus der Anmelderin kann in Echtzeithardware oder in Software implementiert werden. Für eine feste Anzahl von Dreiecken kann die Komprimierung die Gesamtbitgröße der Darstellung minimieren, die Qualitäts- und Implementierungskompromissen ausgesetzt ist. Das resultierende geometrisch komprimierte Bild erleidet nur geringe Verluste in der Objektqualität und kann dekomprimiert werden unter Verwendung von Software- oder Hardwareimplementierungen. Wenn dreidimensionale Darstellungshardware eine geometrische Dekomprimierungseinheit enthält, kann die Anwendungsgeometrie im Speicher in komprimiertem Format abgelegt werden. Weiterhin kann die Datenübertragung das komprimierte Format verwenden, wodurch die effektive Bandbreite für ein Graphikbeschleunigungssystem, einschließlich Anzeigeumgebungen mit gemeinsam genutzter virtueller Realität, verbessert wird. Die resultierende Komprimierung kann wesentlich die Geometrie, die im Hauptspeicher cachespeicherbar ist, erhöhen.
Um ein besseres Verständnis der Rolle der vorliegenden Erfindung, insbesondere in einem Komprimierungs-Dekomprimierungssystem, zu unterstützen, wird nun die Dekomprimierung von Daten, die gemäß der vorliegenden Erfindung komprimiert wurden, detaillierter beschrieben. Die folgende Beschreibung der Dekomprimierung ist aus der vorher erwähnten Patentanmeldung der Anmelderin entnommen.
8 ist ein detailliertes Blockdiagramm der Dekomprimierungseinheit 130, die in 1 gezeigt ist. Wein 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 APDF-Abschnitt der Schnittstelle 120 beinhaltet einen Controller, der die Größe des einkommenden Datenstroms der Einheit 130 signalisiert. Der FIFO 200 stellt eine Eingangsblockzustandsmaschine 220 und einem Eingangsblock 210, einer Zustandsmaschine 220 und eine Eingangsblockeinheit 210, die miteinander kommunizieren, zur Verfügung.
Der Ausgang von dem Block 210 ist mit einer Kernverschiebungseinheit 240 und einem Huffman-Tabellensatz 230 verbunden, der Ausgang von der Huffman-Nachschlagetabelle ist mit der Zustandsmaschine 220 verbunden. Operationscode innerhalb der Zustandsmaschine 220 verarbeitet die Werte, die von den Huffman-Tabellen 230 zur Verfügung gestellt werden, und gibt Daten zu der Barrelverschiebungseinheit 240 aus. Die Zustandsmaschine 220 stellt ebenso einen Ausgang zu dem Datenpfadcontroller 260 zur Verfügung, der vorzugsweise ein 12-Bit breites Signal zu einer Anzeiger-Decoder-Einheit 294 ausgibt und ebenso Daten zu der Barrelverschiebungseinheit 240 und zu einem Normalprozessor 270 und zu einem Positions-/Farbprozessor 280 ausgibt.
Die Barrelverschiebungseinheit 240 gibt zu dem Normalprozessor 270 und zu einem Positions-/Farbprozessor 280 aus. Die Ausgänge von den Prozessoren 270 und 280 werden im Multiplexverfahren durch die Ausgangsmultiplexereinheit 290 in ein vorzugsweise 48-Bit breites Signal übertragen, das einem Formatkonvertierer 292 zur Verfügung gestellt wird.
Die Dekompressionseinheit 130 erzeugt einen vorzugsweise 12-Bit-Anzeiger, der zu dem Anzeigerdecoder 294 parallel mit entweder 32 Bits oder 48 Bits (für die Normalen) gesendet wird, die zu dem Formatkonvertierer 292 gesendet werden. Diese Datenströme stellen Befehle zur Verfügung, die eine Ausgabe für den Formatkonvertierer 292 erzeugen. Ein vorzugsweise 32 Bit Rücklesepfad wird verwendet, um den Zustand der Einheit zurückzulesen.
Tabelle 2 unten zeigt Schnittstellensignale, die verwendet werden, um eine bevorzugte Ausführungsform der Dekompressionseinheit 130 zu implementieren: Tabelle 2
Die Tabelle 3 unten zeigt Ausgangsdatenformate, die von der Einheit 130 zur Verfügung gestellt werden. Wie hier beschrieben wird, erzeugen Vertex, Gitterpufferreferenz und Durchleitbefehle Transaktionen von der Dekomprimierungseinheit 130. Vertex und Gitterpufferreferenzbefehle senden Daten zu dem Formatwandler und jeder erzeugt einen Header, der die Vertexersetzungspolicy bzw. -methode für den gegenwärtigen Vertex, gefolgt durch Komponentendaten, anzeigt. Jeder dieser Befehle erzeugt immer Positionsdaten und kann abhängig von dem Wert des Zustandsregisters Farb- oder Normalendaten enthalten. Alle drei der Normalenkomponente werden vorzugsweise parallel gesendet, wobei jede Positions- und Farbkomponente getrennt gesendet wird. Ein Durchleitbefehl sendet vorzugsweise 32 Bits von Daten zu dem Sammelpuffer.
Tabelle 3
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 8000 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. Vorzugsweise wird ein Gitterpuffer 794 als ein Registerfile und als ein Zeiger auf den gegenwärtigen Ort implementiert. Daten werden an der Position des Zeigers auf den gegenwärtigen Ort in den Gitterpuffer FIFO eingegeben. Es ist jedoch der wahlfreie Zugriff auf irgendeinen der 16 Orte erlaubt, wenn die Daten aus dem FIFO ausgelesen werden, durch Weiterindizieren dieses Zeigers: address = (curr_loc_ptr-Index) mod 16.
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. Vorzugsweise werden die folgenden Zustandsbits definiert:

Bit 5: tex: – Texturwerte anstelle von Farbwerten
Bit 4: rnt: – Repliziere Normale je Vertex
Bit 3: rct: – Repliziere Farbe je Vertex
Bit 2: bnv: – Normale gebündelt mit Vertex
Bit 1: bcv: – Farbe gebündelt mit Vertex
Bit 0: cap: – Farbe beinhaltet alpha (α)

Die Positions-/Farbprozessoreinheit 280 (Siehe 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 Normalene Einstellbefehls oder sie werden durch den Vertex-Befehl aktualisiert, wenn das bnv-Bit in dem Zustandsregister gesetzt ist.
Der Positions-/Farbprozessor 280 beinhaltet weiterhin vorzugsweise vier 16-Bitregister, curr_r, curr_g, curr_b, curr_a, die die gegenwärtigen Farbkomponenten, rot, grün, blau und alpha (α) enthalten. Diese Komponenten werden eingestellt unter Verwendung des Farbeinstellbefehls oder sie werden durch den Vertex-Befehl aktualisiert, wenn das bcv-Bit in dem Zustandsregister eingestellt ist. Vorzugsweise ist alpha nur gültig, wenn das cap-Bit in dem Zustandsregister gesetzt ist. Das Testbit wird eingestellt, wenn die Texturkomponenten verarbeitet werden, wobei in diesem Fall nur rot und grün gültig sind.
Ein bevorzugter Befehlssatz, der die Dekomprimierung von gemäß der vorliegenden Erfindung komprimierten Daten implementiert, wird nun beschrieben. 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

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 ein bevorzugtes Format für den Gitterpufferreferenzbefehl. Dieser Befehl veranlaßt, daß Daten von einem Eintrag in den Gitterpuffer nach außen zu dem Formatumwandler als nächses Vertex gesendet werden. Unter Bezug auf 15E zeigt der Index den Eintrag an, der von dem Gitterpuffer zu senden ist. Der neueste Eintrag in dem Gitterpuffer hat den Index 0 und der älteste hat den Index 15. REP, die oben beschriebene Ersetzungspolicy für den Vertex-Befehl, ist die gleiche wie die für den Gitterpufferreferenzbefehl verwendete. Die Zustände für den Gitterpufferreferenzbefehl sind wie folgt:

1. Verriegele nächsten Operationscode; Ausgabe Header; verschiebe Barrelrechtsschiebeeinheit 500 (siehe 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 unten 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. Es versteht sich, daß die parallele Dekomprimierung eines Datenstroms implementiert werden kann durch zur Verfügung stellen eines zusätzlichen Kommandos, das über die Ankunft einer gegebenen Anzahl von Datenworten, die parallel verarbeitet werden können, informiert. Die Anwesenheit von solchen parallelen Möglichkeiten kann durch die Anwesenheit von Markierungsbits erkannt werden, mit deren Auftreten die angegebene Anzahl von Datenworten zu anderen Prozessoren innerhalb des Systems hin- und hergeschickt werden können für die parallele Dekomprimierung. Weiterhin ist es dann zulässig, über die gegebene Anzahl von Worten in dem Datenstrom zu springen, um bei den nächsten Daten anzukommen, die nicht für die Parallelverarbeitung geeignet sind.
Weiterhin kann ebenso die Morphing-Fähigkeit implementiert werden, um jedes abrupte Wahrnehmungsgap in der Betrachtung eines dekomprimierten dreidimensionalen Objektes zu eliminieren. Es ist innerhalb des dekomprimierten Datenstroms möglich, Vertices als lineare zu spezifizieren oder andere Interpolationen von Vertices zu spezifizieren, die tatsächlich vorhanden sind oder vorher dekomprimiert wurden. Angenommen, daß beispielsweise das dreidimensionale Objekt ein Tiger ist. In einem weiten Abstand sind keine Zähne in dem Mund des Tigers vorhanden, doch bei nahem Abstand sind Zähne vorhanden. Das Ergebnis ist ein nahtloser Übergang, so daß, wenn der Abstand zu dem Tiger sich verringert, die Zähne wachsen, wobei kein plötzlicher Übergang zwischen einem zahnlosen Tiger und einem gezahnten Tiger gesehen wird.
Änderungen und Varianten der offenbarten Ausführungsbeispiele können gemacht werden, ohne von dem Schutzumfang der folgenden Ansprüchen abzugehen.

Claims

Verfahren für das Komprimieren einer ersten Oberflächennormalen, die zu einem dreidimensionalen graphischen Objekt korrespondiert, das aufweist: Empfangen von ersten Oberflächennormalendaten, die eine erste Oberflächennormale darstellen, und Komprimieren der ersten Oberflächennormalen, wobei das Komprimieren aufweist: Kodieren von Informationen, die einen bestimmten Oberflächenbereich einer vorbestimmten Kugel identifiziert, und Kodieren von Information, die einen Ort eines ersten Punktes aus einer Mehrzahl von Punkten auf der bestimmten Oberflächenregion identifiziert.
Verfahren nach Anspruch 1, wobei das Komprimieren dann weiterhin aufweist das Normalisieren der ersten Oberflächennormalen.
Verfahren nach Anspruch 1 oder 2, bei dem die ersten Oberflächennormalendaten vorzeichenbehaftete x-, y- und z-Werte aufweisen, wobei das Kodieren der Information, die die bestimmte Oberflächenregion identifiziert, das Verwenden der Vorzeichen-Bits der x-, y- und z-Werte aufweist, um einen Oktant der vorbestimmten Kugel auszuwählen.
Verfahren nach Anspruch 3, bei dem das Komprimieren weiterhin aufweist das Sortieren der x-, y- und z-Werte in einer vorbestimmten Ordnung und Verwenden zumindest eines Teiles der x-, y- und z-Werte, um einen Sextantunterabschnitt des ausgewählten Oktanten auszuwählen.
Verfahren nach einem der vorherigen Ansprüche, bei dem die ersten Oberflächennormalendaten vorzeichenbehaftete x-, y- und z-Werte aufweisen, wobei das Kodieren der Information, die den Ort des ersten Punktes identifiziert, das Quantisieren der ersten Oberflächennormalen aufweist unter Verwendung zumindest eines Teils der x-, y- und z-Werte, um einen Ort aus der Tabelle von Orten auf der bestimmten Oberfläche der vorbestimmten Kugel auszuwählen.
Verfahren nach einem der vorherigen Ansprüche, wobei das Komprimieren weiterhin aufweist: Erzeugen eines Indexwertes und eines oder mehreren Abbildungswerten und Speichern des Indexwertes und des einen oder der mehreren Abbildungswerte, wobei der Indexwert verwendbar ist, um einen ersten Satz von Zwischenoberflächennormalendaten aus einer Mehrzahl von Gruppen von Zwischenoberfächennormalendaten auszuwählen, und wobei der eine oder die mehreren Abbildungswerte verwendbar sind, um dekomprimierte Oberflächennormalendaten aus der ersten Gruppe von Zwischenoberflächennormalendaten zu erzeugen.
Verfahren nach einem der vorherigen Ansprüche bei dem das Empfangen das Empfangen eines ersten Satzes von Koordinatenwerten beinhaltet, wobei der erste Satz von Koordinatenwerten einer ersten Gruppe von Koordinatenachsen entspricht, wobei der erste Satz von Koordinatenachsen einen ersten Koordinatenraum festlegt, der die vorbestimmte Kugel beinhaltet.
Verfahren nach Anspruch 6 oder 7, bei dem das Erzeugen des Indexwertes das Durchführen einer ersten Abbildung des ersten Satzes von Koordinatenwerten auf einen zweiten Satz von Koordinatenwerten, die innerhalb einer vorbestimmten Mehrzahl von Gruppen von Koordinatenwerten beinhaltet sind, beinhaltet, wobei jeder der vorbestimmten Mehrzahl von Gruppen von Koordinatenwerten einen Punkt innerhalb des vorbestimmten Oberflächenbereichs der vorbestimmten Kugel entspricht, und wobei der zweite Satz von Koordinatenwerten einen zweiten Punkt innerhalb des vorbestimmten Oberflächenbereichs der vorbestimmten Kugel identifiziert.
Verfahren nach Anspruch 8, bei dem der Indexwert verwendbar ist, um den zweiten Satz von Koordinatenwerten aus der Mehrzahl von Sätzen von Koordinatenwerten während der Dekomprimierung auszuwählen, und wobei der eine oder die mehreren Abbildungswerte verwendbar sind, um den ersten Satz von Koordinatenwerten aus dem zweiten Satz von Koordinatenwerten entsprechend der ersten Abbildung zu erzeugen.
Verfahren nach Anspruch 8 oder 9, bei dem der vorbestimmte Oberflächenbereich der vorbestimmten Kugel innerhalb eines ersten Oktanten der Kugel lokalisiert ist, wobei der erste Oktant in sechs Sextantenbereiche von gleicher Größe unterteilt ist.
Verfahren nach Anspruch 10, bei dem der vorbestimmte Oberflächenbereich der vorbestimmten Kugel ein vorbestimmter Sextantbereich innerhalb des ersten Oktanten ist.
Verfahren nach Anspruch 11, wobei die erste Indexkomponente und die zweite Indexkomponente verwendbar sind, um einen Punkt innerhalb des vorbestimmten Sextantbereiches des ersten Oktanten zu lokalisieren.
Verfahren nach Anspruch 10, 11 oder 12, wobei der eine oder die mehreren Abbildungswerte einen Sextantwert beinhalten, der einen gegebenen Bereich der sechs Sextantenbereiche des ersten Oktanten der vorbestimmten Kugel spezifiziert, wobei die sechs Sextantenbereiche begrenzt werden durch die Ebenen x = y, y = z und x = z innerhalb des ersten Koordinatenraumes.
Verfahren nach Anspruch 13, wobei der Sextantwert verwendbar ist während der Dekomprimierung, um die x-, y- und z-Werte des zweiten Satzes von Koordinatenwerten zu permutieren, um einen Zwischensatz von Koordinatenwerten zu erzeugen, der einen dritten Punkt spezifiziert, der in dem gegebenen Bereich der sechs Sextantenbereiche lokalisiert ist, wobei die Größen des Zwischensatzes von Koordinatenwerten gleich der Größen des ersten Satzes von Koordinatenwerten sind, die den ersten Punkt spezifizieren.
Verfahren nach einem der vorherigen Ansprüche, bei dem der eine oder die mehreren Abbildungswerte weiterhin einen Oktantwert beinhalten, der einen gegebenen Oktanten der vorbestimmten Kugel anzeigt, wobei der gegebene Oktant den ersten Punkt beinhaltet, und wobei die Vorzeichen-Bits des ersten Satzes von Koordinatenwerten den Vorzeichen-Bits von Punkten, die in dem ersten Oktanten lokalisiert sind, entsprechen.
Verfahren nach einem der vorherigen Ansprüche, wobei die erste Normale absolut spezifiziert wird durch die komprimierte Darstellung der ersten Normalen und wobei die komprimierte Darstellung der ersten Normalen ebenso den einen oder die mehreren Abbildungswerte beinhaltet.
Verfahren nach einem der vorherigen Ansprüche, bei dem die erste Normale relativ zu einer vorher spezifizierten Normalen delta-kodiert ist, und wobei der eine oder die mehreren Abbildungswerte verwendbar sind, um die erste Normale zu dekomprimie ren und in einer komprimierten Darstellung der vorher spezifizieren Normalen enthalten sind.
Verfahren nach Anspruch 6 oder einem der Ansprüche 7 bis 17, soweit hiervon abhängig, wobei der Indexwert eine erste Indexkomponente und eine zweite Indexkomponente beinhaltet, wobei der zweite Satz von Koordinatenwerten während der Dekomprimierung unter Verwendung sowohl der ersten Indexkomponente als auch der zweiten Indexkomponente ausgewählt wird.
Verfahren nach Anspruch 18, bei dem die erste Indexkomponente relativ zu einer vorherigen ersten Indexkomponente delta-kodiert ist und wobei die zweite Indexkomponente relativ zu der vorherigen zweiten Indexkomponente delta-kodiert ist.
System zum Komprimieren einer ersten Oberflächennormalen entsprechend einem graphischen Objekt, das aufweist: einen Prozessor (60) und einen Speicher (70), der mit dem Prozessor verbunden ist, wobei der Speicher konfiguriert ist, um erste Oberflächennormalendaten entsprechend der ersten Oberflächennormalen zu speichern, wobei der Prozessor konfiguriert ist, um die ersten Oberflächennormalendaten durch Verwendung von geometrischen Merkmalen der ersten Oberflächennormalen zu komprimieren, um die ersten Oberflächennormalendaten zu komprimieren, wobei die ersten Oberflächennormalendaten einen ersten Satz von Koordinatenwerten beinhalten, wobei der erste Satz von Koordinatenwerten einem ersten Satz von Koordinatenachsen entspricht, wobei der erste Satz von Koordinatenachsen einen ersten Koordinatenraum festlegt, der eine vorbestimmte Kugel beinhaltet, wobei der erste Satz von Koordinatenwerten einen ersten Punkt identifiziert, der auf einer Oberfläche der vorbestimmten Kugel lokalisiert ist, wobei die geometrischen Merkmale der ersten Oberflächennormalen einen Oktanten und einen Sextanten der vorbestimmten Kugel beinhalten, auf der die erste Oberflächennormale liegt.
System nach Anspruch 20, bei dem die ersten Oberflächennormalendaten einen ersten Satz von Koordinatenwerten beinhalten, wobei der erste Satz von Koordinatenwerten einem ersten Satz von Koordinatenachsen entspricht, wobei der erste Satz von Koordinatenachsen einen ersten Koordinatenraum festlegt, der eine vorbe stimmte Kugel beinhaltet, wobei der erste Satz von Koordinatenwerten einen ersten Punkt identifiziert, der auf einer Oberfläche der vorbestimmten Kugel liegt.
System nach Anspruch 21, bei dem der Prozessor weiterhin konfiguriert ist, um eine erste Abbildung des ersten Satzes von Koordinatenwerten auf einen zweiten Satz von Koordinatenwerten, die innerhalb einer vorbestimmten Mehrzahl von Sätzen von Koordinatenwerten enthalten sind, durchzuführen, wobei jeder der vorbestimmten Mehrzahl von Sätzen von Koordinatenwerten einem Punkt innerhalb eines vorbestimmten Bereiches der Oberfläche der vorbestimmten Kugel entspricht und wobei der zweite Satz von Koordinatenwerten einen zweiten Punkt innerhalb des vorbestimmten Bereiches der Oberfläche der vorbestimmten Kugel identifiziert.
System nach Anspruch 22, bei dem der Prozessor immer noch weiter konfiguriert ist, um den ersten Satz von Koordinatenwerten mit einem Indexwert und einem oder mehreren Abbildungswerten darzustellen, wobei der Indexwert verwendbar ist, um den zweiten Satz von Koordinatenwerten aus der Mehrzahl von Sätzen von Koordinatenwerten während der Dekomprimierung auszuwählen, und wobei der eine oder die mehreren Abbildungswerte verwendbar sind, um den ersten Satz von Koordinatenwerten aus dem zweiten Satz von Koordinatenwerten entsprechend einer ersten Abbildung zu erzeugen.
Verfahren zum Dekomprimieren komprimierter 3-D-Geometriedaten, wobei das Verfahren aufweist: Empfangen einer komprimierten Darstellung einer ersten Normalen, die einem ersten Vertex entspricht, wobei die komprimierte Darstellung (a) Informationen, die einen Ort eines ersten Punktes auf einem ersten vorbestimmten Oberflächenbereich einer vorbestimmten Kugel, die in einem Erstkoordinatenraum lokalisiert ist, identifiziert, und (b) ein oder mehrere Abbildungswerte, die verwendbar sind, um den ersten Punkt in einen zweiten Oberflächenbereich der vorbestimmten Kugel abzubilden, beinhaltet, und Bilden einer dekomprimierten Darstellung der ersten Normalen unter Verwendung des einen oder der mehreren Abbildungswerte und der Information, die den Ort des ersten Punktes identifiziert,
Verfahren nach Anspruch 24, bei dem das Empfangen der komprimierten Darstellung der ersten Normalen beinhaltet: Empfangen eines Kopfzeilenabschnittes, der einen ersten Anzeigerwert beinhaltet, Bestimmen eines Längenwertes eines Textkörperabschnittes unter Verwendung des ersten Anzeigerwertes und Zugreifen auf den Textkörperabschnitt unter Verwendung des Längenwertes, der aus dem ersten Anzeigerwert bestimmt wurden, wobei der Kopfzeilenabschnitt und der Textkörperabschnitt gemeinsam die komprimierte Darstellung der ersten Normalen beinhalten.
Verfahren nach Anspruch 25, das weiterhin aufweist das Verwenden von Information in dem Kopfzeilenabschnitt, um einen ersten Normalisierungskoeffizienten für die erste Normale zu bestimmen, wobei der erste Normalisierungskoeffizient verwendbar ist für das Skalieren auf vorbestimmte numerische Bereiche.
Verfahren nach Anspruch 25 oder 26, das weiterhin aufweist das Verwenden von Information in dem Kopfzeilenabschnitt, um einen ersten Absolut-/Relativwert für die erste Normale zu bestimmen, wobei der erste Absolut-/Relativwert anzeigt, ob die erste Normale absolut spezifiziert oder delta-kodiert wird.
Verfahren nach einem der Ansprüche 24 bis 27, wobei die Information, die den Ort des ersten Punktes identifiziert, zumindest einen Indexwert beinhaltet, wobei das Ausbilden weiterhin aufweist: Auswählen eines ersten Satzes von Koordinatenwerten unter Verwendung des ersten Indexwertes, wobei der erste Satz von Koordinatenwerten einem ersten Satz von Koordinatenachsen entspricht, wobei der erste Satz von Koordinatenachsen einen ersten Koordinatenraum festlegt, der eine vorbestimmte Kugel beinhaltet, wobei der erste Satz von Koordinatenwerten den ersten Punkt identifiziert, der in dem ersten vorbestimmten Oberflächenbereich der vorbestimmten Kugel lokalisiert ist, und Abbilden des ersten Satzes von Koordinatenwerten auf einen zweiten Satz von Koordinatenwerten unter Verwendung des einen oder der mehreren Abbildungswerte, wobei der zweite Satz von Koordinatenwerten dem ersten Satz von Koordinatenachsen entspricht, wobei der zweite Satz von Koordinatenwerten einen zweiten Punkt auf dem zweiten Oberflächenbereich der vorbestimmten Kugel spezifiziert, und wobei der zweite Satz von Koordinatenwerten verwendbar ist, um eine dekomprimierte Darstellung der ersten Normalen zu bilden.
Verfahren nach Anspruch 28, bei dem das Auswählen eines ersten Satzes von Koordinatenwerten das Verwenden des Indexwertes beinhaltet, um den ersten Satz von Koordinatenwerten aus einer Mehrzahl von vorbestimmten Sätzen von Koordinatenwerten auszuwählen, wobei jeder der Mehrzahl von vorbestimmten Sätzen von Koordinatenwerten einem einer Mehrzahl von vorbestimmten Punkten innerhalb der vorbestimmten Region der vorbestimmten Kugel entspricht.
Verfahren nach einem der Ansprüche 24 bis 29, bei dem die erste Normale relativ zu einer vorher spezifizierten Normalen delta-kodiert ist.
Verfahren nach Anspruch 24, wobei die komprimierten 3-D-Geometriedaten Informationen beinhalten, die eine Mehrzahl von dreidimensionalen Vertices beschreibt, wobei die Mehrzahl von dreidimensionalen Vertices verwendbar sind, um eine Mehrzahl von geometrischen Grundelementen zu bilden, um eine Oberfläche eines dreidimensionalen graphischen Objektes darzustellen.
Verfahren nach Anspruch 28 oder 29, bei dem der Indexwert eine erste Indexkomponente und eine zweite Indexkomponente beinhaltet, wobei der erste Satz von Koordinatenwerten ausgewählt wird unter Verwendung sowohl der ersten Indexkomponente als auch der zweiten Indexkomponente.
Verfahren nach Anspruch 32, bei dem die erste Indexkomponente und die zweite Indexkomponente verwendbar sind, um Punkte auf einem zweidimensionalen Koordinatengitter zu lokalisieren.
Verfahren nach Anspruch 33, bei die erste Indexkomponente und die zweite Indexkomponente verwendbar sind, um Punkte innerhalb des vorbestimmten Bereiches der Oberfläche der vorbestimmten Kugel zu lokalisieren.
Verfahren nach Anspruch 34, wobei der erste Koordinatenraum ein xyz-Koordinatenraum ist und wobei der erste Satz von Koordinatenachsen eine x-Achse, eine y-Achse und eine z-Achse beinhaltet.
Verfahren nach einem der Ansprüche 32 bis 35, bei dem die erste Indexkomponente ein Wert eines Winkels θ ist, wobei der Winkel θ gemessen wird von der y-Achse zu dem ersten Punkt und wobei die zweite Indexkomponente ein Wert eines Winkels Φ ist und wobei der Winkel Φ als Breitenwinkel von der Ebene bei y = 0 zu dem ersten Punkt gemessen wird.
Verfahren nach einem der Ansprüche 32 bis 36, bei dem die vorbestimmte Kugel eine Einheitskugel zentriert auf einen Ursprung des ersten Satzes von Koordinatenachsen ist.
Computersystem (40) für das Dekomprimieren komprimierter 3-D-Geometriedaten, die eine komprimierte Darstellung einer ersten Normalen entsprechend einem ersten Vertex beinhaltet, das aufweist: eine Eingabeeinheit, die verbunden ist, um die komprimierte Darstellung der ersten Normalen zu empfangen, wobei die komprimierte Darstellung zumindest einen Indexwert beinhaltet, wobei die Eingabeeinheit ebenso konfiguriert ist, um ein oder mehrere Abbildungswerte zu empfangen, eine Nachschlagtabelleneinheit, die verbunden ist, um den Indexwert von der Eingabeeinheit zu empfangen, wobei die Nachschlagtabelleneinheit konfiguriert ist, um einen ersten Satz von Koordinatenwerten in Antwort auf das Empfangen des Indexwertes auszugeben, wobei der erste Satz von Koordinatenwerten einem ersten Satz von Koordinatenachsen entspricht, wobei der erste Satz von Koordinatenachsen einen ersten Koordinatenraum festlegt, der eine vorbestimmte Kugel beinhaltet, wobei der erste Satz von Koordinatenwerten einen ersten Punkt identifiziert, der in einem vorbestimmten Bereich einer Oberfläche der vorbestimmten Kugel lokalisiert ist, und eine Abbildungseinheit, die verbunden ist, um den ersten Satz von Koordinatenwerten von der Nachschlagtabelleneinheit und den einen oder die mehreren Abbildungswerte von der Eingabeeinheit zu empfangen, wobei die Abbildungseinheit konfiguriert ist, um einen zweiten Satz von Koordinatenwerten aus dem ersten Satz von Koordinatenwerten unter Verwendung des einen oder der mehreren Abbildungswerte zu erzeugen, wobei der zweite Satz von Koordinatenwerten dem ersten Satz von Koordinatenachsen entspricht, wobei der zweite Satz von Koordinatenwerten einen zweiten Punkt auf der Oberfläche der vorbestimmten Kugel spezifiziert und wobei der zweite Satz von Koordinatenwerten verwendbar ist, um eine dekomprimierte Darstellung der ersten Normalen zu bilden.
Computersystem nach Anspruch 38, bei dem die komprimierten 3-D-Geometriedaten Informationen beinhalten, die eine Mehrzahl von dreidimensionalen Vertices beschreiben, wobei die Mehrzahl von dreidimensionalen Vertices verwendbar sind, um eine Mehrzahl von geometrischen Grundelementen zu bilden, um eine Oberfläche eines dreidimensionalen graphischen Objektes darzustellen.
Computersystem nach Anspruch 38 oder 39, bei dem die Nachschlagtabelleneinheit konfiguriert ist, um eine Mehrzahl von vorbestimmten Sätzen von Koordinatenwerten zu speichern, wobei jeder der Mehrzahl von vorbestimmten Sätzen von Koordinatenwerten einer Mehrzahl von vorbestimmten Punkten innerhalb des vorbestimmten Bereichs der vorbestimmten Kugel entspricht.
Computersystem nach Anspruch 40, bei dem die Nachschlagtabelleneinheit konfiguriert ist, um den ersten Satz von Koordinatenwerten aus der Mehrzahl von vorbestimmten Sätzen von Koordinatenwerten in Antwort auf das Empfangen des Indexwertes auszuwählen.
Computersystem nach einem der Ansprüche 38 bis 41, bei dem der Indexwert eine erste Indexkomponente und eine zweite Indexkomponente enthält, wobei der erste Satz von Koordinatenwerten ausgewählt wird unter Verwendung sowohl der ersten Indexkomponente als auch der zweiten Indexkomponente.
Computersystem nach Anspruch 42, wobei die erste Indexkomponente und die zweite Indexkomponente verwendbar sind, um Punkte auf einem zweidimensionalen Koordinatengitter zu lokalisieren.
Computersystem nach Anspruch 43, bei dem die erste Indexkomponente und die zweite Indexkomponente verwendbar sind, um Punkte innerhalb des vorbestimmten Bereichs der Oberfläche der vorbestimmten Kugel zu lokalisieren.
Computersystem nach Anspruch 44, bei dem der erste Koordinatenraum ein xyz-Koordinatenraum ist und wobei der erste Satz von Koordinatenachsen eine x-Achse, eine y-Achse und eine z-Achse beinhaltet.
Computersystem nach einem der Ansprüche 42 bis 45, bei dem die erste Indexkomponente ein Wert eines Winkels θ ist, wobei der Winkel Φ gemessen wird von der y-Achse zu dem ersten Punkt, und wobei die zweite Indexkomponente ein Wert eines Winkels Φ ist, wobei der Winkel Φ als Höhenwinkel von der Ebene bei y = 0 zu dem ersten Punkt gemessen wird.
Computersystem nach einem der Ansprüche 38 bis 46, bei dem die vorbestimmte Kugel eine Einheitskugel zentriert um einen Ursprung des ersten Satzes von Koordinatenachsen ist.
Computersystem nach einem der Ansprüche 38 bis 47, das weiterhin aufweist eine Normalendekomprimierungstabelle, die eine Mehrzahl von Sätzen von Dekomprimierungsparametern beinhaltet, die für die Normalendekomprimierung verwendbar sind.
Computersystem nach Anspruch 48, bei dem ein erster Satz von Dekomprimierungsparametern ausgewählt wird aus der Gruppe, die besteht aus: (i) einem Längenwert des ersten Anzeigerwertes, (ii) einem Längenwert eines Textkörperdatenabschnittes entsprechend der ersten Normalen, (iii) einem ersten Normalisierungskoeffizienten, der einer ersten Normalen entspricht, und (iv) einem ersten Absolut-/Relativwert entsprechend der ersten Normalen.
Computersystem nach Anspruch 49, bei dem der erste Satz von Dekomprimierungsparametern den ersten Absolut-/Relativwert beinhaltet, und wobei der erste Absolut-/Relativwert anzeigt, daß die erste Normale absolut spezifiziert ist, und wobei der erste Satz von Dekomprimierungsparametern ebenso den ersten Normalisierungskoeffizienten beinhaltet, wobei der erste Normalisierungskoeffizient eine erste Koeffizientenkomponente und eine zweite Koeffizientenkomponente beinhaltet.
Computersystem nach Anspruch 50, bei dem die Eingangseinheit konfiguriert ist, um die erste Indexkomponente des Indexwertes entsprechend der ersten Koeffizientenkomponente des ersten Normalisierungskoeffizienten zu skalieren, wodurch eine erste endgültige Indexkomponente erzeugt wird, und wobei die Eingabeeinheit konfiguriert ist, um die zweite Indexkomponente des Indexwertes entsprechend der zweiten Koeffizientenkomponenten des ersten Normalisierungskoeffizienten zu skalieren, wodurch eine zweite endgültige Indexkomponente erzeugt wird.
Computersystem nach Anspruch 51, bei dem die Eingabeeinheit konfiguriert wird, um die erste endgültige Indexkomponente und die zweite endgültige Indexkomponente zu der Nachschlagtabelleneinheit weiterzuleiten, um den ersten Satz von Ko ordinatenwerten aus der Mehrzahl von vorbestimmten Sätzen von Koordinatenwerten auszuwählen.
Computersystem nach Anspruch 51 oder 52, bei dem die erste endgültige Indexkomponente und die zweite endgültige Indexkomponente verwendbar sind, um Punkte innerhalb des vorbestimmten Bereichs der vorbestimmten Kugel zu lokalisieren.
Computersystem nach einem der Ansprüche 49 bis 53, bei dem der erste Satz von Dekomprimierungsparametern einen ersten Absolut-/Relativwert entsprechend der ersten Normalen beinhaltet und wobei der erste Absolut-/Relativwert anzeigt, daß die erste Normale relativ einer vorher spezifizierten Normalen delta-kodiert ist.
Computersystem nach einem der Ansprüche 38 bis 54, bei dem die Eingabeeinheit konfiguriert ist, um den Indexwert zu einem vorherigen Indexwert zu addieren, um einen endgültigen Indexwert zu erzeugen, wobei die Eingabeeinheit konfiguriert ist, um den endgültigen Indexwert zu der Nachschlagtabelleneinheit weiterzuleiten, um den ersten Satz von Koordinatenwerten auszuwählen.
Computersystem nach Anspruch 55, bei dem der vorherige Indexwert eine vorherige erste Indexkomponente und eine vorherige zweite Indexkomponente beinhaltet und wobei der endgültige Indexwert eine endgültige erste Indexkomponente und eine endgültige zweite Indexkomponente beinhaltet, und wobei der erste Normalisierungskoeffizient eine erste Koeffizientenkomponente und eine zweite Koeffizientenkomponente beinhaltet.
Computersystem nach einem der Ansprüche 38 bis 56, bei dem der eine oder die mehreren Abbildungswerte einen Oktantenwert und einen Unteroktantenwert beinhalten, wobei der Oktantenwert einen bestimmten Oktanten der vorbestimmten Kugel spezifiziert, und wobei der Unteroktantenwert einen bestimmten Unteroktantenbereich in dem vorbestimmten Oktanten der vorbestimmten Kugel spezifiziert.
Computersystem nach Anspruch 57, bei dem die Abbildungseinheit konfiguriert wird, um ein oder mehrere Vorzeichen-Bits des zweiten Satzes von Koordinatenwerten zu erzeugen durch Verwenden von Vorzeichen-Bits des bestimmten Oktanten, der durch den Oktantenwert spezifiziert wird.
Computersoftwareprogramm, das eine Mehrzahl von Befehlen aufweist, die konfiguriert sind, um das Verfahren nach einem der Ansprüche 1 bis 19 oder 24 bis 30 zu implementieren.