DE60004827T2

DE60004827T2 - Segmentierung von komprimierten graphischen daten zur parallelen dekomprimierung und darstellung

Info

Publication number: DE60004827T2
Application number: DE60004827T
Authority: DE
Inventors: F. Michael DEERING
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1999-06-14
Filing date: 2000-06-09
Publication date: 2004-06-17
Anticipated expiration: 2020-06-10
Also published as: US6559842B1; ATE248410T1; EP1185958A1; WO2000077738A1; EP1185958B1; DE60004827D1; AU5600400A; US6459429B1

Description

Technisches Gebiet der Erfindung
Die vorliegende Erfindung betrifft Computergraphiksysteme und insbesondere die Dekomprimierung und Darstellung von komprimierten dreidimensionalen Geometriedaten.
Beschreibung des relevanten Standes der Technik In den letzten Jahren hat sich die Anforderung an Graphiksysteme hoher Leistung, die komplexe dreidimensionale (3D) Objekte und Szenen darstellen können, wesentlich erhöht. Dieser Anstieg erfolgte zumindest teilweise aufgrund neuer Anwendungen, wie z. B. der computererzeugten Animation von bewegten Bildern, Simulatoren/Trainern mit virtueller Realität und interaktiven Computerspielen. Diese neuen Anwendungen stellen gewaltige Anforderungen an graphische Systeme. Ein Gebiet, in dem besonders hohe Anforderungen an Graphiksysteme gestellt werden, ist die Bandbreite. Dies liegt daran, daß 3D-Graphikdaten einige Größenordnungen in der Größe größer als vergleichbare 2D-Graphikdaten sein können. Beispielsweise können einfache 2D-Grafikdaten einfach die Farbinformation für jedes angezeigte Pixel enthalten. Im Gegensatz dazu können 3D-Graphikdaten die x, y, z-Positions-Information, die Normalen-Information, die Farb-Information, die Transparenz-Information, die Texturabbildungs-Information, die Reflektivitäts-Information und zusätzliche Information enthalten. Diese Information wird hier gemeinsam als „Vertexkomponenten-Information" bezeichnet.
Eine Anzahl von unterschiedlichen Techniken wurden vorgeschlagen, um die Bandbreitenanforderungen von 3D-Graphikdaten zu reduzieren. Eine solche Technik ist als geometrische Komprimierung bekannt. Ein Typ der geometrischen Komprimierung ist im Detail beschrieben in dem US-Patent Nr. 5,793,371, das am 11. August 1998 mit dem Titel „Method and Apparatus for Geometric Compression of Three-Dimensional Graphics Data" für Michael F. Deering ausgestellt wurde. Allgemein gesprochen beruht die geometrische Komprimierung auf der erneuten Verwendung von Vertices (unter anderen Techniken), um die Größe der 3D-Graphikdaten zu reduzieren. Um ein 3D-Objekt zu beschreiben, werden eine Anzahl von Punkten (Vertices genannt) spezifiziert. Jedes Vertex kann eine Anzahl von Attributen haben, die mit ihm verknüpft sind. Beispielsweise kann jeder Vertex eine Farb-Information haben, die mit ihm verknüpft ist. Andere Attribute, die mit Vertices verknüpft sein können, sind Texturabbildungskoordinaten, Normalen-, Farb- und Transparenz-Information. Wenn beispielsweise eine Murmeltextur auf einer Kugel mittels Textur abgebildet wird, kann jeder Vertex auf der Kugel eine Texturabbildungskoordinate haben, die spezifiziert, wie die Textur angewendet werden sollte (d.h. welcher Teil der Beispieltextur auf dieses bestimmte Vertex abgebildet werden sollte). Eine Normale ist ein Vektor, der von dem Vertex ausgeht und rechtwinklig zu der Oberfläche des Objektes an dem Vertex verläuft. Dies wird in dem 3D-Objekt von 1 illustriert. Das 3D-Objekt kann durch eine Anzahl von Vertices (als Punkte in der Figur dargestellt) dargestellt werden. Normalen für das Objekt werden durch Teile dargestellt, die sich rechtwinklig von der Oberfläche des Objektes an jedem Vertexpunkt erstrecken.
Normalen sind Vektoren oder Richtungen im dreidimensionalen Raum. Im Kontext der 3D-Graphik können Normalen (ebenso als Oberflächennormalen bezeichnet) jeweils die lokale Orientierung der Oberfläche eines 3D-Graphikobjektes anzeigen. Da der Startpunkt des Vektors aus den xyz-Koordinaten des Vertex bekannt ist, kann die Normale mit einer x-Komponente, einer y-Komponente und einer z-Komponente (bezeichnet als Nx, Ny bzw. Nz) spezifiziert werden. In manchen Ausführungsformen können diese Komponenten relativ zu dem Vertex spezifiziert werden. Diese Ausführungsform wird in 2 dargestellt. Es sind jedoch ebenso andere Formen für die Spezifizierung von Normalen möglich. Darüber hinaus sind in einigen Implementierungen die Normalkomponenten selbst normalisiert. Eine normalisierte Normale ist eine, in der die Summe der Quadrate von Nx, Ny und Nz gleich einer konstanten Eins ist.
In 3D-Graphiken sind die Vertices typischerweise zusammen gruppiert, um Polygone zu bilden, wie z. B. Dreiecke, wie in 3 gezeigt ist. Definitionsgemäß hat ein Dreieck drei Vertices. Dreiecke verwenden jedoch häufig Vertices gemeinsam. In 3 bilden die Vertices 1-2-3 ein erstes Dreieck und die Vertices 2-3-4 bilden ein zweites Dreieck. Somit werden die Vertices 2 und 3 von den beiden Dreiecken gemeinsam verwendet. 3D-Objekte können dargestellt werden durch Spezifizieren einer Anzahl von Dreiecken. Dies ist in 4 gezeigt.
Das Spezifizieren aller Information, die mit jedem Vertex verknüpft ist (z. B. xyz-Ort, Farbe, Normale usw.) jedesmal, wenn auf einen Vertex als Teil eines Dreiecks bezug genommen wird, ist nicht effizient. Statt dessen kann die Information über einen Vertex gespeichert werden (z. B. wenn sie das erstemal übertragen wird) für die spätere Verwendung. Wenn dann der Vertex für ein anderes Dreieck wieder benötigt wird, kann der Vertex aus dem Speicher gelesen werden, statt daß er erneut übertragen werden muß. Die Vertex-Information kann in einem „Netzpufferspeicher" gespeichert werden und dann wiederverwendet werden. Dies kann mit Vorteil die Menge der Information reduzieren, die übertragen werden muß, und kann somit Bandbreite einsparen. Dies ist in 5 dargestellt.
Um Vertices effizient wiederzuverwenden, können die Dreiecke in ein Netz organisiert sein (z. B. eine vorbestimmte Anzahl von benachbarten Vertices). Das Netz kann dann als ein oder mehrere „Dreiecksstreifen" codiert werden. Beispielsweise kann in 6 der Anmeldung der Dreiecksstreifen mit den folgenden Dreiecken beginnen: 6, 1, 7; 1, 7, 2; 7, 2, 3; 7, 3, 4; 7, 4, 8; 4, 8, 5 usw.
Wie dieses Muster zeigt, können, sobald der Dreiecksstreifen gestartet ist, viele nachfolgenden Dreiecke spezifiziert werden unter Verwendung nur eines einzelnen neuen Vertex. Nachdem beispielsweise das Dreieck 6, 1, 7 konstruiert wurde, kann das Dreieck 1, 7, 2 konstru iert werden unter Verwendung nur einem neuen Vertex (d.h. von Vertex 2). Somit kann jedes Vertex in dem Dreiecksstreifen von 1/3 Dreieck bis zu einem Dreieck beschreiben. Beispielsweise beschreibt in der obigen Liste Vertex 6 ein Drittel des Dreiecks 6, 1, 7. Das Vertex 2 beschreibt ein Dreieck 1, 7, 2. In einigen Fällen kann ein Vertex zwei oder mehr Dreiecke beschreiben.
Während eine Anzahl von unterschiedlichen Formaten möglich ist, kann ein Typ eines generalisierten Dreiecksstreifens wie folgt definiert werden (das 3D-Objekt von 6 codierend):
In der obigen Notation ist R ein Neustartanzeiger (der anzeigt, daß ein neues Netz beginnt), O bezeichnet das Ersetzen des Ältesten und M bezeichnet das Ersetzen des Mittleren. Die Operation dieses Typs von generalisiertem Dreiecksstreifen ist in den 7A-7H dargestellt.
In einigen Ausführungsformen können die Begriffe „Ältestes" und „Mittleres" als drei Register darstellend visualisiert werden, die verwendet werden bei der Bildung von Dreiecken aus der Dreiecksstreifen-Darstellung. Die beispielhafte Codierung von oben ist lediglich eine Nomenklatur, die verwendet werden kann, um darzustellen, wie die Vertices des Netzes codiert werden. Andere Implementierungen können andere Nomenklaturen verwenden. Die Beispielnomenklatur verwendet Buchstaben (O und M), um anzuzeigen, welches Vertex aus den drei Registern verworfen werden sollte, wenn ein neues Dreieck gebildet wird. 0 zeigt an, daß das älteste Vertex verworfen werden sollte. M zeigt an, daß das mittlere Vertex verworfen werden sollte. R zeigt an, daß ein Abschnitt des Netzes gestartet wird. Dies wird verwendet, um das älteste, das mittlerste und das neueste Register und Netzpufferspeicher zu löschen, falls gewünscht.
Während dieses Verfahren Vertices wiederverwendet, wird, wenn auf das Vertex 8 ein zweites mal (durch den Befehl O8) Bezug genommen wird, das Vertex erneut übertragen. Diese erneute Übertragung der Vertices kann reduziert oder vollkommen verhindert werden durch Verwendung eines Netzpufferspeichers.
Unter Verwendung einer ähnlichen Nomenklatur wie in dem vorherigen Beispiel kann ein verallgemeinertes Dreiecksnetz, das einen Netzpufferspeicher verwendet, wie folgt definiert werden (erneut das 3D-Objekt von 6 codieren):
In dieser Implementierung bedeutet ein rechtsstehender Buchstabe „p" „schiebe in den Netzpufferspeicher". Die Zahl, die einem Großbuchstaben folgt, ist eine Vertexzahl und eine negative Zahl ist die Netzpufferspeicherreferenz, in der „1" das zuletzt verschobene Vertex bedeutet.
Somit kann die geometrische Kompression explizit alte Vertices (z. B. die obigen Vertices mit einem rechtsstehenden Buchstaben „p") in einen Netzpufferspeicher verschieben. Auf diese alten Vertices kann explizit bezug genommen werden, wenn das alte Vertex erneut benötigt wird. Dieser Ansatz stellt eine Feinsteuerung zur Verfügung, die unregelmäßige Netze von nahezu jeglicher Form unterstützt. Der Begriff „Netzpufferspeicher", so wie er hier verwendet wird, soll sich auf diese Warteschlange beziehen und der Ausdruck „generalisiertes Dreiecksnetz" soll sich auf eine Kombination von generalisierten Dreiecksstreifen und Netzpufferspeicherbezugnahmen beziehen.
Die 8A-8N stellen eine Ausführungsform dieses Verfahrens graphisch dar. Der Netzpufferspeicher kann verwendet werden, um bestimmte Vertices (d.h. diejenigen, die von einem „p" gefolgt werden) zu speichern. Diese Vertices können später aus dem Netzpufterspeicher ausgelesen werden (z. B. durch eine Bezugnahme mit einem Minuszeichen, wie z. B. „M-3"). Dies erlaubt es, daß Vertices von dem Netzpufterspeicher wiederverwendet werden können anstelle daß sie erneut übertragen werden müssen.
Wie vorher bemerkt wurde, kann durch Reduzieren der Größe der 3-D-Graphikdaten Bandbreite eingespart werden. Wenn beispielsweise Programmierer ein 3D-virtuelles Objekt, das in einer Simulation verwendet werden soll, kreieren, können sie ein Komprimierungsprogramm ausführen, um zu bestimmen, wie das 3D-Objekt am besten zu komprimieren ist. Das Komprimierungsprogramm kann tesselieren (in ein Mosaik aufteilen) oder die Oberfläche des Objekts in eine Mehrzahl von Vertices aufteilen, z. B. ein NURBs-(nicht gleichförmiger rationaler B-Spline)Objekt. Das Komprimierungsprogramm kann dann die Vertices in Gruppen von generalisierten Dreiecksnetzen aufteilen, wie oben beschrieben wurde. Diese Netze können dann komprimiert und codiert werden unter Verwendung eines zu dem oben beschriebenen Prozeß ähnlichen Prozeß. Die komprimierten Daten können dann gespeichert (z. B. auf einer CD-ROM oder DVD-ROM) und/oder übertragen (z. B. über das Internet) werden. Die Bandbreitenersparnisse können ebenso auf Busse angewendet werden, die verwendet werden für die Übertragung der 3D-Geometriedaten innerhalb des Graphiksystems selbst.
9 stellt eine Ausführungsform eines Graphiksystems 20 dar, das derart konfiguriert ist, daß es komprimierte 3D-Geometriedaten in generalisierten Dreiecksnetzform benutzt. In dieser Ausführungsform wird die Übertragungsbandbreite über dem Übertragungsmedium 10 eingespart durch Übertragen von 3D-Graphikdaten in komprimierter Form unter Verwendung der Geometriekomprimierung im allgemeinen Dreiecksnetzformat.
Im allgemeinen werden komprimierte 3D-Geometriedaten zu dem Graphiksystem 20 auf dem Eingangsbus 10 übermittelt. Der geometrische Dekomprimierer 12 empfängt die komprimierten Daten und dekomprimiert sie. Ein Netzpufferspeicher 14 kann verwendet werden, um die Vertices zu speichern, die wiederverwendet werden. Wie vorher beschrieben wurde, können die Netzpufferspeicherreferenzen innerhalb der komprimierten Daten codiert werden, um anzuzeigen, welche Vertices wiederverwendet werden und somit in dem Netzpufferspeicher gespeichert werden sollten.
Sobald ein geometrisches Grundelement, wie z. B. ein Dreieck, decomprimiert wird, wird es zu einem einer Mehrzahl von Transformations- und Beleuchtungsprozessoren 18A-N übertragen. Die Transformations- und Beleuchtungs- bzw. Helligkeitsprozessoren arbeiten unabhängig und parallel, um die folgenden Funktionen durchzuführen: (a) Transformieren der Vertices, die ein Grundelement bilden, von ihrem ursprünglichen Koordinatenreferenzeinzelbild (z. B. Objektraum) in ein gemeinsames Referenzeinzelbild (z. B. Weltraum oder Schirmraum) und (b) „Beleuchten" jedes Vertex durch Bestimmen, welche Lichtquellen jedes Vertex beeinflussen und wie stark sie beeinflußt werden.
Als nächstes werden die transformierten und beleuchteten Dreiecke zu dem Zeichenprozessor 22 geleitet, der derart konfiguriert ist, daß er die transformierten und beleuchteten Grundelemente darstellt und Texturabbildung (z. B. von dem Texturabbildungsspeicher 24) anwendet. In einigen Ausführungsformen können Texturen statt dessen während des Beleuchtungsprozesses (gemeinsam als ein „shading" bezeichnet) unter Verwendung eines programmierbaren Shaders angewendet werden. In einigen Ausführungsformen werden, wenn das Shading bzw. das Abschatten verwendet wird, nur Mikropolygone gezeichnet. Der Zeichenprozessor 22 ist derart konfiguriert, daß er die Grundelemente in den Einzelbildpufferspeicher 28 rastert. In den meisten Ausführungsformen wird der Einzelbildpufferspeicher 28 doppelt puffergespeichert, wobei ein Pufferspeicher von dem Zeichenprozessor 22 eingezogen wird, während der zweite Pufferspeicher durch die DACs 30 ausgelesen wird. Die DACs 30 können den Einzelbildpufferspeicher 28 asynchron in bezug auf den Zeichenprozessor 22 auslesen. Die DACs 30 bilden ein Ausgangsvideosignal, das typischerweise verwendet wird, um eine Anzeigeeinrichtung, wie z. B. ein CRT-Monitor oder eine LCD-Anzeige anzutreiben.
Aus den oben ausgeführten Gründen ist die Verwendung der geometrischen Komprimierung insbesondere von Vorteil in Hochleistungsgraphiksystemen. Weitere Leistungssteigerungen werden jedoch durch moderne Anwendungen immer noch angefordert. Somit ist eine effi ziente Methode für das Steigern der Leistung von Graphiksystemen wünschenswert, die derart konfiguriert sind, daß sie 3D-Graphikdaten, die in ein verallgemeinertes Dreiecksnetzformat komprimiert wurden, benutzt. Weiterhin ist ebenso ein Graphiksystem wünschenswert, das in der Lage ist, eine erhöhte Leistung zu erbringen, während komprimierte 3D-Geometriedaten benutzt werden.
Die europäische Patentanmeldung EP-A-0 817 117 zeigt einen Graphikbeschleuniger, der mit einem Systembus verbunden ist und komprimierte Geometriedaten empfängt. Der Graphikbeschleuniger beinhaltet ein oder mehrere Eingangspufferspeicher, die komprimierte und nicht komprimierte Daten empfangen, und enthält einen Befehlsuprozessor, der einen ersten Datenpfad für die Übertragung von nicht komprimierten geometrischen Daten und einen zweiten Datenpfad für das Empfangen und Dekomprimieren von komprimierten geometrischen Daten beinhaltet. Ein Multiplexer empfängt die nicht komprimierten Datenausgabe von der Eingangspufferspeichern und die dekomprimierte Ausgabe von dem Datenpfad des Befehlsprozessors, die Einrichtungen beinhaltet für die Dekomprimierung geometrischer Daten. Der Multiplexer kann selektive nicht komprimierte oder dekomprimierte Daten als Ausgang bereitstellen.
Zusammenfassung der Erfindung
Die Probleme, die oben ausgeführt wurden, können teilweise von einem Graphiksystem gelöst werden, das in der Lage ist, 3D-Geometriedaten, die im allgemeinen von vielen Vertices nur einmal verwendet werden, weiterzuleiten. Dies erlaubt es nachfolgenden Vertices unter Verwendung derselben 3D-Geometriedaten weniger Daten je Vertex zu übertragen. In manchen Ausführungsformen kann dies erzielt werden durch Verwendung eines (oder mehrerer) Bits des Datenblocks als ein Multicastbit/Unicastbit. In manchen Ausführungsformen kann das Bit eingestellt sein, um die Steuereinheit zu instruieren, um die 3D-Geometriedaten zu allen Dekomprimier-, Transformier-, Beleuchtungs- oder anderen Prozessoren global zu verteilen. Diese Ausführungsform kann das Potential haben, die Geschwindigkeit und die Effizienz zu verbessern durch Verringern der Wiederholung der Übertragung identischer 3D-Geometriedaten (z. B. Farbe, Textur usw.).
Die Effizienz kann ebenso erhöht werden durch Verzögern der Bildung von unabhängigen Grundelementen, bis die Transformation und/oder die Beleuchtung durchgeführt wurde. Auf diese Art und Weise haben die Vertices, die von mehr als einem Grundelement gemeinsam verwendet werden, das Potential, nur einmal transformiert und beleuchtet zu werden, im Gegensatz zum transformiert und beleuchtet werden jeweils einmal für jedes Dreieck, zu dem sie gehören. Das Transformieren und/oder Beleuchten kann somit auf einer einzelnen Vertexbasis anstelle auf einer geometrischen Grundelementbasis durchgeführt werden. Die einzeln transformierten und beleuchteten Vertices werden dann zu Grundelementen für die Darstellung zusammengesetzt.
In einigen Ausführungsformen kann das Graphiksystem einen transformierten Vertexcachespeicher benutzen, um transformierte und beleuchtete Vertices zu speichern. Jedesmal, wenn ein bestimmtes Vertex benötigt wird, um ein geometrisches Grundelement zu bilden, wird das Vertex aus dem transformierten Vertexcachespeicher ausgelesen. Auf jedes Vertex kann zugegriffen werden unter Verwendung eines Anzeigers, der mit dem Vertex während der Dekomprimierung verknüpft ist.
In anderen Ausführungsformen kann das Graphiksystem einen transformierten Vertexpufferspeicher benutzen, der ähnlich einem Netzpufterspeicher in Funktion ist. Anstelle des Speicherns von Vertices, die von dem geometrischen Dekomprimierer erzeugt wurden, speichert jedoch der transformierte Vertexpufterspeicher die transformierten und beleuchteten Vertices. Netzpufferspeicherreferenzen können von dem transformierten Vertexpuffer verwendet werden, um zu bestimmen, welche transformierten und beleuchteten Vertices in dem transformierten Vertexpufferspeicher abgelegt werden sollten.
Man bemerke, daß der Begriff Vertices, so wie er hier verwendet wird, nicht auf traditionelle polygonale Grundelementvertices beschränkt sein muß. Beispielsweise können die Vertices, so wie sie hier bezeichnet werden, ebenso Steuervertices für Bezier- oder NURB-Kurven oder Oberflächen sein.
Kurze Beschreibung der Figuren
1 ist eine Darstellung eines dreidimensionalen Objektes mit Vertices und Oberflächennormalen.
2 ist eine Darstellung eines Typs der Oberflächennormalen.
3 ist eine Darstellung eines dreidimensionalen Objektes, das in Dreiecken tesseliert worden ist.
4 ist ein Beispiel einer Liste von Vertices, die Dreiecke bilden, die ein dreidimensionales Objekt beschreiben.
5 stellt die Wiederverwendung von Vertices dar, wenn Dreiecke gebildet werden.
6 stellt ein beispielhaftes Dreiecksnetz dar.
7A-H stellen ein Verfahren für die Dekomprimierung eines generalisierten Dreiecksstreifens dar.
8A-N stellen ein Verfahren für das Verwenden eines Netzpufferspeichers dar, um eine generalsierte Dreiecksnetzdatenstruktur zu dekomprimieren.
9 stellt eine Ausführungsform eines Graphiksystems dar, das derart konfiguriert ist, daß es komprimierte dreidimensionale Geometriedaten verwendet.
10 stellt eine Ausführungsform eines Computernetzwerkes dar.
11 stellt eine Ausführungsform eines Computersystems dar, das ein dreidimensionales Graphiksystem enthält.
12 stellt ein vereinfachtes Blockdiagramm dar, das eine Ausführungsform des Computersystems von 11 darstellt.
13 stellt eine Ausführungsform des Graphiksystems von 12 dar.
14 stellt eine alternative Ausführungsform des Graphiksystems von 12 dar. 15A stellt ein Verfahren für das Darstellen eines Vertex im Objektraum dar.
15B stellt ein Verfahren für das Darstellen eines Vertex im Weltraum dar. 15C stellt ein Verfahren für das Darstellen eines Vertex im Schirmraum dar.
16 ist ein Flußdiagramm, das eine Ausführungsform eines Verfahrens darstellt für das Reduzieren von redundanter Transformation und/oder Belichtungsberechnung in einem Graphiksystem.
17 ist ein Diagramm, das eine andere Ausführungsform des Graphiksystems von 12 zeigt.
18 ist ein Diagramm, das eine Ausführungsform einer Datensequenz zeigt, die benutzt werden kann mit einem Graphiksystem, das derart konfiguriert ist, daß es die parallele Dekomprimierung von komprimierten 3D-Geometriedaten durchführt.
19A stellt die parallele Ausführung einer Sequenz von Blöcken dar.
19B stellt dar, wie Multicastbefehle die Gesamteffizienz in einigen Systemen mit vielen Pipelines reduzieren können.
19C zeigt, wie das Verschieben des Zustandseinstellbefehls in die Unicastbefehle verhindert, daß die Pipelines, die die Unicastblöcke 242D-E ausführen, den nicht notwendigen Zustandseinstellbefehl ausführen müssen.
20A stellt eine Ausführungsform eines Verfahrens dar für das Codieren komprimierter geometrischer Daten innerhalb von Blöcken, die konfiguriert sind, um unabhängig und parallel dekomprimiert zu werden.
20B stellt Details der Codierung dar, die in 20A gezeigt ist.
Während die Erfindung verschiedenen Modifikationen und alternativen Formen zugänglich ist, wurden spezifische Ausführungsformen hiervon beispielhaft in den Figuren gezeigt und werden im Detail beschrieben. Es sollte jedoch verstanden werden, daß die Zeichnungen und die detaillierte Beschreibung dieser nicht dafür vorgesehen ist, die Erfindung auf die bestimmten beschriebenen Formen zu beschränken, sondern im Gegenteil ist es die Absicht, alle Modifikationen, Äquivalente und Alternativen, die in den Geist und den Schutzbereich der vorliegenden Erfindung, wie er von den anhängenden Ansprüchen definiert wird, abzudecken.
Detaillierte Beschreibung von verschiedenen Ausführungsformen
Ein Graphiksystem gemäß der vorliegenden Erfindung kann verwendet werden, um eine verbesserte Leistung zu erzielen durch Reduzieren der redundanten Verarbeitung. Mit Vorteil können komprimierte Geometriedaten immer noch von dem System verwendet werden. Bevor das System und das in Beziehung stehende Verfahren im Detail beschrieben wird, wird die Gesamtumgebung, in der die vorliegende Erfindung ausgeführt werden kann, beschrieben.
Computernetzwerk – 10
10 stellt ein beispielhaftes Computernetzwerk dar. Das Computernetzwerk weist einen Server 60 auf, der derart konfiguriert ist, daß er komprimierte 3D-Geometriedaten zu den Clients 70A–C leitet. In manchen Ausführungsformen kann der Server 60 die komprimierten 3D-Geometriedaten in Echtzeit erzeugen. In anderen Konfigurationen können die 3D-Geometriedaten offline erzeugt werden. Die komprimierten 3D-Geometriedaten können zu den Clients 70A–C in einer Anzahl von unterschiedlichen Art und Weisen weitergeleitet werden. Beispielsweise kann der Server 60 die komprimierten 3D-Geometriedaten über ein physikalisches Kommunikationsnetzwerk 68 übertragen. Kommunikationsnetzwerke können Internetverbindungen, Kabelverbindungen und Telefonleitungen enthalten. Der Server 60 kann die komprimierten 3D-Geometriedaten ebenso unter Verwendung eines physikalischen Trägermediums 62 (auf z. B. einer CD, einer DVD oder einem magnetischen Medium) übertragen. Eine andere Einrichtung für das Übertragen der komprimierten 3D-Geometriedaten kann die drahtlose Übertragung (z. B. über einer Parabolantenne 64 und einen Satelliten 66) beinhalten. Kombinationen von diesen anderen Verfahren können ebenso verwendet werden.
Sobald die komprimierten 3D-Geometriedaten von einem oder mehreren der Clients 70A-C empfangen werden, werden die Daten dekomprimiert, dargestellt und dann angezeigt. Wie in den Figuren gezeigt ist, können die Clients 70A–C Computersysteme, wie z. B. Personalcomputer (PCs), Laptopcomputer, Netzwerkcomputer (NCs), Fernsehgeräte mit „set top"-Decoderboxen, Spielboxen und andere elektronische Geräte beinhalten, die in der Lage sind, 3D-Computergraphik zu manipulieren und/oder anzuzeigen. Andere Beispiele beinhalten persönliche digitale Assistenten (PDAs) und Workstations virtueller Realität (z. B. Computer mit am Kopf montierten Anzeigen).
Computersystem – 11
11 stellt eine Ausführungsform eines Computersystems 80 dar, die ein dreidimensionales (3D)-Graphiksystem beinhaltet. Das 3D-Graphiksystem kann in irgendeinem von verschiedenen Systemen enthalten sein, einschließlich eines Computersystems, eines Netzwerk-PCs, einer Internetanwendung, einem Fernseher einschließlich HDTV-Systemen und interakti ven Fernsehsystemen, persönlichen digitalen Assistenten (PDAs) und anderen Einrichtungen, die 2D- und/oder 3D-Graphik unter anderem zeigen.
Wie gezeigt, weist das Computersystem 80 eine Systemeinheit 82 und einen Videomonitor oder eine Anzeigeeinrichtung 84, die mit der Systemeinheit 82 verbunden ist, auf. Die Anzeigeeinrichtung 84 kann irgendeine von verschiedenen Typen von Anzeigemonitoren oder Einrichtungen sein (z. B. eine CRT-, LCD- oder Gasplasmaanzeige). Verschiedene Eingabegeräte können mit dem Computersystem verbunden sein, einschließlich einer Tastatur 86 und/oder einer Maus 88 oder einem anderen Eingabegerät (z. B. einem Trackball, einem Digitalisierer, einem Tablett, einer Eingabeeinrichtung mit sechs Freiheitsgraden, einem Kopfverfolger, einem Augenverfolger, einem Datenhandschuh, Körpersensoren usw.). Anwendungssoftware kann vom dem Computersystem 70 ausgeführt werden, um 3D-Graphikobjekte auf der Anzeigeeinrichtung 84 anzuzeigen. Wie unten weiter beschrieben wird, beinhaltet das 3D-Graphiksystem im Computersystem 80 einen supergesampelten Abfragepufferspeicher mit einer programmierbaren Einheit zur Umrechnung von Abfrage in Pixel in Echtzeit, um die Qualität und den Realismus von Bildern, die auf der Anzeigeeinrichtung 84 angezeigt werden, zu verbessern.
Computersystemblockdiagramm – 12
12 stellt ein vereinfachtes Blockdiagramm dar, das das Computersystem von 11 darstellt. Elemente des Computersystems, die nicht notwendig sind für ein Verständnis der vorliegenden Erfindung, werden aus Gründen der Bequemlichkeit nicht gezeigt. Das Computersystem 80 beinhaltet, wie gezeigt, eine zentrale Verarbeitungseinheit (CPU) 90, die mit einem Hochgeschwindigkeitsspeicherbus oder Systembus 94 (ebenso als Hostbus 94 bezeichnet) verbunden ist. Ein Systemspeicher 92 kann ebenso mit dem Hochgeschwindigkeitsbus 94 verbunden sein.
Der Hostprozessor 90 kann ein oder mehrere Prozessoren von unterschiedlichen Typen, z. B. Mikroprozessoren, Multiprozessoren und CPUs aufweisen. Der Systemspeicher 92 kann irgendeine Kombination von unterschiedlichen Typen von Speicheruntersystemen einschließlich Speichern mit wahlfreiem Zugriff (z. B. u. a. statische Speicher mit wahlfreiem Zugriff oder „SRAMs", synchrone dynamische Speicher mit wahlfreiem Zugriff oder „SDRAMs" und rambus-dynamische Zugriffsspeicher oder „RDRAM") und Massenspeichereinrichtungen aufweisen. Der Systembus oder Hostbus 94 kann ein oder mehrere Kommunikations- oder Hostcomputerbusse (für die Kommunikation zwischen den Hostprozessoren, den CPUs und den Speichersubsystemen) sowie spezialisierte Subsystembusse aufweisen.
Ein 3D-Graphiksystem oder Graphiksystem 100 gemäß der vorliegenden Erfindung ist mit dem Hochgeschwindigkeitsbus 94 verbunden. Das 3D-Graphiksystem 100 kann mit dem Bus 94 durch beispielsweise einen Kreuzschienenschalter oder eine andere Busverbindungslogik verbunden sein. Es wird angenommen, daß verschiedene andere externe Geräte oder an dere Busse mit dem Hochgeschwindigkeitsbus 94 verbunden sein können. Es sei bemerkt, daß das 3D-Graphiksystem mit ein oder mehreren der Busse in dem Computersystem 80 verbunden sein kann und/oder mit verschiedenen Bustypen gekoppelt sein kann. Zusätzlich kann das 3D-Graphiksystem mit einem Kommunikationsanschluß verbunden sein und dadurch direkt Graphikdaten von einer externen Quelle, z. B. dem Internet oder einem Netzwerk, empfangen. Wie in der Figur gezeigt ist, wird die Anzeigeeinrichtung 84 mit dem 3D-Graphiksystem 100, das in dem Computersystem 80 aufgenommen ist, verbunden.
Die Host-CPU 90 kann Informationen zu und von dem Graphiksystem 100 entsprechend einem programmierten Eingabe-/Ausgabe-(I/O)Protokoll über den Hostbus 94 übertragen. Alternativ dazu kann das Graphiksystem 100 auf das Speichersubsystem 92 entsprechend einem direkten Speicherzugriffsprotokoll (DMA) oder über ein intelligentes Busmastering zugreifen.
Ein Graphikanwendungsprogramm, das sich nach einer Anwendungsprogrammierschnittstelle (API) richtet, wie z. B. Open GL^TM oder Java 3D^TM, kann auf der CPU 90 ausgeführt werden und Befehle und Daten erzeugen, die ein geometrisches Grundelement (Graphikdaten), wie z. B. ein Polygon, für die Ausgabe auf der Anzeigeeinrichtung 84 definieren. Wie von der bestimmten verwendeten Graphikschnittstelle definiert, können diese Grundelemente getrennte Farbeigenschaften für die vordere und hintere Oberfläche haben. Der Hostprozessor 90 kann diese Graphikdaten zu dem Speichersubsystem 92 übertragen. Danach kann der Hostprozessor 90 arbeiten, indem er die Graphikdaten zu dem Graphiksystem 100 über den Hostbus 94 überträgt. In einer anderen Ausführungsform kann das Graphiksystem 100 die Anordnungen geometrischer Daten über den Hostbus 94 unter Verwendung von DMA-Zugriffszyklen lesen. In noch einer anderen Ausführungsform kann das Graphiksystem 100 mit dem Systemspeicher 92 durch einen direkten Anschluß, wie z. B. der verbesserte Graphikanschluß (AGP), der von der Intel Corporation veröffentlicht wurde, verbunden sein.
Das Graphiksystem kann Graphikdaten von irgendeiner von verschiedenen Quellen empfangen, einschließlich der Host-CPU 90 und/oder dem Systemspeicher 92, anderen Speichern oder von einer externen Quelle, wie z. B. einem Netzwerk, z. B. dem Internet oder von einem Sendemedium, z. B. Fernsehen oder von anderen Quellen.
Wie unten beschrieben wird, kann das Graphiksystem 100 derart konfiguriert sein, daß es das Zusammensetzen der geometrischen Grundelemente verzögert, um die redundante Vertexverarbeitung zu reduzieren oder zu eliminieren. Man bemerke, daß, während das Graphiksystem 100 als Teil eines Computersystems 80 dargestellt ist, das Graphiksystem 100 ebenso als selbständige Vorrichtung (z. B. mit seiner eigenen eingebauten Anzeige) konfiguriert sein kann. Das Graphiksystem 100 kann ebenso als eine Einzelchipeinrichtung oder als Teil eines Systems auf einem Chip oder als ein Mehrfachchipmodul konfiguriert sein.
Graphiksystem – 13
13 stellt eine Ausführungsform des Graphiksystems 100 dar, die derart konfiguriert ist, daß sie komprimierte 3D-Geometriedaten benutzt und die redundante Verarbeitung von erneut verwendeten Vertices reduziert. Das Graphiksystem 100 empfängt komprimierte 3D-Geometriedaten von dem Eingangsbus 10. Der geometrische Dekomprimierer 12 empfängt und dekomprimiert die Daten in Objektraumvertices. Der Unterschied zwischen den Objektraum-, den Weltraum- und Schirmraumkoordinaten und Vertices wird unten im Detail erklärt (s. 15). Es sei bemerkt, daß in dieser Ausführungsform der Netzpufferspeicher 14 optional ist, da die Vertices nicht in komplette geometrische Grundelemente innerhalb des Dekomprimierers 12 zusammengesetzt werden müssen. Statt dessen können in dieser Ausführungsform die 3D-Geometriedaten in zwei Informationstypen dekomprimiert werden: (1) einzelne Vertices und (2) Verbindungs- bzw. Konnektivitätsinformationen. Der Begriff „Konnektivitätsinformation", so wie er hier verwendet wird, bedeutet Information, die anzeigt, wie die Vertices miteinander verbunden sind. Die Konnektivitätsinformation kann beispielsweise Netzpufferspeicherreferenzen beiinhalten. Die Konnektivitätsinformation wird von dem Dekomprimierer 12 zu dem Aufbau/Zeichenprozessor 22 geleitet.
Die einzelnen Objektraumvertices werden (z. B. in einer belastungsausgeglichenen Art und Weise) zu den Transformations-/Belichtungsprozessoren 18A–N verteilt. Die Transformations-/Belichtungsprozessoren 18A-N transformieren die Objektraumvertices in Weltraum- oder Schirmraumkoordinaten und führen dann die Belichtungskalkulationen durch. Die transformierten und belichteten Vertices werden dann zu dem Darstellungs-/Zeichenprozessor 22 geleitet.
Der Darstellungs-/Zeichenprozessor 22 ist derart konfiguriert, daß er sowohl die transformierten und belichteten Vertices von den Prozessoren 18A-N als auch die Konnektivitätsinformation von dem geometrischen Dekomprimierer 12 empfängt. Basierend auf der Konnektivitätsinformation wird der Darstellungs-/Zeichenprozessor 22 derart konfiguriert, daß er die transformierten und belichteten Vertices in geometrische Grundelemente transformiert. In der in der Figur gezeigten Ausführungsform kann ein transformierter Vertexpufferspeicher 106 von dem Aufbau-/Zeichenprozessor 22 verwendet werden, um die geometrischen Grundelemente (z. B. unter Verwendung von Registern 108) aufzubauen. Das Aufbauen von geometrischen Grundelementen kann in einer ähnlichen Art und Weise wie die von dem geometrischen Dekomprimierer 12 in den 8A-8N verwendeten. Statt der Verwendung eines Netzpufferspeichers kann jedoch ein Aufbau-/Zeichenprozessor 22 transformierte Vertexpuffer 106 verwenden, um die transformierten und belichteten Vertices entsprechend der Konnektivitätsinformation von dem Dekomprimierer 12 zu speichern. Wie vorher bemerkt wurde, können in einigen Ausführungsformen die Konnektivitätsinformationen Netzpufferspeicherreferenzen von den komprimierten 3D-Geometriedaten enthalten. Diese Netzpufferspeicherreferenzen können verwendet werden, um transformierte und belichtete Vertices auf die transformierten Vertexpufferspeicher 106 zu schieben und hervorzuholen. In dieser Ausführungsform kann der transformierte Vertexpufferspeicher als ein Stapel bzw. Stack konfiguriert sein, auf den unter Verwendung einer zum Anfang des Stacks relativen Adressierung (z. B. wie in 8N gezeigt ist) zugegriffen werden kann.
Wie vorher erwähnt wurde, kann durch individuelles Transformieren und Belichten von Vertices die redundante Transformation und Belichtung von gemeinsam genutzten Vertices reduziert werden. In dem vorherigen System könnte, wenn ein erstes Dreieck mit Vertices 1-2-3 und ein zweites Dreieck mit Vertices mit 2-3-4 von dem Dekomprimierer 12 gebildet werden, der Transformations- und Belichtungsprozessor 18A das erste Dreieck empfangen haben und der Prozessor 18B könnte das zweite Dreieck empfangen haben. Jeder Prozessor würde dann eine Transformations- und Belichtungsberechnung auf jedem der drei Vertices seines Dreiecks durchführen. Somit würde Prozessor 18A die Vertices 1, 2 und 3 transformiert und belichtet haben, während Prozessor 18B die Vertices 2, 3 und 4 transformiert und belichtet haben würde. Wie dieses Beispiel darstellt, werden die Vertices 2 und 3 zweimal transformiert und belichtet.
Im Gegensatz dazu könnten die Vertices 1–3 in der in der Figur dargestellten Ausführungsform zu dem Prozessor 18A abgeleitet worden sein, während die Vertices 4 – 6 zu dem Prozessor 18B geleitet sein könnten. Somit könnte die doppelte Transformation und Belichtung von wiederholten Vertices reduziert oder eliminiert werden. Dies ist möglich, da in den meisten Fällen die Vertices als unabhängige Punkte auf einer Oberfläche eines Objektes betrachtet werden können. Welche Vertices zueinander benachbart sind, ist typischerweise für die Berechnungen der Koordinatentransformation und der Belichtungsberechnung irrelevant.
Alternative Ausführungsform 14
14 stellt eine alternative Ausführungsform des Graphiksystems 100 dar. In dieser Ausführungsform benutzt der Aufbau-/Zeichenprozessor 200 statt der Verwendung eines transformierten Vertexpufferspeichers einen transformierten Vertexcachespeicher 110. Der Begriff „transformierter Vertexcachespeicher", so wie er hier verwendet wird (ebenso als „verarbeiteter Vertexspeicher" bezeichnet) beinhaltet sowohl transformierte Vertexpufferspeicher, transformierte Vertexcachespeicher als auch andere Speichereinrichtungen, die konfiguriert sind, um Vertices zu speichern, die von ihrem ursprünglichen Koordinatenreferenzeinzelbild transformiert wurden.
Der transformierte Vertexspeicher kann Vertices speichern, die einem oder mehreren der folgenden Prozesse ausgesetzt wurden: Modelltransformation, Ansichtstransformation, Abschneideüberprüfung, perspektivische Transformationsbelichtung, Texturbildung, Schattierung oder komplexeren programmierbaren Schattierungs- oder anderen Prozessen. Diese Prozesse können (einzeln und gemeinsam) als „Vertexprozessor" bezeichnet werden, und ein Vertex, auf dem ein oder mehrere Vertexprozesse durchgeführt wurden, kann als ein „verarbeitetes Vertex" bezeichnet werden. Es sei bemerkt, daß Details der programmierbaren Schattierung in dem Buch beschrieben sind mit dem Titel „The Renderman Companion: A Programmer's Guide to Realistic Computer Graphics" von Steve Upstill (Addisson-Wesley Publishing Co., Juli 1989, ISBN: 0201508680).
Wie in der Figur gezeigt ist, ist der Dekomprimierer 12 derart konfiguriert, daß er komprimierte 3D-Geometriedaten empfängt und in Vertices dekomprimiert. Der Dekomprimierer 12 ist jedoch ebenso konfiguriert, um jedem dekomprimierten Vertex einen Anzeiger zuzuweisen. Die dekomprimierten Vertices werden dann mit ihren Anzeigern zu den Transformations- und Belichtungsprozessoren 18A-N weitergeleitet. Der Dekomprimierer 12 ist ebenso derart konfiguriert, daß er Konnektivitätsinformation unter Verwendung der Vertexanzeige erzeugt. Wie in der vorherigen Ausführungsform wird die Konnektivitätsinformation dem Aufbau-/Zeichenprozessor zur Verfügung gestellt.
Der Aufbau-/Zeichenprozessor 22 ist derart konfiguriert, daß er die transformierten und beleuchteten Vertices (und ihre verknüpften Anzeiger) empfängt und sie in dem transformierten Vertexcachespeicher 110 bzw. der Anzeigeanordnung 112 speichert. Abhängig von der Konfiguration kann der transformierte Vertexcachespeicher 110 direkt abgebildet werden, teilassoziativ oder vollständig assoziativ sein. Der Aufbau-/Zeichenprozessor 22 setzt dann die geometrischen Grundelemente basierend auf der Konnektivitätsinformation, die von dem Dekomprimierer 12 bereitgestellt wird, zusammen. In einer Ausführungsform kann die Konnektivitätsinformation Sequenzen von Anzeigern aufweisen. Diese Anzeiger können von dem Aufbau/Zeichenprozessor 22 verwendet werden, um die transformierten und belichteten Vertices aus dem Cachespeicher 110 (unter Verwendung des Anzeigearrays 112) aus und in das Register 110 einzulesen. Wie in der vorherigen Ausführungsform wird, wenn ein Grundelement in den Registern 110 gebildet wird, dies dann in dem Einzelbildpufferspeicher 28 dargestellt (d.h. gezeichnet). Wie bei der vorherigen Ausführungsform kann die Menge der redundanten Verarbeitung, die auf gemeinsam genutzten/wiederverwendeten Vertices durchgeführt wird, reduziert werden. Abhängig von der Konfiguration und der Größe des transformierten Vertexcachespeichers 110 kann diese Ausführungsform die Wiederverwendung von Vertices über ein bestimmtes Netz hinaus (z. B. über die Grenzen eines einzelnen Dreiecksnetzes hinaus) erlauben.
Es sei bemerkt, daß, während die Figuren die Register 108 mit einem Speicher für nur drei Vertices pro Grundelement zeigen, andere Konfigurationen ebenso möglich sind (z. B. vier oder mehr Vertices für Polygone, zwei Vertices für Linien oder ein Vertex für Punkte). Es sei weiterhin bemerkt, daß, während das Graphiksystem 100 als komprimierte 3D-Geometriedaten empfangend gezeigt ist, andere Datentypen empfangen und verwendet werden können. Beispielsweise kann der Dekomprimierer 12 derart konfiguriert sein, daß er nicht komprimierte 3D-Geometriedaten in manchen Ausführungsformen empfängt. Die 3D-Graphikdaten können Daten in einer Anzahl von unterschiedlichen Formaten beinhalten. Beispielsweise können dreidi mensionale Objekte, die Teil einer Szene sind, als Volumina, Oberflächen oder 3D-Objekte dargestellt werden, die in einer Mehrzahl von Polygonen (z. B. Dreiecke oder Vierecke) tesseliert wurden. Die 3D-Graphikdaten können ebenso Objekte beinhalten, die mit NURBs-(nicht gleichförmige rationale B-Splines), Volumenelement-, Subunterteilungsoberflächen-, Netz- und anderen Techniken modelliert wurden. Die 3D-Daten können durch Computeranimatoren, durch 3D-Abtastvorrichtungen, durch 3D-Kameras, durch 3D-Digitalisieren oder durch andere Techniken erzeugt werden. Abhängig von dem Format, in dem die 3D-Graphikdaten empfangen werden, können sie manipuliert werden, bevor sie in einer Mehrzahl von Vertices transformiert werden.
In diesem Fall fungiert der Dekomprimierer 12 eher als ein Konnektivitätsinformationserzeuger durch Erzeugen der Vertexanzeige und entsprechender Konnektivitätsinformation für die Vertices statt der tatsächlichen Dekomprimierung der Daten. In anderen Ausführungsformen können die Daten komprimiert werden unter Verwendung von nicht geometrischen Verfahren (z. B. numerische Komprimierung, wie z. B. LZW-Komprimierung). Während die Vorteile der Bandbreitenreduzierung in solch einer Ausführungsform nicht vollständig realisiert werden können, kann nichts desto trotz das Graphiksystem 100 in der Lage sein, die Menge der redundanten Transformation und Belichtung, die auf gemeinsam genutzten/wiederverwendeten Vertices durchgeführt wird, zu reduzieren.
Um dem Dekomprimierer/Konnektivitätsinformationsgenerator 12 es zu erlauben, die Konnektivitätsinformation effizient zu erzeugen, kann in einer Ausführungsform der Konnektivitätsinformationsgenerator 12 mit einem nicht transformierten Vertexcachespeicher 114 und einer entsprechenden Anzeigeanordnung 116 konfiguriert sein. Wenn der Dekomprimierer/Konnektivitätsinformationsgenerator 12 Daten empfängt, kann er Anzeiger zuweisen und die Vertices und ihre entsprechenden Anzeiger in dem nicht transformierten Vertexcachespeicher 114 bzw. der Anzeigeanordnung speichern. Der Dekomprimierer/Generator 12 kann dann die Vertices untersuchen, wie sie empfangen wurden. Wenn ein entsprechender Eintrag bereits im nicht transformierten Vertexcachespeicher 114 ist, dann wurde das Vertex bereits transformiert und beleuchtet und sollte im transformierten Vertexcachespeicher 114 abgelegt werden. Der Dekomprimierer/Generator 12 kann den Anzeiger zu dem Aufbau-/Zeichenprozessor 22 leiten, ohne daß das Vertex erneut übertragen wurde. Wenn der transformierte Vertexcachespeicher 110 keine Kopie des transformierten Vertex hat, kann dies dem Dekomprimierer/Generator 12 zurück signalisiert werden, und der Dekomprimierer/Generator 12 kann das nicht transformierte Vertex zu einem der Transformations- und Belichtungsprozessoren 18A–N leiten.
Die Größe der Cachespeicher 110 und 114 kann variieren abhängig von der Organisation der Eingangsgraphikdaten. Wenn beispielsweise die Graphikdaten hoch organisiert sind (z. B. in generalisierte Netze) kann ein kleinerer Cachespeicher genügend Speicher enthalten, um effektiv zu sein. Wenn jedoch die Graphikdaten Zufallsvertices enthalten, dann kann ein größe rer Cachespeicher effektiver sein bei der Reduzierung der redundanten Transformations- und Belichtungsberechnungen.
Während jede Ausführungsform unterschiedliche Informationen mit den Vertices, die in dem transformierten Vertexpufterspeicher 106 (oder dem transformierten Vertexcachespeicher 110) abgelegt sind, beinhalten kann, folgt eine Teilliste von Informationen, die in einigen oder allen Vertices aufgenommen sein kann: Vertexposition (z. B. x,y,z-Koordinate in dem Weltraum oder dem Schirmraum), Texturabbildungskoordinaten (z. B. 2D-Koordinaten, 3D-Koordinaten, mehrere Texturabbildungskoordinaten, 4D-Koordinaten), Farbe (z. G. Rot-, Grün- und Blau-Komponenten), Transparenzinformation (z. B. eine Alphakomponente), Normaleninformation (z. B. Nx, Ny, Nz), Belichtungsinformation, Verschiebungsabbildungsinformation, Reflektivitätsinformation, Bumpabbildungsinformation, Unschärfeinformation, eine Intensitäts- und Helligkeitsinformation und andere Steuerinformation.
Es sei bemerkt, daß in einigen Ausführungsformen es mehrere Aufbau/Zeichenprozessoren (z. B. einen für jeden Transformations- und Belichtungsprozessor oder einen für je zwei Transformations- und Belichtungsprozessoren) und mehrere Dekomprimiereinheiten geben kann. Diese Ausführungsformen werden in größerem Detail unten erläutert (s. Diskussion von 17). Die Transformationsberechnungen, die von den Transformations- und Belichtungsprozessoren 18A-N durchgeführt werden, werden jedoch zunächst beschrieben als Verfahren für die Implementierung der vorher beschriebenen Ausführungsformen.
Transformation Figuren 15A–C
15A stellt einen bestimmten Punkt oder Vertex 150 in bezug auf die Koordinatenachsen 140 eines entsprechenden Objektes dar. Die Position des Vertex 150 kann somit spezifiziert werden durch Identifizieren seiner x-, y- und z-Offsetwerte von den Koordinatenachsen 140.
15B stellt denselben Vertex 150 dar, jedoch dieses mal in bezug auf „Weltraum"-Koordinatenachsen 142. Man bemerke, daß, abhängig von dem dreidimensionalen Objekt oder der Szene, die beschrieben wird, die Weltkoordinatenachsen 142 nicht auf einem Objekt sein müssen. Statt dessen können die Weltkoordinatenachsen 142 im Weltraum gegenüber allen Objekten verschoben sein. Um die Koordinaten des Vertex 150 im Weltraum zu erhalten (d.h. relativ zu den Weltkoordinatenachsen 142) können die ursprünglichen Objektraumkoordinaten (wie sie in 15A gezeigt sind) durch die Differenz in der Position der Objektkoordinatenachsen 140 und der Weltkoordinatenachsen 142 verschoben werden.
15C stellt einen Typ des Schirmraumkoordinatensystems dar. Der Vertex 150 kann in bezug auf Schirmkoordinatenachsen 144 spezifiziert werden. Es sei bemerkt, daß in vielen Anwendungen der Offset der Schirmkoordinatenachsen 144 gegenüber den Objektkoordinatenachsen 140 abhängig ist von der gegenwärtigen Position des Betrachters oder des Betrach tungspunktes. Um die Koordinaten des Vertex 150 im Weltraum (d.h. relativ zu den Weltkoordinatenachsen 142) zu erhalten, können die ursprünglichen Objektraumkoordinaten (wie in 15A gezeigt) um die Differenz in der Position der Weltraumkoordinatenachsen 142 und der Schirmraumkoordinatenachsen 144 verschoben werden. Der Prozeß der Verschiebung eines bestimmten Vertex von dem Objekt- zu dem Weltraum oder zu dem Schirmraum wird als „Transformation" bezeichnet. Diese kann durchgeführt werden durch die Transformations- und Belichtungsprozessoren 18A–N.
Verfahren zum Reduzieren redundanter Transformation/Belichtung – 16
16 ist ein Flußdiagramm, das eine Ausführungsform eines Verfahrens zur Reduzierung redundanter Transformation und/oder Belichtungsberechnungen, die auf gemeinsam genutzten Vertices durchgeführt werden, zu reduzieren. Ein gemeinsam genutzter Vertex ist, so wie er hier verwendet wird, einer, der Teil von zwei oder mehreren geometrischen Grundelementen ist. Darüber hinaus sollte der Begriff „geometrisches Grundelement", so wie er hier verwendet wird, Punkte, Linien, Dreiecke, Polygone, Volumenelemente und Oberflächenelemente enthalten, jedoch nicht hierauf beschränkt sein.
Die Geometriedaten werden als erstes von dem Graphiksystem empfangen (Schritt 180). Als nächstes werden die Geometriedaten in einzelne Vertices dekomprimiert und entsprechende Konnektivitätsinformation wird erzeugt (Schritt 182). Wie oben erwähnt wurde, müssen in manchen Ausführungsformen die Geometriedaten nicht komprimiert werden, wenn sie von dem Graphiksystem empfangen werden. Die Konnektivitätsinformation kann Netzpufferspeichertypreferenzen, Vertexanzeiger oder andere Schemata für das Anzeigen, welche Vertices kombiniert werden sollten, um geometrische Grundelemente zu bilden, beinhalten.
Als nächstes werden die Vertices zu den Transformations-/Belichtungsprozessoren verteilt (Schritt 184). In der bevorzugten Ausführungsform gibt es mehrere Transformations- und Belichtungsprozessoren, die derart konfiguriert sind, daß sie unabhängig und parallel zueinander arbeiten. Die Vertices können verteilt werden entsprechend bekannter Belastungsausgleichstechniken, um den Durchsatz für jeden Prozessor zu maximieren. Abhängig von der Implementierung können getrennte Prozessoren die Transformation und die Belichtung behandeln. Alternative Ausführungsformen können die Transformation, die Belichtung und die Texturierung in einem Prozeß kombinieren, der Shading bzw. Schattieren genannt wird. In einigen Ausführungsformen kann das Graphiksystem derart konfiguriert sein, daß es nur die Transformation (Schritt 186) durchführt, bevor die Vertices in geometrische Grundelemente zusammengesetzt werden. In anderen Ausführungsformen kann das Graphiksystem sowohl die Transformation als auch die Belichtung (Schritt 188) durchführen, bevor die Vertices in geometrische Grundelemente zusammengesetzt werden. Die Vertices werden in geometrisches Grundelemente zusammengesetzt unter Verwendung der vorher erzeugten Konnektivitätsinformation, unge achtet, ob entweder sowohl Transformation als auch Belichtung oder nur Transformation (Schritt 190) durchgeführt wurde.
Als nächstes werden die geometrischen Grundelemente in einem Abfrage- oder Einzelbildpufferspeicher dargestellt (Schritt 192). Ein Abfragepufferspeicher nimmt den Platz eines traditionellen Einzelbildpufferspeichers ein durch Speichern der Abfragen neben den Pixeln. Die Abfragen werden dann gefiltert, um einen endgültigen Pixelwert zu bilden. Die Verwendung eines Abfragepufferspeichers erlaubt das Supersampling, in dem die Gesamtzahl von Abfragen größer als die Gesamtzahl von Pixeln ist. Das Supersampling hat eine Anzahl von Vorteilen einschließlich eines realistischeren Bildes und der Fähigkeit, das Antialiasing on-the-fly, d. h. während der Übertragung, durchzuführen. Mehr Information über das Supersampling wird in der US-Patentanmeldung Nr. 09/251,449 geboten, die den Titel trägt „A Graphic System With Programmable Sample Positions" von Michael F Deering, David Naegle und Scott Nelson, eingereicht am 17. Februar 1999 (Anwaltsakte Nr. 5181-24200).
Es sei bemerkt, daß das Flußdiagramm, das in der Figur dargestellt ist, nur für erläuternde Zwecke vorgesehen ist und nicht beschränkend verstanden wird. In manchen Ausführungsformen können die Schritte in einer anderen Ordnung durchgeführt werden, parallel durchgeführt werden, oder einige Schritte können eliminiert werden (z.B. Schritt 188 oder Schritt 194). Zusätzliche Schritte können ebenso durchgeführt werden. Beispielsweise können mehrere Transformationsschritte 186 durchgeführt werden, um die Vertices vom Objektraum in den Weltraum und von dem Weltraum in den Schirmraum zu übersetzen. Weiterhin können mehrere Iterationen durch den Belichtungsschritt 188 durchgeführt werden, wenn mehrere Lichtquellen aktiviert werden. Andere Graphikprozesse können ebenso durchgeführt werden (z.B. die Texturabbildung, die Bumpabbildung, die Verschiebungsabbildung, das Schattieren, das Spiegelmarkieren, das Einnebeln usw.).
Mehrere Graphiksubsysteme – 17
17 ist ein Diagramm, das eine andere Ausführungsform des Graphiksystems 100 darstellt. Iri dieser Ausführungsform weist das Graphiksystem 100 eine Steuereinheit 190 auf, die derart konfiguriert ist, daß sie komprimierte Geometriedaten 208 empfängt (z. B. von der Host-CPU 90 in 12) und die komprimierten Geometriedaten zu ein oder mehreren Dekomprimierern 12A–N leitet. Die Dekomprimierer 12A–N sind derart konfiguriert, daß sie die komprimierten Geometriedaten empfangen und dekomprimieren. Die dekomprimierten Geometriedaten, die ein oder mehrere Vertices enthalten, werden dann weitergeleitet zu den Transformations- und Belichtungsprozessoren 18A–18N. Es sei bemerkt, daß jedes entsprechende Paar der Dekomprimierer und der Transformations- und Belichtungseinheiten als eine „Dekomprimierungs-/Darstellungspipeline" bezeichnet werden kann.
Sobald die Vertices transformiert und belichtet sind, werden sie zu den Aufbau/Zeicheneinheiten 22A–N geleitet. In dieser Ausführungsform hat jede Aufbau-/Zeicheneinheit 22A–N ihren eigenen transformierten Vertexpufterspeicher 106A–N und ihren eigenen Satz von ältestes-mittleres-neuestes Register 108A–N. Diese können in ähnlicher Weise arbeiten wie die in Verbindung mit 14 oben beschriebenen. FIFO-Speicher (ferst-in ferst-out) können in den Pipelines verwendet werden (z.B. zwischen der Steuereinheit 190 und den Dekomprimierungseinheiten 12A-N), um die Daten, die von der Steuereinheit 190 verteilt werden, im Pufferspeicher zu speichern.
Um den Transformations- und Belichtungsprozeß und den Aufbau-/Zeichenprozeß zu steuern, können die komprimierten Graphikdaten 208 vorbestimmte Steuerinformation beinhalten. Ein Teil dieser Steuerinformation kann benutzt werden während des Dekomprimierungsprozesses. Beispielsweise können die komprimierten Graphikdaten 208 Steuerinformation beinhalten, die den Typ der verwendeten Komprimierung anzeigen oder spezifische Information über das bestimmte Netz, das komprimiert wird, enthalten. Ein solcher Typ von Steuerinformation kann eine Anzeige der Farbtiefe, die in dem bestimmten Netz verwendet wird, sein. Ein anderer Typ der Steuerinformation kann eine Anzeige sein, ob Farbinformation für jedes Vertex (d. h. ein Bündelfarbbit) spezifiziert wird oder ob die Farbinformation getrennt definiert wird (z. B. eine globale Farbe für alle Vertices in dem Netz). Andere Steuerinformation (z.B. Transparenz oder Alphainformation) kann ebenso in die komprimierten Geometriedaten eingebettet werden.
Die Steuerinformation kann den „Zustand" einer Zustandsmaschine innerhalb einem oder mehreren der Dekomprimierer 12A–N, der Transformations-/Belichtungsprozessoren 18A-N und/oder der Aufbau-/Zeichenprozessoren 22A–N einstellen. In einigen Ausführungsformen kann die Steuerinformation als entweder „globale" oder „lokale" Steuer-(oder Zustands)Information bezeichnet werden. Die Steuerinformation ist global, wenn sie dafür vorgesehen ist, den Zustand von allen Dekomprimierern 12A–N, von allen Transformations/Belichtungsprozessoren 18A–N oder allen Aufbau-/Zeichenprozessoren 22A–N in dem Graphiksystem 100 zu beeinflussen. Im Gegensatz dazu ist die Steuerinformation dann lokal, wenn die Farbinformation dafür vorgesehen ist, nur den Zustand eines einzelnen Dekomprimierers, einer einzelnen Transformations-/Belichtungseinheit oder einer einzelnen Aufbau-/Zeicheneinheit zu beeinflussen. Die Steuereinheit 190 kann konfiguriert sein, um zu erfassen, ob die in den Strom der komprimierten geometrischen Daten eingebettete Steuerinformation global oder lokal ist und kann dann die Steuerinformation entsprechend leiten. Beispielsweise, wenn ein bestimmter Satz von Steuerinformation global ist, dann kann die Steuereinheit 190 derart konfiguriert sein, daß sie Kopien der Steuerinformation zu jeder Dekomprimierungs-/Darstellungspipeline in dem Graphiksystem 100 sendet. Wenn die Steuereinheit 190 bestimmt, daß die Steuerinformation lokal ist, leitet die Steuereinheit 190 die Steuerinformation zu einer einzelnen Dekomprimie rungs-/Darstellungspipeline zusammen mit dem Vertex oder den Vertices, die mit der Steuerinformation verknüpft sind, weiter.
Die Steuereinheit 190 kann beispielsweise einen Strom von komprimierten Graphikdaten 208 empfangen, der mit einer globalen Farbeinstellungsinstruktion beginnt. Die Steuereinheit 190 kann dann diese globale Steuerinformation zu jedem der Dekomprimierer 12A–12N weiterleiten. Die Steuereinheit 190 kann die komprimierten Vertices in einer Round-Robin-Weise zu den Dekomprimierern 12A–12N weiterleiten. Nachdem jedes Vertex dekomprimiert ist, wird jedem Vertex die globale Farbe zugewiesen. Wenn die Steuereinheit 190 dann einen zweiten globalen Farbeinstellbefehl mit einer neuen Farbe erfaßt, sendet die Steuereinheit 190 erneut Kopien des Befehls zu jedem Dekomprimierer, der damit fortfährt, die neue Farbe allen Vertices zuzuweisen, die er nach dem globalen Farbveränderungsbefehlempfängt.
In einigen Ausführungsformen kann die Steuereinheit 190 derart konfiguriert sein, daß sie die Inhalte des transformierten Datexpufferspeichers 106A–N in Antwort auf die Erfassung eines globalen Steuerbefehls ungültig macht. Dies kann verhindern, daß ein Vertex, das mit unterschiedlichen Farben wiederverwendet wird, mehr als einmal mit derselben Farbe dargestellt wird. Es sei bemerkt, daß, während Farbe und Transparenz in den obigen Beispielen verwendet wurden, andere Typen von lokaler und Steuerinformation ebenso möglich sind und in Betracht gezogen wurden. In einigen Ausführungsformen kann die Bestimmung, ob die Zustands-/Steuerinformation global oder lokal ist, durch die Verwendung eines Unicast/Multicastbits innerhalb der komprimierten Graphikdaten 208 verwirklicht werden, wie detaillierter unten beschrieben wird.
Unicast/Multicast – 18
18 ist ein Diagramm, das eine Ausführungsform einer Datensequenz 208 zeigt, die mit einem Graphiksystem verwendet werden kann, das derart konfiguriert ist, daß es die parallele Dekomprimierung von komprimierten 3D-Geometriedaten durchführt. In dieser Ausführungsform weist die Datensequenz 208 einen Strom von Datenblöcken 200A–C auf. Jeder Datenblock beinhaltet ein Multicastbit 202, einen Längenindikator 204 und einen Datenabschnitt 206. Das Multicastbit 202 zeigt an, ob der Block ein Unicastblock oder ein Multicastblock ist. Unicastblöcke werden zu einer einzelnen Dekomprimierungs-/Darstellungspipeline weitergeleitet. Multicastblöcke werden jedoch zu allen Dekomprimierungs-/Darstellungspipelines in dem Graphiksystem weitergeleitet. Die Längenindikatoren 204 halten jeder einen Wert, der anzeigt, wo der nächste Block in der Datensequenz beginnt. Eine Anzahl von unterschiedlichen Längencodierungsschemata kann verwendet werden. Beispielsweise werden in einer Ausführungsform die Blöcke 200 mit 32-Bit Wortgrenzen ausgerichtet. Die Längenindikatoren 204 können somit einen Wert speichern, der die Anzahl von 32-Bit Worten bis zum Start des nächsten Blokkes anzeigt. In einigen Ausführungsformen können die Längenindikatoren die Gesamtlänge des gegenwärtigen Blockes (in 32-Bit Worten) sein. In anderen Ausführungsformen können die Längenindikatoren die Länge des folgenden Datenabschnittes 206 (entweder in Bits, Bytes oder Words) anzeigen. Die Längenindikatoren 204 können vorzugsweise eine feste Länge haben oder sie können eine variable Länge mit einem Präfix haben, das die Länge des Längenindikators 204 selbst angibt. Der Datenabschnitt 206 ist derart konfiguriert, daß er komprimierte 3D-Geometriedaten (sowie andere Information in bestimmten Ausführungsformen) speichert. In manchen Ausführungsformen kann die Länge der Datenabschnitte 206 auf ein vorbestimmtes Maximum (z. B. 2 Kilobyte oder 512 32-Bit Worte) beschränkt sein. In solch einer Ausführungsform kann die Maximallänge der Längenindikatoren 204 auf 9 Bits begrenzt sein unter der Annahme einer 32-Bit Wortlänge. Andere maximale Längen können ebenso vennrendet werden. Weiterhin kann, wie vorher bemerkt wurde, durch Verwendung eines Längenindikators 204 mit variabler Länge der Datenabschnitt 206 keine Maximallänge haben. Es sei bemerkt, daß die in der Figur dargestellten Konfiguration nur für erläuternde Zwecke vorgesehen ist und nicht als beschränkend angesehen wird. Das Multicastbit 202 kann beispielsweise auf einige Bits verlängert werden, um zusätzliche Information aufzunehmen.
Die Datenabschnitte 206 können komprimierte Geometriedaten entsprechend der vorbestimmten Netzgröße speichern. Datenabschnitte können beispielsweise derart konfiguriert sein, daß sie jeweils komprimierte Geometrieinformation entsprechend einem 16×16 Netz von Vertices speichern. Wie vorher erwähnt wurde, kann jedes Vertex eine variierende Menge von Information enthalten, einschließlich xyz-Position, Farbinformation, Normaleninformation, Texturabbildungsinformation und anderer Vertexkomponenteninformation.
Unter Verwendung der Datensequenz 208 kann die Steuereinheit 190 (s. 17) konfiguriert sein, um jeden Block entsprechend den Multicastbits 202 und der Längenindikatoren 204A effizient weiterzuleiten. Die Längenindikatoren 204 ermöglichen der Steuereinheit 190, die Blockgrenzen zu bestimmen. Durch jeden Block, der von der Steuereinheit 190 empfangen wird, leitet das entsprechende Multicastbit 202 die Steuereinheit 190, um einen Block zu einer einzelnen Dekomprimierungs-/Darstellungspipeline (Unicast) oder zu allen Dekomprimierungs/Darstellungspipelines (Multicast) weiterzuleiten. Für Unicastblöcke kann die Steuereinheit 190 konfiguriert sein, so daß sie den Block zu der Dekomprimierungs-/Darstellungspipeline mit dem geringsten Verarbeitungsrückstand weiterleitet (z. B. zu der Pipeline, die am wahrscheinlichsten verfügbar ist). Während diese Konfiguration eine große Menge von Flexibilität bereitstellt, können in manchen Ausführungsformen bestimmte Restriktionen gegenüber dem Format der Datensequenz 208 plaziert werden, um die Hardware der Steuereinheit 190 und des Graphiksystems 100 zu vereinfachen (z. B. durch Reduzieren oder Eliminieren der Anforderung von unabhängigen Dekomprimierungs-/Darstellungspipelines, die miteinander kommunizieren müssen und/oder sich miteinander abstimmen müssen).
Eine solche Restriktion ist die, daß nur Zustandsinformation in dem Datenabschnitt 206 eines Blockes 200, der Multicast ist, abgelegt werden kann. Ohne diese Restriktion können mehrere Pipelines Zeit damit verbringen, dieselben geometrischen Daten zu dekomprimieren und darzustellen. Statt dessen werden Multicastblöcke darauf beschränkt, „Zustands"-Information zu haben. Zustandsinformation, so wie sie hier verwendet wird, bedeutet Information, die lediglich für die Verwendung mit zukünftigen Vertices eingestellt wurde. Wie vorher erwähnt wurde, kann manche Zustandsinformation (z. B. Farb- und Normaleninformation) für einen bestimmten Vertex des Netzes eingestellt werden und dann von einem Vertex zu dem nächsten wiederverwendet werden. Wenn alle Vertices in einem bestimmten Netz dieselbe Farbe haben, dann kann die Farbinformation einmal als Zustandsinformation gesetzt werden (z. B. mit einem Java 3D^TM komprimierten Geometrie-setColor-Befehl) und dann durch einige oder alle Vertices in dem folgenden Block oder den folgenden Blöcken wiederverwendet werden. Andere Zustandsinformation kann Transparenzinformation und Normaleninformation beinhalten. Abhängig von der Konfiguration können andere Typen von Zustandsinformation ebenso spezifiziert werden. Ein Multicastblock kann somit dazu dienen, alle Dekomprimierungs/Darstellungspipelines auf einen vorbestimmten Zustand zurückzustellen. Dies kann nützlich sein, wenn die Steuereinheit 190 Blöcke empfängt, die ein neues 3D-Objekt beginnen. Während die Information, die in dem Netzpufferspeicher abgelegt ist, ebenso eine Zustandsinformation ist, kann, wie vorher bemerkt wurde, jeder Block dazu gedrängt werden, nicht auf irgendeiner vorher eingegebenen Netzpufferspeicherinformation zu beruhen.
In ähnlicher Weise kann, wenn ein Block als Unicastblock bezeichnet wird, um die Zwischenabhängigkeit zwischen den Dekomprimierungs-/Darstellungspipelines zu reduzieren, der Block aus Geometrieinformation anstelle von „Zustands"-Information begrenzt werden. Geometrieinformation bedeutet, so wie sie hier verwendet wird, jegliche Information, die nicht von einem Block zu dem nächsten übertragen wird. Beispielsweise können Netzpufferspeicherinhalte, Vertexpositionsinformationen und Farbinformationen alle als Geometrieinformationen angesehen werden (abhängig von der exakten Implementierung des Graphiksystems 100).
Eine andere mögliche Restriktion, die verwendet werden kann, um zu verhindern, daß irgendwelche Vertices innerhalb eines Blockes auf irgendeiner vorherigen Information, die in einem vorherigen Block geliefert wurde, beruht, ist es, zu erfordern, daß der erste Vertex von jedem Block von einem Neustartanzeiger begleitet wird. Wie vorher in dem Abschnitt über den technischen Hintergrund erläutert wurde, ist ein Neustartanzeiger ein Anzeiger, der anzeigt, daß ein neues Netz startet. Der Neustartanzeiger kann verwendet werden, um dem Aufbau/Zeichenprozessor anzuzeigen, daß alle vorherigen Einträge in den Registern 108 und/oder dem transformierten Vertexspeicher 106 ungültig gemacht werden sollten (innerhalb der entsprechenden Dekomprimierungs-/Darstellungspipeline).
Die Verwendung der Deltacodierung oder der Delta-Deltacodierung von Vertexkomponenteninformation kann ebenso begrenzt werden. Beispielsweise können manche Ausführungsformen des Graphiksystems 100 konfiguriert sein, um die Farbe eines zweiten Vertex als ein Offsetwert relativ zu einem ersten Vertex zu codieren. In gleicher Weise kann die Position des zweiten Vertex als Offset relativ zu dem ersten Vertex spezifiziert werden. Dieser Typ der Deltaoder Delta-Deltacodierung ist nützlich, da in vielen Fällen benachbarte Vertices ähnliche Attribute haben. Beispielsweise werden benachbarte Vertices typischerweise xyz-Positionskoordinaten haben, die relativ ähnlich sind. Somit kann statt der Spezifizierung einer gesamten Position für das zweite Vertex (z. b. 32-Bits jeweils für x, y und z) ein einfacher Offsetwert (z. B. 8 Bits jeweils für x, y und z) verwendet werden. Dieser Typ der Decodierung kann jedoch die Steuereinheit 190 verkomplizieren. Aus diesen Gründen können manche Ausführungsformen des Graphiksystems 100 das erste Vertex in einem Block dazu bringen, explizit zu sein (d.h. 32-Bits von Positionsinformation für jedes x, y und z). Die Deltacodierung kann somit auf Vertices begrenzt sein, die nach dem ersten Vertex in jedem Block auftreten. In gleicher Weise kann die Delta-Deltacodierung auf Vertices beschränkt sein, die nach dem zweiten Vertex in jedem Block auftreten. Abhängig von den komprimierten Daten und der exakten Implementierung des Graphiksystems kann diese Restriktion nicht außerordentlich belastend sein, da Vertices von unterschiedlichen Blöcken (d.h. unterschiedlichen Netzen) eine größere Wahrscheinlichkeit haben können, daß sie weniger gemeinsam haben als Vertices von dem selben Block/Netz.
Noch eine andere solche Restriktion ist diejenige, daß Vertices in einem bestimmten Datenabschnitt 206 nicht die Netzpufferspeicherzustandsinformation von einem vorherigen Block verwenden dürfen. Diese Restriktion fordert die Unabhängigkeit von jedem Block und kann die Steuereinheit 190 davon befreien, die Blöcke in einer bestimmten Art und Weise weiterzuleiten.
Eine Option für das Implementieren des Graphiksystems 100 ist es, zu garantieren, daß jeder Multicastblock von jeder Dekomprimierungs-/Darstellungspipeline gesehen wird vor jedem nachfolgenden Block in der Datensequenz 208. Wenn beispielsweise der Block 200A der erste Block in einer Datensequenz 208 ist, dann können die Daten codiert werden, so daß der Block 200B ein Multicastblock ist. Wenn dies so ist, dann kann der Block 2000 codiert werden, so daß er auf den Zustandseinstellungsinformationen, die in Block 200B enthalten sind, beruht. Diese optionale Restriktion kann erneut die Steuereinheit 190 vereinfachen. Um diese Restriktion zu implementieren, kann jede Dekomprimierungs-/Darstellungspipeline darauf begrenzt sein, die Blöcke auszuführen, die sie in einer „in-order"-Art und Weise empfängt. Wenn beispielsweise jede Pipeline einen Pufferspeicher hat, um anhängige Blöcke zu speichern, kann die Pipeline dazu gebracht werden, von dem Pufferspeicher in einer FIFO-Weise auszulesen. Die Verarbeitung außerhalb der Ordnung innerhalb einer bestimmten Pipeline wäre in dieser Ausführungsform nicht erlaubt.
In gleicher Weise können manche Ausführungsformen des Graphiksystems 100 garantieren, daß jegliche Blöcke, die einem Multicastblock vorausgehen, ausgeführt werden, bevor der Multicastblock ausgeführt wird (innerhalb einer bestimmten Pipeline). Dies kann in derselben Art und Weise wie oben beschrieben implementiert werden (d. h. durch Veranlassen, daß jede Pipeline Blöcke ausführt, die sie in der Ordnung empfängt, in der sie empfangen werden).
Abhängig von der Implementierung und der Menge der Komplexität innerhalb der Steuereinheit 190, die akzeptabel ist, sind Restriktionen ebenso auf anderen Typen der Zustandsinformation möglich. Beispiele beinhalten Beschränkungen auf der Block-zu-Block-Ausbreitung der Farbinformation (z. B. eingestellt durch Java 3D-setColor-Befehle), Bündelinformation (eingestellt beispielsweise durch Java 3D Bündelbefehle) oder Huffman-Tabellenstellungen. In manchen Ausführungsformen kann die verwendete geometrische Komprimierung auf programmierbaren Huffman-Tabellen für die Dekomprimierung beruhen. Die Tabellen können durch Java 3D setTable-Befehle geladen werden. Nachdem die Dekomprimierungstabelle eingestellt ist, kann jedes folgende Vertex und/oder Grundelement unter Verwendung der Tabelle decodiert werden.
Die vorerwähnten Restriktionen können in einem geometrischen Komprimierungsprogramm (oder speziell vorgesehener Geometriekomprimierungshardware) programmiert werden, die den Restriktionen folgt, wenn die komprimierten 3D-Geometriedaten erzeugt werden. In ähnlicher Weise können die obigen Anforderungen in einem Ladetaktgeberverifizierer programmiert werden, der als Teil des Dekomprimierungsprozesses abläuft. Bevor die Dekomprimierung beginnt, kann der Ladezeitverifizierer die Daten untersuchen, um zu bestimmen, welche, falls irgendwelche, der Anforderungen verletzt wurden.
Das Graphiksystem 100 kann optimiert werden, um einen bestimmten Satz von Komprimierungsanforderungen zu unterstützen. Wenn Daten, die mit den bestimmten Komprimierungsanforderungen nicht konform gehen, empfangen werden, können jedoch in manchen Ausführungsformen das Graphiksystem 100 immer noch konfiguriert sein, um die Daten zu dekomprimieren (wenn auch mit einer weniger als optimalen Geschwindigkeit). In einem worst-case Szenario können beispielsweise alle Blöcke in ihrer Ordnung zu einer einzelnen Dekomprimierungs-/Darstellungspipeline geleitet werden. Obgleich es langsam ist, kann dieses Verfahren immer noch die genaue Dekomprimierung und Darstellung von einigen Typen von komprimierten 3D-Geometriedaten erlauben, die nicht alle Restriktionen erfüllen.
Lebend-tot-Analyse – 19-A-C Während des Komprimierungsprozesses kann das Komprimierungsprogramm/Hardware konfiguriert werden, um eine lebend-tot-Analyse durchzuführen, um sicherzustellen, daß die Geometrie korrekt komprimiert wird. Dies kann ebenso in einem Verifizierer (d.h. einem Programm, das überprüft, daß die komprimierten geometrischen Daten einen Standard oder einen vorbestimmten Satz von Regeln erfüllen) durchgeführt werden. Der Verifizieren kann mit Komprimierungszeit und/oder Ladezeit ablaufen. Die Verwendung der lebend-tot-Analyse kann es dem Komprimierer erlauben, größere Komprimierungsverhältnisse zu erzielen. In manchen Ausführungsformen, insbesondere, wenn es eine große Anzahl von Dekomprimierungs/Darstellungspipelines gibt, kann die Unicast/Multicastimplementierung, die oben beschrieben wurde, die Effizienz in einigem Ausmaß reduzieren. Wenn beispielsweise einer von fünf Blökken ein Multicastblock ist und wenn es sechs Dekomprimierungs-/Darstellungspipelines gibt, kann der Komprimieren oder Verifizieren derart konfiguriert sein, daß er bestimmt, ob eine bestimmte Pipeline notwendigerweise einen bestimmten Multicastblock sehen muß. In manchen Ausführungsformen kann diese Information als ein Satz von „lebend-tot"-Bits codiert werden (z. B. an dem Beginn von jedem Block zusätzlich zu dem Multicastbit). Die Steuereinheit 190 kann konfiguriert sein, um diese lebend-tot-Bits für jeden Block zu erfassen und dann die Blöcke entsprechend weiterzuleiten. In anderen Ausführungsformen kann der Komprimieren konfiguriert sein, um die globalen Befehle umzuordnen oder in lokale Befehle zu verändern.
Wenn beispielsweise eine globale Farbveränderung zu Rot von zwei Vertices gefolgt wird und dann eine globale Farbveränderung in Grün, dann kann der globale Farbveränderer in Rot in zwei lokale Farbveränderungen in Rot (d. h. einen für jeden Vertex, der dem globalen Farbveränderer in Rot folgt) verändert werden. Da die globale Farbveränderung in Grün so dicht folgt, werden die lokalen Farbveränderungen effizienter sein in Systemen mit mehr als zwei Dekomprimierungs-/Darstellungspipelines.
Die 19A-C stellen graphisch den Prozeß der lebend-tot-Analyse unter Verwendung der Netzwerkflußdiagramme dar. 19A stellt die parallele Ausführung einer Sequenz von Blöcken dar, die ursprünglich in der folgenden Ordnung waren: Multicastblock 240, Unicastblock 242A, Unicastblock 242B, Unicastblock 242C und Multicastblock 244. Angenommen der Multicastblock 240 stellt einen bestimmten Abschnitt der Zustandsinformation (z. B. Farbe) auf einen Wert X ein, der Multicastblock 244 kann auf der Zustandsinformation beruhen, die nicht geändert wurde, wenn er ausgeführt wurde. Normalerweise, wenn nachfolgende Blöcke auf der Zustandsinformation beruhen, die von vorherigen Blöcken eingestellt wurde, würde es dazwischen liegenden Blöcken nicht erlaubt, die Zustandsinformation zu verändern. In manchen Ausführungsformen können jedoch die geometrischen Daten komprimiert werden, um dazwischen liegenden Blöcken zu erlauben, zeitweilig die -Zustandsinformation zu verändern. Dies wird durch den Unicastblock 242B gezeigt, der die Zustandsinformation von dem Wert X in dem Wert Y ändert.
In manchen Ausführungsformen kann jedoch die Geometrie unabhängig von der exakten Konfiguration der Zielhardware komprimiert werden. Beispielsweise kann das Komprimierungsprogramm nicht die Anzahl der Dekomprimierungs-/Darstellungspipelines kennen, die in der Zielhardware vorhanden sind. Die Anzahl von Pipelines kann von System zu System ab hängig von ihrer Konfiguration variieren. Um sicherzustellen, daß der Multicastblock 244 korrekt ausgeführt wird (d. h. die richtige Zustandsinformation hat) kehrt somit der Unicastblock 242B die geänderte Zustandsinformation zurück in ihren ursprünglichen Zustand. Dies ist nützlich in Ausführungsformen, in der es mehrere Dekomprimierungs-/Darstellungspipelines gibt, die jeweils unabhängig arbeiten und jeweils ihre eigene interne Kopie der Zustandsinformation haben. Somit kann eine Pipeline zeitweilig unter Verwendung einer anderen Zustandsinformation arbeiten. Wenn ein bestimmtes Stück der Zustandsinformation auf zukünftigen Blöcken beruhen wird, dann wird die Zustandsinformation als „lebende" Zustandsinformation betrachtet. Sobald eine bestimmte Einstellung der Zustandsinformation nicht länger benötigt wird, wird sie als „tot" angesehen. Tote Zustandsinformation kann durch nachfolgende Unicast- oder Multicastblöcke verändert werden, ohne daß zu dem ursprünglichen Zustand der Zustandsinformation zurückgekehrt werden muß.
19B stellt dar, wie Multicastbefehle die Gesamteffizienz in manchen Systemen mit vielen Pipelines reduzieren kann. Angenommen es gibt fünf Pipelines in dem System, so wird unter Verwendung eines Multicastblockes 240, um einen bestimmten Abschnitt der Zustandsinformation auf einen Wert X einzustellen, jede der fünf Pipelines den Befehl auszuführen haben. Wenn jedoch nur die ersten drei Unicastbefehle (242A–C) auf diesem Teil der Zustandsinformation beruhen, verschwenden die letzten beiden Pipelines, die die Unicastblöcke 242D-E ausführen, Zeit durch das Ausführen des Zustandseinstellungsbefehls von dem Multicastblock 240.
Im Gegensatz dazu stellt 19C dar, wie das Verschieben des Zustandseinstellungsbefehls in die Unicastbefehle die Pipelines, die die Unicastblöcke 242D–E ausführen, daran hindert, den nicht notwendigen Zustandseinstellbefehl auszuführen. Durch das Durchführen der lebend-tot-Analyse können die komprimierten Geometriedaten somit weiter optimiert werden.
Codierung der lebend-tot-Bits 20A-B Die 20A-B stellen einen Typ der Codierung für die lebend-tot-Bits dar, in der die lebend-tot-Bits in einem „don't care"-Feld eines no-op-Befehls bzw. Null-Operationsbefehls eingebettet sind. Mit Vorteil kann die Rückwärtskompatibilität erzielt werden unter Verwendung dieses Verfahrens, da nicht-Multicast-aktivierte Hardware (z. B. Hardware, die nur eine Dekomprimierungseinheit oder eine Dekomprimierungs-/Darstellungspipeline hat) konfiguriert werden kann, um die don't care-Bits des no-op-Befehls zu ignorieren und die Blöcke sequentiell zu verarbeiten.
20A stellt eine Ausführungsform eines Verfahrens für die Codierung komprimierter Geometriedaten innerhalb Blöcken dar, die konfiguriert sind, um unabhängig und parallel dekomprimiert zu werden. Wie in der Figur gezeigt ist, weist die Datensequenz 208 eine Reihe von Blöcken auf, wie vorher beschrieben wurde. In dieser Ausführungsform weist jedoch jeder Block eine variable Anzahl von Kopfzeilen/Körperabschnittpaaren (z. B. H1B1, H2B2 usw.) vari abler Länge auf. Jede Kopfzeile kann von ihrem entsprechenden Körper separiert sein. Beispielsweise ist die Kopfzeile H1 von dem Datenkörper B1 durch den Datenkörper BO und die Kopfzeile H2 getrennt. Da der Körper eine Längeninformation betreffend den entsprechenden Datenkörper enthalten kann, kann diese Separation mit Vorteil während des Komprimierungsprozesses erfolgen. Die Separation erlaubt es dem Dekomprimierer, sich für den Empfang der Kopfzeile vorzubereiten, bevor sie tatsächlich empfangen wird. Die zugeteilte Zeit für die Vorbereitung kann die Fähigkeit des Dekomprimierers verbessern, den Dekomprimierungsprozeß effektiv durch die Pipeline zu leiten. Zusätzliche Details betreffend mögliche Verfahren für die Kopfzeilenseparation (ebenso bezeichnet als Kopfzeilenweiterleitung) werden detailliert ausgeführt in US-Patent Nr. 5,867,167 mit dem Titel „Compression of Three-Dimensional Graphics Data Including Quantization, Delta-Encoding, and Variable-Length Encoding" von Michael F. Deering, die hier in ihrer Gesamtheit durch Bezugnahme aufgenommen wird.
Wie ebenso in der Figur angezeigt ist, kann in dieser Ausführungsform der Datenkörper des ersten und des letzten Befehls von jedem Block als no-op-Befehl variabler Länge definiert werden (d. h. BO und Bn). Dies kann es erlauben, daß bestimmte Steuerinformation in den Block eingebettet wird, ohne die Rückwärtskompatibilität zu opfern. Beispielsweise können manche Ladezeitverifizierprogramme konfiguriert werden, um die lebend/tot-Codierung wie oben diskutiert zu implementieren. Die lebend/tot-Codierung kann dann in die no-op-Befehle variabler Länge eingebettet werden. Wenn jedoch ein Graphiksystem nur eine Dekomprimierungs-/Darstellungspipeline oder aus irgendwelchen anderen Gründen die lebend/tot-Codierung nicht unterstützt, dann kann das Graphiksystem konfiguriert sein, um die no-op-Befehle zu ignorieren. In manchen Ausführungsformen können die letzten Kopfzeilenabschnitte Hn+1 ebenso mit lebend/tot-Codierungsinformation und/oder zusätzlicher Information oder Steuerinformation bepackt sein.
20B stellt Details der Codierung dar, die in 20A dargestellt ist. Die Kopfzeilen können Längeninformation enthalten, die die Anzahl von Bits, Bytes oder Worten von der Kopfzeile zu dem entsprechenden Datenkörper anzeigen (d. h. die Kopfzeile H1 zeigt die Länge von BO und möglichem H2 an). Alternativ kann die Kopfzeile Information betreffend die Länge des entsprechenden Körpers enthalten (d. h. die Kopfzeile N1 zeigt die Länge des Körpers B1 an). In der im Bild dargestellten Ausführungsform werden die Kopfzeilen definiert, so daß sie eine feste Länge von 8 Bits haben. Diese Begrenzung kann kurz gefaßt die Maximallänge der variablen Längenkörper begrenzen.
Der erste und der letzte Datenkörper von jedem Block können vordefiniert sein, so daß sie einen bestimmten Satz von Feldern haben. Beispielsweise kann der erste Körperabschnitt (BO) von jedem Block definiert sein, so daß er mit einem Feld 260 fester Länge beginnt, das die Länge des Körperabschnitts (z. B. in Bits, Bytes oder Worten) anzeigt. Das Multicast-/Unicastbit 202 kann definiert werden, so daß es dem Feld 260 folgt. Als nächstes kann das Blocklängenin formationsfeld 204 folgen. Nach dem ersten Datenkörperabschnitt kann eine feste oder variable Anzahl von Kopfzeilen-Datenkörperpaaren folgen. Wie vorher bemerkt wurde, kann die letzte Kopfzeile und/oder der letzte Datenkörperabschnitt ebenso definiert sein, um eine variable oder feste Längen-no-op-Instruktion anzuzeigen und kann verwendet werden, um bestimmte Steuerinformation zu speichern.
In manchen Ausführungsformen kann die Zustandsinformation als Information definiert werden, die nicht mit einem bestimmten Vertex oder Satz von Vertices verknüpft ist (z. B. der Zustandsinformation, die alle folgenden Vertices in dem Block beeinflußt). Der vorher beschriebene globale Farbveränderungsbefehl ist beispielsweise nicht mit einem bestimmten Vertex verknüpft und würde somit als ein Zustandsveränderungsbefehl angesehen. Die Farbinformation kann somit entweder eine Zustandsinformation (z. B. global) oder eine nicht-Zustandsinformation sein (ebenso hier als geometrische Information oder per-Vertexinformation bezeichnet). Eine Anzahl von unterschiedlichen Regeln kann während des Komprimierungsund/oder Dekomprimierungsprozesses angewendet werden, um die lebend/tot-Analyse für die Zustandsinformation zu vereinfachen. In manchen Ausführungsformen kann beispielsweise eine Restriktion eingeführt werden, die verhindert, daß bestimmte oder die gesamte Zustandsinformation (z. B. die Inhalte des transformierten Vertexspeichers) zwischen den Blöcken gemeinsam genutzt werden. Ein Block darf somit nicht auf einer Zustandsinformation beruhen, die von einem vorherigen Block eingestellt wurde. In anderen Ausführungsformen kann die Zustandsinformation jedoch gemeinsam genutzt werden.
Es sei bemerkt, daß die beispielhaften Codierungen, die in den Figuren dargestellt wurden, nur für Erklärungszwecke vorgesehen sind und nicht dafür vorgesehen sind, beschränkend zu sein. Andere Codierungen und Konfigurationen sind möglich und wurden in Betracht gezogen abhängig von der exakten Implementierung. Beispielsweise kann das Multicast/Unicastbit 202 als das erste Feld in dem ersten Datenkörperabschnitt von jedem Block definiert sein. Weiterhin können in manchen Ausführungsformen die Kopfzeilen-Datenkörperpaare zusammenhängend sein statt separiert sein. Der letzte Datenkörperabschnitt (oder der vorletzte usw.) kann definiert sein, so daß er einen bestimmten Befehl enthält, der das nahende Ende des Blockes anzeigt.
Gewerbliche Anwendbarkeit
Ein Graphiksystem und ein Verfahren wurde beschrieben. Die oben beschriebenen Merkmale können einzeln oder in Kombination verwendet werden und können in Software, Hardware oder einer Kombination hieraus realisiert werden. Das System und das Verfahren kann in einer Anzahl von unterschiedlichen Produkten verwendet werden einschließlich Computersystemen, Graphikbeschleunigerkarten, Spielkonsolen, Set-Top-Geräten, tragbare oder in de Hand haltbare elektronische Geräte, graphische Anzeigevorrichtungen, System auf einem Chip-Anwendungen und in anderen Typen von elektronischen Einrichtungen.
Obgleich das System und das Verfahren der vorliegenden Erfindung in Verbindung mit den beschriebenen Ausführungsformen erläutert wurde, ist die Erfindung nicht dafür vorgesehen, auf die spezifischen Formen, die hier ausgeführt wurden, beschränkt zu werden. Im Gegensatz dazu ist die Erfindung dafür vorgesehen, solche Alternativen, Modifikationen und Äquivalente zu umfassen, die vernünftig in den Schutzbereich der Erfindung aufgenommen werden können, wie er durch die angefügten Ansprüche definiert wird.

Claims

Graphisches System (20, 100), das aufweist: eine Steuereinheit (190), die derart konfiguriert ist, daß sie komprimierte 3D-Geometriedaten (208) empfängt, wobei die komprimierte 3D-Geometrie eine geordnete Abfolge von Blöcken (200A–C) aufweist, wobei die Blöcke entweder einfach (242A–C) oder mehrfach (240, 244) sind, und eine Mehrzahl von Dekomprimierern (12), wobei die Steuereinheit derart konfiguriert ist, daß sie Abschnitte der 3D-Geometriedaten zu jedem der Dekomprimierer leitet, wobei die Dekomprimierer derart konfiguriert sind, daß sie 3D-Geometriedaten in ein oder mehrere Vertices (150) dekomprimieren, wobei die Steuereinheit derart konfiguriert ist, „: daß sie die Einfachblöcke zu einem der Dekomprimierer leitet und wobei die Steuereinheit derart konfiguriert ist, daß sie die Mehrfachblöcke zu mehr als einem der Dekomprimierer leitet.
Graphiksystem nach Anspruch 1, wobei die Steuereinheit derart konfiguriert ist, daß sie die Einfachblöcke gemäß eines Belastungsausgleichsschemas weiterleitet.
Graphiksystem nach Anspruch 1 oder Anspruch 2, wobei die Steuereinheit derart konfiguriert ist, daß sie Steuerinformation innerhalb der Mehrfachblöcke detektiert, wobei die Steuereinheit derart konfiguriert ist, daß sie die Steuerinformation verwendet, um zu bebestimmen, welcher der Mehrzahl von Dekomprimierern die Mehrfachblöcke empfangen soll.
Graphiksystem nach Anspruch 1 oder Anspruch 2, wobei die Blöcke ein Mehrfach/Einfach-Bit (202) aufweisen und wobei die Steuereinheit derart konfiguriert ist, daß sie das Mehrfach-/Einfachbit liest, um zu bestimmen, ob ein bestimmter Block ein Mehrfachblock oder ein Einfachblock ist.
Graphiksystem nach einem der Ansprüche 1 bis 4, wobei die Blöcke weiterhin ein Feld fester Länge (204, 260) oder ein Feld variabler Länge (204) aufweisen.
Graphiksystem nach einem der Ansprüche 1 bis 5, wobei die Blöcke weiterhin eine Mehrzahl von Kopf-Hauptteil-Paaren aufweisen, bei der jeder Kopf bzw. Header entwe der den Ort des entsprechenden Hauptteils oder die Länge des entsprechenden Hauptteils anzeigt.
Graphiksystem nach einem der Ansprüche 1 bis 6, wobei jeder Block weiterhin Befehle beinhaltet, die die Zustandsinformation innerhalb der Dekomprimierer einstellt, wobei jeder Dekomprimierer derart konfiguriert ist, daß er die Zustandsinformation benützt, um die geometrischen Daten zu dekomprimieren.
Graphiksystem nach Anspruch 7, wobei die Zustandsinformation zumindest eine Farbzustandsinformation und eine Normalzustandsinformation aufweist.
Graphiksystem nach einem der Ansprüche 1 bis 8, das weiterhin aufweist: eine Mehrzahl von Transformationseinheiten, die jeweils derart konfiguriert sind, daß sie Vertices von einem der Dekomprimierer und ein oder mehrere Einstelleinheiten, die jeweils einen transformierten Vertexspeicher (110, 106) aufweisen, empfangen und transformieren, wobei jede Einstelleinheit derart konfiguriert ist, daß sie die transformierten Vertices empfängt und daraus geometrische Primitive zusammensetzt.
Verfahren für die Dekomprimierung komprimierter 3D-Geometriedaten, wobei das Verfahren aufweist: Empfangen der komprimierten 3D-Geometriedaten (208), wobei die komprimierten 3D-Geometriedaten eine Reihe von Blöcken (200A–C) aufweisen, Untersuchen von zumindest einem Teil von jedem Block, um zu bestimmen, ob der Block ein Mehrfachblock (240, 244) oder ein Einfachblock (242A–C) ist, Leiten von jedem Mehrfachblock zu einer Mehrzahl von Dekomprimierern (12), wobei jeder Dekomprimierer eine einzelne Kopie der Zustandsinformation ablegt, wobei die Mehrfachblöcke dazu dienen, die einzelnen Kopien der Zustandsinformation zu aktualisieren, Leiten jedes Einfachblockes zu einem der Mehrzahl von Dekomprimierern, und Dekomprimieren der Mehrfach- und Einfachblöcke in den Dekomprimierern, um Vertices (150) zu bilden, wobei die Zustandsinformation von jedem Dekomprimierer von dem Dekomprimierer verwendet wird, um die Dekomprimierung durchzuführen.
Verfahren nach Anspruch 10, wobei die Reihe von Blöcken geordnet werden und wobei das Leiten des Einfachblockes gemäß eines Belastungsausgleichsschemas durchgeführt wird.
Verfahren nach Anspruch 10 oder 11, das weiterhin aufweist das Weiterleiten der Vertices zu einem oder mehreren Einstelleinheiten, wobei jede Einstelleinheit einen transformierten Vertexspeicher (106, 110) aufweist, wobei die Einstelleinheiten derart konfiguriert sind, daß sie die Vertices in geometrische Primitive unter Verweundung eines transformierten Vertexspeichers zusammensetzen.
Verfahren nach einem der Ansprüche 10 bis 12, das weiterhin aufweist, das Weiterleiten der Vertices zu einer oder mehreren Einstelleinheiten, wobei jede Einstelleinheit einen transformierten Vertexspeicher aufweist, wobei die Einstelleinheit derart konfiguriert sind, daß sie die Vertices in geometrische Primitive zusammenfügen unter Verwendung eines transformierten Vertexspeichers.
Verfahren nach einem der Ansprüche 10 bis 13, das weiterhin aufweist die Bestimmung der Länge von jedem Mehrfach- und Einfachblock durch Lesen eines Längenfeldes (260, 204) an einem vorbestimmten Ort innerhalb des Blocks oder durch Durchführen eines Rechenprozesses auf einer Untergruppe von Daten in jedem Block.
Verfahren nach einem der Ansprüche 10 bis 14, wobei die Dekomprimierung das Lesen des Paares aus Header und Hauptteil von den Blöcken aufweist, wobei die Headerabschnitte Längeninformationen betreffend die entsprechenden Hauptteilabschnitte enthält, und wobei die Headerabschnitte Längeninformationen betreffend, die entsprechenden Hauptteilabschnitte enthalten und wobei die Header- und Hauptteilabschnitte durch zumindest einen dazwischenliegenden Header-/Hauptteilabschnitt getrennt sind.
Verfahren nach einem der Ansprüche 10 bis 15, wobei die Einfachblöcke eine Per-Vertex-Information aufweisen.
Verfahren nach einem der Ansprüche 10 bis 16, wobei die Dekomprimierszustandsinformation eine Farb- und Transparenzinformation beinhaltet.
Verfahren nach einem der Ansprüche 10 bis 17, wobei jeder Einfachblock Geometriedaten beinhaltet, die ein oder mehrere Vertices beschreiben, wobei jeder Einfachblock einen Restartanzeiger aufweist, der mit den ersten beschriebenen Vertex verknüpft ist, wobei der Restartanzeiger veranlaßt, daß der Dekomprimierer (12) den Einfachblock dekomprimiert, um zumindest einen Teil seiner Dekomprimierungszustandsinformation zurückzusetzen.
Verfahren nach einem der Ansprüche 10 bis 18, das weiterhin aufweist das Garantieren, daß jeder Mehrfachblock, der vor einem bestimmten Einfachblock in der Reihe von Blöcken auftritt nacheinander von jedem der Mehrzahl von Dekomprimierern empfangen wird, bevor irgend ein nachfolgender Block und der bestimmte Einfachblock in der Reihe von Blöcken empfangen wird.
Verfahren nach einem der Ansprüche 10 bis 19, das weiterhin aufweist das Garantieren, daß jeder Mehrfachblock, der vor einem bestimmten Einfachblock in der Reihe von Blöcken auftritt, von jedem der Mehrzahl von Dekomprimierern vor irgendeinem nachfolgenden Block und vor dem bestimmten Einfachblock in der Reihe von Blöcken empfangen wird.
Verfahren für die Komprimierung von 3D-Geometriedaten, wobei das Verfahren aufweist: Empfangen der 3D-Geometriedaten (208), wobei die 3D-Geometriedaten eine Mehrzahl von Vertices (150) aufweisen, Teilen der Mehrzahl von Vertices in Dreiecksgitter basierend auf der xyz-Position der Vertices, Einbetten der Gitterpufferspeicherreferenzen, um die Wiederholung der Vertices in den Gittern zu reduzieren und Formatieren der Gitter in eine Reihe von Blöcken (200A–C), um die parallele Dekomprimierung zu erlauben, wobei eine erste Untergruppe der Blöcke Mehrfachblöcke (240, 244) sind, die derart konfiguriert sind, daß sie zu einer Mehrzahl von parallelen Dekomprimierern (12) geleitet werden, wobei eine zweite Untergruppe der Blöcke Einfachblökke (140A–C) sind, die derart konfiguriert sind, daß sie zu einem einzelnen Dekomprimierer geleitet werden.
Verfahren nach Anspruch 21, wobei die Einfachblöcke die Dekomprimierungszustandsinformation aufweisen und die Mehrfachblöcke Geometriedaten aufweisen, wobei die Mehrfachblöcke, die vor einem bestimmten Einfachblock in der Reihe von Blöcken auftreten, derart konfiguriert sind, daß sie von jedem der Mehrzahl von Dekomprimierern empfangen werden bevor irgendein anderer Block in der Reihe von Blöcken empfangen wird, wobei die Gitterpufferspeicherreferenzen einen Gitterpufferzustand in jedem Dekomprimierer erzeugen, wobei die Gitterpufferzustandsinformation nicht zwischen den Blöcken gemeinsam genutzt wird.
Computerprogramm, das auf einem Trägermedium verkörpert ist, wobei das Computerprogramm eine Mehrzahl von Befehlen aufweist, wobei die Mehrzahl von Befehlen derart konfiguriert ist, daß sie das Verfahren nach einem der Ansprüche 10 bis 22 implementieren.
Computerprogramm nach Anspruch 23, wobei das Trägermedium ein Speichermedium eines Übertragungsmediums ist.