DE60001418T2

DE60001418T2 - Geometrische komprimierung von dreidimensionalen grafiken

Info

Publication number: DE60001418T2
Application number: DE60001418T
Authority: DE
Inventors: F. Deering
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1999-06-14
Filing date: 2000-06-14
Publication date: 2003-12-04
Anticipated expiration: 2020-06-15
Also published as: EP1194897B1; US6525722B1; EP1194897A1; DE60001418D1; ATE232624T1; AU5741100A; WO2000077740A1

Description

Technisches Gebiet der Erfindung

Die vorliegende Erfindung betrifft im allgemeinen die Komprimierung und Dekomprimierung dreidimensionaler graphischer Daten und insbesondere die Komprimierung und Dekomprimierung von dreidimensionalen geometrischen Daten, die regelmäßig und unregelmäßig gekachelten ("tiled") Oberflächenabschnitten von graphischen Objekten entsprechen.

Beschreibung des relevanten Standes der Technik

Dreidimensionale (3D-) Computergrafiksysteme, die umfangreiche geometrische Modelle einsetzen, finden breite Verwendung in Anwendungen, wie z. B. der computerunterstützten Konstruktion (CAD), Umgebungen virtueller Realität, Trainings- und Simulationsprogrammen, Spielen und ortsbasierter Unterhaltung. Solche Systeme beinhalten typischerweise einen 3D- Grafikbeschleuniger mit einem spezialisierten Darstellungsuntersystem, das derart konstruiert ist, daß es den Host-Prozessor von den graphischen Verarbeitungsfunktionen entlastet und dadurch die Systemleistung verbessert. In einem System mit einem 3D-Grafikbeschleuniger erzeugt ein Anwendungsprogramm, das auf dem Host-Prozessor ausgeführt wird, Daten, die dreidimensionale graphische Elemente für die Ausgabe auf einer Anzeigevorrichtung definieren. Das Anwendungsprogramm veranlaßt, daß der Host-Prozessor diese Daten zu dem Grafikbeschleuniger überträgt. Der Grafikbeschleuniger empfängt dann die Daten und stellt die entsprechenden Grafikelemente auf der Anzeigevorrichtung dar.
Um die Darstellungsgeschwindigkeit zu verbessern und den Realismus der dargestellten Bilder zu erhöhen, können Techniken, wie z. B. das Schalten des Detailniveaus (LOD) verwendet werden. Das LOD-Schalten beinhaltet typischerweise die Verwendung von detaillierteren Bildern oder Texturen für Objekte indem Vordergrund einer Szene und die Verwendung von weniger detaillierten Bildern oder Texturen für Objekte in dem Hintergrund. Beispielsweise können für eine Wand, die im Vordergrund ist, Oberflächentexturdetails, wie z. B. Steinmuster, verwendet werden. Im Gegensatz dazu können für eine Wand, die im fernen Hintergrund ist, weniger Details verwendet werden. Die Details der Hintergrundwand können entfernt werden, um die tatsächliche verschwommene Erscheinung von beabstandeten Wänden in der realen Welt nachzuahmen. Ein Weg, die LOD- Schaltung zu implementieren, ist die Verwendung von Polygonvereinfachungen. Die Polygonvereinfachung beinhaltet die Reduzierung der Anzahl von Polygonen, die verwendet wird, um ein Objekt darzustellen.
Um die Darstellungsgeschwindigkeiten weiter zu verbessern, implementieren viele Grafikbeschleuniger eine Technik, die Visibility Culling bzw. Sichtbarkeitsabschneiden genannt wird. Sichtbarkeitsabschneiden bzw. Visibility Culling beinhaltet das Entfernen von nicht sichtbaren Objekten oder Teilen von Objekten aus der Szene, die dargestellt wird. Diese Technik ist jedoch nicht effizient, wenn die meisten Objekte sichtbar sind. In solchen Fällen wird die gesamte Menge der geometrischen Daten von dem Host-Prozessor zu der Darstellungshardware auf dem Grafikbeschleuniger übertragen.
Diese Übertragung der graphischen Grundelemente und Befehle von dem Host-Prozessor zu dem Grafikbeschleuniger über den Systembus ist einer der Hauptengpässe in der Computergrafik. Dieser Engpaß wird problematischer, wenn Verwender von Grafikanwendungsprogrammen eine ständig größere Menge der Komplexität (und somit der Größe) in den geometrischen Modellen erfordern, die verwendet werden, um Visualisierungseffekte zu erzeugen. Das Ergebnis ist, daß langsame Speicheruntersysteme oder langsame Busuntersysteme nicht in der Lage sind, in adäquater Weise geometrische Daten zu der relativ schnellen Echtzeitdarstellungshardware zu liefern. Dies beeinträchtigt die Systemleistung. Zusätzlich kann die Größenanforderung für einen großen Satz von geometrischen Daten ebenso Einschränkungen des Speichers verursachen.
Beispielsweise wird die Darstellung eines großen geometrischen Datensatzes mit einer Million Dreiecken mit 30 Hz einen Systembusdurchsatz von näherungsweise 720 MB/sec (mit einem Verhältnis von 24 Byte/Dreieck) erfordern. Während solche hohen Busbandbreiten für High-End- Systeme verfügbar sind, haben Systeme am unteren Ende bis zum mittleren Bereich typischerweise Bandbreiten in der Größenordnung von 250 bis 320 MB/sec. Die Leistung von preisgünstigen Systemen wird somit durch den Durchsatz durch den Systembus beeinträchtigt, wenn sich die Anforderungen an die geometrische Verarbeitung erhöhen.
Viele Systeme des Standes der Technik verwenden Algorithmen, die die Anzahl von Eckpunkten bzw. Vertices reduzieren, die in den geometrischen Daten enthalten sind. Ein solcher Algorithmus ist die Vertex-Dezimierung. Vertex-Dezimierung versucht, die Gesamtzahl von Polygonen in einem Oberflächenabschnitt ohne Verlust von wichtigen Details zu reduzieren. Eine Veröffentlichung von Schroeder, William J. und Jonathan A. Zarge und William E. Lorensen mit dem Titel "Decimation of Triangle Meshes", Proceedings of SIGGRAPH '92 (Chicago, III., 26.-31. Juli 1992) in ACM Computer Graphics, Band 26, Nr. 2, S. 65-70, Juli 1992, beschreibt eine Form der Vertex-Dezimierung in größerem Detail. Die erreichbare Komprimierung durch Reduzieren der Anzahl von Vertices ist jedoch begrenzt. Insbesondere kann, wenn die Anzahl von Vertices unter ein bestimmtes Niveau fällt, die Bildqualität schnell abfallen. Somit haben Grafikfachleute nach Wegen gesucht, die graphischen Daten, die, nachdem die Anzahl von Vertices reduziert wurde, verbleiben, auf gewünschte Niveaus zu komprimieren.
Zwei solcher Verfahren für die Komprimierung von dreidimensionalen graphischen Daten sind dem Anmelder bekannt. Mit beiden Verfahren kann, wenn die Komprimierung als ein Vorprozeß durchgeführt wird, die Geometrie im Hauptspeicher des Computersystems in einem komprimierten Format gespeichert werden. Die Geometriedaten werden dann zu der Grafikhardware des Computersystems in komprimiertem Format übertragen, um Speicher zu reduzieren und die Anforderungen an die Busbandbreite zu reduzieren. Dekomprimierung kann von der Grafikhardware durchgeführt werden entweder rechnerunabhängig (z. B. unter Verwendung von Softwaredekomprimierung) oder in Echtzeit (z. B. unter Verwendung von Hardware- oder Softwaredekomprimierung).
Von den zwei unterschiedlichen Verfahren für die Komprimierung von Geometriedaten ist eins für regelmäßige Oberflächen und eines für unregelmäßige Oberflächen optimiert. Es werden jedoch keine Vorschriften gemacht für die Behandlung von dreidimensionalen graphischen Daten, die sowohl regelmäßig gekachelte als auch unregelmäßig gekachelte Oberflächen aufweisen. Beispielsweise zeigt Fig. 1 ein 3D-Objekt (einen Kühlschrank) mit hauptsächlich regelmäßig gekachelten Oberflächen, während Fig. 2 ein 3D-Objekt (einen Löwen) mit hauptsächlich unregelmäßig gekachelten Oberflächen zeigt. Fig. 3 stellt jedoch ein 3D-Objekt (einen Bären) mit einer Mischung aus regelmäßig gekachelten und unregelmäßig gekachelten Oberflächen dar.
Aufgrund der Mischung von sowohl regelmäßig gekachelten als auch unregelmäßig gekachelten Oberflächen in Fig. 3 ist keines der Verfahren, die in den Patentanmeldungen beschrieben sind, für diese Daten optimiert. Es ist somit ein neues Verfahren für die effiziente Komprimierung von 3D-Geometriedaten, die sowohl regelmäßige als auch unregelmäßige Oberflächen aufweisen, notwendig.

Zusammenfassung der Erfindung

Die oben ausgeführten Aufgaben können teilweise durch ein Verfahren gelöst werden für die Komprimierung von 3D-Geometriedaten, das in der Lage ist, sowohl regelmäßig gekachelte als auch unregelmäßig gekachelte Oberflächen effizient zu komprimieren. In einer Ausführungsform weist das Verfahren die Untersuchung der 3D-Geometriedaten auf, um die Anwesenheit von regelmäßig gekachelten Oberflächenabschnitten zu erfassen. Die regelmäßig gekachelten Oberflächenabschnitte können dann unter Verwendung einer ersten Codierungsmethode komprimiert werden, während die verbleibenden unregelmäßig gekachelten Oberflächenabschnitte unter Verwendung einer zweiten Codiermethode komprimiert werden können, wobei sich die zweite Codiermethode von der ersten Codiermethode unterscheidet. Mit Vorteil kann die erste Codiermethode für regelmäßig gekachelte Oberflächenabschnitte optimiert sein, während die zweite Codiermethode für unregelmäßig gekachelte Oberflächenabschnitte optimiert sein kann. Es sei bemerkt, daß der Begriff "unregelmäßig gekachelt", so wie er hier verwendet wird, sich auf jeglichen gekachelten Oberflächenabschnitt bezieht, der vorbestimmte Qualifikationen für die Klassifizierung als ein regelmäßig gekachelter Oberflächenabschnitt nicht erfüllt.
In einer Ausführungsform kann die erste Codiermethode die regelmäßig gekachelten Oberflächenabschnitte als Vertex-Raster bzw. Punktraster codieren. Die Vertices werden somit in einem Abtastmuster angeordnet (z. B. in Zeilen und Spalten, die eine rechtwinklige Anordnung von Vertices bilden), die in einem vorbestimmten Muster (z. B. von Seite zu Seite in Zeilen von oben nach unten) abgetastet werden. Als Teil des Vertex-Rasters kann ein "Extend Value" bzw. Bereichswert für jeden regelmäßig gekachelten Oberflächenabschnitt codiert werden. Die Bereichswerte können verwendet werden, um die spezielle Anordnung der Vertices innerhalb des regelmäßig gekachelten Oberflächenabschnittes zu definieren. Beispielsweise kann der Bereichswert die Vertices in dem Raster von einer 8 · 4-Rechteckanordnung anzeigen.
In einer Ausführungsform kann das erste Codierverfahren aufweisen: (1) Spezifizieren eines Bereichs- bzw. Erweiterungswertes für das Vertex-Raster, (2) Spezifizieren von Anfangswerten für ausgewählte interpolierbare Parameter für einen oder mehrere der Vertices und (3) Spezifizieren von Deltawerten, die anzeigen, wie die ausgewählten Parameter über das Vertex-Raster variieren. Eine pro-Vertex-Information kann für bestimmte Vertices innerhalb des Rasters, die Vertex- Parameter haben, die von den spezifizierten Deltawerten abweichen, spezifiziert sein. Pro-Vertex- Information für Vertices, die nicht von den spezifizierten Deltawerten abweichen, jedoch zusätzliche Information haben, die nicht von den Deltawerten dargestellt wird, können ebenso explizit spezifiziert werden. In einer Ausführungsform können die pro-Vertex-Informationen ebenso komprimiert sein (z. B. durch Reduktion der Anzahl von Bits, die verwendet werden, um die konstituenten Vertex- Parameterwerte darzustellen), um die Gesamtgröße der Grafikdaten noch weiter zu reduzieren. Es sei bemerkt, daß Vertex-Parameterwerte, so wie sie hier verwendet werden, Positionsinformation, normale Information, Farbinformation, Beleuchtungs- bzw. Helligkeitsinformation, Spiegelreflexionsinformation, Materialinformation und Texturinformation beinhalten können, jedoch nicht hierauf begrenzt sein müssen.
Das zweite Codierverfahren kann die unregelmäßig gekachelten Oberflächenabschnitte codieren durch Verwendung von Geometriekomprimierung. Eine Anzahl von unterschiedlichen geometrischen Komprimierungstechniken kann verwendet werden (z. B. die Normalkomprimierung und die Gittemetzpufferspeicher).
In einer Ausführungsform kann das Komprimierungsverfahren Operationscodes in die komprimierten Grafikdaten einbetten, um anzuzeigen, wie jeder Vertex codiert wird (z. B. entweder als Teil einer regelmäßig gekachelten Oberfläche oder als Teil einer unregelmäßig gekachelten Oberfläche). Alternativ dazu können Operationscodes eingebettet werden, die anzeigen, ob die Oberfläche, die den Operationscode in den komprimierten Geometriedaten folgt, unter Verwendung des ersten Verfahrens oder des zweiten Verfahrens codiert ist. In beiden Fällen können die Operationscodes entweder eine feste oder eine variable Länge haben. Beispielsweise kann in einer Ausführungsform der Operationscode variabler Länge eine Kopfzeile bzw. einen Header und einen Körper bzw. Body haben, wobei der Header die Länge des Operationscodes enthält und wobei der Body Information enthält, die die folgenden Vertices und/oder Oberflächen betrifft. In anderen Ausführungsformen können andere Anzeiger verwendet werden anstelle von Operationscodes. Beispielsweise können Zeiger- oder Indikatorbits verwendet werden, um Veränderungen in der Komprimierungsmethode innerhalb des Stroms von komprimierten Geometriedaten abzugrenzen.
Optional kann ebenso Fehlerüberprüfungs- und Korrektur- (ECC) und Verschlüsselungsinformation für die komprimierte 3D-Geometrieinformation (oder als Teil hiervon) erzeugt werden. Sobald die 3D-Geometrieinformation komprimiert ist, kann sie auf computerlesbaren Medien gespeichert werden und für die zukünftige Decodierung verteilt werden. Alternativ können die komprimierten Daten über ein Computernetzwerk übertragen werden.
In einer Ausführungsform kann die Komprimierung regelmäßig gekachelte Oberflächen erfassen durch Abtasten der Geometriedaten für Gruppen von Vertices (z. B. rechtwinklige Anordnungen von 32 Vertices oder größer), die jeweils einen oder mehrere Parameter haben, die sich in einer vorhersagbaren Art und Weise ändern (z. B. Parameter, die deltaverschlüsselt sein können unter Verwendung einer vorbestimmten Maximalzahl von Bits). Diese Mehrzahl von ausgewählten Vertices kann codiert werden unter Verwendung des Codierverfahrens, das für regelmäßige Oberflächen optimiert ist (z. B. unter Verwendung von Deltacodierung oder Delta-Delta-Codierung). Es sei bemerkt, daß die Gruppe von Vertices (d. h. die Vertex-Raster) nicht auf eine zweidimensionale Anordnung von gleich verteilten Vertices begrenzt sein müssen. Beispielsweise können die Vertices entsprechend einer kleinen Anzahl von unterschiedlichen Polygonen voneinander beabstandet sein. Beispielsweise können die Polygone Rechtecke, Rhomben, Dreiecke, Hexagone oder Parallelogramme sein.
In einer anderen Ausführungsform kann das Verfahren für die Komprimierung von 3D- Geometriedaten das Codieren von unterschiedlichen Oberflächenabschnitten mit unterschiedlichen Komprimierungsraten abhängig von individuellen Attributen jedes Oberflächenabschnittes aufweisen. Beispielsweise kann ein Oberflächenabschnitt, der eine geringe Variation in den Vertex- Parametern hat, unter Verwendung von Deltacodierung mit nur ein paar wenigen Bits, die für die Deltawerte zugewiesen werden, komprimiert werden, um hohe Komprimierungsverhältnisse zu erreichen. Oberflächenabschnitte, die größere Variationen in den Vertex-Parametern haben, können deltacodiert werden mit einer größeren Anzahl von Bits, die für die Deltawerte zugewiesen werden.
In einer anderen Ausführungsform kann das Verfahren das Umwandeln der Geometriedaten in ein Netzformat aufweisen. Das Netzformat kann zumindest einen unregelmäßigen polygonalen Netzabschnitt und zumindest einen regelmäßigen polygonalen Netzabschnitt beinhalten. Der regelmäßige polygonale Netzabschnitt kann dadurch charakterisiert sein, daß er eine regelmäßige Anordnung von Vertices hat, die Polygone definieren. Die unregelmäßigen polygonalen Netzabschnitte können komprimiert werden unter Verwendung eines ersten Komprimierungsverfahrens. Die regelmäßigen polygonalen Netzabschnitte können komprimiert werden unter Verwendung einer zweiten Komprimierungsmethode. Die zweite Komprimierungsmethode kann jedoch derart konfiguriert sein, daß sie die regelmäßige Anordnung der Vertices verwendet, um einen zweiten Grad der Komprimierung zu erreichen, der sich von dem Grad der Komprimierung unterscheidet, die von dem ersten Komprimierungsverfahren erreicht wird. Die regelmäßigen polygonalen Netzabschnitte können dadurch charakterisiert sein, daß sie eine regelmäßige Anordnung von homogenen polygonalen Netzabschnitten haben.
In einer Ausführungsform wird ebenso ein Softwareprogramm für die Komprimierung von dreidimensionalen Grafikdaten in Betracht gezogen. Die Software kann eine Mehrzahl von Befehlen aufweisen, die derart konfiguriert sind, daß sie regelmäßige Oberflächenabschnitte innerhalb der dreidimensionalen Grafikdaten erfassen. Die regelmäßigen Oberflächenabschnitte können Vertices mit einer oder mehreren Eigenschaften haben, die sich in einer vorhersagbaren Art und Weise ändern. Die Befehle können weiterhin konfiguriert sein, um unregelmäßige Oberflächenabschnitte zu komprimieren unter Verwendung eines ersten Komprimierungsverfahrens und um unregelmäßige Oberflächenabschnitte unter Verwendung eines zweiten Komprimierungsverfahrens zu komprimieren, das eine unterschiedliche Komprimierungsrate als das erste Komprimierungsverfahren erreicht. Das Softwareprogramm kann weiterhin derart konfiguriert sein, daß es Operationscode in die komprimierten Daten einbettet, wobei die Operationscodes anzeigen, welcher Typ von Komprimierung auf dem entsprechenden Oberflächenabschnitt oder den entsprechenden Oberflächenabschnitten verwendet wurde.

KURZE BESCHREIBUNG DER FIGUREN

Fig. 1 ist eine Illustration eines dreidimensionalen Objektes mit mehrheitlich regelmäßig gekachelten Oberflächen,
Fig. 2 ist eine Illustration eines dreidimensionalen Objektes mit mehrheitlich unregelmäßig gekachelten Oberflächen,
Fig. 3 ist eine Illustration eines dreidimensionalen Objektes mit einer Mischung aus regelmäßig und unregelmäßig gekachelten Oberflächen,
Fig. 4 stellt ein verallgemeinertes Netzwerksystem dar, über das die komprimierte dreidimensionale Grafik übertragen werden kann und für die Benutzeransicht dekomprimiert werden kann,
Fig. 5 stellt eine Ausführungsform eines Verfahrens für die Komprimierung von dreidimensionalen geometrischen Daten dar, die sowohl regelmäßige als auch unregelmäßige Oberflächen aufweisen,
Fig. 6 stellt eine andere Ausführungsform eines Verfahrens für die Komprimierung von dreidimensionalen Geometriedaten, die sowohl regelmäßige als auch unregelmäßige Oberflächen aufweisen, dar,
Fig. 7 stellt noch eine andere Ausführungsform eines Verfahrens für die Komprimierung dreidimensionaler Geometriedaten, die sowohl regelmäßige als auch unregelmäßige Oberflächen aufweisen, dar,
Fig. 8 stellt eine verallgemeinerte Dreiecksnetzdatenstruktur und eine verallgemeinerte Netzpufferspeicherdarstellung der Oberflächengeometrie dar,
Fig. 9 stellt das sechsfache Vorzeichenbit und die achtfache Oktantsymmetrie in einer Einheitskugel dar, die verwendet wird, um die 48-fache Reduktion in der Nachschlagtabellengröße zur Verfügung zu stellen,
Fig. 10A stellt eine Ausführungsform eines Vertex-Kommandos in einem geometrischen Komprimierungsbefehlssatz dar,
Fig. 10B stellt eine Ausführungsform einer Normalen, in einem Befehlssatz für die geometrische Komprimierung dar,
Fig. 10C stellt eine Ausführungsform eines Farbbefehls in einem Befehlssatz für die geometrische Komprimierung dar,
Fig. 10D stellt eine Ausführungsform eines Netzpufferreferenzbefehls in einem Befehlssatz für die geometrische Komprimierung dar,
Fig. 10E stellt eine Ausführungsform eines Zustandseinstellbefehls in einem Befehlssatz für die geometrische Komprimierung dar,
Fig. 10F stellt eine Ausführungsform eines Tabelleneinstellkommandobefehls in einem Befehlssatz für die geometrische Komprimierung dar,
Fig. 10G stellt eine Ausführungsform eines nop-Kommandobefehls in einem Befehlssatz für die geometrische Komprimierung dar,
Fig. 10H stellt eine Ausführungsform eines setstate2-Befehls in einem Befehlssatz für die geometrische Komprimierung dar,
Fig. 10I stellt eine Ausführungsform eines setcolor2-Befehls in einem Befehlssatz für die geometrische Komprimierung dar,
Fig. 10J stellt eine Ausführungsform eines setD-Befehls in einem Befehlssatz für die geometrische Komprimierung dar,
Fig. 10K stellt eine Ausführungsform eines setAttribute-Befehls in einem Befehlssatz für die geometrische Komprimierung dar,
Fig. 10L stellt eine Ausführungsform eines setAttributel-Befehls in einem Befehlssatz für die geometrische Komprimierung dar,
Fig. 10M stellt eine Ausführungsform eines gosub-Befehls in einem Befehlssatz für die geometrische Komprimierung dar,
Fig. 10N stellt eine Ausführungsform eines goto-Befehls in einem Befehlssatz für die geometrische Komprimierung dar,
Fig. 10P stellt eine Ausführungsform eines eos-Befehls in einem Befehlssatz für die geometrische Komprimierung dar,
Fig. 10Q stellt eine Ausführungsform eines reservierten Befehls in einem Befehlssatz für die geometrische Komprimierung dar,
Fig. 10R stellt eine Ausführungsform einer speziellen Normalencodierung dar,
Fig. 10S stellt eine Ausführungsform der Bitcodierung dar,
Fig. 10T stellt eine Ausführungsform der Adreßcodierung dar,
Fig. 11 ist ein Flußdiagramm von Verfahrensschritten in einem Algorithmus für die geometrische Komprimierung,
Fig. 12 ist ein Blockdiagramm einer Ausführungsform der Dekomprimierungshardware,
Fig. 13A-13L stellen Objekte dar, die unter verschiedenen Bedingungen komprimiert wurden,
Fig. 14 ist ein detailliertes Gesamtblockdiagramm einer Ausführungsform einer Dekomprimierungseinheit, die für die Dekomprimierung der komprimierten Daten geeignet ist,
Fig. 15 ist ein detailliertes Blockdiagramm einer Ausführungsform des Eingangsblockes, der in Fig. 14 gezeigt ist,
Fig. 16 ist ein detailliertes Blockdiagramm einer Ausführungsform der Barrel-Verschiebungseinheit, die in Fig. 14 gezeigt ist,
Fig. 17 ist ein detailliertes Blockdiagramm einer Ausführungsform der Positions- /Farbprozessoreinheit, die in Fig. 14 gezeigt ist,
Fig. 18A ist ein detailliertes Blockdiagramm einer Ausführungsform der Normalenprozessoreinheit, die in Fig. 14 gezeigt ist,
Fig. 18B ist ein detailliertes Blockdiagramm, das den Decoder, die Faltungseinrichtung und die ROM-Nachschlagkomponenten, die mit der Normalprozessoreinheit von Fig. 14 verknüpft sind, zeigt,
Fig. 19 ist ein Blockdiagramm, das eine Ausführungsform der Schnittstellen zu einem Netzpufferspeicher, wie in Fig. 17 und/oder Fig. 18A gezeigt ist, zeigt,
Fig. 20A stellt Schnittstellen zu Huffman-Tabellen dar,
Fig. 20B stellt eine Ausführungsform für den Eintrag der Huffman-Tabellendaten dar,
Fig. 21A stellt eine Ausführungsform eines Vertex-Befehls dar,
Fig. 21B stellt eine Ausführungsform der Vertex-Komponentendatenformate dar,
Fig. 21C stellt eine Ausführungsform eines Formats für den Normalen-Einstellbefehl dar,
Fig. 21D stellt eine Ausführungsform eines Farbeinstellbefehls dar,
Fig. 21E stellt eine Ausführungsform eines Netzpufferspeicherreferenzbefehls dar,
Fig. 21F stellt eine Ausführungsform eines Zustandseinstellbefehls dar,
Fig. 21G stellt eine Ausführungsform eines Tabelleneinstellbefehls dar,
Fig. 21H stellt eine Ausführungsform eines Durchleitbefehls dar,
Fig. 21I stellt eine Ausführungsform eines NOP-Befehls variabler Länge dar,
Fig. 21J stellt eine Ausführungsform eines skip-Befehls dar,
Fig. 22 stellt eine Ausführungsform eines Computersystems dar, das geometrische Komprimierungsfähigkeiten beinhaltet,
Fig. 23 ist ein vereinfachtes Blockdiagramm des Computersystems von Fig. 22,
Fig. 24 stellt eine Ausführungsform eines Client-Server-Netzwerks dar, das komprimierte geometrische Daten überträgt,
Fig. 25 stellt eine Ausführungsform eines Verfahrens für die Komprimierung geometrischer Daten dar,
Fig. 26 stellt einen Oberflächenabschnitt dar, der ein 5 · 5-Gitter aus Vertices beinhaltet, die als Vertex-Raster dargestellt werden können,
Fig. 27 stellt eine Ausführungsform eines Kommandos dar, um die Größe eines Oberflächenabschnittes einzustellen,
Fig. 28 stellt das Format einer Ausführungsform eines Kommandos dar, Parameter zu initialisieren, die über den Oberflächenabschnitt interpoliert werden,
Fig. 29 stellt eine Ausführungsform einer Traversal- bzw. Durchlaufordnung der Vertices eines Oberflächenabschnittes dar;
Fig. 30A-B stellen eine Ausführungsform eines Formats für Kommandos dar, um Parameter zu variieren, die über die Oberflächenabschnitte interpoliert werden,
Fig. 31A-C stellen Oberflächenabschnitte mit verschiedenen Delta-U- und Delta-V- Positionswerten dar,
Fig. 32A-C stellen eine Ausführungsform eines Formates für Kommandos dar, die Ströme von pro-Vertex-Daten spezifizieren,
Fig. 33A-B stellen eine Ausführungsform eines Formats für Kommandos dar, die Modusbits einstellen, die in der geometrischen Komprimierung und Dekomprimierung verwendet werden,
Fig. 34 stellt eine Ausführungsform eines Formats für ein Vertex-Schritt-Rasterkommando dar,
Fig. 35 stellt einen regelmäßig gekachelten Oberflächenabschnitt dar, der komprimiert werden kann unter Verwendung des Vertex-Schrittrasterkommandos,
Fig. 36 stellt eine Ausführungsform eines Verfahrens für die Komprimierung von Geometriedaten dar unter Verwendung des Vertex-Schrittrasterkommandos,
Fig. 37A stellt Aliasing-Effekte dar, die durch Aufteilung von Oberflächenabschnitten in Vierecke in nur eine Richtung verursacht werden,
Fig. 37B stellt reduzierte Aliasing-Effekte dar, die von einer Ausführungsform der vorliegenden Erfindung gezeigt werden, die die Designierung der Aufteilungsrichtung auf einer quadrilateralen Basis erlaubt,
Fig. 38 stellt einen Oberflächenabschnitt dar, der mit Quad-Split-Bits tesselliert bzw. in ein Mosaik aufgeteilt wurde entsprechend einer Ausführungsform der vorliegenden Erfindung,
Fig. 39 stellt das Format eines Kommandos für die Einstellung der halben Auflösung für die Kante gemäß einer Ausführungsform der Erfindung dar,
Fig. 40A-D stellen Oberflächenabschnitte mit jedem der eingestellten Kantenbits halber Auflösung dar,
Fig. 41 stellt einen Oberflächenabschnitt dar, der den Modus mit halber Auflösung benutzt, um Aliasing-Effekte für ein gegebenes Objekt zu reduzieren,
Fig. 42 stellt ein Blockdiagramm einer Ausführungsform eines graphischen Subsystems dar,
Fig. 43 stellt ein verallgemeinertes Flußdiagramm dar, das eine Ausführungsform eines Verfahrens für das Durchführen der Dekomprimierung von regelmäßig gekachelten Oberflächenabschnitten dar,
Fig. 44 stellt ein Flußdiagramm dar, das eine Ausführungsform eines Verfahrens für das Durchführen der Komprimierung von regelmäßig gekachelten Oberflächenabschnitten dar, das Quad-Split- Bits beinhaltet, und
Fig. 45 stellt ein Flußdiagramm dar, das eine Ausführungsform eines Verfahrens für das Durchführen der Dekomprimierung von regelmäßig gekachelten Oberflächenabschnitten darstellt, das eine untere Kante beinhaltet, die in einem Halbe-Auflösung-Modus dargestellt wird.

