-
Diese Erfindung bezieht sich auf ein Verfahren und eine Einrichtung für die Kompression von Primitivdaten, die durch Tessellation eines Patches in einem dreidimensionalen Computergrafik-Rendering-System generiert werden.
-
Hintergrund der Erfindung
-
Die Tessellation wird für Computergrafiken verwendet, um Unterteilungsflächen mit geringen Detailwerten in Primitive mit größeren Detailwerten umzuwandeln. Die Tessellation löst höherwertige Flächen in geeignete Strukturen für die Wiedergabe auf. Dieser Ansatz ermöglicht es einer Grafikpipeline, Modelle mit geringeren Details (geringerer Polygonanzahl) zu bewerten und sie als Modelle mit mehr Details wiederzugeben. Dies bedeutet, dass eine Fläche, die durch eine höherwertige Gleichung (z. B. kubisch oder quadratisch) definiert ist, zwecks Wiedergabe in eine Vielzahl von flachen Primitiven, typischerweise Dreiecke, geteilt wird.
-
Höherwertige Flächen sind in der Computergrafik-Industrie sehr gut bekannt und oft als „Patches“ bezeichnet. Diese Patches sind Funktionen der polynomischen Gleichungen, die normalerweise eine Gruppe von Kontrollpunkten definieren, welche die Form einer Kurve als parametrisches Verhältnis zwischen einer Variablen ‚t‘ (für eine Kurve, die in zwei Dimensionen ausgedruckt wird) oder zwei Variablen ‚u‘ und ‚v‘ (für eine gekrümmte Fläche in drei Dimensionen) beschreiben.
1 illustriert ein Bezier-Patch als Beispiel einer höherwertigen Fläche, die normalerweise für 3D-Computergrafiken verwendet wird. Ein Punkt ‚P‘ 100 auf einer Bezier-Fläche 110 wird durch die Funktion der Domainkoordinaten u, v 120 (auch als parametrische Koordinaten bekannt) und die jeweiligen Kontrollpunkte k
i,j 130 definiert.
-
Dabei sind A und B Konstanten, die definiert sind als:
-
Es muss beachtet werden, dass die Werte P(u,v) innerhalb des Volumens 140 liegen, das auch als konvexe Hülle bekannt ist, die von den Kontrollpunkten ki,j 130 beschrieben wird. Es muss ebenfalls beachtet werden, dass das Bezier-Patch nur ein Beispiel einer möglichen Flächenformel ist und dass es hier viele andere Möglichkeiten gibt, die in Computer-Grafiksystemen verwendet werden.
-
Die Tessellation ist eine sehr bekannte Technik, die höherwertige Flächen/Patches, wie die, die in 1 gezeigt sind, in eine Reihe angrenzender Primitive, welche auf einer Ebene und innerhalb der Grenzen der Originalfläche liegen, unterteilt. Das Unterteilungsschema des Tessellators wird im Bereich des Patches ausgeführt, wobei typischerweise ein genormtes (null-zu-eins) Koordinatensystem verwendet wird. Die Folge davon ist, dass der Tessellationsprozess unabhängig von einer Krümmung in der endgültigen Fläche ist. Der Bereich des Patches kann viereckig, dreieckig oder eine Gerade sein, und diese Gebiete werden normalerweise in mehrere kleinere Primitive, wie Punkte, Linien oder Dreiecke unterteilt. Diese Primitive sind durch miteinander verbundene Domain-Punkte definiert, deren Anordnung sich nach dem Tessellationsverfahren und den Einstellungen richtet.
-
2 illustriert die Tessellation der Domain-Punkte für ein Bezier-Quad-Patch unter Anwendung eines binären Unterteilungsverfahrens. Das Gebiet 200 mit 16 Domain-Punkten und 0,25 Intervallen auf jeder Achse zeigt die Mindestanzahl der Domain-Punkte innerhalb eines tessellierten Patches, wobei diese Anzahl die gleiche ist wie die Anzahl der Kontrollpunkte, die für die Definition einer Bezier-Fläche erforderlich sind. Eine Tessellationsstufe wird bei 210 angewendet und resultiert in einer weiteren Gruppe Domain-Punkte, die an Intervallen generiert werden, welche an den Mittelpunkten zwischen den ursprünglichen Punktegruppen liegen. In einer zweiten Tessellationsstufe 220 wird eine weitere Punktegruppe am Mittelpunkt zwischen den bei 210 generierten Punkten eingeführt. Dieser Prozess wird wiederholt, bis eine geeignete Tessellationsstufe erreicht ist.
-
Die Tessellationsstufe wird von der Tessellationsanwendung gesteuert und kann durch visuelle Qualitätsmetriken ermittelt werden, um festzustellen, wie viele Polygone erforderlich sind, um eine gekrümmte Oberflläche in einer bestimmten Entfernung von der Kamera gleichmäßig aussehen zu lassen. Alternativ kann die angewandte Tessellationsstufe mit Hilfe eines Computers bestimmt werden, wobei stärkere Systeme höhere Tessellationsstufen verwenden, um die visuelle Qualität zu verbessern. Es sollte beachtet werden, dass eine binäre Unterteilung nur ein mögliches Tessellationsverfahren darstellt und hier lediglich als Beispiel präsentiert wird.
-
Das Direct3D11 (D3D11) Application Programming Interface (API) von Microsoft führt mit der Grafikpipeline eine programmierbare Alternative zur binären Unterteilung für die Tessellation ein, die für die Darstellung in diesem Dokument verwendet wird. Andere APIs, wie OpenGL 4.0, verfügen über eine ähnliche Funktionalität für die Tessellation höherwertiger Flächen. Diese Programmierschnittstellen werden oft durch die Hardware beschleunigt. 3 illustriert die Grafikpipeline, die für die D3D11-API erforderlich ist. Eine Vertex-Shader-Stufe 300 erfasst eine Gruppe individueller Kontrollpunkte für ein Patch und wendet mit Hilfe einer programmierbaren Hardware eine beliebige mathematische Transformation an, auf eine Art und Weise, die dem Fachmann gut bekannt ist. Die transformierten Kontrollpunkte werden dann auf einen Hull-Shader 310 übertragen, der die Tessellationsfaktoren für die Kanten des Patches berechnet und weitere anwendungsdefinierte Änderungen an den Kontrollpunkten durchführt.
-
Die Kantentessellationsfaktoren für das Patch werden dann auf eine Tessellationseinheit 320 übertragen. Die Tessellation finden in zwei Teilen statt: Domain-Tessellation und Konnektivitäts-Tessellation. Die Domain-Tessellation unterteilt das Patch in eine Anzahl von Punkten, die als Domain-Punkte bekannt sind. Die Anordnung dieser Domain-Punkte richtet sich nach dem Tessellationsverfahren und den Tessellationsparametern, die in der in 2 beschriebenen Weise geliefert wurden, jedoch benötigen Verfahren, wie jene, die von der D3D11-API vorgeschrieben sind, nicht, dass die Domain-Punkte in gleichmäßigen Intervallen (z. B. Zweierpotenz) angeordnet sind. Die Konnektivitäts-Tessellation ermittelt, wie die resultierenden Domain-Punkte kombiniert werden, um tessellierte Primitive zu erzeugen, die einem festen Funktionsalgorithmus, dessen Operation von der D3D11-API definiert ist, entsprechen. Eine detaillierte Beschreibung der festen Funktionsdomain und der Konnektivitäts-Tessellationsalgorithmen sprengt den Umfang dieses Dokuments und wird umfassend durch die APIs definiert, was dem Fachmann gut bekannt ist.
-
Die tessellierten Domain-Punkte werden auf einen Domain-Shader 330 übertragen, der diese mit den Kontrollpunkten des Patches, das der Hull-Shader durch Programmierung produziert hat, kombiniert. Normalerweise würde der Domain-Shader eine bekannte Formel für eine gekrümmte Fläche, wie beim Bezier-Patch (wie in 1 oben beschrieben) anwenden, was dazu führt, dass die Domain-Punkte auf dem Patch abgebildet werden, um Primitivscheitelpunkte zu erstellen. Die resultierenden Scheitelpunkte können dann später mit bekannten Techniken wie dem Displacement Mapping geändert werden. Das Displacement Mapping ist eine Technik, bei der die Ergebnisse der höherwertigen Flächen-Tessellation durch eine mathematische Funktion oder eine Höhe, die einer Texturabbildung entnommen wird, verschoben werden. Die Einführung von Displacement Mapping von Scheitelpunkten aus einer Patch-Fläche ermöglicht, dass die Scheitelpunkte nicht länger innerhalb der von den Kontrollpunkten des Patches definierten konvexen Hülle verbleiben.
-
Zu Darstellungszwecken werden Ausführungsformen der Erfindung in Bezug auf die Tessellation innerhalb eines kachelbasierten Rendering-Systems beschrieben, obwohl die offenbarten Verfahren auf nicht gekachelte Systeme ebenfalls anwendbar sind. Kachelbasierte Rendering-Systeme sind sehr gut bekannt. Diese Architekturen unterteilen ein Bild in eine Vielzahl von rechteckigen Blöcken oder Kacheln. 4 illustriert die Architektur eines typischen kachelbasierten Systems, einschließlich der Textur- und Schattierungsstufen.
-
Das kachelbasierte Rendering teilt sich im Allgemeinen in zwei Phasen auf, wobei die erste als Geometrie-Verarbeitungsphase 490 bekannt ist, in der folgende Operationen ausgeführt werden.
-
Zuerst ruft eine Primitiv-/Befehl-Abrufeinheit 400 einen Befehl und Primitivdaten aus einem externen Speicher auf und überträgt diese auf einen Vertex-Shader Unit 401. Die Primitiv- und Befehlsdaten werden dann mit bekannten Verfahren, wie Clip/Cull und Projektion, wie in den Blöcken 402 und 403 gezeigt, auf einen Bildschirmraum übertragen.
-
Die Daten werden dann an die Kacheleinheit 410 weitergegeben, die Objektdaten für jede Gruppe von definierten rechteckigen Bereichen oder Kacheln aus der Bildschirmraumgeometrie in Objektlisten einsetzt. Eine Objektliste für jede Kachel enthält Primitive, die in der jeweiligen Kachel ganz oder teilweise vorhanden und im gekachelten Bildschirmraum-Geometriepuffer 420 gespeichert sind. Es gibt für jede Kachel eine Objektliste auf dem Bildschirm, auch wenn bestimmte Objektlisten keine Daten enthalten können. Es ist auch möglich, ein System zu verwenden, in dem anstatt das Objekt zur Kachelung auf das Koordinatensystem des Bildschirms zu übertragen, die Kachel in das Koordinatensystem des Objekts übertragen und die Kachelung in dieser Domain durchgeführt wird. Jedes normale Koordinatensystem zwischen der Kachel und der Geometrie kann zu diesem Zweck verwendet werden.
-
Die zweite Phase des kachelbasierten Rendering wird als Rasterungsphase 491 bezeichnet, in der folgende Operationen durchgeführt werden.
-
Die von der Kacheleinheit generierten Objektlisten werden vom gekachelten Bildschirmraum-Geometriepuffer über eine Kachel-Parameter-Abrufeinheit 430 gelesen, welche Kachel für Kachel auf eine Hidden Surface Removal-Einheit (HSR) [Entfernen der Rückseite] überträgt. Die HSR Einheit entfernt die Rückseiten, die nicht zur finalen Szene beitragen (normalerweise, weil sie nicht von einer anderen Fläche verdunkelt werden), indem jedes Primitiv in der Kachel verarbeitet wird und nur Daten übertragen werden, die für eine Shading-Einheit 450 sichtbar sind.
-
Die Shading-Einheit übernimmt die Daten aus der HSR-Einheit und verwendet sie, um mit Hilfe der Texturierungseinheit 460 Strukturen abzurufen und mit bekannten Techniken jedes Pixel innerhalb des sichtbaren Objekts zu schattieren. Dann führt die Shading-Einheit die strukturierten und schattierten Daten dem auf einem Chip befindlichen Kachelpuffer 470 zu. Da die Operationen auf einem Kachelpuffer, welcher sich auf einem Chip befindet, ausgeführt werden, wird die Menge des erforderlichen Datenverkehrs extern zum Chip minimiert.
-
Wenn alle Kacheln vollständig sind, werden die resultierenden Daten in einen gerenderten Szene-Puffer 480 geschrieben.
-
Herkömmliche Systeme ohne Tessellation approximieren normalerweise die Geometrie, z. B. gekrümmte Flächen, die nur eine begrenzte Anzahl Polygone haben, um eine akzeptable Leistung beizubehalten. Die häufigste Tessellationsanwendung besteht darin, das Patch als eine kompakte Darstellung einer größeren Anzahl von Polygonen zu verwenden, was sonst nicht machbar wäre. Die kompaktere Darstellung hat den wesentlichen Vorteil, dass sie die Bandbreite auf der Stufe Primitiv-/Befehl-Abruf (400) reduziert.
-
Das Kacheln einer Gruppe von Primitiven, wie jene, die auf einem Patch generiert werden, wird häufig durch Kachelung einer Bounding Box für eine Gruppe durchgeführt. Dies kann erheblich weniger Berechnung erfordern, als notwendig wäre, um jedes einzelne Primitiv separat zu kacheln. Die konvexe Hülle bildet oft die Basis einer geeigneten Bounding Box für die auf der Fläche des Patches generierten Primitive; da jedoch das Displacement Mapping ermöglicht, die Primitivscheitelpunkte über die Trennungslinien der konvexen Hülle des Patches hinaus zu erweitern, ist dies nicht immer ein geeignetes Verfahren für die Verwendung mit der D3D11 -API.
-
Das herkömmliche Verfahren, die programmierbare Tessellation höherwertiger Flächen einer kachelbasierten Rendering-Architektur hinzuzufügen, besteht darin, zuerst jedes Patch in der Szene in Primitive aufzusplitten und dann das Displacement Mapping anzuwenden. Die resultierenden Primitive können anschließend gekachelt und mit einer herkömmlichen kachelbasierten Rendering-Pipeline verarbeitet werden. Obwohl dieser Ansatz einfach ist, müssen die Patch-Daten in den früheren Stufen der Grafikpipeline auf viele Primitive erweitert werden. Diese Datenexpansion erhöht erheblich die Anforderungen an den Speicher und die Bandbreite, die mit dem gekachelten Bildschirmraum-Geometriepuffer (420) im Zusammenhang stehen, macht alle Vorteile zunichte, die mit Primitiv-/Befehl-Abruf erzielt wurden und benachteiligt das kachelbasierte System im Vergleich zu einer nicht gekachelten Architektur, die keinen gekachelten Bildschirmraum-Geometriepuffer verwendet. Es ist daher wünschenswert, dass vor dem Kacheln eine vollständige Datenexpansion vermieden wird, um stattdessen Patches zu speichern und ein Verfahren anzuwenden, bei dem Primitive aus diesen Patches generiert werden.
-
Ein effizienteres Verfahren, bei dem die Tessellation höherwertiger Patches einer kachelbasierten Rendering-Architektur hinzugefügt wird, ist in unserer britischen Patentanmeldung Nr. 1007348.3 beschrieben und wird in 5 schematisch dargestellt. Bei diesem verbesserten Zwei-Pass-System wird die Geometrie-Verarbeitungsphase 590 der Rendering-Pipeline erweitert, um festzustellen, ob die Polygone, die während der Tessellation eines Patches erstellt werden, ganz oder teilweise in einer Kachel vorhanden sind. Es heißt, dass ein Polygon in einer Kachel vorhanden ist, wenn die endgültige Position in der Szene innerhalb des sichtbaren Bereichs dieser Kachel liegt. Ein Polygon ist zur Gänze in der Kachel vorhanden, wenn seine Position in der Szene vollständig im sichtbaren Bereich einer Kachel liegt. Ein Polygon ist in einer Kachel teilweise vorhanden, wenn mindestens ein Teil des Polygons im sichtbaren Bereich der Kachel liegt. Polygone, die ganz oder teilweise in einer Kachel liegen, können ganz oder teilweise in der Kachel sichtbar oder in der endgültigen Szene überhaupt nicht zu sehen sein, wenn sie von anderen Polygonen verdeckt werden. Optional können verdeckte Polygone, die ganz oder teilweise in der Kachel vorhanden sind, in der Liste der Polygone ermittelt und daraus entfernt werden. Wenn ein oder mehrere Polygone eines Patches ganz oder teilweise in einer Kachel vorhanden sind, werden statt der Polygone die Patches in den Objektlisten für die Kacheln gespeichert. Beachten Sie, wenn nur eine geringe Anzahl von Polygonen des Patches sichtbar sind, kann es wünschenswert sein, die Polygone zu speichern, um die Datenmenge zu minimieren. Dieser Prozess der Zuweisung von Geometrie innerhalb einer Kachel wird im Allgemeinen als „Kachelung“ oder „Gruppierung“ bezeichnet.
-
Ein erster Tessellationsdurchlauf erfolgt auf die Patch-Daten, und die Anordnungen der tessellierten Primitive aus jedem Patch werden durch Anwendung des Vertex Shading und des Hull-Shading ermittelt. Wenn eine der bei der Tessellation eines Patches erzeugten Primitive in einer Kachel vorhanden ist, muss dieses Patch in die Objektliste dieser Kachel im gekachelten Bildschirmraum-Geometriepuffer eingefügt werden. Werden nur der Satz von Patch-Kontrollpunkten und die Tessellationsparameter, die erforderlich sind, um die Tessellation in der Rasterungsphase zu wiederholen, gespeichert, wird die im gekachelten Bildschirmraum-Geometriepuffer gespeicherte Datenmenge im Vergleich zur Datenmenge, die erforderlich gewesen wäre, um die nach der Tessellation entstandene Primitivgeometrie zu speichern, erheblich reduziert. Es muss beachtet werden, dass die Patch-Kontrollpunkte gespeichert werden können, nachdem Vertex- und Hull-Shading durchgeführt wurden, damit diese Teile der Tessellationsberechnung während der Rasterung nicht wiederholt werden.
-
Da die komplette Tessellation während des Kachelungsprozesses durchgeführt worden ist, ist es auch möglich, eine Liste der Patch-Primitiven, die ganz oder teilweise nach der Tessellation in der Kachel vorhanden sein werden, zu speichern. Diese Liste macht es möglich, von jedem Patch nur die Primitive erneut herzustellen, die in einer Kachel für eine spätere Tessellationsverarbeitung notwendig sind.
-
Die Vertex-Shader-Einheit 501 und die Hull-Shader-Einheit 502 funktionieren wie oben beschrieben in einer standardmäßigen D3D11-Tessellationspipeline. Die Hull-Shader-Einheit überträgt die berechneten Tessellations-Kantenfaktoren sowohl auf die Domain- Tessellationseinheit 503 als auch auf die Konnektivitäts-Tessellationseinheit 504, und ebenso die verarbeiteten Kontrollpunktdaten auf die Domain-Shader-Einheit 505.
-
Die Domain-Tessellationseinheit generiert Domain-Punkte mit den zugehörigen Domain-Punkt-Indexwerten, und die Domain-Punkt-Konnektivitäts-Tesselationseinheit spezifiziert eine Liste mit Domain-Punkt-Indizes von einem Patch, diese wiederum spezifizieren Primitivindizes und legen die Reihenfolge fest, in der sie verbunden werden müssen, um Primitive zu generieren.
-
Die Primitivscheitelpunkte werden auf eine optionale Cache Einheit 506 übertragen, und die Primitivscheitelpunkte, die zuvor von der Domain-Shader-Einheit generiert wurden, zwischenspeichert. Es muss beachtet werden, dass der Cache nicht erforderlich ist, dass jedoch der Vernetzungsgrad der Primitive, die das tessellierte Patch ausmachen, bedeutet, dass ein vorhandener Cache die Anzahl der Primitiv-Scheitelpunkte, die von der Domain-Shader-Einheit verarbeitet werden, erheblich reduzieren kann. Wenn ein Primitiv-Vertex nicht in einem Cache vorhanden ist, wird er von der Domain-Shader-Einheit angefordert.
-
Die Domain-Shader-Einheit verarbeitet nur den Positionsteil der Daten vom Primitiv-Vertex, da dies der einzig erforderliche Teil ist, um die tessellierte Geometrie zu kacheln. Die Cache-Einheit gibt die Primitivscheitelpunkte, die sich aus den Primitiven ergeben, an die Clipping und Culling Einheit 510 weiter, welche alle Primitive außerhalb des sichtbaren Bildschirmbereichs entfernt und optional rückseitige und/oder sehr kleine Primitive, die sich zwischen zwei Probenpositionen befinden, entfernt. Es muss beachtet werden, dass die Clipping- und Culling-Operationen die regelmäßige Folge der aus tessellierten Patches generierten Primitive unterbrechen, und dass dies die Leistung der nachfolgenden Kompressionsoperationen beeinträchtigen kann. Daher kann optional das Clipping und Culling auf eine spätere Stufe in der Pipeline verschoben werden.
-
Verbleibende Primitive werden an die Projektionseinheit 511 weitergeleitet, die die übrigen Primitive/Primitiv-Scheitelpunkte auf den Bildschirmraum überträgt, damit sie von der Kachelungseinheit 512 gekachelt werden. Die Kachelungseinheit ermittelt, welche Primitive ganz oder teilweise in jeder Kachel vorhanden sind und übermittelt eine Liste der Domain-Punkt-Indizes, welche die Primitiv-Scheitelpunkte beschreibt, an eine optionale Index-Kompressionseinheit 513.
-
Ausführungsformen dieser Erfindung sind unter Bezugnahme auf das in der Index-Kompressionseinheit 513 verwendete Kompressionsverfahren beschrieben. Diese Einheit ist für die effiziente Kompression der Domain-Punkt-Indexliste verantwortlich, die für die Definition der Primitive, welche in jeder Kachel enthalten sind, verwendet wird, damit eine komprimierte Primitivliste erstellt wird. Diese Kompression verringert die Menge an Daten, die in die Geometrielisten der einzelnen Kacheln geschrieben werden und reduziert die Anforderungen an die Speicherung und Bandbreite.
-
Dann wird ein Rückbezug auf den Hull-Shader Output und die komprimierten Primitivlisten in den Gekachelten Bildschirmraum-Geometriepuffer 514 geschrieben.
-
Spätere Phasen in der Pipeline können den Hull-Shader Output verwenden, um jene Primitive zu regenerieren, die sich ganz oder teilweise in der aktuellen Kachel befinden. Primitive aus einem tessellierten Patch, die nicht ganz oder teilweise in der aktuellen Kachel vorhanden sind, müssen im Tessellationsprozess nicht erstellt werden.
-
Die vorliegende Erfindung stellt ein effizientes Kompressionsschema für die Domain-Punkt-Indexlisten bereit, die aus der Kachelung der tessellierten Geometrie stammen.
-
Es gibt bereits verschiedene Kompressionsschemata, um die für die Speicherung der Geometrie erforderliche Datenmenge zu reduzieren. Das geläufigste Schema darunter ist die Verwendung von Dreieckstreifen. Ein Dreieckstreifen ist ein effizientes Verfahren, um verbundene Dreiecksprimitive mit gleichen Scheitelpunkten zu beschreiben. Nachdem das erste Dreieck mit Hilfe von drei Scheitelpunkten definiert wurde, kann jedes neues Dreieck nur durch einen zusätzlichen Vertex definiert werden, indem es die beiden letzten Scheitelpunkte, die für das vorherige Dreiecksprimitiv definiert wurden, ebenfalls verwendet. 6 illustriert ein Beispiel eines Dreieckstreifens, der aus vier verbundenen Dreiecksprimitiven besteht. Ohne die Verwendung von Dreiecksstreifen würde die Indexliste für vier getrennte Dreiecke gespeichert: ABC, CBD, CDE, EDF. Unter Verwendung eines Dreieckstreifens können diese jedoch als eine Abfolge der Scheitelpunkte ABCDEF gespeichert werden. Diese Abfolge würde dann als Dreiecksgruppe ABC, BCD, CDE und DEF dekodiert, dann würde jedes geradzahlige Dreieck (die Zählung beginnt bei eins) reversiert, so dass sich eine konsistente Reihenfolge im Uhrzeigersinn/gegen den Uhrzeigersinn der ursprünglichen Dreiecksprimitive ergeben würde.
-
Dreieckstreifen sind in der Lage, die langen Durchläufe der benachbarten Dreiecke effizient zu komprimieren, sind jedoch bei einer komplexeren Geometrie weniger effektiv. Die durch das Kacheln der tessellierten Patches generierte Geometrie enthält Strukturen, die die Effizienz der Dreiecksstreifenkompression reduzieren, z. B. wenn mehrere Dreiecke einen gemeinsamen Vertex haben, was als Dreiecksfächer bekannt ist, wenn Änderungen in der Vertex-Reihenfolge im Uhrzeigersinn/gegen den Uhrzeigersinn der Dreiecksprimitive vorhanden sind und wenn Dreiecke nach dem Kachelungsprozess fehlen. 7 illustriert eine typische Niedrigstufen-Tessellation eines Dreiecks-Patches in Dreiecksprimitive. Es ist sichtbar, dass die tessellierte Geometrie mehrere Dreiecksfächer und mehrere Änderungen der Dreiecksfolge enthält, die ungeeignet sind, um mit Dreiecksstreifen eine effiziente Kompression durchzuführen. Werden einige der Dreiecksprimitive aus dem tessellierten Patch (als Ergebnis der Kachelung) entfernt, ist es möglich, dass sich die Effizienz der Dreiecksstreifen als Kompressionsverfahren weiter verschlechtert.
-
Vertexpuffer und Indexpuffer sind in der Computergrafik gut bekannt. Zur Veranschaulichung sind in 23 ein Beispiel einer Indexpufferkompression und ein bekanntes Verfahren, um einen Indexstrom zu komprimieren, zu sehen. Die Listen der Indizes kürzlich angesehener Primitive sind in einem Indexpuffer 2320 gespeichert. Beim Hinzufügen eines neuen Primitivs werden die unkomprimierten Domain-Punkt-Indizes des Primitivs 2310 mit den Inhalten 2330 des Indexpuffers verglichen. Ein Indexwert, der bereits im Indexpuffer vorhanden ist, kann durch eine vorhandene Pufferposition dargestellt werden, die den gesamten Indexwert speichert. In der Annahme, dass sich die Position im Indexpuffer mit weniger Bits als dem Indexwert selbst beschreiben lässt, ist die Kompression erreicht 2390.
-
Beachten Sie ein ausgearbeitetes Beispiel in 6, das mit einem Indexpuffer komprimiert wurde. Es wird ein erstes Primitiv ABC eingelesen. Keiner dieser Indizes ist im Puffer vorhanden, bevor das Primitiv gefunden wird. Diese Indizes müssen daher vollständig angegeben und verwendet werden, um den Puffer zu initialisieren. Nach der Initialisierung enthält die Pufferposition 0 den Index A, die Pufferposition 1 den Index B und die Pufferposition 2 den Index C. Es kann eine Bezeichnung in eckiger Klammer verwendet werden, um die Position im Puffer anzugeben: [0]=A, [1]=B, [2]=C. Das zweite Primitiv CBD kann jetzt als zwei Indexpufferpositionen und den neu aufgetretenen Index definiert werden: D:[2][1]D. Sobald der Puffer voll ist, können die neu ankommenden Indizes mit Hilfe einer Ersetzungsrichtlinie, wie first-in first-out (FIFO) oder least recently used (LRU), in den Puffer eingegeben werden. Vertex-/Indexpuffer weisen ein effizientes Kompressionsverfahren für zuvor aufgetretene Indizes auf, jedoch erfordert normalerweise jedes Primitiv mindestens einen Index, der nicht von früheren Primitiven stammt und nicht im Puffer vorhanden ist.
-
Speziell in Bezug auf die Kompression einer tessellierten Geometrie, haben Jon Hasselgren, et al. ein alternatives Verfahren, den Bounding-Box Ansatz („Automatic Pre-Tessellation Culling“, ACM Trans, on Graph., Band 28, Seite 19 (2009) vorgeschlagen, mit dem ermittelt werden kann, welche Polygone in jeder Kachel vorhanden sein können. Dieser Ansatz bedient sich der Intervallmathematik, um für jedes Patch den Bereich der möglichen Verschiebungen vom Basis-Patch festzustellen, den die tessellierte Fläche aufweisen könnte, wenn die Tessellation durchgeführt würde. Wird dieser Bereich möglicher Verschiebungen verwendet, kann eine konservative Bounding Box um das Patch gebildet werden, die alle möglichen Anordnungen der Primitive des Patches beschreibt. Die Bounding Box kann dann projiziert und gekachelt werden, um festzustellen, in welchen Kacheln das Patch entweder ganz oder teilweise nach der Tessellation vorhanden sein könnte. Während dieses Verfahren die Notwendigkeit des Speicherns der verlängerten Primitiv-Geometrie für das tessellierte Patch reduziert, führt die konservative Natur der Bounding Boxes dazu, dass Patches, die in den Kacheln enthalten sind, nach der Tessellation weder ganz noch teilweise vorhanden sind. Darüber hinaus kann eine Bounding Box eines Patches nur spezifizieren, dass die von einem Patch abgetrennten und tessellierten Primitive nach erfolgter Tessellation in einer Kachel vorhanden sein können und bedeutet, dass in einigen Kacheln unnötige Patches enthalten sind. Diese unnötigen Patches führen zu einer vergeudeten Berechnung und später in der Grafikpipeline zu einer vergeudeten Wiedergabe. Das Bounding Box-Verfahren kann ebenfalls nicht ermitteln, welche Primitive aus dem tessellierten Patch in jeder Kachel vorhanden sind und führt daher eine weniger optimale Kachelung durch als ein Verfahren, das jedes Primitiv aus dem tessellierten Patch individuell berücksichtigt. Die Berechnung enger Positions- und normaler Grenzen reduziert die Größe der Bounding Box der tessellierten Primitive und kann daher verwendet werden, um die Anzahl der eingeschlossenen Kacheln zu minimieren. Die Berechnung von Grenzen eines tessellierten Patches nach der Verschiebung durch eine Funktion und optionale weitere Displacement Mapping-Prozesse ist jedoch ein intensiver Berechnungsprozess, und das Ergebnis tendiert in Richtung infiniter Grenzen für komplexe benutzerprogrammierbare Funktionen, die schwierig einzugrenzende Bedingungen, wie Random Noise-Funktionen, enthalten.
-
In der Nichtpatentliteratur finden sich weitere Fundstellen zur dreidimensionalen Modellanalyse und -verarbeitung (YU, Faxin et al., Three-Three-Dimensional Model Analysis and Processing, Springer, 2010. - ISBN: 978-3-642-12650-5) sowie zur Kompression von dichten, regulären Punktewolken (MERRY, Bruce; MARAIS, Patrick; GAIN, James: Compression of dense and regulär point clouds. In: Proceedings of the 4th international conference on Computer graphics, virtual reality visualisation and interaction in Africa. 2006. S. 15-20).
-
Zusammenfassung der Erfindung
-
Ausführungsformen dieser Erfindung stellen ein effizientes Verfahren und eine Vorrichtung für die Kompression einer sichtbaren Primitiv-Indexliste bereit, die durch Kachelung einer tessellierten Geometrie generiert wird.
-
Im Vergleich zu den ursprünglichen Patch-Daten und aufgrund der Datenexpansion im gekachelten Bildschirmraum-Geometriepuffer machen es die Tessellation aller in der Szene vorhandenen Patches in die Bestandteile der Primitive und die Anwendung des Displacement Mapping vor der Kachelung notwendig, sowohl die Anforderungen an den Speicher als auch an die Bandbreite erheblich zu erhöhen. Ein Patch kann jedoch während der Kachelungsphase tesselliert werden, um zu ermitteln, welche Primitive ganz oder teilweise in einer Kachel vorhanden sind. Anstatt eine große Anzahl von Primitiven, die aus der Tessellation stammen, zu speichern, können die Kacheln den Basis-Patch und solche Tessellationsparameter speichern, die notwendig sind, um das Patch aufzusplitten und ebenfalls eine Liste mit jenen Primitiven, die im Tessellationsprozess erstellt wurden und in jeder einzelnen Kachel vorhanden sind. Wenn keines der Primitive, das bei der Tessellation eines Patches entsteht, ganz oder teilweise in der Kachel vorhanden ist, muss das Patch nicht in dieser Kachel gespeichert werden. Im Vergleich zur Speicherung vollständig tessellierter Primitive der einzelnen Patches, reduziert diese Technik die Anforderungen an den Speicher und die Bandbreite ganz erheblich. Weitere Reduzierungen bei den per-Kachel Geometriedaten lassen sich durch Kompression der Liste mit den Primitiven des Patches, der ganz oder teilweise in der Kachel vorhanden ist erzielen, und die Daten werden dann im gekachelten Bildschirmraum-Geometriepuffer gespeichert.
-
Es ist nur bei einigen der Primitive eines tessellierten Patches üblich, dass sie ganz oder teilweise in einer Kachel vorhanden sind. Primitive eines Patches können in einer Kachel nicht vorhanden sein, weil sie stattdessen in einer anderen Kachel untergebracht oder weil sie von anderen Objekten/Primitiven verdeckt sind, weil aufgrund der Ausrichtung (back-face culling) die Funktion Clip/Cull angewandt wurde oder weil sie außerhalb des sichtbaren Schirmbereichs liegen. Die Liste der Primitive, die in einer Kachel vorhanden sind, ist daher eine Teilmenge der Gesamtanzahl an Primitiven der Menge, die durch Tessellation eines Patches entstanden sind (wobei die Teilmenge jedes Primitiv der Menge enthalten kann). Trotz der Möglichkeit, dass in der Liste von Primitiven, die in einer Kachel vorhanden sind, beliebig viele Primitive in einem Patch fehlen können, scheinen reale Ergebnisse Lokalität aufzuweisen, d. h. wenn ein Primitiv in einer Kachel vorhanden ist, besteht die Wahrscheinlichkeit, dass benachbarte Primitive ebenfalls in der gleichen Kachel vorhanden sind. Es muss beachtet werden, dass diese Lokalität optional durch Anwendung von Clip/Cull Operationen vergrößert werden kann, die vermeiden, dass isolierte Primitive aus einem tessellierten Patch entfernt werden. Mit Hilfe des Lokalitätsprinzips und des Wissens über die zugrundeliegende tessellierte Geometrie der Fläche ist es möglich, eine effizientere Kompression der Liste mit Primitiven, die in einer Kachel vorhanden sind, zu erreichen, als mit der Anwendung eines laienhaften Kompressionsschemas.
-
Eine Teilmenge von Primitiven eines tessellierten Patches kann als Indexliste, die diese Primitive definiert, gespeichert werden. Ohne Kompression ist die Anzahl der Indizes, die für die Definition eines Primitivs notwendig sind, gleich der Anzahl der in diesem Primitiv vorhandenen Scheitelpunkte, d. h. eine Gerade ist definiert durch zwei Scheitelpunkte, und ein Dreieck durch drei Scheitelpunkte. Ein erster Aspekt dieser Erfindung ist ein neuartiges Kompressionsschema, das nicht nur die Indizes des/der vorherigen Primitiv/Primitive in einem Indexpuffer speichert, sondern einen oder mehrere prognostizierte Indexwerte hinzufügt, die für die Definition der nachfolgenden Primitive verwendet werden können. In einem beliebigen Netz ist es nicht möglich, Indexwerte, die für das nächste Primitiv erforderlich sind, exakt vorherzusagen; die Kenntnis der internen Struktur eines tessellierten Patches ermöglicht jedoch die Generierung nützlicher, prognostizierter Indexwerte, die in den Indexpuffer aufgenommen werden können. Dieses Verfahren wird als „Indexpufferkompression mit Prognose“ bezeichnet.
-
Ein zweiter Aspekt dieser Erfindung wird in einer zweiten Stufenkompression des Ergebnisses aus der Indexpufferkompression mit Prognose ausgeführt. In Bereichen, in denen der in den Indexpuffer aufgenommene Prognosewert korrekt ist, haben die Indexpuffer-Zugangsmuster eine wiederholende Struktur. Diese wiederholenden Puffer-Zugangsmuster entstehen durch die zugrunde liegende Geometrie und die exakten Prognosen, die von der offenbarten Indexpufferkompression mit Prognoseverfahren generiert werden. Das Auftreten der wiederholenden Muster selbst lässt sich komprimieren, indem Pufferzugangsmuster definiert werden, die wiederholend sind und die Anzahl der Wiederholungen dieser Muster wiederholt wird. Bei langen Durchläufen der Wiederholung der Pufferzugangsmuster, die in der Indexpufferkompression mit Prognose hoch tessellierter Patches üblich sind, kann diese „Pufferzugangsmusterkompression“ die Menge der Geometriedaten, die in jeder Kachel gespeichert werden müssen, erheblich reduzieren.
-
Ein dritter und abschließender Aspekt dieser Erfindung ist die Kompression der verbleibenden Indizes, die nicht im Puffer vorhanden waren, da sie sich nicht in den vorherigen Primitiven befanden und vom ersten Aspekt dieser Erfindung nicht exakt prognostiziert wurden. Diese vollständigen Indexwerte können im ersten Primitiv eines Patches auftreten oder dort, wo Primitive des Patches fehlen, weil sie weder ganz noch teilweise in einer Kachel vorhanden sind. Domain-Punkt-Indizes können als Basisindentifikatorkomponente gespeichert werden, die die geometrische Struktur identifiziert, in der eine Vielzahl von Scheitelpunkten vorhanden sind und eine Verschiebung der geometrischen Struktur, die den geforderten Vertex und seinen Domain-Punkt-Index identifiziert. Mehrere Indizes in der gleichen geometrischen Struktur lassen sich daher anhand eines einzigen Basisidentifikatorwertes beschreiben, und mehrere Offset-Werte und ein Mindestanzahl von Bits können sowohl für den Basisidentifikator als auch für die Offset-Komponenten verwendet werden.
-
Figurenliste
-
Bevorzugte Ausführungsformen der Erfindung sind nachstehend anhand von Beispielen und unter Bezugnahme auf die beiliegenden Zeichnungen detailliert erläutert.
- 1 - zeigt ein Bezier-Patch.
- 2 - illustriert den Tessellationsprozess unter Anwendung einer binären Unterteilung;
- 3 - illustriert die D3D11-programmierbare Tessellationspipeline;
- 4 - zeigt eine schematisches Diagramm eines bekannten kachelbasierten Rendering-Systems;
- 5 - illustriert die Geometrie-Verarbeitungsphase eines kachelbasierten Rendering-Systems, das erweitert wurde, um eine programmierbare Tessellation einzuschließen.
- 6 - illustriert einen beispielhaften Dreieckstreifennetz;
- 7 - illustriert ein D3D11-Dreiecks-Patch, das Dreiecksprimitive verwendet und durch ungerade Partitionierung, minimale interne Reduktion und Tesselationskantenfaktoren von 4, 10 und 50 erstellt wurde.
- 8 - illustriert ein tesselliertes D3D11-Quad-Patch, das Dreiecksprimitive mit Domain-Punkt-Indexierung verwendet und durch ungerade Partitionierung und einen auf alle Kanten angewandten Tessellationsfaktor von 3 erstellt wurde;
- 9 - illustriert ein tesselliertes D3D11-Quad-Patch, das Dreiecksprimitive mit Primitivindexierung verwendet und durch ungerade Partitionierung und einen auf alle Kanten angewandten Tessellationsfaktor von 3 erstellt wurde;
- 10 - illustriert ein tesselliertes D3D11-Patch, das Linienprimitive mit Domain-Punkt-Indexierung verwendet und durch ungerade Partitionierung und einen auf Detail/Dichte, d. h. horizontale/vertikale Kanten angewandten Tessellationsfaktor 3 erstellt wurde.
- 11 - illustriert ein tesselliertes D3D11-Patch, das Linienprimitive mit Primitivindexierung verwendet und durch ungerade Partitionierung und einen auf Detail/Dichte, d. h. horizontale/vertikale Kanten angewandten Tessellationsfaktor von 3 erstellt wurde;
- 12 - illustriert die Kachelung eines D3D11-tessellierten Quad-Patches in einem schattierten Kachelbereich;
- 13 - illustriert, wo ein Primitiv, das nicht ganz oder teilweise in einem schattierten Kachelbereich vorhanden ist, während der Konnektivitätsneuberechnung aus einer sortierten Liste mit Primitivindizes in der Kachel enthalten ist.
- 14 - illustriert die Kompression eines D3D11-tessellierten Quad-Patches unter Verwendung eines Indexpuffers, der die Domain-Punkt-Indizes des vorherigen Primitivs enthält;
- 15 - illustriert die Prognose des nächsten Domain-Punkt-bei der Tessellation eines D3D11-Linienprimitivs eines Quad-Patches;
- 16 - illustriert die Prognose des nächsten Domain-Punkt-bei der Tessellation eines D3D11-Linienprimitivs eines Quad-Patches, wenn eine neue Zeile gefunden wird;
- 17 - illustriert die Ringstruktur von Domain-Indizes in einem D3D11-tessellierten Quad-Patch;
- 18 - illustriert die Prognose des Domain-Punkt-Index des nächsten Domain-Punkt-bei der D3D11-Tessellation eines Dreiecksprimitivs eines Quad-Patches.
- 19 - illustriert die Kompression eines D3D11-tessellierten Quad-Patches unter Verwendung der Indexpufferkompression mit Prognose und Ableitung aus dem einsamen Apex;
- 20 - illustriert die Kompression einer Reihe verbundener Dreiecksprimitive, die aus der Tessellation eines Patches stammen unter Verwendung der Indexpufferkompression mit Prognose und Ableitung aus dem einsamen Apex;
- 21 - illustriert die Kompression eines D3D11-tessellierten Patches durch Spezifizierung der Domain-Punkt-Indizes als Ringzahl und Ring-Offset;
- 22 - illustriert die Kompression eines D3D11-tessellierten Patches durch Spezifizierung der Domain-Punkt-Indizes als Linienzahl und als Linien-Offset;
- 23 - illustriert die Einrichtung eines Indexkompressionsblockes, der ein Indexpufferkompressionsverfahren nach dem Stand der Technik verwendet;
- 24 - illustriert die Einrichtung eines Indexkompressionsblockes mit der offenbarten Indexpufferkompression und dem Domain-Punkt-Index-Prognoseverfahren.
- 25 - illustriert die Einrichtung eines Indexpufferkompressionsblockes mit der offenbarten Indexpufferkompression und dem erweiterten Domain-Punkt-Index-Prognoseverfahren, um die Kompression der Domain-Punkt-Indizes, welche nicht im Prognoseindexpuffer enthalten sind, einzuschließen.
-
Detaillierte Beschreibung der bevorzugen Ausführungsformen
-
Die Tessellation eines Patches ergibt ein Raster von Domain-Punkten im <u,v> Domainraum mit Positionen, die von den Tessellationsparametern des Patches und einem feststehenden Funktionstessellationschema ermittelt werden. Der Tessellationsalgorithmus kann ein Dreieck-, ein Linien- oder ein Punktprimitiv aus einem Patch ausbilden.
-
Das feststehende D3D11-Funktionstessellationsschema generiert Domain-Punkte für das Patch und weist jedem Domain-Punkt einen Index zu. Die Generierung von Domain-Punkten erfolgt in einem spiralförmigen Muster, das sich entlang der äußeren Kanten des Patches und nach innen bewegt, bis die Mitte des Patches erreicht ist. Die Indizes werden in der Reihenfolge nummeriert, in der die Domain-Punkte erstellt werden und inkrementieren daher um eine Spirale beginnend mit dem kleinsten Indexwert (d. h. 0 in diesem Beispiel) bis zum höchsten Indexwert für die Tessellationsstufe (d. h. 15 in diesem Beispiel). 8 zeigt das Beispiel der D3D11-Tessellation eines Quad-Patches in Dreiecksprimitive durch ungerade Teilung und Anwendung eines Kantentessellationsfaktors von drei auf alle Kanten. Das Spiralmuster der nummerierten Domain-Punkte ist hier sichtbar.
-
Das Konnektivitätsschema der D3D11-Tessellation verwendet einen feststehenden Funktionsalgorithmus, um die Domain-Punkte in die Primitive einzubinden. In 8 hat der Konnektivitätsalgorithmus der Tessellation Dreiecksprimitive generiert, von denen alle so definiert sind, dass sie drei Domain-Punkte verwenden und referenziert sind, dass sie die entsprechenden Domain-Punkt-Indizes verwenden. Das Verfahren zur Bestimmung der Konnektivität der Domain-Punkte wird vom verwendeten Tessellationssystem definiert (in diesem Fall D3D11); eine weitere Diskussion hierüber ist zum Verständnis dieser Erfindung nicht erforderlich. Der Fachmann weisst, dass jeder Konnektivitätsalgorithmus angewendet werden kann. In der Annahme, dass es sich um Dreiecksdefinitionen im Uhrzeigersinn handelt, ist ersichtlich, dass die tessellierte Fläche Dreiecksprimitive enthält, wobei jedes Primitiv durch drei Domain-Punkt-Indizes definiert werden kann, z. B.: {0,1,12}, {12,1,13}, {13,1,2} etc. Anstatt die Indizes den Domain-Punkten zuzuweisen, können alternativ dazu die im Tessellationskonnektivitätsverfahren erstellten Primitive einem Primitivindex in der Reihenfolge, in der sie erstellt wurden (siehe 9), zugeordnet werden. Dabei wird jedes Primitiv (Dreieck) von 0 bis 16 nummeriert.
-
Der feststehende Funktionstessellator von D3D11 kann, ebenso wie Dreiecksprimitive, auch Linien- und Punktprimitive erstellen, indem er Domain-Punkte in einem Raster-Scan-Prozess definiert, der sich sequentiell durch das Patch arbeitet, bevor er zur nächsten Zeile übergeht. 10 zeigt ein Beispiel von D3D11-Tessellation eines Linienprimitivs, bei der eine Unterteilung der ungeraden Zahlen erfolgt und Tessellationsfaktoren von 3 für Detail/Dichte (d. h. äquivalent zu den Tessellationsfaktoren für horizontale/vertikale Kanten) angewendet werden. Die Indizes sind in der Reihenfolge nummeriert, in der die Domain-Punkte erstellt wurden und inkrementieren daher in einer Raster-Scan-Sequenz in jeder Zeile, bevor die nächste Zeile abgearbeitet wird. Das Konnektivitätsschema der D3D11-Tessellation verwendet einen feststehenden Funktionsalgorithmus, um die Domain-Punkte in die Linienprimitive einzubinden. Bei Linienprimitiven wird jedes Primitiv von zwei Domain-Punkt-Indizes definiert. Das Verfahren zur Bestimmung der Konnektivität von Domain-Punkten ist durch den Konnektivitätsalgorithmus der D3D11-Tessellation definiert. Es ist ersichtlich, dass die tessellierte Fläche, die in 10 dargestellt ist, Linienprimitive enthält, von denen jedes Primitiv von zwei Domain-Punkt-Indizes definiert werden kann, z. B.: {0,1}, {1,2}, {2,3}, etc. Alternativ dazu kann den Primitiven ein Identifikator in der Reihenfolge, in denen sie erstellt wurden (siehe 11 (0, 1, 2 etc.), zugeordnet werden.
-
In einem kachelbasierten Renderer ist es notwendig zu ermitteln, welche Primitive der jeweiligen tessellierten Patches in jeweils einer Kachel vorhanden sind. 12 zeigt die gleiche tessellierte Fläche, die in 8 beschrieben ist, wobei jedoch zusätzlich ein schattierter Kachelbereich 1201 eingeblendet wurde. Dieser Kachelbereich illustriert den sichtbaren Bereich der rechteckigen Kachel, wenn sie in eine Domain des Patches projiziert wird, d. h. die Schnittlinie der Kachel und mit dem Patch ist sichtbar. Von Primitiven, die ganz oder teilweise vom Kachelbereich überlappt werden, kann gesagt werden, dass sie ganz oder teilweise in der Kachel vorhanden sind und in die Objektliste für diese Kachel aufgenommen werden müssen. In diesem Beispiel überlappen sich die Dreiecke, die die Indizes {0,1,12},{12,1,13}, {13,1,2}, {2,3,13}, {3,4,13} und {11,0,12} definiert haben mit dem Kachelbereich und sind daher entweder teilweise oder ganz in der Kachel vorhanden (bei diesem Beispiel befinden sie sich alle teilweise in der Kachel). Alle anderen Primitive des tessellierten Patches überschneiden sich nicht mit dem schattierten Kachelbereich und sind daher nicht in der Kachel vorhanden, so dass sie den Inhalt der Kachel während des Rendering nicht anzeigen müssen. Primitive, die ganz oder teilweise in der Kachel vorhanden sind, werden der Objektliste dieser Kachel hinzugefügt; die anderen Primitive des tessellierten Patches jedoch nicht. Bei diesem Beispiel wird der Mindestsatz von Primitiven aus dem Patch gespeichert, die während des Rendering der Kachel erforderlich sind.
-
Eine kachelbfasierte Rendering-Pipeline, die eine Tessellation anspricht, welche einen zweistufigen Tessellationsprozess anwendet, wurde vor kurzem in der britischen Patentanmeldung Nr. 10077348.4 offenbart. Bei diesem System werden in einem ersten Schritt des Tessellationsverfahrens die Patches ermittelt, die Primitive enthalten, welche ganz oder teilweise in einer Kachel vorhanden sind, und ein zweiter Tessellationsschritt wird während des Renderings der einzelnen Kacheln ausgeführt, um die Primitive, die in der Kachel eines jedes Patches vorhanden sind, erneut zu erstellen. Die inhärente Trennung der Kachelungsphase und Rendering-Phase in einer solchen kachelbasierten Architektur macht es erforderlich, dass die gekachelte Geometrie bis zu ihrer Verwendung in den Speicher ausgeschrieben und später in die Pipeline für das Rendering zurückgelesen wird. Wünschenswert ist daher die Kompression der Objektlistendaten, die die in jeder Kachel vorhandene Geometrie beschreiben, um die Speicheranforderungen an die Speicherung und die damit verbundene Bandbreitennutzung für das Lesen/Schreiben der Primitivedaten in den Speicher, zu minimieren.
-
Ausführungsformen dieser Erfindungen stellen ein effizientes Kompressionsverfahren der in jeder Kachel vorhandenen Geometrie bereit. Wichtig für die Kompression ist die Erkenntnis, dass die Primitive, die bei der Projizierung in das Gebiet eines tessellierten Patches ganz oder teilweise in einer Kachel vorhanden sind, ganz allgemein die Lokalität anzeigen, das bedeutet, dass wenn sich ein Primitiv in einer Kachel befindet, die Wahrscheinlichkeit besteht, dass benachbarte Primitive ebenfalls in der Kachel vorhanden sind. Im Fall der in 9 und 11 illustrierten Patches, in denen Primitive, die in einer Kachel vorhanden sind von einem Primitivindexwert definiert sind, ist es wahrscheinlich, dass die Lokalität dazu führt, dass Primitive mit aufeinander folgenden Primitiveindizes in der gleichen Kachel gespeichert werden. Diese aufeinander folgenden Primitivindizes können leicht als Durchlauf inkrementierender Werte oder als Lauflängenkodierung von Unterschieden zwischen aufeinander folgenden Werten komprimiert werden. Ähnlich können im Fall der in 8 und 10 illustrierten Patches, in denen Primitive anhand einer strukturierten Liste mit Domain-Punkt-Indizes definiert werden, die Domain-Punkt-Indizes zuerst sortiert und dann anhand eines ähnliches Durchlaufs inkrementierender Werte oder als Lauflängenkodierung der Unterschiede zwischen aufeinander folgenden Werten komprimiert werden. In beiden Fällen erlaubt das Sortierverfahren eine einfache und effiziente Kompression, jedoch gehen Struktur und Konnektivität dieser Domain-Punkte im Indexsortierverfahren verloren.
-
Um diese Kompressionsschemata zu verwenden, ist es notwendig, die Tessellationskonnektivität neu zu berechnen, wenn Daten in späteren Stufen der Pipeline verwendet werden. Darüber hinaus ist eine Neuberechnung der Primitivsichtbarkeit anhand einer Sortierliste aus Domain-Punkt-Indizes mit Primitiven, die sich in einer Kachel befinden, keine Garantie dafür, dass eine Mindestsatz von Dreiecken in der Kachel vorhanden ist. Beachten Sie das Beispiel in 13, in der vier Dreiecksprimitive aus einem Patch (A, B, C und D) auf einem schattierten Kachelbereich 1101 gekachelt werden. Die Primitive A, B und D sind teilweise oder ganz in einer Kachel vorhanden; daher müssen die Primitivindizes {1,2,3}, {3,4,5}, {5,6,1} in die Kachel aufgenommen werden. Das Primitiv C ist nicht in der Kachel enthalten, daher müssen seine Domain-Punkt-Indizes nicht ausdrücklich in die Kachel aufgenommen werden.
-
Sollte die sortierte Kompression angewendet werden, lautete die Liste der Domain-Punkt-Indizes, die die in der Kachel vorhandenen Primitive beschreiben, {1,2,3,4,5,6}. Auch wenn die Domain-Punkt-Indizes nicht ausdrücklich in die Kachel aufgenommen werden, ist jeder Domain-Punkt-Index des Primitivs C (d. h. 1, 3 und 5) bereits in der Sortierliste der Domain-Punkt-Indizes dieser Kachel vorhanden. Dies kommt vor, weil die Domain-Punkt-Indizes des Primitivs C, das nicht in der Kachel enthalten ist, mit den Primitiven A, B und D, die sich bei der Neuberechnung der Tessellationskonnektivität in der Kachel befinden, geteilt werden; das Dreieck C würde daher fälschlicherweise als in der Kachel bestehend neu erstellt, sofern es nicht ausdrücklich ausgeschlossen wird.
-
Der Einschluss einer geringen Anzahl unerwünschter Dreiecke stellt bei bestimmten Anwendungen keinen größeren Aufwand dar. Ähnlich verhält es sich in Fällen, in denen nur eine kleine Menge Primitive aus einem Patch ausgeschlossen werden müssen und es besser wäre, eine Liste der aus der Kachel auszuschließenden Primitive anstelle einer Liste der aufzunehmenden Primitive zu speichern.
-
Bei vielen Anwendungen ist es wünschenswert, die Konnektivitätsinformationen der ersten Tessellation eines Patches beizubehalten, um eine Neuberechnung der Tessellationskonnektivität an späterer Stelle in der Pipeline zu vermeiden. Daher ist ein Kompressionsschema erforderlich, dass die Konnektivitätsinformationen aufrechterhält. Beachten Sie die Tessellation eines Quad-Patches in Dreiecksprimitive, wie in 14 gezeigt. Eine unkomprimierte Domain-Punkt-Indexliste für Primitive eines tessellierten Patches ist in der Tabelle enthalten. Daten in diesem unkomprimierten Domain-Punkt-Indexformat können ohne Sortierung nicht anhand einer einfachen Lauflängenkodierung der Unterschiede sortiert werden. Ähnliches gilt, wenn Dreieckfächer des in 7 gezeigten Typs und abrupte Änderungen der Primitivfolge die mit herkömmlichen Kompressionsschemata, z. B. Dreieckstreifen, erreichbare Kompression aufgrund des damit verbundenen Aufwands bei jeder Unterbrechung einschränken. Höhere Tessellationsstufen, wie zuvor in 7 gezeigt, können erheblich mehr Dreieckfächer und Dreieckstreifenübergänge enthalten. Der am besten geeignete herkömmliche Kompressionsmechanismus ist daher die konventionelle Indexpufferkompression.
-
Bei D3D11 kann jedes Patch in bis zu 4225 Domain-Punkte tesselliert werden. Bei Anwendung der Dreieckskonnektivitätstessellation können bis zu 8192 Dreiecksprimitive erstellt werden. Wenn jedes im Tessellationsverfahren erstellte Dreiecksprimitiv von drei Domain-Punkt-Indizes definiert wird, sind für das tessellierte Patch 24756 Domain-Punkt-Indizes erforderlich. Die Speicherung von Primitiven in unkomprimierter Form würde 13 Bits pro Domain-Punkt-Index und ca. 24756 * 13 = 42.3 Kilobyte Daten nur für das Primitivnetz erfordern. Die Details darüber, wie viele Domain-Punkte/Dreiecke von einem D3D11-Tessellationsalgorithmus produziert werden können, gehen umfassend aus der Spezifikation von D3D11 hervor und werden lediglich zu Referenz- und Kontextzwecken zur Verfügung gestellt.
-
Die herkömmliche Indexpufferkompression verringert die Anforderungen an die Speicherung. Wenn ein Domain-Punkt-Index im aktuellen Primitiv oder frühere Domain-Punkt-Indizes im Puffer vorhanden sind, muss nur die Position im Puffer gespeichert werden und nicht der vollständige Domain-Punkt-Index. Im Falle von Dreiecksprimitiven, die von einem D3D11-Tessellationsalgorithmus generiert wurden, kann ein 13-Bit Domain-Punkt-Indexwert, der im Puffer vorhanden ist durch eine 2-Bit Pufferposition ersetzt werden (in der Annahme, dass der Puffer nur die drei Domain-Punkt-Indizes des vorherigen Dreiecksprimitivs enthält). Erwähnenswert ist, dass, um die Indexpufferkompression zu verwenden, ein 1-Bit Flag vor jedem Indexwert erforderlich ist, um anzugeben, ob der folgende Domain-Punkt-Indexwert ein 13-Bit Domain-Punkt-Indexwert oder eine 2-Bit Pufferposition ist.
-
14 zeigt die Ergebnisse, wenn die herkömmliche Indexpufferkompression auf eine unkomprimierte Domain-Punkt-Indexliste mit Primitiven angewandt wird. Der Puffer enthält drei Domain-Punkt-Indizes des vorherigen Dreiecksprimitivs. Werte in eckigen Klammer verweisen auf die Pufferposition des geforderten Domain-Punkt-Index, wobei [0] der erste Wert im Puffer ist. Bei der Erstellung einer Bitstrom Ausgabe muss jeder Domain-Punkt-Index, der nicht im Puffer vorhanden ist durch ein ‚0‘ Bit dargestellt werden, welches anzeigt, dass der Index nicht im Puffer vorhanden ist, gefolgt von einem vollständigen 13-Bit Indexwert. Jeder Domain-Punkt-Index, der im Puffer vorhanden ist, muss durch ein ‚1‘ Bit dargestellt werden, welches anzeigt, dass der Index im Puffer vorhanden ist, gefolgt von einer 2-Bit Pufferposition. Der resultierende komprimierte Bitstrom des Indexpuffers für das dargestellte tessellierte Patch ist angegeben.
-
Es ist ersichtlich, dass die unkomprimierte Speicherung eines tessellierten Patches 18 Dreiecksprimitive erfordert, von denen jedes einzelne von 3* 13-Bit-Indexwerten = 702 Bits definiert ist. Die herkömmliche Indexpufferkompression ist in der Lage, die gesamte Geometrie mit 21 vollständigen Domain-Punkt-Indexwerten, von denen jeder 14 Bits erfordert (1-Bit Puffer Miss Flag gefolgt von einem 13-Bit Domain-Punkt-Indexwert) und 33 Pufferpositionen (1-Bit Puffertreffer Flag + 2-Bit Pufferpositionen) zu speichern. Dies entspricht (21 × 14) + (33 × 3) = 393 Bits. Die erreichte Kompression beträgt demnach ca. 44 %.
-
Dieses herkömmliche Verfahren der Indexpufferkompression lässt sich durch Hinzunahme eines oder mehrerer prognostizierter Domain-Punkt-Indexwerte in den Puffer verbessern. Die Generierung eines effizienten Prognosemechanismen für ein beliebig nummeriertes Primitivnetz ist nicht möglich. Durch die Beschränkung des Kompressionsschemas auf die Tessellationsanwendung können die inhärente Lokalität und die zugrunde liegende Struktur der Domain-Punkt-Indizes verwendet werden, um eine effiziente Prognose der Domain-Punkt-Indizes zu generieren. Ein höchst erfolgreiches Prognoseschema des Domain-Punkt-Index, das nur die Domain-Punkt-Indizes verwendet (z. B. die Werte im Puffer), lässt sich durch Anwendung eines erfindungsgemäßen Verfahrens erreichen.
-
24 illustriert die veränderte Einrichtung des Indexkompressionsblockes. Bei dieser Architektur werden Indexlisten der zuvor gezeigten Primitive in einem Indexpuffer 2420 gespeichert. Der Indexpuffer wird erweitert, um einen oder mehrere prognostizierte Domain-Punkt-Indexwerte einzuschließen. Die Indexselektion 2421 identifiziert den Domain-Punkt-Indexwert, der in den vorherigen Primitivindizes enthalten war, und der als Basis des/der prognostizierten Indexwerte(s) dient und als Selektierter Index bezeichnet wird. Das Selektionsverfahren wird in diesem Patent offenbart. Der selektierte Index wird dann mit Hilfe des in diesem Patent offenbarten Verfahrens der Indexprognose 2422 geändert, um anhand eines Prognosemodifikators einen oder mehrere prognostizierte Indexwerte zu generieren. Optional prognostizierte Indexwerte, die bereits im Indexpuffer vorhanden sind, können durch eine weitere Änderung der Indexprognose 2423 entfernt werden. Beim Hinzufügen eines neuen Primitivs werden die unkomprimierten Domain-Punkt-Indizes des Primitivs 2410 mit dem Indexpuffer 2430 sowie mit den vorherigen Primitivindizes und den prognostizierten Indizes verglichen. Ein Indexwert, der bereits vorhanden ist, kann durch eine Pufferposition im Indexpuffer einschließlich der Stelle, an der der gesamte Indexwert gespeichert wird, dargestellt werden. In der Annahme, dass sich die Position im Indexpuffer mit Prognose mit weniger Bits als dem Indexwert selbst beschreiben lässt, ist die Kompression erreicht 2490.
-
Das Prognoseschema des Domain-Punkt-Index hängt von der Art Primitiv ab, die der Tessellationsalgorithmus verwendet. Handelt es sich um Punktprimitive, wird ein Punkt durch einen einzigen Domain-Punkt-Index definiert. Nach der Verarbeitung des aktuellen Primitivs mit dem Domain-Punkt-Index A, ist der nächste Domain-Punkt-Index wahrscheinlich A+1. Wir können sagen, dass der gewählte Index der Domain-Punkt-Index A ist und der Prognosemodifikator ist +1. Demgemäß kann ein prognostizierter Domain-Punkt-Indexwert A+1 generiert und im Indexpuffer gespeichert werden.
-
Im Fall von Linienprimitiven ist eine Linie durch zwei Domain-Punkt-Indizes A und A+1 definiert. Nach der Verarbeitung des aktuellen Primitivs werden die Indizes A und A+1 im Indexpuffer gespeichert und benötigen nur eine 1-Bit Pufferposition. Wird der Puffer erweitert, um einen prognostizierten Indexwert aufzunehmen, ist eine 2-Bit Pufferposition erforderlich. Ein 2-Bit Pufferpositionscode erlaubt den Zugriff auf vier Indexwerte, d. h. auf zwei Indizes für das vorherige Linienprimitiv und zwei für die prognostizierten Indexwerte. Für Linienprimitive lauten zwei effektiv prognostizierten Domain-Punkt-Indexwerte daher A+2 und A+3 (d. h. der höchste Domain-Punkt-Indexwert wird als selektierten Index verwendet (d. h. A+1), und die Prognosemodifikatoren sind der selektierte Index plus eins und der selektierte Index plus zwei).
-
15 zeigt den Vorteil, der sich ergibt, wenn ein Domain-Punkt-Indexwert aus dem höchsten Domain-Punkt-Indexwert in den Puffer plus eins aufgenommen wird. Das vorherige Linienprimitiv war durch Domain-Punkt-Indizes {4,5} definiert.
-
Die prognostizierten Indexwerte sind daher {6,7}. Es ist ersichtlich, dass das nächste Linienprimitiv im Patch durch die Domain-Punkt-Indizes {5,6} definiert ist. Beide Indizes sind im Indexpuffer mit prognostizierten Indizes enthalten (einer vom vorherigen Primitiv, der andere von einem prognostizierten Indexwert), so dass eine effektive Prognose und somit Kompression erfolgt ist.
-
16 zeigt den Vorteil, der sich ergibt, wenn zwei prognostizierte Domain-Punkt-Indexwerte aus dem höchsten Domain-Punkt-Indexwert in den Puffer plus eins und der höchste Domain-Punkt-Indexwert plus zwei aufgenommen werden. Das vorherige Linienprimitiv wurde durch Domain-Punkt-Indizes {6,7} definiert. Die prognostizierten Indexwerte sind daher {8,9}. Es ist ersichtlich, dass sich das nächste Linienprimitiv im Patch auf einer neuen Linie befindet und daher keine Indizes des vorherigen Primitivs wiederverwendet. Demzufolge würde das System der herkömmlichen Indexpufferkompression keinen der erforderlichen Domain-Punkt-Indexwerte einschließen. Es ist ersichtlich, dass das nächste Linienprimitiv im Patch durch die Domain-Punkt-Indizes {8,9} definiert ist. Beide Indizes sind im Indexpuffer mit den prognostizierten Indizes vorhanden (beide waren Prognosen), so dass eine effektive Prognose und somit Kompression erreicht wurde.
-
Im Fall von Dreiecksprimitiven ist ersichtlich, dass die geometrische Struktur eines tessellierten Patches aus einer Reihe konzentrischer Ringe von Domainpunkten besteht. Ein einfaches Beispiel einer Dreieckstessellation eines Quad-Patches mit einem gleichmäßigen Tessellationsfaktor 5, der auf alle Kanten angewendet wird, ist in 17 zu sehen. Es ist ersichtlich, dass dieser Patch aus nur vier Ringen besteht, die durch die Domain-Punkt-Indexbereiche {0,...,23}, {24,...,39}, {40,...,47} und einem finalen Innenring, der aus einem einzigen Domain-Punkt-Index {48} besteht, definiert sind. Es ist ersichtlich, dass sich jedes Dreiecksprimitiv, das in dem Patch geschaffen ist, zwischen zwei Ringen erstreckt, wobei sich mindestens ein Vertex des Dreiecksprimitivs auf der äußeren Ringkante und mindestens ein Vertex des Dreiecksprimitivs auf der inneren Ringkante befindet. Jedes Dreiecksprimitiv im Patch kann daher in Bezug auf einen Domain-Punkt-Index auf der äußeren Ringkante (A) und einen Domain-Punkt-Index auf der inneren Ringkante (B) definiert werden. Wir können daher angeben, dass jedes Primitiv entweder durch Verbindung von zwei Domain-Punkten auf der äußeren Ringkante (A, A+1) mit einem Domain-Punkt auf der inneren Ringkante (B) oder ein Domain-Punkt auf der äußeren Ringkante (A) mit zwei Domain-Punkten auf der inneren Ringkante (B, B+1) geschaffen wurde. Daher wird von nun an der Domain-Punkt als solcher auf einem Ring als ein „einsamer Domain-Punkt-Index“ bezeichnet. Die beiden benachbarten Domain-Punkte auf dem anderen Ring werden als „Domain-Punkt-Indexpaar“ bezeichnet.
-
Jedes Dreiecksprimitiv im tessellierten Patch ist definiert durch drei Domain-Punkt-Indizes. Die Domain-Punkt-Indizes des vorherigen Primitivs werden im herkömmlichen Indexpuffer gespeichert. Mit Hilfe eines 2-Bit Codes kann auf diese drei Indizes zugegriffen werden, wobei ein vierter Code-Wert verbleibt, der auf einen prognostizierten Domain-Punkt-Indexwert verweist. Für den im nächsten Primitiv erforderlichen Domain-Punkt-Indexwert wird ein effizientes Prognoseschema offenbart. Der prognostizierte Domain-Punkt-Indexwert ist der einsame Domain-Punkt-Indexwert plus eins. Hinweis: Für die gegen den Uhrzeigersinn definierten Dreiecke würde der prognostizierte Domain-Punkt-Indexwert der einsame Domain-Punkt-Indexwert minus eins sein.
-
18 zeigt den Vorteil, der sich ergibt, wenn ein Domain-Punkt-Indexwert des Einsamen Domain-Punkt-Indexwertes in den Puffer plus eins aufgenommen wird (d. h. der einsame Domain-Punkt-Index wird als selektierten Index verwendet und ein Prognosemodifikator von +1 angewendet). Das vorherige Dreiecksprimitiv wurde durch Domain-Punkt-Indizes {26, 27, 41} definiert. Es ist ersichtlich, dass die Werte im Indexpuffer aus zwei benachbarten Domain-Punkt-Indexwerten {26, 27} bestehen, bei denen es sich um das Domain-Punkt-Indexpaar und um einen isolierten Domain-Punkt-Indexwert {41} handeln muss, wobei der Letztgenannte der einsame Domain-Punkt-Indexwert sein muss. Die Ermittlung des einsamen Domain-Punkt-Index erfolgt daher direkt mit den im Indexpuffer gespeicherten Werten, ohne dass zusätzliche Informationen des Tessellators über den gerade verarbeiteten Ring erforderlich sind. Demgemäß wird ein prognostizierter Wert, der um eins größer ist, als der Einsame Domain-Punkt-Indexwert in den Indexpuffer hinzugefügt und bildet einen Indexpuffer mit Prognose, der Domain-Punkt-Indexwerte {26, 27, 41, 42} enthält. Das nächste Primitiv im Patch ist durch die Domain-Punkt-Indizes {41, 27, 42} definiert, die alle im Puffer vorhanden sind (zwei vom vorherigen Primitiv und einer von dem offenbarten Prognoseverfahren des Domain-Punkt-Index), so dass eine effektive Prognose und Kompression erzielt wurde.
-
Ein alternatives Prognoseverfahren (oder ergänzendes Prognoseverfahren in Umgebungen mit größeren Indexpuffern) besteht darin, den Domain-Punkt-Indexwert am Anfang des Außenrings zu speichern. Dieser Domain-Punkt wird wahrscheinlich wieder verwendet, da das finale Dreieck in einem Ring normalerweise mit dem ersten Dreieck im Ring zusammengeführt wird. Obwohl im Allgemeinen ein Vergleich mit dem oben offenbarten Prognoseschema des einsamen Domain-Punkt-Index plus eins ineffizient ist, ist dieses Schema hilfreicher, wenn die Tessellationsfaktoren klein sind oder wenn bei großen Tessellationsfaktoren die Dreiecke in den inneren Ringen gespeichert werden. Es ist auch besser als die Domain-Punkte eines früheren Dreiecksprimitivs einfach beizubehalten, was normalerweise immer in einem herkömmlichen Indexpuffer ohne Prognose geschieht.
-
Eine Minderheit von Dreiecksprimitiven in einem Patch kann so definiert werden, dass der einsame Domain-Punkt-Indexwert und ein Domain-Punkt-Indexpaar nicht direkt über die im Puffer vorhandenen Werte ermittelt werden können. Dieser Fall ist aus 8 ersichtlich, wo ein tesselliertes Quad-Patch ein Dreiecksprimitiv beinhaltet, das durch Domain-Punkt-Indizes {12, 13, 14} definiert ist. Da alle drei Domain-Punkt-Indizes sequentiell sind, ist es nicht offensichtlich, welcher Domain-Punkt-Indexwert der einsame Domain-Punkt-Indexwert ist und als selektierten Index verwendet werden soll. Alternativ können Situationen entstehen, in denen drei nicht inkrementierende Domain-Punkt-Indizes ein Dreiecksprimitiv definieren. Dieser Fall ist in 8 zu sehen, wo ein tesselliertes Quad-Patch ein Dreiecksprimitiv enthält, das durch Domain-Punkt-Indizes {15,10,12} definiert ist. Da alle drei Domain-Punkt-Indizes nicht-sequentiell sind, ist es nicht offensichtlich, welcher Domain-Punkt-Indexwert der einsame Domain-Punkt-Indexwert ist, der als selektierter Index verwendet wird. In diesen Situationen muss ein alternatives Index-Selektionsverfahren angewendet werden. Geeignete alternative Schemata ermöglichen das Hinzufügen eines Prognosemodifikators, der einen Wert über oder unter dem kleinsten, mittleren oder maximalen Domain-Punkt-Indexwert im Puffer liegt, oder, wie zuvor beschrieben, das Hinzufügen des ersten Domain-Punkt-Indexwertes des äußeren Rings. Ausgearbeitete Beispiele, die nachfolgend in diesem Patent angegeben sind, wenden in Fällen, in denen ein einsamer Domain-Punkt-Indexwert nicht identifiziert werden kann, eine Faustregel an: Der gewählte Domain-Punkt-Indexwert ist der mittlere Domain-Punkt-Indexwert im Puffer mit einem Prognosemodifikator von plus eins. Dies ist in den Figuren durch das Wort „MED“ dargestellt.
-
Um die Effizienz des Puffers zu optimieren, ist es ebenfalls wünschenswert, eine Wiederholung, zu der es immer dann kommt, wenn der prognostizierte Domain-Punkt-Indexwert bereits im Puffer vorhanden ist, zu vermeiden. In diesen Situationen kann der prognostizierte Domain-Punkt-Indexwert durch eines der oben genannten alternativen Prognoseschemata ersetzt oder inkrementiert werden, bis ein Domain-Punkt-Indexwert gefunden wird, der noch nicht im Puffer vorhanden ist. Ausgearbeitete Beispiele, die nachfolgend in diesem Patent angegeben sind, wenden im Fall eines duplizierten Pufferindexes eine Faustregel an: Der prognostizierte Domain-Punkt-Indexwert wird durch den maximalen Domain-Punkt-Indexwert im Puffer plus eins ersetzt. Dies ist in den Figuren durch das word „MAX“ dargestellt.
-
19 illustriert die Indexpufferkompression mit Prognose unter Verwendung des gleichen Quad-Patches, das zuvor mit der herkömmlichen Indexpufferkompression, wie in 14 illustriert, komprimiert wurde. Der Indexpuffer ist am Anfang leer, und das erste Primitiv wird mit Domain-Punkt-Indizes generiert {0, 1, 12}. Hinweis: Anstatt mit einem leeren Puffer zu starten, könnte der Indexpuffer mit einigen prognostizierten Werten, wie {0, 1, 2, 3} oder den ersten zwei Domain-Punkt-Indexwerten, die aus den äußeren beiden Ringen genommen werden, z. B. {0,1} und {12,13} gefüttert werden. Angenommen, dass der Indexpuffer am Anfang leer ist, müssen die ersten drei Domain-Punkt-Indexwerte, die das erste Primitiv im Patch definieren, unter Anwendung vollständiger Domain-Punkt-Indexwerte gespeichert werden.
-
Zuvor wurde gezeigt, dass für die unkomprimierte Speicherung eines tessellierten Patches 18 Dreiecksprimitive erforderlich sind, von denen jedes durch 3 * 13-Bit Indexwerte = 702 Bits (0 % Kompression) definiert ist. Die herkömmliche Indexpufferkompression hat dies auf 21 vollständige Domain-Punkt-Indexwerte reduziert, wobei jeder Wert 14 Bits (1-Bit Puffer Miss Flag gefolgt von einem 13-Bit Domain-Punkt-Indexwert) und 33 Pufferpositionen (1-Bit Puffertreffer-Flag + 2-Bit Pufferposition) = 393 Bits (44 % Kompression) erfordert. Es ist ersichtlich, dass die Indexpufferkompression mit Prognose dies weiter auf 15 vollständige Domain-Punkt-Indexwerte reduziert hat, wobei jeder Wert 14 Bits (1-Bit Puffer Miss Flag gefolgt von einem 13-Bit Domain-Punkt-Indexwert) und 39 Pufferpositionen (1-Bit Puffertreffer-Flag + 2-Bit Pufferposition) = 327 Bits (55 % Kompression) erfordert. Selbst anhand dieses einfachen Beispiels ist ersichtlich, dass die Indexpufferkompression mit Prognose bedeutet, dass die Datenmenge, die für die Darstellung des tessellierten Patches notwendig ist, signifikant reduziert werden können.
-
Eine gemeinsame Datenstruktur bei der Dreiecktessellation eines Patches ist der Dreieckstreifen. Diese Form der sich wiederholenden Geometrie tritt meist an den Kanten eines Rings in stark tessellierten Patches auf. Es wird offenbart, dass exakte Prognosen des Domain-Punkt-Indexwertes in einem Indexpuffer mit Prognoseverfahren ein Wiederholungsmuster der Pufferpositionszugriffe bei wiederholter Geometrie, welche Dreieckstreifen beinhaltet, verursachen.
-
20 illustriert einen typischen Dreieckstreifen nach der Indexpufferkompression mit Prognose. Es ist offensichtlich, dass die Generierung von Prognosen mit dem Verfahren des einsamen Domain-Indexwertes plus eins in einem Dreieckstreifen-Szenario äußerst effizient ist, wie alle Domain-Punkt-Indexwerte, die korrekt prognostiziert wurden und im Indexpuffer vorhanden waren, belegen. Es ist ersichtlich, dass, nachdem das erste Dreieck deklariert wurde, ein Wiederholungsmuster der Pufferzugriffsmuster feststeht, z. B. {[2],[1],[X]} gefolgt von {[1],[X],[2]}. Es ist wichtig zu beachten, dass die Pufferpositionswerte immer von der Anordnung der Domain-Punkt-Indizes, die im ersten Dreieck einer Sequenz verwendet werden, abhängen. Es ist daher nicht speziell das Muster {[2],[1],[X]} gefolgt von {[1],[X],[2]}. Wenn die Anordnung der Domain-Punkt-Indizes des ersten Dreiecks anders war, kann sich eine Reihenfolge, wie {[3],[2],[X]} gefolgt von {[X],[3],[2]} ergeben haben. Beachten Sie jedoch, dass das Wiederholungsmuster intensiven Gebrauch vom prognostizierten Domain-Punkt-Index [X] macht. Die Wiederholung von Pufferzugriffsmustern ist nur möglich, wenn exakt prognostizierte Domain-Punkt-Werte im Puffer vorhanden sind. Nachdem festgestellt wurde, dass die Pufferzugriffsmuster repetitiv sind, können sie noch weiter komprimiert werden. Das vorgeschlagene Verfahren zur Kompression dieser Pufferzugriffsmuster besteht darin, zuerst die beiden anfänglichen Pufferzugriffe am Anfang der Wiederholungsmuster, zu spezifizieren, gefolgt von einem Wiederholungswert, der angibt, wie viele Male die Pufferzugriffsmuster wiederholt werden sollen. Das Beispiel in
20 würde folgende Struktur haben:
-
2 MAL WIEDERHOLEN
-
Dies lässt sich noch weiter verbessern, indem Bruchwerte zugelassen werden, um die Anzahl der Wiederholungen der Pufferzugriffsmuster festzulegen, z. B.:
-
2,5 MAL WIEDERHOLEN
-
Während die Indexpufferkompression mit Prognose darauf abzielt, die für das nächste Primitiv erforderlichen Domain-Punkt-Indexwerte exakt vorherzusagen, können Situationen auftreten, in denen die Prognose nicht korrekt ist. In diesen Situationen muss ein vollständiger Domain-Punkt-Indexwert gespeichert werden. Dass die geforderten Indexwerte nicht im Indexpuffer vorhanden sind, kann häufig beim ersten Primitiv eines Patches und wenn Primitive des tessellierten Patches fehlen (eine Situation, die während der Kachelung eintreten kann) passieren.
-
Es ist daher wünschenswert, die Domain-Punkt-Indexwerte, die nicht im Indexpuffer in komprimierter Form vorhanden sind, zu spezifizieren. Normalerweise benötigt ein Domain-Punkt-Indexwert in einem D3D11-Patch 13 Bits, um den Bereich möglicher Werte abzudecken. Anstatt jeden Domain-Punkt-Indexwert zu speichern, der nicht im Indexpuffer vorhanden ist, ist es möglich, den Bereich der Domain-Punkt-Indizes vorzuberechnen, und falls dieser Bereich der Domain-Punkt-Indexwerte weniger als 13 Bits für die Darstellung benötigt, kann die Kompression erfolgen, und ein Komprimierter Domain-Punkt-Index wird gespeichert. Die Anzahl der in einem Patch vorhandenen Domain-Punkt-Indizes kann leicht mit Hilfe des D3D11-Domain-Tessellationsalgorithmus ermittelt werden und ist unabhängig vom Tessellationskonnektivitätsprozess. Da die maximale Anzahl der Domain-Punkte für ein Patch bei gegebenen Tessellationsfaktoren immer leicht auf der Kompressions- und später auf der Dekompressionsstufe berechnet werden kann, ist die Anzahl der zum Speichern der einzelnen Indexwerte verwendeten Bits immer bekannt, ohne dass ein zusätzlicher Aufwand im Bitstrom erforderlich ist.
-
Im Fall von Dreiecksprimitiven wird offenbart, dass die Domain-Punkt-Indexwerte weiter zu komprimierten Domain-Punkt-Indizes komprimiert werden können, indem jeder Domain-Punkt-Index als eine Ringzahl und ein Offset rund um den gewählten Ring definiert wird. Die Ringzahl definiert den Basisidentifikator des komprimierten Domain-Punkt-Index. 21 illustriert ein Quad-Patch nach der Tessellation eines Dreiecksprimitivs und zeigt Domain-Punkt-Indizes, die als Ringzahl (R) gefolgt von einem Offset rund um den Ring (O) im Format R:O nummeriert sind. Das schattierte Dreiecksprimitiv dieses Patches könnte daher in diesem Format von den komprimierten Domain-Punkt-Indizes (2:0, 1:1, 2:1) definiert sein. Mit Hilfe des D3D11-Domain-Tessellationsalgorithmus und der angeforderten Kantentessellationsfaktoren kann leicht ermittelt werden, wie viele Ringe im tessellierten Patch vorhanden sind (in diesem Fall 4) und wie der Indexwert der einzelnen Ringe lautet. Daraus ergibt sich, wie viele Bits erforderlich sind, um die maximale Anzahl der Ringe darzustellen, die im tessellierten Patch vorhanden sind (in diesem Fall 2-Bits), und wie viele Bits erforderlich sind, um einen Offset rund um jeden Ring darzustellen. Es ist wichtig zu beachten, dass selbst bei hohen Tessellationsstufen, bei denen viele Domain-Punkte auf den äußeren Ringen vorhanden sind, die inneren Ringe immer weniger Bits erfordern, um den maximalen Offset rund um den Ring darzustellen. Da die Anzahl der Bits, die für den Offset rund um einen Ring erforderlich sind, abhängig ist von der Anzahl der Bits, die für den Offset rund um andere Ringe im Patch verwendet werden, können immer erhebliche Einsparungen erzielt werden.
-
Im ausgearbeiteten Beispiel der 21 ist ein Quad-Patch unter Verwendung von Dreiecksprimitiven, gerader Tessellation und einem auf alle Kanten angewandten Tessellationsfaktor 5, tesselliert. Mit dem D3D11-Domain-Tessellationsalgorithmus kann vorausberechnet werden, dass die resultierende Fläche 49 Domain-Punkt-Scheitelpunkte haben wird und aus 4 Ringen besteht. Auch ergibt sich aus dem Domain-Tessellationsalgorithmus, dass der erste Domain-Punkt-Index in den Ringen 0, 24, 40 und 48 lautet. Die Ringzahl der einzelnen Indizes benötigt maximal immer 2-Bits. Wir wissen auch, dass sich 24 Domain-Punkte im Außenring (R=0) befinden, die einen 5-Bit Ring-Offset erfordern, 16 Domain-Punkte in Ringzahl 1 (R=1) erfordern einen 4-Bit Ring-Offset, 8 Domain-Punkte in Ring R=2 erfordern einen 3-Bit Ring-Offset und ein einziger Domain-Punkt-in Ring R=3 benötigt keine Bits für den Offset. Demzufolge wird eine Ringzahl immer durch eine feste Anzahl von Bits definiert, und daraus ist die Anzahl der folgenden Bits, die einen Ring-Offset definieren, ebenfalls bekannt.
-
Das schattierte Dreieck, das durch die komprimierten Domain-Punkt-Indizes {2:0, 1:1, 2:1} definiert ist, kann daher durch den Bitstrom vollständig ausgedrückt werden:
-
Dieser Bitstrom umfasst eine 2-Bit Ringzahl gefolgt von einem 3-Bit Ring-Offset für Ring R=2, eine 2-Bit Ringzahl gefolgt von einem 4-Bit Ring-Offset für Ring R=1 und eine 2-Bit Ringzahl gefolgt von einem 3-Bit Ring-Offset für Ring R=2. Es ist ersichtlich, dass die fortgeschrittenen Kenntnisse darüber, wie viele Bits für jeden Ring-Offset verwendet werden müssen, einen effizienten Datenstrom erlauben, der keines großen Aufwands bedarf, um zu erklären, wie viele Bits für jeden Ring-Offset folgen.
-
In ähnlicher Weise kann das oben erläuterte Ringzahl- und Ring-Offset-Verfahren weiter in eine Ringzahl, eine Kantenzahl und einen Offset an jeder Kante unterteilt werden.
-
Im Fall von Linienprimitiven wird offenbart, dass die Domain-Punkt-Indexwerte als Zeilennummer und als Offset an dieser Zeile dargestellt werden können. Die Zeilennummer definiert den Basisidentifikator des komprimierten Domain-Punkt-Index. 22 illustriert ein tesselliertes Patch mit Linienprimitiv und 36 generierten Domain-Punkte. Die Komprimierten Domain-Punkt-Indizes werden in Klammern mit der Zeilennummer (R) und dem Zeilen-Offset (O) im Format R:0 gezeigt. Um den Bereich von Domain-Punkt-Indizes von 0 bis 35 darzustellen, wäre ein Domain-Punkt-Index mit 6 Bits erforderlich. Bei Verwendung von komprimierten Domain-Punkt-Indizes können die 6 Linienzahlen durch einen 3-Bit-Wert und die 6 Offset-Positionen an jeder Linie ebenfalls durch einen 3-Bit-Wert definiert werden. Scheinbar gibt es bei diesem Beispiel keinen Vorteil bei den komprimierten Domain-Punkt-Indizes.
-
In Kenntnis dessen, dass mehrere Primitive entlang desselben Rings / derselben Kante / derselben Zeile existieren, ist jedoch offenbart, dass weitere Kompressionen erreicht werden können. Im Fall der oben beschriebenen Linienprimitive, muss die Zeilennummer nur einmal per Zeile definiert werden, und alle nachfolgenden Offsets werden weiterhin die gleiche Zeilennummer verwenden, bis die Zeilennummer aktualisiert ist. In diesem Fall ist es notwendig, ein 1-Bit Flag zu verwenden, um anzugeben, ob der folgende Domain-Punkt-Index die vorherige Zeilennummer (‚0‘) wieder verwenden oder eine neue Zeilennummer (‚1‘) einlesen muss. Am Anfang eines Patches kann die aktuelle Zeilennummer auf R=0 initialisiert werden, so dass selbst eine Kompression des ersten Domain-Punkts im Patch möglich ist.
-
Auch im Fall von Dreiecksprimitiven muss die Ringzahl nicht für jeden Domain-Punkt-Index definiert werden. Jedes Primitiv liegt zwischen zwei Ringen; daher muss lediglich entweder die äußere oder innere Ringzahl nachverfolgt und die Ringzahlkomponente der einzelnen Domain-Punkt-Indizes als ein Bit Flag spezifiziert werden, um festzustellen, ob der Punkt auf dem Außenring (0) oder dem Innenring (1) liegt. Mit diesem Verfahren lässt sich die Anzahl der Bits, die für die Speicherung der Ringzahlkomponente von komprimierten Domain-Punkt-Indizes erforderlich ist, reduzieren.
-
Darüber hinaus ist es üblich, dass sich mehrere Primitive entlang des gleichen Ringes und/oder der Ringkante befinden; daher müssen die Ringzahlen/Kantenzahlen so lange nicht wiederholt werden, bis ein neuer Ring / eine neue Kante gefunden ist. Die Wiederverwendung einer Ringzahl erfolgt auf die gleiche Weise wie die Wiederverwendung einer Linienzahl für mehrere Domain-Punkt-Indizes und reduziert die Anzahl der Bits, die für die Speicherung der Ringzahlkomponente der Komprimierten Domain-Punkt-Indizes erforderlich ist.
-
25 illustriert die Einrichtung der Indexpufferkompression mit Domain-Punkt-Prognose, die zuvor in 24 illustriert, hier erweitert, um die Einrichtung für die Kompression der Domain-Punkt-Indizes, die nicht im Indexpuffer vorhanden sind, einzuschließen. Die Tessellationsfaktoren des aktuellen Patches 2510 werden in einen Patch-Analysator 2520 übertragen. Der Patch-Analysator führt eine Tessellationsuntergruppierung durch, die ausreicht, um die Indizes des vollständig tessellierten Patches zu generieren. Für jede Basis im Patch (d. h. Ringe, Kanten oder Zeilen, je nach dem geforderten Tessellationsmodus) wird der Erste Indexwert in einem Patch-Datenpuffer 2530 gespeichert oder bei Bedarf generiert. Wenn der erste Indexwert von zwei aufeinander folgenden Basen bekannt ist, definiert die Differenz den maximalen Offset an dieser Basis. Daher ist es möglich, diese Informationen zu nutzen, um die Mindestanzahl der Bits zu ermitteln, die für die eindeutige Kennzeichnung der einzelnen Basen benötigt werden und für jede Basis die Mindestanzahl der Bits, die erforderlich sind, um den Offset an dieser Basis eindeutig zu kennzeichnen.
-
Bei Hinzunahme eines neuen Primitivs werden bei dieser Architektur die unkomprimierten Domain-Punkt-Indizes des Primitivs 2410 verglichen 2430 mit dem Indexpuffer 2420, einschließlich sowohl der zwei vorherigen Primitivindizes als auch der prognostizierten Indizes. Jeder Indexwert, der sich im Indexpuffer befindet, kann seine Position im Puffer direkt 2590 in die Liste der komprimierten Domain-Punkt-Indizes 2490 schreiben (zusammen mit einem Flag, um anzuzeigen, dass ein Puffertreffer geschehen ist). Für den Fall, dass ein Indexwert nicht im Indexpuffer 2591 vorhanden ist, wird der Index an den Indexwertkompressor 2540 weitergegeben, damit er in eine Basiszahl und einen Offset konvertiert wird. Der Indexwertkompressor verwendet die im Patch-Datenpuffer verfügbaren Daten, um zu ermitteln, zu welcher Basis der Index und der Offset an dieser Basis gehören. Der komprimierte Index kann dann in der Liste der komprimierten Domain-Punkt-Indizes 2490 gespeichert werden, wobei die Mindestanzahl von Bits verwendet wird, die notwendig ist, um einen Grundbestandteil ohne großen Aufwand zu speichern und zu spezifizieren, wie viele Bits für die Grundbestandteile der Basis und des Offsets oder Flags verwendet werden, um anzuzeigen, wo eine Zahl endet und die nächste beginnt. Im einfachsten Kompressionsformat können diese komprimierten Daten bestehen aus 1), einem 1-Bit Flag, um das Fehlen eines Puffers anzuzeigen; 2) einer Basiszahl, die nur so viele Bits wie nötig verwendet, um zu identifizieren, welche der möglichen Basen im aktuellen Patch vorhanden sind; 3) einen Offset, der nur so viele Bits verwendet, um den Bereich der möglichen Offsets entlang der aktuellen Basis zu identifizieren.
-
Der Indexwertkompressor kann so konfiguriert werden, dass er andere als in diesem Patent offenbarte Ausgangsformate erstellt. Einige dieser anderen Ausgangsformate erfordern, dass der Indexwertkompressor die vorherigen Primitive beachtet, um Indizes zu identifizieren, die an derselben Basis auftreten oder sich über zwei benachbarte Basen erstrecken. Dies erreicht er entweder über eine(n) lokale(n) Puffer/Historie oder durch Verwendung von Daten, die bereits im Indexpuffer 2420 über den optionalen Anschluss 2550 vorhanden sind.
-
Im Vergleich zu herkömmlichen Geometriekompressionsverfahren bedeutet die offenbarte Kompression von tessellierten Geometriedaten, welche aus der Tessellation von Patches resultieren, eine beträchtliche Reduzierung der Anzahl von Bits, die für die Speicherung der in den Speicher geschriebenen Domain-Punkt-Indexlisten erforderlich ist