DETAILLIERTE BESCHREIBUNG VON VERSCHIEDENEN AUSFÜHRUNGSFORMEN

Ein graphischer Komprimierer gemäß der vorliegenden Erfindung kann verwendet werden, um den Platz zu reduzieren, der benötigt wird, ein dreidimensionales Grafikobjekt auf z. B. einer CD- ROM oder einer DVD-Platte oder dergleichen zu speichern, sowie auch die Zeit zu reduzieren, die benötigt wird, ein komprimiertes dreidimensionales Grafikobjekt beispielsweise über ein Netzwerk zu übertragen. Bevor das Verfahren für die dreidimensionale Grafikkomprimierung im Detail beschrieben wird, wird die Gesamtumgebung, in der die vorliegende Erfindung praktiziert wird, beschrieben.
In Fig. 4 ist eine Ausführungsform eines verallgemeinerten Netzwerks dargestellt. Das Netzwerk kann vorzugsweise eine dreidimensionale Komprimierung gemäß der vorliegenden Erfindung implementieren, um Speicherplatz zu verringern, Übertragungszeiten zu verkürzen und möglicherweise die Darstellungsgeschwindigkeiten für dreidimensionale Grafikobjekte zu erhöhen. Natürlich kann die dreidimensionale graphische Komprimierung gemäß der vorliegenden Verwendung genausogut in anderen Umgebungen verwendet werden. Sie kann beispielsweise verwendet werden, um die Speicheranforderungen zu reduzieren, wenn dreidimensionale Grafiken auf CD-ROMs abgelegt werden, wenn Daten über ein Netzwerk übertragen werden, wenn Daten in einem Speicher in einem Grafiksystem abgelegt werden und um Daten in Echtzeit zu komprimieren (z. B. in einer interaktiven 3D-Fernsehumgebung).
Wie in Fig. 4 gezeigt ist, kann eine Quelle von dreidimensionalen graphischen Daten 10 mit einem Server oder Codiersystem 20 verbunden sein, dessen verarbeiteter oder komprimierter Ausgang über eines oder mehrere Netzwerke 30 mit einem oder mehreren Ziel-Clients oder Decodersystemen 40 verbunden ist. Das Netzwerk kann homogen, heterogen oder Punkt-zu-Punkt sein.
Der Server 20 beinhaltet eine zentrale Verarbeitungseinheit 50, die eine zentrale Prozessoreinheit ("CPU") 62 mit verknüpftem Hauptspeicher 72, einem Netzpuffer 80, einem Speicherabschnitt 90, der vorzugsweise einen Algorithmus enthält, der verwendet wird, um die Komprimierung gemäß der vorliegenden Erfindung zu implementieren, und einen Bereich von Nur-Lese-Speicher ("ROM") 100 beinhaltet. Alternativ kann die Komprimierung gemäß der vorliegenden Erfindung in der Hardware, Software oder einer Kombination hiervon durchgeführt werden.
Der Server 20 beinhaltet ebenso eine dreidimensionale graphische Komprimierungseinheit 60, deren komprimierte Ausgangsdaten durch eine Disk-Layout-Einheit 70 angeordnet sind für das Speichern auf der Speicherdiskeinheit 86, die eine oder mehrere CD-ROMs beinhalten kann. Der Server kommuniziert über das (die) Netzwerk(e) 30 über die Netzwerkschnittstelleneinheit 110. Fachleute werden erkennen, daß der Server 20 einen Mechanismus für das Entscheiden zwischen einer Mehrzahl von Client-Decoder-Anforderungen für komprimierte Daten beinhalten kann.
Es versteht sich, daß die komprimierten dreidimensionalen Grafikdaten auf der Speichereinheit 86 nicht über ein Netzwerk übertragen werden müssen. Eine Diskette oder eine CD-ROM 84 kann beispielsweise zu einem Benutzer verschickt werden, der Zugriff auf die komprimierten dreidimensionalen Grafikinformationen, die hierauf abgelegt sind, wünscht. Wenn sie jedoch z. B. über ein Netzwerk übertragen werden, wird die Übertragungszeit in vorteilhafter Weise reduziert, da die Komprimierung die Bitgröße der zu übertragenden Datei wesentlich reduziert. Abhängig von der Implementierung und den Daten kann die verlustbehaftete Komprimierung von dreidimensionalen geometrischen Daten typischerweise Verhältnisse von etwa 20 : 1 bis 50 : 1 in einigen Ausführungsformen mit geringem Verlust in der angezeigten Objektqualität erzeugen. Verlustfreie Komprimierung kann Komprimierungsverhältnisse von etwa 3 : 1 bis 10 : 1 abhängig von den zu komprimierenden Daten erreichen. Weiterhin kann die entsprechende Dekomprimierungsfunktion zu relativ geringen Kosten in die dreidimensionale Darstellungshardware aufgenommen werden oder kann stattdessen unter Verwendung von ausschließlich Softwaretechniken implementiert werden. Spezialisierte Echtzeit- oder nahezu-Echtzeit-Komprimierungshardware kann ebenso implementiert werden, obwohl sie teurer sein kann.
In einer Netzwerkumgebung beinhaltet das (die) Decodersystem(e) 40 an dem Empfangsende ein zentrales Verarbeitungssystem 150, das eine CPU 160, einen Speicher 170, von dem ein Teil (Block 180) Dekomprimierungssoftware enthalten kann, und einen ROM 190 beinhaltet. Dreidimensionale Grafikdaten, die komprimiert wurden, können vorteilhafterweise unter Verwendung von Software, Hardware oder einer Kombination hieraus (z. B. in Echtzeit, nahe Echtzeit oder rechnerunabhängig) dekomprimiert werden.
Der Decoder 40 beinhaltet weiterhin eine Netzwerkschnittstelleneinheit 120, eine Einheit 130, die dreidimensionale Grafikdaten dekomprimiert, und dessen Ausgang mit einer dreidimensionalen Grafikdarstellungseinheit 140 verbunden ist. Das (die) dekomprimierte(n) dreidimensionale(n) Grafikbild(er) können dann zu einem Monitor 200 befördert werden oder zu einem anderen System, das die dekomprimierten Grafiken erfordert. Natürlich kann die Einheit 40 eine alleinstehende Einheit sein, in die die dreidimensionalen Grafikdaten, die gemäß der vorliegenden Erfindung vorkomprimiert sind, für die Dekomprimierung gekoppelt werden können. Die Einheit 40 kann beispielsweise einen Computer oder eine Workstation, eine Set-Top-Box, einen digitalen oder 3D-Fernseher, einen holographischen Kiosk, einen intelligenten Datenprojektor oder eine VR-Vorrichtung (z. B. ein Raum oder eine Workstation) sein.

Komprimierung

In Fig. 5 ist ein Flußdiagramm einer Ausführungsform eines Verfahrens für die Komprimierung von dreidimensionalen Grafikdaten mit sowohl regelmäßigen als auch unregelmäßigen Oberflächenabschnitten gezeigt. Dieses Verfahren kann in die dreidimensionale Grafikkomprimierungseinheit 60 implementiert werden. In dieser Ausführungsform werden Oberflächenabschnitte innerhalb der 3D-Grafikdaten untersucht (Schritt 872). Der Begriff "Oberflächenabschnitt", so wie er hier verwendet wird, bezeichnet eine Gruppe von Vertices bzw. Eckpunkten, die die einen oder mehreren gemeinsamen Attribute gemein haben. Beispielsweise können die Vertices an der Tür des Kühlschranks 200 (siehe Fig. 2) einen Oberflächenabschnitt aufweisen, da sie XYZ-Koordinaten innerhalb eines vorbestimmten Bereichs haben. Abschnitte des Datenstroms, die 3D-Objekte darstellen, können hier ebenso als Oberflächenabschnitte bezeichnet werden. Ein regulärer bzw. regelmäßiger Oberflächenabschnitt der Netzformatdaten kann durch eine regelmäßige Anordnung von Vertices charakterisiert werden, die die Polygone definieren, die in dem Netz verwendet werden. Während Dreiecke die geläufigsten Polygone sind, können ebenso andere Polygone verwendet werden, z. B. Vierecke, Quadrate, Rechtecke, Rhomben, Hexagone und Parallelogramme. Die Oberflächenabschnitte werden untersucht, um zu bestimmen, ob sie regelmäßig gekachelt oder unregelmäßig gekachelt sind (Schritt 874). Man beachte, daß, während regelmäßig gekachelte Abschnitte am einfachsten als Abschnitte mit Vertices, die gleichförmig oder vorhersagbar voneinander beabstandet sind, visualisiert werden, andere Typen von regelmäßig gekachelten Oberflächenabschnitten ebenso möglich sind. Beispielsweise kann in einer Ausführungsform eine regelmäßig gekachelte Oberfläche Vertices haben mit einer Farbinformation, die gleichförmig ist oder sich in einer vorhersagbaren Art und Weise ändert. Beispielsweise können die Vertices, die die Mähne des Löwen 202 aufweisen (siehe Fig. 2), während sie keine regelmäßig beabstandeten XYZ-Koordinaten haben, andere gleichförmige (oder sich vorhersagbar verändernde) Vertex-Parameter haben (z. B. Farbe, Normale, Materialinformation oder Texturinformation). Somit können Abschnitte der Mähne des Löwen 202 als regelmäßige Oberfläche beschrieben werden abhängig von dem bestimmten Kriterium, das verwendet wird, wenn der Oberflächenabschnitt in den Schritten 872-874 untersucht wird.
Wenn der bestimmte in Frage stehende Oberflächenabschnitt regelmäßig ist (Schritt 874), dann wird der Oberflächenabschnitt verschlüsselt unter Verwendung einer Codierungsmethode, die die regelmäßige Natur der Vertices ausnutzt (Schritt 876). Wie in der Figur gezeigt ist, ist eine mögliche Technik für das Ausnutzen der Regelmäßigkeit des Oberflächenabschnittes die Verwendung eines Vertex-Rasterformats für die Komprimierung. Dieser Typ der Komprimierung wird unten detaillierter beschrieben (siehe Vertex-Rasterformat unten).
Wenn auf der anderen Seite der bestimmte in Frage stehende Oberflächenabschnitt unregelmäßig ist (Schritt 874), dann wird der Oberflächenabschnitt codiert unter Verwendung eines Codierungsverfahrens, das für unregelmäßige Oberflächen optimiert ist (Schritt 878). Wie in der Figur gezeigt ist, ist es eine mögliche Technik für die Komprimierung unregelmäßiger Oberflächen, ein verallgemeinertes Dreiecksnetzformat zu verwenden. Dieser Typ der Komprimierung wird ebenso unten detaillierter beschrieben (siehe verallgemeinertes Dreiecksnetzformat unten).
Die vorliegende Erfindung erlaubt vorzugsweise, daß zwei oder mehr unterschiedliche Verfahren der Komprimierung benutzt werden. Jedes unterschiedliche Verfahren kann für einen bestimmten Typ von 3D-Grafikdaten optimiert sein und jedes unterschiedliche Verfahren kann unterschiedliche Komprimierungsverhältnisse erzeugen.
In einigen Ausführungsformen können Operationscodes in den komprimierten Datenstrom eingefügt werden, um anzuzeigen, welcher Typ der Komprimierung verwendet wird (Schritte 876A und 878A). Beispielsweise kann den Daten, die jeden komprimierten Oberflächenabschnitt aufweisen, ein Operationscode vorangehen, der anzeigt, daß ein Vertex-Rasterformat verwendet wird. Umgekehrt kann den Daten, die die komprimierten unregelmäßigen Oberflächenabschnitte aufweisen, ein unterschiedlicher Operationscode vorangehen, der anzeigt, daß ein verallgemeinertes Dreiecksnetzformat verwendet wird. Man bemerke, daß bei Verwendung dieses Verfahrens eine Anzahl von unterschiedlichen Komprimierungsverfahren, wobei jedes seinen eigenen Operationscode hat, in Kombination verwendet werden können. Jede Zahl von Formaten kann für die Operationscodes verwendet werden.
In einer Ausführungsform können die Operationscodes in die Daten des vorhergehenden komprimierten Oberflächenabschnittes eingebettet sein. Mit Vorteil kann dies ein "Vorausschau"- Merkmal während der Decodierung zur Verfügung stellen. Beispielsweise kann, während der Decodierung eines ersten Oberflächenabschnittes, der Decoder einen Operationscode decodieren, der anzeigt, daß der nächste Oberflächenabschnitt in dem Datenstrom unter Verwendung des anderen Verfahrens decodiert wird. Durch das Erfassen dieser Information, bevor der Decoder den folgenden Oberflächenabschnitt erreicht hat, kann der Decoder mit Vorbereitungen für die Decodierung der folgenden Oberflächenabschnitte unter Verwendung des anderen Dekomprimierungsschemas beginnen. Diese Vorbereitungen können parallel mit der Decodierung der letzten Abschnitte des ersten Oberflächenabschnittes durchgeführt werden. Somit können in einigen Ausführungsform eingebettete Operationscodes innerhalb der Daten des vorhergehenden Oberflächenabschnittes das effiziente Pipelining von Dekomprimierungsoperationen ermöglichen.
Dieses Verfahren der Untersuchung und Komprimierung jedes Oberflächenabschnittes kann fortgesetzt werden, bis alle Oberflächenabschnitte komprimiert wurden (Schritt 880). Nachdem jeder Oberflächenabschnitt komprimiert wurde, kann der resultierende Datenfile unter Verwendung von zusätzlichen Komprimierungsalgorithmen weiter komprimiert werden (Schritt 882). Beispielsweise können die resultierenden komprimierten Grafikdaten dann komprimiert werden unter Verwendung eines der folgenden Komprimierungsalgorithmen: arithmetische Codierung, Pulscodemodulation, Differentialpulscodemodulation, Lauflängencodierung, Shannon-Fano-Codierung, Huffman- Codierung oder Verzeichnisverfahren (z. B. LZ77, LZSS, LZ78, LZW usw.). Es sei bemerkt, daß verschiedene Variationen und Kombinationen der aufgelisteten Algorithmen ebenso verwendet werden können. Diese zusätzliche Komprimierung ist jedoch optional. In manchen Ausführungsformen wird die zusätzliche Zeit und Verarbeitungsressourcen, die für die Codierung und Decodierung der Daten erforderlich sind, den möglicherweise begrenzten Gewinn, der durch Anwendung von zusätzlichen Komprimierungsalgorithmen geschaffen wird, nicht rechtfertigen. Zusätzlich zu (oder neben der) Komprimierung, die in Schritt S88 durchgeführt wird, kann eine Fehlerüberprüfungs- und Korrekturinformation (ECC) optional berechnet werden und in die komprimierten 3D-Grafikdaten eingefügt werden.
Schließlich werden die komprimierten 3D-Grafikdaten zu ihrem Ziel übertragen oder auf einem computerlesbaren Medium gespeichert (Schritt 884). Es sei bemerkt, daß das oben ausgeführte Verfahren für irgendeine Anzahl von unterschiedlichen Verwendungen optimiert sein kann. Beispielsweise ist in einer Ausführungsform das Verfahren für die Komprimierung von 3D-Grafikdaten in einem nicht-Echtzeit-Format für die Verteilung über ein Computernetzwerk (z. B. dem Internet) oder über CD-ROM (Compact-Disc-Nur-Lese-Speicher) optimiert. In anderen Ausführungsformen kann das Verfahren für die Durchführung von Echtzeitkomprimierung optimiert sein. In solch einer Ausführung können die Verfahren, die verwendet werden, um regelmäßige Oberflächenabschnitte zu erfassen und die Komprimierungsverfahren, die für die Komprimierung von sowohl regelmäßig gekachelten als auch unregelmäßig gekachelten Oberflächen verwendet werden, unter Beachtung der Antwortzeit ausgewählt werden.
Es sei bemerkt, daß in anderen Ausführungsformen die oben beschriebenen Schritte kombiniert oder in einer unterschiedlichen Anordnung oder parallel durchgeführt werden können. Beispielsweise kann Schritt 876A vor Schritt 876 durchgeführt werden.
In noch einer anderen Ausführungsform können die Oberlfächenabschnitte parallel komprimiert werden unter Verwendung von beiden Verfahren (Schritte 876 und 878). Der komprimierte Oberflächenabschnitt; der die geringste Menge von Platz benötigt, wird dann ausgewählt. Es sei bemerkt, daß all die hier beschriebenen Verfahren als Software (d. h. mit einer Mehrzahl von Fehlern, die jeden Schritt durchführen), als Hardware oder als eine Kombination hieraus implementiert werden können. Die Software kann Teil eines Anwendungsprogramms, eines Betriebssystems, eines Gerätetreibers oder eines Mikrocodes sein, der in dem Nur-Lese-Speicher (ROM) gespeichert ist.
In Fig. 6 ist eine andere Ausführungsform eines Verfahrens für das Komprimieren von 3D- Grafikdaten gezeigt, die sowohl regelmäßig gekachelte als auch unregelmäßig gekachelte Oberflächenabschnitte aufweisen. In dieser Ausführungsform wird die zu komprimierende 3D-Grafikdaten nach regelmäßigen Oberflächenabschnitten untersucht (Schritt 890). Wenn es Oberflächenabschnitte gibt, die regelmäßig gekachelt sind (Schritt 892), dann werden sie unter Verwendung eines Formats codiert, das die Regelmäßigkeit ausnutzt, z. B. unter Verwendung eines Vertex-Rasterformats für die Komprimierung (Schritt 894). Sobald die regelmäßig gekachelten Oberflächen codiert sind, können dann die verbleibenden 3D-Daten (die unregelmäßig gekachelte Oberflächenabschnitte aufweisen) unter Verwendung eines geometrischen Komprimierungsverfahrens komprimiert werden, das nicht auf der Kachelregelmäßigkeit beruht und das für unregelmäßig gekachelte Oberflächenabschnitte optimiert ist, z. B. unter Verwendung eines verallgemeinerten Dreiecksnetzformats (Schritt 896). Schließlich werden die komprimierten 3D-Grafikdaten auf einem computerlesbaren Medium gespeichert oder über ein Computernetzwerk übertragen (Schritt 898).
In Fig. 7 ist noch eine andere Ausführungsform eines Verfahrens gezeigt, um 3D- Grafikdaten zu komprimieren, die sowohl regelmäßig gekachelte als auch unregelmäßig gekachelte Oberflächenabschnitte aufweisen. Als erstes werden die 3D-Geometriedaten empfangen (Schritt 900). Als nächstes wird jeder Oberflächenabschnitt untersucht, um zu bestimmen, ob er regelmäßig ist oder nicht (Schritt 902). Wenn der Oberflächenabschnitt regelmäßig ist, wird ein erstes Verfahren für die Komprimierung, das die Regelmäßigkeit ausnutzt, verwendet, um die Zusammenhangs- bzw. Konnektivitätsinformation der Oberfläche zu codieren (Schritt 904). In einer Ausführungsform kann dieses erste Verfahren ein Vertex-Rasterformat benutzen. Es sei bemerkt, daß der Begriff "Konnektivitätsinformation", so wie er hier verwendet wird, sich auf eine Information bezieht, die die relative Ordnung beschreibt, in der die Vertices innerhalb des Oberflächenabschnittes organisiert sind. Alternativ wird, wenn der Oberflächenabschnitt unregelmäßig ist, dann ein zweites Verfahren der Komprimierung, das für unregelmäßige Oberflächenabschnitte optimiert ist, verwendet, um die Konnektivitätsinformation der Oberfläche zu codieren (Schritt 906). In einer Ausführungsform kann dieses zweite Verfahren ein verallgemeinertes Dreiecksnetz verwenden.
Sobald die Konnektivitätsinformation codiert ist, wird die entsprechende pro-Vertex- Information unter Verwendung eines dritten Komprimierungsverfahrens codiert (Schrift 908). Wie bereits vorher bemerkt wurde, kann die pro-Vertex-Information XYZ-Koordinaten, Normalen, Farbinformation, Materialinformation, Beleuchtungsinformation, Durchsichtigkeitsinformation, Oberflächeninformation und andere Charakteristika enthalten. Dieser Prozeß kann für jeden Oberflächenabschnitt wiederholt werden (Schritt 910). Sobald alle 3D-Grafikinformation komprimiert wurde, kann sie auf computerlesbares Medium abgelegt werden oder sie kann über ein Computemetzwerk übertragen werden (Schritt 912).

Verallgemeinertes Dreiecksnetz

Wie vorher bemerkt wurde, ist ein mögliches Verfahren für die Komprimierung von Oberflächenabschnitten (einschließlich unregelmäßigen Oberflächenabschnitten), die Dreiecksdaten des Oberflächenabschnitts in eine effiziente lineare Streifenform, nämlich ein verallgemeinertes Dreiecksnetz, umzuwandeln. Mehr Details betreffend die Komprimierung unter Verwendung eines verallgemeinerten Dreiecksnetzes werden nun erörtert.
In Fig. 8 ist eine Ausführungsform einer verallgemeinerten Dreiecksnetzdatenstruktur einer beispielhaften Oberflächengeometrieregion gezeigt. Einzelnes Speichern oder Übertragen der Dreiecke führt zu einer nicht notwendigen Wiederholung von Vertices. Beispielsweise können die Vertices 1, 6, 7 übertragen werden, um das erste Dreieck zu bilden, dann können die Vertices 1, 7, 2 für das zweite Dreieck übertragen werden. In diesem Beispiel werden die Vertices 1 und 7 unnötig wiederholt. Um die wiederholten Vertices zu reduzieren, bringen manche Komprimierer die übertragenen Vertices in einen Dreiecksstreifen. Beispielsweise können die Dreiecke in der folgenden Ordnung übertragen werden: 6, 1, 7, 2, 3 usw. Jeder Vertex nach den ersten drei ersetzt einfach den ältesten Vertex. Beispielsweise ist das erste Dreieck, 6, 1, 7. Das zweite Dreieck verwirft den ältesten Vertex (d. h. den Vertex 6) und addiert den nächsten Vertex (d. h. Vertex), um 1, 7, 2 zu bilden. Dieser Prozeß fährt bis zum Ende des Dreiecksstreifens fort.
Während die Verwendung von linearen Streifen eine große Verbesserung gegenüber der expliziten Spezifizierung von jedem Vertex für jedes Dreieck ist, gibt es immer noch eine Wiederholung von einigen Vertices. Beispielsweise wird der Vertex 7 zweimal wiederholt (d. h. einmal, wenn das erste Dreieck gebildet wird und dann einmal, wenn das Dreieck 8, 15, 7 gebildet wird, wenn sich der Dreiecksstreifen seinen Weg vor und zurück durch das Dreiecksnetz findet.
Ein verallgemeinerter Dreiecksstreifen speichert die drei Vertices in einen Pufferspeicher und erlaubt es, daß neue Vertices bestehende Vertices selektiv ersetzen. Mit anderen Worten wird der Dreiecksstreifen "generalisiert" bzw. "verallgemeinert", da die neuen Vertices die anderen Vertices ersetzen können (d. h. nicht einfach den ältesten wie in dem vorigen Beispiel).
In Fig. 8 kann ein verallgemeinerter Dreiecksstreifen wie folgt definiert werden, wobei R Restart bzw. Neustart bezeichnet, O das Ersetzen des ältesten bezeichnet, M das Ersetzen des mittleren bezeichnet und ein führender Buchstabe p das Verschieben in den Netzpufferspeicher bezeichnet:
R6, O1, O7, O2, O3, M4, M8, O5, O9, O10, O11, 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
In dieser Notation ist die Zahl, die einem Großbuchstaben folgt, eine Vertex-Zahl und eine negative Zahl ist die Netzpufferreferenz, wobei -1 den zuletzt verschobenen Vertex bezeichnet.
Ein verallgemeinertes Dreiecksgitter und ein Netzpufferspeicher können verwendet werden, um die Wiederholungen von internen Vertices zu reduzieren. Vertices, die möglicherweise erneut verwendet werden, können explizit in den Netzpufferspeicher verschoben (d. h. abgelegt) werden für die Speicherung, bis sie benötigt werden. Zu dieser Zeit werden sie hervorgeholt (d. h. gelesen), um das nächste Dreieck zu bilden.
Unter Verwendung derselben Nomenklatur wie oben kann ein verallgemeinertes Dreiecksnetz 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 sei bemerkt, daß eine Vertex-Referenz (z. B. eine 4-Bit-Zahl, die einen Ort innerhalb des Netzpufferspeichers definiert) mit Vorteil beachtlich kompakter (z. B. durch weniger Bits dargestellt) als eine volle Vertex-Spezifizierung sein kann. Beispielsweise kann ein Vertex 24 Bits der Farbinformation, XYZ-Positionsinformation, Texturabbildungskoordinaten und andere Information beinhalten.
Die geometrische Komprimierung kann explizit alte Vertices (z. B. Vertices mit einem führenden Buchstaben "p" oben) in eine Warteschlange schieben, die mit dem Netzpufferspeicher 80 verknüpft ist (siehe Fig. 4). Auf diese alten Vertices wird später explizit Bezug genommen, wenn das alte Vertex erneut gewünscht wird. Dieser Ansatz stellt eine Feinkontrolle zur Verfügung, die unregelmäßige Netze von nahezu jeder Form unterstützt. In der Praxis hat der Pufferspeicher 80 eine endliche Länge und in einer Ausführungsform wird eine feste Maximalwarteschlangenlänge von 16 mit einem 4-Bit-Index verwendet. Der Begriff "Netzpufferspeicher", so wie er hier verwendet wird, soll sich auf diese Warteschlange beziehen und der Ausdruck "verallgemeinertes Dreiecksnetz" soll sich auf eine Kombination aus verallgemeinerten Dreiecksstreifen und Netzpufferspeicherreferenzen beziehen.
Die feste Größe des Netzpufferspeichers 80 kann in einigen Ausführungsformen erfordern, daß alle Tessellatoren/Re-Striper für die komprimierte Geometrie jeden Lauf, der länger als 16 eindeutige Referenzen ist, abbrechen. Da jedoch geometrische Komprimierung typischerweise nicht direkt auf dem Benutzerniveau programmiert wird, sondern eher durch erfahrene Tessellatoren/Re- Formatierer, ist diese Beschränkung nicht lästig. 16 alte Vertices können tatsächlich erlauben, daß die erneute Spezifizierung von bis zu etwa 94% der redundanten Geometrie vermieden wird.
In einer Ausführungsform kann die geometrische Komprimierungssprache vier Vertex- Ersetzungscodes von verallgemeinerten Dreiecksstreifen unterstützen, nämlich: ersetze ältesten, ersetze mittleren, starte erneut im Uhrzeigersinn und starte erneut im Gegenuhrzeigersinn. Darüber hinaus kann in manchen Ausführungsformen die Sprache ein zusätzliches Bit in der Vertex- Kopfzeile zufügen, um anzuzeigen, ob oder ob nicht dieser Vertex in den Netzpufferspeicher verschoben werden sollte. Dies ist jedoch optional. In einer Ausführungsform hat das Netzpufferspeicherreferenzkommando ein 4-Bit-Feld, um anzuzeigen, auf welches alte Vertex erneut Bezug genommen werden sollte, zusammen mit dem 2-Bit-Vertex-Ersetzungscode. Es sei jedoch bemerkt, daß nur ein und ein halbes Bit der 2-Bit-Vertex-Ersetzungscodes verwendet werden können. Andere Codeformate und Längen sind ebenso möglich und wurden in Betracht gezogen. Netzpufferspeicherreferenzkommandos müssen kein Netzpufferverschiebungsbit enthalten, da alte Vertices üblicherweise nur einmal wiederverwendet werden.
In der Praxis bestehen geometrische Daten selten ausschließlich aus Positionsdaten. Im allgemeinen werden eine Normalen- und/oder Farbe- und/oder Texturabbildungskoordinaten ebenso wie Vertex spezifiziert. Folglich enthalten in einer Ausführungsform Einträge in dem Netzpufferspeicher 80 Speicher für zusätzliche Information wie Vertex einschließlich beispielsweise Normalen- und Farb- und/oder Texturabbildungskoordinaten, Materialeigenschaften. Zusätzlich können einige Ausführungsformen Steueroberflächen für NURBS (nicht gleichförmige rationale B-Splines), parametrische Oberflächen, NURBS-Oberflächen, Unterteilungsoberflächen, Punkte und Voxel (Volumenelemente) anstelle von oder zusätzlich zu traditionellen Vertex-Informationen benutzen.
Für die maximale Speicherplatzeffizienz kann, wenn ein Vertex in dem Datenstrom spezifiziert wird, eine Normalen- und/oder Farbinformation die pro-Vertex-Information direkt mit der Positionsinformation gebündelt werden. Solch eine Bündelung kann durch eine Anzahl von Zustandsbits, z. B. einer Bündelnormalen mit Vertices-Bit (BMV) und Bündelfarben mit Vertices-Bit (BCV) gesteuert werden. Fig. 10E stellt eine Kommandostruktur einschließlich dieser Bits unter anderen dar. Wenn ein Vertex in den Netzpufferspeicher verschoben wird, steuern diese Bits, ob eine 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, Punkte, Steueroberflächen, NURBS-Oberflächen, Voxels und andere Typen von Grafikdaten ebenso komprimiert werden können. Linien sind beispielsweise eine Untergruppe von Dreiecken, in denen die Ersetzungsbits MOVE and DRAW sind. Ein Ausgangsvertex ist dann ein Vertex, der einen Endpunkt einer Linie darstellt, dessen anderer Vertex der zuletzt vorher ausgelassene Vertex ist. Für Punkte sind die Ersetzungsbits DRAW und ein Ausgangsvertex ist der Vertex.
Wenn die CPU 50 ein Netzpufferspeicherreferenzkommando ausführt, würde dieser Prozeß umgekehrt. Das heißt, die zwei Bits spezifizieren, ob eine Normale und/oder Farbe von dem Netzpufferspeicher 80 vererbt oder gelesen werden sollte oder von der gegenwärtigen Normalen oder der gegenwärtigen Farbe erhalten werden sollte. Software kann explizite Kommandos für das Einstellen dieser zwei gegenwärtigen Werte beinhalten. Eine Ausnahme für diese Regel existiert jedoch, wenn ein explizites "stelle gegenwärtige Normale ein"-Kommando von einer Netzpufferspeicherreferenz mit aktivem BMV-Zustandsbit gefolgt wird. In dieser Situation überschreibt ersterer die Netzpufferspeichernormale, um die kompakte Darstellung von harten Kanten in der Oberflächengeometrie zu erlauben. Analoge Semantiken werden ebenso für Farben definiert, was die kompakte Darstellung von harten Kanten in Oberflächenfarben erlaubt.
Die Komprimierung von XY2-Bildpositionen wird nun beschrieben. Die Verwendung des 8- Bit-Exponenten, der mit den 32-Bit-IEEE-Gleitkommazahlen verknüpft ist, erlaubt es, daß die Position in der Größe von subatomaren Teilchen bis Milliarden von Lichtjahren reichen. Für jedes gegebene tessellierte bzw. in Mosaik aufgeteilte Objekt wird der Exponent tatsächlich nur einmal spezifiziert durch eine gegenwärtige Modellmatrix und die Objektgeometrie wird effektiv innerhalb eines gegebenen Modellraums unter Verwendung nur einer 24-Bit-Testmantisse beschrieben. In vielen Fällen werden viel weniger Bits für die visuelle Akzeptanz benötigt. Die geometrische Komprimierungssprache des Anmelders unterstützt daher variable Quantisierung von Positionsdaten bis hinunter zu einem Bit.
In dem anderen Extrem haben empirische visuelle Tests, wie auch die Betrachtung von Halbleiterhardwareimplementierungen gezeigt, daß in vielen Ausführungsformen nicht mehr als 16 Bits Genauigkeit die Komponente der Position für nahezu alle Fälle notwendig ist. Es sei jedoch angenommen, daß die Position und die Skalierung des lokalen Modellraums 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 positionellen Genauigkeit von viel größer als 16 Bits.
Die meiste Geometrie ist lokal. Somit wird innerhalb eines 16-Bit- (oder geringer) Modellraums für jedes Objekt der Unterschied (Δ) zwischen benachbarten Vertices in dem verallgemeinerten Netzpufferspeicherstrom wahrscheinlich weniger als 16 Bits Signifikanz haben. Wenn gewünscht, kann man ein Histogramm konstruieren, das die Bitlänge des Deltas benachbarter Position in einem Stapel aus Geometrien darstellt und basierend auf diesem Histogramm einen Code variabler Länge zuweisen, um die Vertices kompakt darzustellen. Wie beschrieben werden wird, kann angepaßte Huffman-Codierung verwendet werden, um die positionalen Deltas in der geometrischen Komprimierung zu codieren.
Die Komprimierung von Rot-Grün-Blau-Alpha- ("RGBA"-) Farben wird nun beschrieben. Farbdaten werden ähnlich wie Positionen behandelt, jedoch mit einer kleineren maximalen Genauigkeit. Somit werden in manchen Ausführungsformen RGBA-Farbdaten zunächst in 16-Bit-Teilwerte ohne Vorzeichen quantisiert. Die Werte können beispielsweise eine absolute lineare Reflektivität darstellen (in denen 1,0 100% Reflektivität darstellt). Andere Formate können ebenso verwendet werden (z. B. ein 1,15-Format oder ein 0,15-Format). Ein zusätzlicher Parameter erlaubt es, daß Farbdaten effektiv auf irgendeine Größe von weniger als 15 Bits quantisiert werden. Als ein Beispiel können Farben allesamt innerhalb eines 5-5-5-RGB-Farbraums sein, wie in Fig. 10C gezeigt ist. Das optionale Alpha-Feld wird durch ein Zustandsbit "color a present" ("CAP"), das in Fig. 10e gezeigt ist, gesteuert. Auf dem endgültig dargestellten Bild werden einzelne Pixelfarben immer noch zwischen den quantisierten Vertex-Farben interpoliert und sind ebenso der Beleuchtung ausgesetzt.
Als eine Konstruktionsentscheidung wurde entschieden, dieselbe Delta-Codierung für Farbkomponenten zu verwenden, wie sie für die Positionen verwendet wird. Der Bereich der Farbdatenkomprimierung ist dort, wo geometrische Komprimierung und traditionelle Bildkomprimierung auf die ähnlichsten Probleme trifft. Viele fortschrittliche Bildkomprimierungstechniken wurden jedoch vermieden für die geometrische Farbkomprimierung aufgrund ihres Unterschiedes im Fokus.
Beispielsweise beruht der JPEG-Bildkomprimierungsstandard auf Annahmen über die Ansicht der dekomprimierten Daten, die nicht für die geometrische Komprimierung getroffen werden können. Beispielsweise ist es bei der Bildkomprimierung a priori bekannt, daß die Pixel in einer perfekt rechtwinkligen Anordnung erscheinen und daß, wenn sie angesehen werden, jedes Pixel einen engen Bereich von visuellen Winkeln abschneidet. Im Gegensatz dazu kann in der geometrischen Komprimierung die Beziehung zwischen dem Betrachter und der gerasterten Geometrie unvorhersagbar sein.
Bei der Bildkomprimierung ist es bekannt, daß die Ortsfrequenz der anzeigten Pixel beim Auge des Betrachters wahrscheinlich höher ist als die Vorabsehschärfe des menschlichen visuellen Systems. Aus diesem Grund werden Farben gewöhnlich in den YUV-Raum umgewandelt, so daß die UV-Farbkomponenten mit einer niedrigeren Ortsfrequenz als die Y- (Intensitäts-) Komponente dargestellt werden können.
Üblicherweise werden digitale Bits, die unterabgefragte bzw. subgesamplete UV- Komponenten darstellen, auf zwei oder mehrere Pixel aufgeteilt. Die geometrische Komprimierung kann jedoch diesen Vorteil nicht ausnutzen, da es keine feste Anzeigeskala der Geometrie relativ zu dem Auge des Betrachters gibt. Weiterhin kann es, vorausgesetzt, daß die komprimierten Dreiecks- Vertices mit vier bis acht oder mehreren anderen Vertices in dem verallgemeinerten Dreiecksnetz verbunden sind, keinen einfachen konsistenten Weg des gemeinsamen Nutzens "der Hälfte" der Farbinformation entlang der Vertices geben.
Ähnliche Argumente gelten für die anspruchsvolleren Transformationen, die in der traditionellen Bildkomprimierung verwendet werden, wie z. B. die diskrete Cosinus-Transformation. Diese Transformationen nehmen eine regelmäßige (rechtwinklige) Abfrage von Pixelwerten an und können eine große Menge von Zufallszugriffen während der Dekomprimierung verwenden.
Es ist im Stand der Technik bekannt, Pseudofarbnachschlagtabellen zu verwenden, solche Tabellen erfordern jedoch typischerweise eine feste Maximalgröße, wodurch eine relativ teure Ressource für die Echtzeitverarbeitung dargestellt wird. Während PseudofarbVertices zu leicht höheren Kompressionsverhältnissen für einige Szenen führen könnten, wird das RGB-Modell stärker verallgemeinert und ist beachtlich kostengünstiger zu implementieren.
In dem RGB-Modell können die RGB-Werte als lineare Reflektivitätswerte dargestellt werden. Theoretisch könnten, wenn alle Beleuchtungseffekte a priori bekannt wären, ein oder zwei Darstellungsbits fallengelassen werden, wenn die RGB-Komponenten in einem nicht linearen oder wahrnehmbar linearen Raum (manchmal als gamma-korrigierter Raum bezeichnet) dargestellt wurden. In der Praxis tendieren die Beleuchtungseffekte dazu, nicht vorhersagbar zu sein, und die Umwandlung während der Übertragung von nicht linearem Licht in lineares Licht könnte beachtliche Hardwareressourcen erfordern.
Die Komprimierung von Oberflächennormalen wird nun beschrieben. Traditionell werden 96- Bit-Normalen (drei 32-Bit-IEEE-Gleitkommazahlen) in den Berechnungen verwendet, um 8-Bit- Farbintensitäten zu bestimmen. Theoretisch könnten 96-Bit-Informationen verwendet werden, um 2&sup9;&sup6; unterschiedliche Normalen darzustellen, die gleichmäßig über die Oberfläche einer Einheitskugel verteilt sind. Die resultierende extrem hohe Genauigkeit entspricht einer Normale, die jeweils in beliebiger Richtung alle 2&supmin;&sup4;&sup6; Radian zeigt.
Für IEEE-gleitkommanormalisierte Normalen werden jedoch die Exponentenbits effektiv nicht benutzt. Unter der Nebenbedingung Nx² + Ny² + Nz² = 1 liegt zumindest eines der Nx, Ny oder NZ in dem Bereich zwischen 0,5 bis 1,0. 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 die Beleuchtung in Weltkoordinaten durchgeführt wird, ist die Ansichtstransformation nicht in der Verarbeitung der Normalen involviert. Wenn die Normalen vornormalisiert worden sind, dann wird, um redundante Renormalisierung der Normalen zu verhindern, die zusammengesetzte Modelltransformationsmatrix T typischerweise vornormalisiert, um jegliche Skalierungsveränderungen herauszuteilen. Somit ist:
Während der Normalentransformation schneidet die Gleitkommaarithmetikhardware effektiv alle zusätzlichen Argumente auf die Genauigkeit der größten Komponente ab. Das Ergebnis ist, daß für eine normalisierte Normale, die einer Transformation durch eine skalierungsbewahrende Modellorientierungsmatrix unterliegt, die numerische Genauigkeit des transformierten Normalenwerts auf eine Festkommagenauigkeit von nicht mehr als 24 Bit in allen außer ein paar wenigen speziellen Fällen reduziert wird.
Zum Vergleich, selbst 24-Bit-Normalenkomponenten würden immer noch eine höhere Winkelgenauigkeit bereitstellen als das reparierte Hubble-Weltraumteleskop. In der Praxis verwenden manche Systeme nur 16-Bit-Normalenkomponenten. In empirischen Tests mit 16-Bit- Normalenkomponenten bestimmte der Anmelder, daß Ergebnisse von einer Winkeldichte von 0,01 Radian zwischen den Normalen von feineren Darstellungen visuell nicht unterscheidbar waren. Dies waren etwa 100.000 Normalen, die über eine Einheitskugel verteilt sind. Im geradlinigen Raum können diese Normalen eine höhere Darstellungsgenauigkeit für manche Anwendungen erfordern. Im Ergebnis können 16-Bit-Komponenten einschließlich eines Vorzeichens und eines Guard- bzw. Überwachungsbits in einer Ausführungsform verwendet werden. Dies resultiert in einer Länge von 48 Bits, um eine Normale darzustellen, da aber nur 100.000 spezifische Normalen von Interesse sind, könnte theoretisch ein einzelner 17-Bit-Index jede dieser Normalen bezeichnen. Andere Längen sind ebenso möglich und wurden in Betracht gezogen in Abhängigkeit von der exakten Implementierung.
Die Verwendung von Normalen als Indizes und die bereitgestellten resultierenden Vorteile werden nun beschrieben. Ein Verfahren zum Umwandeln eines Indexes einer Normalen auf der Einheitssphäre zurück in einen Nx-, Ny-, Nz- Wert benutzt eine Nachschlagtabelle, wobei die Tabelle vielleicht in den Speicher 70 geladen ist. Obgleich die Tabellengröße möglicherweise groß ist, kann die erforderliche Größe wesentlich reduziert werden durch Ausnutzen des Vorteils der 48-fachen Symmetrie, die es in der Einheitskugel gibt.
Genauer gesagt ist, wie in Fig. 9 gezeigt ist, die Einheitskugel symmetrisch bezüglich der Vorzeichenbits in den acht Quadranten. Durch das Gestatten, daß drei der Normalendarstellungsbits die drei Vorzeichenbits der XYZ-Komponenten einer Normalen sind, kann es dann nur notwendig sein, ein Achtel der Einheitskugel darzustellen.
Wie in Fig. 9 gezeigt ist, kann jeder Oktant der Einheitskugel in sechs identische Komponenten durch Falten um die Ebenen x = y, x = z und y = z aufgeteilt werden. Die sechs möglichen Sextanten werden mit anderen drei Bits codiert, die nur 1/48 der Kugel übrig läßt, die darzustellen verbleiben.
Die Ausnutzung der oben bemerkten Symmetrie reduziert die Größe der Nachschlagtabelle um einen Faktor 8 · 6 = 48. Anstelle des Speicherns von 100.000 Einträgen kann die Nachschlagtabelle stattdessen nur etwa 2.000 Einträge speichern, was eine Größe ist, die klein genug ist, um eine Nachschlagtabelle auf dem ROM-Chip zu sein, die möglicherweise innerhalb des ROM 59 gespeichert (siehe Fig. 4). Das Indizieren in der Nachschlagtabelle verwendet elf Adressenbits, die, wenn sie zu den vorher beschriebenen zwei 3-Bit-Feldern zugefügt werden, zu einem 17-Bit-Feld führen, das alle drei Normalenkomponenten beschreibt.
Das Darstellen eines endlichen Satzes von Einheitsnormalen ist äquivalent zu der Positionierung von Punkten auf der Oberfläche der Einheitskugel. Obgleich keine perfekt gleiche Winkeldichtenverteilung für eine große Anzahl von Punkten existiert, gibt es viele nahezu optimale Verteilungen. Theoretisch könnte eine Verteilung mit dem oben beschriebenen Typ der 48-fachen Symmetrie für die Dekomprimierungsnachschlagtabelle, die mit der dreidimensionalen geometrischen Dekomprimierungseinheit 130 (siehe Fig. 4) verknüpft ist, verwendet werden.
Verschiedene zusätzliche Randbedingungen beauftragen jedoch eine unterschiedliche Wahl der Codierung. Als erstes ist eine skalierbare Dichteverteilung wünschenswert, z. B. eine Verteilung, in der das Einstellen in der Nachschlagtabelle von Adreßbits unterer Ordnung auf "Null" immer noch zu einer ziemlich gleichmäßigen Normalendichte auf der Einheitskugel führt. Anderenfalls würde eine unterschiedliche Nachschlagtabelle für jede Codierungsdichte verwendet. Als zweites ist eine delta-codierbare Verteilung wünschenswert, in der benachbarte Vertices in der Geometrie statistisch Normalen haben, die nahe der Oberfläche der Einheitskugel sind. Nahe Orte auf dem zweidimensionalen Raum der Einheitskugeloberfläche werden am kürzesten 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 Normalencodierungsprozeß verknüpft sind, nicht kritisch wichtig sind, Verteilungen mit geringeren Codierungskosten immer noch bevorzugt.
Aus diesen Gründen kann eine Verteilung mit einem regelmäßigen Gitter in dem Winkelraum innerhalb eines Sextanten der Einheitskugel verwendet werden. Als solche werden alle Normalen innerhalb eines Sextanten mit Vorteil mit zwei orthogonalen 6-Bit-Winkeladressen dargestellt statt einem monolithischen 11-Bit-Index. Diese Konfiguration korrigiert die vorherige Bitsumme auf 18 Bits. Wie es der Fall war für Positionen und Farben, können, wenn eine größere Quantisierung der Normalen akzeptierbar ist, diese 6-Bit-Indices auf weniger Bits reduziert werden und absolute Normalen können somit unter Verwendung einer Zahl von 18 bis hinunter zu 6 Bits dargestellt werden. Dieser Raum ist jedoch, wie oben beschrieben wurde, delta-codiert, um die Anzahl von Bits, die für die Darstellung der Normalen in hoher Qualität verwendet werden, weiter zu reduzieren.
Die Normalencodierungsparametrisierung wird nun beschrieben. Punkte auf einer Einheitsradiuskugel werden parametrisiert unter Verwendung von Kugelkoordinaten durch Winkel Q(θ) und f(φ), wobei Q der Winkel um die Y-Achse und f der Längswinkel von der y = 0-Ebene ist. Gleichung (1) bestimmt die Abbildung zwischen den rechtwinkligen Koordinaten und den Kugelkoordinaten wie folgt:
x = cosθ·cosφ y = sinφ z = sinθ·cosφ (1)
Punkte auf der Kugel werden als erstes um den Oktanten gefaltet und dann durch Sortierungsordnung von xyz in einem der sechs Sextanten. Jegliche Tabellencodierung findet in dem positiven Oktanten in dem Bereich statt, der begrenzt wird durch die Halbebenen:
x/ z z/ y y/ 0
Wie in Fig. 9 gezeigt ist, läuft der beschriebene dreiecksförmige Pfad von 0 bis, π/4 Radian in θ und von 0 bis zu einem Maximum 0,615479707 Radian in φ.
Diese Kugelcodierung wird auf Punkte angewendet. Als erstes wird der Punkt in den positiven Oktanten gefaltet. Dann wird er in den Sextanten gefaltet, wo x > y > 2. Dann werden θ und φ erzeugt.
Quantisierte Winkel werden durch zwei n-Bit-Ganzzahlen n und n dargestellt, wobei n in dem Bereich zwischen 0 und 6 liegt. Für ein gegebenes n ist die Verbindung zwischen den Indizes θ und φ:
Die Gleichungen (2) zeigen, wie die Werte von n und n in Kugelkoordinaten θ und φ umgewandelt werden können, die wiederum in geradlinigen Normalkoordinatenkomponenten über die Gleichung (1) umgewandelt werden können.
Um den Prozeß umzukehren, z. B. um eine gegebene Normale N in n und n zu codieren, kann man nicht einfach Gleichung (2) invertieren. Stattdessen wird N zunächst in dem kanonischen Oktanten und Sextanten gefaltet, was zu N' führt. Dann werden Skalarprodukte für alle quantisierten Normalen in dem Sextanten und N' berechnet. 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 Auffinden der korrekten Werte von n und n existieren, beispielsweise die Indizierung durch die Tabelle, um 4' einzustellen und dann das Springen in θ.
Hierbei kann das komplette Bitformat der absoluten Normalen gegeben sein. Die obersten drei Bits spezifizieren den Sextanten, die nächsten drei Bits spezifizieren den Oktanten und die letzten zwei N-Bit-Felder spezifizieren n und n. Das 3-Bit-Sextantenfeld nimmt einen von sechs Werten an, die Binärcodes hierfür sind in Fig. 9 gezeigt.
Einige weitere Details sind angezeigt. 14 spezielle absolute Normale können mit den zwei nicht verwendeten Einstellungen innerhalb der drei Sextantenbits codiert werden. Dies wird angezeigt durch die Spezifizierung der Winkelfelder, so daß sie eine Länge von 0 (nicht vorhanden) haben und die ersten zwei Bits des Sextantenfeldes beide einen Wert von 1 haben. Fig. 10R listet eine Ausführungsform der Codierung für die 14 speziellen Normalen auf.
Diese Darstellung der Normalen ist der Deltacodierung zugänglich, zumindest innerhalb eines Sextanten, obgleich mit einiger zusätzlicher Arbeit kann dies auf Sextanten erweitert werden, die eine gemeinsame Kante haben. Der Deltacode zwischen zwei Normalen ist einfach die Differenz in und , nämlich Δ und Δ .
Es wird nun die Verwendung der Kompressionsanzeige durch den Anmelder beschrieben. Viele Techniken sind bekannt für die minimale Darstellung von Bitfeldern variabler Länge. Eine besonders nützliche Technik ist eine Variation eines konventionellen Huffman-Algorithmus.
Der Huffman-Kompressionsalgorithmus nimmt einen Satz von Symbolen auf, die darzustellen sind, zusammen mit der Frequenz der Ereignisstatistik (z. B. Histogramme) dieser Symbole. Aus diesem werden eindeutig identifizierbare Bitmuster variabler Länge erzeugt, die es erlauben, daß diese Symbole mit einer nahezu minimalen Gesamtzahl von Bits dargestellt werden, unter der Annahme, daß Symbole mit der spezifizierten Frequenz 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 Deltawert spezifischer Länge. Der finale Binärstrom besteht somit aus Anzeigersymbolen (selbstbeschreibender Länge) mit variabler Länge, wobei jedes von einem Datenfeld gefolgt wird, dessen Länge mit dem eindeutigen Anzeigersymbol verknüpft ist.
Abhängig von der Implementierung kann das binäre Format für die geometrische Komprimierung diese Technik verwenden, um Positionen, Normalen und Farbdatenfelder darzustellen. Für die geometrische Komprimierung dieses Dreiecks geht den < tag, data> -Feldern bzw. Anzeiger-, Datenfeldern unmittelbar ein konventionelleres Computerbefehlssatz-Operationscodefeld voraus. Diese Felder zusammen mit möglichen zusätzlichen Operandenbits werden als geometrische Befehle bezeichnet (siehe Fig. 10A-10K).
Traditionell wird jedem zu komprimierenden Wert sein eigener verknüpfter Kennsatz zugewiesen, z. B. eine xyzΔ-Position wird durch drei Anzeigerwertpaare dargestellt. Da aber die Δxyz- Werte nicht unkorreliert sind, kann eine dichtere, einfachere Darstellung erreicht werden. Im allgemeinen zeigen die xyzΔs statistisch gleichmäßig in alle Raumrichtungen. Wenn somit n die Anzahl von Bits ist, die benötigt wird, um das größte der Δs darzustellen, dann verwenden statistisch die anderen zwei Δ-Werte im Mittel N-1,4 Bits für ihre Darstellung. Die bevorzugte Ausführungsform kann daher einen einzelnen Feldlängenanzeiger verwenden, um die Bitlänge von Δx, Δy und Δz anzuzeigen, obgleich andere Konstruktionswahlen hätten gemacht werden können.
Unglücklicherweise verhindert die Verwendung dieses Ansatzes die Ausnutzung einer anderen Huffman-Technik, um etwas mehr als ein zusätzliches Bit pro Komponente einzusparen. Die implementierte Ausführungsform wiegt jedoch diesen Nachteil dadurch auf, daß sie keine zwei zusätzlichen Anzeigefelder (für Δy und Δz) hat. Ein weiterer Vorteil ist der, daß die Verwendung eines einzelnen Anzeigerfeldes einer Hardwaredekomprimierungsmaschine erlaubt, alle drei Felder parallel zu dekomprimieren, sofern dies gewünscht ist.
Ähnliche Argumente gelten für die Δs der RGBα-Werte und folglich wird ein einzelner Feldlängenanzeiger verwendet, um die Bitlänge der R-, G-, B- und, sofern vorhanden, α-Felder anzuzeigen.
Absolute und Δ-Normalen werden ebenso durch einen einzelnen Wert (n) parametrisiert, der durch einen einzelnen Anzeiger spezifiziert werden kann. Um die Hochgeschwindigkeitshardwareimplementierungen zu niedrigen Kosten zu erleichtern, wurde die Länge des Huffman- Anzeigerfeldes auf sechs Bits, einen relativ kleinen Wert, begrenzt. Eine Nachschlagtabelle für 64 Eintragsanzeiger erlaubt die Decodierung der Anzeiger in einem Taktzyklus. Tabellen existieren für Positions-, Normalen-, Farb- und Texturkoordinaten. Einige der Tabellen können die Länge des Zeigerfeldes, die Länge des (der) Datenfeldes(er), einen Datennormalisierungskoeffizienten und ein absolutes/relatives Bit enthalten.
Für viele Hardwareimplementierungen kann eine zusätzliche Komplikation angesprochen werden. Wie unten beschrieben wird, kann der Befehl in einen 6- oder 8-Bit-Header und einen Body mit variabler Länge aufgebrochen werden, wobei ausreichend Information in dem Header bzw. in der Kopfzeile enthalten ist, um die Länge des Bodys bzw. Körpers zu bestimmen. Die Kopfzeile eines Befehls wird aber in dem Datenstrom vor dem Körper des vorherigen Befehls implementiert, um der Hardware Zeit zu geben, die Kopfzeileninformation zu verarbeiten. Beispielsweise muß die Sequehz... B0 H1B1 H2B2 H3... als... H1 B0 H2 B1 H3 B2... codiert werden.
Der Befehlssatz für die geometrische Komprimierung, der in einer Ausführungsform verwendet wird, wird nun unter Bezug auf die Fig. 10A-10Q beschrieben. Fig. 10A stellt ein Vertex- Kommando dar, das eine Huffman-komprimierte Δ-codierte Position spezifiziert sowie auch eine Normale und/oder Farbe abhängig von den Bündelbits (BNV und BCV). Zwei zusätzliche Bits spezifizieren einen Vertex-Ersetzungscode (REP) und ein anderes Bit steuert die Netzpufferverschiebung dieses Vertexes (MBP). Das Vertex-Kommando hat einen Operationscode mit zwei Bits, ein 2-Bit- Vertex-Ersetzungsfeld, ein Netzpuffenrerschiebungsbit und jede Kombination der folgenden optionalen Unterkommandos: Position, Normale, Farbe, Farbe2, d, tex1, tex2, tex3, tex4, abhängig von der gegenwärtigen Einstellung der Zustandsbündelbits. (Es sei bemerkt, daß, wenn tex< n> gebündelt ist, dann tex< n-1> ... tex< 1> ebenso gebündelt sind.)
Wie in Fig. 10B gezeigt ist, spezifiziert ein Normalenkommando eine neue gegenwärtige Normale und das Farbkommando, das in Fig. 10C gezeigt ist, stellt eine neue gegenwärtige Farbe dar. Das Normalenkommando und das Farbkommando verwenden jeweils die Huffman-Codierung von Δ-Werten.
Die Netzpufferspeicherreferenzkommandostruktur ist in Fig. 10D gezeigt. Das Netzpufferspeicherreferenzkommando erlaubt es, daß auf irgendeinen der 16 zuletzt verschobenen Vertices (und die verknüpften Normalen und/oder Farben) als der nächste Vertex Bezug genommen werden kann. Wie weiterhin in Fig. 10D gezeigt ist, wird ebenso ein 2-Bit-Vertex-Ersetzungscode ("REP") spezifiziert.
Fig. 10E stellt den Zustandseinstellbefehl dar, der die fünf Zustandsbits: BDV, BNV, BCV, CAP und BS2 aktualisiert.
Fig. 10 F stellt ein Tabelleneinstellkommando dar. Das Tabelleneinstellkommando hat einen 5-Bit-Operationscode, ein 2-Bit-Tabellenfeld, ein 7-Bit-Adreß-/Bereichsfeld, ein 4-Bit- Datenlängenfeld, ein absolutes/relatives Bit und ein 4-Bit-nach oben-schiebe-Feld. Die Gesamtbefehlslänge ist bei 23 Bits fixiert. Das Tabellen- und Adreß-/Bereichsfeld spezifiziert, welche Dekomprimierungstabelleneinträge zu aktualisieren sind; die verbleibenden Felder weisen die Aktualisierungswerte für die Tabelleneinträge auf. Die 2-Bit-Tabelle in Fig. 10S spezifiziert, auf welche der drei Dekomprimierungstabellen abgezielt wird. Die 7-Bit-Adreß-/Bereichsfeldtabelle in Fig. 10T spezifiziert, welche Einträge in der spezifizierten Tabelle einzustellen sind.
Die Tabelleneinstellungen werden in geordneten Potenzen von zwei gemacht. Die Position des ersten '1'-Bit in dem Adreß-/Bereichsfeld zeigt an, wie viele Einträge hintereinander eingestellt werden und die verbleibenden Bits nach dem ersten '1' sind die oberen Adreßbits der Basis der einzustellenden Tabelleneinträge. Dies stellt ebenso die Länge des "Zeigers" ein, die dieser Eintrag als gleich der Anzahl von Adreßbits (sofem es welche gibt) nach dem ersten '1'-Bit definiert.
Die Datenlänge spezifiziert, wie groß die Δ-Werte, die mit diesem Zeiger verknüpft werden, sind. Beispielsweise impliziert eine Datenlänge von 12, daß die oberen vier Bits Vorzeichenerweiterungen des ankommenden Δ-Wertes sind. Es sei bemerkt, daß die Datenlänge nicht die Länge des ankommenden Δ-Wertes beschreibt, sondern eher die finale Position des Δ-Wertes für die Rekonstruktion. Mit anderen Worten ist das Datenlängenfeld die Summe der tatsächlichen Δ-Bits, die einzulesen sind, zuzüglich der Menge der Verschiebung nach oben. Für die Positions-, die Farb- und die Texturabbildungskoordinatentabellen entspricht der Datenlängenwert von 1-15 der Länge von 1- 15, aber der Datenlängenwert von 0 codiert eine tatsächliche Länge von 16 (eine Länge von 0 ergibt keinen Sinn für Positionen oder Farben). Für Normalen ist eine Länge von 0 manchmal angebracht und die maximale Länge in dieser Ausführungsform beträgt nur 10. Somit bildet der Wert 0-10 für Normalen auf 0-10 ab und 11-15 werden nicht verwendet. Der Verschiebungswert nach oben ist die Anzahl von Bits, die die Δ-Werte, die von diesen Zeigern beschrieben werden, nach oben verschoben werden, bevor sie zu dem gegenwärtigen Wert addiert werden.
Der absolute/relative Anzeiger zeigt an, ob dieser Tabelleneintrag Werte beschreibt, die als eine absolute Referenz oder ein relatives Δ interpretiert werden. Es sei bemerkt, daß für Normalen die absoluten Referenzen zusätzlich sechs führende Bits haben werden, die den absoluten Oktanten und Sextanten beschreiben (spezielle Normale sind ebenso absolut).
Fig. 10 G stellt ein no-op- ("NOP"-) Kommando dar, das es Feldern innerhalb des Bitstroms erlaubt, mit 32-Bit-Wortgrenzen ausgerichtet zu werden. Dies erlaubt, daß angeordnete Felder bei der Laufzeit durch die allgemeine CPU 52 effizient korrigiert werden.
Fig. 10H stellt ein setState2-Kommando dar. Zusätzliche Eingangs- und Ausgangsbündel- und Zustandsbits beinhalten: bpv (Positionen, die Vertex-gebündelt werden), oen (ermögliche Ausgabe von der Normalen), oec (ermögliche Ausgabe der Farbe), oc2 (ermögliche Ausgabe von color2) und oed (ermögliche Ausgabe von d) und btx (wie viele Texturkoordinatenpaare).
Es gibt kein aktiviere-Ausgangsbit für Positionen, da Positionen ausgegeben werden, wenn sie gebündelt sind. Dies ist der Grund, warum das Positionsbündelbit in dem setState2-Kommando enthalten ist statt in dem setState-Kommando, d. h. daß der Software so signalisiert werden kann, daß sie Positionsinformation erwartet. Dasselbe trifft für die Texturparameter zu. Die Codierung des btx-Feldes ist wie folgt: 0 - Bündle keine Texturkoordinaten; 1 - Bündle nur Texturkoordinatenpaare; 2 - Bündle Texturkoordinatenpaare: tex1 und tex2; 3 - Bündle Texturkoordinatenpaare: tex1, tex2 und tex3; 4 - Bündle alle Texturkoordinatenpaare: tex1, tex2, tex3 und tex 4 und 5, 6, 7 für die zukünftige Benutzung reserviert.
Fig. 101 stellt eine Ausführungsform eines setColor2-Befehls dar. Das setColor2- Kommando hat einen 8-Bit-Operationscode und ein color2-Unterkommando. Wenn ein setColor2- Kommando unmittelbar vor einem mbr- (meshBufferReference-) Kommando existiert, dann überschreibt der neue Farbwert die color2-Daten, die in dem Netzpuffer für die bestimmte Netzpufferreferenz vorhanden sind'. Da setColor2 ein erweitertes Kommando ist, wird setColor2 in drei Sektionen aufgebrochen anstelle der konventionellen Aufbrechung des Kommandos in eine vorgeschaltete Kopfzeile und einen folgenden Körper: einen vorgeschalteten 8-Bit-Header, der nur den Operationscode enthält; einen 6-Bitvorgeschalteten Huffman-Anzeiger/erste-Bits-Abschnitt und den sich anschließenden Körper.
Fig. 10 J stellt eine Ausführungsform eines setD-Befehls dar. Das setD-Kommando hat einen 8-Bit-Operationscode und ein d-Unterkommando. Wenn ein setD-Kommando unmittelbar vor einem mbr- (meshBufferReference-) Kommando enthalten ist, dann überschreibt der neue Farbwert die d-Daten, die in dem Netzpuffer für diese bestimmte Netzpufferreferenz vorhanden sind. Da setD2 ein erweitertes Kommando ist, wird setD2 anstelle der üblichen Aufbrechung des Kommandos in einen vorgeschalteten Header und einen anschließenden Körper in drei Sektionen aufgebrochenen: einen vorgeschalteten 8-Bit-Header, der nur den Operationscode enthält, einen 6-Bitvorgeschalteten Huffman-Anzeiger/erste-Bits-Abschnitt und den anschließenden Körper.
Fig. 10K stellt eine Ausführungsform eines setAttribute-Befehls dar. Der setAttribute-Befehl ist der allgemeine Befehl für das Einstellen bestimmter Grafikzustandsattribute. Die 11-Bit- Attributzahl und 1-32 Datenworte werden zu den CPUs geleitet.
Fig. 10L stellt eine Ausführungsform eines setAttributel-Befehls dar. Der setAttributel- Befehl ist der allgemeine Befehl für das indirekte Einstellen der Grafikzustandsattribute. Der Token ist dafür ausersehen, semantisch das Äquivalente des Softwarekonzepts eines Stapelrahmenargumentoffsets in einer in Einklang stehenden Subroutine zu sein. Die Hardware muß nicht auf die Semantik des Tokens achten; ihre Aufgabe ist es, ihn unverändert weiterzuleiten. Das geometrische Dekomprimierungsformat kann spezifische Semantiken zu dem Token spezifizieren, z. B. als ein explizites Byte oder ein Word Offset in einem Argumentenstapel.
Fig. 10M stellt eine Ausführungsform eines gosub-Befehls dar, der die Kommandos beginnend an der spezifizierten Adresse bis zum Treffen auf einen EOS-Befehl (dargestellt in Fig. 10P) ausführt. In einer Ausführungsform sind die unteren zwei Bits des Adreßfeldes immer 0, so daß das Adreßziel immer 32-Bit-wortausgerichtet ist. In gleicher Weise stellt die Fig. 10N eine Ausführungsform eines goto-Befehls dar. Fig. 10Q stellt mögliche reservierte Befehle für die weiteren Versionen des Befehlssatzes für die geometrische Komprimierung dar.
Der Fachmann wird erkennen, daß Befehlssätze außer denen, die oben beschrieben wurden, stattdessen verwendet werden können, um die vorliegende Erfindung zu implementieren.
Das Verhältnis der Zeit, die verwendet wird, für die Kompression relativ zu der Dekompression ist ein wichtiges Maß für viele Formen der Komprimierung. In der Praxis ist es für die rechnerunabhängige Bildkomprimierung akzeptabel, daß sie vielleicht 60-mal mehr Zeit benötigt als die Dekomprimierung, jedoch für Echtzeitvideokonferenzen sollte das Verhältnis 1 sein.
Viele Implementierungen der geometrischen Komprimierung haben mit Vorteil nicht diese Echtzeitanforderung. Selbst wenn die Geometrie der Übertragung konstruiert wird, erfordern die meisten geometrieerzeugenden Techniken, z. B. CSG, Größenordnungen mehr Zeit als für das Anzeigen der Geometrie benötigt wird. Ebenso wird anders als in kontinuierlichen Bildern, die in Filmen anzutreffen sind, in den meisten Anwendungen der geometrischen Komprimierung ein komprimiertes dreidimensionales Objekt für viele aufeinanderfolgende Einzelbilder angezeigt, bevor es verworfen wird. Sollte das dreidimensionale Objekt die Animierung erfordern, wird die Animierung typischerweise mit Modellmatrizen durchgeführt. In der Tat ist es für ein CD-basiertes Spiel sehr wahrscheinlich, daß ein Objekt milliardenmal durch Käufer bzw. Benutzer dekomprimiert wird, jedoch nur einmal von der Entwicklungsfirma komprimiert wird.
Wie einige andere Komprimierungssysteme können geometrische Komprimierungsalgorithmen einen Kompromiß zwischen der Komprimierungszeit und dem Komprimierungsverhältnis eingehen. Für ein gegebenes Qualitätszielniveau erhöht sich, wenn die erlaubte Zeit für die Komprimierung sich erhöht, das Komprimierungsverhältnis, das durch ein geometrisches Komprimierungssystem erreicht wird. Es existiert ein entsprechender "Knopf" für die Qualität des resultierenden komprimierten dreidimensionalen Objektes und je geringer der Qualitätsknopf ist, um so besser das erreichte Komprimierungsverhältnis.
Ästhetische und subjektive Beurteilung kann an die geometrische Komprimierung angewendet werden. Einige dreidimensionale Objekte werden schlecht erscheinen, wenn die Zielquantisierung von Normalen und/oder Positionen leicht reduziert wird, wohingegen andere Objekte visuell unverändert bleiben können, selbst mit einer großen Quantisierung. Komprimierung kann manchmal sichtbare Artefakte verursachen, jedoch in anderen Fällen nur dafür sorgen, daß das Objekt unterschiedlich aussieht, nicht unbedingt geringer in der Qualität. In einem Experiment des Anmelders beginnt das Bild eines Elefanten tatsächlich realistischer zu erscheinen mit mehr faltenartiger Haut, wenn die Bildnormalen stärker quantisiert werden. Sobald ein Modell kreiert und komprimiert wurde, kann es in eine Bibliothek gestellt werden, um als dreidimensionales Clipart auf Systemebene verwendet zu werden.
Während viele Aspekte der geometrischen Komprimierung universell sind, wurde der oben beschriebene geometrische Komprimierungsbefehlssatz etwas angepaßt, um Hochgeschwindigkeitshardwareimplementierungen mit niedrigen Kosten zu ermöglichen. (Es versteht sich, daß ein geometrisches Komprimierungsformat, das nur für die Softwaredekomprimierung konstruiert ist, etwas unterschiedlich sein würde.) Der bevorzugte geometrische Komprimierungsbefehlssatz ist besonders offen für Hardwareimplementierungen, aufgrund der sequentiellen Einpassverarbeitung, der begrenzten lokalen Speicheranforderungen, des Zeigernachschlagens (im Gegensatz zu einer konventionellen bitsequentiellen Hamming-Verarbeitung) und der Verwendung von Verschiebungen, Addierungen und Suchen, um die meisten arithmetischen Schritte zu verwirklichen.
Fig. 11 ist ein Flußdiagramm, das die Verfahrensschritte einer geometrischen Kompressionsalgorithmusroutine ausführt. Solch eine Routine kann in dem Speicher 80 abgelegt sein und unter der Steuerung der CPU 62 (siehe Fig. 4) ausgeführt werden.
In Schritt 200 wird ein Objekt durch eine explizite Gruppe von zu komprimierenden Dreiecken dargestellt zusammen mit Quantisierungsschwellwerten für Positionen, Normalen und Farben. In Schritt 210 wird eine topologische Analyse der Konnektivität durchgeführt und harte Kanten werden in Normalen und/oder Farben markiert, falls solch eine Information nicht bereits vorliegt.
In Schritt 220 werden Vertex-Durchlaufordnung und Netzpufferreferenzen erzeugt und in Schritt 230 Histogramme von Δ-Positionen, Δ-Normalen und Δ-Farben kreiert. In Schritt 240 werden getrennte Huffman-Anzeigercodes variabler Länge für die Δ-Positionen, Δ-Normalen und Δ-Farben basierend auf Histographen zugewiesen.
In Schritt 250 wird ein binärer Ausgangsstrom erzeugt durch erst Ausgeben der Initialisierung der Huffman-Tabelle, nach der die Vertices in der Reihe durchquert werden. Geeignete Zeiger und 45 werden für alle Werte ausgegeben. In einer anderen Ausführungsform werden speziell angefertigte Tabellenabschnitte ausgegeben (d. h. die Tabelle muß nicht fest für alle Objekte bleiben). Dies wird beschrieben in "Optimized Geometry Compression for Real-time Rendering" von Michael Chow in den Proceedings von IEEE Visualization 97.
Der Anmelder hat einen Wavefront-OBJ-Formatkomprimierer implementiert, der die Komprimierung von Positionen und Normalen unterstützt, vollständig verallgemeinerte Dreiecksstreifen kreiert und einen voll vernetzenden Algorithmus implementiert. Zukünftige Ausführungsformen werden Geometrie mit variabler Genauigkeit, einschließlich feinstrukturierten Aktualisierungen der Komprimierungstabellen untersuchen. Der gegenwärtige Komprimierer wendet Zeit auf mit der Berechnung von geometrischen Details, die dem Tessellator bereits bekannt sind und letztlich wird gehofft, die komprimierte Geometrie direkt zu erzeugen. Selbst im gegenwärtig nicht optimierten Zustand kann jedoch die Software des Anmelders in vielen Fällen etwa 3.000 oder mehr Dreiecke pro Sekunde komprimieren.
Auf der Benutzerseite ist es selbstverständlich wünschenswert, die komprimierten Daten zu dekomprimieren und die oben erwähnte Patentanmeldung beschreibt eine Art und Weise solch einer Dekomprimierung. Ein anwendbarer geometrischer Dekomprimierungsalgorithmus wird unten ausgeführt:
(1) Abrufen des Restes des nächsten Befehls und der ersten 8 Bits des folgenden Befehls (es sei bemerkt, daß mit einem Vertex-Befehl es zusätzliche Unterbefehle geben kann),
(2) Expandieren jedes komprimierten Wertfeldes auf volle Präzision unter Verwendung der Anzeigertabelle,
(3A) wenn die Werte relativ sind, Addition zu dem gegenwärtigen Wert, anderenfalls Ersetzen,
(3B) falls Netzpufferreferenz, Zugreifen auf alte Werte,
(3C) falls anderer Befehl, Durchführen der Verwaltung und
(4) falls Normale, leite Index durch ROM-Tabelle, um volle Werte zu erhalten.
(5) Ausgeben der Werte in generalisierter Dreiecksstreifenform zu der nächsten Stufe.
Der Anmelder hat einen Softwaredekomprimierer implementiert, der erfolgreich komprimierte Geometrie mit einer Geschwindigkeit von etwa 10.000 Dreiecken/Sekunde dekomprimiert. Ein vereinfachtes Blockdiagramm einer Ausführungsform einer Hardwarekonstruktion kann in Fig. 12 betrachtet werden. Zur Zeit kann die Hardware mehr als 6 Millionen Dreiecke pro Sekunde dekomprimieren und zukünftige Konstruktionen sind in Arbeit, die in der Lage sein können, viele Male schneller als dies zu dekomprimieren.
Vergleichende nicht komprimierte und komprimierte Bildergebnisse sind in den Fig. 13A- 14 und in Tabelle 1 unten gezeigt. Die Fig. 13A-13G stellen dasselbe Basisobjekt, einen Triceratops, dar, jedoch mit unterschiedlichen Quantisierungsschwellwerten auf Positionen und Normalen.
Fig. 13A ist die ursprüngliche volle Gleitkommadarstellung unter Verwendung von 96-Bit- Positionen und 96-Bit-Normalen, die durch die Nomenklatur P96/N96 bezeichnet wird. Die Fig. 13B und 13C stellen die Effekte der rein positionalen Quantisierung P36/N96 bzw. P24/N96 dar, während die Fig. 13B und 13E nur die Normalenquantisierung, P96/N18 und P96/N12 darstellen. Die Fig. 13F und 13G zeigen eine kombinierte Quantisierung, P48/N18 und P30/N36.
Die Fig. 13H-13L stellen nur quantisierte Resultate für unterschiedliche Objekte dar, einschließlich einer Galleone (P30/N12), einer Dodge Viper (P36/N14), zwei Ansichten eines 57er Chevy (P33/N13) und eines Insekts (P39/N15).
Ohne in die Objekte hineinzuzoomen, hat die positionale Quantisierung weit oberhalb von 24 Bits üe Komponente) im wesentlichen keinen signifikanten sichtbaren Effekt. Wenn die Normalenquantisierung 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 anderenfalls könnte selbst der Anmelder nicht zwischen dem 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 stellt 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, was über die Positionsanzeiger-Idaten und die Normalenanzeiger-/daten hinausgeht). Die "XY2 Quant"-Spalte bezeichnet die Quantisierungsschwellwerte und die sechste Spalte stellt die Anzahl von Bits/XY2 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 Netzpufferergebnissen, die in Klammern gezeigt sind. Keine tatsächlichen Netzpufferergebnisse waren in dem Softwarekomprimierungsprototyp des Anmelders vorhanden, da bislang kein voller Vernetzungsalgorithmus implementiert wurde. Die Abschätzung (in Klammern) nimmt ein 46%-iges Trefferverhältnis in dem Netzpuffer an.
In Tabelle 1 zeigt die ganz rechte Spalte die Komprimierungsverhältnisleistung, die über existierende ausführbare geometrische Formate erreicht wurde. Obgleich die Gesamtbytezahl der komprimierten Geometrie eine eindeutige Zahl ist, mußten bei dem Angeben eines Kompressionsverhältnisses einige Annahmen über die nicht komprimierte ausführbare Darstellung des Objekts getroffen werden. Der Anmelder nahm optimierte generalisierte Dreiecksstreifen an, bei denen sowohl Positionen als auch Normalen durch Gleitkommawerte dargestellt werden, um die "ursprüngliche Größe"-Daten für die Tabelle 1 zu berechnen.
Um dem Effekt einer reinen 16-Bit-Festpunkteinfachstreifendarstellung zu demonstrieren, zeigt Tabelle 1 ebenso Bytezahlen für den Modus von OpenGL. Wie gezeigt, wird die durchschnittliche Streifenlänge auf den Bereich von 2-3 herabgesetzt. Nur wenige, falls überhaupt irgendwelche kommerziellen Produkte profitieren von generalisierten Dreiecksstreifen und Tabelle 1 gibt somit die möglichen Einsparungen des Speicherplatzes deutlich zu niedrig an. TABELLE 1
Während sicherlich eine statistische 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 in einigen Ausführungsformen die geometrische Komprimierung dreidimensionale Dreiecksdaten mit einem Faktor von sechs- bis zehnmal weniger Bits als mit konventionellen Techniken erforderlich wären darstellen. Der geometrische Komprimierungsalgorithmus des Anmelders kann in Hardware, in Software oder in einer Kombination hiervon implementiert werden. Für eine feste Anzahl von Dreiecken kann die Komprimierung die Gesamtbitgröße der Darstellung, die einen Qualitäts- und Implementierungskompromiß ausgesetzt ist, minimieren. Das resultierende geometrisch komprimierte Bild leidet nur leicht unter Verlusten in der Objektqualität und kann unter Verwendung von Software- oder Hardwareimplementierungen dekomprimiert werden. Wenn dreidimensionale Darstellungshardware eine geometrische Dekomprimierungseinheit enthält, kann Anwendungsgeometrie in dem Speicher in komprimiertem Format abgelegt werden. Weiterhin kann Datenübertragung das komprimierte Format verwenden, wodurch die effektive Bandbreite für ein Grafikbeschleunigungssystem, einschließlich gemeinsam genutzter Anzeigeumgebungen für die virtuelle Realität, verbessert werden. Resultierende Komprimierung kann die Mengen der Geometrie, die im Hauptspeicher cachespeicherbar ist, wesentlich erhöhen.
Um ein vollständigeres Verständnis der geometrischen Komprimierung, insbesondere in einem Komprimierungs-Dekomprimierungssystem, zu unterstützen, wird die Dekomprimierung von Daten, die komprimiert wurden, nun im Detail beschrieben. Die folgende Beschreibung der Dekomprimierung ist aus der vorher erwähnten Patentanmeldung des Anmelders entnommen.
Fig. 14 ist ein detailliertes Blockdiagramm der Dekomprimierungseinheit 130, die in Fig. 4 gezeigt ist. Wie in Fig. 14 gezeigt ist, beinhaltet die Einheit 130 ein Dekomprimierungseingangs- 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 Daten-FIFO mit Beschleunigungsanschluß ("APDF") in der Schnittstelleneinheit 120 kommt (siehe Fig. 4). Der APDF-Abschnitt der Schnittstelle 120 beinhaltet einen Controller, der die Größe des ankommenden Datenstroms der Einheit 130 signalisiert. Der FIFO 200 liefert einen Ausgang zu einer Eingangsblockzustandsmaschine 220 und zu einem Eingangsblock 210, einer Zustandsmaschine 220 und einer Eingangsblockeinheit 210, die miteinander kommunizieren, zur Verfügung.
Der Ausgang von dem Block 210 ist mit einer Barrel-Shifter-Einheit bzw. Kernverschiebungseinheit 240 und einem Huffman-Tabellensatz 230 verbunden, wobei der Ausgang von der Huffman-Nachschlagtabelle mit der Zustandsmaschine 220 verbunden ist. Der Operationscode innerhalb der Zustandsmaschine 220 verarbeitet die Werte, die von den Huffman-Tabellen 230 zur Verfügung gestellt werden, und gibt Daten zu der Barrel-Verschiebungseinheit 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 Barrel-Verschiebungseinheit 240 und zu einem Normalprozessor 270 und zu einem Positions-/Farbprozessor 280 ausgibt.
Die Barrel-Verschiebungseinheit 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 Dekomprimierungseinheit 130 erzeugt einen vorzugsweise 12-Bit-Anzeiger, der zu dem Anzeigerdecoder 294 parallel mit entweder 32 Bits oder 48 Bits (für die Normalen) gesendet wird, die zu dem Formatkonvertierer 292 gesendet werden. Diese Datenströme stellen Befehle zur Verfügung, die eine Ausgabe für den Formatkonvertierer 292 erzeugen. Ein vorzugsweise 32-Bit- Rücklesepfad wird verwendet, um den Zustand der Einheit zurückzulesen.
Tabelle 2 unten zeigt Schnittstellensignale, die verwendet werden, um die Dekomprimierungseinheit 130 in der bevorzugten Ausführungsform 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-, Netzpufferreferenz- und Durchleitbefehle Transaktionen von der Dekomprimierungseinheit 130. Vertex- und Netzpufferreferenzbefehle senden Daten zu dem Formatwandler und jede erzeugt einen Header, der die Vertex- Ersetzungspolicy bzw. -verfahren 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 Normalenkomponenten 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

KOMPONENTEN FORMAT
Komponentenheader 32.
Position s.15
Farbe 1,15 oder s.1,14
Normale s1,14(x3)
Durchgang 32.
Fig. 15 ist ein detailliertes Blockdiagramm des Eingangsblockes 210, der in Fig. 14 dargestellt ist. Ein vorzugsweise 64-Bit-Eingangsregister 300 empfängt Daten von dem APDF-Abschnitt des Interfaces 130 mit 32 Bits oder 64 Bits während der Zeit, in der sie in das Register 300 geladen werden. Das Register 300 gibt vorzugsweise 32 Bits gleichzeitig über den Multiplexer 310 zu einem ersten Barrel-Verschieber 320 aus, dessen Ausgang durch ein Register 330 zu einer Misch- bzw. Verschmelzungseinheit 340 geleitet wird. Der 64-Bit-Ausgang von der Verschmelzungseinheit 340 wird in das Datenregister 350 eingegeben, wobei ein Teil von dessen Ausgang als Eingang zu einem zweiten Barrel-Verschieber 360 zurückgegeben wird. Der Ausgang von dem zweiten Barrel- Verschieber 360 wird durch ein Register 370 geleitet und wird ebenso in die Verschmelzungseinheit 340 eingegeben. Der erste Barrel-Verschieber 320 richtet die Daten mit dem hinteren Ende des bitausgerichteten Datenstroms aus, der von dem Datenregister 350 über den zweiten Barrel- Verschieber 360 wiederverwendet wird. Der zweite Barrel-Verschieber 360 schiebt die verwendeten Bits aus dem Datenregister 350.
Fig. 16 ist ein detailliertes Blockdiagramm der Barrel-Verschiebungseinheit 240, die in Fig. 14 gezeigt ist. Im Überblick expandiert die Barrel-Verschiebungseinheit 240 die Position mit variabler Länge, die Farbe- und die Normalindexkomponenten auf ihre Festpunktpräzisionen. Daten, die in die Einheit 240 von der Einheit 210 und/oder 220 eingegeben werden, 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 Vertex-Befehls verwendet, der Eingang B wird für den Einstellbefehl für die Normale und die ersten Komponenten der Farbeinstellbefehle verwendet und der Eingang C wird für die verbleibenden Komponenten des Vertex- und der Farbeinsteltbefehle verwendet. Die Einheit 240 beinhaltet weiterhin ein Barrel- Linkschieberegister 480, das derart angeschlossen ist, daß es die tag_len-Daten empfängt und zu dem Register 490 ausgibt, dessen Ausgang wiederum in ein Barrel-Rechtsschieberegister 500 eingegeben wird, das derart angeschlossen ist, daß es die data_len-Daten empfängt. Das Register 500 gibt an eine Maskeneinheit 510 aus, die derart angeschlossen ist, daß sie die Schiebedaten empfängt und deren Ausgang mit dem Register 520 verbunden ist, das v_data ausgibt. Der Ausgang des Datenblockes 460 ist mit einem Register 530 gekoppelt, dessen Ausgang mit einem zweiten Register 540 gekoppelt ist, das pt_data ausgibt.
Eine geeignete Tabelle innerhalb der Huffman-Tabellen 230 (siehe Fig. 14) stellt Werte für tag_len, data_len zur Verfügung und verschiebt sie in die Einheiten 480, 500 bzw. 510. Die Barrel- Linksschiebeeinheit 480 verschiebt die Eingangsdaten um 0-6 Bits nach links (tag_len), wodurch der Huffman-Anzeiger herausgeschoben wird. Im Gegensatz dazu verschiebt das Barrel- Rechtsschieberegister 500 die Daten um 0-16 Bits (16-data_len) nach rechts und das Vorzeichen erweitert die Daten, wodurch die Daten auf ihre volle Größe gebracht werden. Die Maskeneinheit 510 deckt die unteren "Verschiebe"-Bits ab, um die Daten auf das korrekte Quantisierungsniveau festzuklemmen.
Fig. 17 stellt in größerem Blockdiagrammdetail die Positions-/Farbprozessoreinheit 280 dar, die in Fig. 14 gezeigt ist. Die Prozessoreinheit 280 erzeugt die Endposition oder die Farbkomponentenwerte. Wie in den Fig. 8 und 10 gezeigt ist, empfängt die Prozessoreinheit 280 einen vorzugsweise 16-Bit-Wert (Vdata) von der Barrel-Verschiebungseinheit 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 ankommenden Daten durch die Kombiniereinheit 600 zu den geeigneten gegenwärtig gespeicherten Daten addiert. Der neue Wert wird durch den Multiplexer 610 geleitet und wird zurück in das Register 620 gespeichert und wird entlang des Ausgangsmultiplexers 290 gesendet, der in Fig. 14 gezeigt ist. Wenn jedoch das abs_rel-Bit auf absolut gesetzt ist, dann umgehen die ankommenden Daten den Addierer 600 und werden in dem Register 620 gehalten und werden ebenso zu dem Ausgangsmultiplexer 290 ausgesendet.
Wie in Fig. 17 gezeigt ist, beinhaltet die Positions-/Farbverarbeitungseinheit 280 weiterhin einen Positions-/Farbnetzpuffer 630, der derart angeschlossen ist, daß er den Eingang zum Register 620 empfängt. Der Ausgang von dem Netzpuffer 630 ist mit den Multiplexergates, die gemeinsam als 640 bezeichnet sind, verbunden, deren Ausgänge die gegenwärtigen Werte von x, y, z, r, g, b und α darstellen. Eine Registereinstellung, die gemeinschaftlich als 650 dargestellt ist, stellt diese gegenwärtigen Werte dem Eingang des Multiplexers 660 zur Verfügung, dessen Ausgang mit dem Addierer 600 gekoppelt ist. Die Prozessoreinheit 280 beinhaltet weiterhin ein Register 670, das von der Barrel-Schiebeeinheit 240 pt_data empfängt und ausgibt.
Wie in Fig. 14 gezeigt ist, gibt die Normalenprozessoreinheit 270 ebenso Daten zu dem Ausgangsmultiplexer 290 aus. Fig. 18A stellt im Detail die Untereinheiten dar, die die Normalenprozessoreinheit 270 aufweist. Wie in der Fig. 14 und der Fig. 16 zu sehen ist, empfängt die Normalenprozessoreinheit 270 einen 18-Bit-Normalenindex als drei getrennte Komponenten: Sextant/Oktant, u und v, codierte Δu- und Δv-Komponenten von der Maskeneinheit 510 in der Barrel- Verschiebungseinheit 240. Wenn der Wert ein Δ-Wert (relativ) ist, werden Δu und Δv zu dem gegenwärtigen u- und v-Werten mittels entsprechenden Addierem 710 addiert. Die Zwischenwerte werden gespeichert und ebenso zu einer Falteinheit 800 weitergeleitet, die mit der Decoder-Falt- ROM-Einheit 272 (siehe Fig. 18B) verknüpft ist.
Wie in Fig. 18A 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 sext-, 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-Komplementierungseinheiten 770, 772, latch-flipflop-Einheiten 780, 782, 784 für das Halten der jeweiligen v-, u- und uv-Information, weitere Addierer 790, 792 und einen Normalengitterpuffer 794, der derart angeschlossen ist, daß er die curr_normal-Eingangskomponenten empfängt, enthalten.
Unter Bezug auf die Fig. 15A und 18B werden die u- und v-Werte für einen absoluten Bezug direkt zu der Faltungseinheit 800 geleitet. Die Oktant- und Sextant-Abschnitte 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, welche die Komponenten umordnen und die Vorzeichen invertieren (unter Verwendung von 2er- Komplementäreinheiten 850, 852, 854).
Die Faltungseinheit 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 der Einheit 270 treiben einen Decoder 810 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 ROM-Nachschlagtabelle 830 für die Normalen beinhaltet sind.
Fig. 19 stellt Schnittstellen zu einem Netzpuffer dar, die in Fig. 17 und/oder Fig. 18A gezeigt ist. Ein Netzpufferspeicher 794 wird vorzugsweise als ein Registerfile und als ein Zeiger auf den gegenwärtigen Ort implementiert. Daten werden an der Position des Zeigers für den gegenwärtigen Ort in dem FIFO-Netzpuffer eingegeben. Es ist jedoch der wahlfreie Zugriff auf irgendeinen der 16 Orte erlaubt, wenn die Daten aus dem FIFO ausgelesen werden, durch Ausindizieren dieses Zeigers: address = (curr_loc_ptr-Index) Modulo 16.
Fig. 20A stellt Schnittstellen zu Huffman-Tabellen, z. B. den Tabellen 230 in Fig. 14, dar. Huffman-Tabellen werden verwendet, um die Huffman-Anzeiger, die den komprimierten Daten vorangehen, zu decodieren. Drei Huffman-Tabellen werden verwendet: eine für die Position, für die Farbe und für die Normalendaten, wobei jede Tabelle vorzugsweise 64 Einträge hält.
Fig. 20B stellt ein bevorzugtes Format für den Eintrag der Positions- und Farbdaten in den Huffman-Tabellen dar, während Fig. 20C das bevorzugte Format für die Normalentabelleneinträge darstellt. Das Befehlsformat für das Laden der Huffman-Tabellen in den komprimierten Datenstrom wird später beschrieben.
Verschiedene Befehle erzeugen Daten für den Formatkonvertierer 292, der in Fig. 14 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 eine Ausführungsform von Anzeigern, 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 dem eingestellten Startbit.

TABELLE 4

KOMPONENTEN ANZEIGER
Header 0 · 020
X 0 · 011
Y 0 · 012
Z 0 · 013/0 · 413
Nx/Ny/Nz 0 · 018/0 · 418
R 0 · 014
G 0 · 015
B 0 · 016/0 · 416
A 0 · 017/0 · 417
U 0 · 0c0/0 · 4c0
V 0 · 01c/0 · 41c
Die Eingangsblockzustandsmaschine 220 (siehe Fig. 14) beinhaltet vorzugsweise ein Zustandsregister, das Informationen über den Verarbeitungszustand der Dekomprimierungseinheit hält. Beispielsweise kann die Zustandsinformation ein bnv-Bit (das anzeigt, ob die Normaleninformation mit den Vertices gebündelt wird), ein bcv-Bit (das anzeigt, ob Farbinformation mit den Vertices gebündelt wird) und ein cap-Bit (das anzeigt, daß alpha (α) Information in der Farbinformation beinhaltet ist) beinhalten.
Die Positions-/Farbprozessoreinheit 280 (siehe Fig. 14 und 17) beinhaltet vorzugsweise drei 16-Bit-Register, curr_x, curr_y und curr_x, die die gegenwärtigen Positionskomponenten x, y und z enthalten und nur durch Vertex-Befehle aktualisiert werden.
Die Normalprozessoreinheit 270 (siehe Fig. 14 und 18A) beinhaltet vorzugsweise drei 6- Bit-Register (curr_oct, cun_sext, curr_u, curr_v), die die gegenwärtige Normale enthalten. Das erste Register hält die 3-Bit-Sextant- und -Oktant-Felder und die verbleibenden zwei Register enthalten die u- und v-Koordinaten für die Normale. Diese Werte werden geschrieben unter Verwendung des Normaleneinstellbefehls oder sie werden durch den Vertex-Befehl aktualisiert, wenn das bnv-Bit in dem Zustandsregister eingestellt ist.
Der Positions-/Farbprozessor 280 beinhaltet weiterhin vorzugsweise vier 16-Bit-Register, curr_r, curr_g, curr_b, curr_a, welche die gegenwärtigen Farbkomponenten, rot, grün, blau und alpha (a) 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. α ist vorzugsweise nur gültig, wenn das cap-Bit in dem Zustandsregister eingestellt ist. Das Test-Bit wird eingestellt, wenn die Texturkomponenten verarbeitet werden, wobei in diesem Fall nur rot und grün gültig sind.
Ein möglicher Befehlssatz, der die Dekomprimierung von komprimierten Geometriedaten implementiert, wird nun beschrieben. Fig. 21A stellt das Vertex-Befehlsformat dar, einen Befehl, der Huffman-Codierung mit variabler Länge verwendet, um ein Vertex darzustellen. Die Positionsinformation ist immer in diesem Befehl vorhanden.
(REP) Die Vertex-Ersetzungspolicy lautet wie folgt:
00 - Neustart im Uhrzeigersinn
01 - Neustart im Gegenuhrzeigersinn
10 - Ersetze Mitte
11 - Ersetze ältestes
(M) - Netzpuffenrerschiebung:
0 - keine Verschiebung
1 - Verschiebung
Unter Bezug auf Fig. 21A bestehen die Positionsdaten aus einem Huffman-Anzeiger variabler Länge (0-6 Bits) gefolgt von drei Datenfeldern von gleicher Länge für die x-, y- und z- Komponenten, die entweder Δ-Werte oder Absolutwerte sind. Das data_len-Feld für den Eintrag in der Huffman-Positionstabelle gibt die Länge von jedem der X-, Y- und Z-Felder an, der tag_len- Eintrag gibt die Länge des Anzeigers an und der abs_rel-Einsatz sagt, ob die Daten absolute Daten sind oder relativ zu dem vorherigen Vertex sind. Der Verschiebeeintrag von der Huffman-Tabelle gibt das Quantisierungsniveau (Anzahl der führenden Nullen) für die Daten an.
Wenn das bnv-Bit in dem Zustandsregister eingestellt ist, wird eine Normale aufgenommen. Die codierte Normale hat einen Huffman-Anzeiger gefolgt von entweder zwei Datenfeldern variabler Länge für Δu und ΔW oder von einem Feld fester Länge für den Sextanten und den 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 letztere Codierung für absolute Codierungen ist. Die data_len-, tag_len-, abs_rel- und die Verschiebefelder von der Huffman-Normalentabelle werden in ähnlicher Weise wie Einträge von der Positionstabelle verwendet.
Fig. 21 B stellt Datenformate der Vertex-Komponente dar. Wenn das bcv-Bit in dem Zustandsregister gesetzt ist, wird Farbe in dem 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 Oktant-Feldern verwendet. Wenn jedoch die Anzeigertabelle relativ anzeigt, werden Δ-Normalen verwendet und es ist ausreichen, Breiten- und Längendaten zu senden (z. B. θ und φ, ebenso als u und v bezeichnet).
Unter weiterem Bezug auf Fig. 21B 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 Schiebefelder von der Huffman-Farbtabelle werden in ähnlicher Weise wie Einträge von der Positions- und Normalentabelle verwendet.
Die Zustände des Vertex-Befehlssatzes sind wie folgt:
1. Sperren bzw. Halten des nächsten Operationscodes; Ausgabe X, verschiebe Barrel- Rechtsschiebeeinheit 500 (siehe Fig. 16) um ptag_len + pdata_len - pquant + 2.
2. Mischen bzw. Verschmelzen; Ausgabe der Kopfzeile.
3. Ausgabe Y, verschiebe Barrel-Rechtsschiebeeinheit 500 (siehe Fig. 16) um pdata_len - pquant.
4. Mische.
5. Ausgabe Z, verschiebe Barrel-Rechtsschiebeeinheit 500 (siehe Fig. 16) um pdata_len - pquant.
6. Mische.
a. Falls (bnv)
i. falls (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 Barrel- Rechtsschiebeeinheit 500 (siehe Fig. 16) um ntag_len + 6.
8. Mische.
9. Ausgabe U.
a. Wenn (absolute Normale), verschiebe Barrel-Rechtsschiebeeinheit 500 (siehe Fig. 16) 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 Barrel- Rechtsschiebeeinheit 500 (siehe Fig. 10) um ctag_len + cdata_len + cquant.
14. Vermische.
15. Ausgabe G; verschiebe Barrel-Rechtsschiebeeinheit 500 (siehe Fig. 16) um cdata_len - cquant.
16. Vermische; wenn (tex), verzweige zu nächstem Befehl.
17. Ausgabe B; verschiebe Barrel-Rechtsschiebeeinheit 500 (siehe Fig. 16) um edata_len - cquant.
18. Vermische; wenn (~cap), verzweige zu nächstem Befehl.
19. Ausgabe A; verschiebe Barrel-Rechtsschiebeeinheit 500 (siehe Fig. 16) um cdata_len - cquant.
20. Vermische; verzweige zu nächstem Befehl.
21. Ausgabe curr_normal.
a. Wenn (bcv), gehe zu 13,
b. sonst, wenn (rct), gehe zu 22,
c. sonst vermische; verzweige zu nächstem Befehl.
22. Ausgabe curr_r.
23. Ausgabe curr_g. Wenn (tex), vermische; verzweige zu nächstem Befehl.
24. Ausgabe curr_b. Wenn (~cap), vermische; verzweige zu nächstem Befehl.
25. Ausgabe curr_a. Vermische, verzweige zu nächstem Befehl.
Fig. 21C stellt das Format für den Normaleneinstellbefehl dar. Der Normaleneinstellbefehl stellt den Wert des gegenwärtigen Normalenregisters ein. Die Normalendaten werden in ähnlicher Weise wie die Normalendaten in dem Vertex-Befehl codiert, der hier beschrieben wurde. Die Zustände des Normaleneinstellbefehls sind wie folgt:
Wenn (absolute Normale)
1. Verriegele nächsten Operationscode; Ausgabe Sextant/Oktant; verschiebe Barrel- Rechtsschiebeeinheit 500 (siehe Fig. 16) um ntag_len + 8.
2. Vermische.
3. Ausgabe U; verschiebe Barrel-Rechtsschiebeeinheit 500 (siehe Fig. 16) um ndata_len - nquant.
4. Vermische.
5. Ausgabe V; verschiebe Barrel-Rechtsschiebeeinheit 500 (siehe Fig. 16) um ndata_len + nquant.
6. Vermische; verzweige zu nächstem Befehl. sonst /*relative Normale*/
1. Verriegele nächsten Operationscode; Ausgabe dU; verschiebe Barrel- Rechtsschiebeeinheit 500 (siehe Fig. 16) um n_tag_len + ndata_len - nquant.
2. Vermische.
3. Ausgabe dv; verschiebe Barrel-Rechtsschiebeeinheit 500 (siehe Fig. 16) um ndata_len - nquant.
4. Vermische; verzweige zu nächstem Befehl.
Fig. 21 D stellt den Farbeinstellbefehl dar, wobei der Befehl den Wert der gegenwärtigen Farbregister einstellt. Die Codierung der Farbdaten erfolgt ä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 Barrel- Rechtsschiebeeinheit 500 (siehe Fig. 16) um ctag_len + cdata_len + cquant + 2.
2. Vermische.
3. Ausgabe G; verschiebe Barrel-Rechtsschiebeeinheit 500 (siehe Fig. 16) um cdata_len - cquant.
4. Vermische. Falls (tex), verzweige zu nächstem Befehl.
5. Ausgabe B; verschiebe Barrel-Rechtsschiebeeinheit 500 (siehe Fig. 16) um cdata_len - cquant.
6. Vermische. Falls (~cap), verzweige zu nächstem Befehl.
7. Ausgabe A; verschiebe Barrel-Rechtsschiebeeinheit 500 (siehe Fig. 16) um cdata_len - cquant.
8. Vermische; verzweige zu nächstem Befehl.
Fig. 21E ist ein bevorzugtes Format für den Netzpufferreferenzbefehl. Dieser Befehl veranlaßt, daß Daten von einem Eintrag in dem Netzpuffer nach außen zu dem Formatumwandler als nächster Vertex gesendet werden. Unter Bezug auf Fig. 21E zeigt der Index den Eintrag an, der von dem Netzpuffer zu senden ist. Der neueste Eintrag in dem Netzpuffer 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 Netzpufferreferenzbefehl verwendete. Die Zustände für den Netzpufferreferenzbefehl sind wie folgt:
1. Verriegele nächsten Operationscode; Ausgabe Header; verschiebe Barrel- Rechtsschiebeeinheit 500 (siehe Fig. 16) um 9.
2. Ausgabe X von Netzpuffer.
3. Ausgabe Y von Netzpuffer.
4. Ausgabe Z von Netzpuffer.
a. Falls (bnv oder mt), gehe zu 5,
b. sonst, falls (bcv oder rct), gehe zu 6,
c. sonst, vermische; verzweige zu nächstem Befehl.
5. Falls (bvn), gib Normale von Netzpuffer aus, sonst, falls (rnt), gib r_normal aus.
a. Falls (bnv oder rct), gehe zu 6,
b. sonst vermische; verzweige zu nächstem Befehl.
6. Falls (bcv), Ausgabe R von Netzpuffer, sonst, falls (rct), Ausgabe curr_r.
7. Falls (bcv), Ausgabe G von Netzpuffer, sonst, falls (rct), Ausgabe curr_g. Falls (tex), vermische; verzweige zu nächstem Befehl.
8. Falls (bcv), Ausgabe B von Netzpuffer, sonst, falls (rct), Ausgabe curr_b. Falls (~cap), vermische; verzweige zu nächstem Befehl.
9. Falls (bcv), Ausgabe A von Netzpuffer, sonst, falls (rct), Ausgabe curr_a. Vermische; verzweige zu nächstem Befehl.
Fig. 21F stellt den Zustandseinstellbefehl dar, welcher die Bits des Zustandsregisters der Dekomprimierungseinheit einstellt. Die Zustände für den Zustandseinstellbefehl sind wie folgt:
1. Verriegele nächsten Operationscode, verschiebe Barrel-Verschieber 2 um 11 Bits.
2. Vermische; verzweige Befehl.
Fig. 21G stellt den Tabelleneinstellbefehl dar, der die Huffman-Tabelleneinträge einstellt. Die Tabellenauswahl ist wie folgt:
00 - Positionstabelle
01 - Farbtabelle
10 - Normalentabelle
11 - undefiniert.
Die Länge der Anzeiger wird von der Adresse abgeleitet. Die neun Bits in dem Eintragsfeld entsprechen dem absoluten/relativen Bit, der Datenlänge und der Felder der Verschiebungsgrößen der Huffman-Tabelleneinträge (das bevorzugte Format der Huffman-Tabelleneinträge wurde hier vorher beschrieben). Die Zustände des Tabelleneinstellbefehls sind wie folgt:
1. Verriegele nächsten Operationscode; sende Adresse und Eintrag zu Huffman- Tabellen; verschiebe Barrel-Rechtsschiebeeinheit 500 (siehe Fig. 16) um 21.
2. Vermische; verzweige zu nächstem Befehl.
Tabelle 5 unten zeigt die bevorzugten Huffman-Tabellenfüllcodes. TABELLE 5
Fig. 21H 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-Bit-Grenze 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; lies Adresse, verschiebe Barrel- Rechtsschiebeeinheit 500 (siehe Fig. 16) um 32 Bits.
2. Vermische.
3. Ausgabe Daten, verschiebe Barrel-Rechtsschiebeeinheit 500 (siehe Fig. 16) um 32 Bits.
4. Vermische; verzweige zu nächstem Befehl.
Fig. 211 stellt den NOP-Befehl variabler Länge ("VNOP") dar, der eine variable Anzahl von 0 Bits in dem Datenstrom codiert. Der 5-Bit-Zähler, der in Fig. 211 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; lies count bzw. Zähler; verschiebe Barrel- Rechtsschiebeeinheit 500 (siehe Fig. 16) um 13 Bits;
2. Vermische.
3. Barrel-Rechtsschiebeeinheit liest "count"-Positionen;
4. Vermische; verzweige zu nächstem Befehl.
Fig. 21 J zeigt den Skip8-Befehl bzw. Auslaßbefehl, dessen Zustände wie folgt sind:
1. Verriegele nächsten Operationscode; verschiebe Barrel-Rechtsschiebeeinheit 500 (siehe Fig. 16) um 16 Bits;
2. Vermische; verzweige zu nächstem Befehl.

Vertex-Rasterformat

Fig. 22 - Computersystem

Es wird nun auf Fig. 22 Bezug genommen. Ein Computersystem 1080 ist dargestellt, das dreidimensionale geometrische Komprimierungs- und Dekomprimierungsfähigkeiten entsprechend einer Ausführungsform der vorliegenden Erfindung beinhaltet. Wie gezeigt, beinhaltet das Computersystem 1080 eine Systemeinheit 1082 und einen Videomonitor oder ein Anzeigegerät 1084, das mit der Systemeinheit 1082 verbunden ist. Verschiedene Eingabegeräte können mit dem Computersystem verbunden sein, einschließlich einer Tastatur 1086 und/oder einer Maus 1088 oder einem anderen Eingabegerät.
Anwendungssoftware kann von dem Computersystem 1080 ausgeführt werden, die dreidimensionale geometrische Daten erzeugt, die graphische Objekte beschreibt, die auf der Anzeigevorrichtung 1084 darzustellen sind. Wie weiter unten beschrieben werden wird, ist das Computersystem 1080 derart konfiguriert, daß es die dreidimensionalen geometrischen Daten komprimiert. Die komprimierten 3D-Geometriedaten können dann in dem Speicher des Computers 1080 gespeichert werden. Die komprimierten 3D-Geometriedaten, die in dem Speicher abgelegt sind, können dann später über ein Netzwerk übertragen werden oder zu einem 3D-Grafikbeschleuniger innerhalb des Computersystems 1080 für die Dekomprimierung und Darstellung der Daten übertragen werden. Alternativ dazu werden die komprimierten 3D-Geometriedaten verwendet, um ein Medium, wie z. B. eine CD- ROM, zu erzeugen, die für Anwendungen, wie z. B. Spiele, verwendet werden kann. Die Komprimierung kann vorteilhafterweise zu einer verringerten Übertragungszeit der komprimierten geometrischen Daten über ein Netzwerk oder zu einem Grafikbeschleuniger führen, sowie auch zu reduzierten Speicheranforderungen für das Speichern der komprimierten Geometrie.
Wenn das Computersystem 1080 für die geometrische Dekomprimierung konfiguriert ist, dann empfängt der Computer 80 komprimierte 3D-Geometriedaten. Diese Daten können von einem Netzwerk, der Host-CPU des Computers 1080 oder von einem Speichermedium (wie z. B. einer CD- ROM), das mit dem Computersystem verbunden ist, empfangen werden.

Fig. 23 - Computersystemblockdiagramm

In Fig. 23 ist ein vereinfachtes Blockdiagramm, das das Computersystem 1080 von Fig. 20 illustriert, gezeigt. Elemente des Computersystems 1080, die nicht für ein Verständnis der vorliegenden Erfindung notwendig sind, sind aus Gründen der Bequemlichkeit nicht gezeigt. Wie gezeigt, beinhaltet das Computersystem 1080 eine zentrale Verarbeitungseinheit (CPU) 1102, die mit einem Hochgeschwindigkeitsbus oder Systembus 1104 verbunden ist. Ein Systemspeicher 1106 ist ebenso vorzugsweise mit dem Hochgeschwindigkeitsbus 1104 verbunden.
Der Host-Prozessor 1102 kann irgendeiner von verschiedenen Typen von Computerprozessoren, Multiprozessoren und CPUs sein. Der Systemspeicher 1106 kann irgendeiner von verschiedenen Typen von Speichersubsystemen sein, einschließlich Speichern mit wahlweisem Zugriff und Massenspeichergeräte. Der Systembus oder Host-Bus 1104 kann irgendeiner von verschiedenen Typen von Kommunikations- oder Host-Computerbussen für die Kommunikation zwischen den Host- Prozessoren, den CPUs und den Speichersubsystemen sein, so wie auch spezialisierte Subsysteme.
Ein 3D-Grafikbeschleuniger 1112 ist mit dem Hochgeschwindigkeitsspeicherbus 1104 verbunden. Der 3D-Grafikbeschleuniger 1112 kann mit dem Bus 1104 beispielsweise durch einen Kreuzschienenschalter oder eine andere Busverbindungslogik verbunden sein. Es wird angenommen, daß verschiedene andere externe Geräte oder andere Busse mit dem Hochgeschwindigkeitsspeicherbus 1104 verbunden werden können, wie es im Stand der Technik bekannt ist. Der Grafikbeschleuniger 1112 kann weiterhin über einen oder mehrere andere Busse mit dem Bus 1104 verbunden sein.
Der Host-Prozessor 1102 kann Information zu und von dem Grafikbeschleuniger 1112 entsprechend eines programmierten Eingabe-/Ausgabe- (I/O-) Protokolls über den Host-Bus 1104 übertragen. In einer Ausführungsform greift der Grafikbeschleuniger 1112 auf das Speichersubsystem 1106 gemäß einem Direktzugriffsspeicherprotokoll (DMA) oder über intelligentes Busmastering zu.
In einer Ausführungsform werden die dreidimensionalen geometrischen Daten durch ein Grafikanwendungsprogramm erzeugt, das auf dem Computersystem 1080 ausgeführt wird. Die resultierenden 3D-Geometriedaten werden vor oder nach dem Speichern in dem Systemspeicher 1106 komprimiert. Die Geometriedaten können von der Host-CPU 1102, die ein Softwarekomprimierungsprogramm von dem Systemspeicher 1106 ausführt, komprimiert werden, oder können zu einer spezialisierten Hardwareeinheit innerhalb der Systemeinheit 1082 für die Komprimierung übertragen werden. Wenn das Computersystem 1080 ebenso verwendet wird, um die 3D-Geometriedaten darzustellen, werden die komprimierten Daten von dem Systemspeicher 1106 zu dem Grafikbeschleuniger 1112 über den Systembus 1104 übertragen. Der Grafikbeschleuniger 1112 dekomprimiert die überkragenen komprimierten geometrischen Daten, wodurch die resultierenden Grundelemente entsprechend auf der Anzeigevorrichtung 1084 dargestellt werden. Die komprimierten 3D- Geometriedaten können ebenso über ein Netzwerk für die nachfolgende Dekomprimierung übertragen werden (wie unter Bezug auf Fig. 22 diskutiert wird) oder auf einem entfernbaren Medium, wie z. B. einer CD-ROM, abgefegt werden. Es sei bemerkt, daß der 3D-Grafikbeschleuniger 1112 nicht notwendig ist, wenn das Computersystem 1080 streng für Komprimierungszwecke verwendet wird. Dies kann der Fall sein, wenn das Computersystem 1080 verwendet wird, um die komprimierten Daten auf ein Speichermedium zu speichern oder die Daten über ein Netzwerk zu übertragen.
Wie unten beschrieben wird, ist das Komprimierungssystem und das Verfahren, das hier beschrieben wird, vorzugsweise auf die Komprimierung von Oberflächenabschnitten von dreidimensionalen Objekten, die regelmäßig gekachelt sind, gerichtet. Wie ebenso unten beschrieben wird, arbeitet das Dekomprimierungssystem und das Dekomprimierungsverfahren derart, daß es komprimierte 3D-Geometriedaten dekomprimiert, die komprimiert worden sind, um die regelmäßige Kachelung der Grundelemente, die in den geometrischen Daten enthalten ist, auszunutzen. In einer Ausführungsform führt das Komprimierungssystem und -verfahren wahlweise verschiedene Typen oder Niveaus der Komprimierung auf Oberflächenabschnitten der 3D-Geometriedaten aus, abhängig davon, ob der zu komprimierende Abschnitt regelmäßig oder unregelmäßig gekachelt ist. Entsprechend kann das Dekomprimierungssystem und das Dekomprimierungsverfahren wahlweise verschiedene Typen der Dekomprimierung abhängig von dem bestimmten Oberflächenabschnitt, der dekomprimiert wird, durchführen.

Fig. 24 - Computemetzwerk

In Fig. 24 ist ein Computernetzwerk 1120 gezeigt, das zumindest einen Servercomputer 1124 und einen oder mehrere Client-Computer 1126 aufweist. (In der in Fig. 24 gezeigten Ausführungsform sind die Client-Computer 1126A-B dargestellt.) Der Server 1122 und der (die) Client(s) 1126 können über eine Vielfalt von Verbindungen 1124, wie z. B. ein lokales Netzwerk (LAN), ein Weitbereichnetz (WAN) oder eine Internetverbindung verbunden sein. In einer Ausführungsform speichert der Server 1122 vorkomprimierte 3D-Geometriedaten. Die Clients 1126A-B können mit dem Server 1122 verbunden sein, um die komprimierte Geometrie herunterzuladen. Einer oder mehrere der Clients 1126 empfangen die komprimierten 3D-Geometriedaten und dekomprimieren dann die komprimierten 3D-Geometriedaten für die Darstellung. Alternativ kann einer oder mehrere Clients 1126 die 3D-Geometriedaten erzeugen, die Komprimierung durchführen und die komprimierte Geometrie zu dem Server 1122 für die Speicherung übertragen. In noch einer anderen Ausführungsform können die komprimierten 3D-Geometriedaten zwischen den Client-Computern 1126 übertragen werden.

Fig. 25-33 - Geometrische Komprimierung eines regelmäßig gekachelten Oberflächenabschnittes

Fig. 25 stellt ein Komprimierungsverfahren 1200 für Daten, die einen regelmäßig gekachelten Oberflächenabschnitt eines dreidimensionalen Objektes definieren, dar. Wie gezeigt, beinhaltet das Verfahren 1200 zunächst den Schritt 1210, in dem die dreidimensionalen Geometriedaten gekachelt werden. In einer Ausführungsform können die geometrischen Daten als verallgemeinerte Dreiecksstreifen dargestellt werden. In einer anderen Ausführungsform können die geometrischen Daten in einem verallgemeinerten Dreiecksnetzformat dargestellt werden. Wie in der US- Patentanmeldung Seriennr. 08/511,294 beschrieben ist, codiert ein verallgemeinertes Dreiecksnetzformat Position und die Konnektivität der geometrischen Daten und verwendet den Platz dadurch effizient, daß die Wiederverwendung von Vertex-Informationen ermöglicht wird. Ein Algorithmus, der verwendet werden kann, um eine verallgemeinerte Dreiecksnetzdarstellung zu erzeugen, ist beschrieben in "Optimized Geometry Compression for Real-time Rendering" von Michael Chow in den Proceedings von IEEE Visualization 97.
In Schritt 1220 wird ein regelmäßig gekachelter Oberflächenabschnitt ausgewählt, um in komprimiertem Format dargestellt zu werden. Dieses komprimierte Format wird hier als "Vertex- Raster" bezeichnet. Allgemein gesprochen beinhaltet ein Vertex-Raster eine verknüpfte Ausdehnung und ausreichend Information, um einen oder mehrere Vertex-Parameterwerte innerhalb der spezifizierten Ausdehnung zu bestimmen. Wie unten beschrieben werden wird, kann der Ausdehnungsabschnitt des Vertex-Rasters eine einer Mehrzahl von vordefinierten Größen spezifizieren oder kann eine willkürliche Größe und Form des Oberflächenabschnittes und der hierin enthaltenen Vertices spezifizieren. Fig. 26 stellt einen regelmäßig gekachelten Oberflächenabschnitt 1300 dar, der als ein Vertex-Raster darzustellen ist. Obgleich ein Vertex-Raster von irgendeiner gegebenen Ausdehnung sein kann, ist die Ausdehnung des Vertex-Rasters, das in Fig. 26 gezeigt ist, ein 5 · 5- Quadratgitter von Vertices.
In Schritt 1230 wird die Ausdehnung des Vertex-Rasters in dem codierten Datenstrom spezifiziert. In einer bevorzugten Ausführungsform wird der Ausdehnungswert eines Vertex-Rasters als ein 2-Bit-Wert codiert, der ein Quadratgitter anzeigt, das eine der drei definierten Größen hat: 5 · 5 (25 Vertices), 9 · 9 (81 Vertices) oder 17 · 17 (289 Vertices). Es sei bemerkt, daß verschiedene andere vordefinierten Größen stattdessen oder zusätzlich zu den oben zitierten Größen verwendet werden können. Beispielsweise kann in einer Ausführungsform ein regelmäßig gekachelter Oberflächenabschnitt als ein 3 · 5-Vertex-Raster dargestellt werden.
In einer Ausführungsform definiert die Spezifizierung einer Ausdehnung für ein Vertex-Raster ebenso implizit die Konnektivitätsinformation für Vertices innerhalb des regelmäßig gekachelten Oberflächenabschnittes, der durch das Vertex-Raster dargestellt wird. Es wird der Oberflächenabschnitt 1300 in Fig. 26 betrachtet. In einer Ausführungsform spezifiziert ein Ausdehnungswert für den Oberflächenabschnitt 1300, daß die Vertices in Quadraten (oder allgemeiner in Vierecken oder "quads") verbunden sind. Jedes Quad wird typischerweise aufgeteilt (oder "tesselliert") in ein Paar aus Dreiecken, die dann in einen komprimierten geometrischen Datenstrom codiert werden. Es sei bemerkt, daß ein gegebenes Quad in eine von zwei Richtungen tesselliert werden kann: von der unteren linken Ecke zu der oberen rechten Ecke oder von der oberen linken Ecke zu der unteren rechten Ecke. In einer Ausführungsform, wenn keine explizite Tessellierungsinformation auf einer Quad-per-Quad-Basis spezifiziert wird, wird angenommen, daß alle Quads in einer vorgegebenen Richtung aufgeteilt werden sollen (wie z. B. die vorgegebene Richtung, die für alle Quads in Fig. 26 gezeigt ist). Wie unten beschrieben wird, kann die explizite Konnektivitätsinformation ebenso innerhalb eines Vertex-Rasters geliefert werden.
Weiterhin müssen die Vertices eines Oberflächenabschnittes nicht notwendigerweise als Vierecke gruppiert sein, um als ein Vertex-Raster dargestellt zu werden. Man betrachte beispielsweise einen Oberflächenabschnitt, der in einer hexagonalen Art und Weise gekachelt ist. Ein Vertex- Raster kann für solch einen Oberflächenabschnitt, der Vertices spezifiziert, die in Hexagonen anstelle von Vierecken oder Dreiecken zusammengebaut ist, definiert werden. Ebenso kann ein Vertex- Raster auch für einen unregelmäßig gekachelten Oberflächenabschnitt definiert werden, der halb regelmäßig ist (z. B. unregelmäßig in einer vorhersagbaren Art und Weise). Beispielsweise können kleine Gruppen von Vertices mit regelmäßigen Attributen in einem unregelmäßigen Muster vorhanden sein oder große Gruppen von Vertices können Attribute haben, die im allgemeinen in einem regelmäßigen Muster variieren, jedoch unregelmäßig auf einer Vertex-pro-Vertex-Basis variieren. Mit anderen Worten können die graphischen Daten von einem makroskopischen Betrachtungspunkt aus regelmäßig erscheinen, jedoch von einem detaillierteren mikroskopischen Betrachtungspunkt unregelmäßig.
In einer Ausführungsform sei bemerkt, daß benachbarte Oberflächenabschnitte eines Grafikobjekts jeweils als ein Vertex-Raster dargestellt werden können. In solch einer Ausführungsform kann sich jeder Oberflächenabschnitt Vertices entlang der gemeinsamen Kante(n) teilen. Folglich können die Vertices in den Vertex-Rastem, die die benachbarten Oberflächenabschnitte darstellen, ebenso jeweils Information über die gemeinsamen Vertices enthalten.
Wie unten beschrieben werden wird, wird die Ausdehnung des Vertex-Rasters während der Dekomprimierung verwendet, um Parameterwerte für jeden der Vertices innerhalb des Oberflächenabschnittes, der von dem Vertex-Raster dargestellt wird, zu bestimmen. Eine Ausführungsform eines Formats für einen "SetVertexRasterSize"-Befehl ist in Fig. 27 gezeigt. Zwei Bits werden verwendet in dem Befehl, um eine von den drei vorbestimmten Rastergrößen zu spezifizieren. In einer alternativen Ausführungsform kann das Vertex-Raster von einer willkürlichen Größe sein. Diese willkürliche Größe kann explizit gegeben sein oder kann in dem Datenstrom pro Vertex als "stop codes" codiert sein, die das Ende einer Zeile oder von Daten oder von dem gesamten Raster anzeigen.
Zusätzlich zu der Spezifizierung einer Ausdehnung eines Oberflächenabschnittes beinhaltet das Vertex-Raster ebenso ausreichend Information, um die Vertex-Parameterwerte der Vertices innerhalb des Oberflächenabschnittes, der durch das Vertex-Raster dargestellt wird, zu dekomprimieren. Wie unten beschrieben wird, können die Vertex-Parameterwerte des regelmäßig gekachelten Oberflächenabschnittes spezifiziert werden pro Vertex (explizit), durch Interpolationswerte oder durch Verwendung einer Kombination hieraus. In einer Ausführungsform beinhalten die Vertex- Parameterwerte, die innerhalb eines Vertex-Rasters spezifiziert sind, (i) Positionswerte, (ii) Farbwerte, (iii) Normalenwerte, (iv) Texturabbildungskoordinaten, (v) Band-Nerschiebungsabbildungswerte und (vi) Oberflächenmaterialeigenschaften.
In einer Ausführungsform können ursprüngliche Werte von ausgewählten Parametern innerhalb eines Vertex-Rasters zusammen mit einer Anzeige, wie sich diese Werte entlang des Vertex- Rasters verändern, spezifiziert werden. Man betrachte beispielsweise einen Oberflächenabschnitt eines graphischen Objekts, in dem Positionskoordinaten in einer regelmäßigen Art und Weise variieren. Für solch einen Oberflächenabschnitt können ursprüngliche Positionswerte spezifiziert werden, die zu einem vorbestimmten Vertex innerhalb des Oberflächenabschnittes korrespondieren. Positionale Deltawerte können dann spezifiziert werden, die anzeigen, wie sich die Positionswerte von Vertex zu Vertex innerhalb des Oberflächenabschnittes, der durch das Vertex-Raster dargestellt wird, verändern. Die Interpolation kann ebenso auf anderen Vertex-Parameterwerten, wie z. B. den oben aufgelisteten, durchgeführt werden. Werte, die in dieser Art und Weise codiert werden, werden ebenso als global spezifizierte Werte bezeichnet.
Vertex-Parameterwerte können ebenso explizit auf einer pro-Vertex-Basis spezifiziert werden. In einer solchen Ausführungsform kann ein Vertex-Raster eine Ausdehnung und eine Codierung enthalten, die spezifiziert, welche Parameter in dem Vertex-Raster enthalten sind, gefolgt von einem Strom von pro-Vertex-Daten. Die Größe dieser Vertex-Daten ist bestimmbar aus der Ausdehnung des Oberflächenabschnittes und der Größe der Daten, die für jedes Vertex spezifiziert sind. Während diese Technik die mögliche Komprimierung unter Verwendung der oben beschriebenen Interpolationswerte nicht erreichen kann, resultiert die Komprimierung immer noch daraus, daß die Konnektivitätsinformation für den regelmäßig gekachelten Oberflächenabschnitt nicht explizit zu codieren ist. Werte, die in dieser Art und Weise codiert werden, werden ebenso als lokal spezifizierte Werte bezeichnet.
Diese zwei Techniken (Interpolation und pro-Vertex-Daten) können ebenso innerhalb eines einzigen Vertex-Rasters kombiniert werden. Das heißt, daß verschiedene Vertex-Parameterwerte durch Interpolation spezifiziert werden können, während andere auf einer pro-Vertex-Basis spezifiziert werden können. Beispielsweise kann ein Vertex-Raster, das einen gegebenen Oberflächenabschnitt eines graphischen Objekts darstellt, Positionswerte enthalten, die durch Interpolation spezifiziert werden, und Farbwerte enthalten, die auf einer pro-Vertex-Basis spezifiziert werden. In noch einer anderen Ausführungsform kann ein gegebener Vertex-Parameterwert errechnet werden unter Verwendung von globalen und lokalen Werten. Ein Beispiel dieser Technik ist die Verwendung von lokal spezifizierten Z-Verschiebungswerten, um global spezifizierte Normalenwerte zu stören.
In dem Flußdiagramm des Verfahrens 1200, das in Fig. 25 gezeigt ist, werden beide Techniken für die Spezifizierung von Vertex-Daten verwendet. Interpolierte Werte werden in den Schritten 1240 bis 1250 codiert, während pro-Vertex-Daten in Schritt 1260 codiert werden. Diese Schritte werden in weiterem Detail unten beschrieben.
In Schritt 1240 werden ursprüngliche Werte von ausgewählten Parametern für Vertices in dem Oberflächenabschnitt spezifiziert, der durch das Vertex-Raster dargestellt wird. Diese ausgewählten Parameter korrespondieren zu einem ursprünglichen Vertex, das typischerweise an einem vordefinierten Ort innerhalb des Oberflächenabschnittes ist. Die Werte der verbleibenden Vertices werden über das Raster während des Dekomprimierungsprozesses basierend auf den in Schritt 1240 eingestellten ursprünglichen Werten interpoliert. Da diese Parameter für jedes Vertex in dem Oberflächenabschnitt interpoliert werden, müssen diese Parameter nicht auf einer pro-Vertex-Basis in dem komprimierten Datenstrom spezifiziert werden, wodurch Speicher und Busbandbreite eingespart wird. Die ursprünglichen Parameterwerte werden in einer Ausführungsform unter Verwendung eines "SetVertexRasterStart"-Befehls in einer bevorzugten Ausführungsform der Erfindung spezifiziert. Ein mögliches Format für diesen Befehl ist in Fig. 28 gezeigt.
Wie in Fig. 28 gezeigt ist, spezifiziert der "SetVertexRasterStart"-Befehl eines von fünf Vektorregistern (i = 0-4). Jedes dieser Vektorregister beinhaltet einen unterschiedlichen interpolierbaren Parameter. Die Zuweisung dieser Vertex-Register in einer bevorzugten Ausführungsform ist unten in Tabelle 6 gezeigt.

TABELLE 6

Vektorregister Parameter
0 Parameterposition
1 globale Farbe
2 globale Normale
3 Bump/Verschiebung Abbildungsbasisvektor 0
4 Bump/Verschiebung Abbildungsbasisvektor 1
Das Vektorregister 0 (VR0) beinhaltet ursprüngliche Positionsdaten und ist in einer bevorzugten Ausführungsform derart konfiguriert, daß es 16-Bit-Festkommawerte für die X-, Y- und Z- Koordinaten speichert. VR1 ist derart konfiguriert, daß es vier 16-Bit-Farbwerte in einer bevorzugten Ausführungsform speichert: rot, blau, grün und alpha. Der alpha-Wert ist optional abhängig von dem Zustand eines unten diskutierten Modusbits. VR2 speichert die XY2-Komponenten eines globalen Normalenwertes, während VR3-4 Basisvektoren speichert, die verwendet werden, um die Bump- bzw. Erhebungs- und Verschiebungsabbildung zu unterstützen. In einer anderen Ausführungsform können die Vektorregister anders konfiguriert werden. Beispielsweise kann eine andere Anzahl oder eine andere Größe je Register verwendet werden. In ähnlicher Weise können andere Attribute, die die Vertices betreffen, in den Vektorregistern abgelegt werden anstelle von oder zusätzlich zu den oben gezeigten Parametern. In einer Ausführungsform kann eine Vertex-Rasterdarstellung 0-5 Set- VertexRasterStart-Befehle, eines für jedes Vektorregister, beinhalten. In dieser Ausführungsform werden, wenn keine Vektorregister spezifiziert werden, die Vertex-Parameterwerte auf einer pro- Vertex-Basis spezifiziert.
In Schritt 1250 werden die Deltawerte für die in Schritt 1240 ausgewählten Parameter eingestellt, die anzeigen, wie sich die Parameter entlang des Oberflächenabschnittes, der durch das Vertex-Raster dargestellt wird, verändern. In einer bevorzugten Ausführungsform können diese Deltawerte in sowohl der U- als auch der V-Richtung (nicht zu verwechseln mit den Namen, die manchmal für die Texturabbildungskoordinaten verwendet werden) spezifiziert werden. Die U- und V- Richtungen sind für eine Ausführungsform eines regelmäßig gekachelten Oberflächenabschnittes in Fig. 29 gezeigt. Fig. 29 stellt ebenso die Vertices innerhalb des Oberflächenabschnittes 1300 dar, der entsprechend der Ordnung, in der die Vertices während der Dekomprimierung verarbeitet werden (und somit die Ordnung, in der die Interpolation durchgeführt wird), markiert sind. In ähnlicher Weise bezieht sich die in Fig. 29 gezeigte Ordnung ebenso auf die Ordnung, in der die pro-Vertex- Daten innerhalb der Vertex-Rasterdarstellung des Oberflächenabschnittes 1300 gespeichert werden. Wie in Fig. 29 gezeigt ist, bezieht sich die U-Richtung in einer Ausführungsform auf die Richtung zwischen den Vertices in einer bestimmten Zeile. Im Gegensatz dazu bezieht sich die V- Richtung in einer Ausführungsform auf die Richtung zwischen aufeinanderfolgenden Zeilen.
In den Fig. 30A und 30B sind die Formate für Befehle, die in einer Ausführungsform die Deltawerte für die in Schritt 1240 ausgewählten Parameter einstellen, gezeigt. Fig. 30A stellt das Format des "SetVertexRasterStepDU"-Befehls dar, während das "SetVertexRasterStepDV"- Befehlsformat in Fig. 30B dargestellt ist. Die Vertex-Raster Delta-U-Vertex-Register sind derart konfiguriert, daß sie drei (vier im Falle des VRDU1) Festkommawerte speichern, die die Veränderung zwischen jedem Vertex in dem Raster in der U-Richtung für eine bestimmte Größe anzeigen. Beispielsweise zeigen die XYZ-Werte in VRDU0 den Positionsunterschied (Δx, Δy und Δz) zwischen irgendwelchen zwei benachbarten Vertices innerhalb derselben Zeile in Fig. 29 an. Die Vertex- Raster Delta-V-Register sind in ähnlicher Weise konfiguriert (VRDV0-Werte spezifizieren den Positionsunterschied zwischen irgendwelchen zwei benachbarten Vertices in Fig. 29 innerhalb derselben Spalte). In einer Ausführungsform erlauben diese Delta-Register, daß die Position, die globale Farbe, die globale Normale und Bump-/Verschiebungsvektoren einmal spezifiziert werden (durch den "SetVertexRasterStart"-Befehl), wobei die verbleibenden Werte für die Vertices des Rasters während der Dekomprimierung interpoliert werden, wodurch die Größe des codierten Datenstroms reduziert wird. Die Werte, die von den "SetVertexRasterStep"-Befehlen spezifiziert werden, sind effektiv die Ableitung des Wertes, dargestellt durch VRi (i = 0-4) nach der ebenen U- oder V-Koordinaten.
Es sei bemerkt, daß alle Vektorregister in Bezug auf das Vertex-Raster optional sind, d. h. keines, einige oder alle hiervon können eingestellt sein. Selbst mit keinen interpolierten Werten in dem Vertex-Raster ist die Konnektivitätsinformation immer noch inhärent in der Vertex- Rasterdarstellung. Dies eliminiert die Notwendigkeit für Netzpufferverschiebungs- und Referenzbits, die explizit in dem verallgemeinerten Dreiecksnetzformat verwendet werden. Die Verwendung der Vektorregister VR0-4 ist vorteilhaft, wo sie anwendbar ist, da größere Komprimierungsverhältnisse erzielt werden können.
Obgleich die Vertices des Oberflächenabschnittes 1300 in einem Quadratgitter angeordnet sind, erlauben die Formate der Vertex-Rasterschrittbefehle, die oben beschrieben wurden, die Spezifikation von Oberflächenabschnitten, die Vertices haben, die in wechselnder Art und Weise angeordnet sind. Dies wird erleichtert durch getrennte Schrittbefehle für die U- und V-Richtung, die beide Veränderungen in jeder der X-, Y- und Z-Koordinaten erlauben. Durch geeignete Codierung des SetVertexRasterStepDU- und des SetVertexRasterStepDV-Befehls können die Oberflächenabschnitte, wie z. B. 1400, 1410 und 1420, die in den Fig. 31A-C dargestellt sind, komprimiert werden. Der Oberflächenabschnitt 1400 beinhaltet Vertices, die in einem rechteckigen Gitter organisiert sind, während die Oberflächenabschnitte 1410 und 1420 als Rhomben (mit keinem rechten Winkel) bzw. als Parallelogramme (mit ungleichen benachbarten Seiten und ungleichen Innenwinkeln) organisiert sind.
In Schritt 1260 wird eine optionale pro-Vertex-Information für Vertices in dem Oberflächenabschnitt, der durch das Vertex-Raster dargestellt wird, spezifiziert. In einer Ausführungsform wird diese Information spezifiziert unter Verwendung von einem der Befehle, die in den Fig. 32A-C gezeigt sind. Fig. 32A stellt das Format eines "ExecuteVertexRaster"-Befehl dar gemäß einer Ausführungsform der Erfindung. Auf diesen Befehl folgt ein Strom von pro-Vertex-Daten. In einer Ausführungsform wird das Format der pro-Vertex-Daten vorspezifiziert unter Verwendung eines zusätzlichen Befehls, der unten beschrieben wird. Auf diese Art und Weise kann das Ende des Stroms der pro-Vertex-Daten bestimmt werden durch Multiplikation der Anzahl von Vertices mit der Datengröße für einen gegebenen Vertex. Dies erlaubt es, daß ein anderer Geometriebefehl ohne notwendige Stop-Bits für den Ausführungsbefehl unmittelbar auf die pro-Vertex-Daten folgt. Es gibt ebenso andere Techniken, die die Notwendigkeit für Stop-Bits in dem pro-Vertex-Datenstrom vermeiden. Eine solche Technik, die Header-Body-Paare verwendet, wird unten in größerem Detail beschrieben. Da die pro-Vertex-Daten dem Befehl inline folgen, werden keine anderen Operationscodes benötigt, bis alle Datenpunkte, die zu jedem der Vertices in dem Raster korrespondieren, gelesen wurden. In einer bevorzugten Ausführungsform beinhaltet der Ausführungsbefehl pro-Vertex-Daten für 25, 81 oder 289 Vertices.
Alternativ können die Vertex-Rasterdaten spezifiziert werden beginnend an einer Speicheradresse durch den "ExecuteVertexRasterlndirect"-Befehl, der in Fig. 32B gezeigt ist. Dies erlaubt es, dieselben pro-Vertex-Daten für unterschiedliche Raster zu verwenden, während die Interpolationsparameter, die oben beschrieben wurden, sich verändern. Die Komprimierungseffizienz wird mit Vorteil durch die Verwendung dieses Befehls erhöht.
Der "ExecuteVertexRaster321ndirect"-Befehl, der in Fig. 32C gezeigt ist, wird für Vertex- Raster mit einem speziellen Speicherformat verwendet: 32-Bit RGBα-Pixel. Die Vertex-Rasterdaten beginnen an der spezifizierten Adresse, jedoch nach 5, 9 oder 17 Pixeln (abhängig von dem Größenwert), setzen die Rasterdaten bei Adresse+stride fort, wobei stride die Breite des Rasters in Bytes ist. In einer bevorzugten Ausführungsform der Erfindung sind sowohl die Adresse als auch der Stride 32-Bit-wortausgerichtet.
Wie oben beschrieben wurde, können verschiedene Vertex-Parameterwerte auf einer pro- Vertex-Basis spezifiziert werden. In einer bevorzugten Ausführungsform werden die pro-Vertex- Attribute, die als Teil eines gegebenen Vertex-Rasters spezifiziert werden, durch den Zustand der Modusbits, die durch die letzten "SetState"- und "SetState2"-Befehle eingestellt wurden, bestimmt. Das Format dieser Befehle in einer Ausführungsform ist in den Fig. 33A und 33B gezeigt. Eine Beschreibung der Operandenfelder des SetState-Befehls ist in Tabelle 7 gegeben.

TABELLE 7

Bitfeld Beschreibung
dde Delta-Delta-Codierung aktiviert für einige Vertices des Vertex-Rasters
bnv Bündelnormale mit pro-Vertex-Daten
bcv Bündelfarben mit pro-Vertex-Daten
cap Farbwerte schließen alpha-Komponente ein
qsp Viereckaufteilungstessellierungsbits in pro-Vertex-Daten enthalten
Das "dde"-Bit aktiviert die Delta-Delta-Codierung und wird unten weiter erörtert. Die "bnv"- und "bcv"-Bits spezifizieren, wenn sie eingestellt sind, daß Normalen bzw. Farben Teil der pro-Vertex- Daten sind, die auf den "ExecuteVertexRaster"-Befehl folgen. Wenn das "cap"-Bit eingestellt ist, dann enthalten die Farbwerte pro Vertex einen alpha-Wert zusätzlich zu den RGB-Komponenten. Schließlich wird, wenn das "qsp"-Bit eingestellt ist, ein Tessellierungsbit für jedes Viereck in dem Vertex-Raster spezifiziert. Diese getrennten Tessellierungsbits werden verwendet für die Zwecke des Anti-Aliasings und werden unten weiter erörtert.
Eine Beschreibung der Bitfelder in dem SetState2-Befehl ist in Tabelle 8 unten gegeben.

TABELLE 8

Bitfeld Beschreibung
scp Spiegelnde Farbe in pro-Vertex-Daten enthalten
tex Interpretiere spiegelnde Farbe als Texturabbildungskoordinate
tx2 Interpretiere spiegelnde Farbe als zweite Texturabbildungskoordinate
psrc Positionsquelle:
00 - xyz-Positionen in pro-Vertex-Daten; VR0 wird nicht verwendet
01 - xyz-Positionen nicht in pro-Vertex-Daten; VR0 wird verwendet
10 - xyz-Positionen nicht in pro-Vertex-Daten; VR0 wird verwendet; z-Verschiebung in pro-Vertex-Daten
11 - reserviert
vr1 Aktiviere Ausgabe von VR1-Werten
vr2 Aktiviere Ausgabe von VR2-Werten
vr3 Aktiviere Ausgabe von VR3-Werten
vr4 Aktiviere Ausgabe von VR4-Werten
Der SetState2-Befehl ist eine Erweiterung der Modusbits, die von dem oben beschriebenen SetState-Befehl eingestellt werden. Das "scp"-Bit zeigt an, daß spiegelnde Farbwerte in der pro- Vertex-Information vorhanden sind. Diese spiegelnden Farbwerte werden als eine Texturabbildungskoordinate interpretiert, wenn das "tex"-Bit gesetzt ist. In gleicher Weise wird der lokale FarbWert (gesteuert durch das "bcv"-Bit) als eine Koordinate von einer alternativen Texturabbildung interpretiert, wenn das "tx2"-Bit gesetzt ist.
Die "psrc"-Bits bestimmen, wie die Vertex-Positionen zwischen aufeinanderfolgenden Vertices in dem Oberflächenabschnitt, der als ein Vertex-Raster dargestellt wird, berechnet werden. Wenn psrc=00, dann werden die xyz-Positionen explizit für jeden Vertex in dem Oberflächenabschnitt spezifiziert (selbst wenn VR0 initialisiert wurde). Obgleich dies die Vertex-Rastersymmetrie nicht voll ausnutzt, wird die Konnektivitätsinformation immer noch implizit durch das Raster definiert. Es besteht somit keine Notwendigkeit für die expliziten Netzpufferverschiebungen und Referenzen, die in einem verallgemeinerten Dreiecksnetz mit keinem Vertex-Rasterbefehl verwendet werden.
Wenn psrc=01, wird der ursprüngliche Wert für die xyz-Positionsdaten über die Vertices des Vertex-Rasters gemäß der vordefinierten U- und V-Deltawerte interpoliert. In Fig. 29 werden die ursprünglichen Positionswerte (die durch den SetVertexRasterStart-Befehl spezifiziert) auf den Vertex 0 angewendet. Der Delta-U-Wert wird dann auf den Vertex 0 angewendet, um die Positionsdaten für Vertex 1 zu erhalten. Dieselbe Prozedur folgt für die Vertices 2, 3 und 4. Um die Position des Vertex 5 zu bestimmen, wird der Delta-V-Wert an den Vertex 0 angelegt. Das Delta U wird dann an den Vertex 5 angelegt, um Vertex 6 zu berechnen (und im folgenden die Vertices 7, 8 und 9). In diesem Modus kann eine größere Komprimierungseffizienz relativ zu der psrc-Einstellung "00" erreicht werden, in der die Positionsdaten für jeden Vertex explizit spezifiziert werden.
Wenn psrc=10, werden die xyz-Positionen von VR0 wie oben beschrieben interpoliert. Zusätzlich sind z Verschiebungswerte in den pro-Vertex-Daten enthalten. Die z Verschiebungswerte werden verwendet, um Verschiebungstexturierung durchzuführen, in der die Oberfläche um eine kleine Menge verschoben wird, um eine Falte oder eine Erhebung zu simulieren. In vielen Fällen ist dies effektiver als die Bandabbildung bzw. Erhöhungsabbildung (in der die Oberflächennormale gestört wird), insbesondere nahe der Silhouette eines dunkel getönten Objektes. Die Codierung psrc=11 wird in einer bevorzugten Ausführungsform der Erfindung gegenwärtig nicht verwendet.
Die Bitfelder VR1, VR2, VR3 und VR4 in dem SetState2-Befehl werden von der Dekomprimierungseinheit verwendet, um zu bestimmen, ob die verschiedenen Vektorregistergrößen für ein bestimmtes Raster aktiviert sind. Wenn ein Bit für eine bestimmte Größe nicht gesendet wird, leitet die Dekomprimierungseinheit keinen Wert für diese Größe (z. B. eine lokale Normale) zu einer nachfolgenden Stufe der Darstellungshardware. In einer Ausführungsform entsprechen die VR- Zustandsbits denjenigen Attributen, die von dem SetVertexRasterStart-Befehl initialisiert wurden.
In alternativen Ausführungsformen werden zusätzliche Zustandsbits eingesetzt, die zusätzliche Daten spezifizieren, die in die pro-Vertex-Daten des Rasters aufgenommen werden sollen. Es sei weiterhin bemerkt, daß die pro-Vertex-Daten des Rasters in einer Vielzahl von Arten und Weisen einschließlich der Komprimierungstechniken, die in der Vorgänger-Patentanmeldung beschrieben wurden, für Positionen, Farben und Normalen codiert werden können.

Fig. 34-36 - StepVertexRaster-Befehl

Wie oben beschrieben wurde, können die Vertex-Raster derart definiert sein, daß sie regelmäßig gekachelte Oberflächenabschnitte darstellen, wobei Vertices in Quadratgittern angeordnet sind, die eine von drei vorbestimmten Größen haben: 5 · 5, 9 · 5 und 17 · 17. Die Gitter sind auf diese Größen in einer bevorzugten Ausführungsform begrenzt, um die Dekomprimierungshardware zu vereinfachen. Im Ergebnis kann es jedoch sein, daß ein gesamter regelmäßig gekachelter Oberflächenabschnitt in einigen Fällen nicht durch eine einzelne Vertex-Rasterstruktur dargestellt werden kann. In diesen Fällen würde die Komprimierungseffizienz beeinträchtigt, wenn die gesamten Vertex-Rasterdaten erneut spezifiziert werden müßten.
Um diese Begrenzung zu verhindern, während immer noch eine handhabbare Vertex- Rastergröße beibehalten wird, kann ein "StepVertexRaster"-Befehl verwendet werden. Ein mögliches Format für diesen Befehl ist in Fig. 34 gezeigt, es sind jedoch andere Formate möglich. Der StepVertexRaster-Befehl hat ein einzelnes Argument "dir". In dieser Ausführungsform codiert das 3- Bit-Feld eine von drei möglichen Richtungen, in der sich das gegenwärtige Vertex-Raster bewegt. Ein Beispiel eines möglichen Verfahrens für die Codierung des dir-Feldes ist in Tabelle 9 unten gezeigt:

TABELLE 9

Bitfeld Richtung
000 +U
001 +U, +V
010 +V
Es sei bemerkt, daß acht Richtungen unter Verwendung des 3-Bit-Feldes codiert werden können. Beispielsweise kann in manchen Ausführungsformen die Codierung des dir-Feldes erweitert werden, um zusätzliche Richtungen darzustellen, um das gegenwärtige Raster zu verschieben (z. B. +U, -U, +V, -V usw.).
Ein Beispiel einer Verwendung des StepVertexRaster-Befehls ist in Fig. 35 dargestellt. Fig. 35 stellt einen 9 · 5 regelmäßig gekachelten Oberflächenabschnitt 1005 eines dreidimensionalen Objektes dar. In einer bevorzugten Ausführungsform, die oben beschrieben wurde, ist es nicht möglich, diese Größe des Oberflächenabschnittes als ein einzelnes Vertex-Raster darzustellen. In einer Ausführungsform kann der Oberflächenabschnitt 1500 in zwei 5 · 5-Oberflächenabschnitte 1510A-B aufgeteilt werden und effizient unter Verwendung einer Kombination des Verfahrens, das mit Bezug auf Fig. 25 beschrieben wurde, und dem StepVertexRaster-Befehl von Fig. 34 komprimiert werden. Ein Verfahren 1600 für die Komprimierung des Oberflächenabschnittes 1500 ist in Fig. 36 gezeigt.
Wie gezeigt, arbeitet das Verfahren 1600 gemäß dem Verfahren 1200, das oben beschrieben wurde. Der Oberflächenabschnitt 1500 wird gekachelt und ausgewählt, daß er ein Vertex-Raster in den Schritten 1210 und 1220 codiert. In Schritt 1230 wird die Ausdehnung des ersten Vertex- Rasters (1510A) als ein 5 · 5-Quadratgitter eingestellt. Als nächstes werden Ursprungswerte in den VR-Registern von Vertex 0 des Rasters 1510A in Schritt 1240 gebildet. In Schritt 1250 werden die Delta-U- und Delta-V-Werte abgelegt, die spezifizieren, wie sich die Parameter, die in Schritt 1240 initialisiert wurden, entlang des Rasters verändern. In Schritt 1260 wird ein ExecuteVertexRaster- Befehl ausgegeben gefolgt durch optionale pro-Vertex-Daten für das Raster.
Nachdem das Vertex-Raster 1510A durch die Schritte 1210-1260 spezifiziert wurde, wird ein StepVertexRaster-Befehl in Schritt 1270 ausgegeben. In dem in Fig. 35 gezeigten Beispiel ist das Vertex-Raster 1510B das nächste, das codiert wird: In Bezug auf das Vertex-Raster 1510A ist das Raster 1510B in der +U-Richtung lokalisiert. Der StepVertexRaster-Befehl in Schritt 1270 beinhaltet daher einen dir-Bitfeldwert von "000" in einer bevorzugten Ausführungsform.
In einer Ausführungsform veranlaßt die Ausführung des StepVertexRaster-Befehls, daß die Werte der aktiven Vektorregister in der Richtung interpoliert werden, die von dem "dir"-Wert spezifiziert werden. In dem obigen Beispiel werden die Delta-U-Werte mit 4 multipliziert und zu den ursprünglichen aktiven VR-Werten addiert, um die ursprünglichen Werte für das Raster 15108 zu erhalten. Keine Veränderung wird in der V-Richtung berechnet. Weiterhin veranlaßt der StepVertex- Raster-Befehl, daß die pro-Vertex-Daten, die von dem vorherigen Vertex-Rasterbefehl spezifiziert wurden, erneut unter Bezug auf die neuen Werte in den VR-Registem ausgeführt wird.
Wie in Fig. 36 gezeigt ist, kann der Schritt 1270 wiederholt ausgeführt werden. Sobald jeder Stufenbefehl ausgeführt ist, werden neue Werte für die VR-Register berechnet. Diese neuen Werte werden dann als eine Basis für die Interpolierung entlang der Vertices des neu spezifizierten Oberflächenabschnittes verwendet. Mit der Ausgabe von noch einem anderen Schrittbefehl werden die zuletzt berechneten VR-Registerstartwerte verwendet als eine Basis für das Berechnen neuer VR- Registerstartwerte.
Da die Interpolationswerte nicht redundant für die Raster 1510B spezifiziert sein müssen, wird die Komprimierungseffizienz mit Vorteil für den Oberflächenabschnitt 1500 erhöht. In einer anderen Ausführungsform kann der Befehl (die Befehle) für den Schritt des Vertex-Rasters durch zusätzliche Daten in der pro-Vertex-Information oder als zusätzliche Operanden geliefert werden, um den Rasterbefehl auszuführen. Die Spezifikation einer Schrittfunktion für Vertex-Raster erlaubt effektiv die Komprimierung der komprimierten Geometriedaten, wobei mit Vorteil die Menge der Datencodierung reduziert wird.

Fig. 37-38 - Viereckaufteilungstessellierung

In den oben dargestellten Oberflächenabschnitten sind die Vierecke, die von dem Schnitt der Zeilen- und Spaltenlinien gebildet werden, alle als in der gleichen (vorgegebenen) Richtung tesselliert gezeigt. Ungeachtet welche Richtung als Vorgabe ausgewählt wird, können unerwünschte visuelle Artefakte im Ergebnis vorhanden sein. Man betrachte die Darstellung des Buchstabens "C" 1650, die in Fig. 37A gezeigt ist. Für den Buchstaben 1650 wird jedes Viereck bzw. Quad in dem Oberflächenabschnitt in derselben Richtung tesselliert (obere linke zu unterer rechter Ecke). Dies führt zu Abschnitten des Buchstabens 1650 mit ausgezackten Kanten.
Im Gegensatz dazu wird die Darstellung des Buchstabens "C" 1660 unter Verwendung von selektiver Aufteilung der Vierecke gebildet. Das heißt, daß jedes Viereck in dem Oberflächenabschnitt von Fig. 37B in einer Art und Weise aufgeteilt ist, die dem Objekt, das gezeichnet wird, am meisten geziemt. Folglich hat der Buchstabe 1660 einen reduzierten Grad der "Ausgezacktheit" im Vergleich zu dem Buchstaben 1650.
Objekte können somit gezackte Kanten zeigen, wenn die Aufteilungsrichtung nicht mit der stärksten Farbveränderung innerhalb eines gegebenen Vierecks übereinstimmt. Die Vierecktessellierungsrichtung kann spezifiziert werden unter Verwendung von Werten in dem codierten Datenstrom oder alternativ durch die Verwendung einer Viereckaufteilungsdifferenzfunktion, die dynamisch während der Dekomprimierung berechnet wird. Die Verwendung von einer dieser Methoden führt mit Vorteil zu weniger Artefakten in dem schlußendlich dargestellten Bild.
Das qsp-Feld des SetState-Befehls wird eingestellt, um die explizite Spezifikation der Quad- Tessellierung in dem Vertex-Raster zu ermöglichen. Das heißt, wenn das qsp-Feld eingestellt ist, daß der pro-Vertex-Datenstrom, der dem ExecuteVertexRaster-Befehl folgt, einen Bitwert für jedes Viereck beinhaltet, das die Aufteilrichtung anzeigt. Ein Beispiel einer Tessellierung, die auf einer pro- Viereck-Basis durchgeführt wurde, ist in Fig. 38 gezeigt.
In Fig. 38 beinhaltet der Oberflächenabschnitt 1700 ein 5 · 5-Gitter aus Vertices, die in 16 Vierecke unterteilt sind. Jedes Viereck ist durch sein entsprechendes Aufteilungsbit markiert. Vierecke, die mit einer "0" (die Vorgaberichtung) markiert sind, werden von der unteren linken Ecke zu der oberen rechten Ecke aufgeteilt, während Vierecke, die mit einer "1" markiert sind, von der oberen linken zu der unteren rechten Ecke aufgeteilt werden.
In einer bevorzugten Ausführungsform kann, wenn das qsp-Bit nicht durch den SetState- Befehl eingestellt ist, eine Differenzfunktion verwendet werden, um automatisch die Viereckaufteilungsrichtung während der Darstellung zu bestimmen. In einer Ausführungsform wird diese Differenzfunktion durch die folgende Gleichung gegeben:
Diese Gleichung kann auf gegenüberliegende Vertices innerhalb eines gegebenen Vierecks angewendet werden, um zu bestimmen, welches Paar die "stärkste" Farbveränderung hat. Die Verwendung dieser Technik erfordert keine zusätzlichen Daten, die während der Codierung zu übertragen sind, da das Aufteilungsbit bzw. Split-Bit als eine Funktion der Farbwerte (die ohnehin gesendet werden) berechnet wird. Die Komprimierungseffizienz wird mit Vorteil erhöht. Es sei jedoch erwähnt, daß, während diese Technik für die Farbbestimmung geeignet ist, sie für die Beleuchtungsberechnungen unkorrekt sein kann. Das heißt, daß die Aufteilungsrichtung einen "glatteren" Farbfluß erzeugen kann, jedoch einen weniger realistischen Lichteffekt erzeugen kann. Aus diesem Grund kann in einer alternativen Ausführungsform die korrekte Aufteilungsrichtung nach der Beleuchtung bestimmt werden.
Als ein Beispiel der Verwendung einer Differenzfunktion wird ein 5 · 5-Netz mit Vertices 0-24 betrachtet. Ein bestimmtes Viereck wird durch das Vertex n bezeichnet, wobei n die obere rechte Ecke bzw. das obere rechte Vertex in dem Viereck ist (somit kann n die Werte 6-9, 11-14, 16-19 und 21-24 einnehmen). Die Differenzgleichung kann dann auf die Paare (n - 6, n) und (n - 5, n - 1) angewendet werden. Wenn das (n - 5, n - 1)-Paar die größere Differenzfunktion hat, dann wird das Viereck in der vorgegebenen Tessellierungsrichtung (unteres linkes Vertex zu oberem rechtem) aufgeteilt. Alternativ wird das Viereck von der oberen linken zu der unteren rechten Ecke aufgeteilt, wenn das (n - 6, n)-Paar die größere Differenzfunktion hat. Es sei bemerkt, daß die obige Gleichung eine Näherung der Umwandlung von dem Rot-Grün-Blau- in den Schwarz-und-Weiß-Farbraum ist.
Es sei bemerkt, daß in einer unterschiedlichen Ausführungsform eine andere Differenzfunktion verwendet werden kann. In ähnlicher Weise können die Codierungen der Aufteilungsrichtung in anderen Ausführungsformen sich ebenso unterscheiden. Es sei weiterhin bemerkt, daß die automatische Aufteilungsbestimmung durch die Verwendung eines Modusbits in einer Ausführungsform aktiviert/deaktiviert werden kann.

Fig. 39-41 - Halbauflösungsmodus

Ein gemeinsames Artefakt in 3D-Grafiken besteht dann, wenn ein Objekt in den Hintergrund einer Szene (dargestellt in niedriger Auflösung) sich in den Vordergrund einer Szene (in die hohe Auflösung) bewegt. Typischerweise erfolgt dieser Übergang von der niedrigen in die hohe Auflösung als eine gewichtige Schaltung, die zu einem nicht ansprechenden (und unrealistischen) visuellen Effekt führt. Eine Lösung dieses Problems ist es, die Kante (oder die Kanten) eines Oberflächenabschnittes eines Objektes in einer Zwischenauflösung während des Übergangs von der niedrigen in die hohe Auflösung darzustellen. Diese Darstellung wird als "Halbauflösung" oder als "half-rez"- Modus bezeichnet. Die Verwendung dieses Modus wird unten beschrieben, sofem sie Vertex-Raster betrifft, obgleich der half-rez-Modus ebenso auf verallgemeinerte Dreiecksnetzformate anwendbar ist.
In Fig. 39 ist das Format des "SetEdgeHalfRez"-Befehls gezeigt. Wie gezeigt ist, beinhaltet der Befehl vier 1-Bit-Operanden (el, et, er und eb), die verwendet werden können, um den half-rez- Modus unabhängig für jede der vier Seiten des gegenwärtigen Vertex-Rasters einzustellen. (Es sei bemerkt, daß, wenn der half-rez-Modus ohne den Vertex-Rastermodus verwendet wird, nur das obere und untere Bit in einer Ausführungsform anwendbar sind.)
Die Fig. 40A-B stellen Oberflächenabschnitte dar mit jedem der eingeschalteten vier Bits. Beispielsweise hat der Oberflächenabschnitt 1800A, der in Fig. 40A gezeigt ist, das "el"- (linke- Kante-) Bit angeschaltet. Die Oberflächenabschnitte 1800B-D, die in den Fig. 40B-D gezeigt sind, haben die "er"-, "et"- bzw. "eb"-Bits gesetzt. Es sei bemerkt, daß jegliche Kombination der vier Bits gesetzt sein kann (d. h. ein Oberflächenabschnitt kann mehr als eine Kante im half-rez-Modus dargestellt haben).
Die Verwendung des half-rez-Modus erlaubt realistischere visuelle Effekte. Wenn sich ein Objekt von der niedrigen Auflösung in die hohe Auflösung (oder umgekehrt) bewegt, können Oberflächenabschnitte dazwischen mit halber Auflösung dargestellt werden. In dieser Art und Weise kann ein "patch" seine Tessellierung auf das, was in den Bereichen benötigt wird, anpassen.
Ein Beispiel eines half-rez-Modus ist durch den Oberflächenabschnitt 1810 in Fig. 41 gegeben. Wie gezeigt ist, beinhaltet der Oberflächenabschnitt 1810 Unterabschnitte 1810A-D. Der Unterabschnitt 1810A, der dem Betrachter am nächsten ist, wird als ein 9 · 9-Quadratgitter von Vertices dargestellt, während Unterabschnitte 1810B-D (die weiter entfernt sind) als 5 · 5-Arrays von Vertices dargestellt werden. Um die Abruptheit der Auflösungsveränderung zwischen den Oberflächenunterabschnitten 1810 zu verringern, werden zwei Kanten des Unterabschnittes 1810 im half-rez-Modus dargestellt.

Fig. 42 - Dekomprimierungshardware

Ein Blockdiagramm einer Ausführungsform des Grafikbeschleunigers 1112, der in Fig. 23 dargestellt ist, ist unter Bezug auf Fig. 42 gezeigt. Wie gezeigt ist, empfängt der Grafikbeschleuniger 1112 einen komprimierten Geometriestrom 1904. Der Strom 1904 kann von dem Hauptspeicher über einen Systembus oder von einem getrennten Computersystem über ein Netzwerk geleitet werden. Der komprimierte Geometriestrom 1904 kann 3D-Geometriedaten enthalten, die unter Verwendung einer Vielfalt von unterschiedlichen Techniken, wie z. B. denjenigen, die hier beschrieben wurden und in der Vorgängerpatentanmeldung des Anmelders beschrieben wurden, komprimiert wurden. Der komprimierte Geometriestrom 1904 kann ebenso nicht komprimierte 3D-Geometriedaten enthalten. Sowohl die komprimierten als auch die unkomprimierten Geometriedaten beschreiben Vertices (und verknüpfte Attribute), die für das Sammeln bzw. Zusammenbauen in Zeichengrundelemente (typischerweise Dreiecke) verwendbar sind, die dann von einer Grafikpipeline dargestellt werden können. Der Strom 904 beinhaltet ebenso typischenrveise eine Steuerinformation für die entsprechenden Daten.
Die Daten in dem Geometriestrom 1904 werden zu einer geometrischen Dekomprimierungseinheit (GDU) 1910 befördert. In einer Ausführungsform empfängt die GDU 1910 den Strom 1904, komprimiert jegliche komprimierten Geometriedaten und trägt eine Mehrzahl von Zeichengrundelementen zusammen unter Verwendung der Konnektivitätsinformation, die in dem Strom 1904 spezifiziert ist. Wie unten beschrieben wird, beinhaltet die GDU 1910 einen Netzpufferspeicher 1912, der für die Dekomprimierung der Geometriedaten, die in Vertex-Rastem oder verallgemeinertem Dreiecksnetzformat dargestellt werden, verwendbar ist. Die Grundelemente, die von der GDU 1910 zusammengetragen werden, werden dann zu einer oder mehreren Front-End-Verarbeitungseinheiten 1920 befördert. Obgleich in Fig. 42 der Einfachheit halber zwei Einheiten (1920A-B) gezeigt sind, kann der Grafikbeschleuniger 1112 andere Konfigurationen in alternativen Ausführungsformen beinhalten.
In einer Ausführungsform beinhaltet der Netzpufferspeicher 1912 eine feste Anzahl von Speicherorten, die für das Speichern der Parameterwerte, die mit ein oder mehreren Vertices verknüpft sind, verwendbar sind. In dieser Art und Weise können die Vertices (und korrespondierende Parameterwerte), die bei dem Bilden der mehreren Grundelemente verwendet werden, in den Netzpufferspeicher 1912 mit der ersten Benutzung verschoben werden. Wenn sie später benötigt werden, kann auf diese Werte von dem Netzpufferspeicher 1912 zugegriffen werden, was die Notwendigkeit, diese Vertices in dem komprimierten Strom 1904 erneut zu spezifizieren, vermeidet. In einer Ausführungsform ist der Netzpufferspeicher 1912 als ein Stapel organisiert und auf ihn wird zugegriffen durch das Zurverfügungstellen eines Offsets in dem Stapel.
Allgemein gesprochen, sind Front-End-Verarbeitungseinheiten 1920 für die Umwandlung der Vertices von einem Modellraumkoordinatensystem (typischerweise durch das Grafikprogramm, das die Geometriedaten erzeugt, definiert) in ein Koordinatensystem, das von der Anzeigevorrichtung spezifiziert wird, verantwortlich. Die Reihe von Schritten, die gemeinsam als das Front-End der Grafikpipeline bezeichnet werden, beinhalten solche Operationen wie die Modelltransformation, die perspektivische Teilung, das Abschneiden bzw. Clipping, die triviale Zurückweisung der Grundelemente und die Schirmraumtransformation. Die Zeichnungsgrundelemente, die von den Verarbeitungseinheiten 1920 erzeugt werden, werden in einem Koordinatensystem (Schirm- oder Vorrichtungsraum) dargestellt, das durch die Rastereinheit 1930 leicht gezeichnet werden kann.
In einer Ausführungsform empfängt die Rastereinheit 1930 die Zeichengrundelemente, die in den Vorrichtungsraumkoordinaten dargestellt werden. Die Rastereinheit 1930 stellt dann diese Grundelemente auf der Anzeigevorrichtung 1084 unter Verwendung von Prozessen, wie z. B. der Kanteninterpolation, der Spanneninterpolation und der Texturabbildungen dar. Die Einheit 1930 kann optional eine Z-Pufferspeichereinheit für das Durchführen der Entfernung verdeckter Oberflächen beinhalten.

Fig. 43-45 - Dekomprimierungsflußdiagramme

Ein verallgemeinertes Flußdiagramm, das eine Ausführungsform eines Dekomprimierungsverfahrens 1930 zeigt, ist unter Bezug auf Fig. 43 gezeigt. Wie gezeigt ist, beinhaltet das Verfahren 1930 als erstes einen Schritt 1932, in dem eine Ausdehnung des dargestellten Oberflächenabschnittes innerhalb einer Dekomprimierungseinheit, wie z. B. der GDU 1910, die in Fig. 42 gezeigt ist, eingestellt wird. In einer Ausführungsform kann die Ausdehnung eines Oberflächenabschnittes codiert werden unter Verwendung eines Formates, wie z. B. des "SetVertexRasterSize"-Befehls, der oben unter Bezug auf Fig. 27 beschrieben wurde. Andere Codierungen für den Ausdehnungswert können genauso in anderen Ausführungsformen verwendet werden.
Der Ausdehnungswert zeigt der Dekomprimierungshardware die Anordnung der Vertices innerhalb des Oberflächenabschnittes an. Dies erlaubt es der Dekomprimierungshardware, den Strom der Vertex-Daten mit den korrekten Zeichnungsgrundelementen richtig zu verbinden. In verschiedenen Ausführungsformen kann der Ausdehnungswert die Form eines Oberflächenabschnittes, die Anzahl von Vertices innerhalb des Oberflächenabschnittes oder beides anzeigen. Der Ausdehnungswert kann ebenso ein Wert sein, der anzeigt, daß die Vertices des Oberflächenabschnittes, der dargestellt wird, entsprechend einer von einer vordefinierten Anzahl von Anordnungen angeordnet ist, die die GDU 1910 kennt. Wie oben beschrieben wurde, spezifiziert der "SetVertexRasterSize"-Befehl, daß der Oberflächenabschnitt entweder 25, 81 oder 289 Vertices beinhaltet, die in einem regelmäßigen Gitter mit einer gleichen Anzahl von Zeilen und Spalten angeordnet ist. In einer anderen Ausführungsform kann dieser Befehl spezifizieren, daß das Gitter in einer alternativen Art und Weise organisiert ist.
Das Verfahren 1930 beinhaltet als nächstes die Schritte 1934 und 1936, in denen globale Parameterwerte und entsprechende Delta-Werte initialisiert werden. In einer Ausführungsform beinhaltet der Schritt 1934 das Decodieren des oben unter Bezug auf Fig. 28 beschriebenen "SetVertexRasterStart"-Befehls. Das Ausführen dieses Befehls stellt in einer Ausführungsform die ursprünglichen Werte in den Vektorregistern 0-4 ein. Jedes der fünf Vektorregister ist vordefiniert, um einen spezifischen Vertex-Parameter darzustellen. In alternativen Ausführungsformen können andere Vertex-Parameter genauso addiert werden. Diese ursprünglichen Werte der Vertex-Parameter entsprechen typischerweise Werten der Vertex-Parameter an dem ersten Vertex, der innerhalb des Oberflächenabschnittes traversiert bzw. umläuft (siehe Fig. 29).
In einer Ausführungsform beinhaltet Schritt 1936 das Decodieren des "SetVertexRaster- Step"-Befehls, der oben unter Bezug auf die Fig. 30A-30B beschrieben wurde. Das Ausführen dieses Befehls stellt in einer Ausführungsform Delta-Werte für die vorbestimmten Vertex-Parameter entsprechend den Registern ein. Es sei bemerkt, daß, selbst obwohl ein Register für einen bestimmten Vertex-Parameter (z. B. Farbe) für einen gegebenen Oberflächenabschnitt reserviert ist, dieser Vertex-Parameter nicht notwendigerweise in einem gegebenen Geometriestrom spezifiziert sein muß.
Wie oben beschrieben wurde, kann es zwei "Schritt"-Befehle geben, die abhängig von der Implementierung spezifiziert werden. Ein Schritt-Befehl stellt die Delta-Werte für die Komponenten eines spezifizierten Vertex-Parameters entlang einer ersten Richtung (z. B. die Richtung, die man erhält, wenn man die Vertices entlang einer gegebenen Zeile des Oberflächenabschnittes traversieren läßt) ein. Ein zweiter Schritt-Befehl stellt die Delta-Werte in ähnlicher Art und Weise entlang einer zweiten Richtung (z. B. zwischen den Spalten) innerhalb des Oberllächenabschnittes ein.
Wie oben beschrieben wurde, wird das Spezifieren von Vertex-Parameterwerten in der oben beschriebenen Art und Weise (Schritte 1934 und 1936) als globale Parameterspezifikation bezeichnet. Dies steht im Gegensatz zu der pro-Vertex- (oder lokalen) Spezifikation der Vertex- Parameterwerte, die ebenso eingesetzt werden kann. Die globale Parameterspezifikation kann in anderen Ausführungsformen unterschiedlich durchgeführt werden. Beispielsweise können Veränderungen in einem Vertex-Parameter durch ursprüngliche Werte und eine oder mehrere Gleichungen, die die Parameter relativ zu ihrer Position innerhalb der Vertex-Traversierungsordnung definieren, spezifiziert werden. Andere Techniken sind ebenso möglich. Es sei weiterhin bemerkt, daß es möglich ist, einen Oberflächenabschnitt als ein Vertex-Raster ohne die Codierung irgendwelcher global spezifizierter Parameter darzustellen. Komprimierung wird immer noch erzielt, da die Konnektivität (und somit die Netzpufferspeicherverschiebebits) implizit durch den Ausdehnungswert spezifiziert sind.
Das Verfahren 1930 beinhaltet als nächstes den Schritt 1938, in dem die GDU 1910 (oder eine andere Dekomprimierungseinheit) beginnt, auf den Strom der pro-Vertex-Daten zuzugreifen, die lokale Werte für die Vertex-Parameter beinhalten. Wie oben beschrieben wurde, impliziert in einer Ausführungsform die Spezifikation eines Ausdehnungswertes eine vorbestimmte Vertex- Traversierungsordnung. Weiterhin ist es in einer Ausführungsform vor dem Empfangen der pro- Vertex-Daten bekannt, welche Parameter für jeden Vertex spezifiziert werden. (In einer Ausführungsform wird diese Information durch Steuerbefehle, wie z. B. die unter Bezug auf die Fig. 33A- B beschriebenen, bestimmt.) Mit der bekannten Anzahl der Vertices sowie der Anzahl der Parameter pro Vertex kann der Strom der pro-Vertex-Daten genau verarbeitet werden.
Es wird ein gegebener Oberflächenabschnitt mit zwei lokal spezifizierten Parametern (Farbe und Normalen) betrachtet. Wenn es bekannt ist, daß nur zwei Parameter für jeden Vertex spezifiziert werden, kann die GDU 1910 korrekt bestimmen, daß nach dem Zugriff auf die zwei Werte an dem Beginn des Stromes der pro-Vertex-Daten nachfolgende Parameterwerte mit dem nächsten Vertex in der Vertex-Traversalordnung verknüpft sind. In solch einer Art und Weise ist die GDU 1910 in der Lage, auf lokale Parameterwerte für den ersten (oder nächsten) Vertex, der von der gegenwärtigen Vertex-Raster-Darstellung spezifiziert wird, zuzugreifen.
Der Strom der pro-Vertex-Daten kann codiert werden unter Verwendung einer Vielzahl von unterschiedlichen Techniken. In einer Ausführungsform ist jeder der Parameter in dem pro-Vertex- Strom von einer vorbestimmten Länge, was die Bereitstellung der Daten erleichtert. In einer bevorzugten Ausführungsform wird der pro-Vertex-Strom codiert unter Verwendung der Header-Body- Technik, die in der Vorgänger-Patentanmeldung des Anmelders beschrieben wurde. Allgemein gesprochen beinhalten die pro-Vertex-Daten Kopfzeilenabschnitte fester Länge, die verwendbar sind, um eine Länge eines entsprechenden Körperabschnittes variabler Länge zu bestimmen. Jedes Header-Body-Paar beinhaltet einen Datenabschnitt, der ein oder mehrere lokale Datenwerte beinhaltet. Der Datenabschnitt kann völlig in dem Header fester Länge (was einen Null-Längen- Körperabschnitt anzeigt), völlig innerhalb des Körperabschnittes oder sowohl in dem Header als auch in dem Body enthalten sein. Um eine Hochgeschwindigkeitsdekomprimierungseinheit zu implementieren, können Header- und Body-Paare in dem Datenstrom durch Header- und Body-Paare anderer Befehle getrennt sein.
Man betrachte beispielsweise die folgende Abfolge von Header-Body-Paaren: H1, B0, H2, B1, H3, B2 usw. Dies zeigt an, daß das Header-Body-Paar H1 - B1 innerhalb des pro-Vertex-Stromes durch den Body-Abschnitt des vorherigen Paares (B0) und den Header-Abschnitt des nächsten Paares (H2) getrennt ist. Dies gibt der GDU 1910 ausreichend Zeit, um die Länge des entsprechenden Body-Körpers zu bestimmen. In einer Ausführungsform wird die Länge des Körpers bestimmt durch Davorlegen des Kopfzeilenabschnittes fester Länge zu einer Dekomprimierungstabelle. (In einer Ausführungsform gibt es eine getrennte Dekomprimierungstabelle für jeden Parametertyp.) Als Antwort gibt die Dekomprimierungstabelle einen oder mehrere Dekomprimierungsparameter, die dem gegenwärtigen Header-Body-Paar entsprechen, das verarbeitet wird, zurück. Diese Dekomprimierungsparameter können die Größe des Datenabschnittes, der in dem Header-Abschnitt enthalten ist, die Länge des Körperabschnittes, ob die Werte in dem Datenabschnitt absolut oder relativ sind und einen Normalisierungskoeffizienten für die Werte in dem Datenabschnitt enthalten, sind jedoch nicht hierauf begrenzt.
Wie oben beschrieben wurde, werden verschiedene Dekomprimierungsparameter in einer Ausführungsform für jedes Kopfzeilen-Körper-Paar spezifiziert (was einen Vertex-Parameterwert für den gegenwärtigen Vertex, der verarbeitet wird, beinhaltet). In Schritt 940 werden diese Dekomprimierungsparameter und die global spezifizierten Werte verwendet, um einen finalen Vertex- Parameterwert zu erzeugen. In einer Ausführungsform kann ein finaler Vertex-Parameterwert erzeugt werden a) ausschließlich aus global spezifizierten Werten, b) ausschließlich aus dem pro- Vertex-Strom oder c) unter Verwendung einer Kombination der global spezifizierten Werte und der pro-Vertex-Daten.
Im Fall a) wird ein finaler Vertex-Parameterwert durch Anlegen der Delta-Werte auf den gegenwärtigen Arbeitswert erzeugt (der entweder der ursprüngliche Wert oder der Wert für den vorherigen Vertex ist). Im Fall b) wird der finale Parameterwert entsprechend der Art und Weise, in der der Wert codiert wurde, erzeugt. Wenn der Wert absolut spezifiziert ist, wird der Normalisierungskoeffizient (sofern es einen gibt) auf den Wert in dem Datenabschnitt angelegt, um den finalen Wert zu erzeugen. Wenn der pro-Vertex-Wert delta-codiert ist, wird der normalisierte Datenwert zu dem Wert des Parameters an dem vorherigen Vertex addiert.
In einigen Ausführungsformen kann die geometrische Komprimierung ebenso die Delta- Delta-Codierung von Werten erlauben. Dies ist nützlich, wenn ein bestimmter Vertex-Parameter sich in einer leicht unregelmäßigen Art und Weise verändert. (In vielen Fällen kann der Delta-Delta-Wert für einen bestimmten Vertex 0 sein, was effektiv anzeigt, daß das letzte Delta wieder anzuwenden ist, um den finalen Parameterwert für den bestimmten Vertex zu erzeugen.) In einer Ausführungsform wird die Verwendung des Delta-Delta-Codierens ermöglicht durch einen Steuerbefehl, wie z. B. den "SetState"-Befehl, der oben unter Bezug auf Fig. 33A erörtert wurde. In dieser Ausführungsform verändert das Einstellen des dde-Bits die Interpretation des absoluten/relativen Bits innerhalb der Dekomprimierungstabelle, was eine absolute Einstellung innerhalb einer Dekomprimierungstabelle veranlaßt, um relative (Delta-) Codierung anzuzeigen, wobei die relative Codierung nun die Delta-Delta-Codierung spezifiziert. Es sei bemerkt, daß man, um die Delta-Delta-Codierung durchzuführen, bereits einen Delta-Vektor haben sollte. Unter der Annahme eines rechtwinkligen Vertex-Rasters kann somit die Delta-Delta-Codierung nicht auf dem ersten oder den Start-Vertices durchgeführt werden. Diese werden als absolute Daten abgelegt, um als Startpunkt zu dienen. In gleicher Weise wird der zweite Vertex verwendet, um das erste Delta zu erzeugen. Somit kann das dritte Vertex der erste sein, der tatsächlich die Delta-Delta-Codierung verwendet. Da die Delta-Delta- Werte in einigen Fällen kleiner sein können als die Delta-Werte, wird die Komprimierungseffizienz durch die Verwendung dieser Technik erhöht. Um somit einen finalen Vertex-Parameter für Fall C zu erzeugen, werden der Parameterwert für den vorherigen Vertex, das vorherige Delta und der Delta- Delta-Wert für den gegenwärtigen Vertex alle addiert.
Mit den finalen Parameterwerten, die für einen bestimmten Vertex in Schritt 1940 erzeugt wurden, wird eine Bestimmung durchgeführt, ob eine Netzpufferverschiebung in Schritt 1942 durchgeführt wird. Diese Bestimmung wird gemacht unter Verwendung des vorher spezifizierten Ausdehnungswertes sowie der gegenwärtigen Vertex-Position. In einer Ausführungsform wird beispielsweise bestimmt, daß die gesamte erste Zeile der Vertices für die spätere Verwendung in den Netzpufferspeicher verschoben wird. Diese Schiebeoperation wird in Schritt 1944 durchgeführt. In einer Ausführungsform wird der Vertex und alle verknüpften Parameter in den Netzpufferspeicher verschoben.
In Schritt 1946 wird eine Bestimmung durchgeführt, ob oder ob nicht ein Grundelement zusammengestellt wird. Beispielsweise werden in einer Ausführungsform keine Grundelemente zusammengestellt, bis auf die Vertices der zweiten Zeile zugegriffen wird. Für die Vertices der ersten Zeile wird dann Schritt 1950 folgend auf Schritt 1946 durchgeführt. Wenn die Bestimmung durchgeführt wird, daß ein Grundelement zusammengestellt wird, verarbeitet das Verfahren 1930 als nächstes Schritt 1948.
In Schritt 1948 wird die Konnektivitätsinformation analysiert, um zu bestimmen, welche Vertices verwendet werden (zusätzlich zu dem gegenwärtigen Vertex), um die Zeichnungsgrundelemente zusammenzustellen. In einer Ausführungsform beinhaltet die Konnektivitätsinformation, daß das implizit durch den Ausdehnungswert sowie die Viereckaufteilungsinformation definiert wird. Es sei bemerkt, daß nach der Verarbeitung eines gegebenen Vertex eine Mehrzahl von Grundelementen gebildet werden kann. Folglich kehrt das Verfahren 1930 nach dem Ausführen des Schrittes 1948 zu dem Bestimmungsschritt 1946 zurück.
Nachdem alle Grundelemente für das gegenwärtige Vertex zusammengestellt wurden, wird eine Bestimmung in Schritt 1950 durchgeführt, ob das gegenwärtige Vertex das letzte Vertex (wie in der vorher spezifizierten Vertex-Traversierungsordnung spezifiziert ist) innerhalb des Oberflächenabschnittes ist. Wenn das gegenwärtige Vertex nicht das letzte Vertex ist, wird das nächste Vertex in Schritt 938 verarbeitet und die Ausführung des Verfahrens 1930 wird fortgesetzt. Wenn das gegenwärtige Vertex das letzte Vertex ist, schließt das Verfahren 1930 jedoch mit Schritt 1952 ab. Wenn ein Vertex-Rasterbefehl nachfolgend auf die Vollendung des Verfahrens 1930 ausgeführt wird, kann der nächste Oberflächenabschnitt durch Verwendung der Werte der globalen Parameter von dem letzten Vertex der vorherigen Rasterdarstellung verarbeitet werden und mit Schritt 1938 des Verfahrens 1930 fortgesetzt werden. Der nächste Strom von pro-Vertex-Daten kann dann, wie oben beschrieben wurde, verarbeitet werden.
Das Verfahren 1930, das oben beschrieben wurde, gibt einen generellen Überblick über eine Ausführungsform des Dekomprimierungsprozesses. Das Verfahren 1960, das in Fig. 24 gezeigt ist, stellt eine detailliertere Implementierung zur Verfügung, die sowohl die implizite als auch die explizite Konnektivitätsinformation handhabt. Das Verfahren 1960 wird als erstes unter Bezug auf den in Fig. 26 dargestellten Oberflächenabschnitt 1300 beschrieben, in dem die Vierecke, die von benachbarten Vertices gebildet werden, alle in der gleichen (vorgegebenen) Richtung aufgeteilt werden. Aus Zwecken des folgenden Beispiels wird angenommen, daß die Vertex-Traversierungsordnung diejenige in Fig. 29 ist (beginnend von der unteren linken Ecke). Folglich können die Vertex- Zahlen, die in folgenden Beispielen verwendet werden, aus Fig. 29 verstanden werden. Zum Beispiel ist Vertex 2 der mittlere Vertex auf der unteren Zeile in jedem der unten gegebenen Beispiele. Es sei bemerkt, daß viele andere Vertex-Traversierungsordnungen ebenso möglich sind. Es sei weiterhin bemerkt, daß innerhalb des Verfahrens 1960 jede der Prozeduren für die Erzeugung von finalen Parameterwerten eingesetzt werden kann.
Fig. 43 beschreibt die Idee der Bildung eines Grundelements. Unter Bezug auf Fig. 44 wird ein Grundelement betrachtet, das zu bilden ist, wenn alle seine Vertices "gezeichnet" sind (zu den Einheiten 1920 für die Verarbeitung geleitet sind). In einer Ausführungsform diktieren die Ersetzungscodes, wie z. B. diejenigen, die in dem verallgemeinerten Dreiecksstreifenformat verwendet werden, wie gezeichnete Vertices kombiniert werden, um Dreiecksgrundelemente zu bilden.
Ausgehend von dem ursprünglichen Zustand 1962 fährt das Verfahren 1960 mit Schritt 1964 fort, in dem auf einen Vertex und seine verknüpften Parameter aus dem komprimierten Geometriestrom 1904 von der GDU 1910 zugegriffen wird. Für die erste Zeile der Vertices in dem Oberflächenabschnitt 1300 (Vertices 0-4) werden alle Vertex-Parameterwerte in den Netzpufferspeicher 1912 in Schritt 1966 verschoben. Diese Vertices werden jedoch nicht gezeichnet, was anzeigt, daß keine Grundelemente gebildet wurden. Eine Bestimmung wird in Schritt 1968 dahingehend durchgeführt, ob das gegenwärtige Vertex das letzte Vertex der ersten Zeile ist. Wenn das gegenwärtige Vertex nicht das letzte Vertex der ersten Zeile ist, kehrt das Verfahren 1960 zu Schritt 1964 zurück und verarbeitet das nächste Vertex.
Wenn das gegenwärtige Vertex an dem Ende der ersten Zeile ist, wird jedoch auf das erste Vertex der gegenwärtigen Zeile (Vertex 0 in Fig. 29) von dem Netzpufferspeicher 1912 zugegriffen und wird in Schritt 1970 gezeichnet. Die Attribute dieses Vertex werden als nächstes in die GDU 1910 der Register in Schritt 1972 geladen. Diese geladenen Werte werden verwendet, sofern sie benötigt werden, um Parameterwerte des ersten Vertexes der nächsten Zeile (Vertex 5) zu berechnen, auf die in Schritt 1974 zugegriffen wird. Die Parameter des Vertex 5 werden ebenso in den Netzpufferspeicher 1912 verschoben und dann in Schritt 1974 gezeichnet.
In Schritt 1976 wird eine Bestimmung dahingehend durchgeführt, ob ein Viereckaufteilungsbit für das gegenwärtige Viereck innerhalb des komprimierten Geometriestroms gesetzt ist. In einer Ausführungsform zeigt ein nicht ausgeübtes Quad-Aufteilungsbit an, daß ein Viereck tesselliert werden sollte in der Vorgaberichtung (obere rechte Ecke zu unterer linker). Wenn dieses Bit jedoch gesetzt ist, wird das Viereck von der oberen linken Ecke zu der unteren rechten hin aufgeteilt. Wenn ein Viereckaufteilungsbit nicht spezifiziert ist, dann wird in einer Ausführungsform das Viereck in einer vorbestimmten Vorgaberichtung aufgeteilt.
in einer Ausführungsform einer Vertex-Rasterdarstellung des Oberflächenabschnittes 1300 sind keine Viereckaufteilungsbits gesetzt. Folglich fährt das Verfahren 1960 mit Schritt 1978 fort, in dem auf die Parameter des nächsten Vertexes der gegenwärtigen Zeile (Vertex 6) zugegriffen wird. Diese Parameter werden in den Netzpufferspeicher 1912 verschoben und das Vertex wird in Schritt 1980 gezeichnet. Ein erstes Dreieckgrundelement innerhalb des Oberflächenabschnittes 1300 wird nun mit den Vertices 0, 5 und 6, die alle gezeichnet sind, gebildet. Das nächste Dreiecksgwndelement wird in Schritt 1982 gebildet, in dem das nächste Vertex der vorherigen Zeile (Vertex 1) gezeichnet ist. Diese Schritte bilden effektiv das Grundelement, das durch die Vertices 5, 6 und 1 definiert ist.
In Schritt 1990 wird das gegenwärtige Vertex überprüft, um zu bestimmen, ob es das letzte Vertex in der gegenwärtigen Zeile ist. Wenn das Vertex nicht das letzte in der gegenwärtigen Zeile ist, kehrt das Verfahren 1960 zu Schritt 1976 zurück, um das nächste Viereckaufteilungsbit zu überprüfen. Das Verfahren 1960 setzt, wie oben beschrieben wurde, fort, und bildet die verbleibenden Dreiecksgrundelemente zwischen den unteren zwei Reihen von Vertices. Wenn das letzte Vertex in der zweiten Zeile in Schritt 1990 erfaßt wird, wird eine weitere Überprüfung in Schritt 1992 durchgeführt, um zu bestimmen, ob das gegenwärtige Vertex das letzte in dem Oberflächenabschnitt ist. Falls dies in diesem Beispiel nicht der Fall ist, setzt das Verfahren 1960 mit Schritt 1970 fort, in dem auf das erste Vertex der gegenwärtigen Zeile (Vertex 5) von dem Netzpufferspeicher 1912 zugegriffen wird und es wird (erneut) gezeichnet. Dann wird das Vertex 10 der dritten Reihe in Schritt 1974 gezeichnet. Das Viereckaufteilungsbit für diesen Vertex wird in Schritt 1976 überprüft und die Formation der Dreiecksgrundelemente wird wie oben beschrieben fortgesetzt. Das Verfahren 1960 ist schließlich in Schritt 1994 beendet, wenn Vertex 24 in Schritt 1992 erfaßt wird.
Als nächstes wird das Verfahren 1960 unter Verwendung des Oberflächenabschnittes 1700 als Eingang beschrieben. Das Verfahren 1960 beginnt, wie oben beschrieben wurde, unter Zugriff auf die Vertex-Parameterwerte für die Vertices 0-4 und unter Verschieben dieser Werte in den Netzpufferspeicher 1912 in den Schritten 1964 bis 1966. Wenn Vertex 4 in Schritt 1968 erfaßt wird, wird Vertex 0 von dem Netzpufferspeicher 1912 in Schritt 1970 wiedergewonnen. Es wird dann auf die Attribute von Vertex 5 von dem Strom 1904 zugegriffen und sie in Schritt 1976 gezeichnet. Bislang entsprechen die Schritte für den Oberflächenabschnitt 1700 denjenigen, die für den Oberflächenabschnitt 1300 genommen wurden, wobei die Vertices 0 und 5 beide gezeichnet werden.
Da das Viereckaufteilungsbit für das erste Viereck in dem Oberflächenabschnitt 1700 aufgeteilt ist, setzt jedoch das Verfahren 1960 als nächstes mit Schritt 1984 fort, in dem auf den nächsten Vertex der vorherigen Reihe (Vertex 1) von dem Netzpuffer 1912 zugegriffen wird und es gezeichnet wird. Dies bildet ein Dreieck, das durch die Vertices 0, 5 und 1 gebildet wird. In Schritten 1986 und 1988 wird aus den Vertices 5, 1 und 6 ein zweites Dreieck gebildet. Das Verfahren 1960 kehrt dann zu Schritt 1976 zurück, wo das nächste Viereckaufteilungsbit überprüft wird. Basierend auf dem Ergebnis dieser Bestimmung werden zwei weitere Dreiecke gebildet und das Verfahren kehrt zu Schritt 1976 zurück. Wenn alle Dreiecke für die gegenwärtige Reihe gebildet sind, kehrt das Verfahren 1960 zu Schritt 1970 zurück. Die Dekomprimierung des Restes des Oberflächenabschnittes 1700 setzt, wie oben beschrieben wurde, fort.
Fig. 45 stellt ein Verfahren für die Dekomprimierung eines Oberflächenabschnittes dar, in dem eine untere Kante als half-rez bezeichnet wird (wie oben unter Bezug auf Fig. 39 beschrieben wurde). Ein Beispiel solch eines Oberflächenabschnittes ist der Abschnitt 1800D in Fig. 40D. Wie in Fig. 40D dargestellt ist, werden einige Vertices auf einer half-rez-Kante nicht verwendet bei der Bildung von irgendeinem Dreiecksgrundelement innerhalb des Oberflächenabschnittes 1800D. Das Verfahren 2000, das in Fig. 45 gezeigt ist, trägt dieser Tatsache Rechnung.
Von dem ursprünglichen Zustand 2002 setzt das Verfahren 2000 in Schritt 2004 fort, in dem auf den ersten Vertex (Vertex 0) von dem Strom 1904 zugegriffen wird. Der Vertex 0 und seine Attribute werden in dem Netzpuffer 1912 in Schritt 2006 verschoben. Auf den Vertex 1 und die verknüpften Parameter wird in Schritt 2008 zugegriffen. Da der Vertex 1 nicht für die Dreiecksbildung verwendet wird, werden die Attribute, auf die in Schritt 2008 zugegriffen wird, nicht verwendet. Trotz der Tatsache, daß diese Attribute nicht verwendet werden, wird eine Dummy-Verschiebung in dem Netzpufferspeicher in Schritt 2010 durchgeführt. Dies wird so gemacht, daß nachfolgende Reihen auf den Netzpufferspeicher 1912 in derselben Art und Weise zugreifen können, egal, ob die untere Kante in dem half-rez-Modus dargestellt wird oder nicht.
In den Schritten 2012 bis 2014 werden der Vertex 2 und seine Attribute von dem Strom 904 abgefragt und in den Netzpufferspeicher 1912 verschoben. Da der Vertex 2 nicht der letzte Vertex in der Reihe ist, kehrt das Verfahren 2000 zu Schritt 2008 zurück. Dies führt dazu, daß das Vertex 3 einer Dummy-Position in dem Netzpufferspeicher 1912 zugewiesen wird und daß die Attribute des Vertex 2 in eine "tatsächliche" Position innerhalb des Netzpufferspeichers 1912 verschoben sind.
An diesem Punkt werden die Vertices 0-4 in den Netzpufferspeicher 1912 verschoben mit entweder einem Platzhalter oder tatsächlichen Einträgen. Das Verfahren 2000 setzt als nächstes mit den Schritten 2018 bis 2020 fort, indem auf den Vertex 0 von dem Netzpufferspeicher 1912 zugegriffen wird und dieser gezeichnet wird. In Schritt 2022 wird auf den Vertex 5 von dem Strom 1904 zugegriffen, dieser gezeichnet und in den Netzpufferspeicher 1912 verschoben. Als nächstes wird auf den Vertex 6 zugegriffen, dieser gezeichnet und in Schritt 2024 verschoben. Dies vervollständigt die Bildung des Dreiecksgrundelements, das durch die Vertices 0, 5 und 6 gebildet wird.
Das Verfahren 2000 setzt mit Schritt 2026 fort, in dem das nächste Vertex von der vorherigen Reihe, dessen Attribute nicht fallengelassen wurden, gezeichnet wird. Dies entspricht dem Vertex 2, da Vertex 1 nicht in der Dreiecksbildung verwendet wird. Dieser Schritt vervollständigt ebenso die Bildung des Dreiecks, das durch die Vertices 0, 2 und 6 gebildet wird. (Diese Vertices werden statt den drei zuletzt gezeichneten Vertices verwendet, da die half-rez-Kanten zu "Stern"- Dreiecksstreifen korrespondieren. Diese Formationen werden in den verallgemeinerten Dreiecksstreifenformat gezeichnet unter Verwendung des "ersetze-mittleres-Vertex"-Kommandos.) Als nächstes wird in Schritt 2028 auf das nächste Vertex von der gegenwärtigen Reihe (Vertex 7) zugegriffen, dieses verschoben und gezeichnet, wobei ein Grundelement aus den Vertices 6, 2 und 7 gebildet wird.
In Schritt 2030 wird eine Bestimmung durchgeführt, daß das Ende der Reihe nicht erreicht wurde. Das Verfahren 2000 setzt somit mit Schritt 2024 fort. Die Schritte 2024 bis 2028 wiederholen sich, wobei drei Grundelemente unter Verwendung der Vertex-Gruppen (2, 7, 8), (2, 8, 4) bzw. (8, 4; 9) gebildet werden. Mit der ersten Reihe von gezeichneten Grundelementen setzt das Verfahren 2000 sich ausführende Schritte 1970 bis 1994 des Verfahrens 1960 fort, bis das letzte Vertex des Oberflächenabschnittes 1800D erreicht wird.
Das Verfahren 2000 ist verwendbar, um die Dekomprimierung auf einem regelmäßig gekachelten Oberflächenabschnitt durchzuführen, in dem die untere Kante in halber Auflösung dargestellt wird. Die Dekomprimierung von Oberflächenabschnitten, in denen andere Kanten in halber Auflösung dargestellt werden, wird in ähnlicher Weise durchgeführt. Es sei bemerkt, daß in alternativen Ausführungsformen die Viereckaufteilungsbits und die half-rez-Kanten unterschiedlich verarbeitet werden können.
Obgleich das System und das Verfahren der vorliegenden Erfindung im Zusammenhang mit den beschriebenen Ausführungsformen erläutert wurde, ist es nicht beabsichtigt, auf die hier ausgeführten spezifischen Formen begrenzt zu werden, sondern im Gegenteil ist es beabsichtigt, solche Alternativen, Modifikationen und Äquivalente abzudecken, wie sie vernünftig in dem Schutzbereich der Erfindung, wie er durch die angefügten Ansprüche definiert wird, beinhaltet sind.

Claims

1. Verfahren zum Komprimieren dreidimensionaler (3D) geometrischer Daten, weiche ein oder mehrere 3D-Objekte repräsentieren, mit:

Untersuchen der geometrischen 3D-Daten, um das Vorhandensein von regelmäßig in Felder aufgeteilten Oberflächenbereichen zu erfassen, und Komprimieren der geometrischen 3D-Daten durch:

Codieren jeglicher regelmäßig in Felder aufgeteilter Oberflächenbereiche unter Verwendung eines ersten Codierverfahrens, und

Codieren jeglicher unregelmäßig in Felder aufgeteilter Oberflächenbereiche unter Verwendung eines zweiten Codierverfahrens, wobei das zweite Codierverfahren sich von dem ersten Codierverfahren unterscheidet.

2. Verfahren nach Anspruch 1, wobei das erste Codierverfahren die regelmäßig in Felder aufgeteilten Oberflächenbereiche als Vertex-Raster codiert und weiches weiterhin das Codieren eines Erweiterungswertes für jeden regelmäßig in Felder aufgeteilten Oberflächenbereich aufweist, wobei die Erweiterungswerte jeweils eine Anordnung von zu komprimierenden Vertices definiert.

3. Verfahren nach Anspruch 2, wobei das zweite Codierverfahren die unregelmäßig in Felder aufgeteilten Oberflächen als ein verallgemeinertes Dreiecksnetz codiert.

4. Verfahren nach einem der Ansprüche 1 bis 3, wobei das erste Codierverfahren weiterhin das Spezifizieren von Anfangswerten für ausgewählte interpolierbare Parameter für die regelmäßig in Felder aufgeteilte Oberfläche und das Spezifizieren von Delta-Werten (Differenzwerten) aufweist, welche anzeigen, wie die ausgewählten interpolierbaren Parameter über die regelmäßig in Felder aufgeteilte Oberfläche hinweg variieren.

5. Verfahren nach Anspruch 4, wobei das erste Codienrerfahren weiterhin das Spezifizieren von Information pro Vertex für die Vertices aufweist, die von den angegebenen Delta-Werten bzw. Differenzwerten abweichen.

6. Verfahren nach Anspruch 5, wobei das erste Codierverfahren weiterhin das Spezifizieren von Information pro Vertex für die Vertices aufweist, die nicht von den spezifizierten Delta-Werten abweichen, jedoch zusätzliche Information haben, welche durch die Delta-Werte nicht repräsentiert wird, wobei jeder der Vertex-Parameterwerte aus der Gruppe ausgewählt wird, die besteht aus:

Information über die Position, die Normale, die Farbe, die Textur, das Material und die Beleuchtung.

7. Verfahren nach einem der Ansprüche 1 bis 6, welches weiterhin das Einbetten von Operationscodes innerhalb der komprimierten geometrischen 3D-Daten umfaßt, welche anzeigen, ob eine folgende Vertex oder Oberfläche unter Verwendung des ersten Codierverfahrens oder des zweiten Codierverfahrens codiert ist.

8. Verfahren nach Anspruch 7, wobei die Operationscodes jeweils einen Kopfteil und einen Hauptteil aufweisen, wobei der Kopfteil einen Anhänger variabler Länge aufweist, der Längeninformation über die Operationscodes bereitstellt.

9. Verfahren nach einem der Ansprüche 1 bis 8, wobei die Untersuchung das Erfassen von Mehrzahlen von Vertices aufweist, die oberhalb einer vorbestimmten Größe liegen, wobei zumindest ein Vertex-Parameter sich innerhalb eines vorbestimmten Toleranzbereiches in vorhersagbarer Weise verändert.

10. Verfahren nach einem der Ansprüche 1 bis 9, wobei das Untersuchen das Erfassen von Mehrzahlen von Vertices oberhalb einer vorbestimmten Größe aufweist, die zumindest einen Vertex- Parameter gemeinsam haben, welcher zu einer Delta- oder Delta-Delta-Codierung mit einem vorbestimmten maximalen Delta oder Delta-Delta in der Lage ist.

11. Verfahren nach einem der Ansprüche 1 bis 10, welches weiterhin aufweist:

Aufnehmen der geometrischen 3D-Daten,

Codieren von Verbindungsfähigkeitsinformation für einen ersten Teil der geometrischen 3D- Daten unter Verwendung des ersten Kompressionsverfahrens,

Codieren von Verbindungsfähigkeitsinformation für einen zweiten Bereich der geometrischen 3D-Daten unter Verwendung des zweiten Kompressionsverfahrens,

Codieren von Vertex-Parameterwerten für den ersten Bereich und den zweiten Bereich der geometrischen 3D-Daten unter Verwendung eines dritten Kompressionsverfahrens, und

Speichern der codierten Verbindungsfähigkeitsinformation für den ersten Bereich der geometrischen 3D-Daten, der codierten Verbindungsfähigkeitsinformation des zweiten Bereiches der geometrischen 3D-Daten und der codierten Vertex-Parameter des ersten Bereiches und des zweiten Bereiches der geometrischen 3D-Daten.

12. Verfahren zum Komprimieren geometrischer 3D-Daten, welche ein oder mehrere 3D-Objekte repräsentieren, mit:

Untersuchen der geometrischen 3D-Daten, um das Vorhandensein von Oberflächenbereichen zu erfassen, welche regelmäßig auftretende Gruppen von unregelmäßigen Vertices aufweisen, und

Komprimieren der geometrischen 3D-Daten durch:

Codieren der regelmäßig auftretenden Gruppen unregelmäßiger Vertices unter Verwendung eines ersten Codierverfahrens und

Codieren der verbleibenden geometrischen 3D-Daten unter Verwendung eines zweiten Codierverfahrens, wobei das zweite Codierverfahren von dem ersten Codierverfahren verschieden ist.

13. Verfahren nach Anspruch 12, welches weiterhin aufweist:

Untersuchen der geometrischen 3D-Daten, um das Vorhandensein von Oberflächenbereichen zu erfassen, die unregelmäßig auftretende Gruppen regelmäßiger Vertices haben, und

Komprimieren der geometrischen 3D-Daten durch:

Codieren der Gruppen von regelmäßigen Vertices unter Verwendung eines ersten Codierverfahrens, und

Codieren der verbleibenden Vertices unter Verwendung eines zweiten Codierverfahrens, wobei das zweite Codierverfahren sich von dem ersten Codierverfahren unterscheidet.

14. Verfahren nach einem der Ansprüche 1 bis 13, welches weiterhin das Übermitteln der komprimierten Daten über ein Netzwerk aufweist.

15. Verfahren nach einem der Ansprüche 1 bis 14, welches weiterhin das Speichern der komprimierten geometrischen 3D-Information auf einem computerlesbaren Medium für die Verteilung und weitere Decodierung aufweist.

16. Verfahren zum Dekomprimieren komprimierter geometrischer 3D-Daten, welche eines oder mehrere 3D-Objekte repräsentieren, wobei das Verfahren aufweist:

Aufnehmen der komprimierten geometrischen 3D-Daten und

Decodieren von Bereichen der komprimierten geometrischen 3D-Daten, welche regelmäßig in Felder aufgeteilten Oberflächenbereichen entsprechen, unter Verwendung eines ersten Codier- bzw. Decodierverfahrens, und

Decodieren von Bereichen der komprimierten geometrischen 3D-Daten, welche unregelmäßig in Felder aufgeteilten Oberflächenbereichen entsprechen, unter Verwendung eines zweiten Codier- bzw. Decodierverfahrens, wobei das zweite Codier- bzw. Decodierverfahren sich von dem ersten Codier- bzw. Decodierverfahren unterscheidet.

17. Softwareprogramm, welches auf einem Trägermedium verkörpert bzw. abgelegt ist, wobei das Computersoftwareprogramm eine Mehrzahl von Befehlen aufweist, die dafür ausgelegt sind, das Verfahren nach einem der Ansprüche 1 bis 16 zu implementieren.